Message oriented middleware (MOM) je kategorií softwaru zajišťujícího komunikaci mezi aplikacemi (či aplikačními komponentami), jenž je obvykle založen na asynchronním posílání zpráv. MOM je obvykle implementován pomocí front zpráv, ale některé MOM systémy používají jiné přístupy – například broadcast nebo multicast komunikaci.
Historie této technologie sahá až někam k roku 1980, kdy vývojáři začali usilovat o řešení nezávislé na platformě, jazyku, hardwaru či síťových protokolech. Postupem času, jak se MOM technologie vyvíjely, získávaly obrysy hlavní výhody messagingu.
Ukládání je jednou z hlavních výhod, pomocí kterého je MOM provider schopen zajistit zaručený transport. Při výpadku serveru nebo síťového spojení může být zpráva bezpečně načtena z disku. Také pakliže konzument nebo konzumenti nejsou dostupní a jsou v takzvaném dlouhodobém (durable) režimu, zpráva zůstává uložena na serveru až do doby, než se zase připojí.
Ukládání je podle mého názoru klíčovou vlastností MOM systémů a zajišťuje nejen vysokou bezpečnost komunikace, ale také výborné prostředky pro následný monitoring či historii transakcí. Například v situaci, kdy objednávkový systém přijímá objednávky a předává je přes vrstvu MOM fakturačnímu systému, nemusí dojít ke kompletní odstávce celého procesu při výpadku fakturací – objednávkový systém funguje zcela nezávisle na fakturačním a zprávy (objednávky) jsou bezpečně ukládány na MOM serveru. Jakmile je fakturace obnovena, všechny objednávky jsou promptně doručeny k vyřízení a zákazník pracující s objednávkami vůbec nepozoruje výpadek.
Pokročilé směřování zpráv je další výhodou, které MOM systémy přináší. Většina messaging systémů nabízí možnosti různého přesměřovávání či duplikování zpráv a to ať už z jednotlivých cílů na jiné, tak mezi různými servery. Pokročilé messaging systémy pak umějí vytvářet (tzv globální) cíle přes více serverů a rozkládat zátěž (load-balancing).
Typickým příkladem může být například pravidlo vytvořené na MOM serveru, které všechny zprávy směrující do cíle „objednávky“ kopírují také do cíle „historie.objednávky“, kde jsou poté vyzvedávány procesem, který data transformuje do datového skladu. Nebo také případ firmy s mnoha pobočkami, mezi jejichž MOM servery probíhá po zabezpečeném kanálu replikace zpráv, je případem doslova ze života.
Nesmím opomenout také transformaci zpráv, kdy MOM server předává zprávu do jiného messaging systému, případně ji importuje nebo exportuje do úplně jiného prostředí (e-mail například). Pokročilé MOM systémy nabízejí nástroje pro mapování a transformaci dat v předávaných zprávách, ale tady již zacházíme do tématu integrace, kterému se budu věnovat v dalším textu.
MOM systémy velmi snadno zajišťují distribuovanost včetně load-balancingu, který je díky frontám zpráv velmi snadno implementovatelný. Pakliže máme komponentu, která zpracovává data velmi pomalu, stačí nám vytvořit několik instancí těchto komponent a všechny napojit na jednu jedinou frontu zpráv. Jakmile se začne fronta plnit, komponenty budou zprávy paralelně vybírat a zpracovávat, přičemž MOM se postará o správné doručení. Tento aplikační load-balancing je typický návrhový vzor používaný v MOM systémech.
Mezi typické vlastnosti MOM patří kromě jistoty přenosu a trvalých (durable) cílů také bezpečnostní politika. Jelikož může být messagingový server dostupný pro celou firemní síť, musí být nějakým způsobem zajištěna autentizace a také zabezpečení přenosu. Každý produkt a technologie tuto věc určitým způsobem řeší, často například napojením na adresářové služby a podporou SSL.
Politiky doručování jsou také velmi důležité, už jsem zmínil reliable messaging, kdy MOM systém zaručuje korektní doručení zprávy, pokud existují příjemci. Mnoho MOM systémů však implementuje více možností, protože u politiky doručování musíme řešit spoustu dalších věcí -– nevadí příjemci duplicitní zprávy? Musí být zachováno pořadí, v jakém byly zprávy odeslány? Tyto otázky si musí architekt systému položit a je nutné najít určitý kompromis mezi robustností, použitelností a výkonem celého řešení.
Důležitou vlastností je také politika uchovávání zpráv -– mají být zprávy uchovávány všechny, nebo jen některé? Co se zprávami, které nelze doručit – zahodit, přeposlat? Jak často se snažit o další doručení? A kdy notifikovat správce, že zpráva nemohla být doručena? Zprávy mají obvykle čas platnosti (TTL), což definuje například JMS specifikace. Tato politika jde ruku v ruce s tvorbou speciálních archivačních cílů s expedicí do systémů pro data mining.
Na světě existuje silný standard JMS, který, ačkoliv má v sobě slůvko „Java“, již dávno překročil hranice této platformy a stal se světově uznávaným standardem. Klientské knihovny pro JMS jsou dnes již implementovány pro mnoho jazyků (C/C++, C#) a také JMS servery nejsou psány již výhradně v Javě –- například Tibco EMS nebo Sun Enterprise Message Queue jsou naimplementovány v jazyce C. JMS se prosadila v enterprise sféře velmi silně a jako standard v podstatě nemá konkurenci.
Některé proprietární systémy nabízí vyšší výkon či jiný přístup k transportu (broadcast/multicast), z těchto bych uvedl například Tibco Rendezvous či IBM MQ Series (nyní tato technologie spadá do rodiny WebSphere). Existují také vysoce specializované messaging implementace nabízející real-time posílání zpráv a svoje messaging řešení nabízí například i firma Microsoft.
Kromě JMS existuje několik pokusů o standardizaci, například AMQP nebo úspěšnější instant messaging protokol XMPP. Ačkoliv enterprise messaging a instant messaging toho má svým zaměřením pramálo společného, například JMS implementace ActiveMQ nabízí do XMPP vlastní binding (jinak řečeno transport).
S messagingem je velmi snadné emulovat také synchronní posílání zpráv, pokud je třeba. Synchronní komunikace je z pohledu messagingu pouze dvojice zpráv dotaz-odpověď, což je v MOM prostředí jednoduchá situace. U JMS se synchronní komunikace řeší pomocí dočasných cílů (temporary destinations), kdy odesílatel vytvoří pro příjem odpovědi dočasný cíl. Svoji roli zde také hraje hodnota hlavičky JMSCorrelationID, která dvojici zpráv pojí dohromady.
Mnoho programátorů a analytiků, kteří nemají s messagingem zkušenosti, mají tendenci používat jej pouze jako primitivní transportní médium. Pakliže MOM implementace poskytuje spolehlivý (reliable) přenos zpráv, není třeba designovat aplikace jako request-response. Po pečlivém navržení strategie přenosu (typy zpráv, timeouty, cíle, routing) lze prostě data MOM systému předat a spolehnout se na vyřízení danými konzumenty. MOM systém zaručuje doručení a je schopen reagovat i na chybové situace – například předáním zprávy do speciální fronty při vypršení daného timeoutu nebo nedoručení.
MOM dnes hraje velmi důležitou roli v oboru nazvaném systémová integrace. Modelování firemních procesů může být velmi komplexní a složitý úkol i pro specializované firmy a je to běh na dlouhou trať. Právě v tomto prostředí sehrává MOM roli prostředníka umožňující se systémům mezi sebou „bavit“ navzájem.
Messaging je vhodný pro tvorbu obchodních sběrnic (enterprise service buses – ESB), kde se obvykle obohacuje o další služby jako je konfigurace, management, monitoring, logování a podobně. ESB sběrnice umožňuje MOM systém abstrahovat a často se používá k implementaci architektury SOA.
Webové služby (web services) umožnily komunikaci mezi počítači přes síť nezávisle na platformě, programovacím jazyku a formátu dat. Cílem bylo vytvořit společný formát, pomocí kterého by se cizí systémy byly schopny dorozumět. Webové služby nejsou messagingovým systémem, ale mají některé společné rysy a pomocí webových služeb se dá MOM systém emulovat. ESB systémy tedy mohou používat MOM, nebo také webové služby. Velmi často také vídáváme adaptéry, které překládají volání webových služeb na zprávy v MOM systému (a naopak). Webové služby často hrají hlavní roli v servisně orientované architektuře (SOA), které se budu věnovat někdy příště.