This post originated from an RSS feed registered with .NET Buzz
by Scott Hanselman.
Original Post: On the road and still more Web Services DON'Ts
Feed Title: Scott Hanselman's ComputerZen.com
Feed URL: http://radio-weblogs.com/0106747/rss.xml
Feed Description: Scott Hanselman's ComputerZen.com is a .NET/WebServices/XML Weblog. I offer details of obscurities (internals of ASP.NET, WebServices, XML, etc) and best practices from real world scenarios.
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:
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
Previous Topic
