被提供的服务操作的方法

    由服务提供者所提供的每一项服务操作必须通过以下两种方式之一被实现：

    Behavior （Activity、Interaction、StateMachine 或者 OpaqueBehavior），它是操作的方法；

    属于合成要素的一个 Activity 中的 AcceptEventAction （异步调用）或者 AcceptCallAction （同步需求或者回复调用）。

    这允许一个单一的 Activity 拥有多于一个的并发进入点，并且它符合 Business Process Execution Language (BPEL) 中的多重接收活动。这些 AcceptEventActions 通常被用来处理回叫信号，从其他异步的 CallOperationActions 中返回信息。

    OrderProcessor 合成要素包含两种服务实现风格的例子。processPurchaseOrder 操作拥有一个同样名字的方法活动。这一活动，如图9所示，是提供服务操作的服务提供者所拥有的一种行为。

    图 9: processPurchaseOrder 服务操作实现
     

    这个图表同用于相同行为的 WebSphere Business Modeler 图表非常符合。InvoiceProcessing 和 ScheduleProcessing 服务操作通过过程中的 processInvoice 和 processSchedule 接收事件行动被实现。请注意接口中的相应操作被指示为触发器操作，它指出响应 AcceptCallActions 的能力（类似于接收和 AcceptEventActions，此处触发器是一个 SignalEvent）。关键字触发器并不是 UML 2 的一部分，它只是用来强调这些操作是如何实现的。

    注释：

    除非 processPurchaseOrder 活动正在运行，并且控制流程已经到达两个接收呼叫行动，否则这些操作将不会被接收。这指示出一个操作的执行能够决定其他操作何时将被响应。

    实现服务契约

    OrderProcessor 合成要素至此已经完成。但是还有两件事没有做：

    首先，我们需要将 OrderProcessor 服务提供者同对其需求进行建模的业务过程相结合。

    其次，我们需要创建一个子系统，将能够提供 OrderProcessor 需求接口的服务提供者和适当的服务端口连接起来。

    这将导致一个能够运行的可配置的子系统。这一小节将处理链接 SOA 解决方案和业务需求的问题。下一小节将介绍可配置的子系统。

    本小节中的操作不会对 OrderProcessor 合成要素如何转变为一个 SOA 执行产生任何改变。将合成要素链接到服务契约，只是描述合成要素如何完成那些契约所指定的需求。这并不影响服务提供者的执行或者它将如何被转变为一个 SOA 解决方案。然而，联接较之依赖要复杂得多。它特定的显示服务提供者的各个部分在服务需求契约中扮演什么角色，以及合成元素完成业务的约束。这提供了更加丰富的可追溯性，对有细密纹理的变化管理的支持，以及使用模型验证解决方案确实满足它们的需求的能力。