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

• As a result of the previous point, the development cycle reduced considerably.
Implementation of a complex message with all related events reduced to two
working days (Purchase Order EBM). The entire Order Management program
was implemented in two weeks, plus two weeks for thorough testing (from the
very beginning we agreed that every message handling module will be supplied
with testing packages, that is, the actual parser will be delivered with the con-
structor for unit test and vice versa). Interestingly, the dynamic execution ap-
proach (based on the service Repository taxonomy and NDS) became so popular
that we had to restrain developers from using it for purposes other than event fil-
tering, message parsing, and construction.
• Finally, now you can clearly see the resemblance between the RTD pattern, im-
plemented in Chapter 4 , From Traditional Integration to Composition - Enter-
prise Business Services in custom Service Broker realization and this solution. We
used the same methods, patterns, and semantics. Obviously, according to the Law
of Indestructibility of Matter, the Adapter framework cannot just disappear by a
flick of the SOA magic wand. We have to move some components to another lay-
ers, also changing the surroundings (Canonicalization first).
In addition to the development perspective, we would like to explore several points from a
pure vendor-neutral architectural standpoint, as follows:
• Without any revolutions or the Big Bang, we refactored the solution making it
more composable. We followed the reusability principle, employing existing curs-
ors for message construction. We engaged the Loose Coupling principle for the
separation of event detection, message construction, and message delivery. We
observed the parallelism, maintaining desirable throughput and performance. And
most importantly, we implemented Canonical Schema and Canonical Protocol;
the main enablers of Composability for this solution.
• We enforced the Hollywood principle, presenting a completely decoupled agnost-
ic solution. Now, middleware does not need to know anything about OEBS APIs,
internal table structure, concurrent programs, and so on to pull the data after re-
ceiving an event message. The complete (Canonical EBM) message is promptly
delivered with minimal delay.
• No protocol bridging, no transformations, both model or format. The number of
EBM/EBOs has been reduced to the optimal level.
• Finally we considerably reduced the Adapter framework around the Oracle E-
Business Suite. That was our ultimate goal and we reached it in a very short time.