XML-viestit edustavat nopeasti kasvavaa, dynaamista IT-aluetta, joka tekee siitä jännittävän ja väsyttävän samanaikaisesti. B2B-vaihdon ja muiden yritysten välisen sähköisen viestinnän muotojen kasvaessa XML-viestit otetaan käyttöön laajemmin kuin koskaan.
Lue koko "XML Messaging" -sarja:
- Osa 1: Kirjoita yksinkertainen XML-viestien välittäjä mukautettuja XML-viestejä varten
- Osa 2: XML-viestit SOAP-tavalla
- Osa 3: JAXM ja ebXML asettavat uuden standardin XML-viestille
Tässä artikkelissa tutkitaan ensin XML-viestintää ja miksi se on hyödyllistä. Sitten tutkitaan erityisiä XML-viestintäominaisuuksia, kuten viestien reititys, muunnos ja välitys. Lopuksi lopuksi yksinkertainen esimerkki XML-välittäjästä. Kun olet lukenut ja ymmärtänyt käsitteet, sinun on ymmärrettävä selvästi, mitkä skenaariot soveltuvat XML-viestintäratkaisun toteuttamiseen.
Mikä on XML-viestintä?
Tutkimuksen aloittamiseksi meidän on ymmärrettävä XML-viestien perusoletus ja termi viestit viittaa. Tätä artikkelia varten määritän viesti seuraavasti:
Kokoelma tietokenttiä, jotka on lähetetty tai vastaanotettu yhdessä ohjelmistosovellusten välillä. Viesti sisältää otsikon (joka tallentaa viestin ohjaustiedot) ja hyötykuorman (viestin todellinen sisältö).Viestit käyttävät viestejä kommunikoimaan eri järjestelmien kanssa jonkinlaisten toimintojen suorittamiseksi. Viittaamme viestinnän viestikeskeiseksi, koska lähetämme ja vastaanotamme viestejä operaation suorittamiseksi, toisin kuin RPC (Remote Procedure Call) -orientoitu viestintä. Yksinkertainen analogia voi auttaa: ajattele viestintää sähköpostina sovelluksille. Itse asiassa viestillä on monia sellaisten henkilöiden ominaisuuksia, jotka lähettävät sähköpostiviestejä toisilleen.
Aikaisemmin, kun käytit tai suunnittelet viestikeskeistä järjestelmää, se tarkoitti, että käytit jonkinlaista MOM-tuotetta (viesti-suuntautunut väliohjelmisto), kuten Tibcon Rendezvous, IBM: n MQSeries tai JMS-palveluntarjoaja lähettämään viestejä asynkroninen (yksisuuntainen) muoti. Viestintä tänään ei välttämättä tarkoita sitä, että käytät MOM-tuotetta, eikä se välttämättä tarkoita sitä, että viestit asynkronisesti. Pikemminkin viestintä voi olla joko synkronista (kaksisuuntaista) tai asynkronista ja käyttää monia erilaisia protokollia, kuten HTTP tai SMTP, sekä MOM-tuotteita.
Miksi XML-viestit?
Miksi haluat kehittää järjestelmän, joka käyttää viestintää? Mikä tekee viestistä hyödyllisen suunnittelutekniikan ja mitkä ovat sen edut? Kuten aiemmin mainittiin, voimme valita kahdesta vaihtoehdosta, kun vaaditaan kahta sovellusta puhumaan keskenään verkon kautta: RPC tai viesti-suuntautunut. RPC-pohjaisen lähestymistavan käyttö (RMI kuuluu tähän luokkaan) tarkoittaa, että menettelykutsun asiakas (tai soittaja) tuntee menettelyn, jonka haluaa kutsua, ja tietää parametrit, jotka se haluaa välittää menettelylle. Soittaja haluaa myös odottaa, kun kutsuttu palvelin (sovellus) suorittaa pyynnön.
Toisessa lähestymistavassa - viestikeskeinen - soittaja ei välttämättä tiedä tarkkaa menettelyä, johon kutsutaan, vaan sen sijaan luo tietyn muotoisen viestin, jonka sekä asiakas että palvelin tuntevat. Asiakas luo viestin ja lähettää sen sitten palvelimelle verkon kautta. Siksi asiakas ei ole riippuvainen palvelimesta tai palvelimen menettelyistä, vaan riippuu sanoman muodosta. Lisäksi viestintä tapahtuu todennäköisesti asynkronisesti, mikä tarkoittaa, että asiakas lähettää pyynnön, mutta ei odota (estä) vastausta. Tämä antaa asiakkaalle mahdollisuuden jatkaa toimintaansa myös silloin, kun palvelin ei ole käytettävissä (esimerkiksi kaatuu). Tämän mallin, jossa asiakas on riippumattomampi palvelimesta, katsotaan olevan löyhemmin kytketty.
Kun arvioidaan, käytetäänkö viestikeskeistä suunnittelua, on tärkeää ymmärtää tällaisen järjestelmän edut ja haitat. Ammattilaisia ovat:
- Löysä kytkentä
- Helpompi viestien reititys ja muunnos
- Joustavampi hyötykuorma (voi sisältää esimerkiksi binääriliitteitä)
- Voi käyttää useita viestejä yhdessä tietyn menettelyn käynnistämiseksi
Yleensä viestikeskeinen lähestymistapa osoittautuu joustavammaksi kuin RPC-lähestymistapa.
Nyt tässä on joitain haittoja:
- Se vaatii enemmän työtä asiakas / palvelin-vuorovaikutuksen kehittämiseksi käyttäen viestisuuntautunutta lähestymistapaa verrattuna RPC-lähestymistapaan, kuten RMI, koska asiakas / palvelin-vuorovaikutuksen kehittäminen sanomalla edustaa toista epäsuoruuden tasoa RPC: stä. Monimutkaisuus lisätään luomalla viesti asiakkaan puolelle (verrattuna RPC-lähestymistavan menettelykutsuun) ja palvelimen puolelle viestin käsittelykoodilla. Viestikeskeistä suunnittelua voi sen monimutkaisuuden vuoksi olla vaikeampaa ymmärtää ja korjata.
- On olemassa vaara, että menetät tyyppitiedot ohjelmointikielelle, jolla viesti lähetettiin. Esimerkiksi kaksoiskieli Java-kielessä ei välttämättä käänny kaksoisviestinä viestissä.
- Useimmissa tapauksissa tapahtumakonteksti, jossa viesti luotiin, ei etene viestipalvelimelle.
Milloin kannattaa käyttää sanakeskeistä lähestymistapaa, kun otetaan huomioon edut ja haitat? Yleisin skenaario tapahtuu, kun asiakas / palvelin-viestintä tapahtuu Internetin kautta ja asiakas ja palvelin kuuluvat eri yrityksille. Tässä skenaariossa voi olla melko vaikeaa saada kaksi yritystä sopimaan menettelyliittymästä. On myös mahdollista, että yritykset eivät halua käyttää samaa ohjelmointikieltä. Toisessa esimerkissä asianomaiset yritykset saattavat haluta käyttää asynkronista viestintämallia siten, että kumpikaan ei riipu toisen sovelluksen käynnistyksestä.
Toinen houkutteleva viestintätilanne tapahtuu, kun kehität tapahtumapohjaista järjestelmää, jossa kiinnostuneet osapuolet luovat ja kuluttavat sitten tapahtumia. Useimmat graafiset käyttöliittymät ovat tapahtumapohjaisia. Esimerkiksi, he voivat luoda hiiren napsautustapahtuman, jossa kiinnostuneet osapuolet kuuntelevat tapahtumaa ja suorittavat sen perusteella jonkin toiminnon. Tässä tilanteessa viestintätavan avulla voit poistaa riippuvuuden tapahtuman (tai järjestelmän toiminnon) ja järjestelmän reaktion tapahtumasta, joka suoritetaan palvelimella.
Nyt kun ymmärrämme vähän viestinnästä, olemme valmiita lisäämään XML-yhtälöön. XML: n lisääminen viesteihin tarkoittaa, että voimme käyttää joustavaa tiedon muotoilukieliä viesteihimme. Viestinnässä sekä asiakkaan että palvelimen on sovittava viestin muodosta. XML tekee tämän helpommaksi päättämällä monista tietojen muotoilukysymyksistä ja lisäämällä muita XML-standardeja, kuten Rosetta Net. Viestimuodon keksiminen ei edellytä ylimääräistä työtä.
Mitä XML-viestien välittäjä tekee?
Viestivälittäjä toimii palvelimena viestikeskeisessä järjestelmässä. Viestinvälittäjäohjelmisto suorittaa toimintoja vastaanottamillaan viesteillä. Näitä toimintoja ovat:
- Otsikkokäsittely
- Turvatarkistukset ja salaus / salauksen purku
- Virheiden ja poikkeusten käsittely
- Reititys
- Kutsu
- Muutos
Otsikkokäsittely
Otsikkokäsittely on yleensä yksi ensimmäisistä toiminnoista, jotka viestissä suoritetaan sen saatuaan XML-välittäjässä. Otsikkokäsittelyyn kuuluu saapuvien viestien otsikkokenttien tutkiminen ja joidenkin toimintojen suorittaminen. Otsikkokäsittely voi sisältää seurantanumeron lisäämisen saapuvaan viestiin tai sen varmistamisen, että kaikki viestin käsittelyyn tarvittavat otsikkokentät ovat olemassa. Alla olevassa XML-viestiesimerkissä viestinvälittäjä voi tarkistaa että otsikkokenttä varmistaaksesi, että tämä on oikea tämän viestin kohde.
Turvatarkistukset ja salaus / salauksen purku
Turvallisuuden näkökulmasta viestivälittäjä voi suorittaa useita eri toimintoja, mutta todennäköisesti haluat suorittaa turvallisuuden "ison kolmen": todennuksen, valtuutuksen ja salauksen. Ensinnäkin, kun se välittää, että viesti sisältää tietoja, joita voidaan käyttää todennukseen, viestien välittäjä todentaa viestit tietoturvatietokantaan tai hakemistoon. Toiseksi sanomanvälittäjä valtuuttaa toiminnot, jotka voidaan suorittaa tämän tyyppisellä viestillä ja valtuutetulla päämiehellä. Lopuksi sanomanvälittäjälle saapuva viesti voidaan salata käyttämällä jotakin salausmenetelmää. Välittäjän vastuulla on purkaa viesti salauksen käsittelemiseksi edelleen.
Virheiden ja poikkeusten käsittely
Virheiden ja poikkeusten käsittely on toinen tärkeä toiminto, jonka viestivälittäjä suorittaa. Yleensä viesti vastaa asiakkaalle (olettaen synkronisen kutsun) virheilmoituksella, joka aiheutuu, kun välittäjälle lähetetty viesti ei sisällä riittävää tai tarkkaa tietoa. Toinen virheiden tai poikkeusten syy ilmenisi pyynnön palvelemisessa (tosiasiallisesti vedoten viestin hyötykuormaan perustuvaan menettelyyn / menetelmään).
Reititys
Viestien reititys on haarautuva logiikka viesteille. Se tapahtuu kahdella eri tasolla viestissä. Ensimmäinen otsikkotason reititys määrittää, onko saapuva viesti sidottu tähän sovellukseen vai onko se lähetettävä uudelle sovellukselle. Toinen, hyötykuorman reititys, määrittää, minkä menettelyn tai menetelmän pitäisi käynnistää, kun välittäjä määrittää, että viesti on sidottu tälle sovellukselle. Nämä kaksi reititystyyppiä mahdollistavat monipuolisen toiminnallisuuden viestien käsittelyssä.
Kutsu
Kutsu tarkoittaa tosiasiallista soittamista tai kutsumista menetelmälle saapuvan viestin sisältämillä tiedoilla (hyötykuorma). Tämä voi tuottaa tuloksen, joka palautetaan sitten välittäjän kautta takaisin asiakkaalle. Tähän voidaan vedota mitä tahansa, mukaan lukien EJB Session -papu, luokkamenetelmä ja niin edelleen.
Muutos
Muunnos muuntaa tai kartoittaa viestin johonkin muuhun muotoon. XML: n avulla XSLT: tä käytetään yleisesti muunnostoimintojen suorittamiseen.
Esimerkki XML-sanomasta
Alla on XML-viesti, jota käytetään seuraavassa esimerkkisovelluksessa. Huomaa otsikon ja rungon osat. Tämä esimerkki on "saveInvoice" -tyyppinen viesti, johon runko sisältää tallennettavan laskun.
yritysVastaanottajayritysLähettäjän tallennusLasku John Smith 123 George St. Mountain View CA 94041 Yritys A 100 Main St. Washington DC 20015 IBM A20 Laptop 1 2000.00
Saatat miettiä, onko mukautetun XML-viestin kehittämisellä etua. Mikset hyödyntäisi yhtä nykyisistä viestistandardeista, kuten ebXML tai SOAP, hyötykuorman (laskun) kapseloinnissa? Tähän on pari syytä. Ensimmäinen on esitellä osa viestissä tarvittavasta sisällöstä ilman täysin monimutkaista selittää täysimittaista teollisuusstandardia. Toiseksi, vaikka nykyiset standardit täyttävät suurimman osan tarpeista, on silti skenaarioita, joissa mukautetun viestin käyttö sopii paremmin tilanteen tarpeisiin, aivan kuten kompromissit ylemmän tason protokollan, kuten HTTP tai SMTP, ja raakapistokkeiden käytön välillä.
XML-välittäjän prototyyppi
Kun olemme keskustelleet syistä, miksi viestisuunnittelu on käytetty sovelluksessasi, siirrymme nyt prototyypin XML-sanomanvälittäjään.
Miksi sinun pitäisi kehittää mukautettu viestivälittäjän toteutus olemassa olevan sijaan? No, koska monet XML-viestintätuotteiden toteutukset ovat uusia, joten on tärkeää tietää, mitä perusasennukseen sisältyy. On myös mahdollista, että koska XML-viestien välittäjät ovat melko kypsymättömiä tuotteita, sinun on kehitettävä oma, jotta saat haluamasi ominaisuudet.
Tässä esitetty perusvälittäjä voi palvella kahden tyyppisiä viestejä: pyyntö luoda lasku, jonka se tallentaa tiedostojärjestelmään, ja asiakaskoodikomponentti, joka vain lukee XML-viestin tiedostosta ja lähettää sen.
Välittäjä koostuu kolmesta pääosasta: kuuntelupala, joka vastaanottaa saapuvia viestejä joillakin kuljetuksilla (tässä esimerkissä tarjotaan vain HTTP-toteutus); päävälittäjän pala, joka päättää mitä tehdä saapuvalla viestillä; ja kutsukappale, joka todella suorittaa jonkin logiikan saapuvan viestin perusteella. Katsotaanpa kutakin tarkemmin.
Vastaanota viesti kuljetuksesta
Välittäjän kuuntelijaosuus kohtaa ensin viestin. Useimmat XML-viestien välittäjät tarjoavat tukea monille erilaisille siirroille (protokollille), kuten HTTP, SMTP, JMS (tietyn toimittajan toteutus) ja niin edelleen. Välittäjämme sallii tämän eristämällä kuljetusosan. Alla esitetty pala vain vastaanottaa viestin tietyllä kuljetuksella, sijoittaa saapuvan viestin merkkijonomuuttujaan ja soittaa välittäjälle singleton:
