Page History

Walk through another example

Introduction

We continue Continuing the walk from Walk through an example. This time our first example, we take a closer look at the routing and explains explain a few pointers - so you wont won't walk into a bear trap, but can enjoy a walk an after-hours walk to the local pub for a large beer

First we take a moment to look at the Enterprise Integration Patterns that is - the base pattern catalog for integrationsintegration scenarios. In particular we focus on the Pipes and filters EIP pattern, that is - a central pattern. This is used for: to route messages through a sequence of processing steps, each performing a specific function - much like the Java Servlet Filters.

...

In this sample we want to process a message in a sequence of steps where each steps can perform their specific function. In our example we have a JMS queue for receiving new orders. When an order is received we need to process it in several steps:

validate
register
send confirm email

This can be created in a route like this:

...

Tip

title	Pipeline is default

In the route above we specify pipeline but it can be omitted as its default, so you can write the route as:

Code Block

	xml
	xml

<route>
   <from uri="jms:queue:order"/>
   <bean ref="validateOrder"/>
   <bean ref="registerOrder"/>
   <bean ref="sendConfirmEmail"/>
</route>

This is commonly used not to state the pipeline.

An example where the pipeline needs to be used, is when using a multicast and "one" of the endpoints to send to (as a logical group) is a pipeline of other endpoints. For example.

Code Block

	xml
	xml


<route>
   <from uri="jms:queue:order"/>
   <multicast>
     <to uri="log:org.company.log.Category"/>
     <pipeline>
       <bean ref="validateOrder"/>
       <bean ref="registerOrder"/>
       <bean ref="sendConfirmEmail"/>
     </pipeline>
   </multicast>
</route>

The above sends the order (from jms:queue:order) to two locations at the same time, our log component, and to the "pipeline" of beans which goes one to the other. If you consider the opposite, sans the <pipeline>

Code Block

	xml
	xml


<route>
   <from uri="jms:queue:order"/>
   <multicast>
     <to uri="log:org.company.log.Category"/>
     <bean ref="validateOrder"/>
     <bean ref="registerOrder"/>
     <bean ref="sendConfirmEmail"/>
   </multicast>
</route>

you would see that multicast would not "flow" the message from one bean to the next, but rather send the order to all 4 endpoints (1x log, 3x bean) in parallel, which is not (for this example) what we want. We need the message to flow to the validateOrder, then to the registerOrder, then the sendConfirmEmail so adding the pipeline, provides this facility.

Where as the bean ref is a reference for a spring bean id, so we define our beans using regular Spring XML as:

...

This example is also based on the in-only message exchange pattern. What you must understand as well is the in-out message exchange pattern, where the caller expects a response. We will look into this in another example.

Child pages

Versions Compared

Old Version 3

New Version Current

Key

Walk through another example

Introduction

See also