In the mid 1990s, many enterprises were looking towards Enterprise Application Integration (EAI) as a Holy Grail
for bringing together data from different silos within the IT infrastructure. In 1999, industry experts began talking about the move towards an enterprise nervous system, rather than the centralized hub found in EAI, based on an Enterprise Service Bus (ESB) as a lighter-weight approach to integrating rapidly developing applications that function on distributed systems. Today ESBs are widely available in a broad range of functionality. And the ESB landscape continues to change as open source ESBs grow in popularity.
Because of this convergence of terms, there are now two distinct flavors of ESB. One flavor is built on the hub and spoke architecture built for earlier EAI products. The second flavor, a barebones ESB, is built on a message-oriented distributed architecture with no central hub.
Despite the move towards Web services, the issues that drove the development of the ESB in 1999 are just as relevant today. "We created this service bus largely based on messaging technology that was good at creating, queuing, and delivering messages. People needed more than quality of service," said Vandervoort. "They needed transformation and various other kinds of mediation. If you could deploy services on the enterprise nervous system, you could transform data, create action models, and use different transformation protocols. A lot of the objectives [for the ESB] were the same as for EAI, but done in an open and lightweight way."
One advantage of the more distributed approach is that it makes it easier to deploy and manage services across multiple servers. This can be important for scalability and moving servers close to their point of use. Vandevoort explained: "If I have a dozen ESB clusters scattered across the globe, I can deploy a service update to all of those in one click. A truly distributed ESB would exhibit strong distributed management capabilities through deployment lifecycle management of a single name space."
For example: An organization might have a service it wants to run on servers distributed around the world in order to reduce latency. Through distributed management it can deploy them to all of these locations simultaneously and then start, stop, pause, resume or upgrade them all at the same time. Distributed management becomes more critical in retail applications, where a chain might want to update a promotion to 10,000 stores in a few seconds.
Jess Thompson, Research Vice President at Gartner, agrees that many ESB products are extensions of the functionality that came with earlier EAI products, such as webMethod's ESB platform, IBM's WebSphere Message Broker, or Tibco ActiveMatrix BusinessWorks.
EAI grew in importance because it could eliminate the mess of integrating multiple applications through non-standard interfaces. EAI provided a common point of integration for mediating between different apps to clean things up.
Barebones ESBs can successfully be used for application integration in some instances, but they are not as capable as those that evolved from EAI at dealing with the whole spectrum of interface cases. Thompson noted that EAI brings pretty heavyweight technology, especially if you are just mediating the exchange of interactions between service consumers and service providers.
Thompson also said that over 70% of the services built by organizations within the next five years will be built using existing assets. That means there will be a lot of integration going on, especially in coarse-grained business services. While EAI might be a heavier approach than a pure ESB, it is needed to support those interactions.