Je velmi neobvyklé, aby "běžná" firma využívala na podporu svých business aktivit jen jednu aplikaci - jeden informační systém. Toto tvrzení lze podpořit i odhadem agentury Gartner: do roku 2005 žádná aplikace nebude pokrývat více než 40% aplikačních potřeb dané organizace. Typický je tedy pravý opak, kdy firmy používají různé specializované aplikace různých výrobců na různých platformách. Tato situace pak vede k tomu, že firmy musí věnovat značné úsilí na zvládnutí technologických ICT procesů, což odvádí jejich pozornost od předmětu vlastního podnikání. Snahy firem být "e-fektivní" proto vyústily v trend vytěsňovat podpůrné činnosti a řešit je dodavatelsky a zbývající aplikace co nejvíce integrovat. V tomto kontextu pak hovoříme o (celo)podnikové integraci aplikací (Enterprise Application Integration - EAI) případně o mezipodnikové integraci aplikací (Business to Business Integration - B2B Integration).

Middleware - klíč ke komunikaci aplikací
Jednou z cest, jak integraci řešit, je využití některé middlewarové technologie, tedy takové technologie, která se - obrazně řečeno - vloží mezi stávající aplikace a komunikaci bude zprostředkovávat. Takovýchto technologií je řada, proto se tento příspěvek bude zabývat pouze popisem systémů řízení výměny zpráv (messaging systems, messaging), který spadá do segmentu trhu MOM (Message-Oriented Middleware). Pojmem messaging pak bude myšlen způsob komunikace - výměna zpráv - mezi softwarovými komponentami nebo softwarovými aplikacemi (tedy nikoli mezi lidmi).

Komunikace aplikací - stará myšlenka v novém kabátě
V dnešním heterogenním rychle se měnícím světě je potřeba spolehlivé a pružné komunikace mezi aplikacemi velmi důležitá. Samotná myšlenka komunikace aplikací však není nová a již řadu let (u některých i desetiletí) existují systémy jako IBM MQSeries, Microsoft MSMQ, BEA WebLogic, TIBCO Rendevous, Open Horizon Ambrosia. K těm mladším pak patří systémy SonicMQ a SonicXQ, iBus nebo FioranoMQ.

Myšlenka komunikace aplikací je velmi prostá: zaručit, že získaná data budou transformována do zprávy (message) a doručena příslušným aplikacím. Již z této věty můžeme usoudit, že komunikace aplikací realizovaná pomocí e-mailového systému stěží může garantovat doručení zpráv, natož další vlastnosti MOM, o kterých budeme dále hovořit. Realizace myšlenky komunikace aplikací je pak pochopitelně u různých dodavatelů MOM systémů různá. Dodavatelé MOM používají odlišná vývojová prostředí pro tvorbu messagingového API, různé formáty zpráv, různé síťové protokoly, různé modely směrování zpráv apod. Vzhledem k této různorodosti se nebude tento příspěvek zabývat proprietárními MOM systémy jednotlivých výrobců, ale zaměří se na jediný výchozí standard de facto - Java Message Service (JMS verze 1.0.2) a jeho komerční implementaci v podobě technologií SonicMQ a SonicXQ.

Hvězdicová Hub&Spoke architektura messagingového serveru SonicMQ

SonicMQ - implementace standardu JMS
Jako stěžejní koncept výměny zpráv (dat) mezi aplikacemi využívá JMS asynchronní výměnu zpráv (dokumentů). Znamená to, že zasílající aplikace není nucena čekat až danou zprávu druhá strana přijme nebo zpracuje. Asynchronní zprávy tvoří autonomní celistvé jednotky nesoucí v sobě kromě vlastních dat i veškeré další údaje (hlavičku, stavy, přílohy, vlastnosti) nutné pro její zpracování. Synchronní výměna zpráv, kdy zpracování na straně odesílajícího je blokováno do okamžiku obdržení odpovědi, je možná, ale netypická.

Zprávy zasílá a přijímá messagingový klient. Architektura SonicMQ se tedy skládá z vlastního message serveru a určitého počtu messagingových klientů. Messagingoví klienti zasílají zprávy SonicMQ message serveru, který je distribuuje ostatním oprávněným messagingovým klientům. Tento klient může být větší či menší aplikace nebo komponenta používající messagingové API.

SonicMQ představuje implementaci specifikace JMS vytvořenou ve 100% čisté Javě, což umožňuje nasazení všude tam, kde běží Java Virtual Machine. Obsahuje širokou paletu komunikačních nástrojů včetně podpory obou messagingových modelů point-to-point a publish-and-subscribe. Na dynamicky se měnící počet připojených messagingových klientů, front a topiků dokáže SonicMQ server reagovat téměř lineárně.

SonicMQ je samostatným produktem nesvázaným s žádným aplikačním serverem (AS) nebo databází (DB), což usnadňuje jeho nasazení i správu. Možnost jeho zakomponování do některého AS nebo DB však zůstává plně zachována (viz např. Borland aplikační server). Zprávy (dokumenty) jsou posílány na logická jména destinací (fronty, topiky), což velmi zpřehledňuje scénář výměny zpráv. Přesun messagingového serveru, změna IP adresy apod. tak nemají na stávající komunikaci žádný dopad.

Vestavěný mechanizmus "ulož a doruč" spolu s interním protokolem potvrzování zpráv garantuje 100% doručení veškerých zpráv, které procházejí SonicMQ serverem. Zprávy jsou ukládány buď do interní Java databáze nebo do databáze Progress, Oracle či MS SQL. Server také disponuje prostředky pro autentikaci, autorizaci (ACL) a zabezpečenou komunikaci (standardní 128 bitové SSL).

SonicXQ nachází uplatnění v architekturách orientovaných na poskytování služeb, umožňuje i definici životního cyklu zpráv/dokumentů (co vše se má se zprávou odehrát na cestě od odesílající k přijímající aplikaci); dynamické směrování zpráv/dokumentů je možné i na základě aktuálního obsahu zprávy

Formát XML a transakční zpracování
SonicMQ je zcela nezávislý na formátu přenášených zpráv (dokumentů). Formát XML je tedy jen jeden z mnoha možných. Zprávy se také dají seskupovat a zpracovávat v logických skupinách. Dokud není doručena i poslední zpráva, není možné jednotlivé zprávy zpracovávat. Tím je zaručena konzistence dat i v případě výpadku HW nebo dané aplikace.

Stejně jako je důležité mít přehled o zprávách doručených, tak neméně důležitý je pravý opak - mít přehled o zprávách, které se z různých důvodů nepodařilo doručit. SonicMQ obsahuje pro tyto účely zvláštní systémovou frontou mrtvých zpráv (Dead Message Queue), kterou lze prohlížet a vyhodnocovat. SonicMQ také umožňuje dynamicky přidávat nebo ubírat messagingové servery, sdružovat je do klastrů a významně tak zvyšovat výkonnost a odolnost dané instalace. Zabudovaná optimalizace směrování zpráv mezi klastry urychluje doručování zpráv a minimalizuje délku jejich cesty.

SonicXQ nahrazuje hvězdicovou architekturu Hub&Spoke a uplatňuje se jako univerzální podniková sběrnice služeb pro komunikaci aplikací

SonicXQ - integrace aplikací pomocí služeb
SonicXQ je nadstavbou messagingového serveru SonicMQ a tvoří rámec pro integraci rozmanitých aplikací a technologií v rozvětvené společnosti nebo složitých mezipodnikových vztazích. Přináší řešení pro implementaci, provoz a správu architektury založené na službách, messagingu a architektuře JCA (J2EE Connection Architecture). Propojování samostatných aplikací se tak zjednodušuje, a to i v případě, že jde o aplikace založené na různých jazycích a technologiích i architekturách, jako např. Java, C/C++, J2EE nebo Microsoft .NET. Firemní oddělení, divize a obchodní partneři mohou využívat rámec pro distribuované zpracování DPF (Distributed Processing Framework) a robustní messaging a s jejich pomocí spolehlivě, bezpečně a s dostatečnou rezervou sdílet softwarové služby a obchodní zprávy, jako např. objednávky, dodací listy, avíza nebo faktury.

Rámec pro distribuované zpracování spolu se službami pro transformaci dat a inteligentním směrováním odvozeným od obsahu umožňují dynamickou změnu ve scénáři výměny zpráv, aniž by bylo nutné cokoli programovat.

Pozn. red.: Autor článku působí jako Business Consultant ve společnosti Progress Software.