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

RE: Internal processes and/or external choreographies (was RE: Ev ents and States ...

From: Jean-Jacques Dubray <jjd@eigner.com>
Date: Fri, 11 Apr 2003 13:17:40 -0400
To: "'Assaf Arkin'" <arkin@intalio.com>, <steve@enigmatec.net>
Cc: "'Cummins, Fred A'" <fred.cummins@eds.com>, "'Burdett, David'" <david.burdett@commerceone.com>, <jdart@tibco.com>, <public-ws-chor@w3.org>
Message-ID: <001501c3004e$55066f40$0502a8c0@JJD>


I am not sure I understand you argument about event. All the examples
that you give for an event seem to b e responses to a request, but how
do you model the request itself as a message event? In my opinion, it is
really the completion of a message exchange pattern that constitutes an


>>-----Original Message-----
>>From: public-ws-chor-request@w3.org
>>On Behalf Of Assaf Arkin
>>Sent: Friday, April 11, 2003 12:49 PM
>>To: steve@enigmatec.net
>>Cc: 'Cummins, Fred A'; 'Burdett, David'; jdart@tibco.com; public-ws-
>>Subject: Re: Internal processes and/or external choreographies (was
RE: Ev
>>ents and States ...
>>Steve Ross-Talbot wrote:
>>>I'd like to echo Fred's comments. I think external is the way to go
>>>if we can provide "compatibility" as a minimum and "verifiablity" as
>>>nice to have we would have done a great job.
>>>The notion of "observable behaviour" and the associated
>>>are in essence how we should approach the issue of verfiability. We
>>>to ensure that "contracually" the external behaviour defined
>>>message patterns over given states) is the observably equivalent to
>>>implementation. It doesn't matter if the implemetation is done over
>>>BPML, Java, BPEL or even by people. If we can observe it as
>>>then we can say it bi-simulates the externally defined behaviour and
>>>meets the contract.
>>>One issue I am less sure on is the issue of time. If observable
>>>behaviour is allowable message patterns over given states, what role
>>>does time play in all of this? Does it have a role? Thoughts .....
>>The basic premise is that you treat everything as events and you find
>>way to agree on the occurrence of events. This also ties the
>>choreography to other models the express everything in terms of events
>>(e.g. various distributed and consensus algoritms).
>>There are two ways you can agree on an event occuring. By
>>the event itself or by communicating the condition that leads to that
>>event. And there are two ways you can communicate that stuff: by
>>messages (events) or by agreeing to use a particular choreography (a
>>form of communication in itself).
>>An event like 'order completed' is explicitly communicated from seller
>>to buyer. An event like 'order completed notificiation time-out' is
>>fired internally by each service, but the fact that this event will
>>occur at the same time for both buyer and seller is communicated, e.g.
>>as part of the purchase order message, or by agreeing to participate
>>the same choreography. By agreeing in one way or the other when the
>>time-out would occur, both buyer and seller are synchronized with each
>>other, even if they don't exchange messages to signify the event.
>>This is much like the real world. In the real world I can call you and
>>say "your order has completed" (possibly leaving you a voice mail) and
>>we both know the order has completed. Or I can call you and say "if
>>don't reply by 5pm, the order is canccelled". If it's after 5pm and
>>didn't call me, we can both conclude the order has been cancelled.
>>There's no need for a second confirmation.
>>>Steve T
Received on Friday, 11 April 2003 13:17:06 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:00:58 UTC