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

• Rule 14 : Maintaining preventive Error Management must be preventive.
However, avoid using heartbeat test messages for performing ABCSes (both pass-
ive and active, especially for active) health check, either for north or south. This
is a valid technique for JIT and Unit tests, but not for production; it could (and
most probably will) complicate everything from data cleansing in the production
database to opening the door for attackers' message probes. There are plenty of
other methods to check the status of your service edges, and JMX should be one
of your first choices. Oracle OEM and OEM management packs are shipped with
predefined thresholds for main vital parameters. Please use them. It might be
funny if it weren't so sad; how many problems could we avoid if the DBA (and
Nagios) admin reacted properly on clear 99% of ORABPEL table space
is full ?
• Rule 15 : Automated Recovery Solution should be SB-based. Again, Error Man-
agement must be preventive. This means that our service edge handlers (with re-
tries, abort and so on), individual service handlers (BPEL Fault Handlers, Com-
pensative Transactions, and Mediator policies), and SB-centralized policy-based
handlers are in fact reactive and not truly effective (yet essential). Real prevention
comes from the already mentioned Log Centralization, just-in-time analysis of all
technical information from the entire technical infrastructure (through JMX,
WLST, or Jython), and an immediate response. To come to this realization at this
point sounds like telling your 18-year-old kid that there is no Santa. Actually, this
realization just spawns another rule in addition to rules 9 and 14; a proactive com-
ponent that contains ART will be presented effectively, controlling the already
mentioned Log Centralization: data log cleansing, on-the-fly analysis, and trigger-
ing preventive or recovery actions. Yes, this is actually the event-driven SOA, a
combination of Event-Driven Network, Event-Driven Messaging , and Com-
plex Event Processing (CEP) ; although, for reasons explained in rule 9, we can-
not put all our eggs into the "OFM Mediator with BPEL Sensors and Events de-
clared in BPEL's Invoke Operation" basket (those are the main OFM EDN play-
ers). Actually, it's not possible technically as we will control the entire OFM's un-
derlying infrastructure; refer to the next figure.
Tip
Every rule paragraph is considerably bigger than one line; however, we have not
only manifested the rules, but have also put clear reasons behind each of them for
you. These reasons are not only the result of the following SOA design principles
and SOA patterns (both clearly indicated), but the quintessence of our own com-
bined experience from various projects. Some say rules are meant to be broken.