HomeDigital EditionSys-Con RadioSearch Java Cd
Advanced Java AWT Book Reviews/Excerpts Client Server Corba Editorials Embedded Java Enterprise Java IDE's Industry Watch Integration Interviews Java Applet Java & Databases Java & Web Services Java Fundamentals Java Native Interface Java Servlets Java Beans J2ME Libraries .NET Object Orientation Observations/IMHO Product Reviews Scalability & Performance Security Server Side Source Code Straight Talking Swing Threads Using Java with others Wireless XML

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.

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

Author Bio
Nigel is director of product management at SpiritSoft with over 20 years' experience in the industry, specializing in distributed systems architecture and audit. [email protected]

All Rights Reserved
Copyright ©  2004 SYS-CON Media, Inc.
  E-mail: [email protected]

Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. SYS-CON Publications, Inc. is independent of Sun Microsystems, Inc.