Today, most Web services are discovered through non-programmatic means using manual, human intervention. Similar to the way companies scrutinize potential partner companies prior to committing to a strategic relationship, selecting services to use within enterprise applications requires significant due diligence. Manual intervention by business analysts, consultants, and others familiar with the company's business and strategic needs will almost always be required for selecting services. The most common sources of locating Web services are existing business partners, UBR home pages, service aggregators such as XMethods, or standard Web search engines such as Google.
The UDDI Business Registry (UBR) is a distributed, public registry containing thousands of service providers and even more services. Sifting through this large (and constantly growing) list to weed out useful providers and services from those that are less than useful (or completely useless) is the biggest drawback and the major difficulty of using such public resources.
Enterprise UDDIs and other such private (or semi-private) UDDIs that support and facilitate easy access to Web services and other resources within an organization will provide direct value. Typical use cases for UDDI within organizations will be to support and manage reuse of programmatic resources throughout an extended enterprise, as well as to dynamically configure and customize an application by changing attributes within the UDDI.
Using client-side API packages such as UDDI4J and Microsoft's UDDI SDK facilitate developing programs that access UDDI registries, and also insulate applications from specification changes and differences between various registries.
UDDI plays a critical and potentially larger role during the run time of applications. Typically, UDDI is seen as a means of discovering services at design time. UDDI also provides a convenient means to manage the lifecycle of Web services as well as the applications that consume them. Changes to information about a Web service can be pushed onto an UDDI registry, and applications that consume that service can be developed to be more reliable and robust by simply querying the UDDI registry for changes upon any invocation failures or other unexpected behavior.