The best definition and description of an Enterprise Service Bus (ESB)

Nowadays IT integration consists of a solid Service-Oriented Architecture (SOA) where primarily web services technology is used. Many consider the Enterprise Service Bus (ESB) to be a major component of the SOA infrastructure.

The ESB is often set against other solutions, such as message brokering technologies, commonly described as hub-and-spoke. Hub-and-spoke, on the other hand, has benefits over point-to-point since the number of routes is reduced.

The hub-and-spoke model is often depicted as




The hub is right in the center of the diagram and forms the central control unit. But hey! Let's do some stretching and squeezing.



and some more!



Amazing!, suddenly we have a figure that is very close to how an ESB is commonly depicted. It appears that the ESB is just another hub-and-spoke model. How can this be? Well, first of all the distinction between an ESB and a hub-and-spoke model is incorrect and confusing. Two different issues are being addressed: the centralization of control, and the distribution of infrastructure. Both ESB and hub-and-spoke solutions centralize control of configuration, such as the routing of service interactions, the naming of services, etc. Similarly, both solutions might deploy in a simple centralized infrastructure, or in a more sophisticated, distributed manner. In fact, if the Hub-and-spoke model has these features it is essentially an ESB.

Now let us iterate the main principles that SOA relies on:
● Explicit implementation-independent interfaces to define services.
● Communication protocols that offer location transparency and
interoperability.
● Services that encapsulate reusable business functions.

Where does the ESB step-in?
The ESB enables the infrastructure, at the most basic level. The ESB provides the capabilities to route and deliver service requests to the correct service provider. The ESB supports the substitution of one service implementation by another with no effect to the clients of that service.
This requires not only that the service interfaces be specified according to SOA principles, but also that the ESB allows client code to invoke services in a manner independent of the service location and the communication protocol involved. Such service routing and substitution are amongst the many capabilities of the ESB.

So what are the minimum capabilities of an ESB? The following list sums it up.
● Routing and addressing services providing location transparency
● An administration capability to control service addressing and naming
● At least one form of messaging paradigm (for example, request / response, publish / subscribe, and so forth)
● Support for at least one transport protocol that is or can be made widely available
● Support for multiple means of integration to service providers, such as web services, asynchronous messaging, adaptors, and so forth.
● An open and implementation-independent service messaging and interfacing model, that should isolate application code from the specifics of routing services and transport protocols, and allow service implementations to be substituted.

If this seems a little too technical then a quote might be interesting.
Stuart Ransom, a vice president at Sonic Software, described the minimum requirements — the ESB table stakes as he put it — as messaging, transformation and routing.

That's consistent with Gartner's ESB definition, which the firm developed in late 2002.

The messaging layer — the Bus (B) in ESB — provides an intermediary through which applications can communicate. Transformation involves mapping data to a format that both sending and receiving applications can use. Routing helps deposit a message at the proper destination.

Finally remember, an ESB is an architecture not a product.