RE: "Orchestration" and "Choreography"

Mike,

It seems to me that WS-Coordinate is a generic 
context creation and management service that can be 
leverage but by the other modules of the 
architecture. One of the very first modules to take 
advantage of it will be WS-Transaction.

Security, caching and other module of the web service 
architecture could leverage the WS-Coordination 
if/when necessary.

Best,
Edwin



---- "Champion, Mike" <Mike.Champion@SoftwareAG-
USA.com> wrote:
> 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 21:00:34 UTC