Jeff says:

I’d love to see someone try to explain to me why UDDI isn’t a complete piece of shit. Justify it - I’m listening.

I believe when you consider setting up the registry part of an SOA — something I believe you’ll do sooner or later, at the latest when you have developed the first bunch of services — you need to decide which approach you want to take:

Chaotic, self-organizing using concepts such as full text search, more peer-to-peer than centrally organized

Highly structured, planned in advance, with explicit metadata relationships, based on categorization schemas designed up front

UDDI clearly is not a good match for option 1. If you want to do this, you’re clearly better off maybe using some XML database that supports REST-based XQuery/XPath interaction and maybe a full-text search. I’m not aware of any standard in this area yet. With option 2, you would be looking for something that defines how data is organized, how to associate metadata, how to define the structure of said metadata. I’m only aware of one standard specifically targeted at doing this in an SOA context, and that is UDDI. Surely you can build something of your own, and as usual it will likely match your requirements perfectly (if you are doing perfect requirements engineering and software development, that is). Of course you’d also lose all of the advantages associated with a standard - like available documentation, people skills, tools, existing definitions, different implementations to chose from, etc.

Still, I believe both options are fine given the appropriate circumstances. In an Internet scenario, I believe UDDI is not a good idea at all. The same is true for highly innovative, independent peers. You will probably go with the second option if you are trying to find a solution for a large organization such as a Fortune 500 company; and while I have a lot of things to criticize about UDDI as it is, I still believe it’s the best strategy for this option currently available.