February 11, 2005
@ 04:57 AM

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.


Friday, February 11, 2005 5:23:47 AM (GMT Standard Time, UTC+00:00)
Ha - I was going to ask Tim about that exact problem, but I guess you've saved me the effort. ;)
Friday, February 11, 2005 7:29:35 PM (GMT Standard Time, UTC+00:00)
Great post. However object first develoment leads to even more problems. And I'm not just talking about what XSD you get out of untyped hashtables, arraylists, and arbitrary object graphs. Even with such excellent contract definition facility as Indigo DataContract the XSD you get with type separators, must understand flags, and other DataContract-isms is going to be a PITA to consume and produce from non-indigo stacks.
Friday, February 11, 2005 9:17:26 PM (GMT Standard Time, UTC+00:00)
>However object first develoment leads to even more problems.

I respectfully disagree. If Indigo using a valid subset of XSD constructs is hard for other toolkits to consume why do you think using the entire gamut of XSD's capabilities would be better instead of worse?
Monday, February 14, 2005 5:34:32 PM (GMT Standard Time, UTC+00:00)
Who says that writing the contract first requires you to use all of XSD's features ?

Unless every tool supports exactly the same subset of XSD (and MSFT seem very against the WS-I proposal to define an XSD subset), you're always going to get a impedence mismatch between tools, the only way forward is to ensure your final contract (however it started) contains the subset of subsets that all the tools support.
Monday, February 14, 2005 8:44:13 PM (GMT Standard Time, UTC+00:00)
So you're basically saying writing a contract first doesn't buy me anything since I still have to target the subset of features supported by all toolkits if I want to globally interop. So basically, writing the XSD/WSDL first doesn't buy me more interop than using a toolkit AND is more expensive to boot since my developers now have to learn the intricacies of WSDL/XSD/WS-*.
Monday, February 14, 2005 9:46:13 PM (GMT Standard Time, UTC+00:00)
Concrete example of an uninteroperable web service which was created by starting out with the object oriented code:


Making the discussion binary ("doesn't buy me anything") is not helpful.

Monday, February 14, 2005 11:30:52 PM (GMT Standard Time, UTC+00:00)
And I can show you an example of an uninteroperable web service generated by hand. Where does that leave us? Everyone seems set on trying to argue about how their favorite approach sucks less than the other.

So far the only useful advice I've seen on this topic was your blog posting suggesting people use multiple toolkits to test their WSDLs. However even that post implies this is somehow a problem with SOAP toolkits that is fixed by the silver bullet that is contract first development.
Tuesday, February 15, 2005 9:16:32 AM (GMT Standard Time, UTC+00:00)
I'm surprised to read a discussion about workarounds against the problems caused by incomplete implementations of ill-conceived protocols by inadequate tools. We shouldn't be using any of that junk.

Easy and unsurprising object-oriented communication requires really object-oriented protocols (e.g. CORBA).
Interoperable implementation of XML Schema, SOAP etc. requires a much greater effort and impact on application code than what typical WS* toolkits promise, typically including explicit XML processing instead of flawed automatic mappings.
Tools trying to do both things,at least until now, are just lying to programmers and maybe to their makers.
A responsible decision is needed: to develop something cheap and brittle for the client toolkit A and server toolkit B in use forgetting about interoperability, or to bear the cost of implementing the stack of required XML-based bad ideas in its entirety.
Lorenzo Gatti
Comments are closed.