We've been covering Web services technologies for quite some time now, almost three years. In that time - I think it amounts to two eternities in Internet time - we've seen all sorts of interesting things occur. Cooperation, coopetition, even the creation of a group whose sole purpose is to make sure that the standards really are standard. (Quis custodiet ipsos custodies? That's Latin for "who's watching the WS-I?) But one of the more interesting developments, one that's really not been discussed greatly, is the number of "optional standards."

Yes, I know, that sounds like an oxymoron, like jumbo shrimp. But the reality of Web services is that it's made up of so many components that some just cry out to be used, while others are left out in the cold at many corporations.

The first candidate for the title of "Left Out 2004" would, of course, be the perennial favorite and Web services demon UDDI. Let's face it, the idea of a single public UDDI registry as an analog to DNS is deader than a doornail. And for good reason. This relegates whole sections of Web services books to the fireplace. Go to chapter 2, rip out all the UDDI pages, and use them for kindling. You'll sleep better at night - at least that night - because you'll be nice and warm. Now realistically, UDDI might be useful in certain circumstances. Certain limited circumstances. However, not enough that organizations who use other standards but ignore UDDI need to worry about saying they do "Web services". You do.

Truthfully, the standards bodies haven't helped matters any either. There are too many standards, at too granular a level, and too much competition. Need an example of how not to build an external interface? Just look at the standards on transaction and coordination. We need one, single standard, folks, not WS - Transaction and WS-Coordination and of course WS-I'll invent my own protocol and call it a standard. Half of these standards are "optional" or "future release" because no one can tell which one is going to gain acceptance. And frankly, I don't want to have to worry that the vendor that implements WS-Coordination also implements WS-Orchestration. They're all facets of the same problem - federating Web services to provide composite services, with transactional integrity. Note to OASIS and the W3C: "More standards - Bad. Consolidation - Good."

Adoption of other standards is sometimes a matter of scale. A single Web services implementation rarely requires full-on management, and if it's internal, it may not require extensive security either. Raise your hand if you want to group security under management anyway. See that? It's consolidation at work. Already we've condensed a whole group of standards.

But when an organization is up to its eyebrows in Web services, can't figure out where they are, or who's using them, or how to ensure quality of service, that's when these "optional standards" become critical. Critical mass requires a second set of Web services technologies - ones that ensure those simple Web services built on the "standard standards" work together in real world, complex situations.

This month, we're focusing on standards themselves, and examining two of the "optional standards" (UDDI and BPEL4WS) in some detail. UDDI, as you can tell, is one of my favorites. BPEL4WS, on the other hand, is something I think will be very useful, if we can get the vendors who proposed it to actually implement it in their products, instead of just talking about it in a future release. But in the meantime, we'll just have to build our Web services with the "Sort of Standards," and the "Proprietary Extensions." Enjoy.