Publikáló-feliratkozó minta
A számítógép-programozásban a publikáló-feliratkozó programtervezési minta, más néven publish–subscribe programtervezési minta, pub/sub egy üzenetküldési minta, amiben az üzenetek küldői, a publikálók nem közvetlenül küldik üzeneteiket a feliratkozóknak. Az üzeneteket kategóriákba sorolva küldik el a címzetteknek, akikről nem kell tudniuk. Hasonlóan, a feliratkozók bizonyos típusú üzenetekre iratkoznak fel, nem tudván a publikálókról.
A minta az üzenetsor rokona, és tipikusan egy nagyobb üzenetorientált köztes réteg része. A legtöbb ilyen rendszer mindkettőt támogatja, mint például a Java Message Service (JMS).
A minta jobb hálózati skálázhatóságot és dinamikusabb hálózati topológiát eredményez, ezzel pedig a publikálók és az üzenetek szerkezetének módosítását nehezíti meg.
Üzenetek szűrése
[szerkesztés]Ebben a modellben a feliratkozók nem kapnak meg minden üzenetet. Az üzenetek fogadásának és feldolgozásának folyamata a szűrés. Ennek két gyakori formája a téma és a tartalom alapú.
Téma alapú rendszerben a publikálók témákba osztják üzeneteiket. A feliratkozók témákra iratkoznak fel. Ezekben minden üzenetet megkapnak, és az adott témára feliratkozók ugyanazokat az üzeneteket kapják.
Tartalom alapú rendszerben a feliratkozók definiálják az üzenetek bizonyos jellemzőit, hogy ők ilyen üzeneteket szeretnének kapni. A publikálók gondoskodnak arról, hogy a megfelelő üzenetek eljussanak a megfelelő feliratkozókhoz.
Vannak hibrid rendszerek is, ahol az osztályozás finomabb, és a rendszer mindkettőt figyelembe veszi.
Topológia
[szerkesztés]Sok rendszerben egy köztes objektum feladata a kézbesítés (lásd postás programtervezési minta). Ez kezeli a feliratkozásokat, oszt prioritásokat az üzeneteknek, és végzi a szűrést is.
A feliratkozók fordítási időben, inicializáció közben vagy futás időbe is feliratkozhatnak. GUI rendszerekben a feliratkozók reagálhatnak a felhasználók parancsaira, ami megfelel a fordítási időben való feliratkozásnak. Egyes keretrendszerekben XML fájlok tárolják a feliratkozások konfigurációját; itt a feliratkozást elvégzik inicializációs időben. A legkifinomultabb az, ha futás közben regisztrálnak, mint adatbázis triggerek, levelezőlisták és RSS.
A Data Distribution Service (DDS) más megközelítést használ. A résztvevők IP multicast alapján metaadatokat közölnek magukról. Ezeket az adatokat helyileg tárolják, és ezek alapján közvetítik üzeneteiket.
Története
[szerkesztés]Az egyik legkorábbi publikus pub/sub rendszer az Isis Toolkit news alrendszere volt, amit az 1987 Association for Computing Machinery (ACM) Symposium on Operating Systems Principles conference (SOSP '87) írt le az "Exploiting Virtual Synchrony in Distributed Systems. 123–138" cikkben.[1]
Előnyei
[szerkesztés]Lazább kapcsolat
[szerkesztés]A publikálóknak és a feliratkozóknak nem kell tudniuk egymásról. Mivel a témákra összpontosítanak, nem kell ismerniük a hálózat topológiáját sem. Mindegyik a többire való tekintet nélkül működhet. A hagyományosan szorosan kapcsolt kliens-szerver modellben a kliens nem küldhet üzenetet, amíg a szerver folyamata nem fut, és a szerver csak a kliens futásideje alatt kaphat üzeneteket. Sok rendszer lehetővé teszi, hogy a feliratkozók azokat az üzeneteket is megkapják, amiket akkor küldtek, amikor nem futottak.
Skálázhatóság
[szerkesztés]A publikáló-feliratkozó rendszer jobban skálázható, mint a hagyományos kliens-szerver. Ehhez igénybe vehet párhuzamos működést, cache-elést, routolást. Azonban szorosan csatolt, nagy méretű vállalati rendszerekben a több ezer szerver bevonása és közös adatközpont használata már megterhelő lehet a rendszer számára. A skálázhatóság növelése ilyen körülmények között kutatás tárgya.
Vállalati rendszereken kívül a pub/sub minta bizonyította skálázhatóságát több adatközpontra is, és teljes Internetre kiterjedő protokollok használják, mint az RSS és az Atom. Ezek jobb garanciát biztosítanak, mint egy webszerver akár több millió feliratkozó számára.
Hátrányai
[szerkesztés]A pub/sub minta hátrányai éppen legnagyobb előnyéből, a kapcsolatok lazításából adódnak. A rendszert gondosan meg kell tervezni, hogy erősebb, jobb legyen, mint amit az alkalmazás megkövetel. Például vissza kell igazolni az üzeneteket, hogy a rendszer biztosíthassa az üzenetek kézbesítését.
Elvesző üzenetek
[szerkesztés]A postás egy bizonyos ideig megpróbálja kézbesíteni az üzeneteket, akár megkapja minden címzettől a nyugtát, akár nem. Ha az idő lejárt, akkor nem próbálkozik többször. Ez a rendszer nem tudja garantálni, hogy az üzenetek célhoz érnek, ezért azt külső eszközökkel kell megoldani.
A feliratkozók hibáinak kezelése
[szerkesztés]Egy publikáló felteheti, hogy van, aki olvassa üzeneteit, de ez valójában nincs így. Egy gyár használhat ilyen rendszert, ahol a berendezés jelentést küldhet hibákról és problémákról egy naplózó rendszernek, ami meg is jeleníti az üzeneteket. Ha a naplózó rendszer valami miatt működésképtelenné válik, akkor ez nem történik meg, és a berendezés hibái észrevétlenek maradnak. Ez javítható azzal, hogy a naplózó rendszer több másolata működik, és ha valamelyik meghibásodik, akkor a többi pótolja. Ez nincs hatással a rendszer többi elemére, így inkrementálisan hozzáadhatók. Emiatt elegendő az alap funkciókat egyszer megvalósítani.
A fenti probléma nemcsak a publikáló-feliratkozó mintában fordulhat elő. Ha a kliens-szerverben adódik hiba a naplózó rendszerben, akkor minden szereplő azonnal értesül a hibáról. A hiba kezeléséhez azonban több naplózó rendszernek kell online lennie, ami bonyolultabbá teszi a teljes rendszert, és az elemeit is.
Stabilitás
[szerkesztés]Kis hálózat, kevés elem és kis üzenetek esetén a pub/sub minta jól skálázódik, az elemek számának növelése rontja a stabilitást, ami korlátozza a skálázhatóságot.
- A sávszélesség egyenetlen kihasználása: vannak időszakok, amikor telítve van, máskor pedig szinte üres.
- Lelassulás: ha sok üzenet megy, akkor a kézbesítés lelassul még akkor is, ha különböző csatornákon kommunikálnak.
- A LAN hálózatot a pub/sub üzenetek foglalják el, a többi résztvevő kommunikációja akadozik.
Biztonsági problémák
[szerkesztés]A postást használó rendszerekben a külső támadó becsaphatja a postást, így az rossz kliensnek küld értesítést, vagy megtagadhatja a szolgáltatást a kliensektől. Túlterheléses támadás is végezhető.
Bármely pub/sub rendszerben kaphatnak a kliensek olyan üzenetet, amihez nem lenne szabad hozzáférniük. Rosszindulatú publikálók küldhetnek inkorrekt vagy káros üzeneteket. Ezen titkosítással lehet javítani, de autorizált publikálók még mindig küldhetnek rosszindulatú üzeneteket. Ez különösen igaz azokra a rendszerekre, ahol a célcsoport nagy.
Jegyzetek
[szerkesztés]- ↑ Birman, K. and Joseph, T. "Exploiting virtual synchrony in distributed systems" in Proceedings of the eleventh ACM Symposium on Operating systems principles (SOSP '87), 1987. pp. 123–138.
Források
[szerkesztés]- Amazon SNS - Pub/Sub Service by AWS
- XMPP XEP-0060: Publish-Subscribe
- Message Broker MQTT With Publish-Subscribe Paradiam
- For an open source example which is in production on MSN.com and Microsoft.com, see Distributed Publish/Subscribe Event System
- Python PubSub a Python Publish-Subscribe broker for messages *within* an application (NOT network)
- The OMG DDS portal Archiválva 2007. október 24-i dátummal a Wayback Machine-ben
- libpubsub-cpp a topic based Publish/Subscribe framework implemented in C++
- Publish Subscribe example in C++
- Synapse is a C++ framework that implements a Publish-subscribe pattern
- Programmer Question-Answer topics tagged with "publish-subscribe"
Fordítás
[szerkesztés]Ez a szócikk részben vagy egészben a Publish–subscribe pattern című angol Wikipédia-szócikk fordításán alapul. Az eredeti cikk szerkesztőit annak laptörténete sorolja fel. Ez a jelzés csupán a megfogalmazás eredetét és a szerzői jogokat jelzi, nem szolgál a cikkben szereplő információk forrásmegjelöléseként.