Contract First Development
Aaron Skonnard, a proponent of contract first development, recently posted on the disconnect between what the vendors are doing and what developers want. He makes the claim that vendors don’t see the value of the contract-first approach. On this statement, I disagree. I don’t think the problem is that the vendors don’t see the virtues of it, I think it’s more the case that it is such a conceptual shift, that it’s a very difficult problem to solve when catering to an audience of C#, VB.NET, or Java coders. This is further justified by the fact that tools like BizTalk, as he mentions, make it so easy to do contract first development. The key is that BizTalk and most tools that fall into the Business Process Orchestration space are designed from the ground up for schema-oriented development. This makes working with XML messages and XSD much more natural. C# and Java are clearly for object-oriented development, so there’s a natural disconnect. There needs to be a bridge between the two worlds, and unfortunately, it began with an effort around traditional RPC mechanisms and as a result, wound up with hard, restrictive bindings between XSD and a C# or Java class. In my opinion, the toolsets need to bring some schema-oriented approaches to the tool sets for C# and Java. This usually involves code generation, and tools that do this have had a hard time gaining adoption. It also brings up memories of the whole object-relational mapping space, so the vendors are proceeding with caution. I expect that in 5 years we still won’t see advances in this area, but we’ll see the majority of services built using tools like BizTalk. For services that still need to be written in Java or C#, the developer will still have to deal with things using a DOM object, just as a database developer still often works with a RowSet. These will be relegated to more complex operations where low-level DOM access is a requirement.