Database Reference
In-Depth Information
Summary
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 assem-
bling 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 ap-
plication suites and packages. Indeed, this claim has factual context. Apparently, overlap-
ping 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, allow-
ing 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 ra-
tionally, 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 per-
formance must not be compromised, consider the API Gateway as your single service col-
laboration 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 mov-
ing these days, both technologically (emerging 4 K TV + H.265 HEVC codec and to ac-
Search WWH ::
Custom Search