Developing and deploying Web site applications gets a lot easier with the release of Microsoft® Internet Information Server (IIS) 4.0 for Microsoft Windows NT®, currently in beta. The latest version of IIS offers process isolation, which allows you to run Active Server Page (ASP) and Internet Server API (ISAPI) applications in a process separate from the main Web server process. Previously, both ASP applications and ISAPI extensions executed within the server process. This gave you great performance, but left the server open to potentially misbehaving application code. This vulnerability to unstable or just plain unpredictable applications compromised server robustness.
Running your IIS 4.0 application in an isolated process protects your Web server from unexpected application failures by separating each application marked as out-of-process into its own memory space. In essence, an isolated process means a process separate from the IIS server process. This fault isolation prevents a single application error from bringing down the rest of the applications on your site.
Other features of IIS 4.0, codenamed K2 and scheduled for release in the fourth quarter of 1997, include the ability for ASP to execute distributed transactions across multiple databases and to send remote recordsets back to the client. If you're interested in what will go into the latest version of IIS, check out http://www.microsoft.com/IIS.
Let's examine how process isolation in IIS can make your site a safe place for application development and execution. I'll walk you through a quick demo of running an IIS application in isolation, and what that means for your application. Then I'll explain how process isolation makes IIS 4.0 a compelling product for the serious site developer. Finally, I'll go over what happens under the hood to make your application run in isolation. I'll also discuss how Microsoft Transaction Server (MTS), which is tightly integrated with IIS 4.0, provides the runtime environment that enables process isolation.
Let's start by using the new application configuration
features in the IIS administration tool, the Internet Service Manager (ISM). If you have any questions regarding unfamiliar terminology, you can refer to the Glossary on page 43 for definitions.
In IIS 4.0, an application is a set of URLs that comprise a subtree of the URL namespace. The namespace begins at the root node, called the Application Starting Point, which is either a directory or virtual directory marked with the ApplicationRoot property. The application includes all files, directories, and virtual directories contained by the root that aren't application roots or more immediate ancestors of another application root. Simply put, if http://machine/foo and http://machine/foo/bar are application roots, then all URLs that contain /foo are part of the /foo application (as long as /foo/bar is not contained in the URL).
By default, an IIS Web application runs in the IIS process. If the Web application is marked to run out-of-process, MTS creates a separate process for the application. To use the process isolation feature, you must first mark your directory or virtual directory as an
application root. For my examples I'm using a virtual directory that's automatically installed with IIS 4.0: the IIS 4.0 Help directory. You can change the IISHelp virtual directory into a Web application through the ISM property sheets. Then you can configure the application to run in a process separate from the IIS process. This way, if you get a fatal error in your help files, neither the server nor the rest of the applications on your Web site will be brought down by the crash.
Before you start working with process isolation, take a look at the new ISM, now hosted by the Microsoft Management Console (MMC). The MMC helps administrators by providing a framework for all the network administration programs in IIS 4.0, including the ISM and MTS Explorer (the MTS administration tool). The MMC console hosts programs called snap-ins. In the MMC console window, the scope pane (on the left) shows a tree view of the namespace, which is the hierarchy of all the items that can currently be managed by MMC (IIS virtual directories or MTS packages). The common tree view hierarchy, similar to a File Explorer view of files and folders on a hard drive, makes it easy to monitor and manage IIS applications running either in the IIS process or isolated from it. Each item (or node) is one of a variety of objects, tasks, or containers.
When you select a node in the namespace, the results pane on the right displays the results of that selection. The results may be a list of the contents of the object you selected (like files in a virtual directory or methods in an interface), or it may be another kind of management view (such as a property sheet or Performance Monitor graph). You administer the network by using commands represented by toolbars or command menus in the right pane.
To make the IISHelp virtual directory an application, open the Administration Web Site in the left pane of the ISM by clicking on the +, then select the IISHelp virtual directory and right-click. Select the Properties option from the context menu. The Properties page for the IISHelp directory contains a Virtual Directory tab that lets you create an application by going to the Application Settings section, typing in a friendly name, and clicking the Create button. This marks the virtual directory as the application root. Figure 1 shows you what the property sheet for creating an application looks like when first invoked.
Figure 1: Creating a Web Aplication
Once you've made your virtual directory an application, you can configure the application to run out-of-
process. To run the IISHelp application in an isolated process, right-click on the IISHelp application and select the Properties option again. The Virtual Directory property sheet now offers slightly different options. The "Run in separate memory space" option has been enabled, as well as the Remove option in the Application Settings. Once you've checked the "Run in separate memory space" box on the Virtual Directory tab (see Figure 2), your application will run out of the IIS process as a separate package in the MTS process.
To make the IISHelp application run in the IIS process again, return to the Virtual Directory tab on the ISM property sheet for the IISHelp virtual directory and clear the check in the "Run in separate memory space" checkbox. This moves the IISHelp application back into the IIS process. To make the IISHelp directory a virtual directory again, click the Remove button.
Methods for extending Web servers have always involved tradeoffs between performance and safety. With CGI, the earliest method for running code on a Web server, a new process is created to handle each request. This simple model protects the server from misbehaving applications, but degrades performance by adding the overhead of process creation. IIS 1.0 introduced ISAPI, and then IIS 3.0 gave you ASP, both of which have better performance, but also the potential to compromise server stability. IIS 4.0 introduces a new paradigm for hosting Web application processes; by creating a long-lived, isolated process, IIS 4.0 process isolation maintains the performance of the ISAPI/ASP model while providing the safety of CGI.
The big advantage to process isolation is fault isolation. If you run a new application in a process separate from the others on your Web site, that application's fatal error won't bring down the rest of the applications hosted on your site-or worse, the server itself. This kind of server protection is invaluable for managing complex production Web sites and hosting multiple applications. You can worry more about developing new applications than protecting the existing server environments from upstart additions.
Use the ISM to manage your Web applications. Running components in-process provides an immediate performance benefit because you don't have to marshal parameters across processes. Use the MTS Explorer to register new components for your application, and administer your application with the ISM.
Process isolation enables IIS applications to be started
automatically when a client requests the services of that application. In the case of a fatal application error, the application's process is automatically terminated. If the application is transactional, all transactions in progress are aborted. The system event log stores a record of the error that occurred, and the MTS runtime environment (which hosts server
processes for IIS) automatically restarts the application process. Since the application was running in isolation from the IIS process, the only ones affected by the failure are clients with outstanding requests to that specific application. Clients calling other applications on the Web site are not affected by the application's failure. This feature gives you the ability to maintain the robustness of your site server while introducing new applications.
You can also unload an application running out-of-process without having to restart IIS 4.0. This means that you can gracefully stage application updates without having to restart your entire server. With ISAPI DLLs in IIS 3.0 or ASP components with IIS 4.0, you have to jump through hoops to update your DLLs. Since both ran in the server process (see Figure 3) and there was no way to get the server to unload the DLLs, the only way to update the components was to stop and restart the server. Once installed, your updates wouldn't be live until the next client request loaded the DLL.
To update an application running out-of-process in IIS 4.0, simply unload the application through ISM, make your changes, and reload the application. The next client that calls the application will load the updates. The only time you'll have to restart the IIS server is when you want a component (an ISAPI DLL) to be shared between an application running out of the IIS process and one running in the MTS process. Restarting the Web server in this instance allows the application running in the IIS process to release its reference to the shared ISAPI DLL.
Underneath process isolation is the complete melding of the MTS runtime environment with IIS directory and application services. The MTS runtime environment hosts all IIS applications, whether they're running in the IIS process or isolated processes. As an administrator, you don't have to do any complicated configuration or programming to get the fault isolation and robustness of running an application isolated from the IIS process. If you want process isolation, you simply select a checkbox in the ISM Virtual Directory property sheet. The action of moving an IIS application out of the IIS process and into a separate process in the MTS runtime environment is conducted transparently by an IIS internal component in conjunction with MTS internal administration objects.
In IIS, applications are hosted by an internal IIS COM component called the Web Application Manager (WAM). The WAM controls loading and interfacing with ISAPI DLLs-including asp.dll, the ASP runtime-and communicates with them every time a request is received from a browser. The WAM itself is a COM component and can be run in the IIS process or isolated in a separate process. Each IIS application has an instance of the WAM. MTS, a runtime environment for COM components, hosts the WAM object and each of its instances.
IIS maintains a pointer to a WAM object for each application. When you select the "Run in separate memory space" checkbox, the WAM moves your application from the IIS process into a separate, isolated process. So how does MTS figure into the story? To move your application into a separate package, the WAM calls MTS administrative objects to create a new package, generate a Globally Unique Identifier (GUID) for the application to register it as a new component in the MTS runtime, and then configure the package to run out-of-process. Basically, the WAM is automating all the steps that you would take in the MTS Explorer to make your IIS application a separate MTS package.
Since the MTS Explorer shares the same console with the ISM, you can see a graphical representation of the process in which your application is running. For example, Figure 4 shows that the IISHelp application is a component in the MTS package for applications running in the IIS process. This means that if the IISHelp application breaks, your IIS server may go down with all applications on board.
Figure 4: In-process IISHelp shown in MMC
As you can see in Figure 4, the component named IISWAM.1_ROOT_IISHELP_ indicates that your IISHelp application is running in the IIS process (or in MTS terms, the IIS In-Process Applications package).
If you run your ISAPI-based application in isolation from the IIS process, your program is automatically made into a separate process hosted in the MTS runtime environment. As shown in Figure 5, the MTS runtime environment sees all applications running in the IIS process as a single process. If you run an isolated application, that application executes in its own memory space within the MTS runtime.
In the MTS world, an application is depicted as a package, and an isolated application will appear as a new package in the MTS Explorer. Figure 6 shows you what the IISHelp application (which has been renamed to IIS - {Administration Web Site//ROOT/IISHELP/}) looks like in the MTS Explorer when it's isolated from the IIS process.
Figure 6: Isolated IISHelp in MTS Explorer
You want a Web server that is as robust and manageable as it is powerful. The process isolation provided by MTS and IIS 4.0 allows you to host new or unstable applications without having your entire server blow up in the event of an application-fatal error. With IIS 4.0, your Web server can gracefully tolerate failures with minimal disruption to clients of other applications on your production site. Combine those features with the ease of administration through the integrated console and you have a safer, more robust server as one part of a multifaceted IIS 4.0 package.