X
Innovation

"Men in Black" still dominate standards?

Lately, there's been a lot of heat generated in the blogosphere about the convoluted way many Web services standards have been coming together, which some snidely refer to as "WS-Complexity." The problem, according to many, is that many of these standards have historically come from the "Men in Black" (MIB -- Microsoft, IBM, BEA Systems).
Written by Joe McKendrick, Contributing Writer
Lately, there's been a lot of heat generated in the blogosphere about the convoluted way many Web services standards have been coming together, which some snidely refer to as "WS-Complexity." The problem, according to many, is that many of these standards have historically come from the "Men in Black" (MIB -- Microsoft, IBM, BEA Systems). Steve Vinoski, chief engineer of product innovation for IONA Technologies, now takes the Web services industry to task for unleashing a bewildering cloud of incompatible standards on the world.

In a previous post, I relayed the results of a study of Web services development shops that found that, beyond XML and SOAP, an overwhelming majority were unfamiliar with the bevy of WS standards now in various stages of approval or release.

Vinoski cuts right to the chase: "The specifications (collectively known as WS-) are numerous and daunting. A coalition of developers and architects from BEA Systems, IBM, and Microsoft authored most of them, though different specifications also include contributions from several other smaller companies. Because the same author companies didnt write all the specifications, at least two different lists exist. Examples of various specs include WS-Addressing, WS-Attachments, WS-BusinessActivity, WS-Coordination, and so on.

Vinoski advocates more end-user and less vendor involvement in standards development. "When a vendor writes a standard, the product that the vendor eventually wants to build and sell is often what becomes standardized. Sometimes, they even wait to build such products until the standardization is nearly complete, to avoid wasting effort building something that will get changed during standardization. The end result can be standards that are full of holes and ambiguities due to the lack of actual implementation experience."



Editorial standards