- 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>
Assaf: 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 event. JJ- >>-----Original Message----- >>From: public-ws-chor-request@w3.org [mailto: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- >>chor@w3.org >>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 and >>>if we can provide "compatibility" as a minimum and "verifiablity" as a >>>nice to have we would have done a great job. >>> >>>The notion of "observable behaviour" and the associated "bi-simulation" >>>are in essence how we should approach the issue of verfiability. We want >>>to ensure that "contracually" the external behaviour defined (allowable >>>message patterns over given states) is the observably equivalent to any >>>implementation. It doesn't matter if the implemetation is done over >>>BPML, Java, BPEL or even by people. If we can observe it as equivalent >>>then we can say it bi-simulates the externally defined behaviour and so >>>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 a >>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 communicating >>the event itself or by communicating the condition that leads to that >>event. And there are two ways you can communicate that stuff: by sending >>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 in >>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 you >>don't reply by 5pm, the order is canccelled". If it's after 5pm and you >>didn't call me, we can both conclude the order has been cancelled. >>There's no need for a second confirmation. >> >>arkin >> >>>Cheers >>> >>>Steve T >>> >>> >>>
Received on Friday, 11 April 2003 13:17:06 UTC