The recent announcement of additional integration capabilities in the IBM WebSphere DataPower XI50 has given rise to speculation that perhaps the enterprise can replace its ESB with an appliance. Gary Smith over at SOA Network Architect disagrees with the assertion that the XML appliance is the "ultimate ESB", while conceding that the SOA appliance may provide a subset of the functionality required and may, in fact, be able to replace the ESB in specific scenarios.

I am agreeing with Gary for the most part, not agreeing with Alexander Ananiev (author of the aforementioned blog).

While the additional integration capabilities are nice, as well as the ability of the XI50 to now address the transformation of formats other than XML, this in and of itself does not necessarily supplant the need for an ESB. The XI50, along with all of the existing XML appliances on the market today, does not address several features and functions required of a product to be granted the ESB moniker. It's more appropriate, and has been for some time, to refer to these products as "ESB Lite", providing the more common use-cases for ESBs without the more advanced functionality offered by true ESB products like those from Sonic Software, BEA (AquaLogic), Oracle, Fiorona, webMethods, and Polar Lake.

So what's missing? Four primary capabilities continue to separate the XML/SOA appliances from true ESB offerings:

1. Orchestration capabilities

2. Transactional integrity

3. Distributed processing and failover

4. Parallel processing in the pipeline

You can't simply claim that adding adapters for messaging middleware and more transformation (message enrichment) capabilities makes a product the equivalent of an ESB. Transactional integrity and parallel processing, in addition to full orchestration capabilites, are required of an enterprise class ESB. Without those features the XML appliance can certainly function in a limited ESB capacity, but it is not a true ESB. Hence the designation "ESB Lite". And that doesn't even begin to take into consideration the disparity between protocol support in the two product sets, another limitation of XML/SOA appliances.

If you were to argue that in many cases organizations don't need the advanced functionality of an ESB, you'd be right. If you were to argue that in many scenarios there is no need for the complexity of a full blown ESB implementation and that an XML appliance would suffice, you'd be right. But if you argued that this means an XML/SOA appliance can take the place of an ESB in scenarios where functionality like transactional integrity and failover are necessary, you'd be wrong.

Sharing similar features does not make a SOA/XML appliance an ESB any more than it makes an old El Camino a truck.

Now, does that mean that functionality in SOA/XML appliances might continue to evolve until they reach feature/capability parity with the ESB? Sure. That's a possibility, in fact it's a very good possiblity given the continued focus on ESB-like capabilites across the XML/SOA appliance marketplace. But there are some tough hurdles that SOA/XML appliance vendors will need to jump to reach parity with the ESB, and in the end it may not be worth the time or effort to do so.

Imbibing: Mountain Dew