We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

Business Ecology Initiative & Service-Oriented Solution

Michael Poulin

Evolution of principles of Service Orientation, part 1

Vote 0 Votes

Recently published book SOA Design Patterns by Thomas Erl has encouraged me to look into principles of Service Orientation. What I have found is a delicate evolutionally shift in wording and meaning of some principles. I think this is a great evidence of survival ability of Service Orientation. The shift happened sometime between 2007 and 2008 when Principles of Service Orientation (SO) transformed into Service-Orientation Design Principles. Following Thomas' books and the ServiceOrientation.org, I list the principles along time line for you to compare:

In 2006:

• services share a formal contract
• services are loosely coupled
• services abstract underlying logic
• services are composable
• services are reusable
• services are autonomous
• services are stateless
• services are discoverable

In 2008:
• Standardized Service Contracts
• Service Loose Coupling
• Service Abstraction
• Service Reusability
• Service Autonomy
• Service Statelessness
• Service Discoverability
• Service Composability

As we know, 'the devil is in details', and I decided to look into the changes of the meaning of these principles. This is especially interesting because SOA has walked difficult way and crossed IT boundaries for last few years. However, before digging into separate principles, I have noticed a motivating word 'Design' in new collective title of the principles.

My understanding of this phenomenon is quite subjective but, I believe, here is something that deserves attention. Simple logical interpretation of appearance of the word 'Design' leads to conclusion that SO principles are not necessarily the same thing as SO Design principles. At the level of speculation, I can also conclude that now we cannot say whether the entity is service oriented based on its appearance if we do not know if it was designed according to the service orientation principles. I find this a bit odd.

The real concern is about potential mismatch between SO design principles and principles of SO concept. Presence of design element converts the concept into the tool, which is practical. But are we sure we have not altered the concept when placed it into the tool-box?

(to be continued)
Thumbnail image for Speaking_Qcon_London_03.jpg

Leave a comment

In this blog, Michael Poulin writes about business and technology ideas, concepts, methodologies and solutions leading to service-oriented enterprise, the primary instrument for obtaining business objectives in fast-changing environments.

Michael Poulin

Michael Poulin is an enterprise-level solution architect working in the financial industry in the U.K. and the United States.

He specializes in building bridges between business needs and technology capabilities with emphasis on business and technical efficiency, scalability, robustness and manageability. He writes about service orientation, application security and use of modern technologies for solving business problems. He contributes to OASIS SOA standards as an independent member and is listed in the the international "Who's Who of Information Technology" for 2001. View more


 Subscribe in a reader

Recently Commented On


Monthly Archives