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

　　领域分解

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

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

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

• 功能区域分析

　　将领域分解为功能区域可以为 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 指定服务消息

　　编写状态管理决策文档

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

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

　　服务组件规范

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

　　确定组件属性

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

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

　　服务实现

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

　　服务分配

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

　　技术可行性探索

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

　　将组件分配到各层

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

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

　　表 3 服务实现决策

　　SOMA 建模环境

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