Java Message Service
Richard Monson-Haefel and David A. Chappell
O’Reilly
January 2001, First Edition
ISBN: 0-596-00068-5
Review by Spiro Michaylov
spiro AT michaylov DOT com
It seems that JMS is used for messaging in a given project in two broad situations:
- The project is being developed substantially using Java 2 Enterprise Edition (J2EE), so it makes sense to use the messaging component of the chosen J2EE platform.
- The project is not using J2EE in general, but a there is a desire to avoid lock-in to a specific vendor’s messaging platform. Then using JMS instead of a proprietary messaging API seems like a good way to avoid vendor lock-in.
Developers in both situations need to know how to use the API effectively, how to achieve good performance, and perhaps how to get the best out of their specific JMS platform. Additionally, developers in both situations may need to know to what extent JMS really does allow them to avoid vendor lock-in (after all, it’s often an objective of projects that make heavy use of J2EE). This involves understanding the pitfalls of vendor neutrality, and what conditions have to be met in order to achieve it. Developers that are in the second situation, or who are contemplating the choice of JMS to avoid vendor lock-in, may also need to know what they’re giving up by choosing JMS over a proprietary API. (In fact, it could even be argued that one could use a proprietary messaging API even from a J2EE application, if there were enough incentive to do so).
This concise and well-written book gives a good overview of messaging in general. It also provides extensive coverage and discussion of the JMS APIs, including advanced topics such as guaranteed messaging, transactions, acknowledgments and failures, and good introductions to side topics like JNDI. The advanced material is kept well out of the way of the basic material, and there are enough examples to keep the exposition “real”, so the book also makes a good quick start guide.
There are important issues that could have been covered in detail but weren’t. There is no significant discussion of performance issues, and no attempt is made to discuss the architectural issues behind the use of messaging in general. This seems quite reasonable: though they’re related, these are not JMS issues per se, and could easily provide enough material for another book.
In summary, this is a valuable introduction and reference for developers using the JMS API.
But let’s return to one of the biggest issues behind JMS: its ability to provide vendor-neutral messaging. JMS is intended to provide a uniform API to the messaging systems of multiple vendors. In some cases JMS is even adopted in organizations that have been using a certain vendor’s messaging API for many years, even since before JMS or even Java existed. Usually the motivation is to make it possible to change to the messaging middleware of a different vendor, either because of a present need (or dissatisfaction) or the more general concern that such a change may be necessary in the indefinite future and should be prepared for now.
Any common API that is intended to hide differences between products is bound to have some problems. How much are the differences hidden, really? How well does each vendor’s implementation of the common API utilize the underlying system, especially if that API was developed as an afterthought? What happens if you need to use two different vendor implementations from a single application? How well do each vendor’s systems allow legacy applications to coexist with those developed for the common API? Consider the differences between the topic spaces in the various JMS implementations. The Tibco JMS topic space looks suspiciously like the Tibco Rendezvous subject space. This is not surprising, but it could be problematic. Consider message structure. In Tibco Rendezvous: an RvMsg can contain other RvMsg instances. Naturally, in Tibco’s Rendezvous/JMS bridge an RvMsg maps to a MapMessage. But a MapMessage cannot contain a MapMessage in the JMS standard. Tibco very reasonably solve this with a nonstandard extension, but what are the consequences for the developer?
This criticism certainly doesn’t prevent the book from being useful (even crucial) but prospective readers should keep it in mind, as perhaps should the authors, when thinking of a second edition.
|
