WebServices dot org

Web Services Will Bridge ESB Islands

There is rising confusion about how Enterprise Service Buses (ESBs) and Web services infrastructures relate to each other. One reason appears to be sheer momentum. For some time, the analyst community has been telling us that ESBs will solve most of our system integration issues. ESBs have been described in terms that are very much aligned with the language we use for Service-Oriented Architectures. A significant number of ESBs are gainfully employed in a very large number of enterprises. However, traditional ESBs are rapidly being overtaken by a newer technology wave, in the form of Web services.

ESBs have considerable value within an enterprise IT infrastructure. They are usually implemented on a message-queuing system that provides higher confidence in reliable message delivery. Application integration across a wide variety of platforms and data formats is often provided by adapters. A wider set of message handling patterns is often provided. Of course your mileage will vary with particular vendors and implementations.

However, in the context of an SOA, your ESBs are forming more proprietary islands that need to be connected. If you have more than one ESB (wait long enough, and business forces within your enterprise will lead to this unenviable position) then interoperability between your ESBs becomes an issue. ESBs do not represent a suitable way to connect your business partners or customers into your SOA and enterprise. A better solution is Web services, at least as an external connection mechanism.

If you step back and consider what technologies you are planning for your SOA, a Web services infrastructure is going to be the answer in most cases. To maximize the reuse of your loosely-coupled services, you need to make them to broadly available. Having them hidden within an ESB, or invoking the overheads of translation on and off the bus at both the exported Web service interface and at the application bus adapter will not lead to high availability or high throughput.

Realistically, many enterprises have already invested in ESB technology for internal application integration. Additionally, there are features of reliable messaging and other message patterns that are not yet mature or effectively supported in Web service infrastructure products. For many years to come, data transformation and mediation features supported by ESBs for applications that are not XML enabled will be a requirement. In addition, ESBs represent a useful migration tool to Web service enable existing systems. However, I believe that the way to view ESBs over the next few years will be processing islands that are connected using a common Web services infrastructure.