深入剖析 Sharepoint

如同电子邮件消息传递 改变了业务通信一样，基于 Web 的协作正在改变着人们协同工作和共享信息的方式。作为一个不错的示例，让我们来看一看 SharePoint 技术所提供的功能。通过使用 Microsoft Windows SharePoint Services (WSS) 3.0 和 Microsoft Office SharePoint Server。

(MOSS) 2007，可创建团队网站、门户网站、Web 内容管理解决方案、文档库和搜索中心，更不用说 2007 Microsoft  Office 系统集成、基于 XML 的表单、工作流、移动性支持等。

然而，SharePoint ® 入门却并非易事。术语可能会令人困惑。系统体系结构可能非常复杂，而且 SharePoint 要求您处理多个组件，包括 IIS、Microsoft .NET Framework、SQL Server  和其他可能的技术（如商业智能、InfoPath  窗体服务、权限管理服务 (RMS)、Exchange Server 以及 ForefrontTM Security）。

您 可能很快就会在集成和自定义中转昏了头，它们为您提供了多种用于创建 SharePoint 解决方案的方法（无论是通过内置用户界面还是以编程方式）。此外，如果 SharePoint 应用程序不起作用，其故障排除操作可能会相当复杂。通常，必须具备应用程序开发人员的思维才能理解所涉及的组件以及它们的交互方式。由于存在这些挑战，您 应从何处着手才能构建一个稳定、可扩展且易于管理的 SharePoint 基础结构呢？

在 本专栏中，我将首先讨论有关体系结构的基础知识，然后再深入探讨 WSS 的部署，包括非常基本的品牌标记自定义功能。通过使用 WSS 3.0 的"自助站点管理"功能，您将了解到如何在维持对 SharePoint 基础结构的集中管理控制的同时，将创建和管理 SharePoint 站点的权限委派给单个用户。

通过首先了解 SharePoint 体系结构，您将更容易理解实施灵活且可扩展的基础结构所必需的部署和配置步骤。因此，让我们先大致浏览一下依赖关系，然后直奔主题介绍 WSS 3.0 的部署。如需详细的部署说明，请参考附属材料。可在《TechNet 杂志》网站的下载区找到此材料，网址为 technetmagazine.com。

SharePoint 体系结构

在使用 SharePoint 时，最好是站在系统架构师的角度来考虑此技术。不必了解所有的细枝末节，但是如果熟悉 SharePoint 体系结构提供的总体依赖关系，您将可以更快地得出解决方案，因为您可以预见到需要配置哪些组件以及其配置原因。

SharePoint 是一种用于配置 Web 应用程序和站点的技术。它是基于 IIS 的网站解决方案，通过 ASP.NET 与 IIS 相集成，并依靠后端的 SQL Server 数据库来存储配置数据和内容。简而言之，SharePoint 组合了三种不同的体系结构（IIS、.NET 和 SQL Server）作为其核心，如图 1 所示。

Figure 1 WSS 3.0 architecture based on IIS 6.0 and ASP.NET 3.0

千万别被这张图吓倒了。由于组件数量很大，所以一开始此体系结构看上去可能非常吓人。但经过系统地研究之后，您会发现所有这些组件都可嵌入到一个逻辑框架当中，这样您就可深入了解组件间的依赖关系。

如 图所示，SharePoint 依靠 IIS 和 ASP.NET 处理 HTTP 请求和响应。标准 IIS 组件（如 HTTP 内核模式驱动程序 (http.sys) 和工作进程 (w3wp.exe)）首先执行请求的初始排队和路由操作，直至请求到达 ASP.NET ISAPI 筛选器 (aspnet_isapi.dll)。在安装 .NET Framework 时，安装例程将在 IIS 元数据库 (C:\Windows\System32\Inetsrv\metabase.xml) 中注册 aspnet_isapi.dll，如下所示：

InProcessIsapiApps="C:\WINDOWS\system32\inetsrv\httpext.dll
C:\WINDOWS\system32\inetsrv\httpodbc.dll
C:\WINDOWS\system32\inetsrv\ssinc.dll
C:\WINDOWS\system32\msw3prt.dll
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll"

一 旦 IIS 加载 ASP.NET ISAPI 筛选器，网站的所有传入请求就可传到 ASP.NET，这一点非常重要，因为 SharePoint 最终必须通过 ASP.NET 接收这些请求。为此，SharePoint 通过添加一个通配符应用程序映射（无论文件扩展名是什么，它都会将所有传入请求路由到 ASP.NET ISAPI 筛选器）扩展选定网站的配置。

在使用"Basic"（基本）安装选项安装 WSS 3.0 之后，就可在 IIS 管理器中看到此过程。WSS 安装例程停用了服务器上现有的默认 IIS 网站，并在端口 80 上创建定义了 ASP.NET 通配符应用程序映射的一个新默认网站（如图 2 所示）。

Figure 2 Wildcard application map for ASP.NET ISAPI filter

为 使 ASP.NET 能够依次将请求传到 SharePoint，SharePoint 还必须通过一个自定义 HttpApplication 对象扩展 HTTP 请求管道，该对象可通过 Microsoft.SharePoint 程序集中名为 SPHttpApplication 的一个类来实现。SharePoint 在 ASP.NET 应用程序文件 (global.asax)（位于 SharePoint 扩展网站的根文件夹的文件系统中）中定义该自定义应用程序对象。以下代码列出了 global.asax 文件的内容：

<%@ Assembly Name="Microsoft.SharePoint"%>
<%@ Application Language="C#" Inherits="Microsoft.SharePoint.ApplicationRuntime.SPHttpApplication" %>

ASP.NET 动态解析并编译该文件以实例化 SharePoint 应用程序对象。

对 于收到的每个请求，ASP.NET 都会触发 Web 应用程序可处理的一系列事件（如 BeginRequest、AuthenticateRequest、ProcessRequest 和 EndRequest）。事件处理的详细信息超出了部署和管理 SharePoint 的范围，但必须了解以下信息：除了在 global.asax 中指定的 SPHttpApplication 以外，SharePoint 还实现了在站点的 web.config 文件中定义的自定义 HTTP 处理程序和模块。例如，SharePoint 使用基于 SPRequestModule 类的 HTTP 模块，并将其注册为在标准 ASP.NET 模块之前的首个 HTTP 模块。SPRequestModule 会初始化 SharePoint 运行时环境，如通过使用 ASP.NET 注册 SPVirtualPathProvider 组件。尽管 SPRequestModule 是供 SharePoint 内部使用，但是 SharePoint 解决方案开发人员可修改 web.config 文件来注册其他组件（如自定义 HTTP 处理程序和模块）。通过自定义 HTTP 模块和标准 HTTP 模块，SharePoint 可在严格控制到 SharePoint 应用程序的所有请求的同时，利用 ASP.NET 的优势。

请 注意，在使用 SharePoint 3.0 中心管理网站创建 Web 应用程序时，WSS 将把 ASP.NET 通配符应用程序映射添加到选定的 IIS 网站，并在该网站的根文件夹中创建 global.asax 和 web.config 文件。每个 Web 应用程序都使用自己的一组顶层 global.asax 和 web.config 文件。

为 处理请求并将有意义的信息返回给浏览器，WSS 3.0 和 MOSS 2007 依赖于标准的 ASP.NET 页面分析程序，该程序会编译请求的 ASP.NET 页面或在无编译模式下处理它们。但是，SharePoint 传给 ASP.NET 分析程序的 ASP.NET 页面并不一定位于它们应该存在的地方。例如，在 SharePoin 扩展网站（如 SharePoint 3.0 中心管理网站）的根文件夹中找不到 default.aspx 文件，但在显示该网站的主页时，您仍会打开 default.aspx。实际上是 SPVirtualPathProvider 组件虚拟化了环境，即从本地文件系统或 SQL Server 内容数据库加载页面内容，然后将其作为虚拟文件传给 ASP.NET 页面分析程序。对于中心管理网站来说，SharePoint 从 C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\SiteTemplates\CentralAdmin 文件夹加载 default.aspx 文件。

主 页（以及大部分其他 SharePoint 站点页面）会链接到用于实现菜单和导航控件的常规布局的 ASP.NET 母版页 (default.master)。Default.master 位于 C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Template\Global 文件夹中，它包含用于未来内容页面的已命名占位符（这些内容页面也可以位于本地文件系统或 SQL Server 内容数据库中）。重点在于在 Web 浏览器中打开 SharePoint 站点时，实际看到的信息是来自并不一定位于本地 Web 服务器上并且按照母版页中定义的布局来排列的一组内容页面。

通常，未修改页面（即 SharePoint 术语中的未自定义页面）作为页面模板存储在每个 SharePoint 服务器的本地文件系统中，而自定义页面将被写入到内容数据库中以便 Web 场中的所有 SharePoint 服务器都可以访问相同的一组页面（请参见图 3）。 假定 Web 场中所有服务器和站点中的未自定义页面都完全相同。但是，如果在 SharePoint 站点中自定义了内容页面或母版页（如通过使用 Office SharePoint Designer 2007），则 SharePoint 会自动将自定义页面存储在内容数据库中。

Figure 3 Uncustomized and customized ASP.NET pages in a SharePoint application

除 自定义页面和其他网站内容外，SharePoint 还将配置数据存储在 SQL Server 数据库中。SharePoint 把配置数据与内容分开保存，其原因是配置数据本质上是全局的，而内容则特定于每个单独的 Web 应用程序和站点集合。因此，一个 Web 场只能有一个配置数据库，但它可以有多个内容数据库。

Web 场中的所有 WSS 服务器使用相同的配置数据库来共享 Web 场中每个 SharePoint 扩展 IIS 网站的元数据、配置设置和相关信息。而另一方面，各个 Web 应用程序可与一个或多个内容数据库相关联（尽管每个内容数据库仅可与一个 Web 应用程序相关联）。

IIS 网站、Web 应用程序、站点集合、站点和内容数据库之间的关系可能有点混乱。在 SharePoint 术语中，术语 Web 应用程序是指 SharePoint 扩展 IIS 网站。Web 应用程序可包括多个站点集合，而每个站点集合又可以包括共享相同配置设置的顶层站点和子层站点。

此 外，创建多个站点集合还可将站点集合管理权限委派给不同的用户和组。单个站点集合不能跨越多个内容数据库，但 Web 应用程序可将多个内容数据库用于多个站点集合，从而增加可伸缩性并缓解在其他 SharePoint 站点上产生大量数据库活动的大型站点的性能影响。但是，将每个 SharePoint 站点放在自己的站点集合中并不是个好主意，因为这种部署方式限制了跨站点的能力。

WSS 3.0 不支持在多个站点集合之间进行内容搜索。此类搜索需要用到 MOSS 2007 或 Microsoft Search Server 2008。例如，可为 http://contoso 创建一个 Web 应用程序和顶层站点，并且站点集合管理员可使用 SharePoint 用户界面创建子层站点（如 http://contoso/info 和 http://contoso/events）。由于属于相同的站点集合，所有这些站点都存储在相同的内容数据库中。

作 为场管理员，还可使用托管路径（如 /sites），然后在 SharePoint 3.0 管理中心中定义其他站点集合（如 http://contoso/sites/IT 和 http://contoso/sites/HR）。这三个站点集合（http://contoso、http://contoso/sites/IT 和 http://contoso/sites/HR）可拥有不同的站点集合管理员、配置设置和内容数据库，但它们仍然都是通过相同的 IIS 网站 (http://contoso) 进行访问，并且使用相同的 Web 应用程序的应用程序池标识。

当然，还有许多更为详细的信息，但 IIS、ASP.NET 和 SQL Server 之间的关系对于理解和熟悉 SharePoint 来说特别重要。如果有兴趣阅读有关 SharePoint 体系结构的更多信息，建议您阅读一下《MSDN® 杂志》中 Ted Pattison 的文章"探寻 SharePoint Services 中为开发人员提供的重大改进功能"，网址为 msdn.microsoft.com/msdnmag/issues/06/07/WSS30Preview。

SharePoint 基础结构要素

现在，让我们把目光从简要的体系结构讨论转向灵活的 SharePoint 基础结构。正如您肯定已注意到的，我们需要 Windows Server®、IIS、.NET Framework 3.0 （用于 ASP.NET 和 Windows® Workflow Foundation）、WSS 3.0 或 MOSS 2007 以及 SQL Server。尽管您可能期待着 Windows Server 2008 中的 IIS 7.0，但在这里我们还是使用 Windows Server 2003 中的 IIS 6.0，因为在撰写本文时，IIS 6.0 仍是最常部署的版本。我们仍将使用 WSS 3.0，因为对于最初的 SharePoint 试验来说，不需要使用 MOSS 2007 特有的功能。

为 简便起见，可在一台计算机上安装 WSS 3.0 以及所有必需组件（按 WSS 3.0 on a single computer.pdf 所述执行安装，可从本专栏的附属材料中获得该文件），它足以满足实验室服务器或小型工作组环境的要求。但是，如果打算把重点放在 SharePoint 基础结构的灵活性上，则不应该在生产环境中建立一个独立的部署。出于可用性和未来可伸缩性方面的原因，最好首先建立一个多层基础结构，并且根据需要添加更 多服务器。

如 果您需要直观且灵活的系统配置，那我推荐图 4 中所示的 SharePoint 基础结构。它包括由两台 SharePoint 服务器组成的一个 Web 场以及一台单独运行 SQL Server 的计算机。该配置消除了 Web 服务器上的数据库处理开销、增加了可用性、可伸缩性并使系统更易于维护。请注意，Active Directory® 为必需项，因为这是 Web 场部署中的 WSS 3.0 的软件要求。如需分步部署说明，请参阅附属材料中的 Basic SharePoint Infrastructure.pdf 文件。

Figure 4 Basic SharePoint infrastructure that can accommodate future growth (单击该图像获得较大视图)

在 此布局方式中，用于部署 SharePoint 的域帐户需要具有 Web 服务器的本地管理员权限。此外，还必需将此帐户添加到 SQL Server 角色 dbcreator 和 securityadmin 中以及 SQL Server 2005 中主数据库的数据库角色 db_owner 中（如 Basic SharePoint Infrastructure.pdf 所示）。然后，可在 WSS 3.0 安装过程中使用"SharePoint Products and Technologies Configuration Wizard"（SharePoint 产品和技术配置向导）为 Web 服务器场创建必需的配置数据库并为 SharePoint 3.0 中心管理站点创建一个内容数据库。否则，SQL Server 管理员必须为您配置这些数据库，并将 WSS 系统帐户添加到 db_owner 角色中。

请务必记住，用于安装 SharePoint 的用户帐户并非 SharePoint 用于访问配置数据库或中心管理站点的内容数据库的帐户。SharePoint 使用的是配置为 SharePoint 3.0 中心管理站点的应用程序池标识的系统帐户。

"SharePoint Products and Technologies Configuration Wizard"（SharePoint 产品和技术配置向导）将提示您输入帐户信息。使用专用域用户帐户（如 CONTOSO\WssConfigAdmin）是个不错的主意。我通常的做法是针对之后创建的每个其他 Web 应用程序使用单独的专用用户帐户。针对每个 Web 应用程序使用单独的应用程序池有助于确保进程隔离，并且针对每个应用程序池使用不同的用户帐户有助于保持安全隔离。应当注意的是，尽管这只是一种方法，但 是应根据自身的环境和业务需求评估可管理性和可能的性能影响。

域 管理员还需为您创建的另一个重要的系统帐户是搜索服务帐户。可使用 Central Administration 帐户，但为确保安全，最好使用没有管理权限且无法修改任何内容的一个专用搜索帐户（如 CONTOSO\WssSearch）。对内容数据库的写入权限并不是必要的，因为搜索服务仅出于索引目的而爬网内容并将搜索数据存到一个单独的数据库 中。

在 服务器场中创建 Web 应用程序时，可将该内容数据库与搜索服务器相关联，这样就暗中向 Web 应用程序的"完全读取"策略添加了相应的搜索服务帐户。搜索服务器是运行 Windows SharePoint Services Search 服务的 SharePoint 服务器。如果遵循 Basic SharePoint Infrastructure.pdf 文件中的分布说明执行操作，则已将两台 Web 服务器配置为搜索服务器，这样就可分摊对多个内容数据库执行爬网和索引的负载。但是，也可在 Web 场中配置一个专用搜索服务器，除网络负载平衡和客户端连接之外，这样还可使客户端连接不受爬网活动的影响。

自助站点管理

当 基本的 SharePoint 基础结构部署到位之后，就可将站点集合和站点的管理权限委派给单个部门和用户，同时仍可集中管理控制 Active Directory、Web 服务器场或 SQL Server 数据库。作为场管理员，您可以与 Active Directory 和 SQL Server 管理员协同工作来为 Web 应用程序配置应用程序池帐户和内容数据库。然后，在这些 Web 应用程序中创建站点集合，并将创建子层站点的权限委派给站点集合管理员。这样，各部门内部的站点集合管理员就可以自行管理其 SharePoint 资源，从而尽可能地减少 IT 部门的工作（如图 5 所示）。

Figure 5 Decentralized site administration in a centralized SharePoint infrastructure (单击该图像获得较大视图)

还 可授予用户在托管路径（例如，/sites 路径或在 SharePoint 3.0 管理中心中创建的包含通配符的其他托管路径）下创建站点集合的权限。如果在 Web 应用程序中启用"自助站点管理"功能，则用户可以在 SharePoint 用户界面中创建自己的站点集合并管理站点组和权限。与子层站点不同，站点集合不会继承父站点的权限。

"自 助站点管理"并不适用于所有 SharePoint 环境，并且默认情况下为禁用状态。如果启用该功能，您的内容数据库中可能出现大量不常用的站点集合。但是，这项功能非常生动地展示了 SharePoint 管理的灵活性，因此建议您在试验部署中试用一下此功能。（此外，SharePoint 中还包含用于通知用户和/或管理员出现非活动站点的选项，这样就可在必要时删除这些站点。）必须为 Web 应用程序显式启用"自助站点管理"功能（如附属材料中的 Enabling Self-Service Site Management.pdf 文件所示）。

SharePoint 自定义和添加品牌标记

Sharepoint 资源

Windows SharePoint Services 技术中心 Windows SharePoint Services 开发人员中心 Microsoft SharePoint 产品和技术团队博客 逻辑体系结构组件 设计服务器场和拓扑

此 时，希望在 SharePoint 用户界面中包含公司的徽标、名称和颜色是再自然不过的需要了。但请注意，您将把 SharePoint 项目提到 ASP.NET 开发人员级别。至少需要一个开发系统（如安装了 Microsoft Office SharePoint Designer 2007 的一个独立 WSS 3.0 服务器）（请参阅附属材料中的 SharePoint Designer Installation.pdf），这样才可在不影响生产环境的情况下创建和测试自定义设置。还应访问 Windows SharePoint Services 开发人员中心（网址是 msdn2.microsoft.com/sharepoint）以深入了解 SharePoint 所提供的大量自定义选项。

虽 然 SharePoint 开发超出了本专栏的讨论范围，但我还是要指出以下需要注意的一些方面。SharePoint 将自定义页面保存在相应站点集合的内容数据库中。换句话说，SharePoint 站点中应用到站点页面、应用程序页面、母版页、样式表等的所有自定义都仅在站点集合或站点级别应用。这一点对于希望使用 SharePoint Designer 2007 来调整站点外观的各个站点集合管理员来说非常棒；但对于希望在 Web 场中的所有 Web 应用程序、站点集合和站点间强制实施公司标识的场管理员来说，却不太妙。

可 基于标准 SharePoint 主题或站点定义的副本来创建自定义站点主题或自定义站点定义。也可创建自定义母版页，并将它们添加到母板页库中。但是，如果启用了"自助站点管理"功能， 则这些选项都无法强制实施全局品牌标记，因为拥有创建站点集合或站点权限的用户仍然可以选择不显示公司标识的标准站点模板。

全 局品牌标记要求替换掉默认 SharePoint 组件，这样才能改用自定义组件。开发人员会尽力在不修改原始文件的情况下实现此目的。一种方法是更改 IIS 管理器中虚拟目录的配置，并将其指向包含自定义文件的新文件夹。另一种方法是使用自定义 HTTP 模块或 ISAPI 筛选器，它们会重写 URL 以将特定默认页面的请求重定向到自定义版本的页面。

结束语

在 本文中，我重点介绍了使用 WSS 3.0 来建立 SharePoint 基础结构的要点。我并未介绍其他功能（如工作流、调查、消息传递集成和防病毒），也没有介绍 MOSS 2007 特有的功能（如门户、站点目录和业务数据目录）。我还简要介绍了 SharePoint 中可能出现的站点管理和公司品牌标记自定义设置。可在 Visual Studio® 中编写自定义应用程序来使用 WSS 3.0 执行更多的自定义功能。

如 添加更多的 Web 服务器或数据库服务器，则该基础结构足以适应未来的增长需求。通过试验性实施几个自定义功能，用户将可以创建单个站点并大致熟悉 SharePoint。这样就建立了用户站点、硬件和软件的核心组件，它们非常灵活足以适应变化并且可用作成熟生产实施的基础。