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.
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.
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.
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.
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 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(interrupt/stop).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.
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.
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.
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.
ASP.NET 2.0 Framework
The ASP.NET Framework is implemented as an ISAPI extension named aspnet_isapi.dll. The basic configuration for ASP.NET involves registering application maps for common ASP.NET file extensions including .aspx, .ascx, .ashx, and .asmx at the level of an IIS Web site or virtual directory. When IIS sees an incoming request targeting a file with one of these extensions, it forwards the request to aspnet_isapi.dll, which effectively passes control over to the ASP.NET Framework.
Once the ASP.NET page parser builds the source file for an .aspx page, it can then compile it into a DLL. This compilation occurs automatically the first time the .aspx file is requested.Once the ASP.NET runtime has compiled an .aspx file into a DLL, that copy of the DLL can be used for all subsequent requests that target the same .aspx file. However, the ASP.NET runtime monitors the datetime stamp on the .aspx file and retriggers the compilation process to rebuild the DLL if it sees that the associated .aspx file has been updated.A page that links to a master page is known as a content page.
HTTP Request Pipeline
Figure 2-4 displays a picture of the HTTP Request Pipeline and its three replaceable component types: HttpHandler, HttpApplication, and HttpModule. As requests come in, they are queued up and assigned to a worker thread that then processes the request by interacting with each of these component types.
The ultimate destination of any request is the endpoint, which is modeled in the HTTP
Request Pipeline by using an HttpHandler class, which implements the IHttpHandler
interface. As a developer, you can create a custom HttpHandler component and plug it into the HTTP Request Pipeline by adding configuration elements to the web.config file.The HTTP Request Pipeline places an HttpApplication component in front of the HttpHandler.
On an application-wide basis, incoming requests are always routed through the HttpApplication before they reach the target HttpHandler, thus giving the HttpApplication the ability to preprocess any request no matter which HttpHandler it is being routed to. This preprocessing stage is handled through a series of events that are defined inside the HttpApplication class
such as BeginRequest, AuthenticateRequest, and AuthorizeRequest.
However, you can replace this standard component by creating a file named global.asax and placing it in the root directory of the hosting ASP.NET application. For example, you can create a global.asax that looks like the following:
protected void Application_AuthenticateRequest(object sender, EventArgs e) {
// your code goes here for request authentication
}
protected void Application_AuthorizeRequest(object sender, EventArgs e) {
// your code goes here for request authorization
}
The third replaceable component type in the HTTP Request Pipeline is the HttpModule. The HttpModule is similar to the HttpApplication component in that it is designed to handle events defined by the HttpApplication class and is processed before control is passed to any HttpHandler classes. For example, you can create a custom HttpModule component to handle request-level events such as BeginRequest, AuthenticateRequest, and AuthorizeRequest. As with the HttpHandler, an HttpModule class is defined with an interface. You can create a class that implements the IHttpModule interface and plug it into the HTTP Request Pipeline by adding configuration elements to the web.config file.
Whereas custom HttpApplication components can be defined as simple text files with an
.asax extension, custom HttpModule components are always compiled as classes within
assembly DLLs. To add a custom HttpModule component into the HTTP Request Pipeline,
you then add entries into a web.config file.
HttpModule components can be configured at the machine level. In fact, the ASP.NET
Framework ships with several different HttpModule components that are automatically
configured at the machine level to provide ASP.NET functionality for things such as Windows authentication, Forms authentication, and output caching.
The final component that we want to discuss with respect to the HTTP Request Pipeline is HttpContext. As ASP.NET initializes a request to send to the HTTP Request Pipeline, it creates an object from the HttpContext class and initializes it with important contextual information.The Object contains such as Request, User, and Response.
HttpContext currentContext = HttpContext.Current;
string incomingUrl = currentContext.Request.Url;
string currentUser = currentContext.User.Identity.Name;
currentContext.Response.Write("Hello world");
WSS Integration with ASP.NET
WSS integrates with ASP.NET at the level of the IIS Web site. Each IIS Web site in which you intend to host WSS sites must go through a one-time transformation process in which it is configured to become what WSS terminology refers to as a Web application. This transformation process involves adding IIS metabase entries and a WSS-specific web.config file to the root directory of the hosting IIS Web site. Once the transformation is completed, WSS extends the routing architecture of IIS and ASP.NET to properly route all incoming requests through the WSS runtime.
Creating a Web application requires a significant number of changes to the file system and the IIS metabase on each front-end Web server. In a Web farm environment, these changes are automatically mirrored across each front-end Web server in the farm by the WSS runtime.
Once a Web application is created, it is no longer necessary to touch the file system or IIS metabase of the front-end Web server when creating, updating, and deleting sites or site collections. The WSS architecture makes it possible to provision new sites and site collections simply by adding entries to the configuration database and a content database. It is this aspect of the WSS architecture that gives it significant management and provisioning advantages
over ASP.NET.
Web Applications
Two primary ways exist to create a Web application by using either the WSS Central Administration Application or the stsadm.exe command-line utility. First, you can create a Web application by converting an existing IIS Web site. Alternatively, you can create a new Web application from scratch and let WSS create the new IIS Web site for you behind the scenes. In either case, WSS configures the resulting IIS Web site by adding an IIS application map and creating several virtual directories. WSS also copies a global.asax file and web.config file to the root directory of the hosting IIS Web site.
WSS must add an IIS application map to each Web application to ensure that each and every incoming request is initially routed to the ASP.NET runtime. Remember that the default configuration for ASP.NET only registers application maps for requests with well-known ASP.NET file extensions such as .aspx, ascx, .ashx, and .asmx. Therefore, WSS configures the hosting IIS Web site with a wildcard application map to route all incoming requests to aspnet_isapi.dll, including those requests with non-ASP.NET extensions such as .doc, .docx, and .pdf.
Because every request targeting a Web application is routed through aspnet_isapi.dll, the request gets fully initialized with ASP.NET context. Furthermore, its processing behavior can be controlled by using a custom HttpApplication object and adding configuration elements to the web.config file. The WSS team uses standard ASP.NET techniques to extend the HTTP Request Pipeline by using several custom components, as shown in Figure 2-5.
First, you can see that WSS configures each Web application with a custom HttpApplication object by using the SPHttpApplication class. Note that this class is deployed in the WSS system assembly Microsoft.SharePoint.dll. WSS integrates this custom application class by creating a custom global.asax file at the root of the Web application that inherits from SPHttpApplication.
You can see that the standard WSS web.config file configures SPRequestModule so that it is the first HttpModule to respond to application-level events in the HTTP Request Pipeline of ASP.NET. If you examine the web.config file for a WSS Web application, you will see that WSS adds back in several of the standard HttpModule components from the ASP.NET Framework that deal with things such as output caching and various types of authentication.
SPVirtualPathProvider
One of the strengths of WSS over ASP.NET is its ability to provision and customize pages
within a site without having to make any changes to the local file system of the front-end Web
server. This capability of WSS to provision and customize pages is made possible by storing
customized versions of .aspx files and .master files inside the content database and retrieving
them on demand when they are needed to process an incoming page request.
when the same page is requested, WSS must retrieve the contents of this customized page definition from the content database and pass it along to the ASP.NET runtime for parsing. We will now explain the architectural details that make this possible.
ASP.NET 2.0 introduced a new pluggable component type known as a virtual path provider. The idea behind a virtual path provider is that it abstracts the details of where page files are stored away from the ASP.NET runtime. By creating a custom virtual path provider, a developer can write a custom component that retrieves ASP.NET file types, such as .aspx and .master files, from a remote location, such as a Microsoft SQL Server database. Once a virtual path provider retrieves the contents of an .aspx page, it can pass it along to the ASP.NET runtime for parsing.
SPVirtualPathProvider is able to retrieve an ASP.NET page file from the content database, such as default.aspx, and then pass it along to the ASP.NET page parser. The SPVirtualPathProvider class works together with another class named the SPPageParserFilter to supply processing instructions to the ASP.NET page parser. For example, the SPPageParserFilter component controls whether the ASP.NET page parser compiles the ASP.NET page into an assembly DLL or whether it processes the page in a no-compile mode that is introduced with ASP.NET 2.0.
Imagine that you have just created 100 new WSS sites from the Blank Site template. If none of these sites requires a customized version of its home page (default.aspx), would it still make sense to copy the exact same page definition file into the content database 100 times? The answer to this question is obviously no. Fortunately, pages within a WSS site such as default.aspx are based on page templates that live on the file system of the front-end Web server. Page templates are used to provision page instances within the context of a site, such as the page that is accessible through a specific URL like http://litwareinc.com/default.aspx.
When a page instance is initially provisioned from a page template, WSS doesn’t need to store a copy of it in the content database because WSS can load the page template from the file system of the Web server and use it to process any request for an uncustomized page instance.
Therefore, you can say that page ghosting describes the act of processing a request for an uncustomized page instance by using a page template loaded into memory from the file system of the front-end Web server.
Page ghosting is valuable because it eliminates the need to transfer the contents of a page definition file from the SQL Server computer with the content database to the front-end Web server computer. Page ghosting also makes it possible to process the home pages for thousands of different sites by using a single page template that is compiled into an assembly DLL and loaded into memory in the IIS worker process just once per Web application. Both of these optimizations are key factors in the scalability of WSS in high-traffic environments running thousands or tens of thousands of sites.
Customized pages are sometimes referred to as unghosted pages.
SPVirtualPathProvider that determines whether the page being requested has been
customized. The SPVirtualPathProvider makes the decision whether to process a page as a ghosted or an unghosted page.
The new architecture introduced in WSS 3.0, which includes the SPVirtualPathProvider and the ASP.Net page parser, should be seen as one of the more significant architectural enhancements over WSS 2.0.
When WSS converts an IIS Web site into a Web application, it creates several virtual directories. These virtual directories, including the _controltemplates directory, the _layouts directory, the _vti_bin directory, and the _wpresources directory, are used by various aspects of the WSS runtime. The _wpresources virtual directory provides a repository for resource files that are deployed along with Web Parts.
Application pages are served up from the _layouts directory.
No comments:
Post a Comment