由于众多原因，企业服务总线(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组织可以编写较少的衔接代码。有了这些工具，我们相信企业能够获得比以前更强健、更灵活的业务流程自动化和监控。