SOA Service Contract in ArchiMate

I have recently been doing allot of service solution modeling using ArchiMate as a result I have been exploring at how to model some of the common SOA concepts. One of the things I have needed to represent but not model in detail has been a service contract. So I thought I would give it a shot with a dummy inventory service.

The first thing I look at is the Service Capabilities. These I model as Requirement elements as then I can model the linkage back to business goals, stakeholders, drivers, principles etc. For this version I have created 3 prospective capabilities:

1. Search current inventory for stock
2. View Product detail
3. View Products commonly purchased with a given Product

So the proposal is to group these 3 capabilities together so that consuming systems only need the one interface.

Figure 1 - Service Contract

Here the Contract object in ArchiMate is used to represent a Service Contract. In the same way a Contract can be used to specify policies and rules for products here it is used to specify the capabilities that are to be realised by the service. The most useful aspect of using a tool that supports ArchiMate is that this view itself can be the contract. For instance in Archi it allows for the documentation of the View which can be named the Product Inventory Service Contract. Each element can detail the specific SLA, NFRs and basic functionality description. If you are working in an Agile environment you can quickly update the current state of the designs and requirements and reference capabilities to stories in Motivation views. This is something I will be going into in more detail in further posts.

We have also identified our basic information architectecture by showing the business objects the capabilities are associated with. We now have enough information to determine how agnostic our service is going to need to be.

The next step is to model the realisation relationships of the service contract. First I model the Contract as a descriptive data object, in this case a WSDL object. Then the behavioral elements that realise the capabilities.

Figure 2 - Service Contract and Capability realisation

The behavioral elements are assigned to an Interface which is the equivalent of a portType in WSDL 1.1 or Interface in WSDL 2.0. In this situation the capabilities and behaviors can be mapped to operations one for one but that may not always be the case. An alternative view can be presented with a single behaviour for the port type and the capabilities linked into it.

Figure 3 - Alternative Service Contract and Capability realisation

This view is simpler and though the operation names are lost, the capabilities are still mapped and the relationships are still clear. I have used both formats depending on my audience and how much detail I need to express. At times I have also shown behaviours within behaviours to show a Service->operation level relationship, but it begins to get very messy at that point and I don't recommend it. The operation level link to the interfaces can be useful especially when you want to show a WebSerivce implementing a behaviour and that same behaviour also exposed on an RMI interface.


A quick mapping of our data model to show the realisation from business objects to data objects results in:

Figure 4 - Data Model Realisation 

This is then aligned with the current service candidate:

Figure 5  - Service Candidate

We now have our service candidate. We can see how the service contract description is accessed by the interface and the data accessed by the different operations.

The next and final step to be shown here for the service contract is the technology layer. The goal now is to express the assets for the contract and the infrastructure interface and behaviour.

Figure 6 - Technology layer of the contract

The first thing to notice is the data has shifted from the right to the left hand side. Here I am showing the data defined by the XSD and the XSD imported into the WSDL file. The binding interface accesses the wsdl file. The behaviour element is not accessing any data objects as I have not modeled how the data is to be retrieved, this view is purely showing the contract for the service.

The major benefits I find with this is once you start to build up your library of capabilities you can very quickly trace through to find reusable services for new compositions and also navigate based on the Information Architecture of your business objects for applications and services.