使用面向服务体系架构建模语言（SoaML）建模，第 4 部分 服务组合.docxVIP

在本文中，我们组合了以前所创建的服务参与者，在第三篇中，我们使用其他参与者的功能。这就是说，我们将会从其他的服务的组合或者组合当中创建一个新的服务。这种服务组合的技术可以重复地使用无限次，不管您的关注点是什么，也不管抽象的层次如何。但是，可能会有结构上的限制因素，影响到服务操作、安全和性能关注、数据交换容量、线性层次交互协议和绑定问题的整体性，它们可能会限制什么构件提供什么服务。这个问题决定了方案的结构，并超出了本文的讨论范围。本系列所有的文章有一个共同点，那就是我们使用已存在的 IBM? Rational? 工具来构建方案工件并将它们再一次联系起来，这样我们就可以根据需求确认方案的可执行性，并更加有效地管理变更。另外，我们通过向 IBM Rational Software Architect 中的 UML 模型添加对象管理组面向服务架构建模语言（OMG SoaML）概述，来为服务建模扩展统一建模语言（UML）。表 1 提供了一个总结，关于我们在开发范例时使用的总体进程，以及用于构建工件的工具。表 1. 开发进程角色、任务与工具角色任务工具业务执行交付业务目标与目的IBM? Rational? Requirements Composer业务分析员分析业务需求IBM? Rational? Requirements Composer软件结构设计方案的结构IBM? Rational? Software ArchitectWeb 服务开发员执行方案IBM? Rational? Application Developer服务实现审核让我们从评审前面文章中执行的服务参与者开始讨论。图 1 显示了 Invoicer 服务提供商。图 1. Invoicer 服务执行Invoicer 服务参与者为计算购买订单的初始价值提供了结账服务，并在知道传递信息时改进所做的估价。订单的全额价值取决于产品是在哪里生产的，以及从哪里进行传递的。初始价值计算可能用于确认消费者拥有足够的信用，或者仍然想要购买产品。在完成订单之前最好确认这一点。图 2 显示了 Productions 服务提供商。图 2. 产品服务提供商Productions 服务参与者提供了一个日程安排服务，以决定在哪里生产一种商品以及什么时候生产。该信息可以用以创建处理购买订单所使用的传递日程安排。图 3 显示了 Shipper 服务提供商。图 3. Shipper 服务提供商Shipper 服务提供商为一个完整的订单向客户提供了传递商品的服务。该服务需要 ScheduleProcessing 界面以请求完成日程安排的消费者进程。服务组合现在一些提供商已经提供了所有的服务，所以我们可以开始使用组合中的这些提供商以满足原始的业务需求了。该组合根据业务需求来组合服务，以为 Purchasing 服务提供了一种方法。我们将会创建一个 OrderProcessor 参与者，该参与者提供了一种购买服务以处理购买订单。然后我们会创建一个 Manufacturer 参与者，它组合了 Invoicer、Productions、 Shipper 参与者以及 OrderProcessor 构件的实例，以执行服务操作进而处理购买订单。订单处理参与者购买订单处理服务是由 Purchasing 服务界面指定的（如图 4 所示），它包括了以下的功能（或者操作）：+ processPurchaseOrder (customerInfo : Customer, purchaseOrder : PurchaseOrder) : Invoice这种服务是由?OrderProcessor?参与者提供的。OrderProcessor 是这样一种参与者，它通过将服务提供商联系在一起来提供一种服务，这些提供商根据一个服务协议来进行组织。这就是说，有一些所提供服务的方法被设计成以一种特定的方式来使用其他的方法。这个构件通过它的购买服务端口来提供 Purchasing 界面。所有的客户之间的交互都是通过这个端口进行的，因此将客户与构件可能与其他服务客户或者提供商之间的交互隔离开来。这种模型之中限制的耦合，使得当市场和服务消费者及提供商发生变更时，变更起来更加容易。图 4. Purchasing 服务界面OrderProcessor 构件的组织就显示在如图 5 所示的 Project Explorer 视图中。图 5. 订单管理业务功能性区域（包）OrderProcessor 参与者包含在?org::ordermanagement?包中，它用于组织与订单管理相关的服务。订单管理包还包含了相关的服务界面和其他的参与者。图 6 所示的 OrderProcessor 图提供了一个关于 OrderProcessor 服务提供商的外部视图及其服务和请求报