Publicēšana — abonēšana

“Publicēšana — abonēšana” (angļu: publish–subscribe) programmatūras arhitektūrā ir ziņojumapmaiņas modelis, kas apraksta ziņojumu plūsmu starp lietojumprogrammām, ierīcēm vai pakalpojumiem. Šajā modelī, atšķirībā no citiem ziņojumapmaiņas veidiem, ziņojumi netiek sūtīti tiešā veidā no sūtītāja adresātam, bet ziņojumu saņemšanu no izdevējiem un izsūtīšanu abonentiem koordinē brokeris (starpnieks) jeb serveris. Tas nodrošina visu ziņojumu saņemšanu, filtrēšanu, nosaka klientus, kam jāsaņem ziņojumi, un pārsūta ziņojumus parakstītājiem.

Ziņojumi tiek kategorizēti tēmās (angļu: topic; sauktas arī par klasēm vai kanāliem). Izdevējs ziņojumu nosūta noteiktai tēmai, tieši "nezinot", kuri abonenti to saņems. Savukārt abonents saņem visas ziņas no noteiktas tēmas, tieši "nezinot", kurš izdevējs to publicējis.

Šis modelis parasti ir daļa no lielākas ziņojumapmaiņas starpprogrammatūras sistēmas. Lielākā daļa ziņojumapmaiņas sistēmu atbalsta gan “publicēšana — abonēšana” sistēmas, gan ziņojumu rindas modeļus, piemēram, Java Message Service. Šis modelis nodrošina lielāku tīkla mērogojamību un dinamiskāku tīkla topoloģiju nekā ziņojumu rindas modelis.

“Publicēšana — abonēšana” modeli plaši izmanto lietu interneta, automatizācijas, tīkla operāciju un izkliedētās mākoņvides sistēmās. Ziņojumu datu saturs var būt jebkas, sākot no vienas skaitliskas vērtības līdz pat sarežģītiem objektiem, kas attēlo tekstu, sensora datus, audio, video vai citu digitālo saturu.

Vēsture

Viena no agrākajām publiski aprakstītajām “publicēšana — abonēšana” sistēmām bija Isis Toolkit “jaunumu” apakšsistēma, kas aprakstīta 1987. gada Skaitļošanas tehnikas asociācijas Operētājsistēmu principu simpozija konferencē, laikrakstā “Exploiting Virtual Synchrony in Distributed Systems”.

Ziņojumu filtrēšana

“Publicēšana — abonēšana” modelī no visie publicētajiem ziņojumiem abonenti parasti saņem tikai apakškopu. Ziņojumu atlasīšana saņemšanai un apstrādei tiek saukta par filtrēšanu. Filtrēšana parasti notiek pēc tēmas vai satura.

Uz tēmām balstītā sistēmā ziņas tiek publicētas “tēmās” vai nosauktajos loģiskajos kanālos. Abonenti uz tēmām balstītā sistēmā saņems visas ziņas, kas publicētas tēmās, kuras tie abonē, un visi tēmas abonenti saņems vienādas ziņas. Izdevējs ir atbildīgs par to ziņojumu klašu definēšanu, kuras abonenti var abonēt.

Uz saturu bāzētā sistēmā ziņojumi tiek piegādāti abonentam tikai tad, ja šo ziņojumu atribūti vai saturs atbilst abonenta noteiktajiem ierobežojumiem. Abonents ir atbildīgs par ziņu klasificēšanu.

Dažas sistēmas atbalsta šo abu formu hibrīdu; izdevēji izliek ziņojumus tēmā, kamēr abonenti reģistrē uz saturu bāzētas parakstīšanās uz vienu vai vairākām tēmām.

Topoloģija

Daudzās “publicēšana — abonēšana” sistēmās izdevēji sūta ziņojumus brokerim vai notikumu kopnei, un abonenti reģistrē abonementus pie šī brokera, ļaujot brokerim veikt filtrēšanu. Brokeris parasti veic saglabāšanas un pārsūtīšanas funkciju, lai maršrutētu izdevēju ziņojumus abonentiem. Turklāt brokeris var noteikt prioritāti ziņojumiem rindā pirms maršrutēšanas.

Abonenti var reģistrēties noteiktiem ziņojumiem pēc veidošanas laika, inicializācijas laika vai izpildlaika. Grafiskās lietotāja saskarnes sistēmās abonentus var kodēt, lai reaģētu uz lietotāju komandām (piemēram, noklikšķinot uz pogas), kas atbilst veidošanas laika reģistrācijai. Daži ietvari un programmatūras produkti izmanto XML konfigurācijas failus, lai reģistrētu abonentus. Šie konfigurācijas faili tiek nolasīti inicializācijas laikā. Visizsmalcinātākā alternatīva ir iespēja bonentus pievienot vai noņemt izpildlaikā. Šī pēdējā pieeja tiek izmantota, piemēram, datu bāzes trigeros, adresātu sarakstos un RSS.

Datu izplatīšanas pakalpojuma (DDS) starpprogrammatūra neizmanto brokeru vidū. Tā vietā katrs izdevējs un abonents “publicēšana — abonēšana” sistēmā dalās ar metadatiem savā starpā, izmantojot IP multiraides. Izdevējs un abonenti šo informāciju saglabā kešatmiņā lokāli un maršrutē ziņojumus, pamatojoties uz koplietojamā informācijā apzinātajām attiecībām.

Priekšrocības

Vaļīga sasaiste

Izdevēji ir vaļīgi saistīti ar abonentiem, un nav pat jāzina par to eksistenci. Tēmai esot pamatā, izdevējiem un abonentiem ir ļauts palikt nezinošiem par sistēmas topoloģiju. Katrs var turpināt darboties kā normāli neatkarīgs no otra. Tradicionālajā cieši saistītajā klientu un serveru paradigmā klients nevar sūtīt ziņojumus serverī, kamēr nedarbojas servera process, kā arī serveris nevar saņemt ziņojumus, ja nav palaists klients. Daudzas “publicēšana — abonēšana” sistēmas atsaista ne tikai izdevēju un abonentu atrašanās vietas, bet arī atsaista tās īslaicīgi. Vispārēja stratēģija, ko izmanto starpprogrammatūras analītiķi ar šādām “publicēšana — abonēšana” sistēmām, ir noņemt izdevēju, lai ļautu abonentam darboties, izmantojot neizpildītos pakalpojumus (joslas platuma ierobežošanas veids).

Mērogojamība

“Publicēšana — abonēšana” sniedz iespēju labākai mērogošanai nekā tradicionālais “klients — serveris” modelis, izmantojot paralēlo darbību, ziņojumu kešošanu, uz koka struktūras vai tīkla struktūras bāzētu maršrutēšanu utt.

Trūkumi

Visnopietnākā problēma ar “publicēšana — abonēšana” sistēmu ir to galvenās priekšrocības blakusefekts: izdevēja atsaiste no abonenta.

Ziņojumu piegādes problēmas

“Publicēšana — abonēšana” sistēmai jābūt rūpīgi izstrādātai, lai tā spētu nodrošināt spēcīgākas sistēmas īpašības, kādas konkrētam lietojumam varētu būt nepieciešamas, piemēram, drošu piegādi.

Brokeris “publicēšana — abonēšana” sistēmā var būt veidots tā, lai piegādātu ziņojumus uz noteiktu laiku, bet pēc tam pārtraukt piegādes mēģinājumus neatkarīgi no tā, vai tas ir saņēmis apstiprinājumu par to, ka visi abonenti ir veiksmīgi saņēmuši ziņojumu. Šādā veidā izstrādāta sistēma nevar garantēt ziņojumu piegādi lietojumprogrammām, kam vajadzīga droša piegāde. Lai veiktu šādu drošu piegādi (piemēram, pieprasot abonentam publicēt saņemšanas ziņojumus), šāda izdevēja un abonenta pāra ciešāka sasaistīšana jāveic ārpus “publicēšana — abonēšana” arhitektūras.

Izdevējs “publicēšana — abonēšana” sistēmā var pieņemt, ka abonents klausās, ja patiesībā tā var arī nebūt. “Publicēšana — abonēšana” sistēma var tikt izmantota, lai iekārtas varētu nosūtīt problēmas vai kļūmes abonentam, kas parāda un reģistrē šīs problēmas. Ja reģistrētājs sabojājas (notiek avārija), ierīču problēmu publicētāji ne vienmēr saņems paziņojumu par reģistrētāja kļūmi, un kļūdas ziņojumi netiks parādīti vai ierakstīti kādā no “publicēšana — abonēšana” sistēmas iekārtām. Šī ir arī izstrādes problēma alternatīvām ziņojumapmaiņas arhitektūrām, piemēram, klientservera sistēmai. Ja klientservera sistēmā kļūdu reģistrētājs nedarbojas, sistēma saņem norādi par kļūdu reģistrētāja (servera) kļūmi. Šādā gadījumā klientservera sistēmai būs jātiek galā ar šo problēmu, izmantojot liekus kļūdu reģistrēšanas serverus tiešsaistē vai dinamiski nārstojot atteices pieteikšanās serverus. Tas sarežģī klienta un servera realizācijas, kā arī klientservera arhitektūrau kopumā. Savukārt “publicēšana — abonēšana” sistēmā liekos kļūdu reģistrēšanas abonentus, kas ir precīzi esošā reģistrētāja dublikāti, var pievienot sistēmai, lai palielinātu reģistrēšanas uzticamību, neietekmējot nevienu citu iekārtu sistēmā. “Publicēšana — abonēšana” sistēmā drošu kļūdu ziņojumu reģistrēšanas funkciju var pievienot pakāpeniski, pēc iekārtu problēmu ziņojumu reģistrēšanas pamatfunkcijas ieviešanas.

“Publicēšana — abonēšana” struktūras mērogi ir labi maziem tīkliem ar mazu publicētāju un abonenta mezglu skaitu un mazu ziņojumu apjomu. Savukārt, pieaugot mezglu un ziņojumu skaitam, palielinās nestabilitātes iespējamība, ierobežojot “publicēšana — abonēšana” tīkla maksimālo mērogojamību. Piemēram, caurlaidspējas nestabilitāte lielos mērogos ietver:

• ielādes pieauguma periodi, ja abonents pieprasa piesātinātu tīkla caurlaidspēju, kam seko zema ziņojumu apjoma periodi (nepietiekami izmantots tīkla joslas platums)
• palēnināšanās, kad arvien vairāk lietojumprogrammu izmanto sistēmu (pat tad, ja tās sazinās atsevišķos kanālos), ziņojuma apjoma plūsma atsevišķam abonentam palēnināsies.

“Publicēšana — abonēšana” sistēmas var būt pakļautas drošības problēmām, jo brokeros (serveros) ir integrēta informācija par to, kā brokeris var nosūtīt ziņojumus abonentam. Brokeri var būt apmuļķoti nosūtīt paziņojumus nepareizam klientam, tādējādi pastiprinot pakalpojuma pieprasījumu noraidīšanu pret klientu. Paši brokeri varētu tikt pārslogoti, jo tie piešķir līdzekļus izveidoto abonementu izsekošanai.

Pat sistēmās, kas neizmanto brokerus, abonents var saņemt datus, kurus tas nav pilnvarots saņemt. Neautorizēts izdevējs var ievietot “publicēšana — abonēšana” sistēmā nepareizus vai bojātus ziņojumus. Tas īpaši attiecas uz sistēmām, kas apraida vai multiraida savus ziņojumus. Šifrēšana (piemēram, Transport Layer Security, SSL/TLS) var novērst nesankcionētu piekļuvi, bet nevar novērst to, ka autorizēti izdevēji ievada bojātus ziņojumus. Arī citas arhitektūras, kas nav “publicēšana — abonēšana”, piemēram, klientserveru sistēmas, ir neaizsargātas pret pilnvarotiem ziņojumu sūtītājiem, kuri rīkojas ļaunprātīgi.

Skatīt arī

• ziņojumu rinda
• MQTT

Ārējās saites

• Getting started with publish-ubscribe messaging systems Stephen Munnings, embedded.com
• What is Pub/Sub Messaging? AWS
• Publish/subscribe messaging IBM MQ