Finding the Compromise – the Adapter Framework - Applied SOA Patterns on the Oracle Platform - page 405

points. In order to keep all applications hot-pluggable, we should avoid the reuse
of adapters (well, not exactly; the following examples will show why).
• An adapter should not disturb the underlying layers (ESB and Orchestration) by
endpoint-specific errors and should not propagate them when the source endpoint
cannot provide the necessary data or a target cannot accept the correct message.
Retry mechanisms, close integration with audit, and error handling are a must.
Discussing the EHS framework earlier, we omitted this part (which is quite sub-
stantial and based on AQ and business rules), but we will definitely return to this
in Chapter 8 , Taking Care - Error Handling .
• In order to support the first design rule, Adapter (Northbound) must provide a Ca-
nonical message and accept it before transformation to the ABM (Southbound).
Thus, both types of transformation patterns and bridging should be implemented
in Adapter. Remember that they are parts of the Service Broker pattern, which is
in turn an essential part of ESB.
Following this approach, you can just use BPEL straight away. Just beware of hybrid ser-
vice implementation, and you do not need to read further. And the hybrid services are
quite a significant risk, as we demonstrated during the analysis of CTU's initial solution.
That's why Oracle recommends isolating ABCS from EBF by EBS layers. So, the rules
are meant to be broken, isn't it? Not quite. Again, we are just following common sense,
that is, applying the pattern to a "meaningful extent".
What if (like in CTU) all your main ERP applications are scheduled for decommissioning
in the next decade, that is, will stay for quite a while? What if the number of your applica-
tions, which you have to wrap by adapters, is so big that the quantity of adapters will just
make your SOA infrastructure cumbersome?
Even more, what if all these applications are very similar in technology and in business
purpose (CTU example, regional installations of the same application with minor
changes)? Thus, the Reusability principle can be applied in the Adapter framework as
well and we are going to demonstrate how.
In Chapter 4 , From Traditional Integration to Composition - Enterprise Business Ser-
vices , discussing OSB, we established the ESB layer with Generic Adapter ( GA ), ful-
filling the VETRO pattern in an endpoint-agnostic way (which is an absolutely pure solu-
tion according to the SOA Pattern catalog) and Service Façade, dynamically dispatching
the message (or service call) to the concrete Protocol Adapter. In addition to the classic
ESB SOA patterns altogether, they are followed to the Business Delegate and Adapter
Factory JEE pattern implementation rules; most of the Transport Adapters are JCA-based