Does the JMS specification require compatibility between JMS implementations, or will all parties involved have to use the same vendor?
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.
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)?