ENSI –SAR

Ce document présente les concepts fondamentaux du Message Oriented Middleware (MOM) et de l’API Java Message Service (JMS). Il s’adresse aux étudiants et professionnels en informatique souhaitant comprendre les architectures de communication asynchrone entre applications distribuées, ainsi que l’utilisation pratique de JMS dans ce contexte.

Introduction : Motivations et principe du MOM

Le modèle client-serveur traditionnel présente des limites : il est synchrone, la communication est souvent 1 vers 1, les entités sont explicitement désignées et l’organisation peu dynamique. Le MOM propose un modèle adapté aux besoins d’intégration d’applications distribuées hétérogènes, avec :

• Communication asynchrone
• Communication possible n vers p
• Désignation non explicite des entités
• Organisation dynamique facilitant l’évolution et la modification des participants

Les objectifs principaux des MOM sont :

• Asynchronisme : ne pas être bloqué pendant la communication
• Indépendance vis-à-vis des interlocuteurs connus ou non
• Intégration de modules hétérogènes
• Fiabilité dans la délivrance des messages
• Couplage faible entre applications et canaux de communication

Le principe repose sur la messagerie inter-application asynchrone, utilisant des files de messages persistantes (stockage sur disque) qui permettent le partage entre plusieurs applications, la gestion des priorités et le filtrage des messages à la réception. Ce système est insensible aux partitions réseau et aux indisponibilités temporaires des applications.

Modèles de messagerie

Trois modèles principaux sont utilisés dans les MOM :

• Message Queue : un message produit est consommé par un seul client.
• Publication-Souscription : un message publié est diffusé à tous les souscripteurs. Il existe aussi une variante basée sur le contenu du message (content-based publish-subscribe) où la diffusion dépend des propriétés du message.
• Requête-Réponse : modèle asynchrone de type client-serveur.

Dans le modèle Message Queue, les messages ont une identification unique, peuvent être typés ou non, persistants ou non, et délivrés avec ou sans accusé de réception. Les queues sont elles aussi identifiées, partagées, persistantes et respectent un ordre spécifié (total, causal, selon priorité, etc.).

Exemple de modèle Message Queue

Un producteur envoie un message à une queue identifiée. Un seul consommateur récupère ce message, qui peut être typé (par exemple TextMessage) et persistant.

Communication par messages : modes Pull et Push

Le mode pull consiste en une réception explicite des messages : le client vient périodiquement consulter sa boîte aux lettres pour récupérer les messages. Ce mode est utilisé dans les forums ou les flux d’actualités où les utilisateurs vont chercher l’information à leur initiative.

Le mode push repose sur une réception implicite : le destinataire s’abonne à un service et est notifié dès qu’un message est déposé. Ce modèle correspond à un paradigme événement-réaction, utilisé dans les listes de diffusion ou les logiciels de chat.

Architecture d’un MOM

Un MOM comprend :

• Clients MOM : reliés en permanence à un serveur MOM, ils envoient et reçoivent des messages.
• Serveurs MOM : reliés entre eux de façon épisodique (réseaux mobiles, WAN), ils maintiennent des copies des messages par réplication (serveurs primaires et secondaires).
• Administrateur/Contrôleur : crée et surveille les files, définit la topologie des interconnexions et la politique de connexion.

L’architecture peut être centralisée (Spoke and Hub), distribuée (Bus) ou pair à pair (Snowflake). Les critères de qualité de service (QoS) incluent disponibilité, fiabilité, passage à l’échelle et sécurité.

Interopérabilité entre MOM

Il existe une difficulté majeure à faire interopérer différents MOM, du fait de l’absence de standardisation complète. Des initiatives comme BMQ (Business Messaging Quality) et MOMA (Message Oriented Middleware Association) visent à améliorer cette interopérabilité. CORBA 3.0 introduit la notion de messages asynchrones, et J2EE propose JMS (Java Message Service) pour uniformiser l’accès aux systèmes de messagerie.

Comparaison RPC et MOM

Caractéristique	MOM	RPC
Relation temporelle client-serveur	Asynchrone	Synchrone
Nature du dialogue	File d’attente	Requête-Réponse
État opérationnel du serveur	Pas nécessaire	Obligatoire
Filtrage des messages	Possible	Non
Performances	Plus lent si sécurisation par écriture disque	Plus efficace car pas de sauvegarde

Exemples de MOM

• IBM MQSeries : leader du marché, supporte plus de 20 plateformes, plusieurs protocoles et langages (C++, Java, Cobol, etc.). Comporte des modules Publish/Subscribe et Workflow.
• MSMQ (Microsoft Message Queue) : implémentation Microsoft, fonctionne sur NT/2000/XP, supporte IP multicast, HTTP/HTTPS, et propose des fonctionnalités avancées comme les triggers et listes de distribution.
• JORAM (Java Open Reliable Asynchronous Messaging) : open source, implémente JMS, architecture multi-serveurs avec équilibrage de charge et haute disponibilité. Utilisé dans des applications Java et serveurs J2EE.

Java Message Service (JMS)

JMS est une API Java standardisée pour accéder aux systèmes de messagerie d’entreprise. Elle supporte les modèles Publish/Subscribe et Point-to-Point (Message Queuing).

Composants d’une application JMS

• Fournisseur JMS (MOM) : supporte les modèles Point-à-Point et Pub/Sub, avec fonctions d’administration.
• Clients JMS : producteurs et consommateurs de messages.
• Objets administrés :
  • Connection factories : créent les connexions entre clients et fournisseurs JMS.
  • Destinations : canaux de communication, queues pour Point-à-Point, topics pour Pub/Sub.
  • Messages : différents types (TextMessage, MapMessage, BytesMessage, StreamMessage, ObjectMessage).

Architecture générale de JMS

Une connexion JMS est liée à un serveur de messages. À l’intérieur d’une connexion, plusieurs sessions peuvent exister. La session gère la transmission globale. Les producteurs et consommateurs existent uniquement dans une session et connaissent seulement la destination. Le message existe uniquement dans une session.

JNDI (Java Naming and Directory Interface)

JNDI est une API permettant de gérer des annuaires de données ou d’objets, utilisés notamment pour retrouver les ressources JMS (queues, topics, connection factories). Elle offre deux méthodes principales :

• Bind : associer un nom à une ressource
• Lookup : retrouver une ressource à partir de son nom

Services définis par JMS

• Création de messages structurés (entêtes, propriétés, corps)
• Connexion à un fournisseur JMS via JNDI
• Récupération d’une file ou d’un sujet nommé via JNDI
• Production et consommation de messages

Le standard ne définit pas l’administration des files, leur stockage, ni l’interopérabilité entre fournisseurs JMS.

Types de messages JMS

• TextMessage : message texte (méthodes getText(), setText())
• MapMessage : paires clé-valeur (setString(), getString())
• BytesMessage : flux de bytes (writeBytes(), readBytes())
• StreamMessage : flux de types primitifs (writeString(), ...)
• ObjectMessage : objet sérialisé (getObject(), setObject())

Les messages peuvent être persistants ou non persistants (mode PERSISTENT par défaut). En cas d’arrêt du serveur JMS, les messages persistants sont renvoyés à la reprise, ce qui peut entraîner des doublons.

Exemple d’utilisation JMS en mode Point-à-Point

QueueConnectionFactory connectionFactory = (QueueConnectionFactory) messaging.lookup("…");
Queue queue = (Queue) messaging.lookup("…");
QueueConnection connection = connectionFactory.createQueueConnection();
QueueSession session = connection.createQueueSession(false, Session.AUTO_ACKNOWLEDGE);

QueueSender sender = session.createSender(queue);
TextMessage msg = session.createTextMessage();
msg.setText("Message d'exemple");
sender.send(msg);

String selector = "(name = 'Bull') or (name = 'IBM')";
QueueReceiver receiver = session.createReceiver(queue, selector);
TextMessage receivedMsg = (TextMessage) receiver.receive();
System.out.println("Message reçu : " + receivedMsg.getText());

Exemple d’utilisation JMS en mode Publication/Souscription

TopicConnectionFactory connectionFactory = (TopicConnectionFactory) messaging.lookup("…");
Topic topic = (Topic) messaging.lookup("/A/x");
TopicConnection connection = connectionFactory.createTopicConnection();
TopicSession session = connection.createTopicSession(false, Session.CLIENT_ACKNOWLEDGE);

TopicPublisher publisher = session.createPublisher(topic);
publisher.publish(msg);

TopicSubscriber subscriber = session.createSubscriber(topic);
subscriber.setMessageListener(new MessageListener() {
  public void onMessage(Message msg) {
    // traitement du message
  }
});

JORAM et la plate-forme Scalagent

JORAM est une implémentation open source de JMS basée sur la plate-forme Scalagent, un bus logiciel à base d’agents communicants. Chaque agent est un objet réactif, persistant et léger, fonctionnant selon un modèle événement-réaction asynchrone.

L’architecture multi-serveurs de JORAM permet :

• Équilibrage de charge par réplication des destinations sur plusieurs serveurs
• Haute disponibilité via un serveur maître répliquant ses queues/topics sur des serveurs esclaves
• Connexion client pouvant basculer entre serveurs maître et esclaves

JORAM est intégré dans des serveurs d’application J2EE (ex. JOnAS) pour gérer les transactions distribuées et la réception asynchrone via les Message-Driven Beans.

Avantages des MOM

• Intégration de multiples protocoles et plateformes
• Messages définis par les utilisateurs
• Garantie de délivrance des messages (GMD)
• Équilibrage de charge
• Tolérance aux pannes
• Support des plateformes hétérogènes
• Gestion et configuration via interfaces graphiques

Glossaire des termes clés

• MOM (Message Oriented Middleware) : middleware basé sur l’échange asynchrone de messages entre applications distribuées.
• JMS (Java Message Service) : API Java standard pour accéder aux systèmes de messagerie d’entreprise.
• Queue (File de messages) : canal de communication pour le modèle Point-à-Point, où un message est consommé par un seul client.
• Topic (Sujet) : canal de communication pour le modèle Publish/Subscribe, où un message est diffusé à plusieurs souscripteurs.
• Producteur (Producer) : entité qui envoie des messages dans une destination.
• Consommateur (Consumer) : entité qui reçoit des messages d’une destination.
• Connection Factory : objet créant des connexions entre clients JMS et fournisseurs JMS.
• JNDI (Java Naming and Directory Interface) : API pour gérer et retrouver des ressources nommées dans un annuaire.
• Persistant : mode où les messages sont sauvegardés sur disque pour garantir leur livraison même en cas de panne.
• Push : mode de réception où le destinataire est notifié automatiquement à la réception d’un message.
• Pull : mode de réception où le destinataire interroge périodiquement la file pour récupérer les messages.
• Message-Driven Bean (MDB) : composant Java EE réagissant de façon asynchrone à la réception de messages JMS.

Points clés à retenir

• Le MOM permet une communication asynchrone, fiable et découplée entre applications distribuées.
• Les modèles de messagerie principaux sont Message Queue, Publication-Souscription et Requête-Réponse.
• JMS standardise l’accès aux systèmes de messagerie en Java, supportant les deux modèles Point-à-Point et Pub/Sub.
• JORAM est une implémentation open source de JMS basée sur une architecture multi-serveurs et agents.
• Les MOM offrent des avantages majeurs en termes d’intégration, tolérance aux pannes, et gestion de la charge.