Database Reference
In-Depth Information
capabilities makes architects and developers look at log mining and infrastructure monit-
oring tools such as Nagios (
http://www.nagios.org/
) closely. In your service infrastructure,
you could have your own homemade monitoring/logging tools, and quite often, deve-
lopers have their own opinions about the usage of log4j and its structure (scattered every-
where). Thus, Log Centralization is one of the primary prerequisites of a successful EH
implementation, although, it's not considered a standard SOA pattern (it's just good com-
mon sense). By the way, Oracle is putting in some efforts in this direction by presenting
different management packs for products' OEMs. Alerts from OEMs can be very useful as
an input for EH.
You will also need to consolidate all logs—when we say all, we mean
ALL
. Data misses
from hidden or stray logs, growing uncontrollably, are not only a perfect recipe for service
resources' depletion and system crashes, but also a juicy target for attackers—and integra-
tion of all Error Handlers are the two main requirements for establishing Policy Centraliz-
ation. Again, here we are talking about fault policies mostly, setting aside all other
policies. This task is harder than the previous type of centralization for several reasons:
• Every tool has its own policy representation and ways of binding it to the event
resolution, and different components within SCA have different policies: Mediat-
or, BPL, and HumanTask.
• The WS-Policy specification along with related WS-SecurityPolicy and WS-Poli-
cyAttachment are not related to most internal policies in OFM. They share some
common principles, but do not expect them to be compatible or easily transform-
able. OEG (API Gateway) Policy Studio will not cover all diversities of policies
despite its name, and it would be better to not use it for a purpose that is different
from security.
Obviously, the complexity of Policy Centralization as a task is proportional to the com-
plexity of underlying individual policies and their alternatives for every Policy Subject
within its scope. These terms will be explained shortly (as you will need them for SOA
exams), but stating it plainly, centralization of EH policies will be positive only if you an-
ticipate all error scenarios for your compositions and present them in a clear hierarchy.
Otherwise, it will be the centralization of
false positives
, thereby mishandling most of the
error situations.
Individual service exception handlers and resource exception handlers could be a good
start for building this hierarchy. The process of speculation on possible compositions in
which this service might participate in would be the second step, and results of this pro-
cess should be properly correlated with established Service Layers (also SOA patterns,
Search WWH ::
Custom Search