Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Matt Powell
MSDN Content Strategist
April 2003
As a Web services developer, you can look forward to new releases of three major tools you use and the platform you target for your Web services. Microsoft® Windows Server™ 2003, Microsoft .NET Framework 1.1, and Microsoft Visual Studio® .NET 2003 feature visible and not-so-visible changes to the platform and environment you work in and host your services on. So what is new? What issues will you run into? How are things changing in the Visual Studio .NET environment that you've worked in for over a year? Let's take a look at all three updates that pertain to Web services developers.
What's New
First, a little background: Windows Server 2003 is the first Windows® server release since Windows 2000 Server. Windows XP was the first Windows client platform built from the Windows NT® operating system base. The server platform has now caught up in look and feel and features to the client platform. There are new architectural changes in Internet Information Server (IIS); other new features such as UDDI Services; and the .NET Framework is now on the installation CD as part of the operating system.
The .NET Framework 1.1 update is a minor release, particularly in regard to Web services, but there are a number of bugs fixed and performance issues addressed that you can take advantage of. Other changes to the 1.1 version include the default configurations that Web service developers use. With a second version of the runtime, there are real issues to be aware of when it comes to side-by-side execution of various assemblies. There are also updates to the documentation that are quite useful.
Visual Studio .NET 2003 has a number of new features for developers, such as a new Add Web Reference wizard and Web Service designer support for Managed Visual C++® Web Services. This makes quick Web service development available in C++ similar to how it is available in Visual Basic and C#.
The Platform: Windows Server 2003
Windows Server 2003 is first version of the Windows operating system that includes the .NET Framework with the installation. We will look at some specifics of the .NET Framework shortly, but what changes are available on the Windows Server 2003 platform itself?
Internet Information Services 6.0
Probably the single biggest change to the underlying platform for Web service developers is that the Web server that all our services run on has a vastly different underlying architecture. The core HTTP request handler has been moved from a user-mode service to a kernel-mode driver similar to the way that TCP/IP and other lower-level network protocols are handled. From the standpoint of writing code, there is little difference.
The real difference comes in performance and stability. Cached responses can be returned without even making a transition to user mode. Similarly, the standard previous configuration was that requests were passed to a single process (Inetinfo.exe) and then passed to a worker process (Dllhost.exe, or for Microsoft ASP.NET requests, Aspnet_wp.exe) to be handled. On IIS 6.0 in Worker Process Isolation mode (the default for new installations), requests are passed directly to the worker process from the kernel, avoiding the additional cross-process marshalling to the Dllhost or Aspnet_wp process. Worker Process Isolation mode also means that an application can be configured so that absolutely no other code is running in its process space. Since there is no Iinetinfo.exe intermediate process, you know that there is no other application code running that can hurt you there, either. ASP.NET has been modified so that instead of having a separate Aspnet_wp.exe process, the ASP.NET code runs in the IIS 6.0 worker process (W3wp.exe). If you are accustomed to running IISreset on Windows 2000 to restart your server whenever a Web application encounters a hanging bug, you can rest assured that simply shutting down the worker process is enough with IIS 6.0 and that other worker processes will not be affected. The default configuration for Web applications in IIS 6.0 is for Web applications to work in a shared worker process, so if you want complete isolation, you do have to configure your Web application appropriately. This is equivalent to the default pooled process setting in IIS 5.0.
The default configuration of Windows Server 2003 and IIS 6.0 is significantly different than in previous versions. High-profile security vulnerabilities require that features are not installed by default. For instance, IIS is simply not installed when you initially install the operating system. Within IIS, you must specifically enable features such as CGI, ISAPI and ASP.NET support before you can run applications of those types. Another change to the configuration is that the worker processes now run under a user account called Network Services. You can think of this in terms of the old IWAM_<machinename> account that was used to run out of process Web applications in IIS 5.0, but the Network Services account is now built-in like the Local System account. Since there are no longer in-process Web applications, you cannot gain unlimited Local System account permissions by simply running your applications in-process. If you really need higher permissions then Network Services provides, you should create a new account with the permissions required and have the specific worker process for that application run under the account you created.
IIS 6.0 does provide support for running in IIS 5.0 Isolation Mode instead of Worker Process Isolation Mode (the default). IIS 5.0 Isolation Mode mimics the environment that IIS 5.0 applications ran under. Applications that have dependencies on the IIS 5.0 process and security model can run in this mode to avoid backwards compatibility problems.
Other changes to IIS 6.0 include support for Windows Management Instrumentation (WMI), an XML formatted metabase, and the fact that there is operating system support for running on 64-bit machines.
UDDI Services
Before Windows Server 2003, UDDI Services were relegated to a few servers on the Internet run by Microsoft and a couple of other companies to advertise Web services on the Internet. With Windows Server 2003, UDDI is available for users on their own corporate networks. UDDI provides a means for querying a registry of Web service types and instances with flexible taxonomies so that queries and organization systems can be created to meet the needs of a particular business. The single biggest advantage of the UDDI registry for holding Web service information is that it allows for well-defined mapping of IDs to a specific Web service type or instance. A corporate Web service may be running on machine A, and then moved to machine B. A UDDI ID associated with this Web service instance would be located in the UDDI registry so that when the move is made, the registry is updated. Client applications using this Web service would be querying UDDI with this ID, and when the transition occurred, they would seamlessly send their requests to the new machine. For more information on using UDDI in your applications, see Using UDDI at Run Time, Part I. UDDI Services also have support for setting up replicated UDDI servers for high performance and high availability.
.NET Framework 1.1
One more change to the underlying platform is that the .NET Framework version 1.1 is installed by default on Windows Server 2003. To avoid any backwards compatibility problems that might arise, you can run versions 1.0 and 1.1 side by side and avoid the DLL Hell problems of the past. We will look further at some of the changes in version 1.1 as it applies to Web service developers.
But before we look at new features, it is interesting to note what is not in version 1.1. The major new feature that was going to be in this release was support for the SOAP 1.2 specification. However, SOAP 1.2 has not been finalized yet and it became apparent that early support would end up with non-compliant code due to the sorts of changes being made to the specification. Therefore, support for SOAP 1.2 was pulled from this version of the .NET Framework.
We talked about security changes that were made to IIS 6.0 earlier, and the same changes apply to the .NET Framework. The HTTP POST and HTTP GET support for calling Web services is turned off by default. This is probably good because they are not WS-I Base Profile-compliant and they don't meld with SOAP header handling that is becoming more and more of a backbone of SOAP message handling. However, one of the convenient testing tools for ASP.NET Web Services is the ability to press the F5 key and open the HTML form that prompts you for input parameters values and calls your Web method from the form via an HTTP POST. It would be a shame to lose that capability. The good news is that the capability is there, but through a new Web service protocol provider called LOCAL POST. LOCAL POST is only available for calls from the local machine. Since this functionality was largely used in the past by developers in early testing of their Web service code, that same functionality is not lost. However if you were having people use the Web interface regularly from other machines, then you will have to re-enable the HTTP POST protocol via a setting in the Web.config file.
For the most part, your code that relies on version 1.0 of the .NET Framework will work just fine with version 1.1. However, there were a number of bugs fixed in 1.1, so it is possible that you have code that relies on functionality that has changed in the 1.1 version. The good news is that side-by-side execution has been designed into the .NET Framework so that your application can run under whatever version it needs to run with in order to work. The bad news is that in the case of ASP.NET, a change is a little more encompassing then it is with a Windows Form application. For instance, in previous versions all ASP.NET applications ran in a single process, Aspnet_wp.exe. Luckily we have options for assemblies running with different versions of the .NET Framework, too, so these are all solvable problems with managed applications. See Side-by-Side Support in ASP.NET in the .NET Framework Developer's Guide for the details on how to configure Web applications for different versions of the .NET Framework. It involves remapping the IIS script maps to use the version of Aspnet_isapi.dll that is associated with .aspx, .asmx and the other extensions for ASP.NET applications. This is made easier by using the Aspnet_regiis.exe utility that can do all the script mapping for a given virtual directory.
One of the most important parts of a software development kit (SDK) is its documentation, and there are a number of changes in the documentation for version 1.1 of the .NET Framework. In the 1.0 documentation, there were a number of classes that were pretty sparsely covered, and it looks that those information holes are pretty much filled at this point. Documentation on side-by-side issues is new, of course, but my two favorite additions are Creating Asynchronous XML Web Service Methods which describes how to enable asynchronous Web method execution analogous to HSE_STATUS_PENDING with ISAPI extensions, and Customizing the Generation of Service Descriptions and Proxy Classes which details how you can modify WSDL generation and proxy class generation for managed applications.
Visual Studio .NET 2003
The changes to Visual Studio .NET for Web service developers are also relatively minor in this version. The bug fixes make for a more stable experience with Visual Studio .NET 2003, and a few other features are convenient for Web service developers.
One of the big new features of Visual Studio .NET 2003 is that C++ support comes much closer to full standards-compliance than previous versions did. Similarly, support for managed C++ development has also reached the mainstream. Much has been made of the fact that you can design managed C++ Windows Form applications in a designer similar to C# and Visual Basic, and there is similarly a Web service designer mode for C++ now. You can drag-and-drop components like a SqlDataAdapter into a C++ Web service, just as you have been able to do for over a year in C# and Visual Basic.
Changes have also been made to the Add Web Reference wizard for all our managed languages. First of all, you can now set the namespace name for the code that is generated for you. This is a nice change from having all the services you access listed under the nondescript "localhost" namespace, and then additional services listed under "localhost1", "localhost2", and so forth. Now the name is completely under your control during the generation process. Another change is that discovery has been turned back on by default, so that you can browse the services on your local machine in an easier fashion, as shown below in Figure 1. This sure beats typing in the URLs for all your projects.
.gif)
Figure 1. The new Add Web Reference wizard
A couple other minor changes include the Web.config file, which now has a default <authorization> element included, and the default Visual Basic .NET Web service project that now has its namespace set to include the local virtual directory (for example, http://tempuri/MyNewWebService/) instead of leaving it as http://tempuri.org.
Take Them and Run
The updates to Visual Studio .NET and the .NET Framework and the major upgrade to the server platform make Windows Server the platform of choice for running Web services. The initial 1.0 "trial" release of .NET has passed with flying colors into the "ready for the real world" version 1.1. IIS 6.0 security and performance, along with the UDDI Services, bring UDDI into the Web service limelight, and the infrastructure for Web services is becoming a reality.