As the High Level Object Model
section later in this article shows in more detail, the highest level
of organization in a SharePoint deployment, other than the farm itself,
is the web application. A web application in SharePoint terminology is closely related to what is called a website
in IIS terminology. An IIS website monitors for incoming requests
through a particular port, and it checks for a particular host header or
IP address, or both. Every SharePoint Foundation web application is
hosted in an IIS website that has the same name as the web application.
It can be helpful, especially when you are trying to see the relation
between SharePoint and IIS from a high and broad perspective, to think
of the SharePoint web application and its corresponding IIS website as a
single entity.
Nevertheless, the SharePoint web application and the IIS website are not quite the same thing (and they are represented by different classes in the SharePoint object model: the SPWebApplication class and the SPIisWebSite class). For one thing, although there is usually a one-to-one relation between SharePoint web applications and IIS websites, this is not always the case. It is possible to extend a SharePoint web application to multiple IIS websites, although that is not a common design.
Figure 2 shows the IIS websites and application pools on a SharePoint Foundation front-end web server.
Just as in any application that is built on the
ASP.NET-IIS integrated pipeline, when a front-end web server receives a
request from a client for a page or other resource in a SharePoint site,
the request is passed through a pipeline of units that process the
request. This processing includes authenticating the user, verifying the
user’s authorization, building the response, sending the response, and
finally, logging the request. For more information about the integrated
pipeline, see ASP.NET Integration with IIS 7.
The response to any request is produced by an HTTP handler object. Requests are assigned to one or another HTTP handler object (or to a handler factory class that creates HTTP handler objects) depending on the resource requested and the HTTP verb in the request. The assignment is determined by a stack of configuration files named applicationhost.config, machine.config, and web.config.
The request pipeline also contains HTTP modules. Modules are assemblies that typically contain one or more event handlers or define new events that other modules can handle. An HTTP module can register for one or more events in the life cycle of the request. They are often used to preprocess requests or postprocess the response. The result of a module’s preprocessing is stored in the HttpContext object. For example, the value of the User property is produced by an authentication module.
The processing of a request by HTTP modules and an HTTP handler is governed by an HttpApplication object or an object derived from that class. SharePoint installs a global.asax file in the root of each web application (IIS website) that identifies SPHttpApplication as the class from which an HTTP application object is created.
SharePoint also modifies the pipeline with a custom HTTP module (SPRequestModule), and with changes to the default applicationhost.config file. For detailed information about SharePoint and the integrated pipeline, see Microsoft SharePoint Foundation as an ASP.NET Application.
Figure 3 shows the relations among the classes that handle HTTP requests for a SharePoint front-end web server.
In addition to its use of the integrated pipeline,
SharePoint uses some other features of IIS and technologies from
ASP.NET. Among them are the following:
Nevertheless, the SharePoint web application and the IIS website are not quite the same thing (and they are represented by different classes in the SharePoint object model: the SPWebApplication class and the SPIisWebSite class). For one thing, although there is usually a one-to-one relation between SharePoint web applications and IIS websites, this is not always the case. It is possible to extend a SharePoint web application to multiple IIS websites, although that is not a common design.
Figure 2 shows the IIS websites and application pools on a SharePoint Foundation front-end web server.
Figure 2. IIS Manager on a SharePoint Foundation front-end web server
Just as in any application that is built on the
ASP.NET-IIS integrated pipeline, when a front-end web server receives a
request from a client for a page or other resource in a SharePoint site,
the request is passed through a pipeline of units that process the
request. This processing includes authenticating the user, verifying the
user’s authorization, building the response, sending the response, and
finally, logging the request. For more information about the integrated
pipeline, see ASP.NET Integration with IIS 7.The response to any request is produced by an HTTP handler object. Requests are assigned to one or another HTTP handler object (or to a handler factory class that creates HTTP handler objects) depending on the resource requested and the HTTP verb in the request. The assignment is determined by a stack of configuration files named applicationhost.config, machine.config, and web.config.
The request pipeline also contains HTTP modules. Modules are assemblies that typically contain one or more event handlers or define new events that other modules can handle. An HTTP module can register for one or more events in the life cycle of the request. They are often used to preprocess requests or postprocess the response. The result of a module’s preprocessing is stored in the HttpContext object. For example, the value of the User property is produced by an authentication module.
The processing of a request by HTTP modules and an HTTP handler is governed by an HttpApplication object or an object derived from that class. SharePoint installs a global.asax file in the root of each web application (IIS website) that identifies SPHttpApplication as the class from which an HTTP application object is created.
SharePoint also modifies the pipeline with a custom HTTP module (SPRequestModule), and with changes to the default applicationhost.config file. For detailed information about SharePoint and the integrated pipeline, see Microsoft SharePoint Foundation as an ASP.NET Application.
Figure 3 shows the relations among the classes that handle HTTP requests for a SharePoint front-end web server.
Figure 3. SharePoint customizations of the HTTP request pipeline
In addition to its use of the integrated pipeline,
SharePoint uses some other features of IIS and technologies from
ASP.NET. Among them are the following:-
Active pages (aspx files):
SharePoint pages are ASP.NET pages. SharePoint controls are referenced
in the page markup with a registered "SharePoint" prefix. (For more
information about the ASP.NET page parsing and compiling system, see Understanding ASP.NET Dynamic Compilation.
Note that the standard page parser of ASP.NET compiles a page the first
time it is requested unless the page is explicitly set not to be
compiled. However, SharePoint pages that have been customized by a
SharePoint website owner are stored in the SharePoint content database
and are not compiled when they are accessed. SharePoint uses a custom
virtual path provider, an internal class named SPVirtualPathProvider that is derived from VirtualPathProvider, to locate a requested page from either the file system or the content database and load it.
-
The master page/content page distinction: A SharePoint page is a merger of a master page and a content page. For more information, see ASP.NET Master Pages and Master Pages. (For some SharePoint Server pages, a third foundational page is involved in the merger, a page layout.)
-
Web Parts: Web Parts
actually originated in an early version of SharePoint. The idea was
adopted by ASP.NET. In most SharePoint Web Part development situations,
we recommend that you use the ASP.NET version, but in some situations
the original SharePoint incarnation is a better choice. The SharePoint
UI for mobile devices also uses the ASP.NET concept of registered Web
Part adapters. For more information about Web Parts in SharePoint, see Building Block: Web Parts and Building Block: Mobile Pages, Controls, and Adapters.
-
User controls (.ascx files): Many SharePoint web controls and Web Parts are built with ASP.NET user controls.
-
Web services (.asmx files):
Some, but not all, SharePoint web services are implemented as ASP.NET
ASMX services. For more information about ASP.NET web services in
SharePoint, see ASP.NET Web Services.
-
Virtual directories:
SharePoint maps several virtual directories in each IIS website to
physical folders in the SharePoint root, which is the folder
%ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\.
When you as a developer need to provision SharePoint web applications
with images, resource files, and other important files, they are
deployed to the appropriate physical folder on the front-end web
servers. This process is handled automatically by the solution
deployment mechanism of SharePoint. For example, user controls are
deployed to %ProgramFiles%\Common Files\Microsoft Shared\web server
extensions\14\ControlTemplates (or a subfolder), which is mapped to the
virtual directory _controltemplates.
-
SharePoint has its own installation and deployment model. For more information, see SharePoint Deployment Models later in this article.
-
SharePoint makes a distinction, unknown in ASP.NET, between application pages and site pages. For more information, see Pages, Parsing, and Safe Mode later in this article.
-
SharePoint has its own systems for modifying web.config files. For more information, see Working with Web.config Files.
-
The ASP.NET worker process model is modified in SharePoint. See Process and Execution Trust Model later in this article.
0 comments:
Post a Comment