The Enterprise Service Bus

Suddenly every platform vendor worth its salt is introducing an Enterprise Service Bus (ESB). So, what's going on and why is this important? Simply put, it represents the evolution of middleware from the era of "hub and spoke" and application servers to an abstracted model that is tailor-made for the movement to a service-oriented architecture. In our view, the only way to get the needed scalability and robustness in a world where we can't predict outcomes is through this abstracted model.

In a perfect world, all vendors would implement this infrastructure in a common and consistent way. However, each vendor would like to be the leader of the ESB pack. In other words: "Come to our service bus and your problems go away." While the vendors would love to occupy this strategic position, no customer we know is ready to forgo their existing investment and move en masse to one service bus. In the long run, vendors will be forced to provide a consistent approach that enables customers to have multiple service buses that interoperate. But we'll have to wait until customers' pressure forces change.

Where We've Been

To understand where we are going, we have to understand where we have been. The traditional way that customers have established application-to-application communications at the enterprise level was based on a hub-and-spoke approach. Typically, systems would communicate through a hub that hosted a directory, knew the network topology and directed the traffic. The messaging backbone would be a message-oriented middleware (MOM) product such as MQ Series or MessageQ. In the new world of ever expanding networks and highly distributed computing, this model no longer scales. Does this mean that organizations will be throwing MQ Series or MessageQ out the window in order to move to SOA? No. These technologies will continue to execute specific jobs within the context of the enterprise. The difference is that these technologies are being incorporated as one transport option within the enterprise service bus.

Defining the ESB

The Enterprise Service Bus (ESB) must have a set of characteristics that enable it to become the backplane for enterprise software environment, with the ability to connect hundreds of application end-points. The characteristics include:

The ESB must be applications aware. It must be able to understand where application code lives, how to connect to it, and what the rules of engagement are. Most importantly, the ESB must be able to understand and respond to the context of usage.
The ESB must enable a variety of different communications methods (batch, real-time, and right-time) to be surfaced in the right situation. These methods (i.e., CICS, Tuxedo, MQ, MOM) are encapsulated within the ESB.
To be successful, an ESB must be able to link seamlessly to a variety of related services including security, identity management, management services (load balancing, etc.), and service provisioning.
The ESB must support common standards such as XML, SOAP, HTTP and UDDI registry.
The ESB must be able to work from the context of business process. A Business Process Bus (BPB) must be a separate abstraction model that sits on top of the ESB. It must be able to understand business process as well as critical business rules. The BPB must understand how services are linked together in different business instances and scenarios. Its focus is on context.
The ESB is based on a federated model that embodies a modular architecture. This is critical because organizations are increasingly virtual. They have the flexibility to link seamlessly to partners, suppliers, and customers with the same scalability and predictability that an organization would expect from a single organizational view.

The ESB Players

The players are the who's who of the enterprise software market. This is both good news and bad news. Some of these efforts will fail; other vendors will be extremely successful. As this happens, each vendor will tend towards a winner-takes-all approach. Here is our preliminary list of the major competitors, including those that we believe will be drawn in to become competitors (either through acquisition or partnership) in order to support their SOA initiatives. In the next several months, we will provide an assessment of the players based on the aforementioned criteria.