Web Applications
两种主要方式存在因使用WSS的中央管理的应用程序或Stsadm.exe命令行实用程序Web应用程序。首先，您可以通过转换现有IIS网站Web应用程序。或者，您可以从头开始创建新的Web应用程序，让WSS的创建新的IIS Web站点为您在幕后。在任何情况下，WSS的配置，加入一个IIS应用程序映射和创建多个虚拟目录所产生的IIS网站。 WSS还拷贝一个Global.asax文件和Web.config文件的存取IIS Web站点的根目录。
WSS的必须添加一个IIS应用程序映射到每个Web应用程序，以确保每一个最初传入的请求路由到ASP.NET运行。请记住，ASP.NET的唯一的注册与著名ASP.NET文件扩展名，如应用程序映射请求的默认配置的。aspx，ascx，。ashx的，和。asmx文件。所以，WSS的配置主机的IIS应用程序映射通配符路由网站所有传入请求，包括那些与非的请求，如ASP.NET扩展到Aspnet_isapi.dll.doc和.docx文档和.pdf。
由于针对每个请求一个Web应用程序是通过aspnet_isapi.dll的路由，请求得到充分ASP.NET中初始化。此外，它的处理行为是可以控制使用自定义HttpApplication对象和配置元素添加到Web.config文件。在WSS团队使用标准的ASP.NET技术，以延长使用多种自定义组件的HTTP请求管道，如下图所示：
首先，你可以看到，WSS的配置，每个使用SPHttpApplication类的自定义HttpApplication对象Web应用程序。请注意，这个类是在WSS的系统组装Microsoft.SharePoint.dll的部署。 WSS的集成通过创建自定义的global.asax在Web应用程序，从SPHttpApplication继承根文件此自定义应用程序类。
<@Application Inherits="Microsoft.SharePoint.ApplicationRuntime.SPHttpApplication" >
除了包括自定义HttpApplication对象，在WSS建筑使用自定义的HttpHandler和自定义HTTP模块。这两个WSS的特定组件集成到HTTP请求管道为Web应用程序使用标准的条目在web.config文件中。检查下面的XML片段，它是从标准的web.config采取文件通过一个WSS 3.0 Web应用程序使用。
<configuration>
<system.web>
<httpHandlers>
<remove verb="GET,HEAD,POST" path="*" />
<add verb="GET,HEAD,POST" path="*" type="Microsoft.SharePoint.ApplicationRuntime.SPHttpHandler, ..." />
</httpHandlers>
<httpModules>
<clear />
<add name="SPRequest" type="Microsoft.SharePoint.ApplicationRuntime.SPRequestModule, ..." />
<!-- other standard ASP.NET httpModules added back in -->
</httpModules>
</system.web>
</configuration>
在WSS团队成员创造了他们自己的HttpModule名为SPRequestModule初始化的WSS运行环境的各个方面。你可以看到标准的WSS的web.config文件配置SPRequestModule，以便它是第一个响应HTTP模块应用在HTTP请求管道的ASP.NET级别活动。如果您检查了一个WSS Web应用程序的web.config文件，你会发现WSS的加回在从ASP.NET框架标准的HttpModule组件几个处理的事情，如输出缓存和各种类型的身份验证。标准WSS的web.config文件也注册一个HttpHandler名为SPHttpHandler并配置与路径“*它”。这使WSS来提供，作为所有传入请求单一的端点SPHttpHandler类。正如你所看到的，WSS的架构是透过HTTP请求延长管道。这使得WSS来充分地利用ASP.NET框架的基本能力，同时还对每个请求所针对的是Web应用程序的监控。
Standard web.config File for a Web Application
在本章上一节中，你看到了一个Web应用程序的Web.config文件包含标准的ASP.NET配置元素。然而，WSS的更进一步扩展标准的ASP.NET web.config中的自定义SharePoint部分文件格式。检查下面的XML片段，显示在configSections元素由ASP.NET扩展的需要配置信息的web.config文件共享点段和元素。
<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>
是的配置在SharePoint部分嵌套是由各个组成部分WSS的运行时读取的元素。在SharePoint内每个元素嵌套节，有一个的configSections元素定义了配置类部分元素用于阅读本在运行时的信息。这可以使运行的WSS的各个组成部分阅读本WSS的具体配置信息，在处理请求。您会看到整本书的几个发展技术，要求增加或改变在Web.config文件的共享点部分元素。
SPVirtualPathProvider
超过ASP.NET WSS的优势之一是它能够提供和定制网站的网页内，无需进行任何正面的本地文件系统前端Web服务器的变化。这种WSS的能力，提供和定制网页是通过存储成为可能定制的版本。里面的内容数据库aspx文件和。主文件和检索时，需要处理传入的页面请求他们的需求。
考虑一个简单的例子是如何工作的页面定制在WSS。假设你想修改的主页（Default.aspx的特定网站）通过使用Microsoft Office SharePoint设计HTML布局。当您修改和保存网页使用SharePoint Designer中，WSS的写到自定义网页的全部内容定义的内容数据库。这一点后，当相同的页面被请求时，WSS的必须检索本从内容数据库自定义页面定义的内容，并通过它传递给了解析ASP.NET运行。我们现在解释的建筑细节，使这成为可能。
ASP.NET 2.0中引入一种新的可插拔组件类型作为一个虚拟路径提供众所周知的。背后的虚拟路径提供者的想法是，它抽象的详细资料，网页文件存放在远离ASP.NET运行库。通过创建自定义虚拟路径提供者，开发人员可以编写一个自定义组件，检索ASP.NET文件类型，如。aspx和。主文件，从远程位置，如Microsoft SQL Server数据库。一旦虚拟路径提供检索的。aspx页的内容，可以通过它传递给了解析ASP.NET运行。
在WSS团队创建了一个虚拟路径提供名为SPVirtualPathProvider即到每一个Web应用程序集成。该SPVirtualPathProvider类是集成到ASP.NET处理的SPRequestModule基础设施的要求。更具体地说，SPRequestModule组件包含代码，以注册使用ASP.NET框架，正如它的工作SPVirtualPathProvider类初始化一个Web应用程序。图2-6显示了图，描绘了SPVirtualPathProvider作用。
正如你所看到的，SPVirtualPathProvider可以检索从ASP.NET页的内容，如数据库的Default.aspx，文件，然后它传递到ASP.NET页分析器。该SPVirtualPathProvider类作品连同其他类命名SPPageParserFilter提供处理指示ASP.NET页分析器。例如，SPPageParserFilter组件控制是否ASP.NET页分析器编译成一个程序集DLL中的ASP.NET页或是否工序，不编译模式下使用ASP.NET 2.0中引入的页面。在下一章中，您将看到如何添加到web.config文件，告诉SPPageParserFilter如何处理进入的网页。
在SPVirtualPathProvider组件起着WSS的整体架构的重要作用。正如你所看到的，它提供的页面定制支持的基础。它也支持一个重要的优化，页面重影，这是一个允许一个WSS农场规模出网页上的一个农场内的所有网站数以万计的关键因素众所周知的。让我提供了一个快速的例子来说明页面鬼影工作。
假设你刚刚创建的100个新的WSS的空白网站从网站模板。如果这些网站都需要有其主页（Default.aspx的）定制版本，将它仍然是有意义的复制到数据库中的内容完全相同的页面定义文件100倍？对这个问题的答案显然是否定的。幸运的是，在一个WSS站点的网页，例如Default.aspx的是基于网页模板，在前面的文件系统前端Web服务器现场。页面模板使用在一个网站的背景下，提供网页的实例，例如网页是通过像http://litwareinc.com/default.aspx特定URL访问。
当一个页面实例最初是从一个页面模板置备，WSS的不需要的内容存储在数据库中的副本，因为WSS的可以加载页面模板从Web服务器的文件系统，并用它来处理任何请求非自定义页面的一个实例。因此，可以说该网页鬼影描述了使用页面模板处理对非自定义页面的请求采取行动，例如加载到内存，从前面的文件系统前端Web服务器。
Page ghosting是有价值的，因为它无需转让从SQL Server与数据库的内容，前端的电脑页面定义文件的内容Web服务器计算机。Page ghosting还能够处理使用单页模板被编译到一个程序集加载DLL和在IIS工作进程到内存中只有一次每个Web应用程序的不同地点的成千上万的网页上。这些优化都是在高流量环境中运行的数以千计或数以万计的网站WSS的可扩展性的关键因素。
当您修改网页并保存它的一个内容数据库中的自定义版本使用SharePoint Designer，您消除页面重影的可能性。相反，必须提供SPVirtualPathProvider检索内容数据库页面的定制版本，如图2-6所示。为此，自定义页面有时被称为unghosted的网页。
现在，您知道如何WSS的过程为幻像和unghosted网页的请求，您应该遵守的重要作用，是由SPVirtualPathProvider作用。这是SPVirtualPathProvider，决定是否被请求的网页已被定制。该SPVirtualPathProvider作出决定是否要处理的页面作为幻影或unghosted页面。此外，所有的网页鬼影方面unghosting是隐藏的ASP.NET运行时，代表着增值WSS的层面。