RE: "Orchestration" and "Choreography"

Thanks, that was very helpful! OK, so  ...

"description" defines the "programming" interface of one web service.

"choregraphy" defines how multiple services mechanically plug in to one
another, e.g., how invoking a particular service puts some object into a
state where another service can be invoked on it.

"orchestration" defines how multiple services can be used in conjunction at
the level of business processes / workflow / program logic, e.g., "If
service X is successful, invoke service Y, otherwise invoke service Z".

Do others agree that these are the generally accepted definitions of these
terms?  Should the WSA adopt this terminology, or try to persuade the
industry to adopt less, uhh, metaphorical terms?

How about "coordination".  I get the impression that WS-Coordination was
created because its inventors factored "coordination" out of both "business
process execution" (aka "orchestration" as defined above) and
"transactions."   The closest I can find to a definition in the
WS-Coordination spec is a bit recursive: it provides an "extensible
framework for providing protocols  that coordinate the actions of
distributed applications. Such coordination protocols are used to support a
number of applications, including those that need to reach consistent
agreement on the outcome of distributed transactions."


> -----Original Message-----
> From: Edwin Khodabakchian [mailto:edwink@collaxa.com]
> Sent: Tuesday, August 13, 2002 3:43 PM
> To: www-ws-arch@w3.org
> Subject: "Orchestration" and "Choreography"
> 
> 
> 
> Mike,
> 
> There are 2 problems that need to be solved:
> 
> Problem #1: You have 3 different services that 
> interact with each other and you want to document the 
> exchange of message between those services.
> 
> Problem #2: You want to invoke 3 different services 
> in a specific order because they have data and 
> control dependencies between each other.
> 
> Problem #1: is called choreorgraphy. It is about 
> providing more information about interfaces of 
> services and how they plug to each other. 
> Choreography defines public protocols that each party 
> needs to be compliant with. RosettaNet PIPs, WSCI, 
> BPSS and BPEL4WS abtract processes try to address 
> this problem. Note: This is not executable logic, 
> only something you are compliant with. 
> 
> Problem #2: is called workflow, BPM or Orchestration. 
> It is about implementing logic that ties a set of 
> services into an end-to-end process. That logic is 
> then executed by a run-time that dispatch the right 
> message to the right component and wait for the 
> reception of the right message to activate the next 
> service. Orchestration languages are similar to other 
> scripting language but usually include support for 
> asynchronous interactions (<receive> in BPEL) and 
> flow coordination ( <flow> in BPEL ) and business 
> transactions (WS-T or BTP). Also, in term of 
> terminology, orchestration languages use activity 
> where traditional languages use statements.
> 
> One of the most important aspect of both of those 
> problems is that they require a visual representation 
> because they are used as an important communication 
> medium between partners but also within an 
> organization between the business analyst and 
> business users that know the rules and data models 
> and the developers that implement the real work.
> 
> my 2c,
> Edwin
> 
> 
> 
> ---- "Champion, Mike" <Mike.Champion@softwareag-
> usa.com> wrote:
> > 
> > OK, trying to eat my own dogfood here, I need help 
> understanding the
> > distinctions between "coordination" 
> and "choreography" in the web services
> > context.  The W3C recently acknowledged 
> a "choreography" submission [1], and
> > IBM/BEA/Microsoft just unveiled a collaborative "WS-
> Coordination" language
> > [2].  
> > 
> > I presume that some of the authors of those 
> documents are on this list.
> > Please help!  [send me private e-mail if you don't 
> want to go on record, and
> > I'll sanitize/anonymize it!!!!]
> > 
> > As best I understand it, "choreography" is a higher-
> level activity involving
> > multiple web service invocations, 
> whereas "coordination" is a lower level
> > activity that choreography or transaction 
> processing, security, etc. would
> > employ in their implementations, and could be 
> exposed as a web service
> > itself.  
> > 
> > I have this vague sense that while REST advocates 
> didn't express much
> > interest in either "coordination" 
> or "choreography", they did so for
> > different reasons:  Coordination can be handled, in 
> the REST view, by shared
> > "state" resources identified URI and accessed by 
> HTTP; Choreography is
> > opposed on RESTful grounds so much as by the sense 
> that
> > RDF/OWL/DAML-S/whatever would provide a better 
> solution than SOAP-based
> > protocols.  Does anyone else see it that way?
> > 
> > Special bonus question: Is there a distinction 
> between "orchestration" and
> > "choreography" in the web services context?
> > 
> > [1] http://www.w3.org/Submission/2002/04/
> > 
> > [2] http://www-
> 106.ibm.com/developerworks/webservices/library/ws-
> coor/
> > 
> > 
> > 
>

Received on Tuesday, 13 August 2002 20:24:47 UTC