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