Le modèle JMS et Jakarta Messaging

Le modèle JMS et Jakarta Messaging définit un ensemble d'interfaces que les applications Java peuvent utiliser pour effectuer des opérations de messagerie. IBM® MQ classes for JMS et IBM MQ classes for Jakarta Messaging sont des fournisseurs de messagerie. Ils définissent comment les objets JMS et Jakarta Messaging sont liés aux concepts IBM MQ . Les spécifications JMS et Jakarta Messaging s'attendent à ce que certains objets JMS et Jakarta Messaging soient des objets gérés.

[ JMS 2.0] IBM MQ 8.0 a ajouté la prise en charge de la version JMS 2.0 de la norme JMS , qui a introduit une API simplifiée, tout en conservant l'API classique de JMS 1.1.

À partir de IBM MQ 9.3.0, Jakarta Messaging 3.0 est pris en charge pour le développement de nouvelles applications. IBM MQ 9.3.0 continue de prendre en charge JMS 2.0 pour les applications existantes. L'utilisation de l'API JMS 2.0 et de l'API Jakarta Messaging 3.0 dans la même application n'est pas prise en charge.

Remarque: Pour Jakarta Messaging 3.0, le contrôle de la spécification JMS passe de Oracle à Java Community Process. Toutefois, Oracle conserve le contrôle du nom "javax", qui est utilisé dans d'autres technologies Java qui n'ont pas été déplacées vers le processus de communauté Java . Ainsi, alors que Jakarta Messaging 3.0 est fonctionnellement équivalent à JMS 2.0 , il existe des différences de dénomination:

Le nom officiel de la version 3.0 est Jakarta Messaging et non Java Message Service.
Les noms de pack et de constante sont précédés de jakarta et non de javax. Par exemple, dans JMS 2.0 , la connexion initiale à un fournisseur de messagerie est un objet javax.jms.Connection et dans Jakarta Messaging 3.0 , il s'agit d'un objet jakarta.jms.Connection .

[ JMS 2.0] Les paquets javax.jms définissent les interfaces JMS , et un fournisseur JMS met en œuvre ces interfaces pour un produit de messagerie spécifique. IBM MQ classes for JMS est un fournisseur JMS qui implémente les interfaces JMS pour IBM MQ.

[ Messagerie Jakarta 3.0] Les paquets jakarta.jms définissent les interfaces Jakarta Messaging , et un fournisseur Jakarta Messaging met en œuvre ces interfaces pour un produit de messagerie spécifique. IBM MQ classes for Jakarta Messaging est un fournisseur Jakarta Messaging qui implémente les interfaces Jakarta Messaging pour IBM MQ.

Etant donné que JMS et Jakarta Messaging partagent beaucoup de choses en commun, d'autres références à JMS dans cette rubrique peuvent être considérées comme faisant référence aux deux. Toutes les différences sont mises en évidence si nécessaire.

API simplifiée

JMS 2.0 a introduit l'API simplifiée, tout en conservant les interfaces spécifiques au domaine et indépendantes du domaine d' JMS 1.1. L'API simplifiée réduit le nombre d'objets nécessaires à l'envoi et à la réception de messages et se compose des interfaces ci-dessous :

ConnectionFactory: Une ConnectionFactory est un objet géré qui est utilisé par un client JMS pour créer une connexion. Cette interface est également utilisée dans l'API classique.
JMSContexte: Cet objet combine les objets Connection et Session de l'API classicCd. JMSLes objets de contexte peuvent être créés à partir d'autres objets de contexte JMS, la connexion sous-jacente étant dupliquée.
JMSExpéditeur: Un fournisseur JMSest créé par un contexte JMSet est utilisé pour envoyer des messages à une file d'attente ou à une rubrique. L'objet JMSProducer entraîne la création des objets nécessaires à l'envoi du message.
JMSConsommateur: Un consommateur JMSest créé par un contexte JMSet est utilisé pour recevoir des messages d'une rubrique ou d'une file d'attente.

L'API simplifiée a un certain nombre d'effets :

L'objet de contexte JMSdémarre toujours automatiquement la connexion sous-jacente.
JMSProducteurs et JMSConsommateurs peuvent désormais travailler directement avec les corps de message, sans avoir à obtenir l'objet de message entier, à l'aide de la méthode getBody du message.
Les propriétés de message peuvent être définies sur l'objet Producteur JMS, à l'aide du chaînage de méthodes, avant l'envoi d'un "corps", d'un contenu de message. Le fournisseur JMSgère la création de tous les objets nécessaires à l'envoi du message. Avec JMS 2.0, les propriétés peuvent être définies et un message peut être envoyé comme suit:
```
context.createProducer().
setProperty("foo", "bar").
setTimeToLive(10000).
setDeliveryMode(NON_PERSISTENT).
setDisableMessageTimestamp(true).
send(dataQueue, body);
```

JMS 2.0 a également introduit des abonnements partagés dans lesquels les messages peuvent être partagés entre plusieurs consommateurs. Tous les abonnements JMS 1.1 sont traités comme des abonnements non partagés.

API classique

La liste suivante récapitule les principales interfaces JMS de l'API classique:

Destination: Une destination représente l'endroit où une application envoie des messages, l'endroit d'où elle en reçoit, ou les deux.
ConnectionFactory: Un objet ConnectionFactory encapsule un ensemble de propriétés de configuration pour une connexion. Une application utilise une fabrique de connexions pour créer une connexion.
Connexion: Un objet Connection encapsule la connexion active d'une application sur un serveur de messagerie. Une application utilise une connexion pour créer des sessions.
Session: Une session est un contexte à unité d'exécution unique pour l'envoi et la réception de messages. Une application utilise ensuite une session pour créer des messages, des expéditeurs de message et des consommateurs de message. Une session est transactionnelle ou non transactionnelle.
Message: Un objet Message encapsule un message envoyé ou reçu par une application.
MessageProducer: Une application utilise un expéditeur de message pour envoyer des messages vers une destination.
MessageConsumer: Une application utilise un consommateur de message pour la réception des messages envoyés vers une destination.

La Figure 1 illustre ces objets et leurs relations.

Le diagramme montre les principales interfaces JMS : ConnectionFactory, Connection, Session, MessageProducer, MessageConsumer, Message et Destination. Une application utilise une fabrique de connexions pour créer une connexion et utilise une connexion pour créer des sessions. L'application peut ensuite utiliser une session pour créer des messages, des expéditeurs de message et des consommateurs de message. L'application utilise un expéditeur de message pour envoyer des messages vers une destination et utilise un consommateur de message pour recevoir des messages envoyés vers une destination. — Figure 1 : Objets JMS et leurs relations

Un objet Destination, ConnectionFactory ou Connection peut être utilisé simultanément par différentes unités d'exécution d'une application comportant plusieurs unités d'exécution, mais un objet Session, MessageProducer ou MessageConsumer ne peut pas être utilisé par des unités d'exécution différentes. La manière la plus simple de s'assurer qu'un objet Session, MessageProducer ou MessageConsumer n'est pas utilisé simultanément consiste à créer un objet Session distinct pour chaque unité d'exécution.

Domaines de messagerie

JMS prend en charge deux styles de messagerie:

Messagerie point-à-point
Messagerie de type publication/abonnement

Ces deux styles de messagerie sont également appelés domaines de messagerie et ils peuvent être combinés dans une application. Dans le domaine point-à-point, une destination est une file d'attente et, dans le domaine de publication/abonnement, une destination est une rubrique.

Avec les versions de JMS antérieures à JMS 1.1, la programmation du domaine point à point utilise un ensemble d'interfaces et de méthodes, tandis que la programmation du domaine de publication / abonnement utilise un autre ensemble. Les deux ensembles sont similaires, mais distincts. Depuis la JMS 1.1, vous pouvez utiliser un ensemble commun d'interfaces et de méthodes qui prennent en charge les deux domaines de messagerie. Les interfaces communes fournissent une vue indépendante du domaine de chaque domaine de messagerie. Le tableau 1 répertorie les interfaces indépendantes du domaine JMS et les interfaces spécifiques au domaine correspondantes.

Tableau 1. Les JMS interfaces indépendantes du domaine et spécifiques au domaine
Interfaces indépendantes du domaine	Interfaces propres au domaine pour le domaine point-à-point	Interfaces propres au domaine pour le domaine de publication/abonnement
ConnectionFactory	QueueConnectionFactory	TopicConnectionFactory
Connexion	QueueConnection	TopicConnection
Destination	File d'attente	Topic
Session	QueueSession	TopicSession
MessageProducer	QueueSender	TopicPublisher
MessageConsumer	QueueReceiver QueueBrowser	TopicSubscriber

[ JMS 2.0] IBM MQ classes for JMS 2.0 supporte à la fois les interfaces spécifiques au domaine de JMS 1.1 et l'API simplifiée de JMS 2.0. IBM MQ classes for JMS 2.0 peut donc être utilisé pour gérer des applications existantes, y compris pour développer de nouvelles fonctions dans des applications existantes.

[ Messagerie Jakarta 3.0] IBM MQ classes for Jakarta Messaging 3.0 prend en charge les versions Jakarta Messaging des mêmes interfaces et est recommandé pour le développement de nouvelles applications.

Dans IBM MQ classes for JMS et IBM MQ classes for Jakarta Messaging, les objets JMS sont liés aux concepts IBM MQ de la manière suivante:

Un objet Connection possède des propriétés issues des propriétés de la fabrique de connexions qui a été utilisée pour créer la connexion. Ces propriétés contrôlent comment une application se connecte à un gestionnaire de files d'attente. Des exemples de ces propriétés sont le nom du gestionnaire de files d'attente et, pour une application qui se connecte au gestionnaire de files d'attente en mode client, le nom d'hôte ou l'adresse IP du système sur lequel s'exécute le gestionnaire de files d'attente.
Un objet Session encapsule un descripteur de connexion IBM MQ , qui définit donc la portée transactionnelle de la session.
Un objet MessageProducer et un objet MessageConsumer encapsulent chacun un descripteur d'objet IBM MQ .

Lorsque vous utilisez IBM MQ classes for JMS ou IBM MQ classes for Jakarta Messaging, toutes les règles normales de IBM MQ s'appliquent. Sachez, en particulier, qu'une application peut envoyer un message à une file d'attente éloignée, mais elle peut uniquement recevoir un message d'une file d'attente qui appartient au gestionnaire de files d'attente auquel l'application est connectée.

La spécification JMS s'attend à ce que les objets ConnectionFactory et Destination soient des objets gérés. Un administrateur crée et gère des objets gérés dans un référentiel central et une application JMS extrait ces objets à l'aide de l'interface JNDI ( Java Naming and Directory Interface).

Dans IBM MQ classes for JMS et IBM MQ classes for Jakarta Messaging, l'implémentation de l'interface Destination est une superclasse abstraite de Queue et Topic, et donc une instance de Destination est soit un objet Queue, soit un objet Topic. Les interfaces indépendantes du domaine traitent une file d'attente ou une rubrique en tant que destination. Le domaine de messagerie pour un objet MessageProducer ou MessageConsumer varie selon que la destination est une file d'attente ou une rubrique.

Par conséquent, dans IBM MQ classes for JMS et IBM MQ classes for Jakarta Messaging , les objets des types suivants peuvent être des objets gérés:

ConnectionFactory
QueueConnectionFactory
TopicConnectionFactory
File d'attente
Topic
XAConnectionFactory
XAQueueConnectionFactory
XATopicConnectionFactory