Forrester View

Are open source integration solutions mature?

By Henry Peyret (Left) and Michael Goulde (right) with Andrew Parker

Open source integration

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 components such as ESB, transformation, adapters, and BPM that 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 WDI’s 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.

Good enough, but

Open source solutions meet ‘good enough’ but not ‘better’ evaluation criteria. Forrester mapped the coverage of open source solutions including all open source consortia and typically available components to the application integration framework (AIF) model we usually employ to assess commercial integration suite products. The results speak 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 that:

• Open source solutions may never address some categories, such as pre-built. The developers’ principal objective is to focus on building a generalised ‘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 won’t 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.

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

Usually, an open source product succeeds once the development community has established mature standards. Forrester’s 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.

Fast path to maturity

A smart strategy for a current EAI supplier, particularly those outside the top 25, would 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 supplier’s own enhancements could accelerate widespread adoption. Eclipse, and IBM’s use of Eclipse in its Rational set of development tools, is an example of this model at work.

Open Source Integration Solutions are still for developers. Open source integration solutions are in their infancy, but developers, not business analysts, can 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 licences. 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:

• 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.
• 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 IPR when signing the contract with the enterprise.
• Participate directly in the community. You create code that satisfies any necessary requirements through well-driven and organised communities like ObjectWeb.
• 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.

For more information, contact Forrester India Country Manager Sudin Apte on sapte@forrester.com or phone 020 25674390/91.