home

Sunday, October 28, 2012

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 cloudSAASapplication, encountered another example how things should not be done. First of all it was not "stateless" but required the use of a login and logoutoperation. With security not based on standardHTTP basic authenticationor 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 acookie! 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: theIBM DataPower ESBrefused 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 IBMarticleclearly explains that a document/literal web service can have multiple parts in a message.

TheWS-I Basic Profilewas 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), haveat most one partlisted 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.