Development vs. Deployment

The industry has spent the last five years or so to get a conceptual, architectural buy-in for web-services. The standards related to web services, generally referred to as WS-*, too have gone beyond proprietary workshops to standard bodies' technical commitees. Surprisingly all of this effort was driven by developers, for developers and of developers.

Web Services have a reached a point where if they don't cross over from the developer domain to deployment domain, there is a very real chance that this whole effort will be for nothing.

A key stumbling block towards deployment of web services is lack of real products which embody the technology developed in standards and employ the principles behind web services. While every vendor has a web services marketing program, very few have real web services products. No wonder the few customers who had the resources and implemented web services as pilots are being claimed as the reference customers by every major vendor.

ESB vs. Application Networks

The article by Dave Chappel provides a good description of what ESB is and its roadmap. However there is one critical architectural flaw in ESB. In trying to scale ESB, one has to scale the container. This is very difficult task as we all know from trying to scale other industry standard containers such as J2EE.

IMHO, application networks are better choice for scalable services that ESB offers. The reason is that in a network it is not the control but the data path that is scaled. From networking, we know scaling a data path is far easier than scaling a control. A highly scalable data path with distributed control across the service network can provide all the services of an ESB without the concomittant headaches for IT of having to integrate another layer of middleware on top of already difficult middleware landscape.