ESB - Everyone's Silver Bullet?

Given its prominence in any discussions around SOA for several years, you might think that by now everyone has acquired an Enterprise Service Bus (ESB).  However, it is clear that there is still ongoing discussion about the need for an ESB, and questions still remain as to what exactly an ESB is.  Cloud computing seems to have renewed interest in the topic. In the same way that people asked "do I need an ESB to do SOA?", we now have "do I need an ESB to do Cloud Computing?" (at least amongst those who recognize that Cloud Computing is largely service-based).

I sometimes think a better expansion of the abbreviation might be “Everyone’s Silver Bullet”, such is the perception that all you need to buy is an ESB and all your problems are solved.

I have long promoted the view that an ESB isn't a product as such, but a set of capabilities that you might assemble from various sources - either upgrading existing infrastructure, buying new components, or even building some yourself. Some of the capabilities might be embedded in the operating platform you use, or looking forward, you might consider some cloud-based ESB capabilities too.

This debate promted me to create the following extract from a report I authored some time ago, but which still seems as relevant today as it did then.

The role of SOA Middleware

SOA middleware may seem an oxymoron. SOA is meant to free organizations from the tyranny of tightly coupled implementations, which in my mind includes creating dependences on middleware, not just application and platform-level dependencies.

With support for Web Service protocols embedded in the Application Servers, and WS-STAR providing support for federated, secure, reliable, transactions between endpoints, why should there be a need for additional middleware?

The reality is that existing benefits of a middleware approach still largely applies. SOA middleware can be used to:

• Separate concerns – remove middleware capability such as messaging and mediation away from applications. Though a modern platform can also assist in achieving this, such as Microsoft Windows Communications Framework (WCF)
• Support Heterogeneity – separate capability away from OS/Platform specific functions
• Provide a more agile environment where changes to infrastructure do not impact applications, or vice versa
• Form part of a shared enterprise SOA infrastructure, rather than embedded in or specific to each application solution
• Manage by policy, and manage centrally. It is easier to deploy and enforce policies through a layer of SOA infrastructure designed for this purpose.
• Web Services are not the only protocol. Even when they do become widely used, most organizations will continue to use the existing middleware and other protocols already in use for some time. Hence SOA middleware often provides support for other protocols.

A challenge for many organizations today, is that the capability required for SOA middleware and SOA infrastructure in general is that it is spread, and often duplicated across multiple products and technologies. In addition it is often found in a mixture of point solutions and specialist SOA products plus existing infrastructure that is typically upgraded to support SOA requirements. Whilst there may be some good reasons to consider new infrastructure products to support SOA, there is also a strong reason for many organizations to look at how they upgrade their existing infrastructure to support SOA – namely, that they already have it, and the existing infrastructure must remain in place to support existing requirements.

However, it is not as straightforward as depending on existing infrastructure. Although not an immediate concern for some organizations, SOA will place new demands on infrastructure capability that the existing infrastructure cannot so easily support. Longer term, the SOA infrastructure must itself become Service-based and able to be virtualized in the same way that is required of business capability. Even in the near term, organizations can gain advantage from using a networked approach to some SOA middleware requirements rather than using a hub and spoke approach that frequently exists today. Longer term, the federated SOA will make this a requirement.

The ESB Spectrum

In earlier reports in our CBDI Journal I identified that there was no commonly agreed definition of an ESB, or a set list of functionality one might expect to find. Consequently, so called ESB products offer a spectrum of capability as shown in the table below.


The ESB Spectrum

At one extreme, ESB products may be little more than a broker, providing routing and transformation capabilities. At the other, ESB products can provide most of the SOA Infrastructure required. It is at this end of the spectrum that the most overlap occurs with other infrastructure domains. Ideally, the range of capabilities offered should be modular enabling organizations to assemble their SOA infrastructure from a range of best of breed capabilities. Unfortunately, not all vendors share a similar goal.

A well formed ESB can help organizations by providing the core mechanism to deliver SOA run-time agility. The role of ESB includes;

• Providing the mediation layer between service consumers and providers to enable loose coupling
• Abstract hard coded transformation and routing of messages away from service consumers and providing resources – making the SOA easier to maintain, manage
• Provide a central point of control for mediation and integration policy enforcement
• Host Services within the SOA itself
• Depending on the ESB implementation
• Provide declarative approach to defining mediations
• Provide dynamic mediation
• Provide policy driven mediation
• Provide mediation based on current and emerging open standards such as WS-protocols, WSBPEL, JMS, JBI
• Provide on/off ramps for multiple transport and message types
• Orchestration of Services

As already mentioned, the capabilities required will be found in a variety of products and technologies. This will include the Operating System or Platform that hosts the services and automation units, or new SOA infrastructure such as the Enterprise Service Bus. Capabilities will also be found in new Web Service Management or SOA Management products, as well as in upgrades to existing Systems Management tools. Orchestration capabilities might also be found in Business Process Automation products. Some capabilities will also be found in upgrades to existing Message Oriented Middleware and Enterprise Application Integration products, some of which have been reborn as Enterprise Service Bus products.

Consequently, the selection and adoption of SOA infrastructure should be carefully managed.  You could assemble it yourself, but it may still be more expedient to acquire a product containing the required capability, and hence delegate the ongoing support to the vendor.  If cost of aquisition is an issue in these lean times, then there are several excellent open-source ESBs available.

There is a longer version of this available as a PDF for download from our website (free on registration). The complete report is available to our paying subscribers via our CBDI-SAE Knowledgebase for SOA.