Support for administered objects

IBM® MQ classes for JMS and IBM MQ classes for Jakarta Messaging support the use of administered objects.

From IBM MQ 9.3.0, Jakarta Messaging 3.0 is supported for developing new applications. IBM MQ 9.3.0 continues to support JMS 2.0 for existing applications. It is not supported to use both the Jakarta Messaging 3.0 API and the JMS 2.0 API in the same application. For more information, see Using IBM MQ classes for JMS/Jakarta Messaging.

The flow of logic within a JMS or IBM MQ classes for Jakarta Messaging application starts with ConnectionFactory and Destination objects. The application uses a ConnectionFactory object to create a Connection object, which represents the active connection from the application to a messaging server. The application uses the Connection object to create a Session object, which is a single threaded context for producing and consuming messages. The application can then use the Session object and a Destination object to create a MessageProducer object, which the application uses to send messages to the specified destination. The destination is either a queue or a topic in the messaging system and is encapsulated by the Destination object. The application can also use the Session object and a Destination object to create a MessageConsumer object, which the application uses to receive messages that have been sent to the specified destination.

The JMS and Jakarta Messaging specifications expect ConnectionFactory and Destination objects to be administered objects. An administrator creates and maintains administered objects in a central repository, and a JMS or Jakarta Messaging application retrieves these objects using the Java Naming Directory Interface (JNDI). The repository of administered objects can range from a simple file to a Lightweight Directory Access Protocol (LDAP) directory.

IBM MQ classes for JMS and IBM MQ classes for Jakarta Messaging support the use of administered objects. An application can use all the features of IBM MQ classes for JMS or IBM MQ classes for Jakarta Messaging that are exposed through IBM MQ without having any IBM MQ-specific information hard coded into the application itself. This arrangement provides the application with a degree of independence from the underlying IBM MQ configuration.

To achieve this independence, the application can use JNDI to retrieve connection factories and destinations that are stored as administered objects, and use only the interfaces defined in the javax.jms (JMS 2.0) or jakarta.jms (Jakarta Messaging 3.0) package to perform messaging operations.

For JMS 2.0, an administrator can use the IBM MQ JMS administration tool JMSAdmin, or IBM MQ Explorer, to create and maintain administered objects in a central repository.

For Jakarta Messaging 3.0, you cannot administer JNDI using IBM MQ Explorer. JNDI administration is supported by the Jakarta Messaging 3.0 variant of JMSAdmin, which is JMS30Admin.

An application server typically provides its own repository for administered objects, and its own tools for creating and maintaining the objects. A Java EE or Jakarta EE application can therefore use JNDI to retrieve administered objects either from the applications server repository or from a central repository.