Üzenetorientált köztesréteg
Üzenet-orientált köztesréteg (angolul Message-oriented middleware (MOM)) egy szoftver vagy hardver architektúra, mely az elosztott rendszerek közti üzenetek küldésében és fogadásában segédkezik. A MOM segítségével az alkalmazás egyes moduljai elhelyezhetők heterogén platformokon, így csökkentve a többféle operációs rendszerre és hálózati protokollra átnyúló szoftverek fejlesztésének komplexitását. A köztes réteg egy elosztott kommunikációs réteget valósít meg, amely elrejti a fejlesztő elől a különböző operációs rendszerekhez és hálózati interfészekhez tartozó sajátosságokat. Az olyan APIk, amelyek átnyúlnak különböző platformokra általában MOM-ot[1] használnak.
A MOM olyan komponenseket kínál, amely minden, a kliens-szerver kommunikációban részt vevő elemben elhelyezésre kerül, és általában az aszinkron hívásokat támogatja a kliens és a szerver között. A MOM csökkenti a szoftverfejlesztők munkáját a kliens-szerver mechanizmusban lévő mester-szolga kapcsolat megvalósításánál.
Eredet[szerkesztés]
Motiváció[szerkesztés]
A bankok a hatvanas évek óta az ügyfeleik adatait a központi számítógépükben tárolták. Ezek a gépek továbbra is nagy terhelés alatt állnak. Ezeken eszközöltek néhány újítást. Habár az úttörő volt, hogy a bankok olyan PC alapú alkalmazásokat mutattak be, melyek olyan szolgáltatásokat nyújtottak az ügyfeleknek, amilyenek eddig a központi számítógéppel nem voltak megvalósíthatók. Ezek valamelyest csökkentették a központi gépek hasznosságát. Ideális esetben ezek a PC-s alkalmazások összeköttetésben vannak a központi géppel, és megosztják egymással az adataikat. A központi számítógép adataihoz való hozzáférés két fő előnnyel jár:
- Az új PC-s alkalmazások helyettesítik a nem felhasználóbarát központi terminálokat.
- új módon tudják hasznosítani ezek a PC-s alkalmazások a központi gép adatait – ezek eddig megszorításokba ütköztek a központi gép szoftvere miatt
Az 1980-as évek végéig a rendszer integrátoroknak nehéz dolga volt ezeknek az alkalmazásoknak az összekapcsolásánál. A fejlesztők a következő problémák találták magukat szembe:
- minden egyes rendszerhez külön szoftveradaptereket kellett létrehozni, amelyek értelmezik az adatokat a cél rendszer számára (és vissza is)
- a feldolgozási sebesség az egyes rendszerekben különböző lehet. Például, ha a központi számítógép lassabb mint a PC, akkor annak be kell várni a központi gépet így lassítva a PC-s alkalmazást. Ezzel szemben ha a folyamatok, amelyek ki lettek helyezve külső szerverekre erőforrás megtakarítási okokból, futnak lassan, akkor a központi gépnek kell ezek befejezését megvárnia.
- az integrátoroknak egy hálózati hidat kell a központi számítógép hálózata és a PC hálózat közé telepíteni ha a két rendszer különböző protokollt használ. Ez az átjáró átalakítja a csomagokat a forrás hálózat protokolljáról a cél hálózatéra és továbbítja azokat a cél hálózatba.
Ezek a problémák nehézzé tették az integrációt. Mivel minden szituáció különbözik valamelyest ezért ekkora integráció szükséges minden alkalommal amikor két alkalmazást különböző platformokon össze akarunk kötni. Mivel ilyen nagy egy-egy rendszer integrációjának költsége ezért az IT részlegek többet foglalkoztak ezzel, mint magával az alrendszer kifejlesztésével. A fejlesztőknek olyan szoftverre volt szükségük, ami az alkalmazások között helyezkedik el, és kezeli az egyes rendszerek közti kommunikációt. Ennek a szoftvernek elég intelligensnek kellett lennie, hogy lekezelje a különböző platformok, programozási nyelvek, hálózati protokollok és hardverek közti különbségeket. El akarták rejteni ezeket a konverziókat, hogy csak az éppen fejlesztett alkalmazás funkcióival keljen foglalkozniuk. Az 1980-as évek végére olyan köztesrétegek kezdtek kialakulni, melyek ezzel a problémával foglalkoztak. A kezdeti köztes rétegek csak bizonyos platformokat, vagy programozási nyelveket támogattak, ezért kevésbé voltak hasznosak. Az idő előrehaladtával azonban egyre fejlettebbek lettek, és több platformot, nyelvet illetve protokollt kezdtek támogatni. A köztes rétegek azon képessége, hogy heterogén hálózatokban lévő különböző rendszereket képes összekapcsolni csak egy példa ennek a technológiának a hasznosságára. A napjainkban használatos köztes rétegek sok olyan új funkciót tartalmaznak, amelyekkel kibővítik az alkalmazást mellyel együttműködnek.
Előnyök[szerkesztés]
A fő ok az üzenet-orientált kommunikációs protokoll mellett, hogy képes raktározni (buffer), útválasztást alkalmazni vagy épp átalakítani az üzenetet amíg eljuttatja a küldőtől a fogadóig.
Szinkronizáció[szerkesztés]
A MOM tartalmaz egy alkalmazások közötti kommunikációs szoftvert, amely az aszinkron üzenettovábbításon alapul, nem pedig kérés-válasz kommunikáción. Az aszinkron rendszerben lévő üzenetsorok ideiglenes tárolóként működnek addig amíg a cél program elfoglalt vagy nincs csatlakozva. A legtöbb aszinkron MOM rendszer biztosít perzisztens tárat, amelyből visszaállíthatók ezek az üzenetsorok. Ez azt jelenti, hogy a küldőnek és a fogadónak nem szükséges egyszerre kapcsolódnia a hálózatra ezzel megoldva az időszakos kapcsolódással járó problémákat. Ebből az is következik, hogy a fogadó program esetleges hibája esetén a küldő tovább folytathatja a munkáját. A küldendő üzenetek felhalmozódnak az üzenetsorban esetleges későbbi feldolgozásra amikor a fogadó újraindul.
Útválasztás[szerkesztés]
Sok üzenet-orientált köztes réteg az üzenetsoroktól függ. Néhány implementáció az üzenet rétegre bízza az útvonalválasztás, míg mások a kliens alkalmazásra. Vannak azonban olyanok is, amelyek mindkét megközelítést használják. Vannak olyan megvalósítások amelyek a broadcast vagy multicast címzést használják.
Átalakítás[szerkesztés]
Az üzenet-orientált köztes rétegben a fogadó által kapott üzenetnek nem feltétlen kell megegyeznie a küldő által küldöttel. A MOM-ba épített intelligencia képes átalakítani az üzeneteket mind a küldő mind a fogadó igényeinek megfelelően.[2] Következésképpen az útválasztással és a broadcast/multicast funkciók segítségével egy alkalmazás képes kiküldeni egy üzenetet a saját natív formátumában és kettő vagy több alkalmazás pedig fogadja azt az általuk használt natív formátumban. Számos modern MOM rendszer kifinomult üzenettranszformáló eszközt tartalmaz amelyek segítségével a programozó képes megadni átalakítási szabályokat egyszerű fogd és vidd műveletekkel.
Hátrányok[szerkesztés]
A legfőbb hátránya az üzenet-orientált köztes rétegnek, hogy egy plusz komponensre van szüksége az architektúrába, az üzenettovábbító komponensre. Ahogy minden rendszernél, további komponens hozzáadása teljesítmény és megbízhatóságbeli csökkenést jelenthet, valamint bonyolultabb és drágább lehet a karbantartása. Ráadásul, számos alkalmazások közötti kommunikáció lényegében szinkron kommunikáció, melynél a küldő meg akarja várni a választ mielőtt folytatná a működést. Mivel az üzenet-orientált kommunikáció eredendően aszinkron ezért nem fog illeszkedni ilyen helyzetekben. Ennek köszönhetően a legtöbb MOM rendszerben vannak arra lehetőségek, hogy csoportosítsuk a kérést illetve választ egy pszeudoszinkron tranzakcióba.
A szabványok hiánya[szerkesztés]
A szabványok hiánya problémákhoz vezet az üzenet-orientált köztes réteg használatakor. Az összes nagyobb terjesztőnek megvan a saját implementációja, APIja illetve menedzsment eszközei. Van azonban remény, hogy végül szabvánnyá válik az aktívan fejlődő OpenMAMA. A Java EE tartalmazza JMS (Java Message Service) APIt, amely a legtöbb MOM terjesztő által implementálva van és megpróbálja elrejteni a részletes MOM API megvalósításokat, bár a JMS nem definiálja a formátumát az üzeneteknek, ennélfogva a JMS rendszerek nem átjárhatók. A Microsoft MSMQ-ja nem támogatja a JMS-t de vannak más által fejlesztett termékek hozzá amelyek kiegészítik ezzel a funkcióval. Az IBM WebSphere Message Brokere támogatja a JMS-t és még sok már modern funkciót is tartalmaz.
Advanced Message Queuing Protocol (AMQP) egy olyan szabvány amely meghatározza az üzenetküldő szerver és kliens formátumait és protokollját is, így ennek az implementációi átjárhatók. AMPQ rugalmas útválasztást biztosít, tartalmazza a népszerű üzenettovábbító paradigmákat mint a P2P, fanout, publish/subscribe és a kérés-válasz. Támogatja még a tranzakciókezelést, üzenetsor használatát, elosztottságot, biztonságkezelést, klaszterezést, összevonást és a heterogén platformok támogatását. Java alkalmazások melyek az AMQP-t használják általában Java JMS-t használva íródnak. Más implementációk biztosítanak API-kat C#, C++, PHP, Python, Ruby és más programozási nyelveknek.
Trendek[szerkesztés]
Az AMPQ-t egyre több alkalmazásba adoptálják, ahol átjárható protokollra van szükség üzenet-orientált köztes réteghez. Egyéb protokollok amelyek üzenet-orientált köztes réteghez vannak használva: XMPP és Streaming Text Oriented Messaging Protocol. Fejlesztés alatt lévő MOM protokollok:
- RestMS viselkedésében hasonló az AMQP-hez de RESTful HTTP transzport fölé készült
- SPB egy minimális üzenet keretező protokoll amely magas szintű MOM protokollok szállítására használható
Egy további trend, hogy hardverbe ültetik bele az üzenet-orientált köztes réteg funkcióit – többnyire FPGA vagy egyéb speciális chippekbe.[3]
Jegyzetek[szerkesztés]
- ↑ Curry, Edward. 2004. "Message-Oriented Middleware"[halott link]. In Middleware for Communications, ed. Qusay H Mahmoud, 1-28. Chichester, England: John Wiley and Sons. doi:10.1002/0470862084.ch1. ISBN 978-0-470-86206-3
- ↑ E. Curry, D. Chambers, and G. Lyons, “Extending Message-Oriented Middleware using Interception” Archiválva 2011. július 26-i dátummal a Wayback Machine-ben, presented at Third International Workshop on Distributed Event-Based Systems (DEBS '04), ICSE '04, Edinburgh, Scotland, UK, 2004.
- ↑ Are You Soft in the Middle? The future of enterprise IT rests in hardware applications. [2009. február 9-i dátummal az eredetiből archiválva]. (Hozzáférés: 2012. május 3.)
Fordítás[szerkesztés]
Ez a szócikk részben vagy egészben a Message-oriented middleware című angol Wikipédia-szócikk ezen változatának 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.
