We're waiting! We've been waiting! We're still waiting! What for? Viable Web services standards!

But Microsoft, IBM, BEA, and others are playing politics with standards committees while they position their own development teams to reap the benefits.

Most recently, (March 25, 2003) Microsoft pulled out of the World Wide Web Consortium (W3C) working group that is focused on choreography rules between Web services modules. Why did it pull out? According to Microsoft, it determined that the scope of the group did not align well with the work of two Microsoft researchers. But is that the real reason? Not likely.

The real reason is that Microsoft, IBM, and BEA have already written their own specification for Web services choreography (also called orchestration) but have not yet submitted it to any standards body for consideration. So, instead of offering up their standard, they're playing their cards close to the vest.

This is not a new tactic by Microsoft or IBM, but it irks big-time. Why? Because it short-circuits the standards process, and it wastes everybody's vital resources that should be focused upon establishing broad, non-proprietary standards to make the implementation of this technology finally come together. As a result, the momentum toward actually building a real, open set of Web services standards is languishing.

What's at stake? Well, maybe the entire Web services effort.

The Importance of Web Services

Web services is a technology that promises to glue disparate program modules together into viable applications across the World Wide Web. These individual modules are like highly specialized subroutines that are written in a manner that allows them to be plugged into a Web application to provide transparent services to other modules that co-exist in the same space.

Web services has long been the goal of e-business developers. The concept of integrating small, discrete pieces of code that can communicate among each other in a secure manner across the Web holds out the promise that Web developers will be able to build massive, comprehensive e-business applications from standardized widgets served across the network from any variety of operating system platforms.

Witnessing demonstrations of how developers can build these applications is an exhilarating experience: By pointing and clicking, browsing and selecting, developers can assemble entire suites of functionality almost effortlessly. This is the promise that .NET and WebSphere offer as integration points through Web services: architectures that deliver application modules that are inherently self-integrating, configurable, and scalable in a secure manner.

How important is Web services to the iSeries? In the past, when customers and developers have complained that such developer platforms as WebSphere are too complex for the iSeries developer community, IBM's standard retort has been, "Wait for Web services! That will make it all come together for you."

A History of Cooperation Deteriorates into Technical Positioning

So we're waiting. And waiting. And waiting.

But in order for Web services to become mature, it has to be an open technology. It requires a standardized syntax like XML and a standardized protocol like SOAP to function in the manner promised. And though these basic technologies are in fact up and running, much more work needs to be completed. Web services also requires secure and reliable messaging mechanisms that turn the basic Internet communication protocols into a structured work environment so that each Web services code module knows how to separate, manipulate, and coordinate the user's information with other modules that are running on the user's machine.

Granted, establishing Web services standards--or any technology standard--in the wide-open mind space of the Internet stretches the capabilities of every major vendor in the market. Still, it's not enough today for IBM or Microsoft or Sun to build the technical mechanisms for communication and then walk away from the standards process. Unfortunately, that seems to be what's happening.

Maximizing Confusion

In this time of economic and technological uncertainty, the major vendors in the Web services sector are hunkering down, staking out their intellectual property claims, and pushing forward their own technical agendas by submitting competing technical specifications. If these so-called "standards" proposals are not immediately accepted by the established committees, these same organizations withdraw from the standards process altogether. Instead of using the standards process to achieve synergy and push the overall technology forward, these organizations are using their preeminent positions in the industry to drive a proprietary wedge into the Web services technology as a whole.

Consider the case of Microsoft two weeks ago. It had already collaborated with IBM to write a number of Web services specifications that relate to the issue of orchestrating services. These specs were noted in the industry newsletters, and W3C members were eager to see how they might further their standards goals.

However, because the specs have yet to be submitted to any standards committee, they were not up for examination, debate, or inclusion in the W3C standards efforts. So Microsoft representatives sat in on the meeting for a couple of days and then said, in essence, "Well, guess we've got this covered! Outta here! See ya!" They pulled their support from the standards committee, taking with them the knowledge they gleaned from the process.

In other words, they didn't use the standards process. They abused it.

Microsoft is not alone in this tactic, and the competitive tactics are getting very proprietary. Last month, Microsoft and IBM published a proposal to add reliability to Web services messaging and said they would submit the specification to some standards body. Yet, a month earlier, a group of companies that included Sun Microsystems, Oracle, Fujitsu, and Hitachi had already submitted to the standards body Oasis an initial "reliable messaging" specification that covered essentially the same ground. So, instead of assisting in the standards process, the organizations are competing against each other to be the standards bearer. Clearly, the various companies are not using the institutions of standards committees to achieve consensus: They're using the committees to position their technologies as the standard and then backing their positions with the might of their market share.

Why?

So why are these vendors pursuing such a destructive strategy? Well, of course R&D is extremely expensive, and technical egos are quite robust. But behind this entire process is the goal of establishing one intellectual piece of property--property that is patented, though publicly available--as the standard specification. Once established in the field of Web services, you can almost guarantee that royalties will readily flow.

But in the meantime, those of us who are awaiting the maturity of Web services will be waiting for a long time to come. And ultimately, this fragmentation of the standards process will cost us all lots of money as different Web services standards for e-business compete. The goal of integration will falter, and the value of Web services as an integrating technology will fail. If these top vendors don't stop playing political games soon, developers will be forced to start seeking a different route through some different technology, leaving Microsoft, IBM, Sun, and others each holding up their own proprietary solutions as the keys to the future.

Unfortunately, those keys won't fit any of the locks we're seeking to open.

Thomas M. Stockwell is the Editor in Chief of MC Press, LLC. He has written extensively about program development, project management, IT management, and IT consulting and has been a frequent contributor to many midrange periodicals. He has authored numerous white papers for iSeries solutions providers. His most recent consulting assignments have been as a Senior Industry Analyst working with IBM on the iSeries, on the mid-market, and specifically on WebSphere brand positioning. He welcomes your comments about this or other articles and can be reached at This email address is being protected from spambots. You need JavaScript enabled to view it..