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

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

--
Nick

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

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
support
a single interact element that has two or more exchange elements with one
request and one
or more respond actions.

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

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

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

</NK>
>
> Regards
> Gary
>
>
>
>

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