Todd Biske: Outside the Box

I was just reading this on MSDN. The author defines a contract as follows:
        •        A contract is everything about the behavior of the service that is engraved in code. They are drawn up at design time.
        •        Policies are everything that can be changed without coding. They are typically detailed later in the process and they are easier to change.

I agree with everything said here, except the use of the term contract. When I’ve heard discussions about service contracts, it goes beyond the functional interface as this article implies. Service contracts are by nature, defined not just by the functional aspects, but the non-functional aspects as well. Think about legal contracts in the real world. They not only say what is going to be done, but they say how it will be done, what the stipulations are if something is done incorrectly, etc. Applying that to system interaction, my tendency would be to rephrase the above definition as follows:
        •        The interface is everything about the behavior of the service that is engraved in code. They are drawn up at design time.
        •        Policies are everything that can be changed without coding. They are typically detailed later in the process and they are easier to change.
        •        The sum of the interface and the policies that dictate its usage constitute the service contract between a service consumer and a service provider.

All of this aside, this is a very good article detailing the importance of the interface, and the challenges associated with taking either a schema first approach or a code first approach to service creation. While I may not agree with his use of the term contract, I do agree with the fundamentals of the discussion.