Why should I use IBM MQ classes for JMS?

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

Summary of advantages of using IBM MQ classes for JMS

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

Note: JMS 2.0 has been superseded by Jakarta Messaging. IBM MQ classes for JMS continues to support the JMS 2.0 standard, but future enhancements to Java messaging will only emerge in Jakarta Messaging, hence in the IBM MQ classes for Jakarta Messaging. IBM MQ classes for JMS are only recommended for maintaining and extending existing JMS 2.0 applications. IBM MQ classes for Jakarta Messaging should be the preferred technology for new development.

You can reuse JMS skills.
IBM MQ classes for JMS is a JMS provider that implements the JMS interfaces for IBM MQ as the messaging system. If your organization is new to IBM MQ, but already has JMS application development skills, you might find it easier to use the familiar JMS API to access IBM MQ resources rather than one of the other APIs provided with IBM MQ.
JMS is an integral part of Java Platform, Enterprise Edition (Java EE).
JMS is the natural API to use for messaging on the Java EE platform. Every application server that is Java EE compliant must include a JMS provider. You can use JMS in application clients, servlets, Java Server Pages (JSPs), enterprise Java beans (EJBs), and message driven beans (MDBs). Note in particular that Java EE applications use MDBs to process messages asynchronously, and all messages are delivered to MDBs as JMS messages.
Connection factories and destinations can be stored as JMS administered objects in a central repository rather than being hard-coded into an application.
An administrator can create and maintain JMS administered objects in a central repository, and IBM MQ classes for JMS applications can retrieve these objects by using the Java Naming Directory Interface (JNDI). JMS 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.
JMS is an industry standard API that can provide application portability.
A JMS 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 javax.jms package to perform messaging operations. The application is then entirely independent of any JMS provider, such as IBM MQ classes for JMS, and can be ported from one JMS provider to another without any change to the application.

If JNDI is not available in a particular application environment, an IBM MQ classes for JMS application can use extensions to the JMS 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 JMS as the JMS provider.
Bridge applications might be easier to write by using JMS.
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 JMS providers, one for each messaging system. The application then uses only one API, the JMS API, and processes only JMS messages.

Deployable environments

To provide integration with a Java EE application server, the Java EE standards require messaging providers to supply a resource adapter. Following the Java EE Connector Architecture (JCA) specification, IBM MQ provides a resource adapter that uses JMS to provide messaging functions within any certified Java EE environment.

While it has been possible to use the IBM MQ classes for Java inside Java EE, this API is not engineered or optimized for this purpose. For more information about IBM MQ classes for Java considerations within Java EE, see Running IBM MQ classes for Java applications within Java EE.

Outside of the Java EE environment, OSGi and JAR files are provided, making it easier for you to obtain just the IBM MQ classes for JMS. 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.