Java Message Service, 2nd Edition

JMS API

JMS is an API for enterprise messaging created by Sun Microsystems through JSR-914. JMS is not a messaging system itself; it’s an abstraction of the interfaces and classes needed by messaging clients when communicating with messaging systems. In the same way that JDBC abstracts access to relational databases and JNDI abstracts access to naming and directory services, JMS abstracts access to messaging providers. Using JMS, an application’s messaging clients are portable across messaging server products.

The creation of JMS was an industry effort. Sun Microsystems took the lead on the spec and worked very closely with the messaging vendors throughout the process. The initial objective was to provide a Java API for connectivity to enterprise messaging systems. However, this changed to the wider objective of supporting messaging as a first-class Java-distributed computing paradigm equal with RPC-based systems such as CORBA and Enterprise JavaBeans. Mark Hapner, the JMS spec lead at Sun Microsystems, explained:

There were a number of MOM vendors that participated in the creation of JMS. It was an industry effort rather than a Sun effort. Sun was the spec lead and did shepherd the work but it would not have been successful without the direct involvement of the messaging vendors. Although our original objective was to provide a Java API for connectivity to MOM systems, this changed over the course of the work to a broader objective of supporting messaging as a first class Java distributed computing paradigm on equal footing with RPC.

The result is a best-of-breed, robust specification that includes a rich set of message delivery semantics, combined with a simple yet flexible API for incorporating messaging into applications. The intent was that in addition to new vendors, existing messaging vendors would support the JMS API.

The JMS API can be broken down into three main parts: the general API, the point-to-point API, and the publish-and-subscribe API. In JMS 1.1, the general API can be used to send and receive messages from either a queue or a topic. The point-to-point API is used solely for messaging with queues, and the publish-and-subscribe API is used solely for messaging using topics.

Within the JMS general API, there are seven main JMS API interfaces related to sending and receiving JMS messages:

• ConnectionFactory

• Destination

• Connection

• Session

• Message

• MessageProducer

• MessageConsumer

Of these general interfaces, the ConnectionFactory and Destination must be obtained from the provider using JNDI (per the JMS specification). The other interfaces are created through factory methods in the various API interfaces. For example, once you have a ConnectionFactory, you can create a Connection. Once you have a Connection, you can create a Session. Once you have a Session, you can create a Message, MessageProducer, and MessageReceiver. The relationship between these seven primary JMS general API interfaces is illustrated in Figure 1-5.

In JMS, the Session object holds the transactional unit of work for messaging, not the Connection object. This is different from JDBC, where the Connection object holds the transactional unit of work. This means that when using JMS, an application will typically have only a single Connection object but will have a pool of Session objects.

There are several other interfaces related to exception handling, message priority, and message persistence. These and other API interfaces are discussed in more detail throughout the book and also in Appendix A.

Figure 1-5. JMS general API core interfaces

Point-to-Point API

Once you gain an understanding of the JMS general API, the rest of the JMS API is fairly easy to infer and understand. The point-to-point messaging API refers specifically to the queue-based interfaces within the JMS API. The interfaces used for sending and receiving messages from a queue are as follows:

• QueueConnectionFactory

• Queue

• QueueConnection

• QueueSession

• Message

• QueueSender

• QueueReceiver

As in the JMS general API, the QueueConnectionFactory and Queue objects must be obtained from the JMS provider via JNDI (per the JMS specification). Notice that most of the interface names simply add the word Queue before the general API interface name. The exception to this is the Destination interface, which is named Queue, and the MessageProducer and MessageConsumer interfaces, which are named QueueSender and QueueReceiver, respectively. Figure 1-6 illustrates the flow and relationship between the queue-based JMS API interfaces.

Applications using the point-to-point messaging model will typically use the queue-based API rather than the general API.

Figure 1-6. JMS point-to-point API core interfaces

Publish-and-Subscribe API

The topic-based JMS API is similar to the queue-based API in that, in most cases, the word Queue is replaced with the word Topic. The interfaces used within the pub/sub messaging model are as follows:

• TopicConnectionFactory

• Topic

• TopicConnection

• TopicSession

• Message

• TopicPublisher

• TopicSubscriber

Notice that the interfaces in the pub/sub domain have names similar to those of the p2p domain, with the exception of TopicPublisher and TopicSubscriber. The JMS API is very intuitive in this regard. As stated at the start of this chapter, pub/sub uses topics with publishers and subscribers, whereas p2p uses queues with senders and receivers. Notice how this terminology matches the API interface names. The relationship and flow of the topic-based JMS API interfaces are illustrated in Figure 1-7.