Service Integration is a common integration problem that many organizations need to solve. This article, gives you a comprehensive understanding on how we can integrate a set of services with the use of the WSO2 ESB. An overview of fundamental concepts relating to WSO2 ESB is briefly explained, while a typical service integration scenario in healthcare is implemented from scratch. Date: Tue, 6th Nov, 2012 Level: Advanced Reads: 5123 Discuss this article on Stack Overflow

Kasun Indrasiri Associate Technical Lead, Member, Management Committee - Integration Technologies WSO2 Inc.

Applies To

WSO2 ESB

4.5.x

Table of Content

• Introduction
• Why Service Integration?
• A Service Integration Scenario - Healthcare Scenario
• Fundamentals of WSO2 ESB
• Implementing the Healthcare Scenario with WSO2 ESB
• Testing the Healthcare Scenario
• Conclusion

Introduction

In a given SOA implementation, Service Integration plays a critical role. As SOA is all about services and their consumers, the infrastructure of implementing SOA; the Enterprise Service Bus (ESB), has the responsibility of interaction between all the services and consumers. Therefore, Service Integration is also a major requirement of any ESB implementation.

This article provides a closer look at the concepts of 'Service Integration' and a complete overview on service integration with the WSO2 ESB by using a real world healthcare scenario that involves service chaining.

Why Service Integration?

Today's modern enterprise is comprised of so many systems and services which may be built based on open standards, custom-built, acquired from a third party, part of a legacy system or any such combination. With the advent of Service-Oriented Architecture (SOA) as the blue print for enterprise integration, most organizations tend to move away from monolithic applications and they expose their business functionalities as 'Services'. A 'Service' is defined as a logical representation of a repeatable business activity that has a specified outcome and does not depend on other services, unless it reuses them or it is composed of other services. By grouping various business functionalities as services in a well-defined and self-contained manner, the need for integrating these services to fulfil a business requirement has became a major challenge in the SOA world.

Figure 1 : Spaghetti Integration Dilemma

Obviously, there are many ways of integrating services and systems. If an organization really doesn't really care about the maintainability, scalability, troubleshooting, governance etc, then its most likely that the final integration outcome will end up in some sort of a Spaghetti Integration style. This is why the SOA needs a proper infrastructure that can provide a neat way of integrating diverse systems by preserving the ease of scalability, maintainability, troubleshooting and governance.

Figure 2 : Integration with an ESB

The standard infrastructure to implement the SOA concept is the Enterprise Service Bus (ESB) and therefore all the communication between the services and the consumers are done via the ESB. Hence, the notion of service integration is a major requirement of any ESB implementation. ESBs should facilitate not just standards based integrations (such as web services) but also other types of integration such as integrating with legacy systems.

A Service Integration Scenario - Healthcare Scenario

The best way to illustrate the WSO2 ESB's service integration capabilities is that by implementing a real world service integration scenario. Let's take a typical healthcare scenario where a given healthcare organization wants to expose some of their functionalities as a service to the external world.

Figure 3 : Healthcare Scenario

One of the most common business use case of a service integration is to expose internal services to the client who will be consuming the services via a Mobile App. As depicted in the Figure 3, the main objective of the mobile user is to find the details of the nearest healthcare center/facilities based on his geographical coordinate (longitude and latitude).

However, in this scenario, there is no direct mapping between the coordinates and the Healthcare facilities. Apparently, the organization has 3 different services (for simplicity, we'll assume that all 3 services are exposed as SOAP services) which can collaboratively provide the required business functionality. So, this is a typical service integration scenario, where we need to have seamless integration of these 3 services and expose the integrated business functionality as a single (virtual) service.

Before proceeding further, lets have a closer look at the available services and their service interfaces.

Figure 4 : Healthcare Scenario - Services

Geo Service

Geo service is capable of mapping a given coordinate to a Zip Code (Postal Code). The request and the response formats are shown below.

Request

         <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
                          xmlns:geo="http://geo.wso2">
            <soapenv:Header/>
            <soapenv:Body>
                <geo:getZipCode>
                    <geo:longitude>1.0</geo:longitude>
                    <geo:latitude>2.0</geo:latitude>
                </geo:getZipCode>
            </soapenv:Body>
        </soapenv:Envelope>
    

Response

        <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
            <soapenv:Body>
                <ns:getZipCodeResponse xmlns:ns="http://geo.wso2">
                    <ns:return>32746</ns:return>
                </ns:getZipCodeResponse>
            </soapenv:Body>
        </soapenv:Envelope>
    

HC Facility Locator Service

HC Facility Locator Service can resolve a given zip code to the Healthcare center codes (IDs). One important thing to note here is that, for a given zip code, there may be multiple healthcare center codes returning from the service.

Request

        <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
                          xmlns:heal="http://healthcare.wso2">
            <soapenv:Header/>
            <soapenv:Body>
                <heal:getHCCenters>
                    <heal:postalCode>32746</heal:postalCode>
                </heal:getHCCenters>
            </soapenv:Body>
        </soapenv:Envelope>
    

Response

        <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
            <soapenv:Body>
                <ns:getHCCentersResponse xmlns:ns="http://healthcare.wso2">
                    <ns:return>2583</ns:return>
                    <ns:return>5201</ns:return>
                    <ns:return>5575</ns:return>
                    <ns:return>805</ns:return>
                    <ns:return>2285</ns:return>
                </ns:getHCCentersResponse>
            </soapenv:Body>
        </soapenv:Envelope>
    

Healthcare Center Information Service

Finally, Healthcare Center Information Service, resolves the Healthcare Center code to the matching healthcare center details.

Request

        <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
                          xmlns:heal="http://healthcare.wso2">
            <soapenv:Header/>
            <soapenv:Body>
                <heal:getHCCenterInfo>
                    <heal:hcCenterCode>2583</heal:hcCenterCode>
                </heal:getHCCenterInfo>
            </soapenv:Body>
        </soapenv:Envelope>
    

Response

        <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
            <soapenv:Body>
                <ns:getHCCenterInfoResponse xmlns:ns="http://healthcare.wso2">
                    <ns:return xsi:type="ax2494:HCInfo" xmlns:ax2494="http://healthcare.wso2/xsd"
                               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
                        <ax2494:address>2583 South Volusia Ave (17-92), Suite 300</ax2494:address>
                        <ax2494:approxDistance>13.1</ax2494:approxDistance>
                        <ax2494:city>Orange City,  FL</ax2494:city>
                        <ax2494:hcCenterName>Orange City CBOC</ax2494:hcCenterName>
                        <ax2494:phone>386-456-2080 Or 386-456-2082</ax2494:phone>
                    </ns:return>
                </ns:getHCCenterInfoResponse>
            </soapenv:Body>
        </soapenv:Envelope>
    

Deploying Sample Services on WSO2 Application Server

Lets start with deploying the sample services on WSO2 Application Server. I have created all 3 sample services which can be downloaded from the attachments section of this article.

• Download and unzip wso2as-5.0.0.zip.
• Change offset (in repository/conf/carbon.xml) of WSO2 AS to :

  1

• Start WSO2 AS with sh ./bin/wso2server.sh
• Login to the WSO2 AS management console (un:admin, pwd:admin) and deploy sample services as aar services on WSO2 AS (Manage > Services > Add > AAR Service)
• The required services are geows-SNAPSHOT.aar, hcfacilitylocator-SNAPSHOT.aar, hcinformationservice-SNAPSHOT.aar
• Once all 3 services are deployed in WSO2 AS, you can use 'TryIt' feature to test and verify the services works properly(You may use the input values used in each request as shown in the previous example)

Fundamentals of WSO2 ESB

Now that we have a good understanding about the Healthcare Service Integration scenario, let's move on with the implementation level details. If we analyze the business requirements again, we need to implement the business functionality as a service, which can provide the details of the nearest Healthcare Center based on the Geographical coordinate provided by the user.

In the ESB's perspective, we need to expose a 'virtual service', that provides the required business functionality by seamless integration of Geo Service, HC Facility Locator Service and HC Center Information Service. In the WSO2 ESB, such service is termed as a 'Proxy Service'. Before jumping in to the actual implementation of the service, it's mandatory to understand some basic concepts related to WSO2 ESB.

Figure 5 : WSO2 ESB - Proxy Services fundamentals

• Mediator : This is the fundamental component of any message flow implementation of WSO2 ESB. A mediator has an input message, an output message and some associated configuration. This configuration is a pure XML based configuration that can be use to transfrom, alter or manipulate the incoming message of a Mediator to form the out going message.
• Sequence : A sequence is a sequential arrangement of a set of mediators. It resembles an industrial pipeline. A given sequence may have an arbitrary number of mediators and message flows through them in sequential manner
• Proxy Service : This is the same concept that we have described above, where we can host a virtual service inside the ESB. We already know the importance of this feature. Obviously, in this Healthcare Service Integration scenario, we will implement a Proxy Service that provides seamless integration of the above three services.
• Endpoint : is a logical representation of an actual back-end service or a group of back-end services (i.e LoadBalancing and FailOver)

Message Flow inside a Proxy Services

• A Proxy Service has two main message flows; InSequence and OutSequence.
• When a client sends a message to a Proxy Service, the message always goes to the 'InSequence'
• So, inside the InSequence, we can manipulate/transform the message and send it to a back-end service using a 'send' mediator (with an Endpoint)
• When the message is sent out from the InSequence, the response message comes to the 'OutSequence' by default (i.e If we don't specify a receiving sequence). Similar to InSequence, inside the OutSequence, we can transform/log/manipulate the message as per our requirement and finally send back to the client.
• If there's a fault, then the fault sequence will get invoked.

Concept of 'Receiving Sequence'

• In the above section on Proxy Service message flow, we have understood the default message flow of a Proxy Service
• From the WSO2 ESB 4.x releases, we have introduced the concept of the 'receivingSequence', where a given user can specify the sequence which the response for a outgoing request from ESB, should go to. In other words, we can override the default behaviour where the response message comes to OutSequence.
• We can simply create a sequence that can handle the response from a given service invocation and just before sending the original request to the service we can specify the receiving sequence in the 'send' mediator.

Implementing Healthcare Scenario with WSO2 ESB

Now that we have deployed/tested the required backend services and understood the basic concepts of ESB, we are all set to start integrating the services with WSO2 ESB

As the initial setup, we need to define the service definition of the virtual service that we are going to expose from the ESB. Since this will be implemented as a Proxy Service inside the WSO2 ESB, we simply need to create a WSDL for the proxy service with the required schema and operations.

Figure 6 : Service Integration with WSO2 ESB

Creating the required Endpoints

• We can start the implementation by defining the Address Endpoints for Geo Service, HC Facility Locator Service and HC Information Service.
• GeoEP Endpoint

            <endpoint xmlns="http://ws.apache.org/ns/synapse" name="GeoEP">
                <address statistics="disable" trace="disable" uri="http://localhost:9764/services/GeoService/"/>
            </endpoint>
        

• HCFacilityLocatorServiceEP Endpoint

            <endpoint xmlns="http://ws.apache.org/ns/synapse" name="HCFacilityLocatorServiceEP">
                <address statistics="disable" trace="disable" uri="http://localhost:9764/services/HCFacilityLocatorService"/>
            </endpoint>
        

• HCInformationService Endpoint

            <endpoint xmlns="http://ws.apache.org/ns/synapse" name="HCInformationService">
                <address statistics="disable" trace="disable" uri="http://localhost:9764/services/HCInformationService"/>
            </endpoint>
        

Implementation of HCCProxyService

Before we dive deep in to the implementation details, its important to have a high level understanding about the implementation. What follows is the implementation of the message flow

Figure 7 : Healthcare Scenario - Summary

• We define the service interface of HCCProxyService such that to have longitude and latitude as the input values.

	<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
                              xmlns:heal="http://healthcare.wso2">
                <soapenv:Body>
                    <heal:getHealthcareCenterInfo>
                        <heal:longitude>34.3</heal:longitude>
                        <heal:latitude>-43.2</heal:latitude>
                    </heal:getHealthcareCenterInfo>
                </soapenv:Body>
	</soapenv:Envelope>
        

• The output will be the details of a set of nearest Healthcare Facilities.
• To implement the scenario explained here, you simply have to use the 'HCCService.wsdl' (provided as an attachment). You can open HCCService.wsdl and observe the request that needs to be sent to the HCCProxyService
• Now we have the WSDL for the proxy service, yet we haven't created it inside the ESB. In order to create the proxy service you can either use the management console of the WSO2 ESB or WSO2 Developer Studio. Either way, you have to create a custom proxy named 'HCCProxyService' by using 'HCCService.wsdl' as the publish wsdl of the proxy service.
• It is recommended to do incremental development of your ESB configuration. So, you may first check the proxy service properly getting invoked from the SOAP UI by putting a full log in the log mediator.
• Since the original request from the client comes to the 'InSequence', our initial configuration must be started from the InSequence of the proxy service : HCCProxyService
• Our goal is to resolve the coordinates and find-out the matching Healthcare Center details, so first we need to call the 'Geo Service' to resolve the zip code from the given coordinate. Therefore we have to create a new request to be sent to Geo Service and enrich that request with the original values of longitude and latitude given from the client.
• Obviously, we need to use the original values of longitude and latitude from the client's request. To do so, first we have to extract those values. Here I have used the property mediator to do so. You may verify that the values are properly extracted by putting some log mediators.

            <property action="set"
                      expression="//heal:getHealthcareCenterInfo/heal:longitude/text()"
                      name="longitude" scope="default" type="STRING" xmlns:heal="http://healthcare.wso2"/>
            <property action="set"
                      expression="//heal:getHealthcareCenterInfo/heal:latitude/text()"
                      name="latitude" scope="default" type="STRING" xmlns:heal="http://healthcare.wso2"/>
            <log category="INFO" level="custom" separator=",">
                <property expression="$ctx:longitude" name="Longitude"/>
                <property expression="$ctx:latitude" name="Latitude"/>
            </log>
        

• Now we have extracted the required values, and now it is time to create the new Geo Service request. For this purpose we may use XSLT, PayloadFactory or Enrich mediators. Here I have used the Enrich mediator (and later I have used the Payload Factory). In general, for simple one to one mapping it is always recommended to use mediators such as Payload Factory or Enrich, as they are more high performant compared to XSLT.
• You may use the WSDL of the GeoService (from WSO2 Application Server) and create the payload in Enrich mediator as an inline source (shown below)
• Initial payload is created with default values, but later I have replaced them with the extracted values, again using Enrich mediator. (Log mediators are used for verification)

            <enrich>
                <source clone="true" type="inline">
                    <geo:getZipCode xmlns:geo="http://geo.wso2">
                        <geo:longitude>0</geo:longitude>
                        <geo:latitude>0</geo:latitude>
                    </geo:getZipCode>
                </source>
                <target action="replace" type="body"/>
            </enrich>
            <enrich>
                <source clone="true" property="longitude" type="property"/>
                <target action="replace" type="custom"
                        xmlns:geo="http://geo.wso2" xpath="//geo:getZipCode/geo:longitude/text()"/>
            </enrich>
            <enrich>
                <source clone="true" property="latitude" type="property"/>
                <target action="replace" type="custom"
                        xmlns:geo="http://geo.wso2" xpath="//geo:getZipCode/geo:latitude/text()"/>
            </enrich>
            <log category="INFO" level="custom" separator=",">
                <property name="MessageFlow" value="======================= Sending Request To : GeoWS ======================="/>
            </log>
            <log category="INFO" level="full" separator=","/>
        

• At this point we are ready to send the request to the Geo Service. However, before proceeding we need to create a receiving sequence that can handle the response from the Geo Service.
• To create the receiving sequence you may just create a new sequence (named as 'hcfRequest') and put an empty send mediator without an endpoint (This will simply send the response message back to the client. We will change this later such that to invoke the HCFacility Locater service). Then modify the HCCProxyService's inSequence by specifying the send mediator with 'GeoEP' and the receiving sequence as 'hcfrequest' (You can send a request from the SOAP UI to the HCCService and the reponse from the Geo should be the response in the SOAP UI.)
• Let's review the full configuration of the inSequence of the HCCProxyService

            <inSequence>
                <property action="set"
                          expression="//heal:getHealthcareCenterInfo/heal:longitude/text()"
                          name="longitude" scope="default" type="STRING" xmlns:heal="http://healthcare.wso2"/>
                <property action="set"
                          expression="//heal:getHealthcareCenterInfo/heal:latitude/text()"
                          name="latitude" scope="default" type="STRING" xmlns:heal="http://healthcare.wso2"/>
                <log category="INFO" level="custom" separator=",">
                    <property expression="$ctx:longitude" name="Longitude"/>
                    <property expression="$ctx:latitude" name="Latitude"/>
                </log>
                <enrich>
                    <source clone="true" type="inline">
                        <geo:getZipCode xmlns:geo="http://geo.wso2">
                            <geo:longitude>0</geo:longitude>
                            <geo:latitude>0</geo:latitude>
                        </geo:getZipCode>
                    </source>
                    <target action="replace" type="body"/>
                </enrich>
                <enrich>
                    <source clone="true" property="longitude" type="property"/>
                    <target action="replace" type="custom"
                            xmlns:geo="http://geo.wso2" xpath="//geo:getZipCode/geo:longitude/text()"/>
                </enrich>
                <enrich>
                    <source clone="true" property="latitude" type="property"/>
                    <target action="replace" type="custom"
                            xmlns:geo="http://geo.wso2" xpath="//geo:getZipCode/geo:latitude/text()"/>
                </enrich>
                <log category="INFO" level="custom" separator=",">
                    <property name="MessageFlow" value="======================= Sending Request To : GeoWS ======================="/>
                </log>
                <log category="INFO" level="full" separator=","/>
                <send receive="hcfRequest">
                    <endpoint key="GeoEP"/>
                </send>
            </inSequence>
        

Now we have implemented one portion of the full message flow; the invocation of the Geo Service. Now we have to modify the receiving sequence : 'hcfRequest' such that to do the second service invocation where we have to call the HC Facility Locator service.

As we did for Geo Service request, here we have to create a new payload to be sent to HC Facility Locator. And we need to extract the 'zipcode' value from the response coming from Geo Service and then add that to the new payload.

To do so, rather than using enrich mediator, we can use Payload Factory mediator. With Payload Factory, we give the required payload with the arguments to that needed to be replaced with dynamic values

Once we are done with it, we can put a log mediator and verify that the payload is properly created by sending some requests

The next step is to add the service invocation logic of HC Facility locator, where again use another receiving sequence 'hciRequest' which the response from the HC Facility Locator is handled.

For that we can add a send mediator which is pointing to 'HCFacilityLocatorServiceEP' endpoint. Again for the testing purpose, you can just add an empty send mediator to the hciRequest, which can send the message back to the client and verify that the response is received at the client side.

Let's review the final configuration of the 'hcfRequest'.

        <sequence xmlns="http://ws.apache.org/ns/synapse" name="hcfRequest">
            <log category="INFO" level="custom" separator=",">
                <property name="MessageFlow" value="------------------- Response Received - From : GeoWS ----------------------------------"/>
            </log>
            <log category="INFO" level="full" separator=","/>
            <property action="set"
                      expression="//geo:getZipCodeResponse/geo:return/text()"
                      name="zipcode" scope="default" type="STRING"
                      xmlns:geo="http://geo.wso2"
                      xmlns:ns="http://org.apache.synapse/xsd" xmlns:ns3="http://org.apache.synapse/xsd"/>
            <log category="INFO" level="custom" separator=",">
                <property expression="$ctx:zipcode" name="zipcode"
                          xmlns:ns="http://org.apache.synapse/xsd" xmlns:ns3="http://org.apache.synapse/xsd"/>
            </log>
            <payloadFactory>
                <format>
                    <heal:getHCCenters xmlns:heal="http://healthcare.wso2">
                        <heal:postalCode>$1</heal:postalCode>
                    </heal:getHCCenters>
                </format>
                <args>
                    <arg expression="$ctx:zipcode"
                         xmlns:ns="http://org.apache.synapse/xsd" xmlns:ns3="http://org.apache.synapse/xsd"/>
                </args>
            </payloadFactory>
            <log category="INFO" level="custom" separator=",">
                <property name="MessageFlow" value="==================== Sending Request To : HCFacilityLocatorService ================"/>
            </log>
            <log category="INFO" level="full" separator=","/>
            <send receive="hciRequest">
                <endpoint key="HCFacilityLocatorServiceEP"/>
            </send>
        </sequence>
    

Once we have completing the Geo and HC Facility Locator service integrations, then we can move to the next step where we get the actual information about a given Healthcare Center based on its code name (or ID)

However, this scenario it not that trivial as the previous two service invocations. Because, as I explained during scenario description, there can be multiple Healthcare Centers for a given zipcode. Therefore, for each and every HC Center code, we have to invoke the HC information Service.

In general this is a standard application of the Splitter EIP. We can use the 'Iterate' mediator that comes with the ESB.

This is the full configuration of the hciRequest, where we iterate based on the Healthcare Center Codes.

<sequence xmlns="http://ws.apache.org/ns/synapse" name="hciRequest">
    <log level="full"/>
    <iterate xmlns:hfs="http://healthcare.wso2" xmlns:ns="http://org.apache.synapse/xsd" xmlns:ns3="http://org.apache.synapse/xsd" preservePayload="true" attachPath="//hfs:getHCCentersResponse" expression="//hfs:getHCCentersResponse/hfs:return">
        <target>
            <sequence>
                <payloadFactory>
                    <format>
                        <heal:getHCCenterInfo xmlns:heal="http://healthcare.wso2">
                            <heal:hcCenterCode>$1</heal:hcCenterCode>
                        </heal:getHCCenterInfo>
                    </format>
                    <args>
                        <arg xmlns:hcc="http://healthcare.wso2" expression="//hcc:getHCCentersResponse/hcc:return/text()"/>
                    </args>
                </payloadFactory>
                <log level="full"/>
                <send>
                    <endpoint key="HCInformationService"/>
                </send>
            </sequence>
        </target>
    </iterate>
 </sequence>

    

Iterate mediator basically splits the message based on a given xpath and it uses the 'attachPath' to constructed the split message. So, inside target element, we can create the new payload that needs to be sent to the HC Information Service. We have used the Payload Factory mediator for that purpose.

Then we send the new message to the 'HCInformationServiceEP' endpoint. The important thing to note here is that, we haven't specified the receiving sequence. As we have already discussed, the default scenario will get applied, which means the response message will come to the 'OutSequence of the proxy service.

All the responses for each split message will end up in the OutSequence of the 'HCCProxyService'. We need to use 'Aggregate' mediator to aggregate all the responses and send the aggregated response back to the client.

Here is the final configuration of the OutSequence of 'HCCProxyService'.

        <log category="INFO" level="custom" separator=",">
            <property name="MessageFlow" value="------------------------Response Received - From : HCInformationService ------------------------"/>
        </log>
        <log category="INFO" level="full" separator=","/>
        <aggregate>
            <completeCondition timeout="0">
                <messageCount max="-1" min="-1"/>
            </completeCondition>
            <onComplete expression="//hcc:getHCCenterInfoResponse" xmlns:hcc="http://healthcare.wso2">
                <log category="INFO" level="custom" separator=",">
                    <property name="MessageFlow" value="======================= Sending Back the Aggregated Responses. ==============="/>
                </log>
                <log category="INFO" level="full" separator=","/>
                <send/>
            </onComplete>
        </aggregate>
    

Testing the Healthcare Scenario

Now that we have analyzed implementation details of the entire scenario, it's time to try out the Healthcare Scenario with the WSO2 ESB and WSO2 Application Server. I have added all the required services and ESB configuration as an attachment. ESB configuration is created using the WSO2 Developer Studio and it is available as a WSO2 Carbon application-cApp : Service_Integration_CApp_1.0.0.car.

        Service_Integration_Artifacts
        ├── cApp
        │   └── Service_Integration_CApp_1.0.0.car
        └── services
        ├── GeoService.wsdl
        ├── geows-SNAPSHOT.aar
        ├── HCCService.wsdl
        ├── HCFacilityLocatorService.wsdl
        ├── hcfacilitylocator-SNAPSHOT.aar
        ├── hcinformationservice-SNAPSHOT.aar
        └── HCInformationService.wsdl

    

After deploying all the required services in WSO2 Application Server, you can simply deploy the attached cApp (Service_Integration_CApp_1.0.0.car) as an Application using WSO2 ESB management console.

Once everything is deployed you can use the SOAP UI project created based on the WSDL of the HCCProxyService and send a request to the HCCProxyService.

You will see various log messages, that we put in using the log mediators in each mediation flow.

Conclusion

Service Integration is a very common integration requirement and the WSO2 ESB provides a rich set of features to cater to these requirements. We have discussed a real world service integration scenario and we implemented it from scratch using the WSO2 ESB. For simplicity, we considered some SOAP services. However in a future article I will touch on service integration with some heterogeneous services as well. Also, one might suggest to use WS-BPEL for the exact same scenario with WSO2 BPS, which is still a valid candidate. I will cover the topic of when to use the ESB and when to use WSO2 BPS in a future article as well.

References

1. Patterns and Best Practices for Enterprise Integration
2. WSO2 ESB - An answer to Enterprise Service Integration
3. WSO2 ESB 4.5.0
4. Achieving Optimal ESB Performance with WSO2 ESB
5. WSO2 ESB performance

Author

Kasun Indrasiri, Associate Technical Lead, WSO2 Inc

Attachment	Size
Service_Integration_Artifacts.zip	34.92 KB