转自http://www.ibm.com/developerworks/cn/webservices/1005_shaohq_bttmdm/
面向服务的体系结构（Service-Oriented Architecture，SOA）作为一种融合现代企业业务需求和 IT 系统建设的体系架构，也是配合业务目标，横向和纵向打破组织界限而定义出一套可重用的功能（服务）的开发方式。具体来说，就是将业务流程、任务分解和描述为一系列原子的或组合的服务，通过统一的数据格式、标准的通信协议和接口描述，支持服务的使用方根据业务需要访问相关的服务。通过对服务的编排和调度以完成特定的业务任务，从而让企业快速适应各种复杂的客观条件和业务需求的变化。
采用 SOA 的体系架构能够有效整合成熟的 IT 技术、方法和设计框架，在这种环境下，可以保证：
- IT 与业务的一致性
- IT 资产的最大化重用
这些有助于确保在耗资巨大的 IT 项目中的投资能够给业务带来长远的价值。
模型驱动开发（Model-driven development，MDD）是对象管理组织发布的，由模型驱动体系架构（Model-driven Architecture，MDA）技术支持并驱动的软件开发方法和过程。MDD 由 MDA 驱动，并更着重于模型转换和代码生成。
模型驱动开发的主要优势在于：
- 开发效率 － MDA/MDD 是一种极其高效的设计和开发方法。使用 MDA/MDD 方法可以尽可能地通过代码生成，以更少的人力来完成原先相同的工作量，或者以原先相同的人力来完成更多的工作，所有这些都无需对开发团队施加额外的压力。
- 软件质量 － 使用一种单一的模型来生成和导出系统的大部分代码可以极大地降低人为错误的发生。
SOA 和 MDD 都已经是业界公认的标准，使用 MDD 方法开发符合 SOA 架构的应用程序，能够最大程度的为企业缩短开发周期，节省研发成本。
SOA 的实施通常从五个切入点（人员、流程、信息、连接性和重用）中的一个或多个入手，遵循 SOA 场景：服务创建、服务重组、交互与协作服务、SOA 所支持的业务流程管理、信息服务、服务设计、服务治理以及服务安全性中的一个或多个来完成。
MDA 的实现则是根据抽象层次的不同，通过定义计算独立模型（Computation-Independent Model, CIM）、平台独立模型（Platform-Independent Model，PIM）和平台相关模型（Platform-Specific Model，PSM）三个阶段逐步实现（更多内容可以参考：模型驱动体系架构和 CIM 相关的技术）
其基本的方法是从 CIM 开始建模，将 CIM 转换为 PIM，然后将 PIM 转换为可以适用于不同具体平台实现的模型 PSM，例如 Java™ 2 Platform、J2EE™ 等。
因此，本文选择了服务创建的场景作为基础，描述了一种从信息模型抽象和服务重用这两个角度出发，采用 MDA/MDD 方法，利用 Rational Software Architect(RSA)、Master Data Management Server (MDM) 和 Webshpere Multichannel Business Transformation Toolkit(BTT) 等工具快速开发服务实现的最佳实践。
CIM 的建模通常是由业务人员根据需求进行分析和构建或者直接采用成熟的行业模型，不在本文讲述范围之内，从 PIM 开始这个过程可以概括为：
- 基于行业模型的定制和裁剪，在 RSA 中完成 UML 建模；
- UML 模型和 MDM Server 模型的转换；
- 利用 MDM 的开发工具生成 EJB、Database Scripts、Configuration snippets 以及 Web Service；
- 利用 BTT 集成 MDM 所生成的 Web Services
平台独立模型的设计是业务人员与开发人员，需求与实现之间的桥梁，好的平台独立模型是项目成功的关键因素之一。在许多行业，都已经有成熟的行业模型可供参考，例如 IBM 在银行业提供 IFW，在保险业提供 IAA，电信业有 TMForum 组织的 eTOM。因此，通常不需要从零开始进行平台独立模型的设计，而是通过对业界参考模型的定制和裁剪，快速创建适合特性业务需求的平台独立模型。
在 RSA 中导入 IFW 的 BOM（Business Object Model）并对其中的产品域（Product Domain）进行定制，生成所需要的业务数据对象（Business Object）。
图 1. 使用 RSA 定制 IFW 模型
平台独立模型中的业务数据对象设计是使用面向对象的分析设计方法，对业务领域的事物的进行抽象和刻画的结果。
图 2. 经过定制的产品对象模型
如图所描述的经过定制的产品对象模型。在此模型中定义了产品领域所要依赖的所有数据实体和几类主要的实体关系：
- Product, 代表产品对象的数据实体，有自己的继承结构和子类实体。如：存款产品（Deposit Product）、贷款产品（Loan Product）和投资产品（Investment Product）等 ，所有子类和产品实体之间是 Generalization 的关系；
- Condition，是附属在产品上的条件，和产品实体是 Association 的一对多关系。例如此产品的适用性条件（Eligibility Condition），收费条件（Fee Condition）和收益率条件（Rate Condition）等；
- Channel，是银行中可用的客户沟通渠道，Product 通过 ProductChannelDetails 与 Channel 相关联，以表示一个产品在哪个渠道上的可执行操作。例如客户可以通过柜台这个渠道对某个产品进行购买 / 查询 / 交易 / 取消等操作，而通过电话这个渠道则只能进行查询的操作；
- MarketSegment 和 ProductTranscationType 分别用来表示产品针对的细分市场和产品支持的交易类型。
用例描述了系统的行为。在本文的例子中，针对 Product 域的用例有：
图 3. Product 域的用例
因为篇幅限制，本文只将其中一个用例详细讲解。下图描述了定义核心产品细节（Define Core Product Details）这样一个用例，它接收 Components Product，ProductComponentDetails，Condition，Product 作为输入，此用例需要检查有没有重复的产品定义，校验产品定义信息的完整性，并将产品的详细信息持久化。
图 4. 用例：定义产品细节
平台独立模型（PIM）最终需要转换为平台相关模型（PSM），并使用具体技术实现模型。MDM 产品具有描述模型并通过模型生成代码的能力，因此，MDM 的模型是本文用的平台相关模型。
MDM Server 作为成熟的主数据管理产品，已经内建了客户（Customer）、产品（Product）和合约（Account） 等领域的模型，以及与这些模型相关的 700 多个 Web Service 操作。MDM 内建的数据 / 操作模型中，客户域基本上无须太多客户化即可应用在大多数行业的客户主数据管理上，而产品和合约相对客户域来说则有所不同。例如银行 / 电信 / 医疗 / 零售 / 保险 / 证券等行业，不同行业在客户关系管理上的数据模型相差无几，但是在产品与合约上的差别则比较明显。
尽管不同行业在产品与合约上的数据 / 操作模型有所不同，MDM 仍然抽象出来了一套适用于各行业的比较通用的模型。但是要求用户针对自己行业的特色来对模型进行扩展和定制。MDM 产品提供了丰富的扩展机制，使得用户能够方便的对 MDM Server 进行扩展和定制。这些扩展机制有：
-
数据扩展（Data Extensions）
InfoSphere MDM Server 提供了不同的机制来扩展 MDM 的数据模型，而无须修改 MDM 产品的已有代码，这些机制有：
-
- Data Additio：创建新的数据库表及相应的 WebService 操作
- Data Extension：对已经存在的数据库表增加属性
- Data Specs：对已存在的数据实体附加 XML 格式的属性
- Product sub-type Hierarchy：对产品的类型结构进行扩展
在使用数据扩展的过程中，首先要对 MDM 已有模型与目标数据模型之间做映射，找出两者的差异。这个过程可能可能出现如下一些情况：
表 1. 数据扩展的场景及解决方案
PIM 模型元素 MDM 模型的映射 解决办法 例子 数据实体（Data Entity） MDM 中不存在此数据实体 通过 MDM Data Addition 扩展方式，在 MDM 中增加此数据实体 Channel，Product Channel Details 数据实体中的属性 MDM 中存在此数据实体，但属性缺失 通过 MDM Data Extension 的方式，在 MDM 中为此数据实体增加属性项。
或者通过 MDM Specs 的方式，为 MDM 中的数据实体附加 Specs本文通过 MDM Specs 方式为 Product 实体增加了属性项。 数据实体中的属性在 PSM 中不存在 MDM 中存在相应的数据实体，并且此数据实体的数据项在 PSM 中不存在 忽略此属性项 枚举类型 MDM 中不存在此枚举类型的 Code Table 为 MDM 增加相应的 Code Table Market Segment、Product Transaction Type -
-
行为扩展（Behavior. Extensions）
在 Web Service 操作的行为方面，MDM Server 以基于事件的方式，在不修改 MDM 产品的情况下提供了一些扩展方式：
-
- Pre/Post Transaction：在交易执行之前或之后增加客户的业务逻辑
- Pre/Post Action：在某次数据操作之前或之后增加客户的业务逻辑
- Overriding Business Rules：修改已有交易的业务规则
行为扩展的目的是为了填补 MDM 操作模型与目标操作模型之间的差异，与数据扩展的使用类似，我们首先要针对 MDM 操作模型和目标操作模型做映射，找出其差异，进而使用行为扩展来对 MDM 进行补充，以此实现业务需求。用户可以通过 MDM Server Transaction Reference Guide 这篇文档查询到所有 MDM Server 中已经实现的 Web Service 的详细描述，包括此操作的输入输出参数，Pre-Condition, Post-Condition, Behavior. 等等。
在操作模型的映射过程中，可能出现的情况有：
表 2. 行为扩展的场景及解决方案
PIM 用例 MDM Web Service 的映射 解决办法 例子 用例 MDM 中存在相应的操作，并且逻辑，参数都相匹配 - Define Core Product Details → addProductInstance
Retrieve Product Details → getProductInstance用例所包含的逻辑 MDM 中存在相应的操作，并且输入输出参数相匹配，业务逻辑不完全一致 通过 MDM Behavior. Extension 的方式客户化 MDM 中此操作的业务逻辑。 用例中对 Pre Condition 的约束 MDM 中存在相应的操作，并且输入输出参数相匹配，但是对输入参数的校验规则不符合用例要求 通过 MDM 规则框架，取消该校验规则；
或者通过 MDM 规则框架，实现自己的校验规则，并替代原有的规则。TermCondition Overriding Rule 用例 MDM 中不存在相应的操作来实现此用例 通过 MDM Transaction Extension 的方式创建新的 Web Service 操作实现此用例。 Select Delivery Channel -
-
新交易（New Transactions）
对于某些业务逻辑复杂，而数据模型无须改动的情况，用户还可以通过创建新的 Web Service 操作的方式来满足业务需要。
使用 MDM Workbench 实现模型的扩展正确安装 MDM Workbench 以后，可以在其 workspace 中看到 MDM 所有模型的实现。MDM 将不同的模块分成不同的项目，而用户对 MDM 已有模型的扩展实现将被放置在用户自己新建的项目中。通过 MDM Workbench 的新建向导（Wizard），用户可以创建新的项目和模型的扩展。
图 5. 创建 MDM 模型的扩展
在 MDM 扩展项目里，最主要的文件是 module.mdmxmi，此文件用于描述用户扩展的模型，前文提到的扩展方式（数据扩展、行为扩展和新交易扩展等）的模型描述都在此文件中。用户对比目标模型和 MDM 已有模型，找出其中的差异后，使用前文提到的相应扩展手段对 MDM 模型进行补充，进而得到符合自己需求的模型实现。在完成对 module.mdmxmi 文件的编辑之后，可以通过其编辑器上的 Generate Code 功能生成相应的实现代码。（在某些情况下，需要用户对生成的代码做进一步的定制。）
如下图所示，编辑 MDM 模型文件，并且通过 Generate Code 功能生成 EJB 代码，数据库操作 Java 代码，业务逻辑 Java 代码，WebService 接口描述文件 WSDL，WebService 实现代码，数据库表创建脚本以及 MDM 框架配置脚本等。
图 6. 编辑 MDM 模型文件并生成代码
图 7. MDM Workbench 生成的代码示例
图 8. MDM Workbench 生成的 WSDL 文件示例
BTT（IBM Webshpere Multichannel Business Transformation Toolkit）是 IBM 在多渠道集成方面提供的解决方案，它符合 SOA 架构，并且对不同渠道提供了良好支持，例如手机渠道、Web 渠道、自助设备渠道（ATM/Kiosk 等）、营业厅柜员渠道等。
本文探讨了在模型驱动开发的方式下，如何高效地使用 BTT。
PIM 模型中描述了数据以及用例，这里的用例会被映射为 PSM 的一个操作，其执行者是应用系统本身。在本文中，PIM 描述的数据以及用例被映射到 MDM 中的数据表以及 Web Service 操作。BTT 作为渠道解决方案，会使用到这些数据以及操作，为终端用户提供交互界面以及展现逻辑。
如下图所示，本文以为产品（Product）选择分发渠道（Delivery Channel）为例，产品经理首先要查询产品列表，并了解产品定义的详细信息，然后查询渠道列表以及相关渠道的详细信息，最后做出决策，将某个产品分配到相关的渠道上去。
图 9. 选择产品分发渠道的作业过程
要实现上图所示的例子，可能会有无数种界面展现形式，在 BTT 里，最简单也是非常有效的方式就是使用页面流（Page Flow）。使用 BTT 的交易向导（Transaction Wizard）可以创建一个页面流，在这里，页面流的实现是一个状态机（State Machine），其中的状态用来显示一个页面，用户在页面上所做的提交（Submit）、回退（Back）、取消（Cancel）、确认（Cancel）等操作被描述为该状态上可能发生的事件，而对后台逻辑的调用则发生在从一个状态到另外一个状态的转换上。使用页面流描述展现逻辑以后，BTT 的工具还可以为这个页面流生成相应的 Java 代码和空白页面。BTT 还提供界面编辑器来辅助用户编写 HTML、JSP、Rich Client 等各种形式的界面。
使用 BTT 与 MDM 集成，需要做如下几个主要步骤：
- 将需要用到的 WSDL 文件从 MDM 的 Workspace 导入到 BTT 的项目当中。
- 根据平台独立模型的描述，使用 BTT 的 Transaction Editor 工具画出页面流程图，并且将相应的 Web Service 关联到页面流的相应节点中。
如下图所示，使用 BTT 的开发工具描述页面流（Page Flow）：
图中绿色的状态用于显示页面，青色的状态可以编写一些业务处理逻辑，也可以直接调用 MDM 提供的 Web Service 接口。
图 10. 使用 BTT 开发工具编写页面流
- BTT 工具在构建的过程中会自动生成相应的 Web Service 调用 Java 代码，BTT 页面流执行文件，相应的页面骨架，以及相关的 BTT 配置文件，如下图所示：
图 11. BTT 页面流工具生成的代码结构
本文提出了一种在 SOA 架构下，使用模型驱动开发的方式，以 IBM 主数据管理产品 MDM Server 和渠道整合产品 BTT 为基础，快速构建行业应用解决方案的办法。
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/14780828/viewspace-665796/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/14780828/viewspace-665796/
2642
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
