When should I use JMS?

First published in SpiritSoft Digital Newsletter, December 2001

JMS - the universal messaging API

JMS has been a Godsend to Java™ developers wanting to use tried and tested messaging paradigms without having to wrestle with multiple proprietary APIs. A new breed of messaging vendors like SpiritSoft is delivering enterprise quality JMS implementations at substantially lower costs than the previous MOM incumbents, as well as offering JMS wrappers to help integrate legacy and Java environments, and extending JMS to lightweight and mobile devices.

The adoption of a single messaging API has the same effect on the market today as did the adoption of SQL, ODBC and then JDBC as the standard APIs for relational databases during the 1980s and 1990s. Developers can learn once, and then deploy any conforming product. Vendors cannot impose their own, proprietary standards - and their pricing power is reduced because developers know they can simply replace one JMS implementation with another.

JMS is now a mandatory component of Java 2 Platform, Enterprise Edition (J2EE™) from release 1.3. Application servers (and developers) now rely on the JMS API, and that means we can be sure that it will be maintained and developed in the future.

However, JMS is not the only show in town. This article discusses when you might prefer (or be forced) to use some alternatives to the JMS API.

Use Messenger to simplify JMS development

For an application developer the complex threading model in JMS can be hard to use; you have to understand which thread owns which session (and consumer and producer), from which session you can send/receive or add a listener and so on. This can be especially hard in Servlet or EJB containers when you don't know what thread your code is called from.

Messenger is a simple open source framework for working with JMS that takes care of all these complex thread pooling issues and quality of service configuration options. Developers using Messenger can simply send, receive or add listeners - then Messenger takes care of the details. The same Messenger instance can be shared across many threads.

At deployment time the exact quality of service and network topology (what JMS provider to use, is it XA, what's the delivery mode, acknowledgement mode, is it a topic or queue, is it durable, what's the client name etc) is all contained in a single XML deployment document. You can find examples and more information at http://jakarta.apache.org/commons/sandbox/messenger/.

The trade-off for the developer is clear. At the (small) cost of using a façade, the developer writes less code, and the code he writes is much less likely to break the JMS provider. He has to supply a configuration file - rather than simply hard-code the details - but that makes it so much easier in the future to maintain and modify the configuration, without having to change the code at all. That makes Messenger an ideal interface for application developers, who want to maximize application flexibility without having to give away the source code.

Already, leading JMS vendors including SpiritSoft are working on ideas for JMS 1.1 - and one of the suggestions is to simplify the queue/topic class structure by supporting generic Connection, Destination, Session, MessageProducer and MessageConsumer classes. This may help developers to make sense of JMS in the future, but there are still lots of programming rules to remember; so why not let Messenger remember for you?

SpiritSoft developer James Strachan has developed Messenger. We are already using Messenger in our new SpiritCache product - it helped us simplify the JMS code immensely.

Use JAXM or SOAP for inter-business messaging

JMS implementations from different vendors are not required to interoperate - details of wire format and transport protocol are left to the provider's discretion. So JMS usage is limited to 'single provider' situations - where the developer controls both producers and consumers.

When the other end of the conversation is another division or company, JMS gives way to wire-format standard based APIs. One such is JAXM - the Java™ APIs for XML Messaging - just finalized by the Java Community Process(sm) as JSR 67 (see http://jcp.org/jsr/detail/67.jsp).

JAXM is designed to support inter-business messaging. Based on Simple Object Access Protocol (SOAP) 1.1 with Attachments, message formats, payloads and transport are standardized so that the other business will be able to receive and understand them. Unlike JMS, JAXM only supports the point-to-point messaging domain - not least because B2B messaging is usually one to one. The high performance, low latency and programmatic flexibility of JMS are traded for simplicity, reliability and interoperability.

There has been some controversy around JAXM and its relationship with JMS. For example, BEA voted against JSR-67 with the following comments:

"We believe that having two Java APIs for messaging is an inherently bad idea and one that will be attacked by our competition as an example of a solution designed by committee. JMS, which was just added to J2EE in 1.3, is being used today for messages with XML payloads, even though there is no explicit XML support. We believe the additional features of XML and SOAP processing in JAXM would be better surfaced as a new release of JMS. We further believe that this issue must be addressed now before developers have the opportunity to use this API or we will never be able to converge them in the future."

However we are finding that JAXM and SOAP are already beginning to be used at the edge of the business organization, to handle communications with other businesses, or with other parts of the same business.

Between businesses, JAXM is used in preference to simpler (but less secure and reliable) HTTP operations (POST and GET). It can also be seen as a more dependable and trackable business version of 'structured email' - especially as it can support the same sorts of attachments.

Within a business, JAXM is preferred to JMS whenever two departments are unable to agree on a single vendor's messaging technology. JMS messaging can be much faster than JAXM - not least because JAXM messages have a substantial header and envelope - but only at the (perhaps insuperable) cost of forced standardization.

JMS messages can of course be bridged across JAXM. SpiritSoft's SpiritBroker can act as a SOAP server (receiving messages and dispatching them directly or via JMS to waiting applications) or a JAXM/SOAP client, taking JMS messages and sending them out over the Internet. And remember, that means that not only can you bridge from one JMS provider to another; you can also bridge messages from J2EE to Microsoft's .NET platform - which also depends heavily on SOAP - or vice versa.

Now SpiritSoft gives you all these ways to bridge Java to Microsoft:

The SpiritWave JMS driver for Microsoft MSMQ - you can send MSMQ messages direct from your Java program
COM and C++ interfaces to JMS (need an Active/X control - you've got it) - you can send messages (through any supported MOM) from your VB or C# application
SpiritBroker and JAXM - to bridge peer to peer between J2EE and .NET servers

Use JavaMail for messages anywhere

Email is slower still than B2B messaging but has a huge installed base - even home users have access to Yahoo or Hotmail. Just as in the past Telex® was used as a hybrid human/machine readable network - you can see its echoes in EDI formats like SWIFT - the JavaMail™ API is ideal for low priority, unpredictable messaging where the receiver may be a human or a process, lengthy delivery delays and even message loss are possible, and disconnected clients likely. Like SOAP, JavaMail supports multipart MIME messages.

Summary

Pick the API (or set of APIs) that best suits your business needs:

JMS is the ideal high-performance messaging platform for intra-business messaging.
Use JMS directly if you need full programmatic control over quality of service and delivery options
Application server developers, and anyone who needs complete control and maximum performance will want to stick to JMS
Messenger provides a simple façade to JMS which - trading flexibility for simplicity - eases development and abstracts complexities into a simple configuration file.
Use Messenger if you are new to JMS - it's easier to learn
Application developers will use Messenger - the configuration file is more flexible than code
JAXM / SOAP provides an inter-business messaging API, supporting complex (but XML only) formats across standard transport protocols, and offering a standard approach for bridging between different JMS providers.
Use JAXM if your message format is XML, and the 'other end' is not under your control
JAXM's SOAP support opens up the communication channel between J2EE and .NET
JavaMail provides lowest common denominator, slow, but human-readable messaging using infrastructure already available on virtually every computing platform

If there is any likelihood that your quality of service or connectivity requirements will change over time, use configurable facades like Messenger to make sure you can easily plug the right solution into your application without having to make expensive code changes.