[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue 6 - Rough draft of proposal for vote
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
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]