Zprávy XML, část 1

Zprávy XML představují rychle rostoucí a dynamickou oblast IT, což je situace, díky které je vzrušující a zároveň únavná. Jak B2B burzy a další formy mezioborové elektronické komunikace rostou, XML zprávy budou nasazeny více než kdy dříve.

Přečtěte si celou sérii „XML Messaging“:

• Část 1: Napište jednoduchého zprostředkovatele zpráv XML pro vlastní zprávy XML
• Část 2: Zprávy XML způsobem SOAP
• Část 3: JAXM a ebXML stanovily nový standard pro zasílání zpráv XML

V tomto článku nejprve prozkoumáme zasílání zpráv XML a proč je užitečné. Pak se ponoříme do konkrétních funkcí zasílání zpráv XML, včetně směrování zpráv, transformace a zprostředkování. Nakonec skončíme s jednoduchým příkladem zprostředkovatele XML. Po přečtení a pochopení konceptů byste měli jasně pochopit, které scénáře se hodí k implementaci řešení zasílání zpráv XML.

Co je zasílání zpráv XML?

Chcete-li zahájit náš průzkum, musíme pochopit základní premisu zasílání zpráv XML a jaký je termín zasílání zpráv naznačuje. Pro účely tohoto článku definuji zpráva jak následuje:

Soubor datových polí odeslaných nebo přijatých společně mezi softwarovými aplikacemi. Zpráva obsahuje záhlaví (které obsahuje řídicí informace o zprávě) a užitečné zatížení (skutečný obsah zprávy).

Messaging používá zprávy ke komunikaci s různými systémy k provádění nějaké funkce. Komunikaci označujeme jako orientovanou na zprávy, protože bychom odesílali a přijímali zprávy k provedení operace, na rozdíl od komunikace orientované na RPC (Remote Procedure Call). Může pomoci jednoduchá analogie: posílejte zprávy jako e-mail pro aplikace. Zprávy ve skutečnosti mají mnoho atributů, kdy si jednotlivci navzájem posílají e-mailové zprávy.

V minulosti, když jste používali nebo pracovali na systému orientovaném na zprávy, znamenalo to, že používáte nějaký druh produktu MOM (middleware orientovaný na zprávy) jako Tibco's Rendezvous, IBM MQSeries nebo poskytovatel JMS k odesílání zpráv v asynchronní (jednosměrný) způsob. Zprávy dnes nemusí nutně znamenat, že používáte produkt MOM, a to nutně neznamená, že komunikujete asynchronně. Spíše mohou být zprávy buď synchronní (obousměrné) nebo asynchronní a používat mnoho různých protokolů, jako je HTTP nebo SMTP, stejně jako produkty MOM.

Proč zasílání zpráv XML?

Proč byste chtěli vyvinout systém využívající zasílání zpráv? Proč je zasílání zpráv užitečnou konstrukční technikou a jaké jsou výhody? Jak již bylo zmíněno dříve, můžeme si vybrat ze dvou alternativ, když požadujeme, aby dvě aplikace spolu komunikovaly po síti: RPC nebo orientované na zprávy. Použití přístupu založeného na RPC (RMI spadá do této kategorie) znamená, že klient (nebo volající) volání procedury zná proceduru, kterou chce vyvolat, a zná parametry, které chce předat proceduře. Volající si také přeje počkat, až volaný server (aplikace) dokončí požadavek.

Ve druhém přístupu - orientovaném na zprávy - volající nemusí nutně znát přesný postup, který bude vyvolán, ale místo toho vytvoří zprávu konkrétního formátu známého klientovi i serveru. Klient vytvoří zprávu a poté ji odešle na server po síti. Klient tedy nezávisí na serveru ani na postupech serveru, ale je závislý na formátu zprávy. Komunikace pravděpodobně probíhá asynchronním způsobem, což znamená, že klient odešle požadavek, ale nebude čekat (blokovat) na odpověď. To umožňuje klientovi pokračovat v činnosti, i když se server stane nedostupným (například dojde k chybě). Tento design, kde je klient více nezávislý na serveru, je považován za více volně spojený.

Při hodnocení, zda použít design orientovaný na zprávy, je důležité pochopit výhody a nevýhody takového systému. Mezi výhody patří:

• Volné spojení
• Snadnější směrování a transformace zpráv
• Flexibilnější užitečné zatížení (může obsahovat například binární přílohy)
• K vyvolání dané procedury lze použít několik zpráv najednou

Obecně se ukazuje, že přístup orientovaný na zprávy je flexibilnější než přístup RPC.

Zde jsou některé nevýhody:

• Vyžaduje více práce na vývoji interakce klient / server pomocí přístupu orientovaného na zprávy ve srovnání s přístupem RPC, jako je RMI, protože vývoj interakce klient / server prostřednictvím zprávy představuje další úroveň nepřátelství z RPC. Složitost se přidává vytvořením zprávy na straně klienta (oproti vyvolání procedury v přístupu RPC) a na straně serveru s kódem pro zpracování zprávy. Kvůli jeho větší složitosti může být návrh orientovaný na zprávy obtížnější pochopit a ladit.
• Existuje riziko ztráty informací o typu programovacího jazyka, ve kterém byla zpráva odeslána. Například zdvojnásobení v Javě se nemusí ve zprávě překládat jako zdvojnásobení.
• Ve většině případů se transakční kontext, ve kterém byla zpráva vytvořena, nerozšíří na server zpráv.

Když vezmeme v úvahu výhody a nevýhody, kdy byste měli použít přístup orientovaný na zprávy? Nejběžnější scénář nastává, když komunikace klient / server probíhá přes internet a klient a server patří různým společnostem. V tomto scénáři by mohlo být docela obtížné, aby se obě společnosti dohodly na rozhraní postupu. Je také možné, že společnosti možná nebudou chtít používat stejný programovací jazyk. V jiném příkladu mohou zúčastněné společnosti chtít použít asynchronní komunikační model, takže ani jedna nebude záviset na tom, zda je aplikace druhého spuštěna.

Další atraktivní scénář zasílání zpráv nastává, když vyvíjíte systém založený na událostech, ve kterém jsou události vytvářeny a poté spotřebovávány zúčastněnými stranami. Většina grafických rozhraní je založena na událostech. Mohou například vytvořit událost kliknutí myší, při které zúčastněné strany událost poslouchají a na jejím základě provedou nějakou akci. V tomto scénáři vám použití přístupu k zasílání zpráv umožňuje odstranit závislost mezi událostí (nebo akcí v systému) a reakcí systému na událost, která se provádí na serveru.

Nyní, když trochu rozumíme zprávám, jsme připraveni přidat do rovnice XML. Přidání XML k zasílání zpráv znamená, že můžeme pro naše zprávy využívat flexibilní jazyk pro formátování dat. V zasílání zpráv se musí klient i server dohodnout na formátu zprávy. XML to usnadňuje rozhodováním o mnoha problémech s formátováním dat a přidáním dalších standardů XML, jako je Rosetta Net. Při navrhování formátu zprávy není potřeba žádná další práce.

Co dělá zprostředkovatel zpráv XML?

Zprostředkovatel zpráv funguje jako server v systému orientovaném na zprávy. Software pro zprostředkování zpráv provádí operace se zprávami, které přijímá. Mezi tyto operace patří:

• Zpracování záhlaví
• Bezpečnostní kontroly a šifrování / dešifrování
• Zpracování chyb a výjimek
• Směrování
• Vyvolání
• Proměna

Zpracování záhlaví

Zpracování záhlaví je obvykle jednou z prvních funkcí prováděných ve zprávě po jejím přijetí v rámci makléře XML. Zpracování záhlaví zahrnuje zkoumání polí záhlaví příchozích zpráv a provádění některých funkcí. Zpracování záhlaví může zahrnovat přidání sledovacího čísla k příchozí zprávě nebo zajištění toho, aby existovala všechna pole záhlaví nezbytná ke zpracování zprávy. V níže uvedené ukázkové zprávě XML mohl zprostředkovatel zpráv zkontrolovat na pole záhlaví, aby bylo zajištěno, že se jedná o správné místo určení této zprávy.

Bezpečnostní kontroly a šifrování / dešifrování

Z hlediska zabezpečení může zprostředkovatel zpráv provádět několik různých operací, ale s největší pravděpodobností budete chtít dosáhnout „velké trojky“ zabezpečení: autentizace, autorizace a šifrování. Nejprve, jakmile zjistí, že zpráva obsahuje data, která lze použít k ověření, zprostředkovatel zpráv ověří zprávy proti databázi zabezpečení nebo adresáři. Zadruhé, zprostředkovatel zpráv povolí operace, které lze provést s tímto typem zprávy a autorizovaným činitelem. Nakonec může být zpráva, která dorazí ke zprostředkovateli zpráv, zašifrována pomocí nějakého šifrovacího schématu. Zprostředkovatel bude odpovědný za dešifrování zprávy za účelem jejího dalšího zpracování.

Zpracování chyb a výjimek

Zpracování chyb a výjimek je další důležitá funkce prováděná zprostředkovatelem zpráv. Obecně bude zpráva reagovat na klienta (za předpokladu synchronního vyvolání) chybovou zprávou způsobenou, když zpráva odeslaná makléři neobsahuje dostatečné nebo přesné informace. Další příčina chyb nebo výjimek by nastala při obsluhování požadavku (ve skutečnosti vyvolání procedury / metody založené na užitečném obsahu zprávy).

Směrování

Směrování zpráv je větvení logiky pro zprávy. Vyskytuje se na dvou různých úrovních ve zprávě. První směrování na úrovni záhlaví určuje, zda je příchozí zpráva vázána pro tuto aplikaci nebo je třeba ji znovu odeslat do jiné aplikace. Druhé směrování užitečného zatížení určuje, který postup nebo metoda se má vyvolat, jakmile broker určí, že je zpráva vázána pro tuto aplikaci. Společně tyto dva typy směrování umožňují bohatou sadu funkcí při práci se zprávami.

Vyvolání

Vyvolání znamená skutečně zavolat nebo vyvolat metodu s daty (užitečné zatížení) obsažené v příchozí zprávě. To by mohlo vést k výsledku, který se poté vrátí prostřednictvím makléře zpět klientovi. To, co je vyvoláno, může být cokoli, včetně fazole relace EJB, metody třídy atd.

Proměna

Transformace převádí nebo mapuje zprávu do jiného formátu. S XML se XSLT běžně používá k provádění transformačních funkcí.

Příklad zprávy XML

Níže najdete zprávu XML použitou v následující ukázkové aplikaci. Všimněte si částí záhlaví a těla. V tomto příkladu je typ zprávy „saveInvoice“, ve kterém tělo obsahuje fakturu, kterou je třeba uložit.

   společnost Přijímač společnost Odesílatel uložit Faktura John Smith 123 George St. Mountain View CA 94041 Společnost A 100 Hlavní St. Washington DC 20015 Notebook IBM A20 1 2000,00 

Možná se divíte, zda existuje výhoda při vývoji vlastní zprávy XML. Proč nepoužít jeden ze stávajících standardů zpráv, jako je ebXML nebo SOAP, k zapouzdření užitečného zatížení (faktury)? Existuje několik důvodů. Prvním z nich je předvést část obsahu potřebného ve zprávě, aniž by bylo nutné složitě vysvětlovat plnohodnotný průmyslový standard. Zadruhé, ačkoli stávající standardy naplňují většinu potřeb, stále budou existovat scénáře, ve kterých použití vlastní zprávy lépe vyhoví potřebám situace, podobně jako kompromisy mezi použitím protokolu vyšší úrovně, jako je HTTP nebo SMTP, a použitím surových soketů.

Prototyp implementace zprostředkovatele XML

Po projednání důvodů pro použití návrhu zasílání zpráv ve vaší aplikaci nyní přistoupíme k implementaci prototypu zprostředkovatele zasílání zpráv XML.

Proč byste měli místo implementace stávajícího vyvíjet implementaci vlastního zprostředkovatele zpráv? Protože mnoho implementací pro produkty zasílání zpráv XML je nové, je důležité vědět, co jde do základní implementace. Je také možné, že protože zprostředkovatelé zpráv XML jsou poněkud nezralé produkty, budete muset vyvinout vlastní, abyste získali požadované funkce.

Zde prezentovaný základní zprostředkovatel může obsluhovat dva typy zpráv: požadavek na vytvoření faktury, který uloží do souborového systému, a komponenta kódu klienta, která pouze načte zprávu XML ze souboru a odešle ji.

Makléř se skládá ze tří hlavních částí: posluchače, který přijímá příchozí zprávy na nějakém transportu (v tomto příkladu bude k dispozici pouze implementace HTTP); hlavní makléřský kousek, který rozhodne, co dělat s příchozí zprávou; a část vyvolání, která na základě příchozí zprávy skutečně provede nějakou logiku. Podívejme se na každý podrobněji.

Přijměte zprávu z transportu

Zpráva se nejprve setká s částí posluchače makléře. Většina zprostředkovatelů zpráv XML poskytuje podporu pro mnoho různých transportů (protokolů), jako jsou HTTP, SMTP, JMS (implementace konkrétního dodavatele) atd. Náš makléř to umožňuje izolováním přepravní části. Dílo zobrazené níže jednoduše přijme zprávu na daném transportu, umístí příchozí zprávu do řetězcové proměnné a zavolá broker singleton: