- From: Jean-Jacques Dubray <jjd@eigner.com>
- Date: Fri, 20 Jun 2003 07:46:03 -0400
- To: <public-ws-chor@w3.org>
- Cc: "'Martin Chapman'" <martin.chapman@oracle.com>
Martin: I wanted to emphasize on one point. Choreographies are a very peculiar piece of software engineering because they can be non-derterministic. In other words, it is very common that in a choreography you define a series of possible MEPs, of which only one of them will occur during any given instance, but you cannot express which one will happen (the logic to select the one is of course outside the choreography definition, so the overall system is deterministic, but not this subsystem). This is typically what I label a "XOR-split". Another non-deterministic aspect is the "recursivity" I was talking about. An orchestration process is deterministic and so is pi-calculus (I think). I am not a specialist, but I am under the impression that each time you have to express the behavior of such non-deterministic system, events are the way to go. This formalism let you describe all the possibilities (hanging off a given event) without assuming anything about how the event is generated. In any case, my recommendation is that we check any formalism to see how this non-deterministic case can be handled, and also how "recursivity" can be dealt with (i.e. a message can be sent any number of time, during a certain period or until another message "disables" this possibility). Cheers, Jean-Jacques >>-----Original Message----- >>From: Jean-Jacques Dubray [mailto:Jean-Jacques.Dubray@eigner.com] >>Sent: Freitag, 20. Juni 2003 07:30 >>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 Friday, 20 June 2003 07:46:59 UTC