外部视图不是一个从执行中分离出来的规范；它仅仅是合成要素某些方面的视图。如果架构师或者开发人员希望完全的将服务提供者的规范从它的可能执行中分离出来，就将使用到规范合成要素。规范合成要素定义了一个服务消费者和服务提供者之间的契约，它从特定的提供者执行中减弱了它们。规范合成要素能够被许多具体的合成要素识别出来，这些要素以一种识别契约的方式提供服务，并且提供服务的可接受的质量。请参见“SOA 建模: 第二部分 服务规范”获得更多细节。

    OrderProcessor 服务提供者要素十分简单和稳定，在这个例子中，架构师和开发人员决定不使用服务规范。结果是，使用 OrderProcessor 合成要素的任何服务消费者都将同这个特定的执行相联系。这是不是一个充分的设计取决于有多少服务将被使用，以及随着时间的推移它们将发生多大程度的改变。只有解决方案架构师能够决定一个特定的系统能够容忍什么程度的耦合性。

    OrderProcessor 合成要素也拥有反映有其他服务提供者（货品计价、时间表、运送）提供的需要请求的服务端口。这些服务提供者提供了 OrderProcessor 合成要素用来执行其被提供的服务操作的那些服务。

    每一个服务交互作用点都涉及到一个简单协议，该协议影响被提供的和被要求的接口。例如，货品计价交互作用点要求 Invoicing 接口启动价格计算器，并且发送运送价格。然而，它可能会花费一些时间来计算运送价格，所以 OrderProcessor 通过其货品计价端口来提供 InvoiceProcessing 接口，从而使得货品计价服务提供者能够在其准备好时发送一张发货单。

    Order Processor 执行设计模型
    我们现在完成了服务模型的架构，并且在服务提供者的外部视图中捕获到它。下一步就是为 OrderProcessor 合成要素所提供的 processPurchaseOrder 服务操作提供一种方法。这种方法必须遵循任何一个已经完成的服务契约或者已经实现的服务规范，也要遵循那些操作已经被定义的服务规范。

    内部结构

    OrderProcessor 服务提供者通过它的购买服务端口提供了一个简单的服务规范 Purchasing。这个服务规范指定了一个简单的操作 processPurchaseOrder。服务提供者必须为它所提供的全部服务操作提供一些方法。在这个例子中，我们使用 Activity 作为 processPurchaseOrder 服务操作的方法。有关的细节被显示在提供服务的 OrderProcessor 合成要素的内部结构中。OrderProcessor 内部结构在图表、接口、类和活动中被捕获，如图7中的 Project Explorer 视图和图8中的复合结构图表所示。

    图 7. OrderProcessor 服务提供者的组织
    

 
    Project Explorer 视图显示了 OrderProcessor 提供者各个部分的列表，以及每一个被提供的操作的方法（行为）。在这个例子中所使用的约定是，使用一个和合成要素名称一致的类图表，并且在包含该合成要素的包中，显示它的外部视图。这就是图6和图7中所显示的图表。同合成要素具有同样名称并且被包含在合成要素中的复合结构图表，提供了服务提供者结构的内部视图。这个图表直接位于图7中的 OrderProcessor 服务提供者的下面。这些约定能够更好的协调服务参与者的外部和内部视图，并且如同合成要素一样仔细研究图表。

    OrderProcessor 复合结构图表如图8所示，提供了一个服务提供者的内部结构的总体视图。再一次显示了合成要素的合成静态结构的各个部分（端口和属性）。

    图 8: OrderProcessor 服务提供者的内部结构
    

 
    OrderProcessor 合成要素的内部视图很简单。它由用于被提供的和被要求的接口的服务端口、加之许多其他保持服务提供者状态的属性共同合成。属性 ID 被用来识别服务提供者的实例。这个属性将被用来动态的关联消费者和提供者的交互作用。属性 schedule 和 shippingInfo 是在 processPurchaseOrder 服务操作的执行中被使用的信息。