RE: [wsbpel] Issue - 20 - installing compensation handlers for faulted scopes

["Satish Thatte" <satisht@microsoft.com>]

Ram,

Your pattern (c) is actually likely to be not uncommon since processes
often perform risky optional work.  This then becomes the "don't care"
case.  The scope's success\failure will likely be reflected in shared
data and integrated into the logic that way.

Regarding alternative completion one can already do that with
conditional work following an unsuccessful scope completion.  Not fully
integrated at the scope level but it seems less complex to understand
than explicit control over installation of compensation handling in
fault cases.

Satish

-----Original Message-----
From: Ram Jeyaraman [mailto:Ram.Jeyaraman@Sun.COM] 
Sent: Sunday, September 21, 2003 5:40 PM
To: wsbpel@lists.oasis-open.org
Subject: [wsbpel] Issue - 20 - installing compensation handlers for
faulted scopes

Following up on the conversation at the F2F meeting last week,

Normally, a control flow is short-circuited when a fault occurs. The 
application may trap the fault and perform corrective actions { undo or
redo }, 
and may decide to suppress the fault or rethrow the fault, depending on
whether 
it is able to recover fully.

(a) Fault suppression upon redo

In the case of a successful redo, the application may choose not to
rethrow the 
fault and hence allow normal forward progress.

But, as observed earlier, attempting redo or alternative normal
completion may 
be hard to implement in most cases, due to the relative complexity in 
implementing an appropriate compensation logic that accounts for such
alternate 
successful completions.

(b) Fault rethrow upon undo: The application may perform cleanup, undo,
etc., 
and rethrow the fault, thereby short-circuiting the normal control flow.
No issues.

(c) Fault suppression upon undo: This is a bit problematic, since the
control 
flows forward, just as normally as it would have otherwise, in spite of
the 
fact that a full recovery was not performed.

While this is a valid usage pattern, it is hard to program a sequential
control 
flow, since each forward step may now have to adapt its behavior
according to 
the outcome of previous completion or completions.

Summary:

1. It may serve to warn against the potential anomalies of usage pattern
(c).

2. Regarding usage pattern (a): It is possible applications may want to
perform 
alternate normal completions in simple cases. Enabling such an usage
would mean 
installing a compensation handler for a faulted scope, upon *explicit* 
application request. That is, a fault handler may explicity request that
a 
compensation handler be installed for the faulted scope, since it was
able to 
perform an alternate normal completion for the faulted scope. Providing
for 
such explicit enablement of compensation handlers may serve applications
that 
attempt alternative normal completions in simple cases.


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.