RE: Choreography and Orchestration

Assaf,

I fully agree the way you define "general choreography".  My earlier 
definition of choreography should better be called "bi-lateral 
choreography".  Do you think this restrictive subset has some attractive 
properties that the workgroup should also define it ?

I realize though that we have a different opinion in what the term 
"orchestration" means.

I look at "orchestration" as one specific way of 
"implementation".  Orchestration is a programming language expressing the 
logic of executing activities, so it is OK to invoking something no 
externally visible.  WS-Orchestration is just an Orchestration while all 
activities are web services interaction.

You look at "orchestration" as a single-party view of a choreography.  This 
single-party view is completely derivable from the choreography so I don't 
fully understand why it is important to have a separate concept.  Is it 
true that WSCI is expressing this single-party view and BPSS is trying to 
express the every-party view ?

Best regards,
Ricky

At 05:52 PM 3/15/2003 -0800, Assaf Arkin wrote:
>I want to offer an alternative definition.
>
>I like to talk in terms of generic models that do not exclude any 
>particular type of application, before drilling down into a specific 
>application. When you talk in generic terms it may seem hard at first to 
>understand 'how my specific problem is solved in that case', but the 
>benefit is that it allows more problems to be solved, not just specific ones.
>
>For example, an OO language is one that allows you to define the common 
>behavior of multiple objects, and allows the behavior to relate to data 
>owned by the object (or referencing other objects). Another definition is 
>that an OO language allows me to build business objects. What about 
>non-business objects like a window or a counter? What about utility 
>objects like a line item list or an address object? A generic definition 
>has more utility then an application-specific definition.
>
>The term choreography was interesting because it was borrowed from 
>performance arts where it usually refers to a dance or a ballet. It places 
>no restriction on how many dancers may participate in the dance. Tango is 
>a choreographed dance that has just two dancers. So while Choreography is 
>a good term for any dance involving any number of dancers, if there is an 
>intent to allow only two dancers, I would prefer to use Tango instead.
>
>In OO we talk about objects and classes. We don't talk much about class 
>instances. Similary in the WS world we talk about service and interface. 
>We don't talk about service instance (though such a thing does exist), nor 
>do we talk about service being an interface instance. Similarly, I would 
>like to propose that we distinguish between Choreography as the definition 
>and Conversation as what actually happens when these services communicate 
>with each other. While we're using two different terms, I think it will 
>actually reduce some of the confusion when we get to discuss more complex 
>use cases.
>
>So what is a choreography: a choreography is a specification of how 
>multiple things interact with each other over space and time.
>
>In our case space means different services in different places, time means 
>the ordering of activities with relation to each other. I would like to 
>suggest the following definition of WS Choreography (as opposed to just 
>about any choreograph):
>
>WS Choreography: A specification of the behavior of multiple servies that 
>interact with each other by exchanging messages
>
>You will notice that in my presentation I've tried, and hopefully 
>succeeded, to make that distinction clear. I was talking about a generic 
>concept first, and then tried to place it in the scope of WS. So I never 
>imagined WS as the only way to choreograph things, but I do think that 
>WS-Choreography would talk only about Web services, as defined by the WSA. 
>This is also important because there are some choreography definitions 
>that cannot be defined by WS-Choreography and in my opinion are not 
>interesting for us, e.g. updating shared states in a database, or using 
>some non-WS means to do that. A load balancing engine has a way to manage 
>shared states that involve multiple servers, but since this is done below 
>the WS level it's not exposable in WS-Choreography (and quite frankly not 
>of interest to this group).
>
>Let's assume that two (or more) Web services are performing a dance with 
>each other based on some WS Choreography scripted for them by some 
>language. What is each of these services doing? Each of these services is 
>talking to other services. It's arranging or controling elements (in this 
>case WS operations) that allow it to achieve some overall effect or goal. 
>That's pretty much the dictionary definition of orchestration (conducting 
>a symphony is another unrelated definition).
>
>So I would like to propose a definition for WS Orchestration that does 
>something like:
>
>WS Orchestration: A specification of how a service interacts with other 
>services by exchanging messages
>
>As I pointed out on the whiteboard, a choreography is a combination of 
>orchestrations. Let's look at a simple example using a bi-party choreography.
>
>Service A sends some message (m) to service B. Following that, service B 
>sends some message (m1) to service A. That's a very simple choreography of 
>how two services interact with each other. It's also a specification of 
>their orchestration. Service A sends message m0 and waits to receive 
>message m1. Service B receives message m0 and then sends message m1.
>
>Let's look at a more complex example involving multi-party choreography 
>with services A, B, C and D. In the choreography we define that service A 
>sends messages to B and C. C sends messages to D. So we also have a 
>definition of what the orchestration in this context would look like: A 
>talks to B,C. B talks to A. C talks to A,D. D talks to C. Magically, the 
>definition of choreography is nothing more than the composed definition of 
>orchestrations, and as I'll show below vice versa.
>
>But there's an interesting question. In defining the orchestration of some 
>service, say service D in the example above, did we also define the 
>implementation? Not necessarily.
>
>Let's say that service D receives a message from C, and based on some 
>information sends back a message to D. How did D get that information? It 
>can have some piece of code in there that does it, whether we write it in 
>Java, BPEL or Perl makes no difference. We've expressed it's orchestration 
>but not it's implementation. In this case, which covers the majority of 
>cases, we've expressed the service interface, one coarse grained 
>orchestration is must perform to participate in the choreography, but in 
>no way did we express its implementation.
>
>So I would also like to formulate three axiomatic restrictions:
>
>1. Closure: A choreography of n service types includes only messages the 
>are exchanged by these n service types.
>
>2. Completeness: Any orchestration for one service type that involves n 
>other service types can be expressed as a choreography of n+1 service types.
>
>3. Non-reflexive: An implementation is a super set of some (possibly more 
>than one) orchestration.
>
>These restrictions are important because they allow us to attain some of 
>the properties of choreography that we all care about, namely:
>
>1. Abstraction: A choreography asks the implementation to do certain 
>things, but does not strive to restrict the number of possible 
>implementations. I argue that a choreography model that does not observe 
>restriction #1 or #3 is not useful.
>
>2. Validation: Since the choreography expresses a subset of the 
>orchestration of a service (#2 and #3), it allows us to determine that the 
>service actually observes it's role obligations in the choreography, 
>regardless of how we choose to implement it. (In other words, we can 
>ensure that the implementation matches the contract, but we don't decide 
>on what the implementation looks like and we can change it as often as we like)
>
>3. Utility: Since we placed no other restrictions we can allow a service 
>to participate in any number of choreographies, and we can allow 
>choreographies that are applicable to B2B, choreographies that are 
>applicable to A2A, simple back & forth and complex end-to-end, reuse and 
>recursive composition, etc.
>
>Note that throughout this discussion I've been talking about services and 
>not business entities. How we map services to business entities is 
>orthogonal. For example, a choreography involving n service types may in 
>fact be a choreography involving two business entities. But since one of 
>these business entities elected to reuse multiple service types in that 
>choreography the choreography involves more than two service types. This 
>makes choreographies more interesting because they support reuse, 
>recursive composition and more than a limited set of scenarios.
>
>Also I did not limit bindings intentionally. In WS terms we talk about 
>service types (or interfaces) and then bind services during the message 
>exchange, possibly passing service references in the messages. Practical 
>examples may be more restricting, depending on what you want to achieve. 
>In some cases services must be fixed as soon as possible and never 
>changed, in other cases the "interesting" services are those that are 
>bound later on (e.g. marketplace scenario). There is no technical 
>restriction that imposes that all services be bound in advance, and a 
>variety of mechanisms that allow them to be bound later on (WSDL, UDDI, 
>WS-Addressing, WS-Callback, WSCI's locator, etc).
>
>I also did not express choreography as a sequence of state alignments for 
>a very simple reason. Choreography is a solution for addressing state 
>alignment, and allows a variety of models (e.g. point-to-point, group 
>consensus, transaction contexts, state expiration). On the other hand, a 
>language for expressing state alignment may be useful but does not specify 
>how WS are used to achieve this. It is quite likely that two services 
>would have a perfect understanding of the states they want to align, but 
>not a perfect understanding of how they intend to do that, resulting in 
>misaligned states. On the other hand, a choreography gives a framework for 
>expressing the deterministic interaction that leads to proper state 
>alignment for any number of executions.
>
>arkin
>
>-----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