DISCO answers the questions "How will people find my Web Service". DISCO was created as an attempt to solidify the process by which consumers of a Web Service locate and programmatically interrogate services at a given URL.
VisualStudio.NET handles creating and managing DISCO and dynamic discovery documents for your applications and server. The IDE automatically adds a .vdisco file for each ASP.NET application that you create.
Discovery is the process of locating a Web Service and interrogating it. After the discovery process is complete, a consumer of the Web Service knows its exact location (URI), capabilities, and how to interface with it. Discovery typically starts with a .vdisco file which is an XML document that contains links to other resources that describe the Web Service. The DISCO file typically points to a WSDL source that in turn points to the actual Web Service:
Note that DISCO documents are optional. In you have a private Web Service intended for a small number of potential clients, you do not have to publish a DISCO document on your Web Server. Not having a DISCO document is one way to prevent unwanted customers from using your Web Service. DISCO is more appropriate when you want to share your Web Service with a large audience and want the world to find it simply by navigating to your Web site's home page.
Note also that any HTML Web page can include a tag that points to a DISCO file. For example, you could include the following HTML code at the top of each page in your Web site:
<head>
<link type="text/xml" rel="alternate" href="default.vdisco"
/>
</head>
This link alerts DISCO client applications that the DISCO file resides elsewhere on the Web server. This does not happen magically - the DISCO client like the Add Web Reference command in VisualStudio.NET, must know how to look for this tag and take the appropriate action based on the href attribute.
DISCO is a specification that seeks to facilitate a programmatic method for finding Web Services. Note that discovery documents can point to other discovery documents as well as WSDL files or other descriptive documents. There are two parts to the specification: the discovery algorithm and the format of a DISCO document
In an effort to standardize the process of locating a discovery document on a Web server, the specification have created a pseudo-code outline to guide developers of client applications that might need to support this functionality. Based on the HTTP Content-Type of a given URI and the actual content of the document at the URI endpoint, the discovery algorithm indicates whether the document contains a DISCO document, point to a DISCO document, or does not contain a DISCO document.
The following is an example of a DISCO document
<?xml version="1.0" ?>
<discovery xmlns="http://schemas.xmlsoap.org/disco/">
<contractRef ref="http://www.diranieh.com/Service1.asmx?wsdl"
docRef="http://www.diranieh.com/Service1.asmx"
xmlns ="http://schemas.xmlsoap.org/disco/scl/" />
<disco:discoveryRef ref="member\default.vdisco" />
</discovery.
This sample document points to two resources:
A DISCO document usually refers to four different types of items. Each of these appears between the <discovery> and </discovery> elements:
Dynamic discovery documents enable potential customers to discover all the Web Services on your Web server with little or no effort on your part. When the dynamic discovery document is requested, the .NET Framework looks through the subdirectories underneath the root Web and finds all the Web Services. This feature could be a huge convenience: You do not have to create a discovery document for each Web Service you publish on your Web server - just allow dynamic discovery to do it automatically for you.
The following is an example of a dynamic discovery document from the root Web on my local server:
<?xml version="1.0" ?>
<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>
This document was generated automatically, and each project created using VisualStudio.NET will have a similar .vdisco file. The only condition is that the Web server must have the .NET Framework installed on it. If you're not using VisualStudio.NET, you will have to create this document by hand.
The dynamic discovery document can be used in several ways, depending on your objectives. The default approach used by VisualStudio.NET is to create the dynamic discovery document and place it in the root Web of the Web site. Then, create dynamic discovery documents in each of the subdirectories that have Web Services. This method allows your potential customers to start the discovery process at the root Web on in a sub-directory. This is the most flexible way for potential consumers to find the Web Services they're looking for, but could permit too much access if you do not want to allow users to see all the Web Services on the server. If you want less exposure of your Web Services, you can simply remove discovery documents at the root of the Web server, or modify the discovery document to exclude certain Web Services from being made available by using the <exclude> element. This technique is often referred to as security via obscurity.
The best example of how a DISCO file is used by client applications is the Add Web Reference command in VisualStudio.NET. By using this command, the developer types a URI to see all the Web Services available.
After a Web Service of a DISCO document has been located, the Add Web Reference command requests the WSDL document. From the WSDL, a proxy class is generated, and the developer can communicate with the Web Service via the proxy. However, the DISCO document is instrumental in helping developers actually find the Web Service they are looking for.