级别： 中级 Brian Byrne, IFW/IAA 过程和集成模型架构师, IBM
John Kling, 顾问和服务架构师,
IBM
David McCarty, IT 架构师,
IBM
Guenter Dr. Sauter, 高级 IT 架构师和管理者,
IBM
Peter Worcester, 服务解决方案营销经理,
IBM
2008 年 10 月 10 日 发现 SOA 设计中规范化建模的方法和价值。看看在 SOA 中规范化数据模型如何与规范化消息模型保持一致。在这个 “SOA 设计的信息透视图” 系列的第 4 篇文章中，选择各种技术和工具，学习这个概念的底层数据和消息建模。本系列将来的文章将描述如何使用各种不同的 IBM® 软件产品来实现这里描述的概念。
简介
本系列的前三篇文章描述了业务术语表在 SOA 中的作用和实现。业务术语表定义描述一个组织的信息的各种术语。规范化数据模型定义一个组织的信息的结构。规范化数据模型的目的不是将数据建模限定在单个的数据库和它的相关物理数据模型上。相反，规范化数据模型是 SOA 包含的所有数据库和相关遗留应用程序中的所有实体及其关系的参考。
数据模型可以采取自上而下的方法根据业务需求单独开发，也可以采取自下而上的方法通过对已有数据结构进行反向工程来开发。这两种方法都可以使用行业数据模型，例如用于保险业的 IBM Insurance Application Architecture（IAA），或 National Retail Federation 为零售业创建的 ARTS 数据模型。不论数据模型是如何创建的，它都表示 SOA 中数据的公共结构。
在 SOA 项目中，规范化数据模型是增量式地开发的。它的信息域覆盖范围与 SOA 项目的范围相对应。在业务分析、需求收集和用例设计期间，有意忽略模型的细节，只显示对业务最重要的信息概念。随着项目推进到技术建模和详细设计阶段，规范化模型将开发成完全支持这些活动。在随后的 SOA 项目中，规范化数据模型逐渐加入更多的业务领域和信息类型，使它们也被纳入到组织的 SOA 的范围。
本文描述使用规范化模型的动机。文中将详细描述每个规范化模型是如何开发的，以及如何在 SOA 中使用它们。
动机
实现成功的 SOA 项目要求谨慎平衡各种相互冲突的因素。例如，需要进行广泛而详细的业务分析，以发现可广泛重用的业务服务。与此同时，经验表明，增量式地开发一系列交付特定业务目标的短小的项目，是开发 SOA 的最易于管理的、最成功的方法。然而，这种实用主义方法的代价是常常会创建 “快而脏” 的服务实现，这种实现只关注眼前的需求和加快实现速度。随着时间的推移，当新的需求要求创建越来越大、越来越复杂的服务组合时，这些服务限制了整个 SOA 的灵活性和可扩展性。
通过检查由服务消息公开的数据结构，可以揭露这种方法的一个症状。如果有很多服务公开相同业务信息的任意变种，或者公开在企业服务总线（ESB）和业务流程中运行的数据映射的很多实例，那么如果适当地注意解决方案的数据架构，就很可能开发出更简单、更易于重用的解决方案来。如果没有注意这一点，这种方法可能会导致一个过于复杂的解决方案，这种解决方案将丧失 SOA 方法的所有优点。
规范化数据模型为各个服务的消息的信息内容提供一个共同的格式。这将导致所有服务的消息格式水平对齐。
规范化消息格式常常需要来自不止一个物理表的数据。这意味着消息必须包含结构信息，以允许服务连接来自不同表的数据。为此，规范化消息模型必须基于规范化数据模型。很多公司已经为公司中最重要的实体开发了一个规范化数据模型。可以利用和扩展这个规范化数据模型，以支持 SOA 分析和设计过程。
考虑 SOA 架构各层中数据格式的垂直对齐和水平对齐很重要。如果规范化数据模型与最终持久化到一个数据库中的数据服务的消息格式差别较大，那么 SOA 需要实现可能比较复杂的转换操作。当数据在服务接口与数据库之间来回流动时，需要用这些操作来完成不同格式之间的映射。
除了避免由于缺乏水平对齐和垂直对齐导致的问题以外，规范化数据模型还可以改善数据的业务用户与应用程序开发人员之间的通信，从而提高开发人员的生产率。最终，企业所做的所有工作都保存在它的数据中。理解数据中内在的业务上的细微差别是应用程序开发人员理解业务的最快、最可靠的方法。在开发应用程序服务的过程中，应用程序开发人员需要有这种理解，以确保应用程序满足业务用户的信息需要。
最后，规范化数据模型是有效数据治理的关键基础。这种模型可以帮助解决一些关键问题，例如：“有多少系统存储每个公共实体的各个部分？”，“哪些系统维护公共数据”，“数据的沿袭是怎样的？”，“信息的质量可以信任吗？”，等等。
与数据治理相关的问题可能是一个项目必须解决的最复杂也是最重要的问题。数据治理问题对于 IT 战略有重大的影响，因为关键项目的成败取决于数据可用性和数据质量。
规范化数据模型
取决于项目的复杂性，可以在两个不同层次的抽象和粒度上指定规范化数据模型。但是，在大部分情况下，这些只是相同模型中的定义的两个阶段。概念化数据建模驱动规范化数据模型中最初宽度的规范，而逻辑数据建模则在同一个模型中增加进一步的细节。
概念数据模型
概念数据模型是从最高层抽象看到的规范化数据模型。模型的这个方面表示 SOA 项目视野下企业的战略性信息需求。
业务实体是概念数据模型的基本构建块。一个实体表示围绕一个单独的、关键的、统一的信息概念进行属性分组，例如人、产品、订单或支付。每个属性表示信息概念在更细粒度上的一个方面，例如名字到期日期或 SKU 号。在术语和语义定义方面，属性和实体都基于业务术语表，并与之一致。概念数据模型是在初始阶段创建的，通常只包括实体和它们最重要的关系。
为了便于演示，可以定义一些主要的属性，不过概念数据模型中不一定非得这样。组成每个实体的所有属性在以后的逻辑数据建模阶段添加。
在 SOA 项目中，概念数据模型的开发几个目的。在 SOA 项目中开发概念数据模型的主要原因是：
- 提供较高层次的信息的共享表示，这些信息用于 SOA 项目范围内的所有业务分析、业务流程设计建模、用例建模和候选服务识别。
- 为项目中随后的建模和设计活动提供共享的起点和边界。它设置基准信息上下文，所有参与业务线的项目的所有服务都将在此上下文中操作。
- 为数据治理在信息的创建、更新、删除、分发和使用上提供一个有用的工具。数据所有权和使用的策略与 SOA 治理模型中为服务所有权和使用定义的责任是紧密耦合的。
概念数据模型通常是粗粒度的，其目的是显示所考虑的宽泛的实体和关系。它并不打算提供可用于服务规范的粒度，而是提供所考虑的信息的高级视图。
这个模型使 SOA 小组可以演示对客户信息需求的结构和内容的理解。它提供：
- 为识别支持资产重用的候选服务之间的信息共享机会提供了基础。
- 为减少遗漏信息需求或无法使 SOA 信息管理与企业更宽范围的信息需求和战略保持一致的风险提供了解决办法。
- 为企业内跨业务单元的信息共享需求分析和信息质量分析（包括未来的变化对 SOA 解决方案的影响的分析）提供起点。这意味着对随后项目估计的准确性受影响的可能性更低，而且随后项目被延迟的可能性也更低。
虽然最常见的是使用信息工程标记法为信息建模编制文档，但是要注意，这种模型可以转换成统一建模语言（Unified Moedling Language，UML），并公开给服务分析人员，以取得跨多个建模域的一致性。为了表现这一点，下面的例子展示了一个使用 UML 的概念模型。可以看到，同样的模型内容可以在 UML 与 IE 标记法之间互换。
图 1：概念数据模型的例子
逻辑数据模型
逻辑数据模型基于前面开发的概念数据模型，通常是同一个模型中的细节的进一步表达，而不是一个与概念模型相映射的完全独立的模型。逻辑数据模型的作用是为跨架构各层：物理数据模型、消息模型和组件模型中的数据结构或数据表示的开发提供输入。此外，逻辑数据模型还可用于服务分析，并公开给服务消费者，例如业务流程模型。
下面说明概念模型与逻辑模型之间最大的区别：
- 逻辑数据模型中的每个实体都被指定了一个主键。实体的主键 是使该实体的一个实例区别于其他实例的一个或一组属性。主键的主要特征是，它是惟一的、稳定的 —— 它不会随着时间而改变。实体中的多个属性可以组合成一个复合的主键。例如，如果所有类型的账户都被指定一个 Account Number，那么可能需要使用 Account
Type 和 Account Number 一起作为 Accounts 实体的主键。
- 在概念数据建模阶段，只显示一些作为演示的属性，而在逻辑数据建模期间，必须将每个实体的所有属性包括进来。逻辑数据模型中包括的属性必须足以支持指定的信息结构的所有方面。属性必须使用与业务术语表一致的业务名称和一致的命名惯例。
- 逻辑数据模型中实体之间的关系是通过外键来表示的，外键与引用实体的主键相关联。如果一个 Sales Order 实体引用一个 Customer 实体，后者由主键 Customer Number 标识，那么 Sales Order 实体将有一个 Customer Number 作为外键。当 Customer 中的主键与 Sales Order 中指向 Customer 的外键具有相同的值时，Customer 实体便与 Sales Order 实体存在关联。有时候，概念数据建模期间表达的关系（特别是多对多关系）在逻辑模型中被显示为实体本身。例如，概念模型可能显示从 Person 到它本身的一个简单的递归关系。在逻辑模型中，我们增加一个名为 RelatedPerson 的实体，该实体包含两个有关系的人的键和一些任意的定义关系本身的属性，例如：RelationshipType="spouse"。
- 规范化决定在逻辑数据模型中得以完成，并导致实体-实体关系与超类型-子类型层次关系的最终规范化表示。
- 逻辑数据模型中的属性被指定一个物理数据类型。为了取得垂直对齐，这应该与用于生成数据模式的物理数据模型一致。为了取得水平对齐，这必须与消息模型一致。
- 指定用于控制允许值的范围或数据值上的其他逻辑约束的规则。这包括跨属性的约束（例如，发货日期必须大于订单日期）。由于这些规则是逻辑数据模型的一部分，所以不应该认为一个数据库必须实施这些规则。数据规则的实施是维护这些实体的服务的职责。这个服务可以使用一个数据库服务或使用应用程序组件来实施这些逻辑数据规则。关于如何实施规则以及由哪些服务实施规则的决定是数据治理的关键方面。
以上列表中的最后两条超出了逻辑模型的正常范围。但是，在 SOA 的上下文中，由于对服务之间共享的数据的一致性和质量的严格要求，这两条非常重要。图 2 显示了逻辑数据模型的一个例子：
图 2. 逻辑数据模型的例子
服务分析模型
服务分析模型表示服务和组件规范的数据结构。服务分析模型中表达的结构是概念模型（或没有概念模型情况下的逻辑数据模型）中的结构的直接反映。在很多情况下，规范化数据模型采用信息工程技术，而服务分析模型采用 UML 技术，业务定义在两者之间可以互换。本系列的下一篇文章中将详细讨论概念定义的这种互换。
图 3 显示了服务分析模型的一个例子：
图 3. 服务分析模型的例子
服务分析模型的目的是以一种与最终数据架构相兼容的方式指导软件组件和服务的规范说明。规范化数据模型以一种规范化的形式描述业务实体、属性和关系，以反映它们的业务用途，而服务分析模型则根据数据的重用特征和服务消费者的需要产生这种规范化模型的确定的聚合和反规范化（de-normalization）。
在很多情况下，可以定义一个单独的组件模型，以便以此为基础派生出规范化消息模型（XML 格式）和组件规范。在这种情况下，概念模型仍然指导组件中的业务类型和通过组件的接口传递的业务类型的定义。这带来了跨数据持久性、软件组件和服务定义的数据结构的对齐。
规范化消息模型
规范化消息模型表示用于在服务总线上交换业务信息的标准化格式。并不是通过架构的不同层传递的所有数据结构都一定遵从这个模型。这个模型只是提供默认的业务数据交换格式，使所有组件只需知道它们自己的数据格式（也许在一个软件组件中）和默认的数据格式（在服务总线上共享）。规范化消息模型虽然基于逻辑数据模型，但是常常通过显著的反规范化处理，以减少关系图和类型层次结构的复杂性，使服务消息更容易被服务消费者理解和消化。
取决于每个项目，规范化消息模型可以使用多种不同的方法来得到。对于主要采用自上而下方法的项目，从服务分析模型经过服务设计建模，最终得到技术性服务规范、组件规范和设计级类模型，包括组成规范化消息模型的数据类型和结构。对于主要集中于 ESB 集成和自下而上服务公开的项目，可以直接用 XML 创建消息模型，这种模型可以手动创建，也可以通过消息流设计和服务代码生成工具自动生成。
用于规范化消息模型的最常见的表示是一组 XML 模式。这种表示的优点是，类型和消息定义在描述所公开的服务的 WSDL 模式中可直接重用。
规范化消息模型由以下部分组成：
- 一组定义好的类型、元素和属性，它们表示所有消息中使用的业务实体和它们的业务属性。每个定义包括：
- 技术性数据类型、格式、结构和名称
- 控制类型允许的值的规则
- 类型的业务语义
- 一组定义好的消息，每条消息包括一组相关的之前定义的类型、元素和属性，它们的结构可提供一个具有特定语义和上下文的业务文档。
图 4 说明了一个规范化消息模型：
图 4. 规范化消息模型的例子
规范化消息模型最终基于逻辑数据模型和业务术语表，中间要通过一个服务分析模型。规范化数据模型以规范化方式描述业务实体、属性和关系，以反映它们的业务用途。规范化消息模型提供规范化数据模型上的一组视图，每个视图将一组相关的实体公开为一个可重用的消息，但总是遵从规范化数据模型中定义的实体和关系结构。
结束语
总之，有很多相关的模型可用于分析和定义服务约定、服务的软件实现和数据平台中涉及的数据结构。数据类型的这些表达的一致性非常重要，这种一致性是通过指定规范化数据模型取得的。规范化数据模型是 SOA 项目中实体及其属性和基于业务需求的关系的一个公共表示。它应该与业务术语表、业务流程、服务/消息模型和物理数据模型保持一致。这样可以确保服务执行期间数据在流经架构中各层时语义和结构的互操作性。
如果这个概念能解决您在项目中遇到的问题，并且有兴趣去理解如何借助工具来解决数据建模中的挑战，那么请继续关注本系列下的一篇文章 “在 SOA 中使用 Rational Data Architect”。
参考资料 学习
- 您可以参考本文在 developerWorks 全球站点上的 英文原文。
-
阅读 本系列 的其他文章。
获得产品和技术
讨论
作者简介  | | | Brian Byrne 在分布式系统的设计和开发领域具有 10 年以上的经验，并花了 7 年时间推动 Industry Models 体系结构在各种企业中的应用。Brian 当前是 IBM Information Management 组织的架构师。 |
| | | John Kling 是 IBM Global Business Services 的一名 Information Services Practice 架构师。他负责领导大型的客户管理，主要领域有数据质量、数据集成和主数据管理。他目前是一家 Fortune 500 强实业公司负责 SAP 实现的数据小组的主管。 |
| 
| | David McCarty 在法国 La Gaude 的 IBM European Business Solution Center 工作，在为 IBM 客户设计和开发 IT 系统方面有 20 年经验，他当前是 Information as a Service Competency Center 的成员，为在 SOA 解决方案中使用数据系统而开发技术和最佳实践。 |
| 
| | Guenter Sauter 是 IBM 软件组的 Information Platform & Solutions 部门中的架构师。他当前从事 IBM 主数据管理和信息平台技术上的体系结构模式和使用场景研究。不久之前，他是一个架构师团队的主管，负责开发 Information as a Service 的体系结构方法、模式和最佳实践。他是 IBM 的 SOA Scenario on Information as a Service 的技术主管之一。 |
| 
| | Peter 在三年前加入 IBM，之前在美国国防部、GE 公司和 Morgan Stanley 等机构工作了差不多 25 年，他在那些机构中担任技术领导职位，并在企业体系结构和企业数据集成方面获得了丰富的经验。他加入 IBM 时最初担任 Information as a Service 架构师团队的高级 IT 架构师。他当前是 IPS Global Services 组织的解决方案营销经理，主要研究 MDM 解决方案。 |
对本文的评价
| 
