forks, joins and modelling constraints (impacts release schedule)
"Tom Baeyens" <[email protected]> Thu, 16 Oct 2003 23:39:22 +0200
| Newsgroups | gmane.comp.jbpm.user |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
------=_NextPart_000_0018_01C3943E.B9E54740
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Hi all,
I had an interesting discussion about fork, joins and concurrent blocks with Pascal Labbe that I want to share with you. So I put
it on the forums : https://sourceforge.net/forum/forum.php?thread_id=954442&forum_id=260700 Pascal convinced me to relax the
constraints on forks, joins and concurrent blocks. Recap that now one fork corresponds with one join in a concurrent-block and that
no transition may cross concurrent-block boundaries. Before I will start to update jBpm to this model, I would like to ask the
opinion of the jBpm community.
The changes to the model would be as follows :
* the notion of concurrent-block would be dropped.
* In the easiest scenario we would model a fork the spawns a flow for every leaving transition, that are all synchronized in a join
(the same as what we now model with a concurrent-block) :
<fork name="f" join="j" />
<join name="j" fork="f" />
* for every flow that is forked, the parent-flow and a name for the child-flow must be specified. This results in a the same
hierarchical flow-structure as before. As a default, the parent-flow is the flow that arrives in the join and the
fork-leaving-transition-names are taken as the child-flow-names. The forkFlow method of the ForkContext would allow to specify the
parent flow and the flow-name.
<fork name="f" handler="com.mycompany.MyForkHandler"/>
Another syntax that could be supported would be e.g.
<fork name="f">
<flow parent="flow://root/f3" name="childone" transition="approve" />
<flow parent="flow://root/f4" name="childtwo" transition="approve" />
<flow parent="flow://root/f4" name="childthree" transition="disapprove" />
</fork>
* every join would then specify which flows it has to join.
<join name="j">
<flow name="flow://root/f1/f2"; />
<flow name="flow://root/f3"; />
<flow name="flow://root/f4/f5/**"; />
</join>
This would make the constraints on the concurrent flows looser. But the runtime model would still be deterministic (a
non-deterministic model requires that forks scan the complete runtime state of a process instance to see if there is a flow that
could arrive in that join) And in my opinion these changes do not introduce extra complexity for the beginning process modeller.
I'm interested to hear your opinion on the forum !
I'm about to release the beta6. If this change is accepted it will be incorporated before the 1.0 final, which would imply that
that release comes later then expected.
Regards, Tom.
------=_NextPart_000_0018_01C3943E.B9E54740
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2715.400" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D795170821-16102003><FONT face=3DArial size=3D2>Hi=20
all,</FONT></SPAN></DIV>
<DIV><SPAN class=3D795170821-16102003><FONT face=3DArial=20
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D795170821-16102003><FONT face=3DArial size=3D2>I had =
an interesting=20
discussion about fork, joins and concurrent blocks with Pascal Labbe =
that I want=20
to share with you. So I put it on the forums : </FONT></SPAN><SPAN =
class=3D795170821-16102003><FONT face=3DArial size=3D2><A=20
href=3D"https://sourceforge.net/forum/forum.php?thread_id=3D954442&fo=
rum_id=3D260700">https://sourceforge.net/forum/forum.php?thread_id=3D9544=
42&forum_id=3D260700</A> =20
</FONT></SPAN><SPAN class=3D795170821-16102003><FONT face=3DArial =
size=3D2>Pascal=20
convinced me to relax the constraints on forks, joins and concurrent=20
blocks. Recap that now one fork corresponds with one join in a=20
concurrent-block and that no transition may cross concurrent-block=20
boundaries. </FONT></SPAN><SPAN class=3D795170821-16102003><FONT =
face=3DArial=20
size=3D2>Before I will start to update jBpm to this model, I would like =
to ask the=20
opinion of the jBpm community.</FONT></SPAN></DIV>
<DIV><SPAN class=3D795170821-16102003><FONT face=3DArial=20
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D795170821-16102003><FONT face=3DArial size=3D2>The =
changes to the=20
model would be as follows : </FONT></SPAN></DIV>
<DIV><SPAN class=3D795170821-16102003><FONT face=3DArial=20
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D795170821-16102003><FONT face=3DArial size=3D2>
<DIV><SPAN class=3D795170821-16102003><FONT face=3DArial =
size=3D2> * the notion=20
of concurrent-block would be dropped.</FONT></SPAN></DIV> * In the =
easiest=20
scenario we would model a fork the spawns a flow for every leaving =
transition,=20
that are all synchronized in a join (the same as what we now model with =
a=20
concurrent-block) : </FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
<DIV><SPAN class=3D795170821-16102003><FONT face=3D"Courier =
New"><fork name=3D"f"=20
join=3D"j" /> <BR><join name=3D"j" fork=3D"f"=20
/></FONT></SPAN></DIV></BLOCKQUOTE>
<DIV><SPAN class=3D795170821-16102003><FONT face=3DArial =
size=3D2> * for every=20
flow that is forked, the parent-flow and a name for the child-flow must =
be=20
specified. This results in a the same hierarchical flow-structure =
as=20
before. As a default, the parent-flow is the flow that arrives in the =
join and=20
the fork-leaving-transition-names are taken as the =
child-flow-names. The=20
forkFlow method of the ForkContext would allow to specify the parent =
flow and=20
the flow-name.</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
<DIV><SPAN class=3D795170821-16102003><FONT face=3DArial =
size=3D2><SPAN=20
class=3D795170821-16102003><FONT face=3D"Courier New"><FONT =
size=3D3><fork=20
name=3D"f"=20
=
handler=3D"com.mycompany.MyForkHandler"/></FONT></FONT></SPAN></FONT><=
/SPAN></DIV></BLOCKQUOTE>
<DIV><SPAN class=3D795170821-16102003><FONT face=3DArial =
size=3D2>Another syntax that=20
could be supported would be e.g. </FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
<DIV><SPAN class=3D795170821-16102003><FONT face=3DArial><SPAN=20
class=3D795170821-16102003><FONT face=3D"Courier New"><fork =
name=3D"f">=20
</FONT></SPAN></FONT></SPAN></DIV>
<DIV><SPAN class=3D795170821-16102003><FONT face=3DArial><SPAN=20
class=3D795170821-16102003><FONT face=3D"Courier New"><SPAN=20
class=3D795170821-16102003><FONT face=3DArial><SPAN =
class=3D795170821-16102003><FONT=20
face=3D"Courier New"> <flow parent=3D"<A =
href=3D'flow://root/f3"'=20
target=3D_new><FONT face=3D"Courier New">flow://root/f3</FONT></A>"=20
name=3D"childone" transition=3D"approve"=20
/><BR></FONT></SPAN></FONT></SPAN><SPAN =
class=3D795170821-16102003><FONT=20
face=3DArial><SPAN class=3D795170821-16102003><FONT face=3D"Courier =
New"> =20
<flow parent=3D"<FONT face=3D"Courier New">flow://root/f</FONT>4"=20
name=3D"childtwo" transition=3D"approve"=20
/><BR></FONT></SPAN></FONT></SPAN><SPAN =
class=3D795170821-16102003><FONT=20
face=3DArial><SPAN class=3D795170821-16102003><FONT face=3D"Courier =
New"> =20
<flow parent=3D"<FONT face=3D"Courier New">flow://root/f4</FONT>"=20
name=3D"childthree" transition=3D"disapprove"=20
=
/><BR></FONT></SPAN></FONT></SPAN></fork></FONT></SPAN></FONT></=
SPAN></DIV></BLOCKQUOTE>
<DIV><SPAN class=3D795170821-16102003><FONT face=3DArial =
size=3D2> * every join=20
would then specify which flows it has to join. </FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
<DIV><SPAN class=3D795170821-16102003><FONT face=3D"Courier =
New"><join=20
name=3D"j"><BR> <flow name=3D"</FONT><A =
href=3D'flow://root/f1/f2"'=20
target=3D_new><FONT face=3D"Courier =
New">flow://root/f1/f2"</FONT></A><FONT=20
face=3D"Courier New">; /> <BR> <flow name=3D"</FONT><A=20
href=3D'flow://root/f3"' target=3D_new><FONT=20
face=3D"Courier New">flow://root/f3"</FONT></A><FONT face=3D"Courier =
New">; />=20
<BR> <flow name=3D"</FONT><A href=3D'flow://root/f4/f5/**"'=20
target=3D_new><FONT face=3D"Courier =
New">flow://root/f4/f5/**"</FONT></A><FONT=20
face=3D"Courier New">; =
/><BR></join></FONT></SPAN></DIV></BLOCKQUOTE>
<DIV><SPAN class=3D795170821-16102003><FONT face=3DArial size=3D2>This =
would make the=20
constraints on the concurrent flows looser. But the runtime model =
would=20
still be deterministic (a non-deterministic model requires that forks =
scan the=20
complete runtime state of a process instance to see if there is a flow =
that=20
could arrive in that join) And in my opinion these =
changes do=20
not introduce extra complexity for the beginning process modeller.=20
</FONT></SPAN><SPAN class=3D795170821-16102003><FONT face=3DArial =
size=3D2>I'm=20
interested to hear your opinion on the forum !</FONT></SPAN></DIV>
<DIV><SPAN class=3D795170821-16102003><FONT face=3DArial size=3D2>I'm =
about to release=20
the beta6. If this change is accepted it will be incorporated =
before the=20
1.0 final, which would imply that that release comes later then=20
expected.</FONT></SPAN></DIV>
<DIV><SPAN class=3D795170821-16102003><FONT face=3DArial=20
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D795170821-16102003><FONT face=3DArial =
size=3D2>Regards,=20
Tom.</FONT></SPAN></DIV></BODY></HTML>
------=_NextPart_000_0018_01C3943E.B9E54740--
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php