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.

Tuesday, December 02, 2008

Think about the arrows

When doing architecture reviews. I'll often point at one of the arrows on the architecture diagram and ask "what is this?". Depressingly I often get an answer similar to " Well, component A talks to component B". Rarely do I get an answer will actually explains:


  • Why the components need to communicate
  • What information is communicated
  • What the arrow indicates (e.g. flow of information)
  • What component initiates the communication
  • How the information is represented
  • What protocols are used
  • What is physically used to transmit the information


In designing an software architecture I've always found it useful to think about what the arrowed lines actually mean as this often provides insights into how the design will actually behave. I was therefore happy to see that at least somebody else also thinks the same way and have submitted a software axiom ("Architects focus is on the boundaries and interfaces" by Einar Landre) to Richard Monson-Haefel's 97 Things. If you haven't come across this before, 97 Things is a set of "axioms for software architects by software architects" and should be published by O'Reilly next year.

Monday, December 01, 2008

Trough of disillusionment

Mr. Gartner had built a new roller coaster based on his, now famous, principles which ensured that every ride was indeed a heady experience which one would not easily forget. His previous rides, often simply named with combinations of letters, were indeed exhilarating experiences. I was eager to ride this one, famously called SOA, and was lucky enough to be now sitting in the front carriage, which was slowly taking me up the steep incline. As the carriage ascended I was able to take in the magnificent vista of the landscape lying below me, revealing a hitherto unknown complexity. But then, looking forward again, I realized I could not see the track in front of me. In fact I seemed to be poised on a great void. It was then that I realized that I was heading into the trough of disillusionment.