I think the idea is not to get into the business of specifying the magic
switch but to recognize that real world engines will need to provided it.
Any solution that relaxes the requirement to process this situations as
formal faults would help. I like Dieter's proposal in particular but I
don't think that is the one. For example, a process author may be given the
ability may decide if he/she wants to explicitly take control of system
faults or not - that would also help. My point is that the current
situation forces process authors to do this and disallows other forms of
engine support.
Paco
"Yaron Y. Goland"
<> To: Francisco Curbera/Watson/IBM@IBMUS
cc: Prasad Yendluri <>, Danny van der Rijn
02/07/2005 03:12 <>,
PM Subject: Re: [wsbpel] Issue 190 - BPEL Internal Faults (New Proposed Issue
Please respond to Announcement)
ygoland
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:
