Posted by: Dilipkrishnan
The advantages of going with contract-first is certainly evident when it comes to interoperability. I remember reading an interesting article about the Contract-first vs Code-first debate a while ago. At the time it was published, I remember thinking to myself that both sides seem to have very valid points, but, Ted Neward, whom I have great regard for, an evangelist for interoperability, was dissing the idea of contract first. Why?
Now, After a couple of years effort in spearheading the contract-first approach to SOA, it behooves me to wonder about the practicality of such an endeavor, for a couple of reasons
- Change management is more intuitive for a code-first approach; and this may very well be just the tooling support around managing changes across schemas and services isn’t as mature.
- The development processes in most places today don’t know how to slot the task of managing contracts in the schema/wsdl form. Who is the person responsible for rationalizing and implementing the changes. Is there a formal process to do this? Can developers do this on their own, without thinking big picture?
In a homogeneous SOA environment its code-first is easily the more practical of the two (which is not to say it doesnt involve an equal amount of thought and architecting). That said, in my opinion, given a service interoperability scenario, there is no clearer winner than contract first. I say this on the strength of one fact. If one were to design code-first interfaces and have them generate the contracts; who is to say that the way the platform renders these contracts would not change in future versions of the platform. All of a sudden service consumers fail because the contract has changed implicitly!!!