RE: [wsbpel] Issue 135 - Proposal to vote

It is not necessarily true that a scope will be forced to terminate only once. If we do premature completion with a completion handler then a fault in the completion handler may cause an attempt to forcibly terminate a scope more than once.

From: Alex Yiu [mailto:alex.yiu@oracle.com]
Sent: Monday, September 27, 2004 2:33 PM
To: Satish Thatte
Cc: Danny van der Rijn; wsbpel@lists.oasis-open.org; Alex Yiu
Subject: Re: [wsbpel] Issue 135 - Proposal to vote

Hi,

+1 to Satish's proposal.

Just want to suggest a couple of minor things to add explicitly to the spec for clarity

A forced termination is an abnormal termination of a scope. The compensation handler of a scope will not be installed after a forced termination. (To distinguish the terminationHandler from the potental completionHandler)
From the text from other parts of the existing spec, I can infer that there is NO such a situation that a BPEL engine will try to terminate a scope more than once due to internal conditions. Could someone confirm my inference?

On the other hand, it may be possible that people may try to "terminate" a process gracefully from a BPEL managment tool more than once, instead of "kill" it immediately?

Do we want to make this explicitly by saying the second or subsequent attempt to terminate an activity / a scope which is being terminated will be ignored? Hence, the terminationHandler of a particular scope instance will NOT be invoked more than once.

A side suggestion: it would be nice to have finite state diagram to illustrate the state transition of a scope in the spec, especially after we pass both completionHandler and terminationHandler issue. The life cycle of a scope can be complicated.

Thanks!

Regards,
Alex Yiu

Satish Thatte wrote:

thanks

From: Danny van der Rijn [mailto:dannyv@tibco.com]
Sent: Friday, September 24, 2004 12:15 PM
To: Satish Thatte
Cc: wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] Issue 135 - Proposal to vote

i misinterpreted some subleties in the proposal. i withdraw my comments.

Satish Thatte wrote:

??

The forcedTermination fault handler was able to do compensation.  Why is

this a change?

No, the fact that the process does not have a termination handler is

deliberate since we do not have a notion of forced termination of a

process instance.  I deliberately moved <terminate/> to <exit/> to make

that clear.

This proposal actually changes absolutely nothing semantically.  It

simply changes syntax.

-----Original Message-----

From: Danny van der Rijn [mailto:dannyv@tibco.com]

Sent: Friday, September 24, 2004 8:31 AM

To: Satish Thatte

Cc: wsbpel@lists.oasis-open.org

Subject: Re: [wsbpel] Issue 135 - Proposal to vote

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_workgr

oup.php.

 
 
 
    

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.

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.

wsbpel message