Microsoft plans to use its 10th annual TechEd developer conference this week in New Orleans to advance its cause in the battle pitting the software behemoth against Sun Microsystems Inc. and its partners over Web services. But as Web services mature, issues such as security, manageability, and reliability are becoming critical.
Redmond, Wash.-based Microsoft will announce at the show Commerce Server 2002, which is the first server in the .Net family, as well as the Exchange Server XML Web services toolkit and beta versions of SQL Server Notification Services. The company has also launched MapPoint, the first commercial Web service, which enables users to create location-based Web services.
The message Microsoft is working to convey at TechEd is that Microsoft technologies are ready for companies to use in building Web services.
On the heels of Sun's JavaOne developers' conference, which ran the last week of March in San Francisco, Microsoft is looking to curb Sun's momentum and take the technological lead in Web services.
"What was talked about at JavaOne was futures. .Net is real and here [now], but J2EE [Java 2 Enterprise Edition] is still kind of promising," said John Montgomery, group product manager for the .Net developer platform at Microsoft.
Naturally, there is a long line of J2EE application server vendors -- representing IBM Corp., BEA Systems Inc., iPlanet E-Commerce Solutions, Oracle Corp., and Hewlett-Packard Co., to name a few -- that are more than willing to rebuke Montgomery's remarks.
But between the claims that their platforms are ready for Web services, both camps are saying that the next version of their back-end servers is where native support for the necessary Web services protocols will emerge.
Sun and its J2EE application server brethren offer support for SOAP (simple object access protocol), UDDI (Universal Description, Discovery, and Integration), and WSDL (Web Services Description Language), but only through add-on packs. In the forthcoming J2EE 1.4 specification, support for standards will be included natively.
For Microsoft users, native support for the standards means waiting for the delayed Windows .Net Server, which has apparently been held up by Microsoft's Trustworthy Computing initiative, which makes security the top priority across all the products.
Montgomery explained that with the .Net Framework, which is in Visual Studio.Net, developers have full access to Web services. When Windows .Net Server ships, however, the .Net Framework will be included within, as it will with future iterations of nearly all Microsoft servers.
On the tools front, both sides claim that they have the suites in place to begin creating Web services, Microsoft with Visual Studio.Net and the J2EE folks with Java IDEs (integrated development environments) from the likes of WebGain and Borland, and proprietary tools such as BEA's WebLogic Workshop.
Whether companies start building Web services now or later, the daunting process will become easier once the native support is in place within the tools and platforms. But it is only the cutting-edge companies that are now building Web services, according to Peter Urban, a senior analyst at AMR Research Inc. in Boston.
"There aren't a whole lot of Fortune 500 mission-critical tasks being done with Web services," Urban said.
Indeed, more conservative companies are waiting for vendors to provide more details about unresolved issues, namely security, reliability, and manageability.
"One of the big issues is that security is not there now within the Web services framework, you have to build it on some other way," said Rob Perry, an analyst Boston-based Yankee Group.
There are security efforts underway, such as XKMS (XML Key Management Standard) and SAML (Security Assertions Markup Language), but they are in the early stages of development.
McDaniel explained that as Web services proliferate, security becomes more of a headache for administrators. Web services promise to be available across a broad range of endpoints, including PCs, handheld devices, cell phones, set-top boxes, and kiosks.
"The more Web services evolve, the less control there will be over security. We'll start to sacrifice control over the endpoints -- and there will be more and more endpoints," McDaniel said.
Likewise, the more endpoints that are involved with Web services, the more the manageability and reliability issues matter. McDaniel added that the more endpoints there are from which people access Web services, the harder it will be to manage those and, in turn, the more important that management will become to maintaining reliable Web services.
Since Web services applications hold the promise of being composed of numerous services residing in physically distributed locations, for the larger superset application to be reliable all of the services that make up that application have to be reliable. And when companies provide users with Web services that rely on services from a third-party partner, they in turn will have to rely on that partner to make sure its service is always available, McDaniel continued.
There remain a number of issues with SOAP and UDDI that need to be resolved, and likely won't be before J2EE 1.4 and Windows .Net Server become generally available.
SOAP, for instance, is not completely secure yet, according to AMR's Urban.
"People always talk about security as an issue. If you make a request over https, it will be secure. But if you are using http, you have to bolt security into the SOAP message," Urban said.
Experts also question whether UDDI is robust enough to live up to its potential as a directory from which users can locate and ultimately consume Web services that have been registered.
Urban added that the use of UDDI is going to remain more popular for private directories. "The public stuff is not really taking off yet," he said.
Furthermore, little doubt exists that more standards will be necessary, and there are a number of them in the works, such as WSFL (Web Services Flow Language), WSIA (Web services for Interactive Applications), WSRP (Web Services for Remote Portals), and WSXL (Web Services Experience Language). But standards bodies can be slow, making it difficult to know when the standards will be fully-baked.
Adding to the confusion, analysts said that even when the current crop of standards is mature, the need for more standards will continue.
"Like the proverbial onion, every time you peel off a layer, you get another [layer], and whether you go up or down the stack, we need more standards for Web services," said Dana Gardner, an analyst at Aberdeen Group Inc., in Boston.