Contract First Vs Code First

Contact-first is one of design principles for achieving SOA. I came across an informative discussion on Contract First Vs Code First web service

http://tssblog.blogs.techtarget.com/2007/04/11/contract-first-or-code-first-design-part-1/

Discussion is structured around following 4 arguments for using Contract first

• Code-first interfaces may not be well suite for the demands of remote traffic.


• Implementation code typically changes at a faster rate than the interface.


• Generated WSDL leads to interface bloat and duplicated and incompatible type definition.


• Code-first doesn’t work in a multi-lingual development organization.

After being enriched by this discussion, here is my take on the these points

Code-first interfaces many not be well suited for demands of remote traffic.

Web Service interface should not contain chatty methods. Number of  method calls invoked during conversation needs to be limited for performance reasons. It does not mater whether you use Contract-first or Code-first approach, as a web service interface designer you need to keep number of method calls to minimum. In code first  approach WSDL is  auto generated, however web service interface is your decision. On the Contract-first side as well you could end up with chatty web service, it is you who has to design the WSDL.

Implementation code typically changes at a faster rate than the interface.

If interface is remaining same and implementation is changing, one approach is not necessarily better than other. Changes could made to back-end without changing the interface.  Implementer of Code-first needs to be careful when changing the implementation not to inadvertently affect the generated WSDL by exposing extra methods.

If interface is varying, then the comparison comes into picture what does it involve

In Contract-first approach, interface changes requires collaboration on interface , data type change amongst  development personal from multiple applications.  Possibilities of  contention are lot more when you change schema type definitions common to multiple application. Multiple applications have to conform to same Schema type definition, which in itself could be limiting due to tight coupling.  Let say CRM application requires changes to representation of Address/Contact, now rest of the applications that have Address/Contact domain model associated with common Address/Contact schema type  has to be change and redeployed whether they want CRM address/contact  change to be reflected in their application or not. On the flip side if we were to use code first approach only the applications that have something to do with CRM Address/Contact have to be changed. Change in Contract-first is much more involved and impact is lot larger than code-first approach. Down side of code first approach is that the representation are different across the applications and mapping code for common fields in Address/Contact need to be maintained.  As times goes by, Address/Contact representations across the application will grow further apart due to number of changes over the years. It is will get harder to maintain the mappings code.

I would go with code-first approach in terms of time/efforts/resources required to make a change.  Changes to mapping code/new representation could still be communicated to other application groups and put on their to-do list, as opposed to expecting them to drop everything and comply with super urgent change for your application.

If you can pull off the alignment of development resources and the collaboration needed to do Contract-first approach, contract-first approach is better and will keep data type uniform across the systems.  Can you do it over a prolonged period ?

Generated WSDL leads to interface bloat and duplicated and incompatible type definition.

This point again depends on skills of code-first interface designer, a well designed interface won't generate bloated WSDL. Duplicate and Incompatible data type goes back to 2nd argument discussed earlier. The time and resources required to collaborate over common data type/data type reuse will be lot more over the years.

Code-first doesn’t work in a multi-lingual development organization.

If the language provide auto-generation tools, why not.