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

A simplified Message Broker implementation
Now, we will walk through the RTD parts focusing on pattern implementation in a simple
hub-and-spoke solution.
Receive
The receiving part must contain functions for message parsing, message identification, and
the extraction of an execution plan based on message ID. These are typical parts of any ser-
vlet, except probably the execution plan, which we add for dynamic task invocation. A ser-
vlet's lifecycle starts with initialization, which occurs only once when the servlet is started,
as presented in the following code:
String dispatchSufix = "";
String mappingURL = null;
...
public void init(ServletConfig config) throws
ServletException {
super.init(config);
...
tmp = config.getInitParameter(MAPPING_URL);
if ( tmp != null ) mappingURL = tmp;
tmp = config.getInitParameter(OK_PAGE);
if ( tmp != null ) okPage = tmp;
...
tmp = config.getInitParameter(XMLRULESPROVIDER_URL);
if ( tmp != null ) XDIRuleListWSURL = tmp;
This fact gives us the possibility to put all heavy, but one-time, operations into the initializ-
ation routine, for instance, obtaining and caching the data sources. For simplicity, we will
not use the database directly in this example, and in general the performance is not our
primary concern. Initially, we just need some pages to display the positive and negative re-
sponses, resource mapping, default logging level, and type of rule engine we will use for
the process type resolution (name of routing slip), and default transformation. All these
parameters will be registered in the web.xml deployment descriptor according to the ser-
vlet specification and reassigned during the initiation step as shown in the preceding code.