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

ted EPs as FSO, stored as simple files, and decomposed them as DB elements in
Chapter 5 , Maintaining the Core - the Service Repository .
The ExecutionPlanLookupService is capable to work with both imple-
mentations, abstracting physical storage resources. Thus, a simple script or ser-
vice can easily dump the EP from the database every time some changes occur;
how it works was explained in Chapter 6 , Finding the Compromise - the Adapter
Framework . The same is true for the Oracle ESR implementation, where standard
synchronization ESR to the UDDI utility can be extended with an additional func-
tionality for EP FSO. Adhering to this rule will eliminate the risk of ESR runtime
unavailability quite gracefully. Unfortunately, it will present a risk when a deve-
loper tries to cut some corners and perform alterations directly on FSO, bypassing
ESR. Also, this could be the case for an insecure direct object reference vulnerab-
ility; see Chapter 7 , Gotcha! Implementing Security Layers . Well, there is no per-
fection in the world. The first issue can be addressed with proper governance (set
the watchdogs around your Service Repository). The second is about establishing
a Trusted Subsystem pattern and avoiding using SB in adapters at the Service
Gateway for external services (which is not always possible). This rule can also
be associated with the newly introduced Reference Data Centralization, but we
believe that the existing Metadata Centralization pattern is overkill. There is no
need to inflate the SOA pattern catalog with obvious things.
• Rule 11 : Apply EM rules according to service layers. Passive Northbound ad-
apters do not propagate validation errors to EBF. Transformation errors related to
missing XSLT should be propagated, but their probability is rather low (usually
related to incorrect deployment and fixed in the first hour).
• Rule 12 : Propagate the errors according to service layers. VETRO errors from the
south will be propagated back to the EBF SB after completing basic recovery op-
erations (if assigned).
• Rule 13 : Observe Service Message TTL when applying EH rules. Combined lo-
gical outcome of rules 11 and 12 strictly observe service message time-to-live
(business validity period, set in MH). If business data is actually set to 30 minutes
only and you set the Retry option on OSB with three different intervals of 5, 15,
and 20 minutes, it will do no good. Again, work diligently on Metadata Centraliz-
ation (previous figure) and define your business exception policies clearly. Use
SOAP/SBDH header elements for propagating business policies to local Error
Handlers, together with the State Messaging pattern (Message Tracking Data sec-
tion in CTU EBM, explained in Chapter 5 , Maintaining the Core - the Service
Repository ).