Database Reference
In-Depth Information
Summary
Using an interactive approach, we gradually constructed our first SOA framework that is
responsible for holding, running, and maintaining our Enterprise Business Flows (in
Oracle's AIA notation). Although AIA denotes this framework as optional, in reality it's the
most common and heaviest element of the integration infrastructure in almost any enter-
prise. Consequently, the source of practically all the problems in this framework is the un-
derstanding of business flows as part of a solid integration, sometimes point-to-point and
not service collaboration.
Orchestration, according to the SOA pattern catalog, is the biggest compound pattern, com-
prising many atomic patterns that are responsible for turning the integration approach into a
more agile service-oriented computing. As demonstrated in this chapter, the first step
would be the proper categorization and decoupling of our bulky services according to their
models and levels of granularity. Reassembling these services into managed compositions
should not always be done in a static way, especially for services of a similar business
nature with slight composition variations. Despite the nature of a static BPEL (rather ima-
ginable), it's quite possible to implement agnostic Composition Controllers that are capable
of assembling business processes dynamically. At first, we must stay focused on business
process parts, which can be automated without manual interventions; Oracle SCA compon-
ents such as BPEL, Mediator, and Business Rules are the main building blocks, and they
are powerful enough to deliver any Orchestrated solution.
We also demonstrated a problem-focused approach, where we do not lock on to particular
patterns, but rather strive to alleviate the negative sides of the existing solution by applying
the most fitting method (based on pattern, if possible). By practicing this approach, we
demonstrated a flexible way of understanding patterns' boundaries using Service Broker
and Intermediate Routing patterns, which are originally bound to OSB in the Orchestration
framework. We kindly advise you to follow the same "pattern", so to say, not focusing on
the patterns' catalog, but analyzing the problem according to SOA principles, decomposing
it into manageable pieces, and refactoring components according to service-orientation if
possible. Also remember that ultimate reusability can come at a price you simply could not
afford, so balance your efforts wisely, again using SOA principles.
The presented part of the solution (Orchestration) in the beginning is completely functional
and is taken from a real-life project, although the company is fictitious, of course. Now you
have enough samples to build your own controller, MDS, and service repository; however,
Search WWH ::
Custom Search