XML processor or Regex, that is the question.

Sometime, you have to wonder why something works the way it does.

The most recent time I had to scratch my head, was when trying to showcase the integration of Web services with the Office 2003 Research pane. It let me wonder what SOAP toolkit is used to build the client side piece. The answer came from the wire; some homegrown client, identified as 'Microsoft Office/11.0 (Windows NT 5.2; Microsoft Office 11.0.6568; Pro)' in the user-agent field.

If you scope the namespace as Microsoft expects them to be, based on the WSDL they advertise, or include a whitespace between the parameter element and the registration response, it won't work. And the error is displayed as "No services were added because the service provider did not provide any valid information." - not exactly true...

When you put this is context of other papers, like 'Why XML Security is Broken', it make it all clear - The XML processing is most likely limited to some kind of optimized text processor that's only serving one purpose: extract the business data from the SOAP wrapper as fast as possible. As I was hutting for some hint, I discovered that the Office 2003 research pane accepts either literal or encoded response.

Nowadays, Web services and SOAP are only used as a transport channel for Plain Old Text (or binary data). Do not try to mix the schema that describes the operations and the underlying business objects.

It’s kind of sad to see that we cannot use XML as a native format inside the SOAP envelope.



Popular posts from this blog

Changing the version of JDK used by JDeveloper

Connection reset from a WCF Web Service

Test locally first, then deploy to the cloud.