Migrating a JMS application to MQ

Question

Today, if we create an application using the JMS API (using MDB as message listeners, start it, say, GlassFish or Weblogic 10), and tomorrow we can say that the traffic is crazy, can we transfer this application without changing the code to any product like Websphere MQ ... theoretically, MQ is more like a specialized JMS provider ...

Answer 1

Yes and no. (The answer to all the best questions is always "it depends.")

If an application adheres to the JMS specification, it should run unchanged on any JMS-compatible provider. This is good news.

The bad news is that it really matters how the provider implemented the JMS. For example, Section 6.5 of the JMS 1.1 specification states this:

Many Pub / Sub provider group topics are in the hierarchy and provide different subscription options for parts of the hierarchy. JMS does not place restrictions on the theme object it represents. This can be a leaf in the hierarchy or a large part of the hierarchy (for subscribing to a common class of information).

The organization of topics and the granularity of subscribing to them is an important part of the Pub / Sub application architecture. JMS does not specify a policy for what should be done. If the application uses a vendor-specific theme grouping mechanism, it must have this document. If the application is installed using another provider, it is the administrator’s task to create an equivalent architecture theme and create an equivalent Theme Objects.

This means that some parts of the specification are open to interpretation by the JMS transport provider. Only the owner of the application will determine how to match these differences when migrating applications.

Another aspect of this question is that even if the specification is strictly enforced by the two transport providers, the behavior of the API may differ. An example of this is connection management. Some providers skip connections transparently with the client, others ask the client to re-establish the connection sequence after the failure. Both approaches can be 100% compatible with JMS, but both require different application logic.

Thus, the answer is that complying with the JMS-API gives you a very close to fully portable and the required amount of porting depends on the differences in how the transport provider interprets parts of the specification and / or implemented functions that are ambiguous in the specification.

Answer 2

It's very easy for developers to be tempted (or sometimes required) to use the vendor’s proprietary functionality in a JMS-based application. In a short period of time spent using JMS, I noticed four reasons why a developer can resort to using a proprietary API.

First, getting Destination and ConnectionFactory objects from a naming service is inconvenient, especially for a developer new to JMS who doesn't want to spend time learning JMS administration commands before they can write an application. It might be more convenient to use the provider’s own functions to directly create Destination and ConnectionFactory objects.

Secondly, for JMS products, they usually offer quality of service higher and higher than those defined in the JMS specification. If these qualities of service are associated with, say, Session , Producer or Consumer , then it’s natural for providers to provide their own set<Name>() tags for these types. Simply put, not all proprietary quality of service can be encapsulated in managed objects.

Third, when a JMS-related operation fails, it throws a (subtype) JMSException . An application developer can request a handled exception in one of several ways, depending on the nature of the exception. However, the JMS specification states that two of the three pieces of information provided by JMSException are property of the JMS provider. Because of this, the developer may have to rely on the supplier’s confidential information contained in the exception when deciding to process it.

Finally, the JMS indicates that the message consists of three parts: (1) header fields, (2) arbitrary properties (i.e. name = value pairs) and (3) body. The intended use of (2) is to support flexible message selection in consumer applications. For example, a producer application running, say, in London, can add location = London to message properties before sending a message. The consumer application can then use the "(location = 'London')" message selector to ensure that it only receives messages with this property value. That sounds good. The bad bit is that the JMS specification reserves property names starting with JMS_<vendor> for use by JMS providers, and some providers use such properties to specify their own quality of service for each message. A developer who wants to use the proprietary quality of service for each message will need to change the code of the producer application so that he sets the property of ownership before sending the message.

T.Rob's warning about topic hierarchies is another issue to worry about.

Answer 3

WebSphere MQ is a very mature, stable platform that, as far as I know, is fully compliant with the JMS standard. Many organizations use JMS over MQ as their transport. I have worked in several that use JMS and their own MQ mechanisms to communicate with the MQ level, and I have not come across any complaints about the implementation of IBM JMS. I did not work with anyone who changed the JMS providers, though ...

IBM provides a bunch of Java libraries that only reference the javax.jms package, so that unless you make any improvements to your vendor, you must be able to host MQ libraries in order for MQ to become your JMS provider. (You may need some administration using the MQ toolkit to do something like setting up a JMS subscription, however ... I didn’t use the JMS aspects of MQ, but only the main libraries.)

Check out this IBM page for more information on the MQ JMS libraries.

If you used only WebSphere MQ as an example, then yes, you still need to check the compliance of the candidate providers with the specifications, but JMS has been around for some time, and I think that all the offers of major players will be a suitable JMS provider.

Answer 4

Since JMS is a relatively simple API (compared to JDBC, etc.), it remains fairly portable between implementations if you take some basic steps to start with .

Regarding the performance improvements from WebSphereMQ, I'm not sure if you will find that to be the case. If you use Point-to-Point, perhaps. But if you are doing Pub / Sub, this is unlikely. See This Criterion , which is admittedly published by a competitor but uses a third-party benchmark and is actually quite generous to some open source contributors.