Let's now look at what an adaptor is in more detail.

Architectural Overview
An adaptor is a convenient assembly of Openadaptor components that function together as a unit. Components may be broadly divided into:

• Connectors that provide mechanisms by which an adaptor communicates with the external environment. Read connectors and write connectors, respectively, accept data from, and output data to, the environment in which the adaptor is operating.
• Processors that provide mechanisms to filter, route, transform, and enrich data as it traverses an adaptor.

Openadaptor's connectors are components built to normalize communications between external systems and the adaptor. Read connectors and write connectors facilitate incoming and outgoing communications, respectively. The framework comes with several connectors available as standard, including connectors to SQL databases, JMS, flat files, Web services, RMI, HTTP, and JNDI. These can be configured via their JavaBeans properties. Also, either through implementing simple interfaces or extending existing connectors, users can easily add connectors of their own, enabling bespoke systems with non-standard interfaces to feed data into or collect data from Openadaptor. There is no assumption as to what platform the integrated systems run on (see Non-Java Based Systems Integration sidebar for details). Where appropriate, under the hood Openadaptor leverages other well-established open source projects to handle particular technologies, for example, Web services connectors will use the XFire embeddable SOAP framework and HTTP connectors will use the popular open source Jetty web server (see Resources).

Processors are components for the manipulation of records. A given processor takes a record as input and generates zero or more records as output. Openadaptor comes with a number of ready-to-use processors, many of which act upon objects called ordered maps or XML (explained in the Internal Data Representation sidebar). The primary types of processors implement the IDataProcessor interface; these processors are the workhorse of Openadaptor. Other types of processors can manipulate records by enriching them with more data from an external resource, such as a database or an XML document. These are known as enrichment processors and implement the IEnrichmentProcessor interface.

A subgroup of data processors is convertors, whose only purpose is to change the format of the data rather than the data itself. Convertors could, for example change an ordered map into an XML document or a fixed-width delimited String to an ordered map.

Bespoke business logic can be implemented either with standard processors that support scripting languages such as JavaScript, or by implementing new Java processors. This may be very useful, especially for implementing more complex algorithms or for when the desired business logic has already been implemented and packaged up as a Java archive. Script processors have the option of invoking Java methods (say from Java archives) to access such algorithms.

Figure 1 shows four key interfaces. Most Openadaptor users shouldn't need to resort to writing custom Java code as the set of connectors and processors shipped with Openadaptor distribution is rich and comprehensive. Developers who elect to write custom Java code may do that either by direct implementation of one of these interfaces, or through the extension of Openadaptor components that most closely match their criteria.

These interfaces represent primary component types that may be arranged in a processing pipeline to form an adaptor. Adaptors are typically assembled using the Spring dependency injection mechanism by creating an XML configuration that defines connectors, processors, and linkages between them.

The framework also permits configuration values to be specified as placeholders, allowing the substitution of the actual runtime values separately. This is extremely useful for deploying from test to production environments.

A processing pipeline that reads from JMS and outputs to a delimited string file might be configured as a JMS read connector linked to a processor that modifies the data in some way and which itself is linked to a file write connector. A JMS message would be turned into an Openadaptor message and make its way through Openadaptor until it reaches the last component.

In its simplest form, an adaptor would consist of two components (see Figure 2): a read connector directly linked to a write connector:

More often, however, the adaptor would also contain a data processor. In a more complex form, as depicted in Figure 3, an adaptor could implement a fan-out to process the same message through two different branches (messages 3a and 3b onwards in Figure 3) that write to distinct external resources. It would typically have data format convertors and an exception handler (for more information on exception handling see the Exception Handling sidebar). Finally, it may even use an enrichment processor to enrich messages with relevant data from an external resource.

Step by step, each component in the pipeline will take the output of the preceding component, perform an operation on it, and pass the result to its successor.

JMX
When a standard Openadaptor JMX bean is added to an adaptor's configuration, individual components will be exposed as MBeans for remote access via a JMX console. This provides an easy way of inspecting a running adaptor's configuration. Information such as an adaptor's build details and runtime environment are readily available. The console also allows for the graceful stopping of running adaptors and dynamic adjustments of logging levels.

Transactions
Openadaptor implements a transaction management abstraction that uses JTA (Java Transaction API, a high-level API by Sun Microsystems that defines interfaces between a transaction manager and the parties involved in a distributed transaction system). Out-of-the-box Openadaptor uses the open source transaction manager JOTM (see Resources); this can be overridden by any other JTA-compliant transaction manager. It's also possible to delegate transaction management, via Spring transaction abstractions, to any enclosing container other than that which Openadaptor happens to be deployed to (including JEE containers).