Registry: Publication and Discovery of Service Descriptions

While the bottom three layers of the stack identify technologies for compliance and interoperability, the service publication and service discovery can be implemented with a range of solutions

Any action that makes a WSDL document available to a requestor, at any stage of the service requestor’s lifecycle, qualifies as service publication. The simplest, most static example is the service provider sending a WSDL document directly to a service requestor. This is called direct publication. E-mail is one vehicle for direct publish. Direct publish is useful for statically bound applications. Alternatively, the service provider may publish the WSDL document describing the service to a local WSDL registry, or to a private or public UDDI registry such as the UDDI Business Registry. The variety of service publication mechanisms is discussed in more detail in the section titled Service Publication.

Since a web service cannot be discovered if it has not been published, service discovery depends upon service publication. The variety of discovery mechanisms parallels the set of publication mechanisms. Any mechanism that allows the service requestor to gain access to the service description and make it available to the application at runtime qualifies as service discovery. The simplest, most static example of discovery is static discovery wherein the service requestor retrieves a WSDL document from a local file. This is usually the WSDL document obtained through a direct publish or the results of a previous find operation. Alternatively, the service may be discovered at design time or run time using a local WSDL registry, or a public or private UDDI registry. The variety of service discovery mechanisms is discussed in more detail in the section titled Service Discovery.

Service Publication

Producing Service Descriptions

The service description may be generated, hand coded, or pieced together based on existing service interface definitions etc. Developers may hand code the entire service description, including the UDDI entry. Tools exist to generate parts of the WSDL and potentially parts of the UDDI entry from metadata artifacts from the programming model and the deployment of the web service executable. Parts of the service description may already exist (for example the web service may be based on an industry standard service interface definition) such that very little needs to be further generated.

Publishing Service Descriptions

A service description can be published using a variety of mechanisms. These various mechanisms provide different capabilities depending on how dynamic the application using the service is intended to be. The service description may be published to multiple service registries using several different mechanisms. The simplest case is a direct publish. A direct publish means the service provider sends the service description directly to the service requestor. This can be accomplished using an e-mail attachment, an FTP site, or even a CDROM distribution. Direct publish can occur after two business partners have agreed on terms of doing e-business over the web, or after fees have been paid by the service requestor for access to the service. In this case the service requestor may maintain a local copy of the service description. Slightly more dynamic publication uses ADS [ADS 00] or DISCO [DISCO]. Both ADS and DISCO WSIL. WSIL defines a simple HTTP GET mechanism to retrieve web services descriptions from a given URL. An enhanced service description repository would provide a local cache of service descriptions, but with additional search capabilities. For service description repositories that span hosts within an enterprise, a service provider would publish to a private UDDI registry. There are several types of private UDDI registrys that may be used depending on the scope of the domain of web services published to it.

· Internal Enterprise Application UDDI registry: Web services for use within a company for internal enterprise applications integration should be published to a UDDI registry of this kind. The scope of this UDDI registry may be single application, departmental, or corporate. These UDDI registries sit behind the firewall and allow the service publishers more control over their service registry and its accessibility, availability, and publication requirements.

· Portal UDDI registry: Web services published by a company for external partners to find and use may use a portal UDDI registry. A portal UDDI registry runs in the service provider’s outside the firewall or in a DMZ between firewalls. This kind of private UDDI registry contains only those service descriptions that a company wishes to provide to service requestors from external partners. This allows companies to retain control of their service descriptions, access to the UDDI registry and quality of service for the UDDI registries. Moreover, by using the Role based visibility inherent in portals, the enterprise limits visibility of service descriptions to the partners authorized to see their existence.

· Partner Catalog UDDI registry: Web services to be used by a particular company can be published to a Partner Catalog (rolodex like) UDDI registry. A Partner Catalog UDDI registry sits behind the firewall. This kind of private UDDI registry contains only approved, tested, and valid web service descriptions from legitimate business partners. The business context and metadata for these web services can be targeted to the specific requestor.

· e-Marketplace UDDI registry: For web services that the service provider intends to compete for requestors' business with other web services, the service description should be published to an e-Marketplace UDDI registry or the UDDI Business Registry. E-Marketplace UDDI registries are hosted by an industry standards organization or consortium and contain service descriptions from businesses in a particular industry. These services may be required to support specific standards, searchable meta data, interfaces, or data types E-Marketplace UDDI registries will generally provide some filtering of illegitimate entries as well as some guaranteed qualities of service.

· UDDI Business Registry: Web services may also wish to publish to the UDDI Business Registry in some other public registry in order that they may be discovered by new potential business partners or service users. When publishing the UDDI Business Registry, complete business context and well thought out taxonomies are essential if the service is to be found be potential service requestors.

Figure 19 - Service Discovery Continuum

This figure shows the continuum from the most static, easiest technologies for publish and discovery to the most dynamic, more complex technologies. Users or implementers of web services may not follow this progression in strict sequence.

Service Discovery

Acquiring Service Descriptions

Like publishing web service descriptions, acquiring web service descriptions will vary depending on how the service description is published and how dynamic the web service application is meant to be. Service requestors will find web services during two different phases of an application lifecycle – design time and run time. At design time, service requestors will search for web service descriptions by the type of interface they support. At run time service requestors will search for a web service based on how they communicate or qualities of service advertised.

With the direct publish approach, the service requestor will cache the service description at design time for use at runtime. The service description may be statically represented in the program logic, stored in a file, or in a simple, local service description repository.

Service requestors can retrieve a service description at design time or runtime from a service description repository, a simple service registry or a UDDI registry. The look-up mechanism will need to support a query mechanism that provides find by type of interface (based on a WSDL template), the binding information (i.e. protocols), properties (such as QOS parameters), the types of intermediaries required, the taxonomy of the service, business information, etc.

The various types of UDDI registries have implications on the number of runtime binding web services can choose from, policy for choosing one among many, or the amount of pre screening that must be done by the requestor before invoking the service. Internal Enterprise Application UDDI registries and Partner Catalog UDDI registries will require no pre screening to establish trust of the service. Service selection can be based on binding support, historical performance, quality of service classification, proximity, or load balancing. E-Marketplace UDDI registries will have more runtime services to choose from. Some pre screening must be done to verify that the web service provider is a worthy partner and is not nefarious or inept. Choosing a service may be done based on price promises, cost, presence on approved partners list, as well as binding support, historical performance, quality of service classifications, and proximity. If service requestors query the UDDI Business Registry for web service providers, they will have to exercise the most caution and diligence when prescreening potential service providers. An efficient and accurate filter will have to be in place to return only suitable descriptions and potential business partners.

Consuming Service Descriptions

Once a service description is acquired, the service requestor will need to process it in order to invoke the service. The service requestor uses the service description to generate SOAP requests or programming language specific proxies to the web service. This generation can be done at design time or at runtime to format an invocation to the web service. Various tools can be used at design time or runtime to generate programming language bindings from WSDL documents. These bindings present an API to the application program and encapsulate the details of the XML messaging from the application.

Inspection

WSIL blah blah blah…

is a specification that defines a file at a well known location (URL) which contains a list of WSDL URLs and WSIL URLs in a domain. They may or may not be local to the system. WSIL documents can be used to enable a variety of discovery agent patterns:

1. local service discovery for ‘local’ web service applications (micro SOAs that don’t leave the box… all else is the same except it limits where it looks for services).

2. application integration

3. discovery agents populated by crawlers looking for WSIL documents

4. management topologies of available services (but its not a discovery source)

(this section needs more, but you get the idea)