<wsdl:operation name="sendRequest" parameterOrder="request requestHeader">
<wsdl:input message="GenericRequest" />
<wsdl:output message="GenericResponse" />
<wsdl:fault message="SystemError" name="SystemError" />
This web service is actually the (one and only) entry point to a "service platform."
We see the operation sendRequest, with a GenericRequest message as input, and a GenericResponse message as output. Here are the definitions:
<xsd:element name="GenericRequest" type="xsd:base64Binary" />
<xsd:element name="response" type="xsd:base64Binary" />
<xsd:element ref="Errors" />
Both input and output messages are base64 encoded binaries.
Well, in reality, I also received a large bundle of XML schemas defining what these binaries actually could be: a whole bunch of XML messages, all base64 encoded.
This is a beautiful example of how web service contracts should not be made.
From the WSDL, the consumer cannot infer at all what the contract is really about. He will need to check additional documentation to figure this out. And indeed, many (>30!) documents accompany the WSDL. Good luck! Hope you don't miss a subtle point somewhere.
And why base64 encoded XML? Base64 is good for real binaries, like images, pdf documents, etc., if you can't send them as attachments, but it is not particularly good for plain text or XML. It makes it hard to unmarshall the XML.
Basically, the base64encoding is an example of a do-it-yourself transport; a protocol that needs to be specifically implemented by both service and consumer. It's embedded within the standard SOAP transport, which may make people think it is standard, but it isn't.
This type of web service violates any good service oriented design. It leads to unnecessary high costs for all parties involved. The governance of future change is going to be a nightmare, and the operations support will be very costly.
This is a legacy system from day one!