I am having a little trouble figuring out the details of graph rewriting semantics for BPMN. The issue is merges (pesky things - should be banned).
In communication, message receive is by far the hardest to get right. It seems that in BPM, merge has a similar role: get merges right and nothing else will be a problem.
Anyway, in traditional graph rewriting, a new 'activity' is created by reading-off a new active copy from the original graph. This corresponds to beta substitution in functional languages. The trouble is that, compared to expressions, BPM graphs are decidedly not well formed: there are loops and all sorts without being specially marked.
Well, the issue is, when you copy off a new activity, how do you ensure that the existing activities are properly linked in to the new one. You can see this in the sequence above. (1) is the start point, and the problem shows up by (4). The (inclusive) merge has lots of connections going in, but only some of these are relevant.
You can't use special markers -- that would allow you to copy off bigger chunks of the graph, including subsequent merges from a split -- because BPMN does not have them!
Graph rewriting works in functional languages because a well defined chunk of the graph is rewritten at each stage: that chunk is defined by a particular pattern in the graph which is rewritten with a template (equation).
More thinking required I believe. It was such good idea too!
In communication, message receive is by far the hardest to get right. It seems that in BPM, merge has a similar role: get merges right and nothing else will be a problem.
Anyway, in traditional graph rewriting, a new 'activity' is created by reading-off a new active copy from the original graph. This corresponds to beta substitution in functional languages. The trouble is that, compared to expressions, BPM graphs are decidedly not well formed: there are loops and all sorts without being specially marked.
Well, the issue is, when you copy off a new activity, how do you ensure that the existing activities are properly linked in to the new one. You can see this in the sequence above. (1) is the start point, and the problem shows up by (4). The (inclusive) merge has lots of connections going in, but only some of these are relevant.
You can't use special markers -- that would allow you to copy off bigger chunks of the graph, including subsequent merges from a split -- because BPMN does not have them!
Graph rewriting works in functional languages because a well defined chunk of the graph is rewritten at each stage: that chunk is defined by a particular pattern in the graph which is rewritten with a template (equation).
More thinking required I believe. It was such good idea too!