Scott Hanselman

On the road and still more Web Services DON'Ts

August 21, 2003 Comment on this post [1] Posted in Web Services | XML
Sponsored By

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:

<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 (  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.

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.

facebook twitter subscribe
About   Newsletter
Hosting By
Hosted in an Azure App Service
August 22, 2003 14:21
Oh my ... this world is so insane ... we should really stay away from these technical experiments ;-)

Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.