The Fallacy of "XML Will Save Us"
Steve Vinoski has a blog posting entitled Focus on the contract where he writes
Tim offers some extremely excellent advice (as usual) regarding what really matters when you write your services. If I may paraphrase what he says and perhaps embellish it a bit, starting from the implementation language and generating your contracts from it is just plain wrong, wrong, wrong, at least for systems of any appreciable magnitude, reach, or longevity. Instead, focusing on the contracts first is the way to go. I've written about this for many years now, starting well over a decade ago.
When you start with the code rather than the contract, you are almost certainly going to slip up and allow style or notions or idioms particular to that programming language into your service contract. You might not notice it, or you might notice it but not care. However, the guy on the other side trying to consume your service from a different implementation language for which your style or notions or idioms don't work so well will care.
Although Steve Vinoski's argument sounds convincing, there is one problem with it. It is actually much easier to make an uninteroperable Web service if one starts with the service contract instead of with object oriented code. The reason for this is quite simple and one I've harped on several times in the past; the impedance mismatch between XSD and objects is quite significant. There are several constructs in W3C XML Schema which simply have no counterpart in traditional object oriented languages which cause current XML Web service toolkits to barf when consuming them. For example, the XmlSerializer class in the .NET Framework supports about half the constructs in W3C XML Schema. Most XML Web Service toolkits support a similar number [but different set] of features of W3C XML Schema.
This isn't theoretical, more than once while I was the program manager for XML Schema technologies in the .NET Framework I had to take conference calls with customers who'd been converted to the 'contract first' religion only to find out that toolkits simply couldn't handle a lot of the constructs they were putting in their schemas.Those conversations were never easy.
The main thing people fail to realize when they go down the 'contract first' route is that it is quite likely that they have also gone down the 'XML first' route which most of them don't actually want to take. Folks like Tim Ewald don't mind the fact that sometimes going 'contract first' may mean they can't use traditional XML Web Service toolkits but instead have to resort to SAX, DOM and XSLT. However for many XML Web Service developers this is actually a problem instead of a solution.
Comments
- Anonymous
February 10, 2005
What you say is true, but it's also true that the .NET support for XSD constructs is needlessly hampered.
It could support an awful lot more of the constructs from the W3C Schema spec that it does.
The specific problem I had with .NET was it's insistence on unambiguous (sorry if that's not the correct word, it was a while ago that I hit this) schemas.
This is not a mismatch between XSD and .NET, it's a limitation of the conversion between the two.
I can see how it would not be possible to resolve issues of this kind efficiently, but that is not the fault of XML, it's the .NET implementation that's at fault.
XML is big, slow, and represents a new data structure paradigm, rather than being either a union or an intersection of existing RPC techniques.
What is needed is something else (possibly a subset of SOAP) that does represent a union of existing RPC techniques.
Design by contract is good, but not if the contract is unimplementable.
(we had a complex schema that predated SOAP, we have always handled it in custom code, the Java implementations we came across were even more restricted than .NET). - Anonymous
March 01, 2005
Avoiding the pitfalls inherent in the contract-first design approach. - Anonymous
June 09, 2009
PingBack from http://cellulitecreamsite.info/story.php?id=7564