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 ; <mailto:> ;
>>> '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:]
>>> Sent: Thursday, September 02, 2004 11:15 PM
>>> To: Alex Yiu; <mailto:>
>>> <mailto:>
>>> 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:]
>>> Sent: Thu 9/2/2004 9:13 PM
>>> To: <mailto:> <mailto:>
>>> 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.
>>>
>>>
>>>
>>>
>>>
>>>
>
