Services as contract

Recently we had a visit from Bertrand Meyer (Eiffel fame). He mentioned how Eiffel langugae helps make contract explicit between user and supplier. He also elaborated in what all different ways the contract definition can be used. (One of the interesting uses he showed was that of 'push button' testing). When I asked him that how does the language discover the contradictions in contract specification, he said "It does not". Which was kind of disappointing, a wrong contract specification, howevere faithfully implemented by the implementor, is no good.

This incidentally is the point I made in one of my earlier posts. Not only, one must make the contract explicit, as most SOA proponents are proposing, but also we must have ability to discover contradictions in the contract specification. We must have ability to see, if multiple contracts can co-exist and satisfy some common properties. It is not easy. However this is an important aspect of contract specification and must be addressed. The service definition should define how the compatibility would be established between various services (which essentially are contracts) and governance must ensure that this continues to be the case. Such defintion time checks, will help prevent costly budget and time overruns not to mention prevention of service proliferation and governance nightmare.