The Big Picture: How Applications Discover Web Services

Proposed standards cooperate to help applications deploy Web services

My previous columns in .NET UPDATE have examined individual basic Web services and Global XML Web Services, explaining how each is intended to make Web services work in a timely and secure way. Now that you're familiar with the individual standards, I'd like to start connecting the dots. This time, let's take a look at how these proposed standards are intended to cooperate to help applications find and deploy Web services.

.NET applications depend not just on their own capabilities—the capabilities that their developers build in—but also on the capabilities of services hosted on other computers (known as "hosts") that the computer running the .NET application has access to. This situation is not unlike how computers running Microsoft Office can either use the clip art that the Office software supplies or access a Microsoft Web site to download additional clip art. In a similar way, .NET applications are designed to be able to communicate with external services and download a service's components locally so that the service is available immediately and in the future.

To deploy a Web service from an IIS-based service host, you create a virtual root on the host, into which you copy the service's configuration files and set up a web.config file for the service (to include security settings that override any default configuration settings for the Microsoft IIS server). You place other required files for the service into a bin subdirectory on the virtual root.

How does the .NET application find and connect to the virtual root? Web Services Description Language (WSDL), which I discussed in the February 7, 2002 .NET UPDATE, is a suggested standard for how Web services should be described on the service host so that an application can interact with them in a predictable way. But the first problem for the .NET application isn't reading the Web service description—it's finding the description. .NET application developers need to build this finding logic into applications so that the user running the application doesn't have to know where to look. The application must be able to find the necessary Web services, read their description, then download any required components to the local computer for execution. (What about application setup? One idea behind .NET applications is that copying the application files to the local directory is setup. Part of .NET's conceptual framework is that applications can be installed not through an installation routine but simply by copying files to an application folder-—similar to the old method of installing DOS files.)

The current way to point applications to a Web service's location is with Microsoft's DISCO technology, in which an XML-based file with a .disco extension is stored on the virtual root. The .disco files link to the actual Web service description (e.g., the WSDL document) and also link to one another and can span all the services on a particular host or collection of hosts. In other words, although a .NET application can connect directly to a service's .disco file, it can also connect to a list of available services that redirects the application to the appropriate service document. Another way to help applications find Web services is to use .vdisco files in place of .disco files, and tell the discovery request handler to look up all the support files with Web services suffixes in each virtual root, then dynamically create a .disco file to link to the Web service description. The two options produce the same effect, but discovering services each time an application needs them keeps the list of available services up to date.

The catch to DISCO is that it works for a specific server or known group of servers because you need a starting point for the application to point to. As you know if you've been reading along with these columns, Universal Description, Discovery, and Integration (UDDI) is another proposed method of service discovery. UDDI is an XML service that organizes other XML services by business type, service, or technical description and that can perform lookups of each type. Service hosts publish their service lookup information in a UDDI directory, which is like a telephone book. To find a Web service published with UDDI, a .NET application need only send a Simple Object Access Protocol (SOAP) message to a UDDI operating site. The catch to UDDI is that application developers either need to trust that all published services on a given site are safe to use (or maintain their own protected sites), or need to find a way to restrict the content of public UDDI sites.

As you've no doubt noticed, both DISCO and UDDI have their limitations, but I'll bet that the future lies with integrating Web services into applications. We're either going to live with these limitations, find solutions to them, or work around them.

For more information about the Web services I've examined in previous .NET UPDATES, check out the following Dot-Tech Perspectives columns: "SOAP: A Basic Component of XML Web Services," January 24, 2002; "WSDL: Defining and Directing Data for XML Applications," February 7, 2002; and "UDDI: The Directory Mechanism for XML Web Services," February 21, 2002.