使用Web存储系统设计知识管理解决方案

1、使用Web存储系统设计知识管理解决方案 Walson Lee Microsoft Corporation 2000年10月 摘要：本文概述了使用 Web存储系统开发高效的知识管理解决方案的设计过程。 目录 简介 Microsoft ? Exchange 2000 Server 是引入一种新的称为 Web 存储系统的存储技术的第一个 Microsoft 产品。 Microsoft 的 Web 存储系统提供许多新的开发功能，例如 Web 存储系统事件与窗体、 工作流引擎、 内容索引以及搜索文件夹。 这些功能特别适用于知识管理 (KM)解决方案。但是，KM解决方案的开发人员 开始时需要经过一个学习过

2、程， 才能理解这些功能， 并逐个理清 Web 存储系统提供的许多个设计选项的作 用。本文着重讲解了有关开发 KM 解决方案的设计方面的知识，并讨论了最佳方法、设计模式以及设计过 程中的考虑因素。其中展示了基于服务的应用程序模型和基于 Microsoft 解决方案框架 (MSF) 的设计过 程。这个设计过程是专为使用 Web 存储系统建立 KM 解决方案量身定做的。 设计过程包含了概念设计模型、 逻辑设计模型以及物理设计模型。本文重点讲述针对 Web 存储系统的物理设计模型的设计考虑因素： ? 用户服务 数字仪表板和 Web 存储系统窗体 ? 业务服务 工作流和事件设计 ? 数据服务 存储架构设

3、计 ? 安全模型 ? 性能 ? 可伸缩性与可用性 ? 分类的实现 ? 与业务范围 (LOB) 应用程序集成 本文旨在提供一种设计基于 Web 存储管理系统技术的 KM 解决方案的正确方法。 它所面向的读者是 KM 解 决方案的构建或设计人员。其他开发人员也能从本文阐述的基本设计概念中获益。 Web 存储系统用作开发平台 Web 存储系统是 Microsoft 为体现它的 “不受限制的知识工作者” 理念而宣布的四项创意之一。 这些创意 的主要目的是消除当今知识工作者面临的妨碍相互协作的障碍。Web 存储系统将文件系统、 Web 以及协作 服务器的功能组合到一个位置，以便存储、访问、管理信息以及建

4、立和运行应用程序。Web 存储系统中的 每一项都是可用 URL 寻址的，并且完全支持半结构化数据，如文档、联系人、消息、报告、 HTML 文件以 及 Active Server Pages (ASP)。 Web 存储系统提供与 Microsoft Office 2000 的高性能集成。它为信息 管理(包括一致搜索和数据分类)建立了一个平台。 图 1 阐释了 Web 存储系统的编程模型。从图中可看出它支持不同的协议、数据访问方式和事件模型。对 Web 存储系统的数据访问包括对 OLE DB 和 ActiveX ? Data Objects (ADO)的支持。 Web 存储系统还提供 通过 HTT

5、P 协议进行访问的功能。(英文)增强了这一功能，使它可支持另一组协议命令。此外，该存储 系统本身还支持可扩展标记语言 (XML) 。 Web 存储系统还包括一些新的功能，如 Outlook ?Web 访问、 Web 存储系统窗体、事件、工作流、内容索 引、搜索文件夹以及即时消息传送。这些功能为开发人员建立 KM 解决方案带来了很大的灵活性，也更容 易实现。有关 Web 存储系统的详细资料，请参见 Exchange 2000 SDK 以及(英文)。 图1. Web存储系统编程模型 建立KM解决方案 对企业中的每一个业务问题，知识管理（KM）通过选择解决问题的正确模块而不断更新。根据不同的组织 方

6、式和技术，每一模块都有自己的特性。下面列岀了一些典型特性： 扩充客户/合作伙伴/雇员的知识 快速学习并重复利用知识 提高知识产权的价值 为产品和服务提供特别的附加值 建立新知识 共享工作过程和质量革新的知识 A Intranet 图2. KM启用模块 有两项技术是所有KM系统的基础：完全Intranet和消息传送及协作。这些技术构建的基础结构支持对 信息进行有效传输、架构、访问和协同管理。 其余的KM启用模块把这一基础结构扩展成一个复杂的KM系统，该系统包含各种服务（如内容管理、各 种信息传递以及数据分析等）。其它服务（如数据跟踪、工作流过程）也包含在该系统和这些模块中。 实现KM启用模块可以

7、是即插即用的。虽然某些模块得益于先前某一模块的实现，仍可按与要开发的特定 业务案例之间的相对顺序选择它们。例如，象视频会议这样的实时协作服务，可以很容易地包含在必备技 术的上层，但要通过内容管理模块中提供的元数据服务才能得以增强。 鼻糾m . Aft 3 % 时入口 轴比L具 1:工 时a 业劳轉褪1 - 图3.可能的知识管理平台分层结构 Microsoft 当前的 KM 平台是 Microsoft BackOffice ? 系列。它提供的服务能够：建立 KM 先决条件（消 息传送及协作和完全 Intranet ），通过实现所有的 KM 启用模块（内容管理、团体和组、入口和搜索、数 据分析以及

8、实时协作） 将它们扩展成 KM 解决方案。除了这些服务， BackOffice 还提供与先前信息或知识 源集成和连接的接口。 在未来的几个月内， Microsoft 将发布 .NET Enterprise Server ，它包含 SQL Server ? 2000 、 BizTalk ? Server 、 Commerce Server 2000、 Host Integration Server 2000、 Internet Security 当前URL所表示的项（例如：ExpenseForm.htm、 ECOform.ASP）。 处理从 HTTP 请求报头读取的信息， 并与存储在 Brows

9、ecap.ini 中浏览器的信息相比较， 就可以得到浏览 器的功能信息。 ISAPI DLL 使用与窗体注册表信息最佳匹配的比较来确定显示哪一个窗体。 有关 Web 存储系统窗体的详细信息，请参考 Exchange 2000 SDK 。 设计业务服务的最佳方法 正如上文所述，业务服务是一个应用程序逻辑单元，它控制执行业务规则的先后顺序，保证所执行操作的 事务完整性。以下是一组使用 Web 存储系统设计业务服务的最佳方法： 通过使用方案确定关键业务过程 在逻辑设计阶段，开发小组应检查他们在概念设计阶段收集的方案以确定业务过程，如文档批准过程或内 容变换过程。 确定实现机制 在物理设计阶段，开发小

10、组需要确定这些业务过程最合适的实现机制。有四个基本选项：工作流引擎、事 件接收器、 COM+ 组件和脚本（客户端或服务器端脚本）。使用脚本的方法会造成一些困难，如代码不易 维护以及脚本的局限性。因此，我们建议采用前三种方法。以下是确定实现方法的一组指南： ? 如果业务过程符合以下情况，则使用工作流： ? 涉及多用户和多资源。 具有复杂过程，如批准或业务验证过程 如果岀现以下情况，则使用事件接收器: ? 只涉及少量的用户或资源。 ? 验证过程简单。 ? 具有整个存储区范围内的事件。 ? 具有定时器事件。 如果使用 Web存储系统进行的大多是读取操作而不是更新操作，且不涉及工作流，则使用COM+

11、组件。 设计数据服务架构的最佳方法 正如上文所述，数据服务是提供最低提取可见级别的应用程序逻辑单元，用于操作数据。数据服务维护作 为公司资产的永久和非永久数据的可用性和完整性。这一部分我们将讨论 Web存储系统架构设计，下一部 分讨论文件夹结构。 首先，什么是架构？对于建立在 Web存储系统技术基础上的整个物理设计模型来说，为什么架构设计 至关 重要？架构一词指的是一种定义和组织数据（有时称为元数据）的方法。在结构化查询语言（SQL）关系型 数据库中，架构包括所有的表定义和列定义，以及其它信息（如索引和触发器）。对于存储区，我们将架 构设计的重心放在内容类及与其相关联的属性集方面。架构设计对整

12、个KM解决方案是否成功有直接影响， 尤其是在性能和可扩展性方面。架构设计通常是定义数据服务模型的第一步。许多设计的考虑因素和决策 都要依赖架构设计。下面一段是对Web存储系统架构的简要介绍。 Web存储系统可用于为您的应用程序定义架构。Web存储系统架构是以内容类为中心的。内容类为存储区 中的项/实例定义架构类，是属性集的逻辑容器。 为您的应用程序创建架构定义时，要定义自定义内容类及 相关的属性。Web存储系统含有大量预定义的内容类和属性。定义自己的自定义内容类时，您可以使用或 扩展（子类）某一预定义内容类。其中包括（但不仅限于）表2.所列的内容类。 表2.内容类 内容类 说明 urn:con

13、tent-classes:item 存储区中各项的基类 urn:content-classes:message 消息的基类 urn:content-classes:calendarmessage 会议请求和响应的基类 urn:content-classes:appointment 约会的基类 urn:content-classes:person 联系人项的基类 urn:content-classes:folder 文件夹的基类 urn:content-classes:document Microsoft Office 文档的基类 Web存储系统架构的一个长处是它们为架构感知的应用程序和工具提供

14、了一种方法，可用来查找出适用于 某一特定应用程序的内容类和属性的名称。 与某一特定应用程序相关的架构信息是通过文件夹的架构范围来控制的。文件夹的架构范围是一组按某特 定顺序遍历的文件夹，它们包含架构定义项。通过在Web存储系统(其中存储您的架构信息)中定义文件 夹的列表，你可以逐个文件夹地扩展架构。范围可以很简单，只包含全局架构文件夹；也可以比较复杂， 包含一个很大的文件夹 URL的列表。 还需要查看以下两个属性来定义架构范围，这两个属性对整体架构设计一尤其是文件夹结构 一也很重 要，我们将在下一部分讨论这一主题。 ? schema-collection-ref (SCR):这一属性是一个文件

15、夹的 URL，将在该文件夹中查找内容类和属 性定义。这是搜索架构定义项的第一个文件夹，并且总是文件夹架构范围中的第一个文件夹。如 果未设置这个属性，则默认为存储区的non_ipm_subtree/Schema 文件夹，其中包含 Web存储系 统的默认架构定义项。 ? Baseschema :这一属性是个多值字符串，包含一个或多个文件夹的URL。通过确定包含架构定 义项的其它文件夹，可以扩展某文件夹的架构范围。 除了定义自定义内容类之外，定义自定义属性是架构设计的另一个重要方面。虽然Web存储系统提供许多 预定义的属性，您可以为每一项存储任意数量的其它属性；这些属性就称为自定义属性。您还可以对每

16、一 项定义一组不同的自定义属性。 自定义属性与它的关联项一起保存。检查项时可以按名称发出请求。如果使用Exchange OLEDB提供程序 或ADO直接绑定到项上，或通过HTTP/WebDAV协议发出一个0深度的PROPFIND命令，Web存储系统将 返回该项的所有自定义属性。对于所有深度为1的项属性，自定义属性对 SQL “SELECT *”语句或 PROPFIND命令都是不可见的，除非这些属性被定义为项的内容类的一部分。因此，要使架构感知的应用程 序能识别您的属性，必须把属性和内容类的定义添加到应用程序文件夹的架构范围中。 下面我们对一些通用的架构设计指南作一总结。如果您不熟悉URN、UR

17、I和URL这些词，在继续之前建议 您看一看下面的定义。 URI、URN 和 URL 统一资源标识符(URI)就是一个采用一定格式的字符串，它可用来唯一地标识一个资源。URI可以是一个 统一资源定位符(URL)或一个统一资源名称(URN)。 ? URL对定位所标识资源所需的底层协议进行编码。 ? 而URN则与位置无关，而且与定位所标识资源要使用的协议或机制也毫无关系。 HTTP URL，语法如下: URL开头带有一个标识协议的前缀，接着是一个针对协议的字符串。对于 http:/ : ? 是服务器的 IP 地址， 是服务器侦听的 TCP 端口号， 是在 HTTP 请求中作 为请求 URI 传递的绝

18、对 URI 。可选的 对应于查询字符串后缀，即用 & 分隔的关键字 / 值对的 列表。只有 URL 的主机部分是必须的。如果未指定端口，默认为端口 80 ；如果未指定路径，请求 URI 将 为“/ ”。 URN对建立现代的、适宜Internet的应用程序是至关重要的，但人们对它还远远不够熟悉。目前还没有 一种通用的方式来间接访问URN以查找它所标识的资源。URN的语法结构保证了 URN跨多个组织的唯一 性。其语法如下所示： urn: : 是命名空间标识符， 是命名空间特定的字符串。如果要标识与位置无关的内容，建议您使 用 URN 机制。对于还需要包含位置信息的标识符，则建议使用 URL 机制。

19、 架构设计指南 架构设计指南的内容如下： 使用和定义命名空间 (URN) 使用命名空间定义属性和内容类是一种好办法。命名空间的作用包括： ? 有助于确保属性和类的名称是全局唯一的；即，解决识别和冲突的问题。如果您有多个应用程序 在同一时间部署， 或者独立软件开发商 (ISV) 在一个大型组织中部署他们的应用程序时， 这一点 都是特别重要的。 ? 指示“拥有”属性或类定义的个体或组织。 在随 Exchange 2000 提供的预定义属性和类中，您会发现有许多不同类型的命名空间： ? urn:schemas:httpmail: ? urn:schemas-microsoft-com:exch-da

20、ta: ? urn:schemas-microsoft-com:office:office ? 第一个示例是一种通用的广为接受的命名空间，目的是为了增强各种架构感知应用程序间的互操作性。 urn ： 接下来的两个是专用 URNo如果您希望为您的应用程序创建一个类似的命名空间，您可以创建 schemas-mycompanysdomain-com:myapplication:。 第二个和第三个命名空间的差别就在于：第二个命名空间的结尾有一个命名空间分隔符而第三个命名空间 没有。如果命名空间以分隔符“ :”或“ / ”结尾，将创建属性或内容类名称，且属性名附于命名空间后。 例如，第二个命名空间中的一

21、个属性是 urn ： schemas-microsoft-com:exch-data:ismultivalued 。 如果命名空间不以分隔符结尾（如第三个示例），则该命名空间中将创建属性名，命名空间与属性名之间 有一个符号“ #”。例如，第三个命名空间中的一个属性是urn ： schemas-microsoft-com:office:office#Author 。 最后一个命名空间示例显示如何将 URL 用作命名空间。您应当从您拥有或已注册的 URL 中选择基于 URL 的命名空间。这将有助于保证命名空间的唯一性。 URL 用作命名空间时，最后一个分隔符为字符“ / ”。 不应向您不拥有的命名

22、空间中添加属性或内容类。例如，向 或 DAV: 命名空间添加属性就不好，而应当 为您的内容类和属性创建自己的命名空间。 进行属性定义 Web 存储系统本身对属性名称中可使用哪些字符没有特殊的限制。但是，最好还是遵守以下一些约定： ? 应当使用命名空间来创建属性并加上一个标识符（如上文所述）。例如， urn:schemas-sample-com:engineering:eco. ? 属性应当是格式正确的 URI 。 ? 属性名称中不应有空格，因为 XML 不支持在元素名称中使用空格，因此HTTP-DAV 也不支持。 定义自定义内容类 在定义了这些自定义属性之后，下一步就是定义您的自定义内容类。首

23、先，您需要为应用程序选择一个文 件夹，用来存储架构信息。您可以将这些信息存储在您的应用程序数据所在的同一文件夹中，但我们强烈 建议您使用一个不同的子文件夹，我们称之为架构文件夹。如果您在正定义的架构不是针对某一个应用程 序的，您可以在相关的公共存储区里的高层架构文件夹中定义它。 存储架构定义的位置和组织架构定义的方式由您决定。但是，在下一部分中，我们将推荐一组方式，指导 您如何组织文件夹结构以及如何确定对一组特定应用程序数据应用哪一个架构定义。 下面的关系图阐释了使用一个 Exchange 2000 SDK 工具（即： Web 存储系统架构设计器）来自定义内容类 的一个示例。我们建议您使用该工

24、具或类似工具来定义自定义内容类的定义和属性定义。 图7.示例：架构设计 考虑内容类的继承性 您当然可以从头开始定义一个全新的内容类。不过，多数内容类都可以扩展（“继承”）现存的内容类。 扩展内容类意味着 已扩展的（派生的）内容类实例的所有属性也存在于扩展中的（基本的）内容类实例中 这一概念与C+这样的面向对象（00）的编程语言中类继承的概念相似。 图10显示一个简单的继承方案。扩展文档类意味着任何可在文档类实例上执行的代码或操作都可以在 expensereport 类实例上执行。 图8.简单内容类继承 图9.带有多个继承关系的内容类 内容类也可扩展为多个内容类。在图11中，我们还能看到一个ex

25、pensereport 类，它具有totalcost 和 approvastate两种属性。但在这一方案中我们希望有作为文档的一个特定类的费用报告和作为消息的一 个特定类的费用报告。因此，我们创建一个exprensereport 类来扩展该类。然后创建一个 exprensemessage 类和一个 exprensedocument类，它们自己没有其它属性。Expensemessage 扩 展了 expensereport 和 message ，而 exprensedocument 扩展了 exprensereport 和 document 。 现在，理解message 类的应用程序就可以理解

26、expensemessage类的一些属性，而把其余属性当作自 定义属性。理解 document 类的应用程序就可以理解exprensedocument类的一些属性。 有关架构设计的详细信息，请参考Exchange 2000 SDK以及白皮书“ Web存储系统架构：使用和最佳方法 指南。” Web存储系统文件夹结构的最佳方法 Web存储系统为设计文件夹结构提供了很大的灵活性。架构定义项可置于特定存储区内的任一文件夹中， 并用于为您的应用程序定义架构。通过合理设置不同文件夹的schema-collection-ref 和baseschema属 性，您可以将这些定义引入到范围中来。 为了避免设计和管

27、理应用程序架构太过复杂，应规划并组织好您的架构信息。例如，可以选择在您指定为 架构文件夹的应用程序文件夹的顶层下创建文件夹。设计文件夹结构有许多种方式。以下步骤概述了这一 过程。 考虑以下各项： ?逻辑模型的复杂程度：正如上文所述，设计存储区的架构有许多方式。在作岀最终设计决定前应 当考察所有相关的信息和设计选项。 ?物理模型的复杂程度：您应当考虑到维护复杂文件夹结构的困难程度。 ?性能影响：将在以后的部分中讨论。 重复使用和共享架构。 将架构文件夹与其它类型的文件夹区分开来，例如： ? 应用程序文件夹：包括 ASP 页面、 HTML 页面、 Web 存储系统窗体等等。 ? 数据（内容）文件夹

28、：包括数据项或文档。 ? 窗体注册文件夹：包括窗体注册项。 通常，特定应用程序的架构定义将置于它们自己的文件夹中。将应用程序文件夹和数据文件夹分开也是一 种好方法。正如上文所述，特定文件夹的 schema-collection-ref （SCR） 和 baseschema 属性确定架构范 围。设计文件夹结构有许多灵活的方式。 文件夹结构的示例如下： ? 一个简单的应用程序可以有一个包含应用程序文件（ASP、HTML 页面）和数据项的文件夹，以及 一个架构文件夹。 ? 稍微复杂点的应用程序可以分别有单独的应用程序文件夹、数据文件夹和架构文件夹。 ? 架构文件夹可以有不同的级别，如顶级架构文件夹包

29、含在同一根下运行的所有应用程序。也可以 采用一系列架构文件夹，每个架构文件夹通过 SCR 引用另一个架构文件夹。 定义架构文件夹。 ? 定义常用的内容类和属性定义。 ? 定义窗体注册。（这可能在一个单独的窗体注册文件夹中。） 创建架构文件夹时，您必须确定这些文件夹的范围。即，某一给定的架构文件夹适用于哪些数据文件夹？ 任意数量的数据文件夹可以使用一个架构文件夹。反之，在多个架构文件夹中定义的架构可以应用于一个 数据文件夹。 正如上文所述， schema-collection-ref 是一个可在数据文件夹上设置的属性，用来指示在查找相关属性 和内容类定义时应首先搜索哪个架构文件夹。 basesc

30、hema 属性则形成一个架构文件夹的树形结构来搜索 架构定义。 在这个架构文件夹的逻辑树中， 每个节点都可有许多子节点。 这个架构文件夹的逻辑树可以 （并 且通常会）与存储区中文件夹的物理布局不同。相对于给定的数据文件夹， schema-collection-ref 属性 指示搜索始于哪个架构文件夹。 定义应用程序和数据文件夹。 ? 如果需要，将 schema-collection-ref （SCR） 属性指向架构文件夹。 ? 使用 baseclass 和 expected-content-class 。 SQL 与 Web 存储系统 这一部分我们考察 SQL 关系型数据库和 Web 存储系统

31、间的主要差别；讨论何时使用 SQL 以及何时使用 Web 存储系统；并提供一套指南，用于从已有的 SQL 数据库向 Web 存储系统移植数据。 表3阐释了 SQL数据库与 Web存储系统的不同之处。注意 SQL数据库与基于 Web存储系统的 Microsoft 产品（如 Exchange 2000 ）有一组相同的服务。 表3. SQL数据库和 Web存储系统 SQL数据库 Web存储系统 关系型数据库 类似于对象数据库 结构化数据 半结构化数据 表 文件夹（以及内容类） 列 内容类和属性 固定行 不固定行 集中于业务智能 协作 以事务为中心 以文档为中心 数据完整性：主键/外键 无主键/外键

32、矩形数据 非矩形 触发器 事件接收 存储过程 无可比实体（与之类似的是事件） 如果现有的KM解决方案正在从SQL关系型数据库中读取数据，而这些数据是典型的非矩形半结构化数 据，您最好考虑将这些数据从 SQL移植到Web存储系统。 请参照以下指南，将数据从 SQL移植到Web存储系统： ? 首先，将SQL列映射到属性，将SQL表映射到文件夹和内容类。 ? 确定表的主键和外键。根据逻辑设计模型查找与之对应的内容类。 ? 通过确定一组能生成项的唯一实例的属性来模拟主键。 ? 考虑内容类的继承性。 物理设计考虑因素 到此，我们已经讨论了设计用户服务、业务服务和数据服务的最佳方法。这一部分我们将集中讨论

33、物理设 计阶段针对Web存储系统的设计考虑因素。 对每个设计考虑因素主题，我们都将介绍一些重要的概念、讨论一些您可以采取的折衷措施，并列出一张 清单，供您在考虑各种选项时参考。 安全模型 这一部分中概述了 Web 存储系统安全模型。除了使用 MAPI 客户程序(如 Outlook )或 Windows 文件系 统 API 来控制安全设置外，您还可以使用基于 XML 的安全描述符来控制对某一项及其属性的访问。使用 Web 存储系统安全描述符，您可以： ? 既可将对某一项及其属性的访问权授予受托者(具有凭证、正在访问该项的人)，也可以拒绝该 受托者进行访问。 ? 使用 Microsoft Wind

34、ows? 安全标识符 (SID) 标识受托者。 ? 设置、检索和修改 XML 格式的描述符。 ? 使用 Microsoft Exchange OLE DB (ExOLEDB) 提供程序和 XML 格式的 HTTP/WebDAV 协议访问描 述符。 每一项的安全描述符都通过该项的 属性访问。这个属性是项的 XML 格式的描述符。 该描述符以 Exchange 2000 Server 特有的二进制格式进行物理存储和复制，这种格式内部是基于标准的 Windows 2000 描述符 格式的。如果文件夹中的某项没有特定的安全描述符，其父文件夹中指定的默认权限将被应用于该项。 安全描述符是一种数据结构，它

35、包含以下内容(以及其它未列出的内容)： ? 一个所有者字段，其中包含对象所有者的安全标识符 (SID) ，该对象与安全描述符相关联。 ? 一个任意访问控制列表 (DACL) 字段，指定谁对该对象字段具有访问权。 ? 一个系统访问控制列表 (SACL) ，指定系统可以审计哪些操作。 访问控制列表 (ACL) 包含一个或多个访问控制项 (ACE) ；每个 ACE 为安全负责人 指定访问权限。 Windows 2000 中的安全负责人可以是一个用户或一组用户。 Exchange 2000 定义了一个新的安全负责人， 叫做 角色 。 角色是一个具有名称的安全负责人(用户或组)的集合，它可在 ACL 里

36、的 ACE 中引用。角色与 Windows 2000 组之间主要的区别在于 Exchange 安全角色是针对对象本身定义和存储的。 也就是说不需要进行具备 特权的目录服务操作，就可以创建这些角色，并填入成员。 对于不需要具备特定 Windows 2000 组就可以部署的应用程序，这一功能是非常重要的。安全角色在 Web 存储系统中创建和存储，而与 Windows 2000 目录服务无关。对应用程序开发人员来说，安全角色具备两 个明显的优势： ? 创建角色不需要使用特权的 Active Directory ? 操作 而这是分部门方案的一个关键要求。 ? 因为角色的作用范围是特定的文件夹(或按文件

37、夹层次结构组织的应用程序)，因此只在文件夹 范围内要求角色的名称唯一。这样，部署在一台运行 Exchange Server 的计算机上的两个应用程 序不需要使用不同的角色名称和成员。 因为角色只在应用程序的设计阶段才被 引用，所以它们在应用程序中只是存在，而不产生影响。程序运行 时将 评估 它们，所以应用程序开发人员可以等到部署应用程序时才加入这些角色。这样程序开发人员就不 必为每次部署而重新编译应用程序。正如上文所述，只要可以对文件夹和项设置 ACL,就可以在Web存储 系统中使用角色。 在用户对某项或文件夹（对象或父对象）定义的“角色成员”属性中填入一个安全负责人（用户、组或角 色）列表，

38、就可以实现安全角色。具体说来，该列表包含安全标识符（SID） ，这些 SID 代表了安全负责人 并为给定角色形成成员列表。角色 SID 与 Windows 2000 SID 不同， Exchange Server （而不是 Windows ） 拥有对它的安全控制。角色 SID 是独立结构的，不包含任何 Windows 2000 的特定安全信息，因此可在多 个域中使用。角色 SID 将为两种信息进行编码： ? 属性：角色属性包含 SID 列表， ACE 就应用于这些 SID 。这一列表中的 SID 既可以是 Windows 2000 SID ，也可以是角色 SID 。 ? 范围 ：该信息指示读取

39、角色属性的位置。 有关安全角色的详细信息，请参考（英文）。 使用 Web 存储系统设计 KM 解决方案的安全模型时，您应当考虑以下列出的内容： 通过概念设计模型和逻辑设计模型确定安全需求 ? 用户 他们的角色和内容访问需求 ? 业务需求，例如隐私和其它有关法律的需求 ? 外部访问 “角色”一词这里表示业务角色，而不是我们前面讨论的 Exchange 角色。即在您开始定义安全模型前应 收集尽可能多的信息。 定义安全策略 ? 根据业务需求将用户分组 ? 定义用户角色 ? 定义应用程序安全模型 例如，谁可以创建事件或工作流 ? 定义内容安全模型 例如，项一级的安全、属性一级的安全 ? 定义外部访问

40、例如，防火墙和与公共密钥基础结构 （PKI） 的集成 性能 KM 解决方案的性能特征通常与联机事务解决方案有显著区别。它不是快速计算数字， 而是注重以下性能特 征： 返回搜索结果或定位具体内容的响应时间 ? 创建、分类和检索内容的响应时间。 ? 处理业务过程（例如批准过程）的响应时间。 正如上文所述， Web 存储系统为建立 KM 解决方案提供了强大的功能和高度的灵活性。要充分利用这些功 能，您需要注意数据访问和处理方式对性能的影响。 要获得最佳性能，请遵循以下指南： 频繁执行深度遍历搜索时使用搜索文件夹 如果您有一个分层文件夹结构，并且您的应用程序必须执行对该层次结构的深度遍历搜索，使用搜索

41、文件 夹可以极大提高应用程序的性能。设置搜索文件夹还可以用来将大文件夹分割成较小的文件夹（根据逻辑 关系）。 例如，假设有一个 KM 应用程序，用来跟踪记录公司雇员生成的各种项目文档。一开始，有成千上万个文 档需要跟踪记录， 这些文档是按照主题在分层结构中组织的。 每一天系统中的文档都会被频繁添加或删除。 在一个正常工作日中，雇员需要频繁搜索存储区中的所有文档才能找到由某些作者编写的文档。由于搜索 必须浏览的记录和文件夹的数量极大，要在整个层次结构中执行这些搜索，成本会相当高昂。在这种情况 下，这种成本高昂的、对全部记录进行的搜索只需要执行一次，其结果可以添加到一个搜索文件夹中。 这个搜索文件

42、夹现在包含存储区中这些作者编写的所有文档。 如果某些文档被添加到存储区 （和层次结构） 或从中删除， Web 存储系统会在必要的时候更新搜索文件夹。如果雇员要搜索存储区中的文档，只需要在 搜索文件夹中而不是层次结构中进行搜索。这样可以搜索到所有相关记录，但不必浏览整个层次结构。 使用搜索文件夹可能造成添加 / 更新/ 删除那些用于创建该搜索文件夹的、在查询范围内的项时，性能会稍 有下降。这种延迟是因为每次进行这样的操作后都必须更新搜索文件夹。因此，我们建议只有在被搜索数 据不会频繁更新的情况下，才应在频繁进行的查询中使用搜索文件夹。 频繁搜索地索引属性 为属性一级编制索引是为频繁执行的搜索提高

43、性能的最好方式。如果改变用于计算那个利用了已索引属性 的 where 子句的表达式的成本， 就可以将显著改善搜索性能。 有关创建索引的信息， 请参考 Exchange 2000 SDK 中的“属性索引”主题。 为属性一级编制索引只能对在用于搜索的 where 子句中使用已索引属性的情况下， 帮助改善搜索性能。 使 用属性一级的索引时，应用程序从已创建索引的文件夹中执行插入 /更新/ 删除项的操作时时，将出现轻微 的性能下降（大约每个索引 1%）。发生这种性能降低的原因是需要更新文件夹索引信息以反映更新操作。 由于存在这一问题，为了尽可能优化应用程序的性能，只应对频繁搜索的属性创建索引。 只在绝

44、对必要时执行“ SELECT *”操作 执行“ SELECT* ”操作要求 Web 存储系统在架构中进行查找被搜索项，以确定要返回哪一组属性。架构计 算的成本可能很高，而且最终成为搜索请求的总成本中很大的一部分。如果只请求需要的列，应用程序可 以避免这部分的额外成本开支。 例如，如果某项有一个关联的自定义架构，它包含属性 “ DAV:displayname ” 和 “DAV:lastmodified ” 下面的第一个搜索执行起来将比第二个快得多，尽管它们返回的数据相同。 ? SELECT DAV:displayname, DAV:lastmodified from scope(SHALLOW

45、TRAVERSAL OF ) ? SELECT * from scope(SHALLOW TRAVERSAL OF ) ? 只搜索文件夹时执行层次结构的遍历。 如果是搜索文件夹，通过指定搜索应使用层次结构而非深度遍历，应用程序可以提高搜索性能。例如，下 面的两个搜索将返回相同的资源，但与第二个搜索相比，第一个搜索的返回速度更快，而且使用的服务器 资源也较少。 ? SELECT DAV:displayname from scope(HIERARCHICAL TRAVERSAL OF ) ? SELECT DAV:displayname from scope(DEEP TRAVERSAL OF )

46、 WHERE DAV:iscollection = true 尽可能指定多个浅层范围，而不是执行深度遍历搜索 执行多个浅层遍历搜索比执行一个深度遍历搜索的效率高。 深度遍历搜索要求 Web 存储系统锁定待搜索的 层次结构(避免执行搜索时层次结构发生变化)，但是浅层遍历搜索没有这一限制。构建搜索请求时，可 以在查询中指定多个范围。所有列出的范围必须是相同类型的范围(即，都是深度的或都是浅层的)。有 关详细信息，请参考 Exchange 2000 SDK 中的“搜索范围”主题。 保守使用同步事件 创建 Web 存储系统应用程序时， 同步事件是一个强有力的工具， 但它们也可能给性能带来严重影响。如果

47、 正在执行的同步事件使用某给定资源，所有要使用该资源的其它操作都将被阻塞，直到该同步事件完成为 止。因此，应尽可能使用异步事件。异步事件的功能不如同步事件丰富，但在对资源进行非串行化访问时， 异步事件更有优势。 对与事件一同使用的 COM+ 组件进行性能调整 使用 COM+ 组件实施事件时，应遵循调整 COM+ 组件的正规操作方式。 可伸缩性与可用性 Exchange 2000 相对于 Exchange Server 的以前版本在可伸缩性与可用性方面有很大的改进。 Exchange 2000 中有助于改善应用程序可伸缩性与可靠性的功能包括： 多个存储区和存储组，减少了备份和恢复的时间，并扩展可

48、伸缩性与可靠性。 ? 活动 / 活动群集，注重提高 KM 应用程序的可靠性和可访问性。 ? 网络负载平衡，它代表另一种形式的群集化，注重在多个服务器间分配网络流量，而不是在发生 服务器故障时确保可访问性（象在活动 / 活动群集中那样）。 ? 分布式前台 / 后台服务器配置结构， 从而可以在多个服务器上划分服务分区， 并且在此过程中允许 Exchange 扩展到能够满足大规模的企业、 ISP 以及 ASP 的需要。 ? 使用 Windows 2000 Active Directory满足安全要求，以便处理集中管理和可靠性的问题。 ? Web 存储系统依靠存储组、 多数据库、 群集以及自身 MIM

49、E 存储，不仅可以与 IIS 集成和快速传 递流媒体文件，并且提供可伸缩性与可靠性。除此之外， Exchange 还负责存储区的 复制 ，以便在 需要时还可以使用这部分存储区。 有关上述功能的详细信息，请参考 Exchange 2000 联机文档和以下白皮书： ? （英文） ? （英文） ? （英文） 指南回顾 概括起来，以下是使用 Exchange 2000/Web 存储系统设计 KM 解决方案的指南的列表： 对不同应用程序创建和划分多个存储区 现在，Exchange 2000支持包含多个公共文件夹树，或称为顶级层次结构（TLH）的功能。此外，对于每 个公共文件夹树来说， Exchange

50、2000 仅将其复制到各服务器的一个公共文件夹存储区中。由于这种复制 带有更多的限制， 管理人员现在可以将选定的几组公共文件夹分别限定在各个服务器上，这样更容易控制， 还可以提高在这些存储区上运行的应用程序的可用性。 在单独的驱动器上安装并保护事务日志 为了保证容错性，以及即使服务器发生故障后仍能恢复存储区，Exchange 2000 与它以前的版本一样都要 依靠于事务日志文件中的事务记录。事务日志充当内存与磁盘上数据库之间的防错中介。在设置和管理事 务日志和数据库时，建议您遵照下列最佳方法： ? 通过诸如磁盘镜象 （RAID） 这样的方式保护驱动器，防止可能的硬件故障造成的损失。 ? 在单独

51、的驱动器上保存事务日志和数据库（存储区）。 ? 保持每个服务器上事务日志驱动程序的数量与存储组的数量相等，以及将每个事务日志设置在不 同的位置上，以使性能达到最佳。 始终将文件系统格式化为符合 NTFS 的要求 关闭循环日志记录功能 设置前台服务器以处理接收的协议请求，设置后台服务器用作 Web 存储区 在这种配置形式中，前台服务器可专用于处理接收的客户连接和协议请求。后台服务器可专用于管理数据 库（存储区）。显然，这种在多个服务器间分配负载的功能有助于提升 Exchange 的容量，从而满足上百 万个用户的需求。此外，将这些操作分开也有利于提高整个系统的可靠性。重要的组件不再被固定到几个 服

52、务器中的某一个上。 为提高可用性使用群集和网络负载平衡服务 正如上文所述， 群集是将服务器分组的一种方式 即使这些服务器是独立的、 分离的计算机 对网络而 言它们是一体的。 它们相互协作， 从而保证即使其中一台发生故障， 另一台能够随时接管并继续提供服务。 在 Exchange 2000 中， 群集是活动 / 活动的，即 Exchange 服务可在群集中的所有服务器上同时运行。如 果其中一台出现故障，另一台能够接管故障服务器的职能，同时还能继续处理自己的任务。 注意： 群集要求 Windows 2000 Advanced Server或 Windows 2000 Datacenter Serv

53、er。 Windows 2000 的网络负载平衡服务与其它类型的基于硬件的解决方案相比，基本上是一种基于软件的负载 平衡解决方案。网络负载平衡服务的功能是抓取进入的 TCP/IP 流量，然后将它平均分配到一个负载平衡 群集中的各个服务器上。 为群集指定一个 IP 地址 （如果主机是归属于多个系统的， 即连接到多个网络上， 则指定一组地址） 。如果主机发生故障或脱机，负载平衡服务能将网络流量重新引导到正常工作的主机上， 因为连接中断后客户机会重试， 最终用户最多只会感到一两秒的延迟， 就可接到正常工作的服务器的响应。 设计事件和工作流过程时要注意可用性 为适应应用程序可用性的需求 使应用程序在发

54、生非致命错误的情况下仍保持运行 您应当注意错误 的处理，特别是事件接收器、COM+组件和工作流方面的错误。这是为了能够从大多数非致命错误中恢复， 同时不丢失服务。 分类的实现 管理和实现 分类是 KM 解决方案需要成功完成的关键任务之一。分类一词指划分和组织内容的方法，它通 常是 KM 解决方案内容管理模块中的一个核心服务。 使用 Web 存储系统实现分类有多种方法。这里我们比较三种方法的优点和缺点。 Active Directory 你可以扩展 Active Directory 架构以包含分类，如与用户或雇员相关的内容信息以及组织和地域信息。 如果内容信息不常更新， 这种方法会很有效， 它通

55、常适用于整个企业。 它也能从使用 Active Directory 基 础结构中获益。另一方面，这种方法的缺点包括： 如果内容信息时常更新，或在处理不适用于整个企业的特定信息时，效果不佳。 ? 如果分类发生改变，管理 Active Directory架构扩展将比较困难。 ? 要复制整个企业范围内的 Active Directory架构扩展，还需要额外的开销。 文件夹以及内容类 如果采用这种方法，您要定义内容类及适当的文件夹结构（上文所述的分层结构或单层文件夹结构均可） 来存储内容信息。这种方法适用于内容信息时常更新的情况。但是，最好留意这种方法的一以下些潜在缺 陷： ? 在“性能”部分我们已经

56、讨论过，检索内容信息的性能在很大程度上依赖于您为自定义属性编制 索引的方式以及您设计的 SQL查询的方式。 ? 在某些情况下，改变分类或用新的分类替代它可能比较困难，需要改变文件夹结构。 搜索文件夹 搜索文件夹的方法与内容类方法相似，只是分类是存储在搜索文件夹中的。正如上文所述，搜索文件夹是 动态的，它们的内容时常被 Web存储系统重新评估并更新。换言之，搜索文件夹包括指向物理对象的指针 （类似于符号链接）。 与业务范围应用程序的集成 现实的KM解决方案必须与其它业务范围 （LOB）应用程序集成。例如，一个KM解决方案需要从其它 LOB 应用程序（如人力资源应用程序或制造过程应用程序）中获取源内容和数据。在另一种情况下，KM解决方