Databases Reference
In-Depth Information
Error Handling
Handling errors or faults is an important consideration for
service-oriented
architecture
(
SOA
) based applications, especially if you consider that a solution is
likely to be a loose assembly of independent components, each with varying levels of
resilience, throughput, and availability.
How faults are handled depends on a number of factors: whether it's a business or
system fault, was the service where the fault originated called synchronously or
asynchronously, and whether the interaction between the client and the component
detecting the fault is synchronous or asynchronous.
A business fault is loosely defined as one we know about in advance. It is defined
as part of the service contract, and thus represents a legitimate state within the
business process. How we handle a fault of this type is largely driven by business
requirements, and so it makes sense to handle these within the context of the process.
A system fault conversely is one that is unexpected in nature and could
typically occur to any component in the solution. Such faults are often caused by
infrastructure problems, such as a network outage or a service being unavailable.
Often these are temporary and can be handled by retrying the service at a later time.
The interaction between the client and the component detecting the fault also
influences how we handle it. If asynchronous, the component has the time to resolve
the problem. For example, if the fault occurred due to a service being unavailable, it
can retry it later.
With synchronous interactions, we only have a small window in which to resolve the
fault before the client times out waiting for our component, and raises its own fault.
With this style of interaction, often all we can do is catch the fault, undo any partially
completed activities so we leave the system in a consistent state, and then return a
fault to the client.
