Deferred Choice (control flow pattern - WCP16) in OpenWFEru

[petia]

Hi John,

> About the implementation of the patternhttp://workflowpatterns.com/patterns/control/state/wcp16.php(this
> question would be a good fit for a workflow pattern mailing list,
> could we create a google group for that ?)

Nice idea! The group is created and a copy of this reply will be send
to there.

- Hide quoted text -
- Show quoted text -
> If I look at the description of the pattern, I have to acknowledge
> that my implementation proposal doesn't comply : a branch has to
> execute completely before the other branches are withdrawn
> (cancelled). I have the impression that the pattern wants us to
> withdraw as soon as one branch as started.

> On the other hand, I have looked at the implementations matrix and
> noticed that BPEL implements this patterns by using the pick activity,
> while jBPM implements it by letting two transitions exit an activity.
> In Ruote that would boil down to :

> <sequence>
> <participant ref="wait_for_external_event__or__choose" />
> <subprocess field-ref="choice" />
> </sequence>

> or

> <sequence>
> <participant ref="wait_or_choose" />
> <if test="${field:choice} == blue">
> <blue-branch />
> <other-branch />
> </if>
> </sequence>

> Granted, variant 2 (<if>) is not as "atomic" as the <pick> BPEL
> construct. In both variants and in BPEL and jBPM there is no
> "withdrawal". If I take a look at the flash animation of the pattern,
> I don't see any withdrawal either.

> Is the proposal/withdrawal essential to this pattern ?

Yes, the proposal/withdrawal is essential to this pattern.

In workflow context two types of choices can be distinguished: 1) a
choice made by the (workflow management) system; and 2) a choice made
by the environment or the user. In the first case the choice is based
on data available to the system at the moment of choice. (This choice
is often referred to as an explicit choice.) In the second case the
choice is made "on the fly" and the data on which the choice is based
may not necessarily be available to the system. (This choice is
sometimes called implicit choice). The subtle difference is that in
the second case the choice on how the flow of execution will continue
is deferred until the actual moment of initiation of the corresponding
path/tasks. In order to make such a choice possible all alternative
paths/tasks need to be presented (i.e., enabled) to the environment/
user (as shown in the pattern animation). The moment the user makes
the choice (i.e., initiates one of the alternative branches/tasks) the
other alternatives gets automatically disabled (this is what I meant
with withdraw earlier). Note that a system could ask a user to enter
his/her choice in a preceding task (i.e., the second solution you
propose above). Then based on the data entered by the user, the system
could direct the flow to the corresponding path/task. Note, however,
that in this case the actual execution of the selected task can start
a lot later than the moment of choice.

I hope this explanation will help. If not, I would recommend the
following article "Three Good Reasons for Using a Petri-net-based
Workflow Management System" by Wil van der Aalst available on
http://is.tm.tue.nl/staff/wvdaalst/publications/p37.pdf

Kind regards, Petia

[John Mettraux]

Hello Petia,

thanks a lot for the explanation. Sorry for the OpenWFEru/Ruote spam,
but would this :

<sequence>
<participant ref="whoever_or_whatever" activity="decide" />
<if test="${field:decision} == branch_a">
<branch_a />
<branch_b />
</if>
</sequence>

or

<step ref="whoever_or_whatever" outcomes="branch_a, branch_b" />

(http://openwferu.rubyforge.org/expressions.html#exp_step)

represent of valid implementation of the pattern ?

Kind regards,

--
John Mettraux - http://jmettraux.wordpress.com

[petia]

Hi John,

> Sorry for the OpenWFEru/Ruote spam,

No worries, any discussions of the patterns are welcome to this forum!

> <sequence>
>   <participant ref="whoever_or_whatever" activity="decide" />
>   <if test="${field:decision} == branch_a">
>     <branch_a />
>     <branch_b />
>   </if>
> </sequence>

This is the Exclusive Choice pattern (WCP 4).

> <step ref="whoever_or_whatever" outcomes="branch_a, branch_b" />

I tried the behaviour of this construct (see the process definition
below). Unfortunately, it did not work for me. After executing <step
ref="bob" I got the message that the workitem has processed but none
of the sub-processes was invoked. I also tried the default attribute,
e.g default="two" and it worked nicely. (If you identify the error in
my code, please let me know.)

However, my feeling is that this construct provides a solution for
the Exclusive Choice pattern (WCP 4). Deferred choice indicates that
the actual choice is deferred to as late as possible. In many systems
and also in OpenWFEru this means that the choice is deferred to the
moment when a task/branch is started and no longer offered. (In
systems which distinguish between allocated and started states for a
workitem, the moment of choice is deferred until the work item is
allocated to a resource and hence no longer offered.) This does not
seem to be the case with the <step> construct. A sub-process (i.e.
thread) is indeed invoked (i.e. selected) as a consequence of the
execution of the <step> construct, but the task (hence the branch it
belongs to) is in state "offered" and not yet "started". Hence the
choice is not deferred, but is the traditional exclusive choice (WCP
4).


Kind regards, Petia

-------------------------------------------------------
<process-definition
name="step"
revision="1">

<description>step process</description>


<step ref="bob" outcomes="two, three" />

<!-- Subprocesses -->

<process-definition name="two">
<participant ref="alpha" description="two" />
</process-definition>


<process-definition name="three">
<participant ref="petia" description="three" />
</process-definition>

</process-definition>
-------------------------------------------------------------

[John Mettraux]

On Mon, Jul 28, 2008 at 10:23 AM, petia <petia...@gmail.com> wrote:
>
> I tried the behaviour of this construct (see the process definition
> below). Unfortunately, it did not work for me. After executing <step
> ref="bob" I got the message that the workitem has processed but none
> of the sub-processes was invoked. I also tried the default attribute,
> e.g default="two" and it worked nicely. (If you identify the error in
> my code, please let me know.)

Hi Petia,

of course, I forgot to mention that the next step is identified by the
value of the workitem field named "outcome". It worked well, when you
had the default value set. If there is no outcome proposed, the step
expression simply replies to its parent expression.

> However, my feeling is that this construct provides a solution for
> the Exclusive Choice pattern (WCP 4). Deferred choice indicates that
> the actual choice is deferred to as late as possible. In many systems
> and also in OpenWFEru this means that the choice is deferred to the
> moment when a task/branch is started and no longer offered. (In
> systems which distinguish between allocated and started states for a
> workitem, the moment of choice is deferred until the work item is
> allocated to a resource and hence no longer offered.)

OK, understood. OpenWFEru (ruote) definitely doesn't support "Deferred
Choice" WCP 16, I will update my documentation.

Thanks a lot, best regards,

[petia]

Hi John

> I forgot to mention that the next step is identified by the
> value of the workitem field named "outcome".

I did that (thanks for your reply). The name "outcome" is self
explanatory and the documentation for it ok, so in run-time I entered
a correct value. It did not work thought, it did not invoked the
corresponding sub-process. I tried the attribute "default" to see
whether it would invoke the specified sub-process and to make sure I
had done the sub-process definition correctly. Default worked nicely.

I believe that the construct

<concurrence count="1" remaining="cancel">
<reserve mutex="safe">
<participant ref="task1A" />
</reserve>
<reserve mutex="safe">
<participant ref="task1B" />
</reserve>
</concurrence>

if working as a concurrence could be used to simulate a deferred
choice for task1A and task1B in OpenWFEru (Ruote).

Please, let me know if you do any changes on the semantics i.e. the
current behaviour of this construct. I am very interested to know.

Kind regards, Petia

[ro...@cs.unibo.it]

On Jul 24, 4:17 pm, petia <petia.wo...@gmail.com> wrote:
<...>

> In the second case the
> choice is made "on the fly" and the data on which the choice is based
> may not necessarily be available to the system. (This choice is
> sometimes called implicit choice). The subtle difference is that in
> the second case the choice on how the flow of execution will continue
> is deferred until the actual moment of initiation of the corresponding
> path/tasks. In order to make such a choice possible all alternative
> paths/tasks need to be presented (i.e., enabled) to the environment/
> user (as shown in the pattern animation).

This is the usual behavior of (C)PN-inspired languages.
On course it only makes sense if the tasks to be activated are "pull"
tasks, i.e. tasks that are "taken into execution", rather than "push"
tasks, like invocations.
If you have two tasks that are, say, invocation to web services (and
you model them with a PN transition) you can put a place between the
two but this is not a deferred choice, it is just an invalid
construct. From this point of view, I have to admit, the distinction
among different type of tasks made by BPMN makes a lot of sense.

> The moment the user makes
> the choice (i.e., initiates one of the alternative branches/tasks) the
> other alternatives gets automatically disabled (this is what I meant
> with withdraw earlier). Note that a system could ask a user to enter
> his/her choice in a preceding task (i.e., the second solution you
> propose above). Then based on the data entered by the user, the system
> could direct the flow to the corresponding path/task. Note, however,
> that in this case the actual execution of the selected task can start
> a lot later than the moment of choice.

Isn't that true also for the solution you propose for BPMN? The
intermediate events after the event-based exclusive gateway do not
enforce the subsequent activity to be fired "at the same time".
Suppose this is a service task, the corresponding service can be
called as soon as the enactment engine decides to do so (which can be
in any later moment).

Regards,
Davide.

[petia]

Hi Davide,

Welcome to the group!

> > The moment the user makes
> > the choice (i.e., initiates one of the alternative branches/tasks) the
> > other alternatives gets automatically disabled (this is what I meant
> > with withdraw earlier). Note that a system could ask a user to enter
> > his/her choice in a preceding task (i.e., the second solution you
> > propose above). Then based on the data entered by the user, the system
> > could direct the flow to the corresponding path/task. Note, however,
> > that in this case the actual execution of the selected task can start
> > a lot later than the moment of choice.
>
> Isn't that true also for the solution you propose for BPMN? The
> intermediate events after the event-based exclusive gateway do not
> enforce the subsequent activity to be fired "at the same time".
> Suppose this is a service task, the corresponding service can be
> called as soon as the enactment engine decides to do so (which can be
> in any later moment).

You refer to the discussion on http://is.tm.tue.nl/staff/wvdaalst/BPMcenter/reports/2006/BPM-06-17.pdf
page 11.
We can agree on that the choices made in Fig. 9 a,b and c (on page 11)
are not based on data present in the system (i.e. the models in these
figure do not capture the exclusive choice patter,
http://www.workflowpatterns.com/patterns/control/basic/wcp4.php). They
are deferred to a later moment, (in this case the moment of the
occurrence of the external event or the receipt of the a message). OK,
I see my statement above "the actual execution of the selected task
can start a lot later" is a bit strong. I was just trying to explain
the term "deferred" choice. If my extra explanation is confusing you
(instead of helping you) please refer to the definition of the pattern
"deferred choice" on http://www.workflowpatterns.com/patterns/control/state/wcp16.php.

Cheers, Petia