SOA 案例研究：SOA 设计

本文是面向服务的体系结构 (SOA) 系列之一，主要通过名为 JKHL Enterprises (JKHLE) 的虚构公司阐述一个案例研究。本文的案例研究重点是与 SOA 设计（更具体地说是服务和流的设计）相关的挑战和解决方案。本文描述如何应用“SOA 设计场景”的实现和解决方案模式来解决与该案例研究相关的业务和 IT 挑战。

我们在本文中介绍的案例研究包括以下人员和角色：

• Sandy Osbourne-Archer，首席技术架构师
• Edmund Smythe-Barrett，企业架构师
• Ursula DeBarry，软件架构师兼服务设计团队主管
• Henry Lee，业务分析人员
• Jason Smith，集成开发人员
• Willy Sheng Duo Li（也叫 Willy Li），应用程序开发人员

帐户开立项目的挑战

我们在本文中定义的帐户开立项目挑战与“SOA 设计场景”相关。该场景的重点包括用于 SOA 设计（更具体地说是服务和流的设计）的方法、构件和工具。

软件架构师兼服务设计团队主管 Ursula DeBarry 从业之初担任的是 J2EE™ 开发人员，后来成为了软件架构师。

她拥有娴熟的设计技能，在应用诸如 Rational® Unified Process® (RUP®) 和面向服务的建模与体系结构 (Service Oriented Modeling and Architecture，SOMA) 之类的方法方面非常熟练。除了使用 IBM® Rational Software Architect 之类的工具对她所负责的项目进行应用程序建模和组装以外，她还为同事组织了多个关于方法和工具使用的研讨会，并在其中负责授课。

Ursula 对专门从事 SOA 设计方面的工作特别感兴趣。在 Ursula 之前担任的职位中，她完成了 Web 服务试验项目的设计和实现。不过，这个试验项目由于政治原因而取消了。

她非常渴望寻找新的 SOA 机会。Ursula 从以前的同事——应用程序开发人员 Willy Li——那里了解到，JKHL Enterprises 正在寻找有经验的软件架构师和服务设计师来实施 SOA 计划。Ursula 前去 JKHL Enterprises 应聘。

首席技术架构师 Sandy Osbourne-Archer 对 Ursula 进行了面试，由于她本身具有丰富的经验、娴熟的技能，并且有 Willy Li 推荐，因此当场就被录用了。Ursula 非常高兴能担任软件架构师兼服务设计团队主管。

在与 Sandy 的首次会面中，Ursula 了解了帐户开立项目的目标和挑战。Sandy 表示，自己对业务和 IT 之间存在的语义差异和细节差异不甚满意，因为这些差异容易出现不同步或不完全一致的现象（请参见图 1）。

Sandy 强调了保持业务设计和 IT 解决方案一致的需求，以便保持企业对新业务机会的敏捷性和响应能力。

图 1 当前业务和 IT 不同步（不一致）

Sandy 列出了帐户开立项目的高级业务目标：

• 目标 1：降低成本：
  • 1.1: 降低创建和管理帐户的成本
    • 1.1.1: 降低帐户激活的成本
  • 1.2: 减少纸质文档的数量
    • 1.2.1: 增加电子应用程序的数量

• 目标 2：提高每个客户拥有的产品数量
• 目标 3：提高可用性
• 目标 4：减少不遵从法律法规的风险
• 目标 5：增加客户自助服务
• 目标 6：加快上市时间

Sandy 总结了高级设计目标和挑战：

• 业务设计：
  • 清楚地定义业务战略和目标
  • 以业务驱动的方式对服务需求、设计和实现进行优先排序
  • 提高服务重用，以加速上市时间并降低成本
• IT 解决方案设计：
  • 为关键业务活动的服务提供显式的可跟踪性
  • 可重复且可扩展的设计方法
  • 能实现更好重用的服务组合
  • 用于多通道访问的服务绑定策略
  • 方便组装、部署和管理的解决方案

SOA 设计场景的帐户开立计划

通过一系列的会议，Ursula 和企业架构师 Edmund Smythe-Barrett 共同制定了 SOA 设计场景的帐户开立计划。

他们与业务分析人员 Henry Lee 进行了讨论，对为帐户开立项目定义的关键业务需求有了更好的理解。图 2 描述了帐户开立高级流程，提供了该流程的关键元素的概念视图。

图 2 帐户开立高级流程

为了提高 SOA 设计的成熟度和改进帐户开立流程，Ursula 计划应用用于服务设计的 SOMA 并执行用于流程组合的业务服务设计。

应用 SOMA 进行服务设计

Ursula 指出，IBM Global Services 的架构师和专家开发的 SOMA 方法基于从客户合作项目中获得的知识。Ursula 希望能够利用经过验证的 SOMA 方法进行帐户开立服务设计。

IBM 提供了两种应用 SOMA 进行服务设计的方法：

• 用于服务设计的 SOMA

在此方法中，客户通过服务约定雇用 IBM，让他们的架构师和专家来应用 SOA 方法和 IBM 工具来代表客户进行服务设计。

Ursula 和 Edmund 一致同意，对于该帐户开立项目，他们将参加与 IBM 的服务合作项目，以便在使用“用于服务设计的 SOMA 方法”来创建服务设计方面获得帮助。服务设计团队和 IBM 将应用 SOMA 方法来确定服务，指定服务和流，并实现该服务设计。与 IBM 的合作将帮助服务设计团队为将来的项目获得 SOAM 的实际应用知识。

• 业务转换分析 (BTA) 和服务设计

在此方法中，客户通过应用 IBM Rational Method Composer 中包含的 RUP SOMA 方法直接创建服务设计。BTA 和服务设计的重点是通过应用自动化的设计工具和流程，以改进设计一致性和加速上市时间，从而提供正式的说明性服务设计方法。或者，客户可以雇请 IBM Services 代表他们应用 BTA 和服务设计。

在旨在使将来的 SOA 变得更加自给自足的工作中，Ursula 领导的服务设计团队将开始培训 BTA 和服务设计的使用。

用于流程组合的业务服务设计

Ursula 将领导帐户开立项目的用于流程组合的业务服务设计。

将 SOA 场景模式应用于该案例研究

SOA 设计场景的重点是通过使用经过证明的 IBM 方法和工具，从而使业务设计与 IT 解决方案设计保持一致。诸如组件业务模型（Component Business Model，CBM）、SOMA 和 RUP for SOMA 等方法提供了概念框架，用于定义建模的方方面面以使业务与 IT 设计保持一致。使用 IBM 工具来支持设计方法，以对可跟踪性建模并创建整个生命周期中的设计构件。SOA 设计场景可应用于每个基本 SOA 场景。

SOA 设计场景模型的基本构造包括流、服务和组件（请参见图 3）。

• 流或流程表示完成某个业务流程所需要的活动流。流是旨在实现业务目标的相关和集成服务的组合。
• 服务是代表性的可重复业务任务。通过提供定义良好并且与实现无关的接口，从而将服务用于封装应用程序的功能单元。服务可由其他服务或客户端应用程序调用（使用）。
• 组件表示服务向服务使用者公开的功能，以及由实现服务的服务提供者提供的服务质量 (QoS)。

图 3 服务提供业务与 IT 之间的一致性

注意：SOA 设计场景的关键元素是服务设计。

服务设计以及最终的服务通过在业务流和目标与 IT 组件之间提供桥梁，从而提供一致性能力（如图 3 所示）。

以下几个部分将详细描述该案例研究解决方案元素，这些元素映射到 SOA 设计场景实现：

• 用于服务设计的 SOMA
• 业务转换分析和服务设计
• 用于流程组合的业务服务设计

用于服务设计的 SOMA

注意： 用于服务设计的 SOMA 实现特别利用了 SOMA 标识、规范和实现阶段来交付所需的 SOA 设计成果。

Ursula 和 IBM Services 合作项目团队开始通过应用用于服务设计的 SOMA 方法来处理帐户开立服务设计。该团队集中于服务设计的以下方面：

• 服务标识
• 服务规范
• 服务实现

SOMA 方法是用于 SOA 设计和构造以支持目标业务流程的分析和设计方法。SOMA 通过服务、组件和流的标识、规范和实现来完成此任务。SOMA v3.1 扩展了 SOMA，以提供同时还包括实现、测试、部署、监视和管理活动的端到端方法，如图 4 所示。

图 4 SOMA 方法

SOMA 方法提供了用于 SOA 设计的描述性指导，并且是 SOA 解决方案设计模式的基础（请参见图 5）。

图 5 用于 SOA 参考体系结构分层解决方案的 SOMA 指导

服务标识

服务标识的目标是创建候选服务及其对业务有意义的关联操作的初始集合。服务标识主要由软件架构师来完成，并且通常包括业务分析人员以支持角色形式的参与。

在服务标识期间，将创建服务模型工作产品，并移交给负责服务规范的软件架构师。服务标识与产生服务模型的分析级别同义，而服务规范则是设计级别。

服务标识的关键输入包括：

• 业务分析和建模

用于定义业务体系结构。CRM 通常用于业务分析，以帮助客户了解其业务和能力，并确定能力差距。也可以使用其他方法来进行业务分析。

• 服务注册中心和存储库

现有的服务和有关它们的信息通常存储在服务注册中心和存储库中。该帐户开立项目是第一次采用 SOA；因此不存在现有的服务。

让我们进一步了解三种用于确定候选服务的补充技术：

• 目标-服务建模
• 领域分解
• 现有资产分析

目标-服务建模

目标-服务建模的关键目标是证明服务的可跟踪性和与业务目标的一致性。目标-服务模型是一种由内向外 (middle-out) 的方法，在相应输出可用时迭代地用于验证通过领域分解和现有资产分析技术确定的候选服务列表的完整性。

在开发目标-服务模型时，您通常与业务主管、业务分析人员和主题专家紧密合作，以确定范围内的业务目标和项目的阶段。对于每个目标和子目标，您将确定可用于评估业务性能的关键性能指标 (KPI) 和度量。

JKHLE 销售管理业务组件中的服务标识重点目标是确定支持该业务组件的服务。表 1 提供了一个业务目标的摘要和支持 KPI，以说明目标-服务模型。

表 1 目标-服务模型的业务目标和 KPI

目标	目标的 ROI	KPI/度量	服务
1.1 将创建和管理帐户的成本降低 10%	$1,000,000	1.1.1 将帐户激活成本降低 50%	AccountActivation 组合 ARSetup AccountSetup CreateAccount

领域分解

对于领域分解，我们采用自顶向下的方式工作，将业务领域分解为主要的功能区域和子系统。在下一个级别，我们进一步将功能区域分解为流程、子流程和高级业务用例。

注意：高级业务用例通常是作为服务公开的理想候选者，并且可以提供初始的设计范围。

领域分解使用并增强领域分析和领域工程方法的子集，包括：

• 功能区域分析

将领域分解为功能区域可以为 IT 子系统及其实现服务的对应服务组件的设计提供业务边界。如果没有提供 CBM，则为 SOMA 合作项目执行领域分析。

• 流程分解

执行业务流程建模以将流程分解为子流程和任务。对于初始的候选服务列表，三个级别的分解通常就足够了（请参见图 6）。

• 面向变化的分析

全面观察流程、规则、策略和结构（数据），以确定候选共性。下一步，分离出流程、规则和结构的变化。

图 6 流程分解

分解集中于“帐户开立”流程以及“帐户激活”和“验证”功能区域，如图 7 所示。

图 7 帐户开立流程和功能区域的领域分解输出

现有资产分析

现有资产分析的主要目标是最大限度地重用现有的应用程序事务、现有系统中的模块和打包的应用程序。在执行现有资产分析时，我们采用自底向上的方法以确定候选服务。可能会确定一些新服务，并且在其他情况下，该技术将确认前一项技术的标识结果。

观察图 7，Ursula 与 Edmund 使用自底向上的方法，共同确定 JKHLE 环境中的现有应用程序和事务，以最大限度地实现重用。Edmund 让 Ursula 知道许多现有的中间件和后端应用程序，例如 CICS、IMS、SAP 和 Siebel。Ursula 评估每个现有的应用程序，以确定应该将哪些应用程序作为帐户开立流程应用程序的服务公开。他们可以使用 IBM WebSphere Studio Asset Analyzer 来扫描 IBM System z™（大型机）和分布式软件，以确定并在存储库中存储相关的应用程序信息，其目的是促进和了解哪些资产可以成为可重用组件并作为服务公开。

现有资产分析并不只是将现有的应用程序接口作为 Web 服务公开。需要周密考虑以确定现有应用程序的接口是否允许良好的服务设计（请参见图 8）。

图 8 将现有应用程序作为服务公开的选项

如图 8 所示，存在几种公开现有应用程序的选项：

• 将现有应用程序包装为服务

将功能保留原样，但是使用工具或中间件将现有功能作为服务公开。例如，将 CICS 应用程序作为 SOAP Web 服务公开（也称为直接公开）。

• 将现有功能包装并替换为服务

按上述方式包装功能，但是在以后使用最终的服务规范来重新开发服务。然后，替换原始服务，并将客户端重定向到新的实现。

• 使用更适合于服务调用的适配器

在某些情况下，无法包装某个功能并将其作为服务公开。

但是，能够以更容易集成的形式包装该功能，例如消息队列接口或 Java 连接器体系结构（Java Connector Architecture，JCA），从而允许新服务就地访问该功能（也称为间接公开）。

• 将功能集成到服务中

在某些情况下，只需将现有的功能用作服务实现中的一个逻辑组件，即可让新服务就地访问该功能。

在执行每一项标识技术之后，将确定一个修订后的候选服务组合，这样就为制定规范做好了准备。

服务规范

服务规范定义依赖关系、组合、公开决策、消息、服务质量约束以及与服务状态管理相关的决策。服务规范任务的目标是详细描述服务模型。

服务规范包括以下子任务：

• 应用 Service Litmus Test 以做出公开决策
• 确定服务依赖关系
• 确定服务组合和流
• 确定非功能性需求
• 指定服务消息
• 编写状态管理决策文档

应用 Service Litmus Test 以做出公开决策

使用 Service Litmus Test 以做出服务公开决策。图 9 突出显示了需要公开的 JKHLE 候选服务。

图 9 要公开的服务

确定服务依赖关系

详细的服务检查可以揭示对用于实现服务功能的其他服务或应用程序的服务依赖关系。

存在两种需要考虑的依赖关系类型：

• 功能依赖关系是这样的服务之间的依赖关系，即这些服务彼此依赖以交付所需交付的服务。例如，AccountActivation 组合服务具有对 ARSetup、AccountSetup 和 CreateAccount 服务的依赖关系。
• 流程依赖关系是这样的服务之间的依赖关系，即这些服务编排在一起以构成业务流程。例如，帐户开立流程依赖“确定资格”前提条件和“创建帐户”流程依赖关系。

确定服务组合和流

检查功能区域和业务流程可以帮助详细描述服务及其流的组合。服务流规范描述服务之间的编排。例如，帐户激活组合服务是一个长时间运行的可中断流程宏流。“帐户查询”是一个短时间运行的不可中断流程（微流）。

确定非功能性需求

服务模型必须考虑用于指定服务质量 (QoS) 的非功能性需求。例如，“帐户查询”服务可用性需求为 99.999%，帐户激活服务的帐户激活性能需求为在四天内激活。

指定服务消息

服务模型中的数据流通常以在服务之间流动的消息的形式表示。在确定服务规范的过程中，存在数据模型未完成的情况。要考虑有关将实现的服务的详细信息在此时间点不足够的情况。虽然如此，仍然需要考虑用于服务输入和输出的数据和消息。例如，表 2 指定了 AccountInquiry 服务的服务消息。

表 2 指定服务消息

消息段	值
服务	AccountInquiry
主题	QueryAccount
输入消息	CustomerInformation
输出消息	AccountInformation

编写状态管理决策文档

在某些情况下，服务组合需要编写状态管理文档，例如有状态、无状态、带有缓存状态的状态等等。

例如，存在流程的某些部分的状态管理可能由组合服务或其他元素控制的情况。

服务组件规范

服务规范任务的最后一部分是组件规范。孤立地执行此任务通常是非常困难的，因此实现任务通常并行地执行并且是迭代的。服务组件规范包括以下子任务：

• 确定组件属性
• 确定事件和消息
• 确定组件内部流
• 创建组件类关系图
• 面向变化的设计

可以使用 IBM Rational Software Architect，以 UML 的形式为服务组件规范任务创建若干工作产品。

服务实现

在确定并指定服务以后，需要做出有关每个组件如何实现功能的关键体系结构决策。

服务分配

在整个生命周期中以迭代的方式将服务分配到组件，以执行用于将服务分配到企业组件的服务分配。例如，帐户查询服务被分配到客户 CICS 后端系统（请参见第 12 页上的图 7）。

技术可行性探索

需要确定并评估技术约束，以确保公开候选服务在技术上是可行的，对于在现有系统分析期间确定的服务尤其是如此。通常使用技术原型来探索技术可行性。

将组件分配到各层

将组件分配到应用程序体系结构中的各个 SOA 参考体系结构层是在指定组件并编写实现决策文档之后执行的（请参见第 12 页上的图 7）。

表 3 提供了关键的服务实现决策的摘要

表 3 服务实现决策

组件	实现的服务	功能/技术组件	实现决策
客户/帐户	帐户查询	客户 重用客户 CICS 应用程序提供的现有服务	权限和策略管理 为现有的客户 CICS 应用程序创建新的帐户查询功能
	帐户激活	客户 帐单 GL 权限和策略管理	重用客户 CICS 应用程序组件提供的服务 重用现有的帐单 CICS 应用程序 重用现有的 SAP GL 应用程序

SOMA 建模环境

SOMA 建模环境（Modeling Environment，ME）提供模型、方法、IBM 工具和内容的内聚联系，以支持对用于 IBM 客户服务合作项目的 SOA 解决方案进行基于资产的开发。

业务转换分析和服务设计

注意：业务转换分析（Business Transformation Analysis，BTA）和服务设计实现使用 RUP SOMA 业务转换分析方法。

服务设计使用 IBM Rational Method Composer 包括的 RUP SOMA 方法中捕获的过程。 IBM Rational Software Architect 用于创作和重用服务设计模式和最佳实践，包括数据和部署建模以及服务组装。

Ursula 和服务设计团队成员开始进行有关如何使用 BTA 和服务设计的培训。该团队计划使用此方法为将来的 SOA 项目创建服务设计。

在“用于服务设计的 SOMA”中，我们在“帐户开立项目”的上下文中描述了 SOMA 的核心元素。在本部分，我们将重点介绍业务转换分析 (BTA) 和服务设计实现的关键元素，这些元素利用了 IBM Rational Method Composer 中包括的 RUP SOMA 方法。 BTA 和服务设计实现通过应用自动化的设计工具和流程，以改进设计一致性和缩短上市时间，从而提供正式的说明性 SOA 设计方法。

图 10 显示了核心 RUP SOMA 用例和参与者。RUP SOMA 利用了“应用基于模式的工程方法”的概念。

请注意，参与者将带模式的 BTA 和服务设计应用于执行业务转换分析用例，以及包括标识、指定和实现服务的核心 SOMA 用例。

图 10 核心 RUP SOMA 用例

图 11 显示了用于 BTA 和服务设计的扩展流程。RUP SOMA 流程步骤显示得非常粗略。更详细的信息在 IBM Rational Method Composer 包括的 RUP SOMA 方法中。

请注意数据建模、集成服务和部署建模的连锁流程。在此例中，RUP SOMA 流程使用数据建模的结果。集成服务和部署建模主要是 RUP SOMA 的后续流程。管理可重用资产是扩充所有其他流程的基础结构流程。

IBM 推出的重用管理解决方案基于 IBM Rational Asset Manager，后者用于管理和治理对任何角色和规则有利的几乎任何资产的重用。Rational Asset Manager 可以与 IBM WebSphere 集成在一起。服务注册中心和存储库支持在组织的标准资产重用流程上下文中重用和治理与服务相关的运行时资产。

图 11 BTA 和服务设计扩展流程关系图

图 12 显示了 RUP SOMA 中定义的主要活动：

• 执行业务转换分析：生成用作服务设计输入的业务和业务流程模型。
• 标识服务：发现候选服务并将其组织为层次结构以便于理解。
• 指定服务：指定服务的外部视图，并充实服务传递的消息。
• 实现服务：做出有关服务实现的决策。

RUP SOMA 流程没有充分强调可靠的需求管理在整个 SOA 设计生命周期中的作用。因此，添加了管理需求流程元素。如图 12 所示，整个生命周期中非常协调地使用了 IBM WebSphere Business Modeler、IBM Rational RequisitePro® 和 IBM Rational Software Architect。

图 12 用于 BTA 和服务设计的核心 RUP SOMA 流程

在下面的几个部分中，我们将重点介绍核心 BTA 和服务设计用例的重要参与者、方法与模式、工具和工作产品。

执行 BTA

图 13 显示了执行 BTA 流程中的主要活动。BTA 的结果是创建了描述以下内容的工作产品：

• 业务的静态结构

创建业务分析模型并执行功能区域分析的活动。

• 业务的动态特性

创建业务用例模型，并通过 WebSphere Business Modeler 业务流程实现业务用例。

BTA 活动可以产生业务体系结构的完整描述。BTA 活动还可以提供与业务相关并且是服务设计的必需输入的模型。服务设计还使用业务规则和业务目标作为服务发现的输入。BTA 还包括集中于那些构件的活动。

图 13 RUP SOMA——执行 BTA

标识服务

图 14 显示了用于标识服务的 RUP SOMA 流程。该流程依赖并行执行的子任务，这些任务用于标识候选服务。同时使用不同的方法可以极大地提高发现完整候选服务集的机会。

图 14 RUP SOMA——标识服务

指定服务

图 15 显示了用于指定服务的 RUP SOMA 流程。该流程用于定义服务的外部视图，以及用于实现服务的子系统和组件的外部视图的设计。在每个抽象级别，描述了接口、接口签名、接口协议和消息。此外，将在总体流程的此部分期间处理更细粒度的元素（例如原子服务）的编排，以实现更抽象的元素（例如组合服务的接口操作）。

在此级别的设计完成之后，可以使用产品化的 Rational Software Architect 转换来创建可供 IBM WebSphere Integration Developer 使用的项目和内容，包括描述服务接口的 WSDL 文件和描述元素（这些元素用于实现服务）执行的 BPEL。内容为集成开发人员提供了起点，此起点基于解决非功能性以及功能性需求的已架构 IT 解决方案，从而给集成开发人员带来好处。

图 15 RUP SOMA——指定服务

实现服务

图 16 显示了用于实现服务的 RUP SOMA 流程。做出有关使用哪些现有资产来实现服务的决策。

在使用新组件以实现服务的情况下，将做出有关在总体系统体系结构中的何处使用那些组件的决策。

图 16 RUP SOMA——实现服务

用于流程组合的业务服务设计

注意：用于流程组合的业务服务设计实现演示了使关键业务度量与业务目标保持一致的流程建模和模拟。

Ursula 从业务分析人员那里了解到需要对帐户验证流程进行流程改进。Ursula 使用 IBM WebSphere Business Modeler 来模拟现有的流程，然后在通过关键度量模拟来实现的流程优化基础上创建了建议的流程。

当前帐户验证流程

下面，我们将描述当前帐户验证流程（如第 26 页上的图 17 所示）。帐户协调人员检查客户申请，并研究有关多个不同系统的信息，以确定是否需要信用报告。

如果不需要信用报告，则客户申请将跳过该流程的大部分内容。如果需要信用报告，则帐户协调人员将向信用调查机构打电话或发送传真，以请求信用报告。由于通信方法（传真或电话）问题，信用调查机构没有为 JKHLE 提供针对其服务的优惠定价。获得多个信用报告非常昂贵并且耗时。

JKHLE 无法区分高风险和中等风险的客户，从而导致远高于行业平均水平的大量拒绝受理请求。最后，帐户协调人员发出了批准。批准的定价是通过参考一组复杂的纸质手册来确定的。

当前流程中存在多处流程改进余地。

• 缺乏单一客户视图和信用流程业务规则导致我们定购了超过需要的信用报告。
• 手动的信用报告检索流程高度不一致、代价昂贵并且非常耗时。
• 太多的客户请求被拒绝，导致潜在客户不愉快并导致销售代表不满。
• 虽然定价和帐户规则相当简单，但是其值更改得非常频繁。由于该过程是手动的，很难实现快速更改。

图 17 帐户验证（现有）

预期的帐户验证流程

Ursula 在 WebSphere Business Modeler 中修改了模拟的帐户验证流程来处理上述流程改进，以创建如图 18 所示的基准。接下来，Ursula 可以通过更改流程中的关键度量或值，从而试着优化该业务流程。这称为流程优化（请参见图 19）。

优化后的流程具有以下改进：

• 自动化的完整客户视图减少了需要信用报告的客户数量。
• 自动化的信用报告显著降低了成本并更加快速。
• 批准更大比例的客户请求。
• 基于规则的动态定价，可在业务需求的基础上根据需要进行更改。
• 平均持续时间变化百分比：加速 97.6%
• 加权平均利润：增加 84.7%

图 18 帐户验证（预期）


图 19 帐户验证——用于优化的流程模拟

集成开发人员 Jason Smith 根据前面的实现中描述的方法，使用指定的服务和实现的组件组装并组合了该业务流程。

总结

了解到 Ursula 已完成了帐户开立项目的设计，Sandy 非常高兴。通过与 IBM 的合作，Ursula 能够将用于服务设计的 SOMA 方法应用于帐户开立服务设计。此外，服务团队学会了如何使用 RUP SOMA 方法来为将来的 SOA 采用创建服务设计。

帐户开立服务的设计和开发团队发现，用于 SOA 设计场景的 IBM 工具集成良好并且很容易使用。诸如 IBM Rational RequisitePro、Rational Method Composer 和 Rational Software Architect 等工具提供了功能丰富的工具环境，可用于加速创建应用 IBM 方法的服务设计。使用 IBM WebSphere Business Modeler 对于业务服务设计和流程组合非常有帮助。

总而言之，帐户开立案例研究中对 SOA 设计场景使用了以下 IBM 产品：

• Rational Method Composer
• IBM Rational RequisitePro
• IBM Rational Software Architect

IBM Rational Software Architect 中包括的产品功能：

• IBM Rational Application Developer
• IBM Software Modeler
• IBM Rational Data Architect

• IBM WebSphere Business Modeler
• IBM WebSphere Integration Developer
• IBM WebSphere Studio Asset Analyzer

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/14789789/viewspace-406665/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/14789789/viewspace-406665/