On the road and still more Web Services DON'Ts
We've just arrived in Hong Kong and we're wireless again. I'd post another picture, but it would look just like the last one except we'd be more tired and have Chinese writing behind us.
On a technical note, we're continuing to run into more Web Services No-No's. This time it was interfacing .NET with a "legacy" Apache-SOAP implementation. Oy vey. It insisted on a custom Apache encoding style ala:
http://xml.apache.org/xml-soap/literalxml"><ns1:SomeMessage xmlns:ns1="urn:UpdateSubUser" SOAP-ENV:encodingStyle="
So, in the tradition of writing Soap Extensions we are ashamed of :) my CTO whiped up an custom attribute "XmlForceEncoding" that allows this madness to occur. Also, the Web Services we were consuming was using the XSD spec from 1999, rather than 2001, so that was special.
Here's some things Chris and I learned (Chris' words):
The encodingStyle they are using is archaic and Apache-specific (non-standard). It also violates the current WS-I Basic Profile (http://ws-i.org/Profiles/Basic/2003-08/BasicProfile-1.0a.htm#refinement35501800). There are a number of messages on SOAPBuilders and elsewhere about challenges with interoperability for servers using this sort of encoding (see below). The problem here is the contradiction between the use="literal" attribute and the encodingStyle attribute. In (modern) web services, use="literal" means XSD schema-based encoding, so it is therefore unecessary (and redundant) to specify an encodingStyle. In this case it is even contradictory. http://aspn.activestate.com/ASPN/Mail/Message/Apache-Soap-Users/736360
About Scott
Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.
About Newsletter
Christian Weyer
Comments are closed.