RE: two-phase (from RE: General Choreography and Bi-lateral Choreography)

There are a number of features such as 2PC, conversations, reliability,
routing, etc. which can affect the choreography (in the Ricky Ho sense) at
run time. The question we face is - should we express the choreography
associated with these features directly in the application choreography or
instead just reference them? I believe we should refer to them by reference
rather than by value.

Imagine a simple choreography: A --> B (One way message)

Now imagine trying to describe that choreography when reliable messaging is
used:
A --> B (One way message)
  <--   (Acknowledgement)
  -->   (Optional repeat of Message if no Ack received)
  <--   (Repeat Ack)
  ...   (Etc.)

I don't think that the second choreography provides any clarity over the
first. I suspect we would do best if we were simply to say:

A --> B (One way message, sent using reliable messaging protocol X)

Where X could be any of the currently available reliable messaging
protocols.

A --> B (One way message, reliably sent, member of 2PC as implemented by
protocol Z)

Where Z could be any of the currently available 2PC protocols.

In the choice of expressing these features by value or by reference I think
we are better off using by reference.

		Yaron


> -----Original Message-----
> From: public-ws-chor-request@w3.org
> [mailto:public-ws-chor-request@w3.org]On Behalf Of Furniss, Peter
> Sent: Monday, March 17, 2003 10:31 AM
> To: Monica J. Martin
> Cc: Ricky Ho; public-ws-chor@w3.org
> Subject: two-phase (from RE: General Choreography and Bi-lateral
> Choreography)
>
>
>
> Monica's comment
>
> > >      <mm> The use of a 2-phased commit, using the BTP work, is an
> > >      implementation decision.  At the definition or design level,
> > >      the criteria will be driven by business rules that specify
> > >      what paths (expected or less traveled) occur and to show the
> > >      criteria to move through those paths.
>
> I disagree. (though it may turn out to be a diagreement about what we
> consider to be implied by "2-phase commit").
>
> If two entities are to achieve a coordinated state change, they must
> pass through a transient state in which one party has stated that it
> will make the change if and only if the other definitively decides so.
> That's the core of BTP two-phase outcome. You can move around who makes
> the promise and who
> makes the decision (going outside what BTP currently supports in some
> cases), and you can creep up to the agreement step by step and put in
> various let-out clauses and exceptions, but essentially it comes down to
> the same pattern. At some point, one side makes a binding commitment and
> the other side gives the yes/no. And again other things may move on
> after that, but it is a clear state aligning synchronization point
> (whether it is yes or no, both sides will know what the others view of
> the state is - provided the protocol is written correctly)
>
>
> There will be business rules that decide whether the promise (to change
> make the proposed change if the other agrees) is made or accepted. But
> those are essentially internal to the parties and it is not necessary,
> as I see it, to expose those to the other side.
>
>
> Actually, I fear we're each talking about something completely
> different, but I'm not sure what it is.
>
> Peter
>
>

Received on Tuesday, 18 March 2003 17:16:42 UTC