General Choreography and Bi-lateral Choreography

David,

I agree with everything you say.  However, I want to elaborate my view on 
multi-party choreography.

Most real life B2B scenario are multi-party interaction.  But "multi-party 
interaction" is NOT equivalent to "multi-party choreography".  For example, 
a company (or "domain of control") can have an orchestration that span 
multiple "bi-lateral" choreographies.  In other words, "multi-party 
interaction" can be realized by multiple "bi-lateral" choreographies linked 
together by orchestration.  The only thing lost is the sequence 
dependencies between message exchanges within choreographies is NOT 
captured externally.

I honestly don't think bi-lateral choreography is sufficient to capture 
arbitrary public protocol sequence.  For example, the well-known 2-phase 
commit protocol cannot be specified using bi-lateral choreography.  So I 
agree with you that in a generic sense "choreography" should NOT be 
restricted to 2 parties.

Let me rephrase my previous e-mail and say we should define a special case 
of choreography called "bi-lateral choreography" by add some restriction 
around the generic choreography model.  The purpose is to avoid the 
following complexities inherited in the generic multi-party choreography
1) Because message exchange is always bi-lateral.  Therefore, it is 
complicated to synchronize the "public state" with all the parties.  Of 
course, we can have a 2-phase handshaking protocol similar to 
WS-Coordination to achieve that, but this leads to more complication.
2) Dynamic binding between roles and business entities can happen after the 
choreography instance is created.  This introduce additional complexity 
such as an extra protocol among existing parties to control the rebind, as 
well as how to reach a consensus about the rebind.

I bet people will be more interested in "bi-lateral" choreography because 
it is much simpler to understand and still can handle 80~90 % of real-life 
B2B cases.

Best regards,
Ricky

At 12:24 PM 3/15/2003 -0800, Burdett, David wrote:
>I totally agree with Ricky on separating choreography and orchestration 
>but disagree with Edwin on restricting collaborations to just two.
>
>Details below.
>
>CHOREOGRAPHY AND ORCHESTRATION
>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 advantage.
>
>WHY DOMAIN OF CONTROL
>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.
>
>For example consider a procurement system interacting with an ERP system. 
>The procurement system might be implemented using an orchestration and 
>therefore can be changed flexibly, but the ERP has its own internally 
>fixed and unchangeable rules on the sequence in which messages are 
>exchanged with it. This means that ERP system is really imposing a 
>constraint on what the procurement system, in *exactly* the same was as an 
>external business might impose a constraint on what the procurement system 
>could do. So really there is a "choreography" between the procurement and 
>and the ERP system since the procurement system MUST conform to it and 
>cannot control it - even though they are both being run by the same business.
>
>NUMBER OF PARTIES IN A COLLABORATION
>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.
>
>Regards
>
>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;>mailto:david.burdett@commerceone.com; 
>Web: <http://www.commerceone.com/>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
>
>Ricky,
>
>*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.
>
>Edwin
>
>-----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 mean.
>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 INSTANCE.
>
>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 the ORCHESTRATION level.
>
>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 order.
>"       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 couriers.
>"       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 seller.
>
>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, ShipmentNo)
> From State accepted
>Triggered by when buyer send a FulfillmentCompleted message to seller
>
>End State = returned :  (OrderStatus= returned , OrderNo, ShipmentNo)
> 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 
>Choreography
>
>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 
>availability
>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,
>Ricky