Hi Mark,
I guess you would not be surprised that I still prefer detecting
orphaned IMA at the end of compensationHandler. Reasons are:
- The missingReplies error is actually resulted from the modelling
mistake or unanticipated runtime failure in the child scope (which the
CH is attached), not the FH of the parent scope. Fault at the CH level
is more precise.
- From section 12.4.2: "This
is because their compensation handlers are
still available, and therefore the execution of such scopes may
continue during
the execution of their compensation handlers, which can be thought of
as an
optional continuation of the behavior of the associated scope."
I tend to interprete that the primary (normal) activity of the scope is
its part #1, while the activity of the CH of that scope is its part #2.
Their nature should be symmetrical in the counter-working way. If we
perform certain checks in part #1, similar checks should happen in part
#2.
- The asymmetry between missingReplies and other fault (e.g.
selectionFailure) concerns me. (This is the last but the most important
point.) If there is a problem in the CH logic that triggers a fault
(e.g. selectionFailure), it will be propagated from the CH to the
corresponding compensation activity in FCTHandler (fault, compensation
and termination). If there is no fault handling around the
compensation activity, the whole FCTHandler will not continue. But, now
we are saying that the FCTHandler will continue until its end, if the
error condition is the missingReplies fault? This asymmetry may be
surprising to users. I would say it may the process more difficult to
model.
Let me use one more example to illustrate my preference. If one wants
to continue the logic in a FH including continuing other compensation
activities, one want to add a scope
That is changing from:
---------------------------------------
<catch ... >
<sequence>
<compensationScope target="A" />
<compensationScope target="B" />
<compensationScope target="C" />
</sequence>
</catch>
---------------------------------------
to:
---------------------------------------
<catch ... >
<sequence>
<scope>
...
<catchAll> <empty/> </catchAll>
...
<compensationScope target="A" />
</scope>
<compensationScope target="B" />
<compensationScope target="C" />
</sequence>
</catch>
---------------------------------------
This <catchAll> will handle all kind of faults, not just
missingReplies.
Again, it will allow BPEL process definition to have a finer grain of
control on how to handle missingReplies fault.
Also, **if** the work of "A", "B" and "C" are highly related to each
other, I would say that it is actually more common for the process
designer to prefer the compensation work stop immediately, if the
compensation of "A" failed. That will avoid any propagating any strange
states from "A" to "B" and "C". That is also consistent with the
design of Compensation Handler Instance Group. That is, if one instance
fails within the group, other instances (not started yet) will not be
attempted.
I hope I did a better convincing job this time. :-)
More thoughts?
Thanks!
Regards,
Alex Yiu
Mark Ford wrote:
In dealing with an orphaned IMA within
a compensation handler, it seems to me that there are two possible
resolutions. Either the compensation handler detects the orphaned IMA's
and faults or the detection of orphaned IMA's is deferred to the fault
handler or termination handler that invoked the compensation handler. I
am in favor of the latter since it allows compensation to continue even
with orphaned IMA's. There is very little that can be done with these
orphaned IMA's so we may as well allow the compensation logic to
proceed as best it can and defer its fault to
I have reworded my original proposal
to avoid introducing any new terms as per Danny's suggestion. The
approach is still the same in that the detection of an orphaned IMA is
NOT made by the compensationHandler.
Add a fifth bullet to Section 12.2
which reads as follows:
No checks for orphaned IMA's are
made when a compensation handler completes. The compensation handler's
execution must necessarily start from within a fault or termination
handler so any orphaned IMA's created by a compensation handler will be
detected and handled as described in the above bullets.
|