级别： 中级 Mei Y. Selvage (meis@us.ibm.com), SOA 数据架构师，Enterprise Integration Solutions, IBM
Ray W. Ellis (rayellis@us.ibm.com), 高级软件工程师, SOA Design Center, SOA Advanced Technologies, IBM
Daniel T. Chang (dtchang@us.ibm.com), 高级软件工程师, Information Management, Data Tools, IBM
2008 年 2 月 14 日 本文对 IBM® Rational® Data Architect 和
IBM WebSphere® Business Modeler 进行了全面评述。通过查看三种场景，了解如何使用 Rational Data Architect 和 WebSphere Business Modeler 将业务流程与数据建模相集成，并了解此过程的一些推荐方法和最佳实践。
简介
在 SOA 领域，业务流程与数据建模紧密关联。大多数业务流程都需要操作某种类型的数据。数据支持业务流程完成目标业务结果。使用模型驱动开发（Model-Driven
Development，MDD）方法，可以轻松集成业务流程和数据建模。此外，在企业架构各层之间可以实现语义互操作。
IBM 是业务流程和数据建模工具的领先提供商。用户可以在 WebSphere Business Modeler 建模业务流程，并在 Rational Data Architect 中执行逻辑数据建模。IBM 已经认识到使用 MDD 集成流程和数据建模的重要性，并因此开发了 WebSphere Business Modeler 到 Rational Data Architect 的集成插件（此后统称为 “插件”），从而将这两种工具链接起来。该插件安装在 Rational Data Architect V7 之上。“WebSphere Business Modeler
and Rational Data Architect Integration Asset – User Guide” 中详细介绍了该插件的安装和使用方法（参见 参考资料）。本文对 WebSphere Business Modeler 和 Rational Data Architect 进行了全面概述，并介绍了三种 WebSphere Business Modeler 和 Rational Data Architect 集成场景中的推荐方法和高级步骤，这三种场景分别是：自上向下、自下而上和中间会合。以下小节将详细介绍这三种场景。
WebSphere Business Modeler 和
Rational Data Architect
WebSphere Business Modeler 是一种业务流程建模工具，使企业能够针对业务流程进行建模、设计、模拟、分析和生成报告，以及定义结构、资源和信息。WebSphere Business Modeler 在业务和信息技术（IT）之间架起了一座桥梁，不仅帮助企业查找并消除业务流程中隐藏的低效率、成本和延迟，还将重要的信息捕获给下游 IT 工具，例如 WebSphere Integration
Developer、WebSphere Process Server 和 Rational Software Architect。
WebSphere Business Modeler 中的业务项（Business item）可以是在业务流程中创建、装配、检查、测试、修改或处理的任何内容。下面的 图 1 展示了一些业务项示例 —— Loans、Application 等等 —— 这些业务项均来自示例 WebSphere Business Modeler 项目 QuickstartFinance，它是 WebSphere Business Modeler 教程的一部分。
图 1.
WebSphere Business Modeler QuickstartFinance 项目中的业务项示例
Rational Data Architect 是一种全面的开发环境，可用于数据建模、关联和集成数据资产以及开发数据库应用程序。最重要的一点是，Rational Data Architect 是一款可允许用户执行逻辑和物理数据建模、存储、域以及集成数据建模的强大工具。下面的 图 2 展示了由示例 Rational Data Architect 项目 QuickstartFinance 导出的 Logical Data Model 示例。注意这些实体均对应于 WebSphere Business Modeler 中的业务项。
图 2. Rational Data Architect 中创建的 Logical Data
Model 示例
在软件开发生命周期中，逻辑数据模型（Logical Data Models，LDM）常常被忽略，但是出于多种原因，它在 SOA 中的地位变得日益重要。LDM 允许用户快速了解应用程序或企业中的数据实体（即通常表示真实事物或抽象理论的数据单元），而不需要关心实现细节。LDM 尤其适合解决日渐复杂的异构 IT 环境。通过创建一个企业数据视图，LDM 有助于降低数据冗余、改善数据质量、加速集成，以及开发新（green-field）项目。其他 IT 工件，如服务模型、消息模型、对象模型和物理数据模型，可在语义上追溯到 LDM，并常常由 LDM 直接转换。将 LDM 称为企业架构的语义中心并未夸大其辞。
拥有了最先进的 MDD 工具，如 Rational Data Architect 和 Rational Software Architect，您可以轻松地根据 LDM 生成下游模型和物理实现。本文稍后将介绍一个真实的案例分析，研究使用 LDM 作为语义源并将其转换为各种 IT 工件。
自上而下的集成场景
在自上而下的场景中，WebSphere Business Modeler 业务项作为 XSD 导出，随后又作为 LDM 中的建模元素（即实体、属性和关系）导入到 Rational Data Architect 中。该场景需要涉及两个主要的 IT 角色：业务分析师执行业务建模，而数据建模师实现逻辑数据建模。
该场景涉及以下几个步骤：
- 业务分析师在 WebSphere Business Modeler 中建模业务流程，并以业务项（BI）的形式获得业务数据。
- 业务分析师在 WebSphere Business Modeler 中将业务项作为 XSD 导出。
- 数据建模师使用 Rational Data Architect 中的插件将 XSD 作为 LDM 导入并进行转化。
- 数据建模师还可以选择使用 Rational Data Architect 将 LDM 转换为一个物理数据库模式和 DDL。
以下图表（图 3）是在 WebSphere
Business Modeler 中创建的，显示了自上而下场景中业务分析师和数据建模师之间的交互：
图 3. 自上而下场景中的步骤概览
当同时满足以下条件时，考虑使用自上而下场景：
- 业务流程建模驱动项目计划
- 业务流程跨越业务单元筒仓（silo）
- LDM 不可用，并且未包含在某个项目之中
- 物理数据库模式相当复杂
然而，人们有时会因为一些错误的原因而选择采用自上而下场景。下面列出了这些决定采用自上而下场景的错误理由（使用引号括起）：
- “我们以前从未实现过 LDM”。凡事总有第一次。如果您的企业过去曾经在 LDM 方面走捷径，那么 LDM 发挥的效用越快，企业获得的长期收益越好。
- “我们没有 LDM 技术”。优秀的数据建模师值得企业为其投资，因此，您应该雇用拥有 LDM 技术的人员或在内部进行培训。
- “我们的应用程序只处理消息”。多数消息最终会持久保存到某个地方。某些人还需要了解消息语义并映射到数据库的物理实现和 Java 类中。LDM 有利于减少总体拥有成本。
最后，需要了解使用 ‘纯’ 自上而下场景的缺点：
- 由于数据模型可能会与特定业务流程紧密耦合，以至于将来的项目需要对 LDM 进行大量修改。
- 由于业务项高度不规范并以文档为中心，如果未经严谨设计和规范化，从业务项到 LDM 的简单转换将导致糟糕的 LDM。
自下而上的集成场景
在自下而上场景中，Rational Data Architect LDM 被作为 XSD 导出，随后作为业务项导入到 WebSphere Business Modeler。通常，与自上而下方法相比，人们更倾向于使用自下而上方法，原因是可以利用本文开头所介绍的 LDM 带来的众多优点。此外，自下而上方法可以实现问题分离：业务分析师关注业务流程建模和改善，而数据建模师集中注意力开发企业级词汇表和兼容的逻辑数据实体。
以下是该场景涉及的步骤：
- 数据建模师在 Rational Data Architect 的 LDM 中对数据建模。或者，数据建模师可以根据现有数据库模式、visio 等获得 LDM。
- 数据建模师使用 Rational Data
Architect 中的插件将 LDM 转换为 XSD。
- 业务分析师将生成的 XSD 作为业务项导入。
- 另外一种选择是，业务分析师还可以将 XSD 作为业务服务对象（Business Service Object）导入。业务服务对象与业务项类似，用于定义调用业务服务操作所需的业务数据。这个方法只适合下面这种情形：当 BSO 元素在 WebSphere Business Modeler 中是只读的时，业务分析师不需要对 BSO 进行修改。
下图在 WebSphere Business Modeler 中创建，显示了业务分析师和数据建模师在自下而上场景中的交互：
图 4. 自下而上方法概览
当满足以下这些条件时，考虑使用自下而上场景：
- LDM 可用。
- 企业希望从业务流程中解耦数据并实现企业级数据管理（例如，主数据管理）。
- 企业希望跨整个企业实现可重用的信息服务。
- 涉及多个计划（例如，业务应用程序重写并需要绑定到数据仓库）。可以更加轻松地分担额外的 LDM 成本。
- 业务流程过于复杂并经常变化。LDM 可以实现更好的稳定性。
- 应用程序以数据为中心。
- 项目需要考虑现有数据源（至少要考虑一部分）。如果具有遗留应用程序、第三方应用程序或基于标准的业务伙伴接口，那么就需要考虑到这点。
最后，实现 ‘纯’ 自下而上方法也需要付出一定代价：
- 在从 LDM 转换到业务项时可能会丢失一些语义，因为 LDM 语义要比业务项语义丰富。
- 由于 LDM 一般比业务项更加完整，具有更多字段或正确标准化的实体。如果未经恰当交流就将 LDM 推入流程模型中，那么业务分析师将会面对大量的信息。如果业务分析师没有正确理解 LDM，他们可能会生成重复的信息并定义 LDM 中已经存在的实体或属性。因此，数据建模师和业务分析师之间需要进行恰当的培训和交流。
- LDM 应避免被物理数据库、应用程序或业务单元束缚，从而实现跨整个企业的语义中心。
中间会合式场景
本文已经介绍了自上而下和自下而上式场景，它们主要侧重于全新的开发。然而，SOA 的永恒主题就是变化。对业务流程和数据模型建模并不是件一劳永逸的事，这种现象只有在模型被废弃或很快就会过时的情况下才会发生。为了避免这种情况，业务流程和数据建模需要反复进行并迅速转化为业务价值。因此，业务流程和数据建模工具应该支持往返（round-trip）功能。例如，可以对业务流程中业务项的修改进行更新并自动（适用于简单修改）或手动（涉及复杂过程）方法反映到 LDM 中，从而实现模型会合。
在实际中，在业务流程模型和逻辑数据模型中管理同步并更改业务项管理并不容易实现，因为它们位于不同的工具中，并且通常由不同的角色执行 —— 业务分析师和数据建模师。尽管如此，精心安排、良好沟通和严格的更改管理可以最大程度地利用工具特性并实现端到端数据管理。
取决于您是否希望更新业务项或逻辑数据模型，中间会合式场景有两种用例。
第一种用例：更新业务项：一旦将 LDM 作为业务项导入到 WebSphere
Business Modeler 中，业务分析师将对业务项作出一些更改（例如，添加新属性）。您需要更新 Rational
Data Architect 以反映 WebSphere
Business Modeler 中的业务项修改。这种用例非常类似于自上而下场景，惟一的区别是在 Rational Data Architect 中使用新的/修改过的信息同步现有 LDM，从而增加了复杂度。下面列出了这种用例涉及到的步骤：
- 数据建模师导入从 WebSphere
Business Modeler 业务项导出的 XSD 版本 1，并使用 Rational Data Architect 内的插件将其转换为 LDM（基准 1）。
- 业务分析师在 WebSphere Business Modeler 中修改业务项，然后导出更新过的业务项作为 XSD 版本 2。
- 数据建模师导入 XSD 版本 2 并根据它创建一个 LDM（基准 2）。
- 数据建模师在 Rational Data
Architect 中比较并合并基准 1 和基准 2。
第二种用例：更新逻辑数据模型：一旦从 WebSphere Business Modeler 将业务项传递给 Rational Data Architect，数据建模师在 Rational Data Architect 中进行一些修改（例如，添加新的列）。然后需要更新 WebSphere Business Modeler 以反映修改。这种用例非常类似于自下而上场景，惟一的区别是在 WebSphere Business Modeler 中使用新的/修改过的信息同步现有业务项，从而增加了复杂度。下面列出了该用例涉及到的步骤：
- 业务分析师将从 Rational Data Architect LDM 导出的 XSD 版本 1 作为 WebSphere Business Modeler 中的业务项导入，作为基准 1。
- 数据建模师在 Rational Data Architect 中修改 LDM，然后将更新后的 LDM 作为 XSD 版本 2 导出。
- 业务分析师在 WebSphere
Business Modeler 中将 XSD 版本 2 作为业务项导入。
- 对于具有相同名称的实体，WebSphere Business Modeler 将创建新的业务项，添加 “_1” 作为后缀；对于新实体，WebSphere Business
Modeler 将只创建新实体。
- 业务分析师需要确定保留哪个版本。
图 5 所示的屏幕截图展示，在使用 XSD 将业务项从 Rational Data Architect 导回到 WebSphere Business Modeler 后，为其添加 _1 作为后缀。
图 5. 往返后导入到 WebSphere Business Modeler 的业务项
基于 LDM 的 MDD 案例分析
SOA 既要求分层式架构，也要求在各层之间实现相互连接。分层式架构可以实现问题分离，并且相互连接支持影响分析和可追溯性。手动方法依赖于非结构化文档、手动发现和冗余通信，不能满足快速应用程序开发和业务需求。因此，利用模型驱动开发方法（MDD）加速 SOA 中的软件开发变得至关重要。
IBM SOA Advanced Technologies US Design Center 最近针对金融服务客户进行了一项 SOA 概念证明，使用 ESB 启用业务到业务的消息路由和转换。MDD 是此次概念证明的核心。客户不具备格式良好的企业逻辑数据模型。现有数据库模式非常不规范，其本质上反映的是消息结构。这种不规范将为数据检索、分析和质量控制增加难度。幸运的是，客户所在的行业具有一组格式相对良好、标准的消息模式。IBM 团队首先根据行业标准消息模式按照数据建模最佳实践开发了符合概念证明需求的 LDM。团队随后与业务分析师和开发团队对该 LDM 进行了审核，以确保 LDM 的定义和标准与企业其余部分保持一致。图 6 展示了使用 Rational Data Architect、WebSphere Business Modeler 和 Rational
Software Architect 的模型和代码转换步骤。
图 6. 使用 Rational Data
Architect、Rational Software Architect 和 WebSphere Business Modeler 实现模型驱动开发
结束语
本文对 WebSphere Business Modeler 和
Rational Data Architect 进行了较高层次的概述。现在，根据本文介绍的推荐方法，您应该已经了解何时采用各种集成场景。您还了解了这三种 WebSphere Business Modeler 和 Rational Data Architect 集成场景中涉及到的具体步骤。
WebSphere Business Modeler 在流程建模过程中捕获关键的业务信息作为业务项。业务项可以是业务文档、工作成果，或者是任务或流程的产物（例如一张发票），或者可以启用某一流程的活动（例如客户查询）。如果某个业务域没有现成的 LDM，那么可根据业务项定义逻辑数据模型（LDM）。同时，LDM 将捕获业务实体、它们的关系和业务规则。一个格式良好的 LDM 可以提供对复杂 IT 环境中的关键业务信息的快速预览，从而反映业务信息需求。它可以比众多应用程序、流程和物理数据源的存在时间更长。当企业准备实现业务流程建模时，LDM 简洁、完整和准确的语义可以为业务项提供理想基础。
最后，同样重要的是，仅仅了解如何使用工具创建格式良好的业务流程和逻辑数据模型还远远不够。还需要知道采用某种场景、安排健壮且可重复的更改管理，以及创建策略以利于业务流程和数据建模的协作优势等背后的原因。成功的业务流程和逻辑数据建模通常需要实现机构和文化方面的转变。“WebSphere Business Modeler and Rational Data Architect Integration Asset – User
Guide” 也总结了一些集成业务流程和数据建模的最佳实践（参见 参考资料）。本文以及用户指南将为您快速掌握业务流程和数据建模集成提供帮助。
参考资料 学习
获得产品和技术
-
IBM Rational Data Architect XSD-LDM 转换插件：在 RDA 逻辑数据模型和 XSD 文件之间进行转换。由于 WebSphere Business Modeler 业务项和业务服务对象可以从 XSD 文件中导出和导入，因此该插件可以实现 Rational Data Architect 和
WebSphere Business Modeler 的集成。
- 使用 IBM 试用软件 构建您的下一个开发项目，可直接从 developerWorks 下载获得。
讨论
作者简介  | | | Mei Selvage 是一名 SOA 数据架构师，在各个信息管理领域和面向服务的体系结构 (SOA) 领域拥有丰富的实践经验。她的目标是帮助跨越 SOA 与信息管理之间的鸿沟。她的研究兴趣包括信息管理和集成模式（结构化数据和非结构数据）、数据建模、元数据、面向方面的研究、人员协作和 SOA。 |
| 
| | Ray Ellis 是 IBM 位于 Austin 的 SOA Design Center 的一名高级软件工程师。他曾经参与过大量 IBM Information Management、WebSphere 和 Rational 产品的开发。 |
| 
| | Daniel T. Chang 是 IBM 硅谷实验室的一名高级软件工程师。他于 2006 年加入了 RDA Core 团队。 |
对本文的评价
| 
