Database Reference
In-Depth Information
Establishing the Adapter Framework
The Adapter framework optimization, or, in fact, the minimization of all protocols/endpoint
types aiming the realization of the Official Endpoint SOA pattern presented previously, de-
pends on many factors (we have indicated them in the Conclusion section), but decisive is
only one. As we already mentioned, this factor is not technical, unfortunately. At the end,
the main question is the level of ownership we as architects have on refactored application
endpoints. When the approach is invasive (we have to inject unified triggers and establish
event handling and ESR schemas), we totally depend on the level of cooperation with the
application owner/vendor. If this approach is not approved, then noninvasive methods shall
be considered and some of them, as we explained earlier, could be based on disaster recov-
ery data replication and here we could face even bigger resistance from DBAs/Operations.
Who can blame them? The approaches we discussed in the first part of this chapter have
been proved many times and you can completely rely on them, but at the end, everything
will rest on your ability to convey the rational of discussed SOA Patterns to the managers
and application owners. We already gave you enough arguments to win hearts and minds
(including the real operational figures, which in complete stress test were 35 percent high-
er), so we will put this discussion aside for now, but the possible outcome of this discussion
could be "Build the integration layer to get our data" and that means—establish full-fledged
ABCS. It doesn't mean that our optimization failed; it's just another confirmation that the
SOA approach has plenty of room for traditional integration methods, which we will apply
consciously. Thus, we move back to the CTU Telecom Enterprise, as we left it in Chapter
4 , From Traditional Integration to Composition - Enterprise Business Services .
One small note before we continue with the CTU Adapter framework. Application Ad-
apters, Technology Adapters, and Protocol Adapters are really a strong (and probably the
strongest) side of OFM. The list of available adapters is enormous (we mentioned it in
Chapter 2 , Oracle Fusion Introduction - A Solid Foundation for Service Inventory ) and the
methods of their implementation are wizard-based and very native. This fact also reflects
Oracle's transition from traditional integration to the composition-oriented approach. You
can find a lot of topic and web tutorials full of step-by-step demos, overloaded by screen-
shots, and we would like to spare you from that here. Still, some rules of thumb will be
mentioned, which are as follows:
• The primary rule of adapters design can be expressed as "sacrifice the Reusability
for better Loose Coupling and Contract Standardization". Indeed, for better modu-
larity and performance, each adapter should be tailored to the application's end-
Search WWH ::




Custom Search