- From: Assaf Arkin <arkin@intalio.com>
- Date: Fri, 20 Jun 2003 08:53:00 -0700
- To: Jean-Jacques Dubray <jjd@eigner.com>
- CC: public-ws-chor@w3.org, "'Martin Chapman'" <martin.chapman@oracle.com>
Just a small reminder. There is indeed a species of process calculus that is deterministic. The type of process calculus models we are talking about (pi-calculus and friends) definitely supports non-determinism. If it didn't support any of the following, we wouldn't be able to use it even for the trivial case: - X or Y (or Z or ...) (conditional) - X followed by X or Y (iterative) - zero or more X until Y (recursive) where X, Y, etc can be messages, time events, faults, etc. arkin Jean-Jacques Dubray wrote: >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 > >
Received on Friday, 20 June 2003 11:53:28 UTC