[jboss-dev-forums] [Design of JBoss jBPM] - Re: meeting context

[tom.baeyens@jboss.com]

"heiko.braun at jboss.com" wrote : Let's look at a Parallel Gateway for example. To me, this is a core element. But it's semantics are not clear. Does a parallel split require a subsequent join or can both path of execution end differently? The answer to this question has a technical impact on the implementation  (i.e. threading, transactions) and thus an impact on the API.
  | 

indeed.  the crucial factor here is the runtime data structure which is exposed in the activity API. 

FWIW, jPDL 3 now has only 1 fork/join strategy and that is not the most common one.  The motivation for the jPDL 3 fork-join design was that it also could handle nested fork/join combinations.

The most common fork join is one which just counts the tokens/executions in the join.  In that case the unstructured fork/join combination (as ronald indicated graphically) works, but then nested fork/joins become a problem.

So my current intention is to have multiple types of forks and joins in jPDL4.  We also might spend some time thinking if we can combine both forms.  I have some ideas, but it's not all clear to me whether to what extend this is possible.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181185#4181185

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181185