XML съобщения, част 1

XML съобщенията представляват бързо нарастваща, динамична област на ИТ, ситуация, която я прави вълнуваща и уморителна в същото време. С нарастването на B2B обмена и други форми на междубизнес електронна комуникация, XML съобщенията ще бъдат разгърнати по-широко от всякога.

Прочетете цялата поредица „XML съобщения“:

  • Част 1: Напишете прост посредник на XML съобщения за персонализирани XML съобщения
  • Част 2: XML съобщения SOAP начин
  • Част 3: JAXM и ebXML задават новия стандарт за XML съобщения

В тази статия първо ще разгледаме XML съобщенията и защо е полезно. След това ще се задълбочим в специфични функции за XML съобщения, включително маршрутизиране на съобщения, трансформация и посредничество. Накрая ще завършим с прост пример за XML брокер. След като прочетете и разберете концепциите, трябва ясно да разберете кои сценарии се поддават на внедряване на XML решение за съобщения.

Какво представлява XML съобщенията?

За да започнем нашето изследване, трябва да разберем основната предпоставка за XML съобщенията и какво означава терминът съобщения . За целите на тази статия определям съобщението, както следва:

Колекция от полета за данни, изпратени или получени заедно между софтуерни приложения. Съобщението съдържа заглавка (която съхранява контролна информация за съобщението) и полезен товар (действителното съдържание на съобщението).

Съобщенията използват съобщения за комуникация с различни системи, за да изпълняват някаква функция. Ние наричаме комуникацията ориентирана към съобщения, защото бихме изпращали и получавали съобщения, за да извършим операцията, за разлика от RPC (Remote Procedure Call) ориентирана комуникация. Една проста аналогия може да помогне: мислете за съобщения като имейл за приложения. Всъщност, съобщенията притежават много от атрибутите на хората, изпращащи имейл съобщения един към друг.

В миналото, когато сте използвали или работите върху система, ориентирана към съобщения, това означава, че използвате някакъв продукт на MOM (ориентиран към съобщения междинен софтуер) като Rendezvous на Tibco, MQSeries на IBM или JMS доставчик за изпращане на съобщения в асинхронна (еднопосочна) мода. Съобщенията днес не означават непременно, че използвате MOM продукт и не означава непременно, че комуникирате асинхронно. По-скоро съобщенията могат да бъдат синхронни (двупосочни) или асинхронни и да използват много различни протоколи като HTTP или SMTP, както и MOM продукти.

Защо XML съобщения?

Защо искате да разработите система, използваща съобщения? Какво прави съобщенията полезна техника за проектиране и какви са предимствата? Както споменахме по-рано, можем да избираме от две алтернативи, когато изискваме две приложения за разговор помежду си по мрежа: RPC или ориентирани към съобщения. Използването на RPC-базиран подход (RMI попада в тази категория) означава, че клиентът (или повикващият) на извикването на процедурата знае процедурата, която иска да извика, и знае параметрите, които желае да предаде на процедурата. Освен това повикващият желае да изчака, докато извиканият сървър (приложението) изпълни заявката.

При втория подход - ориентиран към съобщения - повикващият не знае непременно точната процедура, която ще бъде извикана, а вместо това създава съобщение от определен формат, известен както на клиента, така и на сървъра. Клиентът създава съобщението и след това го изпраща на сървъра по мрежата. Следователно клиентът не зависи от сървъра или процедурите на сървъра, но зависи от формата на съобщението. Също така комуникацията вероятно се осъществява по асинхронен начин, което означава, че клиентът ще изпрати заявка, но няма да чака (блокира) отговора. Това позволява на клиента да продължи да функционира, дори ако сървърът стане недостъпен (например се срива). Този дизайн, при който клиентът е по-независим от сървъра, се счита за по-свободно свързан.

Когато оценявате дали да използвате дизайн, ориентиран към съобщения, е важно да разберете плюсовете и минусите на такава система. Плюсовете включват:

  • Разхлабено съединение
  • По-лесно маршрутизиране и трансформиране на съобщения
  • По-гъвкав полезен товар (може да включва двоични прикачени файлове, например)
  • Може да използва няколко съобщения заедно, за да извика дадена процедура

Като цяло подходът, ориентиран към съобщенията, се оказва по-гъвкав от RPC подхода.

Ето няколко минуса:

  • Изисква повече работа за разработване на взаимодействие клиент / сървър, използвайки подход, ориентиран към съобщения, в сравнение с RPC подход като RMI, тъй като разработването на взаимодействие клиент / сървър чрез съобщение представлява друго ниво на непрякост от RPC. Сложността се добавя чрез създаването на съобщението от страна на клиента (срещу извикване на процедура при RPC подход) и от страна на сървъра с код за обработка на съобщения. Поради допълнителната си сложност, дизайнът, ориентиран към съобщения, може да бъде по-труден за разбиране и отстраняване на грешки.
  • Съществува риск от загуба на информация за типа за програмния език, на който е изпратено съобщението. Например, двойно в Java може да не се превежда като двойно в съобщението.
  • В повечето случаи транзакционният контекст, в който е създадено съобщението, не се разпространява към сървъра за съобщения.

Имайки предвид плюсовете и минусите, кога трябва да използвате ориентиран към съобщенията подход? Най-често срещаният сценарий възниква, когато комуникацията клиент / сървър се осъществява през Интернет и клиентът и сървърът принадлежат на различни компании. В този сценарий би могло да бъде доста трудно двете компании да се споразумеят за интерфейса на процедурата. Също така е възможно компаниите да не искат да използват същия език за програмиране. В друг пример, участващите компании може да искат да използват асинхронен комуникационен модел, така че нито един от двамата да не зависи от приложението на другия, което работи и работи.

Друг привлекателен сценарий за съобщения възниква, когато разработвате система, базирана на събития, в която събитията се създават и след това се консумират от заинтересованите страни. Повечето графични интерфейси са базирани на събития. Например, те могат да създадат събитие с щракване на мишката, в което заинтересованите страни да слушат събитието и да извършат някакво действие въз основа на него. В този сценарий използването на подход за съобщения ви позволява да премахнете зависимостта между събитие (или действие в системата) и реакцията на системата към събитието, което се извършва на сървъра.

Сега, след като разбрахме малко за съобщенията, сме готови да добавим XML към уравнението. Добавянето на XML към съобщенията означава, че можем да използваме гъвкав език за форматиране на данни за нашите съобщения. При съобщенията и клиентът, и сървърът трябва да се споразумеят за формата на съобщението. XML улеснява това, като решава много проблеми с форматирането на данни и с добавянето на други XML стандарти като Rosetta Net. Не се изисква допълнителна работа, за да се излезе формат на съобщението.

Какво прави брокерът на XML съобщения?

Брокерът на съобщения действа като сървър в система, ориентирана към съобщения. Софтуерът на посредника за съобщения извършва операции върху съобщенията, които получава. Тези операции включват:

  • Обработка на заглавката
  • Проверки за сигурност и криптиране / дешифриране
  • Обработка на грешки и изключения
  • Маршрутизиране
  • Призоваване
  • Трансформация

Обработка на заглавката

Header processing is usually one of the first functions performed in the message upon its receipt within an XML broker. Header processing involves examining the header fields of incoming messages and performing some functions. Header processing could include adding a tracking number to an incoming message or ensuring that all of the header fields necessary to process the message exist. In the example XML message below, the message broker could check the to header field to ensure that this is the proper destination for this message.

Security checks and encryption/decryption

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

Съобщение първо ще срещне частта на слушателя на брокера. Повечето брокери на XML съобщения предоставят поддръжка за много различни транспорти (протоколи) като HTTP, SMTP, JMS (изпълнение на конкретен доставчик) и т.н. Нашият брокер позволява това, като изолира транспортната част. Показаното по-долу парче просто получава съобщението на даден транспорт, поставя входящото съобщение в променлива низ и извиква сингълтон на брокера: