The Advertisement and Discovery of Services (ADS) protocol for Web services

Directories for Web Services, that are accessible to both developers and applications, will become one of the central pieces of the future B2B infrastructure, in much the same way as business directories are critical pieces of today's economies. Emerging standards will provide universal access to these directories, while most businesses will be able to register their information with well-known directory service providers. The transition to this new infrastructure may have to take place at many different levels and at different times within an organization.

This article deals with the problem of how to effectively enable the emergence of B2B directories using existing Web infrastructure, and aims at outlining the path for a smooth transition from today's user-centric Web to a new business-enabled one. The starting point is thus the current HTML oriented Web, while the (moving) target is the future services directory infrastructure. The connection between the two is achieved using XML descriptions of service interfaces.

This document describes a simple mechanism by which a Web server can become a read-only directory advertising its own services, thus enabling B2B search engines to discover the services the Web server makes available. The proposed mechanism uses existing HTML pages to aid in the location of XML descriptions of business services. It introduces a basic HTTP discovery protocol, but architects an extension mechanism that uses Web Services Description Language (WSDL) documents to allow flexible integration with upcoming directory standards.

Describing services in ADS

ADS uses the service description architecture of WSDL for the various Web Services it advertises. The ADS specification supports the following three classes of services descriptions:

1. The description of a single service.
2. The description of a collection of services.
3. The description of a repository of services information.

Describing a single service

For a single service, the description is composed of two parts: a non-functional characteristics description and an access mechanism specification. The non-functional description is provided in a document defined according to the Well-Defined Services (WDS) specification (see Resources). It includes non-operational information directed mainly to human users or search engines. This information is variable by nature, but must at least include provider name and contact information, textual, and keyword based descriptions of the service, and service categorization. It must also provide a reference to a WSDL document including access information.

The access mechanism to a service is described by a WSDL document (see Resources). It provides all the information required to connect to the service, and includes an abstract interface definition, access protocol information, and service endpoints.

Describing multiple services

For a collection of services, the description provided is contained within a new type of document called a service description list. This new document type contains both links to a number of WDS documents, as well as pointers to other service description list documents, enabling the developer to create of a hierarchy of descriptions.

You can identify this aggregation document written in XML by its root element serviceListDef, qualified by the corresponding ADS namespace http://www.ibm.com/namespaces/ADS. Its children include a single description element which provides information about the set of services listed, and a variable number of serviceDef and serviceListDef elements.

The serviceDef elements are used to reference a WDS document and have a required serviceRef attribute containing the URL where the service description can be located. They may also have targetNamespace and name attributes that provide a unique qualified name of the service. The serviceListDef element includes a serviceListRef attribute containing the URL where another service description list document can be found. A simple schema for service description list documents is included in Listing 1.

 <xsd:schema targetnamespace="http://www.ibm.com/namespaces/ADS"
             xmlns:xsd="http://www.w3.org/1999/XMLSchema"
             xmlns:wsdl="http://www.ibm.com/namespaces/WSDL"
             xmlns:wds="http://www.ibm.com/namespaces/WDS"
             xmlns:ads="http://www.ibm.com/namespaces/ADS">
 
  <xsd:element name="serviceListDef" type="serviceListDefType"/>
 
  <xsd:complexType name="serviceListDefType">
    <xsd:element name="description" type="xsd:string"/>
    <xsd:choice maxOccurs="unbounded">
      <xsd:element name="ads:serviceDef" type="serviceRefType"/>
      <xsd:element name="ads:serviceListDef"
                   type="serviceListRefType"/>
    </xsd:choice>
  </xsd:complexType>
 
  <xsd:complexType name="serviceRefType">
    <xsd:attribute name="targetNamespace"
                   type="xsd:uriReference" minOccurs="0"/>
    <xsd:attribute name="name" type="xsd:string" minOccurs="0"/>
    <xsd:attribute name="serviceRef" type="xsd:uriReference"/>
  </xsd:complexType>
 
  <xsd:complexType name="serviceListRefType">
    <xsd:attribute name="serviceListRef"
                   type="xsd:"uriReference"/>
  </xsd:complexType>
 
 </xsd:schema>

A service repository for describing services

The third type of service description, the description of a repository, is based upon the use of a WSDL document to describe the access mechanism that should be used to retrieve the contents of a services directory. The WSDL document represents an agreed upon interface for communication with the repository. For example, the WSDL document could describe how to access a Lightweight Directory Access Protocol (LDAP) based directory that contains information about a set of services. Because the WSDL document is simply a description of an access mechanism, it provides a point of continuing extensibility for this architecture that enables the use of richer access interfaces as they become available.

Back to top

Advertising services

ADS is comparable to other discovery mechanisms proposed by Microsoft in their DISCO specification, and CommerceNet in their eCo Framework, in that they all offer means to advertise locations of service descriptions. The ADS method utilizes the Well-Defined Service description documents described earlier. In addition, ADS supports two mechanisms that allow service providers to announce the availability of service descriptions. This can be done through:

1. The creation of a svcsadvt.xml file placed in the root directory of the server.
2. The use of a meta tag carrying the value serviceDescriptionLocation in its name attribute that can be included on any HTML page of a given host.

Service providers can create a file named svcsadvt.xml in the root directory of their server in order to advertise their offerings. The contents of this file can be a WDS document describing a single service, a service description list document describing a set of services, or a WSDL document describing the information necessary to contact a services repository. The use of a svcsadvt.xml file provides a consistent location for discovery tools to examine when searching for services.

The second method to advertise services is through the use of meta tag carrying the value serviceDescriptionLocation in its name attribute on an HTML page. Typically, one would include this tag on highly visible pages, like the root document of the server. The corresponding content attribute must have a valid URL indicating the location of the document listing the service descriptions for that business. Like the contents of the svcsadvt.xml file, the referenced document may either be a single WDS document, a service description list document, or a WSDL document containing information about the access mechanism for a services repository. In each of these cases, an HTTP GET request against this URL should return the desired information.

Note that it is possible to encode multiple meta tags within a single document, as in Listing 2.

 <meta name="serviceDescriptionLocation"
       content="http://www.getquote.com/quote.wds"/>
 <meta name="serviceDescriptionLocation"
       content="http://www.getquote.com/services-wsdl"/>

This way a search engine can choose the most appropriate access interface according to its capabilities.

Back to top

Usage scenarios of different advertisement mechanisms

The different advertisement mechanisms can apply to different scenarios. For example, a consumer of services information, such as a portal, may make use of both advertisement mechanisms. The svcsadvt.xml file provides a consistent starting point for performing a search for services provided by a site, while the second mechanism may be used during the standard indexing of web pages, allowing for the categorization of services based upon contextual information.

An offerer of services, such as a small business, may also utilize both mechanisms. The svcsadvt.xml provides a means by which a business can provide access to an aggregation of the information about the services that it provides. The second method, the reference of a services description from within an HTML document, can be used to advertise available services when a customer comes to visit the providers site. The visiting party does not need to examine any other locations to learn about services which may be available; instead, the party can extract that information directly from the given page.

Back to top

Discovery services

Assuming that services have been advertised using the methods described above, applications can then be developed to utilize the new information. Two main discovery patterns are likely to arise from the availability of services advertisements: discovery through crawling and discovery through context.

Discovery through crawling follows the same approach that many search indices use today to gather information. Seeded with one or more starting points, the algorithm follows links present within the information until it reaches some predefined ending points, with interesting information being recorded along the traversal. An algorithm for a simple crawling engine for locating advertisements is shown in Listing 3.

For each starting URL:
   Store the URL in a queue if it isn't already there
   Store the URL corresponding to the svcsadvt.xml file for the
     location that is referenced by the starting point URL
 
 Repeat until the queue is empty:

   Pop a URL off of the queue
   Load the data specified by the URL
   If the data is an XML file, see if we can recognize it as a WSDL or
     WDS file and do the appropriate thing
   If the data is an HTML file, process the HTML file as follows:
     If we find meta tags with the desired name attribute, process the
       referenced document
     If we find links, add them to the queue if they are not already
       there.  Then, take the host portion of the link and create a URL
       that looks for a svcsadvt.xml file in the root of the server
       referenced in the link.  If that new URL has not previously been
       placed onto the queue, do so now.

When a user visits an HTML page containing an advertisement via the meta tag, they are performing the discovery-through-context process. The context, in which the link appears, can provide information about the referenced service in addition to what may be contained within its description. This mechanism allows content providers to directly couple available services with the provided content. For example, a Web page selling flowers may offer a service to allow for a purchase order to be submitted through some type of electronic interchange. The service may be advertised directly from this Web page, in which case not only can contextual information about the service be gathered, such as the fact that it has something to do with a business that sells flowers, but in addition, a smart browser may be able to modify its interface to allow for the user to interact with the offered service.

Back to top

UDDI and future directions

The mechanisms in this proposal are complementary to what can be found in the Universal Description Discovery and Integration (UDDI) specification. While UDDI provides for a fixed entry point for the discovery/location of a wide range of services, its responses are constrained by the information which has been registered in the directory. For those services whose presence has not been announced to the directories, for any number of reasons, the ADS mechanism provides a means by which their existence can be discovered and their functionality utilized. It is easy to see how one possible use of ADS may be to populate a UDDI directory, although further work needs to be done before that task is made easy. In addition, ADS provides for a means by which services and content can be tightly coupled by the content provider, whereas UDDI requires that a consumer actively search for a service.

One possible migration path to more tightly couple the ADS mechanisms and the UDDI directories is for them both to utilize a common description format. A single document, constrained by the UDDI schema, could perhaps be used to replace the current WDS and service description list documents which are referenced by ADS, without requiring a change of the discovery mechanism.

Resources

• Refer to The Well Defined Services (WDS) Specification which is part of Web Services Toolkit.
  
  
• Read The Web Services Description Language (WSDL) specification.
  
  
• IBM, Microsoft, and Ariba, all contributed to the Universal Description Discovery and Integration (UDDI) white paper, which provides a strong basis for understanding Web services.
  
  

About the authors

Comments

Back to top

Trademarks

Table of contents

• Describing services in ADS
• Advertising services
• Usage scenarios of different advertisement mechanisms
• Discovery services
• UDDI and future directions
• Resources
• About the authors
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

My developerWorks community

Dig deeper into SOA and Web services on developerWorks

We want to know you!

Update your My developerWorks profile and start connecting with others