Like anything new and potentially disruptive in the technology industry, the enterprise service bus (ESB) is going through some predictable growing pains. Early vendors introduced the concept, defining it via the features and functionality contained it their own products. The industry analyst community took its own time in defining what makes an ESB an ESB. Now, throw in some fear, uncertainty and doubt from vendors dealing in more traditional EAI products and a “watch this space” product roadmap approach from some of the major platform players. What we are left with is a situation that can easily cause confusion for the companies that are looking for a way to solve the integration challenges they face today, while at the same time preparing for the inevitable evolution of their systems to meet new business requirements in the future.

In many ways, it could be argued that the ultimate goal for an ESB is be an end to integration. By that, I mean a successful ESB should be about creating service endpoints that are able to communicate directly or via composite applications, orchestration engines or transformation engines in a seamless way. This should be accomplished without the necessity to modify the endpoints, or the systems and applications behind them every time a new element is added to the architecture. A successful ESB is about having a catalog that enables convenient discovery of the endpoints in your systems. An ESB is also about interoperability with proven and established development toolsets that allow your developers to work with what they know instead of forcing them to lean something completely new. Using an ESB to achieve your enterprise architecture goals is also about seamless runtime behavior, regardless of platform and execution environment. An ESB should also allow you to modify the application after it has been deployed, without bringing the entire system down.

Unfortunately, we are finding that to a certain degree the marketplace has corrupted the concept of the ESB. Some vendors have attempted to simply reposition JMS wrapper technology as an ESB. Since this approach forces the user to revert to inefficient and inflexible hub and spoke topologies, you have already strayed from what an ESB should enable you to do. Others have combined simple Web services with legacy gateways to create a kind of integration broker that attempts to achieve the kind of interoperability associated with ESBs. No matter what the specific approach, trying to reposition a failed EAI product around a new industry buzzword does not an ESB make.