Les spécifications de JMS 2.0

1. Introduction

L’objectif de cet article est la présentation des nouvelles fonctionnalités proposées par la nouvelle version de la spécification JMS 2.0, qui a peu évolué depuis sa création en 1998.

C’est quoi JMS ? JMS est l’acronyme de Java Message Service, API standard utilisée par les applications Java pour échanger des informations au format message via Middleware Orienté Message (MOM).

C’est quoi un MOM ? Un MOM est une brique logicielle utilisé pour bâtir un système d’échange de messages asynchrone ou synchrone entre les applications qui composent le SI.

Les messages échangés peuvent être de type :

• Stream
• Text
• Byte

Le rôle de l’API JMS est de fournir les services dont une application Java a besoin pour :

• Etablir une connexion au fournisseur de service JMS (MOM)
• Créer un message
• Envoyer un message vers la destination
• Consommer un message transmis par une application source

Le rôle du MOM est de délivrer le message à l’application cible en proposant des services qui répondent aux besoins suivants :

• Assurer l’acheminement des messages vers la destination
• Gestion du routage des messages
• Garantir l’intégrité des messages
• Assurer la sécurité des messages
• Assurer la persistance des messages en cas d’erreur
• Gestion de la répartition des charges
• Gestion du failover

Des exemples d’implémentation seront présentés dans les prochains paragraphes pour expliquer comment une application Java interagit avec une un MOM par l’intermédiaire de l’API JMS.

2. Evolution de l’API JMS

2.1     JMS 1.0.2b

JMS est l’une des rares API de la trame JEE qui a peu évolué depuis son intégration dans la plateforme JEE. Dans la première spécification JMS 1.0.2b, les ingénieurs de SUN ont défini une API composée d’interfaces distinctes, dédiées à l’implémentation d’un client JMS pouvant interagir avec un MOM en utilisant un des deux modes d’échange suivant :

• Point à Point : les applications utilisent les files d’attente, QUEUE, pour échanger des messages. L’émetteur poste le message dans une file et le destinataire lit le message dans la file d’envoi ou dans une autre file de réception des messages. L’acheminement du message de l’émetteur vers le destinataire est assuré par le MOM.

• Publication / Abonnement : ce mode se base sur la notion de rubrique, TOPIC. Les applications publient un message sur un sujet, qui sera consommé uniquement par les applications qui se sont abonnées à ce sujet pour recevoir une copie du message. L’acheminement du message vers chaque destinataire est assuré par le MOM. Dans ce mode, plusieurs applications peuvent publier un message sur un sujet et un message peut être adressé à plusieurs destinataires.

L’API JMS se compose des interfaces suivantes :

a) ConnectionFactory

Cette interface permet la création des connexions d’accès à un MOM et son implémentation est fournie par le fournisseur des services JMS. Le type de la fabrique de connexion à utiliser dépend du mode d’échange avec le MOM :

• QueueConnectionFactory : fabrique de connexion pour le mode Point à Point
• TopicConnectionFactory : fabrique de connexion pour le mode Publication / Abonnement

La récupération d’une instance de cette interface est réalisée grâce au service JNDI.

b) Connection

Cette interface se charge d’établir la communication avec un MOM et le type de connexion à créer dépendra du mode échange avec le MOM :

• QueueConnection : pour le mode Point à Point et la fabrique de connexion à utiliser pour instancier cette connexion est QueueConnectionFactory
• TopicConnection : pour le mode Publication / Abonnement et la fabrique de connexion à utiliser pour instancier cette connexion est TopicConnectionFactory

c) Session

Cette interface permet de créer le contexte dans lequel l’envoi et la réception du message sont exécutés. Ce contexte peut être transactionnel s’il est activé lors de la création de la session JMS. Une session JMS est mono-thread et comme pour la connexion, son type est lié au mode connexion au MOM :

• QueueSession : pour le mode Point à Point
• TopicSession : pour le mode Publication / Abonnement

d) Destination

Cette interface fournit la description de l’adresse sur laquelle les messages pourront être envoyés ou lus. L’implémentation de cette interface est fournie par un fournisseur de services JMS et l’obtention d’une instance de cette interface se fait via le service JNDI. Comme pour la session, le type de la destination dépend du mode d’échange avec le MOM :

• Queue : pour le mode Point à Point
• Topic : pour le mode Publication / Abonnement

e) MessageProducer

Cette interface se charge d’envoyer le message vers la destination : Queue ou Topic. Le type du producteur à utiliser, QueueSender ou TopicPublisher, dépend du mode de connexion au MOM et son instance est créée de la manière suivante :

• Utilisation createSender pour le mode Point à Point

• createPublisher : pour le mode Publication / Abonnement

f) MessageConsumer

Cette interface est utilisée pour implémenter la réception des messages transmis par le MOM dans une application Java. Elle propose deux interfaces fille qui représentent les deux modes de communication avec un MOM :

• QueueReceiver : pour le mode Point à Point
• TopicSubscriber : pour le mode Publication / Abonnement

La réception du message peut être :

• Synchrone : l’exécution de l’application Java est bloquée jusqu’à la réception du message. Un délai d’attente maximal est possible pour la réception du message et au-delà duquel l’application pourra continuer son exécution. Un autre point important, la méthode start de l’objet Connexion doit être appelée avant la méthode receive pour donner l’ordre à la connexion de commencer la réception des messages.

• Réception synchrone en mode Point à Point

• Réception synchrone en mode Publication / Abonnement

• Asynchrone : l’application délègue la réception du message à un listener de type jms.MessageListener. La méthode onMessage du listener est exécutée automatiquement dès réception d’un message dans la destination : Queue ou Topic. Comme pour le mode synchrone, la méthode start de l’objet Connexion doit être appelée après l’enregistrement du listener asynchrone pour démarrer la réception des messages.

• Réception asynchrone en mode Point à Point

• Réception asynchrone en mode Publication / Abonnement

• Implémentation de l’interface javax.jms.MessageListener

2.2     JMS 1.1

En 2002, la version 1.1 de JMS est publiée avec comme objectif principal, pouvoir utiliser les mêmes interfaces pour les deux modes d’échanges et simplifier le modèle de développement des fonctions d’envoi ou de réception des messages.

Dans JMS 1.0.2b, chaque mode d’échange a ses propres interfaces pour implémenter l’envoi ou la réception des messages.

Les deux changements majeurs apportés par JMS 1.1 sont :

• Les interfaces parentes de l’API JMS ont été enrichies de nouvelles méthodes permettant de créer des objets d’implémentation des fonctions d’envoi ou de réception des messages, communs aux deux modes d’échanges avec un MOM

La possibilité de faire du Point à Point ou Publication / Abonnement avec la même session JMS dans une même transaction

a) Envoi d’un message avec une session transactionnelle

Cet exemple met en évidence les nouveautés de JMS 1.1 et la généricité du code implémenté dans une application, puisque les deux modes d’échange sont implémentés avec les mêmes interfaces et la distinction apparaît uniquement lors la définition de la destination : Queue ou Topic.

Aussi, on remarque que l’envoi des messages vers une file d’attente, Queue, et une rubrique, Topic, est rattaché à une seule session JMS et exécuté dans une même transaction, alors que dans JMS 1.0.2b chaque mode avait sa propre session JMS.

Enfin, l’interface Session s’est enrichie avec de nouvelles méthodes permettant de créer un objet de type javax.jms.MessageProducer qui se charge d’envoyer les messages dans la destination au détriment des anciennes interfaces javax.jms.QueueSender et javax.jms.TopicPublisher.

b) Réception d’un message avec une session transactionnelle

Comme pour l’envoi du message, il est possible pour une application d’implémenter la réception des messages dans une file d’attente, Queue, et dans une rubrique, Topic, avec la même session JMS et dans une même transaction.

L’interface Session s’est enrichie avec de nouvelles méthodes permettant de créer un objet de type javax.jms.MessageConsumer qui se charge de lire les messages dans la destination au détriment des anciennes interfaces javax.jms.QueueReceiver et javax.jms.TopicSubscriber.

3. Conclusion

Dans cette première partie de l’article, nous avons pu voir comment le modèle d’implémentation des échanges avec le MOM a évolué entre les deux spécifications JMS 1.0.2b et JMS 1.1.

Au début, le modèle proposait pour chaque mode d’échange (Point à Point ou Publication / Abonnement) des interfaces dédiées pour développer un envoi ou une réception de message dans une application. Ensuite, ce modèle a évolué et a été simplifié par JMS 1.1 puisque les interfaces utilisées dans l’implémentation de l’envoi ou de la réception des messages étaient communes aux deux modes d’échanges : Point à Point ou Publication / Abonnement.

Enfin, une deuxième partie, nous allons parcourir les changements introduits par la spécification JMS 2.0 à l’API de JMS 1.1.

Yacine Dechmi

Consultant Architecte