Service Contracts = Hall of Mirrors

Nice post on service versioning by Dare Obasanjo. He refers to posts by Tim Ewald extensively.

I generally agree with their conclusions. Sadly, it demonstrates that "design by contract" with web services really is a hall of mirrors.

I beat the "contract first" drum as loud as anyone. The truth is, however, at runtime, the true contract between my services is very loose. This is due to lots of things - complexity of WSDL (I try to avoid at all costs), over engineering of XSD, industry standard schemas, etc.

Tool support / code gen from XSD used to be important to me. I came to services via CORBA and was enamored with the whole IDL thing. IDL in CORBA was much simpler - just basic C structs etc. It generally worked, but was certainly not without its problems. So when I first started writing web services in 2002, I dedicated myself to making WSDL an IDL (i.e., contract first). As I've said in various parts of this blog, that was a very painful experience.

I moved on from web services to just dealing with services that use XML on the wire. That XML has always been backed by XSD. As Dare and Tim recommend, the contracts are very loose.

Until recently, I have been ardently pro tool support with this (i.e., just simple XSD) approach. You can get any tool to work when you dumb things down (e.g., .NET xsd.exe, JAXB, Castor, XMLBeans). I always put the generated classes in some package like "msgmapper". I then write some helper classes that serve as a level of indirection to the generated classes.

I used to think it was pure unadulterated evil to generate XML by hand via JDOM, Xerces, etc. Now, I almost prefer that approach. Maybe I am just getting tired. Maybe I am taking the simplicity thing too far. Its just that all the tools come with baggage. You have to run them in the build, they spew out thousands of classes, developers forget to isolate them and they bleed deep into your code (and are hard to extract) etc. With the brute force approach, you go to the "msgmapper" package and there is your code that generates your XML - no fuss, no muss.

More and more I think that any tool that generates code (at least for high level languages like Java & C#) is to be avoided at all costs.

So are contracts important? Of course they are. The thing is the devil is in the details & there is no tool that is going to just give it to you or even make it easy. IMHO contracts are more of an art then a science.