A few years ago, when Web services started out as a buzzword in the enterprise, the whole paradigm was associated with (and still is) associated with three concepts - SOAP, WSDL, and UDDI. Now, when enterprises are putting Web services into production, you will most likely see two out of the three stakes being driven into the ground, but I have yet to see any real adoption of the "dynamic" part of any Web services implementation. Web services are taking root as a very feasible platform for achieving service orientation (not the only platform, mind you), but none of the clients that I have interacted with have any plan to adopt a UDDI-based service registry in the near or long term.

W3C defines a Web service as "a software system identified by a URI, whose public interfaces and bindings are defined and described using XML. Its definition can be discovered by other software systems. These systems may then interact with the Web service in a manner prescribed in its definition using XML-based messages conveyed over Internet protocols." Ironically, the definition does not mention WSDL as the mandated standard for defining and describing the Web service, SOAP as the XML-based message format, or UDDI as the means of "discovering the definition." The only things mandated by the definition is the usage of XML. However, as we know, the standard Web Services Architecture specification assumes SOA, WSDL, and UDDI. The definition and protocol aspects are definitely standardized and being deployed in enterprise applications. However, the discovery aspect still remains a pie in the sky as far as its actual application in the enterprise is concerned.

Web services is a platform for achieving SOA. In order to have reusable services, a component/service repository is a very valuable artifact. However, a public repository that can be used by multiple parties to locate universally available services across distributed locations is still a bit of an overkill in the industry today. UDDI is not necessary for categorizing services. Dynamic discovery and binding are very interesting concepts, until they are actually applied to the way businesses today, and in the foreseeable future, will interact with other businesses.

While the conceptualization, development, deployment, and maintenance of ubiquitous yellow pages is inherently complex, I don't think that is the crux of the problem. The bottom line is that you actually need a viable business model to apply the technology too. Think of our evolution from RPC to CORBA, to RMI (in Java) to Web services. Dynamic invocation has always had the "coolness" factor to it, but has never really found a home in prevalent business models. A few years back when all of us were drinking the Kool-Aid and dreaming about public marketplaces where participants of all levels could participate in a transaction, the whole concept of multi-party, multi-transactional architectures didn't really take off. This was not a failing in technology. It was a failing in the application of viable technology to a non-existent business model. How could parties conducting serious trade put their trust in companies who were here today, but may be gone tomorrow?

UDDI seems to in a similar situation. We have a long way to go before transactions, based on a random search, can be conducted without a formally established trust relationship between two parties. In the end, transactions are conducted between a consumer and a supplier, and these two parties establish relationships well in advance before exchanging goods.

On a different note, if you are a looking for a good book that discusses Web services from several perspectives, check out Perspectives on Web Services by Zimmerman, Tomlinson, and Peuser. A review is available on my blog http://ajitsagar.javadevelopersjournal.com.