Re: [wsbpel] Issue 135 - Proposal to vote

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

i don't like the idea of the default termination handler performing 
compensation.  this part is an addition, rather than a syntactic 
substitution, and i think it falls on the wrong side of the meaning of 
default.

also, i assume that the fact that a process doesn't have a termination 
handler is an inadvertent omission?

danny

Satish Thatte wrote:

>Overview:
>
> 
>
>The bpws:forcedTermination "fault" in the current specification is not a normal fault.  It is simply a way to permit interception of forced termination by a scope to perform special handling to shut the scope down in an orderly manner.  The differences from a normal fault include the inability to be caught by a catchAll handler, and the inability to throw or rethrow any fault within the handler.  It is thus proposed that we eliminate the notion of a bpws:forcedTermination fault from the specification and replace it with a notion of a special handler for forced termination.  A secondary part of the proposal is to replace the <terminate/> activity with an <exit/> activity with identical semantics, simply to avoid terminological confusion with the notion of forced termination.
>
> 
>
>Detailed proposal:
>
> 
>
>In all the text of the specification, including section 5 and Appendix A, eliminate the mention of bpws:forcedTermination and remove this token from the bpws namespace.
>
> 
>
>In Sections 6.2 and 13
>
> 
>
>Replace the syntax
>
> 
>
><scope variableAccessSerializable="yes|no" standard-attributes>
>
>        standard-elements
>
>        <variables>?
>
>            ...
>
>        </variables>
>
>        <correlationSets>?
>
>            ...
>
>        </correlationSets>
>
>        <faultHandlers>?
>
>            ...
>
>        </faultHandlers>
>
>        <compensationHandler>?
>
>            ...
>
>        </compensationHandler>
>
>        <eventHandlers>?
>
>            ...
>
>        </eventHandlers>
>
>        activity
>
></scope>
>
> 
>
>with the syntax
>
> 
>
><scope variableAccessSerializable="yes|no" standard-attributes>
>
>        standard-elements
>
>        <variables>?
>
>            ...
>
>        </variables>
>
>        <correlationSets>?
>
>            ...
>
>        </correlationSets>
>
>        <faultHandlers>?
>
>            ...
>
>        </faultHandlers>
>
>        <compensationHandler>?
>
>            ...
>
>        </compensationHandler>
>
>        <terminationHandler>?
>
>            ...
>
>        </terminationHandler>
>
>        <eventHandlers>?
>
>            ...
>
>        </eventHandlers>
>
>        activity
>
></scope>
>
> 
>
>In Section 13.4.2
>
> 
>
>Replace the text
>
> 
>
>Scopes provide the ability to control the semantics of forced termination to some degree. When the activity being terminated is in fact a scope, the behavior of the scope is interrupted and the fault handler for the standard bpws:forcedTermination fault is run. Note that this applies only if the scope is in normal processing mode. If the scope has already experienced an internal fault and invoked a fault handler, then as stated above, all other fault handlers including the handler for bpws:forcedTermination are uninstalled, and the forced termination has no effect. The already active fault handler is allowed to complete. 
>
> 
>
>The fault handler for the bpws:forcedTermination fault is designed like other fault handlers, but this fault handler cannot rethrow any fault. Even if an uncaught fault occurs during its behavior, it is not rethrown to the next enclosing scope. This is because the enclosing scope has already faulted, which is what is causing the forced termination of the nested scope. 
>
> 
>
>In other respects this is a normal fault handler. Its behavior begins by implicitly (recursively) terminating all activities directly enclosed within its associated scope that are currently active. It can invoke compensate activities. And when it is missing, it is provided by using the same implicit behavior that is used for all other implicit fault handlers. 
>
> 
>
>Note that forced termination of nested scopes occurs in innermost-first order as a result of the rule (quoted above) that the behavior of any fault handler begins by implicitly (recursively) terminating all activities directly enclosed within its associated scope that are currently active. 
>
> 
>
>with the text
>
> 
>
>Scopes provide the ability to control the semantics of forced termination to some degree. When the activity being terminated is in fact a scope, the forced termination of a scope begins by terminating all activities directly enclosed within its associated scope that are currently active.  Following this, the custom termination handler for the scope, if present, is run.  If the custom termination handler is missing, the default termination handler performs compensation of all successfully completed nested scopes in the same order as in the case of a default fault handler. 
>
> 
>
>Forced termination for a scope applies only if the scope is in normal processing mode. If the scope has already experienced an internal fault and invoked a fault handler, then the termination handler is uninstalled, and the forced termination has no effect. The already active fault handler is allowed to complete. 
>
> 
>
>The termination handler for a scope is permitted to use the same range of activities as a fault handler, including the <compensate/> activity.  However, a termination handler cannot throw any fault. Even if an uncaught fault occurs during its behavior, it is not rethrown to the next enclosing scope. This is because the enclosing scope has already either faulted or is in the process of being terminated, which is what is causing the forced termination of the nested scope. 
>
> 
>
>Forced termination of nested scopes occurs in innermost-first order as a result of the rule (stated above) that the termination handler is run after terminating all activities (including scope activities) directly enclosed within its associated scope that are currently active. 
>
> 
>
>
>To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php.
>
>
>  
>