Despite the fact that I have a toolbox full of tools, I'm not a mechanic. I have wrenches and sockets in all sizes and shapes, and because I'm not inherently tidy, they tend to get all mixed up in the toolbox as I use them. So as you may expect, when it comes time to tighten a bolt, I have to go rummaging around in the toolbox, trying to find the right socket to use.

What makes matters more painful for me is the fact that sometime in the past two different standards of measurement were implemented for sockets. There is English measurement, which is based on increments of the Inch, and Metric, which naturally is based on the Meter. The problem is that there is usually no indicator on the bolt as to what size it is, or which unit of measure, and therefore system of sockets, is to be used. Invariably, I end up nearly stripping the bolt head before I realize that it's the wrong unit and finally find the right socket to use.

Sometimes the only thing worse than no standard is more than one.

We're back to the issue of standards within WSJ. Once again we will examine the state of Web services as they relate to the standards, which have been proposed, ratified, and implemented.

To start with, we can be happy that the basic standards of Web services are alive, well, and relatively clear of competitors. If all you need is basic connectivity, you can easily do meaningful work using just SOAP, XML, WSDL, and UDDI. UDDI Version 3.0 has recently been ratified, adding some significant features to the basic Web services registry, such as support for public and private registries. At the same time, some of the features of UDDI overlap with WSDL, and it's still not clear that UDDI is absolutely necessary for anything. Searching for a service may be technically interesting, but in most cases it's not part of the actual business implementation. Within organizations services move rarely, if at all, so the need to dynamically locate a service is usually not an imperative business requirement. The overlap is like having two sets of sockets, some of which are nearly the same sizes and in a pinch could be made to serve. Still, it's easier to just use the right one.

Even SOAP is not immune to competition, although it seems to be the predominant standard. REST is another standard that purports to be better than SOAP, depending upon which pundit you read. Again they do much of the same, in slightly different ways, making it harder and harder to decide on the standards of even the basics of Web services.

The challenge that all of these competing, nearly equivalent standards present is that they in fact reduce a standard to something less concrete. Where you could expect a single standard to be the only way the overwhelming majority of people do things (there is always someone who just won't go the same way as everyone else), when multiple standards exist, that uniformity that adds value for this particular set of software is diluted.

The biggest benefit of Web services is that they are implemented by almost every platform and software vendor. Early on the WS-I was formed when it was recognized that even with the single standards that were out, not every implementation really got it right. That's why the WS-I is so valuable; it makes interoperability more likely.

It's also why every new competing standard reduces the usefulness of the standard with which it competes.

My toolbox needs organizing - I'm a software architect, not a mechanic or carpenter. My real working tools are software and standards. While I can live with my toolbox at home being a little unorganized, I can't say the same about my working tools. I need them to be clear, simple, easy to use, and unambiguous. And so do you.