- From: Jon Dart <jdart@tibco.com>
- Date: Tue, 18 Mar 2003 14:31:58 -0800
- To: "Yaron Y. Goland" <ygoland@bea.com>
- CC: "Furniss Peter" <Peter.Furniss@choreology.com>, "Monica J. Martin" <monica.martin@sun.com>, public-ws-chor@w3.org, Ricky Ho <riho@cisco.com>
As I mentioned at the F2F, I think there is a general requirement for composability and reuse. If I have defined a complex MEP for interacting with one partner, I should be able to reuse that in interacting with another partner, without copying. So to that extent, I agree. However, reliability IMO might best be modelled as an "atomic" attribute of interactions - i.e. something that isn't further decomposed into acks, retries, etc. The reason is that some transports can provide reliability in a way that makes the realization of that attribute opaque to the application layer. Others require application interaction, but perhaps that too should be considered a level "beneath" the choreography layer. --Jon Yaron Y. Goland wrote: > 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:32:47 UTC