【IT168 技术文档】由于众多原因，企业服务总线 (ESB) 是任何企业级 SOA 必不可少的一部分。

随着实施面向服务结构建能够将服务编制为端到端业务流的灵活且标准的业务流程。

该系列文章的前几部分描述了如何利用最新的标准和体系结构方法为后端应用程序提供服务，并在企业服务总线 (ESB) 上发布这些服务。但所有这些服务只能在访问它们的客户端和业务流程的上下文中使用。本文关注如何构建能够将服务编制为端到端业务流的灵活且标准的业务流程。

业务流程是实现业务功能所需的一系列步骤。业务流程可能包括企业内或企业间的系统交互和/或人工交互。出于一致性或合规性目的，一些企业只记录他们的业务流程。然而，在过去几年中，我们看到越来越多的组织使用 IT 系统自动执行和监控其业务流程。我们认为，越来越多的人采用业务流程管理 (BPM) 的主要原因之一是，出现了能够被广泛接受的标准（例如，WS-BPEL）来实现和执行业务流程。

图 1 用于定单处理的 BPEL 流程示例

在“精通 SOA”系列的这部分中，我们将描述如何使用这些标准，并结合 Oracle 供应商和 Monster Worldwide 的经验以及生产中若干个成功的 Oracle 企业服务总线和 Oracle BPEL 流程管理器的面向服务体系结构 (SOA) 实现，来面对业务流程编制的挑战。

Monster Worldwide

Monster Worldwide 已经确定 BPEL 是一个重要标准，因为 SOA 和 BPEL 不仅能够提供成为全球标准所需的敏捷性和可扩展性，同时还能满足客户的本地业务需要。此外，BPEL 由若干个 IT 行业公司支持的标准化委员会推动，从而最小化了由选择专用集成平台而带来的供应商束缚风险。

随着 Monster Worldwide 应用程序的不断增多，需要使用 Web 服务和 SOA 将这些应用程序互联。它通过将接口以标准方式公开给现有系统来发布服务，从而利用 Web 服务标准，例如，SOAP、WSDL 和 XML Schema。然后，Monster Worldwide 可以将这些服务编制为端到端业务流。BPEL 是此类编制的行业标准。

在本文中，您将看到关于 Monster 如何实现 SOA 和 BPEL 的示例，以及来自其他 Oracle 客户的 SOA 实现的提示和技巧。您还将学习 BPEL 标准的特性，它如何适应 SOA 空间中的其他标准，以及 Oracle SOA 套件如何提供实现这些标准的基础架构。

BPEL 基础知识

BPEL 定义了一个基于 XML 的语言，用于指定基于 Web 服务的业务流程行为。第一个公开的 BPEL 规范在 2002 年 7 月发布（即 BPEL4WS 版本 1.0），它结合了 IBM 的 Web 服务流语言 (WSFL) 和 Microsoft 的 XLANG 规范。版本 1.1 于 2003 年发布，是由许多业界供应商协作完成的，而 WS-BPEL 标准的 2.0 版预计将由 OASIS 标准机构于 2007 年初发布。

BPEL 标准将企业业务流程的互操作性和可移植性提高到一个前所未有的程度。互操作性使运行在不同业务流程引擎上的业务流程能够彼此交互，以及与多个供应商和开源平台发布的服务交互。能够实现这一点是因为 BPEL 基于较低级的 Web 服务堆栈 — 即 SOAP、UDDI、WS-Addressing、WSDL、XML、XML Schema 等。业务流程方面的互操作性已经实现多年了；然而，BPEL 和 Web 服务标准可将其带入下一级别。继互操作性概念之后，业务流程的可移植性概念则是全新的。BPEL 提供的流程可移植性确保您可以使用支持该标准并可以运行在任何兼容系统上的工具定义业务流程。如今，您可以从较大的平台供应商（例如，Oracle 和 IBM）获得 BPEL 引擎，也可以从较小的特定供应商和开源公司获得。

编排和编制

实现业务流程的运行时生命周期需要执行多个活动。BPEL 是一种 Web 服务编制语言，不同于流程编排。流程编排（IT 界常用术语）可描述多个贸易伙伴为了实现多组织业务功能而进行的交互。例如，在供应链方面，实施产品采购可能涉及到多家公司的定单、发货通知单和资金的交互。编排不描述每个公司如何处理操作，只描述不同公司如何彼此交互。

流程编制使用一个中心流程来协调不同的 Web 服务操作。这个中心“指挥家”（就像在管弦乐团一样）了解编制的总体目标、涉及的操作以及操作的调用顺序。这种集中化管理使 Web 服务能够在不了解彼此影响的情况下进行添加和删除，还允许在出现错误和异常的情况下进行补偿。

流程编制和流程编排仅在描述服务接口和交互方面类似。对本文而言，我们将关注流程编制。当您使用 BPEL 进行编制时，BPEL 语言将提供一个标准来控制整体操作序列、调用服务以及在 BPEL 服务器上执行。

Monster Worldwide 最复杂的一项集成工作是开发一个从 Oracle 的 Siebel 客户关系管理 (Siebel CRM) 到 Oracle 电子商务套件的定单-发票集成。这些要求包括将初始定单消息（一个 Siebel 生成的对象，包括定单和客户数据）分为两个消息，转换这两个消息中的数据，以及在将消息发送到 Oracle 电子商务套件之前丰富定单数据。此外，需要在发送客户定单之前在 Oracle 电子商务套件中创建客户配置文件。我们将构建一系列 BPEL 流程来协调这些步骤的执行。收到 Siebel 定单对象之后，第一个服务将对象分为两个消息，即客户和定单。然后，编制将并行增强该定单和客户数据。转换定单数据之后，将其传递到演练整个定单数据增强功能的服务。完成后，编制将客户消息发送至 Oracle 电子商务套件，并等待成功响应后再发送定单消息。该编制可确保 Monster 的所有活动按预期序列发生，并确保在该过程中遇到错误时进行正确的补偿。

BPEL 框架

BPEL 是一个强大的语言，允许使用 Web 服务组件开发复杂的业务流程。BPEL 流程可指定调用哪些 Web 服务以及调用的顺序。BPEL 服务器跟踪事务中涉及的业务流程；确保这些步骤以正确顺序执行；并管理事务、补偿和异常。

BPEL 支持来自任何编制语言的所有控制流结构：循环和条件、变量，分配数据值，定义错误处理程序，等等。BPEL 接收活动用于定义当客户端通过服务接口首次调用它时将创建业务流程实例的事件或消息。然后该流程将调用其他服务（定义的业务流程序列中的活动）。通常将生成一个响应（回复）。

其中，BPEL 流程可能必须操作数据变量（赋值），处理错误和异常（引发）或等待一段时间。最后，该流程可以在任意时刻结束（终止）。

该元素变量定义在整个流程描述中使用的所有消息和数据。变量用于发送到涉及的服务或从它们接收的每个消息。它们用于与任何编程语言相同的方式处理流程执行。

结构化活动可能包括按顺序（序列）执行活动或并行（流）执行活动的 BPEL 编制。以下是 BPEL 中最重要的一些控制流活动：

    switch — 基于条件选择路由
    while — 等待特定条件的满足
    pick — 等待接收若干消息之一

BPEL 可以基于条件行为定义业务流程异常。例如，将 Monster 按区域划分：北美、欧洲和亚太地区。根据定单的来源区域，BPEL 流程执行区域特定的逻辑。

同样，Monster 已经定义了定单-发票 BPEL 流来并行处理客户和定单，同时按顺序处理定单服务。

BPEL 处理编制服务 (partnerLink)，该服务可为该流程与之交互的各方定义接口。这些 partnerLink 包括 BPEL 流程和该接口（客户端通过该接口调用 BPEL 流程自身）调用的服务。BPEL 流程灵活绑定到物理服务端点可以在设计、部署或运行时进行。对于上面描述的服务，Siebel 和 Oracle 电子商务套件适配器是我们的关键 partnerLink。

BPEL 具有对异步事件的丰富支持。BPEL 流程可以等待在任何时候从客户端（同样的 BPEL 接收活动用于实例化新的流程实例）接收消息或请求。BPEL 引擎将处理保持流程状态的开销，直到该消息传入并将消息与特定流程实例相关（通过标准 WS-Addressing 或自定义相关机制）。

BPEL 流程自身可将同步或异步接口公开给它们的客户端。同步 BPEL 流程操作锁定客户端直到流程返回对客户端的响应。异步 BPEL 接口可以是单向的（“即发即弃”），或通过回调返回对客户端的响应。异步流程常用于较长期运行的操作，而同步常用于较短期运行的操作。

在 Monster，上面描述的定单-发票流程是长期运行的异步流程。除了上面描述的逻辑，Oracle 电子商务套件中创建的发票号通过回调返回到 Siebel，如果发生异常，异常处理过程包括人工流程。

异常和补偿处理

通常，实现有用的业务流程用例（当一切准备就绪时）只是业务流程总体设计和实现工作的一小部分。大部分时间都花费在定义所有适当的异常处理逻辑上，以便构建在所有预期条件下（甚至在意外条件下）能够进行合理操作的强健且灵活的流程。BPEL 提供了丰富的异常处理功能，以便开发人员可以定义（以分层 try/catch 类型模式）在流程执行过程中出现异常和错误时如何处理。

但是，除了异常处理之外，一些流程需要更具事务性的行为。在短期流和服务方面，标准事务模型足够用了，因为它们使用的是 XA 或 ACID 事务模型，其中的资源可在事务持续时间内锁定并在必要时回滚。

但是，在业务流程编制领域，服务可能由外部组织拥有，并且执行流程和服务接口可能要花几分钟、几小时甚至是几天，因此需要一个新的事务模型。这称为长期运行的事务或补偿事务。虽然该领域正等待这方面的实际标准来允许事务协调器自动处理补偿事务，但是 BPEL 语言通过一个称为补偿处理程序的特性为该功能提供了支持。

补偿处理程序可以显式撤销在某个错误条件生成前成功完成的工作。每个调用活动可以按需与撤销它的补偿活动配对。如果出现错误，针对在失败活动范围内已经完成的工作的补偿处理程序将用于撤销完成的工作。

不足之处在于，该补偿处理程序方法需要流程设计器显式考虑如何补偿每个活动。正面来讲，BPEL 引擎然后将在运行时跟踪所有活动并只为以前完成的步骤执行那些补偿处理程序。此外，BPEL 引擎将在运行时对数据进行快照，以便补偿处理程序在初始活动完成时可以访问当前数据。最后，该方法意味着服务自身无需具有对补偿事务的显式支持 — 这是好事，因为对补偿事务而言仍然没有诸如 XA 和 JTA 的标准。

BPEL 2.0

BPEL 2.0 是作为通用 OASIS 标准的 BPEL 1.1 的发展演变。BPEL 2.0 提供一些重要的增强功能，例如：

    新活动类型 — if-then-else、repeatUntil、validate、forEach 和 extensionActivity
    forEach 活动中的完成条件
    变量初始化
    用于变量转换的 XSLT — 新的 XPath 扩展函数 bpws:doXslTransform
    对变量数据的简化 XPath 访问 — XPath 变量语法 $variable[.part]/location
    Web 服务活动中的 XML Schema 变量 — 用于 WS-I doc literal 样式服务交互
    局部声明的 messageExchange — 接收和回复活动的内部关联，抽象流程的分类

除 BPEL 2.0 之外，我们 BPEL 的其他发展以及相关标准包括对人工流程和子流程的显式支持。（有关 BPEL 2.0 的更多信息，参阅 OTN 上“新 SOA 标准”系列的技术白皮书。）

人工流程

BPEL 旨在实现建模为 Web 服务的服务间的交互。这意味着，它不通知任何有关人工交互和手动流程的步骤。但是，由于 BPEL 具有对异步服务的丰富支持，可以将人工流程服务实现为，使人工和手动步骤从流程角度看起来像其他任何异步服务。该方法的优势在于，BPEL 流程可以保持百分之百的标准，而手动和自动系统交互可以轻松编制。Oracle 已将该方法用于 Oracle BPEL 流程管理器的人工流程服务。

使用此方法，用户交互的范围从简单的方案（例如，流程中的手动批准步骤）延伸到复杂的方案（其中用户必须输入数据才能使流程继续）。现在有一个积极的标准化工作正在进行中（称为 BPEL4People），它旨在标准化该方法论以将人工任务合并到 BPEL 流程。

业务规则

业务规则是将业务的特定操作或策略抽象为外部化描述的方式。使用能够将经常变化的业务逻辑具体化为业务规则的开发方法（而非将它们嵌入在服务和流程中），使业务在描述其操作、定义和约束时能够保持敏捷。业务能够更有效地响应更改，因为规则集中在一个信息库中，从而可从核心业务流程分别管理它们。

以下是当敏捷需要可通过抽象业务规则来满足时的一些示例方案：

    定期或经常改变的业务逻辑（例如，定价规则和促销）
    复杂的决策逻辑难以使用诸如 BPEL 或 Java 的语言实现
    合规要求

Monster Worldwide 认为 Oracle SOA 套件是合适的解决方案，这主要因为其组件产品的紧密集成。这些组件之一是 Business Rules Engine，它与 BPEL 结合使用时允许划分我们的业务逻辑。例如，Monster 使用业务规则进行销售定单的定单项税款计算。Monster 的规则还包括业务特定的规则，例如，描述工作和简历在工作搜索站点中的张贴位置的规则。

有两个主要的结构方法可用于在 SOA 中包括业务规则引擎。业务规则可以在实用工具服务层实现。这些规则是按通用方式设计的，可以提供能够从多个地方利用的决策服务。业务规则还可以实现为具有特定业务行为的服务。无论是实用工具服务还是业务服务，当业务规则作为编制的流程的一部分时，它们能以更灵活的方式指定流程后台的逻辑和流，而不是使用过程编程语言进行硬编码。我们推荐一个非常好的实践：组织考虑业务规则适用于业务流程的何处，并使用业务规则产品为业务用户定义和执行这些规则 — 在适当的时候友好地编辑可用界面。

设计模式

设计模式是“对所遇到问题的解决方案”；即，它表示对设计中重复出现的问题的高质量解决方案。在过去几年中，设计模式在 IT 界非常引人注意，而我们现在注意到服务编制设计模式的出现。这里我描述几个此类模式。

错误诊断 (Error Hospital)。 该模式将异常处理作为服务提供。要最大化流程简易性和性能，需要将业务流程设计为简单的异步流程甚至短期同步流程。当出现异常时，消息会发布到错误诊断过程，然后提供所需的异常管理，包括人工服务（如果需要）。

很多服务编制模式在诸如 Oracle BPEL 流程管理器的编制引擎中实现：

    组合服务。 将多个服务的功能合并到一个组合服务中，并将其作为一个整体提供给感兴趣的客户。BPEL 通过自动将每个过程作为服务提供来支持这一点，这些服务可用作构建块来构建较高级的复合流。
    编制引擎。 使用可运行在编制引擎上的标准语言（例如，BPEL）显式指定与编制相关的控制流和数据流。编排引擎可以提供基础架构服务，例如，审计线索、长期运行流的持久性、常见异常处理模式，等等。
    服务补偿。 以与松耦合、无状态服务和长期运行流程结合的方式提供事务性支持。
    编制实例。 创建用户并允许其独立观察并管理业务流程的并发实例。

Monster 在我们的集成中间件的体系结构中使用了大量设计模式。

    有保证的提交
        消息发送者如何确保其消息提交到 BPEL 编制引擎中的相关流程（即使消息处理系统失败）？
            在将消息传送到 BPEL 编制引擎之前以事务方式将消息保留到数据存储。每次都要删除在前一流程前保留的消息。

    消息历史和审计日志
        如何在松耦合系统中分析和调试消息流？
            为消息附加消息历史以列出消息从产生以来经过的应用程序和组件。

    过滤器
        如果消息包含多个元素（每个元素可能经过不同处理），如何处理消息？
            将组合消息分为一系列单独消息，每个包含与一个项相关的数据。

    消息存储
        如何在不破坏消息处理系统的松耦合和临时特性的前提下报告消息信息？
            在中心位置（独立于基础编制引擎平台的事务性数据存储）捕获每个消息的信息。

    异步请求回复
        当应用程序发送消息时，它如何从服务器获取响应？
            发送一对请求-回复消息，每个消息在它自己的信道上并通过消息主体数据或 WS-Addressing 关联。

    聚合函数
        如何合并相关联的单个消息的结果，以便将它们作为整体进行处理？
            使用会话状态的过滤器收集并存储单个消息，直到它接收完整的相关消息组。然后，发布从多个单独消息浓缩提取的单个消息。

测试编制的 BPEL 流程

当涉及到编制多个服务的长期运行的异步流程时，测试变得既关键又复杂。要全面测试一个流程，需要满足以下情况：

    服务满足功能要求。每个服务需要单独满足定义的功能要求。此外，需要针对功能和服务质量要求单独测试每个流程。
    流程将模拟具有所有可能返回值（包括异常、超时和重试等）的服务之间的所有可能交互。测试应该在包括所有可能的正反面用例以及可能的异常处理选项的情况下进行。流程可在生产中伸缩。在 Monster，我们认为性能测试应该至少模拟预期最大事务量的 200%。
    对共享服务的修改不公开共享缺陷。确保服务中的更改不损害使用它们的应用程序。

结论

过去几年，我们看到诸如 BPEL 的业务流程编制标准以及诸如 Oracle SOA 套件的技术平台从出现到走向成熟。随着这些标准和平台的采用，开始出现一组非常好的实践和设计模式。我们希望诸如本系列的文章将鼓励更多用户分享其想法和知识。

在本文中，我们讨论了现今在大量业务应用中常见的大量业务流程编制特性和要求：长期运行的流程和人工流程、可靠的通信、Web 服务的使用、流程可持续性和补偿处理。

诸如 BPEL 的新标准和 Web 服务的强大之处在于它们的抽象和平台基础架构，它们本身就可以提供这些功能，以便 IT 组织可以编写较少的衔接代码。有了这些工具，我们相信企业能够获得比以前更强健、更灵活的业务流程自动化和监控。