Your Bus Needs a New Driver

Three reasons why an ADC should be an essential component of your SOA initiative

An ESB (Enterprise Service Bus) can be a valuable component of your SOA initiative. It provides orchestration, service virtualization, content-based routing, and asynchronous messaging capabilties. All good things and in some cases (not all) necessary for your organizational specific SOA initiative to succeed.

But don't fall into the trap of using an ESB to perform duties for which it was truly not designed. Nearly all ESBs overlap in functionality with application delivery controllers (ADC), but their implementation of such functionality is rudimentary and unlikely to suffice as even adequate in most complex processing environments.

There are three reasons why you should consider deploying an ADC to provide these particular services rather than rely on the basic functionality provided by your ESB.

1. Load balancing

While the most basic of load balancing algorithms are supported by ESBs, they are exactly that - the basics. Load balancing has always been the purview of the application delivery controller and these devices provide a plethora of options to ensure that not only are services load balanced, but that they are load balanced in a way that improves performance and ensures availability. While the ADC has traditionally been deployed at the edge of the network, on the permiter, there is no reason why they cannot also be deployed inside the data center, as a service on your ESB providing the most advanced load balancing capabilities and assurances of availability possible.

2. Failover

In the same vein as load balancing, ESBs provide only the most basic of failover options - and then usually only at the broker or node level. While an ESB is capable of ensuring availability of nodes through a distributed computing model,  it is not capable of providing failover for services which are deployed outside its domain of control. Additionally, most ESBs providing failover support require that the backup nodes be hardcoded, introducing unnecessary configuration complexity and increasing the time and effort necessary to scale your implementation. While the ESB may be able to ensure its own availability, it can do very little if anything to ensure the availability of services it is orchestrating. An ADC, however, is purpose built to provide failover capabilities and ensure availability of those services and is well-versed in easing the process of scaling systems.

3. Advanced Health Checking

While the ESB may be able to provide load balancing and even content based routing, these products do not take into consideration the health of the service being load balanced. ADCs have long recognized that though a service may be accessible, still it may be returning errors that result in the same end as being unavailable. While an ESB will continue to route to a service regardless of whether the service is actually returning valid content, an ADC is capable of validating the content being returned and ensuring that traffic is routed to an available and correctly functioning service. This eliminates unnecessary error handling and delayed processing of messages within the bus and ensures a better performing infrastructure.

An ADC cannot take the place of an ESB, but neither can an ESB take the place of an ADC. Use the best tool for the job and be not fooled by the offering of rudimentary features in your ESB. If assurance of availbility is a must, then design your SOA infrastructure with an ADC up front. Your transactions - and SOA - will thank you for it.

Imbibing: Coffee