Chapter 2. Introduction to JMS

Red Hat AMQ adheres to the JMS 1.1 specification in implementing all of the standard JMS features including:

Point-to-point (PTP) messaging uses queue destinations. Queues handle messages in a first in, first out (FIFO) manner. Messages are consumed from the queue in the order in which they are received. Once a message is consumed from a queue it is removed from the queue.

PTP messaging is similar to person-to-person email sent and received through a mail server. Each message dispatched to a queue is delivered only once to only one receiver. The queue stores all messages until they either expire or are retrieved by a receiver.

Clients that produce messages are referred to as senders. Messages are sent either synchronously or asynchronously. When sending messages synchronously, the producer waits until the broker, not a receiver, acknowledges receipt of the messages.

Clients that consume messages are referred to as receivers. Receivers consume messages from the end of the queue. Multiple receivers can register concurrently on the same queue, but only one of them will receive any given message. It is the receiver's responsibility to acknowledge the receipt of a message. By default, AMQ guarantees once-only delivery of any message to the next available, registered consumer, thus distributing messages in a quasi round-robin fashion across them.

Publish and subscribe (Pub/Sub) messaging uses topic destinations. Topics distribute published messages to any clients that are currently subscribed and waiting to consume them. Once all of the clients that are subscribed to the topic have consumed a message it is removed from the destination.

Pub/sub messaging is similar to a mailing list subscription, where all clients currently subscribed to the list receive every message sent to it. Any message dispatched to a topic is automatically delivered to all of the topic's subscribers.

Clients that produce messages are referred to as publishers. Messages are sent either synchronously or asynchronously. When sending messages synchronously, the producer waits until the broker, not a consumer, acknowledges receipt of the messages.

Clients that consume messages are referred to as subscribers. Topics typically have multiple subscribers concurrently registered to receive messages from it. Typically, subscribers must be actively connected to a topic to receive published messages. They will miss messages that are published while they are disconnected.

To ensure that they do not miss messages due to connectivity issues, a subscriber can register as a durable subscriber. The topic will store messages for a durable subscriber and deliver the messages when the durable subscriber reconnects.

AMQ supports the request/reply messaging paradigm, which provides a mechanism for a consumer to inform the producer whether it has successfully retrieved and processed a message dispatched to a queue or a topic destination.

AMQ's request/reply mechanism implements a two-way conversation in which a temporary destination is used for the reply message. The producer specifies the temporary destination in the request message's JMSReplyTo header, and the consumer identifies the request message to which the reply corresponds using the reply message's JMSCorrelationID property.

Persistent messaging ensures no message is lost due to a system failure, a broker failure, or an inactive consumer. This is so because the broker always stores persistent messages in its stable message store before dispatching them to their intended destination. This guarantee comes at a cost to performance. Persistent messages are sent synchronously—producers block until the broker confirms receipt and storage of each message. Writes to disk, typical for a message store, are slow compared to network transmissions.

Because non-persistent messages are sent asynchronously and are not written to disk by the broker, they are significantly faster than persistent messages. But non-persistent messages can be lost when the system or broker fails or when a consumer becomes inactive before the broker dispatches the messages to their destination.

The default behavior of JMS brokers and consumers is to use persistent messaging. JBoss A-MQ defaults to storing persistent messages in a lightweight, file-based message store. The default is intended to provide persistence at the lowest cost. If you need to use a more robust (RDBMS) message store or want to forgo persistence in favor of performance, you can change the defaults.

There are several ways to alter the default persistence behavior when using AMQ:

For details, see the guide, Configuring Broker Persistence, on the Red Hat Customer Portal.

AMQ supports JMS transactions that occur between a client and broker.

A transaction consists of a number of messages grouped into a single unit. If any one of the messages in the transaction fails, the producer can rollback the entire transaction, so that the broker flushes all of the transacted messages. If all messages in the transaction succeed, the producer can commit the entire transaction, so that the broker dispatches all of the transacted messages.

Transactions improve the efficiency of the broker because they enable it to process messages in batch. A batch consists of all messages a producer sends to the broker before calling commit(). The broker caches all of these messages in a transaction store until it receives the commit command, then dispatches all of them, in batch, to their destination.

For details, see ActiveMQ in Action (Snyder, Bosanac, and Davies).

AMQ supports XA transactions that occur between a client and broker.

XA transactions work similarly to JMS transactions, except XA transactions use a two-phase commit scheme and require an XA Transaction Manager and persistent messaging. The Transaction Manager and two-phase commit scheme are used because the broker is required to write every message in an XA transaction to a persistent message store, rather than caching them locally, until the producer calls commit().

XA transactions are recommended when you are using more than one resource, such as reading a message and writing to a database. This is so because XA transactions provide atomic transactions for multiple transactional resources, which prevents duplicate messages resulting from system failures.

For more information, see ActiveMQ in Action (Snyder, Bosanac, and Davies) and What are XA transactions? What is a XA datasource?.