Section 8.1. Role of UDDI in SOA and the WS Stack

8.1. Role of UDDI in SOA and the WS Stack

One of the main benefits of a SOA is the ability to reuse services through the process of "service composition," the process in which existing services are assembled to create new services and applications. To realize this benefit, designers and developers need to know what existing services are available and how to interact with them. UDDI has an important role to play in providing a single well-known place that can be searched for services and provide pointers to more detailed information about the services, including the WSDL description of the service if one exists.

A second benefit is the ability to dynamically select an implementation of a service at runtime. Either the application or the infrastructure that is hosting it can perform this selection. UDDI also enables service providers to publish their service implementations, and service users to find the one that provides the best match with their requirements.

These two roles of the UDDI registry are described in the following sections.

8.1.1. Use of UDDI During Design and Development

In a typical development-time use case of UDDI, a developer will require a specific service, such as a service that supports renting a car, when building a new application. To find this service, the developer would send to the UDDI registry a query for all service providers (instances of "businessEntity," which we describe later in this chapter) that are categorized as supporting the car rental function. The categorization can use a well-known category system, such as UNSPSC, a proprietary category system, or a combination of both. After the developer obtains the list of providers, she can choose to issue further queries to find out more details about those that interest her, in particular, the actual services they provide. Having selected a provider and a particular service, the developer can then use the pointers in the UDDI data structures to find additional details about the service, including the WSDL description for the service if that is appropriate. She can then use development tools to generate the code artifacts necessary to invoke the service.

8.1.2. Use of UDDI at Runtime

UDDI has always been intended for use at runtime, not only during design and development. Runtime usage is referred to as the invocation pattern in the UDDI specifications.

One of the key attributes of an SOA is the ability to dynamically bind to a service, and UDDI is a key component in enabling this behavior. Rather than bind a client to a particular implementation of a service at a particular location, one can use UDDI to find an implementation of a service at runtime and then retrieve the location of the service to configure the client dynamically.