Cyclic graphs considered harmful Was: [wsbpel] implicite links ofthe runtime engine (was: Implicit <sequence> macro)

[Assaf Arkin <arkin@intalio.com>]

Frank Leymann wrote:

>Edwin,
>
>this was EXACTLY my reaction too!
>
>Assaf,
>
>I would appreciate an example of a business process that contains "wild
>cycles", and I would like to see a written down description of what the
>semantics of these loops are (two "intersecting" cycles suffice), a
>description of how you cope with races in the process, with one and the
>same activity being activited multiple time and at the same time (!), with
>concurrency issues on affected variables etc.. Thanks!
>
Let's begin with some clarification of operational semantics first. If 
it's any help, I'm volunteering to help beef up that portion of the spec 
to make it more clear for implementors.

The language discussing scopes and event handlers seem to suggest that 
two instances of the same event handler could be ongoing concurrently in 
the same scope. On the other hand the operational semantics only allow 
an event handler to respond to one message at a time, though multiple 
*different* event handlers can be going in parallel. I'm not clear 
whether the spec intended to allow the former, or restrict it to the 
later, or just avoid any judgement call. I read 'same activity being 
activated multiple times' as an intent to only allow the later, but 
further clarification would help.

Let's say we have two event handlers, we'll call them EH1 and EH2. Each 
event handler excepts an input message, M1 and M2 respectively, and 
performs some activity A1 and A2 respectively. Note that there is no 
restriction on how many messages would be received, in what order, 
whether EH1 and EH2 would execute at different or overlapping times. 
This trivial process has some non-deterministic logic.

The question now becomes, how do we cope with 'races in the process' and 
'concurrency issues on affected variables'. Would it be safe to assume 
there's a solution to that problem? Can we harness that solution to deal 
with cyclic graphs?

Now for the magic trick of the night. We allow both A1 and A2 to send 
(directly or indirectly*) messages M1 and M2. Effectively, A1 can start 
A1 again, or start A2, and A2 can start A2 again or start A1 (or both or 
neither). I believe this would classify as two intersecting cycles. Is 
this precluded in the spec? Do any new issues emerge that do not exist 
in other usages of event handlers? What am I missing?

arkin
 
(*) Directly: to get around the WSDL 1.1 restriction regarding two ports 
for same service we can define the process as exposing two different 
services one for EH1 and one for EH2. Indirectly: we can just have a 
process that receives the message from A1 or A2 and routes it back to 
EH1 or EH2. Or for the more classical example, we can just say that the 
result of A1/A2 is that some user decides to send message M1 or M2 to 
the process (which alludes to the expected use case)..