异常和补偿处理
通常，实现有用的业务流程用例（当一切准备就绪时）只是业务流程总体设计和实现工作的一小部分。大部分时间都花费在定义所有适当的异常处理逻辑上，以便构建在所有预期条件下（甚至在意外条件下）能够进行合理操作的强健且灵活的流程。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 组织可以编写较少的衔接代码。有了这些工具，我们相信企业能够获得比以前更强健、更灵活的业务流程自动化和监控。
