Database Reference
In-Depth Information
Oracle Enterprise Business Service's SOA
patterns
After completing the previous task, we have a Message Broker that is capable of imple-
menting the RTD interchange pattern in the form of a hub-and-poke controller. Although it
is perfectly operational, you have to add a little to the demonstrated code snippets to create
a production version. Its practical application is limited by assumptions we made at the be-
ginning of this exercise. Let's repeat the assumptions again:
• Limited number of protocols.
• Limited number of message validation techniques.
• Limited ways of message transformation (XSLT is preferable).
• Relatively elaborate ways of implementing new delivery options and any plug-
gable modules in general.
• When it comes to policy-based management, you will have to manage everything
on your own. You will have to implement policy enforcement points (PEP) on your
own too.
• To make the situation more dramatic, as you remember, we even implemented a
custom rule engine (although this argument is weak as nothing prevents us from
using any RE with Java or WS API; almost nothing, as performance should be
considered seriously).
Simply put, this is a servlet with some customization and with all downsides related to a
custom solution. Apparently, CTU cannot accept it as a generic Pan-Latin-American Ser-
vice Broker and Adapter Factory. Equipped with knowledge gained during this exercise
and understanding what we need from the SOA patterns catalogue to mitigate the dis-
covered problems, we are now ready to refactor our SCA solution from the previous
chapter and move the synchronous parts to the OSB. There will be more protocols to adapt,
more formats to translate, more models to transform, more tasks to invoke, and more oper-
ations to execute. Refer to the following figure:
Search WWH ::
Custom Search