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

Naturally, new requirements emerged quite soon. Now, we have to transport more busi-
ness messages (not only the purchase order as it was planned initially). Also, we have
more application to integrate in addition to a single instance of OEBS. Still, all of this
doesn't sound that bad. We can easily deduce that we have the classic RDT interchange
pattern with transformation, possibly with translation and content-based routing. Syn-
chronous APIs do not require complex processing; all brokering must be performed from
a central location. The broker will be some kind of single point of contact, acting in the
same manner as a Front Controller. The Front Controller is one of the common JEE pat-
terns, although it is commonly related to UI and presentation-tier integration ( ht-
tp://www.oracle.com/technetwork/java/frontcontroller-135648.html ) . Physical realization
of a Front Controller is our main interest as it's a classic servlet, and after consultations
with developers we agreed that this will be the heart of our Message Broker.
Talking about Message Broker's body parts, the next vital organ will be Business Deleg-
ate, which can be accessed through the servlet's helper. As we discussed in the previous
chapter, it has the responsibility to transform and dispatch messages to the actual workers
(service providers). This will be the solution's brain. The last D (deliver) from RTD will
be closely associated with Business Delegate, which presents the Adapter Factory pattern.
Despite the initial intention to serve only HTTP communications, file/FTP operations re-
quirements were added into the design.