SharePoint basics 7-Integration of SharePoint infrastructure with ASP. NET

As you build WSS and ASP. net, you will understand the high-level design goal of WSS, that is, Asp. net Framework adds practical value. WSS in ASP.. NET and adds important practical value to environments such as frequent and continuous creation, update, and deletion of websites. WSS is still in ASP. added a dimension for site element creation, allowing site administrators to quickly create pages, lists, and document libraries in the context of the site.

 

WSS and ASP.. Net integration. every IIS site that you want to use to store WSS sites must undergo a conversion process. During this conversion process, the IIS Site will be set to something called Web Application in WSS terms. this conversion process involves adding an entry to IIS metabase and adding a WSS-related web. config file to the root directory of the IIS Site. once the conversion process is complete, WSS extends IIS and ASP. net routing architecture. The extended method is to use the WSS runtime to perform appropriate routing operations on requests.

Next we will discuss how WSS applications are configured. however, before you go into these details, we hope you can make an important observation. specifically, from the perspective of manageable and measurable capabilities, we hope you will consider how Web applicaiton is embedded into the WSS architecture as a whole.

 

WSS web application creation is an important management task that requires the permissions of field administrators. to create a web application, you must make a series of important changes to the file system and IIS metabase on each Web Front-End Server. in the web environment, these modifications are automatically mirrored to other web front-end servers when the WSS is running. the procedure for creating a web application is only required when WSS is initially installed and configured.

 

Once a web application is created, you do not need to create, update, or delete the site or site set before touching the file system on the front-end server and the IIS metabase. the WSS architecture makes it possible to simply create a new site and site integration by adding some data to the configuration database and content database. this is the aspect of the WSS architecture, which makes the WSS far more manageable and creative than ASP. net. the benefits of manageability added here are especially evident in the Web environment.

 

Web Applications

====================

There are two main ways to create a web application: One is through WSS central administration (WSS Management Center), and the other is by running stsadm. EXE command line tool. first, you can create a web application by converting an existing IIS Site. you can also create a new Web application from scratch to allow WSS to create a new IIS Site for you in the background. in any case, WSS will add an IIS application ing under the IIS Site and add some virtual directories. WSS also copies global. asax file and web. config file to the root directory of the IIS Site.

 

WSS must add Iis Application ing for each web application to allow all requests to pass through ASP. net route. remember, the default ASP. net configuration only registers ASP. net file suffix (. aspx, ascx ,. ashx, and. asmx) Application ing. therefore, the WSS configuration uses a * wildcard to configure the host IIS Site, so that all requests are processed by aspnet_isapi.dll. In this way, non-aspfiles are suffixed with. Doc ,. docx, and ASP.. net.

 

Because all requests directed to the Web application are routed through aspnet_isapi.dll, ASP is used completely for requests. net context to initialize. further, the request processing behavior can be controlled by the HTTP application object defined by WSS, And the configuration element is also added to the web. config file. the WSS team uses standard ASP. by using several custom components, such as HTTP request pipeline.

First, you can see that WSS configures each web application. By using the sphttpapplication class, you can set a custom httpapplication object. note that this class is in the WSS system assembly Microsoft. sharepoint.. WSS creates a custom global under the root directory of the Web application. the asax file to integrate the Custom Application class. The web application class inherits from the sphttpapplication.

<%@ Application Inherits="Microsoft.SharePoint.ApplicationRuntime.SPHttpApplication" %>

 

In addition to custom httpapplication objects, The WSS architecture also uses a custom httphandler and a custom httpmodule. the two WSS-related components are stored on the web. the standard entry is added to the config file and integrated into the HTTP request pipeline. check the following XML snippet, which is the standard web used by wss3.0 web application. the.

<?xml version="1.0" encoding="utf-8" ?><configuration>  <system.web>    

 
The WSS team members created their own httpmodule called sprequestmodule to initialize various WSS runtime environments. you can see the standard WSS web. the sprequestmodule configured in the config file, so it is the first in ASP. the HTTP request pipeline of net responds to the HTTP module of the application layer event. if you check the web of the WSS web application. config file, you will see that WSS has added many ASP. the standard httpmodule In the. NET Framework is used to process modules such as the output cache and authentication method.
 
Standard WSS web. the Config File also registers an httphandler called sphttphandler and configures it with a "*" as the path. this allows the WSS to use sphttphandler as the unique endpoint of all incoming requests.
 
Standard Web. config file of Web application
====================
In the previous section, you see the standard ASP.. Net configuration element for Web applications. config file. however, WSS extends the standard ASP. net web. the Config File also has a lot of work done, and it also adds custom SharePoint section. check the following XML snippet, which shows the web. the SharePoint section of the config file is also ASP. net
Elements required for scaling configuration information.
<?xml version="1.0" encoding="utf-8" ?><configuration>  <configSections>    <sectionGroup name="SharePoint">      <section name="SafeControls" type="..." />      <section name="RuntimeFilter" type="..." />      <section name="WebPartLimits" type="..." />      <section name="WebPartCache" type="..." />      <section name="WebPartWorkItem" type="..." />      <section name="WebPartControls" type="..." />      <section name="SafeMode" type="..." />      <section name="MergedActions" type="..." />      <section name="PeoplePickerWildcards" type="..." />    </sectionGroup>  </configSections>  <SharePoint>    <SafeMode />    <WebPartLimits />    <WebPartCache />    <WebPartControls />    <SafeControls />    <PeoplePickerWildcards />    <MergedActions />    <BlobCache />    <RuntimeFilter />  </SharePoint></configuration>

 
The folding configuration elements in the SharePoint section are read by multiple components during WSS running. for each element collapsed in the SharePoint section, an element in configsections defines which configuration class is used to read the information at runtime. this makes it possible for different WSS runtime components to read the specific configuration information of the WSS when processing a request.
 
Spvirtualpathprovider
============================
WSS is better than ASP. one aspect of net is that it can create and customize pages on the site without making any changes to the local file system on the Web Front-End Server. the ability of WSS to create and modify pages is achieved in two ways: 1. store customized versions of aspx files and master files in the content database; 2. these files are obtained when they are requested by an incoming request.
 
Consider how page customization works in a simple WSS. imagine you need to modify the homepage (default. aspx) HTML layout. when you use SharePoint designer to modify and save the page, WSS writes the content of the customized page to the content database. after that, when the same page is requested, WSS must get the customized page definition from the content database and then hand it to ASP.. Net runtime to parse. now, Let's explain the architecture details that may have taken place in this process.
 
ASP. NET 2.0 introduces a pluggable component called virtual path provider.Virtual Path providerThe idea behind it is to let it store the page somewhere from ASP.. Net runtime. create a custom virtual path provider, and developers can write a custom component to obtain ASP from a remote address (such as Microsoft SQL Server database.. Net file type (such as aspx and master files ). once a virtual path provider obtains the content of An ASPX page, it passes the content to ASP.. Net runtime to parse.
 
The WSS team created a virtual path provider called spvirtualpathprovider and integrated it into every web application. the spvirtualpathprovider class is integrated into ASP through sprequestmodule.. Net request processing infrastructure. more specifically, the sprequestmodule component contains code to register the spvirtualpathprovider to ASP. NET framework, because this is the work of the sprequestmodule when initializing the web application. demonstrate the role of spvirtualpathprovider.

 
As you can see, spvirtualpathprovider can get an asp from the content database. NET page file, and then pass it to ASP. NET page analyzer. spvirtualpathprovider works with another class called sppageparserfilter, Which is ASP. NET page analyzer provides processing commands. for example, the sppageparserfilter component can control ASP. NET page analyzer whether ASP.. NET page is compiled into the Assembly DLL, or ASP. the non-compilation mode introduced by NET 2.0. in the future, you will see how. add entries in config to tell sppageparserfilter how to process the page.
 
The spvirtualpathprovider component plays a key role in the entire WSS architecture. as you can see, it provides support for page customization. it also supports an important optimization called page ghosting. This page Ghosting is a key factor that allows the WSS field to expand and display thousands of pages. let me provide a quick example to illustrate how page ghosting works.
 
Imagine you have just created 100 new WSS sites using a blank website template. if these sites do not have a homepage (default. aspx), is it reasonable to accurately define the pages to the content database for 100 times? The answer to this question is obviously no. fortunately, pages in WSS are like default. aspx is based on the page template in the file system of the Web Front-End Server. A page template is used to create page instances in the context of a site. For example, a page accessed through a specific URL is likeHttp://litwareinc.com/default.aspx.
 
When a page instance is created from a page template, WSS does not need to store a copy of the page in the content database, because WSS can load the page template from the file system on the Web Front-end server, and then use this template to process any request pointing to an uncustomized page instance. therefore, you can say that page ghosting describes an action to process requests directed to uncustomized pages. This action is completed by loading the page template to the memory on the front-end server.
 
Page Ghosting is valuable because it reduces the need to get file-defined content from the content database of the SQL server computer and pass it to the Web Front-End Server. Page ghosting also makes useA page template compiled as DLL and loaded to the memory of the IIS Worker ProcessIt is possible to process the homepage of thousands of different sites, and each web application only needs to process it once. these two optimizations are critical factors for improving the scalability of WSS when running tens of thousands of sites in a high-load environment.
 
When you use SharePoint designer to modify a page and save the customized page to the content database, you can eliminate the possibility of using page ghosting. as an alternative, the spvirtualpathprovider provided to You must retrieve the page file of the custom version from the content database, as shown in. for this reason, customized pages are sometimes called unghosted pages.
 
Now that you have understood how WSS processes the requested ghosted and non-ghosted page, you should observe the role played by spvirtualpathprovider. the spvirtualpathprovider determines whether the requested page is customized. spvirtualpathprovider determines whether to process the request by processing the ghosted page. furthermore, all page ghosting and unghosting are applied to ASP.. NET is hidden during runtime and represents a dimension of WSS's additional value.
 
 
Postscript: This is the most important article in this series. it is important to understand the architecture of SharePoint. Please read it carefully. on msdn, an excerpt from some texts (in English) is used as an article about SharePoint infrastructure.