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
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
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
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
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.
Pick the API (or set of APIs) that best suits your business needs:
If there's 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
- 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
- JavaMail provides lowest common denominator, slow, but
human-readable messaging using infrastructure already available on
virtually every computing platform.
Nigel is director of product management at SpiritSoft with over 20
years' experience in the industry,
specializing in distributed systems architecture and audit.