All docs This doc
Skip to end of metadata
Go to start of metadata

This section explains, through an example scenario, how the Pipes and Filters EIP can be implemented using the WSO2 ESB. The following topics are covered:

Introduction to Pipes and Filters

The Pipes and Filters EIP breaks down a large task into smaller subsets of independent steps that are chained together. This is useful when a sequence of processing steps are required to perform a single event in an integration scenario. The main use case of this EIP is to maintain independence and flexibility between each processing step.

For more information, go to Pipes and Filters.

Figure 1: Pipes and Filters EIP

Example scenario

The following diagram depicts an example scenario, where a stock quote request is sent from a client to a service (Stock Quote Service). The request is first received by the ESB, which transmits the request through the following filters:

  • Check Username filter: To verify the username.
  • Check User ID filter: To verify the user ID.

Once the request successfully passes through the filters (i.e., the filtering criteria is fulfilled), the ESB sends the stock quote request to the back-end service (Stock Quote Service) for processing.

Figure 2: Example scenario of the Pipes and Filters EIP

Before digging into implementation details, let's take a look at the relationship between the example scenario and the Pipes and Filters EIP by comparing their core components.

Pipes and Filters EIP (Figure 1)Example Scenario of the EIP (Figure 2)

Incoming Order

Stock Quote Request

Filters

We use Filter Mediators in the ESB, to verify the validity of the message (checking the user name and user ID). If the message meets the criteria of the first filter, we forward it to the next filter, and then to the stock quote service.
Clean OrderStock Quote Service

The ESB configuration

Given below is the ESB configuration for simulating the example scenario explained above.

<definitions xmlns="http://ws.apache.org/ns/synapse">

    <!-- Sender will invoke the following Sequence -->
    <sequence name="PipesAndFilters">
        <log level="full" xmlns="http://ws.apache.org/ns/synapse"/>
        <!-- Checks For the User Name -->
        <filter xmlns:m0="http://services.samples" source="//m0:credentials/m0:name" regex="UserName">
            <!-- If the filtered condition is satisfied -->
            <then>
                <!-- Checks for the User ID -->
                <filter xmlns:m1="http://services.samples" source="//m1:credentials/m1:id" regex="001">
                    <then>
                        <!-- The filtered message will be routed to the end point -->
                        <send>
                            <endpoint>
                                <address uri="http://localhost:9000/services/SimpleStockQuoteService"/>
                            </endpoint>
                        </send>
                    </then>
                    <else>
                        <drop/>
                    </else>
                </filter>

            </then>
            <!-- If the condition was not satisfied -->
            <else>
                <drop/>
            </else>
        </filter>
    </sequence>
    <!-- Will be triggered first -->
    <proxy name="pipes-and-filters-proxy" startOnLoad="true" transports="http https">
        <target>
            <inSequence>
                <!-- Will direct an incoming request to the specified sequence -->
                <sequence key="PipesAndFilters"/>
            </inSequence>
            <outSequence>
                <respond/>
            </outSequence>
        </target>
    </proxy>
</definitions>

The configuration elements

The elements used in the above ESB configuration are explained below.

  • <proxy> - This is the proxy service that should be invoked to execute the configuration.
  • <inSequence> - A message is first received by the proxy service, and then directed to this sequence.
  • <outSequence> - This sequence is triggered after the execution of the <inSequence>.
  • <sequence> - This is an external sequence, which is invoked by the proxy.
  • <filter mediator> - This mediator filters an incoming message based on the constraints specified in the regex.
  • <then> - Actions to take if the conditions are satisfied through the filtering criteria.
  • <else> - Actions to take if the conditions are not satisfied.

Simulating the example scenario

Now, let's try out the example scenario explained above.

Setting up the environment

You need to set up the ESB, and the back-end service:

  1. Download the Pipes-and-Filters.zip file, which includes the ESB configuration described above. 
  2. See Setting up the Environment for instructions on setting up the ESB and the back-end service.

    When you set up the environment, note that you only need to start one instance of the back-end service (Stock Quote Service) to simulate this example.

Executing the sample

Send the following request to the ESB, by using a SOAP client. When you send the request, you will need the wsdl URL of the proxy service defined in the ESB configuration. The default wsdl URL for this proxy service is http://localhost:8280/services/pipes-and-filters-proxy?wsdl.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ser="http://services.samples" 
xmlns:xsd="http://services.samples/xsd">
   <soapenv:Header>
	<ser:credentials>
          <ser:name>UserName</ser:name>
          <ser:id>001</ser:id>
      </ser:credentials>
   </soapenv:Header>	
   <soapenv:Body>
      <ser:getQuote>
         <ser:request>
            <xsd:symbol>msft</xsd:symbol>
         </ser:request>
      </ser:getQuote>
   </soapenv:Body>
</soapenv:Envelope>

Analyzing the result

When you send the request, the ESB first receives the message and then routes it to the back-end service (StockQuoteService). The following output will be printed on the Axis2 server's console, confirming that the request is successfully received by the back-end service.

samples.services.SimpleStockQuoteService :: Generating quote for : msft

You can view the response in the SOAP UI as follows. If you send another request by changing the name or ID, you can see how the request fails.

  • No labels