Správy XML predstavujú rýchlo sa rozvíjajúcu a dynamickú oblasť IT, čo ju robí vzrušujúcou a únavnou súčasne. Ako budú výmeny B2B a ďalšie formy medzipodnikovej elektronickej komunikácie narastať, bude sa zasielanie správ XML rozširovať viac ako kedykoľvek predtým.
Prečítajte si celú sériu „XML správ“:
- Časť 1: Napíšte jednoduchý sprostredkovateľ správ XML pre vlastné správy XML
- Časť 2: Správy XML spôsobom SOAP
- Časť 3: JAXM a ebXML stanovili nový štandard pre zasielanie správ XML
V tomto článku najskôr preskúmame správy XML a ich užitočné informácie. Potom sa pozrieme na konkrétne funkcie zasielania správ XML, vrátane smerovania, transformácie a sprostredkovania správ. Nakoniec skončíme na jednoduchom príklade sprostredkovateľa XML. Po prečítaní a pochopení pojmov by ste mali jasne pochopiť, ktoré scenáre sa dajú implementovať do riešenia správ XML.
Čo je zasielanie správ XML?
Aby sme mohli začať s našim prieskumom, musíme porozumieť základnému predpokladu správy XML a termínu zasielanie správ naznačuje. Na účely tohto článku definujem správa nasledovne:
Zbierka dátových polí odoslaných alebo prijatých spoločne medzi softvérovými aplikáciami. Správa obsahuje hlavičku (ktorá obsahuje kontrolné informácie o správe) a užitočné zaťaženie (skutočný obsah správy).Správy používajú správy na komunikáciu s rôznymi systémami na vykonávanie niektorých funkcií. O komunikácii hovoríme, že je orientovaná na správy, pretože by sme na rozdiel od komunikácie orientovanej na RPC (Remote Procedure Call), odosielali a prijímali správy na vykonanie operácie. Pomôcť môže jednoduchá analógia: pod správami si správy predstavujte ako e-mail pre aplikácie. Zasielanie správ má v skutočnosti veľa atribútov osôb, ktoré si navzájom posielajú e-mailové správy.
V minulosti, keď ste používali alebo pracovali na systéme orientovanom na správy, znamenalo to, že ste na posielanie správ používali nejaký produkt MOM (middleware orientovaný na správy) ako Tibco's Rendezvous, IBM MQSeries alebo poskytovateľ JMS. asynchrónny (jednosmerný) spôsob. Dnešné správy nemusia nevyhnutne znamenať, že používate produkt MOM, a to nevyhnutne neznamená, že komunikujete asynchrónne. Správy môžu byť skôr synchrónne (obojsmerné) alebo asynchrónne a môžu používať veľa rôznych protokolov, napríklad HTTP alebo SMTP, ako aj produkty MOM.
Prečo zasielanie správ XML?
Prečo by ste chceli vyvinúť systém pomocou správ? Vďaka čomu je zasielanie správ užitočnou technikou návrhu a aké sú výhody? Ako už bolo spomenuté vyššie, môžeme si vybrať z dvoch alternatív, keď požadujeme, aby dve aplikácie spolu komunikovali po sieti: RPC alebo správa. Použitie prístupu založeného na RPC (RMI spadá do tejto kategórie) znamená, že klient (alebo volajúci) volania procedúry pozná procedúru, ktorú chce vyvolať, a pozná parametre, ktoré chce procedúre odovzdať. Volajúci si tiež želá počkať, kým volaný server (aplikácia) dokončí požiadavku.
V druhom prístupe - orientovanom na správy - volajúci nemusí nevyhnutne poznať presný postup, ktorý bude vyvolaný, ale vytvorí správu v špecifickom formáte, ktorý pozná klient aj server. Klient vytvorí správu a potom ju pošle na server cez sieť. Klient teda nezávisí od servera ani od postupov servera, ale závisí od formátu správy. Komunikácia tiež pravdepodobne prebieha asynchrónnym spôsobom, čo znamená, že klient pošle žiadosť, ale nebude čakať (blokovať) na odpoveď. Toto umožňuje klientovi pokračovať v činnosti, aj keď je server nedostupný (napríklad zlyhanie). Tento dizajn, kde je klient nezávislejší od servera, sa považuje za voľnejšie prepojený.
Pri hodnotení, či sa má použiť dizajn zameraný na správy, je dôležité pochopiť výhody a nevýhody takéhoto systému. Medzi výhody patria:
- Voľné spojenie
- Ľahšie smerovanie a transformácia správ
- Flexibilnejšie užitočné zaťaženie (môže obsahovať napríklad binárne prílohy)
- Na vyvolanie daného postupu môže byť použitých niekoľko správ naraz
Všeobecne sa ukazuje, že prístup zameraný na správy je flexibilnejší ako prístup RPC.
Tu je niekoľko nevýhod:
- Vyžaduje si viac práce na rozvinutie interakcie klient / server pomocou prístupu orientovaného na správu v porovnaní s prístupom RPC, ako je RMI, pretože vývoj interakcie klient / server prostredníctvom správy predstavuje ďalšiu úroveň nepriamosti z RPC. Zložitosť sa pridáva vytvorením správy na strane klienta (v porovnaní s vyvolaním procedúry v prístupe RPC) a na strane servera s kódom na spracovanie správy. Vďaka svojej pridanej zložitosti môže byť návrh orientovaný na správy ťažšie pochopiteľný a laditeľný.
- Existuje riziko straty typových informácií pre programovací jazyk, v ktorom bola správa odoslaná. Napríklad zdvojnásobenie v jazyku Java nemusí preložiť ako zdvojnásobenie v správe.
- Vo väčšine prípadov sa transakčný kontext, v ktorom bola správa vytvorená, nerozšíri na server správ.
Keď vezmeme do úvahy klady a zápory, kedy by ste mali použiť prístup orientovaný na správy? Najbežnejší scenár nastáva, keď komunikácia klient / server prebieha cez internet a klient a server patria iným spoločnostiam. V tomto scenári by mohlo byť dosť ťažké dosiahnuť, aby sa obe spoločnosti dohodli na rozhraní postupu. Je tiež možné, že spoločnosti možno nebudú chcieť používať rovnaký programovací jazyk. V ďalšom príklade môžu príslušné spoločnosti chcieť použiť asynchrónny komunikačný model, takže žiadna z nich nebude závisieť od fungovania druhej aplikácie.
Ďalším atraktívnym scenárom zasielania správ je, keď vyvíjate systém založený na udalostiach, v ktorom udalosti vytvárajú a potom spotrebúvajú zainteresované strany. Väčšina grafických používateľských rozhraní je založená na udalostiach. Môžu napríklad vytvoriť udalosť kliknutia myšou, v ktorej zainteresované strany udalosť vypočujú a na základe nej vykonajú určitú akciu. V tomto scenári vám použitie prístupu k zasielaniu správ umožňuje odstrániť závislosť medzi udalosťou (alebo akciou v systéme) a reakciou systému na udalosť, ktorá sa vykoná na serveri.
Teraz, keď už trochu rozumieme zasielaniu správ, sme pripravení pridať do rovnice XML. Pridanie XML do správ znamená, že môžeme pre naše správy využívať flexibilný jazyk na formátovanie údajov. Pri zasielaní správ sa klient aj server musia dohodnúť na formáte správy. XML to uľahčuje rozhodovaním o mnohých problémoch s formátovaním údajov a pridaním ďalších štandardov XML, napríklad Rosetta Net. Pri navrhovaní formátu správy nie sú potrebné žiadne ďalšie práce.
Čo robí sprostredkovateľ správ XML?
Sprostredkovateľ správ funguje ako server v systéme orientovanom na správy. Softvér na sprostredkovanie správ vykonáva operácie so správami, ktoré prijíma. Medzi tieto operácie patrí:
- Spracovanie hlavičky
- Bezpečnostné kontroly a šifrovanie / dešifrovanie
- Spracovanie chýb a výnimiek
- Smerovanie
- Vyvolanie
- Transformácia
Spracovanie hlavičky
Spracovanie hlavičiek je zvyčajne jednou z prvých funkcií vykonávaných v správe po jej prijatí v rámci sprostredkovateľa XML. Spracovanie hlavičiek zahŕňa preskúmanie polí hlavičiek prichádzajúcich správ a vykonávanie niektorých funkcií. Spracovanie hlavičky môže zahŕňať pridanie sledovacieho čísla k prichádzajúcej správe alebo zabezpečenie existencie všetkých polí hlavičky potrebných na spracovanie správy. V príklade správy XML nižšie môže sprostredkovateľ správ skontrolovať do do poľa hlavičky, aby ste sa uistili, že toto je správne miesto určenia pre túto správu.
Bezpečnostné kontroly a šifrovanie / dešifrovanie
Z bezpečnostného hľadiska môže sprostredkovateľ správ vykonávať niekoľko rôznych operácií, ale s najväčšou pravdepodobnosťou budete chcieť dosiahnuť „veľkú trojku“ zabezpečenia: autentifikáciu, autorizáciu a šifrovanie. Najskôr, akonáhle zistí, že správa obsahuje údaje, ktoré sa dajú použiť na autentifikáciu, sprostredkovateľ správy autentifikuje správy proti bezpečnostnej databáze alebo adresáru. Po druhé, sprostredkovateľ správ povolí operácie, ktoré je možné vykonať s týmto typom správy a autorizovaným príkazcom. Nakoniec môže byť správa, ktorá dorazí k sprostredkovateľovi správ, zašifrovaná pomocou nejakej šifrovacej schémy. Za dešifrovanie správy za účelom jej ďalšieho spracovania bude zodpovedný sprostredkovateľ.
Spracovanie chýb a výnimiek
Spracovanie chýb a výnimiek je ďalšou dôležitou funkciou, ktorú vykonáva sprostredkovateľ správ. Správa vo všeobecnosti odpovie klientovi (za predpokladu synchrónneho vyvolania) chybovým hlásením, ktoré vznikne, keď správa odoslaná sprostredkovateľovi nebude obsahovať dostatočné alebo presné informácie. Ďalšia príčina chýb alebo výnimiek by nastala pri obsluhe požiadavky (skutočné vyvolanie procedúry / metódy založenej na užitočnej záťaži správy).
Smerovanie
Smerovanie správ je vetvenie logiky správ. Vyskytuje sa na správe na dvoch rôznych úrovniach. Prvé smerovanie na úrovni hlavičky určuje, či je prichádzajúca správa viazaná na túto aplikáciu alebo musí byť odoslaná do inej aplikácie. Druhá, smerovanie užitočného zaťaženia, určuje, ktorý postup alebo metóda sa má vyvolať, akonáhle sprostredkovateľ určí, že správa je viazaná na túto aplikáciu. Spoločne tieto dva typy smerovania umožňujú bohatú sadu funkcií pri práci so správami.
Vyvolanie
Vyvolanie znamená skutočné vyvolanie alebo vyvolanie metódy s údajmi (užitočné zaťaženie) obsiahnutými v prichádzajúcej správe. To by mohlo viesť k výsledku, ktorý sa potom vráti sprostredkovateľovi späť klientovi. Vyvoláva sa môže byť čokoľvek, vrátane fazule EJB Session, metódy triedy atď.
Transformácia
Transformácia prevádza alebo mapuje správu do iného formátu. S XML sa XSLT bežne používa na vykonávanie transformačných funkcií.
Príklad správy XML
Ďalej nájdete správu XML použitú vo vzorovej aplikácii, ktorá nasleduje. Všimnite si časti hlavičky a tela. Tento príklad je správou typu „saveInvoice“, v ktorej telo obsahuje faktúru, ktorú je potrebné uložiť.
spoločnosťPríjemca spoločnostiSender save saveFaktúra John Smith 123 George St. Mountain View CA 94041 Spoločnosť A 100 Main St. Washington DC 20015 IBM A20 Laptop 1 2000,00
Možno by vás zaujímalo, či je výhodné vyvinúť vlastnú správu XML. Prečo na zapuzdrenie užitočného zaťaženia (faktúry) nevyužiť jeden z existujúcich štandardov správ, ako je ebXML alebo SOAP? Existuje niekoľko dôvodov. Prvým z nich je preukázanie časti obsahu potrebného v správe bez toho, aby bolo potrebné vysvetliť komplexný priemyselný štandard. Po druhé, hoci existujúce štandardy uspokojujú väčšinu potrieb, stále budú existovať scenáre, v ktorých použitie vlastnej správy lepšie vyhovie potrebám situácie, podobne ako kompromisy medzi používaním protokolu vyššej úrovne, ako je HTTP alebo SMTP, a použitím nespracovaných zásuviek.
Prototyp implementácie sprostredkovateľa XML
Po diskusii o dôvodoch použitia návrhu zasielania správ vo vašej aplikácii teraz prejdeme k implementácii prototypu sprostredkovateľa zasielania správ XML.
Prečo by ste mali vyvinúť implementáciu vlastného sprostredkovateľa správ namiesto použitia existujúcej? Pretože veľa implementácií pre produkty na zasielanie správ XML je nové, je dôležité vedieť, čo sa týka základnej implementácie. Je tiež možné, že pretože sprostredkovatelia správ XML sú trochu nezrelé produkty, budete musieť vyvinúť svoje vlastné, aby ste získali požadované funkcie.
Tu uvedený základný sprostredkovateľ môže obsluhovať dva typy správ: požiadavku na vytvorenie faktúry, ktorú uloží do súborového systému, a komponent kódu klienta, ktorý iba načíta správu XML zo súboru a odošle ju.
Sprostredkovateľ sa skladá z troch hlavných častí: poslucháča, ktorý prijíma prichádzajúce správy na nejakom prenose (v tomto príklade bude poskytnutá iba implementácia HTTP); hlavný sprostredkovateľ, ktorý rozhodne, čo s prichádzajúcou správou; a časť vyvolania, ktorá na základe prichádzajúcej správy skutočne vykoná určitú logiku. Pozrime sa na každú podrobnejšie.
Prijať správu z prepravy
Správa sa najskôr stretne s časťou poslucháča sprostredkovateľa. Väčšina sprostredkovateľov správ XML poskytuje podporu pre mnoho rôznych prenosov (protokolov), ako sú HTTP, SMTP, JMS (implementácia konkrétneho dodávateľa) atď. Náš sprostredkovateľ to umožňuje izolovaním prepravnej časti. Kus uvedený nižšie jednoducho prijme správu na danom transporte, umiestni prichádzajúcu správu do premennej reťazca a zavolá sprostredkovateľa singleton:
