Activities 和 BPEL 过程

    由服务提供者所提供的每一项功能（操作）都必须以某种形式被实现。这种实现或者是在 UML 中通过使用每一项操作的行为被设计，或者是其他一些行为的 Accept Call 行动。后一种方法通过允许提供者决定合适希望并且能够响应一个请求，而不是当操作被服务使用者调用时必须立即响应，提供了使用者和提供者之间额外的去耦合性。

    WebSphere Integration Developer SCA 采用了一种不同的方法。每一个导出必须被连接到为那个接口中的操作提供实现的集合中的组成元素。SCA 中的每一个组成元素都拥有如下实现类型：

    Human Task
    Java
    Process
    Rules Group
    State Machine

    图10和图22中的 OrderProcessor 服务提供者，通过它的购买服务提供了一中单一功能。这项操作的实现是 UML 服务模型中的一个活动。UML-to-SOA 转换从哪项活动中创建了一个 BPEL 过程，并且将它作为扩展操作的实现来使用。

    图 23. OrderProcessor 过程组成元素实现
    
 
    请注意，图23中的 BPEL 过程同图11中的活动非常相似。UML 活动如何被转换到一个 BPEL 过程中的详细细节，可以查阅 Rational Software Architect 中的 Help 小节。

    减少接口和实现的耦合性

    正如前面所描述的那样，WebSphere Integration Developer SCA 通过写一个导出来实现被提供的功能，这个导出将接口提供给一个实现被提供操作的组成元素。因为每个组成元素都拥有一个实现类型，所以导出的所有结构所提供的所有操作都必须以同样的方式被实现。这就将实现类型同一个导出的所有接口连接起来。（一个导出可以被连接到一个组成元素，或者被一个组成元素实现。）如果开发者希望改变一个特定操作的实现类型（例如，从一个人工任务到 Java 中的一个自动服务实现），那么接口就必须被重做以允许不同的导出被连接到不同的组成元素实现类型上。依次的，这需要那些接口的所有用户作出相应的改变。这种接口设计到实现类型的耦合性，可能约束 SOA 解决方案所要支持的业务敏捷性。

    UML 没有这个规范和实现耦合性。每一项被提供的操作都能够拥有一个方法行为：活动、交互作用、状态机、或者不透明行为（代码）。建模器独立的设计了每一项操作的实现。这将导致图4中所显示的情况：同一个服务提供者组成元素，为通过同一个接口所提供的不同操作，使用不同的行为类型。我们需要某种方式将这些服务提供者转换到 Web 服务。

    还有一个因素需要考虑。在 UML 中，组成元素是被实例化的，而不是它们所拥有的行为。因此，实例辨认和生命周期对于同一个组成元素中的所有行为都是一样的。除此之外，该组成元素为其所拥有的所有行为建立了一个上下文环境或者范围，从而允许那些行为分享访问组成元素状态（属性和端口）。因此，当被转换到 Web 服务时，我们必须能够管理这个能够实现 UML 语义的识别、周期和分享状态。这就是 Business Process Execution Language (BPEL) 过程进入的地方（请参见 参考资源 获得更多关于 BPEL 的内容）。

    我们并不创建一个实现模型组装中服务提供者的每一项行为的分离的 SCA 组成元素，相反，我们创建一个符合组成元素自身的单一的 BPEL 过程。您将注意到图23中 BPEL 过程的名称是 OrderProcessor ，这同 OrderProcessor 服务提供者相同，而不是被提供操作的名称 processPurchaseOrder。

    我们仔细查看一下图4，看一看 Productions 组成元素是如何被转换到 WebSphere Integration Developer Web 服务的。请注意用于 requestProductionScheduling 的实现设计使用了一个 Activity （细节并未显示），但是 sendShippingSchedule 通过 Java 代码中提供的实现使用了一个 OpaqueBehavior。用于这一服务提供者的模型组装被显示在图21中，而 Productions Process 组成元素被显示在图24中。

    图 24. Productions 服务提供者实现
    
 
    BPEL 过程是为 Productions 服务提供者组成元素而被创建的。服务提供者的身份属性被用来定义 Invoke、Receive 和 Reply 活动之间的相互关系。该组成部分所提供的每一项操作都被这个过程的一个片段所实现。该过程首先挑选那些被用来分派每一项操作需求的元素。然后，为每一项为 UML 行为中定义的变量提供位置的操作创建一个范围。这个范围包括被转换的行为的结果。如果行为是一个 UML Activity，那么该范围将包括从那个活动中被生成的 BPEL。如果行为是一个 Java 语言的 OpaqueBehavior，那么该行为的主体就被拷贝到这一范围中的 Java 剪断的活动之中。如果行为是一个 HTML 或者 Java?Server Pages (JSP) 语言的 OpaqueBehavior，那么 Human Task 活动将被添加到这个范围之中。

    这提供了接口及其实现之间完全的去耦合性。例如，如果建模者或者开发者决定从一个自动的 Java 服务的人工任务中改变一个服务操作实现，那么只需改变那个操作的范围中的人工任务元素。客户端将不会注意到实现已经被改变，它们只会注意到服务运行的更快了，并且不需要做过多的操作。

    人们普遍认为这有些复杂，就像当 SCA 已经定型后再作出改变一样。但是去耦合性、关注的分割、复用和敏捷的解决方案是 SOA 的基础，并使得它们并不总是那么容易。