OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[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, Yaron

Few things to clarify:
(1)
Only within a parallel flow generation construct (e.g. <flow> or future 
parallel foreach) needs a cancellation mechanism to be triggered by BPEL 
users code.

When "break" is used within a pure sequential env (e.g. a <while> loop 
with a <sequence> without <flow>), there will be no flow or "thread" got 
cancelled. It is just equivalent to a "GOTO" statement.

(2)
When "break" is used within a <flow>, then, yes, the same 
"cancelling-other-flows" mechanism will be triggered as well. (with 
certain speculation of break semantics)

(3)
I think we should have a generic section describe the semantics of what 
"cancelling other flows" mechanism means under section "12.5 Flow". And 
list out what possible constructs can trigger this mechanism. (e.g. 
"completionCondition" or "break" within a <flow>.)

Hence, we may want to have a more generalized wordings for describing 
cancelHandler like below:
-----------------------
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 "cancelling-other-flows" 
mechansim within a parallel flow generation construct.
-----------------------

We shall add suitable examples to the above paragraph upon the 
resolution of Issue 6 and Issue 142 (break and continue).

(4)
We (Oracle) are still evaluating the benefits and implication of 
break/continue in parallel-flow enabled BPEL env.


Thanks!


Regards,
Alex Yiu





Yaron Y. Goland wrote:

> 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.                    
>>>>
>>
>
> 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]