What are faults in a Web Service?

BPEL introduces fault handlers in order to let you deal with exceptional situations, such as the following:
A fault recognized as the result of a Web service invocation
A fault thrown explicitly by the process logic
A fault caused by a problem encountered by the runtime infrastructure

The BPEL runtime infrastructure recognizes a number of predefined exceptional situations within a running process instance. If such a situation occurs, a BPEL standard fault is raised. Examples for such standard faults are
mismatchedAssignmentFailure—Incompatible types in an assign activity
forcedTermination—Fault in an enclosing scope
correlationViolation—Message contents in receive, reply, invoke, or pick/onMessage don't match correlation data
uninitializedVariable—Attempt to access an uninitialized part of a message variable
invalidReply—Attempt to execute a reply for which no corresponding receive activity has been processed

Fault Handlers
In BPEL, fault handlers are the mechanism to explicitly catch these faults and respond to them in appropriate business logic. Fault handlers are associated with a scope activity or with the overall process.
When a fault is recognized, the scope or process first stops all its nested activities. Structured activities are terminated immediately. Some types of basic activities are also interrupted, including wait, receive, reply, and invoke. Other activities are considered short-lived and aren't interrupted.
A fault handler contains an activity that runs in case the corresponding fault occurs. For example, the fault handler may contain a reply activity that notifies a partner that normal processing of the logic can't be completed.
Syntactically, a fault handler is a catch or catchAll element. The catch element lets you specify the qualified name of a fault, a fault variable, or both. The fault variable can be omitted in cases where faults don't have additional data associated with them. The catchAll element doesn't have attributes.



Transition conditions on the links determine whether the validation result is OK or considered failed. In the latter case, a fault is thrown explicitly. The associated fault handler sends a fault reply message.
If a fault handler throws a fault itself, then this fault can be caught by the next higher enclosing scope. This applies to explicitly rethrown faults and to unexpected faults that occur during processing of the fault handler.

Not every scope has a fault handler specified for every possible type of fault. When a fault isn't caught by a fault handler, then a default fault handler applies. The default fault handler runs all available compensation handlers for immediately enclosed scopes in the reverse order of completion of the corresponding activities, and then rethrows the fault to the next enclosing scope.

The fault-handling concept in BPEL is similar to exception-handling in Java and other programming languages.