[wsbpel] Issue 190 - Proposal For Vote

[Dieter Koenig1 <dieterkoenig@de.ibm.com>]

Revised resolution proposal for issue 190.

Changes included in the wording below:
(1) Apply this 190 issue resolution to all standard faults except
"bpws:joinFailure".
(2) Change the default for the process attribute "exitOnStandardFault" to
"no".
(3) Similar to "suppressJoinFailure", the default for the
"exitOnStandardFault" is inherited from the actual attribute value on the
enclosing scope or process.

Proposed changes *not* included in the wording below:
(-) There has been a proposal to ignore exitOnStandardFault="yes" if there
is an explicit fault handler for a particular standard fault. I would
prefer not doing so in order to keep more consistency with the behavior for
"bpws:joinFailure". If one has an explicit fault handler for
"bpws:joinFailure" and specify suppressJoinFailure="yes", then the fault
handler will never be executed. The same should apply for
exitOnStandardFault="yes", i.e., explicit fault handlers for standard
faults are not executed.
(-) There has been a proposal to move the attribute exitOnStandardFault to
the catchAll element. I prefer not doing so in order to keep the behavior
consistent between explicit and implicit catchAll fault handlers. For the
latter, one obviously cannot specify an attribute.

================================================

Submitter's proposal: Standard faults (except "bpws:joinFailure") generally
represent modeling errors. There exist BPEL processes that would not want
to handle BPEL standard faults, in particular in catchAll fault handlers,
and would like to be able to indicate that on the process definition.

Instead of allowing processes to catch these as standard faults, we propose
that the process instance can *exit* immediately when such a situation is
encountered.

Rationale: The behavior of "exit" is well-defined in BPEL -- as far as BPEL
is concerned the instance execution ends when exit is encountered without
any fault handling behavior. Additional facilities for extended support
for, e.g., repair and continue, are definitely out of scope.

In order to support the behavior suggested here and also allow process
modelers to continue using the current behavior, an explicit boolean
attribute can be added to the <process> and <scope> elements:
   <process/scope ... exitOnStandardFault="yes|no" ...>

================================================
Section 6.2. The Structure of a Business Process
Add a new bullet under "The top-level attributes are as follows":
 * exitOnStandardFault. If set to "yes" then a process must exit
immediately when any standard fault except "bpws:joinFailure" has been
encountered (in the same way as if an exit activity was reached). If set to
"no" then a process can handle the standard fault using a regular fault
handler. The default is "no".

================================================
New section 13.4.X Handling BPEL Standard Faults
If the exitOnStandardFault attribute on a scope is set to "yes", then a
process must exit immediately when any standard fault except
"bpws:joinFailure" has been encountered in this scope (in the same way as
if an exit activity was reached). If it is set to "no" then a scope can
handle the standard fault using a regular fault handler. Similar to the
behavior for the suppressJoinFailure attribute, the default for the
"exitOnStandardFault" is inherited from the actual attribute value on the
enclosing scope or process.

================================================
Appendix C. XML Schemas
(add @exitOnStandardFault to complex types "tProcess" and "tScope")