- From: Jean-Jacques Dubray <jjd@eigner.com>
- Date: Tue, 18 Mar 2003 17:55:10 -0500
- To: "'Yaron Y. Goland'" <ygoland@bea.com>, "'Furniss, Peter'" <Peter.Furniss@choreology.com>, "'Monica J. Martin'" <monica.martin@sun.com>, <public-ws-chor@w3.org>
- Cc: "'Ricky Ho'" <riho@cisco.com>
Yaron: Isn't that the expression of a message exchange pattern? When you talk about RM, do you include several levels of RM such as: a) the message got there b) a) + the message was valid with respect to a message schema c) b) or a) + the message was processed without exception by the receiving system of record(s), what even it is (they are). Each level might require one (or a series) of signals. In my opinion, a choreography cannot be defined without all these levels of RM. JJ- >>-----Original Message----- >>From: public-ws-chor-request@w3.org [mailto:public-ws-chor-request@w3.org] >>On Behalf Of Yaron Y. Goland >>Sent: Tuesday, March 18, 2003 5:17 PM >>To: Furniss, Peter; Monica J. Martin; public-ws-chor@w3.org >>Cc: Ricky Ho >>Subject: 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:58:21 UTC