Question

Today if we build an application using the JMS API (using MDBs as message listeners, host it on lets say GlassFish or Weblogic 10) and tomorrow lets say the traffic goes crazy, can we port this application without code changes to some product like Websphere MQ… coz theoretically MQ is more like a dedicated JMS provider …

Answer 1

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

If the application adheres to the JMS specification then it should run unchanged on any JMS compliant provider. That’s the good news.

The bad news is that it really does matter how the provider implemented JMS. For example, Section 6.5 of the JMS 1.1 specification says this about topics:

Many Pub/Sub providers group topics
into hierarchies and provide various
options for subscribing to parts of
the hierarchy. JMS places no
restrictions on what a Topic object
represents. It might be a leaf in a
topic hierarchy, or it might be a
larger part of the hierarchy (for
subscribing to a general class of
information).

The organization of topics and the
granularity of subscriptions to them
is an important part of a Pub/Sub
application’s architecture. JMS does
not specify a policy for how this
should be done. If an application
takes advantage of a provider-specific
topic grouping mechanism, it should
document this. If the application is
installed using a different provider,
it is the job of the administrator to
construct an equivalent topic
architecture and create equivalent
Topic objects.

What this means is that certain parts of the specification are open to interpretation of the JMS transport provider. It will be up to the application owner to determine how to map these differences when porting applications.

Another aspect of this question is that even when the specification is followed strictly by two transport providers, the behavior behind the API may differ. An example of this is connection management. Some providers fail connections over transparently to the client, others ask the client to re-drive the connection sequence after a failure. Both approaches can be 100% JMS compatible and yet both require different application logic.

So the answer is that adhering to the JMS API gets you very close to fully portable and the amount of porting that is required depends on the differences in how the transport provider interprets parts of the spec and/or implemented features that are ambiguous in the spec.