When Should I use JMS?

JMS has been a godsend to Java developers who want to use tried-and-tested messaging paradigms without having to wrestle with multiple proprietary APIs. A new breed of messaging vendors 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.

However, JMS is not the only show in town. This article discusses when you might prefer to use three existing alternatives to JMS.

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 should be used? Is it XA? What's the delivery mode? Acknowledgment 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/messenger.html.

Messenger is already in use in SpiritSoft's new SpiritCache product; it helped us simplify the JMS code immensely.

Use JAXM for Interbusiness 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, in which 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, such as JAXM - the Java APIs for XML Messaging - developed by the Java Community Process as JSR 67.

JAXM is designed to support interbusiness messaging. Based on SOAP, message formats, payloads, and transport are standardized so that the other business will be able to receive and understand them. Unlike JMS, JAXM supports only 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. JMS messages can of course be bridged across JAXM.

Use JavaMail for Messages Anywhere

E-mail 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 are 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 intrabusiness messaging, with full programmatic control over quality of service and delivery options.
• Messenger provides a simple facade to JMS which - trading flexibility for simplicity - eases development and abstracts complexities into a simple configuration file.
• JAXM provides an interbusiness messaging API, supporting complex (but XML only) formats across standard transport protocols, and offering a standard approach for bridging between different JMS providers.
• JavaMail provides lowest common denominator, slow, but human-readable messaging using infrastructure already available on virtually every computing platform.