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

engine type to Execution Plan, new IF branch to dispatcher
and new Java deliverer
The pros and cons of a simplified Message Broker
The solution based on the presented architecture has been delivered quickly and served its
purposes really well for a limited number of trading partners (message recipients). Most
importantly, performance was more than acceptable and it was really reliable, so the tac-
tical goals were achieved. We can even see this servlet-based approach as a good invest-
ment in the REST service infrastructure. Commonly, REST is implemented by Jersey-ser-
vlets, and we encourage you to look at this technology as it's not in the scope of this topic.
You will find a lot of similarities with the quick example we discussed previously. Oracle
has many good examples that cover the servlet pattern and its utilization in JAX-RS/Jer-
sey ( http://docs.oracle.com/cd/E19776-01/820-4867/ghqxq/index.html ) . This means that
you really do not have to do everything from ground zero for message brokering and ser-
vice implementation. The actual purpose of this example was to demonstrate the physical
implementation of some patterns such as Mediation and Adapter Factory, as discussed be-
fore, and mainly the EAI-SOA path of evolution: point2point | hub-and-spoke | message
broker | service broker | full-fledge ESB .
The example also demonstrated the complexity of the task. We didn't cover a lot of fea-
tures that are compulsory for a full-scale solution, for instance:
• Basic security
• MTOM / messages with attachments
• Throttling / Load balancing
Also, many more solutions will be covered later. However, most importantly, we didn't
implement true service decoupling, as no Proxy concepts were provided. It is a good time
to return to the CTU service broker now and see how we can improve this solution using
the discussed and tested patterns.