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

I completely agree in fact this is what I was trying to suggest. They are
separate and can be done in multiple different ways. However the outcome of
the validation does affect choreography and therefore we need to consider
whether or not for common web service related errors, e.g. XML errors in the
body of a soap message, we want to have standard ways of representing the
information. It's just a question.

David

-----Original Message-----
From: Jean-Jacques Dubray
To: 'Burdett, David'; 'Jean-Jacques Dubray'; 'Yaron Y. Goland'; 'Furniss,
Peter'; 'Monica J. Martin'; public-ws-chor@w3.org
Cc: 'Ricky Ho'
Sent: 3/19/2003 11:12 AM
Subject: RE: two-phase (from RE: General Choreography and Bi-lateral
Choreography)

David:

We should not make any assumption about where the code that validates a
particular conditions lives. If you are like a big A&D company I know
and have 84 procurement systems you probably want to do a lot of
validation upstream rather than repeating the code in each application.

We should also be careful on associating "message valid" with "message
will be processed". Let's say you release a bill of material, and as
part of this process you are "synch-ing" your PLM system with your ERP
system. The BOM message can be perfectly valid but the BOM update in the
ERP may fail because one of the part of the BOM has not been created.
Then you need a way to say that ultimately there was a "process failure"
and that the state of the ERP and the PLM system could not be
synchronized (this could also be true between two PLM systems one at the
OEM and the other at one of its supplier).

One of the reason of separation validation from processing is precisely
to enable centralization of the validation function. Some implementation
will be very simple and clearly the implementation of a service can also
take on validation.

JJ- 
 
 

>>-----Original Message-----
>>From: Burdett, David [mailto:david.burdett@commerceone.com]
>>Sent: Wednesday, March 19, 2003 1:59 PM
>>To: Jean-Jacques Dubray; '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)
>>
>>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 18:04:20 UTC