Building the Core – Enterprise Business Flows - Applied SOA Patterns on the Oracle Platform - page 183

Tip
Select a very limited vocabulary for your routing slip if you decide to go this way (as if
you have a choice). Technically, we would like to execute some tasks by calling public en-
dpoints. Later we will call it Execution Plan ( EP ), with some similarity to DB's execu-
tion plans.
Thus, we have no plans to reinvent the BPEL. Even more, by balancing the Normalization
of different processes, we openly declare that not all processes can (and should) be de-
composed down to a simple sequential EP. We deliberately would like to keep complex
processes untouched and invoke them from the same EPs. Even more, we will denormal-
ize some processes due to the presence of complex parallel processing or difficulties that
arise with error compensation. Another reason for the implementation of the Contract
Denormalization pattern is the needless multiplication of the services and high perform-
ance demands associated with it. For sequential processes though, Execution Plans (struc-
ture will be explained in detail with connection to Enterprise Repository in Chapter 5 ,
Maintaining the Core - the Service Repository , but critical elements will be presented
here) can solve this problem more gracefully.
Next, all of the logic related to BPEL is applicable to the Mediator concern as well. The
fact is that the Oracle Mediator is not lighter than BPEL, and its engine is also rather
heavy. Yes, the syntax and vocabulary is a bit more modest, but Mediator is also a stateful
component that is capable enough to perform the processing sequentially and in parallel
with the predefined priorities. Thus, its XML metalanguage is not the best candidate for
performing a simple sequential EP. However, similar to what we did with BPEL, we are
planning to use at least two (initially) mediators: one for dynamically extracting EP or
routing to the complex denormalized BPEL and another for routing to the specific end-
point (this decision will be revised soon).
Gradually, we will come to the dynamic extraction of EPs, which can be realized on Rule
Engine; now we are moving on to the Rule Centralization pattern (8) , enforced by
Oracle SCA Decision Service. Here, another concern can be expressed. Would it be more
logical to use Rule Engine to identify the next task in the dynamic workflow instead of
extracting the execution plans by the same Rule Engine? The answer is already in the
question. For a sequential composition, we will need up to 10 Decision Service invoca-
tions instead of one (see requirements). Most importantly, for dynamically branching a
process, we can invoke RE from EP with no problems, or we can call another SCA that
could encapsulate another Decision Service.