RE: Choreography and Orchestration

  -----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.

  For WSCI we've elected to use the term 'choreography' because just like
the dictionary term it makes no such restriction. It can be used to define a
Tango or a Swing dance that includes only two dancers. But it can also be
used to define a ballet or an opera that includes a larger than two dance
group. A choreography describes a dance group and not necessarily two
dancers. That's why it's an applicable term for a specification that can
range over any number of services.

  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.

  What about a choreography instance that defines how two services interact
where these two services are implemented by the same business entity? For
example, my 'complex component A' interacting with with my 'complex
component B'. I've elected to use Web services in this scenario because
component A does one business task and is developed by one group, and
component B does some other business task and implemented by a 3rd party
supplier.

  Can we say that choreography is not applicable to this case? Or do we have
to invent business entities to make it usable? Are we treading into the
space of ebXML which deals with business entities in a much better way?

  I would also argue that we need to not use the term choreography instance,
and since 'dance' is kind of a stupid term I would advocate 'conversation'.
In much the same way that we have a separation between class and object (not
a class instance) and interface and service (not an interface instance). I
would prefer to have two different names here.

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

  I would argue in reverse. A choreography can be used to express how states
are shared. That means that A and B can exchange messages to share a state.
But it doesn't mean that everything A and B do is shared. If I tell you
about a state and then go out of business and forget about it, is it shared?

  The interesting thing about choreography is that it allows you to define
which events are used to share a state, and which state you share by these
events. Practically we find that people want to share states and want to
define the state sharing events. So there's a practice here, but we need to
differentiate between the practice and the concept.

  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.

  What is the definition of a party? Does it relate to a service
type/interface or a service/process?

  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

  Not necessarily. We need to distinguish between B2B scenarios where
interactions require a lot of validation and synchronization, and between WS
scenarios where it doesn't. We also need to distinguish between bi-party and
multi-party, because in a multi-party choreography it's possible that most
of the interesting work happens further down and the first two services
don't do anything interesting but identify the services that do (e.g. use a
marketplace to find a quote then engage in purchasing a product based on
that quote from the quoted supplier).


  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.

  There's a difference between what I may privately do and what is the
external behavior of that. However, WS orchestration is an external behavior
of what I do -- it talks about the WS I interact with to do that. So whether
I define it using BPML or BPEL, it still holds true that I define something
that contains a lot of external behavior and may include no details but
those expressed in an external behavior.

  An orchestration is therefore not much different from a choreography, it
simply defines things from the perspective of the service and all the
services it would talk to, whereas a choreography ranges over a set of
services and defines all their interaction.

  For example, a choreography of A, B, C and D will define all that happens
between A, B, C and D.  An orchestration of A may define how A interacts
with B and C, but since A does not talk to D, it only covers A, B and C. So
it's a subset of that choreography.

  There's another issue regarding implementation. To implement my role I may
need more than just orchestration of services. I may also need an
implementation of these services that cannot be defined by an orchestration.
It may be a piece of C#, Java or Perl code. In some cases the implementation
and orchestration are overlapping, but in many cases the implementation is
significantly more than the orchestration.

  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.

  Absolutely.

  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.

  Try group communication as one example, and the
patient-receptionist-doctor example that Jon gave and see if you can fully
describe either one using 2 party choreographies. Of course you don't have
to fully describe either one, you can just have a WSDL description. But if
you want to describe the scenario, in both cases, you'll need more than the
two-party restriction of a WSDL interface.

  arkin


  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