This chapter is from the book
This chapter is from the book
This chapter is from the book
3.5 Discovery Services
The transport, description, and messaging layer are fundamental to allowing Web services to communicate in an interoperable way using messages. However, to facilitate this, it is necessary to collect and store the important metadata that describes these services. The metadata must be in a form that is discoverable and searchable by users who are looking for appropriate services they require to solve some particular business problem. Also, such metadata aggregation and discovery services are a useful repository/registry in which many different organizations might want to publish the services that they host, describe the interfaces to their services, and enable domain-specific taxonomies of services.
3.5.1 UDDI
The Universal Description and Discovery Interface (UDDI) is a widely acknowledged specification of a Web service registry. It defines a metadata aggregation service and specifies protocols for querying and updating a common repository of Web services information. Solutions developers can query UDDI repositories at well-known locations at design time to ascertain those services that might be compatible with their requirements. After they locate a directory, they can send a series of query requests against the registry to acquire detailed information about Web services (such as who provides them and where they are hosted) and bindings to the implementation. They can then feed this information into an assortment of development time tools to generate the appropriate runtime software and messages required to invoke the required service. Solutions can also query UDDI repositories dynamically at runtime. In this scenario, the software that needs to use a service is told at execution time the type of service or interface it requires. Then it searches a UDDI repository for a service that meets its functional requirements, or a well-known partner provides it. The software then uses this information to dynamically access the service.
UDDI repositories can be provided in one of three ways:
Public UDDI—These are UDDI repositories that can serve as a resource for Internet-based Web services. An example of this is the UDDI Business Registry [UBR]—hosted by a group of vendors led by IBM, Microsoft, and SAP—that is replicated across multiple hosting organizations.
Intra Enterprise UDDI—An enterprise has a private internal UDDI repository that provides much more control over which service descriptions are allowed to be placed there and used by application developers within that specific enterprise.
Inter Enterprise UDDI—This basically scopes the content of the UDDI to services that are shareable between specific business partners.
As discussed in Chapter 1, service discovery (publish/find) plays an important role in an SOA. You can achieve this in other ways, but within a Web services world, UDDI provides a highly functional and flexible standard approach to Web services discovery.
UDDI is covered in detail in Chapter 8, "UDDI."
3.5.2 MetaData Exchange
WS-Policy proposes a framework that extends the service description features that WSDL provides. Having more refined service descriptions, qualified by specific WS-policies, supports much more accurate discovery of services that are compatible with the business application that is to be deployed. In a service registry (such as a UDDI registry), queries of WS-Policy-decorated services enable the retrieval of services that support appropriate policies in addition to the required business interface. For example, a query might request all services that support the creditAuthorization WSDL interface (port type), use Kerberos for authentication, and have an explicitly stated privacy policy. This allows a service requester to select a service provider based on the quality of the interaction that delivers its business contracts.
Although service registries are important components of some Web services environments, it is often necessary to address the request of service information directly to the service itself. The WS-MetaDataExchange specification defines protocols that support the dynamic exchange of WS-Policy and other metadata that is relevant to the service interaction (such as XML Schema and WSDL descriptions) between interacting Web services endpoints. WS-MetadataExchange allows a service requester to ask a service provider directly for all or part of its metadata, without the involvement of a third-party registry. Using the WS-MetadataExchange protocol service, endpoints can exchange policies at runtime and use them to bootstrap their interaction from information about the settings and protocols to be applied. This is especially useful when not all policy information is in a repository or when a requester receives a reference to a service through some mechanism other than a direct query on a registry. This direct dynamic exchange of policies also supports the customization of each interaction based, for example, on the identity of the other endpoint or any other aspect of the context under which the interaction takes place. This flexibility allows Web services to be designed to offer different qualities of service for different targeted audiences.
WS-MetadataExchange is discussed in detail in Chapter 9, "Web Services Metadata Exchange."