[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 123 - Proposal for vote
Thanks for following this discussion thread. Really appreicate it ... :-)
The main motivations behind "S2-to-S2" for missingReply fault are:
==> Finer-grain reply / compensation
About "Reason 1" : "programming-error-vs-runtime-error" consideration:
I agree with you this is more likely a programming error, not a true runtime error. That is why Dieter introduced this exit-on-standard-fault facility to allow people to stop process in case of this programming error.
With or without using this exit-on-standard-fault facility, as a complete specification, we need to specify snapshot state of the process - i.e., what scopes are faulted and not, when the "exit" takes place.
If you think of the <onEvent> example described above, S1 should not be faulted, when the "exit" happens. Similarly, the previous 4 instance of "S2" should not be faulted either. Only the true missingReply scope should be faulted.
I also agree with you that people should not rely on catching this missingReply fault to do any complicated business logic. At most, people should just log the fault and attempt doing the partial compensation, as described above. (This applies to most of standard fault catchers).
I am just promoting scope-modularity. Definitely, not promoting any weired coding style. If you want, I think we can add a caution statement along the intention of the passed resolution of Issue 192 (Dieter's exitOnStandardFault proposal) to spec to state that: "If people do not set exitOnStandardFault to true, it is a good practice to restrict logic of any standard fault fault handler to some minimalistic repair work (e.g. error logging and partial compensation)."
Actually, the same wisdom applies to most of conventional programming language. E.g. in Java, if one got an IOException, SQLException, or Security permission related Exception, there are only few things that a Java application programmer can do / should do (similar to above).
About "Reason 2: When to judge if a reply is missing":
we should expect a fault handler to send a reply.Yes, I totally agree with you here. :-)
Our intended behavior are actually very similar. :-) ... I guess the related text in my previous email writeup is muddled. Sorry for the not-organized enough text.
Let me add some clarification and refinement here:
There are two checkpoints to decide whether a bpws:missingReply fault needs to be thrown in a scope (S2):
If the triggered fault handler (either by bpws:missingReply fault or other kinds of fault) does not generate proper replies to any open IMAs, a missingReply fault MUST be thrown. This is the case #2 checkpoint logic.
Here is a fragment of process definition that illustrates the relationship of scope S1 and S2 described above:
<partnerLink name="pl1" ... />
<receive partnerLink="pl1" ... />
<!-- receive without reply -->
Note: The bpws:missingReply fault is thrown by scope S2 to scope S2 itself.
[I highlighted the clarification changes in GREEN.]
To summarsize, we agree more than disagree. :-) ....
Case #2 is where the fault is thrown by S2 to S1.
I am merely adding one more differentiated checkpoint (case #1) to allow the fault thrown by S2 to S2 to achieve the semantics of scope-modularity and finer-grain repair and compensation. (IMHO, that is very important for <onEvent> cases).
I hope I have explain my intended behavior better this time. :-)
More thoughts on this topic ... ? :-)
Yuzo Fujishima wrote: