From Traditional Integration to Composition – Enterprise Business Services - Applied SOA Patterns on the Oracle Platform - page 230

lot of common properties. This allows us to group them under the factory methods, which
will do the actual dispatching to specific adapters.
Abstract Factory, which acts as a dispatcher, should be isolated from the client by the
Facade with a simplified interface that accepts Message Container. In fact, in JEE terms,
it's a Transfer Object ( http://www.oracle.com/technetwork/java/transferob-
ject-139757.html ) with the Business Object inside and all elements in a header, necessary
for obtaining the instance of the required protocol adapter from Adapter Factory.
In this case, the Factory Method pattern acts as a dispatcher between adapters of the same
technology/protocols, Abstract Factory mediates between groups of transport adapters,
and Facade isolates client calls from Adapter Factory and performs all necessary tasks on
Transfer Object (extract headers elements, for instance). Validation and transformation of
business payload should ideally be done on Adapter in order to keep Adapter Factory's
Facade completely generic, but this task can be generalized as well by using OSB; we will
be discussing this soon.
We just mentioned another pattern related to Proxy, that is, Facade. If we want to simplify
the interface, make it more generic and universal (in other words, abstract), we should put
the Facade upfront. It's similar to the Decorator pattern, but we are not adding a new
method to the abstracting (wrapping) interface; we are simplifying it. Actually, it's quite
the opposite. The whole point here is the unification of access to the object/API. We are
hiding the complexity of the existing implementation and moving the delegation to the un-
derlying methods upon receiving the call. Thus, it's pretty close to Abstract Factory and
not Decorator. Is it some kind of Adapter? Not really. The Facade pattern implements a
new, simplified interface, while Adapter strives to preserve the existing one. This key dif-
ference is crucial, as it defines the physical location of Facade in SOA topology and we
will get back to it when we will discuss the SOA reincarnation of these traditional pat-
terns. You can spot one relation already: our SCA Mediator is in fact the Facade!
Note
We left Mediator in the SCA orchestration layer, and now we have mentioned it while
talking about traditional patterns in ESB. Confusing? Yes, if you believe that the SOA pat-
terns catalogue is something fixed and predefined. Here, we are showing the application
of patterns in a working platform, in relation to other patterns and physical boundaries, are
limited by the logic of the SOA principles and characteristics we want to achieve.
Mediator is one of the core patterns that establishes intermediate routing between
sender(s) and receivers (for OOP, visit http://www.oodesign.com/mediator-pattern.html ,