Prise en charge des objets gérés

IBM® MQ classes for JMS et IBM MQ classes for Jakarta Messaging prennent en charge l'utilisation d'objets gérés.

DepuisIBM MQ 9.3.0 ,Jakarta Messaging 3.0 est pris en charge pour le développement de nouvelles applications. IBM MQ 9.3.0 et les versions ultérieures continuent de prendre en charge JMS 2.0 pour les applications existantes. L'utilisation de l'API Jakarta Messaging 3.0 et de l'API JMS 2.0 dans la même application n'est pas prise en charge. Pour plus d'informations, voir Utilisation des classes IBM MQ pour JMS/Jakarta Messaging.

Le flux logique dans une application JMS ou IBM MQ classes for Jakarta Messaging commence par les objets ConnectionFactory et Destination. L'application utilise un objet ConnectionFactory pour créer un objet Connection, qui représente la connexion active depuis l'application vers un serveur de messagerie. L'application utilise l'objet Connection pour créer un objet Session, qui est un contexte avec une seule unité d'exécution permettant de générer et de consommer des messages. L'application peut ensuite utiliser l'objet Session et l'objet Destination pour créer un objet MessageProducer, que l'application utilise pour envoyer des messages à la destination indiquée. La destination est soit une file d'attente, soit une rubrique du système de messagerie et est encapsulée par l'objet Destination. L'application peut aussi utiliser l'objet Session et un objet Destination pour créer un objet MessageConsumer, qu'elle utilise pour recevoir des messages envoyés à la destination indiquée.

Les spécifications JMS et Jakarta Messaging s'attendent à 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 ou Jakarta Messaging extrait ces objets à l'aide de Java Naming Directory Interface (JNDI). Le référentiel des objets gérés peut aller d'un fichier simple à un annuaire LDAP (Lightweight Directory Access Protocol).

IBM MQ classes for JMS et IBM MQ classes for Jakarta Messaging prennent en charge l'utilisation d'objets gérés. Une application peut utiliser toutes les fonctions de IBM MQ classes for JMS ou de IBM MQ classes for Jakarta Messaging qui sont exposées via IBM MQ sans qu'aucune information spécifique à IBM MQne soit codée en dur dans l'application elle-même. Cette disposition offre à l'application une certaine indépendance par rapport à la configuration IBM MQ sous-jacente.

Pour obtenir cette indépendance, l'application peut utiliser JNDI pour extraire des fabriques de connexions et des destinations qui sont stockées en tant qu'objets gérés et utiliser uniquement les interfaces définies dans le package javax.jms (JMS 2.0) ou jakarta.jms (Jakarta Messaging 3.0) pour effectuer des opérations de messagerie.

PourJMS 2.0 , un administrateur peut utiliser leIBM MQJMS outil d'administrationJMSAdmin , ouIBM MQ Explorer , pour créer et maintenir des objets administrés dans un référentiel central.

PourJakarta Messaging 3.0 , vous ne pouvez pas administrer JNDI à l'aide deIBM MQ Explorer . L'administration du JNDI est soutenue par leJakarta Messaging 3.0 variante deJMSAdmin , lequel estJMS30Admin .

Un serveur d'applications fournit généralement son propre référentiel pour les objets gérés et ses propres outils pour la création et la gestion des objets. UNJava EE ouJakarta EE l'application peut donc utiliserJNDI pour récupérer les objets administrés soit depuis le référentiel du serveur d'applications, soit depuis un référentiel central.