It seems there is still some confusion out there as to what a “Service” means in the context of Service Oriented Architecture. Just recently I came across a discussion where “service” is being communicated as just a simple web services interface. That is why I thought of sharing here the definition I used in a presentation about SOA over a year ago. I used some concepts from OASIS SOA Reference Model and added other aspects of service that I think are important. The diagram below shows the anatomy of SOA service – what it really means when we say “Service” in the context of SOA. The usual common picture people use to communicate SOA based service is by using the triangle that shows service provider, service consumer and service broker or registry. What is more important and most of the time not clearly explained is the other view of the same triangle I overlay in the diagram below. That is, service has a description, service has implementation and service is governed. 

Service Anatomy - What Service means in SOA

In short, the following aspects of “service” are implied or need to be considered when one speaks of service in SOA:

• The usual high level view
  • Service has provider
  • Service has consumer
  • Service has a registry
• The other view which is more important is:
  • Service has description. This includes tasks that the provider has to worry about to meet the consumer need and how service can be used by the consumer (for the definition of these terms please refer to OASIS model linked above):
    • Contract
    • Interface
    • Reachability
    • Metrics
    • Functionality
  • Service has implementation. This includes tasks that the provider has to worry about to meet the consumer expectation of the capability of the service :
    • Design (you know how this is important too -:))
    • Code (you know … this is where the meat is -:))
    • Test (yeah.. you think this is not important? In most of the cases this is where the money is spent – cost. You must deal with on the strategy on how to test SOA services)
    • Package (yeah… you think this is not important? Think again… this is related to service versioning, migration, change management etc.. issues. You better have a good strategy on how to package the services implementation before they get deployed)
    • Deploy (considerations of performance, scalability, availability, and other operational needs)
    • Secured (this is missing from my previous diagram – but i think it is important aspect that must be considered)
    • Monitor (why? you must capture some metrics to evaluate if the service is of value to the business as expected. This metrics comes from the top level business service design because that is where they identified as important factors to capture for business use (mostly referred to as KPI). There are also operational metrics that are collected to meet operational requirements – e.g. capacity planning, trouble-shooting, etc…)
  • Service is governed. This includes tasks that the Enterprise Architecture has to worry about:
    • Standards (i.e. service may have to be compliant with some industry standards. Those standards are best specified by enterprise architecture)
    • Guidelines (i.e. enterprise architecture should have SOA principles from which some measurable guidelines can be derived. Services need to be compliant with these guidelines, otherwise the principle is considered not applied)
    • Compliance assessments (i.e. services should be assessed against the specified standards, guidelines or principles for compliance by the governance team)
    • Exceptions management (i.e. it is a reality that a given standrd or guideline may not be followed in under some circumstances. For example the cost of implementing the guideline or standard may not be justified at the moment; and as a result a non-standard approach may be used to implement the same capability required by the business. This is about weighing the pros and cons of such a decision and if allowed then the governance team need to manage that exception. The exception is normally temporary. However there are cases where the exceptions reveal a defect in the principles or architecture itself.  This is mostly the case if too many exception is granted as a result of violation of a given standard or guideline. In such situations, the architecture or principle need to be reviewed and the broken guideline need to be updated accordingly.)

 In the above discussion, I did not mention where the service we talked about came from – I mean its granularity, usefulness from business needs perspective, etc. I assumed that a “service” we talk about here is based on top level service architecture as a part of enterprise architecture. See my discussion on Service Oriented Enterprise Architecture Framework which puts the “SOA service” discussed here in a bigger context.

From end-to-end perspective, I think when we say “service” in the context of SOA, we need to understand the above aspects of a SOA service – its complete anatomy.

Awel Dico