Handle SOAP Version Mismatch issue using OSB

What is SOAP?

SOAP is a protocol specification for exchanging structured information in the implementation of web services in computer networks. Its purpose is to induce extensibility, neutrality and independence.

Difference Between SOAP 1.1 and SOAP 1.2

SOAP Version 1.2 can do everything that SOAP/1.1 does, and more. Below are some of the properties SOAP 1.2 has over SOAP 1.1.

• Provides clear processing model
• Testing and implementation requirements leads to better interoperability
• Based on XML Information Set i.e. it is specified as an Infoset which is carried from one SOAP node to another. While SOAP/1.1 was based on XML 1.0 serialization
• Gives developers protocol independence by providing a binding framework
• Includes HTTP binding for better integration to the World Wide Web
• Delivers a very well-defined extensibility model
• Has better support for Web standards

WSDL changes observed in SOAP-1.2

1. Namespace Changes: SOAP 1.2 supports below namespace definition.

xmlns:soap12="http://www.w3.org/2003/05/soap-envelope"

2. SOAP 1.2 uses "application/soap+xml" as Content-Type and SOAP 1.1 uses "text/xml".
3.  SOAP:Operation and SOAP Binding need to be specified in SOAP 1.2 WSDL

Use Case Scenario:

We had a requirement where we should create a OSB service which should call first a SOAP1.2 web service (say as service-A) and get data from the service-A. Then the OSB service need to add the retrieved data from service-A and call up another SOAP service based on SOAP 1.1 (say as service-B) to process the data.

In this scenario we have created a OSB Service which was build on a WSDL which was first calling Service-A and then Service-B, but during Testing of the OSB Service, we found that services were failing due to SOAP version mismatch issue as Service-B is built on SOAP version 1.1 and Service-A  being a latest release services are built on SOAP Version 1.2.

Solution

To overcome this versioning issue, we have followed below steps:

1.       Generate the OSB Proxy as a Message Based Proxy service which will be based on the XSD which will have only the “body” part with required parameters to call Service-A and Service-B.

2.       Create a Pipeline Service based on the same methodology explained in point#1.

3.       In the Pipeline Service, go to message flow and add a pipeline pair and rename it as per the process standards.

4.       In the Request Pipeline node, add a Stage and renamed it as per standards.

5.       Inside the stage, add a Service callout, and browse for the proxy service for wrapper of Service-A or business service of Service-A, and configure the Service Callout as shown in below diagram, and assign the required message to Service-A parameters.

6.       Now after the above Pipeline Pair, add a RouteNode .

7.       Inside the Route Node add a Routing Operation and configure the same for the Business Service  of Service-B

8.       Inside the Request Actions, assign or replace the Body and Header to make a successful call for Business Service. Below snapshot will help on the same.