Does the JMS specification require compatibility between JMS implementations, or will all parties involved have to use the same vendor?

Jerry Smith

The JMS specification, like many specifications, is an attempt to specify a software system with both core and optional functionality. As with many specifications, there are design and implementation issues that are unclear, or not fully specified. Sometimes, specifications are unclear in certain areas by accident; sometimes, ambiguities are inevitable, simply because the technology is new and it is virtually impossible to fully anticipate every issue. Over time, feedback from the developers who implement the specification helps clarify certain issues and the specification is then revised.

Vendors who provide JMS implementations must implement the core functionality; implementing optional functionality is, of course, optional. Another issue is vendor-specific functionality beyond the optional functionality described by the specification. Developers who use JMS implementations expect optional functionality to be missing in some implementations. In contrast, vendor-specific functionality is not likely to appear, in any other implementation (at least not as compatible, extended functionality). Sometimes, vendor-specific functionality provides a truly needed service for the vendor's customers; sometimes, it simply inhibits portable software development.

A developer should expect each JMS implementation to be highly source-code compatible with respect to the core functionality. That is, with minor changes to various configuration-related code areas, an enterprise should be able to switch JMS implementations half way through the development process, assuming that they strive to write portable code. Of course, the user cannot expect runtime compatibility among JMS implementations, because the specification does not address low-level transport details, as well as other implementation issues.

The JMS specification, for example, does not address the overall JMS server administration process. (The specification does outline so-called administered objects.) Thus, each vendor's configuration and administration interface will vary, for example, lightweight text-oriented, command-line tools versus graphical administration consoles with elaborate resource monitoring charts. Even with these variances, however, the developer should still be able to deliver applications with JMS functionality that is approximately 95 percent portable.

Choosing a JMS vendor is not unlike choosing a relational database vendor, because all parties in the enterprise must weigh the importance of the vendors' extensions, as well as the robustness and portability of the core functionality. Although the JMS specification has been around for a relatively short period (in terms of specification and standards metrics), there are already several very stable JMS implementations, with several more under development. (Compare this stability to, for example, Swing.)

One issue that organizations should consider is whether or not a JMS implementation is truly enterprise-capable and is compatible (as much as possible) with other frameworks, for example, Enterprise JavaBeans (EJB). Furthermore, does the JMS implementation make its administered objects available via standard services now common in the Java arena, such as the Java Naming and Directory Interface (JNDI)?

See the JMS corner of the Java universe for a list of JMS vendors. See the Taco framework for an example of JMS-related software that is striving to be 100 percent portable.