Circling back on ESBs vs XML Appliances

Alexander Ananiev at MyArch has an in-depth and insightful response on the ESB vs XML Appliance debate.

For the most part, Alexander elaborates on the core differences between ESB and XML appliances, and hits the nail on the head when he discusses the lack of extensibility inherent in the appliance model. There are only a couple of points on which I disagree.

Extensibility of hardware appliances is typically very limited. This is the cost of having closed-down low-maintenance device. Allowing running arbitrary Java code on it would simply defeat the purpose of going the appliance route in the first place. There is obviously no way to run business logic on the appliance.

While I agree with the lack of extensibility inherent in hardware appliances, I would argue that business logic as we understand it is being replaced by process orchestration and as such is certainly executing on appliances via BPEL or proprietary process execution languages. I would point out CastIron Systems IA3000 as the best example to date of this evolution. 

As a side note, I believe that ESB capabilities will be moving down the stack to the base application server products. It becomes more and more difficult for vendors to charge for application server licenses as the competition in the open source space intensifies (just look at the buzz generated by the latest version of Glass Fish). At the same time, more and more enterprise applications are being built using Web services and more and more applications become Web service consumers. This means that soon most applications will require using ESB-like integration technologies that would allow them to orchestrate and mediate services easily. So software ESB products will be used more and more as platforms for service-based applications whereas XML appliances will be playing a key role in the Web services integration/management space.

I'm going to agree and disagree. The belief that ESB capabilities will be moving down the stack is hard to argue against as it certainly already appears to be occuring right now and the effect of OSS packages has been felt by ISVs for a number of years now. But while XML appliances offer some capabilities in the integration space, they do so only to provide mediation, management, and security capabilities and are not true integration devices. They currently lack several key features required to be considered integration devices, most notably true orchestration capabilities.

That does not mean that they won't become true integration devices, but it seems unlikely. Even IBM is keeping the two lines separate. The XI50 is an integration device, not a gateway device like its XS40 sibling, and it does not appear that IBM will merge the feature sets any time soon, recognizing the need for devices that serve both the gateway/networking market (XS40) as well as the integration market (XI50).

That XML appliances will play a key role in the SOA/XML space is absolutely true, but whether they are deployed for their minimal integration capabilities or their delivery capabilities is another story. The latter is most likely, which keeps XML appliances firmly in the Service-Oriented Networking category, and out of the integration category.

Imbibing: Coffee