Web Service incompatibilities

SOAP Web Services have lost quite some of their popularity: too complex, incompatibilities etc.  My answer is always that 1) SOAP just adds a very simple envelope around the request and response messages and 2) SOAP does work fine when you stick to the rules (a copy of a slide I use in my training classes):
 
Just recently I had encountered 2 nice examples of SOAP incompatibilities.

Cookies and SOAP

While investigating the web services API of a cloud SAAS application, encountered another example how things should not be done.  First of all it was not “stateless” but required the use of a login and logout operation. With security not based on standard HTTP basic authentication or WS-Security, but a proprietary scheme:
 
  <urn:credential>
    <urn:companyId>company-id</urn:companyId>
    <urn:username>user-name</urn:username>
    <urn:password>password</urn:password>
  </urn:credential>
 
 
But then came the surprise: the login operation returns a session handle which is actually a cookie! The cookie is to be passed as an HTTP header in each subsequent web service.  Had seen many ways to make web service implementations incompatible, but this is one for the top 5!  Obviously most web service clients require some hack to pass this cookie along the SOAP request.

Doc/literal with 2 parts

A more subtle challenge came recently by at a customer: the IBM DataPower ESB refused to import the WSDL file an Oracle product.  The web service used the document/literal style and one of the operations had a request message consisting of 2 parts.  So who was wrong and who was right: IBM or Oracle?
 
SOAP went through some growing pains in the beginning. The initial idea was an RPC mechanism whereby an operation could have multiple parameters. These parameters are passed as multiple parts in a request and response message. But with a better understanding of XML and XML schema’s, the world move to a model whereby XML documents were passed. Microsoft introduced the document/literal wrapped style whereby the root contains the name of the operation.
<soap:Envelope xmlns:soap=”http://www.w3.org/2001/12/soap-envelope”>
  <soap:Body>
    <OperationName>
      actual XML document…
    </operationName>
  <soap:Body>
</soap:Envelope
</soap:Envelope>
 
So my initial response was, document/literal web services should only have one part and Oracle is wrong. But a colleague pointed to the fact that Oracle would not implement web services that violate the standards. And indeed, the IBM article clearly explains that a document/literal web service can have multiple parts in a message.
 
The WS-I Basic Profile was an initiative to sharpen the rules and states: “R2201 A document-literal binding in a DESCRIPTION MUST, in each of its soapbind:body element(s), have at most one part listed in the parts attribute, if the parts attribute is specified.“. So the Oracle web service is not WS-I basic compliant but does not violate the SOAP/WSDL specifications.
 
Again a situation where one has to go for workaround, this time in the DataPower ESB. Had IBM implemented the specs correctly and/or Oracle stuck to the widely accepted ways-of-working and the WS-I Basic profile, everything would have worked smoothly.
 
Author: Guy

blogger

blogger

Curious to know more about this topic?

Working at i8c

i8c is a system integrator that strives for an informal atmosphere between its employees, who have an average age of approx 30 years old. We invest a lot of effort in the professional development of each individual, through a direct connection between the consultants and the management (no multiple layers of middle management). We are based in Kontich, near Antwerp, but our customers are mainly located in the triangle Ghent-Antwerp-Brussels and belong to the top 500 companies in Belgium (Securex, Electrabel, UCB, etc…).

Quality Assurance

i8c is committed to delivering quality services and providing customer satisfaction. That’s why we invested in the introduction of a Quality Management System, which resulted in our ISO9001:2000 certification. This guarantees that we will meet your expectations, as a reliable, efficient and mature partner for your SOA & integration projects.

i8c - ISO9001-2015

Also worth reading

Apigee Scope Validation using OpenAPI Specification

In API security and management, we often use a lot of different security mechanisms to protect the requested resource behind the API Gateway. One of these mechanisms is the validation of scopes to authorize a client on a specific sub-resource of the API. Most of

Read More »

Integrating with TIBCO CLOUD

Our experts Glenn, Jason, Jurgen, and Kevin dedicated an i8c FastTrack Day to examining the TIBCO iPaaS offering. Check out their Research & Development day report to learn what they uncovered. 👇  TIBCO CLOUD™ The TIBCO Cloud™ Integration enterprise integration platform-as-a-service (iPaaS) provides self-service integration

Read More »