Microsoft's Web services approach may be the easiest, but at what cost? WEB SERVICES’ PROMISE to eliminate the complexities of EAI (enterprise application integration) plays like a siren’s song to all levels of IT management. Worn down by mounting costs for EAI-related consulting, development, and middleware, many IT chiefs see Web services as a long-sought ladder out of the EAI money pit. Others view this nascent technology with a more cynical eye, but IT departments, software vendors, and developers alike are under enormous pressure to embrace and implement Web services. While rivals Sun, IBM, and Hewlett-Packard scramble to piece together their Web services strategies, Microsoft is in the unusual position of being the technology leader. When Visual Studio .Net makes its retail debut in February, developers will gain a multilanguage IDE (integrated development environment) built around the easy design, creation, deployment, discovery, and consumption of Web services. If Microsoft’s strategy works, many Java shops will be enticed to .Net by the lavish IDE, the C# programming language, and the promise of effortless integration of Web services into their applications. The road to Web services is not necessarily a smooth one. Both Windows and Java developers face huge challenges in porting existing code to .Net and building connections to external applications. IT bosses who want to leverage .Net tools must use Windows servers to host .Net applications and services. That will mean trusting Windows to manage critical elements of the company’s enterprise application infrastructure, a role that Sun and others contend Windows is unfit to play. Microsoft counters that Windows and .Net are ideally suited to enterprise tasks and that Windows Web services technology is at least a year ahead of competitors. Consultants go home Regardless of whether you buy Microsoft’s take on the market, the notion of reducing your company’s dependence on consultants must be appealing. Too many substantial business software purchases turn into open-ended consulting contracts, making planning more complicated and operating costs almost impossible to project. Much of the money paid to consultants is invested in fitting a new application into the company’s latticework of existing software. As the applications evolve, the consultants must return to tweak interapplication interfaces so that data continues to flow smoothly. Web services lay down a set of standardized rules for wiring applications together. But by itself, this isn’t enough to bring costs down. Indeed, Web services will raise operating costs if they are implemented as yet another interoperability layer. If they don’t supplant any existing middleware, Web services merely add to that pile of code that only pricey consultants are smart enough to understand. Unlike its Unix-oriented rivals, Microsoft does not rely on consulting revenue. A key element of Microsoft’s pitch is that Visual Studio .Net makes Web services technology accessible to in-house developers. Microsoft makes no secret of its plans to use Web services as an engine to drive sales of tools, operating systems, enterprise software, and hosted services. During the next several months, enterprise Windows applications from Microsoft and others will be wired for Web services through .Net, which promises a paradise in which any entry-level Visual Basic programmer can safely and easily interweave data from the company’s applications, as well as from external services to which the company subscribes. If you could shift integration duties to a small group of in-house developers, you could gleefully show your consultants the door and recover a bundle of money. No free lunch The .Net framework will eventually make its way to Unix, but for the foreseeable future, realizing the Eden described above means standardizing on Windows. Existing Web services standards leave key issues such as security and scalability to vendors to resolve. Until the standards are fleshed out and implementations mature, compatibility problems will complicate connections between .Net and non-.Net Web services. The short-term future of Web services is uncertain, but we see a brighter day on the horizon. Windows developers should use Microsoft’s tools, not low-level APIs, to outfit applications for Web services. This approach will make it easier to adapt to changing standards. Sun’s December release of the Java XML Pack officially puts Java on the road to Web services, and Sun says it will fill in the missing functionality (compared to .Net’s Web services) in the coming weeks. Customers, ISVs, and standards will eventually force the .Net and Java camps to come to terms and commit to transparent Web services interoperability across platform lines. Software Development