RE: [wsbpel] Issue 190 - Adding a switch

["Eckenfels. Bernd" <B.Eckenfels@seeburger.de>]

Hallo Yaron,

I agree, and want to add, that not only in short lived processes ony
might want to do such a clean up handling. We for example use a catch
all handler to generate an Alert List Task Item and post it to a Portal.
This item contains info for restarting the process and for detals.

Therefore we like to have a  catchAll (on proces scope) which can 

A) catch system faults (especially from transports)
B) catch BPEL faults
C) retrieve detailed info (location, fault typ, fault details)

Also we like to have a assign.copy  whith an xpath expression which
might not find any matching element (because the falt type does not
support it) for exmple to look for "/mycomany/traceInfo"

-----Original Message-----
From: Yaron Y. Goland [mailto:ygoland@bea.com] 
Sent: Monday, February 14, 2005 11:19 PM
To: wsbpeltc
Subject: [wsbpel] Issue 190 - Adding a switch

In many processes, especially shorter lived ones, users don't want to
require administrative intervention if a process runs into a system
fault. They would much rather just put in a fault handler that can
detect that a system fault has occurred, clean up any resources the
process is using and shut the instance down.

190, as I understand it, would make the previous impossible in a
portable way. If we pass 190 then as soon as a system fault occurs the
process must terminate. At that point no further standard behavior is
possible.

At a minimum we should keep the current portable behavior for the many
scenarios where it is useful.

Potentially we could introduce a switch which could specify that if a
system fault is thrown then the process should be terminated. The
purpose of the switch is to let the programmer know that they don't ever
need to worry about handling system faults in their code because their
code will never see the system fault.

But I must admit that the utility of the switch is suspect as it depends
for its utility on exactly what the admin will do after termination,
something that is completely undefined in BPEL.

But in any case, we shouldn't remove the current portable behavior.

		Yaron




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.