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

• A mediator with a static routing table can be overinflated by the number of condi-
tions and rules. Adding transformation to it will not make it better than the origin-
al solution. A rule-based mediation has certain limitations that we mentioned in
Chapter 2 , An Introduction to Oracle Fusion - a Solid Foundation for Service In-
ventory , and we will discuss it a bit further.
• Most importantly, quite a few of the decomposed processes are almost identical
from the business logic and involved applications' perspective (Canonical Expres-
sions and Canonical Schema are either in place or can be maintained).
The last bullet item means that for some processes, we could continue with the decompos-
ition down to the endpoints' definitions, aiming to apply the dynamic partner links tech-
nique as an option or generalize the processes to simple XML configuration files in the
form of routing slips, describing the endpoints that should be called. This process is simil-
ar to the ultimate DB's structure normalization, where we strive to eliminate redundant
constructions and minimize dependencies. This activity is described as the SOA Process
Normalization pattern where we eliminate redundant logic and establish the atomic pro-
cess as a single carrier of business logic. Of course, the primary candidates for normaliza-
tion are as follows:
• Processes of the same logic for different geographic units (only endpoints are dif-
ferent)
• Processes similar for one type of product or the same service-provisioning group
For these Processes/Service Normalization and Capability Composition (assembling cap-
abilities outside the service boundaries in order to fulfill complex business logic; a typical
role of task-orchestration services), business logic can be really "dehydrated" to routing
slips. The concept of routing slips is quite common and mature; it's one of the core EAI
patterns ( http://www.enterpriseintegrationpatterns.com/ ) that is inherited by SOA as well.
Products such as Apache Camel and ServiceMix (and the commercial Red Hat version,
Fuse ESB) use it for dynamic and static routing. The whole concept is highly related to
the WS-Addressing standard notation that we discussed in Chapter 1 , SOA Ecosystem -
Interconnected Principles, Patterns, and Frameworks : "The message came from A, then
must go to the endpoint B and sequentially to C. The reply must be delivered to service D.
In case of error, service E must be notified".
We would like to repeat it here again, just for comparison.