RE: [wsbpel] Issue 135 - Rough draft of a proposal for vote

From: Alex Yiu [mailto:alex.yiu@oracle.com]
Sent: Friday, September 03, 2004 2:33 PM
To: edwin.khodabakchian@oracle.com
Cc: Satish Thatte; ygoland@bea.com; 'Frank Leymann'; 'wsbpeltc'; Alex Yiu
Subject: Re: [wsbpel] Issue 135 - Rough draft of a proposal for vote

Satish,

Thanks for bring in a new perspective to the discussion. I agree with you guys in general. The fault notion of forcedTermination does create some confusion.

Just few more clarification questions:

If we have this "cancelHandler", I presume we will have a default cancelHandler also. The default cancelHandler will be similar to the default faultHandler except about the part that it does not rethrow fault.

[Satish Thatte] yes the behavior is quite similar which is why we were tempted to attempt the “false economy”

I also presume that: the "forcedTermination" fault concept will not exist explicitly anymore.

[Satish Thatte] correct

And, the "cancelHandler" can be only triggered by BPEL engine action, not by the logic specified by BPEL itself.

[Satish Thatte] exactly

Thanks!

Regards,
Alex Yiu

Edwin Khodabakchian wrote:

+ 1. - Edwin

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

From: Satish Thatte [mailto:satisht@microsoft.com]

Sent: Thursday, September 02, 2004 11:15 PM

To: Alex Yiu; ygoland@bea.com

Cc: wsbpeltc

Subject: RE: [wsbpel] Issue 135 - Rough draft of a proposal for vote

There is no reason to allow catchall to also handle the forcedTermination

"fault" since the latter is in fact an external "cancel" signal rather than

an internal fault that may be optionally rethrown.  We should insist that in

order to capture and handle forcedTermination you must have a specific

handler, and we shouldn't even need to call it a faultHandler -- call it a

cancelHandler instead.  The whole forcedTermination "fault" notion is a

false economy of concept that causes unnecessary confusion.  Didn't Peter

make some such proposal at some point?

________________________________

From: Alex Yiu [mailto:alex.yiu@oracle.com]

Sent: Thu 9/2/2004 9:13 PM

To: ygoland@bea.com

Cc: wsbpeltc; Alex Yiu

Subject: Re: [wsbpel] Issue 135 - Rough draft of a proposal for vote

Hi, Yaron,

[ I know you are on vacation now ... Still, I would like to reply this

thread. :-) ]

Thanks for clarification.

Few points to add:

*       +1 to the part of rename <teminate> activity to <halt> activity.

Because, I got a similar confusion between "forcedTermination" fault and

<terminate> activity, when I first read the spec. Also, the term "terminate"

is used everywhere in the spec. But, the usage of "terminate" has no

relation with <terminate> activity.

*       Regarding to the fault handler part of proposal,

        *       Default fault handler: For clarity, we may want to change

the description of default fault handler in Section 13.4.1 as well.

Currently, it said: "Rethrow the fault to the next enclosing scope.". I

think it should say: "Rethrow the fault to the next enclosing scope, if the

fault is not bpws:forcedTermination".

        *       In the case of <catch faultName="bpws:forcedTermination">:

We may want to enforce the prohibition <throw> or <rethrow> within this

particular kind of <catch> construct by static analysis.

        *       In the case of <catchAll>: I think users should be able to

use <catchAll> to catch "bpws:forcedTermination" fault.  Because users

should be able to specify an explicit fault handler to perform any partial

undo operation, no matter which fault is causing the problem. In order to

observe "bpws:forcedTermination", I have two alternative proposals to refine

catchAll semantics.

               [A] If a <catchAll> handler exists without a <catch

faultName="bpws:forcedTermination"> handler in the same scope, <throw> or

<rethrow> will be disallowed in the <catchAll> handler. This restriction can

be enforced by static analysis. This restriction will essentially force BPEL

developers to have two fault handlers when then want to throw fault in

<catchAll>. [Better code clarity; more burden on users]

               [B] If a <catchAll> get a "bpws:forcedTermination", any

<throw> or <rethrow> activity within that <catchAll> fault handler instance

will become an NO-OP. [Less code clarity; less burden on users]

Thoughts ... ? Particularly for the last item.

Thanks!

Regards,

Alex Yiu

Yaron Y. Goland wrote:

        I am not proposing any functional changes, I am just proposing

changing the name of "terminate" to "halt" so as to prevent confusion with

the completely unrelated bpws:forcedTermination fault.

            Thanks,

                Yaron

        Alex Yiu wrote:

               Hi, Yaron,

               Do you mean to introduce a new activity "halt"?

               If so, could you highlight again what is the difference

between "halt" and "terminate"?

               Thanks!

               Regards,

               Alex Yiu

               Yaron Y. Goland wrote:

                       Below is a first attempt to creating a proposal for

vote for issue 135.

                           Thoughts? Comments?

                                   Yaron

                       Proposal Summary:

                        * Change the name of the terminate activity to the

Halt activity.

                        * Specify that the bpws:forcedTermination fault

cannot be caught by catchAll handlers.

                       Proposed Language Changes:

                       Change all instances of the Terminate activity name

to Halt.

                       Change section 14.6 to read:

                       The halt activity can be used to immediately halt

the business process instance within which the halt activity is performed.

All currently running activities MUST be halted as soon as possible without

any fault handling or compensation behavior.

                       <halt standard-attributes>

                           standard-elements

                       </halt>

                       Section 13.4:

                       Current Language: A catchAll clause can be added to

catch any fault not caught by a more specific catch handler.

                       Proposed Language: A catchAll clause can be added to

catch faults not caught by a more specific catch handler, with the exception

of the bpws:forcedTermination fault.

                       Delete the following sentence, it appears twice:

Otherwise, the default catchAll handler is selected if present.

                       Add an extra bullet after the existing two bullets

in section 13.4 that reads: If the fault is not caught by any of the

handler's catch clauses per the previous two rules, the fault is not a

bpws:forcedTermination fault, and there is a catchAll handler then the fault

MUST be caught by the catchAll handler.

                       Insert the following sentence after the previous

bullet: The bpws:forcedTermination fault cannot be caught by the catchAll

handler because the environment in which bpws:forcedTermination faults are

handled is different than the normal BPEL fault environment and so a

dedicated fault handler is needed. If a dedicated bpws:forcedTermination

fault handler is not provided then bpws:forcedTermination fault is dropped.

                       Current Language: If there is fault data associated

with the fault, the third catch will be selected if and only if the type of

the fault's data matches the type of variable "bar", otherwise the default

catchall handler will be selected. Finally, a fault with a fault variable

whose type matches the type of "bar" and whose name is not "x:foo" will be

processed by the second catch. All other faults will be processed by the

default catchall handler.

                       Proposed Language: If there is fault data associated

with the fault, the third catch will be selected if and only if the type of

the fault's data matches the type of variable "bar". Finally, a fault with a

fault variable whose type matches the type of "bar" and whose name is not

"x:foo" will be processed by the second catch. All other faults, other than

the bpws:forcedTermination fault, will be caught by the catchall handler and

discarded.

                       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