Before we proceed, setting up an environment to run the examples shown here should be straightforward and not take too long. For the first example all that is required is the Openadaptor distribution (www.openadaptor.org/downloads.html) and a JRE 1.4+ installed on the system. After unzipping the package, the CLASSPATH should be set appropriately to run the examples. The XML configurations presented here, together with detailed instructions on setting the CLASSPATH and running the adaptors, can be found in openadaptor\example\spring\demo\*.xml in the standard Openadaptor distribution. The second example uses a JMS write connector that requires running a (default) JBoss implementation (to provide the JMS service). It also illustrates reading data from a database, for simplicity Hypersonic (a.k.a. HSQLDB) is assumed, and again should be available. Familiarity with JBoss or Hypersonic is not required. See Resources for Openadaptor, JBoss, Hypersonic and JRE download links.

Example One
The first adaptor exposes a servlet interface to receive data, which is then forwarded to an XML convertor that in turn passes it to a console printer (see Figure 4). The adaptor is deliberately contrived and simplistic in order to make it easy to run and experiment with. In the second example it will be replaced with a more realistic scenario. Data may be injected into the adaptor via a test web page. The XML configuration will hold four bean definitions. One of the beans is a servlet (IReadConnector) that will await HTTP requests to deliver input data into the adaptor. When a request comes in, it will be passed to an XML convertor that will turn the tabular data in the form of a Map into an XML document. Last, a write connector will print the resulting XML document on the screen. Listing 1 provides the three bean definitions.

Normally, bean definitions are reasonably terse as Java classes that provide their implementations take sensible defaults. The server bean, when instantiated, will start an HTTP server and listen for requests on port 9999. It will by default convert the data it receives to an ordered map, which will then be passed on to the toXMLConvetor, which will make an attempt to convert it to an XML document. The last component in the pipeline, the file writer, defaults to console (stdout) output if no file name is provided.

The last required definition is that of the adaptor (see Listing 2). The adaptor's messageProcessor property may be used to arrange the components into what is loosely referred to as a processing pipeline.

Before continuing, it's worth noting the optional JMX monitoring feature. Should it be required, it is possible to monitor the state of the adaptor by exposing the components (including the Adaptor) as MBeans that will be accessible via a JMX console. To do so, it suffices to add the following bean definition shown to the configuration.

<bean class="org.openadaptor.core.jmx.MBeanServer">
    <property name="port" value="8082"/>
</bean>

Figure 4 illustrates the structure of the adaptor; note the data from a sample request and the format it takes when passing between components. The payload type, as might be expected, changes from an ordered map to a String containing an XML document in the toXMLConvertor.

The adaptor's XML configuration is now complete. After starting the adaptor from the command line, opening the test page within a web browser will allow test data to be injected (download test page here). After sending a sample request, the adaptor's console output should be similar to the example1output.html. (The source code for this article can be downloaded from the online version of this article at http://java.sys-con.com.)

Example Two
In this example several more advanced features will be presented, such as an enrichment processor, a fan-out (splitting of the processing pipeline into multiple branches), and exception handling. The job of the adaptor will be to read a comma-delimited file, filter out records of interest, enrich them with relevant data stored in a relational database, and finally publish data to a JMS queue. Records that do not have the expected format will be caught by the exception handler and written to an error log file. Apart from writing to a JMS destination, the output data will also be written to a flat file. Reading of the input file will be throttled - records will be read in with a one second interval in between (see Figure 5).

Please note: if you want to run this example in its full version, you will need to download, install, and run the JBoss application server and Hypersonic database engine (see Resources for download links). Optionally, if you cannot or don't want to install JBoss, remove the jmsPublisher component from the processing pipeline. Likewise, if you take out the dbBasedEnricher component, you won't need the Hypersonic database to be available.

The first bean definition will be of a file reader that sources data from a simple comma-delimited file (input/delim.txt) located in the input folder, relative to the location the adaptor is executed from. This is the file's content (note that the second record is missing the last field):

palinm, Michael Palin, 1
chapmang, Graham Chapman
jonest, Terry Jones, 3
idlee, Eric Idle, 4