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

Re: Why event calculus might be the right model

From: Assaf Arkin <arkin@intalio.com>
Date: Fri, 20 Jun 2003 08:53:00 -0700
Message-ID: <3EF32DDC.1070503@intalio.com>
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.


Jean-Jacques Dubray wrote:

>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
>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).
Received on Friday, 20 June 2003 11:53:28 UTC

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