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

Handling Error States (was: RE: BPSS_f2f_june03.ppt

From: Burdett, David <david.burdett@commerceone.com>
Date: Tue, 24 Jun 2003 08:24:17 -0700
Message-ID: <C1E0143CD365A445A4417083BF6F42CC08391B92@C1plenaexm07.commerceone.com>
To: Jean-Jacques Dubray <jjd@eigner.com>, "'Ugo Corda'" <UCorda@SeeBeyond.com>, public-ws-chor@w3.org

JJ

I agree with your idea of "building in" handling for common error conditions
however, instead of specifying actual messages, I would specify the "states"
that sending a message would cause. This means that the WS-Chor group could
define several standard states such as, to quote from your email ...
"success ... failure ... timeout ... structure invalid ... content invalid"
etc.

Then in an implementation you could bind the sending of specific messages to
these choreography states whilst still allowing different message structures
and delivery methods. The main reason I suggest this is that I KNOW that
other groups (e.g. UBL) are thinking about defining message structures for
exactly this purpose. If WS-Chor were to define the XML message structures
as well then there would be unnecessary competion.

So basically I think we should define the semantics and leave the
representatio to others.

Thoughts?

David
PS As Steve has requested, I am changing the subjects on this string of
emails whenever the content is significantly different from the original
email



-----Original Message-----
From: Jean-Jacques Dubray [mailto:jjd@eigner.com]
Sent: Friday, June 20, 2003 4:30 AM
To: 'Ugo Corda'; 'Jean-Jacques Dubray'; public-ws-chor@w3.org
Subject: RE: BPSS_f2f_june03.ppt



Ugo:

Basically a choreography protocol is needed to ensure that each peer in
the choreography has the same view of the state in which the
choreography instance is. Imagine a situation, where you send me a PO
and I am not supposed to respond until the goods are shipped and I will
respond by sending you an invoice. So you send me a PO and the RM tells
you "I got it" (just like a fax). The next thing that should happen then
is you receive the goods and later on an invoice. If there was a human
behind a fax machine, and the order was garbled he could call and figure
out the right information. In this case, the sender things the
choreography is going ok. The responder on the contrary thinks that the
collaboration is terminated on an error. This is why you need a
protocol: to tell you that no exception occurred, each party has the
same view of the state of the choreography.

If you take a "highly-connected" system that has several hundred /
thousands participants (not all participating in the same choreography
instance but rather having 2 by 2 conversations). You cannot expect that
every message that will be exchanged in this setting would be of high
quality (the structure may be old or wrong, the content may be
incoherent making the processing of the message impossible, i.e. a
response cannot be created because the message could not get into the
system that was supposed to create the response). 

At this point, you can say I don't need/want a protocol. That means that
when a choreography is designed, the designers must account for these
possible (yet common) errors. They will create specific messages to say
"could not process your orders, it contains errors", and make these
messages part of the choreography.

On the other hand if you had a protocol, you would have a standard set
of exceptions (common to all message exchanges) and materialized with a
set of standard messages. You could then express the choreography paths
based on these error conditions (if success ... if failure ... if
timeout ... if structure invalid ... if content invalid ...) with an
implicit message exchange. The simplest set of exception for me are:
message did not get there on time, message could not be processed by
system/service of record.

Again, all this has nothing to do with RM. The problem here is not that
your message did not get to the recipient, it is rather that the
recipient got a message that he could not process, hence interrupting
the choreography instance. A protocol would help you cover 80/90% of the
common exceptions. Others can be dealt with at the design level.

Cheers,

Jean-Jacques Dubray____________________
Chief Architect
Eigner  Precision Lifecycle Management
200 Fifth Avenue
Waltham, MA 02451
781-472-6317
jjd@eigner.com
www.eigner.com 
 
 

>>-----Original Message-----
>>From: Ugo Corda [mailto:UCorda@SeeBeyond.com]
>>Sent: Donnerstag, 19. Juni 2003 22:14
>>To: Jean-Jacques Dubray; public-ws-chor@w3.org
>>Subject: RE: BPSS_f2f_june03.ppt
>>
>>Jean-Jacques,
>>
>>I did not have a chance to listen to your presentation, so you might
have
>>already explained this. In your slides you talk about a "choreography
>>protocol", and I am not sure whether it is just regular messages plus
an
>>instance ID (as you mentioned in a previous message to the list) or it
is
>>more than that.
>>
>>Thank you,
>>Ugo
>>
>>> -----Original Message-----
>>> From: Martin Chapman [mailto:martin.chapman@oracle.com]
>>> Sent: Thursday, June 19, 2003 12:18 PM
>>> To: public-ws-chor@w3.org
>>> Subject: FW: BPSS_f2f_june03.ppt
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Jean-Jacques Dubray [mailto:jjd@eigner.com]
>>> Sent: Thursday, June 19, 2003 10:23 AM
>>> To: 'Martin Chapman'; 'Steve Ross-Talbot';
Daniel_Austin@grainger.com
>>> Subject: BPSS_f2f_june03.ppt
>>>
>>>
>>> Martin et al:
>>>
>>> This is my presentation for this afternoon. Please let me
>>> know what time
>>> and which number to call.
>>>
>>> Best regards,
>>>
>>> JJ-
>>> 781-472-6317
>>>
Received on Tuesday, 24 June 2003 11:24:24 GMT

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