he Java Messaging Service (JMS) API, a Sun Microsystems interface for connecting Java programs to enterprise messaging middleware, is composed of multiple object interfaces with a hierarchy of relationships. The JMS class hierarchy in particular is extensive and can seem confusing at first glance. (Figure 1 illustrates the relationships among the classes within JMS.) However, this complexity is necessary for JMS to:

Figure 1: The JMS Class Hierarchy (UML)

Although the reasons for its complexity are sound, the relationships among JMS classes make writing code to the JMS API tedious and confusing at times. Applying the Facade pattern offers a solution to this problem.

A Facade is a design pattern that hides the details and complexities of the lower-level software service for which it is written, making the service easier to use. In fact, the lower-level classes need not be classes at all. They can be an API in the form of a code library or a Web service.

A Facade also provides a unified entry point into the layers of the software. This reduces your application’s dependency on the software service details and allows the Facade to hide future changes in the software service itself. JMS Class Model Complexity: Simplification Needed
The JMS class model is a complex structure that can be tedious to code to and difficult to remember. It can also result in a lot of duplicate code within your application, some for working with JMS topics and the rest for JMS queues. This section describes the highly involved sequence of code that JMS requires.

To use JMS, you first must get a connection to your JMS provider. Through JNDI, retrieve the javax.jms.ConnectionFactory object, which you’ll use to get this connection in the form of a javax.jms.Connection object (For an overview of JNDI, read the sidebar, “Java Naming and Directory Interface (JNDI)“.).

In JMS, messages are sent to, or received from, a destination. The javax.jms.Destination class is the base class to the more familiar javax.jms.Topic or javax.jms.Queue classes. We’ll discuss these classes in more detail as we go along.

You must create a javax.jms.Session object for every javax.jms.Destination in which your application is interested. To create a Session object you must call the appropriate method on the Connection object. Each Session can be used by only one thread at a time. This means that for two or more threads to listen to the same Destination, they each must retrieve their own instance of a Session object for that Destination.

In turn, you use a Session object to create a javax.jms.MessageProducer object to send messages to a Destination, a javax.jms.MessageConsumer object to receive messages, and the javax.jms.Message objects themselves.

All the classes discussed so far are actually abstract interfaces, thus they cannot be instantiated themselves. Instead, JMS defines more specific classes that extend these interfaces.

To clarify, the UML diagram in Figure 2 illustrates the extended class model for the ConnectionFactory, Connection, and Session classes.

Figure 2: The JMS Connection and Session Types

You must know ahead of time whether you will need a TopicConnectionFactory, a QueueConnectionFactory, or both. References to these objects also are retrieved through JNDI. The only difference between the two connection factory classes is the type of Connection object each one creates: a TopicConnection or a QueueConnection. In turn, the only difference between these two connection objects is the type of Session object each one creates: a TopicSession or a QueueSession.

The UML diagram in Figure 3 illustrates the class model for the remaining classes, Destination, MessageProducer, and MessageConsumer.

Figure 3: Topic and Queue Subclasses

The Topic and Queue classes are subclasses of the Destination super class. Typically, destinations are created ahead of time through an administration interface on your JMS Provider. However, a TopicSession or QueueSession object can create Topic or Queue objects at runtime, respectively.

The TopicPublisher and QueueSender classes extend MessageProducer, and they send messages to a Topic or Queue, respectively. Similarly, the TopicSubscriber and QueueReceiver classes extend MessageConsumer, and they receive messages from a Topic or Queue, respectively.

For the sakes of improvement and simplification, you should create a JMS Facade class.The JMS Facade
The JMS Facade attempts to merge the publish/subscribe and point-to-point message models into one interface, hiding the model itself from the programmer. In my experience, application code written around the publish/subscribe model is very similar to that written around the point-to-point model. The difference lies in the details of how each delivers the messages themselves. This difference can be considered an implementation detail and, hence, should be hidden from developers in most cases. (For an overview of the JMS message models, read the sidebar, “The Java Message Service (JMS)“.)

To use the JMS Facade, start by importing the com.JMSFacade package. Next, create an instance of the com.JMSFacade.JMSManager class, as shown in Listing 4. JMSManager does all the work.

import com.JMSFacade;import javax.jms.*;public class myClass{    JMSManager jmsMgr = new JMSManager();        ...}

Subjects
The JMS Facade attempts to abstract the concepts of publish/subscribe (Topic) and point-to-point (Queue) using the term “subject.” Very simply, code written around the JMS Facade listens to, or sends messages to, a subject that is nothing more than a text name. It is not required to denote whether the destination is a topic or queue at this point?or ever.

Subject Creation
You don’t need to create subjects explicitly, even though the JMS Facade does allow it. The Facade creates subjects automatically when you call the listen or send methods. The only reason to explicitly create a subject is to control the message-delivery model, publish/subscribe or point-to-point. The default model is publish/subscribe.