BPEL 概述

    OASIS 标准组织已将 Business Process Execution Language (BPEL) 定义为基于标准的方法，使用该方法可以编排由服务构成的业务流程。2007 年，WS-BPEL 2.0 被批准为标准语言。作为一种执行语言，WS-BPEL 定义了如何表示业务流程中的活动，以及流控制逻辑、数据、消息相关性和异常处理等。

    IBM 的 WebSphere Process Server（以下称为 Process Server）包括业务流编排器（即基于 WS-BPEL 的流引擎）。上一版本称为 WebSphere Business Integration Server Foundation，该版本也包括 WS-BPEL 支持。

    Process Server 包含多个主要功能，其中包括：

    业务流程：流程可以是有状态和长时间运行的，或者是事务型微流。长时间运行的流程无法像微流那样回滚，不过，它们可以使用补偿处理程序撤消先前执行的活动。流程可用于实现组合服务。

    人工任务：业务流程的一个关键部分是能够将人员引入该流程。人工任务管理器启用一些步骤，通过这些步骤可以将人员作为一种服务来调用。工作流模式是使用 BPEL 扩展通过外部（参与）任务或内联任务进行支持的。

    业务规则：集成的规则引擎允许创建和评估业务规则，而不是将决策硬编码到业务流程。授权用户可以使用 Web 浏览器更新该规则。管理员可以激活更新，并将其导出，因此开发环境可以与运行时保持同步。

    集成 ESB：Process Server 包括完整的 WebSphere ESB 产品。在本文中，我们只介绍 Process Server 的 BPEL 引擎组件。

    SCA：Process Server 中的服务调用是使用服务组件体系结构 (SCA) 规范完成的。SCA 接口映射可用于调用其接口与调用组件不同的服务。接口映射也支持高级功能（如关系）。如果系统 A 使用“123”作为客户标识符，而系统 B 使用“ABC”作为客户标识符，则在这两个系统之间转换时，您可以使用关系建立“123”到“ABC”的中介，反之亦然。

    决定使用哪一个运行时

    正如前面所提到的，Process Server 和 ESB 之间存在一些功能重叠。二者都可以与适配器一起工作。二者都可以转换数据。二者都支持组合服务模式。当面临使用非常好的软件解决给定的业务问题时，您需要决定使用哪一个。

    作为架构师，您需要熟悉两个软件平台的功能。收集了完整的需求集后，便可以开始决定要使用的流程。

    业务的第一项是分析需求，并确定所选流程是否为较适合的流程。例如，如果需要有状态流程，则可以立即排除 ESB。另一方面，如果要求在 0.2 秒内处理消息转换，则显然应该选择 ESB。遗憾的是，在现实世界中，并不是所有项目的需求都能机械套用的。通常需要检查多个条件才能确定非常好的选项。

    ESB 的优点

    ESB 的主要优点之一就是处理消息。消息的传入和传出也许会用到协议或格式中介。当这些需求明显需要处理消息时，使用 ESB 可以提供许多优势，其中包括在转换中处理较复杂事务的能力。当这些需求需要使用 ESB 基本功能（如消息路由、转换或协议中介）之一时，则 ESB 是非常好的选择。

    ESB 的另一个优点是性能。ESB 在计划上能够处理大量的消息。例如，如果需求是每天处理 200,000 条消息，则 ESB 显然是较好的选择。

    如果需求是以数据为中心的，则显然要选择 ESB。

    BPEL 的优点

    BPEL 引擎的主要优点是能够编排业务流程。如果需求是处理具有复杂逻辑的流程，则 BPEL 是较好的选择。WS-BPEL 包含容器活动，如 ESB 不支持的 while 循环和范围。ESB 中的逻辑通常非常简单，而 WS-BPEL 可以处理更复杂的情形。

    WS-BPEL 引擎（如 WebSphere Process Server）的另一个优点是能够让业务流程长时间运行并维持其状态。当需要状态时，不应使用 ESB，因为维护状态会占用许多自定义代码。如果需求是进行有状态的处理，则在选择时可以排除 ESB。

    如果需求是以流程为中心的，则显然要选择 WS-BPEL。

    功能注意事项

    特定项目的具体需求是确定哪一个环境最适合给定项目的主要因素。您需要考虑的一些重要问题包括：

    需要哪些传输协议？例如，Process Server 和 Message Broker 都支持 WebSphere MQ，但是只有 Message Broker 支持 IP 多播。如果使用 JMS，还务必了解系统是否支持特定的 JMS 提供程序。

    需要哪些标准？例如，需求可能是 WS-Security，或支持复杂的工业标准模式。您需要知道服务器是否支持这些标准。例如，Message Broker 对无类型的消息处理可能具有更强的支持，而 Process Server 可以使用 J2EE 安全，因为它运行在 J2EE 容器中。不同的环境可能都支持某个标准，但支持的级别不同。在做出决定之前，确保检查所有的细节。

    什么是服务质量 (QoS) 需求？系统必须是高可用的吗？如果在高可用性环境中安装了 Message Broker，而未安装 Process Server，则可能会影响您的决策。您需要了解特定的环境，才能理解可用的 QoS。您需要考虑性能需求以及有保证的邮件传递之类的需求。

    需要哪些路由和消息传递样式？在系统中可以使用各种消息传递样式，如同步或异步、请求/响应、单向和发布/订阅。需要哪些消息传递样式？可能是一种消息传递样式或消息传递样式的组合。在给定的环境中支持哪些消息传递样式？Process Server 可以通过 JMS 主题执行消息发布，而 Message Broker 具有更高级的功能（如基于内容的订阅）。这些需求有助于缩小运行时选择范围。