RE: Choreography and Orchestration

I want to apologize in advance for switching from HTML to text, but some
rather popular e-mail client that I'm using insists on crashing half way
through the response, so until I find a solution I'll have to use text
e-mails for a while.


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

I agree 100% with this assesment. Except, I don't see domain of control as
implying business entity. I think two different applications owned by the
same business entity and serving it's need, like an ERP and a CRM, are two
domain of control, with each application defining a domain and is the only
one exterting control over that domain. I don't see two components within
the same domain needing to define a choreography, but I see two components
in different domains in the same business entity benefiting from defining
choreography.

And in fact -- without mentioning names but we all know who we're talking
about -- the major ERP and CRM vendors are looking at these technologies
because this problem applies very well to what they do within the constraint
of a single business entity but across domains of control.


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

Unfortunately, I can't agree with both. If bindings do not change within the
lifecycle of a conversation (which is my definition) then a choreography can
define multiple conversations, although a subset can be devised that only
defines one conversation.

But this treads into what you want to describe. If you want to describe a
conversation between two parties only, then bi-lateral definition in any
choreography language would work. If you want to describe an uber
conversation that may be decomposed into smaller conversations (or composed
in order to benefit from reuse), then you will end up with more use cases.

If these were not real life use cases I would consider them interesting but
not worthy of a solution. But the fact is that many businesses out there do
these things on a daily basis, and with all do respect to UML diagrams and
PDF files, there's a lot of interest in a more precise language that is
understandable to tools like WS stacks, monitoring tools, applications, etc.


<ro>
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".
</ro>

+1

I think the issue of 'consensus reaching protocol' is a very interesting one
and in fact captures very well the problem we're trying to solve. And if you
remember from my presentation, I tried to put it in scope and also a variety
of solutions out there for solving that problem by talking in more abstract
terms and looking at an approach that unifies all these different models.


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

<ro>
Totally agree !  I assume the "event" here means "message exchanges".
</ro>

In the space of WS I would further constrain it to the message exchange that
WSDL defines, or something along these lines that is consistent with the
language used by the WSA.


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

This is where it gets a bit tricky to make the distinction. If you view an
orchestration as not necessarily being an implementation, then you can
accept that orchestrations can be extended in much the same way we extend
classes in OO languages*. So you can have one orchestration that is
constrainted to one choreography (and defined by it), and you can have  one
orchestration that extends it, ties two choreographies together and in fact
gives you an implementation! And perhaps you want to define the first
(abstract, non-executable) with WSCI or BPSS and the second (complete,
executable) with BPEL or BPML.

If we can think in these generic terms and tie the concepts together (and
they are not separate) then we can also build a framework in which multiple
implementation languages and multiple interface languages (e.g. one for WS
and one for trading partners) can coexist and all complement each other from
the get-go.



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

Absolutely not. If you need to change the choreography because the
implementation changes then you lose a lot of the value of the choreography
language. But notice that I did not equate the orchestration with the
implementation, so I do accept that there is an incomplete orchestration
derived from the choreography and in this case a more complete (and possibly
executable) orchestration that spans different choreographies, so you do
preserve abstraction.

So in the case where you have an orchestration for A talking to B and C this
is an orchestration but not an implementation. An implementation requires A
to talk to B, C, X and Y. That may also be an orchestration (or it may
require some other logic which is not covered by the orchestration). These
are two different orchestrations, though one can constrain the other, or in
reverse we can say that one extends the other. The one that is
computationally complete (or Turing complete if we insist on this term) can
be an implementation. The other cannot.

arkin

Received on Sunday, 16 March 2003 16:32:07 UTC