difference between what
Dieter originally suggested and my subsequent embellishment is that I
we allow “exit” (formerly terminate) to carry fault-like data and
then treat all current “internal” faults (except joinFailure) as
exits (as Dieter suggested) but with
This allows engines dealing with such exited aka frozen process
instances to privately
support notions such as “convert
an exit to a fault and proceed” or “repair process and continue”.
Just want to make it clearer for our standardization process:
Since the current tone projected by Satish and Paco are quite different
the one first described by Dieter, I think we need to a restated
description in writing first for Issue 190. Then, we can decide and
whether it is a feature or a bug to the spec.
After/if the issue is opened, we need to have a new proposal with exact
wordings to vote on.
Alex Yiu wrote:
Then, it seems to me that we are converging.
What we need now is a new proposal with exact wordings and clear
the new semantics.
Satish Thatte wrote:
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:email@example.com]
Sent: Fri 2/11/2005 11:49 AM
To: Satish Thatte
Cc: firstname.lastname@example.org; Francisco Curbera; Prasad Yendluri; Danny van der Rijn; email@example.com; firstname.lastname@example.org
Subject: Re: [wsbpel] Issue 190 - BPEL Internal Faults (New Proposed Issue Announcement)
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?