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

Common requirements
Let's get back to Chapter 1 , SOA Ecosystem - Interconnected Principles, Patterns, and
Frameworks , and look at the figure under the SOA Technology Concept one more time. In
the first chapter, we tried to consolidate WS-* specifications in one logical roadmap. Gen-
erally speaking, we do not have standards that are specially dedicated to Error Handling,
and activities in this area are governed by policies (as we mentioned, not exactly WS-
Policies and differently for all vendors); this is due to the importance of the subject we put
on the right-hand side of SOA patterns (generic) under the roof of the consolidated Error
Hospital (which is Oracle-specific). So, we must have and maintain the following:
• The ultimate importance of the Exception Shielding pattern for SOA security has
been explained in the previous chapter. There, we stated that doing shielding and
error message sanitation on the gateway is not a good choice because unclean mes-
sages will travel across the whole infrastructure until the front door before it is
cleansed/blocked. However, what if you do not have a Gateway? Even if you have,
think about the processing pressure you put on the secure perimeter, which is
already loaded with Message Screening tasks, or the possibility to read an error's
theatrical information within your network. Anyway, excessive messaging could
unnecessarily stress your network. Therefore, cleansing must be on service at first
hand, at least for proper distribution of the workload.
• Another task associated with Exception Shielding is the translation of an error's
message/code. Unfortunately, this task cannot be performed on a service; that's the
responsibility of the Composition Controller (within Error Handler as well). When
the remote application returns a completely valid error message with an error code
that is different from your service domain notation, it must be filtered/normalized
according to your standards. As a typical composition controller is either an SCA-
or OSB-based service, it can be done on these inner layers. Alternatively, it can be
done by an adapter in the ABCS Framework using Adapter Factory (which is also
OSB-based in our realization). In our design, we have the Lookup functionality,
but its main purpose is to extract from the ER transformation descriptor (XQuery
function or XSLT) or endpoint's URI. In this case, translation can be performed by
transformation, but everything depends on the transformations' complexity. Trans-
formation of an acknowledged message from an external service would be requited
anyway, as we should not expect that its format will be the same across different
domains; this would be too ideal.
If you decide to handle it in SCA, traditional Domain Value Maps will do the job
with the handy dvm:lookupValue function. Later, we will touch upon how it