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中的业务过程的一部分。在此视图中，该过程显示了许多泳道，每个泳道表示一个参与过程的特殊角色。

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

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

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

　　图3. 显示了与用例、接口和活动的关系的Customer Order Handling业务过程的UML协作
 
　　提示：

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

　　图4. Rational Software Architect中的WebSphere Business Modeler模型的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工程为有效的目标。

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

　　图6. 指定转换源
 
　　转换所生成的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业务过程和相关的服务模型的约定验证。

　　图7. 组合结构图的实例
 
　　表示服务的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所示。

　　表1. 转换映射

　　选择过程分解

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

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

　　图8. 使用转换配置为每个业务过程指定分解类型
 
　　如图9所示，默认的Implementation扩展在由业务分析模型克隆来的活动元素描述行为的地方生成分解。

　　图9. Default Implementation扩展
 
　　注意：

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

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

　　图10. Skeleton Only扩展创建的SCDL分解
 
　　要创建包含了对于其他领域的实现细节的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部分向您提供了一个逐步的实例，讲述了为了将业务过程转换为服务模型而创建定制的过程分解的方法。它面向熟悉撰写转换扩展的读者。