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

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

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>
Message-ID: <00a101c2eda1$80b0e770$0502a8c0@JJD>

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 01:00:06 GMT