Great quotes on Contract-driven (aka Contract-First) Development...

I was trying to get a pulse on Contract-driven Development and what the industry was saying, so I compiled a list of quotes and links.

As I think this might be useful for anyone interested in the area, I thought I'd share this out. Let me know what you think and if you have anything more to add about "Contract-driven" development that is not captured below.

I've also learnt that Christian Weyer recently published a new version of WSCF that works on VS2005. (



Relevant Quote Link
The trouble is this promotes a very code-first approach. This really sucks from a BizTalk developer's point of view. I already have my schemas. I know the shape of the messages I want to receive. Where's the support for the Schema- and WSDL-first approach?
If contract-first means wrestling with the nine-headed monstrosity known as Hydra, er, I mean, XSD, then it's doomed to failure...But the "everyone just wants to write classes" meme is WRONG (yes, I'm shouting) and the teams at Microsoft that believe it are doing a great disservice to their customers by crippling the toolset... I don’t know if they believe we (the great unwashed masses of programmers) are just too lazy, too stupid, or too ignorant to handle message-oriented programming, but they clearly don’t think we can handle it...I’ll believe Microsoft is serious about SO when the “Whitehorse” tools include a GUI facility for building messages (not classes!) and that tool generates schema and compileable code that can be tweaked by developers...
Let's face it, big SOA / integration projects like Government, Inusrance, Pharma (the list goes on) starts with massive pre-defined schemas and large numbers of non MS systems. WSDL is defined based on those schemas and then a contract is implemented as client or server using .Net or whatever.
Contract-First Development doesn't go far enough. The CBDI Forum advocates an extended version of Design by Contract, including Pre/Post Conditions, QoS and Commercial Contract ...
I design my contracts using the built in XML and XML Schema editor's, but ultimately end up stiching the WSDL file together by hand.
Its this ability to have reusably defined types and easily assemble them into XML document definitions that we're looking for. Also, it would be great to have software that let you "harvest" the types present in XML document schemas and WSDLs to encourage type reuse, or for better searching amidst a sea of interface definitions.
Now, as a software developer, one's sole interest in contract-first development should be in defining the inputs and outputs of one’s software, and in ensuring that, if necessary, those inputs and outputs can be represented in a platform-independent format...The XML becomes a fetish, falsely imbued with the true virtues of contract-first development.
This morning I had the simplest class, marked Serializable, and ran it through an XmlSerializer test just to "be sure". Little booger started throwing those weirdo XmlSerializer exceptions. They are so hard to understand, even if you look at the InnerException, its enough to make you go stark, raving mad. Finally, I thought, "How about doing it backwards?" In other words, Let's write the XSD Schema and be happy with it. Then, we just fire up XSDObjectGen and let the tool generate the class, right?Well, it serialized perfectly right out of the box. I had gotten a property assignment wrong (mistakenly assigned to the public field instead of the private one in the ctor).
Interface constraints or restrictions cannot be expressed exactly enough using programming languages. For example: "enumerations of concrete values" or "date vs time" etc. Interface very often contains only subset of the internal domain data, maybe even transformed, often restricted. A separate layer of mapping is usually anyway requred.
The problem here is WSDL itself: it’s an arcane, obtuse vocabulary that isn’t very human-readable. I don’t think it does a good job of describing web services in the same way that people actually think about them. The problem here is WSDL itself: it’s an arcane, obtuse vocabulary that isn’t very human-readable. I don’t think it does a good job of describing web services in the same way that people actually think about them,guid,efd237dd-029b-4e51-91e4-711a8660c7c8.aspx
The insurance industry has two standards Origo and Accord. Both contain vast schemas detailing all the industry types and even message flows. Therefore the design of an SOA system will include message design and then the WSDL. The WSDL will define services based on these pre-defined types from these schema (such as a "policy" or a "customer" etc.). Once the WSDL has been built all the different parties involved can begin developing simultaneously against the contract in .Net or Java or KSH scripts and PERL if you like.If you tried to do this the other way around you'd be in a world of pain...minOccurs and maxOccurs just can't be represented using the code first approach. There's a huge impedance mismatch between .NET and Xml Schema.
I previously expressed my preference for the term Design-by-Contract, since this term is strongly associated with a broader notion of Contract including preconditions and postconditions. Even traditional Design-by-Contract doesn't include some of the non-functional obligations expressed in a service contract, such as Service Level Agreements, Security Policy and Commercial Terms, which are essential for distributed computing and SOA.
WSDL is even more tragic. XSD’s ugliness mostly hides in the plumbing where civilians don’t have to go near it, but WSDL is in the customer’s face; as Nelson Minar of Google once told me, “The WSDL should be the .h file for my Web-services application.” Indeed, but WSDL as it stands is not something that wins friends and influences people. Even if it’s too late for WS-* to untwine itself from XSD, maybe there’s still a hope for finding a better way to publish service interfaces?