Contract-first: do you believe?

Aaron

What is wrong with this?
http://www.thinktecture.com/resources/software/wscontractfirst/default.html

Nothing. It's great!

Christian has done outstanding work in this area and I congratulate him for it. But unless MS deeply embraces it, developers are not likely to have much confidence in the model. And therefore, they're not likely to use it.

I remember the old VB6 era, when I encouraged my students to use "interface first" programming with VB, with publicnotcreatable and implements and square blackets and all. I failed to make them believe it was the right way to do their daily tasks. With that experience alone, I would demand better tool support first. Better tool support is the reason why MS is so successful with C#/.NET. If Java folks still have VJ++, things would be much different.

If contract-first means wrestling with the nine-headed monstrosity known as Hydra, er, I mean, XSD, then it's doomed to failure. Let's face it, when Tim Ewald thinks something is too complex and convoluted, the chances of the average corporate developer mastering it are approximately zero. 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’m convinced that the folks who say that are really thinking “Everyone should write classes”. 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. Look at all the effort Microsoft has put into hiding the messaging aspects of SO and web services. The whole XmlSerializer approach is just mystifying to me. Why on earth would they have created a system that deliberately prevents the developer from seeing the code that is used to transform class instance data into the message on the wire? If you look closely under the covers (peeling back all the obfuscating layers they built), you can see that those generated assemblies could easily be created at design-time and the system would be simpler, more robust, and far more transparent. Instead, if we’re interested in the format of the messages our services use, we’re forced to monkey around with the attributes that drive their black box approach and then view the existing output. The situation gets marginally better in Whidbey and then Indigo, but they are still clearly committed to the notion that messaging is for “plumbers”. 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.

I'm pretty much sold on the idea of contract-first and if it will improve interop, I will embrace it. Here's the tough question: "Will you do it even if you have to fight against the tools today or would you demand better tool support first?" I'd like to sound heroic about it and say yes, but the answer is: probably not. I'm in the same mindset as John and Fumiaki regarding tool support - Whitehorse is a good start, but I probably wouldn't want to rely on addins such as WsContractFirst.

I believe.. because I don’t have any other choice. A majority of the web service work that I do right now deals with Interop with non-Microsoft webservice stacks such as Apache Axis and BEA in the US Government sector. The siren call of RPC based webservices is very seductive in this space … and is really not conducive to interop.

If Microsoft wants to play with any seriousness in this space (especially given that with the huge US Gov Net-Centric Initiatives, web services are the primary choice of interop technology going forward) having this capability in the tools becomes a competitive advantage for a vendor.

The May 2005 VS Preview actually made the "fighting the tools" problem worse. ASP.NET projects have code-behind semantics setup by default. But if you are creating web services with no UI, what's the code actually behind? Anyway, a few of us made some noise on the feedback newsgroups and maybe it's better now.

The Whitehorse demos are great. But if you are an ISV or an integrater that wants to deliver your work with Whitehorse metadata, you are out of luck. AFAIK, there is no way to package the Whitehorse deployment constraints/rules. You have to compile the project onsite. The Indigo guys advocate ASMX as the best WS tech choice today, and that apps written on ASMX can run completely within MS hosting stacks. You would think Whitehorse could close the loop and give you a great deployment and tuning capability.

I haven't seen much of Microsoft Business Framework yet, but the bits so far steer WAY clear of contract-first development. But there is time to perhaps work on that.

The good news is that I keep hearing more people within Microsoft advocating contract-first. I'm hoping this leads the way for getting onto working out the XSD versioning and extensibility issues that you run into once you really embrace contract-first.

Aaron asks if we believe in Contract-First. I sure do. BUT, he nailed it right on the head: It's very...

We're using webservices as a "better DCOM" - we expect/require both the client and server to be C#/.NET. Given that, there's not as much motivation do do "contract first", since interoperabitliy isn't a big deal.

1) Lots.
2) Yes.
3) Yes.

Our customers are using contract-first development practices today to build services and clients that play in their heterogeneous environments. In fact project architects require that development be based on the Contract, rather than specific or proprietary Object technologies. At least one reason why "contract-first" development is gaining momentum is because it allows engineers to choose the language/technology of their choice for whichever platform they happen to be on. By starting with the contract developers are (almost) assured that their applications will seamlessly communicate with others in the SOA space.

There's still much work to be done in both the tooling (VS for instance, needs to allow more WSDL control) and in the implementation of standards. Hopefully discussions like this will help empower vendors to embrace the contract-first model. Meanwhile organizations such as the WS-I are helping to bridge the gaps in standards implementations.

Oh and
1) yes
2) yes
3) yes...but my product is doing this already. ;-)

Recent blog entries from Don Box and Aaron Skonnard ask the question about contract-first development for Web services. This is not a new concept, of course. CORBA was designed around the concept of an interface language separated from its implementation. Before that, DCE included an interface language, as did COM. And even before all of that, ACMS from Digital included an interface language, as did the Structured Transaction Definition Language specification based upon it. In Web services this idea has been somewhat controversial, since SOAP was defined before WSDL, and is often used without WSDL in practice. Also, we have the REST crowd who argues that XML over HTTP is sufficient for everything. The big deal in all of this is transport independence. But what does that really mean? Allowing SOAP messages to flow over multiple transports? Or the ability to send the same SOAP message over multiple different transports?...

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 ...

This is an issue for orchestration (BPEL etc) as well as basic web services ...

YES YES and I always use this approach despite the pain.

It is almost as if MS don't really believe in their Enterprise development promise. This often hinders our ability to have .Net taken seriously. We are not all just developing small green field applications where code-first manages to get away with it.

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.

On these projects you realise just how much more switched on the "other" vendors are. When BEA ship WSDL2Java and ServiceGen they also ship "ant" tools that wrap them up. Not only do they nicely support your contract first approach but they know you'll be working on a large project and will want to integrate these tools into your monster build process - not your little Ctrl+Shif+B.

Yes, yes and yes ...

...however this may prove difficult in practice until Mort understands Contract-first, has simple tools to help him and sees the benefits.

I also believe many developers have this hang-up where they measure their productivity by the number of line of code they generate each day. Therefore anything that gets in between them and writing code is considered being unproductive.

How do we get them to take time out to design their contracts before writing their code?

I guess xsd.exe will generate lots of lines of code which they can add to their line count!

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

Relevant Quote
Link

The trouble is this promotes a very code-first approach. This really...