Using WebSphere MQ classes for JMS

WebSphere® MQ classes for Java Message Service ( WebSphere MQ classes for JMS) is the JMS provider that is supplied with WebSphere MQ. As well as implementing the interfaces defined in the javax.jms package, WebSphere MQ classes for JMS provides two sets of extensions to the JMS API.

The JMS specification defines a set of interfaces that applications can use to perform messaging operations. The javax.jms package defines the JMS interfaces, and a JMS provider implements these interfaces for a specific messaging product. WebSphere MQ version 7.5 currently uses the JMS 1.1 specification. WebSphere MQ classes for JMS is a JMS provider that implements the JMS interfaces for WebSphere MQ.

The JMS specification expects ConnectionFactory and Destination objects to be administered objects. An administrator creates and maintains administered objects in a central repository, and a JMS application retrieves these objects using the Java Naming and Directory Interface (JNDI). WebSphere MQ classes for JMS supports the use of administered objects, and an administrator can use either the WebSphere MQ JMS administration tool or WebSphere MQ Explorer to create and maintain administered objects.

WebSphere MQ classes for JMS also provides two sets of extensions to the JMS API. The main focus of these extensions concerns creating and configuring connection factories and destinations dynamically at run time, but the extensions also provide function that is not directly related to messaging, such as function for problem determination.
The WebSphere MQ JMS extensions
Previous releases of WebSphere MQ classes for JMS contain extensions that are implemented in objects such as MQConnectionFactory, MQQueue, and MQTopic objects. These objects have properties and methods that are specific to WebSphere MQ. The objects can be administered objects, or an application can create the objects dynamically at run time. This release of WebSphere MQ classes for JMS maintains these extensions, which are now known as the WebSphere MQ JMS extensions. You can continue to use, without change, any applications that use these extensions.
The IBM® JMS extensions
This release of WebSphere MQ classes for JMS provides a more generic set of extensions to the JMS API, which are not specific to WebSphere MQ as the messaging system. These extensions are known as the IBM JMS extensions and have the following broad objectives:
  • To provide a greater level of consistency across IBM JMS providers
  • To make it easier to write a bridge application between two IBM messaging systems
  • To make it easier to port an application from one IBM JMS provider to another

The extensions provide function that is similar to that provided in Message Service Client for C/C++ and Message Service Client for .NET.

Why should I use WebSphere MQ classes for JMS?

Using WebSphere MQ classes for JMS has the following advantages:
  • You can reuse JMS skills.

    WebSphere MQ classes for JMS is a JMS provider that implements the JMS interfaces for WebSphere MQ as the messaging system. If your organization is new to WebSphere MQ, but already has JMS application development skills, you might find it easier to use the familiar JMS API to access WebSphere MQ resources rather than one of the other APIs provided with WebSphere 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, JavaServer 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.

  • An administrator can create and maintain JMS administered objects in a central repository, and WebSphere MQ classes for JMS applications can retrieve these objects using the Java Naming and Directory Interface (JNDI).

    JMS connection factories and destinations encapsulate WebSphere 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 WebSphere 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 defined in the javax.jms package to perform messaging operations. The application is then entirely independent of any JMS provider, such as WebSphere 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, a WebSphere 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 WebSphere MQ classes for JMS as the JMS provider.

  • Bridge applications might be easier to write 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 using product specific APIs and message formats. Instead, you can write a bridge application using two JMS providers, one for each messaging system. The application then uses only one API, the JMS API, and processes only JMS messages.