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

1、使用 Web 存储系统设计知识治理解决方案Walson Lee Microsoft Corporation 2000年10月 摘要： 本文概述了使用 Web 存储系统开发高效的知识治理解决方案的设计过程。目录 HYPERLINK /China/msdn/msdnonline/features/articles/DesignKMSols.ASP l designkmsols_topic1#designkmsols_topic1 简介 HYPERLINK /China/msdn/msdnonline/features/articles/DesignKMSols.ASP l designkmsols

2、_topic2#designkmsols_topic2 Web 存储系统用作开发平台 HYPERLINK /China/msdn/msdnonline/features/articles/DesignKMSols.ASP l designkmsols_topic3#designkmsols_topic3 建立 KM 解决方案 HYPERLINK /China/msdn/msdnonline/features/articles/DesignKMSols.ASP l designkmsols_topic4#designkmsols_topic4 Microsoft 解决方案框架：基于服务的应用程序

3、模型 HYPERLINK /China/msdn/msdnonline/features/articles/DesignKMSols.ASP l designkmsols_topic5#designkmsols_topic5 MSF 设计过程 HYPERLINK /China/msdn/msdnonline/features/articles/DesignKMSols.ASP l designkmsols_topic6#designkmsols_topic6 KM 解决方案设计模型 HYPERLINK /China/msdn/msdnonline/features/articles/Desig

4、nKMSols.ASP l designkmsols_topic7#designkmsols_topic7 设计用户服务的最佳方法 HYPERLINK /China/msdn/msdnonline/features/articles/DesignKMSols.ASP l designkmsols_topic8#designkmsols_topic8 设计业务服务的最佳方法 HYPERLINK /China/msdn/msdnonline/features/articles/DesignKMSols.ASP l designkmsols_topic9#designkmsols_topic9 设计

5、数据服务架构的最佳方法 HYPERLINK /China/msdn/msdnonline/features/articles/DesignKMSols.ASP l designkmsols_topic10#designkmsols_topic10 Web 存储系统文件夹结构的最佳方法 HYPERLINK /China/msdn/msdnonline/features/articles/DesignKMSols.ASP l designkmsols_topic11#designkmsols_topic11 SQL 与 Web 存储系统 HYPERLINK /China/msdn/msdnonli

6、ne/features/articles/DesignKMSols.ASP l designkmsols_topic12#designkmsols_topic12 物理设计考虑因素 HYPERLINK /China/msdn/msdnonline/features/articles/DesignKMSols.ASP l designkmsols_topic13#designkmsols_topic13 安全模型 HYPERLINK /China/msdn/msdnonline/features/articles/DesignKMSols.ASP l designkmsols_topic14#d

7、esignkmsols_topic14 性能 HYPERLINK /China/msdn/msdnonline/features/articles/DesignKMSols.ASP l designkmsols_topic15#designkmsols_topic15 可伸缩性与可用性 HYPERLINK /China/msdn/msdnonline/features/articles/DesignKMSols.ASP l designkmsols_topic16#designkmsols_topic16 指南回忆 HYPERLINK /China/msdn/msdnonline/featur

8、es/articles/DesignKMSols.ASP l designkmsols_topic17#designkmsols_topic17 分类的实现 HYPERLINK /China/msdn/msdnonline/features/articles/DesignKMSols.ASP l designkmsols_topic18#designkmsols_topic18 与业务范围应用程序的集成 HYPERLINK /China/msdn/msdnonline/features/articles/DesignKMSols.ASP l designkmsols_topic19#desig

9、nkmsols_topic19 结论 简介 Microsoft Exchange 2000 Server 是引入一种新的称为 Web 存储系统的存储技术的第一个 Microsoft 产品。Microsoft 的 Web 存储系统提供许多新的开发功能，例如 Web 存储系统事件与窗体、工作流引擎、内容索引以及搜索文件夹。这些功能特不适用于知识治理 (KM) 解决方案。然而，KM 解决方案的开发人员开始时需要通过一个学习过程，才能理解这些功能，并逐个理清 Web 存储系统提供的许多个设计选项的作用。本文着重讲解了有关开发 KM 解决方案的设计方面的知识，并讨论了最佳方法、设计模式以及设计过程中的考

10、虑因素。其中展示了基于服务的应用程序模型和基于 Microsoft 解决方案框架 (MSF) 的设计过程。那个设计过程是专为使用 Web 存储系统建立 KM 解决方案量身定做的。设计过程包含了概念设计模型、逻辑设计模型以及物理设计模型。本文重点讲述针对 Web 存储系统的物理设计模型的设计考虑因素： 用户服务 数字仪表板和 Web 存储系统窗体 业务服务 工作流和事件设计 数据服务 存储架构设计 安全模型 性能 可伸缩性与可用性 分类的实现 与业务范围 (LOB) 应用程序集成 本文旨在提供一种设计基于 Web 存储治理系统技术的 KM 解决方案的正确方法。它所面向的读者是 KM 解决方案的构

11、建或设计人员。其他开发人员也能从本文阐述的差不多设计概念中获益。 Web 存储系统用作开发平台 Web 存储系统是 Microsoft 为体现它的“不受限制的知识工作者”理念而宣布的四项创意之一。这些创意的要紧目的是消除当今知识工作者面临的阻碍相互协作的障碍。 Web 存储系统将文件系统、Web 以及协作服务器的功能组合到一个位置，以便存储、访问、治理信息以及建立和运行应用程序。 Web 存储系统中的每一项差不多上可用 URL 寻址的，同时完全支持半结构化数据，如文档、联系人、消息、报告、HTML 文件以及 Active Server Pages (ASP)。Web 存储系统提供与 Micro

12、soft Office 2000 的高性能集成。它为信息治理（包括一致搜索和数据分类）建立了一个平台。图 1 阐释了 Web 存储系统的编程模型。从图中可看出它支持不同的协议、数据访问方式和事件模型。对 Web 存储系统的数据访问包括对 OLE DB 和 ActiveX Data Objects (ADO) 的支持。Web 存储系统还提供通过 HTTP 协议进行访问的功能。 HYPERLINK /pub/ietf/webdav/ WebDAV 规范（英文）增强了这一功能，使它可支持另一组协议命令。此外，该存储系统本身还支持可扩展标记语言 (XML)。Web 存储系统还包括一些新的功能，如 Ou

13、tlook Web 访问、 Web 存储系统窗体、事件、工作流、内容索引、搜索文件夹以及即时消息传送。这些功能为开发人员建立 KM 解决方案带来了专门大的灵活性，也更容易实现。有关 Web 存储系统的详细资料，请参见 Exchange 2000 SDK 以及 HYPERLINK /exchange/ MSDN Exchange Server 开发人员中心（英文）。图 1. Web 存储系统编程模型建立 KM 解决方案 对企业中的每一个业务问题，知识治理 (KM) 通过选择解决问题的正确模块而不断更新。依照不同的组织方式和技术，每一模块都有自己的特性。下面列出了一些典型特性： 扩充客户/合作伙伴

14、/雇员的知识 快速学习并重复利用知识 提高知识产权的价值 为产品和服务提供特不的附加值 建立新知识 共享工作过程和质量革新的知识 图 2. KM 启用模块有两项技术是所有 KM 系统的基础：完全 Intranet 和消息传送及协作。这些技术构建的基础结构支持对信息进行有效传输、架构、访问和协同治理。其余的 KM 启用模块把这一基础结构扩展成一个复杂的 KM 系统，该系统包含各种服务（如内容治理、各种信息传递以及数据分析等）。其它服务（如数据跟踪、工作流过程）也包含在该系统和这些模块中。 实现 KM 启用模块能够是即插即用的。尽管某些模块得益于先前某一模块的实现，仍可按与要开发的特定业务案例之间

15、的相对顺序选择它们。例如，象视频会议如此的实时协作服务，能够专门容易地包含在必备技术的上层，但要通过内容治理模块中提供的元数据服务才能得以增强。图 3. 可能的知识治理平台分层结构Microsoft 当前的 KM 平台是 Microsoft BackOffice 系列。它提供的服务能够：建立 KM 先决条件（消息传送及协作和完全 Intranet），通过实现所有的 KM 启用模块（内容治理、团体和组、入口和搜索、数据分析以及实时协作）将它们扩展成 KM 解决方案。除了这些服务，BackOffice 还提供与先前信息或知识源集成和连接的接口。在以后的几个月内，Microsoft 将公布 .NET

16、 Enterprise Server，它包含 SQL Server 2000、 BizTalk Server、 Commerce Server 2000、 Host Integration Server 2000、 Internet Security & Acceleration Server 2000、 Exchange 2000 Server 以及 Application Center 2000。设计这些组件的目的是通过它们的紧密协作来建立下一代的 Web 应用程序。本文的重点是 Web 存储系统，它是 Exchange 2000 以及 Microsoft 以后产品的基础存储技术。Web

17、存储系统是建立和提供以下关键知识服务所需的一个开发平台： 搜索与传递 协作 文档治理 跟踪和工作流 有关详细信息，请参考 HYPERLINK /solutions/km/KMSols.htm 建立知识治理解决方案白皮书（英文）。Microsoft 解决方案框架：基于服务的应用程序模型 为了奠定一个基础，以便您掌握下面关于如何设计 KM 解决方案的讨论，我们将依照 Microsoft 解决方案框架 (MSF) 白皮书，简要概括 MSF 的基于服务的应用程序模型。有关详细信息，请参考 HYPERLINK /msf Microsoft 解决方案框架白皮书（英文）。MSF 提倡使用基于服务的应用程序模

18、型来设计和实现分布式组件和业务解决方案。“基于服务的应用程序模型”是指应用程序的功能定义为一组服务集合。按照 MSF 的观点，一个应用程序是由服务的使用者与提供者组成的逻辑网络构成的。在这一模型中，使用者能够是一个用户或另一个服务组件。这些服务能够跨越物理和功能的边界，满足各种不同应用程序的需求。什么是服务？服务确实是一组应用程序逻辑，它针对对象实现操作、功能或转换。服务能够执行业务规则，计算或治理数据，提供输入、检索、查看或修改信息等功能。为进一步精确讲明服务网络的分布特性， MSF 应用程序模型定义了组成一个应用程序的三类服务： 用户服务是提供应用程序接口的应用程序逻辑单元。应用程序的用户

19、能够是一个用户或另一个应用程序。 因此，应用程序的接口能够是图形用户界面 (GUI) 和/或应用程序编程接口 (API)。 业务服务这种应用程序逻辑单元用于操纵业务规则的先后顺序和执行，同时能够保证所执行操作的事务完整性。通过应用恰当的业务规则，业务服务可将数据转换成信息。 数据服务是提供最低提取可见级不的应用程序逻辑单元，用于操作数据。数据服务维护作为公司资产的永久和非永久数据的可用性和完整性。它们提供创建、读取、更新和删除服务，如此业务服务（数据服务的使用者）就不需要了解数据的位置、实现方式和访问方式了。 MSF 设计过程 设计业务解决方案的过程可与设计建筑一座建筑物相比。好的建筑师只有了

20、解了客户的需求才真正了解了客户。在系统设计中，可有多个视角描述最终产品，这与建筑是一样的。每一个视角差不多上为不同的受众预备的，它们的详细程度也不尽相同。KM 解决方案的设计也是如此 应用程序有不同的重点和技巧。设计人员专注于用户界面、业务过程或数据库问题，我们需要为他们提供一种途径来协调和同步他们的工作，使他们能高效地、有组织地利用他们的专业技能完成全面平衡的设计。MSF 设计过程分三个时期： 概念设计 逻辑设计 物理设计 概念设计 概念设计是指确切了解要解决的问题，然后以治理方和用户都能理解的方式构架出问题的解决方案。与单纯收集需求相比，它的范围要广得多。那个时期还需要依照具体环境来处理这

21、些需求，从而合理决策。 概念设计提取出要执行业务活动所需的本质任务和信息，从而按照既紧密围绕过程，又以用户为中心的方式看待解决方案。在 MSF 中,方案是概念设计过程的关键结果。一个方案描述在某种业务环境中用户执行的与行为相关的一系列任务或事务。方案必须依照负责这项工作的用户的需要（以用户为中心）来提取业务解决方案的需求（围绕过程）。逻辑设计 逻辑设计是指通过定义系统各部分及它们间相互作用的方式来描述解决方案的过程。这一过程组织新系统的逻辑结构并阐释该系统的组成方式以及它与外部世界的接口。在逻辑设计过程中，必须加深项目组对系统的认识。这是确定设计的详细程度的要紧考虑因素。逻辑设计提供的组织和结

22、构规则必须满足各个独立的组成员同时高效工作的要求，还要奠定与外部项目和构架进行协作的基础。逻辑设计提供了评价各种物理设计选项的基础。通过不同的物理设计都可能实现对逻辑元素的组织。在一个反复的过程中，进行逻辑设计会与进行物理设计有部分相重叠。如此整个小组才能够逐步优化系统。逻辑设计旨在列出系统中的各部分、描述它们的相互联系并定义使用这些部分能够达到什么目的。请记住概念设计与逻辑设计是紧密相关的。逻辑设计描述系统如何配合每一个概念设计方案。设计组能够从定义系统的要紧模块开始逻辑设计过程。模块表示协同工作完成某项任务的一些过程的集合。设计组必须确定每一个元素、每个元素的职能以及每个元素如何与其它元素

23、相互作用。那个时期的结果包括： 核心的功能区域或元素 这些区域的活动或功能 区域间联系 物理设计 物理设计是从开发小组的角度描述解决方案的组件、服务以及技术的过程。物理设计旨在依照现实的技术局限性分析逻辑模型，包括实现情况和性能方面的考虑。物理设计过程的结果是一组组件、特定平台的用户界面设计以及物理数据库设计。物理设计为功能规格提供基础。开发小组、测试小组以及部署小组都可使用这一功能规格作为质量保证的基础。物理设计过程包含几个步骤：研究、分析、合理化以及规范化： 物理设计的研究步骤包括确定差不多结构的物理局限性以及解决方案的物理需求，并处理物理局限性与需求之间可能产生的冲突。 物理设计的分析步

24、骤包括选择备选的实现技术并草拟由网络、数据、组件拓扑结构组成的初步部署模型。 物理设计的合理化步骤包含确定打包方式和分布策略、将对象分解成基于服务的组件、在拓扑结构中分布组件以及进一步改进打包和分布方式。 物理设计的规范化步骤包括确定编程模型、指定组件接口和了解组件结构的考虑因素。 KM 解决方案设计模型 到此，我们差不多分析了建立 KM 解决方案、 MSF 应用程序模型和设计过程的关键概念。现在该将它们综合起来集中学习如何按照 MSF 设计过程设计 KM 解决方案了。我们将使用 MSF 基于服务的应用程序模型作为以下论述的差不多方针。设计典型的 KM 解决方案时，我们必须认真考虑以下问题：

25、我们设计的目的是什么？ 我们是否定义了猎取用户和业务需求的方案？ 我们是否有足够的信息来定义一组服务以及它们的接口？ 一旦我们确定了实现技术，差不多结构和技术方面将存在哪些局限性？ 我们是否定义了对象模型？ 下表阐释了一个 KM 解决方案设计模型的示例，它是基于一个虚构的 Exchange 2000 示例应用程序的。表 1. 知识治理解决方案设计模型服务层次概念设计（方案）逻辑设计（对象/服务）物理设计（组件/技术）用户服务示例方案：建立社区论坛，通过动态地、依照需要添加论坛来实现它的灵活性。一个基于 Web 的虚拟社区，包括以下服务： 业界新闻 协作 最佳方法 共享联系人 易于查找的信息 一

26、个基于 Exchange 2000 的数字版面，它包含不同的 Web 部件，与逻辑设计中定义的服务相对应。业务服务示例方案：要求引导 (RFQ) 文档综述和批准过程。生成 RFQ 服务 在 BizTalk 框架的基础上将 RFQ 转换成 XML 文档 RFQ 批准过程 生成并验证 RFQ 的属性的事件接收器 使用工作流引擎实现 RFQ 批准过程 使用 ServerXMLHTTP、XML DOM、XSLT 实现 RFQ 转换过程 数据服务示例方案： 一个中央信息库，用来容纳所有相关项目文档以及与工程组织相关的设计文档。 同意小组成员通过适当的安全模型共享或查看文档。 以下对象的逻辑架构设计： 项

27、目 文档 小组成员 基于 Web 存储系统的物理架构设计： 文件夹结构 架构文件夹 自定义内容类及属性 安全 XML 描述符模板 以下是适用于 KM 设计模型的一般最佳方法或建议。在下面的部分我们将讨论具体的主题。 在概念设计时期，重点是定义能把握业务过程和需求的方案。方案的定义应当依照业务问题范围内的环境来进行，而不是依照解决方案范围内的环境来进行。 在从概念设计到逻辑设计的过渡时期中，开发小组可审核整套方案以应用适当的面向对象 (OO) 的设计技术（例如用户案例分析），来确定备选服务和/或对象。这些备选服务/对象奠定了逻辑设计模型的基础。这通常是个反复的过程，即需要往复几次才能完成。图 6

28、 是一个基于 Microsoft Visio 2000 联机文档的示例用户案例关系图。本关系图源自 ObjectSpace （)（英文）公司的 Craig Larman 所写的面向对象的分析和设计材料。 图 4. 用户案例关系图示例 在逻辑设计时期，小组应专注于设计业务和对象，而不考虑技术和平台的因素。对多数开发人员来讲，做到这一点比较困难。一些开发小组可能倾向于干脆跃过逻辑设计时期而直接进行物理设计。这绝对不是一个好方法。逻辑设计模型有许多优点，如： 为各个单独的小组成员同时高效工作提供必需的组织和结构规则。 充当与外部项目和设计人员协作的基础。 降低复杂性。 提供依照用户需求（即方案）优化

29、设计的机会。 在从逻辑设计到物理设计的过渡时期中，开发小组能够使用逻辑设计时期定义的服务和对象草稿开始物理设计。所有小组成员和该项目涉及的其他人员都应当首先了解解决方案和整个系统结构的情况，包括系统中各部分之间的相互联系。使用统一建模语言 (UML) 中定义的相互作用关系图（顺序关系图）来猎取系统的动态相互作用关系是一个较好的方法。图 7 是一个示例顺序关系图，摘自 Microsoft Visio 2000 联机文档。本关系图源自 ObjectSpace （)（英文）公司的 Craig Larman 所写的面向对象的分析和设计材料。 在物理设计时期，开发小组应专注于能优化或改进设计模型的设计因

30、素。本文其余部分将集中讨论适用于使用 Web 存储系统进行设计需要注意的最佳方法。 图 5. 顺序关系图示例 用户服务设计的最佳方法 正如上文所述，用户服务是提供应用程序界面的应用程序逻辑单元。其设计活动的中心通常是图形用户界面 (GUI) 和/或应用程序编程接口 (API)。以下是使用 Web 存储系统设计用户服务的一组最佳方法：通过考察关键使用方案确定一般用户服务 在逻辑设计时期，小组要考察各种使用方案，尤其是与用户（或 UML 中的“操作者”）相互作用的情况。多数情况下，从方案中确定用户服务会特不容易。然而，要找到可重复利用的用户服务就需要额外的精力和经验了。示例：在设计雇员 KM 入口

31、 Web 站点时，内容搜索用户服务和分类选择用户服务可能会在整个 Web 站点中重复利用。使用新的数字仪表板框架 数字仪表板概述：数字仪表板是知识工作者的自定义解决方案，它将个人、小组、公司以及外部的信息综合在一起，并专门容易使用分析和协作工具。使用 HYPERLINK /DirectAccess/Products/SBS/CRK/files/digital_dashboard/CD/default.htm 数字仪表板资源工具包 (DDRK) 2.0（英文），公司专门快就能够建立并部署自定义的数字仪表板解决方案。DDRK 中包含所有必需的工具和文档、示例仪表板以及可立即用于各种数字仪表板的组件

32、。数字仪表板由 Web 部件（可重复使用的组件，包含任何形式基于 Web 的信息）组成。 生成 Web 部件专门容易；最终用户可在仪表板中创建简单的 Web 部件。开发人员使用 Web 部件生成器能够创建更加复杂的 Web 部件。通常数字仪表板应用程序有一个增强的用户界面，它将常见的 Microsoft Office 功能与易用的 Web 扫瞄器风格的控件相结合。用户只需点击一下，就可使用简便的工具来自定义数字仪表板、创建新的 Web 部件或者从 Internet 或本地 Intranet 上的 Web 部件库中导入 Web 部件。图 8 显示一个名为 Adventure Works 的虚构的

33、公司的数字仪表板。那个数字仪表板包含的 Web 部件显示用户收件箱、MSN Messenger Service、日历以及有关该公司的关键信息。图 6. 数字仪表板示例实现用作 Web 部件的一般用户服务 数字仪表板的核心是 Web 部件。Web 部件是能够重复使用的组件，它包括基于 Web 的内容（如 XML、 HTML）和脚本，还包括一组标准属性，用于操纵 Web 部件在数字仪表板中的显示方式。这些属性使 Web 部件和仪表板成为中立的存储空间同时完全能够重复使用。因为 Web 部件遵守一般标准，您能够把它们存储在库中，从那个库中您能够提取 Web 部件来组成您的组织中的所有数字仪表板。许多

34、 Web 部件和仪表板都具有用户专用的属性，但假如您是治理员，能够操纵用户能够更改 Web 部件或仪表板的程度。通过 UI 设计指南定义一致的外观 定义一组 UI 设计指南是个好方法。如此能够保证 KM 解决方案有一致的外观。例如，为了使用户对您的 KM 入口 Web 站点更加中意，就要为一般 KM 用户服务设计一致的 UI，这些服务包括： 导航服务 内容搜索服务 分类选择服务 内容表示服务 尽量使用 Outlook Web Access 只需要重复使用 Outlook Web Access 中的某些部分，您就可创建自定义的 Web 页面。这些部分能够嵌入到 Web 页面中。可使用表、框架和

35、iFrame 来安排 Outlook Web Access 的各个部分。Outlook Web Access 为每天的任务提供了默认视图 例如，查看收件箱和发件箱。 通过指定其它参数能够操作默认视图。例如， Web 页面能够包含用户的收件箱和组日历。在页面的一角能够显示一个商标或公司标识，在另一角有当前新闻和与内部工具的链接。因为使用 Outlook Web Access 能够在专门大程度上减轻您的开发工作，您应当尽可能地使用它。为自定义的内容类和属性使用 Web 存储系统窗体 假如差不多设计了自定义的内容类和属性，您应当考虑使用 Web 存储系统窗体。Web 存储系统窗体是一种基于 Web

36、的窗体技术，它建立在 Internet 标准之上。Web 存储系统窗体是在 Web 存储系统中注册的 Web 页面。注册本身确实是 Web 存储系统数据存储区中的一条记录。Web 存储系统窗体被设计为能够与符合 HTML 3.2 标准的扫瞄器一同工作。支持那些功能的扫瞄器包括 Microsoft Internet Explorer 3.0 或更高版本以及 Netscape Navigator 3 或更高版本。 Web 存储系统窗体有什么专门之处呢？Web 存储系统窗体具有以下特点： 以数据为中心：扫瞄器请求存储区中某一项的 URL。存储区执行与所请求的项相对应的窗体。 适应性强：窗体只需要了解

37、如何处理某一特定语言、扫瞄器或操作。存储区能够与请求相适应以保证执行正确的窗体。 究竟什么是窗体？它是一个相当宽泛的词汇，通常与通过 HTTP 协议与存储区中数据绑定的 HTML 页面相关。依照 Microsoft Exchange 产品组的编程经理 Jamie Cool 的讲法，更正式的定义为“一个过程，它使用 HTTP 通信，可通过 HTML 与用户进行交互并操作数据，从而响应用户的操作。”了解 Web 存储系统窗体如何工作是必要的。Web 存储系统中的所有内容差不多上可用 URL 寻址的。从 Web 进行访问时，Outlook Web Access 为 Web 存储系统中的所有项提供默认

38、的显示方式。窗体注册表同意开发人员覆盖 Outlook Web Access 中的默认显示方式。Exchange 接收到来自用户扫瞄器的 HTTP 请求后，该请求即被传送给 Microsoft Internet Information 服务 (IIS)。 IIS 调用 ISAPI DLL。这与 Web 存储系统用来处理所有 HTTP/DAV 请求所使用的 DLL 相同。ISAPI DLL 检查窗体注册表的窗体注册。窗体注册提供一组针对窗体的属性，如内容类、用户操作、语言、扫瞄器类型、项状态和两个重要属性： 执行 URL：执行该 URL 将显示窗体。它可能是一个 ISAPI 筛选器（例如：/ex

39、chweb/bin/exwform.dll）或一个 ASP 页面（例如：process.asp）。 窗体 URL：正在处理或显示的窗体或模板的 URL；当前 URL 所表示的项（例如：ExpenseForm.htm、ECOform.ASP）。 处理从 HTTP 请求报头读取的信息，并与存储在 Browsecap.ini 中扫瞄器的信息相比较，就能够得到扫瞄器的功能信息。ISAPI DLL 使用与窗体注册表信息最佳匹配的比较来确定显示哪一个窗体。有关 Web 存储系统窗体的详细信息，请参考 Exchange 2000 SDK。设计业务服务的最佳方法 正如上文所述，业务服务是一个应用程序逻辑单元，

40、它操纵执行业务规则的先后顺序，保证所执行操作的事务完整性。以下是一组使用 Web 存储系统设计业务服务的最佳方法：通过使用方案确定关键业务过程 在逻辑设计时期，开发小组应检查他们在概念设计时期收集的方案以确定业务过程，如文档批准过程或内容变换过程。确定实现机制 在物理设计时期，开发小组需要确定这些业务过程最合适的实现机制。有四个差不多选项：工作流引擎、事件接收器、 COM+ 组件和脚本（客户端或服务器端脚本）。使用脚本的方法会造成一些困难，如代码不易维护以及脚本的局限性。因此，我们建议采纳前三种方法。以下是确定实现方法的一组指南： 假如业务过程符合以下情况，则使用工作流： 涉及多用户和多资源。

41、 具有复杂过程，如批准或业务验证过程。 假如出现以下情况，则使用事件接收器： 只涉及少量的用户或资源。 验证过程简单。 具有整个存储区范围内的事件。 具有定时器事件。 假如使用 Web 存储系统进行的大多是读取操作而不是更新操作，且不涉及工作流，则使用 COM+ 组件。 设计数据服务架构的最佳方法 正如上文所述，数据服务是提供最低提取可见级不的应用程序逻辑单元，用于操作数据。数据服务维护作为公司资产的永久和非永久数据的可用性和完整性。这一部分我们将讨论 Web 存储系统架构设计，下一部分讨论文件夹结构。首先，什么是架构？关于建立在 Web 存储系统技术基础上的整个物理设计模型来讲，什么缘故架构

42、设计至关重要？架构一词指的是一种定义和组织数据（有时称为元数据）的方法。在结构化查询语言 (SQL) 关系型数据库中，架构包括所有的表定义和列定义，以及其它信息（如索引和触发器）。关于存储区，我们将架构设计的重心放在内容类及与其相关联的属性集方面。架构设计对整个 KM 解决方案是否成功有直接阻碍，尤其是在性能和可扩展性方面。架构设计通常是定义数据服务模型的第一步。许多设计的考虑因素和决策都要依靠架构设计。下面一段是对 Web 存储系统架构的简要介绍。Web 存储系统可用于为您的应用程序定义架构。Web 存储系统架构是以内容类为中心的。内容类为存储区中的项/实例定义架构类，是属性集的逻辑容器。为

43、您的应用程序创建架构定义时，要定义自定义内容类及相关的属性。Web 存储系统含有大量预定义的内容类和属性。定义自己的自定义内容类时，您能够使用或扩展（子类）某一预定义内容类。其中包括（但不仅限于）表 2. 所列的内容类。表 2. 内容类内容类讲明urn:content-classes:item 存储区中各项的基类urn:content-classes:message 消息的基类urn:content-classes:calendarmessage会议请求和响应的基类urn:content-classes:appointment 约会的基类urn:content-classes:person 联

44、系人项的基类urn:content-classes:folder文件夹的基类urn:content-classes:documentMicrosoft Office 文档的基类Web 存储系统架构的一个长处是它们为架构感知的应用程序和工具提供了一种方法，可用来查找出适用于某一特定应用程序的内容类和属性的名称。与某一特定应用程序相关的架构信息是通过文件夹的架构范围来操纵的。文件夹的架构范围是一组按某特定顺序遍历的文件夹，它们包含架构定义项。通过在 Web 存储系统（其中存储您的架构信息）中定义文件夹的列表，你能够逐个文件夹地扩展架构。范围能够专门简单，只包含全局架构文件夹；也能够比较复杂，包含一

45、个专门大的文件夹 URL 的列表。还需要查看以下两个属性来定义架构范围，这两个属性对整体架构设计 尤其是文件夹结构 也专门重要，我们将在下一部分讨论这一主题。 schema-collection-ref (SCR)：这一属性是一个文件夹的 URL，将在该文件夹中查找内容类和属性定义。这是搜索架构定义项的第一个文件夹，同时总是文件夹架构范围中的第一个文件夹。假如未设置那个属性，则默认为存储区的 non_ipm_subtree/Schema 文件夹，其中包含 Web 存储系统的默认架构定义项。 Baseschema：这一属性是个多值字符串，包含一个或多个文件夹的 URL。通过确定包含架构定义项的其

46、它文件夹，能够扩展某文件夹的架构范围。 除了定义自定义内容类之外，定义自定义属性是架构设计的另一个重要方面。尽管 Web 存储系统提供许多预定义的属性，您能够为每一项存储任意数量的其它属性；这些属性就称为自定义属性。您还能够对每一项定义一组不同的自定义属性。自定义属性与它的关联项一起保存。检查项时能够按名称发出请求。假如使用 Exchange OLE DB 提供程序或 ADO 直接绑定到项上，或通过 HTTP/WebDAV 协议发出一个 0 深度的 PROPFIND 命令，Web 存储系统将返回该项的所有自定义属性。关于所有深度为 1 的项属性，自定义属性对 SQL “SELECT *”语句或

47、 PROPFIND 命令差不多上不可见的，除非这些属性被定义为项的内容类的一部分。因此，要使架构感知的应用程序能识不您的属性，必须把属性和内容类的定义添加到应用程序文件夹的架构范围中。下面我们对一些通用的架构设计指南作一总结。假如您不熟悉 URN、URI 和 URL 这些词，在接着之前建议您看一看下面的定义。URI、URN 和 URL 统一资源标识符 (URI) 确实是一个采纳一定格式的字符串，它可用来唯一地标识一个资源。URI 能够是一个统一资源定位符 (URL) 或一个统一资源名称 (URN)。 URL 对定位所标识资源所需的底层协议进行编码。 而 URN 则与位置无关，而且与定位所标识资

48、源要使用的协议或机制也毫无关系。 URL 开头带有一个标识协议的前缀，接着是一个针对协议的字符串。关于 HTTP URL，语法如下： http:/ : ? 是服务器的 IP 地址， 是服务器侦听的 TCP 端口号， 是在 HTTP 请求中作为请求 URI 传递的绝对 URI。可选的 对应于查询字符串后缀，即用 & 分隔的关键字/值对的列表。只有 URL 的主机部分是必须的。假如未指定端口，默认为端口 80；假如未指定路径，请求 URI 将为“/”。URN 对建立现代的、适宜 Internet 的应用程序是至关重要的，但人们对它还远远不够熟悉。目前还没有一种通用的方式来间接访问 URN 以查找它

49、所标识的资源。URN 的语法结构保证了 URN 跨多个组织的唯一性。其语法如下所示： urn: : 是命名空间标识符， 是命名空间特定的字符串。假如要标识与位置无关的内容，建议您使用 URN 机制。关于还需要包含位置信息的标识符，则建议使用 URL 机制。架构设计指南 架构设计指南的内容如下：使用和定义命名空间 (URN) 使用命名空间定义属性和内容类是一种好方法。命名空间的作用包括： 有助于确保属性和类的名称是全局唯一的；即，解决识不和冲突的问题。假如您有多个应用程序在同一时刻部署，或者独立软件开发商 (ISV) 在一个大型组织中部署他们的应用程序时，这一点差不多上特不重要的。 指示“拥有”

50、属性或类定义的个体或组织。 在随 Exchange 2000 提供的预定义属性和类中，您会发觉有许多不同类型的命名空间： urn:schemas:httpmail: urn:schemas-microsoft-com:exch-data: urn:schemas-microsoft-com:office:office /exchange/ 第一个示例是一种通用的广为同意的命名空间，目的是为了增强各种架构感知应用程序间的互操作性。 接下来的两个是专用 URN。假如您希望为您的应用程序创建一个类似的命名空间，您能够创建 urn：schemas-mycompanysdomain-com:myappl

51、ication:。第二个和第三个命名空间的差不就在于：第二个命名空间的结尾有一个命名空间分隔符而第三个命名空间没有。假如命名空间以分隔符“:”或“/”结尾，将创建属性或内容类名称，且属性名附于命名空间后。例如，第二个命名空间中的一个属性是 urn：schemas-microsoft-com:exch-data:ismultivalued。假如命名空间不以分隔符结尾（如第三个示例），则该命名空间中将创建属性名，命名空间与属性名之间有一个符号“#”。例如，第三个命名空间中的一个属性是 urn：schemas-microsoft-com:office:office#Author。最后一个命名空间示例

52、显示如何将 URL 用作命名空间。您应当从您拥有或已注册的 URL 中选择基于 URL 的命名空间。这将有助于保证命名空间的唯一性。URL 用作命名空间时，最后一个分隔符为字符“/”。不应向您不拥有的命名空间中添加属性或内容类。例如，向 /exchange/ 或 DAV: 命名空间添加属性就不行，而应当为您的内容类和属性创建自己的命名空间。进行属性定义 Web 存储系统本身对属性名称中可使用哪些字符没有专门的限制。然而，最好依旧遵守以下一些约定： 应当使用命名空间来创建属性并加上一个标识符（如上文所述）。例如， urn:schemas-sample-com:engineering:eco. 属

53、性应当是格式正确的 URI。 属性名称中不应有空格，因为 XML 不支持在元素名称中使用空格，因此 HTTP-DAV 也不支持。 定义自定义内容类 在定义了这些自定义属性之后，下一步确实是定义您的自定义内容类。首先，您需要为应用程序选择一个文件夹，用来存储架构信息。您能够将这些信息存储在您的应用程序数据所在的同一文件夹中，但我们强烈建议您使用一个不同的子文件夹，我们称之为架构文件夹。假如您在正定义的架构不是针对某一个应用程序的，您能够在相关的公共存储区里的高层架构文件夹中定义它。存储架构定义的位置和组织架构定义的方式由您决定。然而，在下一部分中，我们将推举一组方式，指导您如何组织文件夹结构以及

54、如何确定对一组特定应用程序数据应用哪一个架构定义。下面的关系图阐释了使用一个 Exchange 2000 SDK 工具（即：Web 存储系统架构设计器）来自定义内容类的一个示例。我们建议您使用该工具或类似工具来定义自定义内容类的定义和属性定义。图 7. 示例：架构设计考虑内容类的继承性 您因此能够从头开始定义一个全新的内容类。只是，多数内容类都能够扩展（“继承”）现存的内容类。扩展内容类意味着已扩展的（派生的）内容类实例的所有属性也存在于扩展中的（差不多的）内容类实例中。这一概念与 C+ 如此的面向对象 (OO) 的编程语言中类继承的概念相似。 图 10 显示一个简单的继承方案。扩展文档类意味

55、着任何可在文档类实例上执行的代码或操作都能够在 expensereport 类实例上执行。图 8. 简单内容类继承图 9. 带有多个继承关系的内容类内容类也可扩展为多个内容类。在图 11 中，我们还能看到一个 expensereport 类，它具有 totalcost 和 approvastate 两种属性。但在这一方案中我们希望有作为文档的一个特定类的费用报告和作为消息的一个特定类的费用报告。因此，我们创建一个 exprensereport 类来扩展该类。然后创建一个 exprensemessage 类和一个 exprensedocument 类，它们自己没有其它属性。Expensemess

56、age 扩展了 expensereport 和 message，而 exprensedocument 扩展了 exprensereport 和 document。现在，理解 message 类的应用程序就能够理解 expensemessage 类的一些属性，而把其余属性当作自定义属性。理解 document 类的应用程序就能够理解 exprensedocument 类的一些属性。有关架构设计的详细信息，请参考 Exchange 2000 SDK 以及白皮书“Web 存储系统架构：使用和最佳方法指南。”Web 存储系统文件夹结构的最佳方法 Web 存储系统为设计文件夹结构提供了专门大的灵活性。架

57、构定义项可置于特定存储区内的任一文件夹中，并用于为您的应用程序定义架构。通过合理设置不同文件夹的 schema-collection-ref 和 baseschema 属性，您能够将这些定义引入到范围中来。为了幸免设计和治理应用程序架构太过复杂，应规划并组织好您的架构信息。例如，能够选择在您指定为架构文件夹的应用程序文件夹的顶层下创建文件夹。设计文件夹结构有许多种方式。以下步骤概述了这一过程。考虑以下各项： 逻辑模型的复杂程度：正如上文所述，设计存储区的架构有许多方式。在作出最终设计决定前应当考察所有相关的信息和设计选项。 物理模型的复杂程度：您应当考虑到维护复杂文件夹结构的困难程度。 性能阻

58、碍：将在以后的部分中讨论。 重复使用和共享架构。 将架构文件夹与其它类型的文件夹区分开来，例如： 应用程序文件夹：包括 ASP 页面、HTML 页面、Web 存储系统窗体等等。 数据（内容）文件夹：包括数据项或文档。 窗体注册文件夹：包括窗体注册项。 通常，特定应用程序的架构定义将置于它们自己的文件夹中。将应用程序文件夹和数据文件夹分开也是一种好方法。正如上文所述，特定文件夹的 schema-collection-ref (SCR) 和 baseschema 属性确定架构范围。设计文件夹结构有许多灵活的方式。文件夹结构的示例如下：一个简单的应用程序能够有一个包含应用程序文件（ASP、HTML

59、页面）和数据项的文件夹，以及一个架构文件夹。 略微复杂点的应用程序能够分不有单独的应用程序文件夹、数据文件夹和架构文件夹。 架构文件夹能够有不同的级不，如顶级架构文件夹包含在同一根下运行的所有应用程序。也能够采纳一系列架构文件夹，每个架构文件夹通过 SCR 引用另一个架构文件夹。 定义架构文件夹。 定义常用的内容类和属性定义。 定义窗体注册。（这可能在一个单独的窗体注册文件夹中。） 创建架构文件夹时，您必须确定这些文件夹的范围。即，某一给定的架构文件夹适用于哪些数据文件夹？任意数量的数据文件夹能够使用一个架构文件夹。反之，在多个架构文件夹中定义的架构能够应用于一个数据文件夹。正如上文所述，sc

60、hema-collection-ref 是一个可在数据文件夹上设置的属性，用来指示在查找相关属性和内容类定义时应首先搜索哪个架构文件夹。baseschema 属性则形成一个架构文件夹的树形结构来搜索架构定义。在那个架构文件夹的逻辑树中，每个节点都可有许多子节点。那个架构文件夹的逻辑树能够（同时通常会）与存储区中文件夹的物理布局不同。相关于给定的数据文件夹，schema-collection-ref 属性指示搜索始于哪个架构文件夹。 定义应用程序和数据文件夹。 假如需要，将 schema-collection-ref (SCR) 属性指向架构文件夹。 使用 baseclass 和 expecte