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.