Chapter 2: SharePoint Architecture

• Review important concepts and terms for IIS and ASP.NET.

• Understand how Windows SharePoint Services (WSS) extends the ASP.NET routing infrastructure.

• Understand the difference between site pages and application pages.

• Learn to create custom application pages.

IIS and ASP.NET 2.0 Primer

This chapter examines the core architectural details of how WSS integrates with Microsoft Internet Information Services (IIS) and ASP.NET. We’ll start by reviewing some of the fundamental concepts and terms used with IIS and ASP.NET. We’ll then describe how the WSS team designed and implemented WSS 3.0 to sit on top of IIS and extend the ASP.NET Framework.

The primary goal of this chapter is for you to understand the internal workings of a Web application and how it initializes the WSS runtime environment. As you will see, the WSS team has extended ASP.NET by replacing many of the standard components with their own.

At the end of this chapter, we will introduce application pages and discuss why they become a fundamental aspect of WSS architecture. We will also walk you through the process of creating your own application pages for a custom solution and writing code behind them that accesses the WSS object model.

IIS Web Sites and Virtual Directories

Both ASP.NET and WSS rely on IIS 6.0 to supply the underlying listening mechanism to process incoming HTTP requests and supply a management infrastructure for launching and running worker processes on the Web server. Your understanding of how all of the pieces fit together should start with the basic concepts of an IIS Web site and virtual directories.

An IIS Web site provides an entry point into the IIS Web server infrastructure. Each IIS Web site is configured to listen for and process incoming HTTP requests that meet certain criteria. For example, an IIS Web site can be configured to handle requests coming in over a specific IP address or port number or can be routed to the Web server by using a specific host header, such as http://Extranet.Litwareinc.com.

IIS automatically creates and configures an IIS Web site named Default Web Site that listens for HTTP requests coming in over port 80 on any of the IP addresses supported on the local Web server. It is also possible to create and configure additional IIS Web sites by using the IIS Administration tool.

Each IIS Web site defines a specific URL space. For example, the standard Default Web Site defines a URL space to handle any incoming request whose URL maps to the following pattern: http://www.Litwareinc.com/*. As you can imagine, an unlimited number of URLs can be created within this URL space. IIS processes incoming requests targeted to one of these URLs by routing them to the Default Web Site.

Each IIS Web site is configured to map to a root directory, which is a physical directory on the file system of the hosting Web server. For example, standard configuration for IIS maps the Default Web Site to a root directory located at C:\Inetpub\wwwroot. In the most straightforward routing scenarios, IIS maps incoming HTTP requests to physical files inside the root directory. For example, IIS will respond to a request for http://www.Litwareinc.com/page1.htm by simply loading the contents of the file located at c:\Inetpub\wwwroot\page1.htm into memory and streaming it back to the client.

One important aspect of an IIS Web site is that it controls whether incoming requests require authentication and, if so, which authentication protocols to use. For example, the Default Web Site might be intended as a public-facing Web site for Internet users. As such, it might be configured to allow anonymous access and to support Basic Authentication. A secondary IIS Web site intended exclusively for employee use within the corporate LAN might be configured to disallow anonymous access and to support Integrated Windows Authentication instead of Basic Authentication.

In addition to IIS Web sites, IIS supports the creation and configuration of virtual directories. A virtual directory is an entity that defines a child URL space nested within the URL space of its parent IIS Web site. Like an IIS Web site, a virtual directory is configured with a root directory on the file system of the hosting Web server. IIS provides the flexibility of defining the root directory for a virtual directory at any location. For example, you could create a virtual directory within the Default Web Site with a URL space such as http://www.Litwareinc.com/Sales. When you create this virtual directory, you can configure its root directory as a file system directory such as C:\WebApps\Site1.

IIS provides an administration utility named Internet Information Services (IIS) Manager”, shown in Figure 2-1. This utility allows you to inspect, create, and configure IIS Web sites and virtual directories on the current machine. It can be started by using the shortcut Start | Administrative Tools | Internet Information Services (IIS) Manager. If you are not already familiar with this utility, you can launch it to learn how it is used to inspect and configure the properties of IIS Web sites and virtual directories.

Figure 2-1: IIS provides an administration utility to inspect and configure IIS Web sites and virtual directories.

Note that IIS tracks configuration information about its IIS Web sites and virtual directories in a repository known as the IIS metabase. The IIS metabase lives on the file system of each front-end Web server running IIS. For example, when you create and configure an IIS Web site using the IIS administration utility, IIS tracks these changes by writing entries to the local IIS metabase.

Instead of using the IIS administration utility, you can also automate the process of creating and configuring IIS Web sites and virtual directories by writing scripts or by writing managed code that programs against the IIS object model. This process is commonly done in Web farm environments when rolling out new Web sites because the identical IIS metabase setting must be applied across each front-end Web server in the farm.

ISAPI Extensions and ISAPI Filters

In the most straightforward routing scenarios, IIS simply maps an incoming request to a physical file within the root directory of an IIS Web site or virtual directory. However, IIS also supports the Internet Server Application Programming Interface (ISAPI) programming model, which provides the opportunity for more sophisticated routing scenarios. In particular, the ISAPI programming model allows you to configure an IIS Web site or virtual directory so that incoming requests trigger the execution of custom code on the Web server.

The ISAPI programming model was introduced with the original version of IIS and continues to provide the lowest level for creating custom components for IIS. The ISAPI programming model consists of two primary component types: ISAPI extensions and ISAPI filters.

An ISAPI extension is a component DLL that plays the role of an endpoint for an incoming request. The fundamental concept is that IIS can map incoming requests to a set of endpoints that trigger the execution of code within an ISAPI extension DLL. An ISAPI extension DLL must be installed on the Web server and configured at the level of either an IIS Web site or virtual directory. Configuration commonly involves associating specific file extensions with the ISAPI extensions by using an IIS application map.

While an ISAPI extension serves as an endpoint, an ISAPI filter plays the role of an interceptor. An ISAPI filter is installed and configured at the level of the IIS Web site. Once installed, an ISAPI filter intercepts all incoming requests targeting that IIS Web site. The fundamental concept is that an ISAPI filter can provide pre-processing and post-processing for each and every incoming request. ISAPI filters are typically created to provide low-level functionality for an IIS Web site, such as custom authentication and request logging.

Custom development of ISAPI components isn’t very popular these days for several reasons. First, custom ISAPI components are difficult to design, develop, and debug because they must be written in unmanaged C++ and require complicated coding techniques for things such as thread synchronization. Most developers work a level above ISAPI and utilize frameworks such as ASP and ASP.NET. While it is likely that you will never be required to write an ISAPI component, it is still important that you understand how ISAPI components fit into the big picture.

Application Pools and the IIS Worker Process

IIS provides a flexible infrastructure for managing worker processes by using application pools. An application pool is a configurable entity that allows you to control how IIS maps IIS Web sites and virtual directories to instances of the IIS worker process. Note that instances of the IIS worker process are launched using an executable named w3wp.exe, as shown in Figure 2-2.

Figure 2-2: IIS uses a device driver named HTTP.SYS to route incoming requests to the proper application pool.

The routing architecture of IIS is controlled by a kernel-level device driver named http.sys. This device driver listens for incoming HTTP requests and uses information in the IIS metabase to route them to whatever instance of w3wp.exe is associated with the target application pool. If http.sys determines that the target application pool doesn’t have a running instance of w3wp.exe, it launches a new instance on demand to process the request.

Each IIS Web site and virtual directory can be configured to run in its own isolated application pool. Conversely, you can configure many different IIS Web sites and virtual directories to run in the same application pool for greater efficiency. The key observation you should make is that a tradeoff exists between isolation and efficiency. To achieve greater isolation means you must run more instances of w3wp.exe, which compromises efficiency. To achieve greater efficiency means you must map multiple IIS Web sites and virtual directories to fewer instances of the IIS worker process, which compromises isolation.

Every application pool has an important setting known as the application pool identity. The application pool identity is configured with a specific Windows user account that is either a local account on the Web server or a domain account within an Active Directory directory service domain. When http.sys launches a new instance of w3wp.exe for a specific application pool, it uses the application pool identity to initialize a Windows security token that serves as the process token. This is important because it establishes the “runs as” identity for code that runs within the IIS worker process.

By default, IIS uses the identity of the local Network Service account when you create a new application pool. However, you can configure the application pool identity by using any other user account you like. When deploying Web sites based on ASP.NET and WSS, it is recommended that you configure the application pool identity with a domain account instead of the Network Service account. This is especially true in a Web farm environment when you need to synchronize the identity of an application pool across multiple front-end Web servers in the farm.

Restarting an Application Pool

When developing for ASP.NET and WSS, you will occasionally find it necessary to restart the application pool that you are using to test your code. This might be the case when you need to refresh an XML file within a feature definition you are developing, or you might need to reload a new version of an assembly DLL from the Global Assembly Cache. You can restart all of the processes associated with IIS by running the following command from the command line:

 IISRESET

You can alternatively restart just the process associated with a specific application pool by running a VB Script macro named iisapp.vbs that has been a standard part of the IIS 6.0 installation since Windows Server 2003 Service Pack 1. You must run this script by using a scripting host, such as cscript.exe. When you call cscript.exe and then include the path to iisapp.vbs, you can restart a specific application pool by passing the /a parameter along with the name of the IIS application pool.

 cscript.exe c:\windows\system32\iisapp.vbs /a "DefaultAppPool"

The main advantage of using this technique is that it is faster than a full IISRESET command, which restarts all processes associated with IIS. Using this command instead of an IISRESET command can save you a few seconds here and there.