IBM® Rational® Software Architect 提供当您为您的软件开发面向服务的体系结构（Service-Oriented Architecture，SOA）时，使用 UML 来对 SOA 解决方案建模的必要工具。本系列四篇文章探究了这一 SOA 转换功能。本文说明了如何利用 IBM® WebSphere® Business Modeler 和 Rational Software Architect 来将业务过程转换为 SOA 模型。

业务过程分析模型的概述

典型的开发周期从获取和分析商业需求和目的开始。分析工作包括确定出创建满足商业需求的面向服务的体系结构（Service-Oriented Architecture，SOA）所必需的核心服务。

商业需求的分析任务一般落到业务分析人员身上，他们通常使用 IBM® WebSphere® Business Modeler 来创建 Business Analysis model（业务分析模型） （也称为 Service Specification model），并且利用 WebSphere 软件内嵌的分析和模拟功能来精炼、扩展，或优化该模型。该分析阶段的最终产品是定义了核心服务（商业过程）、它们如何交互，以及参与者或其他服务如何调用它们的模型。

您可以在 Jim Amsden 所写的“SOA 建模”（参见 参考资料）系列中的文章“SOA 建模：服务规范”中找到服务规范建模的详细概述。

将业务过程转换为高层架构

周期的下一个步骤是将 Business Analysis（业务分析）模型转变为 Design Solution Architecture （设计解决方案架构）模型。这是一般由软件架构师执行的任务。IBM® Rational® Software Architect 的 Business Process-to-Service Model 转换特性有助于该转变。

您可以在用 WebSphere Business Modeler Integration 特性配置的 Rational Software Architect 工作平台中使用 WebSphere Business Analysis 模型工程。当您打开它时，该软件生成一个您可用作业务操作需求建模的基础的业务模型的内存中的 UML 表示。

通过反映业务过程的基于角色的视图，将来自 WebSphere Business Modeler 的 Business Analysis 模型转变为 UML 表示。换句话说，您可以将业务过程看作是任务所需的角色和过程中涉及的服务之间的协作。您可以将每个所需要的角色看作是为每个任务定义操作及任务所负责的 WebSphere Business Modeler 服务的 UML 接口。图 1 展示了描述如何处理交易中的客户订单的 WebSphere Business Modeler 中的业务过程的一部分。在此视图中，该过程显示了许多泳道，每个泳道表示一个参与过程的特殊角色。

业务过程的 UML 表示包括代表每个过程的 UML 用例，以及对于参与用例的每个角色的参与者（Actor）。该表示在最高的抽象层次上展示了角色和过程之间的关系，这适用于概括了解业务过程。图 2 展示了 Customer Order Handling 业务过程的用例和参与者（Actor）。

下面的图 3 显示了表示相同过程的 UML 协作，以及其与表示所需的角色和过程的 UML 用例的 UML 接口的关系。在下面的图中，注意，图 1 显示的获取 CRMApplication 角色（举例来说，Determine Requester Status）的任务已经被转化为 CRMApplication UML Interface 中的操作了（参见 图 3）。

除了用例和协作之外，业务过程的行为方面（换句话说，在任务执行过程中，角色之间如何交互）被表示为协作所拥有的 UML 活动（UML Activity）。就像在前面介绍的角色接口中定义的一样，每个来自原始业务过程的任务都由调用适当操作的 UML Call Operation 行为来表示。任务之间的流，以及控制节点（决策、分叉、合并，等等）也在 UML 活动（UML Activity）中表示。协作展示了哪些角色一起定义过程，而活动（Activity）指定这些角色互相如何交互。活动中的划分表示协作中的角色。该 UML 模型实质上定义了什么是定义了任何实现了业务过程的解决方案模型都必须满足的结构和行为需求的规范。

提示：
参见参考资料中 Jim Amsden 所写的 SOA 建模系列中的商业服务建模的文章，更彻底地讨论 WebSphere Business Modeler Business Analysis 模型的元素和 UML 副本的元素之间的关系。

WebSphere Business Modeler 中的模型的 UML 表示被看作由构架的解决方案模型所实现的需求约定。Rational Software Architect 中的 Business Process-to-Service Model SOA 转换特性的目的是创建初始、或默认的 SOA 解决方案模型。

要创建并配置这一转换，在 Modeling 透视图（参见图 5）中选择 Modeling > Transform > Create new configuration 菜单。该转换将接受 WebSphere Business Modeler 中打开的模型为有效的源，并且接受任意的 Eclipse 工程为有效的目标。

图 6 显示了一个单独的 WebSphere Business Modeler 模型和一个目标，该目标可以是您想要将转换所生成的输出放入的任意的 Eclipse 工程或文件夹。

转换所生成的 UML 服务模型表示从每个业务过程的分析模型而来的服务分解。您可以在转换 UI 中配置分解的类型，并且将其应用于个别的业务过程。分解的结构依赖于目标领域（实现语言、部署环境，等等）。

每个服务的分解将由扩展生成。虽然转换伴随三个扩展，但是不限于这三个（高层次的 UML，一般的 SCDL 分解，和 Do Not Transform 的空的实现）。转换是可扩展的，并且允许客户创建并添加自定义的扩展。在本文后面部分中我们将详细地观察每个默认的扩展。

当转换生成模型之后，系统或软件架构师可以进一步精炼服务模型，指定更多的实现细节或者创建对于其他服务或遗留库的引用，从而用于复用。

需求回溯的约定验证

不管是什么具体的分解，转换所生成的构架的解决方案模型（也称为 服务模型，或约定实现模型）保存着规范模型定义的约定信息。它还提供履行约定所需的实现细节。

规范模型中的业务过程是由 UML Collaboration 元素表示的。来自规范模型的 UML Collaboration 元素被转换为构架的解决方案模型中的 UML Component 元素。转换利用为业务过程所需或提供的服务指定接口的端口来填充所生成的组件。

另外，转换在每个组件中生成 CollaborationUse 元素。CollaborationUse 元素维护着一个规范模型中的原始 Collaboration 元素和服务模型中的 Component 元素之间的链接。转换创建组件端口和协作角色之间的 UML 绑定。通过 CollaborationUse 元素建立的端口和角色绑定定义了在服务软件中部分地执行了约定需求中的角色。这使得实现了解决方案及其实现的业务需求之间的可溯性，以及验证解决方案实际地满足 WebSphere Business Modeler 业务模型所表示的业务需求的方法。

考虑图 7 中的实例，哪一个描述了 Customer Order Handling 业务过程和相关的服务模型的约定验证。

表示服务的 Customer Order Handling 组件包含了拥有 Collaboration 类型的 CollaborationUse 元素，它指向 WebSphere Business Modeler 中创建的 Business Analysis 模型中定义的 Customer Order Handling Collaboration 元素。Customer Order Handling Collaboration 角色由组件端口扮演（绑定到组件端口）。如 Business Analysis 模型中所概括的，每个端口指定该业务过程所提供或需要的接口。举例来说：提供到服务（myRole）的接口的端口绑定到 Collaboration 角色上，这表示业务过程本身。表示各种参与者的其他端口（可能是其他服务）绑定到 Collaboration 元素中它们各自的角色上。这些端口（举例来说，PaymentHandling、OrderVerification、CRMApplication，等等）需要接口来与有关的参与者进行通信。所需的和所提供的接口都定义在 WebSphere Business Analysis 模型中，Rational Software Architect 中的服务模型指回那些接口，如表 1 所示。

选择过程分解

业务过程到服务模型的转换提供对于转换在规范模型中的业务过程的扩展。

如 UML Componet 所表示的（参见图 8），Default Implementation 分解通过将 UML 活动分配为业务过程自身拥有的行为来描述过程的行为。该分解随后可以被 UML-to-SOA 转换所使用，以生成带有 Business Process Execution Language（BPEL）工件的 Services Component Definition Language（SCDL）模块。

如图 9 所示，默认的 Implementation 扩展在由业务分析模型克隆来的活动元素描述行为的地方生成分解。

注意：
在您不想要考虑转换的确定过程的情况下选择 Do Not Transform 选项。该扩展仅仅意味着“忽略此过程”。

Skeleton Only 实现将行为转换为结构，为 Services Component Definition Language 创建了一般的分解（参见图 9）。为了在调用角色分别的参与者（可能是另一个服务）之前执行任意的预处理（举例来说，例如获得代理），它为每个 Collaboration 角色生成内部的组件。像这样的模型可以由 UML-to-SOA 转换用来生成输出，这可以由 IBM® WebSphere® Integration Developer 来部署。

要创建包含了对于其他领域的实现细节的 UML 服务模型，客户可以为 Business Process-to-Service Model 转换创建并注册自定义的扩展。

本系列中的下一篇文章“向 SOA 的转换：第 2 部分. 为 IBM Rational Software Architect 中的 Business Process-to-Service Model 转换特性创建定制的扩展”将介绍创建定制的分解的实例（参见目录表上面的 More in this series）。

第 2 部分包含什么

本文着重于将 WebSphere Business Modeler 工件集成到 Rational Software Architect 环境中，以及用来创建业务模型和软件分析及设计模型之间的桥梁的工具。第 2 部分向您提供了一个逐步的实例，讲述了为了将业务过程转换为服务模型而创建定制的过程分解的方法。它面向熟悉撰写转换扩展的读者。

参考资料

• 您可以参阅本文在 develperWorks 全球网站上的 英文原文。
• 本系列的第 2 部分，向 SOA 转型，第 2 部分: 在 IBM Rational Software Architect 中为 Business Process-to-Service Model 转换特性创建一个自定义扩展。
• 本系列的第 3 部分：向 SOA 转型，第 3 部分：从 UML 到 SOA。
• 要了解更多有用的信息，请阅读 Jim Amsden 所写的有关基于面向服务的体系结构（Service-Oriented Architecture，SOA）开发软件的五篇系列文章：
  • SOA 建模，第 1 部分: 服务识别。介绍了如何利用由 IBM Software Service Profile 扩展的 UML 模型设计与商业需求有联系的 SOA 解决方案，但独立于解决方案实现。作者介绍了商业目的和目标，以及满足那些目标的商业过程，然后介绍了如何使用这些过程来确定执行服务所表示的需求所必需的业务相关的服务。
  • SOA 建模，第 2 部分: 服务规范。作者通过详细地对每个服务的规范进行建模来继续定义 SOA 解决方案。这些规范将定义服务的消费者和生产者之间的约定。这些约定包括所提供的和所需要的接口，在服务规范中那些接口所扮演的角色，以及那些角色如何交互的规则或协议。
  • SOA 建模，第 3 部分: 服务实现。第三篇文章介绍了如何实际地实现基于 SOA 的 Web 服务。服务实现决定什么组件将提供什么服务。该决策在服务可用性、分布、安全性、事务范围，和耦合方面有重要的含意。在制定了这些决策之后，您可以对如何实现每个服务的功能，以及如何实际地使用所需的服务进行建模。然后您可以使用 IBM Rational Software Architect 中包含的 UML 到 SOA 的转换特性来创建可以用于 IBM WebSphere Integration Developer 中实现、测试、和部署已完成的解决方案的 Web 服务实现。
  • SOA 建模，第 4 部分: 服务合成。第四篇文章介绍了如何汇集并连接“第 3 部分. 服务实现”中建模的服务提供者，并编排它们的交互来提供针对商业需求的完整解决方案。结果的组件将成为组成 Invoicer、Productions，和 Shipper 组件所提供的，用来提供处理订购单的服务功能的服务的服务参与者。它还介绍了该服务参与者如何实现原始的商业需求。
  • SOA 建模，第 5 部分: 服务实现。在这系列的最后一篇文章中，作者介绍了如何创建一个与服务模型中所获取的架构和设计决策相一致的实际的实现。我们将通过利用模型驱动的开发和 IBM Rational Software Architect UML-to-SOA 的转换特性来由 SOA 模型创建 Web 服务来生成具体平台的实现。
• 浏览 developerWorks 上的 SOA 和 Web 服务专区，获得提高您在面向服务体系结构方面的技能所需的资源。
• 访问 IBM.com 上的 IBM Service- Oriented Architecture (SOA) Solutions 页面。
• 访问 developerWorks 上的 Rational 软件专区，获得用于 Rational Software Delivery Platform 产品的技术资料和最佳实践。
• 订阅 developerWorks Rational 专区通讯。关注 developerWorks Rational 内容。每两周您将收到关于 Rational 软件交付平台（Rational Software Delivery Platform）的最新的技术资料和最佳实践的更新。
• 订阅 Rational Edge 时事通讯，获得关于有效的软件开发背后的概念的文章。
• 浏览技术书店获得关于这些和其它技术主题的书籍。

• 下载 IBM Rational Software Architect，Version 7 的试用版。
• 下载 IBM 产品评估版并着手于来自 DB2®、Lotus®、Rational®、Tivoli®，和 WebSphere® 的应用程序开发工具和中间件产品。

• 查看 developerWorks blogs 并加入 developerWorks 社区。
• Rational Software Architect、Data Architect、Software Modeler、Application Developer 和 Web Developer 论坛：询问关于 Rational Software Architect 的问题。