As Peter wrote in his answer to my last post in this category, there might be some questions in regards to what a "contract" is. I will devote my post to explain this, partly because I've got loads to do at the time being, as well as me being completely worn out.

But what is a contract?

In a SOA perspective you deal with a multitude of services that interact with eachother. Normally, as you might know from your occational open-source project, you would write a service endpoint in WSDL to describe your service. This is more or less a painfull job, and I don't blame you for hating it -- I hate it too.

As I have mentioned earlier, Microsoft has been decent enough to supply us developers with the WCF framework. This framework has a different approach to the WSDL part. Instead of writing the service straight forward and then adding the WSDL, you create an interface with some inline attributes to the interface and to the method declarations. These are [ServiceContract] and [OperationContract] respectively. These attributes has no immediate value for the developer (apart from to some degree show service method invokation flow). When you then host your service, you build a class that implements your servicecontract interface, and implements the methods that are prefixed with the OperationContract attribute. When you then run the service and point a browser to it's endpoint, the WSDL will be generated dynamically, and you don't have to write that. However, this is just a side-effect (i.e. feature) of the WCF.

ServiceContracts has one advantage that you and I cannot disagree on: When you have a service contract that any client relies on, you can update your code-behind (in respect to the service endpoint) without touching the servicecontract, and your v1.0 clients will still be compatible to the v1.2 service. This allows for seamless integration of emergency patches and backwards compability. Backwards compability requires another level of contracting, and I'll get to that now.

Just as you can specify a servicecontract to formalize what methods can be called, you would still want to formalize your data exchange. This is done with data contracts. You might be accustomed to creating export classes that are exposed through the service, and this where the data contracting comes into view.

When you create an export object, you can first define it's members and properties in an interface. This interface will of course be prefixed by the [DataContract] attribute, and it's properties (or public members if you will) will be prefixed with [DataMember]. When implementing this in the export object class, you are in short terms telling the client which data to keep and not to keep. Diving deeper into that matter might require it's own post, so I will urge you to perform a google search about it instead. Either way, you can also give these attributes some properties which defines if they are backwards compatible or not. This actually makes it possible to have a true and seamless backwards compability design in mind when building SOA networks. Messagecontracts is another kind of datacontract, but I'd prefer to leave that to another time being.

But I'm going to leave it with this. I did try Ruby on Rails the other day, and so far I have to admit it was a big yawn.