[Tutorial] Lightweight Service Orchestration for Non-blocking Backend Services using WSO2 ESB
- By Nadeesha Gamage
- 9 Dec, 2013
Ability to configure WSO2 ESB to act as a lightweight service orchestrator for non-blocking backend services.
4.5.0 or above
Table of contents
1. What is Service Orchestration in SOA
2. Service Orchestration using WSO2 ESB
3. Non-blocking service orchestration using WSO2 ESB
What is Service Orchestration in SOA?
Service Orchestration is the process of accessing multiple fine-grained services from a single coarse-grained service. The service client would only have
the visibility to a single coarse-grained service and would be encapsulated from the multiple fine-grained services that are invoked in the process flow.
This can be depicted as shown in Figure 1.1.
Service orchestration can have two types of backend services.
1. Blocking backend services (synchronous)
2. Non-blocking backend services (asynchronous)
Blocking backend services would involve multiple services that are invoked as part of a sequence where one service is dependent on the response of the
previous service. This type of backend services require the Service Orchestration Layer to manage and handle the service responses and use them as an input
parameter for the next service. An example of service orchestration of blocking backend services using WSO2 ESB can be found in the following link
On the other hand, non-blocking backend services would involve multiple services that can be invoked independently from each other. This allows the
services to be invoked simultaneously without been blocked until a response is received from another service. This has been illustrated in Figure 1.2.
Service Orchestration using WSO2 ESB
WSO2 ESB is a lightweight, lean, high performance ESB that is rich with features and provides comprehensive support for many SOA standards. WSO2 ESB’s
rich mediator library can be used to facilitate service orchestration for both non-blocking and blocking backend services.
Non-blocking service orchestration using WSO2 ESB
Given below in Figure 1.3 is the non-blocking service orchestration scenario that would be developed using WSO2 ESB.
As illustrated in Figure 1.3, the service client would be invoking the Student Registration Proxy Service exposed by the WSO2 ESB. The WSO2 ESB would
in-turn handle the service calls for Student Registration Service, Course Details Service and Payment Calculation Service which are required for the
student registration process. The process complexity of the student registration process would be encapsulated from the service client and would be
internally handled by the WSO2 ESB. Service Client would only be making a service invocation to the Student Registration Proxy service which would respond
back to the service client with the aggregated response from the 3 backend services. The ESB mediation involved in this process can be illustrated by the
diagram in figure 1.4.
This scenario adopts the scatter-gather Enterprise Integration Pattern to achieve service orchestration. The service invocation by the client is cloned
into 3 message flows using the clone mediator of the WSO2 ESB. In each flow a payload is build using the payload builder to invoke each backend service.
Once the payload is build it would be sent to the relevant backend service using the send mediator.
Each backend service would respond with the service response which would be dealt by the aggregate mediator in the out-sequence of the WSO2 ESB. The
aggregate mediator would wait until all 3 responses are received from the backend services and build a new message payload that can be sent to the service
Given below is the request to the proxy service made by the service client
Nadeesha 14331234567 Male C001
Given below is the proxy service configuration for WSO2 ESB
$1 $2 $3 $1 $1 $1 $2 $3
Given below is the sample response from the proxy service
929 Dr Lee Yong, Building B, Monday 1 PM - 3 PM 1000.0
· This scenario doesn’t have any error handling. To introduce the error handling, an error handling sequence must be introduced to the proxy service in
· Endpoints are specified inside synapse.xml, but it is a best practice to store the endpoints in the Governance Registry of the ESB.
While service orchestration is important, it can only be achieved through business process management or business process execution tools. However, as discussed in this article, WSO2 ESB can address this requirement because it has the capability to orchestrate operations of multiple non-related backend services and expose them as a single service to the service consumer.
Nadeesha Gamage, Senior Engineer - Technical Sales, WSO2 Inc.