Fault handling is basically running an alternate activity when a fault is detected in the main activity of the process or one of its nested scopes. While the principle is simple, the ability to perform an arbitrary activity in response to a fault makes handling it a multi-step, long duration procedure which must be tracked and logged.
Things get even better. The reaction to a fault varies according to the state of the scope where the fault is thrown. What if a fault occurs when another fault is being handled already? The following picture from the BPEL spec explains the state changes:
Transition exited is taken when the fault handler completes, whereas faulted is taken when the handler fails. In the latter case the fault is rethrown to the enclosing scope.
The package org.jbpm.bpel.exe.state implements the above state diagram. The design follows the state pattern.
Class ScopeState plays the State role. Other classes in the same package represent the concrete states. Note that TerminatingState corresponds to the Canceling state above. The rename follows a terminology change between BPEL4WS 1.1 and WS-BPEL 2.0. The Context corresponds to ScopeInstance. When a fault occurs, method faulted is invoked on the scopeInstance, passing the available fault details. This method delegates to its peer in ScopeState for state-dependent behavior.
JIRA issue BPEL-9: fault and termination handling is currently on my plate. What is left to do is fill in the blanks in transition methods and make sure everything works according to the spec. I'd like to mention that the existing foundation was laid by Juan Carlos Cantu, a good friend of mine and a former member of the jBPM team.
