Database Reference
In-Depth Information
No.
Component
Purpose
OFM SCA
Oracle Rule Engine as Decision service within
Composite. As Separate activity invoked within
Service broker in order to obtain execution plan
based on message parameters. Execution plan can
be a preconstructed object or can be constructed by
Rule Engine on the fly.
This component is used to replace the hardcoded "if-else" business
logic and make it portable, centralized, and detached from the
composite application and make the business logic more visible
for business analysts. This is also used to establish dynamic rout-
ing logic based on the previous step and maintain the endpoint
URL resolution on the fly.
Pros: Truly detach business logic from SCA and
make it highly dynamic and manageable. Imple-
ments Process centralization and Functional de-
composition patterns.
Decision Ser-
vice (RE)
1
Cons: Gives most positive results when logic is
complex. Increases maintenance costs.
Dynamic routing based on Decision Service is a
standard Oracle SCA pattern. Mediator is required.
Downsides are discussed.
Oracle Service Repository
This is a placeholder where all service references are stored (such
as URL) with supplemental information in some Service Profile
form. Task lists' references could also be stored here as Orches-
trated Task Services.
Service Repos-
itory (ER)
2
Custom DB
Local XML files
This is a Service Registry Lookup service and is used to accept
CDM elements as parameters and return the Execution Plan ob-
ject.
Depending on the realization, it will act as an ad-
apter to a DB or file. Alternatively, it can act as a
solution, as in the previous step.
Service Invent-
ory Endpoint
3
Orchestrated Task service sequential representation; a collection of
tasks/endpoints in the form of execution plans. These are dynamic-
ally discovered and are an array of tasks with associated compens-
ation/rollback tasks (service endpoint IDs).
Execution Plan
Object (task/
endpoint list)
XML
4
Part of the universal CTU message-container
BPEL process within composite with four activit-
ies:
•
Assign MH elements.
Dispatcher to the actual worker. Looping through the Execution
Plan and sequentially invoke services from a list. Store response
and dispatch to associated compensation task/endpoint if response
is negative.
•
Using MH elements obtain Execution
Plan.
Business
Delegate
5
•
Loop over Execution Plan and invoke
tasks/services. Depending on re-
sponse, proceed to next or compensa-
tion.
•
Wrap up response.
Dynamic End-
point Resolu-
tion (Mediator)
Isolate Business Delegate from actual service implementation. Dy-
namically resolves service URI.
6
See the previous step
Search WWH ::
Custom Search