Applied SOA: Part 6–Service Composition

This is part of a series of blog post about Applied SOA. The past blog entries are:

• Introduction
• SOA Basics
• Service Discovery Process
• Service Taxonomy
• Interoperability

In this article, I’ll quickly cover service composition.

Service Composition is often stated as a goal of SOA.  I think it’s rather a consequence of a Service Oriented Architecture.  You first deploy building block-type of services.  Once those are running, you can start deploying higher order services reusing those building blocks.

As we’ve seen in the Service Taxonomy blog entry, a good service taxonomy helps you to structure service composition.  The one I presented, from soapatterns.org, has composition built-in.  Typically, a business processes compose many services.  An activity within a process might also compose a few more agnostic services.

Composition is good, it’s incarnated reuse, so we should want it everywhere, shouldn’t we?  Well, like with everything sweet, there’s a tension related to its usage.  In the case of composition, this tension is with isolation.  As we’ve seen in different SOA definitions, isolation is important.  Composition compromises isolation in many ways:

• It couples SLA:  the composing service is just as strong as its weakest link at any moment in time.
• It couples services time-wise:  composition increases latency but also require the composed service to be up-and-running.
• It also often couples service contracts if the composing service expose data from the composed services.  One way or the other, changes in the composed service will affect the composing service.

This tension is the reason why you won’t want to layer your services in many layers.  Doing so would result in weak SLA, long response time and high-maintenance.  If you do not layer at all, you’ll end up with duplicated logic.  As usual, patterns and judgement should help you balance your solution!