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.

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.

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.

BPMN Again

I've posted in the past about trying to find good online introductions to BPMN. Recently Bruce Silver has released some excellent e-learning material on SAP's Business Process Expert community site (registration is required).

Bruce uses some as yet unreleased software to diagram the BPMN examples he uses. I've taken the cheap route in the past and have been using some of the free Visio stencils I mentioned in the last post. Recently though I've been using a elegant stencil from Orbus software. Unfortunately it doesn't cover all of the features (e.g. catching and throwing events) and symbols in version 1.1 of BPMN.

Application Servers - The Next Generation?

I recently came across this in an InfoQ post (my highlighting):

Paremus recently released version 1.2 of Infiniflow, a next-generation distributed application server based on OSGi and SCA.

What is interesting is the tacit acceptance that there is now a "next generation" of application servers.

SOA in Cloud Cuckoo Land

There seems to be a general feeling that SOA services will somehow just exist out there in a cloud. The nitty gritty of their implementation, of who is actually responsible for them and how they are managed is hidden behind the service interface and the consumer doesn't have to worry about it.

If you had that point of view and you'd been using Amazon's S3 services you would have been hit when the S3 service went down last week. If you boil down Amazon's explanation to it's essence it seems that the number of "consumers" increased unexpectedly and overloaded the security system. Now Amazon's up-time statistics are maybe very good, but systems still go down.

Now say that you're implementing a SOA in your company. The services provided are going to be mission critical (just like your applications are). But one day, they will go down. And when they do you better make sure that you know who is responsible for them, what the implementation is so that you can fix things and that the management is so set up that the right people are brought to the problem as soon as possible (and while you're at make sure that you've defined the SLAs for the services, governance processes are in place to ensure that usage profiles are known in advance and that the services are monitored so that you can spot possible problems before they become serious).