购买规范

    最后，我们来看处理定购单的服务规范，如图7所示。

    图7. Purchasing 服务规范
 
    如同 Scheduling 服务规范一样，Purchasing 是一个简单的接口，它仅仅拥有一个为消费者处理定购单提供功能的操作，而这些消费者将返回一个完全的发货单。伴随而来的副作用是，订购的条目被生产（如果需要的话）并且运送给消费者。

    该服务接口反映了在原始的 Process Purchase Order 业务过程中指定的功能性的能力。它反映了从那个业务过程中识别和设计的服务。

    服务拓扑结构重温

    至此，服务规范被更加完整的定义。我们能够查看前面 图3 中所显示服务拓扑结构。回顾它显示了被识别服务的实例如何能够被使用来满足业务 Service Requirements 契约。但是那个图表没有很好的显示服务自身，它们是如何被连接的，以及在它们的交互作用中涉及到什么协议。既然服务规范已经被完成，您创建一个新的图表，来指示使用这些服务的服务参与方如何进行交互来实现该需求。您将在本系列的下一篇文章 “SOA 建模 第三部分 服务实现” 中再次看到这一图表，在那里它将被当作本例子中最终的完整的服务解决方案的出发点被使用。

    图8显示了一个抽象的 Order Processing 组件，它为显示服务拓扑结构的另一个视图提供了上下文环境。它部分反映了将要提供或者需求服务（或者既提供又需求）的必须满足 Process Purchase Order 需求契约的顺序处理参与方。我们尚不精确的知道这些部分是什么（它们没有类型），但是我们能够通过指出它们在定义其如何交互的服务规范中扮演什么角色，结合它们想要满足的需求是什么，来指定它们需要做什么。

    图8. 服务交互的细节
 
    Order Processing 组件各部分之间的连接器，指出了各部分之间预期的交互作用。连接器的名称与它们契约的名称相对应，在这种情况下，这是相应的服务规范的协议。这指示出这些部分将必须提供和要求服务规范所指定的接口，并且根据服务规范的协议各部分将会使用的这些接口。在本系列的下一篇文章对服务实现的描述中，将对这件事是如何完成的进行建模。

    我们还看到这些被放在一起的部分将会以一种满足 Process Purchase Order 需求契约的方式相互作用。因此，Order Processing 总结出以下两点：

    服务消费者和提供者（或者称之为参与者）需要满足业务需求，
    表示这些参与者如何相互作用的连接和协议同样如此。