This section explains, through an example scenario, how the Routing Slip EIP can be implemented using WSO2 ESB. The following topics are covered:
Introduction to Routing Slip
The Routing Slip EIP routes a message consecutively through a series of processing steps when the sequence of steps is not known at design-time, and may vary for each message. For more information, refer to http://www.eaipatterns.com/RoutingTable.html.
Figure 1: Routing Slip EIP
The sequence in which a message should process usually varies based on the request that arrives. This EIP observes the message at the initial state and attaches a specific list of steps that the message should follow.
In the example scenario, when the ESB receives a message, it will attach a property to the message using the Header mediator to indicate the set of processors that it should follow. It defines each process as a separate sequence. This example consists of three independent sequences. The attached properties are processed using the Iterate mediator, and the process is analyzed using the Switch mediator in each iteration cycle. Once the process is analyzed, the message will be sent to the respective process (sequence).
The diagram below depicts how to simulate the example scenario using WSO2 ESB.
Figure 2: Routing Slip Example Scenario
Before digging into implementation details, let's take a look at the relationship between the example scenario and the Routing Slip EIP by comparing their core components.
|Routing Slip EIP (Figure 1)||Routing Slip Example Scenario (Figure 2)|
|Request Message||Simple Stock Quote Request|
Header Mediator appends node to SOAP header
- Download and install WSO2 ESB from http://wso2.com/products/enterprise-service-bus. For a list of prerequisites and step-by-step installation instructions, refer to Installation Guide in the WSO2 ESB documentation.
- Start the sample Axis2 server instances. For instructions, refer to the section Setting Up the ESB Samples - Starting the Axis2 server in the WSO2 ESB documentation.
Simulating the sample scenario
- Send a request like the following to the client.
ant stockquote -Dtrpurl=http://localhost:8280/services/RoutingSlipProxy -Dsymbol=foo
- Note that the steps are attached to the message header initially. Thereafter, processing will be decided based on the attached slip. You can observe process A and process C being logged in the ESB management console.
Axis2 Sever output:
samples.services.SimpleStockQuoteService :: Generating quote for : fooClient output:
Standard :: Stock price = $155.1065862596588
ESB Console output:
[EI-Core] INFO - LogMediator Process = A
[EI-Core] INFO - LogMediator Process = C
You can also allow the message to flow through Process B by indicating a header in the following manner.
If you add the above header at the beginning, you will notice the message going through Process B as well.
How the implementation works
Let's investigate the elements of the ESB configuration in detail. The line numbers below are mapped with the ESB configuration shown above.
- header [line 7 in ESB config] - The Header mediator appends a key/value pair to the SOAP header. It can be used to remove such pairs. In this example, the configuration adds a header field called
RoutingSlipwith a value of Process A. It then adds another header field
RoutingSlipwith a value of Process C.
- iterate [line 15 in ESB config] - The Iterate mediator is used to iterate over all
RoutingSlipnodes inside the header.
- switch [line 20 in ESB config] - The Switch mediator is used to filter out and match the value in
RoutingSlipto run the relevant sequence.