XML ziņojumapmaiņa ir strauji augoša, dinamiska IT joma, kas padara to vienlaikus aizraujošu un nogurdinošu. Pieaugot B2B apmaiņai un citiem starpvalstu elektronisko sakaru veidiem, XML ziņojumapmaiņa tiks izmantota plašāk nekā jebkad agrāk.
Izlasiet visu "XML Messaging" sēriju:
- 1. daļa: Uzrakstiet vienkāršu XML ziņojumu starpnieku pielāgotiem XML ziņojumiem
- 2. daļa: XML ziņojumapmaiņa SOAP veidā
- 3. daļa: JAXM un ebXML nosaka jaunu XML ziņojumapmaiņas standartu
Šajā rakstā mēs vispirms izpētīsim XML ziņojumapmaiņu un to, kāpēc tā ir noderīga. Tad mēs iedziļināsimies īpašās XML ziņojumapmaiņas funkcijās, ieskaitot ziņojumu maršrutēšanu, pārveidošanu un starpniecību. Visbeidzot, mēs pabeigsim vienkāršu XML brokera piemēru. Pēc jēdzienu izlasīšanas un izpratnes jums ir skaidri jāsaprot, kuri scenāriji ir piemēroti XML ziņojumapmaiņas risinājuma ieviešanai.
Kas ir XML ziņojumapmaiņa?
Lai sāktu izpēti, mums ir jāsaprot XML ziņojumapmaiņas pamatnosacījums un termins ziņojumapmaiņa nozīmē. Šī raksta vajadzībām es definēju ziņu sekojoši:
Datu lauku kolekcija, kas kopā nosūtīta vai saņemta starp lietojumprogrammām. Ziņojums satur galveni (kurā glabājas vadības informācija par ziņojumu) un lietderīgo kravu (faktiskais ziņojuma saturs).Ziņapmaiņa izmanto ziņojumus, lai sazinātos ar dažādām sistēmām, lai veiktu sava veida funkcijas. Mēs uzskatām, ka komunikācija ir orientēta uz ziņojumu, jo operācijas veikšanai mēs sūtīsim un saņemsim ziņojumus, atšķirībā no RPC (attālās procedūras zvana) orientētas komunikācijas. Var palīdzēt vienkārša līdzība: domājiet par ziņojumapmaiņu kā par e-pastu lietojumprogrammām. Patiešām, ziņojumapmaiņai piemīt daudzi to personu atribūti, kas viens otram sūta e-pasta ziņojumus.
Agrāk, kad izmantojāt uz ziņām orientētu sistēmu vai strādājāt ar to, tas nozīmēja, ka, lai nosūtītu ziņojumus, izmantojot kādu MOM (uz ziņām orientētu starpprogrammatūru) produktu, piemēram, Tibco Rendezvous, IBM MQSeries vai JMS nodrošinātāju asinhronā (vienvirziena) mode. Ziņapmaiņa šodien nenozīmē, ka jūs izmantojat MOM produktu, un tas nenozīmē, ka sazināties asinhroni. Drīzāk ziņojumapmaiņa var būt vai nu sinhrona (divvirzienu), vai asinhrona, un tajā var izmantot daudz dažādu protokolu, piemēram, HTTP vai SMTP, kā arī MOM produktus.
Kāpēc XML ziņojumapmaiņa?
Kāpēc jūs vēlaties izveidot sistēmu, izmantojot ziņojumapmaiņu? Kas ziņapmaiņu padara par noderīgu dizaina tehniku un kādas ir tās priekšrocības? Kā minēts iepriekš, mēs varam izvēlēties divas alternatīvas, kad divām lietojumprogrammām ir jārunā savā starpā tīklā: RPC vai orientēta uz ziņojumu. Izmantojot RPC balstītu pieeju (RMI ietilpst šajā kategorijā), tas nozīmē, ka procedūras izsaukuma klients (vai zvanītājs) zina procedūru, kuru vēlas izsaukt, un zina parametrus, kurus vēlas nodot procedūrai. Arī zvanītājs vēlas gaidīt, kamēr izsauktais serveris (lietojumprogramma) izpilda pieprasījumu.
Otrajā pieejā - orientēta uz ziņojumu - zvanītājs ne vienmēr zina precīzu procedūru, kas tiks izsaukta, bet tā vietā izveido konkrēta formāta ziņojumu, kas zināms gan klientam, gan serverim. Klients izveido ziņojumu un pēc tam to tīklā nosūta serverim. Tāpēc klients nav atkarīgs no servera vai servera procedūrām, bet ir atkarīgs no ziņojuma formāta. Arī saziņa, visticamāk, notiek asinhronā veidā, kas nozīmē, ka klients nosūtīs pieprasījumu, bet negaidīs (bloķēs) atbildi. Tas ļauj klientam turpināt darboties pat tad, ja serveris vairs nav pieejams (piemēram, avarē). Šis dizains, kurā klients ir vairāk neatkarīgs no servera, tiek uzskatīts par brīvāk savienotu.
Izvērtējot, vai izmantot uz ziņojumu orientētu dizainu, ir svarīgi saprast šādas sistēmas plusus un mīnusus. Plusi ietver:
- Brīva sakabe
- Vieglāka ziņojumu maršrutēšana un pārveidošana
- Elastīgāka krava (var ietvert, piemēram, bināros pielikumus)
- Var izmantot vairākus ziņojumus kopā, lai izsauktu noteiktu procedūru
Parasti uz ziņām orientēta pieeja izrādās elastīgāka nekā RPC pieeja.
Tagad šeit ir daži mīnusi:
- Lai izstrādātu klienta / servera mijiedarbību, izmantojot uz ziņām orientētu pieeju, ir nepieciešams vairāk darba, salīdzinot ar RPC pieeju, piemēram, RMI, jo klienta / servera mijiedarbības attīstīšana, izmantojot ziņojumu, norāda citu RPC nenovirzīšanas līmeni. Sarežģītība tiek pievienota, izveidojot ziņojumu klienta pusē (pretēji procedūras izsaukumam RPC pieejā) un servera pusē ar ziņojumu apstrādes kodu. Tā kā tā ir sarežģītāka, uz ziņojumu orientētu dizainu var būt grūtāk saprast un atkļūdot.
- Pastāv risks zaudēt informāciju par programmēšanas valodu, kurā tika nosūtīts ziņojums. Piemēram, Java dubultojums ziņojumā var netulkot kā dubultu.
- Vairumā gadījumu darījumu konteksts, kurā ziņojums tika izveidots, netiek izplatīts ziņojumapmaiņas serverī.
Ņemot vērā plusus un mīnusus, kad jums vajadzētu izmantot uz ziņām orientētu pieeju? Visizplatītākais scenārijs rodas, ja klienta / servera saziņa notiek internetā un klients un serveris pieder dažādiem uzņēmumiem. Šajā scenārijā varētu būt diezgan grūti panākt, lai abi uzņēmumi vienotos par procedūru saskarni. Tāpat ir iespējams, ka uzņēmumi, iespējams, nevēlas izmantot vienu un to pašu programmēšanas valodu. Citā piemērā iesaistītie uzņēmumi var vēlēties izmantot asinhrono komunikācijas modeli tā, lai neviens no tiem nebūtu atkarīgs no otra lietojumprogrammas darbības un darbības.
Vēl viens pievilcīgs ziņojumapmaiņas scenārijs rodas, izstrādājot uz notikumiem balstītu sistēmu, kurā notikumus izveido un pēc tam patērē ieinteresētās puses. Lielākā daļa GUI ir balstītas uz notikumiem. Piemēram, viņi var izveidot notikumu ar peles klikšķi, kurā ieinteresētās puses klausās notikumu un uz tā pamata veic kādu darbību. Šajā scenārijā ziņojumapmaiņas pieejas izmantošana ļauj noņemt atkarību starp notikumu (vai darbību sistēmā) un sistēmas reakciju uz notikumu, kas tiek veikts serverī.
Tagad, kad mēs mazliet saprotam ziņojumapmaiņu, esam gatavi vienādojumam pievienot XML. XML pievienošana ziņojumapmaiņai nozīmē, ka mēs saviem ziņojumiem varam izmantot elastīgu datu formatēšanas valodu. Ziņapmaiņā gan klientam, gan serverim ir jāvienojas par ziņojuma formātu. XML to atvieglo, izlemjot daudzus datu formatēšanas jautājumus un pievienojot citus XML standartus, piemēram, Rosetta Net. Lai izveidotu ziņojuma formātu, nav nepieciešams papildu darbs.
Ko dara XML ziņojumu starpnieks?
Ziņojumu starpnieks darbojas kā serveris uz ziņojumu orientētā sistēmā. Ziņojumu starpnieka programmatūra veic darbības ar saņemtajiem ziņojumiem. Šīs darbības ietver:
- Galvenes apstrāde
- Drošības pārbaudes un šifrēšana / atšifrēšana
- Kļūdu un izņēmumu apstrāde
- Maršrutēšana
- Uzaicinājums
- Pārvērtības
Galvenes apstrāde
Galvenes apstrāde parasti ir viena no pirmajām funkcijām, kas tiek veiktas ziņojumā pēc tās saņemšanas XML brokerī. Galvenes apstrāde ietver ienākošo ziņojumu galvenes lauku pārbaudi un dažu funkciju veikšanu. Galvenes apstrāde var ietvert izsekošanas numura pievienošanu ienākošajam ziņojumam vai pārliecināšanos, ka visi galvenes lauki, kas nepieciešami ziņojuma apstrādei, pastāv. Zemāk esošajā XML ziņojuma piemērā ziņojumu starpnieks varētu pārbaudīt uz galvenes lauku, lai pārliecinātos, ka tas ir pareizs šī ziņojuma galamērķis.
Drošības pārbaudes un šifrēšana / atšifrēšana
Raugoties no drošības viedokļa, ziņojumu starpnieks var veikt vairākas dažādas darbības, taču, visticamāk, jūs vēlēsities veikt drošības "lielo trīs": autentifikāciju, autorizāciju un šifrēšanu. Pirmkārt, tiklīdz ir noteikts, ka ziņojumā ir dati, kurus var izmantot autentifikācijai, ziņojumu starpnieks autentificēs ziņojumus, izmantojot drošības datu bāzi vai direktoriju. Otrkārt, ziņojumu starpnieks autorizēs darbības, kuras var veikt ar šāda veida ziņām un pilnvarotu principālu. Visbeidzot, ziņojums, kas pienāk pie ziņu starpnieka, var tikt šifrēts, izmantojot kādu šifrēšanas shēmu. Brokera pienākums būs atšifrēt ziņojumu, lai to tālāk apstrādātu.
Kļūdu un izņēmumu apstrāde
Kļūdu un izņēmumu apstrāde ir vēl viena svarīga funkcionalitāte, ko veic ziņojumu starpnieks. Parasti ziņojums klientam (pieņemot sinhronu izsaukumu) atbildēs ar kļūdas ziņojumu, kas rodas, ja brokerim nosūtītajā ziņojumā nav pietiekamas vai precīzas informācijas. Apkalpojot pieprasījumu, varētu rasties vēl viens kļūdu vai izņēmumu cēlonis (faktiski tiek izsaukta procedūra / metode, kuras pamatā ir ziņojuma lietderīgā slodze).
Maršrutēšana
Ziņojumu maršrutēšana ir sazarota loģika ziņojumiem. Tas notiek divos dažādos ziņojuma līmeņos. Pirmais, galvenes līmeņa maršrutēšana nosaka, vai ienākošais ziņojums ir saistīts ar šo lietojumprogrammu, vai tas ir jānosūta citai lietojumprogrammai. Otrais - lietderīgās slodzes maršrutēšana - nosaka, kuru procedūru vai metodi izsaukt, tiklīdz brokeris nosaka, ka ziņojums ir saistīts ar šo lietojumprogrammu. Šie abi maršrutēšanas veidi kopā nodrošina bagātīgu funkcionalitāti, strādājot ar ziņojumiem.
Uzaicinājums
Uzaicināšana nozīmē faktiski piezvanīt vai izsaukt metodi ar datiem (lietderīgo slodzi), kas ietverti ienākošajā ziņojumā. Tas varētu radīt rezultātu, kas pēc tam ar brokera starpniecību tiek atgriezts klientam. To var izmantot jebko, ieskaitot EJB sesijas pupiņu, klases metodi utt.
Pārvērtības
Transformācija pārveido vai kartē ziņojumu kādā citā formātā. Izmantojot XML, XSLT parasti izmanto, lai veiktu transformācijas funkcionalitāti.
XML ziņojuma piemērs
Zemāk jūs atradīsit XML ziņojumu, kas tiek izmantots sekojošajā parauga lietojumprogrammā. Ievērojiet galvenes un ķermeņa daļas. Šis piemērs ir "saveInvoice" veida ziņojums, kurā pamattekstā ir rēķins, kas jāsaglabā.
kompānijaIzņēmēja uzņēmumsSūtītāja saglabāšana Rēķins Džons Smits 123 Džordža Sentkalna View, CA 94041 Uzņēmums A 100 Main St Washington, DC 20015 IBM A20 Laptop 1 2000.00
Jums var rasties jautājums, vai pielāgotu XML ziņojumu izstrādei ir kāda priekšrocība. Kāpēc neizmantot kādu no esošajiem ziņojumu standartiem, piemēram, ebXML vai SOAP, lai iekapsulētu lietderīgo kravu (rēķinu)? Ir vairāki iemesli. Pirmais ir parādīt daļu no ziņojumā nepieciešamā satura, pilnībā izskaidrojot pilnvērtīgu nozares standartu. Otrkārt, lai arī esošie standarti aizpilda lielāko daļu vajadzību, joprojām būs scenāriji, kuros pielāgota ziņojuma izmantošana labāk atbilst situācijas vajadzībām, līdzīgi kā kompromisi starp augstāka līmeņa protokola, piemēram, HTTP vai SMTP, izmantošanu un neapstrādātu ligzdu izmantošanu.
XML brokera prototipa ieviešana
Apsprieduši ziņojumapmaiņas dizaina izmantošanas iemeslus jūsu lietojumprogrammā, tagad mēs turpināsim ieviest XML ziņojumapmaiņas starpnieka prototipu.
Kāpēc jums vajadzētu izstrādāt pielāgotu ziņojumu starpnieka ieviešanu, nevis izmantot esošu? Nu, jo daudzi no XML ziņojumapmaiņas produktu ieviešanas veidiem ir jauni, tāpēc ir svarīgi zināt, kas ietilpst pamata ieviešanā. Turklāt ir iespējams, ka, tā kā XML ziņojumu starpnieki ir nedaudz nenobrieduši produkti, jums būs jāizstrādā savi, lai iegūtu vēlamās funkcijas.
Šeit uzrādītais pamata brokeris var apkalpot divu veidu ziņojumus: pieprasījumu izveidot rēķinu, kuru tas glabā failu sistēmā, un klienta koda komponentu, kurš vienkārši nolasa XML ziņojumu no faila un nosūta to.
Brokeris sastāv no trim galvenajām daļām: klausītāja daļa, kas saņem ienākošos ziņojumus par kādu transportu (šajā piemērā tiks nodrošināta tikai HTTP ieviešana); galvenais brokera gabals, kurš izlems, ko darīt ar ienākošo ziņojumu; un izsaukuma gabals, kas faktiski veiks kādu loģiku, pamatojoties uz ienākošo ziņojumu. Apskatīsim katru sīkāk.
Saņemiet ziņojumu no transporta
Ziņojums vispirms sastapsies ar brokera klausītāja daļu. Lielākā daļa XML ziņojumu starpnieku nodrošina atbalstu daudziem dažādiem pārvadājumiem (protokoliem), piemēram, HTTP, SMTP, JMS (konkrēta piegādātāja ieviešana) utt. Mūsu brokeris to pieļauj, izolējot transporta daļu. Zemāk parādītais gabals vienkārši saņem ziņojumu par konkrētu transportu, ievieto ienākošo ziņojumu virknes mainīgajā un izsauc starpnieku:
