W3C home > Mailing lists > Public > public-ws-chor@w3.org > March 2003

Re: reliability, 2PC etc (from RE: General Choreography and Bi-lateral Choreography)

From: Jon Dart <jdart@tibco.com>
Date: Tue, 18 Mar 2003 14:31:58 -0800
Message-ID: <3E779E5E.3050309@tibco.com>
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 


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
>>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.
Received on Tuesday, 18 March 2003 17:32:47 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:00:57 UTC