RE: "Orchestration" and "Choreography"

I've always viewed "choreography" as going a bit beyond just how "A" plugs
into "B". Certainly in ebXML nomenclature, choreography defines a certain
sequence of message exchanges between/among a set of Web services -- in many
cases it defines a long term transaction, such as purchase order processing.
Choreography does not include workflow, although it might define
exception-raising situations. I would say that the primary distinction
between "choreography" and "orchestration" is whether or not workflow is
involved.

Regards,
Anne

> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Champion, Mike
> Sent: Tuesday, August 13, 2002 8:25 PM
> To: edwink@collaxa.com; www-ws-arch@w3.org
> Subject: 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:56:55 UTC