UDDI has not settled well in the enterprise, although it is over fours old. Every now and then, there is a new article or a blog post saying that UDDI is dead, or that UDDI has always been a
hype. Then there are those who say why UDDI is necessary for categorizing
services, and how
UDDI and SOA are going to change the enterprise world by way of UDDI’s
dynamic discovery capabilities. The truth lies somewhere in between.
The most common argument from UDDI proponents is that adoption of truly dynamic discovery and binding of web services is only a matter of time. As enterprises deploy more and more web services, the proponents argue, there will be more room for dynamic discovery and binding, and ultimately service consumers will be able to fully take advantage of UDDI. There are more web services in operation than there were two years ago. Yet, UDDI registries have not gained wider adoption in the industry. Is something wrong with UDDI? As I try to argue in this note, the problem does not lie with UDDI itself. Dynamic discovery and binding will not automatically gain wider adoption as enterprises deploy more web services! Web service interfaces and their implementations need to have certain characteristics to justify the role of UDDI in practice.
To be fair to UDDI proponents, there is some truth (at least in theory) to the arguments about the potential of UDDI in SOA. However, we need to take those arguments with a pinch (or a bag?) of salt because distributed software development and deployment is utterly complex. There are several moving parts that need to tuned to make software work as expected. In practice, as you try to extend the value of UDDI to the real world, you may find that things can not be achieved as advertised. This is precisely what gives ammunition to UDDI opponents.
Let us look at some the arguments made by UDDI proponents.
Argument: Big fat yellow/white/whatever pages
The yellow pages analogy of UDDI is true in theory, but hyped up in reality. It is true that you can publish and categorize web service interfaces and producers which can help help querying for services. Such a source may not be useful if it is only used for design time queries. Even more, there is no guarantee that this information is always kept accurate. Even if the information is accurate, you need to contact the source of (e.g. WSDL) the definition/implementation to check the supported operations, input and output types, and faults.
Argument: Source of standard web service interface definitions for common business processes
This is laudable goal, but except for the most abstract services, this is hard to achieve. This is due to the complexity of semantics involved in completely specifying a service such that implementations can interoperate fairly easily without human intervention. The only services that can meet this goal are those that have complete semantic specifications, and those that are governed by domain-specific standards bodies.
Argument: Publish, find, and dynamically bind
Dynamic binding is possible only by developing a Consumer a priori. You cannot bind a Consumer to an arbitrary Producer at runtime without writing code. Most web service integration requires human effort. Whenever human effort is involved, the value provided by UDDI will be limited to design time lookup.
Argument: Runtime indirection
Some have argued (and still argue) that UDDI can be used to build smart consumers that can dynamically discover the best available provider of the service, and that this is key to the success of SOA in enterprises. When the location of the service changes, the consumer will be redirected to the new location by finding the current location provided by UDDI lookup. However, to be able to dynamically choose a provider, you need identical providers. The service providers must be deployed in similar environments (security, network etc.) and offer similar quality of service.
Ideally, the consumer should not bother itself with finding the best available provider. This task should be left to an intermediary, such as a load-balancing proxy. More over, if your web services are stateful, dynamically changing the provider is risky and may not even work without establishing the same context for stateful interactions.
Argument: You need a UDDI registry for SOA
The argument is that you cannot understand the services in the enterprise without attaching metadata to those services in a location and transport independent manner. This is an interesting argument, but SOA is a style of runtime and deployment architecture that does not necessarily depend on UDDI.
So, when does UDDI make sense?
Are the semantics of web services completely defined and documented?
WSDL cannot completely describe the semantics of a web service. You can use UDDI categorization to add metadata to services, but that does not necessarily add more semantics to services either. You need other forms of specifications of web services to fully understand the semantics of a web service. UDDI service entries must include references to these other forms of specifications. In addition to input and output types, producers and consumers must agree on how to recover from faults predictably. You need software developers to understand the semantics of the service before designing the consumer.
Is there a sizable consumer population?
You need a good number of consumers to justify the effort of publishing and maintaining a UDDI registry.
Can your consumers plug-and-play with producers?
Can your consumer find a producer via UDDI, and with a few point-and-clicks be bound to the producer? This may be possible if your consumers and producers have been setup and verified to interoperate beforehand. For example, you may have to setup digital certificates so that the consumer can participate in an SSL handshake with the producer.
If a given set of web services meet these characteristics, they may be candidates for publishing in UDDI.
November 22, 2004 If you have read this far, please also read the excellent post Trust, contracts and UDDI at Loosely Coupled.
