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.
Contract-first is the only way I know of to employ this type of process and it's the primary motivation for doing so. Code-first, on the other hand, is self-centered and discourages collaboration.
Obviously there are situations where you cannot collaborate with all your consumers ahead of time, but in many of the common enterprise integration scenarios you can. When you can't, one should definitely stick to a subset of XSD that will be most likely to work with as many possible consumers. These subsets, however, are just the documented best practices that came from the type of collaboration I described above.
I believe the other reason for the general disconnect is that vendors believe that developers don't want to work with anything but objects. They believe that developers don't want to author service contracts directly. They believe it's too hard. So instead of trying to make it easier through tools, they turn to objects instead. Ironically this is the reason for the impedance mismatch problems that cause so many of the interop problems to begin with. It's this general attitude that causes
many of us to "shake our heads in sorrow". I believe vendors got this wrong - there are many developers who would quickly embrace working this way if they were only given the proper tool support.
In fact, I believe this is one of the reasons BizTalk is starting to take off. BTS is the first MS technology that breaks the mold and doesn't try to hide XML messages behind an object facade. Instead they've tried to improve the XSD-driven developer experience through better tools and they've done a great job at it. BTS acknowledges that successful integration is built on these principles and contract-first, along with message-orientation in general, is the way to go. Contract design is step #1 in developing a BizTalk solution.
In the end, contract-first encourages and enhances XSD-focused collaboration, instead of the "let's just ignore it and hope it works" attitude which discourages it, and as a result, hurts interoperability.
Posted
Apr 25 2005, 06:30 PM
by
Aaron Skonnard