Middleware evolution

Web services give CTOs an opportunity to rethink their portfolios of high-cost technologies

THE FUTURE OF WEB services in the enterprise lies not in hit-and-run applications such as stock quotes, ZIP code validation, and weather updates. Rather, Web services promises to take companies to the next level of automation: Business process integration. Instead of passively routing data from one application to another, BPI drives processes -- and CTOs want it now. Sixty-three percent of respondents to the 2002 InfoWorld Web Services Applications Survey cited BPI as the primary objective of their Web services deployment.

Web services is uniquely equipped to advance a CTO's BPI strategy. But when compared with commercial EAI middleware, Web services' technical shortcomings are substantial. Established middleware handles security and transactions, neither of which is covered by Web services standards. EAI middleware arguably has an edge in orchestration, too, because every viable middleware solution has mature connectors to various messaging transports and back-end applications.

But that may be a short-lived advantage. The Web services standards already in the works -- WS-Security, WS-Coordination, WS-Transaction, and BPEL4WS (Business Process Execution Language for Web Services) -- will close many of the gaps between Web services and EAI middleware.

The extent to which Web services will supplant companies' current EAI infrastructure is unclear. Only 13 percent of survey respondents are using or will use Web services for EAI in the next 12 months. IT organizations have an enormous investment in EAI, and, for many, those efforts are just starting to generate returns. Middleware vendors are going to great lengths to characterize Web services as complementary to -- not competing with -- what they've been doing all along. As IT mines the overlap between the old and the new for cost savings, vendors are pushing back by pitching middleware as a hardening layer for Web services.

Vendors prefer the old EAI approach because proprietary technology gives them more control over their markets: Server, tools, and consulting services revenues are driven by vendor-specific EAI. IT is under internal and external pressure to build on top of current EAI technology instead of replacing it.

Initially, middleware players hoped customers would choose their reliable proprietary messaging transports instead of the primitive methods used in most Web services implementations. So far, this isn't panning out. According to the Web Services Applications Survey, the bulk of deployed Web services use the very HTTP, HTTPS and SMTP transports favored from the beginning. Tibco's advanced, reliable Rendezvous transport is used by a scant 3 percent of surveyed readers, so it seems unlikely that EAI middleware will thrive as a plug-in messaging layer for Web services.

Establishing BPI as a primary objective makes it smarter to converge on Web services. All Web service endpoints can expose similar capabilities. Data format and type translations are not needed, reducing the likelihood of errors. Debugging, auditing, and intelligence gathering are simplified by standards and readable, easily-parsed XML. CTOs gain the freedom to choose how to implement BPI; they're not stuck with one vendor's take on how it should be done. Nearly five times more respondents plan to use Java than middleware to run Web services.

As are many middleware vendors, Vitria and Tibco are struggling to integrate Web services into their offerings. Vitria's endorsement of BPEL4WS will enhance BusinessWare's interoperation with other standards-based solutions, but its Web Services Module merely routes SOAP requests to BusinessWare, cementing the underlying proprietary API and middleware server in place.

Tibco seems more willing to embrace Web services, but it, too, is careful not to steer customers too far from its proprietary approach. Tibco is cautiously repositioning ActiveEnterprise suite as an enterprise-grade Web services platform, and it has several advantages over BusinessWare in that regard. ActiveEnterprise uses XML, XML Schema, and XSLT (Extended Stylesheet Language Transformations) for data representation and translation. It offers the HTTPS transport, but portrays its Rendezvous transport as a faster, more reliable solution. Tibco hasn't stated a commitment to BPEL4WS, but its architecture seems adaptable to future standards.

BusinessWare has no future as a framework and messaging transport for Web services, so Vitria's survival depends on establishing BusinessWare as an orchestration solution for Web services, which doesn't look likely. Vitria faces substantial challenges from Microsoft, IBM, and Sun, which are building BPI features into their application servers, tools, and back-end software. If CTOs continue to favor .Net (61 percent of respondents) and J2EE (45 percent) for Web services, Vitria has little room to add value. The Web Services Module will be used to temporarily graft Web services hooks onto BusinessWare processes as a migration stepping stone.

Tibco's strong ties to J2EE and XML make it a potential long-term fit in an IBM, Sun, or BEA Systems shop. ActiveEnterprise could help CTOs tame large-scale Web services deployments, even if they do not favor its approach to BPI. As long as it allows customers to choose components without buying into the whole ActiveEnterprise solution, Tibco stands a good chance of surviving the transition to Web services.

Middleware is the glue of enterprise integration, and Web services will not change that overnight; it's likely to take at least a year for proposed standards to take hold. Meanwhile, CTOs should review their rosters of integration technologies, looking for ways to trim costs, reduce complexity, and eliminate dependence on proprietary solutions. Any incumbent middleware vendor that can't help hit those targets and enable new initiatives should be written off.


Copyright © 2002 IDG Communications, Inc.