本文的写作背景

在本文中，我们组合了以前所创建的服务参与者，在第三篇中，我们使用其他参与者的功能。这就是说，我们将会从其他的服务的组合或者组合当中创建一个新的服务。这种服务组合的技术可以重复地使用无限次，不管您的关注点是什么，也不管抽象的层次如何。但是，可能会有结构上的限制因素，影响到服务操作、安全和性能关注、数据交换容量、线性层次交互协议和绑定问题的整体性，它们可能会限制什么构件提供什么服务。这个问题决定了方案的结构，并超出了本文的讨论范围。

本系列所有的文章有一个共同点，那就是我们使用已存在的 IBM® Rational® 工具来构建方案工件并将它们再一次联系起来，这样我们就可以根据需求确认方案的可执行性，并更加有效地管理变更。另外，我们通过向 IBM Rational Software Architect 中的 UML 模型添加对象管理组面向服务架构建模语言（OMG SoaML）概述，来为服务建模扩展统一建模语言（UML）。表 1 提供了一个总结，关于我们在开发范例时使用的总体进程，以及用于构建工件的工具。

服务实现审核

让我们从评审前面文章中执行的服务参与者开始讨论。图 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 服务提供商的外部视图及其服务和请求报告。所需要的服务被标记成 Requests 以将参与者与功能区分开来。外部的或者黑箱视图就是其他参与者所看到的内容。接下来例子中显示的参与者的内部结构，提供了结构的内部或者黑箱视图，以支持参与者的执行设计。

图 6. OrderProcessor

外部视图并不是与实现相隔离的规格；它只是构建一些方面的简单视图。如果架构师或者开发员想要完整地将服务提供商的规格与它可能的实现分隔开来，那么应该使用一个规格构件，就像在 图 3 中对 Shipper 参与者所做的那样。一个规格构件定义了服务消费者与服务提供商之间的契约。规格参与者可以由许多具体的构件来实现，这些构件以一种可以实现契约并提供可靠服务质量的方式来提供服务。您可以查看“第 2 部分：服务实现”以得到更多的具体信息。

OrderProcessor 参与者非常的简单和稳定。因此，在这个例子中，架构师或者开发员并不想要使用一种服务规格。结果，任何使用 OrderProcessor 构件的服务消费者都需要进行这种特定的执行。它是否是一种可用的设计，取决于服务将会被使用多少，以及它随着时间将会发生什么样的变化，只有业务或者方案架构师可以决定特定的系统可以承受多大程度的耦合度。

OrderProcessor 构件还有一些请求端口，它指定了其他参与者提供的需要：结账、日程安排及传递。

每一个服务和请求交易点都可以涉及到一个协议，该协议指定了怎样使用提供的和需要的界面操作。例如，结账的请求端口需要 Invoicing 界面进行价格计算并发送传递的价格。但是，计算传递的价格可能还需要一段时间，于是 OrderProcessor 通过它所请求的端口提供 InvoiceProcessing 界面，这样结账服务提供商就可以在就绪的时候发送结好的账目了。

Order Processor 执行设计模型

现在我们已经完成了服务模型的架构化结构，并在服务提供商的外部视图中得到它。接下来要做的事情是为 OrderProcessor 构件提供的 processPurchaseOrder 服务操作设计一种方法。该方法必须遵循任意实现的服务契约或者实现的服务规格，以及定义操作的服务规格。

内部的结构

OrderProcessor 服务提供商通过它的购买服务端口提供了一种单个的服务规格，Purchasing。该服务指定了一种单个的操作，processPurchaseOrder。服务提供商必须为所有提供的服务操作提供一些方法。该例使用 Activity 作为 processPurchaseOrder 服务操作的方法。具体这是怎样实现的显示在提供服务的 OrderProcessor 构件的内部结构中。OrderProcessor 内部结构是通过图表、界面、类及活动获取的，如图 7 中的 Project Explorer 视图和 图 8 中的组合结构图所示。

图 7 中的 Project Explorer 视图显示了 OrderProcessor 提供商部分的列表以及每一个提供的操作的方法（行为）。该例中采用的习惯是使用一个与其参与者同名的类图，以显示 图 6 中显示的外部视图。

图 7. OrderProcessor 的结构

与构件相同名字的构件结构图提供了服务提供商结构的内部视图。该图直接位于图 8 中 OrderProcessor 服务提供商下面。这些习惯使得协调服务参与者的内部视图及外部视图，以及处理与构件相同的图表变得更加容易。

图 8 中所示的 OrderProcessor 构件结构提供了服务提供商的内部结构的一个概述。这再次显示了组成参与者静态结构的部件（端口与属性）。

图 8. OrderProcessor 服务提供商的内部结构

OrderProcessor 构件的内部结构是简单的。它由所提供的和所需要的界面的服务与请求端口，加上维持服务提供商状态的一些其他属性组成。ID 属性用于识别服务提供商的实例。该属性将用于在运行时联系消费者与提供商。schedule 与 shippingInfo 是 processPurchaseOrder 服务执行的实现中会使用到的信息。

注意：
在本例中，所有的服务都是非论述的，但是提供和使用服务的参与者通常不是这样的。

提供服务操作的方法

服务提供商提供的每一个服务操作必须通过一种行为或者操作来实现：

• 一个是操作的方法的行为（Activity、Interaction、StateMachine 或者 OpaqueBehavior）
• Activity 中属于构件的 AcceptEventAction （对于异步访问）或者 AcceptCallAction （对于同步的请求或者回应访问）

这就使得单个的 Activity 能够拥有不止一个当前的进入点，而且它能响应 Business Process Execution Language（BPEL）中多个接受活动。这些 AcceptEventActions 通常用于处理访问以从其他的异步 CallOperationActions 中返回信息。

OrderProcessor 构件有服务实现两种形式的范例。processPurchaseOrder 操作拥有与 Activity 方法相同的名字。如图 9 所示，该活动是提供服务操作的服务提供商所拥有的行为。

图 9. processPurchaseOrder Service Operation 的实现

该图十分紧密地相应于 IBM® Rational® Requirements Composer Business Process Modeling Notation （BPMN）业务进程。InvoiceProcessing 和 ScheduleProcessing 服务操作通过 processInvoice 与 processSchedule 来实现并接受进程中的变更。注意界面中相应的操作会标记成接受，以指示响应由其他参与者发送的访问事件的能力。

注意：
这些操作将不会得到接受，除非 processPurchaseOrder 活动正在运行而且控制的流程达到了两个 Accept Call 操作。这意味着操作的执行可以决定什么时候其他的操作将会得到回应。

组合参与者

OrderProcessor 构件现在已经是完整的了。但是让其能够在任意的环境下，手动或者自动执行（实现），OrderProcessor 参与者必须联系能够满足请求的参与者。否则，请求端口上激发的操作将得不到执行，因为没有参与者去执行它们。剩下来还有两件事要做：

1. 首先，我们需要创建一个参与者，它组合了其他能够向合适服务提供 OrderProcessor 请求的参与者。
2. 然后我们需要将 OrderProcessor 服务提供商与为需求建模的服务结构联系起来。

这就产生了一个潜在活动参与者的完整组合体，可以在一些执行环境下运行（包括手动的过程）。

这个部分处理了新的 Manufacturer 参与者中组合的参与者。接下来的部分讨论了尝试让方案回到它所遵循的服务架构部分。

图 10 中显示的 Manufacturer 参与者代表了一个完整的参与者部分，该参与者将 OrderProcessor 服务提供者与提供受请求服务的其他服务提供者联系起来。这个参与者是其他参与者的一个组合体，它提供了所需要的所有信息，以完成订单处理和购买服务。

图 10. 组合 Manufacturer 部件

Manufacturer 参与者是引用 OrderProcessor、Invoicer、Productions 及 Shipper 参与者实例的组合体。销售参与者的结账服务与 Invoicer 参与者的结账服务是相互联系的。这是一种有效的联系，因为 OrderProcessor 参与者的结账服务的服务界面与 Invoicer 参与者的结账服务相同。

联系的服务与请求意味着参与者同意根据服务界面通过一种服务渠道来进行交互。这就是说，它们同意遵循需要的协议。服务界面定义了联系协议中参与者的角色。orderProcessor 消费者的结账请求端口与 Invoicer 提供商的结账服务端口之间的服务渠道连接器创建了参与者之间的协议。这个过程需要通过服务渠道的任意交互形式，以遵循服务界面的协议。

其他的消费者和提供商按照相似的方法进行联系。联系的服务可以提供不同的绑定形式。服务交互点之间的服务渠道可以指定实际的绑定形式以使用。

服务价值链

将 orderProcessor 请求与 Invoicer 服务联系起来的服务渠道，建立了价值链中的联系。orderProcessor 参与者的请求代表了通过结账请求端口所要达到的目标，以及服务期望的质量。所有这些信息在服务界面中获取，以定义请求。与之相反 Invoicer 的服务通过它的结账服务端口及它提供的功能来代表它的价值，以支持该价值的成就，参与者愿意并且能够实施的服务的质量。

Manufacturing 参与者现在就是完整的，并且已经可以在一些执行环境中执行和部署了。它引用了所需要的全部服务参与者以充分地执行 processPurchaseOrder 服务操作。在它部署之后，其他的服务消费者可以绑定至 Manufacturer 参与者的购买服务并激发服务操作。

遵循服务架构

本例中所要做的最后一件事就是将我们的方案与在第一篇文章中，第 1 部分：服务实现所设计的服务架构联系起来。我们的方案已经与业务动机和策略联系起来，因为在第 1 部分中识别的服务界面揭示了实现业务战略和目标的业务功能。在一个更广泛的例子中，我们可以使用 OMG Business Motivation Model （BMM）来获取业务动机和战略的一个更加复杂的图。这样一个模型不仅仅包括业务目标，还包括了促进业务变更的影响，变更包括识别那些模板、支持那些目标成就的战略和战术、评价业务在降低风险与增加回报方面的潜在效果等等。这可以用于将方案中的服务直接与业务上的处理联系起来，因此识别了校正构造的价值。

本文中并没有变更 Manufacturer 参与者转化为特定平台实现的方式。将参与者与服务架构联系起来，只描述了参与者实现了架构指定的需求的方式。这并不会影响服务提供商的执行，或者它转化为平台方案的方式。

但是，联系要比一个简单的附件更加复杂。特别需要指出的是，它显示了服务提供商在服务架构中发挥的作用，以及在参与者方面的限制因素是如何对结构和业务施加影响的。它为变更提供了更高的追踪性和支持，以及使用模型确认的能力以确保方案能够满足它们的需要。

图 11，摘自“第 1 部分：服务实现”，显示了处理购买订单的服务架构。协作使用添加至 Manufacturer 参与者以指示它所满足的服务架构。

图 11. 处理购买订单的服务架构

协作使用，也就是图 12 中所谓的结构，是来自第 1 部分制造者架构服务架构的一个实例。它指定了 OrderProcessor 服务提供商遵循服务架构。绑定的角色指定了服务结构中所扮演的角色。例如，结账的参与者扮演了 Invoicer 的角色，而 orderProcessor 参与者扮演了 orderHandler 的角色。

图 12. 遵循服务结构

这些绑定的角色与前面部分中描述的服务渠道连接器没有关系。服务渠道连接器用于将参与者组合中的消费者请求与提供商服务联系起来。角色绑定指定了各个部件在服务结构中扮演了什么角色。角色绑定的理解可以严格，也可以宽松一点。

• 严格 意味着部件必须与它们绑定的角色的类型是协调的。
• 宽松 意味着部件需要根据结构来发挥其作用，但是模型认证并不需要可能也不能确认角色和部件的协调性。

这可能是因为，服务结构是不完整的，或者只是以一种不规范草图的形式存在。

显示 SOA 方案怎样执行业务结构需要做一些其他的工作，以制定服务结构与角色绑定。但是它为管理变更提供了很大的便利之处。模型查询可以用于决定哪些参与者实现了业务需求。需求上的任何变更，都可能导致服务结构上某个角色的变更。建模者可以直接切换到扮演某种角色的部件那里，以决定对部件指定类型的服务界面需要做什么变更以应对需求上的变更。

模型确认还可以用于决定是否有一些角色发生了变更，以及 SOA 方案中部件所发挥的作用是否不再能够执行这个角色所赋予的责任。这要比构型一致的附件功能更加强大，该附件没有支持的语义意义或者用例实现的宽松语义。SOA 方案与业务需求之间规范可确认的联系，可以确保方案是业务相关的，满足需求，并使得敏捷方案能够快速适应变更。

本文的总结及接下来的内容

现在我们已经完成了服务的识别、指定和实现，并指明了提供和使用服务以满足业务目标的参与者。结果是一个以平台为中心、以技术为中心但是却相当完整的服务方案结构。

为了能够真实运行方案，我们需要创建一个平台执行，它与服务模型中获取的结构化设计决策相一致。我们可以将模型作为指南使用以手动创建该方案。但是这种方法是比较繁琐、容易出错、费时，可能还需要一个有着高度技巧的开发员以确保结构化的决策得到合适的执行。

手动创建方案显然是可能的，使用模型作为指南可以帮很大的忙。但是拥有一个完整、规范且确认的模型给我们了一个机会，去利用模型驱动开发（MDD），以从模型中创建一个方案草图，然后在特定平台的编程环境中完成具体的编码活动。而这正是本系列文章的下一篇也就是最后一篇文章的主题，这篇文章就是“使用 soaML，面向服务架构建模语言来建模：第 5 部分：服务的执行”。在那篇文章中，我们使用 Rational Software Architect 的 UML-to-SOA 转换特性，来创建一个可以直接在 IBM WebSphere Integration Developer 中使用的 Web 服务方案，以执行、测试和部署所完成的解决方案。