Business Process Management (Part-2 Business Process Modelling[Chapter IV Process Orchestrations ] ) Sec H -- By Mathias Weske

Deferred Choice

Deferred choice is a state-based pattern. State-based patterns capture the implicit
behaviour of processes that is based not on the current case but rather on
the environment or other parts of the process. Some of the following patterns
require the existence of an external process that represents the environment.
This process is used as a source for external events.
A deferred choice is a point in a process model where one of several
branches is chosen. In contrast to the exclusive or split, the choice is not
made explicitly—for example, based on data values or a user decision—but
several alternatives are offered to the environment.
The environment activates one of the alternatives, and the other branches
are then withdrawn. Because the choice is delayed until one of the alternative
branches has actually been started, the moment of choice is deferred to a point
in time that is as late as possible.
Regarding the states of activity instances, each of the alternative branches
is represented by one activity instance in the init state. The state transition
from init to enabled is triggered by the environment, for instance, by sending
a message. After the state transition has occurred, the activity instances that
were not chosen enter the skipped state.
In that example, after a terminates, activity instances b, c, and d are created. Assuming that b is selected by receiving a message, b enters the enabled state, while c and d are
no longer required. Therefore, these activity instances are skipped.

Sequential Execution without A Priori Design Time Knowledge

The sequential execution without a prior design time knowledge pattern is
described as follows: a set of activity instances is executed sequentially in an
order that is decided at run time. No two activity instances of this set are
active at the same point in time.
Originally this pattern was called interleaved parallel routing; however,
this was somewhat misleading: The activity instances do not interleave, and
they are not executed in parallel. They are executed sequentially in an order
that is defined while the process instance runs. Therefore, in this book the
term sequential execution without a prior design time knowledge refers to this
pattern.
Activity models B,C,
and D are part of this pattern, so any sequential execution of activity instances
b, c and d are valid. This pattern is very useful in situations in which several
activities need to be executed sequentially and in any order. Since for any n
elements there are n! permutations, each of which corresponds to a sequential
execution ordering of n activity instances, modelling these explicitly is not
feasible.
The pattern can even be extended so that the execution ordering is not defined
before the first activity instance of the pattern has started. The sequence
can be defined also during the execution of the activity instances. A concrete
example is as follows: three persons need to work on a file, and each person
works on a separate part, so that the order in which the work is conducted is
not relevant. In this setting, after completing the first activity instance, one
person selects the next person to do his or her work.
The sequential execution in this case is induced by the single resource—
the file—that cannot be shared by the persons. Therefore, current allocation
of work to persons can be taken into account when deciding at run time on
the actual sequence in which the activities are executed.