JMS is a standardized means for transmitting messages between distributed applications. It defines a specific set of required features, a specific message anatomy, and a set of interactions between client applications and the message broker.
Fuse ESB Enterprise' messaging service supports the two messaging domains defined in the JMS 1.1 specification.
Point-to-Point (PTP)
PTP messaging uses queue destinations. Producers are referred to as senders, and consumers are referred to as receivers. Messages are sent and received either synchronously (producer waits until the broker acknowledges receipt of messages) or asynchronously. The queue stores all messages until they either expire or are retrieved by a receiver.
Each message dispatched to a queue is delivered only once to only one receiver. The receiver is responsible for acknowledging receipt of a message. Messages are delivered to the next available, registered consumer, so distribution flows across consumers in a quasi round-robin fashion.
See Major Widgets Phase One Solution for a point-to-point example use case.
Publish/Subscribe (Pub/Sub)
Pub/Sub messaging uses topic destinations. Producers are referred to as publishers, and consumers are referred to as subscribers. Topics typically have multiple subscribers concurrently registered to receive messages from it. Messages are sent and received either synchronously (producer waits until the broker acknowledges receipt of messages) or asynchronously.
Any message dispatched to a topic is automatically delivered to all of the topic's subscribers.
Topics do not store messages for subscribers, unless explicitly told to do so by the subscriber registering as a durable subscriber (see Durable subscribers). When a disconnected durable subscriber reconnects to a topic, the message broker delivers all unexpired messages due it.
For more information, see the Java™ Message Service Maintenance Release.
Fuse ESB Enterprise's messaging service 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.
The request/reply mechanism implements a two-way conversation in which a temporary destination is typically used for the reply message. The producer specifies the temporary destination, and the consumer identifies the request message to which the reply corresponds.
Fuse ESB Enterprise's messaging service supports persistent and nonpersistent messages.
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. However, this guarantee comes at a cost to performance because persistent messages are sent synchronously—producer blocks until broker confirms receipt and storage of message— and writes to disk, typical for a message store, are slow compared to network transmissions.
Nonpersistent messages are significantly faster than persistent messages, but they can be lost when the system or broker fails or when a consumer becomes inactive before the broker dispatches the messages to their destination.
For details, see Configuring Message Broker Persistence .
Fuse ESB Enterprise's messaging service 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 TransactionStore until it receives the commit
command, then dispatches all of them, in batch, to their destination.
Fuse ESB Enterprise's messaging service 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. This is so 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.
For details, see Introduction to Transactions in EIP Transaction Guide. See also What are XA transactions? What is a XA datasource?.
 |  |  |
 |
