回想这个服务协作反映了一个需求合同，它潜在来源于一个反映我们的服务解决方案所必须做的事情的业务过程中。它是一个和体系结构无关的需求规范，并不过度约束 SOA 解决方案。

    图2显示了作为满足需求所需要的被识别的服务规范。本质上讲，我们正在建造（购买、复用、适应）能够在这一业务服务需求合同中扮演角色的服务。

    图2. 服务拓扑结构
 
    图3显示了完全的 Scheduling 服务规范。由于没有使用时序安排服务的协议，该服务规范只是一个简单的接口。

    
    图3. 时间进度服务规范
 
    图4显示了 ShippingService 服务规范。

    
    图4. ShippingService 服务规范
 
    这一服务规范稍微有些复杂，这是因为它是通过使用简单的回调式的交互对交付者和订购者之间的交互进行建模。由于该规范包括行为协议，所以使用一个对服务协议中涉及到的角色（属性）进行定义的抽象类来进行建模。这些角色的职责都被它们的类型所定义，这些类型就是由服务规范提供的或者要求的接口。ShippingService 服务规范所拥有的 ShippingService 交互作用，定义了交付者和订购者如何进行相互作用的规则。这一交互作用将成为连接到该服务接口所定义的一个服务的服务信道的合同。

    图5显示了 InvoicingService 服务规范。

    
    图5. InvoicingService 服务规范