Tracking change and innovation in the enterprise software development community
Scaling Scrum
in the enterprise?
ScrumWorks Pro
can help.
Start a trial today
QCon London 2010!
March 10-12, 100
Speakers, 80 sessions,
"THE" team leads and,
architects conference.
Free Book Offer
SOA Demystified
$40 Value
Posted by Boris Lublinsky on Sep 01, 2008
With increasing attention given to SOA, it becomes more and more important to standardize (give precise meaning) the terminology used. An interesting discussion illuminates that point.The discussion was started by Michael Poulin who was asking the question about the difference between "orchestration" and "choreography" hoping to be pointed to the place where the difference "had been clearly articulated". Instead of a simple answer, his question caused a flurry of replies, each giving a slightly different meaning to the terms and interpreting them differently..
Anne Thomas Manes starts her explanation by referring to the Merriam-Webster dictionary for the traditional meaning of the words:
Choreography - the art of symbolically representing dancing:
- the composition and arrangement of dances especially for ballet
- a composition created by this art
Orchestration - the arrangement of a musical composition for performance by an orchestra; also: orchestral treatment of a musical composition
Although that definition does not really help to clarify the differences between orchestration and choreography in IT, it was implicitly used by many participants in the discussion. Anne continues her explanation by referring to the meanings used in existing WS-* specifications namely Business Process definition Language (BPEL) and Web services Choreography Definition language (WS-CDL):
Orchestration refers to automated execution of a workflow, i.e., you define workflow using an execution language such as BPEL, and you have an orchestration engine to execute the workflow at runtime. An orchestrated workflow is typically exposed as a service that can be invoked through an API. It does not describe a coordinated set of interactions between two or more parties.
Choreography refers to a description of coordinated interactions between two or more parties. For example, you request a bid, I return a quote, you submit a purchase order, I send you the goods
A slightly different point of view is expressed by John Evdemon, classifying the two terms based on their visibility:
Orchestrations describe what an overall process appears to do without specifying how any of it is implemented.
I view choreography as a form of peer-to-peer interaction because there is no "conductor". The choreography is an agreed-upon model for interactions that may consist of a series of orchestrations.
From a B2B perspective, orchestrations are intra-organization while choreographies are inter-organization. Put more simply, one organization does not orchestrate another
That definition is refined by Steve Johns:
Orchestrations are "fixed" in that there is a described set of steps and decisions. Choreographies, should be, more goal oriented and be about the co-ordination of resources towards that goal
Alan Dean distinguishes the two terms based on whether there is a "centralized controller" as part of the overall architecture:
It seems to me that Orchestration / Co-ordination has a central Conductor / Co-ordinator whereas Choreography does not...
- Orchestration is Autocratic
- Choreography is Autonomous
Ashley McNeile at Metamaxim traces choreography to the RosettaNet’s "Partner Interface Processes" standard, and considers it the description of certain fixed patterns of (interaction) behavior between participants. He considers that the dispute:
...is not so much on the distinction between "choreography" and "orchestration" as concepts, but on the need for a language to describe/capture choreography independently of orchestration.
Rob Eamon sides with Ashley, saying:
At what point in an architecture definition, or in a design, does the distinction between choreography and orchestration matter? In an architecture or design will the use of one or the other term be sufficient without further explanation? Seems to me to be yet another case where assumptions about what a particular means in a particular context will lead to miscommunication. One is wise to ensure that the parties involved have a common understanding of the terms being used, however said terms are defined.
This opinion is also shared by Gregg Wonderly:
As is normal, computer scientists are taking words that already exist, and trying to make them apply in a particular context. People, who know and use these words in different contexts, have bias and experience which makes them perceive those usages as either right or wrong (binary logic, "sometimes" is hard to use as a logical explanation in a world of absolute logic). So, we get to have all these discussions trying to shape everyone’s view to something that we can all agree on, no matter how contorted the arguments get..
I just wish that the SOA crowd would learn to be happy with using all the words and terms that are the "definitative" meaning instead of trying to shoehorn some silly word into being the place holder for that.
Steve Jones summarized this discussion really well:
Basically I think the point is that choreography, orchestration, co-ordination, process management and all the other words are very badly defined. I wouldn't be surprised if a vendor pitched a BPEL engine as a choreography product. One reason (IMO) that choreography hasn't caught on as well is that its real world equivalent (dance) isn't really an IT specialty.
This discussion is just one example of the situation that is becoming more and more common in SOA and IT in general. People are using the same words while they really mean different things and keep arguing because they are using different words although in reality they are in complete agreement.
Right Collaboration Architecture Drives Business Transformation
Understand and Align BPM, SOA, and Lean Six Sigma: 43 page IBM Redguide
Restful BPM, Pragmatic SOA, Mashups, Avoiding Failure: SOA track @ QCon London in March
Visit SOA Appliance Comparison Site
*Video Usage Model Tutorials
*Comparison to IBM DataPower X150
*Performance Benchmarks/Webinars
*Replace DataPower Program
FREE 1:1 Swap & Migration Services
I'd give my +1 for Anne Thomas Manes' definition. However, I'd put the choreography definition slightly different: "A requests a bid, B returns a quote, A submits a purchase order, B sends A the goods". As soon as you talk about "I/me" and "you", it's getting difficult to separate a local view from a global view and you glue them together. Its like a "deployment" of a choreography into a specific setting where "I/me" and "you" are "endpoints" with a certain "orchestration", that fit to the global view defined in the "choreography". That thus results in
Hi Tammo, when I posed a question on the "local" role of BPEL to Gregor Hohpe, he pointed out that BPEL can be used to describe these dependencies in an abstract way, too. Do you agree?
I wrote a similar blog back in 2006: Service Orchestration vs. Service Choreography.
Looks like we're all still confused.
If we all stepped back and swapped the "C" in WS-CDL to mean Conversation instead of Choreography, I believe this may be the last time we read such an article.
I think Gregor Hohpe put it really well: WS-CDL is the superior specification for conversations & message exchange, but the pervasiveness of BPEL in the enterprise environment makes it the better bet for modeling these interactions even with its perceived shortcomings.
Zubin Wadia
www.zwadia.com
Hi Stefan,
I absolutely agree with Gregor, but as he said it depends on the scenario. In a very simple scenario where just 2 services/processes are connected, an abstract BPEL describing each behavioral interface is sufficient for describing the choreography. If you imagine a more complex scenario like the request-with-referal service interaction pattern, the abstract BPEL is not explicit enough because the local BPEL process can not know what happens between other participants. For instance process A is buying something by sending a PO to B and later receives the goods (something immaterial of course ;) ). Now B has decided to outsource the shipping part and delegates it to partner C who sends the shipping message to A. Although it is possible in A's BPEL to define that the response is expected from another participant, it is unknown to A what happens between partner B and C. To make this knowledge explicit, you would need to capture the global model. Of course it is possible to derive the global behavior of a set of BPEL processes but this can be tricky because BPEL aims at hiding the binding to concrete partners so you would need to analyze a specific deployment setting to know which process plays which role and with whom it interacts. In this case it appears more appropriate to model the global choreography (e.g. with WS-CDL or BPEL4Chor) and then split it to abstract BPELs that are then implemented by the participating processes/services.
Thanks for the comment (and incidentally, the BPEL4Chor pointer which I admit I hadn't heard of before :-) )
I think the title does little to help the debate. It is not "vs" because that implies one or the other. It is about understanding what each does.
BPEL is all about execution. It is about implementation.
CDL is all about description. It is all about architecture but in a way that describes intent without elaborating the how (execution).
BPEL does not describe without introducing a specific view point (that of the service that it realises - the end point view). This is why it is unsuitable for description.
CDL deso describe but does not execute. This is why it is unsuitable for execution (it needs many other moving parts, i.e. the non-observable logic that BPEL is so good at modeling and BPEL engines good at realising).
We all need architecture and implementation. CDL is architecture and BPEL is implementation. CDL provides testable architecture (against requirements) which ensures that subsequent implementation (of which BPEL is a key target) is correct against the description (the architecture).
So both are needed - describe architecture, validate it and realise it. They are used at different levels of abstraction with CDL being higher than BPEL.
The "WS" in WS-CDL is a misnomer. It applies with or without Web Services which is why the interfaces on roles in WS-CDL (which references WSDL) is optional.
Sorry the last post did not capture breaks. So here it is again properly formatted.
I think the title does little to help the debate. It is not "vs" because that implies one or the other. It is about understanding what each does.
BPEL is all about execution. It is about implementation.
CDL is all about description. It is all about architecture but in a way that describes intent without elaborating the how (execution).
BPEL does not describe without introducing a specific view point (that of the service that it realises - the end point view). This is why it is unsuitable for description.
CDL does describe but does not execute. This is why it is unsuitable for execution (it needs many other moving parts, i.e. the non-observable logic that BPEL is so good at modeling and BPEL engines good at realising).
We all need architecture and implementation. CDL is architecture and BPEL is implementation. CDL provides testable architecture (against requirements) which ensures that subsequent implementation (of which BPEL is a key target) is correct against the description (the architecture).
So both are needed - describe architecture, validate it and realise it. They are used at different levels of abstraction with CDL being higher than BPEL.
The "WS" in WS-CDL is a misnomer. It applies with or without Web Services which is why the interfaces on roles in WS-CDL (which references WSDL) is optional.
Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).
The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?
The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.
"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?
Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.
SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.
Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.
For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.
8 comments
Watch Thread Reply