Integration with MTS

Think of the server-side script in an ASP page as the first layer of business logic. This layer might use several COM objects to satisfy a request. In Chapter 4, we saw how transactions can be used to help ensure that resources are updated correctly when multiple objects are working together to fulfill a request from a client. Thus, it seems reasonable to include the processing of the ASP page itself within a transaction. IIS 4.0 enables this process.

In IIS 4.0, an application is identified by marking a directory or virtual directory as an application root. The application includes all files, directories, and virtual directories contained by the root that aren't part of another application.

Any ASP page can be declared to use transactions. When a page is processed, a new transaction will be created. All the objects created within the page are automatically enlisted in the transaction, if appropriate, by MTS. The transaction terminates when the entire file has been interpreted and any server-side scripts have executed. If the transaction aborts, all of the resources in the transaction will roll back to the values they had before page processing began. As you might imagine, this capability is particularly useful for pages that update databases.

IIS also uses MTS to manage server application processes. Each application, denoted by a unique virtual directory, can be configured to run in the main IIS process or in a specific MTS process, which improves overall server reliability. If one application fails, only that application's process is shut down and restarted. The entire Web server does not shut down. Separating applications into individual processes also helps with server maintenance. If an application needs to be updated, only that application process needs to be shut down. The Web server and other server applications can continue to run.

The architectural diagram in Figure 5-1 illustrates the integration of MTS with IIS and ASP. In IIS, applications are managed by a COM component called the Web Application Manager (WAM). The WAM is responsible for loading the ASP run time and other ISAPI DLLs. The WAM communicates with these DLLs whenever an HTTP request is received.

Each application, whether it is running in the IIS process or in a separate process, contains an instance of the WAM object. All application processes are managed by MTS. When you use IIS to configure an application to run in a separate process, MTS administrative objects are called on your behalf to create a new MTS package, generate a new globally unique identifier (GUID), add the WAM to the package using the new GUID, and configure the package to run in a separate process. Applications that are configured to run in the IIS process are registered in the default MTS in-process package.

Figure 5-1. The integration of MTS with IIS and ASP.

When IIS receives an HTTP request, it determines whether the requested URL is part of an application. If the URL is part of an application, IIS looks in its internal WAM map to locate the correct WAM object. If the application isn't running, its WAM won't exist and will have to be created. IIS creates the WAM object using the application-specific GUID generated at registration time. At this point, MTS starts a new process, if necessary, and begins managing objects and resources for the application.