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

This is now touching on some of the boundary conditions on where errors are
detected. You could imaging that some Reliable Messaging middleware could
produce an "acknowledgement" that consisted of the following information:
1. Basic Ack - Message Received and persisted - it should not, barring
disasters, be lost
2. Additional information over and above the basic ack:
  a) Message Structure OK - the different parts could be separated and
understood as well as the (SOAP) headers
  b) Message Parts valid - the different parts conform to their schemas
  c) Message passed to the application - i.e. the message has got beyond the
RM middleware and has been successfully passed to the application for
processing
  d) Message Valid - the message is completely valid and therefore there is
no reason why the message should not be processed successfully
  e) Message Processed.

On the other hand, 2b (and onwards) *could* just as easily be provided by
the application that is processing the message rather than the RM
Middleware. It all depends on your implementation.

It is also true that errors, as described above are relevant to choreography
as it will affect the action you take. I think the best way to solve this is
to separate:
1. The definition of the choreography, including the receipt of errors, from
2. The binding of the choreography to the messages.

That way you could detect the errors either in the RM Middleware or the
application and the choreography definition would not need to change.

Thoughts?

David

-----Original Message-----
From: Jean-Jacques Dubray [mailto:jjd@eigner.com]
Sent: Tuesday, March 18, 2003 2:55 PM
To: 'Yaron Y. Goland'; '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)



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 Wednesday, 19 March 2003 13:59:31 UTC