ESB: Just another TLA?

Analyst firms are often fond of creating new terms that define constantly shifting markets. After all, such new terms help to categorize vendor companies into segments that they can easily quantify and explain in the context of the greater IT marketplace. They also help the analyst groups organize themselves and their research.

Many times, however, such analyst-speak is more of a hindrance than a help. New terminology often introduces ambiguity and confusion in the market when end-users aren’t sure about how to apply the new term to the vendors they are considering for a particular project. Such confusion is especially prevalent surrounding the term Enterprise Service Bus (ESB) that is making its way into the PowerPoint presentations of vendors very small to very large. Just how useful is the term ESB? Is it just another Three-Letter Acronym (TLA) of limited use?

ESBs: What are They?
An ESB is the combination of standards-based messaging middleware, distributed Service containers that use Web Services, XML transformation, and rules-based routing of documents. We have also seen ESBs defined as “a new kind of middleware that combines features from several previous types of middleware into one package.” Previous types of middleware presumably include message-oriented middleware (MOM), Enterprise Application Integration (EAI), and Business-to-Business (B2B) integration solutions. ESBs also often provide some value-added services beyond those found in those previous middleware approaches, such as message validation, transformation, content-based routing, security, Service discovery for a Service-oriented architecture (SOA), load balancing, failover and logging.

Yet, despite these attempts at definition, the ESB term is being used in increasingly more vague and unhelpful ways. For example, Microsoft’s Indigo has been described as an ESB. However, Indigo, which forms the basis of Microsoft’ next-generation development environment combining SOA as well as advanced code management and code portability capabilities, is not by itself any more an ESB than any other development or runtime environment.

Furthermore, companies that have traditionally been in the Enterprise Application Integration (EAI), Message-oriented Middleware (MOM), and object brokering markets are increasingly calling upgraded versions of their existing products ESBs. Does this trend mean that ESBs are a new technology movement and emerging market that a growing number of companies are modifying their products to meet, or is it really the case that ESBs don’t represent a new technology approach or market, but rather the natural evolution of existing middleware infrastructure as standards-based, loosely coupled distributed computing approaches take hold?

In order to understand the answer to this question, ZapThink examines the role of ESBs within the context of SOA, and how the nature and relevance of ESBs will necessarily change as companies migrate towards architectures that inherently address the challenge of integration.

ESBs: A Transitory Market
In order to get an understanding of the role and importance of ESBs, is it first important to understand the importance of asynchrony. As we frequently communicate in our research, there are three fundamental tenets (idées fortes) of SOA: loose coupling, coarse granularity, and asynchrony. Loose coupling is the discipline that requires Service consumers to be independently created and controlled from Service producers; coarse granularity implies that high-level business Services can be composed of lower-level atomic Services, and asynchrony is the mandate that Service requesters not wait around for requests to be processed before continuing on other Service tasks.

In reality, all of these fundamental tenets are directly related to each other. Loose coupling demands that systems not be aware of each other’s communication protocols and requirements. It is certainly easier to accomplish this goal using asynchronous messaging techniques than synchronous, blocking protocols. Furthermore, the more coarse-grained a business Service becomes, the more long-lived it tends to be. Rather than enabling a discrete database call, a coarse-grained Service might represent an entire supply chain process. These processes depend on asynchrony in order to execute reliably. Finally, coarse granularity and loose coupling are themselves connected in that coarse-grained Services are themselves composed of finer-grained Services that should know nothing about the processes and composite applications that will use them.

In this regard, ESBs can provide the infrastructural backbone over which loosely-coupled, asynchronous interactions can happen. Yet, as mentioned in an earlier ZapFlash, ESBs by themselves don’t provide the required integration to meet high-level business requirements or provide guarantees of loose coupling and coarse granularity as required in an SOA. Basically, implementing ESBs to meet SOA requirements require the addition of extra functionality to compose fine-grained Services into coarse-grained business Services and provide policy-driven, managed, and secure Service interactions.

It is for this reason that ZapThink believes that the ESB market is actually a transitory one. At this time, many companies don’t yet understand the power of standards-based, asynchronous, loosely-coupled distributed computing that SOAs offer. As a result, such companies simply want to move away from proprietary integration approaches to a different approach that represents a step in the right direction. ESBs fulfill this short-term need, and as a result, we expect that all tightly-coupled integration vendors will aim to either provide, or appear to provide, ESB solutions so that they don’t become obsolete.

Yet, as mentioned above, the ESB is not sufficient to provide the needs of companies implementing SOAs. ZapThink proposes that the real long-term market opportunity is the SOA Implementation Framework, which provides all the technology that enterprises need to build and run an SOA — process, management, security, modeling, and more. In fact, as enterprises look to implement SOAs, and vendors work to produce solutions that enable such architectures, ESBs will combine with other integration approaches such as Business Process Modeling (BPM) and Service-Oriented Integration (SOI) to provide an optimal implementation of an SOA — one that meets the requirements for loosely coupled, coarse grained, asynchronous Services.

ZapThink Take
The ESB term is helpful in the short term as companies seek to understand how to move from their proprietary, tightly-coupled integration approaches of today to the standards-based, loosely-coupled, agile infrastructures of tomorrow that solve integration problems through architectural approaches. In addition, ESBs represent a viable implementation approach for SOAs that relegate the application server to a role that is one of executing particular synchronous Services, while the ESB forms the backbone for asynchronous inter-Service communication. While ESBs by themselves don’t offer the entire SOA picture that companies will require, they provide a necessary stepping stone.

In the long term, however, the ESB term is just a means to an end. Once companies realize that they need the infrastructural capabilities of an ESB, they will desire the rest of the SOA Implementation Framework as well, and the functionality of today’s ESBs will shift to solve those requirements. Yet, the fast-and-loose use of the term ESB, which originally had a reasonably specific meaning, is now becoming increasingly vague, and ZapThink believes it will gradually lose its value to the market as a result.