Friday, December 05, 2008

The Pentagon Model of Service Contracts

Many have stressed the importance of an service contract model in specifying services in an SOA. But what should a service contract contain and what is its structure?

One model I have been using is what I call the the "Pentagon Model". No, this does not have any thing to do with the US Department of Defence, but comes from the broad shape of the relationships between parts of the contract (see the diagram).


The model starts with the premise that any contract is between a consumer and provider and is not directly associated with the thing that is the subject of the contract. Secondly the subject of the contract is the service operation rather than the whole service.

Let's illustrate this with an example. If you were implementing a CRM service then this may have operations such GetCustomer, FindCustomer. It stands to reason that each of these operations has a different contract due to the different interface and that they may well have different SLAs (searching for a customer probably takes longer that just returning one specified by a key value). However you may want to specify different SLAs for the service operations when they are called from the corporate network than when called over a mobile phone connection by a mobile sales force. Most definitely the security policies would be different in each case.

Changing the consumer is one thing, but why also have the contract depending on the provider? Well, you may have a number of providers for the same service interface. For example, the CRM service in Europe may have different response times and access policies associated with it than when accessing the same service interface, but using the CRM provider in the US branch. This is even more important when accessing sensitive information that may be subject to the laws of different jurisdictions.

This model is, of course, a simplification of a complete service contracts model. It starts to get complex when you have to model the policy structure and also have to take into the account that providers can be consumers. But it provides a simple framework to start thinking about service contracts.

No comments: