Sporočila XML predstavljajo hitro rastoče, dinamično področje informacijske tehnologije, zaradi česar je hkrati vznemirljivo in dolgočasno. Z rastjo B2B izmenjav in drugih oblik medpodjetniške elektronske komunikacije bo sporočanje XML razširjeno bolj kot kdaj koli prej.
Preberite celotno serijo "Sporočila XML":
- 1. del: Napišite preprost posrednik sporočil XML za sporočila XML po meri
- 2. del: Sporočilo XML na način SOAP
- 3. del: JAXM in ebXML postavljata nov standard za sporočanje XML
V tem članku bomo najprej raziskali sporočanje XML in zakaj je to koristno. Nato se bomo poglobili v posebne funkcije sporočanja XML, vključno z usmerjanjem sporočil, preoblikovanjem in posredovanjem. Na koncu bomo zaključili s preprostim primerom posrednika XML. Ko preberete in razumete koncepte, morate jasno razumeti, kateri scenariji so primerni za izvajanje rešitve za sporočanje XML.
Kaj je sporočanje XML?
Za začetek našega raziskovanja moramo razumeti osnovno izhodišče sporočanja XML in kakšen izraz sporočanje pomeni. Za namene tega članka definiram sporočilo kot sledi:
Zbirka podatkovnih polj, poslanih ali prejetih med programskimi aplikacijami. Sporočilo vsebuje glavo (ki vsebuje nadzorne informacije o sporočilu) in koristni tovor (dejanska vsebina sporočila).Sporočila uporabljajo sporočila za komunikacijo z različnimi sistemi za izvajanje neke vrste funkcije. Komunikacijo označujemo kot usmerjeno v sporočila, ker bi za izvedbo operacije pošiljali in prejemali sporočila, v nasprotju s komunikacijo, usmerjeno v RPC (oddaljeni postopek). Preprosta analogija vam lahko pomaga: sporočanje si predstavljajte kot e-pošto za programe. Sporočila imajo dejansko številne lastnosti posameznikov, ki si medsebojno pošiljajo e-poštna sporočila.
V preteklosti, ko ste uporabljali ali delali v sistem, usmerjen v sporočila, je pomenilo, da uporabljate nekakšen izdelek MOM (vmesna programska oprema, usmerjena v sporočila), kot so Tibco's Rendezvous, IBM-ov MQSeries ali ponudnik JMS za pošiljanje sporočil v asinhrona (enosmerna) moda. Sporočila danes ne pomenijo nujno, da uporabljate izdelek MOM, in ne pomeni nujno, da komunicirate asinhrono. Sporočila so lahko sinhrona (dvosmerna) ali asinhrona in uporabljajo veliko različnih protokolov, kot sta HTTP ali SMTP, pa tudi izdelke MOM.
Zakaj sporočila XML?
Zakaj bi radi razvili sistem z uporabo sporočil? Zakaj je sporočanje uporabna tehnika oblikovanja in kakšne so prednosti? Kot smo že omenili, lahko izbiramo med dvema možnostma, kadar potrebujemo dve aplikaciji za medsebojni pogovor: RPC ali sporočilo usmerjeno. Uporaba pristopa, ki temelji na RPC (RMI spada v to kategorijo), pomeni, da odjemalec (ali klicatelj) klica postopka pozna postopek, ki ga želi poklicati, in pozna parametre, ki jih želi posredovati v postopek. Prav tako klicatelj želi počakati, da klicani strežnik (aplikacija) izpolni zahtevo.
Pri drugem pristopu - usmerjenem k sporočilu - klicatelj ne ve nujno natančnega postopka, ki bo poklican, ampak ustvari sporočilo določene oblike, ki je znana tako odjemalcu kot strežniku. Odjemalec ustvari sporočilo in ga nato pošlje strežniku prek omrežja. Zato odjemalec ni odvisen od strežnika ali strežnikovih postopkov, ampak je odvisen od oblike sporočila. Tudi komunikacija verjetno poteka asinhrono, kar pomeni, da bo stranka poslala zahtevo, vendar ne bo čakala (blokirala) na odgovor. To omogoča odjemalcu, da še naprej deluje, tudi če strežnik postane nedostopen (na primer zruši). Ta zasnova, kjer je odjemalec bolj neodvisen od strežnika, velja za bolj ohlapno povezano.
Pri ocenjevanju, ali uporabiti zasnovo, usmerjeno v sporočila, je pomembno razumeti prednosti in slabosti takega sistema. Prednosti vključujejo:
- Ohlapna sklopka
- Lažje usmerjanje in preoblikovanje sporočil
- Prožnejši tovor (lahko vključuje na primer binarne priloge)
- Za uporabo določenega postopka lahko skupaj uporabi več sporočil
Na splošno se sporočilo usmerjen pristop izkaže bolj prilagodljiv kot pristop RPC.
Zdaj je nekaj slabosti:
- Potrebno je več dela za razvoj interakcije odjemalec / strežnik z uporabo sporočilo usmerjenega pristopa v primerjavi s pristopom RPC, kot je RMI, ker razvoj interakcije odjemalec / strežnik prek sporočila predstavlja drugo stopnjo indirektnosti od RPC. Kompleksnost se doda z ustvarjanjem sporočila na strani odjemalca (v primerjavi s klicem postopka v pristopu RPC) in na strani strežnika s kodo za obdelavo sporočil. Zaradi dodatne zapletenosti je zasnovo, usmerjeno v sporočila, težje razumeti in odpraviti napake.
- Obstaja nevarnost izgube podatkov o vrsti za programski jezik, v katerem je bilo sporočilo poslano. Na primer, dvojnik v Javi se v sporočilu morda ne prevede kot dvojnik.
- V večini primerov se transakcijski kontekst, v katerem je bilo sporočilo ustvarjeno, ne širi na strežnik za sporočanje.
Glede na prednosti in slabosti, kdaj bi morali uporabiti pristop, usmerjen v sporočila? Najpogostejši scenarij se zgodi, ko komunikacija odjemalec / strežnik poteka prek interneta in če odjemalec in strežnik pripadata različnim podjetjem. V tem primeru bi bilo težko doseči, da bi se podjetji dogovorili o vmesniku postopka. Možno je tudi, da podjetja morda ne želijo uporabljati istega programskega jezika. V drugem primeru lahko sodelujoča podjetja želijo uporabiti asinhroni komunikacijski model, tako da nobeno od njih ne bo odvisno od tega, ali se aplikacija drugega izvaja.
Drug privlačen scenarij sporočanja se zgodi, ko razvijate sistem, ki temelji na dogodkih, v katerem dogodke ustvarijo in nato porabijo zainteresirane strani. Večina grafičnih uporabniških vmesnikov temelji na dogodkih. Na primer, lahko ustvarijo dogodek miške, v katerem zainteresirane stranke poslušajo dogodek in na podlagi njega izvedejo nekaj dejanj. V tem primeru lahko s pristopom sporočanja odstranite odvisnost med dogodkom (ali dejanjem v sistemu) in sistemsko reakcijo na dogodek, ki se izvede na strežniku.
Zdaj, ko malo razumemo sporočanje, smo v enačbo pripravljeni dodati XML. Dodajanje XML sporočilu pomeni, da lahko za svoja sporočila uporabimo prilagodljiv jezik za oblikovanje podatkov. Pri sporočanju se morata odjemalec in strežnik dogovoriti o obliki sporočila. XML to olajša z odločitvijo o številnih težavah s formatiranjem podatkov in z dodatki drugih standardov XML, kot je Rosetta Net. Za oblikovanje sporočila ni potrebno dodatno delo.
Kaj počne posrednik za sporočila XML?
Posrednik sporočil deluje kot strežnik v sistemu, usmerjenem v sporočila. Programska oprema za posrednike sporočil izvaja operacije nad prejetimi sporočili. Te operacije vključujejo:
- Obdelava glave
- Varnostni pregledi in šifriranje / dešifriranje
- Obravnavanje napak in izjem
- Usmerjanje
- Poklic
- Preobrazba
Obdelava glave
Obdelava glave je običajno ena od prvih funkcij, ki se izvede v sporočilu po prejemu v posredniku XML. Obdelava glave vključuje pregledovanje polj glave dohodnih sporočil in izvajanje nekaterih funkcij. Obdelava glave lahko vključuje dodajanje številke za sledenje dohodnemu sporočilu ali zagotavljanje, da obstajajo vsa polja glave, potrebna za obdelavo sporočila. V spodnjem primeru sporočila XML lahko posrednik sporočil preveri do polje glave, da zagotovite, da je to pravi cilj za to sporočilo.
Varnostni pregledi in šifriranje / dešifriranje
Z varnostnega vidika lahko posrednik sporočil izvede več različnih operacij, vendar boste najverjetneje želeli doseči "veliko trojko" varnosti: preverjanje pristnosti, avtorizacijo in šifriranje. Najprej, ko ugotovi, da sporočilo vsebuje podatke, ki jih je mogoče uporabiti za preverjanje pristnosti, posrednik sporočil preveri pristnost sporočil proti varnostni zbirki podatkov ali imeniku. Drugič, posrednik sporočil bo odobril operacije, ki jih je mogoče izvajati s to vrsto sporočil, in pooblaščeni naročnik. Na koncu je sporočilo, ki prispe na posrednika sporočil, morda šifrirano z neko shemo šifriranja. Odgovornost posrednika je, da sporočilo dešifrira, da bi ga nadalje obdelal.
Obravnavanje napak in izjem
Obravnavanje napak in izjem je še en pomemben del funkcionalnosti, ki ga izvaja posrednik sporočil. Na splošno se sporočilo odzove odjemalcu (ob predpostavki sinhronega klica) s sporočilom o napaki, ki nastane, če sporočilo, poslano posredniku, ne vsebuje zadostnih ali natančnih informacij. Drug vzrok za napake ali izjeme bi se pojavil pri servisiranju zahteve (dejansko sklicevanje na postopek / metodo, ki temelji na koristni obremenitvi sporočila).
Usmerjanje
Usmerjanje sporočil je logika razvejanja sporočil. Pojavi se na dveh različnih ravneh v sporočilu. Prvo usmerjanje na ravni glave določa, ali je dohodno sporočilo vezano za to aplikacijo ali jo je treba znova poslati drugi aplikaciji. Drugi, usmerjanje koristnega tovora, določa, kateri postopek ali metodo uporabiti, ko posrednik ugotovi, da je sporočilo vezano za to aplikacijo. Ti dve vrsti usmerjanja skupaj omogočata bogat nabor funkcionalnosti pri obravnavi sporočil.
Poklic
Priklic pomeni dejansko poklic ali priklic metode s podatki (koristnim tovorom), ki jih vsebuje dohodno sporočilo. To bi lahko povzročilo rezultat, ki se nato prek posrednika vrne stranki. Prikliče se lahko karkoli, vključno z zrnom seje EJB, metodo razreda itd.
Preobrazba
Transformacija pretvori ali preslika sporočilo v drugo obliko. Z XML se XSLT pogosto uporablja za izvajanje funkcij preoblikovanja.
Primer sporočila XML
Spodaj boste našli sporočilo XML, ki se uporablja v vzorčni aplikaciji, ki sledi. Opazite glavo in dele telesa. Ta primer je vrsta sporočila "saveInvoice", v katerem telo vsebuje račun, ki ga je treba shraniti.
podjetjePrejemnik podjetjeSender saveRačun John Smith 123 George St. Mountain View CA 94041 Company A 100 Main St. Washington DC 20015 IBM A20 Laptop 1 2000,00
Sprašujete se, ali je razvijanje sporočila XML po meri prednost. Zakaj ne bi uporabili enega od obstoječih standardov sporočil, kot sta ebXML ali SOAP, za vključitev koristnega tovora (računa)? Obstaja nekaj razlogov. Prvi je prikazati nekatere vsebine, ki so potrebne v sporočilu, ne da bi bilo treba založiti v celoti razložen industrijski standard. Drugič, čeprav obstoječi standardi izpolnjujejo večino potreb, bodo še vedno obstajali scenariji, v katerih bo uporaba sporočila po meri bolje ustrezala potrebam situacije, podobno kot kompromisi med uporabo protokola višje ravni, kot sta HTTP ali SMTP, in uporabo surovih vtičnic.
Izvedba prototipa posrednika XML
Potem ko smo razpravljali o razlogih za uporabo zasnove sporočil v vaši aplikaciji, bomo zdaj nadaljevali s prototipom implementacije posrednika sporočil XML.
Zakaj bi morali razviti izvajanje posrednika sporočil po meri, namesto da bi uporabili obstoječega? No, ker so številne izvedbe izdelkov za sporočanje XML nove, zato je pomembno vedeti, kaj gre za osnovno izvedbo. Prav tako je mogoče, da so posredniki sporočil XML nekoliko nezreli izdelki, zato jih boste morali razviti, da boste dobili želene funkcije.
Tu predstavljeni osnovni posrednik lahko servisira dve vrsti sporočil: zahtevo za izdelavo računa, ki ga shrani v datotečni sistem, in komponento odjemalske kode, ki samo prebere sporočilo XML iz datoteke in ga pošlje.
Posrednik je sestavljen iz treh glavnih delov: poslušalca, ki sprejema dohodna sporočila na nekem prevozu (v tem primeru je na voljo le izvedba HTTP); glavni posredniški del, ki se bo odločil, kaj storiti s prihajajočim sporočilom; in priklicni del, ki bo dejansko izvedel neko logiko na podlagi dohodnega sporočila. Oglejmo si vsako podrobneje.
Prejmite sporočilo od prevoza
Sporočilo bo najprej naletelo na del poslušalca posrednika. Večina posrednikov sporočil XML nudi podporo za številne različne transporte (protokole), kot so HTTP, SMTP, JMS (izvedba določenega prodajalca) itd. Naš posrednik to omogoča tako, da izolira transportni del. Spodnji del preprosto sprejme sporočilo na danem prevozu, dohodno sporočilo postavi v spremenljivko niza in pokliče posrednika posrednika:
