Once you’ve created Web services, they’ll be available for use by developers. But you still have to provide a way for your developers to identify the services that exist. This process is called discovery. Through discovery, developers will be able to view the Web services and their available methods. Discovery makes use of a standard XML-formatted document that identifies which Web services are available and how the server should detect those services. There are two types of discovery: static and dynamic. This section describes both types of discovery—how to advertise the existence of your Web service to other developers—and the language that’s used to describe Web services.
Static discovery is used when a static discovery file exists. The file holds details about the services available on a site and has an extension of .disco. The static discovery file is an XML-formatted file that provides links to individual .disco files or to the services themselves. The root node of the document is <discovery>. The file contains <contractRef> or <discoveryRef> tags that hold the pertinent information about each service, as shown in the following code:
<?xml version="1.0"?> <discovery xmlns="http://schemas.xmlsoap.org/disco/"> <contractRef ref="myprofile.wsdl" xmlns="http://schemas.xmlsoap.org/disco/scl/"/> <contractRef ref="myservices.wsdl" xmlns="http://schemas.xmlsoap.org/disco/scl/"/> </discovery>
The <contractRef> tag is used to specify a URL that will return the Web Services Description Language (WSDL) information for your Web service. (The section “Understanding WSDL,” later in this chapter, provides additional information about WSDL.) You can use <discoveryRef> tags to identify the location of other discovery files.
Alternatively, you can use dynamic discovery to enable ASP.NET to dynamically detect the Web services on your site. This is done by providing a dynamic discovery file, which has the extension .vsdisco in the virtual directory with your Web services. The root node of the document will be <dynamicDiscovery>. The document can contain tags that will be used to exclude paths from the search for Web services, as illustrated in the example below.
<?xml version="1.0" encoding="utf-8" ?> <dynamicDiscovery xmlns="urn:schemas-dynamicdiscovery:disco.2000-03-17"> <exclude path="_vti_cnf" /> <exclude path="_vti_pvt" /> <exclude path="_vti_log" /> <exclude path="_vti_script" /> <exclude path="_vti_txt" /> <exclude path="Web References" /> </dynamicDiscovery>
Although the static and dynamic discovery pages provide information about the existing Web services on your site, they do little to advertise their existence to other developers. How will developers make use of your services if they don’t know the services exist? If you want to make your Web services available to others, you can advertise them using the Universal Description, Discovery, and Integration (UDDI) services.
The UDDI specification defines a standard for publishing and discovering information about Web services. UDDI sites are Web services on which you can register your own Web services and search for other Web services. These directories can include the following four types of information about the services:
Information about specifications for services
This information can be accessed programmatically and can be used to generate the proxy stubs that provide local references for your projects.
Microsoft and IBM jointly developed WSDL to provide a standard way of documenting the messages that a Web service will send and receive. These messages define the methods and outputs of the Web services. These methods are known as the contract that’s offered by the service. The contract specifies the message schemas that will be accepted and returned from the service.