Are Open Source Integration Solutions Mature?

by Henry Peyret and Michael Goulde

with Andrew Parker

EXECUTIVE SUMMARY

Companies have begun to use open source integration solutions in their critical projects. When compared with commercial integration solutions, the feature coverage of these open source tools remains poor. This is not surprising: Established standards are important as a platform for open source development, but standards bodies have yet to establish many standards in this area particularly for the most advanced features. Despite this, open source integration solutions represent a viable alternative to commercial integration products for follower enterprises. To move forward, Forrester believes that large organizations particularly government and large enterprises will increasingly need to invest and participate in open source committees to drive requirements and interoperability standards and fund the development of more capable and coherent open source integration solutions.

DIFFERENT APPROACHES FOR MORE COMPLETE OPEN SOURCE INTEGRATION SOLUTIONS

A number of open source projects fulfill some basic integration functions, such as enterprise service bus (ESB), JMS MOM, transformation, or BPM. However, customers often seek a more direct equivalent to commercial integration suites, such as those from TIBCO Software, webMethods, and SeeBeyond. Examples of open source projects moving in this direction include OpenSymphony, openadapter, Proteus EAI Toolkit, and OpenEAI Project. There are three main approaches to developing integrated open source integration solutions:

• Integrate. A systems integrator integrates various componentssuch as ESB, transformation, adapters, and BPMthat it has already worked with.
• Build. A consortium builds a solution around an application server platform like ObjectWeb or JBoss.
• Package. A vendor packages various components with additional functions like life-cycle management or its own light product version, such as WDIs BIE.

Each of these approaches can deliver a more or less complete, integrated, and coherent set of integration functions for the scope of problems they intend to solve. Prospective users, though, will rightly ask whether these open source integration solutions match up to commercially developed equivalents when compared using a broader set of integration criteria.

OPEN SOURCE SOLUTIONS MEET GOOD ENOUGH, BUT NOT BETTER, EVALUATION CRI-TERIA

Forrester mapped the coverage of open source solutionsincluding all open source consortia and typically available componentsto the application integration framework (AIF) model we usually use to assess commercial integration suite products. The results speak eloquently for themselves: Open source solutions currently do not provide any coverage for most categories in the matrix (see Figure 1). Generally, the more powerful proprietary EAI solutions on the market fulfill all but five or so of the functional requirements in the matrix. However, a more thorough evaluation indicates that the situation is not as bad as it appears: In many cases, open source solutions work well enough to meet their intended scope. Prospective users should note, in particular, that:

• Open source solutions may never address some categories, such as prebuilt. The developers principal objective is to focus on building a generalized good enough solution.
• The business rules category is relatively new, even for commercial solutions. It is unrealistic to expect open source developers to include business rules functionality in the near term.
• Reuse of a single repository wont start until 2006. Open source developers are doing some work on repositories and directories functionality based on the Eclipse repository, but the various open source solutions will not start reusing a single repository until 2006 at the earliest.

Additionally, external infrastructure components usually provide the security and architectural functionalities that the AIF model prescribes. However, integration suites must reuse the customers existing security and infrastructure components. To get these features, customers will probably have to use commercial productsas few open source solutions are available for security and operations.

Usually, an open source product succeeds once the development community has established mature standards. Forresters mapping of open source integration solutions to the AIF model provides a good representation of the maturity level of the integration standards. For example, XSLT is the standard often used to describe transformations for map authoring. This works well for XML transformation, but users also need to transform other formats, such as database structures and EDI; these often remain proprietary because of the absence of standards in these areas, making it hard for open source offerings to target them. As standards emerge in more areas of functionality, open source solutions will emerge.

A FAST PATH TO MATURITY FOR OPEN SOURCE INTEGRATION SOLUTIONS

A smart strategy for a current EAI supplierparticularly those outside the top 25would be to launch an open source project based on its products. A strategy that uses core open source technologies as a foundation and opens up the opportunity to combine other contributions with the suppliers own enhancements could accelerate widespread adoption. Eclipseand IBMs use of Eclipse in its Rational set of development toolsis an excellent example of this model at work.

WHAT IT MEANS

OPEN SOURCE INTEGRATION SOLUTIONS ARE STILL FOR DEVELOPERS

Open source integration solutions are still in their infancy, but developersnot business analystscan use the available components to fit enterprise integration requirements.

RECOMMENDATIONS

PARTICIPATE IN OPEN SOURCE COMMUNITIES FOR CRITICAL PROJECTS

Buyers of commercial integration solution products know how difficult and expensive it is to maintain and migrate their existing EAI-based interfaces to new EAI versions it often costs more than the actual licenses. Given open source integration solutions actual state of maturity, it is critical when choosing one that you participate as an active member of the community; this will allow you to better plan and drive the maintenance and migration of your upcoming open source-based interfaces. Companies can choose from four approaches to involvement in open source communities:

1. Start a project internally and then allow a new open source community to develop it. The community will continue to evolve it. Dresdner Bank has adopted this strategy for openadapter.
2. Pay an enterprise that is already involved in the existing community. An enterprise, such as a systems integrator, develops the missing features and then makes the source code freely available for the benefit of the open source community. Be clear about the intellectual property rights when signing the contract with the enterprise.
3. Participate directly in the community. You create code that satisfies any necessary requirements through well-driven and organized communities like ObjectWeb.
4. Participate in standards bodies that will help open source communities. Open source integration solutions make best progress on the back of established standards; companies can foster the emergence of open source integration functionality by targeting appropriate standards bodies, such as OASIS, and the bodies that supervise standards, such as WSI and ebXML.

ENDNOTES ¹ This Web resource offers an interesting list of Java open source integration projects: visit http://www.manageability.org/blog/stuff/open-source-messaging-integration-transformation-routing-java/view for information. ² Red Hats entry into identity management and certificate management (announced June 2005) could, for example, have long-range implications in that domain. ³ IONA is a recent example of this fast path; in June 2005, it announced it would introduce a Java-based enterprise service bus called Celtix.

⁴ Visit www.connext.co.za/openadapter for more information on Dresdner Banks strategy.