Finding the Compromise – the Adapter Framework - Applied SOA Patterns on the Oracle Platform - page 379

passing standard OEBS APIs. Finally, we have the hybrid type of services, mixing ad-
apters functionality and task-orchestrated service operations in one service.
There is no service bus like the one we discussed in Chapter 4 , From Traditional Integra-
tion to Composition - Enterprise Business Services , it's pretty much a two-layer architec-
ture with one core application and lots of denormalized hybrid services with overlapped
boundaries, multiple adapters, some generic (for event) and many proprietary, extracting
similar business objects with small variations.
Inside the main application, we can see a lot of custom triggers with overlapping trigger-
ing conditions and elements of business code, resulting quite often in ORA-04091: table
<tablename> is mutating… .
Now the picture is quite clear, we hope. So, what would be the action plan? Ultimately,
we should put BES back to operation as the standard Oracle event system, but ideally we
should propagate canonical EBM to task services around OEBS, not events. In other
words, we should get rid of the callback pattern and eventually minimize the Adapter
framework footprint here. We have the perfect opportunity for that, as we have a snow-
flake architecture (classification you can find in Application Integration: EAI B2B BPM
and SOA from Bernard Manouvrier and Laurent Menard) in place with a single "source of
truth" (OEBS with linked business domains) and lots of trading partners, capable to accept
RRDs canonical objects. Therefore, the proposed steps are as follows:
1. As a "table mutation" is the immediate problem, remove all triggers from core
business tables and present one unified way of event detection.
2. Consolidate all enterprise objects representations under canonical models, present
them as generic XSDs, and make them public and available for all external/intern-
al developing teams. SOA MDS and external HTTP servers will be good options.
3. Analyze message construction procedures and consolidate them inside OESB in
order to eliminate the Adapter framework (at least minimize the footprint). All
SCAs/BPELs should receive the required EBM without enrichment or excessive
transformations.
4. We are not only constructing messages, we receive them as well. Supply every
EBO with a unified individual parser/loader. It will conclude the message-hand-
ling components set (constructor/parser).
5. After removing table triggers, we have to put all event's recognition/filtering logic
somewhere. That will be our rule functions and the XPath artifact, which we also
have to register in the Service Repository (or BES subsystem when it will be op-
erational again).