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

使用Web存储系统设计知识管理解决方案672020年5月29日文档仅供参考使用 Web 存储系统设计知识管理解决方案Walson Lee Microsoft Corporation 10月 摘要: 本文概述了使用 Web 存储系统开发高效的知识管理解决方案的设计过程。目录 简介 Web 存储系统用作开发平台 建立 KM 解决方案 Microsoft 解决方案框架:基于服务的应用程序模型 MSF 设计过程 KM 解决方案设计模型 设计用户服务的最佳方法 设计业务服务的最佳方法 设计数据服务架构的最佳方法 Web 存储系统文件夹结构的最佳方法 SQL 与 Web 存储系统 物理设计考虑因素 安全模型 性能 可伸缩性与可用性 指南回顾 分类的实现 与业务范围应用程序的集成 结论 简介 Microsoft Exchange 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 的高性能集成。它为信息管理(包括一致搜索和数据分类)建立了一个平台。图 1 阐释了 Web 存储系统的编程模型。从图中可看出它支持不同的协议、数据访问方式和事件模型。对 Web 存储系统的数据访问包括对 OLE DB 和 ActiveX Data Objects (ADO) 的支持。Web 存储系统还提供经过 HTTP 协议进行访问的功能。WebDAV 规范(英文)增强了这一功能,使它可支持另一组协议命令。另外,该存储系统本身还支持可扩展标记语言 (XML)。Web 存储系统还包括一些新的功能,如 Outlook Web 访问、 Web 存储系统窗体、事件、工作流、内容索引、搜索文件夹以及即时消息传送。这些功能为开发人员建立 KM 解决方案带来了很大的灵活性,也更容易实现。有关 Web 存储系统的详细资料,请参见 Exchange SDK 以及 MSDN Exchange Server 开发人员中心(英文)。图 1. Web 存储系统编程模型建立 KM 解决方案 对企业中的每一个业务问题,知识管理 (KM) 经过选择解决问题的正确模块而不断更新。根据不同的组织方式和技术,每一模块都有自己的特性。下面列出了一些典型特性: 扩充客户/合作伙伴/雇员的知识 快速学习并重复利用知识 提高知识产权的价值 为产品和服务提供特别的附加值 建立新知识 共享工作过程和质量革新的知识 图 2. KM 启用模块有两项技术是所有 KM 系统的基础:完全 Intranet 和消息传送及协作。这些技术构建的基础结构支持对信息进行有效传输、架构、访问和协同管理。其余的 KM 启用模块把这一基础结构扩展成一个复杂的 KM 系统,该系统包含各种服务(如内容管理、各种信息传递以及数据分析等)。其它服务(如数据跟踪、工作流过程)也包含在该系统和这些模块中。 实现 KM 启用模块能够是即插即用的。虽然某些模块得益于先前某一模块的实现,仍可按与要开发的特定业务案例之间的相对顺序选择它们。例如,象视频会议这样的实时协作服务,能够很容易地包含在必备技术的上层,但要经过内容管理模块中提供的元数据服务才能得以增强。图 3. 可能的知识管理平台分层结构Microsoft 当前的 KM 平台是 Microsoft BackOffice 系列。它提供的服务能够:建立 KM 先决条件(消息传送及协作和完全 Intranet),经过实现所有的 KM 启用模块(内容管理、团体和组、入口和搜索、数据分析以及实时协作)将它们扩展成 KM 解决方案。除了这些服务,BackOffice 还提供与先前信息或知识源集成和连接的接口。在未来的几个月内,Microsoft 将发布 .NET Enterprise Server,它包含 SQL Server 、 BizTalk Server、 Commerce Server 、 Host Integration Server 、 Internet Security & Acceleration Server 、 Exchange Server 以及 Application Center 。设计这些组件的目的是经过它们的紧密协作来建立下一代的 Web 应用程序。本文的重点是 Web 存储系统,它是 Exchange 以及 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 示例应用程序的。表 1. 知识管理解决方案设计模型服务层次概念设计(方案)逻辑设计(对象/服务)物理设计(组件/技术)用户服务示例方案:建立社区论坛,经过动态地、根据需要添加论坛来实现它的灵活性。一个基于 Web 的虚拟社区,包括以下服务: 业界新闻 协作 最佳方法 共享联系人 易于查找的信息 一个基于 Exchange 的数字版面,它包含不同的 Web 部件,与逻辑设计中定义的服务相对应。业务服务示例方案:要求引导 (RFQ) 文档综述和批准过程。 生成 RFQ 服务 在 BizTalk 框架的基础上将 RFQ 转换成 XML 文档 RFQ 批准过程 生成并验证 RFQ 的属性的事件接收器 使用工作流引擎实现 RFQ 批准过程 使用 ServerXMLHTTP、XML DOM、XSLT 实现 RFQ 转换过程 数据服务示例方案: 一个中央信息库,用来容纳所有相关项目文档以及与工程组织相关的设计文档。 允许小组成员经过适当的安全模型共享或查看文档。 以下对象的逻辑架构设计: 项目 文档 小组成员 基于 Web 存储系统的物理架构设计: 文件夹结构 架构文件夹 自定义内容类及属性 安全 XML 描述符模板 以下是适用于 KM 设计模型的一般最佳方法或建议。在下面的部分我们将讨论具体的主题。 在概念设计阶段,重点是定义能把握业务过程和需求的方案。方案的定义应当根据业务问题范围内的环境来进行,而不是根据解决方案范围内的环境来进行。 在从概念设计到逻辑设计的过渡阶段中,开发小组可审核整套方案以应用适当的面向对象 (OO) 的设计技术(例如用户案例分析),来确定备选服务和/或对象。这些备选服务/对象奠定了逻辑设计模型的基础。这一般是个重复的过程,即需要往复几次才能完成。图 6 是一个基于 Microsoft Visio 联机文档的示例用户案例关系图。本关系图源自 ObjectSpace ()(英文)公司的 Craig Larman 所写的面向对象的分析和设计材料。 图 4. 用户案例关系图示例 在逻辑设计阶段,小组应专注于设计业务和对象,而不考虑技术和平台的因素。对多数开发人员来说,做到这一点比较困难。一些开发小组可能倾向于干脆跳过逻辑设计阶段而直接进行物理设计。这绝对不是一个好办法。逻辑设计模型有许多优点,如: 为各个单独的小组成员同时高效工作提供必须的组织和结构规则。 充当与外部项目和设计人员协作的基础。 降低复杂性。 提供根据用户需求(即方案)优化设计的机会。 在从逻辑设计到物理设计的过渡阶段中,开发小组能够使用逻辑设计阶段定义的服务和对象草稿开始物理设计。所有小组成员和该项目涉及的其它人员都应当首先了解解决方案和整个系统结构的情况,包括系统中各部分之间的相互联系。使用统一建模语言 (UML) 中定义的相互作用关系图(顺序关系图)来获取系统的动态相互作用关系是一个较好的方法。图 7 是一个示例顺序关系图,摘自 Microsoft Visio 联机文档。本关系图源自 ObjectSpace ()(英文)公司的 Craig Larman 所写的面向对象的分析和设计材料。 在物理设计阶段,开发小组应专注于能优化或改进设计模型的设计因素。本文其余部分将集中讨论适用于使用 Web 存储系统进行设计需要注意的最佳方法。 图 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. 数字仪表板示例实现用作 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 SDK。设计业务服务的最佳方法 正如上文所述,业务服务是一个应用程序逻辑单元,它控制执行业务规则的先后顺序,保证所执行操作的事务完整性。以下是一组使用 Web 存储系统设计业务服务的最佳方法:经过使用方案确定关键业务过程 在逻辑设计阶段,开发小组应检查她们在概念设计阶段收集的方案以确定业务过程,如文档批准过程或内容变换过程。确定实现机制 在物理设计阶段,开发小组需要确定这些业务过程最合适的实现机制。有四个基本选项:工作流引擎、事件接收器、 COM+ 组件和脚本(客户端或服务器端脚本)。使用脚本的方法会造成一些困难,如代码不易维护以及脚本的局限性。因此,我们建议采用前三种方法。以下是确定实现方法的一组指南: 如果业务过程符合以下情况,则使用工作流: 涉及多用户和多资源。 具有复杂过程,如批准或业务验证过程。 如果出现以下情况,则使用事件接收器: 只涉及少量的用户或资源。 验证过程简单。 具有整个存储区范围内的事件。 具有定时器事件。 如果使用 Web 存储系统进行的大多是读取操作而不是更新操作,且不涉及工作流,则使用 COM+ 组件。 设计数据服务架构的最佳方法 正如上文所述,数据服务是提供最低提取可见级别的应用程序逻辑单元,用于操作数据。数据服务维护作为公司资产的永久和非永久数据的可用性和完整性。这一部分我们将讨论 Web 存储系统架构设计,下一部分讨论文件夹结构。首先,什么是架构?对于建立在 Web 存储系统技术基础上的整个物理设计模型来说,为什么架构设计至关重要?架构一词指的是一种定义和组织数据(有时称为元数据)的方法。在结构化查询语言 (SQL) 关系型数据库中,架构包括所有的表定义和列定义,以及其它信息(如索引和触发器)。对于存储区,我们将架构设计的重心放在内容类及与其相关联的属性集方面。架构设计对整个 KM 解决方案是否成功有直接影响,特别是在性能和可扩展性方面。架构设计一般是定义数据服务模型的第一步。许多设计的考虑因素和决策都要依赖架构设计。下面一段是对 Web 存储系统架构的简要介绍。Web 存储系统可用于为您的应用程序定义架构。Web 存储系统架构是以内容类为中心的。内容类为存储区中的项/实例定义架构类,是属性集的逻辑容器。为您的应用程序创立架构定义时,要定义自定义内容类及相关的属性。Web 存储系统含有大量预定义的内容类和属性。定义自己的自定义内容类时,您能够使用或扩展(子类)某一预定义内容类。其中包括(但不但限于)表 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:documentMicrosoft 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 提供的预定义属性和类中,您会发现有许多不同类型的命名空间: 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 用作命名空间时,最后一个分隔符为字符”/”。不应向您不拥有的命名空间中添加属性或内容类。例如,向 : 命名空间添加属性就不好,而应当为您的内容类和属性创立自己的命名空间。进行属性定义 Web 存储系统本身对属性名称中可使用哪些字符没有特殊的限制。可是,最好还是遵守以下一些约定: 应当使用命名空间来创立属性并加上一个标识符(如上文所述)。例如, urn:schemas-sample-com:engineering:eco. 属性应当是格式正确的 URI。 属性名称中不应有空格,因为 XML 不支持在元素名称中使用空格,因此 HTTP-DAV 也不支持。 定义自定义内容类 在定义了这些自定义属性之后,下一步就是定义您的自定义内容类。首先,您需要为应用程序选择一个文件夹,用来存储架构信息。您能够将这些信息存储在您的应用程序数据所在的同一文件夹中,但我们强烈建议您使用一个不同的子文件夹,我们称之为架构文件夹。如果您在正定义的架构不是针对某一个应用程序的,您能够在相关的公共存储区里的高层架构文件夹中定义它。存储架构定义的位置和组织架构定义的方式由您决定。可是,在下一部分中,我们将推荐一组方式,指导您如何组织文件夹结构以及如何确定对一组特定应用程序数据应用哪一个架构定义。下面的关系图阐释了使用一个 Exchange SDK 工具(即:Web 存储系统架构设计器)来自定义内容类的一个示例。我们建议您使用该工具或类似工具来定义自定义内容类的定义和属性定义。图 7. 示例:架构设计考虑内容类的继承性 您当然能够从头开始定义一个全新的内容类。不过,多数内容类都能够扩展(”继承”)现存的内容类。扩展内容类意味着已扩展的(派生的)内容类实例的所有属性也存在于扩展中的(基本的)内容类实例中。这一概念与 C+ 这样的面向对象 (OO) 的编程语言中类继承的概念相似。 图 10 显示一个简单的继承方案。扩展文档类意味着任何可在文档类实例上执行的代码或操作都能够在 expensereport 类实例上执行。图 8. 简单内容类继承图 9. 带有多个继承关系的内容类内容类也可扩展为多个内容类。在图 11 中,我们还能看到一个 expensereport 类,它具有 totalcost 和 approvastate 两种属性。但在这一方案中我们希望有作为文档的一个特定类的费用报告和作为消息的一个特定类