Proč si programy posílají zprávy?

Kdysi dávno, v dobách veleještěrů zhluboka oddychujících v obrovských sálech to bylo jednoduché. Na jednom velepočítači byla spuštěna jedna veleaplikace, k níž se připojovali její uživatelé. Počítače byly izolované, aplikace spolu proto příliš nespolupracovaly. Jak klesala cena počítačů i náročnost aplikací, začaly se firmy vybavovat stále větším počtem počítačů s různými aplikacemi usnadňujícími chod firmy. Jakmile se všechny počítače mezi sebou propojily sítí, ukázalo se, že by bylo nesmírně vhodné propojit nějak i vlastní aplikace, protože se tak zvýší jejich užitná hodnota. A právě tehdy si mezi sebou začaly aplikace posílat zprávy a tehdy také vznikly termíny messaging a middleware.

Jako mnoho termínů ze současné informační vědy, nemají slova middleware a messaging exaktně definovaný význam. I když mají jednotlivé interpretace společný základ, přesto je každý chápe trochu jinak. Proto se také mezi sebou odlišují řešení od různých firem. Proto je těch řešení tolik. A proto také neexistuje jednoznačný a hezký český překlad obou termínů. Abychom si mohli ukázat přehled současných řešení, která jsou s těmito termíny spojena, se však významu těchto slov musíme nějak dobrat.

Začněme tím jednodušším: messaging. Každý, kdo je jen trochu znalý anglického jazyka, tuší, že termín pochází z anglického message, tedy zpráva. Na zprávy narážíme v moderní informatice neustále: informace, které si po síti posílají uživatelé jsou zprávou, hlášení systému či programu je zprávou, zprávy si mezi sebou vyměňují i aplikace (často o tom dokonce jejich uživatelé vůbec neví). Problémem klasického, živelně vzniklého informačního prostředí firmy ovšem je, že k této výměně zpráv dochází jaksi neuspořádaně. Některé programy spolu komunikují a jiné ne, někteří uživatelé spolu mluví a jiní ne. Aby firma běžela jako po másle, je tedy nutné vnést do všeho nějaký systém. A protože stále ještě mluvíme o zprávách, nazývá se tento systém messagingový (messaging system), zkráceně messaging.

Samotný pojem zpráva je velmi obecný. I v obyčejném životě, kde o počítač nezavadíte, se používá v různém kontextu. Ve světě informatiky je především nutné rozlišit klasické "lidské" zprávy od zpráv a hlášení, jež si mezi sebou vyměňují jednotlivé aplikace nebo aplikace a systém. Pro skutečně efektivní práci firmy je nutné systematicky hlídat tok zpráv lidských i technologických, a pro oba typy zpráv také existují různá řešení. My se zaměříme na zpracování a řízení komunikace mezi aplikacemi, označované někdy také jako technology messaging. Tokem zpráv generovaných lidskými uživateli se zabývá odvětví označované jako unified messaging.

Zprávy posílané mezi jednotlivými aplikacemi často padají na straně příjemce do jakési fronty (queue), odkud si je příjemce postupně vybírá. Proto mnoho implementací messagingových systémů snadno odhalíte podle písmen M a Q v názvu aplikace (IBM, Sun, Microsoft, Progress).

Pojem middleware je snad ještě obecnější než messaging. Někdy dokonce oba pojmy splývají v jeden. Obecně je ale možné říci, že messaging system je jakýmsi potrubím, jež zajišťuje hladký běh a výměnu zpráv a middleware je "to všechno kolem". Máme-li jistotu, že jsou spolu aplikace schopny komunikovat, musíme rozhodnout, jaké zprávy si budou posílat, jaká data budou sdílet a jak je zpracují. A to všechno zajišťuje právě middleware. Chytrý middleware je navíc navržen tak, že jednotlivé aplikace nijak neomezuje a nezdržuje. Middleware schopný pracovat se zprávami se nazývá message oriented middleware a bývá označován zkratkou MOM.

Kombinace middleware s aplikacemi a databázemi vytváří dohromady cosi, co je nejčastěji nazýváno jako firemní informační systém. Je to provázaný soubor aplikací, jež spolu sdílejí data a vzájemně spolupracují. Správně navržený a sestavený informační systém svými funkcemi pokrývá veškerou důležitou firemní agendu (zpravidla vedení účetnictví, personalistiku, skladové hospodářství, správa kontaktů na partnery a zákazníky, workflow a další). Díky automatizaci a zrychlení některých činností tak firma získává konkurenční výhody, neboť šetří pracovní síly, čas i náklady. Je pochopitelné, že se informační systémy jednotlivých firem od sebe výrazně odlišují. Liší se nejen skladbou aplikací danou předmětem činnosti firmy či organizace, podstatně se liší také rozsahem i cenou.

Vzhledem k tomu, že v uvedené sestavě snadno na první pohled rozlišíme tři základní vrstvy (původní aplikace, middleware a klientské aplikace), označuje se taková aplikace často jako třívrstvá. Middleware tvoří střední vrstvu (odtud také pochází jeho název), tedy prostředníka mezi aplikacemi a jejich výstupy na straně klientů. Messagingový systém je tmel, který slepuje rozhraní mezi aplikacemi a střední vrstvou. Strukturu klasické třívrstvé aplikace ukazuje obrázek.

Generace integrace

Jen zřídka vzniká firemní informační systém jen tak z ničeho na zelené louce. V takovém případě je všechno velmi jednoduché: systém je navrhován jako celek, dílčí aplikace nebo databáze jsou voleny tak, aby spolu vzájemně bezproblémově spolupracovaly. Funkce jednotlivých aplikací se nijak nepřekrývá, nedochází k ukládání stejných dat na více místech. Řešení může být sestaveno z produktů jedné firmy, stejně dobře může být poskládáno z dílčích aplikací různých výrobců. Systém je navíc často přímo navrhován tak, aby byly některé nebo všechny jeho funkce dostupné přes webové rozhraní, určité důležité výstupy či sestavy mohou být zaneprázdněným manažerům, pobývajícím neustále na cestách, zprostředkovány i mobilním telefonem.

V praxi je ovšem taková situace spíše nadpřirozeným úkazem. Téměř každá firma pořizuje své softwarové vybavení postupně. Nejprve bývají zakoupeny jednotlivé dílčí aplikace, ve větší firmě navíc o nákupu rozhodují různá oddělení. Účetní dostane účetní programy, správce skladu nějaké skladové hospodářství, sekretářka vyrobí v tabulkovém procesoru databázi zaměstnanců a evidenci docházky, firemní kontakty jsou uloženy v samostatné databázi, obchodní oddělení získá vlastní aplikaci pro správu objednávek a faktur. Jednotlivé programy jsou různě staré, pracují s různými objemy dat, v různém režimu. Největším problémem potom je skutečnost, že se funkce některých programů částečně překrývají a v databázích jednotlivých programů se hromadí duplicitní data. Taková situace se časem může stát neudržitelnou, neboť bude stále obtížnější zajistit, aby nedocházelo ke ztrátě informací a aby se některé činnosti neprováděly dvakrát.

Jakmile se vedení firmy rozhodne "s tím něco udělat", vstoupí do firmy osoba znalá a povolaná - systémový integrátor. Nejprve provede rozsáhlou studii stávajícího systému aplikací. Vyšetří, kde všude se jednotlivé aplikace překrývají, jaká data chybí, jaká jsou ukládána dvakrát a které procesy je možné automatizovat. Následuje zdlouhavý a bolestný proces zavádění pořádku označovaný jako integrace.

Integrace může být v zásadě dvojího druhu: aplikační a na úrovni middleware. V prvním případě je systém jednotlivých nespolupracujících aplikací a databází zásadně přebudován. Staré aplikace jsou nahrazeny novými, jejich spektrum je upraveno tak, aby se vzájemně funkčně přesně doplňovaly. Roztříštěné databáze jsou sloučeny a jednou či několika novými nahrazeny tak, aby byla data ukládána s maximální efektivitou. Proces je zdlouhavý, náročný a často také poměrně drahý, neboť je nutné pořizovat zcela nové aplikace, nové databáze a s s tím ruku v ruce často také nové servery a další hardwarové vybavení.

Ve druhém případě se toho naopak přestavuje co nejméně. Pod stávající aplikační vrstvu je se jakoby podsune cosi, co donutí jednotlivé aplikace spolupracovat a sdílet svá data. Správně tušíte, že tím cosi je právě middleware a messagingový systém. Výhodou je, že nemusíte příliš zasahovat do struktury firmy, a kromě vlastního middleware nemusíte (teoreticky) pořizovat nic dalšího. V praxi se pochopitelně obě metody částečně kříží a doplňují. V prvním případě se stejně musí nějaký messagingový systém použít. Vzhledem k tomu, že ale současně zásadně měníte své aplikace a data, může to být zcela jiný systém, než po kterém sáhnete v případě druhém, kdy chcete především rychle zajistit spolupráci bez dalších zásahů.

Pod kůží messagingového systému

Messagingový systém tedy propojuje navzájem mezi sebou jednotlivé aplikace a vytváří tak ze samostatných součástek výkonný a hladce běžící stroj. Důležité je, že spolu mohou součástky svobodně hovořit každá s každou, kdykoliv je právě napadne. Jinými slovy, messaging zajišťuje přímou asynchronní komunikaci mezi samostatnými komponentami, na rozdíl od staršího modelu klient-server. Aplikace si zkrátka jakousi potrubní poštou posílají zprávy s definovanou strukturou. Nemá-li na tom příjemce speciální zájem, nemusí se vůbec starat, kdo mu zprávu poslal, kde se odesílatel fyzicky nachází a kdy přesně zprávu generoval. Takový systém lze tedy poměrně snadno uzpůsobovat aktuálním potřebám jeho uživatelů - je tedy snadno škálovatelný. Messagingový systém představuje univerzální sběrnici - podobně jako ostatní harware většinou nijak nepostřehne výměnu staré grafické karty za výkonnější model, ani v tomto případě si ostatní příjemci nemusí všimnout, že se jeden z odesílatelů přestěhoval z PC na nějaký veleserver s komerčním Unixem. Systémy sestávající ze vzájemně propojených nezávislých komponent postupně nahrazují složité distribuované aplikace, neboť odpadají problémy se synchronizací vzájemné komunikace, dosažitelností, škálovatelností a bezpečností připojení (posílané zprávy je možné jednoduše kódovat nebo digitálně podepisovat).

Dva modely komunikace

Chceme-li do potrubní sítě odeslat nějakou zásilku, můžeme ji popsat dvěma způsoby. První variantou, která asi každého ihned napadne, je napsat na obálku zásilky adresu příjemce. Zásilka putuje potrubím, až dorazí na místo určení. Propojuje se tak vlastně adresáta s odesílatelem, systém pracuje v režimu point-to-point. Výhoda je zřejmá: zásilkou není obtěžován ten, komu není určena. Někdy se však stane, že se rozhodneme více adresátům předat stejný balíček dat. Vzhledem k tomu, že se na obálku vejde právě jedna adresa, musíme vytvořit a odeslat tolik balíčků, kolik je adresátů, i když balíčky obsahují úplně stejná data. Tento systém je také často charakterizován termínem všichni směrem k jednomu, neboť se libovolný počet odesílatelů může ve stejnou chvíli obrátit na jednoho adresáta.

K problému proto můžeme přistoupit zcela odlišně: nebudeme zprávy rozlišovat podle adresáta, ale podle jejich obsahu. Na každou zprávu nějak jasně napíšeme, co zpráva obsahuje a všichni připojení aktivní příjemci se podle popisu sami rozhodnou, zda mají o zásilku zájem, či nikoliv. Nevýhoda je zřejmá - balíčkem se musí zabývat každý, kdo je do mé potrubní sítě připojen. Když se ale rozhodnu z ničeno nic připojit do systému novou komponentu, nemusím ostatním říkat její adresu a sahat tak do nastavení. Komponenta si sama zachytí data, jež pro svou práci potřebuje. Tento model je označován jako publish/subscribe. Odesílatelé generují zprávy s různým obsahem (tématem). Příjemci se přihlašují k odběru určitého téma. V jednu chvíli tak vlastně libovolný počet odesílatelů oslovuje libovolný počet příjemců.

V obou případech pochopitelně může být komponenta současně odesílatelem zpráv i jejich příjemcem.

Některé messagingové systémy podporují pouze jeden z modelů, jiné jsou schopné oba modely kombinovat. V přehledu konkrétních řešení je vždy podporovaný model komunikace uveden.

Technologie a realizace

Prvotní idea pro sestavení messagingového systému je tedy velmi prostá. Je nutné nějakým způsobem definovat formát s fyzickou podobu zprávy a vyřešit, jak zajistit její doručení. Skutečných messagingových systémů existuje poměrně velké množství. Jako i v jiných oblastech, i zde existují implementace vystavěné na otevřených standardech vedle zcela privátních a uzavřených řešení. Ponechme raději stranou diskusi o sporu mezi otevřeným a uzavřeným řešením a podívejme se raději na stavební kameny, jež mají tvůrci jednotlivých řešení k dispozici.

Messagingový systém musí ve své ideální podobě propojit různé aplikace v různých operačních systémech. Rovněž formát přenášených dat by v ideálním případě měl být rozluštitelný za různých okrajových podmínek. Je proto vcelku pochopitelné, že je velmi často v souvislosti s těmito systémy skloňována Java díky své nezávislosti a XML jako vhodný formát pro data. Ne všechny systémy jsou napsány v Javě, ale projdeme-li je postupně, zjistíme, že je jich naprostá většina. Ty, které v Javě napsány nejsou, alespoň disponují nějakým rozhraním, kterým je možné se k javským aplikacím připojit.

Ani messagingový systém nevisí někde ve vzduchoprázdnu. Ohromný stroj, který pohání, musí čas od času komunikovat s jiným ohromným strojem: informačním systémem zákazníka či obchodního partnera. Tato firma může pracovat s úplně jiným messagingovým systémem. Jestliže již dopředu víte, že se budete takto na někoho napojovat, je od počátku vhodné hlídat, zda se je váš systém s partnerským propojitelný. Tato napojení jsou vlastně jakýmsi mostem, překlenujícím vzdálenost mezi vámi a partnerskou firmou, proto jsou výrobci často označována jako bridges.

Při rozhodování je dále důležité, kolik aplikací lze skutečně na messagingový systém napojit. Je-li napsán s využitím nějakého standardu, napojíte pochopitelně všechny aplikace s vhodným rozhraním. To je však zpravidla málo, neboť podobná rozhraní vznikají až v poslední době. Chcete-li tedy připojit nějakou starší aplikaci, musíte mít jistotu, že pro ni má zvolený systém správný konektor. Zde se asi nejvíce projevují rozdíly mezi řešením budovaným na otevřených formátech a uzavřenými systémy. Ve druhém případě si totiž musíte zakoupit speciální konektor pro každou aplikaci. V prvním případě musíte shánět konektory jen pro ty aplikace, jež není možné připojit jinak (přes standardní rozhraní).

Standardně jsou systémy budovány tak, že u každé aplikace, jež je zdrojem či příjemcem zpráv, číhá tykadlo messagingového systému. Tohle tykadlo může být buď nativní aplikace připravená přímo pro operační systém nebo nějaký interpretovaný program. Proto je vhodné včas kontrolovat, jakými tykadly systém disponuje. (V praxi se ovšem tykadla nazývají poněkud prozaicky klienti.) Je-li systém napsán v Javě, pravděpodobně nebudou žádné problémy, je-li však nějakým komerčním řešením, musíte být pozorní. I v Javě existují různé standardy a firma Sun hlídá, které aplikace jim vyhovují. Jestliže nějaké řešení splní všechny referenční testy a prokáže, že skutečně plně a správně implementuje všechny rysy standardu, získává od Sunu licenci (certifikát). Seznam licencovaných výrobců Sun zveřejňuje na svých webových stránkách.

Java jako taková je na messaging připravena. Standard J2EE (Java 2 Enterprise Edition) obsahuje i Java Message Service (JMS), nabízející standardní rozhraní pro všechny, kdo by chtěli v Javě vytvářet messagingový systém nebo se na něj z nějaké aplikace napojovat. JVM umožňuje vysílání metodou poin-to-point i metodou publish/subscribe. Tělem zprávy může být buď textový řetězec (tedy i libovolný XML dokument) nebo objekt.

Zmínili jsme také problém bezpečnosti. Máme-li více poboček na různých místech, můžeme pochopitelně posílat zprávy i mezi pobočkami. Jestliže k přenosu zpráv chceme využít Internet, je vhodné kontrolovat, zda systém nabízí možnost zprávy nějak šifrovat nebo pro jejich přenos využít hůře prolomitelné protokoly. I když se nechystáme vyrazit přímo do Internetu, není dobré bezpečnost podceňovat. Konec konců, prokazatelně nejvíc útoků přichází z nitra firem, nikoli zvenčí.

Aplikační server

Volbou messagingového systému však celý proces nekončí ani nezačíná. Systém je zde jen jakýmsi prostředníkem, potrubím pro výměnu zpráv. Definuje jejich formát, určuje způsob šíření. V závislosti na zvoleném řešení je různě inteligentní: u některých výrobců je messagingový systém striktně oddělen od implementace aplikační logiky, jinde obojí podstatnou měrou splývá. Holý messagingový systém nabízí jen málokdo, častým souputníkem messagingového systému je proto ještě další velmi důležitý program nazývaný aplikační server.

Zatímco messagingový systém propojuje dílčí komponenty na úrovni fyzické a vytváří prostředí pro přenos zpráv, aplikační server pracuje na úrovni programové logiky. Aplikační server je skutečným srdcem informačního systému. Obsahuje definici firemních procesů a zajišťuje jejich fungování. Je-li nutné během výměny dat mezi aplikacemi data nějak zpracovávat, převádět nebo upravovat, zná podrobný popis jednotlivých akcí a zodpovídá za jejich provedení. Vzhledem k tomu, že nejčastějším médiem pro výměnu zpráv na dlouhé vzdálenosti bývá Internet, často je aplikační server propojen s webovým serverem nebo portálovou aplikací. Některé aplikační servery navíc dokáží data dopravit k různým koncovým zařízením: mobilním telefonům či kapesním počítačům.

Ne všechny aplikační servery jsou vybaveny klasickým messagingovým systémem v podobě, v jaké jsme jej zatím popsali. Buď pro správu distribuovaných aplikací využívají jiné technologie nebo jsou určeny pro trochu jiné aplikace. Hlavními hráči na trhu aplikačních serverů jsou firmy IBM a BEA, oba jejich servery stejně jako ty ostatní jsou napsány v Javě. Jsou tak snadno přenositelné z prostředí do prostředí, což je důležité zejména v okamžiku, kdy se firma začne rozrůstat a rozhodne se server střední třídy nahradit železem těžkého kalibru.

Standard J2EE obsahuje mimo jiné i definici, jak vytvářet a psát konektory mezi serverem a vlastní aplikací (nebo dalším firemním informačním systémem) - tzv. Java Connector architecture. Většina dobrých aplikačních serverů tuto technologii podporuje a pro důležité aplikace již existují hotové konektory. Dodávají je buď výrobci aplikací nebo serverů.

Praktické ukázky

V hrubých obrysech jsme si v předcházejícím textu nastínili, co je to messagingový systém a kde jej můžeme hledat. Vzhledem k tomu, že se jeho pojetí liší výrobce od výrobce, nabízím nyní stručný přehled nejznámějších a nejpoužívanějších řešení. Jako první jsou do přehledu řazena řešení využívající javské technologie a standardy, následují různá alternativní a uzavřená řešení.

U každého řešení je uvedena jeho základní charakteristika a seznam systémů, s nimiž dokáže spolupracovat. Dále jsou zmíněny všechny další vlastnosti, které podle mého názoru uvedené řešení odlišují od ostatních.

iPlanet Message Queue for Java

Protože jsem se rozhodla nejprve představit řešení postavená na javských standardech (především na JMS), je slušností začít přímo u pramene, přesněji u Slunce. Firma Sun má svůj vlastní aplikační server iPlanet a poměrně rozsáhlé portfolio produktů s ním spolupracujících. V kategorii integration services je zařazena také implementace JMS. Patří pochopitelně mezi implementaci s certifikátem.

Server je možné provozovat na operačních systémech MS Windows NT/2000, Solaris a Linux (RedHat 6.1 pro PC). Klienti pracují navíc ještě v systémech Windows 98/Me.

Zprávy je možné posílat v režimu point-to-point i v režimu publish/subscribe. Implementace je vybavena grafickým uživatelským rozhraním pro správu, pochopitelně se nezapomíná ani na příkazovou řádku. Pro zabezpečení komunikace je možné využít SSL (další možností je TCP a HTTP), je možné rozhodovat odkud a kdo se smí k systému připojovat.

Zájemci si mohou vyzkoušet volně poskytovanou variantu pro vývojáře (Developer Edition), která je nabízena na domovských stránkách produktu (rozcestník najdete na CD). Tato verze pracuje devadesát dní a slouží pouze k testovacím účelům. Nesmí být nasazena v nějaké "ostré" aplikaci. Pro skutečné aplikace je určena Enterprise Edition, jejíž cena se určuje podle počtu procesorů (4.000 USD za jeden).

Kdybyste se rozhodli pro sestavení aplikace využít i další produkty z řady iPlanet, asi vás bude zajímat především iPlanet Integration Server (B2B Edition či EAI Edition), což jsou aplikační servery sloužící právě pro propojování různých firemních aplikací. Jestliže právě chystáte nějaký e-obchod či e-portál, můžete sáhnout po iPlanet Application Serveru (Standard, Enterprise a Enterprise Pro Edition).

BEA WebLogic Server

Ačkoli je firma BEA jednou z nejmladších v našem výčtu, její aplikační server patří mezi ty nejpoužívanější. Firma nenabízí jen aplikační server, ale i všechny další důležité produkty pro sestavení správné třívrstvé aplikační struktury. Srdcem všech řešení však zůstává javský aplikační server WebLogic, jenž obsahuje také implementaci JMS. WebLogic Server je jedním z řešení, kde messagingový systém není samostatným produktem, ale nedílnou součástí aplikačního serveru.

BEA vyniká podporou mnoha nejrůznějších kombinací operačního systému s hardware, na nichž je možné server provozovat. Firma nepíše vlastní JVM (Java Virtual Machine) pro jednotlivá prostředí, ale využívá JVM dodaných výrobcem systému, které certifikuje. Díky spojení s aplikačním serverem je pochopitelně pamatováno na otázky bezpečnosti, propojitelnosti (podpora Java Connector architecture), dostupnosti v různých koncových zařízeních a další.

Vývojářská edice serveru je nabízena zdarma ke stažení na webových stránkách firmy. Vlastní server WebLogic existuje ve variantách Server (určen především pro tvorbu webových aplikací), Enterprise (pro tvorbu robustnějších aplikací) a Express (jednodušší dynamické webové aplikace).

SonicMQ

Poslední implementací JMS v našem výčtu je SonicMQ pocházející z dílny Progress Software. Navíc oproti standardu podporuje i zprávy ve formátu XML, pracuje v obou režimech rozesílání zpráv. SonicMQ podporuje digitální certifikáty, 40-128bitové šifrování, umožňuje autorizaci přístupů. Odeslané zprávy jsou registrovány ve vestavěné databázi, proto by měly být zprávy vždy doručeny, bez ohledy na výpadky fyzické infrastruktury. Podporuje databáze Progress v 9.1, Oracle 8i a Microsoft SQL Server V7.

Pro vývoj aplikací a jejich testování je možné využít Developer Edition poskytovanou zdarma (je přiložena na samostatném CD k časopisu), nebo Professional Developer Edition. První varianta má limitován počet připojených uživatelů a povoluje připojení k jedné IP adrese. Pro vlastní nasazení ve firmě je určena E-Bussines Edition. Vytvořené aplikace lze mezi jednotlivými variantami přenášet.

Ze SonicMQ se spojíte se všemi systémy podporujícími JMS i s IBM MQSeries (viz dále). SonicMQ pracuje s klienty vybavenými Java API, COM/ActiveX nebo adaptérem pro Progress 4GL. Pro vývojáře je navíc připravena SonicMQ Messaging JavaBean, integrovatelná webových řešení nebo grafických vývojových nástrojů.

Progress Software má i svůj aplikační server (Open AppServer), jenž se SonicMQ spolupracuje.

MQ Series

Firma IBM má vlastní implementaci messagingového systému, pojmenovanou MQSeries. MQSeries nevycházejí z JMS, ale obsahují i podporu pro Javu a API pro připojení k aplikacím, jež JMS využívají. MQSeries přenášejí data mezi aplikacemi prostřednictvím front, v nichž jsou zprávy řazeny. Na každém počítači je umístěna jedna fronta pro zprávy, ze které si aplikace zprávy vybírají. Rozdíly mezi komunikací v rámci jednoho a více počítačů ukazují obrázky. API pro MQSeries nabízí čtyři základní operace: otevření fronty, vložení zprávy, vybrání zprávy a zavření fronty.

MQSeries pracují v systémech AIX, Compaq NSK, HP-UX, Linux, OpenVMS Alpha, OpenVMS VAX, OS/2, OS/390, OS/400, Solaris, VSE/ESA a Windows 3.x/95/98/NT/2000.

IBM má také svůj vlastní javský aplikační server (WebSphere), který je po serveru WebLogic v současné době nejrozšířenějším. I při použití MQSeries proto můžete zůstat v náručí jedné firmy.

TIB/Active Enterprise

Dalším alternativním řešením jsou produkty firmy Reuters z řady TIB/Active Enterprise. Pro výměnu dat je používán vlastní formát nezávislý na prostředích a datových formátech propojovaných aplikací. Aplikace jsou k transportní vrstvě připojovány konektory, které si musíte pro každou aplikaci zakoupit zvlášť. Systém pracuje pouze v režimu publish/subscribe, jednotlivé adaptéry si ze zpráv vybírají podle jejich záhlaví. U každé připojené aplikace číhá démon, jenž je zodpovědný za příjem i vysílání zpráv. I když řešení přímo neobsahuje aplikační server, je možné modulem TIB/MessageBroker zajistit transformaci a zpracování dat. Modul je možné využít i pro implementaci jednoduššího workflow. K systému je možné připojit i rozhraní pro JMS (TIBCO Enterprise for JMS).

Systém pracuje na AIX 4.3/5.1, FreeBSD 3.3/4.2, HP UX 11.X, Linuxu (od jádra 2.2), Solarisu (od verze 2.6), VMS 7.2 a Windows NT/2000.

MSMQ a BizTalk Server

Microsoft se vydává svou vlastní cestou, jejíž výhodou a nevýhodou zároveň je přímé propojení messagingového systému s operačním systémem. Messagingový systém se nazývá MSMQ a Windows 2000 počínaje je součástí operačního systému. Písmena v názvu napovídají, že i tento systém řadí zprávy do front.

Pro vlastní propojení jednotlivých aplikací je určen BizTalk Server. Data jsou mezi aplikacemi vyměňována ve formátu XML, server je proto doprovázen sadou nástrojů pro snadné mapování různých formátů na XML. Po převodu do XML mohou být zprávy dále transformovány s využitím XSLT. Vývojové nástroje také obsahují grafické prostředí pro definici firemních procesů. BizTalk Server 2000 pracuje v prostředích Windows 2000.

Poslední změna: 3. 3. 2011