XML poruke, 1. dio

XML poruke predstavljaju brzo rastuće, dinamično područje IT-a, što ga čini istovremeno uzbudljivim i zamornim. Kako B2B razmjene i drugi oblici među-poslovne elektroničke komunikacije rastu, XML poruke bit će raspoređivane šire nego ikad.

Pročitajte cijelu seriju "XML poruke":

  • 1. dio: Napišite jednostavan posrednik XML poruka za prilagođene XML poruke
  • Dio 2: XML slanje poruka putem SOAP-a
  • Dio 3: JAXM i ebXML postavljaju novi standard za XML poruke

U ovom ćemo članku prvo istražiti XML poruke i zašto su korisne. Zatim ćemo se pozabaviti određenim značajkama razmjene poruka XML, uključujući usmjeravanje, transformaciju i posredovanje poruka. Na kraju ćemo završiti s jednostavnim primjerom XML brokera. Nakon što pročitate i razumijete koncepte, trebali biste jasno razumjeti koji se scenariji mogu implementirati u XML rješenje za razmjenu poruka.

Što su XML poruke?

Da bismo započeli istraživanje, moramo razumjeti osnovnu pretpostavku XML poruka i što pojam poruka podrazumijeva. U svrhu ovog članka, definiram poruku kako slijedi:

Zbirka podatkovnih polja poslanih ili primljenih zajedno između softverskih aplikacija. Poruka sadrži zaglavlje (u kojem se nalaze kontrolni podaci o poruci) i korisni teret (stvarni sadržaj poruke).

Poruke koriste poruke za komunikaciju s različitim sustavima kako bi izvršile neku vrstu funkcije. Komunikaciju nazivamo orijentiranom na poruke jer bismo slali i primali poruke da bismo izvršili operaciju, za razliku od komunikacije usmjerene na RPC (daljinski postupak). Jednostavna analogija može vam pomoći: razmjenjujte poruke kao e-poštu za programe. Zapravo, razmjena poruka posjeduje mnoge atribute pojedinaca koji jedni drugima šalju poruke e-pošte.

U prošlosti, kada ste koristili ili radili na sustavu usmjerenom na poruke, to je značilo da ste za slanje poruka u asinkrona (jednosmjerna) moda. Poruke danas ne moraju nužno značiti da koristite MOM proizvod i ne znači nužno da komunicirate asinkrono. Umjesto toga, razmjena poruka može biti sinkrona (dvosmjerna) ili asinkrona i koristiti mnogo različitih protokola kao što su HTTP ili SMTP, kao i MOM proizvode.

Zašto XML poruke?

Zašto biste željeli razviti sustav koji koristi poruke? Što čini razmjenu poruka korisnom tehnikom dizajna i koje su prednosti? Kao što je ranije spomenuto, možemo birati između dvije mogućnosti kada su nam potrebne dvije aplikacije za međusobni razgovor putem mreže: RPC ili orijentirane na poruke. Korištenje pristupa temeljenog na RPC-u (RMI spada u ovu kategoriju) znači da klijent (ili pozivatelj) poziva procedure zna proceduru koju želi pozvati i zna parametre koje želi proslijediti proceduri. Također, pozivatelj želi pričekati dok pozvani poslužitelj (aplikacija) dovrši zahtjev.

U drugom pristupu - orijentiranom na poruku - pozivatelj ne mora nužno znati točan postupak koji će se pozvati, već umjesto toga stvara poruku određenog formata poznatog i klijentu i poslužitelju. Klijent kreira poruku, a zatim je putem mreže šalje poslužitelju. Stoga klijent ne ovisi o poslužitelju ili procedurama poslužitelja, već ovisi o formatu poruke. Također, komunikacija se vjerojatno odvija na asinkroni način, što znači da će klijent poslati zahtjev, ali neće čekati (blokirati) odgovor. To omogućuje klijentu da nastavi funkcionirati čak i ako poslužitelj postane nedostupan (na primjer, sruši se). Smatra se da je ovaj dizajn, gdje je klijent neovisniji od poslužitelja, labavije povezan.

Pri procjeni treba li koristiti dizajn orijentiran na poruke, važno je razumjeti prednosti i nedostatke takvog sustava. Pros uključuju:

  • Labava spojnica
  • Jednostavnije usmjeravanje i transformacija poruka
  • Fleksibilniji korisni teret (na primjer, može uključivati ​​binarne privitke)
  • Može koristiti nekoliko poruka zajedno za pozivanje određenog postupka

Općenito, pristup usmjeren na poruku pokazuje se fleksibilnijim od RPC pristupa.

Evo nekoliko nedostataka:

  • Potrebno je više rada na razvoju interakcije klijent / poslužitelj korištenjem pristupa orijentiranog na poruke u usporedbi s RPC pristupom kao što je RMI, jer razvijanje interakcije klijent / poslužitelj putem poruke predstavlja još jednu razinu indirektnosti od RPC-a. Složenost se dodaje stvaranjem poruke na strani klijenta (nasuprot pozivu procedure u RPC pristupu) i na strani poslužitelja s kodom za obradu poruka. Zbog svoje dodatne složenosti, dizajn usmjeren na poruku može biti teže razumjeti i otkloniti pogreške.
  • Postoji rizik od gubitka podataka o tipu za programski jezik u kojem je poruka poslana. Na primjer, double u Javi možda se neće prevesti kao double u poruci.
  • U većini slučajeva transakcijski kontekst u kojem je poruka stvorena ne širi se na poslužitelj za razmjenu poruka.

S obzirom na prednosti i nedostatke, kada biste trebali koristiti pristup usmjeren na poruku? Najčešći se scenarij događa kada se komunikacija klijent / poslužitelj odvija putem Interneta, a klijent i poslužitelj pripadaju različitim tvrtkama. U ovom bi scenariju moglo biti prilično teško postići da se dvije tvrtke dogovore o sučelju postupka. Također, moguće je da tvrtke možda ne žele koristiti isti programski jezik. U drugom primjeru, uključene tvrtke možda će htjeti koristiti asinkroni komunikacijski model tako da niti jedan neće ovisiti o tome radi li druga aplikacija.

Još jedan atraktivan scenarij za razmjenu poruka događa se kada razvijate sustav zasnovan na događajima u kojem se događaji kreiraju, a zatim konzumiraju od zainteresiranih strana. Većina GUI-a temelje se na događajima. Na primjer, mogli bi stvoriti događaj klika miša u kojem zainteresirane strane slušaju događaj i na temelju njega izvršavaju neke radnje. U ovom scenariju, korištenje razmjene poruka omogućuje vam uklanjanje ovisnosti između događaja (ili radnje u sustavu) i reakcije sustava na događaj koji se izvodi na poslužitelju.

Sad kad malo razumijemo razmjenu poruka, spremni smo dodati XML u jednadžbu. Dodavanje XML-a porukama znači da možemo koristiti fleksibilni jezik za oblikovanje podataka za svoje poruke. U razmjeni poruka, i klijent i poslužitelj moraju se dogovoriti o formatu poruke. XML to olakšava odlučivanjem mnogih problema s formatiranjem podataka i dodavanjem drugih XML standarda poput Rosetta Net. Da bi se došlo do formata poruke nije potreban nikakav dodatni rad.

Što radi XML posrednik poruka?

Posrednik poruka djeluje kao poslužitelj u sustavu orijentiranom na poruke. Softver za posredovanje poruka izvodi radnje na porukama koje prima. Te operacije uključuju:

  • Obrada zaglavlja
  • Sigurnosne provjere i šifriranje / dešifriranje
  • Rukovanje pogreškama i iznimkama
  • Usmjeravanje
  • Pozivanje
  • Transformacija

Obrada zaglavlja

Obrada zaglavlja obično je jedna od prvih funkcija koja se izvodi u poruci nakon primitka u XML posredniku. Obrada zaglavlja uključuje ispitivanje polja zaglavlja dolaznih poruka i izvršavanje nekih funkcija. Obrada zaglavlja može uključivati ​​dodavanje broja za praćenje u dolaznu poruku ili osiguravanje da postoje sva polja zaglavlja potrebna za obradu poruke. U primjeru XML poruke u nastavku, posrednik poruka mogao bi provjeriti topolje zaglavlja kako bi osigurao da je ovo odgovarajuće odredište za ovu poruku.

Sigurnosne provjere i šifriranje / dešifriranje

From a security perspective, a message broker can perform several different operations, but most likely you'll want to accomplish the "big three" of security: authentication, authorization, and encryption. First, once it determines that the message contains data that can be used to authenticate, the message broker will authenticate messages against a security database or directory. Second, the message broker will authorize operations that can be performed with this type of message and an authorized principal. Finally, the message that arrives at the message broker may be encrypted using some encryption scheme. It will be the broker's responsibility to decrypt the message in order to process it further.

Error and exception handling

Error and exception handling is another important piece of functionality performed by the message broker. Generally, the message will respond to the client (assuming a synchronous invocation) with an error message, caused when the message sent to the broker does not contain sufficient or accurate information. Another cause for errors or exceptions would occur when servicing the request (actually invoking a procedure/method based on the payload of the message).

Routing

Message routing is branching logic for messages. It occurs at two different levels in a message. The first, header-level routing, determines if an incoming message is bound for this application or needs to be resent to another application. The second, payload routing, determines which procedure or method to invoke once the broker determines that the message is bound for this application. Together these two types of routing enable a rich set of functionality when dealing with messages.

Invocation

Invocation means to actually call or invoke a method with the data (payload) contained in the incoming message. This could produce a result that is then returned through the broker back to the client. What is invoked could be anything, including an EJB Session bean, class method, and so on.

Transformation

Transformation converts or maps the message to some other format. With XML, XSLT is commonly used to perform transformation functionality.

An example XML message

Below you'll find an XML message used in the sample application that follows. Notice the header and body portions. This example is a "saveInvoice" type of message, in which the body contains an invoice that needs to be saved.

   companyReceiver companySender saveInvoice      John Smith 123 George St. Mountain View CA 94041   Company A 100 Main St. Washington DC 20015    IBM A20 Laptop 1 2000.00       

You may wonder whether there is an advantage to developing a custom XML message. Why not use one of the existing message standards like ebXML or SOAP to encapsulate the payload (the invoice)? There are a couple of reasons. The first is to demonstrate some of the contents needed in a message without all of the complexity of explaining a full-blown industry standard. Second, although the existing standards fill most needs, there still will be scenarios in which using a custom message will better fit the needs of a situation, much like the tradeoffs between using a higher-level protocol like HTTP or SMTP and using raw sockets.

A prototype XML broker implementation

Having discussed the reasons for using a messaging design in your application, we will now proceed to a prototype XML messaging broker implementation.

Why should you develop a custom message broker implementation instead of using an existing one? Well, because many of the implementations for XML messaging products are new, so it's important to know what goes into a basic implementation. Also, it's possible that because XML message brokers are somewhat immature products, you'll need to develop your own to get the features you want.

The basic broker presented here can service two types of messages: a request to create an invoice, which it stores on the filesystem, and a client code component, which just reads the XML message from a file and sends it.

The broker comprises three main parts: a listener piece that receives incoming messages on some transport (in this example there will only be an HTTP implementation provided); the main broker piece, which will decide what to do with an incoming message; and the invocation piece that will actually perform some logic based on the incoming message. Let's look at each in more detail.

Receive the message from the transport

Poruka će prvo naići na dio slušatelja brokera. Većina XML posrednika poruka pruža podršku za mnoge različite prijenose (protokole) kao što su HTTP, SMTP, JMS (implementacija određenog dobavljača), i tako dalje. Naš broker to omogućava izoliranjem dijela za transport. Komad prikazan dolje jednostavno prima poruku na danom prijevozu, dolaznu poruku smješta u varijablu niza i poziva posrednika posrednika: