LIPSZ
Főoldal Vélemények Képes arra az AMQP, hogy megtörje az IBM MOM monopóliumát? (2. rész)
2019 | 08 | 24
LIPSZ Menü
Események, rendezvények
Tudásbázis
Képes arra az AMQP, hogy megtörje az IBM MOM monopóliumát? (2. rész) PDF Print E-mail
2008. Szeptember 04, Csütörtök - 09:29
Folytatjuk az üzenetküldési szabványokról, illetve az AMQP-ről szóló írásunkat. Az előző részben a bemutattuk a protokollt, ebben a részben pedig interjút közlünk Carl Trieloffal a Red Hat MRG kezdeményezése és az Apache Qpid projekt kulcsemberével.

Jelenleg hol tart az AMQP specifikáció?

A specifikáció már közel van az 1.0-ás verzióhoz, és azt tervezzük, hogy ez év végére eljut erre a szintre. Nagyon sok munkába telt, hogy eljussunk a 0.9-től a 0.10-ig, mivel nagyobb megbízhatóságot kellett biztosítanunk annak érdekében, hogy az összes JMS szemantikát kezelni tudja. A rétegek sorrendjét is optimalizáltuk, például azáltal, hogy különválasztottuk a hardverhez és a szoftverhez kapcsolódó rétegeket. A protokollt arra terveztük, hogy könnyebbé tegye bizonyos alacsony szintű funkcionalitás hálózati hardveren való kezelését. A Cisco a munkacsoport tagja, és fontos szerepet játszik benne.

 

A Red Hat AMQP verziója az Apache Qpid projektjére épül. A Red Hat mellett ki járul még hozzá a Qpid projekthez?

Az Apache hozzájárulók köre általában név nélküli. Jelenleg a Qpid projektnek 19 résztvevője van, továbbá 6 személy jelentős mértékben hozzájárul, de ők most kevésbé aktívak. Emellett 5 további személy segít a projekt futtatásában, illetve 8 további személy hoz létre kódot, akik végül a projekt tagjaivá válhatnak. A Red Hat az egyik legnagyobb hajtóerő a Qpid mögött, de semmi esetre sem alkotja a többséget.

 

Mi a kapcsolat az AMQP és a JMS között?

A munkánkat az üzleti felhasználók követelményei irányítják. A JMS API-ként széles körben használt egyéb MOM-ok esetén, mint például az IBM és a Tibco, így nyilvánvaló, hogy az AMQP a JMS-sel jó együttműködést kell biztosítson. A specifikáció korábbi verziói nem voltak elég gazdagok ahhoz, hogy a JMS szemantikát futtassák, így ezen még dolgoznunk kellett. Fontos megjegyezni, hogy a JMS csak egy API. A JMS összes implementációja tulajdonosi. Az API lehetővé teszi, hogy az adott implementáció részleteitől elvonatkoztassunk. Az IBM MQ és a Tibco Rendezvous is elérhető JMS-en keresztül, de nem várhatjuk el, hogy együttműködjenek. Az AMQP esetén azonban más a helyzet. A Qpid implementáció jól együttműködik a RabbitMQ és az iMatix implementációkkal. Azt is meg kell jegyezni, hogy a JMS használata az AMQP számára egy lehetőség csupán, nem pedig követelmény. Ha nem Java objektumok szerializálásáról van szó, a JMS-t használhatjuk az egyik végen, egy másik API-t pedig a másik végen. A Qpid fejlesztett API-kat az AMQP kliensünk összes nem Java verziójához, beleértve a C++-t, a C#-ot, a Pythont és Ruby-t. Voltak olyanok is, akik CICS interfészt kértek; ennek az elkészítését is fontolgatjuk.

 

Mi a Red Hat stratégiája a kereskedelmi AMQP termék piacra hozatalával kapcsolatban?

A Red Hat Messaging az Apache Qpid disztribúciója. A Qpid az a Red Hat Messaging számára, mint a kernel.org a Red Hat Enterprise Linuxnak, vagyis ez ugyanis az upstream tárház. A Red Hat ehhez további komponenseket ad hozzá, mint például különböző menedzsment jellemzők. Más vállalatok is megjelentették a saját Qpid disztribúcióikat (pl. Iona). A Red Hat Messaging a Red Hat MRG-ben is megjelenik. A Red Hat MRG Red Hat üzenetküldési, valósidejű és grid komponensek készlete, melyek mindegyike saját közösségi tárházzal rendelkezik, melyeket a Red Hat egy köztesréteg termékké integrál, ami a Red Hat Enterprise Linuxon fut.

 

Kik számára fejlesztették ki a Red Hat MRG-t?

Nem feltétlenül érdeklődik minden ügyfél mindhárom komponens iránt. Például vannak olyan ügyfelek, akik olyan beágyazott alkalmazásokat futtatnak, melyek csak a valósidejű működést igénylik. Ez a Red Hat Enterprise Linux egy valósidejű rendszermagja, ami garantálja a szolgáltatások válaszidejét, tehát nagyon determinisztikus. Vannak olyan ügyfelek, akiknek mind a valósidejűségre, mind az üzenetküldésre azaz az AMQP-re is szükségük van. Például ide tartoznak a kereskedelmi alkalmazások a pénzügyi szektorban, és bizonyos telekommunikációs alkalmazások. A grid komponens, ami a Universtiy of Wisconsin Condor projektjéből származik, nagyon népszerű a HPC és a méretezhető architektúrák körében. Például, egy felhasználó helyileg futtathat egy táblázatkezelőt, majd pedig végrehajthat egy szimulációt távol, a felhőn elhelyezkedő griden. Így az alkalmazástól függ, hogy a felhasználót az összes, vagy csak egyetlen MRG komponens érdekli. Az MRG azonban menedzsmentperspektívából egyesíti a különböző komponenseket.

 

Az AMQP komoly fenyegetést jelent majd az IBM vagy a Tibco számára?

Valószínűleg az AMQP miatt nem fogják „kidobni” az MQ-t, mivel a meglévő projektek áttervezési költségei túl magasak, hacsak további tényezőkről nem beszélhetünk. Azonban szerintünk az AMQP-t olyan új bevezetések során alkalmazzák majd, melyek jobb teljes tulajdonosi költséget, vagy más értékláncot ajánlanak, illetve ahol az ügyfelek a nyílt forráskód előnyeit akarják majd élvezni. Lehetnek olyan esetek is, ahol az MQ-t üzleti okokból frissítik AMQP-ra, például talán, ha a felhasználó vállalatot felvásárolják vagy összevonják másokkal. Az üzenetküldés terén az IBM-mel fogunk majd versenyezni, de háborút biztos, hogy nem indítunk ellenük. A valósidejű Java terén még együtt is működünk.

 

Az AMQP hogyan működik majd együtt ESB-kkel és a SOA-val?

Az ESB (vállalati szolgáltatási busz) szerepe az, hogy az üzenetküldési formátumokat és protokollokat egymás között fordítsa, valamint az üzeneteken műveleteket végezzen, és ne csupán szállítsa őket egyik helyről a másikra. Az ESB alapvetően egy olyan komponens, melyben különböző szolgáltatásokat lehet elindítani, amik az üzeneteinken dolgoznak. A JBoss ESB, ami a Red Hat SOA (szolgáltatás-orientált architektúra) platformja, a közvetítő komponensekre összpontosít, és azt a képességet nyújtja, hogy különböző szállítókhoz kapcsolódni tudjunk. Ugyanakkor szükséges egy alap-üzenetküldési infrastruktúra is az üzenetszállítás során, és ez az, amit az AMQP nyújt az ESB-n túlmenően. A Red Hat ESB megoldása jelenleg olyan JMS szállítást nyújtó szolgáltatásokat támogat, mint például az IBM MQ, és még ebben az évben az Apache Qpidot is támogatja majd.

 

Mi a kapcsolat az AMQP és a Web Services ReliableMessaging (WS-RM) között?

A WS-RM azért került a képbe, mert nyilvánvaló, hogy a HTTP önmagában nem elegendő szállítási protokollként. Így a WS-RM célja, hogy a HTTP mellett további, nagyobb megbízhatóságot nyújtson. Ez egy olyan webszolgáltatási forgatókönyv esetén érvényes, melyben XML üzeneteket SOAP csomagolásban küldünk. Néhányan, akik nem szeretik a HTTP-t, azt mondják, hogy küldjünk helyette SOAP-ot, JMS-en keresztül. Természetesen ugyanezt az AMQP-vel is meg lehet csinálni, mivel jól működik majd SOAP és XML szállítóként. Az AMQP egy teljes alapszintű protokollt meghatároz, és így kiküszöbölhető a HTTP. Az AMQP célja azonban túlmutat a WS-RM-en. Arra tervezzük, hogy bármilyen alkalmazások közötti üzenetküldési tartalom esetén működjön, különösen bináris formátumoknál, és nem csak az XML-nél. Valószínűleg nincs értelme WS-RM-et AMQP-n futtatni, de lehetséges, hogy valaki készít majd egy RM és AMQP közötti hidat. Szerintem a WS-RM kezdetben ígéretes volt, de az elmúlt években vesztett a lendületéből.

 

Mi garantálja azt, hogy a különböző AMQP implementációk együttműködjenek?

Még nincs hivatalos mechanizmus, de az AMQP munkacsoport sokat dolgozik az interoperabilitáson. Igaz, hogy akármilyen időpontban nézzük, a különböző AMQP implementációk a specifikáció különböző megvalósítási, és így interoperabilitási szintjén lesznek. A tapasztalatunk azonban az, hogy az implementációk közötti együttműködés egyre jobb, mivel a specifikációk minősége jobb és kevésbé kétértelműek, és azért is, mert a fejlesztők keményen dolgoznak rajta. Szerintem fontos, hogy az interoperabilitás egy nagyon pragmatikus megközelítését alkalmazzunk. Ha a Sunt vesszük például, ők hatalmas összegeket költenek arra, hogy TCK-kat (Technology Compatibility Kit – technológia kompatibilitási készlet) írjanak a Java specifikációkhoz, de ez nem mindig garantálja az interoperabilitást.

Ez az írás az alábbi cikk alapján készült: http://www.interopnews.com/analysis/can-amqp-break-ibms-mom-monopoly-part-2.html