Taking Care – Error Handling - Applied SOA Patterns on the Oracle Platform - page 471

Chapter 8. Taking Care - Error Handling
While discussing security patterns, we described handling (or, in fact, mishandling) faults
as one of the major contributors to the vulnerabilities of SOA, and the inadequately de-
signed Fault/Errors Handling (EH) framework is apparently the main provider of all in-
formation to the error/event logs and the "grateful" attacker. We mentioned some simple
rules for exception handling inside a single service (Entity or Utility service models) as the
sole building block of the entire SOA infrastructure. Implementation of this rule would be
enough for an infrastructure that contains only these models of SOAP services or simple
REST services without compositions of any complexity. When we have something more
complex (such as Task Orchestrated service models) or in fact any external exposure along
with associated security risks or (usually) both, something that is a lot more substantial is
required. This something in addition to a proper EH's service design will require events
logging and log mining/analyzing; it also requires you to add compensation handlers, build
compensation policies, bind policies and handlers, and establish manual recovery routines
in a worklist as the last line of defense. More often than not, the complexity of the steps we
just mentioned is frustratingly high (composition with three sequential invocations can eas-
ily span compensation activities with five invocation steps). It is so complex that after sev-
eral workshops and incomplete prototypes, architects decide to put all of the handling into
a work list to come up with a manual resolution with all the associated human-related prob-
lems (responsiveness, accuracy, and consistency).
The design of our agnostic composition controller will be incomplete and the whole idea of
dynamic composition assembly compromised if we do not demonstrate how to automate
error recovery using SOA patterns. Traditional Oracle OFM/SCA realization covers both
Rollback and Compensation patterns (where Rollback is part of Atomic Transaction
Coordination and Compensation is BPEL/SCA); the automated recovery functionality is
usually consolidated in the policy-based Error Hospital OFM facility.
It would be useful to look at the term policy-based and understand what the policy is, how
it can be enforced, how many of them there are, and is it really possible to centralize all
policies in one center. The role of the Service Repository, whose taxonomy we discussed
earlier, has to be observed from one more side.
In this chapter, we are going to discuss standard tools first, explaining what kind of central-
izations you have to maintain to achieve Policy Centralization (for recovery, compensation,
and composition protection) as well as basic patterns such as Compensative Service Trans-
action, Service Repository, and Service Instance Routing. However, the main purpose here