- From: Furniss, Peter <Peter.Furniss@choreology.com>
- Date: Mon, 17 Mar 2003 18:31:04 -0000
- To: "Monica J. Martin" <monica.martin@sun.com>
- Cc: "Ricky Ho" <riho@cisco.com>, <public-ws-chor@w3.org>
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