There are two points at issue here.
1. Are undefined-runtime-semantics "faults" really faults in the sense
that one would write specific catch handlers for things like
conflictingReceive, or correlationViolation in the same way as one would
write catch handlers for approvalDenied?
2. Admitting that undefined-runtime-semantics "faults" will occur since
we do not mandate pessimistic static analysis to prevent them, what
exactly is a reasonable way to deal with these "faults"?
I would hope that we have no disagreement that specific handlers for
correlationViolation and such would be extremely rare. CatchAll is the
way these "faults" would be intercepted if at all. And in that context
there is very little one can do except suppress the fault, i.e., limit
its impact, and possibly notify someone that it happened. I have not
seen anyone argue otherwise.
The primay disagreement seems to be about the second question, and
especially about the tradeoff between the approaches of
A. Explicitly define impact boundaries ("modularity" entered the
discussion as an example for such boundaries) even for
undefined-runtime-semantics "faults" and within those boundaries apply
the usual unravel and compensate logic that gets applied by default.
B. There is no reasonable way to define the impact boundaries in most
cases and in a lot of important processes the usual unravel and
compensate logic would create unintended havoc and destroy years of work
if blindly allowed to proceed by default and oversight.
By the way, neither approach helps as far as letting a partner know what
is going on in cases like missingReply. For that we would have to go
back to my suggestion of explicitly declaring MEP instances in scopes
and then defining standard wire-faults in case an MEP instance went out
of scope without completing. To be clear, I am *not* suggesting we go
down that road at this point.
I don't think we can settle this with arguments based on examples
because "allowing ordinary compensation to proceed" can be viewed as
being either desirable or disastrous depending on the scenario you have
in mind.
I disagree with Yaron that his setting#1 which corresponds to my
approach B is possible today without preventing the BPEL engine from
actually carrying out prescribed runtime semantics. But I agree with
him that the two approaches need to be made possible via some
platform-specific switch, i.e., made compatible with BPEL normative
semantics. One way is to extend our notion of "terminate" to include
optional fault data. I would then argue that a BPEL engine is free to
provide a (private) switch that chooses between
terminate-then-optionally-repair-and-continue behavior as well as
auto-convert-terminate-to-fault-and-continue behavior.
Satish
-----Original Message-----
From: Yaron Y. Goland [mailto:]
Sent: Monday, February 07, 2005 12:13 PM
To: Francisco Curbera
Cc: Prasad Yendluri; Danny van der Rijn;
Subject: Re: [wsbpel] Issue 190 - BPEL Internal Faults (New Proposed
Issue Announcement)
I think the core of the problem is another part of our ever increasing
elephant.
Lots of systems are going to have a magic switch that I strongly
encourage us not to attempt to specify in BPEL both because it's at
least 80% out of scope and because it will take a long time to agree on
the semantics.
That switch will specify (either on a process level or perhaps a scope
level) what to do if certain kinds of faults are thrown. One of the key
faults this switch will focus on are system faults.
This switch will typically have at least two settings.
Setting #1 - If a system fault is thrown immediately freeze the process
and call the admin for help who can then edit the process to fix things.
Setting #2 - If a system fault is thrown then send a note to the admin
but let the fault go through the normal fault handlers.
Both the first and second settings are possible with the existing spec.
The first behavior through an out of scope operational override and the
second behavior is pretty much our default behavior.
Issue 190 would make the second setting effectively impossible since it
would be illegal to ever allow system faults to go through normal fault
handling. But as Alex and others have convincingly argued there are many
interesting cases in which it makes sense to allow system faults to go
through normal fault handling.
In terms of maximizing portability I think we should stick with our
current behavior and leave the 190 style behavior to out of scope
extensions.
Yaron
Francisco Curbera wrote:
