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.

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.