Database Reference
In-Depth Information
similar to this pattern's implementation, but this is for task services within one composite
because, task services are also quite often related to a single EBO.
In the SOA modeling and analysis practice, there is one rule that concerns the functional
decomposition of business logic, that is, isolate manual tasks and do not try to automate
them (at least see the automation of manual tasks as a second priority). Human Workflow
is actually a very elegant way to address this designing dilemma.
So, the simple conclusion about this framework is that Oracle SOA Suite covers it pretty
well, following the BPEL 2.0, WSDL 2.0, XSD 1.1, and XSLT 2.0 standards. Some
XPath 2.0 functional arrears are supported as well. Therefore, we can give positive, as
well as practical, answers for all questions in the following table dedicated to the EBF as-
works
. In terms of SOA patterns, the most important composite pattern, Orchestration, is
covered in great detail.
Common problem
Pattern addressing the problem
•
Process Abstraction
: SOA Suite is quite cleverly organized according to
Ser-
vice Component Architecture
(
SCA
), allowing the abstraction of assembled
components and hiding implementation details.
The isolation of business-centric (nonagnost-
ic) services from agnostic, highly reusable
components, and visually representing them
in a comprehensive and manageable form
•
Mediator, Human Task Services, and Decision Services reduce the complexity of
BPEL processes, increasing modularity and composability of complex business
solutions.
•
Agnostic services (Entity and Utility) can be easily recognized and filtered out
for separate implementations. Surely, this separation cannot be done by SOA
Suite alone. We have to architect our service layers cleverly.
•
Process Centralization
: Oracle SOA Suite provides all the necessary engines to
support orchestrated task services. All these service models are centralized under
a harmonized environment (WLS
soa_server
), covered by HA measures.
Nevertheless, it must be realized that all engines (BPEL, Mediator, Rule, and
ADF runtime for hardware) are a burden for the infrastructure and operational
support, so please model your services carefully and avoid hybrid models in or-
der to save costs and effort.
Task services are a special kind of services,
with specific requirements for the service en-
gine. In fact, as we have four separate com-
ponents, then four separate engines will prob-
ably be necessary in our technical infrastruc-
ture to support this framework.
•
Back to the discussion of development tools unification; the physical isolation of
orchestrated task services from other infrastructures does not justify the IDEs'
disparity, but at least it explains the complexity of unification.
•
Another type of centralization pattern covered by SOA Suite is Rules Centraliza-
tion. Decision services, connected to the central rule repository, allow us to ab-
stract business rules and make our task services more flexible. The risks associ-
ated with the realization of this pattern were discussed earlier in
The Oracle Rule
Engine
section.
•
State Repository
: We already discussed this pattern when talking about DBs.
This is a crucial pattern for the whole orchestration, and the point here is not the
performance deficiencies that are quite natural in (almost) any persisting tech-
nique. The question here is the safekeeping of storage and data consistency.
What makes the orchestration layer quite spe-
cial is the necessity to persist process data
during an inactive state for days, or even
weeks.
•
Choose your storage purge strategy wisely; Oracle supplies us with online and
offline purge scripts, but local DBA's attention is highly advisable. And, of
course, back up, back up, back up…
Search WWH ::
Custom Search