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 - Rough draft of a proposal for vote


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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]