What really is an ESB?

Even-though all of us think we know what an ESB is, it's actually difficult to give a proper and comprehensive answer to the above question. ESB stands for Enterprise Service Bus, yes, but what kind of a beast it it?

The best answer I found so far is the following, from Java SOA Cookbook published by O’Reilly.

There is no specification for ESB. There is no standard that supports the creation of an ESB, or even a precise definition of what an ESB is. While by now the industry generally agrees on what features should be present in a product calling itself an ESB, vendors offer a wide variety of products with features that differ dramatically from one ESB to the next.
  
How to create a route in Oracle Service Bus is completely different from creating a route in TIBCO ActiveMatrix or a delivery channel in Apache ServiceMix. They don’t all have the same features, and the common features they do have are implemented in very different ways. So the knowledge you would gain about the specifics of one ESB would not be transferable to any other. A deep dive on Mule would offer very little insight for developers who aren’t using Mule, and there are so many ESBs to choose from.
  
In some cases, vendors, such as Oracle, Software AG, IBM, TIBCO, and others, offer “SOA suites” that comprise a collection of products such as an ESB, an orchestration engine, a SOAP engine, an enterprise registry/repository, a BPEL engine and design- time tools, Business Activity Monitoring and related tools, and more. The features present in these products from vendor to vendor are not consistent. For example, you might have an ESB from one vendor that handles transformations for you, and another ESB product that delegates transformations to an orchestration engine.  

It can all get very confusing. You can get a standalone orchestration engine, such as Apache ODE or Active Endpoints VOS, as well as standalone ESBs. Some ESBs run on an application server. Some vendors, such as Oracle, include a “light” subset of orchestration functions directly in their ESB but also sell an orchestration product.

The ESB is capable of connecting a variety of messaging systems without forcing you to create point-to-point channels that are visible to application clients. Clients connect to the bus, which serves as a mediation layer that shields clients from the disparate messaging formats and protocols used in the backend systems. The bus choreographs message interactions with a variety of related SOA technologies, such as rules engines (external or embedded), an orchestration engine (employing BPEL or XPDL), adapters for legacy and packaged applications, and internal routing and transformation mechanisms. This allows all of the nodes of the bus to interact without having to create specific routes to each application, thereby reducing the maintenance overhead. Because the bus abstracts and mediates connected nodes, some flexibility is achieved; if you want to swap out one application for another one, you can do so with minimal disruption to the overall solution.  ESBs are the backbone of SOA. They provide the opportunity to really make your entire IT landscape visible, integrated, and ready to participate in new composite applications across EAI, supply chain, B2B, portals, and more.

An ESB is often lightweight, and offers a centralized system for deploying components that can scale independently. 

An ESB allows you to send messages between multiple services in a distributed environment, offering a layer of indirection that provides a rich set of mediating features for those messages. An ESB is typically platform-independent in the sense that it will run on a range of operating systems and is often neutral with respect to application server and programming language. The bus allows you to connect native Java applications, .NET applications, object request brokers, and legacy platforms. To achieve this end, most ESBs offer support for invoking web services and other network-ready application nodes, employ adapters to connect with packaged and legacy applications, offer robust routing support for messages, allow orchestration and transformation of message content, and more.