Enterprise Service Bus

Enterprise Service Bus or ESB is one of the most important components of Service Oriented Architecture (SOA). But what is it? Is it a product, a technology, a specification or a platform?

ESB is one or more of the following:

A distributed, heterogenous infrastructure
An event driven integrator
A message oriented integrator
An Intelligent router
A protocol transformer
A control point (for external services)
Able to substitute one service implementation with other, with no effect to client
A suitable level of quality of service provider
Provides means to manage services in SOA
Operate & integrate in an heterogenous environment

Basically, ESB is a logical architectural component, a set of infrastructure capabilities, provided and implemented by middleware technology, that enable the integration of services in an SOA. But, it is beyond just the routing and transport capability, at the same time not all of above capabilities are needed to have an ESB in place.

I would put the service choreography out of ESB. That is not really part of ESB, but some experts do keep it in ESB.
As you can see, ESB is suppossed to provide service routing capability, but not necessarily service directory. However, given that in scenarios like Web Services, UDDI acts as both service directory and router, therefore, make it also part of ESB.

We know that to implement SOA, both applications and infrastructure must support SOA principles. Enabling applications is the core - expose it as service, by creating service interfaces to the existing or new functions. Enabling infrastructure, at the minimum, involves the capability to route and transport service requests to the correct service provider. The role of ESB, in part, is to enable the infrastructure in this fashion.

That's the minimum, but what's the value add? The true value of the ESB concept is to enable the infrastructure for SOA in such a way that reflects the needs of today's enterprise.

I am much influenced by an IBM Redbook on SOA Patterns. So my views here are a reflection of what I read in that book.

The ESB supports multiple Integration paradigms:

The ESB must support in one infrastructure the three major styles of Enterprise Integration:

> Service-oriented architectures in which applications communicate through reusable services with well-defined, explicit interfaces. Service-oriented interactions leverage underlying messaging and event communication models.
> Message-driven architectures in which applications send messages through the ESB to receiving applications.
> Event-driven architectures in which applications generate and consume messages independently of one another.

The ESB does this while providing additional capabilities to mediate or transform service messages and interactions, enabling a wide variety of behaviors and supporting the various models of coupling interaction.

The ESB is positioned as an infrastructure component, and as such as a component that does not host or execute business logic. This is in contrast to components such as service requesters, service providers, and the Business Service Choreography whose role is to handle business logic.

Update: Many companies are now marketing ESB as a product or suite of products, so, no wonder if you see ESB products from different vendors competing. Well, you can commercialize anything nowadays.