Accueil Nos publications Blog Files MQ : Notions et Outils

Files MQ : Notions et Outils

queueActuellement, les systèmes d’information doivent répondre à plusieurs problématiques dont l’une des plus importantes est d’être accessible par le plus grand nombre de vecteurs possibles. Certains de ces systèmes sont parfois anciens et se voient donc attribué une surcharge logicielle plus moderne. La question de la communication entre ces applications est au centre des préoccupations. Les files de messages, bien qu’étant un composant de base, restent tout à fait viables pour répondre à ce besoin. Nous allons explorer ensemble leur fonctionnement et les différentes solutions proposées.

Présentation

D’après le dictionnaire, une file est une suite d’éléments placés les uns derrière les autres.
MQ signifie Message queue (littéralement, queue de messages ou bien file de messages). C’est un composant logiciel permettant la communication entre applications, qui fait partie d’un groupe logiciel appelé Message Oriented Middleware (MOM). Les files sont très utilisées dans les SI lourds et/ou comportant des applications utilisant un melting pot de technologies. Par exemple, dans les systèmes bancaires, plusieurs applications ont été développées il y a quelques années avec du COBOL. Les nouvelles applications, quant à elles, ne peuvent communiquer avec le précédent système que par des moyens limités (web services, files MQ).
Quand on parle de “file MQ”, il s’agit en fait de plusieurs composants intervenant pour envoyer et recevoir des messages.

Queue Manager

C’est le composant  permettant de gérer les files qui peuvent être présentes sur un environnement. Ainsi, il permet essentiellement de créer, modifier, supprimer des files. Il permet aussi:

  • D’instaurer et de gérer la connexion avec l’hôte distant
  • D’assurer le transfert des messages

Message broker

C’est le composant qui traduit et route le message dans l’architecture MOM. Plus précisément, il permet de:

  • Envoyer un message vers les bonnes destinations
  • Récupérer le message sur une file
  • Le lire et le traduire pour le destinataire

Le message peut être découpé en plusieurs paquets avent d’être expédié. Le “broker” doit le recomposer avant de le lire.

Simple Text Oriented Message Protocol

Simple Text Oriented Message Protocol (STOMP) est un protocole simple conçu pour les MOM. Ressemblant au HTTP, il s’utilise sur le TCP. La trame est l’élément de communication entre le client et le serveur. Elle est constituée de plusieurs lignes:

  • La commande (CONNECT, SEND, SUBSCRIBE, …)
  • L’en-tête, sous la forme de <clé>:<valeur> (une par ligne)
  • Une ligne vide
  • Le corps du message
  • Le caractère null à la fin

Advanced Massage Queuing Protocol

Advanced Massage Queuing Protocol (AMQP) est le protocole qui a été défini pour normaliser les échanges entre les différents logiciels implémentant les files de messages (voir le site officiel). Il permet aux applications utilisant différents “brokers” de dialoguer. Il existe aussi un protocole similaire chez Microsoft, MSMQ.

Java Message Service

Java Message Service (JMS) est l’API Java permettant d’interagir avec des composants logiciels intermédiaires, tels que les files de messages. Ainsi, on peut, grâce à du code Java, créer, et modifier une file, ainsi qu’envoyer ou lire un message.

Fonctionnement

L’émetteur dépose un message sur la file et peut continuer ses tâches. Le récepteur possède un composant qui écoute sur la file ou bien vient y récupérer périodiquement les messages. Ainsi, les communications se font de façon asynchrone.

Le message est constitué d’un en-tête et des données à envoyer. L’en-tête contient des informations techniques telles que le type de caractères utilisé ou l’information déterminant si une réponse est attendue de la part du destinataire.

Avantages

Ce type d’architecture présente un certain intérêt:

  • Il est conseillé pour des systèmes d’information hétérogènes
  • Le traitement asynchrone des messages permet aux applications de ne pas être bloquées sur une tâche

Inconvénients

Les principaux problèmes avec ce composant sont les suivants:

  • Nécessite un surcoût en termes de développement. Il faut en effet que, de part et d’autre de la file, on ait les outils pour pouvoir correctement interpréter ce qui a été envoyé, par exemple.
  • Un changement dans le format du message nécessite des tests et/ou des ajustements pour tous les intervenants (expéditeur et récepteur)

Les formes de communication

Il existe 2 principales façons d’implémenter les files MQ : par abonnement (publish-subscribe), par point-à-point.

Mode point-à-point

Ce mode est utilisé dans le cas où l’on veut s’assurer que le destinataire reçoive effectivement les messages et cela dans un certain ordre. Concrètement, le message envoyé est stocké pour une garantie de livraison. Quand le message est reçu par le destinataire, il envoie un accusé de réception et c’est à ce moment-là que le message est effacé. En cas de problème lors de la réception, le message est réémis.

mode_point_a_point_file_MQ

Dans ce mode de fonctionnement, on peut avoir plusieurs consommateurs enregistrés, mais un seul va consommer le message.

Mode “publish-subscribe”

Dans ce cas, on peut avoir plusieurs expéditeurs qui envoient des messages à une entité sur un serveur. Celle-ci est appelée topic. Plusieurs applications s’abonnent donc à ce topic; de leur point de vue ce n’est qu’un mot, une chaîne de caractères. Tous les abonnés reçoivent donc une copie du message envoyé au topic.

mode_publish_subscribe_file_MQ

 

En exemple, on peut citer les fils d’actualité ou les chaînes Youtube. A chaque fois qu’une nouvelle publication est faite, tous les abonnés sont prévenus.

 Quelques outils du marché

Plusieurs applications et outils permettent d’avoir des “brokers” assez évolués. Selon le besoin, on peut en choisir un dans un panel assez varié dont nous présenterons quelques outils connus ici.

Websphere MQ

D’abord connu sous le nom de MQ Series, il a changé de nom lors de son rachat par IBM. C’est une solution de transfert de messages inter-applicatifs qui offre de nombreux avantages.

  • Intègre le module AMS (Advanced Message Security) qui permet de sécuriser le contenu des messages qui sont envoyés dans les files. Dans le cas de transfert de données bancaires (numéro de carte de crédit) ou de données sensibles (informations de sécurité sociale), il est nécessaire que le contenu des messages soit hautement sécurisé.
  • Implémentation de SSL (Secure Sockets Layer) et TLS (Transport Layer Security) lors des échanges entre application cliente et queue Manager, et entre les Queue Managers (cas d’une configuration en cluster)
  • Utilise les APIs standards définies pour les accès aux files de messages: JMS (Java Message Service) et XMS (IBM Message Service Client)
  • Permet de définir un cluster de Queue Manager. Ainsi, on définit un réseau logique où les différents Queue Managers sont connectés entre eux. Les applications envoient donc leurs messages dans le cluster, qui se charge de les rediriger vers le bon destinataire.

Un des inconvénients majeurs de cette solution est son coût: étant une solution propriétaire, elle est proposée par modules plus ou moins onéreux. Si votre budget est limité, il faudra se tourner vers un autre broker. Mais un autre avantage de Websphere MQ est qu’il offre un support de qualité, ce qui n’est pas négligeable.

Pour information, une faille de sécurité a été détectée sur Websphere: ainsi, on peut simuler une réponse très volumineuse qui provoquera donc un déni de service sur la file.

Joram

JORAM signifie Java Open Reliable Asynchronous Messaging. C’est une implémentation Open source d’un Queue Manager. Il est utilisé comme référence JMS par le serveur d’application Jonas. Il est caractérisé par les points suivants:

  • Implémentation de JMS 1.1 et AMQP
  • Implémentation du SSL pour des connections sécurisées
  • Possibilité de faire le lien entre tout serveur JORAM et toute plateforme implémentant JMS
  • Réplication possible du serveur pour maintenir une haute disponibilité
  • Configuration dynamique possible car on peut ajouter ou enlever à chaud des serveurs JORAM grâce à l’API dédiée.

Un de ses avantages est qu’il gère le fait que l’émetteur et le(s) récepteur(s) peuvent se trouver sur la même JVM ou bien être distants (prise en charge du TCP). Les détails de ces caractéristiques se trouvent sur le site officiel du projet.

A noter: Un projet en parallèle, permet à l’utilisateur, même débutant, de mesurer les performances de l’architecture JORAM mise en place: MQ Perf.

 

Apache ActiveMQ 

C’est un projet open source Apache qui contient un client JMS et un message broker. Il est développé en JAVA et offre plusieurs fonctionnalités:

  • Plusieurs APIs permettent de dialoguer avec des applications hétérogènes. Ainsi les langages de programmation suivants sont supportés: C, C++, C#, Perl, Ruby, .Net, Dephi, FreePascal entre autres
  • Les protocoles gérant les messages suivant sont pris en charge: JMS, AMQP, XMG pour la messagerie instantanée
  • Plusieurs architectures sont possibles: cluster de brokers, configuration en maître / esclave… Elles permettent de limiter voire supprimer toute indisponibilité en cas de problème sur l’un des brokers
  • Supportant Spring, Active MQ peut être facilement embarqué dans des projets en utilisant une configuration XML

Certaines de ces caractéristiques sont abordées de façon plus détaillées ici.

 RabbitMQ

Il s’agit d’un projet Open Source d’implémentation de message broker. Le serveur est programmé en Erlang, un langage de programmation fonctionnelle. Il offre les avantages suivants:

  • Plusieurs langages de programmation sont pris en charge: Java, C, C#, Perl, .Net, Erlang …
  • Les protocoles de gestion de messages suivant sont pris en charge: AMQP, STOMP, MQTT, HTTP (même si ce n’est pas un protocole d’envoi de messages à proprement parler, RabbitMQ peut s’en servir pour transmettre des messages de faible volume)
  • Les serveurs RabbitMQ peuvent être regroupés en un seul serveur logique (cluster) pour permettre une centralisation des traitements
  • Les files de messages peuvent être dupliquées sur plusieurs serveurs (dans le cluster) pour s’assurer de la prise en charge des messages même en cas de défaillance d’un équipement
  • Le protocole SSL est intégré au serveur.

Un des points importants de RabbitMQ est qu’il est soutenu par une communauté active. Celle-ci a créé plusieurs adaptateurs et outils pour le développement (module RabbitMQ pour le framework Play!, projet Spring AMQP pour Java, client  RabbitMQ pour .NET …).

Conclusion

Les MOMs sont très utiles comme nous l’avons souligné plus haut. Mais leur mise en place reste coûteuse en terme de temps (modification de l’architecture, développement) et de ressources (argent, personnes). Le choix de les intégrer dépendra donc essentiellement du gain (valeur ajoutée) que cela représentera pour l’ensemble du système d’information.

Le choix de l’un ou de l’autre des “brokers” du marché dépendra donc du budget et de la volonté ou non d’avoir un support.

Pour aller plus loin

Utilisation des files avec MS Azure (en anglais)

Les files de messages vs les webservices (en anglais)

Comparaison de Beanstalkd, Ironmq et amazon SQS (en anglais)