Why should I use IBM MQ classes for Jakarta Messaging?

Using IBM® MQ classes for Jakarta Messaging has a number of advantages including being able to reuse any existing Jakarta Messaging skills in your organization, and applications being more independent from the Jakarta Messaging provider and the underlying IBM MQ configuration.

Summary of advantages of using IBM MQ classes for Jakarta Messaging

Using IBM MQ classes for Jakarta Messaging allows you to reuse existing Jakarta Messaging skills and provide application independence.

You can reuse Jakarta Messaging skills.
IBM MQ classes for Jakarta Messaging is a Jakarta Messaging provider that implements the Jakarta Messaging interfaces for IBM MQ as the messaging system. If your organization is new to IBM MQ, but already has Jakarta Messaging (or JMS) application development skills, you might find it easier to use the familiar Jakarta Messaging API to access IBM MQ resources rather than one of the other APIs provided with IBM MQ.
Jakarta Messaging is an integral part of Jakarta EE.
Jakarta Messaging is the natural API to use for messaging on the Jakarta EE platform. Every application server that is Jakarta EE compliant must include a Jakarta Messaging provider. You can use Jakarta Messaging in application clients, servlets, Java Server Pages (JSPs), enterprise Java beans (EJBs), and message driven beans (MDBs). Note in particular that Jakarta EE applications use MDBs to process messages asynchronously, and all messages are delivered to MDBs as Jakarta Messaging messages.
Connection factories and destinations can be stored as Jakarta Messaging administered objects in a central repository rather than being hard-coded into an application.
An administrator can create and maintain Jakarta Messaging administered objects in a central repository, and IBM MQ classes for Jakarta Messaging applications can retrieve these objects by using the Java Naming Directory Interface (JNDI). Jakarta Messaging connection factories and destinations encapsulate IBM MQ-specific information such as queue manager names, channel names, connection options, queue names, and topic names. If connection factories and destinations are stored as administered objects, this information is not hard-coded into an application. This arrangement therefore provides the application with a degree of independence from the underlying IBM MQ configuration.
Jakarta Messaging is an industry standard API that can provide application portability.
A Jakarta Messaging application can use JNDI to retrieve connection factories and destinations that are stored as administered objects, and use only the interfaces that are defined in the jakarta.jms (Jakarta Messaging 3.0) package to perform messaging operations. The application is then entirely independent of any Jakarta Messaging provider, such as IBM MQ classes for Jakarta Messaging, and can be ported from one Jakarta Messaging provider to another without any change to the application.

If JNDI is not available in a particular application environment, a IBM MQ classes for Jakarta Messaging application can use extensions to the Jakarta Messaging API to create and configure connection factories and destinations dynamically at run time. The application is then completely self-contained, but is tied to IBM MQ classes for Jakarta Messaging as the Jakarta Messaging provider.
Bridge applications might be easier to write by using Jakarta Messaging.
A bridge application is an application that receives messages from one messaging system and sends them to another messaging system. Writing a bridge application can be complicated by using product-specific APIs and message formats. Instead, you can write a bridge application by using two Jakarta Messaging providers, one for each messaging system. The application then uses only one API, the Jakarta Messaging API, and processes only Jakarta Messaging messages.

Deployable environments

To provide integration with a Jakarta EE application server, the Jakarta EE standards require messaging providers to supply a resource adapter. Following the Jakarta Connectors Architecture specification, IBM MQ provides a resource adapter that uses Jakarta Messaging to provide messaging functions within any certified Jakarta EE environment. For more information, see WebSphere Liberty and the IBM MQ resource adapters.

Note: WebSphere Application Server does not currently support Jakarta EE.

Outside of the Jakarta EE environment, OSGi and JAR files are provided, making it easier for you to obtain just the IBM MQ classes for Jakarta Messaging. These JAR files are more readily deployable either stand-alone or within software management frameworks such as Maven. For more information see Obtaining the IBM MQ classes for JMS and IBM MQ classes for Jakarta Messaging separately.