34 Part I: The Web Services Architecture
provider, Web services offered, and bindings to the implementations. Each of these parts pro-
vides progressively more detailed information about the Web service.
The most general information describes the service provider. This information is not targeted
at Web services software, but at a developer or implementer that needs to contact someone
responsible for the service directly. Service provider information includes names, addresses,
contacts, and other administrative details. All UDDI entries have multiple elements for multi-
The list of available Web services is stored within a service provider entry. These services can
be organized, depending on their intended use; they can be grouped into application area,
geography, or any other scheme that is appropriate. Service information stored in a UDDI reg-
istry includes simply a description of the service and a pointer to the Web service implemen-
tations it contains. Links to services hosted by other providers, called Service Projections, can
also be registered.
The final part of a UDDI service provider entry is the binding to an implementation. This
binding associates the Web service entry to the exact URI(s) to identify where the service is
deployed, specifies the protocol to use for access, and contains references to the exact proto-
cols that are implemented.
These details are sufficient for a developer to write an application that invokes the Web ser-
vice. The detailed protocol definition is provided through a UDDI entity called a Type Model
(or tModel). In many cases, the tModel references a WSDL file describing the SOAP Web ser-
vice interface, but tModels are also flexible enough to describe almost any kind of resource.
For each provider or service registered in UDDI, additional metadata from standard taxono-
mies (such as NAICS [NAICS] and the older SIC industry codes [SIC]) or other identification
schemes (such as an Edgar Central Index Key) can be used to categorize the information and
improve search accuracy. The set of available taxonomies and identifier schemes is readily
extensible as a part of any implementation, so it can be customized to support any specific
geographic, industry, or corporate requirements.
Dynamic Web service discovery is provided in a different manner. As an alternative to storing
information in a known registry, dynamically discovered Web services explicitly announce
their arrival and departure from the network. WS-Discovery defines protocols to announce
and discover Web services through multicast messages.
When a Web service connects to a network, it announces its arrival by sending a Hello mes-
sage. In the simplest case, these announcements are sent across the network using multicast
protocols—we call this an ad hoc network. This approach also minimizes the need for polling
on the network. To limit the amount of network traffic and optimize the discovery process, a
system can include a Discovery Proxy. A Discovery Proxy replaces the need to send multicast