FrontPage Feature

Digg This!

Page 2 of 5   « previous page   next page »

To overcome these limitations and accommodate appropriate standards and technologies that have since emerged, the framework has recently been completely overhauled. The rewritten version comes with a much cleaner, smaller codebase and architectural improvements throughout:

• Improved performance achieved partially through a strategy of minimal interference with payload data as it traverses adaptors, including the elimination of the rigid internal data representation format (DataObjects) and consequent, possibly unnecessary conversions.
• Spring framework (see Resources) based XML configuration - typically adaptors are assembled via simple Spring XML configuration files rather than having to write and compile Java code. This also makes adaptors easy to embed into Spring applications.
• Better extensibility - writing custom components does not require extensive knowledge of the framework. Interfaces for custom components are few and simple. Bespoke behavior, previously only possible through custom code, can now often be achieved through scripting.
• Lighter - the framework adds only a thin layer between the JVM (or a user process that runs an adaptor) and the actual components that read and process the data. The overhead is minimal, and apart from a JVM being installed in the target environment, system requirements are minimal.
• Flexible execution and embedding - adaptors may be run as standalone processes, be embedded within other processes, or deployed to JEE or other application servers. The flexibility makes it easy to introduce Openadaptor into existing projects.
• Not reinventing the wheel - Openadaptor delegates responsibility wherever possible to external, well-accepted industry standard mechanisms. For example, it allows users to leverage the Spring framework's dependency injection (while not requiring it), to use well-accepted JTA implementations for transaction management, or to deploy adaptors to JEE application servers and use their resources.
• Flexible internal data representation - so-called ordered maps (which are standard Java Maps, see Internal Data Representation sidebar for details) and XML are often used for internal data representation and manipulation, but users are free to use a representation of their choosing - such as an organization's bespoke format - for communication between their custom processors.
• Pragmatic - it is here to do a real job, it is used in critical high-volume, low-latency production systems; in the financial domain it processes hundreds of millions of Euros worth of trades daily.
• Cross platform - as a Java-based framework, it benefits from platform neutrality. At the same time, by offering connectors such as Web services, it does not assume the integrated systems are written in any particular programming language or are running on any specific platform.
• Easy management and monitoring - supports instrumentation through JMX.
• Comprehensive and modular - Openadaptor has a component architecture, allowing the inclusion of functionality as per user requirements.
• Easy to test - replacing connectors to external resources such as databases, messaging solutions, or bespoke systems with file-based connectors allows for the easy creation of debugging environments or the ability to craft automated system tests. It also facilitates decoupling of producers and consumers of data in MOM environments.

In addition, it was designed to permit a reasonable migration path from legacy Openadaptor, which will be of relevance to users of previous versions of the framework.

The essence of the framework remains unchanged. What exactly can Openadaptor be used for? Essentially it excels in two areas.

First, Openadaptor can be a link between a system and a Message Oriented Middleware (MOM). When used in combination with MOM, Openadaptor can loosely be classified as an Enterprise Service Bus (ESB) and constitute part of an organization's messaging backbone.

Second, it can be a link between two systems, not involving MOM. To illustrate this, Openadaptor might query a Web service, perhaps filter or modify the returned data, and eventually persist it to a relational database. As a subset of this category, the framework could be used as a file processing tool, perhaps to convert comma-delimited files to XML documents.

Openadaptor is primarily targeting system integrators and Java developers, who will often have come across the need to achieve tasks like these:

• Read in an XML document from a flat file, find XML elements of interest using XPath, and use the content of those elements to run an SQL update query on a database.
• Start a Web service to accept data from a .NET system. When the service receives a request, use a JavaScript-based filter to discard irrelevant data. The discarded data is to be written to a dedicated flat file while the data that passes through the filter is to be sent to an MQSeries topic.
• Periodically query a relational database after looking up a data source in JEE application server's JNDI tree. Save the query results to a comma-delimited text file. Expose a JMX console that allows for the monitoring of details, such as the number of database queries run or the size of the output file, through a web page.
• Collect data from a bespoke front-end trading application and validate, filter, and reformat it using a simple scripting language. Pass the data on to a bespoke back-end booking system. Both systems are transaction-aware and every message is required to be processed as part of a distributed global transaction.
• Subscribe to a JMS messaging backbone and on receipt of a correct message update a relational database. On receipt of an erroneous message send an e-mail to a system administrator.

In each of the above situations, Openadaptor could significantly increase efficiency and reduce implementation time. All tasks would require nothing but a short XML configuration file.

Java developers may find that by providing many ready-to-use components, the framework offers an alternative to programming in the large; it can reduce the need to repeatedly write code to connect to various interfaces using different, sometimes complicated APIs. At the same time it doesn't prevent users from adjusting (either programmatically or through configuration) components to their needs or writing custom components with custom Java code from scratch. By commoditizing the tedious task of integration, it frees the developer to concentrate on more interesting problems.

Page 2 of 5   « previous page   next page »