Les Middleware Orientés Messages (MOM) - Une introduction aux MOM

Sommaire

Message Oriented Middleware

Technique

Blog

Logiciel (rss 2.0)

Liens

Les Middleware Orientés Messages

Une introduction aux Message Oriented Middleware (MOM)

La communication en mode message, les Middleware Orientés Messages.

Voir aussi Télécharger les programmes d'exemple JMS

Configurer Xinetd pour IBM WebSphere MQ

Résumé:

Ces pages décrivent ce que sont les Message Oriented Middleware (MOM), appelés aussi parfois Brokers de messages, ainsi que l'API standard d'utilisation de ces middlewares dans le monde Java et Java EE, (Appelée J2EE auparavant) l'API Java Message Service (JMS), spécifiée par Sun Microsystems en 1998, et implémentée depuis par les éditeurs de MOM.

Mots clés:

Message Oriented Middleware, Communication en mode message, Store and Forward, Publish/Subscribe, échanges asynchrones, Providers, Messages, Header, Properties, JMS, Java Message Service, Message Broker, connecteurs.

Les Message Oriented Middleware

Java Message Service (Sommaire)

La programmation d'une application cliente utilisant l'API JMS

Les Message Oriented Middleware

Les Middleware Orientés Messages sont des systèmes fournissant à leurs clients un service de Peer to peer.

La définition standard du terme de Peer to Peer désigne sur Internet un échange de données ou de fichiers d'un machine à une autre (en Français d'égal à égal), un MOM est un logiciel serveur dont le rôle est de fédérer l'envoi et la réception de ces messages entre les différents types d'applications.

La communication de deux applications via un Message Oriented Middleware est complètement asynchrone, c'est à dire que l'émetteur et le destinataire n'ont pas besoin d'être connectés simultanément lorsqu'ils communiquent.

La communication n'est synchrone qu'entre l'emetteur et le MOM d'une part, et le MOM et le destinataire d'autre part.

Mode de fonctionnement

Les MOM utilisent des files d'attentes ou queues par lesquelles transitent les messages. Lorsqu'un applicatif envoie un message, il se connecte au broker de messages (courtier de messages) à qui il envoie le message en précisant l'identifiant de la file d'attente. Quand le destinataire du message se connecte à son tour à l'agent de gestion des messages, le message lui est alors délivré lorsqu'il lit la file d'attente en question.

Une file d'attente peut aussi être utilisée pour plusieurs couples d'applicatifs (pas besoin de dédier une file par liaison applicative) puisque les MOM comportent différents critères de sélection de messages lors de la lecture.

Par ailleurs, comme c'est le cas pour une table d'une base de données, les messages peuvent être aussi consultés sans être lus, c'est ce qu'on appele le mode "browse".

Définitions relatives aux MOM

Les termes suivants sont utilisés dans les Middleware Orientés Message:

Middleware Orienté Message - Store and Forward
Un Middleware Orienté Message est un système qui permet de faire communiquer deux applicatifs par son intermédiaire, et ce de manière asynchrone.
Dans une telle architecture où les messages sont échangés par un intermédiaire logiciel, on parle aussi de Store and Forward: le MOM stocke le message et le route par la suite à son destinataire lorsque celui-ci le demande.
Le délai entre la phase "Store" et la phase "Forward" ne dépend que de l'application destinataire.
Ce mode de fonctionnement est à l'opposé des modes connectés de communication entre deux applications.
Provider
Un Provider dans le domaine des Message Oriented Middleware est un produit, un logiciel, qui fournit des services d'envoi/réception de messages en mode asynchrone.
Par extension, on parle de Provider JMS pour un Middleware Orienté Message qui implémente la norme JMS définie par Sun.
On utilise aussi parfois le terme de Broker, mais son utilisation ne se limite pas aux MOM: la plupart des produits d'EAI sont aussi appelés Brokers.
Message
Le message représente les informations échangées par deux applications via le MOM. Il est constitué de trois parties distinctes:
- Les données elles mêmes, on parle aussi de charge utile (ou payload)
- L'entête du message, qui comporte ses caractéristiques techniques (son identifiant, date de dépot ...)
- Ses propriétés, les caractéristiques fonctionnelles du message, qui sont différentes pour chaque application émettrice
- Données du message
  Les données d'un message sont les données applicatives échangées entre les deux logiciels qui communiquent ensemble.
  Certains messages peuvent être sans données, avec seulement une entête et des propriétés. D'autres peuvent contenir des messages textes, ou des données sérialisées comme c'est le cas avec les ObjectMessage de JMS.
  Dans tous les cas, le rôle du MOM se borne à véhiculer ces données, en aucun cas il ne doit les modifier ou les altérer.
- Entête de message
  Dans l'entête du message, on trouve: la date de dépot, le nom de la file d'attente destinataire, l'identifiant du message, et éventuellement: le nom du queue manager destinataire, l'identifiant de corrélation, la date de disponibilité, la date d'expiration, ...
- Propriétés des messages
  Les propriétés d'un message sont un ensemble de (clés, valeurs) de différents types (entier, chaine, booléen ...) qui apportent des précisions sur le message.
File d'attente (En Anglais "queue")
Une file d'attente est un espace de stockage pour les messages, limité ou non.
Topic (En Français "sujet")
Un Topic est une file d'attente particulière qui est destinée à recevoir les messages utilisés dans le mode Publish/Subscribe.
Gestionnaire de files d'attentes (Queue manager)
Un queue manager est un ensemble de files d'attentes formant un tout cohérent et géré par une ou plusieurs instances d'un MOM. Le queue manager est l'équivalent dans le monde des MOM d'une base de données dans le monde des SGBD.
Canal (Channel)
On appelle canal un lien entre deux queue manager qui communiquent et s'envoient des messages.
Noeud
Lors de la communication entre deux gestionnaires de files d'attente par le biais d'un canal, on parle de communication entre deux noeuds.
Routage
Quand un message qui est destiné à un MOM situé par exemple à New York est envoyé via le noeud du MOM situé à Paris, on parle de routage.
Le message est alors transféré par le Middleware Orienté Message vers le noeud Américain de façon transparente pour l'applicatif émetteur.
Généralement, un message devant être routé sur un autre noeud possède des caractéristiques spéciales dans son entête permettant au MOM de savoir qu'un routage est demandé.

Fonctionnalités offertes par les MOM

Les Middleware Orientés Message, outre les services d'acheminement (envoi, réception), de stockage, et de recherche des messages etc ..., offrent des services plus évolués comme:

Rendre certains messages plus prioritaires que d'autres
Compresser les données utiles du messsage
Faire expirer un message à une date donnée
Ne rendre un message disponible qu'à partir d'une certaine date (sur certains MOM uniquement)
Des services de routage des messages d'un noeud à l'autre (un peu à la manière des serveurs de mails)
Des fonctionnalités de triggering: lancement d'applications lorsque des messages sont disponibles pour elle
Des possibilités d'alertes suivant la présence de messages dans une file donnée ou suivant un nombre de messages donné.

Attention, la compression n'est pas implémentée par tous les MOM. Par exemple ActiveMQ permettent de compresser les messages, mais MQ Series requiert que ce soit l'application qui se charge de compresser le message si elle le souhaite.

Les messages disponibles à partir d'une certaine date constituent également une fonctionnalité optionnelle offerte par certains MOM comme Synchrony Messaging.

Domaines d'utilisation

Les Middleware Orientés Message sont très utilisés dans le domaine de l'EAI (Enterprise Application Integration) ainsi que dans les ESB (Enterprise Service Bus).

Les autres secteurs utilisateurs de MOM incluent, par exemple, le Data Warehouse, les messageries inter-bancaires (par exemple le broker de messages open source AMQ) ainsi que la diffusion d'informations.

Avantages des MOM

La communication en mode message via un MOM présente l'avantage de ne pas attendre des applicatifs destinataires des messages de fonctionner en permanence ; seul le MOM doit rester actif.

L'autre avantage de ce mode de communication est d'éviter d'implémenter pour chaque type de communication un service spécifique: chaque application s'adresse au serveur de messages et utilise donc toujours les APIs de ce dernier.

De plus, les MOM sont des logiciels portés sur de nombreux systèmes d'exploitation et proposant des API dans plusieurs langages, ce qui facilite la connectivité entre des applications hétérogènes qui tournent sur des systèmes d'exploitation aussi divers qu'Unix, Windows ou MVS.

C'est ainsi que l'on a vu disparaitre progressivement des systèmes d'informations les multiples interfaces entre applications formant ce qu'on a appelé alors "le plat de spaghettis", dans les débuts de l'EAI.

Un autre avantage des MOM est qu'ils sont insensibles (au moins temporairement) à l'indisponibilité des applications, en ce sens que dès qu'un message est envoyé au MOM ou reçu par l'applicatif, cet applicatif peut s'arrêter, puisque la connexion entre l'application et le MOM n'est requise que pendant l'échange du message.

De plus, dans le cas où le MOM a la charge de lancer les applicatifs consommateurs des messages, des mécanismes de ré-essai sont généralement en place pour relancer l'applicatif si celui-ci venait à ne pas répondre la première fois.

Inconvénients des Message Oriented Middleware

L'inconvénient que l'on peut trouver aux MOM est précisément de devoir installer et configurer un composant logiciel supplémentaire pour faire communiquer plusieurs applications.

Cette contrainte est largement contrebalancée par le fait qu'avec un MOM, on s'affranchit alors de l'implémentation de la couche d'envoi/réception de messages au sein même des applicatifs.

De la même façon, si l'on devait écrire une base de données chaque fois que l'on a besoin des services d'un tel middleware, on serait rapidement embêté !

On critique ensuite les MOM pour leur manque de standards.

Cette critique n'est pas recevable dans la mesure où la plupart des MOM actuels implémentent tous l'interface JMS, qui est le standard pour la communication en mode message en Java.

Différences avec les serveurs de Mails

Les Messages Oriented Middleware font communiquer entres eux des applicatifs ou des composants logiciels, alors qu'avec les serveurs de Mails, on trouve généralement un être humain à l'un ou l'autre bout de la chaine.

Ensuite, les serveurs de Mails ne sont pas faits pour envoyer des messages trop volumineux, contrairement aux MOM qui savent le faire. Les MOM sont conçus pour être fiables et robustes mais aussi rapides, ce qui est beaucoup moins le cas avec les serveurs Mail.

Enfin, les MOM fonctionnent généralement suivant deux modes, le mode persistant ou les messages sont stoqués sur disque et le mode non persistant où ils résident en mémoire ; ce dernier étant très performant.

Néanmoins, les deux systèmes présentent des similitudes, comme la notion de destinataires, ou d'entêtes de messages, à tel point qu'il n'est pas rare de rencontrer des "bridges" de communication entre Middleware Orientés Messages et serveurs de Mails.

Quelques Middleware Orientés Message

Les principaux MOM du marché

MQ Series d'IBM qui se nomme désormais WebSphere MQ.

La dernière version de WebSphere MQ est la version 6.0.

Sonic MQ (Progress Software).

Les Middleware Orientés Message dans le domaine de l'Open Source

Active MQ qui fait partie du projet Geronimo d'Apache.

Le Queue Manager Joram maintenant intégré dans le serveur d'applications Jonas de l'Inria.

OpenJMS, le premier Middleware Orienté Message compatible JMS en Open Source.

Les implémentations de JMS

Les implémentations connues de la norme JMS.

Liens sur le Message Queueing

Le Message Queueing dans l'annuaire Google.

Voir aussi Java Message Service,

et Exemples de code avec JMS