Is ESB The Mediation Infrastructure of Web Services Platform?

Lori MacVitte from F5 had a few comments about my post on using XML appliances in ESB capacity. While I don’t completely agree with some of her specific points about what ESB capabilities are missing from XML appliances (for example, parallel processing is employed by most appliance vendors, transactionality is also supported for relevant protocols (although no XML appliance can act as an XA transaction coordinator)), the overall observation is correct – there is (and there always will be) a big difference between software-based ESBs and hardware-based XML appliances.

Software ESBs are implemented on top of application servers or messaging products. As such, they are infinitely flexible. Even if certain feature (e.g., some fancy transformation) is not supported by the ESB product out of the box, it can always be custom-developed using Java or other language supported by the product. This custom code can use all the facilities of the underlying application server, such as transaction management, connection pooling and so forth.

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.

In many cases, organizations implement ESBs to serve very simple needs, such as authentication/authorization, management/monitoring, schema validation and, perhaps some relatively simple transformations dealing with cleansing data formats and reconciling version incompatibilities. The actual business logic involving business process management, service orchestration and other aspects is very often pushed down to the application tier. In other words, ESB in this case is treated as a low-level integration and service management infrastructure as opposed to a container for Web services. Appliance-based ESB would fit very well to this environment.

On the other hand, if there is a desire to use ESB as a platform and container for Web services, appliances are certainly not appropriate. Such a Web services platform acts as a next generation application server. It allows developers to implement Web services using technologies supported by the ESB (such as mediation flows and BPEL) and/or using technologies supported by the underlying application server (Java EE). Product such as WebSphere Proces Server, and, to some degree BEA AquaLogic Bus (it does not support BPEL) fit into this category.

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.