Üzenetküldő programtervezési minta

A szoftver architektúrákban az üzenetküldő programtervezési minta (Messaging Design Pattern - MDP), leírja, hogy egy üzenetkezelő rendszer különböző részei hogyan kapcsolódnak egymáshoz és hogyan kommunikálnak egymással.

Az üzenetküldő tervezési minta lehetővé teszi információk („üzenetek”) cseréjét program-komponensek illetve alkalmazások között. A minta alkalmazása csökkenti a komponensek csatoltságát, növeli az egységbezárást, az újrahasznosíthatóságot és a skálázhatóságot azáltal, hogy szétválasztja a komponens kommunikációját a komponens funkcionalitásától. A komponensek, az üzenetek és az üzenetküldés mechanizmusa nem csatolt entitások, hanem teljesen függetlenek lehetnek.

A minta használatos konkurencia mintaként, többszálas futtatási környezetben a komponensek/programszálak közötti kommunikáció megvalósításához, illetve szerkezeti mintaként hálózat-orientált programrendszerekben a (jellemzően) külön számítógépen futó programok közötti információcseréhez.

Általános felépítés

1. ábra - Az üzenetküldő minta általános felépítése

Az üzenetküldő minta általános felépítésében szerepel egy feladó, egy címzett, egy kézbesítő és üzenetek:

• Feladó: A komponens, ami az üzenetet küldi.
• Címzett: A komponens, ami fogadja a hozzá beérkező üzenetet és annak feldolgozása után előállít(hat) egy válasz üzenetet. A beérkező üzenet általánosságban tetszőleges információt hordozhat.
• Kézbesítő: Közvetítő, ami eljuttatja az üzenetet a feladótól a címzetthez. A feladónak és a címzettnek nem kell azzal törődnie, hogyan kerül továbbításra az üzenet (kommunikációs protokoll, üzenetformátum, kódolás/biztonsági mechanizmusok stb.), sem azokkal az esetleges átalakításokkal amik az üzenettel a továbbítás során történnek. Ezek a kézbesítő feladatai és felelősségi köre. A való élethez hasonlóan gyakran előfordul az is, hogy nem szükséges kézbesítő, hanem a feladó közvetlenül a címzetthez juttatja el az üzenetet.
• Üzenet: bármilyen információdarab (adat), amit át kell adni a feladó és a címzett között. Jellemzően kétféle üzenet létezik a rendszerben: a küldött üzenet és a válasz üzenet. A válasz üzenet nem kötelező.

A feladó az üzenetet a kézbesítőnek adja át, aki gondoskodik arról, hogy az üzenet eljusson a címzetthez. A címzett a válaszüzenetét szintén a kézbesítőnek adja át, aki azt továbbítja a feladónak. Ahogy említettük, létezik a sémának olyan változata is, ahol nincs a modellben külön kézbesítő, hanem a feladó és a címzett közvetlenül kommunikál egymással.

Alapvető kommunikációs módok

Az üzenetek átvitelére többféle kommunikációs mód lehetséges, a legalapvetőbbek a szinkron, az aszinkron és a kétirányú üzenetküldés.

2. ábra - Szinkron üzenetküldő kézbesítővel

• Szinkron kommunikációs módnál az üzenetek „azonnal“ (közel valós időben) továbbításra kerülnek, az üzenetek köztes tárolásának beiktatása nélkül.

3. ábra - Aszinkron üzenetküldés sor (queue) használatával

• Aszinkron kommunikációs mód esetén az üzenetek átmeneti tárolásra kerülnek (a kézbesítő által), jellemzően egy sor adatszerkezetben (queue), ahonnan adott ütemezés szerint kéri le azokat a címzett.
• Kétirányú üzenetküldés esetén a „címzett“ felveheti a „feladó” szerepét is (kezdeményezhet üzenetküldést), a kommunikáció aztán ugyanúgy az általános séma szerint zajlik le, csak „fordított” szereposztással.

Használata, indokoltsága

Az objektumorientált programozással létrehozott alkalmazások, egy sor komponensből állnak össze, amelyeknek kommunikálniuk kell egymással. Ez tradicionálisan függvény/eljárás hívással valósul meg, akár lokálisan (egy gépen belül), akár hálózaton keresztül (több gép között távoli eljárás hívás/RPC). Az eljáráshívással működő megoldások helyett, az esetek legnagyobb részében használható az üzenetküldő tervezési minta megfelelő megvalósítása, amely általánosságban jelentős előnyöket hordoz magában (részletesen lásd: Tulajdonságai, előnyei).

Az üzenetküldő mintához kiválóan illeszkedik számos jól ismert egyéb programtervezési minta, illetve segíti ezek implementációját, sokkal természetesebb és kifejezőbb megvalósítást lehetővé téve. Az alábbi ábra az üzenetküldő minta egy megvalósítását mutatja a helyettes és az illesztő programtervezési mintával együtt.

4. ábra - Az üzenetküldő, a helyettes és az illesztő minta együttes használata

Az üzenetküldés paradigmájában, a helyettes elsősorban az üzenetek az „igazi címzettnek” történő továbbításáért felel. Például a helyettes végezheti egy hálózati szolgáltatás terhelés-elosztását a „mögöttes, igazi” szolgáltatók (pl. WEB szerverek) között.

Az illesztő fő feladata az üzenetküldés használatánál az üzenetek átalakítása a küldő és fogadó oldal között, hogy ezek a komponensek összekapcsolódhassanak. Például implementálhat egy HTTP illesztőt, amely biztosítja, hogy a helyi komponensek kommunikálni tudjanak távoli komponensekkel HTTP protokoll segítségével (ugyanez az elv vonatkozik a többi kommunikációs technológia és protokoll használatára is, pl.: Socket, Webszolgáltatás, REST, stb.).

Tulajdonságai, előnyei

• Egységbe zárás: Az üzenetküldő minta maximalizálja az egységbezárást, minden komponens önmagában zárt/független egység. A kommunikáció más komponensekkel és alkalmazásokkal csak az üzenetküldésen keresztül valósul meg.
• Csatoltság csökkentése: A minta minimalizálja a csatoltságot, minden komponens önállóan, a rendszer többi részétől függetlenül működhet. A komponensek kommunikációs mechanizmusa teljesen függetlenítve van a komponensek egyéb funkcionalitásától.
• Újrahasznosíthatóság: A minta használata növeli az újrahasznosíthatóságot, kicsit a „Lego“ építőkockákhoz hasonlóan. Nagyon komplex modellek készíthetőek egyszerű elemekből, amik csak a kapcsolódásuk módját osztják meg egymással (pl. egy közös interfésszel). Az üzenetküldő mintát használó komponensekből olyan módon építhető komplex alkalmazás, hogy az egyes alkotóelemek kicserélhetőek maradnak. A lehetséges összeépítési változatok száma végtelen, egy komponens használatához csak azokat a fogadott/küldött üzeneteket szükséges ismerni, amiket a komponens kezel. Az alkalmazások újrahasznosíthatnak komponenseket akár más alkalmazásokból is, ha azok az üzenetküldő mintát használják.
• Skálázhatóság: Egy tradicionális távoli eljárás hívásra (RPC) épülő rendszerben, fejlesztés esetén a klienseken és szerveren futó szoftverek egyidejű cseréje szükséges, ami folyamatos üzem esetén nehezen kivitelezhető. Az üzenetküldő minta alacsony csatoltsága miatt, fejlesztés esetén csak a kezelt üzenetféleségek száma változik, így egy „továbbfejlesztett” szerver beüzemelése után az képes kezelni a régi és az új kliensek üzeneteit is, ami a kliensek folyamatos cseréjét (ezáltal az üzemeltetés folytonosságát) teszi lehetővé. A rendszer komponensei akár elfedhetik azt is, hogy egy adott üzenet kezelésére több hasonló komponenst használ a rendszer (pl. proxy használatával, szerverek terhelés-elosztása).
• Minőségbiztosítás és tesztelés: Az üzenetküldő minta megkönnyíti a tesztelési és hibakeresési munkákat. A komponensek különálló egységekként kerülnek tesztelésre olyan módon, hogy üzeneteket küldünk az adott komponensnek és leellenőrizzük az (elvárt) válasz üzeneteket („feketedoboz”-tesztelés). Általában az egységtesztelés automatizált teszt-keretrendszerek segítségével történik, nem szükséges teszt célú kódokat írni a komponensbe magába, ami időigényes lehet, ráadásul önmagában is szoftver hibákat eredményezhet.
• Tervezési folyamat: A minta alkalmazása hatékonyabbá és egyszerűbbé teszi a tervezési folyamatot. A tervezési munka legnagyobb része az lesz, hogy a rendszer igényeinek megfelelő komponenseket definiáljunk, és megadjuk azokat a küldött/válasz üzeneteket amit az egyes komponenseknek kezelniük kell. Szoros összefüggés van az UML tervezési diagram elemei és az implementációhoz szükséges komponensek között. Egyes UML diagramok az üzenetküldő minta irányába mutathatnak (sorrendiség és együttműködés) jóllehet, az implementációjuk nem ezen alapul. Ha nem az üzenetküldő mintát használjuk, az UML modell és az implementáció szétválik. Mivel az összes komponens ugyanazt az üzenetkezelő interfészt használja, ezeket is könnyedén hozzáadhatjuk a BPM/BPEL diagramokhoz. Mint az újrahasznosíthatóság kapcsán már említettük, ez hasonló az építőkockákhoz, amik újrahasznosíthatóak és számos különböző módon összekapcsolhatóak.
• Fejlesztési folyamat: Mivel minden komponens ami az üzenetküldésen alapul független és önmagában zárt, akár egy nagyobb csapat is együttműködhet a fejlesztésben anélkül, hogy egymás kódjába/munkájába kellene „nyúlniuk”. Ideális esetben, egy adott komponenssel/csomaggal kapcsolatos felelősség egy emberre tartozhat. A csapat többi tagjának csak azokat küldött/fogadott üzeneteket kell ismernie amiket mások komponensei kezelni fognak. Általában emiatt nem kell mások kódját megváltoztatni. A kód különféle változatainak létrehozása, karbantartása illetve összefésülése szintén minimálisra csökken vagy akár el is maradhat. A tesztelésért és minőség-ellenőrzésért felelős mérnökök függetlenül végezhetik el a tesztelést automatizált teszt-keretrendszerek segítségével. Általános szabályként nem szükséges teszt célú kódokat hozzáadni magához a komponenshez.
• Naplózás és hibakeresés: Mivel az összes komponens ugyanazt az üzenetkezelő interfészt használja, az üzenetek (a rendszer „történései”) könnyen és automatikusan naplózhatóak. Ez minimalizálja a kiíró/naplózó utasítások szükségességét a kódban, amelyek végrehajtása „időrabló” és hibalehetőségeket is jelentenek. Egy naplózott üzenetváltást megvizsgálva, általában gyorsan végigkövethető és megtalálható az az üzenet/komponens amely a problémát okozza (csekély plusz erőkifejtéssel).
• Biztonság: A jól ismert titkosító és autentikációs mechanizmusok kiválóan alkalmazhatóak az üzenetküldő mintával együtt. Erős biztonságot lehet megvalósítani a mintát implementáló rendszerekben, az üzenetcsere titkosításával és a résztvevők autentikációjával. A feladónak és a címzettnek nem kell különösebben foglalkoznia azzal, hogy hogyan van a biztonságos üzenetküldés implementálva. Ez lehetőséget teremt erős biztonság megvalósítására, a biztonságot adó megoldások implementációjának egyszerűen tartása mellett. Ha szükséges, egyedi biztonsági mechanizmusok is megvalósíthatóak: ebben az esetben a feladónak és a címzettnek „meg kell egyeznie” a használt titkosítási/autentikációs mechanizmusokban illetve implementálniuk is kell azokat.
• Többszálúság és aszinkron üzenetkezelés: Az üzenetküldő minta képes kezelni a többszálúságból és aszinkron üzenetkezelésből fakadó komplexitást. Az üzenetküldő mintát használó komponensek futhatnak külön/független végrehajtási szálon. Ez a valós világ természetes reprezentációja: minden komponens (entitás) egy önmagában zárt/független egység és a kódvégrehajtása független a rendszer többi részétől. Az üzenetek aszinkron módon dolgozhatóak fel, a komponens saját független végrehajtási szálát használva. Azokat az entitásokat amik ezt a viselkedési mintát követik, „élő” vagy „eleven” jelzővel is szokás illetni. Ez a képesség általában egy komponens keretrendszer segítségével kerül implementálásra, így a komponensnek nem kell külön megírt logikát tartalmaznia a többszálúság kezeléséhez, amely időigényes és komplex lehetne, azonkívül hibalehetőséget is jelentene.
• Fejlesztési idő és költség: A fentiekben ismertetett előnyök miatt, az üzenetküldő minta használata képes jelentősen növelni a fejlesztés sebességét, illetve csökkenteni a költségeket.
• Minőség és szoftverkarbantartás: A minőségbiztosítási és szoftver karbantartási tevékenységek szintén hatékonyabbak a fentebb leírtak következtében.
• Az üzenetküldés paradigmája és a tanulási folyamat: Hogy az érintetteknek elérhessék ennek a tervezési mintának minden előnyét, az üzenetküldés paradigmájának fogalmai szerint kell gondolkodniuk a szoftver-alkalmazások modellezése, tervezése és felépítése során: független entitásokban (komponensek) amik üzeneteket váltanak egymással. Ez tanulásra szánt időt és gyakorlást kívánhat meg. Jóllehet az üzenetküldő megközelítés természetes, intuitív és összeegyeztethető a valós világgal, a hagyományos megközelítés a függvény/eljárás híváson (akár helyi akár távoli) alapul. Ne feledjük, hogy az üzenetküldésnek, mint koncepciónak számos tulajdonsága, jellemzője van, az üzenetküldő minta pedig örökli vagy „elnyeli” ezeket. Emiatt kihívást jelenthet megtalálni az üzenetküldő koncepció illetve a minta hátrányait. Ez nem szokványos helyzet a programtervezési minták kontextusában. Hasonló helyzet áll elő akkor, ha valamilyen más, valós életből vett koncepciót vizsgálunk, amely a szoftver modellünk része lehet, mint például a „gravitáció” vagy az „erő”.
• Fegyelmezett hozzáállás: Az üzenetküldő minta ösztönzi azt a fegyelmezett hozzáállást, hogy az üzenetküldés legyen az egyetlen kommunikációs csatorna a komponensek között. Bár a külső osztályok függvényei/eljárásai a tradicionális módokon hívhatóak meg, ezeket nagyon csekély mértékben ajánlott használni, a csatoltság minimalizálása és az egységbezárás maximalizálása miatt. Az „ideális” komponens egy önmagában zárt egység, amely kizárólag üzenetek segítségével lép interakcióba más komponensekkel. A minta használatával elérhető előnyök jóval többet jelenthetnek, mint a minta használatához szükséges plusz fejlesztési idő. Ráadásul az üzenetküldő minta alapján megvalósított komponensek szükség esetén beszerezhetőek vagy kinyerhetőek más alkalmazásokból is.

Hátrányai

• Többlet terhelés: Az üzenetek továbbítása a komponensek között, némi többlet terhelést okoz a tradicionális függvény/eljárás híváshoz képest. Ez különösen akkor igaz, ha kézbesítő komponens is van a minta implementációjában. Amiatt, hogy a számítógépek egyre gyorsabbak és gyorsabbak, ennek a hátránynak egyre kisebb a jelentősége. A legtöbb esetben az üzenetküldő minta használatának előnyei jóval nagyobb nyereséggel járnak, mint a teljesítménycsökkenésért fizetett ár.

SOAP protokollok

A SOAP a Simple Object Access Protocol rövidítése. A definiált protokollok a következők:

• In-Only: csak bemenő. A fogyasztó üzenetet küld a szolgáltatónak, ami állapottal válaszol.
• Robust In-Only: robusztus csak bemenő. A fogyasztó üzenetet küld a szolgáltatónak, ami állapottal válaszol, vagy hibajelzést küld. Ez esetben a fogyasztó állapotot küld vissza.
• In-Out: kérés-válasz. A fogyasztó küld egy üzenetet, majd a szolgáltató küld egy üzenetet, vagy egy hibajelzést, végül a fogyasztó állapottal választ.
• In-Optional-Out: kérés-opcionális válasz; úgy, mint előbb, de a szolgáltató válasza opcionális.
• Out-Only: csak kimenő, nem válthat ki hibajelzést. Értesítésekre használják (notification).
• Robust Out-Only: mint az előző, de kiválthat hibaüzenetet.
• Out-In: kérés-válasz, az In-Out fordítottja. A szolgáltató küldi az üzenetet, és kezdeményezi a válaszadást.
• Out-Optional-In: az In-Optional-Out fordítottja. A szolgáltató küld üzenetet, a válasz opcionális.

ØMQ socketek

A ØMQ egy üzenetküldési könyvtár, aminek socketjei a hagyományos IP és UNIX socketek általánosításai. Ezek használatára üzenetküldési mintát kell választani, és minden mintára optimalizálva vannak. A legalapvetőbb minták:

• Kérés-válasz: szolgáltatók és kliensek összekapcsolása; távoli eljáráshívási és feladatelosztási minta.
• Publish–subscribe: publikálók és olvasók összekapcsolása; adatelosztási minta.
• Push–pull: legyezőszerűen kapcsol össze csúcsokat. A minta megenged köröket és szintek is közbeiktathatók. Párhuzamos feladatelosztási és eredmény-összegyűjtési minta.
• Kizáró párok: két socket összekapcsolása kizáró párrá. Alacsony szintű minta, speciális, fejlett használatra.

Minden minta más hálózattopológiát határoz meg. A kérés-válaszhoz szolgáltatásbusz, a publish-subscribe mintához adatelosztási fa, a push-pull mintához párhuzamosított csővezeték. Ezeket a mintákat úgy tervezték, hogy jól skálázódjanak, akár internet méretben is.

Kapcsolódó szócikkek

• Programtervezési minta

Források

• A. GALVIS, Messaging Design Pattern and Pattern Implementation
• Hohpe, Gregor. Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Addison-Wesley (2003. március 27.). ISBN 0-321-20068-3 

Fordítás

Ez a szócikk részben vagy egészben a Messaging 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.