W3C home > Mailing lists > Public > public-ws-chor@w3.org > October 2004

Fwd: Follow on discussion: Fault handling endpoint generation to BPEL

From: Steve Ross-Talbot <steve@enigmatec.net>
Date: Mon, 25 Oct 2004 11:13:14 +0100
Message-Id: <7BC5FF10-266E-11D9-9AFF-000393D13C9A@enigmatec.net>
Cc: Nickolas Kavantzas <nickolas.kavantzas@oracle.com>
To: WS-Choreography List <public-ws-chor@w3.org>

Nick in particular but anyone in the group will do.
We need to get the fault handling sorted out (from last week). Gary 
sent in this email and you have all been very quiet.
So I am pinging you for action.

Cheers

Steve T


Begin forwarded message:

> Resent-From: public-ws-chor@w3.org
> From: "Gary Brown" <gary@enigmatec.net>
> Date: 20 October 2004 10:08:54 BST
> To: <public-ws-chor@w3.org>
> Subject: Follow on discussion: Fault handling endpoint generation to 
> BPEL
>
>
> Hi,
>
> [Observations based on BPEL1.1 fault handling - may have changed 
> since?]
>
> Although BPEL does define fault handlers at the process level, that 
> could be used to interrupt a process if a fault was to occur, it does 
> also allow fault handlers to be scoped to the 'invoke' activity. This 
> effectively means that alternative paths through the process can be 
> taken, depending on whether a normal or a fault message occurs, 
> without interrupting the process.
>
> I think it is important that a choreography should be able to receive 
> a fault message without necessarily causing an exception, so that more 
> comprehensive choreographies can be defined - otherwise each 
> interaction that may result in a fault message would have to be 
> defined in its own sub-choreography. However, I don't know that 
> embedding exception handlers within the 'interaction'/'exchange' 
> statement would necessarily be the best thing.
>
> If we were to model the alternative responses as separate 
> interactions, with their own exchange and record elements, this would 
> simplify the notation - but then the problem is ensuring that the 
> association between the interactions is valid - which I think could be 
> handled by a semi-intelligent parser. For example, we need to ensure 
> that all of the interactions statements (representing the receipt of 
> the normal response or one of possibly many fault responses) are 
> placed in a single choice statement, so they are mutually exclusive.
>
> When doing endpoint generation to BPEL, it would then be relative 
> straightforward to take the projections associated with each of the 
> choice elements, and place the fault projections within fault handlers 
> inside the associated invoke activity.
>
> The other approach would be to have multiple exchange elements in a 
> single interaction (as Nick's proposal suggested), but we would need 
> to ensure that the occurance of a fault did not simply cause an 
> exception to be thrown. However, this would mean having some form of 
> decision block following the interaction that would have to check to 
> see which variable had been populated, before knowing which workunit 
> (path) to take next.
>
> I believe this second approach may not be as straightforward to 
> project onto BPEL exception handlers (within the invoke statement) due 
> to the potential for a user to define more complex guards on the 
> workunits following the interaction - although we could always 
> validate to avoid this situation aswell.
>
> Regards
> Gary
>
Received on Monday, 25 October 2004 10:13:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 01:01:06 GMT