On Intermediation in SOA

Posted by Hartmut Wilms on May 21, 2007 03:01 PM

Community

SOA

Topics

Messaging

Tags

Service Design

Nick Malik writes about "The Value of Intermediation in SOA", which started an interesting discussion. In his first blog post on the subject he asked the question: "Is it Service Oriented if the message cannot be intermediated?".

Malik argues that one of the key benefits of any SOA is Intermediability, "the ability to intercept a message going from point A to point B, and react to that message without informing either end of that pipe". In his view intermediation goes hand in hand with Technology Independence, which requires "that I can replace system A with a system of an entirely different technology, and that does not affect system B, as long as the message is consistent".

According to Nick Malik "SOA in an architecture for Enterprise Application Integration". Intermediation supports integration by its substitutability principle. Malik explains this point by comparing the architectural intermediary to the factory pattern in object-orientated design and referring to the Liskov Substitution Principle:

The ability to add intermediation gives me some fairly specific advantages.  Just like factories give me the benefits of the Liskov Substitution Principle in OO design, intermediation gives me the benefits of substitution in messaging design. Intermediation is the ability to observe a message passing from one trading partner to another and to take action based on the contents of that message (assuming I have been given proper access to it).

Udi Dahan disagrees with Malik's EAI statement and his idea of orchestrating services via intermediation:

While I whole-heartedly agree with what Nick has to say in terms of OO intermediation of the Dependency Injection variety, and that scaling up those same concepts in terms of messaging is the right way to go, I take issue with orchestration in the intermediation area. These “tactical changes” need to be done in the context of the top, business-level service strategy. That means that all logic belongs within a service. The “network” between services is just that, a “dumb” network - no business logic of any kind, just technological capabilities like knowing which physical server to route messages to.

JohnCJ responds to the value of intermediation in the comments of Malik's blog entry and states that intermediation should not be seen as a general requirement for service-orientation. He argues that

1. "Requiring intermediation encourages messages to carry more contextual information."
2. "Intermediation greatly complicates any message exchange pattern other than request-response and pub-sub."
3. "Intermediation requires the intermediating system to understand at least some of the semantics of the messages it intercepts."

In a second entry on the Value of Intermediation Nick Malik addresses each of these points. He points out that contextual information does not bloat the message, but that "the necessary increase in size of a single message in order to represent the independent canonical business document that we will pass in an enterprise EAI scenario is a small price to pay to achieve business agility". Regarding the second argument Malik gives a very nice analogy of Joe the bank clerk, who hands his vacation request form to his boss and waits for an approval. His boss is one of many intermediaries on the way to the ultimate receiver of his request. Joe does not know nor care about any of these intermediaries. The only thing he cares for is the outcome, the final response to his request. The approval process might be altered at any step without changing the business semantics of the process. Thus Malik "would argue that nearly all valuable long running transactions MUST have the ability to intermediate in order to allow them to be composed, and recomposed, and orchestrated". Finally he argues that sharing the semantics of a message depends on the function of the intermediary. In any case he declares that point as a "risk. Not a cost.  It is a risk that occurs in any project.  In a well defined SOA infrastructure, the risk is Lower than if we were attempting to compose a manual business process by entering data in three different computer systems".

Nick Malik concludes that in his view intermediation is not a general requirement for all services, but that it "is a requirement of a service oriented architecture designed to deliver composability, and therefore, business agility".

• Older >