CNET también está disponible en español.

Ir a español

Don't show this again

Tech Industry

Commentary: Hop on the bus?

An enterprise service bus can help companies meet basic integration requirements, but there are limits to what a commercial ESB product can do without custom-developed extensions.

Commentary: Hop on the bus?
By Forrester Research
Special to CNET
July 9, 2004, 9:15AM PT

by Ken Vollmer, Mike Gilpin and Jost Hoppermann, Forrester Research

An enterprise service bus can be a flexible, low-cost alternative for meeting basic integration requirements, but at this time there are limits to what can be accomplished with a commercial ESB product without custom-developed extensions.

Still, customized ESB technology is being deployed in many companies as part of a broader strategy to enable a service-oriented architecture (SOA), and its applicability to a broader range of integration problems will increase as ESB functionality expands in parallel with the growing maturity of new Web services standards. This will lead more and more to commodity status for many features of today's proprietary enterprise application integration (EAI) arrangements, as these become commonly embedded features of service-oriented application platforms.

The term "enterprise service bus" has become widely used to refer to a layer of middleware through which a set of core (reusable) business services are made widely available. The bus is expected to provide certain infrastructure services, such as service registration and location, reliable messaging and other quality-of-service options, message routing and transformation, security, endpoint identity, and rights management. As such, ESBs are one alternative for implementing an SOA or service fabric, but an SOA can be implemented in other ways, such as message-oriented middleware, CORBA, integration platforms and custom development.

Flexibility and cost
Depending on its particular needs, a business may find that an ESB is a more flexible and lower-cost alternative to proprietary

Related story

ESB technology is part of Big Blue's
streamlining plan to move customers
to cheaper, easier integration options.

EAI setups for integration. An ESB is often based on commercial products like Sonic ESB or WebMethods Fabric (or even IBM's WebSphere or BEA Systems' WebLogic) and provides core infrastructure services, such as event triggering, routing, XML translation and support for Web services, but may lack more advanced integration features commonly found in more mature EAI products.

Consequently, one increasingly popular strategy is to implement a part-commercial, part-custom-development approach in which the vendor-supplied ESB technology provides core services, while additional required functionality like process automation, custom security features, and business gateway functions are provided via custom development. Such hybrid ESB efforts often build in support for additional service delivery mechanisms, such as message-oriented middleware, in addition to standard support for Web services (Simple Object Access Protocol, or SOAP) connectivity.

For example, Federated Department Stores has implemented a part-commercial, part-custom-developed ESB to support communications between its Web site, call centers, Web site and point-of-sale terminals using SOAP-based connectivity plus message-oriented middleware-based interfaces with multiple back-office mainframe applications providing service implementations. This sort of ESB is not just an EAI replacement, for it enables a services-oriented architecture and customized integration functionality for which EAI arrangements may not be well suited, because they provide a number of additional features not needed in some SOA contexts. Extra features can also mean extra costs, and when those features are not needed (or only needed in lightweight forms available from an ESB), EAI can be overkill.

Missing ingredients
Packaged ESB solutions are standards-based products that provide core infrastructure services but do not yet provide complete EAI functionality because the relevant Web services standards are not yet available or commercialized. In particular, process automation, support for packaged application adapters, complex data transformation, and process modeling are functions that are commonly found in EAI tools but are generally missing from packaged ESB products. However, as integration standards like Business Process Execution Language, ASAP (a Web services protocol for supporting long-running activity), and many others mature during the next two to three years, Forrester does expect ESB products to become feasible alternatives for the current level of integration functionality provided by proprietary EAI solution providers.

Some of these integration vendors, such as WebMethods and SeeBeyond, already have ESB functionality embedded in their product suites, and Forrester expects most other integration providers to follow suit. At the same time, Forrester also expects that integration vendors of all types will continue to add new functionality to their product suites in an attempt to avoid commoditization that is being driven by increasing levels of ESB adoption. This will lead to a vendor landscape in which many options will be available for implementing an ESB--some lighter, some heavier--with a range of features to suit problems from the simple to the complex.

As integration standards mature, ESBs will become increasingly relevant to large and midsize organizations.

•  Organizations that have not worked with an ESB should look for an opportunity to experiment with this technology, especially if an SOA implementation is already in the works.

•  Do not plan on replacing your EAI setup with an ESB at this time unless you are using only a subset of EAI features that can be provided by today's more limited ESB products and services, with only limited custom extensions. Only the largest companies should consider more than very limited custom development of ESB infrastructure services, where the cost of such custom development can be amortized over a large number of projects and in the context of a broader SOA initiative.

•  Adjust your strategy as ESB functionality matures, as the capabilities of products--and the maturity of the relevant standards--will evolve rapidly for the next few years.

© 2004, Forrester Research, Inc. All rights reserved. Information is based on best available resources. Opinions reflect judgment at the time and are subject to change.