WSS3.0技术内幕-----SharePoint体系结构(3)(翻译)

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 的层面。