Managing a SOAP Version Mismatch Issue Using Oracle Service Bus

Recently, we discovered a version mismatch issue in which two SOAP services on different versions (Service-A on SOAP 1.2 and Service-B on SOAP 1.1) were failing to communicate with each other. Here, we explain how to resolve this issue.

Difference between SOAP 1.1 and SOAP 1.2

Before diving into the solution, let’s look at the improvements SOAP Version 1.2 provides over SOAP 1.1.

1. Offers a clear processing model;
2. Provides improved interoperability with testing and implementation requirements;
3. Based on XML Information Set (i.e. It is specified as an Infoset, which is carried from one SOAP node to another, whereas SOAP 1.1 was based on XML 1.0 serialization.);
4. Offers protocol independence for developers by providing a binding framework;
5. Includes HTTP binding for improved integration to the World Wide Web;
6. Delivers a well-defined extensibility model; and
7. Provides improved support for Web standards.

WSDL changes observed in SOAP 1.2

1. Namespace Changes: SOAP 1.2 supports the following namespace definition:

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

2.  SOAP 1.2 uses “application/soap+xml” as the Content Type, whereas SOAP 1.1 uses “text/xml”.

3.  SOAP:Operation and SOAP Binding must be specified in SOAP 1.2 WSDL.

Solution

Now, to overcome the versioning mismatch issue mentioned above, we must follow these steps:

1. Generate the OSB Proxy as a Message Based Proxy service. This will be based on the XSD with only the “body” part with required parameters to call Service-A (SOAP 1.2) and Service-B (SOAP 1.1).
2. Create a Pipeline Service based on the same methodology explained in number 1, above.
3. In the Pipeline Service, navigate to Message Flow and add a Pipeline Pair – rename it per the process standards.
4. In the Request Pipeline node, add a Stage and rename it per process standards.
5. Inside the Stage, add a Service Callout, then browse for the Proxy Service for the wrapper of Service-A or the business service of Service-A. The Service Callout configuration is shown below with the required message to Service-A parameters assigned. 
6. After the above Pipeline Pair is complete, add a Route Node.
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. The following snapshot illustrates this.  

As always, if you have any questions regarding this issue or solution, leave us a comment below or contact us at info@astcorporation.com and our team will get back to you.