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

使用使用 Web 存储系统设计知识管理解决方案存储系统设计知识管理解决方案 Walson Lee Microsoft Corporation 2000 年 10 月 摘要 摘要 本文概述了使用 Web 存储系统开发高效的知识管理解决方案的设计过程 目录目录 简介 Web 存储系统用作开发平台 建立 KM 解决方案 Microsoft 解决方案框架 基于服务的应用程序模型 MSF 设计过程 KM 解决方案设计模型 设计用户服务的最佳方法 设计业务服务的最佳方法 设计数据服务架构的最佳方法 Web 存储系统文件夹结构的最佳方法 SQL 与 Web 存储系统 物理设计考虑因素 安全模型 性能 可伸缩性与可用性 指南回顾 分类的实现 与业务范围应用程序的集成 结论 简介简介 Microsoft Exchange 2000 Server 是引入一种新的称为 Web 存储系统的存储技术的第一个 Microsoft 产品 Microsoft 的 Web 存储系统提供许多新的开发功能 例如 Web 存储系统事件与窗体 工作流引擎 内容索引以及搜索文件夹 这些功能特别适用于知识管理 KM 解决方案 但是 KM 解决方案的开发人 员开始时需要经过一个学习过程 才能理解这些功能 并逐个理清 Web 存储系统提供的许多个设计选项 的作用 本文着重讲解了有关开发 KM 解决方案的设计方面的知识 并讨论了最佳方法 设计模式以及设 计过程中的考虑因素 其中展示了基于服务的应用程序模型和基于 Microsoft 解决方案框架 MSF 的设 计过程 这个设计过程是专为使用 Web 存储系统建立 KM 解决方案量身定做的 设计过程包含了概念设 计模型 逻辑设计模型以及物理设计模型 本文重点讲述针对 Web 存储系统的物理设计模型的设计考虑 因素 用户服务 数字仪表板和 Web 存储系统窗体 业务服务 工作流和事件设计 数据服务 存储架构设计 安全模型 性能 可伸缩性与可用性 分类的实现 与业务范围 LOB 应用程序集成 本文旨在提供一种设计基于 Web 存储管理系统技术的 KM 解决方案的正确方法 它所面向的读者是 KM 解决方案的构建或设计人员 其他开发人员也能从本文阐述的基本设计概念中获益 Web 存储系统用作开发平台存储系统用作开发平台 Web 存储系统是 Microsoft 为体现它的 不受限制的知识工作者 理念而宣布的四项创意之一 这些创 意的主要目的是消除当今知识工作者面临的妨碍相互协作的障碍 Web 存储系统将文件系统 Web 以及 协作服务器的功能组合到一个位置 以便存储 访问 管理信息以及建立和运行应用程序 Web 存储系 统中的每一项都是可用 URL 寻址的 并且完全支持半结构化数据 如文档 联系人 消息 报告 HTML 文件以及 Active Server Pages ASP Web 存储系统提供与 Microsoft Office 2000 的高性能集成 它为信息管理 包括一致搜索和数据分类 建立了一个平台 图 1 阐释了 Web 存储系统的编程模型 从图中可看出它支持不同的协议 数据访问方式和事件模型 对 Web 存储系统的数据访问包括对 OLE DB 和 ActiveX Data Objects ADO 的支持 Web 存储系统还提 供通过 HTTP 协议进行访问的功能 WebDAV 规范 英文 增强了这一功能 使它可支持另一组协议命令 此外 该存储系统本身还支持可扩展标记语言 XML Web 存储系统还包括一些新的功能 如 Outlook Web 访问 Web 存储系统窗体 事件 工作流 内容 索引 搜索文件夹以及即时消息传送 这些功能为开发人员建立 KM 解决方案带来了很大的灵活性 也更 容易实现 有关 Web 存储系统的详细资料 请参见 Exchange 2000 SDK 以及 MSDN Exchange Server 开 发人员中心 英文 图图 1 1 Web 存储系统编程模型存储系统编程模型 建立建立 KM 解决方案解决方案 对企业中的每一个业务问题 知识管理 KM 通过选择解决问题的正确模块而不断更新 根据不同的组织 方式和技术 每一模块都有自己的特性 下面列出了一些典型特性 扩充客户 合作伙伴 雇员的知识 快速学习并重复利用知识 提高知识产权的价值 为产品和服务提供特别的附加值 建立新知识 共享工作过程和质量革新的知识 图图 2 2 KM 启用模块启用模块 有两项技术是所有 KM 系统的基础 完全 Intranet 和消息传送及协作 这些技术构建的基础结构支持对 信息进行有效传输 架构 访问和协同管理 其余的 KM 启用模块把这一基础结构扩展成一个复杂的 KM 系统 该系统包含各种服务 如内容管理 各 种信息传递以及数据分析等 其它服务 如数据跟踪 工作流过程 也包含在该系统和这些模块中 实现 KM 启用模块可以是即插即用的 虽然某些模块得益于先前某一模块的实现 仍可按与要开发的特定 业务案例之间的相对顺序选择它们 例如 象视频会议这样的实时协作服务 可以很容易地包含在必备技 术的上层 但要通过内容管理模块中提供的元数据服务才能得以增强 图图 3 3 可能的知识管理平台分层结构可能的知识管理平台分层结构 Microsoft 当前的 KM 平台是 Microsoft BackOffice 系列 它提供的服务能够 建立 KM 先决条件 消息传送及协作和完全 Intranet 通过实现所有的 KM 启用模块 内容管理 团体和组 入口和搜 索 数据分析以及实时协作 将它们扩展成 KM 解决方案 除了这些服务 BackOffice 还提供与先前信 息或知识源集成和连接的接口 在未来的几个月内 Microsoft 将发布 NET 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 存储系统是建立和提供以下关键知识服 务所需的一个开发平台 搜索与传递 协作 文档管理 跟踪和工作流 有关详细信息 请参考建立知识管理解决方案白皮书 英文 Microsoft 解决方案框架 基于服务的应用程序模型解决方案框架 基于服务的应用程序模型 为了奠定一个基础 以便您掌握下面关于如何设计 KM 解决方案的讨论 我们将根据 Microsoft 解决方 案框架 MSF 白皮书 简要概括 MSF 的基于服务的应用程序模型 有关详细信息 请参考 Microsoft 解决方案框架白皮书 英文 MSF 提倡使用基于服务的应用程序模型来设计和实现分布式组件和业务解决方案 基于服务的应用程序 模型 是指应用程序的功能定义为一组服务集合 按照 MSF 的观点 一个应用程序是由服务的使用者与 提供者组成的逻辑网络构成的 在这一模型中 使用者可以是一个用户或另一个服务组件 这些服务可以 跨越物理和功能的边界 满足各种不同应用程序的需求 什么是服务服务 服务就是一组应用程序逻辑 它针对对象实现操作 功能或转换 服务可以执行业务规则 计算或管理数据 提供输入 检索 查看或修改信息等功能 为进一步精确说明服务网络的分布特性 MSF 应用程序模型定义了组成一个应用程序的三类服务 1 用户服务用户服务是提供应用程序接口的应用程序逻辑单元 应用程序的用户可以是一个用户或另一个应 用程序 因此 应用程序的接口可以是图形用户界面 GUI 和 或应用程序编程接口 API 2 业务服务业务服务这种应用程序逻辑单元用于控制业务规则的先后顺序和执行 并且可以保证所执行操作 的事务完整性 通过应用恰当的业务规则 业务服务可将数据转换成信息 3 数据服务数据服务是提供最低提取可见级别的应用程序逻辑单元 用于操作数据 数据服务维护作为公司 资产的永久和非永久数据的可用性和完整性 它们提供创建 读取 更新和删除服务 这样业务 服务 数据服务的使用者 就不需要了解数据的位置 实现方式和访问方式了 MSF 设计过程设计过程 设计业务解决方案的过程可与设计建造一座建筑物相比 好的建筑师只有了解了客户的需求才真正了解了 客户 在系统设计中 可有多个视角描述最终产品 这与建筑是一样的 每一个视角都是为不同的受众准 备的 它们的详细程度也不尽相同 KM 解决方案的设计也是这样 应用程序有不同的重点和技巧 设 计人员专注于用户界面 业务过程或数据库问题 我们需要为他们提供一种途径来协调和同步他们的工作 使他们能高效地 有组织地利用他们的专业技能完成全面平衡的设计 MSF 设计过程分三个阶段 1 概念设计 2 逻辑设计 3 物理设计 概念设计概念设计 概念设计是指确切了解要解决的问题 然后以管理方和用户都能理解的方式构架出问题的解决方案 与单 纯收集需求相比 它的范围要广得多 这个阶段还需要根据具体环境来处理这些需求 从而合理决策 概念设计提取出要执行业务活动所需的本质任务和信息 从而按照既紧密围绕过程 又以用户为中心的方 式看待解决方案 在 MSF 中 方案是概念设计过程的关键结果 一个方案描述在某种业务环境中用户执行的与行为相关的一 系列任务或事务 方案必须根据负责这项工作的用户的需要 以用户为中心 来提取业务解决方案的需求 围绕过程 逻辑设计逻辑设计 逻辑设计逻辑设计是指通过定义系统各部分及它们间相互作用的方式来描述解决方案的过程 这一过程组织新系统 的逻辑结构并阐释该系统的组成方式以及它与外部世界的接口 在逻辑设计过程中 必须加深项目组对系统的认识 这是确定设计的详细程度的主要考虑因素 逻辑设计 提供的组织和结构规则必须满足各个独立的组成员同时高效工作的要求 还要奠定与外部项目和构架进行 协作的基础 逻辑设计提供了评价各种物理设计选项的基础 通过不同的物理设计都可能实现对逻辑元素的组织 在一 个反复的过程中 进行逻辑设计会与进行物理设计有部分相重叠 这样整个小组才能够逐步优化系统 逻辑设计旨在列出系统中的各部分 描述它们的相互联系并定义使用这些部分可以达到什么目的 请记住 概念设计与逻辑设计是紧密相关的 逻辑设计描述系统如何配合每一个概念设计方案 设计组可以从定义系统的主要模块开始逻辑设计过程 模块表示协同工作完成某项任务的一些过程的集合 设计组必须确定每一个元素 每个元素的职能以及每个元素如何与其它元素相互作用 这个阶段的结果包 括 核心的功能区域或元素 这些区域的活动或功能 区域间联系 物理设计物理设计 物理设计物理设计是从开发小组的角度描述解决方案的组件 服务以及技术的过程 物理设计旨在根据现实的技术 局限性分析逻辑模型 包括实现情况和性能方面的考虑 物理设计过程的结果是一组组件 特定平台的用户界面设计以及物理数据库设计 物理设计为功能规格提 供基础 开发小组 测试小组以及部署小组都可使用这一功能规格作为质量保证的基础 物理设计过程包含几个步骤 研究 分析 合理化以及规范化 物理设计的研究研究步骤包括确定基本结构的物理局限性以及解决方案的物理需求 并处理物理局限 性与需求之间可能产生的冲突 物理设计的分析分析步骤包括选择备选的实现技术并草拟由网络 数据 组件拓扑结构组成的初步部 署模型 物理设计的合理化合理化步骤包含确定打包方式和分布策略 将对象分解成基于服务的组件 在拓扑结 构中分布组件以及进一步改进打包和分布方式 物理设计的规范化规范化步骤包括确定编程模型 指定组件接口和了解组件结构的考虑因素 KM 解决方案设计模型解决方案设计模型 到此 我们已经分析了建立 KM 解决方案 MSF 应用程序模型和设计过程的关键概念 现在该将它们综 合起来集中学习如何按照 MSF 设计过程设计 KM 解决方案了 我们将使用 MSF 基于服务的应用程序模型作为以下论述的基本方针 设计典型的 KM 解决方案时 我们 必须仔细考虑以下问题 我们设计的目的是什么 我们是否定义了获取用户和业务需求的方案 我们是否有足够的信息来定义一组服务以及它们的接口 一旦我们确定了实现技术 基本结构和技术方面将存在哪些局限性 我们是否定义了对象模型 下表阐释了一个 KM 解决方案设计模型的示例 它是基于一个虚构的 Exchange 2000 示例应用程序的 表表 1 1 知识管理解决方案设计模型知识管理解决方案设计模型 服务服务 层次层次 概念设计概念设计 方案 方案 逻辑设计逻辑设计 对象 对象 服务 服务 物理设计物理设计 组件 组件 技术 技术 用户服务用户服务示例方案 建立社区论 坛 通过动态地 根据 需要添加论坛来实现它 的灵活性 一个基于 Web 的虚拟社 区 包括以下服务 业界新闻 协作 最佳方法 共享联系人 易于查找的信 息 一个基于 Exchange 2000 的数字版面 它包含不同 的 Web 部件 与逻辑设 计中定义的服务相对应 业务服务业务服务示例方案 要求引导 RFQ 文档综述和批准 过程 生成 RFQ 服务 在 BizTalk 框 架的基础上将 RFQ 转换成 XML 文档 RFQ 批准过程 生成并验证 RFQ 的属性的事件接 收器 使用工作流引擎 实现 RFQ 批准 过程 使用 ServerXMLHTTP XML DOM XSLT 实现 RFQ 转换过程 数据服务数据服务示例方案 一个中央信息 库 用来容纳 所有相关项目 文档以及与工 程组织相关的 设计文档 允许小组成员 通过适当的安 全模型共享或 以下对象的逻辑架构设 计 项目 文档 小组成员 基于 Web 存储系统的物 理架构设计 文件夹结构 架构文件夹 自定义内容类及 属性 安全 XML 描述 符模板 查看文档 以下是适用于 KM 设计模型的一般最佳方法或建议 在下面的部分我们将讨论具体的主题 在概念设计阶段 重点是定义能把握业务过程和需求的方案方案 方案的定义应当根据业务问题范围 内的环境来进行 而不是根据解决方案范围内的环境来进行 在从概念设计到逻辑设计的过渡阶段过渡阶段中 开发小组可审核整套方案以应用适当的面向对象 OO 的设计技术 例如用户案例分析 来确定备选服务和 或对象 这些备选服务 对象奠定了逻辑 设计模型的基础 这通常是个反复的过程 即需要往复几次才能完成 图 6 是一个基于 Microsoft Visio 2000 联机文档的示例用户案例关系图 本关系图源自 ObjectSpace 英文 公司的 Craig Larman 所写的面向对象的分析和设计 材料 图图 4 4 用户案例关系图示例用户案例关系图示例 在逻辑设计阶段 小组应专注于设计业务和对象 而不考虑技术和平台的因素 对多数开发人员 来说 做到这一点比较困难 一些开发小组可能倾向于干脆跳过逻辑设计阶段而直接进行物理设 计 这绝对不是一个好办法 逻辑设计模型有许多优点 如 为各个单独的小组成员同时高效工作提供必需的组织和结构规则 充当与外部项目和设计人员协作的基础 降低复杂性 提供根据用户需求 即方案 优化设计的机会 在从逻辑设计到物理设计的过渡阶段过渡阶段中 开发小组可以使用逻辑设计阶段定义的服务和对象草稿 开始物理设计 所有小组成员和该项目涉及的其他人员都应当首先了解解决方案和整个系统结构 的情况 包括系统中各部分之间的相互联系 使用统一建模语言 UML 中定义的相互作用关系 图 顺序关系图 来获取系统的动态相互作用关系是一个较好的方法 图 7 是一个示例顺序关 系图 摘自 Microsoft Visio 2000 联机文档 本关系图源自 ObjectSpace 英文 公司的 Craig Larman 所写的面向对象的分析和设计 材料 在物理设计阶段 开发小组应专注于能优化或改进设计模型的设计因素 本文其余部分将集中讨 论适用于使用 Web 存储系统进行设计需要注意的最佳方法 图图 5 5 顺序关系图示例顺序关系图示例 用户服务设计的最佳方法用户服务设计的最佳方法 正如上文所述 用户服务是提供应用程序界面的应用程序逻辑单元 其设计活动的中心通常是图形用户界 面 GUI 和 或应用程序编程接口 API 以下是使用 Web 存储系统设计用户服务的一组最佳方法 通过考察关键使用方案确定一般用户服务通过考察关键使用方案确定一般用户服务 在逻辑设计阶段 小组要考察各种使用方案 尤其是与用户 或 UML 中的 操作者 相互作用的情况 多数情况下 从方案中确定用户服务会非常容易 但是 要找到可重复利用的用户服务就需要额外的精力 和经验了 示例 在设计雇员 KM 入口 Web 站点时 内容搜索用户服务和分类选择用户服务可能会在整个 Web 站点 中重复利用 使用新的数字仪表板框架使用新的数字仪表板框架 数字仪表板概述 数字仪表板是知识工作者的自定义解决方案 它将个人 小组 公司以及外部的信息综 合在一起 并很容易使用分析和协作工具 使用数字仪表板资源工具包 DDRK 2 0 英文 公司很快 就能够建立并部署自定义的数字仪表板解决方案 DDRK 中包含所有必需的工具和文档 示例仪表板以及 可立即用于各种数字仪表板的组件 数字仪表板由 Web 部件部件 可重复使用的组件 包含任何形式基于 Web 的信息 组成 生成 Web 部件 很容易 最终用户可在仪表板中创建简单的 Web 部件 开发人员使用 Web 部件生成器可以创建更加复杂 的 Web 部件 通常数字仪表板应用程序有一个增强的用户界面 它将常见的 Microsoft Office 功能与易用的 Web 浏 览器风格的控件相结合 用户只需点击一下 就可使用简便的工具来自定义数字仪表板 创建新的 Web 部件或者从 Internet 或本地 Intranet 上的 Web 部件库中导入 Web 部件 图 8 显示一个名为 Adventure Works 的虚构的公司的数字仪表板 这个数字仪表板包含的 Web 部件显示用户收件箱 MSN Messenger Service 日历以及有关该公司的关键信息 图图 6 6 数字仪表板示例数字仪表板示例 实现用作实现用作 Web 部件的一般用户服务部件的一般用户服务 数字仪表板的核心是 Web 部件 Web 部件是可以重复使用的组件 它包括基于 Web 的内容 如 XML HTML 和脚本 还包括一组标准属性 用于控制 Web 部件在数字仪表板中的显示方式 这些属性使 Web 部件和仪表板成为中立的存储空间并且完全可以重复使用 因为 Web 部件遵守一般标准 您可以把它们存储在库中 从这个库中您可以提取 Web 部件来组成您的组 织中的所有数字仪表板 许多 Web 部件和仪表板都具有用户专用的属性 但如果您是管理员 可以控制 用户能够更改 Web 部件或仪表板的程度 通过通过 UI 设计指南定义一致的外观设计指南定义一致的外观 定义一组 UI 设计指南是个好方法 这样能够保证 KM 解决方案有一致的外观 例如 为了使用户对您的 KM 入口 Web 站点更加满意 就要为一般 KM 用户服务设计一致的 UI 这些服务包括 导航服务 内容搜索服务 分类选择服务 内容表示服务 尽量使用尽量使用 Outlook Web Access 只需要重复使用 Outlook Web Access 中的某些部分 您就可创建自定义的 Web 页面 这些部分可以嵌 入到 Web 页面中 可使用表 框架和 iFrame 来安排 Outlook Web Access 的各个部分 Outlook Web Access 为每天的任务提供了默认视图 例如 查看收件箱和发件箱 通过指定其它参数可以操作默认视图 例如 Web 页面可以包含用户的收件箱和组日历 在页面的一角 可以显示一个商标或公司标识 在另一角有当前新闻和与内部工具的链接 因为使用 Outlook Web Access 可以在很大程度上减轻您的开发工作 您应当尽可能地使用它 为自定义的内容类和属性使用为自定义的内容类和属性使用 Web 存储系统窗体存储系统窗体 如果已经设计了自定义的内容类和属性 您应当考虑使用 Web 存储系统窗体 Web 存储系统窗体是一种 基于 Web 的窗体技术 它建立在 Internet 标准之上 Web 存储系统窗体是在 Web 存储系统中注册的 Web 页面 注册本身就是 Web 存储系统数据存储区中的一条记录 Web 存储系统窗体被设计为能够与符合 HTML 3 2 标准的浏览器一同工作 支持那些功能的浏览器包括 Microsoft Internet Explorer 3 0 或更高版本以及 Netscape Navigator 3 或更高版本 Web 存储系统窗体有什么特殊之处呢 Web 存储系统窗体具有以下特点 以数据为中心以数据为中心 浏览器请求存储区中某一项的 URL 存储区执行与所请求的项相对应的窗体 适应性强适应性强 窗体只需要了解如何处理某一特定语言 浏览器或操作 存储区能够与请求相适应以 保证执行正确的窗体 究竟什么是窗体 它是一个相当宽泛的词汇 通常与通过 HTTP 协议与存储区中数据绑定的 HTML 页面相 关 根据 Microsoft Exchange 产品组的编程经理 Jamie Cool 的说法 更正式的定义为 一个过程 它 使用 HTTP 通信 可通过 HTML 与用户进行交互并操作数据 从而响应用户的操作 了解 Web 存储系统窗体如何工作是必要的 Web 存储系统中的所有内容都是可用 URL 寻址的 从 Web 进行访问时 Outlook Web Access 为 Web 存储系统中的所有项提供默认的显示方式 窗体注册表允许开 发人员覆盖 Outlook Web Access 中的默认显示方式 Exchange 接收到来自用户浏览器的 HTTP 请求后 该请求即被传送给 Microsoft Internet Information 服务 IIS IIS 调用 ISAPI DLL 这与 Web 存储系统用来处理所有 HTTP DAV 请求所使用的 DLL 相 同 ISAPI DLL 检查窗体注册表的窗体注册 窗体注册提供一组针对窗体的属性 如内容类 用户操作 语言 浏览器类型 项状态和两个重要属性 执行执行 URL 执行该 URL 将显示窗体 它可能是一个 ISAPI 筛选器 例如 exchweb bin exwform dll 或一个 ASP 页面 例如 process asp 窗体窗体 URL 正在处理或显示的窗体或模板的 URL 当前 URL 所表示的项 例如 ExpenseForm htm ECOform ASP 处理从 HTTP 请求报头读取的信息 并与存储在 Browsecap ini 中浏览器的信息相比较 就可以得到浏 览器的功能信息 ISAPI DLL 使用与窗体注册表信息最佳匹配的比较来确定显示哪一个窗体 有关 Web 存储系统窗体的详细信息 请参考 Exchange 2000 SDK 设计业务服务的最佳方法设计业务服务的最佳方法 正如上文所述 业务服务是一个应用程序逻辑单元 它控制执行业务规则的先后顺序 保证所执行操作的 事务完整性 以下是一组使用 Web 存储系统设计业务服务的最佳方法 通过使用方案确定关键业务过程通过使用方案确定关键业务过程 在逻辑设计阶段 开发小组应检查他们在概念设计阶段收集的方案以确定业务过程 如文档批准过程或内 容变换过程 确定实现机制确定实现机制 在物理设计阶段 开发小组需要确定这些业务过程最合适的实现机制 有四个基本选项 工作流引擎 事 件接收器 COM 组件和脚本 客户端或服务器端脚本 使用脚本的方法会造成一些困难 如代码不易 维护以及脚本的局限性 因此 我们建议采用前三种方法 以下是确定实现方法的一组指南 如果业务过程符合以下情况 则使用工作流 涉及多用户和多资源 具有复杂过程 如批准或业务验证过程 如果出现以下情况 则使用事件接收器 只涉及少量的用户或资源 验证过程简单 具有整个存储区范围内的事件 具有定时器事件 如果使用 Web 存储系统进行的大多是读取操作而不是更新操作 且不涉及工作流 则使用 COM 组件 设计数据服务架构的最佳方法设计数据服务架构的最佳方法 正如上文所述 数据服务是提供最低提取可见级别的应用程序逻辑单元 用于操作数据 数据服务维护作 为公司资产的永久和非永久数据的可用性和完整性 这一部分我们将讨论 Web 存储系统架构设计 下一 部分讨论文件夹结构 首先 什么是架构架构 对于建立在 Web 存储系统技术基础上的整个物理设计模型来说 为什么架构设计架构设计至 关重要 架构架构一词指的是一种定义和组织数据 有时称为元数据元数据 的方法 在结构化查询语言 SQL 关 系型数据库中 架构包括所有的表定义和列定义 以及其它信息 如索引和触发器 对于存储区 我们 将架构设计的重心放在内容类及与其相关联的属性集方面 架构设计对整个 KM 解决方案是否成功有直接 影响 尤其是在性能和可扩展性方面 架构设计通常是定义数据服务模型的第一步 许多设计的考虑因素 和决策都要依赖架构设计 下面一段是对 Web 存储系统架构的简要介绍 Web 存储系统可用于为您的应用程序定义架构 Web 存储系统架构是以内容类内容类为中心的 内容类为存储区 中的项 实例定义架构类 是属性集的逻辑容器 为您的应用程序创建架构定义时 要定义自定义内容类 及相关的属性 Web 存储系统含有大量预定义的内容类和属性 定义自己的自定义内容类时 您可以使用 或扩展 子类 某一预定义内容类 其中包括 但不仅限于 表 2 所列的内容类 表表 2 2 内容类内容类 内容类内容类说明说明 urn content 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 存储系统架构的一个长处是它们为架构感知架构感知的应用程序和工具提供了一种方法 可用来查找出适用于 某一特定应用程序的内容类和属性的名称 与某一特定应用程序相关的架构信息是通过文件夹的架构范围架构范围来控制的 文件夹的架构范围是一组按某特 定顺序遍历的文件夹 它们包含架构定义项 通过在 Web 存储系统 其中存储您的架构信息 中定义文 件夹的列表 你可以逐个文件夹地扩展架构 范围可以很简单 只包含全局架构文件夹 也可以比较复杂 包含一个很大的文件夹 URL 的列表 还需要查看以下两个属性来定义架构范围 这两个属性对整体架构设计 尤其是文件夹结构 也很重 要 我们将在下一部分讨论这一主题 schema collection ref SCR 这一属性是一个文件夹的 URL 将在该文件夹中查找内容类和 属性定义 这是搜索架构定义项的第一个文件夹 并且总是文件夹架构范围中的第一个文件夹 如果未设置这个属性 则默认为存储区的 non ipm subtree Schema 文件夹 其中包含 Web 存 储系统的默认架构定义项 Baseschema 这一属性是个多值字符串 包含一个或多个文件夹的 URL 通过确定包含架构定 义项的其它文件夹 可以扩展某文件夹的架构范围 除了定义自定义内容类之外 定义自定义属性自定义属性是架构设计的另一个重要方面 虽然 Web 存储系统提供许 多预定义的属性 您可以为每一项存储任意数量的其它属性 这些属性就称为自定义属性 您还可以对每 一项定义一组不同的自定义属性 自定义属性与它的关联项一起保存 检查项时可以按名称发出请求 如果使用 Exchange OLE DB 提供程 序或 ADO 直接绑定到项上 或通过 HTTP WebDAV 协议发出一个 0 深度的 PROPFIND 命令 Web 存储系 统将返回该项的所有自定义属性 对于所有深度为 1 的项属性 自定义属性对 SQL SELECT 语句或 PROPFIND 命令都是不可见的 除非这些属性被定义为项的内容类的一部分 因此 要使架构感知的应用 程序能识别您的属性 必须把属性和内容类的定义添加到应用程序文件夹的架构范围中 下面我们对一些通用的架构设计指南作一总结 如果您不熟悉 URN URI 和 URL 这些词 在继续之前建 议您看一看下面的定义 URI URN 和和 URL 统一资源标识符 URI 就是一个采用一定格式的字符串 它可用来唯一地标识一个资源 URI 可以是一 个统一资源定位符 URL 或一个统一资源名称 URN URL 对定位所标识资源所需的底层协议进行编码 而 URN 则与位置无关 而且与定位所标识资源要使用的协议或机制也毫无关系 URL 开头带有一个标识协议的前缀 接着是一个针对协议的字符串 对于 HTTP URL 语法如下 http 是服务器的 IP 地址 是服务器侦听的 TCP 端口号 是在 HTTP 请求中作 为请求 URI 传递的绝对 URI 可选的 对应于查询字符串后缀 即用 分隔的关键字 值对的 列表 只有 URL 的主机部分是必须的 如果未指定端口 默认为端口 80 如果未指定路径 请求 URI 将为 URN 对建立现代的 适宜 Internet 的应用程序是至关重要的 但人们对它还远远不够熟悉 目前还没有 一种通用的方式来间接访问 URN 以查找它所标识的资源 URN 的语法结构保证了 URN 跨多个组织的唯一 性 其语法如下所示 urn 是命名空间标识符 是命名空间特定的字符串 如果要标识与位置无关的内容 建议您使 用 URN 机制 对于还需要包含位置信息的标识符 则建议使用 URL 机制 架构设计指南架构设计指南 架构设计指南的内容如下 使用和定义命名空间使用和定义命名空间 URN 使用命名空间定义属性和内容类是一种好办法 命名空间的作用包括 有助于确保属性和类的名称是全局唯一的 即 解决识别和冲突的问题 如果您有多个应用程序 在同一时间部署 或者独立软件开发商 ISV 在一个大型组织中部署他们的应用程序时 这一 点都是特别重要的 指示 拥有 属性或类定义的个体或组织 在随 Exchange 2000 提供的预定义属性和类中 您会发现有许多不同类型的命名空间 urn schemas httpmail urn schemas microsoft com exch data urn schemas microsoft com office office 第一个示例是一种通用的广为接受的命名空间 目的是为了增强各种架构感知应用程序间的互操作性 接下来的两个是专用 URN 如果您希望为您的应用程序创建一个类似的命名空间 您可以创建 urn schemas mycompanysdomain com myapplication 第二个和第三个命名空间的差别就在于 第二个命名空间的结尾有一个命名空间分隔符而第三个命名空间 没有 如果命名空间以分隔符 或 结尾 将创建属性或内容类名称 且属性名附于命名空间后 例如 第二个命名空间中的一个属性是 urn schemas microsoft com exch data ismultivalued 如果命名空间不以分隔符结尾 如第三个示例 则该命名空间中将创建属性名 命名空间与属性名之间 有一个符号 例如 第三个命名空间中的一个属性是 urn schemas microsoft com office office Author 最后一个命名空间示例显示如何将 URL 用作命名空间 您应当从您拥有或已注册的 URL 中选择基于 URL 的命名空间 这将有助于保证命名空间的唯一性 URL 用作命名空间时 最后一个分隔符为字符 不应向您不拥有的命名空间中添加属性或内容类 例如 向 或 DAV 命名空间添加属性就不好 而应当为您的内容类和属性创建自己的命名空间 进行属性定义进行属性定义 Web 存储系统本身对属性名称中可使用哪些字符没有特殊的限制 但是 最好还是遵守以下一些约定 应当使用命名空间来创建属性并加上一个标识符 如上文所述 例如 urn schemas sample com engineering eco 属性应当是格式正确的 URI 属性名称中不应有空格 因为 XML 不支持在元素名称中使用空格 因此 HTTP DAV 也不支持 定义自定义内容类定义自定义内容类 在定义了这些自定义属性之后 下一步就是定义您的自定义内容类 首先 您需要为应用程序选择一个文 件夹 用来存储架构信息 您可以将这些信息存储在您的应用程序数据所在的同一文件夹中 但我们强烈 建议您使用一个不同的子文件夹 我们称之为架构文件夹 如果您在正定义的架构不是针对某一个应用程 序的 您可以在相关的公共存储区里的高层架构文件夹中定义它 存储架构定义的位置和组织架构定义的方式由您决定 但是 在下一部分中 我们将推荐一组方式 指导 您如何组织文件夹结构以及如何确定对一组特定应用程序数据应用哪一个架构定义 下面的关系图阐释了使用一个 Exchange 2000 SDK 工具 即 Web 存储系统架构设计器 来自定义内容 类的一个示例 我们建议您使用该工具或类似工具来定义自定义内容类的定义和属性定义 图图 7 7 示例 架构设计示例 架构设计 考虑内容类的继承性考虑内容类的继承性 您当然可以从头开始定义一个全新的内容类 不过 多数内容类都可以扩展 继承 现存的内容类 扩展内容类意味着已扩展的已扩展的 派生的 内容类实例的所有属性也存在于扩展中的扩展中的 基本的 内容类实例中 这一概念与 C 这样的面向对象 OO 的编程语言中类继承的概念相似 图 10 显示一个简单的继承方案 扩展文档文档类意味着任何可在文档类实例上执行的代码或操作都可以在 expensereportexpensereport 类实例上执行 图图 8 8 简单内容类继承简单内容类继承 图图 9 9 带有多个继承关系的内容类带有多个继承关系的内容类 内容类也可扩展为多个内容类 在图 11 中 我们还能看到一个 expensereport 类 它具有 totalcost 和 approvastate 两种属性 但在这一方案中我们希望有作为文档的一个特定类的费用报告和作为消息 的一个特定类的费用报告 因此 我们创建一个 exprensereport 类来扩展该类 然后创建一个 exprensemessage 类和一个 exprensedocument 类 它们自己没有其它属性 Expensemessage 扩展了 expensereport 和 message 而 exprensedocument 扩展了 exprensereport 和 document 现在 理解 message 类的应用程序就可以理解 expensemessage 类的一些属性 而把 其余属性当作自定义属性 理解 document 类的应用程序就可以理解 exprensedocument 类的一些属 性 有关架构设计的详细信息 请参考 Exchange 2000 SDK 以及白皮书 Web 存储系统架构 使用和最佳方 法指南 Web 存储系统文件夹结构的最佳方法存储系统文件夹结构的最佳方法 Web 存储系统为设计文件夹结构提供了很大的灵活性 架构定义项可置于特定存储区内的任一文件夹中 并用于为您的应用程序定义架构 通过合理设置不同文件夹的 schema collection ref 和 baseschema 属性 您可以将这些定义引入到范围中来 为了避免设计和管理应用程序架构太过复杂 应规划并组织好您的架构信息 例如 可以选择在您指定为 架构文件夹的应用程序文件夹的顶层下创建文件夹 设计文件夹结构有许多种方式 以下步骤概述了这一 过程 考虑以下各项 考虑以下各项 逻辑模型的复杂程度 正如上文所述 设计存储区的架构有许多方式 在作出最终设计决定前应 当考察所有相关的信息和设计选项 物理模型的复杂程度 您应当考虑到维护复杂文件夹结构的困难程度 性能影响 将在以后的部分中讨论 重复使用和共享架构 将架构文件夹与其它类型的文件夹区分开来 例如 将架构文件夹与其它类型的文件夹区分开来 例如 应用程序文件夹 包括 ASP 页面 HTML 页面 Web 存储系统窗体等等 数据 内容 文件夹 包括数据项或文档 窗体注册文件夹 包括窗体注册项 通常 特定应用程序的架构定义将置于它们自己的文件夹中 将应用程序文件夹和数据文件夹分开也是一 种好方法 正如上文所述 特定文件夹的 schema collection ref SCR 和 baseschema 属性确定架构 范围 设计文件夹结构有许多灵活的方式 文件夹结构的示例如下 一个简单的应用程序可以有一个包含应用程序文件 ASP HTML 页面 和数据项的文件夹 以及 一个架构文件夹 稍微复杂点的应用程序可以分别有单独的应用程序文件夹 数据文件夹和架构文件夹 架构文件夹可以有不同的级别 如顶级架构文件夹包含在同一根下运行的所有应用程序 也可以 采用一系列架构文件夹 每个架构文件夹通过 SCR 引用另一个架构文件夹 定义架构文件夹 定义架构文件夹 定义常用的内容类和属性定义 定义窗体注册 这可能在一个单独的窗体注册文件夹中 创建架构文件夹时 您必须确定这些文件夹的范围 即 某一给定的架构文件夹适用于哪些数据文件夹 任意数量的数据文件夹可以使用一个架构文件夹 反之 在多个架构文件夹中定义的架构可以应用于一个 数据文件夹 正如上文所述 schema collection ref 是一个可在数据文件夹上设置的属性 用来指示在查找相关属性 和内容类定义时应首先搜索哪个架构文件夹 baseschema 属性则形成一个架构文件夹的树形结构来搜 索架构定义 在这个架构文件夹的逻辑树中 每个节点都可有许多子节点 这个架构文件夹的逻辑树可以 并且通常会 与存储区中文件夹的物理布局不同 相对于给定的数据文件夹 schema collection ref 属性指示搜索始于哪个架构文件夹 定义应用程序和数据文件夹 如果需要 将 schema collection ref SCR 属性指向架构文件夹 使用 baseclass 和 expected content class SQL 与与 Web 存储系统存储系统 这一部分我们考察 SQL 关系型数据库和 Web 存储系统间的主要差别 讨论何时使用 SQL 以及何时使用 Web 存储系统 并提供一套指南 用于从已有的 SQL 数据库向 Web 存储系统移植数据 表 3 阐释了 SQL 数据库与 Web 存储系统的不同之处 注意 SQL 数据库与基于 Web 存储系统的 Microsoft 产品 如 Exchange 2000 有一组相同的服务 表表 3 3 SQL 数据库和数据库和 Web 存储系统存储系统 SQL 数据库数据库Web 存储系统存储系统 关系型数据库类似于对象数据库 结构化数据半结构化数据 表文件夹 以及内容类 列内容类和属性 固定行不固定行 集中于业务智能 协作 以事务为中心以文档为中心 数据完整性 主键 外键无主键 外键 矩形数据非矩形 触发器事件接收 存储过程无可比实体 与之类似的是事件 如果现有的 KM 解决方案正在从 SQL 关系型数据库中读取数据 而这些数据是典型的非矩形半结构化数 据 您最好考虑将这些数据从 SQL 移植到 Web 存储系统 请参照以下指南 将数据从 SQL 移植到 Web 存储系统 首先 将 SQL 列映射到属性 将 SQL 表映射到文件夹和内容类 确定表的主键和外键 根据逻辑设计模型查找与之对应的内容类 通过确定一组能生成项的唯一实例的属性来模拟主键 考虑内容类的继承性 物理设计考虑因素物理设计考虑因素 到此 我们已经讨论了设计用户服务 业务服务和数据服务的最佳方法 这一部分我们将集中讨论物理设 计阶段针对 Web 存储系统的设计考虑因素 对每个设计考虑因素主题 我们都将介绍一些重要的概念 讨论一些您可以采取的折衷措施 并列出一张 清单 供您在考虑各种选项时参考 安全模型安全模型 这一部分中概述了 Web 存储系统安全模型 除了使用 MAPI 客户程序 如 Outlook 或 Windows 文件系 统 API 来控制安全设置外 您还可以使用基于 XML 的安全描述符来控制对某一项及其属性的访问 使用 Web 存储系统安全描述符 您可以 既可将对某一项及其属性的访问权授予受托者 具有凭证 正在访问该项的人 也可以拒绝该 受托者进行访问 使用 Microsoft Windows 安全标识符 SID 标识受托者 设置 检索和修改 XML 格式的描述符 使用 Microsoft Exchange OLE DB ExOLEDB 提供程序和 XML 格式的 HTTP WebDAV 协议访问 描述符 每一项的安全描述符都通过该项的 属 性访问 这个属性是项的 XML 格式的描述符 该描述符以 Exchange 2000 Server 特有的二进制格式进 行物理存储和复制 这种格式内部是基于标准的 Windows 2000 描述符格式的 如果文件夹中的某项没有 特定的安全描述符 其父文件夹中指定的默认权限将被应用于该项 安全描述符是一种数据结构 它包含以下内容 以及其它未列出的内容 一个所有者字段 其中包含对象所有者的安全标识符 SID 该对象与安全描述符相关联 一个任意访问控制列表 DACL 字段 指定谁对该对象字段具有访问权 一个系统访问控制列表 SACL 指定系统可以审计哪些操作 访问控制列表 ACL 包含一个或多个访问控制项 ACE 每个 ACE 为安全负责人安全负责人 指定访问权限 Windows 2000 中的安全负责人可以是一个用户或一组用户 Exchange 2000 定义了一个新的安全负责人 叫做角色角色 角色是一个具有名称的安全负责人 用户或组 的集合 它可在 ACL 里的 ACE 中引用 角色 与 Windows 2000 组之间主要的区别在于 Exchange 安全角色是针对对象本身定义和存储的 也就是说不 需要进行具备特权的目录服务操作 就可以创建这些角色 并填入成员 对于不需要具备特定 Windows 2000 组就可以部署的应用程序 这一功能是非常重要的 安全角色在 Web 存储系统中创建和存储 而与 Windows 2000 目录服务无关 对应用程序开发人员来说 安全角色具备两 个明显的优势 创建角色不需要使用特权的 Active Directory 操作 而这是分部门方案的一个关键