Pour savoir où on va, il faut savoir d'où l'on vient

Vous avez
une question ?
Un projet ?

Contactez nous !
 

Contactez-nous

Vous avez une question ? un projet ? 
Vous souhaitez plus d'informations sur un produit ? sur notre offre ? 
Contactez-nous, on vous répond sous 4H.

retour

Les Middlewares Orientés Messages ou MOM

Les Middlewares Orientés Messages ou MOM

Définition

On l’a vu, les MOMs sont des middlewares, des outils d’échange qui permettent à des applications de communiquer en échangeant des messages. Une application « A » doit adresser un message à une application « B », qui tourne (peut-être) sur un serveur différent. L’application « A » confie son message au MOM, qui se charge de l’acheminer et de le remettre à l’application « B ».

L’objet véhiculé par le MOM entre deux applications est appelé message. Mais rien n’est imposé quant à ce que représente ce message, sa taille, ou encore le format des données qu’il véhicule. Pour l’essentiel, ces questions ne concernent que l’application « A » et l’application « B », qui doivent partager un certain nombre de conventions, afin de se comprendre.

Le MOM, quant à lui, ne s’intéresse donc pas au contenu du message, il ne fait que le transmettre, et il le remet au destinataire sans y avoir apporté de changement.

MOM, EAI, ESB

À la différence d’un MOM, un outil d’EAI ( Enterprise Application Integration), est aussi en charge de réaliser transformations sur les informations portées par les messages, afin d’adapter les données de l’émetteur aux formats gérés par le destinataire.

Un EAI englobe donc les fonctionnalités du MOM, et y ajoute des possibilités facilitant l’intégration des applications au niveau des données transférées.

Dans un MOM, comme on l’ a vu, les applications doivent parler le même langage, tandis qu’un EAI au contraire prend en charge les traductions entre représentations différentes.

Un EAI est donc un middleware qui a comme principales fonctions :

  • L’interconnexion des systèmes hétérogènes.
  • La gestion de la transformation des messages.
  • La gestion du routage des messages.

L’ESB, Enterprise Service Bus, est un concept plus ambitieux encore, qui se présente comme le socle uniforme d’une architecture SOA globale. Là où l’EAI peut prendre en charge des transformations de formats permettant à une application A d’interopérer avec une application B, l’ESB généralise le concept, en posant pour principe qu’ il suffit qu’une application A soit interfacée à l’ESB pour qu’elle puisse interopérer par son intermédiaire avec toute autre application interfacée à l’ESB. Et par ailleurs, la connexion à l’ESB n’est pas exclusivement à base de messages, elle doit supporter une grande diversité de modes d’échange et de protocoles.

EDA, Event Driven Architecture

Puisque nous évoquons quelques acronymes en vogue, il faut parler aussi du concept EDA, « Event-Driven Architecture », architecture pilotée par les événements, qui est à certains égards une alternative à l'approche SOA.

L'approche EDA part de l'idée que tout traitement est d'une certaine manière exécuté en réaction à un événement. Et bien sûr, tout traitement est par ailleurs générateur d'événements. Ainsi, la vente d'un produit est un événement, qui induit un ensemble de traitements relatifs par exemple à la gestion des stocks, à la comptabilité, à la logistique, à la relation client, etc. Tout est événement, tout est réaction à des événements, et il en va de même pour nous-mêmes, êtres humains, qui agissons en réaction à un ensemble de stimuli externes.

Dans l'approche EDA, la réaction à un événement n'est pas un traitement synchrone. Elle peut avoir des exigences de rapidité, mais elle est par essence asynchrone. Alors que l'approche SOA, même si elle peut se décliner dans une logique asynchrone, est malgré tout par essence une approche synchrone. Et bien sûr, les MOMs sont le support naturel d'une approche EDA.

Un dernier acronyme à trois lettres pour la route: CEP, pour « Complex Event Processing », traitement d'événements complexes, consiste à identifier, puis traiter, des événements complexes à partir d'une combinaison d'événements simples. C'est donc un concept complémentaire à l'approche EDA, partant du principe qu'il ne suffit pas de réagir à des événements individuels, il faut être en mesure d'identifier des événements de plus haut niveau, comme résultante d'événements élémentaires. Par exemple: un ordre de vente, plus un autre ordre de vente, plus encore un ordre de vente... égal une crise financière, événement complexe, s'il en est !

Des échanges asynchrones

Les échanges de messages mis en œuvre par les MOMs sont asynchrones. Cela signifie que les applications ne sont pas en attente d’une réponse à leur message. En fait, il est possible qu’un message de réponse soit attendu, mais dans ce cas il n’y a pas de délai garanti pour cette réponse, de sorte que l’application ne doit pas se bloquer en attente de la réponse, et encore moins faire attendre un utilisateur. Le caractère asynchrone ne dit rien quant au délai d’acheminement du message : il peut être très rapide, de quelques millisecondes à peine, mais il ne doit pas être considéré comme assuré.

Des échanges fiables

L’une des qualités attendues des MOMs est de garantir l’acheminement des messages quelles que soient les circonstances, les aléas, et en particulier y compris dans le cas où la connectivité réseau est interrompue, où le serveur distant est arrêté, ou bien où l’application destinatrice n’est pas en mesure de réceptionner les messages. Dans tous ces cas de figure, le MOM doit conserver les messages qui lui sont confiés jusqu’à ce qu’ils aient été remis, et même, jusqu’à ce qu’ils aient été correctement traités par l’application destinatrice.

Nous verrons que cette fiabilité de l'acheminement peut être rendue plus ou moins forte, selon les paramètres et la configuration du MOM.

Les échanges à base de MOM ne sont pas, par nature, en mode requête / réponse, comme peut l’être un échange HTTP par exemple. Il est possible bien sûr que l’application destinatrice émette à son tour un message, que l’on peut considérer comme une réponse, mais il s’agit alors seulement d’une utilisation particulière du MOM.

Brokers

Les brokers sont des programmes gérant le flux de messages. En d'autres termes, un MOM est composé d'un ou de plusieurs brokers. Comme le montre la figure suivante, c'est avec les brokers que les applications clientes communiquent, au travers de l’API.

Brokers

Un broker est un serveur au sens logiciel du terme, c'est-à-dire un processus qui est à l’écoute des requêtes qui peuvent lui être adressées par d’autres processus, les applications clientes.

Une plateforme MOM ou plateforme middleware est donc constitué d’un ensemble des brokers et des passerelles.

Protocoles et APIs

Lorsqu’une application échange avec un broker, par exemple pour lui remettre un message, et de même lorsqu’un broker échange avec un autre broker, ces échanges mettent en œuvre un protocole réseau. Le protocole définit les commandes invoquées et leurs paramètres, ainsi que la représentation des données, entêtes et corps, constituant les messages.

Protocoles et APIs

Ce protocole est généralement invisible pour les applications, qui ne voient que des appels de fonctions, des APIs. Et de même, pour ce qui est des échanges entre deux brokers d’un même MOM, le protocole peut être considéré comme une affaire privée, interne, relevant purement de l’implémentation du MOM. C’est pourquoi on s’intéresse généralement davantage à l’ouverture des MOMs en termes d’APIs qu’en termes de protocoles d’échange.

Pourquoi un MOM open source ?

Un middleware est nécessairement structurant pour les applications qui en font usage, c'est-à-dire que les applications seraient un peu différentes si elles utilisaient un autre middleware, et en conséquence, changer de middleware pourrait impliquer des changements sur toutes les applications, avec donc un coût important.

En conséquence, il est clair que l'on ne souhaite pas avoir à changer de middleware, et qu'il vaut mieux éviter aussi d'avoir un fournisseur en position de tirer profit de cette dépendance.

C'est une des raisons pour lesquelles les solutions open source sont naturellement à privilégier pour cette typologie d'outils.

Et c'est pourquoi aussi les grands acteurs de l'open source ont depuis longtemps placé les middleware au premier rang de leurs priorités, ce qui explique que l'on ait aujourd'hui un large choix de produits de qualité, comme on le verra.

Il faut « rendre à César ce qui appartient à César », et rappeler que le père de tous les MOMs est sans doute le produit MQSeries, de IBM, aujourd'hui renommé « Websphere MQ », un produit introduit dans les années 90, et qui a rencontré un grand succès en particulier dans les banques et autres grands comptes IBM. MQSeries a posé les concepts du MOM, échanges asynchrones et fiables, en offrant par ailleurs des connecteurs pour une diversité d'environnements.

Aujourd'hui, les solutions open source sont en position de force. Elles sont généralement plus respectueuses des standards, plus ouvertes, et – pour certaines d'entre elles au moins – plus dynamiques dans leur développement. Et elles présentent un coût total de possession bien plus avantageux.

Les services d'un MOM

Le service de base d'un MOM est d'acheminer un message d'une application vers une autre.

Mais il a d'autres valeurs ajoutées, d’autres caractéristiques :

Un service fiable

Le MOM garantit à l'application A que le message qui lui est confié ne sera pas perdu. Ceci, même en présence d'incidents de différentes natures (logiciels, matériel, réseau). L'application émettrice peut compter sur le MOM, et le fait de pouvoir compter sur lui permet de simplifier la conception de l'application. On peut, à différents égards, faire un parallèle entre un MOM et une base de données. Lorsqu'une application a écrit une donnée dans un SGBD, elle peut compter que cette donnée ne sera pas perdue. Les mécanismes qui permettent d'assurer ceci peuvent être complexes, mais l'application n'a pas à s'en préoccuper. C'est la même chose pour un MOM. Le MOM peut donc être utilisé y compris pour transporter des objets critiques, des transactions financières par exemple. Nous verrons plus loin que l'on peut, dans certains contextes d'utilisation, choisir de se passer de cette fiabilité.

Un service asynchrone

L'application A confie son message au MOM, à destination de l'application B. Mais l'application B est peut-être saturée, ou bien arrêtée, son serveur est peut-être en panne, ou bien injoignable. Rien de tout cela ne pose problème: le MOM attendra. Que le réseau remarche, que le serveur soit en état, que l'application soit lancée. Il attendra jusqu'à avoir pu remettre le message à son destinataire. Et même un peu plus: jusqu'à ce que son destinataire ait indiqué que le message a pu être traité avec succès.

Une indirection de nommage

Nous avons jusqu'ici fait comme si l'application A remettait au MOM un message « à destination de l'application B ». Ce n'est pas tout à fait exact, et la nuance est importante. L'application A remet au MOM un message à destination d'une file d'attente, d'une queue. Et une application B (mais peut-être aussi différentes applications B1, B2, …) peut lire les messages de cette queue, selon des modalités que nous verrons plus en détail. Cette indirection est importante: l’application A ne connait pas l'application B, ne connait ni son « nom », ni le serveur sur lequel elle tourne, ni dans quel sous-réseau ce serveur peut se trouver. Néanmoins, le message sera remis à l'application B. On voit que le principe de couplage lâche n'est pas que dans le caractère asynchrone, il est important également en ce qui concerne l'identification des applications prenant part aux échanges.

Pas de transformation des données

À la différence d'autres middleware, et en particulier la famille des ORB, les MOMs ne prennent pas en charge de transformation de la représentation des données. Le MOM reçoit un message d'une application A, et le remet tel quel, inchangé, à une application B. Les applications échangeant grâce au MOM doivent donc « parler le même langage », c'est-à-dire représenter leurs objets (chaînes, nombres, matrices, classes, dates, etc.) de la même manière, au sein des messages, pour se comprendre.

Autres services

Nous verrons que la gestion de la répartition de charge et la gestion du secours sont extrêmement faciles à mettre en œuvre au moyen d'un MOM. La possibilité d'avoir plusieurs applications lisant et traitant les messages sur une même queue, implémente une répartition de charge très simple, mais très efficace.