[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue 190 - BPEL Internal Faults (New Proposed Issue Announcement)
OK let us discuss at the F2F.
-----Original Message-----
From: Chris Keller [mailto:chris.keller@active-endpoints.com]
Sent: Monday, February 21, 2005 10:05 AM
To: Satish Thatte; 'Dieter Koenig1'
Cc: wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Issue 190 - BPEL Internal Faults (New Proposed
Issue Announcement)
Satish,
I am not against a repair and continue option and I am in fact in favor
of
having it, even though we can't dictate it as part of the specification.
What I am suggesting is that Dieter's proposal prohibits that option. I
am
also saying that catchall is a little too broad and that having a filter
on
catchAll for standard faults would be a good thing. There are of course
other ways to resolve it.
Chris
-----Original Message-----
From: Satish Thatte [mailto:satisht@microsoft.com]
Sent: Monday, February 21, 2005 12:46 PM
To: chris.keller@active-endpoints.com; Dieter Koenig1
Cc: wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Issue 190 - BPEL Internal Faults (New Proposed
Issue
Announcement)
Just to be clear, this exit behavior is not new. It is exactly the same
as the behavior of the "terminate" activity we had before. There was
only a name change.
Re how to deal with standard faults (which are essentially bugs
discovered at runtime), the argument has been that in many cases of
really long-running processes the way to deal with such a fault is not
to unravel the process through the usual mechanism but to allow the
process to be fixed and continued. This is what we are trying to
achieve while *also keeping the existing option of using normal fault
handling*.
I am not really following your argument against the repair-and-continue
option.
Satish
-----Original Message-----
From: Chris Keller [mailto:chris.keller@active-endpoints.com]
Sent: Monday, February 21, 2005 7:37 AM
To: 'Dieter Koenig1'
Cc: Satish Thatte; wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Issue 190 - BPEL Internal Faults (New Proposed
Issue Announcement)
Hi Dieter,
I read over the current draft for the exit activity and it does indicate
that compensation should be skipped. That seems like a bug to me. If I
get
to a part of a process and I need to cancel the entire process, I will
have
to throw a fault and not catch it anywhere to have the rollbacks occur.
Well, the new exit behavior, as is sometimes the case with bugs, may be
desirable sometimes. I think the following sentence from section 13.4
is
misleading, since it implies that not catching a fault at the process
level
is the same as exit.
"If the fault occurs in (or is rethrown to) the global process scope,
and
there is no matching fault handler for the fault at the global level,
the
process terminates abnormally, as though an exit activity had been
performed."
btw - I even feel stronger now that the adjustment to catchAll is far
better
than a process level exit flag. Or we should do nothing at all. Faults
are
faults and some of these faults may not reveal themselves until much
after
the process is in production. For example think of the "invalidReply"
fault, where there is a complex logic leading from the receive to the
normal
reply and a series of fault replies. I have a condition I didn't find
during
testing and my process tries a second reply to a receive that it had
already
replied to. Should the process end silently, with none of the other
scopes
given a chance to repair themselves?
- Chris
-----Original Message-----
From: Dieter Koenig1 [mailto:dieterkoenig@de.ibm.com]
Sent: Monday, February 21, 2005 6:30 AM
To: chris.keller@active-endpoints.com
Cc: 'Satish Thatte'; wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Issue 190 - BPEL Internal Faults (New Proposed
Issue
Announcement)
Hi Chris, as far as I understood the exit activity, it does NOT lead to
the
execution of a handler, including the terminationHandler. However, as
the
spec only talks about immediate termination "without any fault handling
or
compensation behavior", more precise language may be needed to clarify
this.
Kind Regards
DK
"Chris Keller"
<chris.keller@act
ive-endpoints.com
To
> "'Satish Thatte'"
<satisht@microsoft.com>, Dieter
20.02.2005 14:47 Koenig1/Germany/IBM@IBMDE,
<wsbpel@lists.oasis-open.org>
cc
Please respond to
chris.keller
Subject
RE: [wsbpel] Issue 190 - BPEL
Internal Faults (New Proposed
Issue
Announcement)
Satish,
I don't think that the expected behavior of a standard fault would be to
immediately and silently exit a process if it were encountered. Since
the
proposed attribute was exitOnStandardFault one would reasonably expect
that
the behavior would be the same as if the process executed an "exit"
activity. The exit activity does kick in the default
terminationHandler,
which when not explicitly defined does compensate the completed scopes.
As
you point out this rollback (unraveling) is also what happens when one
doesn't catch a fault, which is why I suggested it had the same effect.
I am in complete agreement on allowing the implementation to do other
interesting things like suspend (freeze) when one of these faults is
encountered. That is another reason why I don't want to mandate an
exit,
which I pointed out in my email.
I have seen people add catchAll when multiple declared faults (WSDL
declared
that happen as the result of invokes in the scope) should end up doing
the
same thing (e.g. replying with an error response to an outstanding
request).
Often they don't understand or expect that BPEL standard faults will
also
be
sent there. It would be nice if a user could easily differentiate
between
catching declared and runtime failures. In lieu of a fault hierarchy in
BPEL, I suggested we introduce the idea of standard (runtime faults)
faults
being only caught when the user wants to catch them.
- Chris
-----Original Message-----
From: Satish Thatte [mailto:satisht@microsoft.com]
Sent: Saturday, February 19, 2005 8:30 PM
To: chris.keller@active-endpoints.com; Dieter Koenig1;
wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Issue 190 - BPEL Internal Faults (New Proposed
Issue
Announcement)
Chris,
How would changing catchAll behavior cause the same effect as
exitOnStandardFault? If catchAll doesn't catch standard fault such
faults
would simply unravel the entire instance including default compensation,
rather than freezing the instance so one can (using private means) fix
and
continue.
Satish
________________________________
From: Chris Keller [mailto:chris.keller@active-endpoints.com]
Sent: Thu 2/17/2005 7:45 PM
To: 'Dieter Koenig1'; wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Issue 190 - BPEL Internal Faults (New Proposed
Issue
Announcement)
Hi Dieter,
I think the scope of the proposed attribute is not right. Instead of
this
process level attribute perhaps we could add a flag to the catchAll (imo
the
primary culprit for catching these faults when you don't want or expect
to),
which allows the user to specify that it shouldn't catch standard faults
(similar to the difference between catching Throwable vs. Exception in
java).
<catchAll includeStandardFaults="yes|no"/>
The default could still be no. In many ways this ends up being the same
as
the proposal since the behavior would be implicit fault handling which
is
terminate. This option gives users more fine grained control of their
fault
handling. It also opens up the ability for engines to have interesting
options like suspend on uncaught standard faults. Certainly that is out
of
the scope of this specification, but could be a nice option as opposed
to
saying the default is that an engine MUST terminate a process on
standard
faults.
- Chris
-----Original Message-----
From: Dieter Koenig1 [mailto:dieterkoenig@de.ibm.com]
Sent: Thursday, February 17, 2005 6:52 AM
To: wsbpel@lists.oasis-open.org
Subject: [wsbpel] Issue 190 - BPEL Internal Faults (New Proposed Issue
Announcement)
I would like to modify my original Submitter's proposal for 190 by
adding a
suggestion for an explicit process/scope attribute (see the last
paragraph
below).
Kind Regards
DK
Submitter's proposal: Instead of allowing processes to catch these as
standard faults, we propose that the process instance must *terminate*
immediately when such a situation is encountered.
The behavior of terminate is well-defined in BPEL -- as far as BPEL is
concerned the instance execution ends when terminate is encountered
without
any fault handling behavior. Any additional facilities for extended
support
for, e.g., repair and continue, is definitely out of scope.
This approach would also create a clear direction for dealing with any
pathological situation within an inlined language (Issue 163) and
therefore
also for errors within transition conditions (Issue 169).
In order to support the behavior suggested here and also allow process
modelers to continue using the current behavior, an explicit boolean
attribute can be added to the <process> and <scope> elements:
<process/scope ... exitOnStandardFault="yes|no" ...>
where the default is "yes".
To unsubscribe from this mailing list (and be removed from the roster of
the
OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgr
oup
.
php.
To unsubscribe from this mailing list (and be removed from the roster of
the
OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgr
oup
.
php.
To unsubscribe from this mailing list (and be removed from the roster of
the
OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgr
oup
.
php.
To unsubscribe from this mailing list (and be removed from the roster of
the
OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgr
oup.
php.
To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgr
oup.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]