W3C home > Mailing lists > Public > public-ws-chor@w3.org > March 2003

RE: Choreography and Orchestration

From: Assaf Arkin <arkin@intalio.com>
Date: Sat, 15 Mar 2003 13:19:51 -0800
To: "Burdett, David" <david.burdett@commerceone.com>, <edwink@collaxa.com>, "'Ricky Ho'" <riho@cisco.com>, <public-ws-chor@w3.org>
  -----Original Message-----
  From: public-ws-chor-request@w3.org
[mailto:public-ws-chor-request@w3.org]On Behalf Of Burdett, David
  Sent: Saturday, March 15, 2003 12:25 PM
  To: 'edwink@collaxa.com'; 'Ricky Ho'; public-ws-chor@w3.org
  Subject: RE: Choreography and Orchestration

  I totally agree with Ricky on separating choreography and orchestration
but disagree with Edwin on restricting collaborations to just two.

  Details below.

  I agree that there is a clear distinction between:
  1. The *choreography* that occurs between businesses or what I would
generalize to "domains of control"
  2. The *orchestration* of (business) processes within a business (or
within a "domain of control").

  The Choreography HAS to be agreed between the parties if interoperability
is to occur. The Orchestration, on the other hand, does not. Better internal
business processes are often a way in which a business realizes competitive


  I am suggesting using the term "domain of control" (or something similar)
because you have the same issues arising, for example, when a business
process needs to interact with any system over which it has no control even
if the system is within the same business.

  David has raised this issue before several times and I'm surprised that it
hasn't made it's way into the conceptual level.

  We're not here to solve a problem specific to B2B purchase order
scenarios. We're here to solve a problem that applies to Web services in
general. The notion of domains of control and trust domains is more generic,
it applies equally well to trading partners, business departments and even
different software systems.

  Yes, B2B is a very interesting and important problem to solve. But if we
think in terms of domains with B2B being one level in which a distinction of
domains occurs, then we can solve a much larger problem. The value of Web
services is that they can solve a much larger set of problems than just B2B,
yet the same solution they use in general applies well to B2B problems.

  Although you can restrict collaborations to just two, there are several
common use cases when three parties or more parties can be involved, such as
the one at [1] from the WS Architecture list which describes an exchange
between a buyer, a seller and a third party, independent shipper. There is
clearly one transaction going on and it is hard and definitely unnatural to
split the three-party choreography down into a set of two party
interactions, even if it is possible to do. The group might want to consider
this use case when defining the scope of the activity.

  So I would suggest that we allow more than two parties to be involved in a
choreography. My personal view is that it is not too difficult to do either.

  I know from experience as a vendor that solving a multi-party problem is a
bit more complicated than solving a bi-party problem.  I wish customers did
not have real life complex problems, like the one you provided. But they do.
So I think as a group we need to first decide how we want to approach

  Given the real life problems that customers are facing, we want to devise
an approach to solve them. The approach could be about language and tools
that do more, mirroring the customer's real life problem. Or the approach
can be instructions for the customers on how to fit their complex problems
into a restricted model. One deliverable of this working group could be a
set of rules for mapping complex real life problems into a limited language.
Another deliverable count be a language that makes no such restriction.

  Is there a clear preference to one over the other?



  David Burdett
  Director, Product Management, Web Services
  Commerce One
  4440 Rosewood Drive, Pleasanton, CA 94588, USA
  Tel/VMail: +1 (925) 520 4422; Cell: +1 (925) 216 7704
  mailto:david.burdett@commerceone.com; Web: http://www.commerceone.com

  [1] http://lists.w3.org/Archives/Public/www-ws-arch/2002Oct/0369.html
    -----Original Message-----
    From: Edwin Khodabakchian [mailto:edwink@collaxa.com]
    Sent: Saturday, March 15, 2003 11:52 AM
    To: 'Ricky Ho'; public-ws-chor@w3.org
    Subject: RE: Choreography and Orchestration


    *Great* work: Simple and clear. This is one of the pieces I have seen
regarding Choreography Versus Orchestration. The balance between definition
and use case/example is very helpful.

    Constraining choreography to bi-lateral interactions would be a good
property of the architecture in my opinion.


      -----Original Message-----
      From: public-ws-chor-request@w3.org
[mailto:public-ws-chor-request@w3.org] On Behalf Of Ricky Ho
      Sent: Saturday, March 15, 2003 8:10 AM
      To: public-ws-chor@w3.org
      Subject: Choreography and Orchestration

      I try to put up my own definition of "Choreography" and
"Orchestration" and use a simple buyer/seller use case to illustrate what I
      I'm particularly interested to see how the "Choreography" portion of
this simple example get represented by WSCI and BPSS.

      1       Definitions

      1.1     Choreography
      CHOREOGRAPHY defines the public part of a bi-lateral interaction
between two communicating parties.  It formalize a contractual agreement
between these parties.

      CHOREOGRAPHY defines TWO communicating parties in terms of ROLES,
which will be bound to the actual business entity when the choreography
instance starts.  The binding doesn’t change throughout the lifecycle of the

      CHOREOGRAPHY defines a set of “SHARED STATES” between the TWO
communicating parties.

      CHOREOGRAPHY defines the TRANSITIONS of SHARED STATES in terms of MEP,
where one ROLE sends a message to another ROLE.  In other words, the purpose
of MEP is to align the SHARED STATES between the two ROLES.

      CHOREOGRAPHY does NOT reflect the perspective of a single party.  It
can be taken by any parties who wants to play a role within it.

      The CHOREOGRAPHY INSTANCE starts when the following occurs
      •       One party sends the first message (which propose the initial
SHARED STATES) to another party.
      •       This another party verifies that the initial SHARED STATES
meets the pre-requisite to start the CHOREOGRAPHY

      1.2     Orchestration
      ORCHESTRATION defines the private part of the implementation of a
particular party who plays a ROLE in the CHOREOGRAPHY.  It formalize the
execution logic of that party throughout the message exchanges.

      ORCHESTRATION realize a particular ROLE of a CHOREOGRAPHY.  Therefore,
ORCHESTRATION needs to be conformed with the CHOREOGRAPHY.

      ORCHESTRATION can potentially span across multiple CHOREOGRAPHIES.
Therefore, CHOREOGRAPHY INSTANCES can form inter-dependent relationship at

      Note here that I try to restrict choreography to 2 parties and
disallow changes of role binding throughout the lifecycle of choreography
instance.  The downside is now a multi-party interaction needs to be broken
down into multiple bi-lateral choreographies and their inter-dependencies is
not externalized at the choreography level.  It is up to the implementation
(which is the orchestration) to determine such inter-dependencies.  The
purpose of these restrictions is to simplify the choreography model which I
think still address 80% of the real life use cases.  I would like to see
where it breaks before remove this restriction.

      2       Use Case Example

      Lets look at a very simple example of the product purchase interaction
between a BUYER, a SELLER, and a COURIER.
      •       The buyer send a PURCHASE ORDER message to the seller.
      •       The seller check the credit history of the seller as well as
the product availability and decide either to accept or reject the purchase
      •       If the seller decide to reject the order, he send an ORDER
REJECTION message back to the buyer.  The interaction ends here.
      •       If the seller decide to accept the order, he will arrange
shipment of the purchased product by selecting one of his preferred
      •       The selected courier pickup the product from the seller and
deliver to the buyer’s location.  The courier start a new interaction with
the buyer by sending a SHIPMENT NOTICATION message.
      •       The buyer verifies the product is delivered in good shape and
send back a SHIPMENT RECEIVED message to the courier as well as FULFILLMENT
COMPLETE message to the seller.  Otherwise, the buyer sends back a SHIPMENT
REJECTED message to the courier as well as FULFILLMENT FAILED message to the

      3       Illustration

      3.1     Choreography
      There are four possible CHOREOGRAPHIES in this example
      •       Product Purchase (Buyer and Seller)
      •       Credit Checking (Seller and CreditCheck provider)
      •       Arrange Delivery (Seller and Courier)
      •       Shipment Delivery (Courier and Buyer)

      For the purpose of this discussion, I’ll focus in the first one.

      3.1.1   Public / Shared States
      Product Purchase choreography defines the following “PUBLIC STATES”
      •       OrderNo
      •       OrderStatus (“Submitted”, “Accepted”, “Rejected”, “Delivered”,
“Returned”, “Terminated”)
      •       ShipmentNo

      3.1.2   Message Exchanges
      Product Purchase Choreography defines the PUBLIC STATE TRANSITIONS in
terms of the following message exchanges …

      Start State = “submitted”:  (OrderStatus=“submitted”)
      Triggered by: when buyer send a “PurchaseOrder” to sender

      State = “accepted”:  (OrderStatus= “accepted”, OrderNo, ShipmentNo)
      From State “submitted”
      Triggered by when seller send a “OrderAcceptance” message to buyer

      State = “rejected”:  (OrderStatus= “rejected”)
      From State “submitted”
      Triggered by when seller send a “OrderRejection” message to buyer

      End State = “delivered”:  (OrderStatus= “delivered”, OrderNo,
      From State “accepted”
      Triggered by when buyer send a “FulfillmentCompleted” message to

      End State = “returned”:  (OrderStatus= “returned”, OrderNo,
      From State “accepted”
      Triggered by when buyer send a “FulfillmentFailed” message to seller

      3.2     Orchestration
      Here is the Orchestration of the Seller within the Product Purchase

      Wait for receiving a PurchaseOrder message from buyer
      Starts a new instance of “Credit Check” choreography by invoke the
CreditCheck web services.  After receiving the response, this “Credit Check”
choreography instance is terminated.
      Invoke an internal web service to check the stock level of product
      If (credit is OK and product is available) {
          Invoke an UDDI search to lookup shipping companies.
          Select one courier based on company specific decision logic
          Starts a new instance of “Arrange Shipment” choreography by
invoking the ShipmentHandling web services.
          Send an “OrderAcceptance” message (which include the shipment No)
to the buyer
          Wait for receiving either “FulfillmentComplete” or
“FulfillmentFailed” message from the buyer and update the OrderStatus
correspondingly.  The choreography instance ends here.
          If the OrderStatus is “return”, log into the customer care DB.
      } else {
          Send an “OrderRejection” message to the buyer

      As you can see, some activities within the orchestration is not
visible by the buyer and hence is the private part of the seller.
      - Check the credit history
      - Check the product availability
      - Start another choreography with the courier

      Comments and Thoughts ?

      Best regards,
Received on Saturday, 15 March 2003 16:20:52 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:00:56 UTC