Here is a proposal for the completion condition - it addresses some issues not tackled so far (at
least not in case of <completeCondition>). It is a version of
the proposal for completion condition for the bundle element. This proposal
includes comments from many people including Frank Leymann, Dieter
Koenig, Dieter Roller and Satish Thatte. It does not mean that
they completely support the proposal - they may have issues with any part of
the proposal.
Completion condition
=====================
The current semantics of the flow activity is that it waits for all
concurrent activities to complete. The completion also means that an
enclosed activity/scope may end abnormally or be skipped (e.g. the join
condition of the activity evaluated to false). If a fault is thrown within
an enclosed activity/scope and one of the local fault handlers catch the
fault (and does not rethrow the fault), the enclosed activity/scope will be
deemed to be completed (although ended abnormally). If a fault is not caught
by any local fault handler (or is rethrown) the flow activity will terminate
all active concurrent activities and corresponding fault handler may be
initiated.
A completion condition for the flow activity is needed for scenarios
where not all concurrent activities of a flow activity must complete in
order the flow activity to complete. Note: We are not talking about
"successful completion" of enclosed concurrent activities because that would
not be consistent with the semantics of the current flow activity.
The completion condition may have different flavors, such
as:
(1) N out of M
(2) The two most important requests
completed
(3) A Boolean condition operating upon process
variables
Not all activities must complete in order the enclosing flow activity
to complete. The way to identify that an enclosed activity did not complete
is to propagate faults. We may distinguish between severe faults and those
that can be ignored. Severe faults cause the enclosing flow activity (or
more precisely, enclosing scope) to terminate the flow activity, including
all active concurrent activities, and corresponding fault handler may be
initiated. Other faults may be ignored - the flow activity is "informed"
that a concurrent activity did not complete but still allows other active
concurrent activities to continue with execution.
Ignore semantics
=================
Faults thrown within enclosed concurrent activities/scopes and not
handled by local fault handlers are rethrown. Enclosing <flow> element
decides which of these rethrown faults can be ignored. This new "ignore"
semantics should be part of the completion condition and should apply to all
enclosed activities. This new semantics does not introduce a new fault
handling mechanism. It is needed for identifying how many of the enclosed
activities failed.
Proposed syntax
================
<flow standard-attributes>
standard-elements
<completionCondition/>?
<links>?
<link name="ncname">+
</links>
activity+
</flow>
<completionCondition>
<conditions
branch="xsd:integer"?
expression=xpath?/>?
<ignoreFaults>?
<fault name="qname"? value="ncname"?/>*
<ignoreAll/>?
</ignoreFaults>
</completionCondition>
Attribute branch is used to specify a condition of flavor
"wait for N out of M activities to complete", or more
precisely value N. Attribute expression is used to specify a Boolean
condition operating upon process variables or
a condition of flavor "the two most important requests completed".
Both conditions (branch and expression) may be
specified at the same time. They will be checked when one instance of the
scope activity reaches the end. If at least one condition evaluates to true
all active instances will be terminated.
Element <ignoreFaults> specifies faults that may be ignored. Element fault is used to specify a fault which
may be ignored (fault name and fault data may be specified).
Element <ignoreAll> would mean that all faults thrown/rethrown by any concurrent
activity/scope may be ignored. If this element is
specified <fault> element must be
omitted.
Completion condition failure
=============================
A new standard fault, e.g. completionConditionFailure, should be
introduced to notify that the completion condition of a flow activity
evaluated to false (note: all concurrent activities have been completed).
The fault is thrown in the scope enclosing the flow element.
Completion condition and links
==============================
There should be no difference between a flow activity with a
completion condition and a flow activity without completion condition. For
example, if the completion condition fails all links leaving the flow
activity should have value "false" (or be reverted to a negative status).
There are just a few additional rules:
(1) Let's assume enclosed activity A is the source of a link. If the
completion condition evaluates to true and activity A is not completed it
will be terminated and the value of the link will be set to
"false".
(2) Let's assume enclosed activity A is the source of a link and the
activity failed but the fault is "ignored" by the enclosing flow activity.
The value of the link will be set to "false".
New function for completion condition of flavor "the two most
important requests completed"
============================================================================================
For completion conditions of flavor "the two most important requests
completed" standard attribute "name" must be specified for all enclosing
activities in order to be able to distinguish them. In addition a new
function, e.g. isCompleted('activityName') must be introduced. The semantics
of the function is: if activity completed successfully the function returns
value true.
Example
<completionCondition expression=
"isCompleted('A') AND isCompleted('B')"
</completionConditions>
Regards,
Ivana