RE: Choreography and Orchestration

Assaf, thanks for your detail comments.  my feedbacks embedded
>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.

Agree !  This is the "general choreography".

>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 shouldn't use the term "business entity".  Maybe the term "domain of 
control" that David introduce is more precise.  But I doubt two components 
within a "domain of control" needs to define a choreography.
>
>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.

Fine with me as long as we know "conversation" is an instance of 
"choreography".
Do you agree that the binding doesn't change within the lifecycle of 
conversation ?

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

I think we are saying the same thing.  First, "states" are only concretely 
defined at the orchestration level.  The "SHARED STATES" at the 
choreography level is an abstract concept which is derived from the 
orchestration-level states.  In fact, "SHARED STATES" is the same as 
CONSENSUS which needs to be always synchronized between two parties using 
message exchanges.  "Choreography" is basically an application specific 
"consensus alignment protocol".
I don't think you can tell me a "SHARED STATE" and forget about it.  You 
have legal obligation in all messages you send within the definition of a 
choreography.
>
>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.

Totally agree !  I assume the "event" here means "message exchanges".

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

A "party" is a "domain of control" (using David's term again).
>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).

I'm thinking along the "bi-lateral choreography" here.  But what you say is 
true in the "generic choreography" case.

The validation I'm thinking here is mainly for correlation between multiple 
choreographies within an orchestration.  For example, an orchestration who 
receive a shipment notice and about to start the shipment choreography need 
to make sure the shipment notice carry an order number that can match with 
an earlier product purchase 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.
>
>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.

In my example, the "buyer" send a purchase order and the "seller" invoke a 
credit check WS before deciding whether to accept the order.  Do you 
consider the credit check invocation as an external behavior ?  Of course, 
the credit checking company sees that, but the buyer don't and doesn't 
care.  The buyer only care whether the order is accepted or rejected.  In 
other words, the credit check web services invocation is "private" with 
respect to the "purchasing choreography".  That WS invocation is probably 
"public" with respect to another "credit checking choreography" which is 
out of scope of the "purchasing choreography".
>
>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.

We have a disagreement here.
An an implementation mechanism, an orchestration, of course can span across 
multiple choreographies.  But this doesn't mean all these choreographies 
can be combined to a bigger choreography.
Going back to my previous example, credit checking is completely separated 
from purchasing at the choreography level.  The fact that the seller want 
to do a credit check before accepting an order is purely an implementation 
decision and shouldn't be reflected at the choreography level.  You don't 
want to change the purchasing choreography definition just because the 
seller change his strategy later not to do the credit check.
>
>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.

The orchestration may as well define how A interacts with B, C, X and 
Y.  Spanning across yet another 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.

You don't have to use orchestration to implement the role you play in a 
choreography.
You are absolutely right !  An orchestration engine will can only invoke 
web services may not be sufficient to implement everything you need.  But 
you can always code the implementation, expose it as web services and have 
the orchestration engine call it.  Possible but not optimal.  Right ?

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

I agree with you and think we should have both "generic" and "bi-lateral" 
choreography.

Rgds, Ricky