Red Hat Training

A Red Hat training course is available for Red Hat Fuse

3.2. InOnly Message Exchange Pattern

Overview

The type of exchange created by a JMS consumer endpoint depends on the value of the JMSReplyTo header in the incoming message. If the JMSReplyTo header is absent from the incoming message, the consumer endpoint produces exchanges with the InOnly message exchange pattern (MEP). For example, consider the following route that receives a stream of stock quotes from the queue, queue:rawStockQuotes, reformats the incoming messages, and then forwards them to another queue, queue:formattedStockQuotes. 
from("jmstx:queue:rawStockQuotes")
    .process(myFormatter)
    .to("jmstx:queue:formattedStockQuotes");
Routes that process InOnly exchanges can easily be combined with transactions. In the preceding example, the JMS queues are accessed through the transactional JMS instance, jmstx (see Section 3.1, “Configuring the JMS Component”). The transaction initiated by the consumer endpoint, jmstx:queue:rawStockQuotes, ensures that each incoming message is reliably transmitted to the producer endpoint, jmstx:queue:formattedStockQuotes.

Enforcing the InOnly message exchange pattern

Typically, a route designed to work for InOnly exchanges does not work properly for InOut exchanges. Unfortunately, this leaves the route at the mercy of the external JMS client: if the client should accidentally set a JMSReplyTo header, the JMS consumer endpoint will create an InOut exchange, which could lead to errors in a route that is designed for InOnly exchanges.
To avoid the risk of creating InOut exchanges when they are not wanted, you can use the disableReplyTo option in the JMS consumer to enforce the InOnly MEP. For example, the following route is guaranteed to process all incoming messages as InOnly exchanges: 
from("jmstx:queue:rawStockQuotes?disableReplyTo=true")
    .process(myFormatter)
    .to("jmstx:queue:formattedStockQuotes");

InOnly scenario

Figure 3.1, “Transactional JMS Route that Processes InOnly Exchanges” shows an overview of a scenario consisting of JMS consumer endpoint feeding into a route that ends with a JMS producer endpoint. This route is designed to process exclusively InOnly exchanges.

Figure 3.1. Transactional JMS Route that Processes InOnly Exchanges

Transactional JMS Route that Processes InOnly Exchanges

Description of InOnly scenario

Messages coming into the route shown in Figure 3.1, “Transactional JMS Route that Processes InOnly Exchanges” are processed as follows:
  1. When a oneway message (JMSReplyTo header is absent) is polled by the JMS consumer endpoint, the endpoint starts a transaction, provisionally takes the message off the incoming queue, and creates an InOnly exchange object to hold the message.
  2. After propagating through the route, the InOnly exchange arrives at the JMS producer endpoint, which provisionally writes the exchange to the outgoing queue.
  3. At this point, we have arrived at the end of the transaction scope. If there were no errors (and the transaction is not marked for rollback), the transaction is automatically committed. Upon committing, both of the JMS endpoints send acknowledgement messages to the queues, turning the provisional read and the provisional write into a committed read and a committed write.