In Fuse Mediation Router, pipelining is the dominant paradigm for connecting nodes in a route definition. The basic idea of a pipeline is that the output of one command is fed into the input of the next. The natural analogy in the case of a route is for the Out message from one processor to be copied to the In message of the next processor.

Every node in a route, except for the initial endpoint, is a processor. Processors make up the basic building blocks of a route. For example, DSL commands such as filter, delayer, setBody, setHeader, and to all represent processors.

Processors use one of the following processing approaches:

The first approach is where the processor simply modifies the exchange's In message, as shown in Figure 2.1. The exchange's Out message remains null in this case.

Figure 2.1. Processor Modifying an In Message

The route in Example 2.1 shows a setHeader command that modifies the current In message by adding (or modifying) the BillingSystem heading.

<from uri="activemq:orderQueue" />
<setHeader headerName="BillingSystem" id="setHeader1">
  <language language="xpath">/order/billingSystem</language>
</setHeader>
<to uri="activemq:billingQueue" />

The second approach is where the processor creates an Out message to represent the result of the processing, as shown in Figure 2.2.

Figure 2.2. Processor Creating an Out Message

The route in Example 2.2 shows a transform command that creates an Out message with a message body containing the string, DummyBody.

<from uri="activemq:orderQueue" />
<transform id="transform1">
  <language language="constant">DummyBody</language>
</transform>
<to uri="activemq:billingQueue" />

Figure 2.3 shows an example of a processor pipeline for InOnly exchanges. Processor A acts by modifying the In message, while processors B and C create an Out message. The route builder links the processors together as shown.

In particular, processors B and C are linked together in the form of a pipeline. Processor B's Out message is moved to the In message before feeding the exchange into processor C, and processor C's Out message is moved to the In message before feeding the exchange into the producer endpoint. Thus the processors' outputs and inputs are joined into a continuous pipeline, as shown in Figure 2.3.

Figure 2.3. Sample Pipeline for InOnly Exchanges

Fuse Mediation Router employs the pipeline pattern by default, so you do not need to use any special syntax to create a pipeline in your routes. For example, Example 2.3 pulls messages from a userdataQueue queue, pipes the message through a Velocity template (to produce a customer address in text format), and then sends the resulting text address to the queue, envelopeAddressQueue.

<from uri="activemq:userdataQueue" />
<setExchangePattern pattern="InOut">
  <to uri="velocity:file:AdressTemplate.vm" />
</setExchangePattern>
<to uri="activemq:envelopeAddresses" />

Where the Velocity endpoint, velocity:file:AdressTemplate.vm, specifies the location of a Velocity template file, file:AdressTemplate.vm, in the file system. The setExchangePattern command changes the exchange pattern to InOut before sending the exchange to the Velocity endpoint and then changes it back to InOnly afterwards. For more details of the Velocity endpoint, see Velocity in Component Reference.

Figure 2.4 shows an example of a processor pipeline for InOut exchanges, which you typically use to support remote procedure call (RPC) semantics. Processors A, B, and C are linked together in the form of a pipeline, with the output of each processor being fed into the input of the next. The final Out message produced by the producer endpoint is sent all the way back to the consumer endpoint, where it provides the reply to the original request.

Figure 2.4. Sample Pipeline for InOut Exchanges

	Note
	In order to support the InOut exchange pattern, it is essential that the last node in the route creates an Out message. Otherwise, any client that connects to the consumer endpoint would hang and wait indefinitely for a reply message.

Example 2.4 shows a route that processes payment requests that are received via HTTP.

<from uri"jetty:http://localhost:8080/foo" />
<to uri="cxf:bean:addAccountDetails" />
<to uri="cxf:bean:getCreditRating" />
<to uri="cxf:bean:processTransaction" />

When the pipeline consists of just a sequence of endpoints, it is also possible to use the alternative syntax shown in Example 2.5.

<from uri="jetty:http://localhost:8080/foo" />
<pipeline>
  <to uri="cxf:bean:addAccountDetails" />
  <to uri="cxf:bean:getCreditRating" />
  <to uri="cxf:bean:processTransaction" />
</pipeline>

The pipeline for InOptionalOut exchanges is essentially the same as the pipeline in Figure 2.4. The difference between InOut and InOptionalOut is that an exchange with the InOptionalOut exchange pattern is allowed to have a null Out message as a reply. That is, in the case of an InOptionalOut exchange, a null Out message is copied to the In message of the next node in the pipeline. By contrast, in the case of an InOut exchange, a null Out message is discarded and the original In message from the current node would be copied to the In message of the next node instead.