Web Services Architecture and Its Specifications: Essentials for Understanding WS-*

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-

language descriptions.

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 Discovery

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