Porting a JMS application to MQ_问答_开发者_运维开发者技术经验分享

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 ...

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.

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

First, obtaining Destination and ConnectionFactory objects from a naming service is inconvenient, especially for a developer new to JMS who does not want to have to spend time learning JMS administration commands before being able to write an application. It might be more convenient to use vendor-proprietary functions to create Destination and ConnectionFactory objects directly.

Second, it is common for JMS products to offer qualities of service above and beyond those defined in the JMS specification. If these qualities of service are related to, say, Session, Producer or Consumer, then it is natural for a vendor to provide proprietary set<Name>() operations on those types. Put simply, not all proprietary qualities of service can be encapsulated in administered objects.

Third, when a JMS-related operation fails, it throws a (subtype of) JMSException. The developer of an application might wish to process a caught exception in one of several ways, depending on the nature of the exception. However, the JMS specification states that two out of the three pieces of information provided by JMSException are proprietary to a JMS vendor. Because of this, a developer may need to rely on vendor-proprietary information contained in an exception when deciding how to process it.

Finally, JMS specifies that a message is composed of three parts: (1) header fields, (2) arbitrary properties (that is, name=value pairs), and (3) a body. The intended use of (2) is to support flexible message selection in consumer applications. For example, a producer application running in, say, London, might add location=London to a message’s properties before sending the message. A Consumer application could then use the message selector "(location = 'London')" to ensure it receives only messages with that property value. That sounds good. The bad bit is that the JMS specification reserves property names starting with JMS_<vendor> for use by JMS vendors, and some vendors use such properties to specify a proprietary quality of service on a per message basis. A developer who wishes to make use of a proprietary, per-message quality of service will have to modify the code of a producer application so it sets the proprietary property prior to sending a message.

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

WebSphere MQ is a very mature, stable platform which - as far as I know - fully complies with the JMS standard. Numerous organisations use JMS over MQ as their transport. I have worked in several that use both JMS and native MQ mechanisms to talk to the MQ layer, and I have not come across any complaints about the IBM JMS implementation. I have not worked with anyone that has changed JMS providers, though...

IBM provides a bunch of Java libraries that only reference the javax.jms package, so as long as you haven't let any vendor-specific enhancements into your code, you should be able to slot in the MQ libraries to have MQ become your JMS provider. (You may need to do some administration with the MQ tooling to do things like set up JMS subscriptions, however... I haven't used the JMS aspects of MQ, only the core libraries.)

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

If you only used WebSphere MQ as an example then yes, you may still need to check the candidate vendors' compliance with the spec, but JMS has been around a while and I think all of the big players' offerings would be a suitable JMS provider.

Since JMS is a relatively simple API (compared to JDBC etc.) it remains quite portable between implementations, provided you take some basic measures to begin with.

As far as getting better performance from WebSphereMQ, I am not sure you will find that to be the case. If you are using Point-to-Point, perhaps. But if you are doing Pub/Sub, it's pretty unlikely. See this benchmark which is admittedly published by a competitor, but it uses a third party benchmark and is actually quite generous to some open source contestants.