Addressing a service presents a few problems. By putting the URL (or queue name if using messaging), you unintentionally couple between the service consumer and the physical instance of the service. (Meaning what server it’s on, IP address, etc.)
Applications often unintentionally become tightly coupled simply by addressing connections directly, by IP address, server name, or queue name. This is unacceptable, as any change in the physical layer results in software changes. (Hardcoding such information is clearly a major mistake, but even placing it in a configuration file or database entry still results in application manipulation due to physical layer changes.)
Replace a server, redeploy all consumers of the services exposed on that server? Ouch. Even moving from development to test to production becomes a challenge (as you have to recompile or reconfigure as the consumer needs to repoint to the new provider instance in each environment).
UDDI was originally created as a runtime service lookup to decouple the logical use from the physical implementation. Since service addressing must use outside facilities to allow adjusting addresses without touching the service, whether from the consumer/request or within the integration bus. UDDI fits the bill.
(Some IT shops try to get off easy by using just DNS to solve this problem. This can be helpful in a single environment, such as the replacement of a production server. But not for redirection between environments.)
However, some vendors have expanded basic UDDI systems into something much larger – basically expanding into Design Time Governance “registry and repository” capabilities…
Every organization using services should (but doesn’t have to) implement a UDDI. The extended capabilities that have been loaded into many UDDI products often confuse the issue.
Example – IBM’s Websphere Registry and Repository started as a good production quality UDDI and was initially extended to handle MQ as well (handling queue addresses in addition to URL’s). But then it was extended with a partial set of design time governance features, confusing the issue if I need a UDDI and have other design time governance tools.
In at least one conversation I’ve had with a vendor they had a hard time understanding what I meant by “runtime UDDI”, being focused on design time repository abilities. UDDI’s become rather divorced from it’s original and primary functionality.