RE: [wsbpel-implement] categories of faults

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

Hello Kristofer,

yes I agree completely. Catching a communication error (after some time and efford depending on the QOS of the binding) should be possible in a portable (i.e. well defined) way, without using catch all. And it also should be possible to tell, if it was side effect free (i.e. eighter we throw this exception only, if it was guranteed that no transmission happened (like you suggested), or we add an attribute delivered=no vs. delivered=possibly.

Mit freundlichen Grüßen
Bernd Eckenfels
Chief Architect
--
SEEBURGER AG - Edisonstr.1 , D-75015 Bretten, Germany
Fax: +49 (0)7252 96-2400 - Phone: +49 (0)7252 96-1256
mailto:b.eckenfels@seeburger.de - http://www.seeburger.de


-----Original Message-----
From: Kristofer Agren [mailto:kagren@pakalert.com]
Sent: Wednesday, March 17, 2004 11:49 PM
To: 'Trickovic, Ivana'
Cc: 'bpel implementation'
Subject: RE: [wsbpel-implement] categories of faults


Ivana,

While I think that propagating protocol/communication level faults in
general is a can of worms and a job for the different implementations to
handle, having a standard "serviceUnreachable" fault would be very helpful
in many cases. I am sure there are a number of scenarios where it would be
perfectly acceptable for a business process to consciously handle such a
fault, such as simply selecting another end-point or returning a specific
fault to a caller. 

The "serviceUnreachable" fault should only be thrown if it was not possible
to contact the service, it is 100% certain that no work was done on the
remote end, and there will be no further attempts by the engine to deliver
the request.

Any thoughts?

Kristofer

-----Original Message-----
From: Trickovic, Ivana [mailto:ivana.trickovic@sap.com] 
Sent: Wednesday, March 17, 2004 10:36 AM
To: 'wsbpel-implement@lists.oasis-open.org'
Subject: [wsbpel-implement] categories of faults

Hi all,

On Monday we were discussing different kinds of faults in BPEL. It is
probably worth to identify different categories of faults in order to better
organize the discussion and finally see if there is a new issue.

The following faults categories could be identified:
* Application/process-level faults: these faults are listed in Appendix A
(Standards Faults) of the BPEL specification. 
In this category belong also fault messages that may be output of a WSDL
operation. If an <invoke> activity performs a synchronous operation that
receives a fault message it will be terminated and the fault will be
implicitly thrown.
* Protocol-level faults: these faults are raised by the underlying
protocols; the question is whether these faults are all propagated up to the
process level 
* System faults: these faults are raised by process engines executing BPEL
processes; from my point of view, these faults are non-recoverable and
cannot be propagated up to the process level.  

Your thoughts?

Ivana