Why Web Services Won’t Replace Middleware

Web services has been heralded as the greatest thing since the last great overhyped technology (pick your favorite). In the year or two since Web services arrived as a mainstream technology, some have touted that the technology spells the end of middleware altogether because it leverages freely available open standards. Why would CIOs pay a middleware vendor for what they could do themselves with a minimum of fuss, using connections already built into every application they own?

In fact, reports of the demise of middleware are not just exaggerated, they are completely incorrect. First, Web services by definition is a subset of and complement to traditional middleware, rather than a mutually exclusive technology. Most middleware customers today are evaluating how to inject Web services into existing environments to achieve ever greater speed and efficiency. And many longtime middleware vendors are looking to move their products into a Web services space, sometimes by providing the management tools necessary to properly orchestrate Web services. (It’s one thing to say that two Web services will talk nicely to each other; it’s another entirely to make a few dozen of them work effectively together.)

For another thing, Web services is an unproven technology that is still at the early adopter stage. The Web services honeymoon is not yet over. Web services often uses a polling architecture in which the Web service polls the legacy system to access its data. That can add up to a major performance hit on the mission-critical mainframe systems. And when you open up a critical system to a Web application under Web services, security issues are bound to arise?issues that must be addressed before Web services can hope to completely take over as the next evolution of middleware.

-L.G.P.