MTS and IIS

A behind-the-scenes look at these tightly integrated technologies

The Windows NT 4.0 Option Pack for NT Server includes technologies that let you create and manage Internet and distributed applications: Microsoft Internet Information Server (IIS) 4.0, which is the Web server; Microsoft Transaction Server (MTS) 2.0, which hosts and executes COM objects; and Microsoft Message Queue Server (MSMQ), which adds NT framework for building distributed applications using queuing technologies. Although the Option Pack's technologies operate independently to some extent, these technologies cooperate more than you might know.

The ASP-IIS-MTS Connection
MTS is a transaction processing system for developing, deploying, and managing high-performance, scalable, and robust enterprise, Internet, and intranet server applications. MTS defines an application-programming model for developing distributed component-based applications. MTS also provides a runtime environment for deploying and managing these applications. This system is the basis for Microsoft's Active Server Pages (ASP) transaction processing.

Microsoft has tightly linked IIS and MTS—IIS uses MTS to execute all applications. MTS uses a package to define a process space. A package contains the components that reside within a particular process and defines the attributes that all its components share. A package's components execute in the same process space (components in another package execute in a different process space). Packages let system managers and developers partition a server's components and applications to execute together or separately.

IIS In-Process Applications is a default MTS package for IIS. All applications that execute in the IIS process run in this package. This package includes any Internet Server API (ISAPI) programs (e.g., the ASP.DLL) that an application uses.

Each server defined in the Computers folder within MTS Explorer will typically have many packages installed. To view a server's packages, select the Packages Installed folder. You can click any package to view its components. Screen 1 shows the IIS In-Process Applications package in MTS Explorer. Each component is an ASP application. For example, IISWAM.1_Root_Charting points to the Charting Web site that I created with Microsoft Visual InterDev. The Web Application Manager (WAM) refers to the file C:winntsystem32 inetsrvwam.dll. If you select Properties for an entry in IIS In-Process Applications, you'll see a reference to this file, as Screen 2 shows. The WAM manages IIS applications. IIS dynamically creates instances of the WAM as IIS receives requests. When IIS receives a request for a URL, IIS must determine which namespace to map the request to. IIS looks up the namespace and forwards the request to the WAM for that process.

Isolated Applications
IIS 4.0 lets you run an application as an isolated process. With this option, the isolated application (aka an out-of-process application) runs in a separate memory space, so it doesn't affect other applications and DLLs. This method makes applications and the server more fault-tolerant because an application failure won't take down other applications or the IIS process.

You can run an application in isolated mode with Internet Server Manager (ISM). Screen 3 shows the Microsoft Management Console (MMC) version of ISM with the Run in separate memory space (isolated process) check box selected.

When you convert a nonisolated application to run in isolated mode, IIS creates a new MTS package for that application and moves its WAM into the package's Components folder. For example, you can create the isolated application Charting under the default Web site, and the application appears as the package IIS-(Default Web Site//Root/Charting). You can see the application's configuration change in MTS Explorer.

IIS can run a mixture of isolated and nonisolated applications; each application runs as usual, and you can link applications. No differences exist between an isolated and nonisolated application's code.

You'll see the advantage of an isolated application if it crashes. The isolated application will terminate, but it won't affect other packages or processes because they're running either in a separate process space or in the IIS process space. Also, because you can run a Web application in a separate process space, you can configure options (e.g., the debug settings) that will apply to only that application rather than all applications, or the whole IIS program.

The mtx.exe file executes an isolated application. To see this process, open Task Manager and locate mtx.exe in the list of processes while the application is running. You will see one occurrence of mtx.exe for the nonisolated applications and another instance for each isolated application.

ASP and IIS Working Together
You need to note how ASP applications fit with IIS 4.0. A virtual root can contain more than one application. IIS 3.0 limited each virtual root to one application, which the global.asa file defined. IIS 4.0 gives you more flexibility—you can have more than one application, each of which the folder that contains its global.asa defines.

A significant benefit of running an application in a separate process space is that you can unload and reinstall components that run as part of a Web application without stopping the IIS service. However, replacing components is a problem within an ASP application because if the application is running in process with IIS, you must stop the Web server to replace the component. This interruption becomes important when you need to recompile and replace the component that the ASP application is using. Because ASP is using the component, you can't delete or replace it when IIS is executing and holding on to the component.

To stop IIS, you must do more than stop the Web server process using the ISM. Go to the Services applet in Control Panel, and stop the IIS Admin Service (which also stops the Web Publishing Service). You can then replace the component and restart the service. The consequence of this approach is that the Web application is down when you have the service stopped. (This method can cause problems if you use components in your application on a production server.)

To stop an isolated application, open ISM, right-click the application name, and select Properties. Click Unload to stop the application. Now, you can replace the component. The application will restart when users access the application.

Running Web applications within the shared process space of IIS also provides benefits. You'll experience better system performance because this approach avoids much of the system overhead associated with out-of-process applications.

COM's Role
Out-of-process COM servers can exchange data even though they're running in a separate address space from the client program. The COM process makes a copy of the data and passes this copy to the server's address space so that the server's methods have access to it. COM replaces the original pointer to the data with a pointer to the copy in the server's address space. With IIS, you can consider IIS to be the client and the out-of-process Web application running in a separate MTS package to be the server.

When the server's method finishes, COM copies the data from the component back to the client's address space. This process is transparent to applications and can even convert different data types on the fly. Neither the server nor the client is aware of the actions the COM process is taking on its behalf. Microsoft refers to the process of copying data from one process to another as marshaling, which occurs when an application accesses any property or method of an out-of-process component. With IIS, marshaling occurs as interaction with the Web application takes place. Each time a client's browser makes a request to an application, marshaling occurs.

Benefits of Isolated Applications
In-process components run faster than out-of-process components run, because all the code and data are located in the client's address space. With in-process components, no action is necessary to copy data from one address space to another. Because an in-process Web application is running in the shared process space of IIS, the application and IIS can better share resources.

Isolated applications are extremely helpful during the development process. You can run an application in an isolated process as you build an application and its components. This method provides you with isolated process protection from a potentially buggy application. You also get the convenience of being able to unload and reload components without having to stop the server.

When the application is ready for production, you can change it to run in process with IIS for maximum performance. You also can move a production process to an isolated application when you need to replace components. After you replace a component, you can move the application back to an in-process application.

Putting the Pieces Together
This article illustrates why developers and systems administrators must understand how technologies work together and, to an extent, what's happening behind the scenes. With so many wizards, GUIs, and easy-to-use tools available, you can lose sight of the need to understand the details. The tight integration of MTS and IIS demonstrates how the details of plumbing can hide behind the glitzy interfaces.