[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
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 ; '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]