If we try to use a service in choreography, we, certainly, find a lot of interactions between services. Probably, it is easier to comprehend than implicit interactions in orchestration collaboration. However, this is it; this is all what is easy. It is obvious that if we want our service to participate in the more than one choreography, we have to embed all choreography rules for all choreographies into the service; if we want to add the service to the one more choreography, we have to modify the service, i.e. disturb all choreographies it participates in already. Is the cost of such tremendous coupling acceptable for SO environment?
Here is another area of concerns about choreography capacities to keep up with service orientation. For example, the same service may be used in a few choreographies that, in turn, may be used in the same collaboration hierarchy but in different levels. Are we saying now that each service has to be aware about where and how it is used to operate in 'right 'choreography? IMO, this kind of knowledge simply contradicts SO Principles.
Many believe that choreography in essence is a model of business interactions. My take on this is - it is correct if the interaction scope is limited by peer-to-peer interactions and it is incorrect if choreography tries to organise interactions across multiple peer-to-peer communications. That is, the choreography, as it is defined today, is good for a figure of a dance. However, it is not suitable for the whole dance
Why I think so? Because modern definition of choreography requires the management of service activities to be embedded into the services and, because of that, the management is limited in its options if something is going wrong. That is, choreography does not offer any solutions for the stalemate case in chess or for emergency process when a participant unable to perform its activities in accordance with the global contract. The entire collaboration goal is at risk in such cases. This is where choreography model deviates from the business interactions that the choreography claims it is modelling. For such situations, business has a solution - the resolution of 'no go' problem may be found outside of the service in the absolute majority of the cases and business collaboration can move forward; choreography does not have such ability (while orchestration does).
This means, that at in choreography any service at any moment has a risk of destroying the entire collaboration. People who work with emergency solutions at the government level say that they have to use choreography model because independent organisations do not accept any directives from outside on what and how they have to operate. With all respect to the business owners, I have to outline that emergency status is defined and declared by the government, not by the Board of Directors; it is not a business-as-usual situation. I do not see how a government may be made accountable to its citizens for resolving emergency cases if any emergency plan - based on choreography - may be stopped by any organisation assigned some emergency related activities but decided it could perform them due to any reasons. Uncoordinated emergency management is a dangerous thing, IMO.
Hi Michael
I like the Chess example :-)
I think my perspective on this is as follows:
If we want to build multiparty peer-to-peer service collaborations between stateful participants, and we want to engineer the solution so that we know it works, then we have no choice but to use a Choreography based solution - whereby the participant behaviours are abstracted from a global description. This is because, from a theoretical point of view, this is the only approach that is known to work.
So I think the question is not "Should we use Choreography or Orchestration?" but "Do we want to build this kind of distributed application?"
Rgds
Ashley
Ashley, what does mean "the only approach that is known to work"? Doest it mean that others do not work or we (in the engineered solutions) simply do not know?
Choreography in engineering is very similar to network topology called 'ring'. Solutions based on 'ring' have shown not high reliability - one element failure caused failure of the whole system. Another analogy is network mesh. It is more reliable because there are more routs to the target that can bypass the failing node. But if the failing is the one that handles the transaction at the moment of failure, there is no way to resolve the case - nobody is responsible for the overall system behaviour.
However, there is another topology called 'star'. This one has one point of failure - the central node. From practical experience (and theoretically) the model consisting of 'star' of 'stars' (remember, in J2EE - cluster of clusters or pool of pools) demonstrates better reliability and ease management. If anything happens with the working nodes, there is s central node to resolve the problem; if this one also fails, another 'star' can be involved. One more advantage of 'star' model is that I can add and remove nodes dynamically with no impact on many others (only on the centre node). Neither 'ring' nor 'mesh' can do so.
This is why I think that 'star'-like orchestration is more suitable for service-oriented environment than choreography.
"Do we want to build this kind of distributed application?" So far, I do not know an example where it would be better solution then others. So, we have a solution, now we are looking for the task… Oh, BAU again.
Hi Michael
By "the only approach that is known to work" I mean that there may be other approaches that work, but they have not yet been discovered/invented.
Choreography addresses "peer-to-peer" stateful collaboration, where there is no distinguished "controlling" node. The Internet is an example of a highly successful technology that works on this principle. Whether this is appropriate for service collaborations remains to be seen, so I think that Choreography should properly be regarded as a research issue. However, it is the proper place of research to lead rather then follow BAU.
At least the W3C regard it as potentially important as they say (in the Web Services Choreography Working Group Charter):
The Web Services Architecture Requirements Working Draft created by the Web Services Architecture Working Group also lists the idea of Web service choreography capabilities as a Critical Success Factor, in support of several different top-level goals for the nascent Web services architecture. (The bold is mine.)
They could, of course, be quite wrong!
Rgds
Ashley