Deploying Web Services

A certain mystique surrounds Web services. Microsoft's struggle to define Microsoft .NET—finally settling on ".NET is Web services"—has caused widespread confusion over the past few years. Despite the confusion, the concept of Web services is easy to grasp, and Web services are easy to build with tools such as Visual Studio .NET. Deploying Web services is also a simple process. Let's take a quick look at what Web services are, then discuss how to deploy them.

Web Services in a Nutshell
A Web service is a resource that programmatically returns information (i.e., applications or other Web services) to clients who want to use it. Web services bring the promise of interoperability through truly distributed computing across numerous platforms. However, unlike distributed technologies of the past that depended on proprietary object models and proprietary programming languages, Web services work in a loosely coupled and vendor-neutral environment.

As with any Web application, you can use Internet standards (e.g., HTTP) to integrate a Web service with other Web services. A Web service is URL-addressable, meaning you can access it simply by entering a URL. In fact, when I describe Web services to people, I often say, "Web services are like COM objects with their methods exposed to the Internet." Although this explanation is decent, it doesn't completely hit the mark because Web services can also live inside a firewall, in which they might function in an intranet scenario.

Web services go by several names. You might hear them called ".NET Web services," which is a misnomer because Web services aren't unique to .NET, nor are they unique to Microsoft. You might also hear them called "XML Web services" because XML is the language some Web services use. The only assumption between the application that uses the Web service and the Web service is that recipients will understand the messages they receive. Simple Object Access Protocol (SOAP), the transport for XML, facilitates this understanding by providing a standard for Web service communications, whether they occur on the Microsoft platform, the Sun Microsystems platform, or any other platform.

You can implement security for Web services the same way that you implement security in any ASP.NET application: by leveraging IIS to provide authentication and authorization options. You can also configure customized SOAP-based security.

Although you can feasibly use a simple text editor such as Notepad to build a Web service, a more powerful tool is Visual Studio .NET. You can use Visual Studio .NET's simple template, which Figure 1, page 2, shows, to create a Web service. After only a few clicks, the software sets up the entire framework that Web services require.

UDDI
One of the biggest criticisms of the Internet is that the tools for searching and discovering the Internet's vast amount of information are relatively weak. The Universal Description, Discovery, and Integration (UDDI) specification defines a standard way to publish and discover information about XML Web services. Providers of Web services use UDDI to advertise the existence of their Web services. Web service consumers can also use UDDI to locate Web services of interest. In UDDI, the industry has a specification for building flexible, interoperable XML Web service registries that are useful in both private and public deployments.

UDDI 3.0 is now available at http://www.uddi.org. The enhancements that version 3.0 offers include multiregistry topologies, increased security features, improved Web Services Description Language (WSDL) support, a new subscription API, and core information-model advances, such as improved registry management. For more information about version 3.0, see the UDDI 3.0 specifications at http://uddi.org/pubs/uddi_v3.htm.

Registering your Web service in UDDI is a simple process. Go to http://www.uddi.org and click Register to access the page that Figure 2 shows. Choose your Web service platform (e.g., Microsoft), and click Go to proceed with the wizard.

The wizard prompts you to authenticate in Microsoft Passport—a requirement of registering your Web service on the Microsoft platform in UDDI. Next, you provide details about your company and your Web service. UDDI promises that it will propagate your submission to the live UDDI registry within 24 hours.

You can manually or programmatically search UDDI for a Web service. To manually search for a Web service, go to http://www.uddi.org and click Find. Choose your Web service platform (I'll assume you click Microsoft), and click Go to proceed to Microsoft's UDDI site (https://uddi.microsoft.com). Choosing Search in the left navigation bar takes you to the Search Criteria page. As an example, my company has two public Web services registered on UDDI. In Figure 3, you can see that I selected the Providers tab and entered InterKnowlogy as a provider name. When I click Search, the Microsoft UDDI site returns two results in the left pane. When I click either result, I obtain my company's Web service details.

Programmatically searching UDDI for a Web service is a powerful way for developers to enhance their applications' functionality. In large enterprises, developers can write applications that programmatically search and locate Web services within their entire organization.

Deploying Web Services
The Web service deployment scenarios that I discuss later require that you install the .NET Framework on the target Web server. For information about deploying the .NET Framework, see "Get Ready for .NET," May 2002, InstantDoc ID 24479.

As far as IIS is concerned, a Web service is nothing more than an .asmx file and a .NET assembly that live in a virtual directory. After you install the .NET Framework on a machine, IIS will recognize files with .asmx extensions as Web service files and will process them appropriately. (Similarly, IIS recognizes files with .asp extensions as Active Server Pages—ASP—files and knows that .aspx extensions identify ASP.NET files.)

Deploying Web services into your existing Web farms is a simple process: You simply copy the appropriate files to your IIS Web server. This process is often called XCopy deployment because unlike COM, .NET no longer has the dependencies of the registry. Your current methods for deploying content and files into IIS Web farms will work fine for deploying Web services because Web services are simply files and virtual directories when you break them down into functional parts.

Visual Studio .NET can automatically set up, configure, and deploy a Web service. However, you probably don't want to use Visual Studio .NET in a production-deployment scenario because of the number of steps the software requires and because of the excess baggage (e.g., debugging files) that the software creates. Microsoft Application Center 2000's deployment utility is a better tool for deploying Web services: In addition to deploying the Web service's content, the tool automatically sets up and configures virtual directories on target servers.

Upon deployment, Web services resemble any other virtual directory or Web application in IIS, as Figure 4 shows. Deploying a Web service involves copying the .asmx file and any assemblies that the Web service uses to the IIS Web server. A .NET assembly—the primary building block of a .NET application—is a grouping of application functionality. That grouping is built, versioned, and deployed as one implementation unit in the form of one or more files. Every assembly includes an assembly manifest in the form of metadata, so the assembly is self-describing. The assembly manifest performs the following functions:

The self-describing nature of assemblies helps make the installation and XCopy deployment feasible.

In a Web service deployment, any assemblies that the Web service uses that are part of the .NET Framework need not be deployed to the IIS Web server. In the Web service that Figure 5, page 4, shows, you can see one assembly file—OrdersWebSvc.dll—that must be deployed into a bin directory off the root of the Web service virtual directory. That file is the only file that the Web service needs to function properly. The OrdersWebSvc.dll file—aka the project .dll file—contains the Web service's code-behind class file (.asmx.vb or .asmx.cs file), which is readable in any text editor and holds the full code and all other class files included in the project. But the OrdersWebSvc.dll file doesn't include the .asmx file itself. For that reason, you must deploy the .asmx file separately. After you deploy the .asmx file, you deploy the single project .dll file to the production server without any affiliated source code. When the XML Web service receives a request, it loads and executes the project .dll file.

Other Files
Now, let's take a look at some files in a Web service deployment. Some files are optional; others simply result from building and deploying the sample Web service in Visual Studio .NET.

.pdb files. A program database (.pdb) file holds debugging and project-state information that permits incremental linking of a Web service's (or ASP.NET application's) debug configuration. Because the developer uses .pdb files in the debugging process, these files aren't necessary in a production deployment of a Web service. In Figure 5, notice the OrdersWebSvc.pdb file that resides in the bin directory.

.disco files and .vsdisco files. Disco, a technology that Microsoft introduced in .NET, facilitates the capability of Web service clients to discover Web services and their associated WSDL documents. If a Web service publishes a static discovery (.disco) file, you can enable programmatic discovery of that Web service. A .disco file defines what files to search; whereas a dynamic discovery (.vsdisco) file simply identifies which directories to omit. The .disco and .vsdisco files provide alternative ways to discover Web services that preclude the use of UDDI. In fact, .disco and .vsdisco files are separate from UDDI; if UDDI is in use, .disco and .vsdisco files aren't.

A file with a .disco extension is an XML document that can contain links to other discovery documents, XML Schema Definition (XSD) schemas, and service descriptions. When a client (e.g., another Web service) requests the default .vsdisco file in a site's root folder, dynamic discovery for the entire Web site begins. Dynamic discovery is a process by which ASP.NET performs an iterative search through a hierarchy of folders on a Web server to locate available Web services.

When you install the .NET Framework on an IIS Web server, .vsdisco extension is mapped to aspnet_isapi.dll and the .NET Framework class System.Web.Services.Discovery.DiscoveryRequestHandler processes any requests for a .vsdisco file. This handler searches the folder that contains the requested .vsdisco file—and all its subfolders—for Web services (.asmx files), .vsdisco files, and .disco files. If the handler doesn't find an .asmx or .vsdisco file, or if it finds a .disco file, it simply terminates its search. Therefore, you shouldn't (and, in fact, you can't) place both a .vsdisco file and a .disco file in the same folder.

A word of caution: For security reasons, you need to control which XML Web services clients can discover on your IIS Web server. You should use only .vsdisco files—not .disco files—on development and staging Web servers. When you deploy Web services to production Web servers, you should always create .disco files for the Web services that you want clients to discover.

Web.config files. By including a web.config file in your Web service's default folder, you can provide customization and extensibility and override your IIS Web server's default configuration settings. For example, a web.config file might provide your Web service with custom authentication that's different from your Web site's authentication.

Global.asax files. The .NET equivalent of ASP's global.asa file is the global.asax file, which you can choose to include in your Web service's root folder. Global.asax is an optional, customizable file that contains code for responding to application-level events (e.g., session on_start, session on_end) that a Web service raises.

As Simple as That
Now you know that deploying Web services involves simply copying the Web service .asmx file, some optional files, and any assemblies that the Web service uses to your IIS Web server. So get out there and start deploying.