Why Standards Overlap

In June 2002, a vendor coalition led by Sun Microsystems wrote a specification called WSCI (Web Services Choreography Interface, or Whiskey, in geek-speak). A few months later, IBM, Microsoft and a few other vendors offered up BPEL4WS (Business Process Execution Language for Web Services), a specification that overlapped with WSCI. W3C formed the Web Services Choreography Working Group to consider the specifications. At the first meeting, a researcher from Microsoft showed up "to determine if he wanted to join the working group", says Microsoft's VanRoekel.

David Chappell, Sonic Software's chief technology evangelist and a member of the W3C working group, remembers the meeting well. He says the representative from Microsoft and one from BEA Systems "were clear that there was this other BPEL initiative, and they said: 'The wishes of both Microsoft and BEA are that the group focus on things that are complementary to BPEL and not competing'," recalls Chappell. "The response from the group was: 'We'll take that under advisement.' So Microsoft said: 'We're not going to participate.'" The Microsoft representative never returned, although BEA continued to be a part of the group. IBM does not have a representative in the group.

Microsoft's VanRoekel says the researcher made the decision whether to join the group meeting as an individual, "independent of him being a member of the Web services group at Microsoft". But the damage had been done. Some vendors, most notably Oracle and Sun, took it as a snub and a signal that IBM and Microsoft were going to go their own way on Web services.

Indeed, Microsoft and IBM took their BPEL specification (which each had been working on for years and had embedded into their products) to Oasis and formed a committee to begin working on a standard. Responding to complaints about potential confusion and duplication, Oasis and W3C established liaisons to coordinate work between the two groups to try to avoid overlap.

As of this writing, they're still working at it.

Oasis Versus W3C: Titans Clash by Proxy

If there's a driving force behind the growing competition between Oasis and W3C, it's less the organisations themselves than it is their predominantly vendor membership. They're split into two major camps: IBM and Microsoft on one side and Sun and (usually) Oracle on the other, with smaller vendors trailing in the wake of both. IBM and Microsoft worked together to build the first major Web services specification, SOAP, that they offered to W3C for consideration in 2000 (W3C later modified and ratified it as a standard in June 2003). In April 2001, IBM and Microsoft submitted a road map to W3C of the specifications that they believed needed to be added in and around SOAP to fill out the Web services stack, as it is known.

IBM and Microsoft have followed that road map ever since, publishing 20 different specifications for Web services. Critics say the plan is both an impressive technological vision . . . and a rationale for excluding other vendors - and even the standards organisations - from the process. Of the 20 specifications, only two have been submitted to any standards organisation for consideration. Critics charge that the others are being held back while the two companies work to perfect them and build them into their products, thereby giving them an advantage in the market.

"If you look at the pattern of behaviour that's been established by Microsoft and IBM, it's clear that they want to create specifications in a vacuum without input and hold them close to the vest while they develop them in their products and then release them to the standards organisations," says Ed Julson, group manager of Web services standards and technology for Sun.

"We've worked together with industry partners to be sure that the standards process starts with a well-defined proposal," responds IBM's Eisenstadt.

When Microsoft and IBM do offer up their specifications for input, critics say, it's usually behind closed doors rather than in the open forum of a standards meeting. Sonic's Chappell recalls being invited to Microsoft's headquarters in Redmond to view two Web services specifications. "IBM and Microsoft were being hammered for going off and doing their own thing," he says, "so this was viewed as a way of opening things up." But Chappell says he had to sign an agreement saying he would not discuss the specifications with anyone else and that anything he contributed to the development would become the intellectual property of the companies writing the specifications.

Microsoft's VanRoekel says his company does not require visiting vendors to sign nondisclosure agreements. "You're welcome to talk about what's going on," he says. But he says Microsoft does make them sign a feedback agreement that stipulates that "if you come and offer input on this technology, then that input must be made available royalty-free". He adds that Microsoft plans to publish results of vendor feedback sessions on a public Web site this fall.

Critics say Microsoft and IBM's strategy of writing specifications outside of the standards groups limits give-and-take. "It's turning into a proxy war where Microsoft and IBM are coming up with what they feel will be the standards and shopping them around to see who will rubber-stamp them," says an official from a standards group who requested anonymity. "If one won't take it, they take it to the other. They're playing W3C and Oasis off against each other."

Last January, another conflict broke out between the two vendor camps, this time within Oasis. After a coalition of vendors led by Sun, Oracle and Sonic submitted a specification to ensure reliable delivery of messages (called Web Services Reliability) and formed a committee, Microsoft and IBM published their own specification called WSReliability, which has not yet been submitted to any standards organisation.

Microsoft's VanRoekel says his company is simply following the road map it submitted to W3C. "The reason we take this approach is to make sure the specifications are well-engineered, have a fast time to market and have something we call composability, which means they work well with the other pieces out there," he says. "What has typically happened in the standards bodies where you design by committee is that the end product is so open for loosely interpreted implementation that you end up not having technology that will work with other pieces that have been developed out in the industry."