AddThis Social Bookmark Button

Print

.NET Framework Essentials, 2nd Ed.: Web Services, Part 1
Pages: 1, 2, 3

Web Services Discovery

Even though advertising of a Web Service is important, it is optional. Web services can be private as well as public. Depending on the business model, some business-to-business (B2B) services would not normally be advertised publicly. Instead, the Web Service owners would provide specific instructions on accessing and using their service only to the business partner.



To advertise Web Services publicly, authors post discovery files on the Internet. Potential Web Services clients can browse to these files for information about how to use the Web Services--the WSDL. Think of it as the yellow pages for the Web Service. All it does is point you to where the actual Web Services reside and to the description of those Web Services.

The process of looking up a service and checking out the service description is called Web Service discovery. There are two ways of advertising the service: static and dynamic. In both of these, XML conveys the locations of Web Services.

Static discovery

Static discovery is easier to understand because it is explicit in nature. If you want to advertise your Web Service, you must explicitly create the .disco discovery file and point it to the WSDL.[2] All .disco files contain a root element discovery as shown in the following code sample. Note that discovery is in the namespace http://schemas.xmlsoap.org/disco/, which is referred to as disco in this sample.

<?xml version="1.0" ?>
<disco:discovery xmlns:disco="http://schemas.xmlsoap.org/disco/">
</disco:discovery>

Inside the discovery element, there can be one or more of contractRef or discoveryRef elements. Both of these elements are described in the namespace http://schemas.xmlsoap.org/disco/scl/. The contractRef tag is used to reference an actual Web Service URL that would return the WSDL or the description of the actual Web Service contract. The discoveryRef tag, on the other hand, references another discovery document.

This XML document contains a link to one Web Service and a link to another discovery document:


<?xml version="1.0" ?>
<disco:discovery 
       xmlns:disco="http://schemas.xmlsoap.org/disco/"
       xmlns:scl="http://schemas.xmlsoap.org/disco/scl/">
<scl:contractRef ref="http://yourWebServer/yourWebService.asmx?WSDL"/>
<scl:discoveryRef ref="http://yourBrotherSite/hisWebServiceDirectory.disco"/>
</disco:discovery>

This sample disco file specifies two different namespaces: disco, which is a nickname for the namespace http://schemas.xmlsoap.org/disco/; and scl, short for http://schemas.xmlsoap.org/disco/scl/. The contractRef element specifies the URL where yourWebService WSDL can be obtained. Right below that is the discoveryRef element, which links to the discovery file on yourBrotherSite web site. This linkage allows for structuring networks of related discovery documents.

Dynamic discovery

As opposed to explicitly specifying the URL for all Web Services your site supports, you can enable dynamic discovery, which enables all Web Services underneath a specific URL on your web site to be listed automatically. For your web site, you might want to group related Web Services under many different directories and then provide a single dynamic discovery file in each of the directory. The root tag of the dynamic discovery file is dynamicDiscovery instead of discovery.


<?xml version="1.0" encoding="utf-8"?>
<dynamicDiscovery xmlns="urn://schemas-dynamic:disco.2000-03-17" />

You can optionally specify exclude paths so that the dynamic mechanism does not have to look for Web Services in all subdirectories underneath the location of the dynamic discovery file. Exclude paths are in the following form:

<exclude path="pathname" />

If you run IIS as your web server, you'd probably have something like the following for a dynamic discovery file:[3]

<?xml version="1.0" encoding="utf-8"?>
<dynamicDiscovery xmlns="urn://schemas-dynamic: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>

Discovery setting in practice

A combination of dynamic and static discovery makes a very flexible configuration. For example, you can provide static discovery documents at each of the directories that contain Web Services. At the root of the web server, provide a dynamic discovery document with links to all static discovery documents in all subdirectories. To exclude Web Services from public viewing, provide the exclude argument to XML nodes to exclude their directories from the dynamic discovery document.

UDDI

Universal Description, Discovery, and Integration (UDDI) Business Registry is like a yellow pages of Web Services. It allows businesses to publish their services and locate Web Services published by partner organizations so that they can conduct transactions quickly, easily, and dynamically with their trading partner.

Through UDDI APIs, businesses can find services over the web that match their criteria (e.g., cheapest fare), that offer the service they request (e.g., delivery on Sunday), and so on. Currently backed by software giants such as Microsoft, IBM, and Ariba, UDDI is important to Web Services because it enables access to businesses from a single place.

The System.Web.Services Namespace

Now that we have run through the basic framework of Microsoft .NET Web Services, let us take a look inside what the .NET SDK provides us in the System.Web.Services namespace.

There are only a handful of classes in the System.Web.Services namespace and the most important ones for general use are:

WebService
The base class for all Web Services.

WebServiceAttribute
An attribute that can be associated with a Web Service-derived class.

WebMethodAttribute
An attribute that can be associated with public methods within a Web Service-derived class.

The two essential classes for creating Web Services are the WebService base class and WebMethodAttribute. We make use of these classes in the next section, where we implement a Web Service provider and several Web Service consumers. WebService is the base class from which all Web Services inherit. It provides properties inherent to legacy ASP programming such as Application, Server, Session, and a new property, Context, which now includes Request and Response.

The WebMethodAttribute class allows you to apply attributes to each public method of your Web Service. Using this class, you can assign specific values to the following attributes: description, session state enabling flag, message name, and transaction mode. See the following section for an example of attribute setting in C# and VB.

The WebServiceAttribute class is used to provide more attributes about the Web Service itself. You can display a description of the Web Service, as well as the namespace to which this Web Service belongs.

In the next installement, you will learn about Web services providers and more.


View catalog information for .NET Framework Essentials, 2nd Ed.

Return to the .NET DevCenter.