More on UDDI. [...] OK, UDDI-as-the-yellow-pages I'll buy, but this idea of "give me the WSDLs for those services" implies that I'm going to dynamically invoke a web service, meaning now essentially you're tying me into a loose-binding situation similar to writing Java or .NET Reflection code. Quite frankly, I don't buy this argument whatsoever--I *need* to have some idea of the service I'm trying to invoke, otherwise, how can I know what to pass where? I recognize this idea of "dynamic glue" is an attractive one, allowing me to walk up to any web service at runtime and consume it without any a priori knowledge whatsoever, but this is akin to suggesting that I can write a generic Java user interface that can gather any sort of data from the user without any sort of a priori knowledge whatsoever, driven by an XML file--you can do it, but boy will the UI suck. I'm still not convinced that UDDI is worth saving from the cliff; essentially we're talking about a naming/directory server (remember I can always attach attributes to an entry in an LDAP-like environment), coupled with dynamic binding at runtime of the endpoints. I still don't see the value here. [The Mountain of Worthless Information]

Get over RPC. Think messages. Get over coding and programming models. Think data.  

When you have a choice of three different services to call -- I will stick with my previous example -- one at UPS, one at FedEx and one at Deutsche Post, you will always know what data you have to give them and you know what you want from them. The challenge is to find those services by meaningful criteria and to map from your internal representation of data to their representation and back. Precisely, it's about mapping their idea of representing well-understood and agreed semantics into your representation of the same semantics. The global UDDI space (public registries) is the place where you can locate those services in general, the local UDDI space (enterprise registry) is where you can augment this information with your own metadata and mapping information.

All of this and Web services in general are not about taking someone's WSDL, code-generating a proxy and calling that proxy via reflection. That's RPC or Automation. That's last century's technology. That's old programming. The center of programming is shifting towards messaging. Enjoy.