LIPSZ
Főoldal Vélemények Képes arra az AMQP, hogy megtörje az IBM MOM monopóliumát?
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? PDF Print E-mail
2008. Augusztus 21, Csütörtök - 09:28
Az alábbi cikkben Jeff Gould az AMQP-ről (Advanced Message Queuing Protocol) a nagyon gyorsan fejlődő, nyílt forráskódú üzleti üzenetküldési szabványról ír.

Az első e-mail fiókomat 1991-ben hoztam létre. Valószínűleg sokak számára ez egy ősrégi történetként hangzik, de ekkor valójában az internet korának egy meglehetősen késői szakaszában jártunk már. Ebben az időben már sok barátom és ismerősöm használt e-mailt, és sokat viccelődtek azon a furcsa szokásomon, hogy faxon kommunikálok velük. Így megadtam magam, és létrehoztam egy CompuServe fiókot.

Ez a CompuServe e-mail meglehetősen kezdetleges volt. Biztosan sokan emlékeznek még azokra a furcsa címekre, melyek számok_hosszú_sorozatából_á This e-mail address is being protected from spambots. You need JavaScript enabled to view it előtt, és az esetlen „kövér kliens” Windows programra, amit használtak. Ezzel az e-maillel még csatolmányokat sem tudtam küldeni, habár azt is figyelembe kell venni, hogy a modemem akkoriban 2400 bit/másodperces sebességet nyújtott (akkoriban ezt Baudnak nevezték). Szóval nagyon büszke voltam az új e-mail címemre. Végül is, mindenkit, legalábbis majdnem mindenkit elérhettem a világban, akinek volt e-mail címe.

Ekkoriban még nem minden e-mail rendszer volt kompatibilis az Internetes szabvánnyal. Számos nagyvállalat belsőleg tulajdonosi e-mail rendszert használt, melyek nem tudtak a külső világgal kommunikálni. Akkoriban egy kis piackutató vállalatot vezettem Párizsban, mely az IT felhasználók körében végzett felmérésekre specializálódott. A legnagyobb ügyfeleim az IBM, a Hewlett Packard és a francia telefonszolgáltató (Francia Telekom) voltak. Mindegyikük rendelkezett saját e-mail rendszerrel, de egyiküknek sem tudtam küldeni e-mailt a CompuServe fiókomról. Tehát, amikor egy új felmérésről írtam jelentést, akkor az iszonyúan drága Apple lézernyomtatómmal kellett azt kinyomtatnom, majd pedig futárt kellett fogadnom, hogy a jelentést elvigye az ügyfelek hivatalába a forgalmas Párizson keresztül. Ez alól csak az jelentett kivételt, amikor a Hewlett Packardnak írtam a jelentéseket. A vállalat hivatalai Grenoble-ben voltak, Párizstól több száz kilométerre délre, így nem tudtam futárokat alkalmazni. Azonban a Hewlett Packardnak természetesen voltak faxgépei, és épp ekkor vettem egy nagyon modern készüléket, amit fax modemnek nevezünk, így el tudtam faxolni a dokumentumot az összes formázással együtt, egyenesen a Microsoft Wordből, így egy kicsit spórolhattam azokon a drága lézernyomtatókon. Ezzel a hetedik mennyországba jutottam, de még mindig nem tudtam egy egyszerű e-mailt küldeni az ügyfeleimnek.

Természetesen a fejlődés megállíthatatlan szele elsöpörte az e-mail kapcsolatok előtt álló összes akadályt. Egy-két évvel azután, hogy megvettem a faxmodemem, egy nagy amerikai kiadóhoz kerültem, és 1994-re olyan e-mail címem volt, ami a nevemet is tartalmazta, nem pedig számok sorozatát. Aztán hamarosan felfedeztem, hogy a HP és az IBM is eldöntötte, hogy ledönti a tulajdonosi e-mail rendszereiket körülvevő falakat. Hirtelen azok, akikkel az IBM-től leveleztem, már tudtak nekem e-mail küldeni a Profs rendszerükről (habár minden nyomtatott betűkkel volt írva). Még a HP is megjelentetett egy terméket OpenMail néven, ami azért volt híres, mert valóban megértette a szabványos e-mail protokollokat. Abban az időben ez egy fergeteges innováció volt.

Könnyű visszanézni, és az e-mail akkori kezdetleges állapotán nevetni. Ma már nincs olyan IT felhasználó, akinek egyáltalán az eszébe jutna, hogy olyan üzenetküldési szoftvereket vásároljon, melyek nem működnek együtt az alapvető Internet szabványok használata során. És egy önmagára valamit is adó IT gyártó sem merne ilyen terméket értékesíteni.

Valójában ez nem tejesen így van. Míg a hagyományos e-mailek már rég szabványokon alapulnak, addig az e-mail csúcstechnológiájú megfelelője, amit üzenet-orientált köztesrétegként, vagyis MOM-ként ismerünk, még mindig tulajdonosi elszigeteltségben teng-leng. A küldetéskritikus vállalati alkalmazások a MOM-ot használják az egymásnak való üzenetküldés során, rendszerint ugyanolyan aszinkron stílusban, mint az e-mail (például válaszra várakozás nélkül, a sokkal kezdetlegesebb RPM mechanizmusokkal szemben). Ezek az alkalmazások közötti üzenetek sokkal nagyobb üzleti értékkel bírnak, mint a tipikus személyek közötti hivatali levelek, és ezért különleges bánásmódot igényelnek. Ezért az olyan MOM termékek, mint például az IBM WebSphere MQ (korábban MQSeries néven volt ismert) és a Tibco Rendezvous minden olyan jellemzőt magukban foglalnak, mellyel garantálhatják, hogy egy üzenet valóban el legyen küldve, és csak egyszer. Ezek a MOM-ok méretezhetők is annak érdekében, hogy hatalmas mennyiségű adatot, rövid idő alatt kezeljenek, ami akkor hasznos, ha például arra van szükségünk, hogy másodpercenként több ezer részvény árfolyamfrissítését tudjuk kiküldeni, több ezer kereskedőnek. A MOM-ok már majdnem két évtizede vannak jelen, és rendkívül kifinomult szoftverekké fejlődtek, melyeket az olyan jómódú ügyfelek, mint például a Wall Street-i befektetési bankok és telekommunikációs vállalatok, széles körben alkalmaznak. Az egyetlen dolog, amire nem képesek, hogy egymással natív módon üzeneteket váltsanak, anélkül, hogy olyan drága, egyedi meghibásodási pontot nyújtó eszközökre támaszkodjanak, mint például az átjárók.

Őszintén szólva, az inkompatibilis MOM-ok együttműködésre bírása kétség kívül nem könnyű feladat. Például alapvető szemantikai különbségek vannak az IBM eredeti sor-orientált és a Tibco publikációs és előfizetési modelljei között. Azonban az évek során a legtöbb MOM gyártó egymás jellemzőinek készletéhez anélkül közeledett, hogy az interoperabilitást akár még távolról is érintették volna. Ha valaki MOM felhasználó, akkor lényegében még 1991-ben él. Az, hogy a MOM gyártók szándékosan visszautasítják a szabvány-alapú interoperabilitást, mind a történelemmel, mind a józan ésszel szemben áll. Igaz, hogy időközben felkarolták a Java világ JMS szabványát (Java Message Service), ami specifikációjának meghatározását valójában az IBM és a Tibco vezette. Azonban a JMS csak egy API. Nem határozza meg a fejlécek és a csomagok formátumát, amik valójában a legalsóbb szinten helyezkednek el, és nem nyújtja az interoperabilitás ígéretét. Tegyük fel, hogy két azonos Java alkalmazásunk van, az egyik az A, másik pedig a B banknál, és mind a kettő JMS-t használ a helyi MOM implementációval való kommunikációhoz. Ha az A oldal MOM-ja IBM MQ, a B oldal MOM-ja pedig Tibco, akkor nem tudnak majd üzeneteket váltani, hacsak nem használnak egy átjárót (amit gyakran hídnak (bridge) neveznek az iparágban, habár a hagyományos adatok közötti kapcsolat szintje felett működik). A JMS pedig csak a Javához jó, így nem használható az olyan alkalmazások esetén, amiket például PHP-ben, Ruby-ban, vagy C++-ban írtak.

Valószínűleg sokan elgondolkodtunk már azon, hogy miért nem veszik figyelembe az interoperabilitást, ezt az alapvető követelményt? A válasz egyszerű. A Gartner szerint az IBM és a Tibco felügyeli a MOM piac óriási részét, a 93%-át, ami a piackutató vállalat becslései szerint az idén 725 millió dollárt érő piac. Ilyen piaci részesedéssel az IBM és a Tibco olyan árat kérhetnek, amit csak akarnak (az IBM misztikus „processzor értékegység” ársémája alapján a WebSphere MQ processzoronként több tízezer dollárba kerül). A harmadik helyen álló gyártó, a Progress Software „Sonic unit” terméke kevesebb, mint 2%-os piaci részesedéssel bír. Egy fiatal és egy gyorsan növekedő piacon egy olyan innovatív vállalat, mint a Sonic, a nagy piaci szereplők versenytársává válthat. A MOM azonban egy érett piac, mely évente csak néhány százalékkal nő. Röviden, az IBM és a Tibco egy kényelmes és haszonnal kecsegtető duopóliumon osztoznak, amit valószínűleg egy hagyományos versenytárs sem tud megdönteni. Az ügyfeleknek így kevés választásuk van, és el kell fogadniuk, amit ezek a nagy gyártók kínálnak, még akkor is, ha az interoperabilitás nem valósul meg.

Eddig ez volt a jellemző. Néhány nagy MOM felhasználó azonban végre eldöntötte, hogy nem fogadják el az interoperabilitással kapcsolatos kérdésekre adott nemleges válaszokat, és összefogtak néhány ambiciózus nyílt forráskódú gyártóval, hogy kifejlesszenek egy új és teljesen nyílt forráskódú üzleti üzenetküldést, az AMQP-t. Az AMQP az Advanced Message Queuing Protocol rövidítése.

Az AMQP alapító géniusza John O'Hara, a JPMorgan londoni kirendeltségének alelnöke és kiváló mérnöke. O'Hara a projektet még 2003-ban kezdte, és az első implementáció létrehozására egy kis európai, nyílt forráskódú tervezési hivatalt, az iMatrixot, kérte fel. A béta verzió 2006-ban jelent meg élesben, és a következő évben a bank már napi 300 millió üzenetét dolgozta fel. Az évek során sok befektetési bank hozta létre saját köztesrétegét, de csak nagyon kevés látott napvilágot a saját vállalati tűzfalakon kívül. O'Hara AMQP terve sokkal ambiciózusabb volt. Az AMQP ezért szándékosan eltávolodott az XML-től, ami a nagyjából hasonló WS-ReliableMessaging szabvány része. (A WS-RM, ami az Oasis webszolgáltatási szabványok közé tartozik, arra lett tervezve, hogy megbízható XML üzenetszállítást nyújtson a sajátosságából fakadóan nem megbízható HTTP-n keresztül.

O'Hara azonban a MOM jellemzők teljes készleténél többet akar. A tulajdonosi termékek kiszorítása érdekében az AMQP-nak az új internetes szabvánnyá kellene válnia. Ez a különböző, versenytársi implementációk közötti interoperabilitás garantálását jelentené. Emellett azt, hogy a munkacsoport más felhasználókkal és kereskedelmi szponzorokkal is kibővülne, valamint azt biztosítaná, hogy a felemelkedő szabvány „tiszta” szellemi tulajdonjogokat élvezzen.

Az AMQP jelenleg az érettség korai szakaszánál tart. A teljes 1.0-ás verzió várhatóan ez év végén jelenik meg. Legalább három különböző nyílt forráskódú implementáció érhető el: az eredeti iMatrix C implementáció, a Red Hat MRG disztribúció, ami az Apache Qpid-et foglalja magában (AMQP szerverek Javában és C++-ban vannak implementálva, az AMQP kliensek pedig C++-ban, Javában, Pythonban, Ruby-ban és C#-ban), valamint a RabbitMQ implementáció az Ericson nagy teljesítményű Open Telecom Platformján. Más nyílt forráskódú gyártók, akik részt vesznek az AMQP munkacsoportban, még nem jelentették meg a saját verzióikat. Ezek a gyártók például a következők: Novell, WS02 és Iona (melyet a JMS úttörő Progress Software vásárolt fel).

Habár az AMQP a tehetős és nagynevű befektetési bankok kivételezett környezetében jött létre, a támogatói az alkalmazásai jövőjét nem csak a pénzügyi szektorban képzelik el. Az AMQP a szolgáltatás-orientált architektúrák alapvető üzenetküldési megoldása lehet egy olyan iparágban, ahol az alkalmazások közötti üzenetküldés jelentős üzleti értékkel bír. De hiba lenne azt gondolni, hogy az AMQP csupán a tulajdonosi tűzfalak mögötti, vagy zárt kereskedelmi közösségek tulajdonosi köztesrétegének egy nyílt forráskódú megfelelője. John O'Hara víziója sokkal távolabbra mutat ennél. Ebben a vízióban az AMQP egy napon a vállalatok közötti nyílt, üzleti tranzakciós hálózatok egyetemes alapjává válik majd, ahol minden vállalat saját üzenetközponttal rendelkezik, mely más üzenetközpontokkal tulajdonosi átjárók használata helyett közvetlenül kommunikál. Ez a nagy értékű, üzletek közötti üzenetküldést olyan egyszerűvé tenné, mint a mai Internetes e-mail.

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