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

Still, most of it can be considered as a Governance issue and lack of policy enforcement,
especially from the ownership prospective. There is nothing bad related to adapters imple-
mentation, the topic of this chapter. Or is there?
Let's look at the sequence of messages exchange logic again as follows:
• First, an event is detected. Event subscribers are recognized and the event mes-
sage is issued to all recipients through the common channel (AQ in most cases).
• Recipients recognize the event and activate the object extraction though the stand-
ard OEBS API which we mentioned in Chapter 1 , SOA Ecosystem - Interconnec-
ted Principles, Patterns, and Frameworks .
• For complex business cases, one extraction is not enough, we have to enrich ex-
tracted business objects ( EBO ) several times or build a custom procedure in an
XXCU custom schema for complex data aggregation and use a standard DB ad-
apter for that.
• We will process the business object and return the completion status back to
OEBS.
What can we say about the classic Hollywood principle here ("don't call us, we'll call
you")? Well, apparently, if we have more than one call here, the principle is entirely
broken. Someone is calling us and asking to call back. So much for low coupling and high
cohesion, isn't it? We have a callback MEP where it's not really required. Try to imagine
this type of interchange applied in stock exchange and utilized by stock trading robots: the
robot will receive notification about an index change (time) and then make a decision for
index data extraction (some more time) and after that do the actual extraction (and more
time). Are we going long or short? No matter what, money will be lost anyway.
You can say that this case is kind of extreme; some latency will exist anyway in any sys-
tem, and such rapid response is not really required for RRD business cases (we use AQs
after all). However, the main question remains—why not provide EBM for the actual ob-
ject itself in the first place, not just events notification? We've been talking about schema
standardization quite a lot, but here it seems only the event message is standardized in the
APP_WF_EVENT_T.xsd schema. The main reason for that was mentioned earlier—lack
of governance, which resulted in many versions of the same EBM.
In fact, they are ABMs with no centralized EBO. The object generally provided by the
standard OEBS API is disregarded as too complex or vague. Most of the processes hand-
ling the Event notifications in SOA Suite SCA should be aware of the data models, loca-
tions, and constraints to pull the data out for object construction and enrichment, and for a
more custom version of EBO, you need a more complex extraction for the procedures, by-