XML žinučių siuntimas reiškia sparčiai augančią, dinamišką IT sritį, padarantį ją tuo pačiu įdomia ir varginančia. Augant B2B mainams ir kitoms tarpšakinėms elektroninėms komunikacijoms, XML pranešimai bus naudojami kaip niekad plačiai.
Perskaitykite visą „XML Messaging“ seriją:
- 1 dalis. Parašykite paprastą XML pranešimų tarpininką pasirinktiniams XML pranešimams
- 2 dalis: XML pranešimai SOAP būdu
- 3 dalis: JAXM ir ebXML nustato naują XML pranešimų standartą
Šiame straipsnyje pirmiausia išnagrinėsime XML pranešimus ir kodėl tai naudinga. Tada mes įsigilinsime į specifines XML pranešimų siuntimo funkcijas, įskaitant pranešimų nukreipimą, transformavimą ir tarpininkavimą. Galiausiai pateiksime paprastą XML brokerio pavyzdį. Perskaitę ir supratę sąvokas, turėtumėte aiškiai suprasti, kurie scenarijai tinka įgyvendinant XML pranešimų sprendimą.
Kas yra XML žinučių siuntimas?
Norėdami pradėti tyrinėti, turime suprasti pagrindinę XML pranešimų prielaidą ir kokį terminą susirašinėjimas reiškia. Šio straipsnio tikslais aš apibrėžiu pranešimą taip:
Duomenų laukų, išsiųstų ar gautų kartu tarp programinės įrangos, rinkinys. Pranešime yra antraštė (kurioje saugoma pranešimo valdymo informacija) ir naudingoji apkrova (tikrasis pranešimo turinys).Pranešimai naudoja pranešimus, kad galėtų bendrauti su skirtingomis sistemomis tam tikroms funkcijoms atlikti. Mes nurodome, kad komunikacija yra orientuota į pranešimą, nes operacijai atlikti siųsdavome ir priimdavome pranešimus, priešingai nei į RPC (nuotolinio procedūrų iškvietimo) orientuotą ryšį. Gali padėti paprasta analogija: galvokite apie pranešimų siuntimą kaip el. Paštą programoms. Iš tiesų, žinučių siuntimas turi daugelį asmenų, siųsiančių vienas kitam el. Laiškus, atributų.
Anksčiau, kai naudodavote į pranešimą orientuotą sistemą arba dirbote, tai reiškė, kad laiškams siųsti naudojote kažkokį MOM (į pranešimą orientuotą tarpinę programinę įrangą) produktą, pvz., „Tibco“ „Rendezvous“, „IBM“ „MQSeries“ ar JMS teikėją. asinchroninė (vienpusė) mada. Šiandien susirašinėjimas nebūtinai reiškia, kad naudojate MOM produktą, ir tai nebūtinai reiškia, kad bendraujate asinchroniškai. Atvirkščiai, pranešimai gali būti sinchroniški (dvipusiai) arba asinchroniški ir naudoti daug skirtingų protokolų, tokių kaip HTTP ar SMTP, taip pat MOM produktus.
Kodėl verta naudotis XML pranešimais?
Kodėl norėtumėte sukurti sistemą naudodamiesi pranešimais? Kuo pranešimų siuntimas yra naudinga projektavimo technika ir kokie yra jo pranašumai? Kaip minėta anksčiau, reikalaujant, kad dvi programos kalbėtųsi tarpusavyje tinkle, reikalaudami dviejų programų: RPC arba orientuotos į pranešimą. Naudojant RPC pagrįstą metodą (RMI patenka į šią kategoriją), tai reiškia, kad procedūros iškvietimo klientas (arba skambinantysis) žino procedūrą, kurią nori iškviesti, ir žino parametrus, kuriuos nori perduoti procedūrai. Be to, skambinantysis nori palaukti, kol iškviestas serveris (programa) užpildys užklausą.
Antruoju požiūriu - orientuotu į pranešimą - skambinantysis nebūtinai žino tikslią procedūrą, kuri bus taikoma, o sukuria konkretaus formato pranešimą, žinomą tiek klientui, tiek serveriui. Klientas sukuria pranešimą ir per tinklą išsiunčia jį į serverį. Todėl klientas nepriklauso nuo serverio ar serverio procedūrų, bet priklauso nuo pranešimo formato. Be to, bendravimas greičiausiai vyksta asinchroniškai, o tai reiškia, kad klientas išsiųs užklausą, bet nelauks (blokuos) atsakymo. Tai leidžia klientui toliau veikti, net jei serveris tampa nepasiekiamas (pvz., Užstringa). Laikoma, kad šis dizainas, kai klientas yra labiau nepriklausomas nuo serverio, yra labiau susietas.
Vertinant, ar naudoti į pranešimą orientuotą dizainą, svarbu suprasti tokios sistemos pliusus ir minusus. Privalumai:
- Laisva mova
- Lengvesnis pranešimų nukreipimas ir transformavimas
- Lankstesnė naudingoji apkrova (gali apimti, pavyzdžiui, dvejetainius priedus)
- Gali naudoti kelis pranešimus kartu, norėdami iškviesti nurodytą procedūrą
Apskritai, į pranešimą orientuotas požiūris yra lankstesnis nei RPC metodas.
Dabar čia yra keletas trūkumų:
- Norint išplėtoti kliento / serverio sąveiką, naudojant į pranešimą orientuotą metodą, reikia daugiau darbo, palyginti su RPC metodu, pvz., RMI, nes kliento / serverio sąveikos plėtojimas pranešimu reiškia kitą RPC nenukrypimo lygį. Sudėtingumas pridedamas kuriant pranešimą kliento pusėje (palyginti su procedūros iškvietimu RPC metodu) ir serverio pusėje su pranešimų apdorojimo kodu. Dėl papildomo sudėtingumo į pranešimą orientuotą dizainą gali būti sunkiau suprasti ir derinti.
- Yra rizika prarasti tipo informaciją apie programavimo kalbą, kuria buvo išsiųstas pranešimas. Pavyzdžiui, dvigubas „Java“ pranešimas gali būti neišverstas kaip dvigubas pranešimas.
- Daugeliu atvejų operacijų kontekstas, kuriame buvo sukurtas pranešimas, neplinta į pranešimų serverį.
Atsižvelgiant į privalumus ir trūkumus, kada turėtumėte naudoti į pranešimą orientuotą požiūrį? Dažniausias scenarijus įvyksta, kai kliento / serverio ryšys vyksta internetu, o klientas ir serveris priklauso skirtingoms įmonėms. Pagal šį scenarijų gali būti gana sunku pasiekti, kad abi įmonės susitartų dėl procedūrų sąsajos. Be to, gali būti, kad įmonės gali nenorėti naudoti tos pačios programavimo kalbos. Kitame pavyzdyje dalyvaujančios įmonės gali norėti naudoti asinchroninį komunikacijos modelį, kad nė vienas nepriklausytų nuo to, ar veikia ir veikia kito programa.
Kitas patrauklus susirašinėjimo scenarijus įvyksta, kai kuriate įvykiais pagrįstą sistemą, kurioje įvykiai yra kuriami, o vėliau suinteresuoti asmenys juos vartoja. Dauguma GUI yra pagrįsti įvykiais. Pavyzdžiui, jie gali sukurti pelės paspaudimo įvykį, kuriame suinteresuotosios šalys klausytų įvykio ir pagal jį atliktų tam tikrus veiksmus. Tokiu atveju pranešimų siuntimo metodo naudojimas leidžia pašalinti priklausomybę tarp įvykio (ar veiksmo sistemoje) ir sistemos reakcijos į įvykį, kuris atliekamas serveryje.
Dabar, kai šiek tiek suprantame pranešimus, esame pasirengę pridėti XML prie lygties. XML pridėjimas prie pranešimų reiškia, kad savo pranešimuose galime naudoti lanksčią duomenų formatavimo kalbą. Pranešimų siuntime klientas ir serveris turi susitarti dėl pranešimo formato. XML tai palengvina, spręsdamas daugybę duomenų formatavimo problemų ir pridėdamas kitų XML standartų, tokių kaip „Rosetta Net“. Norint sugalvoti pranešimo formatą, nereikia papildomai dirbti.
Ką veikia XML pranešimų brokeris?
Pranešimų brokeris veikia kaip serveris į pranešimą orientuotoje sistemoje. Pranešimų tarpininko programinė įranga atlieka gautų pranešimų operacijas. Šios operacijos apima:
- Antraštės apdorojimas
- Saugumo patikrinimai ir šifravimas / iššifravimas
- Klaidų ir išimčių tvarkymas
- Maršrutai
- Kvietimas
- Transformacija
Antraštės apdorojimas
Antraštės apdorojimas paprastai yra viena iš pirmųjų funkcijų, atliekamų pranešime ją gavus XML tarpininke. Antraštės apdorojimas apima gaunamų pranešimų antraštės laukų tyrimą ir kai kurių funkcijų atlikimą. Antraštės apdorojimas gali apimti stebėjimo numerio pridėjimą prie gaunamo pranešimo arba užtikrinimą, kad egzistuoja visi antraštės laukai, reikalingi pranešimui apdoroti. Žemiau pateiktame XML pranešimo pavyzdyje pranešimų tarpininkas gali patikrinti į antraštės lauką, kad įsitikintumėte, jog tai yra tinkama šio pranešimo paskirties vieta.
Saugumo patikrinimai ir šifravimas / iššifravimas
Žvelgiant iš saugumo perspektyvos, pranešimų tarpininkas gali atlikti keletą skirtingų operacijų, tačiau greičiausiai norėsite atlikti „didįjį trejetą“: autentifikavimą, prieigos teisę ir šifravimą. Pirma, nustačiusi, kad pranešime yra duomenų, kuriuos galima naudoti autentiškumui patvirtinti, pranešimų tarpininkas autentifikuos pranešimus pagal saugos duomenų bazę ar katalogą. Antra, pranešimų tarpininkas leis atlikti operacijas, kurias galima atlikti naudojant tokio tipo pranešimus ir įgaliotąjį atstovą. Galiausiai pranešimas, pasiekiamas pranešimų tarpininkui, gali būti užšifruotas naudojant tam tikrą šifravimo schemą. Brokerio atsakomybė bus iššifruoti pranešimą, kad jis būtų toliau apdorojamas.
Klaidų ir išimčių tvarkymas
Klaidų ir išimčių tvarkymas yra dar viena svarbi funkcija, kurią atlieka pranešimų tarpininkas. Paprastai pranešimas atsakys klientui (darant prielaidą, kad yra sinchroninis iškvietimas) su klaidos pranešimu, kuris atsiranda, kai brokeriui išsiųstame pranešime nėra pakankamai ar tikslios informacijos. Kita klaidų ar išimčių priežastis atsirastų aptarnaujant užklausą (iš tikrųjų iškviečiant procedūrą / metodą, pagrįstą pranešimo apkrova).
Maršrutai
Pranešimų nukreipimas yra šakojanti pranešimų logika. Tai įvyksta dviem skirtingais pranešimo lygmenimis. Pirmasis, antraštės lygio maršrutas, nustato, ar gaunamas pranešimas yra susietas su šia programa, ar jį reikia siųsti kitai programai. Antrasis, naudingosios apkrovos nukreipimas, nustato, kokią procedūrą ar metodą reikia iškviesti, kai brokeris nustato, kad pranešimas yra susietas su šia programa. Šie du maršrutų tipai kartu suteikia daug funkcijų, susijusių su pranešimais.
Kvietimas
Kvietimas reiškia iš tikrųjų paskambinti arba iškviesti metodą naudojant duomenis (naudingąją apkrovą), esančius gaunamame pranešime. Tai gali duoti rezultatą, kuris per brokerį grąžinamas atgal klientui. Tai, kuo remiamasi, gali būti bet kas, įskaitant EJB sesijos pupelę, klasės metodą ir pan.
Transformacija
Transformacija konvertuoja arba susieja žemėlapį su kitu formatu. Naudojant XML, XSLT paprastai naudojamas transformacijos funkcijoms atlikti.
XML pranešimo pavyzdys
Žemiau rasite XML pranešimą, naudojamą toliau pateiktoje pavyzdinėje programoje. Atkreipkite dėmesį į antraštę ir kūno dalis. Šis pavyzdys yra „saveInvoice“ tipo pranešimas, kurio tekste yra sąskaita faktūra, kurią reikia išsaugoti.
KompanijaGavėjo įmonėSiuntėjas išsaugo sąskaitą faktūrą John Smith 123 George St. Mountain View CA 94041 Company A 100 Main St. Washington Washington DC 20015 IBM A20 Laptop 1 2000.00
Jums gali kilti klausimas, ar yra pranašumas kuriant pasirinktinį XML pranešimą. Kodėl nenaudojant vieno iš esamų pranešimų standartų, pvz., „EbXML“ ar „SOAP“, kaupiama apkrova (sąskaita faktūra)? Yra keletas priežasčių. Pirmasis yra parodyti kai kuriuos pranešime reikalingus turinius, nesudėtingai paaiškinant visiško pramonės standarto. Antra, nors galiojantys standartai patenkina daugumą poreikių, vis tiek bus scenarijų, kai pritaikyto pranešimo naudojimas geriau atitiks situacijos poreikius, panašiai kaip kompromisai tarp aukštesnio lygio protokolo, pvz., HTTP ar SMTP, ir neapdorotų lizdų naudojimo.
XML brokerio prototipo įgyvendinimas
Aptarę pranešimų dizaino naudojimo programoje priežastis, dabar mes pradėsime įgyvendinti XML pranešimų brokerio prototipą.
Kodėl turėtumėte sukurti pasirinktinį pranešimų brokerio diegimą, užuot naudoję esamą? Na, nes daugelis XML pranešimų produktų įdiegimų yra nauji, todėl svarbu žinoti, kas yra pagrindinis diegimas. Be to, gali būti, kad dėl to, kad XML pranešimų brokeriai yra šiek tiek nebrandūs produktai, turėsite sukurti savo, kad gautumėte norimas funkcijas.
Čia pateiktas pagrindinis brokeris gali aptarnauti dviejų tipų pranešimus: prašymą sukurti sąskaitą faktūrą, kurią jis saugo failų sistemoje, ir kliento kodo komponentą, kuris tiesiog nuskaito XML pranešimą iš failo ir jį išsiunčia.
Tarpininką sudaro trys pagrindinės dalys: klausytojo dalis, gaunanti gaunamus pranešimus tam tikru transportu (šiame pavyzdyje bus pateiktas tik HTTP diegimas); pagrindinis brokerio kūrinys, kuris nuspręs, ką daryti su gaunamu pranešimu; ir iškvietimo dalis, kuri iš tikrųjų atliks tam tikrą logiką pagal gaunamą pranešimą. Pažvelkime į kiekvieną iš jų išsamiau.
Gaukite pranešimą iš transporto
Pranešimas pirmiausia susidurs su brokerio klausytojo dalimi. Dauguma XML pranešimų tarpininkų teikia paramą daugeliui skirtingų perdavimo būdų (protokolų), tokių kaip HTTP, SMTP, JMS (konkretaus tiekėjo diegimas) ir pan. Mūsų brokeris tai leidžia, išskirdamas transporto dalį. Žemiau parodytas kūrinys tiesiog gauna pranešimą tam tikru transportu, įterpia gaunamą pranešimą į eilutės kintamąjį ir paskambina brokeriui į vieną:
