Messaging Models

JMS domains provide for the classification of messaging paradigms, including point-to-point and publish/subscribe. Point-to-point messaging generally relies upon queues to transport messages. Publish/subscribe, as we discussed in Chapter 7, addresses messages to some node in a content hierarchy. Pub/sub is particularly useful to application integration projects because it does not require an understanding about the resource that is being subscribed to. JMS provides client interfaces created for each type of domain.

With these two paradigms available, the question that confronts the architect and developer is, which one to use and when? The answer may be found in a closer examination of the two options. JMS point-to-point messaging defines how a client works with queues. For example, it defines how a JMS-enabled application finds queues, sends a message to them, and/or receives messages from them. JMS can send a message to a specific queue. Asynchronously, the receiving applet or application need not be engaged in order for the message to be placed in the queue; it picks up the message from the queue when it has time.

Point-to-point messaging is best applied when applications need to communicate with one another but, in doing so, do not need to delay the target or source application from processing tasks.

As with traditional queues, JMS queues may contain a mixture of messages. Unfortunately, JMS suffers from the shortcoming of not defining facilities to administer queues. The upside is that this shortcoming is not as significant as it might first appear because JMS implementations leverage static, not dynamic, queues.

Developers should keep several Java concepts in mind when working with JMS queues. Among them are the Queue object, TemporaryQueue, QueueConnectionFactory, QueueConnection, QueueReceiver, Queue Sender, and QueueSession. Together, these represent a set of classes that developers can leverage within a JMS-enabled application.

The Queue object, the heart of this beast, encapsulates a provider-specific queue name. This object identifies a queue to a JMS method from the client. A QueueConnection is an active connection to a JMS point-to-point provider. The JMS client leverages the QueueConnection to create instances of QueueSessions, which produce and consume messages.

The TemporaryQueue is created for the duration of the Queue Connection. True to its name, it is a system-defined queue, available only to the QueueConnection object that created it as a temporary storage location. The QueueConnectionFactory creates an instance of a QueueConnection object within a JMS provider. The client uses a QueueReceiver to receive messages that exist in a queue, while in contrast, a QueueSender places messages in a queue.

If the point-to-point model doesn't meet the needs of the project, the JMS pub/sub model probably will. This model uses a content-based hierarchy structure to describe how JMS clients publish messages and subscribe to them from a well-defined node. This model, as we noted in our earlier discussion of middleware models, is superior to simple point-to-point models. It is most practical when considering JMS for use with traditional application integration projects (although either model can be used with application integration implementations).

JMS refers to these nodes as "topics." A topic is, in fact, a small message broker that gathers and distributes messages from other entities (see Figure 8.3). JMS uses topics as quasi-intermediaries. They create messages that are separated logically from subscribers. Topics are adaptive; they adjust as subscribers and publishers appear and disappear.

Figure 8.3. JMS can gather and distribute messages throughout an enterprise.

By drilling down to the next "topic level," we can discern that a topic is nothing more than a Java object that encapsulates a provider-specific topic name. Unlike most pub/sub vendors that group topics into hierarchies, allowing subscribers to subscribe to any part of the hierarchy, JMS places no such restrictions on its users. Instead, it organizes topics and the granularity of subscriptions in a completely open manner. This "openness" is a positive development. Strict pub/sub policies are, by definition, limiting.

JMS and Application Development

Because JMS is just another Java-enabled API, application development comes down to simply linking to and leveraging the proper JMS objects within an application. A JMS application can be created and deployed as a single unit, or JMS clients can be added to an existing JMS-enabled application or applet. Generally, JMS plays an important role in the creation of distributed Java applications and linking non-JMS messages into the world of Java. For example, IBM is in the process of ensuring that its MQSeries is able to exchange messages with JMS. And where Big Blue leads, other MOM vendors are sure to follow.

A typical JMS client application must go through a standard procedure to get up and running. This procedure includes using the Java Naming and Directory Information (JNDI) to find a ConnectionFactory object, and then find one or more destination objects. To create a number of instances of a JMS session, the ConnectionFactory object is used to create an instance of a JMS connection and the Connections method. Finally, the JMS client must use the Session and the Destinations to create the MessageProducers and MessageConsumers required for the application. From this point, the connection to the queue or the pub/sub engine is set, and the application may use JMS as a mechanism to transport data into and out of an application.

A number of key issues remain that JMS must address. These include load balancing, fault tolerance, and error notification. We can probably anticipate that JMS-compliant software vendors will build such features into their products. Wouldn't it be nice if they all chose to use a consistent paradigm and mechanism? Sure it would. But don't count on it. As we mentioned earlier in this chapter, no notion of administration is built into the JMS specifications. IBM discovered that a weak administration initially hurt MQSeries, so it responded by fixing the problem. At this point, Java seems to have no such inclination to fix JMS. In addition, security seems to be an afterthought in JMS. Unfortunately, this is hardly unusual in the world of middleware.

Beyond JMS, Java integration with the big MOM products is having a significant impact. With over 65 percent of the point-to-point message-oriented middleware marketplace, MQSeries is MOM's "800-pound gorilla" that will always get its way. Providing Java links will only add value to that domination. IBM is "Java-tizing" just about everything these days. Java is going to be the least common denominator between CICS, Component Broker, and MQSeries representing the largest enterprise growth area for Java. Although JMS will support smaller systems at first, it is only a matter of time before it supports larger systems, as well.