在本系列前面的四篇文章中（请参见左上方的“本系列的更多信息”），我们使用业务分析识别满足业务目标的和业务相关的服务（“SOA 建模: 第 1 部分 服务识别”）。然后我们指定服务并使用满足 IT 目标所必须的协议（“SOA 建模: 第 2 部分 服务规范”）。接着，我们为如何提供和使用服务提供设计模型（“SOA 建模: 第 3 部分 服务实现”、“SOA 建模: 第 4 部分 服务组成”）。结果得到一个和技术无关的但是完全的体系结构服务解决方案的设计模型。在这篇收尾之作中，我们看一看如何创建一个同服务模型中被捕获的体系结构设计决定相一致的实际的实现。我们将通过进行模型驱动开发和 IBM? Rational? Software Architect UML-to-SOA 转换特性从 SOA 模型中创建一个 Web 服务，生成一个特定平台的实现。

　　本文的内容

　　前面几篇文章中的步骤创建了一个满足业务需求的完全的 SOA 解决方案模型。因此，我们知道这个解决方案体系机构完成什么需求，以及当需求变化时需要什么改变。

　　要配置和运行 Web 服务，我们需要创建一个同服务模型中被捕获的体系结构设计决定相一致的实际的实现。我们能够将该模型作为向导，通过手工来创建这个解决方案。但是这样做非常冗杂、易出错、费时间、并且需要一个高水平的开发人员确保体系结构决定能够正确的被实现。当然可以通过手工来创建解决方案，并且将该模型作为向导也是非常有帮助的。但是，一个完全的、正式的、经过验证的模型才能使我们有机会进行模型驱动的开发（MDD），从模型中创建一个解决方案的代码框架，然后在特定平台编程环境中完成细节的编码。这正是本文的内容。我们将使用 IBM? Rational? Software Architect UML-to-SOA 转化特性，创建一个能够直接在 IBM? WebSphere? Integration Developer 中实现、测试和配置的完整的 Web 服务解决方案。

　　如同本系列中的所有文章一样，我们将使用现有的 Rational 和 WebSphere 工具来建造解决方案，并且将它们链接到一起，从而我们能够检验该解决方案是否符合需求和更加有效的管理变化。表1总结了我们开发例子将使用的全部过程，以及我们所使用的工具。

　　我们首先来回顾在前面文章中被创建的服务和服务参与者。

　　服务规范、供应和使用回顾

　　图1显示了作为满足需求所需要的被识别的服务规范。这些是能够在这一业务服务需求合同中扮演角色的服务。

　　图 1. 服务拓扑结构
 
　　图2显示了服务数据的数据模型。这是服务消费者和提供者之间进行信息交换的模型，它被用来定义服务操作的参数。

　　图 2. 服务数据模型
 
　　Scheduling

　　图3显示了完全的 Scheduling 服务规范。

　　图 3. Scheduling 服务规范
 
　　由于没有使用时序安排服务的协议，该服务规范只是一个简单的接口。图4显示了提供 Scheduling 服务的一个服务提供者。

　　图 4. Productions 服务提供者
 
　　requestProductionScheduling 和 sendShippingSchedule 行为（分别为一种活动和一种行为）的实际实现，并没有在这一图表中被详细的显示，但是在模型中被定义。

　　Shipping

　　图5显示了 ShippingService 服务规范。

　
　　图 5. ShippingService 服务规范
 
　　这一服务规范稍微有些复杂，这是因为它是通过使用简单的回调风格的交互作用对运送者和订购者之间的交互作用进行建模。图6显示了提供 ShippingService 服务的服务提供者。

　　图 6. Shipper 服务提供者
 
　　requestShipping 行为是被提供的 requestShipping 操作调用运送端口上的 processSchedule 的方法。同这一端口相连接的消费者将被期望提供这一操作的一个实现来响应该需求。

　　Invoicing

　　图 7 显示了 InvoicingService 服务规范。

　　图 7. InvoicingService 服务规范
 
　　这一服务规范稍微有些复杂，它指示出使用服务功能必须遵循的一个特定的顺序。无论是消费者还是提供者都被期望遵循这一协议。用和响应。在这种情况下，一个活动被用来定义服务协议。

　　图8显示了提供 InvoicingService service 的服务提供者，以及提供服务功能的方法。

　　图 8. Invoicer 服务实现
 
　　Purchasing

　　最后，图9显示了 Purchasing 服务规范。

　　图 9. Purchasing 服务规范
 
　　服务规范反映了在初始的 Process Purchase Order 业务过程中被指定的功能性。它反映了一个从业务过程中被识别和设计的服务。

　　图10显示了提供 Purchasing 服务的服务提供者，以及它要求按照顺序完成的服务。

　　图 10. OrderProcessor 服务提供者
 
　　图11显示了使用 UML 活动进行 processPurchaseOrder 服务操作的完全的方法。

　　图 11. processPurchaseOrder 服务操作实现
 
　　这个图表同用于相同行为的 WebSphere Business Modeler 图表非常符合。InvoiceProcessing 和 ScheduleProcessing 服务操作通过过程中的 processInvoice 和 processSchedule Accept Event 行动被实现。请注意接口中的相应操作被指示为 <trigger> 操作，它指出响应 AcceptCallActions 的能力（类似于接收和 AcceptEventActions，此处触发器是一个 SignalEvent）。关键字 <trigger> 并不是 Unified Modeling Language 2 (UML 2) 的一部分；它只是用来强调这些操作是如何实现的。请注意除非 processPurchaseOrder 活动正在运行，并且控制流程已经到达两个接收呼叫行动，否则这些操作将不会被接收。这指示出一个操作的实现能够决定其他操作何时将被响应。

　　服务建模最佳实践

　　UML 2 建模通过过滤掉无关的细节，有助于提高我们对于系统本质的认识。虽然如此，建模并不是一剂包治百病的良方，有意义的模型图表仍然需要专门的技术来创建和理解。于是，很自然的提出支持一个非常通用的计算模型的需要，它能够被用于广泛的应用域和抽象级，并且反映若干个特定平台实现模型的语义。此外，行动的类型或者活动模型的风格可能需要被约束，从而允许那些模型到目标实现平台的有效转换。

　　在这种情况下，目标平台是 WebSphere Integration Developer 所支持的 Web 服务和 IBM SOA 编程模型。这包括业务目标（XSD）、接口（WSDL）、模型组装（SCDL，SCA 的一种 IBM 原型）、过程（BPEL）、SCDL（业务状态机）和 Java? 等组成元素。为了对这个特定的 Web 服务平台提供 UML 模型的转换，我们需要遵循一些服务建模的最佳实践。也就是说，我们需要首先个性化定制 UML 来对一个 SOA 解决方案体系结构建模，然后，我们需要使用一个特定的建模风格来生产可以被转换到 Web 服务的模型。

　　UML 通过使用规范被典型的定制。规范定义了许多能够通过添加属性和关系被扩展为一个或者更多的 UML 元类的模板类。规范被应用到 UML 模型中，从而使这些扩展变得可用。这些可被应用的规范通常都支持模型驱动体系结构中的两个目的：

　　首先，通常来讲，规范的使用是为了个性化定制打算被支持的抽象概念。在这种情况下，我们将 IBM Software Services 规范应用到我们的 Purchase Order Process 模型中，扩充 UML 来支持服务建模。规范中的许多模板类仅仅澄清了 UML 元类是如何被用到建模一个 SOA 解决方案，以及如何被用来限制那些能够在 UML 中被完成的模板类，从而确保 SOA 模型能够反映 SOA 原则。例如，<serviceConsumer> 模板被用来指示一个对并不实际为自己提供任何复用服务的用户进行建模的 UML 组成元素。这种组成元素可能反映一种不打算被复用的业务过程。举一个约束的例子，Software Services 规范需求所有被一个服务端口非直接控制的 <serviceProvider> 组成元素所实现和使用的接口。这样做的目的是为了通过拥有服务端口上的依赖，减少被连接用户和提供者之间的耦合性。当某些接口发生变化时，只有那个接口需要被检查来响应变化，而无需对所有被连接到该组成元素的端口都进行操作。

　　模型驱动的体系结构（MDA）中规范的第二个目的就是支持特定平台的标记。这些标记包括“组成”具有将模型转换到特定平台所必须的额外的模板和属性。例如，当一个 UML 包需要被转换到一个 Web 服务容器时，它可能需要一个指定的 Uniform Resource Identifier (URI)。

　　有时，规范的这两个目的被结合在一起。例如，支持相关数据建模的 UML 的扩展，由一个既为实体相关属性（ERA）数据建模扩充 UML，又提供必要的标记来将 UML 域模型转换到 IBM? Rational? Data Architect 逻辑数据模型 (LDMs) 的规范组成。IBM Software Services 规范为那些被转换到 Web 服务的模型提供了这种双重角色。

　　在其他情况下，当一个规范被用来驱动转换的同时，另一个规范能够被用作建模支持。例如，SOA 建模设计将在 Java? 2 Platform, Enterprise Edition (J2EE) 中被实现。后者能够通过将 Software Services 规范和 Enterprise Java?Beans (EJB) 转换规范应用到同一个模型上得到援助。当 EJB 转换规范模板将被应用到模型元素上来指导 Rational Software Architect UML-to-EJB 转换的实现的同时，Software Services 规范模板将被应用到模型元素上来支持服务建模。当然，同一个 SOA 模型也能够通过使用 Rational Software Architect UML-to-SOA 转换工具被转换到 Web 服务。UML-to-SOA 转换将通过切断 Software Service 规范来产生 Web 服务。它将忽略用于 EJB 转换的标记。

　　下一小节将描述一些 SOA 模型转换到 Web 服务的建模的最佳实践，尤其是像在 IBM SOA 编程模型 中被实现的 Web 服务，以及被 WebSphere Integration Developer 所支持的服务。

　　数据建模

　　服务操作参数的类型应当或者是一个原始类型，或者是一个 <message> DataType。建模器应当既不考虑数据的位置、是值呼叫还是引用呼叫语义，也不考虑任何并发管理工具。假定服务实现工作在一个可能已经被从其最初源转移或者转换的数据的瞬时副本上。这样做确保了服务使用者和服务提供者之间最小程度的数据耦合性。

　　服务建模

　　如同 IBM Software Services 规范中所指定的那样，服务提供者组成元素必须通过服务端口，间接的实现或者使用所有接口。这样做确保了被连接到该组成元素的服务消费者和提供者之间适当的去耦合性。

　　活动建模

　　一个具体的服务提供者通过为每一项操作提供一个行为来对它的服务操作进行方法建模。

　　注释：

　　一个具体的服务提供者是一个既不抽象也不 <specification> 的组成元素。

　　任何行为都可能被使用，但是如果模型目标平台是 Web 服务，那么就能够很方便的使用一个容易被转换到 WebSphere-BPEL 的活动。图11所显示的活动模型是 Order Processor 服务提供者组成元素的一个自有行为，该组成元素是 processPurchaseOrder 操作的方法。关于这个活动，有如下一些事需要进一步的解释：

　　方法行为的签名必须同它的规范操作相匹配。
　　行动的输入和输出插口被规定从包含行动的右下角开始，并且按照顺时针的方向进行处理。这一插口顺序符合被呼叫操作的参数的顺序：目标输入插口作为第一个插口，并且操作的类型作为最后一个输出插口。目标输入插口反映了行动要求发送的那个目标对象（例如，拥有操作的分类器）。
　　输入和输出插口类型通常并不被设置，这是因为这些类型能够从相应的参数中被获得。
　　这个活动并不使用对象流程来指定图表的创建。相反，行动的输入和输出插口的名称被上下文分类器（拥有该活动的类）的参数、变量或者结构特性进行标注。UML 2 对其中任何一种都提供支持。
　　活动的参数节点（位于活动的左侧或右侧边缘）没有被使用。相反，活动的参数节点（必须同其规范操作的参数相一致）根据需要被直接引用到输入和输出插口上。如果对象流程被使用的话，这些活动参数节点就将被使用。
　　设置活动分区来反映包含该活动的组成元素的各个服务端口或者部分。。所有请求和事件都通过这些部分被接收。在这个例子中并没有指定分区的名称，这是因为被反映的性质提供了识别分区的足够信息。
　　呼叫操作行动的目标输入插口不需要被设置。活动分区反映了调用该分区中呼叫的那个服务端口。在 UML 2 中，这些被称为 <instance> 的分区具有定义良好的语义。目标输入插口也能够被定义，但是这样做是多余的。
　　Accept Call 行动的 returnInformation 插口同呼叫操作行动的目标输入插口处理相同的事物。它也是有活动分区表现的端口，它表现了交互作用点，通过这个点呼叫将被接受。
　　分配公式通过不透明行动被显示，在那里行动的名称包括一个反映参考变量、参数、结构特性的分配公式。分配声明中的 lvalue 和 rvalue 以 := （冒号加等号）被隔开。
　　对象和控制流程的表达式是活动范围内参考变量、参数和结构特性的 Java 或者 XPath Boolean 表达式。
　　对象流程中的 数据 被流程的名称所引用。
　　对象流程中的 类型 被它的源所决定。
　　这些约定被用来使得活动建模简单化、指定活动图表、更好的符合将要从它们中被生成的 BPEL。

　　转变为 Web 服务

　　转换需要使用一个转换配置。

　　配置该转换

　　您能够通过选择 File > New > Other > Transform Configuration 创建一个转换（参见图12）。

　　图 12. 创建一个新的转换配置
 
　　在这个例子中，我们将使用一个 UML-to-SOA 转换，如图13所示。

　　图 13. 选择 UML-to-SOA 转换
 
　　大多数转换的配置都包括以下三个基本部分：

　　选择转换源元素
　　选择（或者先创建再选择）目标元素
　　配置转换属性
　　可允许的源元素通过选中特定的转换被定义。通常来说，最好的实践是转换整个模型，而不是转换模型的各个部分。这样做确保了反映单个资源的模型被当作关于模型转换的编辑单元来对待。这一简单化的模型管理和转换依赖通过确保工作区中资源的变化同建造器和转换增量相一致，从而确保它们同源元素同步。例如，您不会想选择 Java 类中的一个方法并且只编译那个方法，然后将它插入到这个类其余部分的字节代码中。在快速变化的环境中，不可能这样管理。它将要求您而不是建造器和编译器，了解变化所导致的需要被编译的所有依赖。

　　在这个例子中，PurchaseOrderProcess 模型是源，我们为目标创建了一个新的、简单的 Eclipse 项目。所有被转换的模型元素都被放置在这个项目中（参见图14）。

　　图 14. 配置转换源和目标
 
　　转换配置参数反映了转换选项，这些选项对于模型中的标注来说通常并不适当。典型的情况是，这些控制了全部选项，而不是那些适用于某一个特定模型元素的选项。UML-to-SOA 转换只具有一些转换选项，如图15所示。

　　图 15. 配置转换属性
 
　　处理 UML 而不将模板设置为 True 意味着 IBM Software Services 规范实际上被选中。数据类型、组成元素和活动被转换到 Web 服务解决方案，而不需要 <消息>、<服务> 或者 <serviceProvider>，或者模板被留在并不需要额外属性的特定模型元素中。

　　至此，完成了 PurchaseOrderProcess 模型到 Web 服务解决方案的转换的配置，它将被放置在 PurchaseOrderProcessWorkspace 项目中。

　　运行该转换

　　实现 PurchaseOrderProcess2WebServices 转换十分简单：

　　选择前面小节中所创建的 PurchaseOrderProcess2WebServices.tc 转换配置文件。

　　从弹出菜单中，选择 Transform > UML-to-SOA。

　　在转换配置中被选择的转换已经被实现，因此将源模型转换到 Web 服务中，并且将结果放置在 PurchaseOrderProcessWorkspace 项目里。

　　贴士：

　　如果模型发生变化，那么您将需要重新运行这个转换。

　　转换的结果如图16所示，它使用 Project Explorer 中的 Modeling 透视图。

　　图 16. 转换结果
 
　　检查结果

　　UML-to-SOA 转换配置需要一个目标项目，所有获得的成果都被放置在这个目标项目中。这个项目是一个简单的 Eclipse 项目，它包含一个 WebSphere Integration Developer 库或者模型项目，具体情况如下所述。

　　library 项目包含业务对象、接口以及同其他项目共享的模型导出。
　　module 项目包含 UML 服务模型中用于每一个服务提供者的模型实现。
　　您可以将这些项目导入到您的 WebSphere Integration Developer 工作区中。或者，您可以将目标项目作为一个工作区来使用，这个工作区包含了为和 SOA 模型相关的一组 UML-to-SOA 转换而生成的所有项目。

　　启动 WebSphere Integration Developer 并且选择目标文件夹作为您的工作区。
　　然后导入那个文件夹中的所有项目到工作区中。
　　贴士：
　　您可能发现直到所有项目被导入之后再关闭 Automatic Build 对于提高导入的速度会很有用。

　　模型和库

　　在转换配置选中的源中的每一个模型，都将以该模型的名字被转换到 WebSphere Integration Developer 库中。这个库包含一个为源模型中每一个类和数据类型所用的 XSD 元素，和一个为每一个 UML 接口所用的 WSDL 定义。这些库定义了业务对象和接口，转换配置选中的源中生成的所有 WebSphere 模型都是用了这些对象和接口。

　　图17显示了 WebSphere Integration Developer 中导入生成的库和模型项目，并且通过展开 PurchaseOrderProcess 来显示生成的业务对象和接口。请注意 WebSphere 中的文件夹和名称空间直接符合 UML 服务模型中的包结构。这样做确保了跨资源和工具的名称空间管理和复用支持的一致性。

　　图 17. ProcessPurchaseOrder 库及其业务目标和接口
 
　　我们深入观察一下业务对象和接口，并且通过它们的 UML 源元素进行比较。图18使用在 PurchaseOrder 业务对象上打开的 WebSphere Integration Developer Business Object 编辑器，显示来自图2中所示的服务数据模型所生成的 XSD。您将看到，XSD 同它们的源 <消息> 数据类型非常符合。点击该图查看生成的源。

　　图 18. 从服务数据模型中生成的 XSDs
 
　　每一个 UML 接口都被转换为一个 WSDL portType。为图7中的 Invoicing 接口而生成的 WSDL 如图19所示。点击该图查看生成的 WSDL 源。再次强调，WSDL 同 UML 接口非常相似。

　　图 19. 为 Invoicing 接口生成的 WSDL
 
　　组成元素和模型组装

　　UML 服务模型中的每一个服务提供者组成元素都被转换到 WebSphere Integration Developer 模型中。目前尚没有用于集合服务使用者（消费者）和提供者的 Web 服务标准。因此，WebSphere Integration Developer Version 6.0.2 使用一个工具，服务组件体系结构 (Service Component Architecture, SCA) 的早期版本。模型组装是被捕获的 .component 文件，它们使用 Service Component Description Language (SCDL)——一种用于 SCA 的 XML 标记语言。一些公司正准备协作开发 SCA 的标准。更多信息请参见 Open SOA 网站。

　　UML-to-SOA 转换为一个服务提供者元素的最大化复用创建了 WebSphere Integration Developer 模型。SCA 模型不能从其他模型中被组合。然而，它们能够从其他模型中导入服务，并且直接使用它们。因此，UML 中服务消费者和提供者之间的连接就如同 WebSphere Integration Developer 中的模型导入和导出之间的绑定一样。例如，Invoicer 服务提供者如图8所示。

　　图20显示了相应的 WebSphere Integration Developer 模型组装。模型导入和导出是为每一个服务端口所创建的。SCA 不能够同时支持用于同一个交互作用点的被提供和被需求的接口，因此为提供和需求接口的服务端口分别创建导入和导出元素。invoicingExport 服务到处被提供的 Invoicing 接口；而 invoicingImport 导入被需求的 Invoicer 服务提供者的货品计价服务端口的 InvoiceProcessing 接口。

　　图 20. Invoicer 模型组装
 
　　请注意模型的名称。模型是一个 Eclipse 项目，但是由于模型是一个可复用元素，所以它必须像其它可复用元素一样对名称冲突进行管理。UML-to-SOA 装换所使用的约定，是为了创建基于服务提供者组成元素的有完全资格名称的模型项目的名称，由它所包含的包决定。这样做导致了很长的模型名称，可能会由于 URL 长度的限制引起 Windows 平台上的运行问题。这些模型名称能够很容易的被重新制作为满足其复用上下文环境管理的短长度的名称。

　　Productions 组成元素导致另一个模型组装，如图21所示。这个模型没有导入，这是因为服务端口不需要任何接口。

　　图 21. Productions 模型组装
 
　　这些模型都使用 BPEL 过程来实际实现相应的服务提供者组成元素所提供的服务。详细操作细节请参见下一小节。

　　查看图22中之前为 OrderProcessor 组成元素所创建的模型组装，如图10所示。

　　图 22. OrderProcessor 模型组装
 
　　OrderProcessor 服务提供者提供了购买服务，并具有对货品计价、时间表和货运服务的请求。与图10中的消费者和提供者组成元素相连接的服务信道，被作为绑定到相应的服务提供者导出的 OrderProcessor 模型中的导入来实现。这样做允许在 WebSphere Integration Developer 中有效的模块复用，并且保持 UML 服务模型独立于 SCA 的演变。当 SCA 被标准化时，UML 服务模型必须要改变；只有转换需要被更新。

　　Activities 和 BPEL 过程

　　由服务提供者所提供的每一项功能（操作）都必须以某种形式被实现。这种实现或者是在 UML 中通过使用每一项操作的行为被设计，或者是其他一些行为的 Accept Call 行动。后一种方法通过允许提供者决定合适希望并且能够响应一个请求，而不是当操作被服务使用者调用时必须立即响应，提供了使用者和提供者之间额外的去耦合性。

　　WebSphere Integration Developer SCA 采用了一种不同的方法。每一个导出必须被连接到为那个接口中的操作提供实现的集合中的组成元素。SCA 中的每一个组成元素都拥有如下实现类型：

　　Human Task
　　Java
　　Process
　　Rules Group
　　State Machine

　　图10和图22中的 OrderProcessor 服务提供者，通过它的购买服务提供了一中单一功能。这项操作的实现是 UML 服务模型中的一个活动。UML-to-SOA 转换从哪项活动中创建了一个 BPEL 过程，并且将它作为扩展操作的实现来使用。

　　图 23. OrderProcessor 过程组成元素实现
 
　　请注意，图23中的 BPEL 过程同图11中的活动非常相似。UML 活动如何被转换到一个 BPEL 过程中的详细细节，可以查阅 Rational Software Architect 中的 Help 小节。

　　减少接口和实现的耦合性

　　正如前面所描述的那样，WebSphere Integration Developer SCA 通过写一个导出来实现被提供的功能，这个导出将接口提供给一个实现被提供操作的组成元素。因为每个组成元素都拥有一个实现类型，所以导出的所有结构所提供的所有操作都必须以同样的方式被实现。这就将实现类型同一个导出的所有接口连接起来。（一个导出可以被连接到一个组成元素，或者被一个组成元素实现。）如果开发者希望改变一个特定操作的实现类型（例如，从一个人工任务到 Java 中的一个自动服务实现），那么接口就必须被重做以允许不同的导出被连接到不同的组成元素实现类型上。依次的，这需要那些接口的所有用户作出相应的改变。这种接口设计到实现类型的耦合性，可能约束 SOA 解决方案所要支持的业务敏捷性。

　　UML 没有这个规范和实现耦合性。每一项被提供的操作都能够拥有一个方法行为：活动、交互作用、状态机、或者不透明行为（代码）。建模器独立的设计了每一项操作的实现。这将导致图4中所显示的情况：同一个服务提供者组成元素，为通过同一个接口所提供的不同操作，使用不同的行为类型。我们需要某种方式将这些服务提供者转换到 Web 服务。

　　还有一个因素需要考虑。在 UML 中，组成元素是被实例化的，而不是它们所拥有的行为。因此，实例辨认和生命周期对于同一个组成元素中的所有行为都是一样的。除此之外，该组成元素为其所拥有的所有行为建立了一个上下文环境或者范围，从而允许那些行为分享访问组成元素状态（属性和端口）。因此，当被转换到 Web 服务时，我们必须能够管理这个能够实现 UML 语义的识别、周期和分享状态。这就是 Business Process &#101xecution Language (BPEL) 过程进入的地方（请参见 参考资源 获得更多关于 BPEL 的内容）。

　　我们并不创建一个实现模型组装中服务提供者的每一项行为的分离的 SCA 组成元素，相反，我们创建一个符合组成元素自身的单一的 BPEL 过程。您将注意到图23中 BPEL 过程的名称是 OrderProcessor ，这同 OrderProcessor 服务提供者相同，而不是被提供操作的名称 processPurchaseOrder。

　　我们仔细查看一下图4，看一看 Productions 组成元素是如何被转换到 WebSphere Integration Developer Web 服务的。请注意用于 requestProductionScheduling 的实现设计使用了一个 Activity （细节并未显示），但是 sendShippingSchedule 通过 Java 代码中提供的实现使用了一个 OpaqueBehavior。用于这一服务提供者的模型组装被显示在图21中，而 Productions Process 组成元素被显示在图24中。

　　图 24. Productions 服务提供者实现
 
　　BPEL 过程是为 Productions 服务提供者组成元素而被创建的。服务提供者的身份属性被用来定义 Invoke、Receive 和 Reply 活动之间的相互关系。该组成部分所提供的每一项操作都被这个过程的一个片段所实现。该过程首先挑选那些被用来分派每一项操作需求的元素。然后，为每一项为 UML 行为中定义的变量提供位置的操作创建一个范围。这个范围包括被转换的行为的结果。如果行为是一个 UML Activity，那么该范围将包括从那个活动中被生成的 BPEL。如果行为是一个 Java 语言的 OpaqueBehavior，那么该行为的主体就被拷贝到这一范围中的 Java 剪断的活动之中。如果行为是一个 HTML 或者 Java?Server Pages (JSP) 语言的 OpaqueBehavior，那么 Human Task 活动将被添加到这个范围之中。

　　这提供了接口及其实现之间完全的去耦合性。例如，如果建模者或者开发者决定从一个自动的 Java 服务的人工任务中改变一个服务操作实现，那么只需改变那个操作的范围中的人工任务元素。客户端将不会注意到实现已经被改变，它们只会注意到服务运行的更快了，并且不需要做过多的操作。

　　人们普遍认为这有些复杂，就像当 SCA 已经定型后再作出改变一样。但是去耦合性、关注的分割、复用和敏捷的解决方案是 SOA 的基础，并使得它们并不总是那么容易。

　　完成解决方案

　　UML-to-SOA 转换并不产生完全的解决方案（至少现在如此）。这是因为将实现细节放到模型中的努力，将会比通过使用为此目的而创建的编辑器将它们放到特定平台上更加困难。这些也是没有被转换到 BPEL 的 UML 2 Activities 的一些特性。这些将被添加到未来发布的版本中。Rational Software Architec 中的 Help 中将提供在一个特定版本中将支持哪些功能的详细说明。

　　典型的，WebSphere Integration Developer 将必须完成某些或者是下列所有的开发活动。

　　如果在模型中没有提供用于不透明行为的 Java 代码，则添加之。即使 Java 代码在不透明行为的主体中被提供，它也是易于出错的，这是因为 Content Assist 和 Java 编译（目前）还没有同 Rational Software Architect 的建模功能集成在一起。

　　为业务过程添加相关性。相关性指定了识别一个组成元素的实例所需要的信息，并且它尚不被 UML-to-SOA 转换所支持。它将在将来发布的版本中被支持。

　　为人工任务创建一个用户接口（UI）。UML 建模器可能包括一个不透明操作的主体中的 JSP 或者 HTML。但是，如同 Java 源代码一样，这可能是不完全和不正确的。集成的开发器将希望使用 Human Task 编辑器、Page Designer、入口、或者其他工具来创建正确查看和感觉来完成应用程序 UI 的完全的人工任务。

　　配置监控器模型。当前，UML-to-SOA 转换并不创建任何监控器信息来评价业务 Key Performance Indicators (KPIs)，这些 KPI 可能已经作为服务和服务提供者的约束被进行建模了。集成开发器能够在 WebSphere Integration Developer 中使用 Monitor Model Editor 工具，配置那些被收集起来用于仿真更新和业务测量的数据。

　　本系列总结

　　我们总结了在 Rational Software Architect 中使用 IBM Software Services 规范的服务建模（请参见左上方的 More in this series）。第一篇文章，SOA 建模: 第 1 部分 服务识别，介绍了如何使用业务过程模型和服务协作，为一组服务应当如何被连接和设计从而实现某些目标指定需求合同。这些服务合同往往被用来指定什么必须被完成，从而达到目标。然后服务协作能够在识别那些提供真正业务价值的服务中发挥作用。

　　SOA 建模: 第 2 部分 服务规范，显示了如何从提供者的角度对一个服务规范的细节进行建模。服务规范为潜在消费者决定一个服务是否适用于它们的问题，以及如果适合的话如何真正使用它，定义了必要的信息。服务规范还定义了一个服务的提供者要实现该服务都需要做什么。

　　SOA 建模: 第 3 部分 服务实现 和 SOA 建模: 第 4 部分 服务组成，显示了如何设计和建模提供或者需求服务的组成元素，以及该服务操作是如何被实现的。它们还描述了服务提供者如何指示出它们完成的将服务提供者链接回到业务目标、过程和需求的合同。

　　最后一篇文章描述了如何在 IBM WebSphere Integration Developer 所提供的 Web 服务平台上，通过使用 IBM UML-to-SOA 转换来实现服务。WebSphere Integration Developer 支持一个 SOA 编程模型，该模型同在 Rational Software Architect 中捕获的服务辨认、规范和实现设计相一致。通过使用 WebSphere Integration Developer，您能够完成服务编程，然后为人工任务、运行测试和配置您的 SOA 解决方案产生一个 UI。

　　关于作者

　　Jim Amsden 是一名 IBM 的高级技术人员 (Senior Technical Staff Member)，在应用程序设计和开发以及软件开发行业工具方面有二十多年的经验。他持有波士顿大学的计算机科学硕士学位。他的兴趣点包括基于契约的开发，代理编程，业务驱动开发，J2EE UML，以及面向服务架构方面。他也是 “Enterprise Java Programming with IBM WebSphere” 一书的合著者。他目前关注于如何集成工具以更好地支持敏捷开发过程。