If I understand your first question correctly, that was my notion of the convert-terminate-to-fault-and-continue behavior. And then yes, the failure could be capped to a scope, since the "modeling" fault at that point will be treated like any other ordinary fault.
________________________________
From: Alex Yiu [mailto:]
Sent: Fri 2/11/2005 11:49 AM
To: Satish Thatte
Cc: ; Francisco Curbera; Prasad Yendluri; Danny van der Rijn; ;
Subject: Re: [wsbpel] Issue 190 - BPEL Internal Faults (New Proposed Issue Announcement)
Hi, Satish,
I guess I undestand you point ...
More questions: Say:
If we don't call it "fault", after the process is "freezed" ...
and after user-inspection, he/she consider the fault should not affect
the compensation logic, can the user select the action to activate a
fault handler of a related scope which does the compensation logic and
marked the scope faulted and continue rest of the process?
It is important to cap the system failure to one of child scopes, not
the whole process, for fault-tolerant design [ Oh my ..... the term
"fault" comes again ... do we really want to avoid that term? ]
Thinking out loud again: maybe we should still call them as fault and
have a clear explanation on how system failure will be handled
differently from an application fault?
Regards,
Alex Yiu
Satish Thatte wrote:
