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.

IBM MQ classes for JMS is one of two alternative APIs that Java applications can for use to access IBM MQ resources. The other API is IBM MQ classes for Java. Although existing applications that use the IBM MQ classes for Java continue to be fully supported, new applications should use the IBM MQ classes for JMS (see Choice of API).

Summary of advantages of using IBM MQ classes for JMS

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

• We 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. We 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, we 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. See the IBM technote Use WebSphere MQ Java Interfaces in J2EE/JEE Environments for details of IBM MQ classes for Java considerations 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 now more readily deployable either stand-alone or within software management frameworks such as Maven. For more information see the IBM technote Obtaining the WebSphere MQ classes for JMS.

Choice of API

New applications should use the IBM MQ classes for JMS rather than IBM MQ classes for Java.

IBM MQ classes for JMS provide access to both the point-to-point and publish/subscribe messaging features of IBM MQ. As well as sending JMS messages that provide support for the JMS standard messaging model, applications can also send and receive messages without additional headers and so can inter-operate with other IBM MQ applications, for example, C MQI applications. Full control of the MQMD and MQ message payloads are available. Further IBM MQ features such as message streaming, asynchronous put and report messages are also available. Using the supplied PCF helper classes, IBM MQ PCF administration messages can be sent and received through the JMS API and can be used to administer queue managers.

Features that have recently been added to IBM MQ, such as asynchronous consume and automatic reconnection, are not available in the IBM MQ classes for Java, but are available in the IBM MQ classes for JMS. Existing applications that use the IBM MQ classes for Java continue to be fully supported.

If you need access to IBM MQ features that are not available through the IBM MQ classes for JMS, we can raise a Request for Enhancement (RFE). IBM can then advise whether the implementation is possible in the IBM MQ classes for JMS implementation, or whether there is a best practice that can be followed. For additional messaging features, as IBM is a contributor to the open standard, these features can be raised as part of the JCP process.