Roughly last year at this time, as we covered the convergence of EAI and Web services, many people were asking about the ultimate survival of EAI as a software solution. In one sense, this was understandable, as the technologies that make up Web services provide significant amounts of functionality similar to that provided by EAI products, while achieving greater interoperability.

Still, it was fairly ingenuous to suggest that EAI was about to go the way of the dodo bird. And a year later, we still see a strong presence in the market from EAI vendors. This is true for several reasons.

First of all, besides technology, EAI vendors supplied knowledge. Consider a new programmer who looks at an API to accomplish some task. Sure all the services may be exposed as method invocations, but do you know which service to invoke to create the application that you want? Are some services meant only for aggregations, and should not be used directly? Do some services have defects that make them challenging to use? Is there a better way to accomplish the task, given several services that provide similar functionality? All of these questions require knowledge, not just information about the API. EAI vendors have concentrated on examining the most critical applications in use in many industries, worked with their APIs, and concentrated that special business knowledge in their products. This extra knowledge is necessary, regardless of whether or not a Web services approach is used to access the services provided by the underlying application.

Additionally, EAI vendors have adapted to the changing times and have embraced Web services as a key delivery mechanism for their knowledge. One of the biggest impediments to EAI had always been the proprietary nature of the products, which prevented one system from working with another and limited the synergy that could be created. Web services provides widespread, vendor-neutral connectivity that alleviates the need for proprietary solutions. Newer standards, some authored in part by representatives from EAI vendors, will also continue to standardize aspects of EAI. In particular, the specifications for transactions and coordination will become a key component in the further merger of Web services technology into EAI. And the EAI vendors will likely be leaders in the release of new products based on their previous proprietary transaction and coordination engines, which will implement these new standards. Much like what happened in the Java world, vendors will compete by implementing standards, then achieving success in the field by product differentiations, such as ease of use, speed, and reliability.

Undoubtedly, the rise of Web services has also had a tremendous impact on EAI. Interapplication communication, once an extremely difficult interaction that formed part of the basis of EAI in the first place, is now much easier to accomplish, and no longer requires the custom adapters that made up a typical EAI product. This is forcing EAI vendors to become Web services vendors, and move their products up the evolutionary ladder in order to survive the commoditization of a portion of their services. Change is never easy, but there is of course the upside - now more and more software can be governed by an EAI engine, not just those for which adapters have been written, but a broad spectrum of applications, without the need to create custom adapters. This allows the EAI vendors to focus their attentions on the task of making business sense out of the offered services, not just plumbing. And that's where their value add is still intact.