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

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

From: Nickolas Kavantzas <nickolas.kavantzas@oracle.com>
Date: Mon, 25 Oct 2004 14:40:44 -0700
Message-ID: <02f501c4badb$4884e690$48af2382@us.oracle.com>
To: "Gary Brown" <gary@enigmatec.net>, <public-ws-chor@w3.org>

See comments below. I am expecting that we spend time tomorrow in the
con-call to discuss
these issues in greater detail.


----- Original Message ----- 
From: "Gary Brown" <gary@enigmatec.net>
To: <public-ws-chor@w3.org>
Sent: Wednesday, October 20, 2004 2:08 AM
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
> 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
> 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
> thing.
> If we were to model the alternative responses as separate interactions,
> 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
> 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.

Two points:
1) the rules for associating the exchange/record parts of an interaction
that span multiple interaction
elements have to be clearly specified and this may be a challenging
exercise. What are
the exact rules your are proposing for the associations?

2) even if the association rules are properly spelled out, we still need to
a single interact element that has two or more exchange elements with one
request and one
or more respond actions.

> 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
> 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.

<NK>As we've discussed in last week's con-call there are no surprises in
this approach</NK>
> I believe this second approach may not be as straightforward to project
> 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.

Again, I think that there are no surprises here:
-faults that are caused in an interaction are triggering exception work
units to be considered for
-normal data populating variables in a exchange/record of an interact are
triggering normal
work units to be considered for matching

> Regards
> Gary
Received on Monday, 25 October 2004 21:41:28 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:01:05 UTC