The Omnipotent Extensible ESB

*Editor's Note: This article is being re-issued in light of exciting news in the ESB space in the last week.

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.

Take for example products identified by their vendors as ESBs that are built around a single transport such as JMS. Should a company attempt to bring these products into the enterprise and hope for interoperability, they may be in for a rude awakening. Any time your ESB is built around a single transport, you will inevitably need also to bring in an integration broker to make the investment useful in the least. In the JMS example, only JMS applications benefit from a JMS-based ESB. Since the goal of an ESB is to achieve seamless interoperability of all applications in the enterprise, requiring .NET, CORBA, TIBCO, mainframe, C++ and Web services-based applications, among others, to pass through an integration broker to be accessible to your ESB completely defeats the purpose of your technology investment.

The same argument can be said about vendors that elect to build a Web services only ESB. In the Web services only scenario, the approach is to move SOAP over HTTP or SOAP over any other transports. The biggest fault with this approach is that it assumes that your entire enterprise is Web service enabled. Unfortunately, that assumption is often wrong. For example, MQ Series applications that are not Web services enabled do not understand SOAP. Even if you attempt to use MQ Series as the transport, the approach is going to fail and you will find yourself forced into adopting a hub and spoke topology.

What we can determine from these two examples is that the single transport model ESB and the Web services only ESB approach, whether intentional or not, is really an ESB for green field integration opportunities in the enterprise. This presents an interesting conundrum since it could be argued that 80-90 percent of interoperability requirements in the enterprise are for applications and systems that have been previously deployed and may be considered legacy. Even if an enterprise has elected to move toward a common infrastructure platform for future application development and deployment, conventional wisdom holds that it is highly unlikely that any enterprise will be Java everywhere, or .NET everywhere or Web services everywhere. It is simply not going to happen that way in the world’s largest enterprises.

Facing the heterogeneous nature of today’s enterprise systems, you need an ESB that is truly extensible and allows you to use the same application coordination infrastructure for all the applications and systems found in the enterprise. Extensibility, when discussed in the context of an extensible ESB, means that systems architects are able to use configuration driven development strategies that effectively keep middleware artifacts separate from application development. An extensible ESB helps to make your applications more flexible and future proof, as changes at the middleware level, or in integration scenarios will not force a change in the underlying application. Extensibility also means that developers and/or architects have the ability to easily and cost effectively create their own plug-ins to support interoperability scenarios unique to their own enterprise. In many enterprises it is not uncommon to find homegrown middleware solutions supporting mission-critical applications and systems. An extensible ESB gives you the freedom to create real interoperability and efficiently bring all systems and applications into your enterprise computing initiatives.

There is no question that there is a lot going on, and a lot of noise in the ESB space. The good news is that as the ESB market continues to mature, the confusion associated with it should begin to dissipate. The differentiation between the various products in the ESB bucket are becoming clearer and CIOs and enterprise architects are better able to truly understand which products will best help them accomplish their integration goals. Most importantly, the industry is beginning to see that deploying an ESB is all about lowering the barrier of communications across the enterprise. Whichever ESB product you choose, from whichever vendor, you must be confident that when incorporated into your architecture, the ESB truly blurs the distinction between systems and helps turn the heterogeneity inherent in nearly all enterprises into a business asset.

About the Author

Ivan Casanova is the Director of Product Management for IONA Technologies, and is responsible for the execution of IONA’s product strategy. Before joining IONA, Ivan served in a number of senior management roles in product marketing and product management at middleware vendor Level 8 Systems.

More by Ivan Casanova