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 Wednesday, 20 October 2004 09:08:18 UTC