Business Ecology Initiative & Service-Oriented Solution

Michael Poulin

Why We Don't Recommend WS-CDL for SOA and What Is the Alternative

Vote 0 Votes

Recently, I presented my work at the 7th European Conference on Modelling Foundations and Applications, ECMFA 2011, and I'd like to share the essence of my presentation with those who were not there.

As we know, to stand a chance at adequately responding to changes in the external environment, an enterprise has to deliver flexible business functionality. This flexibility may be gained via dynamic re-combinations of collaborating services. The power and business value of service orientation (and related architecture) is in the combination and re-combination of the services used to solve business problems.

In combinations, services have to collaborate in order to fulfil a common goal at:

• Logical / functional level
• Physical / message exchange level
Service Collaboration Patterns are valuable at both levels. However, to be effective, service collaboration patterns, have to provide for easy re-combination of services while preserving service independence and self-sufficiency. This relates to solving both intra- and inter-enterprise business problems.

A number of problems appear when message exchange starts to prevail the functionality, i.e. the message exchange overshadows the purpose of the services and reasons for combinations. Collaboration Patterns have to resolve this problem. The most popular collaboration patterns are Orchestration and Choreography. Since many do not share one common definition of the latter, we will use choreography as it is defined in the WS-CDL recommendation. So, the Orchestration Collaboration Pattern procreates service combinations based on the answers to the questions WHAT to do and WHY while the Choreography Collaboration Pattern focuses on HOW the interactions between services should happen.

From this point going further, we will discuss the part of the WS-CDL, which tries to make a "global contract" out of a structure of interactions between multiple services.
OASIS Reference Architecture Foundation for SOA standard-draft states that services interact because they need to, want to, and able to. Particularly, a service becomes of interest to a consumer because of offered functionality and Real World Effect rather than because of the mechanics of its interface and related message exchange.

When WS-CDL justifies the need for the "global contract", which scripts all interactions between all participants in certain order, it referred to the independence of the businesses (or services) that do not accept a central conductor, i.e. existing Orchestration Pattern is not suitable in the WS-CDL opinion. Also, WS-CDL outlines that the participants of the WS-CDL's "global contract" agree to participate and follow agreed sequence of interactions. Unfortunately, the agreement is just an agreement, it is not a guarantee. Recall, for the services to interact (and a business is a service to the consumers of the business products) all three conditions have to be in place - interest, willingness and ability. Now, imagine that a financial regulator has issued new policy and businesses should be compliant; if not compliant, they have to pay fines and these may be millions of dollars.

Do you think the businesses are interested in this regulation or do they want to invest a couple of millions into the compliance that does not bring them a penny? Well, they certainly can implement the compliance procedures but is it enough to rely on the business' good behaviour? What if a business simply cannot perform its agreed actions because of the lack of resources at the moment when the agreed message has arrived? What if such message does not arrive at all because another participant failed to perform its actions due to any reasons? And the last one, what happens with the whole "global contract" is several participants fail to perform as agreed at the same time (and there is no one here who is responsible for overall outcome of the collective collaboration/choreography)? If you think that these are all my fantasies, just recall what happened with the choreography-based emergency plan when the hurricane Katrina hit New Orleans ...

Even if participants willingly agreed with the choreography "global contract", this does not mean that this willingness lasts forever. So, to make the "global contract" more realistic, it has to be accompanied by the "rainy day" scenarios. However, the more participants in the choreography the possible variation of failure should be observed and agreed. An agreement with all this mass of scenarios usually leads to some special work to be done by (inside) each participant. If an entity has to participate in multiple choreographies at the same time (as we said, the value of SOA in easy re-compositions), do you still think that choreography's "global contract" is for SOA? I believe you know exactly where any manager would like me to go, together with such SOA, if I try to offer a service collaboration model that requires changes all the time with no responsibility for the final result.

Instead of the WS-CDL "global contract" for service collaboration I've proposed to use the pattern of Distributed Orchestration.

The Distributed Orchestration pattern helps in organising cooperation between different services in resolving a common task. The pattern is based on two pillars: 1) the use of natural activities of the service; 2) the use of the partner-and-supply chains of the service in its natural form instead of direct invocation.

The Distributed Orchestration pattern may be applied to different types of entities - services, SW applications, business organisations - and assumes that:

1. Each collaborating entity provides its native capabilities and is fully responsible (to its owners) for restoring these capabilities in the case of failure
2. Each collaborating entity (service) performs in its native functional realm with no implementation changes attributed to particular collaboration
3. Only a few core services have to be invoked to start collaborative work; these core services will engage their regular partners and suppliers in a regular manner to fulfil their part of the common task, if needed
4. Entity collaboration may be facilitated, initiated and directed the enforcement of shared policies
5. The preconditions for any collaboration between two or more entities are: 1) a need to collaborate, 2) a willingness to collaborate, and 3) an ability to collaborate.

Since each entity (service) in normal conditions creates and maintains its relationships with partners and the supply net, it is assumed that if an element in this net fails, the rest of the net (or primary interested entities) initiatively fix this problem by finding and engaging an alternative service. Using Distributed Orchestration pattern, we do no need to prescribe fail-over activities to each collaborating service for each potential combination of failure cases - the services do this by themselves. The latter statement is based on that each of the participating services is the conductor for its own activities and needs. That is, the centralised administration and enforcement attributed to the orchestration's conductor becomes distributed among all participants.

To activate the process of the common task resolution, it is enough to engage a few major services that will cascade this invocation down to their supply chains and partners in regular way. This means that the Distributed Orchestration pattern requires a very accurate analysis of the inter-service relationship, which is usually publicly known at the enterprise level and below. The analysis has to ensure that all requirements of the common task are met by services to be involved into the collaboration. At the same time, no services need to know what collaborations their consumers are involved into as well as what collaborations they themselves are involved whilst the consumer agrees with the service description.

Even if the consumer does not want to use all service's functionality or adhere to all policies listed in the services description and negotiates a sub-set of them with the service (provider), this does not affect the service body and does not require any changes. When invoked, the services will engage their supporting services with no special agreements. This is a recursive process applicable to the services of engaged services. So, to organise multiple independent services to work together on solving a common task, we need:

1) To make the task attractive to a few major services in the task domain, or
2) To find services that are interested in the task already, but
3) Never to enforce the task directly on the services (instead, we better change the execution environment/context making services interested in the task)
4) To count on native service's domains and activities in those domains. This includes the entire net of inter-service relationships of the services, i.e. a net of other services that normally serve each other in those domains.

If you cannot generate an interest or a need of the potential contributors into the task resolution, you have to change the execution context into the form where a centralised orchestration may be applied because this is only one reliable alternative available.

Here are a few examples where a change in the execution context of the services facilitated collaboration in resolving common task.
The first example is about how a country-wide task of legal registration of companies has been solved in the UK. The task to be resolved is: provide for all UK businesses to register in the UK Companies House. Such registration discloses the company to the Taxman and not everybody is a big fan of him. For the sake of the explanation simplicity, I express several UK Laws in my own words in the form of rules:

1) All business entities have to be legal
2) A business may be conducted with legal counterpart only
3) A business entity is legal if it registers with the Companies House

As one sees, nobody orders any business (service) to register. The effectiveness of aforementioned rules is based on the assumption that businesses usually operate by dealing with other businesses or consumers. If the business is illegal, it will be very difficult to find legal peers, suppliers and consumers. So, it is cheaper to register and find other means for dealing with the Taxman than to hide and avoid registration. Even if the business does not want to register, in described legal environment it is interested in minimising potential fines for being illegal. So, the business has a need to interoperate with others, it is interested in minimizing its risk of fine and it goes for the registration. Apparently, if a business has registered, it will look up for partners and suppliers who have registered as well. That is, the wave of distributed orchestration (of the task of registration) spreads over the business domains.

We can find realisation of the Distributed Orchestration pattern in many different situations as well. The most well-known is one of the supply chain models ( by Supply Change Management, the description of the Extended Enterprise concept is: "... the loosely coupled, self-organizing network of businesses that cooperate to provide product and service offerings"). If every chain node possesses the authority to find and hire all external providers needed for solving its business tasks, then the chain will grow and shrink by itself when needed.

Another not very obvious example is a reversed VNA - Value Network Analysis. Actually, the VNA recreates and analyses the structure of informal relationships between entities, particularly human workers. The VNA may be effectively applied to the discovering and documenting informal relationships between groups of people as well, i.e. between teams involved into the business process. Matter is in that those relationships had been initially created via realisation of the Distributed Orchestration pattern, i.e. every element of the Value Network created its "friends" and "advisors" by itself at its time. Thus, the VNA recreates the results of the work of the Distributed Orchestration patter.

This pattern can be implemented via semi-automated tools in the same way as the "global contract" of the choreography. The only requirement here is the distributed authority and independence must be well understood first. However, this is just a matter of time.


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