We are in the middle of the book, but journey is far from over yet. So far we covered the three main SOA Frameworks: Service Collaboration (ESB), Service Orchestration (EBF), and Application Business Connector Services (ABCS, or Adapters) and all SOA Patterns associated with them. We also described the role of Enterprise Service Repository (yet another framework, heart of the SOA Governance) in all of these frameworks. This chapter, entirely dedicated to the ABCS layer had no purpose to cover all aspects of Adapters implementation though, but rather how to optimize this layer in order to make all our service-oriented applications in our inventory more intrinsicly interoperable (one of the major SOA characteristics, you remember).
Why? Well, why does a classic construction brick have pretty much a standard size of 3 5/8". 2 1/4". 8"? Maybe because none of the construction architects in the entire world want to have their masons waste their time adjusting boulders, rocks, and stones instead of building houses and bridges? And further on, maybe that's the way the Pattern-based standardization approach, proposed by Christopher Alexander, becomes so increasingly successful among the software architects as well?
The Extensive Adapter framework is not only a waste of time (and money) during design time and development, but also the constant pain for Operations and Support depts and the reason for more than 80 percent of outages and breakdowns in our operational environments. All middleware specialists know that they are the first people to blame when the message from source A didn't reach destinations B and C. The root cause of that—application A initially was not able to collaborate with applications B and C, and the adapter was simply unable to fix this problem for a complete 100 percent. Even if it could, it's an extra layer, adding complexity to our landscape and therefore making it susceptible to faults.
Thus, our primary architectural task would be to make our core applications more service-oriented for eliminating the requirements for adapters. This approach was demonstrated in the first part of this chapter, when we optimized the OEBS APIs and Event Handling System for the Scandinavian Logistic operator. You were supplied with enough information and code samples for your own implementation of this approach.
Composability and Composition Controllers are the primary goals of this book as this principle and these building blocks are endorsing reuse and modularity (read—cost savings and operational reliability). Therefore, the second part of this chapter demonstrated how we 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 technique, quite well-known from version 10g 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 composing yet another book, 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 Integration, 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 book.
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 mitigation.