As a Windows network administrator, you might be wondering how Microsoft .NET will affect your world. In fact, you might still be wondering what .NET is! I've read several good and bad attempts to describe .NET, but most of those attempts are equal parts technology and marketing spin. You're probably ready for a .NET discussion that cuts through the hype and focuses on the technology.
You're probably particularly curious about some of the new protocols and standards that will fall under the umbrella term of Web Services—a key component of .NET. Web Services promise to vastly simplify your life but will also present some new challenges. Before you dive into the details, check out the sidebar ".NET Demystified," page 24, for my succinct answer to the question, what is .NET?
What Are Web Services?
The media have described Web Services as the next phase of the Web's evolution. Web Services are compelling for many reasons, one of which is that most major e-commerce software vendors (e.g., Microsoft, IBM, Sun Microsystems, Ariba) have committed to support Web Services in their products. Because of this industrywide support, Web Services might finally provide the necessary adhesive to connect applications across networks, application frameworks, and OSs. Web Services provide two key benefits: First, they provide a new, more integrated way for applications to interact over the Web, and second, they let disparate application platforms interact more smoothly than ever before.
In today's Web-application world, you'll find many common elements—despite the varying hardware, software, and OSs in use. Most companies use a Web server (e.g., Microsoft IIS, Active Server Pages—ASP) to develop HTML-based presentation logic. For example, when you visit a Web site to buy a product, you use your browser to view the HTML results of the data that you've requested from the site. Behind the scenes, that site's Web server is communicating with a back-end database (e.g., Microsoft SQL Server) either directly from an ASP-generated page or through middle-tier business-logic application servers. Business logic, which represents the "brains" of a Web site application, is usually encapsulated within components written in object models such as COM or Java. By adding new capabilities, Web Services change this model.
Suppose Company A has developed a Web site that delivers weather forecasts for any city in the world. If I use my browser to visit Company A's site, I can click through a series of Web forms to obtain the forecast for a certain city. Now, suppose I offer worldwide travel information on my Web site, and I'd like to make Company A's weather information available on my site. In today's Web world, I can provide that information in a few ways—none of which are particularly elegant. First, I could link to Company A's site from within a frame on my site, passing a query string based on user input. Second, I could "screen-scrape" the results of a search from Company A's site and present it to the user at my site. Third, if Company A has componentized its weather logic, I might be able to buy it and run it on my site directly. Only the third option results in a good user experience, but I don't particularly want to invest in a new component every time I want to add new functionality to my site. Figure 1 illustrates today's Web site interactions.
What I'd like to do is call the business logic running on Company A's Web server directly from within my Web application. That way, my site could present users with a fully integrated experience and avoid the mess of the above approaches. I've just described the promise of Web Services, which provide applications a way to expose their own components and use other applications' components. Figure 2 illustrates this new interaction.
SOAP Keeps It Clean
Web Services applications use a standard set of protocols and services to communicate directly with other Web Services applications. A Web Services application creates a remote object and calls a remote method on the remote Web application server, just as I might do through Microsoft Distributed COM (DCOM), Java Remote Method Invocation (RMI), or Common Object Request Broker Architecture (CORBA) Internet Inter-ORB Protocol (IIOP). However, the Web Services set of technologies instead uses the Simple Object Access Protocol (SOAP).
SOAP is an XML-based way of representing interobject communication that's independent of the underlying object technology (e.g., COM, Java, CORBA). Figure 3 shows a Network Monitor trace from a SOAP message. The top frame shows the client application's HTTP requests and replies (designated as LOCAL) to the server running the Web Service (designated as ROUTER because the server resides across a router). The middle frame shows an exploded view of the currently selected HTTP packet. Notice that I've drilled into the HTTP request portion of the packet. The bottom frame shows the data values of the portion of the packet that I've highlighted.
A SOAP message contains three primary components—an envelope, a header, and a body. The envelope identifies the XML encoding as a standard SOAP message. The header contains optional message information, such as authentication information. The body contains information related to the component that the application is calling (i.e., the expected input and output parameters and the data types of those parameters).
The SOAP 1.2 specification is currently a working draft within the World Wide Web Consortium (W3C). Vendors such as Microsoft and IBM currently support SOAP 1.1 (even though the protocol isn't yet a fully ratified standard within the W3C) with tools that use the technology. Therefore, my Web application—written in C# or Visual Basic.NET (VB.NET) and running on a .NET server or client—can call a component written in Java running on an IBM WebSphere Application Server that's using IBM Web Services that also support SOAP. And, of course, I can also use SOAP to call .NET components running on one .NET server from a .NET application running on another .NET server. Such powerful interoperability has been, until now, elusive.
A key aspect of SOAP is its protocol-binding capabilities. The W3C's SOAP specification describes the binding of SOAP messages to HTTP. Compatibility with HTTP presents another big advantage to using SOAP as an interobject transport because HTTP typically passes very easily through corporate firewalls. Also, you can use HTTP over Secure Sockets Layer (HTTPS) to pass encrypted messages between applications. The use of HTTP is advantageous for applications that communicate with one another through a typical request-reply model—as in standard remote procedure call (RPC) communications.
However, if two applications need to call objects asynchronously, HTTP isn't a good choice because HTTP requests typically must wait for a reply before the next set of requests can proceed. Several vendors have proposed other message-based protocols—such as SMTP—as a possible transport for the binding of SOAP messages. (So far, no standard has been established for such a binding.)
Finding and Describing Web Services
In addition to using SOAP to format object requests that travel across a network, applications need to be able to find Web Services of interest at design time (i.e., during application development) and at runtime. Then, the application must be able to determine the capabilities of those Web Services. Suppose your company is running a financial-information portal. You want to provide visitors to your site up-to-the-minute stock quotes. However, your developers don't want to build their own quote system. Rather, at runtime, they'd like their application to be able to query a central Internet repository to find other sites that have Web Services offering quote capability. The Universal Description, Discovery, and Integration (UDDI) service describes just such a repository. (For more information about the UDDI specification, see http://www.uddi.org.) A UDDI registry is a directory of Web Services that an application can query to find appropriate Web Services. Microsoft provides a UDDI registry and a software development kit (SDK) at http://uddi.microsoft.com; developers can use this SDK to register and locate Web Services in the Microsoft registry. UDDI relies on SOAP messages as its transport for discovery of Web Services. Consider UDDI a specialized type of SOAP message that facilitates querying and discovering Web Services registered within a UDDI registry.
After using UDDI to discover a Web Service that's appropriate to the application, developers need to be able to get a description of that Web Service in terms that their application can understand. For this task, Microsoft, IBM, and others are advocating the Web Services Description Language (WSDL) standard. WSDL is an XML document standard for describing a particular Web Service's details, including its input and output, the names and types of the methods or functions that the service implements, and the protocols (e.g., HTTP) to which the service is bound.
Associating a standards-based WSDL document with a Web Service means that any application that supports WSDL can discover and use, or consume, that Web Service. In fact, WSDL is a key component of the way .NET applications advertise and consume Web Services.
How the .NET Framework Implements Web Services
With .NET, Microsoft has simplified the developer's task of creating and consuming Web Services. Besides providing support for the above-mentioned protocols and specifications—SOAP, UDDI, and WSDL—Microsoft has integrated support for Web Services into the Visual Studio (VS) development environment, as well as IIS and ASP.NET. Web Services published in .NET resemble a special kind of ASP Web page. Notably, IIS and ASP.NET advertise Web Services as Web pages with an .asmx extension. For example, a Web Service from Company A called weatherservice would be addressable by using the http://companya.com/mywebservices/weatherservice.asmx URL.
Microsoft derived the .asmx extension from assemblies, its term for .NET-managed applications. IIS and ASP.NET know that the URL in the previous paragraph is for a Web Service and that requests for that URL are probably SOAP messages that the system needs to decode and deliver to the .NET application called weatherservice. Similarly, the client application that uses this Web Service could be another .NET Web server application or a .NET-developed Windows desktop application that communicates through SOAP.
To facilitate sharing the weatherservice Web Service with other .NET applications, I simply need to make the WSDL file for that Web Service available to application developers who need to call it. Microsoft provides a tool in the .NET Framework SDK—wsdl.exe—that uses the WSDL file as input and generates VB.NET, JScript.NET, or C# proxy code that a developer can call from his or her application. This proxy code tells the application where to find the Web Service (i.e., at the given URL) and how to call it.
Web Service Security
You're probably wondering how you can secure access to a particular Web Service if your Web site is hosting more than just HTML. After all, Web Services are your business logic—your intellectual property—appearing as just another Web page. Unfortunately, the SOAP specification doesn't provide any explicit mechanisms for authentication or authorization to a particular Web Service. Instead, the Web Service creator is responsible for providing such an authentication and authorization model. Such a model is relatively simple to establish. Web Services on a .NET Web server run simply as another Web page under IIS; therefore, they can use IIS's built-in security capabilities. You can specify anonymous, basic, or integrated Windows authentication for a virtual directory that hosts your Web Services. Also, when .NET ships, Microsoft will likely provide support for other authentication mechanisms (e.g., X.509 digital certificates).
Regardless of the authentication method you choose, the calling application must be able to pass the required credentials to your Web server when it requests access to the Web Service. The wsdl.exe utility satisfies this requirement when it creates the proxy code that the calling application uses to call your Web Service. When you run the utility, you specify not only the Web Service's .asmx URL but also any required username and password to access that URL. If you find that you must traverse a proxy to reach a site that's hosting a Web Service, you can also specify an HTTP proxy server.
Keeping Your Network Clean
In today's corporate IT environment, you probably use Web proxies and firewalls to segregate your internal network from the wild and woolly Internet. You might poke selective holes through those firewalls to let relatively harmless protocols such as HTTP browser traffic (e.g., ports 80 and 443) flow through. For the most part, however, you prevent protocols that facilitate true distributed applications (e.g., DCOM, RMI) from traversing firewalls. In fact, firewalls have complicated the development of cross-enterprise distributed applications, forcing developers to tunnel interapplication communications over less efficient protocols, such as HTTP.
We all know how previously mild traffic such as email has morphed into a potential carrier for all kinds of nasty invasions (e.g., Microsoft Outlook—based email viruses). The challenge of Web Services becomes clear when your developers discover that they can build robust distributed applications, using standard protocols such as HTTP, that can interact with applications across the Internet—right through your firewall.
Obviously, this powerful new capability requires extra vigilance on your part. Most networks have "one-way" holes in their firewalls; for example, users in your internal network can connect to external Web sites, but not vice versa. Therefore, a developer creating applications that use Web Services can consume external Web Services, but external entities can't use HTTP to actively infiltrate your network. Still, the door is now open for unwary developers to let malicious Web sites gain access to and possibly exploit your internal network. You need to take care that your developers consume only legitimate Web Services. To be sure, you're not totally without defenses: You can still use HTTP proxies to block access to certain Web sites that host Web Services. In addition, you can use router- or switch-based access lists to look higher up the network stack, into the HTTP header, and block packets that contain SOAP-specific headers.
The Power of Web Services
Regardless of the approach you take to manage this new mechanism for developing distributed applications, Web Services represent an extremely powerful model for leveraging application frameworks—.NET or others—across the Internet. .NET provides the tools and the technology to take advantage of this new model within the Windows environment. But you need to be vigilant in ensuring that applications developed inside and outside your organization behave properly and let you keep your network and systems up and running.
