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 Monday, 17 March 2003 13:31:10 UTC