Aaron Skopnnard has posted a response to my Contract-First XML Web Service Design is No Panacea blog post. In his post The virtue of contract-first Aaron Skonnard writes
I love being challenged
on my opinions. I've been challenged extensively regarding
my opinion
on contract-first development, although mostly by folks at Microsoft like
Don
,
Doug
, and
Dare
. The funny thing is when I have the same discussions with folks in the field building systems today, it's a no-brainer.
So why the disconnect between vendors and the rest of the world?
I believe it's because most vendors don't see (or appreciate) the main virtue of the contract-first approach, which has more to do with collaboration than interoperability. The latter is a result of the former. Let me explain.
Interoperability is the net result of a well-designed contract. By "well-designed" I mean a contract that experiences fewer interoperability issues when used across a variety of toolkits. Simply using contract-first does not guarantee a good contract. However, increased collaboration during contract does. This means getting all parties (everyone who will have to deal with the contract) involved early, during design, so you can identify what will and won't work in each implementation environment. This allows you to bring local expertise to the table early in the process before the implementation investment begins. This process influences the subset of XSD constructs that can be safely used given the identified limitations.
The first thing that I'll point out is that I'm not a 'vendor'. Now that I work at MSN, I am as much a customer of the XML Web Services stuff coming out of the Indigo folks as anybody else. My approach to XML Web Service design comes from the perspective of having to figure out what strategy we should use when deploying services that will be used by millions of customers either directly or indirectly.
With that out of the way, I can focus on the fundamental error in the generalization presented by Aaron Skonnard. He writes "This means getting all parties (everyone who will have to deal with the contract) involved early, during design". Unfortunately there is simply no chance that
providers of XML Web Services on the Web whether they are big companies like Microsoft, Google and Amazon or small startups like del.icio.us, Bloglines or Flickr can poll all the potential users of their XML web services to figure out what XSD constructs their toolkits can handle and then design a schema that uses the intersection of these features.
The approach Aaron encourages may work if you are in a small company and are designing services that will be used by a few parties but doesn't really work if you are providing services on the Web or even at a large company where it is hard to get everyone who will be using the service in the same country let alone the same meeting room. The latter scenario is what likely happened in the
original mail to XML-DEV which sparked my blog post on Friday.
I should clarify that when I say 'code-first' development that this doesn't mean that there shouldn't be guidelines as to what types are exposed as XML Web Services. At work we've settled on using a small set of types within XML Web Services; System.Int32 and other numeric types, System.Double, System.String, System.DateTime, System.Boolean, various instances of System.Enum and arrays of System.Byte for base 64 encoded binary data. The only collection types we pass around are arrays. This maps to a very small subset of XSD and is reminiscent of the set of types supported in
XML-RPC.
With these guidelines our developers can build XML Web Service applications in a 'code first' manner yet have a high degree of confidence that the services we build will be interoperable across various toolkits. One doesn't have to be an expert (or even deeply knowledgeable) about complex technologies like XSD and WSDL to build XML Web Service applications in this manner. And quite frankly, I think it is a waste of our developer's time to make them experts at these technologies when it tangential to the bulk of the work their code has to do.