"heiko.braun(a)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#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...