A Java Message Service Primer

Developers have long faced the daunting task of moving data between heterogeneous systems. One impediment to exchanging information has been the difficulty of getting humans to agree on precisly how to exchange and format that data. Java Message Service solves part of this problem by providing a means of interacting with existing J2EE applications or legacy systems in a neutral manner.

JMS makes available common sets of interfaces for sending and receiving messages reliably and asynchronously. Asynchronous messaging is an obvious choice for use with disconnected clients such as cell phones and PDAs. In addition JMS is a means of integrating enterprise systems in a loosely coupled (if not completely de-coupled) manner with the primary objective of creating applications that are seemingly portable across messaging vendors, while freeing development staff from the inherent complexities integrating these enterprise systems.

Java Message Service supports two messaging models: Point-to-Point messaging (P2P) and Publish Subscribe messaging (Pub/Sub). Although the JMS specification doesn't require a vendor to support both messaging models, there are several that do. A developer should be familiar with the advantages and disadvantages of both messaging models in order to make informed design decisions.

P2P messaging is designed for use in a one-to-one delivery of messages. An application developer should use P2P messaging when every message must be successfully processed. Unlike the Pub/Sub messaging model, P2P messages are always delivered.

Some of the characteristics of the P2P messaging model are as follows.

• Uses message queues, senders, and receivers.
• Messages are sent to specific queues; clients will extract messages from specific queues established to hold their messages.
• Queues retain all messages sent until such time as the messages are consumed or expire.
• Each message has only one consumer, though multiple receivers may connect to the queue.
• Messages are removed from the start of the queue (FIFO).

There is no time dependency -- a receiver may acquire a message whether of not the service was available at the time the message was sent.

• Receivers acknowledge the successful receipt of a message.

The Pub/Sub model is designed for one-to-many broadcasts of messages. An application developer may wish to use Pub/Sub messaging when it is acceptable for some level of unreliability to exist. In other words, it is feasible that all consumers will receive not all messages or no consumer will receive any message.

Some of the characteristics of the Pub/Sub messaging model are as follows.

• Uses message topics, subscribers, and publishers. Messages are addressed to specific topics.
• Publishers and subscribers are usually anonymous.
• The system takes care of distributing the messages arriving from a topic's publishers to its subscribers.
• Producers send messages via topics and consumers receive those messages by subscribing to a topic.
• Messages are retained only as long as it takes to distribute them to the registered subscribers.
• Each message may have multiple subscribers. There are time dependencies that exist between publishers and subscribers; subscribers to a topic may only consume messages published after a subscription was created.
• Subscribers must maintain their subscription to a topic to continue receiving messages.