[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 135 - cross-issue consideration with Issue 6
The reason this makes me uncomfortable is that it would only solve the problem for flows. But the general issue of break/continue, which is what we are really describing here, is much more general than that. Rather than coming up with a special mechanism for flow I would rather see us create a more general purpose mechanism we can re-use in multiple places, e.g. break/continue. Thanks, Yaron Alex Yiu wrote: > > Hi, all, > > As mentioned before, similar to Yaron's opinion, +1 on Satish's > suggestion in terms of abandoning the false economy of > "forcedTermination" fault. > > One thing I would like to bring up is: we may want to solve Issue 135 > and Issue 6 together. > > For Issue 6, we need to enable and describe a clean way to terminate / > cancel other on-going parallel flows once the complete condition is > reached, without involving overloading fault-related concepts. > > Copied from my recent email on Issue 6: > ======================== > About "Cancel-other-flows": (Let me consolidate what I am leaning > towards so far.) We need to formal define the notion of a " > cancel-other-flows " mechanism. This mechanism is specified and attached > to <flow> construct (and future parallel forEach construct). When this > mechanism is triggered by one of parallel flows, it will > cancel/terminate other parallel flows which are still running, after the > triggering flow is completed. If the other flow activties are scope > activities, the scope will be marked as cancelled. > > This mechanism will be triggered upon the completionCondition is > evaluated to be true. > ======================== > > From previous email on this thread: > >> * And, the "cancelHandler" can be only triggered by BPEL engine >> action, not by the logic specified by BPEL itself. >> >> */ [ Satish Thatte ] exactly /* >> >> > > I guess the wordings about "cancelHandler" will be refined to something > like: > > * The "cancelHandler" can be only triggered by BPEL engine action. > It cannot be triggered directly by the logic specified in BPEL > process definition. The exceptional case is: the > "completionCondition" within a <flow> can be used to trigger the > cancellation/termination of activities of flows. > > > Does it make senses? > Thanks!!! > > > > Regards, > Alex Yiu > > > > > Yaron Y. Goland wrote: > >> +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 <mailto: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> >>> <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> <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]