The first chapter introduces MOM. There are two models that a JMS provider might implement — point-to-point (or queue) and publish/subscribe messaging. The second chapter develops a simple pub/sub example, a chat room application. The third chapter discusses messages in some detail — headers, types, and selectors. Selectors allow a receiver to be selective about which messages it’s interested in receiving. Among other things, a selector can be used to match a reply to a request.

Chapters 4 and 5 are devoted to pub/sub and point-to-point, respectively. For both, simple applications are developed for illustration. Chapter 6 discusses a variety of topics, for example, guaranteed messaging, that is, once-and-only-once delivery. Chapter 7 is devoted to deployment considerations, including performance and security. Chapter 7 discusses JMS in the context of J2EE and EJBs. Chapter 8 provides an overview of some JMS providers. One would do well to go to the Sun website instead, as it is more inclusive. There are appendices on the JMS API, message headers, and message properties.

There is the usual smattering of misprints. Then on page 112, there is a serious error. The authors say, “Unless you are doing a synchronous request-reply, you should avoid grouping a send followed by an asynchronous receive within a transaction.” Even with request-reply, you don’t want to group a send followed by a receive within a transaction. The reason is simple — deadlock. The sending application sends a request and does a receive with wait for the reply. Within a transaction, the sent request is not committed until the reply is received and so, is not visible to any potential receiving application until then. Of course, a receiving application won’t send a reply until it receives a request. The result is deadlock.
Rating: 3 / 5