[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 221 - Proposal vor Vote
I don't think that your intention for (2) is clear in the language. Something along the lines of: (2) If a fault handler has completed then a check for missing replies MUST be made. If any missing reply other than the exact one that caused a missingReply fault to be thrown initially is detected then a bpws:missingReply is thrown to the parent scope (similar to throwing or rethrowing other faults from a fault handler). As for (1), I am troubled that a fault that is serious enough to exit the engine could be lost so easily. But let's deal with a specific case: Scope A catch bar empty Scope B catch foo throw bar sequence receive (create open IMA) throw foo Scope B receives a message, creating an open IMA, and then throws foo. Its fault handler catches foo, and throws bar, thus losing the missingReply fault. Scope A catches bar, and suppresses it. When "catch bar" completes, the IMA is still open. Does Scope A throw a missingReply? Or is the fact that B ":lost" it mean that it's lost forever? I would vote for the former (A throwing), but the text isn't clear to me as to what happens. Danny Dieter Koenig1 wrote: If more than one fault is thrown then only one is handled by a fault handler, either in the same or in an enclosing scope. All other faults are lost. This rule applies to bpws:missingReply as well. In (2), the check allows to throw bpws:missingReply to an enclosing scope after a different fault has been handled in the scope that completes unsuccessfully. The "different fault" may be a different "instance" of a bpws:missingReply fault as well. Do you still see an issue w.r.t this behavior, or can you suggest better language for 221 that would not trouble you :-) ? Kind Regards DK Danny van der Rijn <dannyv@tibco.com To > wsbpel@lists.oasis-open.org cc 25.01.2006 22:35 Subject Re: [wsbpel] Issue - 221 - Proposal vor Vote I had sent this question to the irc during the meeting before I had to go. Don't know if it got discussed or not. point (2) - why is this only "(for a different fault)"? more specifically: - if there is more than one IMA that caused the fault to be thrown, and there is still at least one open (but less than before) at the end of the <catch missingReply>, what happens? - if the <catch missingReply> opens a new IMA that it doesn't close before it's done, what happens? the inconsistent nature of dealing with these, especially since they can exitOnStandardFault, truly troubles me. Danny Dieter Koenig1 wrote:Two additional changes to the 221 resolution (friendly amendments): (A) First sentence: Drop "during termination of a scope, " (B) Appendix A (missingReply standard fault): Result: (A) Add to the end of 14.4: -------- The standard fault bpws:missingReply can also be detected if one or more receive operations using a partner link or message exchange defined inthescope remain open. (1) If the contained activity and the event handlers of the scope have completed then a check for missing replies MUST be made. If one isdetectedthen a bpws:missingReply is thrown. The scope itself can catch it as this is still inside of the scope. (2) If a fault handler (for a different fault) has completed then a check for missing replies MUST be made. If one is detected then a bpws:missingReply is thrown to the parent scope (similar to throwing or rethrowing other faults from a fault handler). (3) If a fault handler itself throws or rethrows a different fault to the parent scope then no check for missing replies is made, so a bpws:missingReply is potentially lost (similar to a case where multiple faults have been detected and only one gets propagated). (4) If the termination handler is executed then no check for missing replies is made, so a bpws:missingReply is potentially lost (like anyotherfault thrown in the termination handler). -------- (B) Change Appendix A (missingReply standard fault) from: -------- Thrown when a receive has been executed, and the process instancereachesthe end of its execution without a corresponding reply having been executed. -------- To: -------- Thrown when a receive has been executed, and the process instance or a scope reaches the end of its execution without a corresponding replyhavingbeen executed. -------- Kind Regards DK ----- Forwarded by Dieter Koenig1/Germany/IBM on 25.01.2006 17:39 -----DieterKoenig1/Germany/IBMTowsbpel@lists.oasis-open.org19.01.2006 17:58ccSubject[wsbpel] Issue - 221 - ProposalvorVoteThe last paragraph of section 14.4. "Web Service Operations" (startingwith"The fourth extension ...") introduces the standard fault "bpws:missingReply". Add the following text to the end of the paragraph: -------- The standard fault bpws:missingReply can also be detected during termination of a scope, if one or more receive operations using a partner link or message exchange defined in the scope remain open. (1) If the contained activity and the event handlers of the scope have completed then a check for missing replies MUST be made. If one isdetectedthen a bpws:missingReply is thrown. The scope itself can catch it as this is still inside of the scope. (2) If a fault handler (for a different fault) has completed then a check for missing replies MUST be made. If one is detected then a bpws:missingReply is thrown to the parent scope (similar to throwing or rethrowing other faults from a fault handler). (3) If a fault handler itself throws or rethrows a different fault to the parent scope then no check for missing replies is made, so a bpws:missingReply is potentially lost (similar to a case where multiple faults have been detected and only one gets propagated). (4) If the termination handler is executed then no check for missing replies is made, so a bpws:missingReply is potentially lost (like anyotherfault thrown in the termination handler). -------- Kind Regards DK --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs inOASISat: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]