XML-meldinger, del 1

XML-meldinger representerer et raskt voksende, dynamisk IT-område, en situasjon som gjør det spennende og slitsomt samtidig. Etter hvert som B2B-utvekslinger og andre former for elektronisk kommunikasjon mellom virksomheter vokser, vil XML-meldinger bli bredere distribuert enn noen gang.

Les hele "XML Messaging" -serien:

• Del 1: Skriv en enkel megler for XML-meldinger for tilpassede XML-meldinger
• Del 2: XML-meldinger på SOAP-måten
• Del 3: JAXM og ebXML setter den nye standarden for XML-meldinger

I denne artikkelen vil vi først utforske XML-meldinger og hvorfor det er nyttig. Deretter vil vi fordype oss i spesifikke XML-meldingsfunksjoner, inkludert meldingsruting, transformasjon og megling. Til slutt avslutter vi med et enkelt eksempel på en XML-megler. Etter at du har lest og forstått konseptene, bør du forstå hvilke scenarier som egner seg til å implementere en XML-meldingsløsning.

Hva er XML-meldinger?

For å starte utforskningen vår, må vi forstå den grunnleggende forutsetningen for XML-meldinger og hva begrepet er meldinger tilsier. I forbindelse med denne artikkelen definerer jeg beskjed som følger:

En samling datafelt sendt eller mottatt mellom programvareapplikasjoner. En melding inneholder en overskrift (som lagrer kontrollinformasjon om meldingen) og en nyttelast (det faktiske innholdet i meldingen).

Meldinger bruker meldinger for å kommunisere med forskjellige systemer for å utføre en slags funksjon. Vi refererer til kommunikasjonen som meldingsorientert fordi vi ville sende og motta meldinger for å utføre operasjonen, i motsetning til en RPC (Remote Procedure Call) -orientert kommunikasjon. En enkel analogi kan hjelpe: tenk på meldinger som e-post for applikasjoner. Meldinger har faktisk mange av egenskapene til enkeltpersoner som sender e-postmeldinger til hverandre.

Tidligere, når du brukte eller jobbet med et meldingsorientert system, betydde det at du brukte en slags MOM (meldingsorientert mellomvare) -produkt som Tibcos Rendezvous, IBMs MQSeries eller en JMS-leverandør for å sende meldinger i en asynkron (enveis) mote. Meldinger i dag betyr ikke nødvendigvis at du bruker et MOM-produkt, og det betyr ikke nødvendigvis at du kommuniserer asynkront. Snarere kan meldinger være enten synkrone (toveis) eller asynkrone og bruke mange forskjellige protokoller som HTTP eller SMTP, samt MOM-produkter.

Hvorfor XML-meldinger?

Hvorfor vil du utvikle et system ved hjelp av meldinger? Hva gjør meldinger til en nyttig designteknikk, og hva er fordelene? Som nevnt tidligere kan vi velge mellom to alternativer når vi krever to applikasjoner for å snakke med hverandre over et nettverk: RPC eller meldingsorientert. Å bruke en RPC-basert tilnærming (RMI faller inn i denne kategorien) betyr at klienten (eller innringeren) av prosedyreanropet kjenner til prosedyren den vil påberope og kjenner parametrene den ønsker å overføre til prosedyren. Dessuten ønsker den som ringer å vente mens den ringte serveren (applikasjonen) fullfører forespørselen.

I den andre tilnærmingen - meldingsorientert - vet ikke den som ringer nødvendigvis den nøyaktige prosedyren som vil bli påkalt, men oppretter i stedet en melding i et bestemt format kjent for både klienten og serveren. Klienten oppretter meldingen og sender den deretter til serveren over nettverket. Derfor er klienten ikke avhengig av serveren eller serverens prosedyrer, men er avhengig av meldingsformatet. Kommunikasjonen skjer også sannsynligvis på en asynkron måte, noe som betyr at klienten sender en forespørsel, men ikke vil vente (blokkere) på svaret. Dette gjør at klienten kan fortsette å fungere selv om serveren blir utilgjengelig (for eksempel krasjer). Denne designen, der klienten er mer uavhengig av serveren, anses å være mer løst koblet.

Når du vurderer om du skal bruke en meldingsorientert design, er det viktig å forstå fordeler og ulemper med et slikt system. Proffene inkluderer:

• Løs kobling
• Enklere ruting og transformasjon av meldinger
• Mer fleksibel nyttelast (kan for eksempel omfatte binære vedlegg)
• Kan bruke flere meldinger sammen for å påkalle en gitt prosedyre

Generelt viser en meldingsorientert tilnærming seg mer fleksibel enn en RPC-tilnærming.

Nå er det noen ulemper:

• Det krever mer arbeid å utvikle en klient / server-interaksjon ved hjelp av en meldingsorientert tilnærming sammenlignet med en RPC-tilnærming som RMI, fordi utvikling av en klient / server-interaksjon via en melding representerer et annet nivå av indireksjon fra RPC. Kompleksitet blir lagt til gjennom opprettelsen av meldingen på klientsiden (kontra en prosedyreinnkalling i en RPC-tilnærming) og på serversiden med meldingsbehandlingskode. På grunn av den ekstra kompleksiteten kan en meldingsorientert design være vanskeligere å forstå og feilsøke.
• Det er en risiko for å miste typeinformasjon for programmeringsspråket der meldingen ble sendt. For eksempel kan dobbel i Java ikke oversettes som en dobbel i meldingen.
• I de fleste tilfeller overføres ikke transaksjonskonteksten der meldingen ble opprettet til meldingsserveren.

Når du vurderer fordeler og ulemper, når bør du bruke en meldingsorientert tilnærming? Det vanligste scenariet oppstår når klient / serverkommunikasjon foregår over Internett og klienten og serveren tilhører forskjellige selskaper. I dette scenariet kan det være ganske vanskelig å ha de to selskapene enige om prosedyregrensesnittet. Det er også mulig at selskapene kanskje ikke vil bruke samme programmeringsspråk. I et annet eksempel vil de involverte selskapene kanskje bruke en asynkron kommunikasjonsmodell slik at ingen avhenger av at den andres applikasjon er i gang.

Et annet attraktivt meldingsscenario oppstår når du utvikler et hendelsesbasert system der hendelser blir opprettet og deretter konsumert av interesserte parter. De fleste GUIer er hendelsesbaserte. For eksempel kan de opprette et museklikk-hendelse der interesserte lytter til arrangementet og utfører noen handlinger basert på den. I dette scenariet kan du bruke en meldingsmetode til å fjerne avhengigheten mellom en hendelse (eller handling i et system) og systemets reaksjon på hendelsen som utføres på serveren.

Nå som vi forstår litt om meldinger, er vi klare til å legge til XML i ligningen. Tillegget av XML til meldinger betyr at vi er i stand til å bruke et fleksibelt dataformateringsspråk for meldingene våre. I meldinger må både klienten og serveren bli enige om et meldingsformat. XML gjør dette lettere ved å avgjøre mange dataformateringsproblemer og med tillegg av andre XML-standarder som Rosetta Net. Det kreves ikke noe ekstra arbeid for å komme med et meldingsformat.

Hva gjør en XML-meldingsmegler?

En meldingsmegler fungerer som server i et meldingsorientert system. Meldingsmeglerprogramvare utfører operasjoner på meldinger den mottar. Disse operasjonene inkluderer:

• Topptekstbehandling
• Sikkerhetskontroller og kryptering / dekryptering
• Feil og unntakshåndtering
• Rute
• Påkallelse
• Transformasjon

Topptekstbehandling

Overskriftsbehandling er vanligvis en av de første funksjonene som utføres i meldingen etter mottakelse i en XML-megler. Overskriftbehandling innebærer å undersøke topptekstfeltene i innkommende meldinger og utføre noen funksjoner. Overskriftsbehandling kan omfatte å legge til et sporingsnummer til en innkommende melding eller sikre at alle topptekstfeltene som er nødvendige for å behandle meldingen, eksisterer. I eksempelet på XML-meldingen nedenfor, kunne meldingsmegleren sjekke til overskriftsfelt for å sikre at dette er riktig destinasjon for denne meldingen.

Sikkerhetskontroller og kryptering / dekryptering

Fra et sikkerhetsperspektiv kan en meldingsmegler utføre flere forskjellige operasjoner, men mest sannsynlig vil du oppnå de "store tre" av sikkerhet: autentisering, autorisasjon og kryptering. Først når den bestemmer at meldingen inneholder data som kan brukes til å autentisere, vil meldingsmegleren autentisere meldinger mot en sikkerhetsdatabase eller katalog. For det andre vil meldingsmegleren autorisere operasjoner som kan utføres med denne typen meldinger og en autorisert rektor. Til slutt kan meldingen som kommer til meldingsmegleren krypteres ved hjelp av et krypteringsskjema. Det vil være meglerens ansvar å dekryptere meldingen for å behandle den videre.

Feil og unntakshåndtering

Feil- og unntakshåndtering er en annen viktig funksjon som utføres av meldingsmegleren. Generelt vil meldingen svare på klienten (forutsatt en synkron påkallelse) med en feilmelding, forårsaket når meldingen sendt til megleren ikke inneholder tilstrekkelig eller nøyaktig informasjon. En annen årsak til feil eller unntak vil oppstå når du betjener forespørselen (faktisk påkaller en prosedyre / metode basert på nyttelasten til meldingen).

Rute

Meldingsruting er forgreningslogikk for meldinger. Det forekommer på to forskjellige nivåer i en melding. Den første ruting på toppnivå bestemmer om en innkommende melding er bundet til dette programmet eller må sendes på nytt til et annet program. Den andre, nyttelastruting, bestemmer hvilken prosedyre eller metode som skal påberopes når megleren bestemmer at meldingen er bundet til denne applikasjonen. Sammen gir disse to rutene et rikt utvalg av funksjonalitet når du arbeider med meldinger.

Påkallelse

Påkallelse betyr å ringe eller påkalle en metode med dataene (nyttelasten) i den innkommende meldingen. Dette kan gi et resultat som deretter returneres gjennom megleren tilbake til klienten. Det som påberopes kan være hva som helst, inkludert en EJB Session bønne, klassemetode og så videre.

Transformasjon

Transformasjon konverterer eller kartlegger meldingen til et annet format. Med XML brukes XSLT ofte til å utføre transformasjonsfunksjonalitet.

Et eksempel på en XML-melding

Nedenfor finner du en XML-melding som brukes i eksempelprogrammet som følger. Legg merke til topptekst og kroppsdeler. Dette eksemplet er en "saveInvoice" type melding, der kroppen inneholder en faktura som må lagres.

   selskapMottakerselskapAvsender lagreFaktura John Smith 123 George St. Mountain View CA 94041 Company A 100 Main St. Washington DC 20015 IBM A20 Laptop 1 2000,00 

Du lurer kanskje på om det er en fordel å utvikle en tilpasset XML-melding. Hvorfor ikke bruke en av de eksisterende meldingsstandardene som ebXML eller SOAP for å kapsle nyttelasten (fakturaen)? Det er et par grunner. Den første er å demonstrere noe av innholdet som trengs i en melding uten at det er så komplisert å forklare en fullstendig industristandard. For det andre, selv om de eksisterende standardene fyller de fleste behov, vil det fremdeles være scenarier der bruk av en tilpasset melding bedre vil passe til behovene i en situasjon, omtrent som kompromissene mellom å bruke en høyere nivåprotokoll som HTTP eller SMTP og bruk av rå stikkontakter.

En prototype XML-meglerimplementering

Etter å ha diskutert årsakene til å bruke et meldingsdesign i applikasjonen din, vil vi nå gå videre til implementering av en prototype XML-meldingsmegler.

Hvorfor bør du utvikle en tilpasset implementering av meldingsmeglere i stedet for å bruke en eksisterende? Vel, fordi mange av implementeringene for XML-meldingsprodukter er nye, så det er viktig å vite hva som går med i en grunnleggende implementering. Det er også mulig at fordi XML-meldingsmeglere er noe umodne produkter, må du utvikle dine egne for å få de funksjonene du vil ha.

Den grunnleggende megleren som presenteres her, kan betjene to typer meldinger: en forespørsel om å opprette en faktura, som den lagrer på filsystemet, og en klientkodekomponent, som bare leser XML-meldingen fra en fil og sender den.

Megleren består av tre hoveddeler: et lytterstykke som mottar innkommende meldinger på noen transport (i dette eksemplet vil det bare være en HTTP-implementering gitt); hovedmeglerstykket, som bestemmer hva du skal gjøre med en innkommende melding; og påkallingsstykket som faktisk vil utføre litt logikk basert på den innkommende meldingen. La oss se nærmere på hverandre.

Motta meldingen fra transporten

En melding vil først møte meglerens lytterdel. De fleste XML-meldingsmeglere gir støtte for mange forskjellige transporter (protokoller) som HTTP, SMTP, JMS (en bestemt leverandørs implementering) og så videre. Megleren vår åpner for dette ved å isolere transportdelen. Brikken vist nedenfor mottar ganske enkelt meldingen på en gitt transport, plasserer den innkommende meldingen i en strengvariabel, og kaller megleren singleton: