探寻 SharePoint Services 中为开发人员提供的重大改进功能

最新推荐文章于 2024-09-23 21:32:49 发布

qwjsdbj789

最新推荐文章于 2024-09-23 21:32:49 发布

阅读量987

点赞数

Microsoft Office SharePoint Server (MOSS) 的下一个主要版本（包括 Windows® SharePoint® Services (WSS) 版本 3.O）即将出炉。如同先前版本一样，WSS 提供了开箱即用的协作功能，这使得用户可以通过使用共享元素（如日历、联系人列表和文档库）来方便地创建和设计 Web 站点。但对于终端用户而言，WSS 绝不仅仅只是一种协作工具。它还是一个成熟的开发平台，为 ASP.NET 增添了巨大的价值。

WSS 3.0 是 Windows Server™ 2003 的附件。其核心是，WSS 作为可伸缩的站点提供引擎，简化了成百上千个 Web 站点的创建和管理过程，并使得成千上万的用户能够对其进行访问。通过使用在考虑 Web 领域环境的基础上所设计的体系结构，从而实现了 WSS 的可伸缩性。此体系结构基于依赖于 SQL Server™ 来存储内容和其他站点相关数据的无状态前端 Web 服务器而构建。

WSS 为 ASP.NET 2.0 开发平台带来更多价值的原因在于其自身的可扩展性模型，该模型简化了页面、列表和文档库的提供与存储。这种提供可通过自定义代码或基于浏览器的用户界面中的用户操作来实现。在后台，WSS 会自动制定如何以及在何处存储内容的方案，另外还提供用户用来添加、查看和修改内容的 UI 元素。

我会重点介绍版本 3 中为开发人员提供的最重要的增强功能以及附带的术语变更。有关详细信息，请参见“SharePoint:Use Windows SharePoint Services as a Platform for Building Collaborative Applications”（英文），摘自 MSDN® 杂志的 2004 年 7 月刊。

请记住，本文的研究和代码示例均基于 WSS 的 Beta 1 版。在已发布的版本中，有些术语和代码可能有所更改。

与 ASP.NET 2.0 集成

WSS 3.0 提供从 IIS Web 站点开始。在能够创建第一个 WSS 站点之前，您需要运行一个管理过程，将 WSS 功能扩展到一个或多个 IIS Web 站点。在 WSS 2.0 中，“虚拟服务器”这一术语用于描述由 SharePoint 功能扩展的 IIS Web 站点。为了避免与其他同名 Microsoft 产品混淆，WSS 3.0 文档现在将由 WSS 功能扩展的 IIS Web 站点称作 Web 应用程序。

通过使用 ISAPI 筛选器 DLL，WSS 2.0 与 IIS 6.0 和 ASP.NET 1.1 集成在一起，这导致 IIS 将请求先路由到 WSS 中而后路由到 ASP.NET 中。在某些情况下，该路由可能存在问题，因为 WSS 控制着传入的 HTTP 请求，使该请求没有机会通过 ASP.NET 环境进行正确初始化。

但在版本 3 中，WSS 与 ASP.NET 的集成已完全进行了重新设计。首先，WSS 3.0 构建于 ASP.NET 2.0 基础之上，它提供了比 ASP.NET 1.1 更重大的增强功能。此外，通过移除 ISAPI 筛选器以及添加使用标准 web.config 条目注册到 ASP.NET 中的 HttpModule 和 HttpHandler，路由基础结构得到了改进。这意味着传入的 HTTP 请求始终进入 ASP.NET 运行时环境，并通过 ASP.NET 环境对其进行完全初始化，之后再转发到用于执行特定于 WSS 的处理的代码中。

在扩展 IIS Web 站点，使之成为 Web 应用程序时，WSS 3.0 会添加至 IIS 元数据库的通配符应用程序映射。此映射会将所有传入的 HTTP 请求均路由到 ASP.NET 运行环境，而忽略文件类型（.pdf、.doc、.docx 等等）。之后，ASP.NET 将请求转发给 WSS 进行处理。

新的体系结构还会解决分析和编译 .aspx 页面过程中存在的缺陷。ASP.NET 1.1 所使用的 .aspx 页面分析程序仅对驻留于本地文件系统上的页面有效。但是，WSS 体系结构依赖于在 SQL Server 数据库中存储 .aspx 页面，这样，它无法利用 ASP.NET 1.1 页面分析程序。而且，遗憾的是，根据自身需求所开发的 SharePoint 分析程序并不支持由 ASP.NET 页面分析程序提供的许多更为强大的功能。

但是，ASP.NET 2.0 引入了一种新型可插入组件，称为虚拟路径提供者。其理念就是开发人员可编写一个能够检索任意位置中的 .aspx 页面（或 ASP.NET 处理的其他任意内容）的自定义组件。一旦自定义虚拟路径提供者检索到一个 .aspx 页面，它会立即将该页面提交给 ASP.NET 以进行必要的分析和编译。借助单独的组件 PageParserFilter，SharePoint 能够控制分析和编译页面的方式以及在这些页面上所执行的内容。

WSS 3.0 包括其自身的虚拟路径提供者，名为 SPVirtualPathProvider，如图 1 所示。正如您所见，SPVirtualPathProvider 能够从 SQL Server 中检索 .aspx 页面，之后，将它们提交给 ASP.NET 2.0 提供的 .aspx 分析程序。因此，对于页面分析，WSS 3.0 并未像 WSS 的先前版本那样丧失掉一部分功能。

图 1 自定义虚拟路径提供者和 ASP.NET 2.0

页面模板

术语重像和取消重像通常与 WSS 2.0 站点的 .aspx 页面结合使用。通过页面重像，前端 Web 服务器可在其本地文件系统上存储一个 .aspx 页面模板，然后在许多个不同的站点中共享该模板。由于通过使用存储在本地文件系统并只需载入内存一次的页面模板，WSS 可为数千个站点提供页面，所以页面重像具有性能优势。

WSS 2.0 支持用户通过使用工具（如 Microsoft® Office FrontPage® 2003）对页面模板进行修改。在用户修改页面模板并保存更改后，该页面的定制版本便会存储在该特定站点的 SQL Server 中。这通常称为取消重像页面。

WSS 3.0 依旧支持存储在 Web 服务器上的页面模板以及存储在 SQL Server 中的定制版本。不过，文档不再使用重像和取消重像这两个术语。现在，“取消定制的页面”这一术语用于描述直接从 Web 服务器的本地文件系统使用的页面模板，而在谈到已写入到特定站点内容数据库中的页面模板的已修改版本时，则使用“定制的页面”这一术语。

Microsoft Office FrontPage 2003 已重命名为 Office SharePoint Designer 2007，但是其目标受众仍然是用户，而非开发人员。当然，它也是 WSS 开发人员的一种便捷工具。SharePoint Designer 为在 WSS 站点中定制 .aspx 和 .master 页面提供了代码编辑器和所见即所得设计器，对于在 Web 服务器上没有对应页面模板的站点，您可在其中创建新页面。您还能创建列表和文档库，甚至还存在一个用于在 WSS 站点中创建自定义工作流的新向导。（稍后我将更深入地讨论此问题。）

使用母版页

在 WSS 2.0 中自定义和创建站点时，其中最乏味的一点就是为所有页面创建同一种外观，原因在于 ASP.NET 1.1 没有提供任何恰当的页面模板技术。结果，许多开发人员和设计人员采用了一页一页地复制和粘贴 HTML 布局的方法。您会想像得到，要想自定义和维护其布局要求不同于标准 WSS 站点的站点，这是非常困难的。

随 ASP.NET 2.0 引入了一种补救措施，其以强大的页面模板功能形式出现，称之为“母版页”。“母版页”一种模板，它允许您使用各种元素（如标题、导航控件以及其他菜单）为整个站点定义标准页面布局。链接到“母版页”的页面称为内容页面。

关键概念是每个内容页面均链接到“母版页”以获取共享布局，之后通过在已命名占位符中插入自定义内容来扩展“母版页”。有关母版页如何在 ASP.NET 中工作的详细信息，请参见 Fritz Onion 的文章“Master Pages:Master Your Site Design with Visual Inheritance and Page Templates”（英文），摘自 MSDN 杂志的 2004 年 6 月刊。

WSS 3.0 从头开始设计，以包含 ASP.NET 2.0 的“母版页”基础结构。为每个版本 3 站点提供一个特殊的目录，称为“母版页”库，它包含一个名为 default.master 的页面。此页面用于为每个站点的主页 (default.aspx) 以及与列表和文档库相关联的所有标准 WSS 形式的页面（如，AllItems.aspx 和 NewItem.aspx）定义一个通用布局。“母版页”布局包括标准菜单和导航控件。图 2 显示的是以 default.master 定义的标准布局为基础的示例页面。

图 2 default.master 定义的页面标准布局

default.master 定义包括许多已命名的占位符，如 PlaceHolderPageTitle、PlaceHolderMain 和 PlaceHolderLeftNavigation，可使其相对简单地创建一个与站点中其他页面具有相同布局的新自定义内容页面。请看一下内容页面定义是如何的简单：

  <%@ Page language="VB" MasterPageFile="~masterurl/ 
    default.master" %>
  <asp:Content ContentPlaceHolderId="PlaceHolderMain"
    runat="server">
    <h3>欢迎使用 Windows SharePoint Services 3 进行自定义</h3>
    这比使用版本 2 进行自定义要容易得多！
                     </asp:Content>

内容页面定义只是将 HTML 内容的最小片段置于 PlaceHolderMain 内部，但生成了带有站点图标、菜单和导航栏的典型页面布局，如图 3 所示。在了解了如何使用 default.master 中所定义的占位符的标准集后，便可以很方便地用您自己的 ASP.NET 控件来代替 WSS 元素，如菜单和导航栏。这可适用于站点范围或站点集合中的页面。

图 3 从母版页自定义内容页面

母版页和内容页面的存储和加载方式类似于先前介绍的页面模板和页面定制的存储和加载方式。为母版页和内容页面定义的页面模板位于前端 Web 服务器的本地文件系统上。每个站点最初使用母版页模板和内容页面模板的取消定制（重像）版本。当用户使用诸如 SharePoint Designer 之类的工具为特定站点定制和保存其中的一个页面时，一个定制（取消重像）版本会保存到 SQL Server 数据库中。

如果喜欢，您可以为站点定制母版页，而将内容页面保留为取消定制。也可以定制一个或多个内容页面，而将母版页保留为取消定制。可以撤消任何更改；WSS 和 SharePoint Designer 均提供了简单的菜单命令，用以放弃在 SQL Server 数据库中的定制更改，恢复为原始页面模板。

您可能已经注意到，通过使用 ~masterurl/default.master 形式的特殊语法，先前所显示的内容页面链接到母版页。这是到母版页的已标记化引用，可以在站点范围的基础上以编程方式进行更改。为此，可以取得到当前站点的 SPWeb 引用，然后更新 MasterUrl 属性（请参见图 4）。

注意，每个站点都有其自身的含 default.master 的母版页库以及其自身的 MasterUrl 属性。这意味着站点集合内的所有站点不会自动使用同一母版页。但是，通过使用递归方法可以相当轻松地针对 WSS 3.0 对象模型编写一些代码，以同步站点集合中的顶层站点和所有子站点，从而使它们使用同一个母版页，如图 5 所示。

母版页的另外一个有用的动态标记采用 ~masterurl/custom.master 形式。此动态标记与站点的 CustomMasterUrl 属性配合使用，并提供可以编程方式重定向的第二目标母版页。还有两个以 ~site 或 ~sitecollection 开头的静态母版页标记。利用这两个静态标记，可以硬编码一个从当前站点的根或当前站点集合的根到母版页的相对路径。

返回页首

WSS 中的 Web 部件

开发人员扩展 WSS 2.0 站点的最常用方法之一是创建自定义 Web 部件。Web 部件极为有用，因为它们可添加用户自定义和个性化的额外维度。主要由于 Web 部件在 WSS 2.0 中的受欢迎程度，Microsoft 决定增加对 ASP.NET 2.0 的新 Web 部件基础结构（与 WSS 中的 Web 部件基础结构类似但仍有不同）的支持。

因此，现在有两种不同的 Web 部件样式。旧的 WSS 样式的 Web 部件与 Microsoft.SharePoint.dll 有依赖关系，并且必须继承自 Microsoft.SharePoint.WebPartPages 命名空间中的 WebPart 基类。新的 ASP.NET 样式的 Web 部件与 System.Web.dll 有依赖关系，并且必须继承自 System.Web.UI.WebControls.WebParts 命名空间中的另外一个名为 WebPart 的基类。

WSS 3.0 的一个重要设计目标就是能够同时运行 WSS 样式的 Web 部件和 ASP.NET 样式的 Web 部件。实现这一目标的方法是：在 ASP.NET Web 部件基础结构的顶部构建 WSS 3.0 对 Web 部件的支持，然后更改 Microsoft.SharePoint.dll，这样，针对 WSS 2.0 环境编写的 WSS 样式的 Web 部件会与版本 3 运行时环境兼容。

要在 ASP.NET 2.0 应用程序中运行 Web 部件，必须创建一个 .aspx 页面，其中只包含 WebPartManager 控件的一个实例以及一个或多个 WebPartZone 控件。WebPartManager 负责序列化与 Web 部件相关的数据，以及在 ASP.NET 服务数据库的各表格中存储和检索这些数据。

用作 Web 部件页面的 .aspx 页可以包含编辑器部件，用户可以利用这些部件自定义和个性化永久 Web 部件属性。Web 部件页面也可包含目录部件，用户可以利用这些部件将新 Web 部件添加到各个区域中。WSS 3.0 负责添加目录和编辑器部件，因此无需 Web 页面设计器来明确地执行此任务。有关 ASP.NET 2.0 Web 部件基础结构如何工作的更多背景信息，请阅读文章“ASP.NET 2.0:Personalize Your Portal with User Controls and Custom Web Parts”（英文）（ASP.NET 2.0：使用用户控件和定制的 Web 部件个人化你的门户网站）。

在名为 SPWebPartManager 的控件顶部构建 WSS 3.0 Web 部件基础结构，该控件由 ASP.NET 2.0 WebPartManager 控件派生而来。SPWebPartManager 控件替代了 WebPartManager 控件的标准行为，以将 Web 部件数据保留在 WSS 内容数据库内部而非保留在 ASP.NET 服务数据库中。大多数情况下，您不必担心如何直接使用 SPWebPartManager 控件进行处理，因为在 default.master 中已事先定义了一个唯一需要的实例。在创建链接到 default.master 的内容页面时，SPWebPartManager 控件已经存在。

在图 6 中显示了出现在典型 WSS 3.0 Web 部件页面上的其他控件。注意，对于 WSS 3.0 中 Web 部件页面的 Web 部件区域，应使用在 Microsoft.SharePoint.WebPartPages 命名空间内部所定义的 WebPartZone 控件创建，而不使用 ASP.NET 2.0 中的标准 WebPartZone 控件创建。

图 6 Web 部件页面中的控件

通常在内容页面中定义 WebPartZone 控件的实例。图 7 显示了一个创建内容页面的简单示例，该内容页面旨在用作 WSS 3.0 站点中的 Web 部件页面。如您所见，与前面的示例恰好相同的是，此 .aspx 文件也链接到 default.master。不过，它还显式继承自 WebPartPage 基类，并将两个 WebPartZone 控件添加到 PlaceHolderMain 中。

在为标准 ASP.NET 2.0 应用程序创建 Web 部件页面时，需要添加与 WebPartManager 控件交互的逻辑，以管理 Web 部件显示模式，通常还需要明确地将编辑器部件和目录部件添加到该页面和 HTML 布局中，以容纳这些部件。幸运的是，在为 WSS 3.0 站点创建内容页面时，不需要您来执行这些任务。而是继承自在 Microsoft.SharePoint.WebPartPages 命名空间内部所定义的 WebPartPage 类，然后让它在后台帮您完成此工作。

返回页首

开发自定义 Web 部件

为 WSS 3.0 站点创建 Web 部件的首选方法是创建 ASP.NET 样式的 Web 部件。这至少包括创建从 System.Web.UI.WebControls.WebParts 命名空间中定义的 WebPart 基类所继承的类，以及改写 RenderContents 方法。如果要添加永久 Web 部件属性，则使用在 ASP.NET 中所使用的相同技术。

图 8 中显示的 Web 部件定义与 Microsoft.SharePoint.dll 不存在依赖关系，因此既可以在标准 ASP.NET 应用程序中使用也可以在 WSS 3.0 站点中使用。但在许多情况下，您应该向 Microsoft.SharePoint.dll 添加一个引用，以便 Web 部件后面的代码同样可按照 WSS 3.0 对象模型进行编写。

WSS 3.0 还设计用于支持针对版本 2 环境而创建的 Web 部件。这些旧样式的 WSS Web 部件继承自在 Microsoft.SharePoint.WebPartPages 命名空间内部所定义的 Microsoft.SharePoint.dll 中的 WebPart 基类。

旧版 Microsoft.SharePoint.dll 中的 WebPart 类继承自 ASP.NET 控件类，如图 9 所示。但是，您也可以看到，已将新版 Microsoft.SharePoint.dll 中的 WebPart 类修改为继承自 ASP.NET Web 部件类。这项在程序集的新版本中更改基类的技术称为基类重定位。Microsoft.SharePoint.dll 中 WebPart 基类的基类重定位技术是在 WSS 3.0 环境中支持旧样式 Web 部件的一项关键内容。

图 9 已重定位基类的 WebPart 类

如果查看 WSS 3.0 Web 应用程序的标准 web.config 文件，您会看到它包含用于将引用从旧版 Microsoft.SharePoint.dll 重定向到新版 Microsoft.SharePoint.dll 的配置元素。这种重定向与 Web 部件基类的基类重定位技术结合在一起后，针对版本 2 环境编写的 Web 部件 DLL 便可在版本 3 环境中运行，无需任何重新编译。

如果您决定将版本 2 Web 部件项目转换为 Visual Studio® 2005，则可以继续使用以前曾经用过的相同样式来演化您的代码，而且，这些内容仍然有效。但是，在已经移到 Visual Studio 2005 并将到 Microsoft.SharePoint.dll 的旧项目引用切换为新 WSS 3.0 版本后，您也可以选择使用另外一种方法来执行此任务。既然 ASP.NET WebPart 基类当前是继承层级的一部分，那么您可以更改 WSS 样式 Web 部件类的某些方面，就好像它是 ASP.NET 样式的 Web 部件一样。这称作混合 Web 部件。

返回页首

内容存储中的增强功能

在 WSS 2.0 中，令开发人员感到头疼的一个问题是：文档库中所支持的一些重要功能在列表中却得不到支持。例如，文档库支持版本化和事件，列表却不支持。在 WSS 3.0 中，列表支持文档库所支持的许多功能，其中包括版本化、事件和文件夹。另外，列表和文档库还同时支持一些新功能，如通过自动 RSS 反馈公开数据。

WSS 3.0 引入了一种新的列索引功能，以帮助解决 WSS 2.0 中的文档库和列表存在的一些性能问题。通过列表设置页面或文档库设置页面，可向任意一列添加索引。这不会在 SQL Server 中实际创建物理索引。而是使用列表项或文档的整数 ID 以及索引列的值创建一个表。然后，WSS 使用此表改进从视图返回数据的性能，尤其是在将视图与基于索引列的筛选器配合使用时更是如此。

许多开发人员希望能够在较低级别使用 WSS 字段，以获取字段呈现和验证的更多控制权限。为了响应上述问题，WSS 3.0 添加了新的可扩展字段类型。可通过使用 C# 或 Visual Basic® 编写类来创建可扩展字段类型，该字段类型继承自其中一种内置 SharePoint 字段类型（如 SPFieldText 和 SPFieldNumber）。可扩展字段类型也可以使用包含您所喜欢的 Web 控件的 ASP.NET 用户控件，对于控件初始化和验证，您可以使用在 ASP.NET 应用程序中所使用的相同技术。

WSS 3.0 中的另一个有用创新是自定义站点列。站点列是可以应用在多个列表中的可重复使用定义。它定义了列的名称，其基本字段类型以及其他特征（如默认值、格式和验证）。只要定义了站点列，便可以在定义您的用户定义列表的结构时使用该站点列。一个明显的优点是您可以在一个位置更新站点列，而该更新会影响到使用该站点列的所有列表。站点列在单个站点范围内定义，但对于下面的所有子站点而言，该站点列都是可见的。要创建一个可在整个站点集合中使用的站点列，请在顶层站点内部定义该站点列。

站点列为您提供了在各个站点中执行字段查找的功能，而在 SharePoint 的先前版本中，如果没有编写自定义代码就无法完成该项任务。例如，您可以在顶层站点中创建一个站点列，顶层站点对同一站点中的列表执行查找。然后，可以在子站点中创建其他列表，这些子站点使用此站点列对顶层站点中的列表执行查找。假设您要在同一文档库中存储若干不同类型的文档。例如，假定您需要存储客户演示文稿、提案和报告，而且希望每种文档类型都有其自己的唯一一组自定义列以及自己的唯一事件处理程序。在 WSS 2.0 中，只能向文档库自身添加额外的列和事件处理程序，这会始终影响该文档库中的每个文档。而且，一个文档库只有一个关联的文档模板。

为了解决这一问题，WSS 3.0 引入了一种强大的新存储机制，称为内容类型。内容类型是一种灵活的、可重复使用的 WSS 类型，它用于为列表中的项或文档库中的文档定义样式和行为。例如，您可以使用唯一一组列、一个事件处理程序及其自己的文档模板为客户演示文稿文档创建一种内容类型。还可以使用另外一组列、工作流以及另外的文档模板为客户提案文档创建第二种内容类型。然后，可以创建一个新文档库，并将其配置为同时支持这两种内容类型。这是一种重要的增强功能，因为利用此功能可处理列表和文档库中的不同类型的内容。

返回页首

事件处理程序

WSS 2.0 中的事件支持文档库但不支持列表。此外，版本 2 仅支持在将某用户操作提交到 SQL Server 数据库后触发的异步事件。开发人员无法取消事件处理程序内部的用户操作。

WSS 3.0 改进了事件处理功能，不仅仍保留版本 2 中对异步事件的支持，而且增加了对允许取消用户操作的同步事件的支持。例如，可以防止用户在文档得到批准后将其删除，或防止用将来的订单日期创建订单。而且，在列表项以及文档库中的文档上均支持事件。

通过编写从某一 WSS 接收方类继承的自定义类并覆盖各方法来创建事件处理程序，以便处理事件。例如，要处理列表中某项目的更新事件，则要创建一个从 SPItemEventReceiver 类继承的类并覆盖 ItemUpdating 方法，如图 10 所示。

可对照对象模型编写代码或在 WSS 功能中定义事件接收方，从而将事件处理程序绑定到特定的列表或文档库。例如，可以使用如下所示的代码将该事件接收方绑定到某列表：

Dim list As SPList = web.Lists("Orders")
list.EventReceivers.Add(SPEventReceiverType.ItemAdding, _
    "[全限定程序集名称]", "Litware.MyReceiver")

WSS 接收方类对可覆盖方法使用了可区分同步事件和异步事件的命名约定。例如，ItemUpdating 是在对内容数据库进行更改之前触发的可取消的同步事件。这些同步事件提供了一种有效方式来验证列值，如图 10 中的事件处理程序所示。

有一个名为 ItemUpdated 的补充异步事件，在将更改写入到内容数据库之后发生。与同步事件不同，异步事件不支持取消用户操作。相反，它们提供了在对文档或列表项进行更改后执行所需操作的方法，例如，分配已计算列的值或发送电子邮件通知。

除了支持列表项和文档上的事件外，WSS 3.0 还支持其他新的事件类型，例如，在有人更改列表定义时触发的列表事件。例如，只要有人试图删除或重命名您的某个自定义列表中的某列，您就可取消该用户的操作。还存在一些在有人删除或移动某站点或整个站点集合时触发的事件。

返回页首

WSS 中的工作流

工作流应用程序最近在 Microsoft 内部引起了极大关注。即将与 Windows Vista™ 一同发行的 WinFX® 运行时组件增加了一个完整的基础结构，即 Windows Workflow Foundation，以用于构建工作流样式的应用程序。该工作流基础结构包含一个引擎、多个用于保持工作流状态的可插入组件，以及一个 Visual Studio 设计器，该设计器通过将各组件（称为活动）拖放到一个工作流设计表面上来简化自定义工作流的创建过程。

WSS 3.0 构建在 Windows Workflow Foundation 之上，以提供一种用于将业务逻辑附加到列表项和文档的结构。它通过将某任务列表和历史列表与每个工作流相关联来扩展基本工作流模型，从而为面向人性化的工作流（例如，用于审阅或批准文档的路径）增加了一定程度的责任性和问责性。

WSS 和 MOSS 2007 所附带的工作流均已安装完毕且随时可以使用。WSS 3.0 包含一些用于调解和批准之类操作的简单路线工作流。MOSS 2007 提供了更复杂的工作流，以支持 Web 内容管理批准过程之类的功能。

对于使用 WSS 和 MOSS 2007 构建业务解决方案的开发人员而言，创建自定义工作流代表了一种明显的扩展点。除了 Visual Studio 扩展功能对 Windows Workflow Foundation 的标准支持之外，还计划提供特定于 WSS 的工作流 SDK 和入门工具包，该工具包包含了用于为 WSS 站点创建自定义工作流的 Visual Studio 项目模板。

SharePoint Designer 同样支持在 WSS 3.0 站点中创建自定义工作流。实际上高级用户与开发人员一样甚至比其更适合利用该支持，因为它提供了一种在产品站点中逐步执行向导中操作并将业务逻辑附加到列表项和文档的方法。

返回页首

站点定义、功能和解决方案

曾将 WSS 2.0 用作平台来构建业务解决方案的开发人员发现，使用低级站点定义可实现最大程度的控制性和复用性。站点定义是前台 Web 服务器上包含 XML 文件和 .aspx 页面模板的一个目录，其中 XML 文件和 .aspx 页面模板用于定义站点蓝图，包括列表架构和页面布局。在许多站点定义文件内部使用的基于 XML 的语言称为协作应用程序标记语言 (CAML)。

不过，在版本 2 中此策略存在一些问题。首先，版本 2 站点定义内部的 XML 文件分解得很糟糕，这使它们变得难以处理和使用。其次，一旦某站点定义被用于创建站点后，就不支持对该站点定义的引伸。这表示没有任何涉及站点定义的受支持技术可用于向现有 WSS 2.0 站点添加功能。第三，站点定义以及这些定义所依赖的自定义集合导致了部署问题，因为必须在没有 WSS 基础结构协助的情况下将文件传送到某 Web 场中的每个前台 Web 服务器。最后，WSS 2.0 未提供任何用于本地化站点定义的方法，这会让那些想要国际化其业务解决方案的公司多少感到有些失望。

WSS 3.0 在这方面首要的增强性体现在各功能的引入。一个功能类似于一个站点定义：即包含基于 CAML 的 XML 文件和页面模板的目录。但是，各功能提供了一个更加模块化的方式，因为无需为站点定义整个蓝图。一个简单功能可定义单个站点元素，例如，自定义列表定义或要显示在某一 WSS 标准菜单中的菜单命令。

可喜的是，可在现有站点上激活各功能。例如，可创建一个用于定义自定义列表类型、该列表类型的实例以及该列表实例上的事件处理程序或工作流的功能。只要安装了功能，就可在某 Web 场内的任一站点中将其激活，也可通过 WSS 用户界面、命令行或对照 WSS 对象模型编写的自定义代码将其激活。功能被激活后，该站点将包括新的自定义列表以及您想要附加到该列表的任何行为。

各功能还简化了站点定义的开发。在 WSS 2.0 中，每个列表定义都必须在某站点定义的上下文内部指定。在版本 3 中，可将每个列表定义分解为其各自的功能。此时，站点定义更加易于创建，因为可使用功能引用来构成这些定义。所有作为 WSS 协作服务一部分提供的列表类型均采用此方法。

WSS 3.0 引入了一个称为解决方案的新部署机制，它是一个聚合的 .cab 文件，包含需要部署在每个前台 Web 服务器上的 XML 指令和文件，从这种意义上说，它类似于 Web Part 软件包。但解决方案要高出 Web Part 软件包一筹，可支持用于事件处理程序和工作流的功能、站点定义以及相关集合的部署。

WSS 3.0 对解决方案的支持还有助于将部署文件传送到某 Web 场中的每个 Web 服务器。管理员将某解决方案添加到 WSS 场，后者将解决方案 .cab 文件复制到配置数据库中。接下来，管理员运行命令来部署该解决方案，此时，WSS 启动计时器作业，将解决方案 .cab 文件传送到每个 Web 服务器并将其安装。

对 WSS 开发人员而言，一个极受欢迎的变革是新增了本地化支持。此功能已构建在 ASP.NET 2.0 的本地化基础结构之上，而且现在可以（并建议）以非特定于语言的方式创建站点定义和功能，并可维护 .resx 文件中的字符串文字。在功能或站点定义的 XML 文件和 .aspx 页面模板文件内，可以使用 ASP.NET 标准语法为已本地化为 .resx 文件的命名字符串获取值。

<%$Resources:Litware,MyString%>

返回页首

Internet 样式安全性

WSS 2.0 中的身份验证基于 Windows 帐户及其关联的安全 ID (SID) 来执行。从实际意义上说，这表示在除了最小型部署之外的任何应用领域中，WSS 2.0 都会与 Active Directory® 紧密结合。对于那些在开始使用 WSS 2.0 和 SharePoint Portal Server 2003 构建基于内部网的解决方案时部署 Active Directory 的公司来说，这种依存关系没有带来任何问题。但对于构建基于外部网的解决方案的公司来说，这却成为一个极大的难题。WSS 与 Active Directory 的紧密结合迫使许多公司为非公司用户（例如，供应商和客户）创建并维护域帐户。

所有这一切都随着 WSS 3.0 发生了改变，因为在随 ASP.NET 2.0 引入的新身份验证提供程序基础结构之上对身份验证进行了重新设计。如果不想为 Active Directory 内部的 WSS 和 MOSS 2007 站点维护用户帐户，则只需构建或获取一个 ASP.NET 身份验证提供程序即可，该提供程序专用于在另一个身份库中存储和管理用户帐户。

例如，ASP.NET 2.0 所附带的窗体身份验证提供程序使您可以在 SQL Server 数据库内部维护用户帐户。可对该身份验证提供程序进行配置以供在 WSS 站点中使用。不费吹灰之力，您就可将 WSS 站点放置到 Internet 上，并允许未知用户作为成员自行注册。ASP.NET 2.0 为创建和维护用户帐户提供了便利支持，甚至允许用户更改和重设其密码。

返回页首