The Java Message Service (JMS)

Important 

The Java Message Service (JMS) is an API for accessing messaging systems.

The JMS specification defines an interface but does not itself define an implementation. JMS provides a standard Java-based interface to the message services of a MOM of some provider. The specification in itself is vendor neutral - it sets requirements but does not dictate how they are implemented. The JMS specification provides Java applications with a common way to create, send, receive, and read an enterprise messaging system's messages.

As shown in the figure below, JMS Service Providers implement the JMS interface on top of their messaging services. It is up to the vendor to add facilities, services, or enhancements not included or defined explicitly in the specification. JMS defines queues and topics, but it does not require the provider to implement both. JMS thus tries to maximize portability of the solution with as many features as possible:

The primary features of JMS are as follows:

• Connection factories are used in JMS to create connections to a specific JMS provider.

• In JMS, Publish/Subscribe messaging and Point-to-Point messaging domains are implemented and defined by separate interfaces so that a provider does not have to support both.

• JMS defines the concept of a topic or a queue as the target for a message. Topics are used for Publish/Subscribe messaging. Queues are used for Point-to-Point messaging.

• The providers' code is accessed through JMS interfaces, freeing the implementation from the limitations of sub classing.

• JMS provides support for distributed transactions and JMS messaging domains.

Messaging systems are classified into different models that determine which client receives a message. The messaging models supported by JMS are:

• Publish/Subscribe messaging

• Point-to-Point messaging

We describe these models in the following sections.

Publish/Subscribe Messaging

The destination in this paradigm is called a topic. This domain allows for asynchronous message delivery. When multiple applications need to receive the same messages, Publish/Subscribe messaging is used. The central concept in a Publish/Subscribe messaging system is the topic. This model, as shown in the figure below, is extremely useful when a group of applications want to notify each other of a particular occurrence. A client publishes an event to a topic, and by subscribing, multiple clients are informed of the event.

The point to note in Publish/Subscribe messaging is that, there may be multiple senders and multiple receivers:

The simple Publish/Subscribe example shown in the above figure contains a single topic and six clients (three publishers and three subscribers). All the subscribers subscribe to the topic and all the publishers publish messages to the topic. The messaging system takes care of distributing messages from the publisher to the subscriber. The characteristic pattern of interaction is as follows:

• During the subscriber's initialization, the subscriber registers an instance of a callback (a message handler invoked by the server) with the topic.

• The publishing client arrives at a point in its processing when it needs to send out a message. It creates the message and publishes it to the topic.

• The messaging system delivers the message to all its subscribers by invoking the respective callbacks that were registered earlier.

• Once all the subscribers have been notified, and the appropriate acknowledgements received, the message is removed from the topic.

Durable Subscriptions

When a subscribing client (through its session with the JMS server) requests a durable subscription, the JMS server will, in its persistent store, "save" any messages intended for the subscriber during periods when the subscriber is inactive.

Durability vs. Persistence

Durable versus non-durable relationships exist between a consuming client and the JMS server, which delivers messages. If a particular topic has durable subscribers, the messaging server retains all the messages published on the topic in a database or file for delivery to those subscribers that might be currently disconnected from the server. A message subscription for a client can be placed in a dormant state, halting the delivery of all messages to the client. The messaging server will however, store all the messages for that client until the subscription is awakened. This is really useful for disconnected and mobile users who, even though not always connected to the network, can be assured they will receive all their messages. A message is only deleted from the off-line storage when it has been delivered to all durable subscribers or after the expiration time of the message.

Delivery mode involves a message-level relationship between the producing client and the JMS server, and only indirectly between the producing and consuming clients. The delivery mode field in the message header of every message is set to either persistent message delivery or non-persistent message delivery at the time the message is sent. This is what I refer to as a message-level relationship between the producer and the destination.

A producing client can choose persistent delivery mode for either messaging model - Publish/Subscribe or Point-to-Point. "Durable delivery" is an option for clients that subscribe to topics, not for clients that connect to a queue.

Point-to-Point Messaging

The destination in this paradigm is called a queue. This domain allows for synchronous message delivery. When one process needs to send a message to another process, Point-to-Point messaging can be used. However, this may or may not be a one-way relationship. The client to a messaging system may only send messages, only receive messages, or send and receive messages. At the same time, another client can also send and/or receive messages. In the simplest case, one client is the sender of the message and the other client is the receiver of the message.

There are two basic types of Point-to-Point messaging systems. The first one involves a client that directly sends a message to another client. The second and more common implementation is based on the concept of a message queue. Such a system is shown in the figure overleaf:

Important 

The main issue in Point-to-Point messaging is that, even though there may be multiple senders of messages, there is ultimately only a single potential receiver for each message.

The simple Point-to-Point example shown in the above figure contains a single queue and four clients (three senders and a receiver). The characteristic pattern of interaction in Point-to-Point systems is as follows:

• The sender client arrives at a point in its processing when it's necessary to send out a message. It creates a message and sends it out to the queue. The message is held in the queue.

• The receiver client pauses and checks the queue for messages.

• The message is returned to the receiver client.

Publish/Subscribe vs. Point-to-Point Messaging

When designing messaging applications, design decisions on whether to choose Publish/Subscribe messaging or Point-to-Point messaging have to be based on two fundamental factors:

• The Publish/Subscribe messaging model provides two options not available with Point-to-Point messaging:

  • Clients can produce messages for an unknown, and/or unlimited, number of subscribers: Publish/Subscribe messaging supports one-to-many messaging operations

  • Subscribing clients have the choice between durable and non-durable connections to the JMS server

• The Point-to-Point messaging model is designed for one-to-one messaging between a producing client and a consuming client