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

could promote reusability on the Adapter level, balancing adapter-related SOA patterns
between OSB and ABCS. Remember, although perfectly operational, this technique
should be applied with caution, depending on the number of legacy applications in your
infrastructure and the level of their similarity. Sorry, it would be quite irresponsible to give
you numbers for selecting any of these approaches, but the CTU example can give you an
understanding of what could be really achieved.
Finally, if first two approaches are not possible, you can employ the standard adapter tech-
nique, quite well-known from version 10 g and even earlier, build the individual adapters
for all applications, and decouple them using OSB. Some examples for that have been
provided as well.
Once again, just in case if someone has an idea—we have nothing against Adapters, we
love them. Frankly, it's a good way of making money (although we believe that compos-
ing yet another topic, full of screenshots from BPEL Creating Partner Link for all type of
adapters wizard would be quite useless for you as you probably have enough already).
Adapters are inevitable and play essential roles in many solutions, presenting Data Integ-
ration, Virtualization, Federation, and Master Data Management. Most of them are based
on classic SOA ESB patterns and can be quite effectively implemented on the Oracle
OFM (surely, most salesmen of these tools will strongly disagree with us). Anyway,
Oracle has a single product called ODI to cover most of these requirements, but that's the
subject of a completely different topic.
Only the journey is written not the destination. Our next stop will be the Security Patterns
and how they can be applied at all levels, from a single Java component up to Security
Gateway. We will look at possible threats, attacks types, and the methods of risk mitiga-
tion.