Re: [wsbpel] Issue 190 - Proposal For Vote

[Danny van der Rijn <dannyv@tibco.com>]

I really don't like this being on scopes.  I can (maybe) understand its 
presence at the process level, but having it overridden at each scope 
doesn't make sense to me. 

Dieter Koenig1 wrote:

>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")
>
>
>---------------------------------------------------------------------
>To unsubscribe from this mail list, you must leave the OASIS TC that
>generates this mail.  You may a link to this group and all your TCs in OASIS
>at:
>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>
>
>  
>