ESB watered down by EAI, but distinction remains |
 |
By George Lawton
09 Jul 2009 | SearchSOA.com |
|
|
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.
|
|
|
|
|
The definition of ESB has lost some of its distinction as a distributed architecture
Hub Vandervoort,
Progress Software
|
|
|
|
|
|
|
|
|
|
While the hype around ESBs has caught on, some proponents argue that the term "ESB" has lost some of its meaning because many vendors simply rename their existing EAI products and architectures as ESBs, though they don't resemble the ESB as it was initially conceived. "ESB has been watered down as a definition because a lot of the EAI tools got recast as ESB when the term became more popular," said Hub Vandervoort, CTO of SOA Infrastructure products at Progress Software. "The consequence is that the definition of ESB has lost some of its distinction as a distributed architecture."
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.
Thompson said the design point of ESBs was to support the deployment of composite applications using Web services. In essence, they were doing something similar to EAI but, rather than mediate interactions between applications, ESBs mediate interactions between service providers and consumers. The ESB has what could be characterized as lightweight EAI: support for multiple interactions styles and store and forward functionality.
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.
|
|
|
|
