Programmering

XML-beskeder, del 1

XML-beskeder repræsenterer et hurtigt voksende, dynamisk IT-område, en situation der gør det spændende og trættende på samme tid. Efterhånden som B2B-udvekslinger og andre former for elektronisk kommunikation mellem virksomheder vokser, vil XML-meddelelser blive bredere implementeret end nogensinde.

Læs hele serien "XML Messaging":

  • Del 1: Skriv en simpel XML-meddelelsesmægler til brugerdefinerede XML-meddelelser
  • Del 2: XML-beskeder SOAP-måde
  • Del 3: JAXM og ebXML indstiller den nye standard for XML-beskeder

I denne artikel undersøger vi først XML-beskeder, og hvorfor det er nyttigt. Derefter dykker vi ned i specifikke XML-messaging-funktioner, herunder meddelelsesrute, transformation og mægling. Endelig slutter vi med et simpelt eksempel på en XML-mægler. Når du har læst og forstået begreberne, skal du forstå hvilke scenarier, der egner sig til implementering af en XML-messaging-løsning.

Hvad er XML-beskeder?

For at starte vores udforskning er vi nødt til at forstå den grundlæggende forudsætning for XML-meddelelser og hvad udtrykket er beskeder indebærer. Med henblik på denne artikel definerer jeg besked som følger:

En samling af datafelter sendt eller modtaget mellem softwareapplikationer. En besked indeholder en overskrift (som gemmer kontroloplysninger om meddelelsen) og en nyttelast (det faktiske indhold af beskeden).

Messaging bruger beskeder til at kommunikere med forskellige systemer for at udføre en slags funktion. Vi henviser til kommunikationen som beskedorienteret, fordi vi ville sende og modtage meddelelser for at udføre operationen i modsætning til en RPC (Remote Procedure Call) -orienteret kommunikation. En simpel analogi kan hjælpe: tænk på messaging som e-mail til applikationer. Faktisk besidder messaging mange af egenskaberne hos enkeltpersoner, der sender e-mail-meddelelser til hinanden.

Tidligere, da du brugte eller arbejdede på et meddelelsesorienteret system, betød det, at du brugte en slags MOM (meddelelsesorienteret middleware) -produkt som Tibcos Rendezvous, IBMs MQSeries eller en JMS-udbyder til at sende meddelelser i en asynkron (envejs) mode. Beskeder i dag betyder ikke nødvendigvis, at du bruger et MOM-produkt, og det betyder ikke nødvendigvis, at du kommunikerer asynkront. Snarere kan messaging enten være synkron (tovejs) eller asynkron og bruge mange forskellige protokoller såsom HTTP eller SMTP samt MOM-produkter.

Hvorfor XML-beskeder?

Hvorfor vil du udvikle et system ved hjælp af messaging? Hvad gør messaging til en nyttig designteknik, og hvad er fordelene? Som nævnt tidligere kan vi vælge mellem to alternativer, når vi kræver, at to applikationer skal tale med hinanden via et netværk: RPC eller meddelelsesorienteret. Brug af en RPC-baseret tilgang (RMI falder inden for denne kategori) betyder, at klienten (eller den, der ringer) til procedurekaldet kender den procedure, den ønsker at påberåbe sig, og kender de parametre, den ønsker at overføre til proceduren. Den, der ringer op, ønsker også at vente, mens den kaldte server (applikationen) fuldfører anmodningen.

I den anden tilgang - beskedorienteret - kender den, der ringer, ikke nødvendigvis den nøjagtige procedure, der vil blive påberåbt, men opretter i stedet en besked i et specifikt format, der er kendt for både klienten og serveren. Klienten opretter meddelelsen og sender den derefter til serveren via netværket. Derfor er klienten ikke afhængig af serveren eller serverens procedurer, men er afhængig af meddelelsesformatet. Kommunikationen foregår sandsynligvis også på en asynkron måde, hvilket betyder, at klienten sender en anmodning, men ikke venter (blokerer) på svaret. Dette gør det muligt for klienten at fortsætte med at fungere, selvom serveren bliver utilgængelig (f.eks. Nedbrud). Dette design, hvor klienten er mere uafhængig af serveren, anses for at være mere løst koblet.

Når man vurderer, om der skal bruges et meddelelsesorienteret design, er det vigtigt at forstå fordele og ulemper ved et sådant system. Fordelene inkluderer:

  • Løs kobling
  • Lettere routing og transformation af meddelelser
  • Mere fleksibel nyttelast (kan f.eks. Omfatte binære vedhæftede filer)
  • Kan bruge flere meddelelser sammen for at påkalde en given procedure

Generelt viser en meddelelsesorienteret tilgang sig mere fleksibel end en RPC-tilgang.

Her er nogle ulemper:

  • Det kræver mere arbejde for at udvikle en klient / server-interaktion ved hjælp af en meddelelsesorienteret tilgang sammenlignet med en RPC-tilgang som RMI, fordi udvikling af en klient / server-interaktion via en besked repræsenterer et andet niveau af indirektion fra RPC. Kompleksitet tilføjes gennem oprettelsen af ​​meddelelsen på klientsiden (versus en procedureopkald i en RPC-tilgang) og på serversiden med beskedbehandlingskode. På grund af sin ekstra kompleksitet kan et meddelelsesorienteret design være sværere at forstå og fejle.
  • Der er risiko for at miste typeoplysninger for det programmeringssprog, som meddelelsen blev sendt med. For eksempel kan dobbelt i Java muligvis ikke oversættes som en dobbelt i meddelelsen.
  • I de fleste tilfælde spredes den transaktionelle kontekst, hvor meddelelsen blev oprettet, ikke til messaging-serveren.

I betragtning af fordele og ulemper, hvornår skal du bruge en meddelelsesorienteret tilgang? Det mest almindelige scenario opstår, når klienten / serverkommunikationen finder sted over Internettet, og klienten og serveren tilhører forskellige virksomheder. I dette scenarie kan det være ret vanskeligt at have de to virksomheder enige om proceduregrænsefladen. Det er også muligt, at virksomhederne måske ikke vil bruge det samme programmeringssprog. I et andet eksempel ønsker de involverede virksomheder måske at bruge en asynkron kommunikationsmodel, så ingen af ​​dem afhænger af, at den andres applikation er i gang.

Et andet attraktivt messaging-scenarie opstår, når du udvikler et begivenhedsbaseret system, hvor begivenheder oprettes og derefter forbruges af interesserede parter. De fleste GUI'er er hændelsesbaserede. For eksempel kan de oprette en museklikshændelse, hvor interesserede parter lytter til begivenheden og udfører en handling baseret på den. I dette scenarie giver brug af en messaging-tilgang dig mulighed for at fjerne afhængigheden mellem en begivenhed (eller handling i et system) og systemets reaktion på den begivenhed, der udføres på serveren.

Nu hvor vi forstår lidt om messaging, er vi klar til at tilføje XML til ligningen. Tilføjelsen af ​​XML til messaging betyder, at vi er i stand til at gøre brug af et fleksibelt dataformateringssprog til vores meddelelser. I messaging skal både klienten og serveren være enige om et meddelelsesformat. XML gør dette lettere ved at beslutte mange dataformateringsproblemer og med tilføjelsen af ​​andre XML-standarder som Rosetta Net. Der kræves ikke noget yderligere arbejde for at komme med et beskedformat.

Hvad gør en XML-mægler?

En meddelelsesmægler fungerer som serveren i et meddelelsesorienteret system. Meddelelsesmæglersoftware udfører operationer på meddelelser, den modtager. Disse operationer inkluderer:

  • Hovedbehandling
  • Sikkerhedskontrol og kryptering / dekryptering
  • Fejl og undtagelse håndtering
  • Routing
  • Påkaldelse
  • Transformation

Hovedbehandling

Headerbehandling er normalt en af ​​de første funktioner, der udføres i meddelelsen, når den modtages i en XML-mægler. Headerbehandling indebærer at undersøge headerfelterne i indgående beskeder og udføre nogle funktioner. Hovedbehandling kan omfatte tilføjelse af et sporingsnummer til en indgående besked eller at sikre, at alle de overskriftsfelter, der er nødvendige for at behandle meddelelsen, findes. I nedenstående eksempel på XML-besked kunne beskedmægleren kontrollere til headerfelt for at sikre, at dette er den rigtige destination for denne meddelelse.

Sikkerhedskontrol og kryptering / dekryptering

Fra et sikkerhedsperspektiv kan en meddelelsesmægler udføre flere forskellige operationer, men sandsynligvis vil du udføre de "store tre" af sikkerhed: godkendelse, autorisation og kryptering. Først når det bestemmer, at meddelelsen indeholder data, der kan bruges til at godkende, vil meddelelsesmægleren godkende meddelelser mod en sikkerhedsdatabase eller -mappe. For det andet godkender meddelelsesmægleren handlinger, der kan udføres med denne type besked og en autoriseret hovedstol. Endelig kan den meddelelse, der ankommer til meddelelsesmægleren, muligvis krypteres ved hjælp af et krypteringsskema. Det vil være mæglerens ansvar at dekryptere meddelelsen for at behandle den yderligere.

Fejl og undtagelse håndtering

Fejl- og undtagelseshåndtering er et andet vigtigt stykke funktionalitet, der udføres af meddelelsesmægleren. Generelt vil beskeden svare på klienten (forudsat en synkron påkaldelse) med en fejlmeddelelse, der skyldes, når meddelelsen sendt til mægleren ikke indeholder tilstrækkelig eller nøjagtig information. En anden årsag til fejl eller undtagelser vil opstå, når der betjenes anmodningen (faktisk påberåbt en procedure / metode baseret på meddelelsens nyttelast).

Routing

Routing af beskeder er forgreningslogik for meddelelser. Det forekommer på to forskellige niveauer i en meddelelse. Den første routing på headerniveau bestemmer, om en indgående besked er bundet til denne applikation eller skal sendes igen til en anden applikation. Den anden, nyttelastruteing, bestemmer hvilken procedure eller metode, der skal påberåbes, når mægleren bestemmer, at meddelelsen er bundet til denne applikation. Tilsammen muliggør disse to typer routing et stort sæt funktionalitet, når man beskæftiger sig med beskeder.

Påkaldelse

Invokation betyder faktisk at ringe eller påkalde en metode med de data (nyttelast), der er indeholdt i den indgående besked. Dette kan give et resultat, som derefter returneres gennem mægleren tilbage til klienten. Det, der påberåbes, kan være hvad som helst, inklusive en EJB Session bønne, klassemetode osv.

Transformation

Transformation konverterer eller kortlægger meddelelsen til et andet format. Med XML bruges XSLT ofte til at udføre transformationsfunktionalitet.

Et eksempel på en XML-besked

Nedenfor finder du en XML-besked, der bruges i den følgende applikationsapplikation. Læg mærke til overskrift og kropsdele. Dette eksempel er en "saveInvoice" type besked, hvor kroppen indeholder en faktura, der skal gemmes.

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

Du undrer dig måske over, om der er en fordel ved at udvikle en brugerdefineret XML-besked. Hvorfor ikke bruge en af ​​de eksisterende meddelelsesstandarder som ebXML eller SOAP til at indkapsle nyttelasten (fakturaen)? Der er et par grunde. Den første er at demonstrere noget af det indhold, der er nødvendigt i en besked uden al kompleksiteten ved at forklare en fuldt ud sprængt industristandard. For det andet, selvom de eksisterende standarder udfylder de fleste behov, vil der stadig være scenarier, hvor brug af en brugerdefineret meddelelse bedre passer til behovene i en situation, ligesom afvejningen mellem at bruge en højere protokol som HTTP eller SMTP og at bruge rå sockets.

En prototype XML-mæglerimplementering

Efter at have diskuteret årsagerne til at bruge et messaging-design i din applikation, vil vi nu gå videre til implementering af en prototype XML-messaging-mægler.

Hvorfor skal du udvikle en tilpasset meddelelsesmæglerimplementering i stedet for at bruge en eksisterende? Fordi mange af implementeringerne til XML-messaging-produkter er nye, så det er vigtigt at vide, hvad der ligger i en grundlæggende implementering. Det er også muligt, at fordi XML-beskedmæglere er noget umodne produkter, skal du udvikle dine egne for at få de funktioner, du ønsker.

Den grundlæggende mægler, der præsenteres her, kan betjene to typer meddelelser: en anmodning om at oprette en faktura, som den gemmer på filsystemet, og en klientkodekomponent, der bare læser XML-beskeden fra en fil og sender den.

Mægleren består af tre hoveddele: et lytterstykke, der modtager indgående meddelelser på en eller anden transport (i dette eksempel vil der kun være en HTTP-implementering); det vigtigste mæglerstykke, der bestemmer, hvad de skal gøre med en indgående besked; og påkaldsstykket, der faktisk udfører en vis logik baseret på den indgående besked. Lad os se nærmere på hver enkelt.

Modtag beskeden fra transporten

En meddelelse møder først mæglerens lytterdel. De fleste XML-meddelelsesmæglere yder support til mange forskellige transporter (protokoller) såsom HTTP, SMTP, JMS (en bestemt leverandørs implementering) osv. Vores mægler tillader dette ved at isolere transportdelen. Stykket vist nedenfor modtager simpelthen beskeden på en given transport, placerer den indgående besked i en strengvariabel og kalder mægleren singleton:

$config[zx-auto] not found$config[zx-overlay] not found