Service Composition (continued...)

In my last post we talked about service composition in SOA. Miguel posted a good question about whether composition in SOA is analogous with composition in Component Oriented Programming. This really got me to thinking about whether composition actually has any real meaning in SOA at all.

One of the key differences between components in Component Oriented Programming and services in SOA is that components must be instantiated. A client must instantiate a component before the component is used. Furthermore, multiple instances of a component can and usually do exist at the same time.

Composition makes a lot of sense in Component Oriented Programming because we have one or more child components supporting a parent component. Every new instance of the parent component contains new instances of the child components.

Without instancing, composition wouldn't really make a great deal of sense in Component Oriented Programming. Just because a component uses or references another component, doesn't make those components a composite. What makes a set of components a composite is the lifetime of the child components being indelibly tied to that of the parent component. The children are created with the parent and destroyed when the parent is destroyed. The children have no purpose other than to meet the needs of the parent.

SOA is a different ballgame however. There is only ever one and only one instance of every service. All services for all intents and purposes are always running (except for the odd moments of downtime) until those services are retired. So what is a composite in SOA terms? If I have a service A which consumes services B and C, is A a composite of B and C? I would say no. Otherwise all services in our enterprise would simply one big composite.

I would suggest that composition in SOA refers to the bringing together of lower level services in order to support one or more higher level services. It seems we need to have services at different levels in order for composition to make sense in SOA. So if services B and C are lower level services that form part of the implementation of service A, then I would say that services B and C have been composed to form service A.

As I mentioned in my last post, with all the hype around Layered Service Models, where lower level services (like task and entity services) are composed to form higher level process services, we see service composition taking centre stage in SOA discussions far more than it really should.

As I've previously discussed, the type of reuse central to Layered Service Models (functional reuse as opposed to reuse of events) doesn't really work very well in practice. Functions exposed at the service level generally are too coarsely grained to be reused in different contexts. As such, the notion of having a registry of lower level services that can be composed together in support of higher level services is somewhat flawed.

We may have lower level services such as integration services, UI services or B2B services that support a higher level business service, but those lower level services should not be reused between the higher level services. As such, in this case the service composition is really just an implementation detail of the higher level services and as such not really architecturally noteworthy.

So I say again, service composition in SOA is only really a noteworthy concept if you're pursuing a Layered Service Model which as I've said before is not ideal.