Messagerie XML, partie 1

La messagerie XML représente un domaine informatique dynamique en pleine croissance, une situation qui la rend à la fois passionnante et fastidieuse. Au fur et à mesure que les échanges B2B et d'autres formes de communication électronique interentreprises se développent, la messagerie XML sera plus largement déployée que jamais.

Lisez toute la série «Messagerie XML»:

  • Partie 1: rédiger un courtier de messages XML simple pour les messages XML personnalisés
  • Partie 2: Messagerie XML à la manière SOAP
  • Partie 3: JAXM et ebXML définissent la nouvelle norme pour la messagerie XML

Dans cet article, nous allons d'abord explorer la messagerie XML et pourquoi elle est utile. Ensuite, nous explorerons les fonctionnalités de messagerie XML spécifiques, notamment le routage, la transformation et le courtage des messages. Enfin, nous terminerons avec un exemple simple de courtier XML. Après avoir lu et compris les concepts, vous devez clairement comprendre quels scénarios se prêtent à l'implémentation d'une solution de messagerie XML.

Qu'est-ce que la messagerie XML?

Pour commencer notre exploration, nous devons comprendre les principes de base de la messagerie XML et ce que le terme messagerie implique. Aux fins de cet article, je définis le message comme suit:

Une collection de champs de données envoyés ou reçus ensemble entre des applications logicielles. Un message contient un en-tête (qui stocke des informations de contrôle sur le message) et une charge utile (le contenu réel du message).

La messagerie utilise des messages pour communiquer avec différents systèmes afin d'exécuter une sorte de fonction. Nous nous référons à la communication comme étant orientée message car nous enverrions et recevions des messages pour effectuer l'opération, contrairement à une communication orientée RPC (Remote Procedure Call). Une simple analogie peut aider: pensez à la messagerie comme au courrier électronique pour les applications. En effet, la messagerie possède de nombreux attributs d'individus qui s'envoient des e-mails.

Dans le passé, lorsque vous utilisiez ou travailliez sur un système orienté message, cela signifiait que vous utilisiez une sorte de produit MOM (middleware orienté message) comme Rendezvous de Tibco, MQSeries d'IBM ou un fournisseur JMS pour envoyer des messages dans un mode asynchrone (unidirectionnel). La messagerie d'aujourd'hui ne signifie pas nécessairement que vous utilisez un produit MOM, et cela ne signifie pas nécessairement que vous communiquez de manière asynchrone. Au contraire, la messagerie peut être synchrone (bidirectionnelle) ou asynchrone et utiliser de nombreux protocoles différents tels que HTTP ou SMTP, ainsi que des produits MOM.

Pourquoi la messagerie XML?

Pourquoi voudriez-vous développer un système utilisant la messagerie? Qu'est-ce qui fait de la messagerie une technique de conception utile et quels en sont les avantages? Comme mentionné précédemment, nous pouvons choisir entre deux alternatives lorsque deux applications doivent se parler sur un réseau: RPC ou orientée message. L'utilisation d'une approche basée sur RPC (RMI entre dans cette catégorie) signifie que le client (ou l'appelant) de l'appel de procédure connaît la procédure qu'il souhaite invoquer et connaît les paramètres qu'il souhaite transmettre à la procédure. En outre, l'appelant souhaite attendre que le serveur appelé (l'application) termine la demande.

Dans la seconde approche - orientée message - l'appelant ne connaît pas nécessairement la procédure exacte qui sera appelée, mais crée à la place un message d'un format spécifique connu à la fois du client et du serveur. Le client crée le message, puis l'envoie au serveur sur le réseau. Par conséquent, le client ne dépend pas du serveur ou des procédures du serveur, mais dépend du format du message. En outre, la communication se déroule probablement de manière asynchrone, ce qui signifie que le client enverra une demande mais n'attendra pas (bloquera) la réponse. Cela permet au client de continuer à fonctionner même si le serveur devient indisponible (plante, par exemple). Cette conception, où le client est plus indépendant du serveur, est considérée comme plus faiblement couplée.

Lorsque vous évaluez s'il faut utiliser une conception orientée message, il est important de comprendre les avantages et les inconvénients d'un tel système. Les avantages incluent:

  • Couplage lâche
  • Routage et transformation des messages plus faciles
  • Charge utile plus flexible (peut inclure des pièces jointes binaires, par exemple)
  • Peut utiliser plusieurs messages ensemble pour appeler une procédure donnée

En général, une approche orientée message s'avère plus flexible qu'une approche RPC.

Voici maintenant quelques inconvénients:

  • Il faut plus de travail pour développer une interaction client / serveur en utilisant une approche orientée message par rapport à une approche RPC comme RMI car le développement d'une interaction client / serveur via un message représente un autre niveau d'indirection de RPC. La complexité est ajoutée par la création du message côté client (par opposition à un appel de procédure dans une approche RPC) et côté serveur avec le code de traitement des messages. En raison de sa complexité supplémentaire, une conception orientée message peut être plus difficile à comprendre et à déboguer.
  • Il existe un risque de perdre des informations de type pour le langage de programmation dans lequel le message a été envoyé. Par exemple, un double en Java peut ne pas se traduire par un double dans le message.
  • Dans la plupart des cas, le contexte transactionnel dans lequel le message a été créé ne se propage pas au serveur de messagerie.

Compte tenu des avantages et des inconvénients, quand devriez-vous utiliser une approche orientée message? Le scénario le plus courant se produit lorsque la communication client / serveur a lieu sur Internet et que le client et le serveur appartiennent à des sociétés différentes. Dans ce scénario, il pourrait être assez difficile d'amener les deux sociétés à s'entendre sur l'interface de procédure. En outre, il est possible que les entreprises ne veuillent pas utiliser le même langage de programmation. Dans un autre exemple, les entreprises impliquées peuvent souhaiter utiliser un modèle de communication asynchrone afin qu'aucune ne dépende de la mise en service de l'application de l'autre.

Un autre scénario de messagerie intéressant se produit lorsque vous développez un système basé sur des événements dans lequel les événements sont créés puis consommés par les parties intéressées. La plupart des interfaces graphiques sont basées sur des événements. Par exemple, ils peuvent créer un événement de clic de souris dans lequel les parties intéressées écoutent l'événement et effectuent une action en fonction de celui-ci. Dans ce scénario, l'utilisation d'une approche de messagerie vous permet de supprimer la dépendance entre un événement (ou une action dans un système) et la réaction du système à l'événement qui est effectué sur le serveur.

Maintenant que nous comprenons un peu la messagerie, nous sommes prêts à ajouter du XML à l'équation. L'ajout de XML à la messagerie signifie que nous pouvons utiliser un langage de formatage de données flexible pour nos messages. Dans la messagerie, le client et le serveur doivent s'accorder sur un format de message. XML facilite cela en résolvant de nombreux problèmes de formatage des données et en ajoutant d'autres normes XML telles que Rosetta Net. Aucun travail supplémentaire n'est requis pour créer un format de message.

Que fait un courtier de messages XML?

Un courtier de messages agit en tant que serveur dans un système orienté messages. Le logiciel de courtage de messages effectue des opérations sur les messages qu'il reçoit. Ces opérations comprennent:

  • Traitement des en-têtes
  • Contrôles de sécurité et cryptage / décryptage
  • Gestion des erreurs et des exceptions
  • Routage
  • Invocation
  • Transformation

Traitement des en-têtes

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

Un message rencontrera d'abord la partie écouteur du courtier. La plupart des courtiers de messages XML prennent en charge de nombreux transports (protocoles) tels que HTTP, SMTP, JMS (implémentation d'un fournisseur particulier), etc. Notre courtier permet cela en isolant la partie transport. La pièce ci-dessous reçoit simplement le message sur un transport donné, place le message entrant dans une variable de chaîne et appelle le singleton du courtier: