In the beginning, the ESB (Enterprise Service Bus), was marketed as much more than an integration technology. While the core of an ESB is  certainly about connectivity between services, there was – and still is – so much more to an ESB than just integrating disparate protocols and technologies. Transformation, parallel processing, content based routing, and service orchestration are among the more useful and beneficial capabilities of an ESB.

That’s why it was somewhat surprising to see the CTO of an organization that offers an (open-source) ESB essentially quoted as discouraging the use of ESBs unless it’s for use as an integration hub. Dana Gardner, in To ESB, or Not to ESB?, analyzes MuleSource CTO Ross Mason’s recent blog that actively discourages architects from leveraging an ESB unless it’s necessary.

While the conversation focused on the pitfalls of using an ESB where you don’t need one, the Mule CTO naturally believes there are architectures where the ESB makes sense. To begin with, you need to be working on a project where you have three or more applications that need to talk to each other, he explained.

“If you’ve got three applications that have to talk to each other, you’ve actually got six integration points, one for each service, and then it goes up exponentially,” Mason said.

The ESB technology is also needed where the protocols go beyond HTTP. “You should consider an ESB when you start using Java Message Service (JMS), representational state transfer (REST), or any of the other protocols out there,” Mason said. “When communications start getting more complicated is when an ESB shows its true value.”

I could disagree more, but not much. The reduction of a robust technology like ESB – once considered the backbone of SOA – to little more than an integration hub was painful to read.

But what’s more painful is that the paraphrasing in Dana Gardner’s article misses most of Mason’s guidance. Reading through the original blog clearly indicates that Mason believes an ESB is much more than an integration hub and even spells out a rather lengthy list of “selection criteria” to help architects understand when and ESB will be beneficial and when it will not. But Gardner’s article appears to make the case that the only good use for an ESB is as an integration hub.

SECOND HAND INFORMATION OFTEN LACKING NECESSARY CONTEXT

The only disagreement I have with Mason’s list is that some of the criteria seems to contradict other criteria. For example, he states: “Do you need to use more than one type of communication protocol? If you are just using HTTP/Web Services or just JMS, you’re not going to get any of the benefits if cross protocol messaging and transformation that Mule provides.” but then offers “Do you need message routing capabilities such as forking and aggregating message flows, or content-based routing?”

But what if I need aggregation of message flows and content-based routing between three or more HTTP/Web services? Oh the conflict!

Aside from that particular nit, which is really not all that much of one given that architects are smart enough to resolve that apparent conflict, Mason’s extensive set of questions not only offer proper guidance but also subtly lays out a comprehensive list of what an ESB can (and should) really do. He is not, as it appears from Gardner’s article, implying ESB is nothing more than an integration hub. In fact it appears that Mason is doing exactly the opposite as the list of criteria clearly leads the reader toward an understanding that if the only thing you need is integration, you might want to look at solutions other than an ESB. The problem is that the secondary article distills Mason’s guidance in an attempt to succinctly get to the point and in doing so oversimplifies the answer to the question “Should I use an ESB or not?”

The article about the original article is lacking the context necessary to properly interpret and understand Mason’s points. It’s much the same as we see in an application infrastructure, where multiple point products are chained together in an attempt to provide a variety of application delivery related services: security, optimization, load balancing, secure access, and acceleration. As data flows from one solution to the next, the original context is lost and the loss of that context means that most of the hops are bereft of all the juicy information (the lengthy list in Mason’s article) necessary to actually make intelligent decisions regarding the application of policies designed to improve application security, reliability, and performance.

The use of disparate solutions to provide related but separate application delivery functions takes the transaction out of context much in the same way second-hand sources tend to distill the original source until its context is nearly gone and changes its intended meaning. That leaves folks (and devices) interpreting information without the benefit of the original context, which can lead to the wrong conclusion (wrong policy, wrong decision, etc…).

Too, the simplification of a technology-related matter also bothers me not just because it does a disservice to ESB, but because it happens all the time with technology; I see it every day with load balancing and application delivery. Load balancing is certainly core to application delivery, the latter deriving from the former over time, but application delivery is, like ESB and any other evolutionary solution, comprised of much more functionality and value than its predecessor. Load balancing is certainly easier to implement, like point-to-point integration between two services, but the optimization, security, and acceleration benefits of application delivery are lost when focusing solely on load balancing much the same way the orchestration, processing, and management benefits of an ESB are lost when focusing solely on its integration capabilities.

Distillation is all well and good, and oft times necessary, but should not happen at the expense of the technology.

Related blogs & articles:

• From the Mule’s Mouth: To ESB or not to ESB
• Dana Gardner: To ESB, or Not to ESB
• The Context-Aware Cloud
• Governance: Service Catalogs and the Cloud
• SOA Announces Comeback Tour
• SOA isn't dead, but its standards are
• Is your SOA really SEA?
• Load Balancing as an ESB Service
• Business-Layer Load Balancing