In June I attended the JavaOne conference out in San Francisco, to keep up with what the Java world was doing, and to see how it impacted Web services. I see a number of parallels between Web services and the way that the various Java specifications have been created, and some key differences. But even further, I went to a number of sessions on Web services and was reminded, once again, that the lack of a single standards body is a serious roadblock to implementation of Web services.

Now, of course I'm not talking just about UDDI, WSDL, SOAP, and XML. These are pretty much okay for implementation, but when you have to have an entire standards organization such as the WS-I, whose only purpose is to make sure that Web services implementations interoperate, there's something wrong.

Not that I have anything against the WS-I, mind you - they're doing very necessary work. But it's only necessary because the standards stink. That's right. They stink. If my SOAP stack doesn't work with your SOAP stack (sounds like a bad prison movie) there's just something fundamentally flawed in how the specification was created. And there are plenty of those stories out there.

But I was further reminded of the mess we're in by some of the Web services presentations. While obviously biased toward Java (it was JavaOne, after all), what really got me was the way everyone needed to explain how this specification came from HP, that standard was developed by W3C, and OASIS has a competing specification to some other specification. It's clear that there are too many bodies producing standards, not to mention too many standards themselves.

The Java model works somewhat better, with a single standards organization and the JSR process. Rather than develop competing specifications (SAML or WS-Security, for example), the JCP provides guidance from multiple companies toward the creation of a single standard that all Java vendors will comply with. No one has to decide whether to use BPML or BPEL, or the Java equivalent.

Not that the model isn't without its flaws as well. I was speaking with several board members of the WS-I recently and in their view multiple standards are good, in that they are a sign of intense interest and usually of innovation.

And that's good to a point. That point being the place where people are paralyzed by confusion over which standard to use, what product to buy, and how to manage the process. The Java concept of a single standards body was an acknowledgement by Sun that to grow Java widely, they needed to give up a great deal of control to other organizations who would also profit from participation. The ingenious aspect of the development of Java was that the control was released gradually, and the single body retained all control over the platform.

For us, I fear that the cat is already out of the bag. With two major standards-making bodies, one standards integration body, and vendor companies with multiple divisions backing different horses, we're never going to get to the same level of cooperation as the JCP.

Instead, I would propose that WS-I become the central Web services body, and that the members of the other bodies treat them as the Supreme Court of Web services. Once they rule on a specification, let there be no further disputes. Let's limit the number of specifications so the innovations can go toward making a smaller set of standards better.

Of course the WS-I may not want to act as the final arbiter of Web services fate, and for various reasons, many vendors may not want the WS-I as currently constituted to be the sole determining body for Web services. That's fair. I suppose we can always create yet another body to do the task. We'll probably need a few more standards as well, just in case.