Kris Lachor

Subscribe to Kris Lachor: eMailAlertsEmail Alerts
Get Kris Lachor: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Article

Systems Integration with Openadaptor

Business system integration with little or no custom programming

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.

More Stories By Kris Lachor

Kris Lachor is a senior software developer at Dresdner Kleinwort.

Comments (2) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
higginse 10/28/08 09:41:45 AM EDT

Ismael,
Thanks for the feedback, it's always very useful to us. You should be able use stored procedures for updates - see the MapCallableStatementWriter (and corresponding map-stored-proc-writer.xml example, and their XML equivalents). In fact, if you can guarantee that the warehouse will always be based on Oracle it might be easiest to implement the 'upsert' funtionality in a stored procedure which the JDBC writer would invoke.

Having said that, with your comments in mind, we are looking at adding direct support for updates (and possibly 'upserts') with a view towards squeezing it into our upcoming 3.4.3 (November '08) release of openadaptor.

Also it's worth noting that the RawSQLWriter can achieve the same effect - it uses actual SQL strings which get directly executed against the db, albeit with a performance penalty (overhead of constructing the SQL manually, and not being able to compile it).

regards
Eddy Higgins, Kris Lachor (& the openadaptor dev team)

P.S. Note that www.openadaptor.org is the primary resource for openadaptor technical support. This affords the best visibility to the dev team, and other oa users.

imatos 10/27/08 11:55:00 AM EDT

Great article. Great tool. It seems a good fit to a new project I'm involved with.

The project will require extracting data from a ERP system to load into a data warehouse. The ERP system uses a DB2 UDB database, while the data warehouse will be based on an Oracle database. On a daily basis, it is necessary to extract all the new or updated records from selected tables on our ERP database to load on the data warehouse.

From the documentation and the samples, I found that it is very easy to INSERT data in a table, but could not find references to table UPDATES, or more specifically to the situation where an input record may be updating the corresponding record in the target table if it already exists, otherwise it will be inserted on the target table.

What would be the best approach to resolve this "UPSERT" type of problem using Openadaptor?

Many thanks for the help

Ismael