[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 135 - Rough draft of a proposal for vote
+1 on Satish's proposal Satish Thatte wrote: > > > > > > > * 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 <mailto: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 <mailto: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. > > > > > > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]