RE: two-phase (from RE: General Choreography and Bi-lateral Choreography)

Although "choreography" can be used to described low level protocol (even 
TCP).  I think the interests at this group is at the business protocol level.
I totally agree with you that some of the low level one are given (MEP is 
defining that), and so don't need to be expressed at the business level, 
they just refer to that.

The reason I use 2PC is because this is a well-known choreography to 
illustration the deficiency of the bi-party model.

Best regards,
Ricky

At 02:16 PM 3/18/2003 -0800, 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 Wednesday, 19 March 2003 13:06:31 UTC