Remember that kid in the neighborhood - the one who had the bat and ball, and if you wanted to play together, you had to use his stuff? Even if he was a pretty nice kid, there was always a time when you longed for the ability to play on your own, or at least use a bat that was more your size.

Until recently, with the advent of Web services, that's been the situation with EAI products. The vendors in the EAI space have been in a constant battle, competing with one another for market share and mindshare in a fairly limited market. And while adding new features to their products has been a strong point for each vendor, interoperability between EAI offerings has been extremely limited. Realistically, it isn't in any vendor's best interests to interoperate - they lose revenue and potentially even an account by doing so. And since their offerings are geared toward integration within a company, the party line is that you need only one EAI product.

Which is fine if your company never merges with another company, or gets acquired, or spun off, or any of the myriad of different corporate dances that can ask IT shops to combine systems they never dreamed of supporting.

An even more problematic issue is dealing with external entities within the supply chain - the suppliers, distributors, and customers. Far and away the largest technical issue with tightly integrated supply chains is the integration of all of the needed systems in the chain. Rarely does an entire supply chain present a neat, unified API for each segment of the business.

But that's just what Web services provides - a way to put that interface on the systems. A common language, allowing two or more participants to work together, regardless of hardware and software.

EAI vendors have been slower to react to the Web services movement than have the application vendors. In part this had been due to Web services' origin in the application server communities. The companies leading the charge on Web services, Microsoft, IBM, BEA, and the like, all have a stake in the way applications are created, and much of the industry perception of Web services is a result of their marketing arms, who would love you to believe that you need to select an application server platform to do Web services.

Adding to the delay for EAI vendors has been the chicken-and-egg problem: vendors were waiting to see if Web services was a flash in the pan before investing limited development resources into it.

But this issue shows that they've begun to adjust and react. And they bring a completely different take on Web services to the party. For EAI vendors, Web services are about integration, not application.

I've long been a proponent of a richer set of Web services protocols - additions to the standard set of UDDI, XML, and WSDL. Because until the technology has a business use, it's nothing but interesting technology. And one of the things that's missing is Business Process Management (BPM). The ability to coordinate activity is crucial to Web services.

Now some people would claim that EAI and BPM are two entirely different things, and if you look at the technologies used to implement them, I won't disagree. But if you look at what they both do, which is to orchestrate communications between entities, then they begin to look very similar. Web services needs EAI capabilities.

At the same time EAI needs Web services. EAI needs to move to an open standard so businesses can begin to take advantage of integration capabilities, and not just within the confines of a single corporation, but also within the whole supply chain. Forget the kid with the ball and bat, we're in the big leagues now.

Author Bio
Sean Rhody is the editor-in-chief of Web Services Journal. He is a respected industry expert and a consultant with a leading Internet service company. Sean@sys-con.com