2014/03/03
3 Mar, 2014

Service Orchestration with WSO2 ESB

  • Isuru Udana
  • Director - Engineering - WSO2

WSO2 ESB is a fast, lightweight, and user-friendly open source ESB with a rich set of features that allows developers to easily implement their service orchestration scenarios.

Archived Content
This article is provided for historical perspective only, and may not reflect current conditions. Please refer to relevant product page for more up-to-date product information and resources.

Applies to

WSO2 ESB 4.8.x

Table of contents

Introduction

In SOA, a service is a self-contained unit that provides a specific functionality. In order to implement real-world business use cases, is it often required to integrate a set of services. Service orchestration is the process of integrating several services based on some business logic and exposing them as an aggregated single service. This orchestration of services and exposing them as a composite service can be done with the help of an ESB. The ESB is responsible for transforming and enriching messages as required by the services and communicating with different services according to a business logic.

To illustrate the service orchestration capabilities of WSO2 ESB, let’s now implement a sample service orchestration scenario.

Check out how eBay used the WSO2 ESB for its operations in our case study on

Scenario - Vehicle license renewal service

This scenario is about an online vehicle license renewal system. Vehicle owners have to renew their vehicle license annually. To renew the license, the vehicle should have a valid insurance policy, a valid emission test certificate, and a credit card to make the payment.

The system is built by orchestrating several services. Even though the license service requires a need to have all the above-mentioned parameters, the user sends a request that contains only the vehicle registration number and a credit card number as the input data. The rest of the required data is fetched and validated by talking to several other services. The services orchestrated in this scenario are as follows.

Services

InsuranceService

Insurance service takes the vehicle registration number as the input data and gives the insurance policy ID as the response.

Request format


    
        
            SPKP-6531
        
    

Response format

    
        
            
                869864462
            
        
    

EmissionTestService

This service takes the vehicle registration number as the input data and gives the emission test certificate as the output.

Request format


    
        
            SPKP-6531
        
    

Response format


    
        
            1250719063
        
    

LicenseService

This is the service that does the main task of this system. It takes the vehicle registration number, insurance policy ID, and the emission test certificate ID as the input data and gives out the fee to be paid and a reference number for the request. Since the insurance policy ID and the emission test certificate ID have to be fetched prior to calling the service, this service depends on the output of the insurance service and the emission test service.

Request format


    
        
            SPKP-6531
            869864462
            1250719063
        
    

Response format


    
        
            
                30
                f0a6c76d-87dc-4d8e-8168-b99a46a9ee50
                Sun Feb 09 23:38:58 IST 2014
            
        
    

PaymentService

This service is responsible for making the payment. It takes the credit card number, amount, and the reference number that is issued by the license service.

Request format


    
        
            xxxx-xxxx-xxxx-xxxx
            f0a6c76d-87dc-4d8e-8168-b99a46a9ee50
            30
        
    

Response format


    
        
            Transaction Completed
        
    

Fundamental concepts

Now we have an understanding of the scenario that we are going to implement here. Before moving on to the actual implementation using WSO2 ESB, let’s get a basic understanding of some of the fundamental components that are required for this implementation.

Mediator

Mediator is the basic unit that does the message mediation in WSO2 ESB. All the message flows of ESB are constructed with a set of mediators. A mediator has an input message, an output message, and a configuration. Based on the configuration, a mediator can alter, transform, or manipulate the incoming message into the output message.

Sequence

A sequence consists of sequential arrangement of a series of mediators. A message that is dispatched to a sequence is flown through each and every mediator in a sequential manner and the message gets altered by each and every mediator present in the sequence.

Endpoint

Endpoint is a logical representation of an actual back-end service or a group of back-end services. We need to define an endpoint for each and every backend service invoked by the ESB.

Proxy service

A proxy service is a virtual service hosted in the ESB. In the scenario described above we need to expose a single service as the license renewal service to the client orchestrating all the required services. This new service that is hosted in the ESB is called a proxy service.

It is important that we get a very good understanding of the message flow of a proxy service before we start implementing any integration scenarios using WSO2 ESB.

A proxy service has three sequences. They are InSequence, outSequence and FaultSequence. When a client sends a message to a proxy service, the message will be dispatched to the inSequence. At the inSequence, we can alter the received request (do transformations etc.) and send to the back-end service using the send mediator.

When a response is received from the backend, it will be dispatched to the outSequence by default. Similar to inSequence, we can do all manipulations required for the response message at the outSequence and send the response back to the client.

If there is an error within any of the flows, the message will be dispatched to the faultSequence. We can write the fault handling logic at the faultSequence.

This is the default message flow of a proxy service. From ESB 4.0.0 onwards a new concept called “receivingSequence” is introduced to make implementation of service chaining simpler. When we set a receiving sequence at the send mediator, the response for the outgoing request will arrive to that sequence instead of arriving it to the outSequence.

Call mediator

In ESB 4.8.0, a new mediator called “Call” mediator was introduced to simplify the synapse configuration required to implement service orchestration scenarios. According to the above description of the proxy service message flow, when the request is sent through the send mediator the response will arrive to the outSequence or to the receivingSequence. Calling the next service has to be done from the receiving sequence.

But when we send a request using the call mediator, the response will arrive to the mediator that is placed right after the call mediator. So this will allow us to specify all the service invocations one after the other in a chain within a single sequence. This makes the synapse configurations much simpler to define for service chaining scenarios. The following diagram illustrates the message flow of a proxy service when call mediator is in use.

Implementing vehicle license renewal scenario using WSO2 ESB

Now that we have all the background information required, we can start the implementation of this scenario.

Deploying sample services on application server

We have prepared sample axis2 services to represent services in this scenario. All four services are packed in a Carbon Application Archive (Capp) which can be deployed in the WSO2 Application Server.

  • Download and unzip WSO2 Application Server
  • Change the port offset of WSO2 AS to 1 by editing carbon.xml located at /repository/conf/ directory
  • Start WSO2 Application Server with sh ./bin/wso2server.sh
  • Login to the WSO2 Application Server management console and deploy AppServerServices_1.0.0.car (Manage > Carbon Applications > Add)
  • Following services should get deployed and appear in the Services list
      -EmissionTestService
    1. -InsuranceService
      -LicenseService
      -PaymentService
  • You may use 'TryIt' feature to invoke and verify whether services works properly (optional step).

ESB configuration

Now let’s start implementing the configurations required for ESB. To implement ESB configurations, lets use WSO2 Developer Studio. We are going to use the Developer Studio version 3.5.0 as it is the compatible version for ESB 4.8.0.

Start Developer Studio and create a ESB Config project. (New > Project > WSO2 > Message Mediation > ESB Config Project)

Creating endpoints

Now lets create the required endpoints to represent back-end services.

Right click on the created ESB Config project and select New > Endpoint.

Create four endpoints of the type Address for 4 services as follows.

EmissionTestServiceEp

Address uri : https://localhost:9764/services/EmissionTestService

Synapse configuration :


    
 

InsuranceServiceEp

Address uri : https://localhost:9764/services/InsuranceService

Synapse configuration :


    

LicenseServiceEp

Address uri : https://localhost:9764/services/LicenseService

Synapse configuration :


    
 

PaymentServiceEp

Address uri : https://localhost:9764/services/PaymentService

Synapse configuration :


    
 

We need to specify a WSDL for the proxy service which we are going to create in the next step. So first we have to store that wsdl in the ESB. To do that, lets create a Local Entry with the content available in the attached file LicenseServiceProxyWSDL.wsdl.

Right click on the created ESB Config project and select New > Local Entry.

In the appeared wizard select “Create a new Local Entry” and then in the next page select “In-Line XML Entry” as the Local Entry Creation Type. Use the content available at the attached file LicenseServiceProxyWSDL.wsdl as the value.

Implementation of LicesneServiceProxy

Out of four back-end services, InsuranceService and the EmissionTestService are independant from each other. But LicenseService depends on the outcome of both Insurance Service and EmissionTestService. PaymentService is also depending on the outcome of the LicenseService. So invocation of the InsuranceService and the EmissionTestService can be done parallelly and other invocations have to be done sequentially. This means invocation of the LicenseService has to be done after receiving responses for both EmissionTestService and InsuranceService. Moreover, invocation of the PaymentService has to be done after receiving the response of the LicenseService. By taking these dependencies into consideration we can draw order of service invocations as follows.

 

Right click on the created ESB Config project and select New > Proxy Service.

In the appeared wizard select “Create a new Proxy Service” and then in the next page select “Custom Proxy” as the Proxy Service Type.

After creating the proxy service, point the publish wsdl of the proxy to the above created local entry at the properties view. According to the LicenseServiceProxyWSDL, following is the request accepted by the proxy service.


    
        
            ?
            ?
        
    

Now we can drag and drop mediators from the mediator palette to the Editor and design the proxy configuration. First we are going to save the vehicleId and creditCard values as properties for future reference.



As described above, InsuranceService and the EmissionTestService are independent of each other so that they can be invoked parallelly. So we can create two parallel flows using the clone mediator.


    
    

Within one clone target we need to define the message payload and the Action header required by the backend service and finally using the Call mediator we can invoke the service. Following is the clone target for the InsuranceService.


    
        
            
                
                    $1
                
            
            
                
            
        
        
After these two service invocations, we need to combine their responses. This is done using the aggregate mediator. Following is the configuration up to this level.

 


    
        
            
            
            
                
                    
                        
                            
                                
                                    $1
                                
                            
                            
                                
                            
                        
                        
$1

Now we have completed the first two service invocations. Now lets add the other two service invocations.

As mentioned above, LicenseService depends on the result of the InsuranceService and the EmissionTestService. So we can continue with integration of LicenseService after the completion of the Aggregate mediator. Similar to the above, we can use the PayloadFactory mediator and the header mediator to create the required request for the LicenseService and invoke it using the Call mediator.

 


    
        
    
    
        
            
                
                    
                    
                        
                            $1
                            $2
                            $3
                        
                    
                
            
            
                
                
                
            
        
        

Invocation of PaymentService also can be done similarly. Required configuration elements has to be placed after the aggregate mediator.

 


    
        
            $1
            $2
            $3
        
    
    
        
        
        
    

Finally we can send the response back to the client using the respond mediator.

Following is the complete proxy service configuration for this scenario.

 


    
        
            
            
            
                
                    
                        
                            
                                
                                    $1
                                
                            
                            
                                
                            
                        
                        
$1
$1 $2 $3
$1 $2 $3

Running the scenario

Now that we have completed the ESB configuration implementation, we can continue with deploying the ESB artifacts to the server and test it.

  • Create a Composite Application Project that has a dependency to the above created ESB Config project
  • Create the composite archive and deploy it to ESB. (an archive is attached)
  • You should be able to see the LisenceServiceProxy in the services list
  • Invoke the LisenceServiceProxy using a client. The request can be generated from the LisenceServiceProxy wsdl

Summary

Service orchestration is a crucial aspect in SOA. WSO2 ESB provides a rich set of features to implement service orchestration use cases. Configuration required to implement service orchestration scenarios has been further simplified with the introduction of ‘Call Mediator’ in the most recent WSO2 ESB release.

References

  1. WSO2 ESB 4.8.0
  2. Call Mediator
  3. WSO2 Developer Studio
  4. EIP Patterns with WSO2 ESB
Attachment Size
AppServerServices.zip 5.83 KB
ESBArtifacts.zip 5.01 KB
LicenseServiceProxyWSDL.xml 5.57 KB

 

About Author

  • Isuru Udana
  • Director - Engineering
  • WSO2