Microsoft: We Need Contract-First Dev Tools

The little survey I did on how developers feel about contract-first development shows a resounding amount of support for the model. Almost everyone who responded believes in the benefits of contract-first but they expect better tools first. Comments indicated an understanding that contract-first would indeed improve interop. Colby Dyess statesz his opinon as follows:

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.

It's how we've always developed distributed apps: you define the interface (contract) first, then you go off and implement the classes on both sides of the wire (proxy/stub). This is how C++ DCOM developers always worked. However, Fumiaki Yoshimatsu draws an interesting comparison to the situation with DCOM in VB6. He tried to teach developers the benefits of starting with the interface definition first, and then implementing it in a VB6 class, but the lack of tool support made it impossible for him to make them believe. I think this is a great analogy to what will happen with Web services unless we get better tool support.

Don Box, an Indigo architect (whose blog doesn't support trackbacks), believes in contract-first (hurray!) although his definition of tool support is more liberal than mine.

So what do I want in terms of contract-first tool support?

Well, Christian Weyer's WsContractFirst VS.NET addin is a great start. It basically lets you right click on a WSDL file in VS.NET and select “Generate Web service code...“ (along with several other hand features). This is a good first step. However, this tool assumes that you have already the WSDL definition.

What's missing is a simple high-level XSD/WSDL contract designer that even the novice can use. The XSD editor in VS.NET doesn't cut it - and there is no WSDL editor today. This is essential. I also want some easy to use wizards/templates for the common use cases. I also need the ability to keep contract definitions synchronized with class definitions once generated. Combining such features with the basic functionality of Christian's tool (would go a long way towards enouraging contract-first. Without easy to use designers, I doubt it will happen.

Whitehorse seems to be making progress in this direction but they haven't gone far enough. They provide a designer that you can define Web services on and then generate class definitions. They do a good job of synchronizing the contract definition with the class definition. They also do a good job of generating a concrete class with all the right attributes (unlike wsdl.exe /server which requires copy-n-paste of the attributes to a derived concrete class). But they don't provide a good XSD/WSDL designer and I'm not holding my breath for Whidbey.

Besides Whitehorse related things, I've heard rumblings of at least one possible new Whidbey feature that would benefit contract-first development. It's not a visual designer but it's quite compelling. Stay tuned.

Colby indicates that his product (from Iona) already embraces contract-first development. I'm not sure what that means (maybe he can elaborate?). Nevertheless, I wouldn't be surprised if other vendors beat MS to the punch on this given their current direction with the tools. Another reader, Anil John, indicates how important this is to the government work he's doing, which requires interop between Axis, BEA, and MS tools:

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.

I agree. I think contract-first is more important to Microsoft's competitive advantage than they may realize. Developers want to develop this way. It's good for interop. But they need good visual tools.

Microsoft, if you're listening...please?

BTW, I'm going to be in Redmond next week and I plan to bend an ear or two. If anyone from MS would like to have a discussion on this, please let me know. I'd be happy to make myself available. If anyone outside of MS has more interesting data points, please post them here or send them along.