IBM goes for the ESB lock-in

More than an architectural design pattern, ESB as a product makes for an effective vendor lock-in strategy, as IBM acknowledged yesterday with the launch of not one but two products bearing the ESB label.

The first product, WebSphere ESB, is described as a "lightweight" ESB designed for those customers who simply want to route and transform web services messages. It seems a lot of customers fall into that category, because the product is a response to "heavy demand for a lighter weight ESB product based on web services," Robert LeBlanc, IBM WebSphere Software general manager, told journalists in a conference call yesterday. Presumably to reassure customers perturbed by the association of the word "lightweight" with IBM, he added that WebSphere ESB comes out of the box implemented on an instance of the WebSphere application server.

I put it to him that shipping it prepackaged on the WebSphere platform could be regarded as overkill for something that (on further reflection) is really just a web services intermediary. He assured me that rather than being a full implementation of the application server, it provides just a subset of the necessary functionality to support the ESB. Unlike competing products, however, such as Cape Clear's ESB or the recently announced Synapse project, IBM's lightweight ESB cannot be implemented in a Java container on an existing WebSphere server alongside other functions. This makes it more cumbersome to distribute within a network, forcing implementation as a separate WebSphere instance with all the extra resource overhead that implies. To my mind this defeats one of the primary objects of making it lightweight in the first place. It may be lightweight in effect but it seems to be at best middleweight in implementation, and more tightly tied to IBM's own application server than you might expect from an allegedly "standards-based" product.

IBM refers to its second product as an advanced ESB. WebSphere Message Broker is built using Java on top of IBM's MQ Series enterprise messaging middleware, and, as Computer Business Review reminds us in its online coverage, is a "latter-day incarnation of the old CrossWorlds EAI product." As far as I could glean from what IBM was saying yesterday, WebSphere Message Broker is more advanced than your average ESB by virtue of its greater support for tight coupling, which is hardly surprising given its pedigree but somewhat departs from what I understand to be the core definition of ESB.

As Cape Clear's Annrai O'Toole recently pointed out in an incisive blog entry called Enterprise Bus Anyone?, vendors that have been around in enterprise messaging for decades have a habit of emphasizing the 'bus' part of ESB more than the 'services':

"Customers are buying ESBs because they are interested in rolling out Service Oriented Architecture. They are not rolling out Enterprise Oriented Architectures or Bus Oriented Architectures ... Customers are not really all that interested in buying an 'Enterprise Bus' (EB). That's because an EB is just a messaging product (MOM) and they have already bought at least one (or in many cases two) of them!"

So I took the opportunity yesterday to ask whether IBM's "advanced ESB," the WebSphere Message Broker, is architected as a set of services in the same way that the lightweight ESB and indeed its newly launched WebSphere Process Server both are. "Yes, to some extent," was the ambivalent answer I got back from IBM Software chief Steve Mills.

It seems, then, that IBM is going to continue encouraging customers to spread the kind of point-to-point integration that PolarLake's Ronan Bradley has castigated them for in Monday's opinion piece here on Loosely Coupled, SOA is no excuse to slap lipstick on a pig.

Coincidentally, I noticed Michael Liebow, VP of web services and SOA for IBM Global Services, quoted in an article on searchWebServices yesterday about the role of service contracts in an SOA. Abstracting implementation policies into separate contract documents makes services much more reusable (something I once called Contract-oriented architecture), but Liebow says that IBM is happy for customers to continue to hard-code assumptions about implementation policies into the services they deploy: "Most of what we're seeing in web services are on the trusted internal network, rather than with external partners, so a contract is not really needed ... It's still too early for it, I think, because the ecosystem you need for them hasn't evolved yet."

This kind of point-to-point thinking is so widespread that a well-researched article published yesterday by Britain's Computer Weekly reports the misleading information that "web services are not essential for SOA — message-oriented middleware does the job equally well. And for internal services the advantage of using available 'glue', such as RMI (Remote Method Invocation) to Enterprise Java Beans or message-oriented middleware, is twofold: you can reuse existing middleware technology and you avoid the overhead of using XML."

If it were acting responsibly, IBM would be knocking this kind of nonsense on the head. While it may be possible to build something that fits some definitions of SOA using RMI and MQ Series, it is irresponsible to imply that doing so automatically confers all the benefits of agility and reuse that a truly loosely coupled SOA delivers. Yes, there are some applications where tightly coupled architectures deliver better performance, and those applications can be loosely coupled into an SOA environment. But doing so will not change their inherently brittle and tightly coupled make-up.

IBM likes to hide behind the notion of 'customer choice' rather than speak out about the roadmap implications of such decisions, because the more that customers buy its costly and complex EAI products, the longer they'll be locked into buying IBM products, maintenance contracts and professional services. But as I said a couple of weeks ago, SOA must be centered around mediation. That takes more work than following the same old point-to-point patterns, but in the long term it yields more flexibility and productivity and puts vendor neutrality at the heart of the architecture. Oh yes, and if you do that, you might actually get some of the benefits IBM is promising from deploying its WebSphere Process Server, the one bright spot of yesterday's announcements.

posted by Phil Wainewright 12:55 PM (GMT) | comments | link