面向 Web 服务的业务流程执行语言(BPEL 或 BPEL4WS)是一种使用 Web 服务定义和执行业务流程的语言。BPEL 使您可以通过组合、编排和协调 Web 服务自上而下地实现面向服务的体系结构 (SOA)。BPEL 提供了一种相对简单易懂的方法，可将多个 Web 服务组合到一个新的复合服务(称作业务流程)中。

　　本文将介绍如何创建一个将一系列虚拟的、与旅行相关的 web 服务结合起来的示例业务流程，然后将其部署到 Oracle BPEL Process Manager 运行时环境。

　　BPEL 背景知识

　　首先，介绍一些背景知识。BPEL 基于 XML 和 Web 服务构建;它使用一种基于 Web 的语言，该语言支持 web 服务技术系列，包括 SOAP、WSDL、UDDI、Web 服务可靠性消息、Web 服务寻址、Web 服务协调以及 Web 服务事务。

　　BPEL 代表了两种早期工作流语言 – Web 服务流语言 (WSFL) 和 XLANG 的交汇。WSFL 由 IBM 基于有向图概念设计。XLANG 是一种由 Microsoft 设计的块结构化语言。BPEL 组合了这两种方法，并提供了丰富的词汇来描述业务流程。

　　BPEL 的第一个版本诞生于 2002 年 8 月。此后，随着许多主要供应商(包括 Oracle)的纷纷加入了，催生了多项修改和改进，并于 2003 年 3 月推出了 1.1 版。2003 年 4 月，BPEL 提交结构化信息标准促进组织 (OASIS) 以实现标准化，并组建了 Web 服务业务流程执行语言技术委员会 (WSBPEL TC)。该努力使 BPEL 在业界获得更广范围的认可。

　　在企业内部，BPEL 用于标准化企业应用程序集成以及将此集成扩展到先前孤立的系统。在企业之间，BPEL 使与业务合作伙伴的集成变得更容易、更高效。BPEL 激发企业进一步定义它们的业务流程，从而导致业务流程的优化、重新设计以及选择最合适的流程，进而实现了组织的进一步优化。BPEL 中描述的业务流程定义并不影响现有系统，因此对升级产生了促进作用。在已经或将要通过 Web 服务公开功能的环境中，BPEL 是一项重要的技术。随着 Web 服务的不断普及，BPEL 的重要性也随之提高。

　　编制与编排

　　Web 服务通常公开某些应用程序或信息系统的操作。因此，组合多个 Web 服务实际上涉及基础应用程序及其功能的集成。

　　可以用两种方式组合 Web 服务:

　　编制
　　编排

　　在编制(通常用于专用业务流程)中，一个中央流程(可以是另一个 Web 服务)控制相关的 Web 服务并协调对操作所涉及 Web 服务的不同操作的执行。相关的 Web 服务并不“知道”(也无需知道)它们参与了组合流程并在参与更高级别的业务流程。只有编制的中央协调员知道此目标，因此编制主要集中于操作的显式定义以及 Web 服务的调用顺序。(见图 1。)

　　图 1:通过编制组合 Web 服务

　　而编排并不依赖某个中央协调员。相反，编排所涉及的每个 Web 服务完全知道执行其操作的时间以及交互对象。编排是一种强调在公共业务流程中交换消息的协作方式。编排的所有参与者都需要知道业务流程、要执行的操作、要交换的消息以及消息交换的时间。(见图 2。)

　　图 2:通过编排组合 Web 服务

　　从组合 Web 服务以执行业务流程的角度而言，编制是一个更灵活的范例，它相对于编排而言具有以下优点:

　　元件流程的协调由某个已知的协调员集中管理
　　可以组合 Web 服务而不必使它们知道它们正在参与更大的业务流程
　　可以准备其他方案以防发生故障。
　　BPEL 支持两种不同的业务流程描述方法(支持编制和编排):

　　可执行流程允许指定业务流程的准确细节。它们遵循编制范例，并可由编制引擎执行。

　　抽象业务协议允许只指定双方之间的公共消息交换。它们不包含流程的内部细节并且无法执行。它们遵循编排范例。

　　现在，我们来逐步演示如何创建可执行的 BPEL 业务流程;可以下载它的代码并将其部署到 Oracle BPEL Process Manager。我们将假设已经按照安装指导成功安装了 Oracle BPEL Process Manager，并假设它使用缺省端口 9700。如果在安装过程中选择了其他端口，则必须相应地修改示例。

　　构建业务流程

　　BPEL 流程指定参与的 Web 服务的确切调用顺序 – 顺序地或并行地。使用 BPEL，您可以表述条件行为。例如，某个 Web 服务的调用可以取决于上次调用的值。还可以构造循环、声明变量、复制和赋予值、定义故障处理程序等。通过组合所有这些构造，您可以以算法的形式定义复杂业务流程。实际上，由于业务流程本质上属于活动图，因此使用统一建模语言 (UML) 活动图表示它们可能很有用。

　　通常情况下，BPEL 业务流程接收请求。为了满足请求，该流程调用相关的 Web 服务，然后响应原始调用方。由于 BPEL 流程与其他 Web 服务通信，因此它在很大程度上依赖于复合型 Web 服务调用的 Web 服务 的 WSDL 描述。

　　我们来看一个示例。一个 BPEL 流程由多个步骤组成，每个步骤称作“活动”。BPEL 支持基元活动和结构活动。基元活动表示基本构造，用于如下所示的常见任务:

　　使用 <invoke> 调用其他 Web 服务
　　使用 <receive>（接收请求）等待客户端通过发送消息调用业务流程
　　使用 <reply> 生成同步操作的响应
　　使用 <assign> 操作数据变量
　　使用 <throw> 指示故障和异常
　　使用 <wait> 等待一段时间
　　使用 <terminate> 终止整个流程。

　　然后，我们可以组合这些基元活动以及其他基元活动，以定义准确指定业务流程步骤的复杂算法。为组合基元活动，BPEL 支持几个结构活动。其中最重要的是:

　　顺序 (<sequence>)，它允许定义一组将按顺序调用的活动。
　　流 (<flow>)，用于定义一组将并行调用的活动
　　Case-switch 构造 (<switch>)，用于实现分支
　　While (<while>)，用于定义循环
　　使用 <pick> 能够选择多个替换路径之一。

　　每个 BPEL 业务还将使用 <partnerLink> 定义合作伙伴链接，使用 <variable> 声明变量。

　　为了理解 BPEL 是如何描述业务流程的，我们将定义雇员出差安排的简化业务流程:客户端调用此业务流程，指定雇员姓名、目的地、出发日期以及返回日期。此 BPEL 业务流程首先检查雇员出差状态。我们将假设存在一个可用于进行此类检查的 Web 服务。然后，此 BPEL 流程将检查以下两家航空公司的机票价格:美国航空公司和达美航空公司。我们将再次假设这两家航空公司均提供了可用于进行此类检查的 Web 服务。最后，此 BPEL 流程将选择较低的价格并将出差计划返回给客户端。

　　然后，我们将构建一个异步 BPEL 流程。我们将假设用于检查雇员出差状态的 Web 服务是同步的。由于可以立即获取此数据并将其返回给调用方，因此这是一个合理的方法。为了获取机票价格，我们使用异步调用。由于确认飞机航班时刻表可能需要稍长的时间，因此这也是一个合理的方法。为简化示例，我们假设以上两家航空公司均提供了 Web 服务，且这两个 Web 服务完全相同(即提供相同的端口类型和操作)。

　　在实际情形下，您通常无法选择 Web 服务，而是必须使用您的合作伙伴提供的服务。如果您有幸能够同时设计 Web 服务和 BPEL 流程，则应考虑用哪个接口更好。通常，您将对持续时间较长的操作使用异步服务，而对在相对较短的时间内返回结果的操作使用同步服务。如果使用异步 Web 服务，则 BPEL 流程通常也是异步的。