本文的写作背景

对 SOA 建模的完整理解，需要知道提供商具体是如何实施一项服务，以及消费者具体是如何使用此项服务的。如果实施方案实施起来很困难，那么有可能是因为服务规范是不合适的，或者是识别了错误的服务。本文向您展示了怎样设计我们在前面文章中开发的每一项服务的实施接口。实施方案的设计由三个步骤组成：

1. 决定由哪一个服务提供商提供哪一项服务。
2. 设计服务的实施方案。
3. 组合并连结在建模一个完整的实施方案中所涉及到的所有服务消费者与提供商。

决定由哪一个提供商提供什么服务（不止一个提供商），由许多的因素决定，包括：

• 功能性的聚合以尽可能地实现重用
• 服务最有可能被使用的地方
• 服务最有可能被部署到的地方
• 需要什么质量的服务
• 功能性区域的稳定性
• 预期最有可能发生变更的地方
• 域中能够容忍多大程度的耦合
• 降低耦合情况以降低变更所能产生的影响
• 安全性问题
• 合适的平台实施方案技术
• 对已有系统的集成与重用

所有这些关注点的具体分析，已经超出了本文的讨论范围，但是在 IBM® SOMA 方法中却进行了详细地讨论。这里，我们在一定程度上假设，IT 架构师会决定由哪一个参与者提供什么服务，这样我们就可以只关注于如何对提供商进行建模，以及怎样将它们组合到消费者方案中。

注意：
面向服务的架构建模语言（SoaML）标准使用术语参与者，而且不区分服务提供商与服务消费者。这是因为，通常意义上，参与者即会提供服务又会使用服务。从参与者的服务和请求端口来看，可以很清楚地看到实际上提供了什么以及使用了什么，使得进一步识别参与者变得不太必要。

对于本系列的所有文章，我们将会使用现有的 IBM® Rational® 工具，来构建方案工件，并将其联系在一起，这样我们就可以根据需求确认方案，并且更加有效地管理变更。另外，我们通过将 Object Management Group（OMG）SoaML Profile 添加到 IBM® Rational® Software Architect 中的 UML 模型里，来扩展统一建模语言（UML）以进行服务建模。表 1 提供了总体流程的概况，我们将会在开发本文范例的过程中使用这一流程与相应的工具来构建工件。

服务识别与规范评审

让我们从评审在前面文章中识别和指定的服务规范开始。图 1 显示了揭示处理购买订单所需功能的服务接口。

图 1. 处理购买订单的功能

图 2 显示了完整的 Scheduling 服务接口。该服务接口是一个简单的接口，因为对于使用日程安排服务来说，并没有感兴趣的协议。

图 2. Scheduling 服务接口

图 3 显示了 ShippingService 服务规范。

图 3. Shipping 服务接口

该服务接口有一点点复杂，因为通过使用一个简单的回叫形式的交互，它为传递者及订购者之间的交互进行了建模。因为这种指定包含了一个协议，我们使用一个定义服务协议中会涉及到的角色（属性）的服务接口来建模。这些角色的责任是由它们的类型定义的，它就是服务接口提供或者需要的接口。ShippingService 服务拥有的 shippingService 交互定义了传递者与订购者之间进行的交互。这种交互将会成为联系该服务接口定义的服务的服务渠道的协议。

图 4 显示了 InvoicingService 服务规范。

图 4. InvoicingService 接口

该协议同样有一些复杂，因为提供的和需要的服务功能性性能必须得到调用，并对应于特定的顺序。在这种情况下，可以使用一种活动来定义协议。

图 5 显示了 Purchasing 服务规范。

图 5. Purchasing 服务接口

Purchasing 服务接口代表了在原始 Process Purchase Order 业务过程中指定的功能性性能。它代表了识别的和设计的服务，以实现业务过程。因为没有与该规范相联系的协议，我们使用一个简单的接口，再一次对其建模。

现在我们就可以设计工件了，该工件提供了每一种服务，并实现了揭示的功能。

服务的实现

所谓的服务定义了一系列的能够满足服务消费者或者用户需要的功能。服务实施方案设计的第一步，是划分服务。这就是说，我们必须想好我们将会提供什么服务，哪一个服务提供商会提供什么样的服务功能。这是设计一个 SOA 非常关键的一部分，因为选择提供商将会建立服务消费者与提供商之间的关系。因此，这就建立了一个系统以及系统各部分之间潜在耦合关系的功能。

您可以将所有的操作都放到一个单独的服务中，并因此拥有一个简单的解决方案。但是同时所有的客户都会依赖于一个服务，这就造成了很高的耦合度。提供商方面很小的一个变更，都有可能会造成所有消费者也都会产生变更。就这就是过去 C 编程时代模块化最常面临的问题。您也许会说，可以为每一个功能性性能都创建一个单独的服务，但是这将会导致产生一个复杂的系统，该系统在内聚度和封装性上面的表现十分糟糕。在消费者与提供商之间进行模块化交互可能是十分困难的，这种交互遵循一种交互协议使用一系列相关的功能性性能。

于是，决定服务的参与者是一种需要技巧的工作，并且通常会受到大量折中考虑的影响。其中分布性会发挥十分关键性的作用。如果我们可以设计不受参与者位置影响的 SOA 方案的话，那还不错，但是通常来说这是不现实的。服务部署的位置，会是消费者及其他需要服务的群体所在的地方，它对方案的性能、可用性及安全性方面会有重大意义的影响。在方案架构中忽略这一点，在方案的可执行性方面会造成十分严重的后果。

我们在这里面临的问题是十分简单的，所以初始 Business Process Modeling Notation（BPMN）业务过程概述中的汇于泳道，对于哪些参与者将会提供服务，哪些将会消费服务，都给出了一个明确的线索。图 1中的所有服务及该图下面具体的服务规范，为所有的服务提供了服务提供商的模型。这是一个十分简单的例子，其中有多个参与者只会提供一种服务，并且只有一种功能。这与实际情况是不相符的。参与者通常会提供或者消费（或者即提供又消费）多种拥有多种功能性性能的服务，在这里，我们故意把这个例子简化，使之抽象出具体复杂的情况以便您更好地理解其中的概念。

注意：
本文中提到的服务实现化问题的概念，与在 SOMA 中描述的有些出入。在 SOMA 中，服务实现处理的是架构性决策问题，它关注的是方案的模板与模式、SOA 引用架构的具体内容、技术上的可实现性以及原型问题。这超出了本系列文章的讨论范围，本文只涉及到了决定由哪些参与者提供服务、哪些参与者消费服务，以及怎样决定这些内容。

结账

一个结账者为计算一个购买订单的初始价值提供了 Invoicing 服务。然后当他得知传递信息之后，可以进一步地完善估价活动。初始价值估计可以用于确认客户拥有相应的支付能力和信用，或者一直想要购买产品。在完成整个订单之前就进行确认会更好。

在开始这个服务时，我们创建一个定义其需求的系统用例，以及一个叫做 Invoicer 实现用例的参与者，如图 6 所示。Invoicer 参与者将会位于信用包中，并导入 CRM（客户关系管理）包，以使用公共的服务数据（信息类型）定义。

图 6. 最初的 Invoicer 服务提供商

Invoicer 参与者提供了 InvoicingService 服务。我们通过向 Invoicer 添加 Service 来对其建模，它是 InvoiceService 服务接口类型的。所有的服务是由服务接口输入的，该服务接口定义了什么功能性性能是提供的，什么是需求的，以及使用它们的协议。图 7 显示了 Invoicer 与添加的结账服务。

图 7. 对 Invoicer 服务提供商添加 InvoicingService

我们可以通过服务的类型来知道该服务提供了 Invoicing 接口，并且需要使用 InvoiceProcessing 接口。从服务的类型中，我们可以知道与服务相关消费者使用服务所需要执行的操作，以及 Invoicer（或者其他的提供商）实施时必须执行的操作。服务的任意使用和实施必须与服务的规范及其协议相一致。

Invoicer 提供了 Invoicing 接口，它涉及到了两种操作：

• initiatePriceCalculation
• completePriceCalculation

Invoicer 必须为每一种指定如何提供操作的服务操作提供一种设计。当价值估算按照服务协议中指定的那样完成时，方法必须调用 InvoiceProcessing 接口的 processInvoice 操作。如图 8 所示，Invoicer 构件拥有两个与提供操作名字相同的行为。

图 8. Invoicer 服务实施

completePriceCalculation 活动是 Invoicing::completePriceCalculation 服务操作的方法。它使用一种模糊行为，来估计总体的价值，然后它会激活结账端口上的 InvoiceProcessing::processInvoice 操作。（processInvoice 操作的目标输入帧是结账服务端口，如包含操作的活动分区所示）。注意这与 InvoicingService 服务接口指定的结账协议相一致。

initiatePriceCalculation 模糊行为是 initiatePricesCalculation 服务操作的方法。该操作通过使用自然语言或者在模糊行为主体中获取的 Java™ 代码来实施。

产品日程安排

一个产品日程安排参与者会提供 Scheduling 服务，以决定在什么地方生产货物以及什么时候生产。可以使用该信息来创建一个使用的传递日程安排以处理购买订单。

产品参与者通过它的日程服务端口来提供 Scheduling 服务接口，如图 9 所示。

图 9. Productions 服务提供商

服务操作方法是 requestProductionsScheduling 及 sendShippingSchedule 行为。这些实施方案的具体内容并没有显示在图表中，并有可能由开发员使用一些更加实用、特定平台的语言来实施。

传递

一个传递服务提供商会为一个客户提供 Shipping 服务接口以传递货物。它还需要 ScheduleProcessing 接口，以请求客户处理完整的日程安排。图 10 显示了 ShippingService 服务接口来提供传递服务。

在本事例中，我们将 Shipper 参与者的指定与它的实现分隔开来。该指定参与者无论是在内部还是外部，都为实现参与者描述了架构。我们这样做是因为可能会有 Shipper 参与者指定的许多种不同实现方法，每一种方法都有不同的附加的功能及需要及服务的质量。我们展示了一个实现的参与者，ShipperImpl。特别是对集合的服务，我们将会使用 Shipper 参与者，而不是直接地引用 ShipperImpl。然后，在部署和运行的时候，该规范可以替换成各种的实施方法，以获得服务所需的质量。