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.
Do you think it is an anti-pattern for an implementation of one service to depend on another service at all?
ReplyDeleteOr is it merely a question of tying the lifecycle of one service implementation to the lifecycle of another one?
Yours, Mike
Mike:
ReplyDeleteIn my opinion, one service depending upon another service is not an anti-pattern. The service doing this should hide this from the consumer though and not require the consumer to know anything about the dependent service.
Tying the life cycle of a service to the life cycle of the consumer is the anti-pattern of SOA. If a service cannot be re-purposed amongst other consumers or reused by the same consumer, it is the opposite of SOA.
Good, I think I'm understanding your viewpoint better. I would certainly agree that a service should not show its consumers anything about how it is constructed - it should only provide the service contract.
ReplyDeleteHowever, what about the concept of a service component? In other words, the bundle of code that actually implements a service. While a service consumer doesn't care about this, the programmer building the service might well care about this. And does the programmer need to think about the services that the service component consumes in order to provide its service(s)? How does this fit into your picture?
Yours, Mike.
Perhaps the term composition is in its original usage here - e.g. the marketing types saying this - not the UML heads.
ReplyDeleteTherefore it simply means the act of composing services (aka service composition) - and hence can be made up of whatever parts and components are required.
As ever, dumb trumps smart.
I fear you are trying to call back something that is already out of the bottle here.
Just making clear service composition as a term has nothing to do with that usage in object parlance may at least permit you to sleep better!?!
;-)
ReplyDeleteI have no realistic expectations that this blog post will change the use of the term "composition" in the mainstream but may impact a few of the wiser analysts, media.
I see service components as an important part of the service ecosystem and in no way conflicting with this post. The only topic this post refers to is the relationship.
To really add confusion - check out this description - that explicitly says that composite services are aggregations!
ReplyDeletehttp://www.soaglossary.com/service_composition.asp
So maybe you are both correct?!?
No - they are different. The owner of the SOA Glossary needs to update the entry.
ReplyDeleteDuane,
ReplyDeleteYou're assuming that UML is the ultimate source of truth. From the American Heritage Dictionary:
com·po·si·tion (kŏm'pə-zĭsh'ən)
noun:
The combining of distinct parts or elements to form a whole.
"Distinct parts" seems pretty clear to me that they exist outside the scope of the whole.
Anne
Anne:
ReplyDeleteTrue - I did use the terminology form UML, OO and Corba as the main source (the definitions are aligned). In terse english, composition is still defined as "making up" the whole (see your definition). Service do not make up the whole, they support the whole during its life cycle hence the distinction.
I will grant you that the english dictionary term does not address whether or not they can exist without the whole.
I have no expectations the terms will be changed in the future. We're already way to far down the road.
;-)
To ann - "distinct parts" does not necessarily mean they exist outside of the whole. "Distinct means they can be still identified as part of the whole much like parts of a car. composition is a made of relationship.
ReplyDeleteAnne:
ReplyDeleteIt is not just UML. Wikipedia (http://en.wikipedia.org/wiki/Composite_pattern) defines the design pattern of composition as follows:
1. Composite allows a group of objects to be treated in the same way as a single instance of an object.
DN: This is definitely an Anti-pattern of SOA as the concepts of clean decoupling of services from consumers seems to be a generally accepted principle of SOA design.
2. "[The Composition Pattern] defines Composite object (e.g. a shape) designed as a composition of one-or-more similar objects (other kinds of shapes/geometries), all exhibiting similar functionality. The Composite object then exposes properties and methods for child objects manipulation as if it were a simple object.
DN: This again seems to be an anti-pattern of SOA as services can exist without becoming "part" of the thing that uses them.
I note that some markup was messing up the document.
ReplyDeleteIt says (to the naked Eye)
Note this one is abstract of any stereotype such as <> or <> but these could be added.
but that <> and <> really says (assuming a curly brace had been used instead of angle brackets:
Note this one is abstract of any stereotype such as {{uses}} or {{composes}} but these could be added.
I hope this helps someone else make sense of the article