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: Sunday, March 16, 2003 8:04 AM
  To: Assaf Arkin; public-ws-chor@w3.org
  Subject: 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 ?

  My opinion is that if you can say something about a group of n services,
you can obviously say something about a group of 2 services. If you have a
language for n-service choreography then by definition you have a language
for 2-service choreogaphy. So there's not risk that the WG will have to
define two separate languages, or do a lot of work to extend the n-service
language to somehow deal with 2-service interaction. The later is just
given.

  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.

  In my opinion there is more than one way to implement anything. Sometimes
the implementation can be done in the form of orchestration, sometimes the
implementation cannot be done in the form of orchestration at all (e.g.
running a credit application against a ruleset to determine credit rating
requires a different kind of logic). Sometimes an implementation is a
combination of both. So I don't equate orchestration with implementation
unless in the very specific case that all you need to implement something is
to orchestration services. But that's just one specific case.

  The other question deals with external visibility. Orchestration of
external visible services is possible, which is why a choreography that only
deals with external behavior (whatever that means) also describes
orchestration that only deals with external behavior. As I said above, this
may not lead you to having an implementation there. But you're still
defining an orchestration, just not your implementation.

  Since orchestration does not necessarily imply implementation, I've
carefully written my text to define orchestration in the proper way that
does in no way imply that orchestration is the only form of implementation.
And since external vs internal is really a matter of scope, it's quite
evident that an orchestration of externally visible services is possible
without precluding that there's also an implementation which may even be a
different orchestration of internally + externally visible services.

  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 ?

  It's actually not in conflict with BPSS. The difference between WSCI and
BPSS is in the manner they a) define the service to begin with and b) tie
processes together. WSCI (and also BPML and BPEL4WS) use the WS model for
describing a service and it's operations, we can argue whether the WSDL
model is good or bad, but it's given. And WSCI uses mobile process calculus
model to allow more compositions and mobility. We can argue whether that's
beneficial or not.

  But let's look at an example that both WSCI and BPSS can describe equally
well. In describing a choreography of n services they also describe
orchestration of each service i with at most n-1 other services. That's
really conceptual and does not depend on which language you want to use. I
have also crafted my text to make it very clear that I am talking about
conceptual model and not specific languages, because I can show how it
applies to both and in fact a few other languegs.

  In fact, I am looking at this from the concept of concurrent processes
interaction, and let's for a second pick pi-calculus as one low-level way to
describe it. It's obvious that what you call choreography (P = Q | R) is
actually a composition of orchestrations (Q and R). That model can describe
both WSCI and BPSS equally well. There are things you can do in the model
that you can't do in one language or the other. But there is nothing you can
do in the language that you can't describe in the model. That model is proof
that choreography and orchestration are one and the same (but also proof
that an orchestration is not necessarily an implementation).

   arkin

  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