Oracle has come a long way from ad-hoc apps that link to enterprise integration and finally, to the full-fledged service orientation. With no doubt, products from Collaxa, BEA, and Sun turned the single DB-company into one of the strongest Middleware players with the most advanced products in the portfolio. Importantly, we see that Oracle SOA's product stack is evolving and this evolution is guided by the open standards committees where Oracle is the one most active contributor and is influenced from partners and customers who bring business demands and challenges. At the same time, it is important for us not to follow this path blindly, trusting somebody else's strategy, but rather choose our own way of achieving the strategic goals. In this sense, Oracle is setting a good example by assembling its own and acquired products following the Composability principle and giving us a wide range of the tools, enabling service-oriented computing.

Some architects accuse Oracle of offering products with overlapping functionalities in application suites and packages. Indeed, this claim has factual context. Apparently, overlapping can hardly be avoided in a particular market's expansion strategy. But honestly, most of the enterprise architects have to admit that in our own companies, the level of redundant denormalized functionality in applications/services is sometimes far from optimal, and that's normal. Architecture is a living mechanism—it has to evolve—and as long as we do not want to get into the disastrous Big Bang approach, we have to move gradually, allowing some level of functional denormalization along the way. So Oracle does as well.

What matters is the way we normalize our functional and technical boundaries. More rationally, this could be done by applying the SOA principles and standards in identified frameworks. After all, most of the Oracle components in software packages are optional. If you do not have long-running services, go for OSB (EBS) first and turn to SOA Suite (EBF) later, when necessary. If your security requirements are particularly high and performance must not be compromised, consider the API Gateway as your single service collaboration platform with no extra layers. If you run mostly heavy-batch jobs during the night hours, give ODI and master data management (MDM) a general thought; however, bear in mind that these tools are also parts of the EDN and AIA SOA implementation. Nevertheless, what almost certainly will be presented in your infrastructure are the core ten frameworks, and as we discussed in this chapter, Oracle has good candidates to employ.

As a final example to conclude this chapter, we can look at the industry-specific case of an SOA platform realization based on Oracle products. The telecom industry is rapidly moving these days, both technologically (emerging 4 K TV + H.265 HEVC codec and to accommodate it at home -802.11 ac routers) and commercially (any content + any protocol + any device + any place). To accommodate this business shift technologically, another term was proposed— Service Delivery Platform (SDP)—and all the key telecom providers rushed to offer their platform realizations: Huawei, Amdocs, Ericsson, Alcatel-Lucent, and Telcordia. According to Gartner (market analysis 2012), Oracle is among the strongest three SDP providers. However, what is Oracle SDP? Again, Oracle's Telecom-specific products are the result of the latest acquisition (from Convergin): Oracle Communications Converged Application Server (OCCAS), Oracle Communications Services Gatekeeper (OCSG), and Oracle Communications Marketing and Advertising (OCMA).

Generally speaking, the controller and gatekeeper are the elements of the telecom-specific adapter framework, handling telephone network protocols (OCCAS: SIP, ISC, INAP, and so on) and telecom enablers (OCSG). Gatekeeper is also capable of handling home devices, such as REST and SOAP calls. Unsurprisingly, these ABCS elements are connected to the enterprise backbone, where Oracle Service Bus, SOA Suite, Service Repository, and API Secure Gateway are playing the same roles as we discussed for each enterprise framework. Oracle put considerable effort into the Contract Standardization of each component of the Telecom SOA platform, abstracting specific protocols to increase SDP Composability and demonstrating a high-level of reusability of its own assets to achieve strong merits.

Now we are ready to look at the most widely recognized SOA framework, Enterprise Business Flows (EBF), and see how SOA patterns can solve typical problems there.