I feel like I should have titled this post “The Emperor has no clothes: Part 16” as I have seemingly made a career by challenging the status quo. This post may be a bit of a rant but make sure you read it before passing judgment.
The SOA community has once again used poor judgment in terms of coining titles for aspects of SOA, namely Service Composition and Composite Applications. If these are truly built on an SOA infrastructure, most of them are in fact Service Aggregations and Aggregate Applications. Let me explain where the terms come from and what they really mean.
Composition and Aggregation are both types of Binary Relationships. They are also both specializations of the “whole-part” pattern, a pattern in which a whole “thing” has parts. In both cases, the Whole (in this case the so called Composite Applications and Service Compositions) rely and cannot exist without the Part(s) (the services). There are very subtle yet concrete differences between how Composition and Aggregation work though. The main difference is that in aggregation, the parts can exist without the whole. Wikipedia discusses aggregation (http://en.wikipedia.org/wiki/Object_composition#Aggregation):
“Aggregation differs from ordinary composition in that it does not imply ownership. In composition, when the owning object is destroyed, so are the contained objects. In aggregation, this is not necessarily true”
Composition (as defined by UML) is a special type of relationship where the part and the whole are inextricably linked. In short, the Whole IS MADE UP OF one or more Parts. If the Whole does not exist, neither can the Parts and their life cycle is tied directly to the life cycle of the Whole. The UML composition relationship is depicted below.
Aggregation is a different animal. In an aggregate binary relationship, the Parts may exist without the Whole and be used by more than one “thing”. The Whole CANNOT BE MADE UP OF the Parts. The UML aggregation relationship is depicted below.
Aggregation is akin to how services are utilized within an SOA environment. Services are not contained within the service consumer, services are independent entities within an SOA environment and “consumed” by the consumer. Services can therefore exist without the consumer being present, the opposite of a composition binary relationship. In fact, both services and consumers are usually considered first class entities within an SOA environment as commonly depicted amongst the SOA community. The UML relationship can be depicted below. Note this one is abstract of any stereotype such as <
Given one of the core goals of SOA is the ability to “re-purpose” services amongst several consumers, it would be highly illogical (and an “anti-pattern” of SOA) to tie a service’s life cycle to one single consumer and to constrain that service to exist only within the consumer. That is in effect the pattern SOA strives to avoid. Note that once again, I have changed terms slightly. The term “re-purposed” has been used instead of “re-used”. Services that are re-used only by one consumer do not tend to offer huge advantages other than reducing dependencies and creating agility buy cleanly decoupling the consumer from the core functionality offered via the service.
Business Process Management (BPM), Service Aggregation and Aggregate Software Applications are all specialized types of service consumers. In all three cases they consume services but are not made out of services. The services exist without the consumer.
I am not confident that the industry will change but if you think this makes sense, please take a pledge to start at least making this distinction.
