[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 221 - discussion carried over from Issue 123
Hi DK, Assaf and all others, DK's point (1), (2) and (3) description are consistent the two checkpoints logic that I have been suggesting in previous emails - i.e. describing the same semantics. DK also mentioned point (4) for TerminationHandler which needs some extra description. (Thanks! Dieter) In short, +1. :-) I will try to resend a consolidated text for formal proposal to vote based on my previous email, Chris' email and Dieter's 4 points. If I could not send that formal proposal soon enough for the next conf call, I would suggest to pass Dieter's 4 points as a directional vote. I hope that sounds good to people. Thanks! Regards, Alex Yiu Assaf Arkin wrote: > +1 > > assaf > > Dieter Koenig1 wrote: > >> +1 >> >> The missingReply standard fault is useful today on the process level, >> and >> even more if it can be detected on the scope level. >> >> How about the following approach: missingReply can be detected during >> termination of a scope in which the used partner link or message >> exchange >> is defined: >> ==> (1) If the scope's contained activity has completed normally then >> missingReply is thrown - this is still inside of the scope, so the scope >> itself can catch it >> ==> (2) If the scope's fault handler (for a different fault) has >> completed >> normally then missingReply is thrown to the parent scope >> ==> (3) If the scope's fault handler faulted itself then the parent >> scope >> can catch that other fault (missingReply is lost) - note that this is >> just >> another case where multiple faults have been detected >> ==> (4) If the scope's termination handler is executed then no fault is >> thrown (missingReply is lost like any other fault) >> >> Kind Regards >> DK >> >> >> >> >> Alex >> Yiu >> <alex.yiu@oracle. >> >> com> To >> Danny van der >> Rijn 15.12.2005 02:42 >> <dannyv@tibco.com> >> >> cc >> chris.keller@active-endpoints.com, >> "'Yuzo >> Fujishima'" >> <fujishima@bc.jp.nec.com>, "'ws >> bpel >> tc'" >> <wsbpel@lists.oasis-open.org>, Alex >> Yiu >> <alex.yiu@oracle.com> >> >> Subject Re: [wsbpel] Issue 221 >> - discussion carried over from >> Issue 123 >> >> >> >> >> >> >> >> >> >> >> >> Hi Danny, >> >> >> ~I~ >> >> 1) The existing missingReply fault, I remind you, is thrown only >> upon >> process exit. >> Yes, that's why we are trying to change that via Issue 221 based on the >> passed resolution of Issue 123. >> >> 2) I don't find exitOnStandardFault to be very useful in this >> context. I want the process to *portably continue*. >> >> I feel that when taken alongside the rest of the business logic >> that >> is represented, the fact that the process failed to reply is not >> cause to interrupt control flow. My point was that if the elephant >> wants to clean up some peanut shells 'cause it's a good citizen, >> then >> it should feel free to do so. But throwing a fault is, in my mind, >> the moral equivalent of halting a parade in order to return a penny >> that someone dropped. (OK, I'll stop the metaphors now..) >> >> I think understand more what you want now. I don't oppose that >> "elephant" >> doing some automatic clean up work for open IMA, if user choose to >> ask the >> "elephant" to do so. And, specifying a missingReply fault and its >> semantics >> does not prevent the "elephant" from doing this clean up trick. >> >> If the "elephant" knows this clean up trick and send out the default >> reply, >> the missingReply will NOT be triggered at all. HOWEVER, it should NOT be >> the default semantics without any elephant extension or using >> "exitOnStandardFault". Especially, since the work is done by the >> "elephant", I am not sure whether we can make this elephant work >> portable >> at all without invent a bunch of mechanism around it. (e.g. we need to >> specify what is the default reply sent out, if a user's reply is >> missing?). >> >> >> The "portably" word in "*portably continue*" seems a bit contradictory, >> ironic and infeasible. >> >> The key semantics that we need to maintain is: if the elephant does not >> provide this clean service, the scope that causes this missing reply >> situation needs to be FAULTED, not completed. >> >> >> ~II~ >> >> Asking the "elephant" to do a cleanup work exists in many forms. One of >> them can be your missingReplyHandler. The other form can be: >> <receive operation="validatePO" variable="x" ...> >> <foo:defaultReply variable="y" ... /> >> </receive> >> >> A much cleaner way to solve this in the process would be to add: >> >> <OracleExtension:missingReplyHandler> >> >> I found it extra interesting, as you use "Oracle" word here, given you >> passed a resolution to remove the "rendezvous" wording. :-) ;-) >> >> >> ~III~ >> >> Let me repeat myself [ again :-) ]. There are two checkpoints in my >> suggestion: >> - step (5) in Chris' 7-step description for Normal Completion of a scope >> - step (F4) in my 4-step description for Fault Handler execution of a >> scope >> >> Danny wrote: >> my point in the second example: >> S2 >> catch missingReply >> replyToReceive >> S1 >> FaultHandler "F1" >> sequence >> doSomeCleanup >> rethrow "F1" >> catch missingReply >> replyToReceive >> Sequence >> receive >> doSomethingThatThrowsFault "F1" >> reply >> >> is that careful programmers will be forced to put the S1 catch >> missingReply in in order to clean up after themselves. People who >> include others' code in a modular fashion will be forced to wrap >> them >> a la S2, since there is no way (that I can see) of the encloser >> of S2 >> to be sure that S1 will not throw a missingReply (unless it has no >> IMAs...). >> >> The catch missingReply activity, if present, can have an IMA in it, >> or could fail to successfully reply. Without examining each >> enclosed >> scope to determine what its IMA/missingReply behavior would be, all >> enclosing scopes are going to have to do this wrapping to protect >> themselves. I'd be happy to find out that I'm wrong in this, but >> it's what it looks like to me on first examination. >> >> Actually, you may be happy to find out that in your scenario you depict, >> those blue codes are NOT needed. BOTH check points are NOT reached >> due to a >> fault throw or rethrowing. >> >> Similar situation for your second iteration of your second example. >> Those >> blue codes are not needed. >> >> >> ~IV~ >> >> On the other hand, I am **relatively** OK to loosen up checkpoint in >> step >> (F4), while I **strongly** supports reinforcing checkpoint in step >> (5) for >> normal completion. Because the scope is already faulted in the case of >> (F1)-(F3). It is ok up to the child scope to control whether to throw a >> business fault or a standard missingReply to its parent scope. This >> arrangement will not break any scope-modularity design principle. >> >> Then, even if we removed "rethrow F1", the parent scope still does >> not need >> to do anything with missingReply. >> >> >> >> >> >> Regards, >> Alex Yiu >> >> >> Danny van der Rijn wrote: >> >> >> Alex Yiu wrote: >> >> Hi Danny, >> >> The reply is indeed like "stream-of-consciousness". :-) ... >> Still, thank you for your reply. >> >> [1] >> Danny wrote: >> I think we might be much better off leaving this >> "modelling error" to the elephant. >> >> With existing missingReply fault and Dieter's >> "exitOnStandardFault" facility, this modelling error can be >> handed over to the "elephant" easily. We are trying to define >> the common paradigm of: >> when this missingReply fault happens (i.e. to define >> when >> the "elephant" can do its magic job) >> where this missingReply fault is thrown to (i.e. to >> define the snapshot state of process and scope, when >> the >> "elephant" steps in. e.g. which scope is faulted, which >> scope is completed). >> >> If we take out "missingReply" fault, we would leave both >> of the >> above items undefined. That seems too much of handwaving >> to me. >> Users would get lost in different kinds of "wonderland" of >> "elephants". >> >> 1) The existing missingReply fault, I remind you, is thrown only >> upon >> process exit. >> 2) I don't find exitOnStandardFault to be very useful in this >> context. I want the process to *portably continue*. >> >> I feel that when taken alongside the rest of the business logic >> that >> is represented, the fact that the process failed to reply is not >> cause to interrupt control flow. My point was that if the elephant >> wants to clean up some peanut shells 'cause it's a good citizen, >> then >> it should feel free to do so. But throwing a fault is, in my mind, >> the moral equivalent of halting a parade in order to return a penny >> that someone dropped. (OK, I'll stop the metaphors now..) >> >> >> [2] >> You may have misunderstood current fault propagation model >> and >> my proposal unfortunately. >> >> [2a]: >> Danny wrote: >> Chris' 7-points mail looks to me like it's throwing the >> fault to the parent scope: >> If we do that then like any other fault generated by a >> fault handler it would be thrown to the parent scope. >> But this isn't what you're proposing, is it? >> >> With my suggested proposal, the typical chain of events for >> missingReply would be >> (S2 is a child scope, S1 is the parent scope). >> => S2 throws a missingReply fault to S2 => S2 (given the >> default fault handler behavior) will throw a missingReply >> fault >> to S1. >> >> In short, if S2 does NOT try to intercept a missingReply >> fault >> (default behavior) and does NOT set "exitOnStandardFault" to >> true (default behavior), a missingReply fault will be >> thrown to >> S1 as the result. >> >> >> [2b]: >> >> Copy and paste a part of my proposal again here: >> ------------------------------------------ >> F1 - marks scope as faulted >> F2 - matches and selects a fault handler (it can be the >> default >> one) and uninstall other fault handlers and termination >> handler >> F3 - executes the activity of the selected fault handler (A >> fault may be thrown to the parent during this step. If so, >> step >> F4 will not be reached). >> F4 - validates that message exchanges have closed (A >> missingReply fault may be thrown to the parent during this >> step) [ same logic as in step (5) ] >> [No source links will be fired after F4. Instead, DPE may be >> triggered.] >> ------------------------------------------ >> >> >> Ah, I missed the italicized part of F3. Thanks. That makes it a >> bit more consistent to me, but sitll doesn't win me over. So >> missingReply is a "backstop fault" - I'll complain about this if >> there's nothing else to complain about. >> >> Using your first example: >> ------------------------------------------ >> S1 >> FaultHandler >> sequence >> doSomeCleanup >> rethrow F1 >> Sequence >> receive >> doSomethingThatThrowsFault >> reply >> ------------------------------------------ >> >> F1 will be thrown to the parent scope, instead of >> missingReply. >> Because F4 logic will not be reached. >> >> If the "rethrow F1" is missing, then a missingReply fault >> will >> be thrown to the parent scope of S1. >> >> [2c] >> I am not sure I follow your second BPEL source code example. >> Maybe, that example was constructed based on some >> misunderstanding of my suggestion. The way I read of your >> second example is: both blue "catch missingReply" handler >> will >> NOT be triggered. >> >> >> my point in the second example: >> S2 >> catch missingReply >> replyToReceive >> S1 >> FaultHandler >> sequence >> doSomeCleanup >> rethrow >> catch missingReply >> replyToReceive >> Sequence >> receive >> doSomethingThatThrowsFault >> reply >> >> is that careful programmers will be forced to put the S1 catch >> missingReply in in order to clean up after themselves. People who >> include others' code in a modular fashion will be forced to wrap >> them >> a la S2, since there is no way (that I can see) of the encloser >> of S2 >> to be sure that S1 will not throw a missingReply (unless it has no >> IMAs...). >> >> The catch missingReply activity, if present, can have an IMA in it, >> or could fail to successfully reply. Without examining each >> enclosed >> scope to determine what its IMA/missingReply behavior would be, all >> enclosing scopes are going to have to do this wrapping to protect >> themselves. I'd be happy to find out that I'm wrong in this, but >> it's what it looks like to me on first examination. >> >> Perhaps my example should have been: >> S2 >> catch missingReply >> empty <!-- Did my best, now just make the darned thing GO >> AWAY --> >> S1 >> FaultHandler >> sequence >> doSomeCleanup >> rethrow >> catch missingReply >> replyToReceive <!-- Rats, somebody was left hanging. >> Attempt to let them know that I failed --> >> Sequence >> receive >> doSomethingThatMayThrowAFault >> Maybereply >> >> There are many cases here: doSomethingThatMayThrowAFault may fault >> and it may not. Maybereply might reply and it might not. To >> protect >> against all these cases, you need both of those handlers. The sad >> thing is that if doSomethingThatMayThrowAFault does throw a fault, >> then the missingReply fault is never thrown, and we've failed to >> manage to clean up that IMA. >> >> Why give people an 80% solution here? It would be much cleaner >> (for >> everyone) if we leave this to the elephant. >> >> A much cleaner way to solve this in the process would be to add: >> >> <OracleExtension:missingReplyHandler> >> >> as another handler on a scope or process. This would be run after >> the scope is complete, and all other handlers are uninstalled. >> It is >> presented with a list of open IMAs and it does with them as it sees >> fit. I wish you luck in implementing it ;-) >> >> >> I hope this clarify any misunderstanding. >> >> >> Thanks! >> >> >> >> Regards, >> Alex Yiu >> >> >> >> >> >> --------------------------------------------------------------------- >> 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]