业务流程：理解 BPEL4WS，第 1 部分

业务流程：理解 BPEL4WS，第 1 部分

业务流程中的概念
2002 年 12 月

最近发布的 Web 服务的业务流程执行语言（Business Process Execution Language for Web Services，BPEL4WS）规范，其定位是成为整合方面的 Web 服务标准。您可以创建能够如完成 Web 服务调用、操纵数据、抛出故障或终止一个流程等工作的不同活动，然后将它们连接起来，从而创建出复杂的流程。这些活动可以嵌套到结构化活动中，结构化活动定义了其中的活动的运行方式，如是串行或是并行还是取决于某些条件。本系列文章的目的是让读者对 BPEL4WS 语言的不同部件有所了解，并教读者如何创建他们自己的完整的流程。本文是本系列的第 1 部分，将引领读者创建第一个简单的流程。后续的部分将以不同方式扩展这个示例，以便阐述并解释 BPEL4WS 语言的关键部分，包括数据操纵、相关性、故障处理、补偿以及 BPEL4WS 中的各种结构化活动。

引言
今天，Web 服务能够通过业界规范进行相互通信、公开自己、被发现和被调用。然而，直到上周，在将这些服务链接在一起以成为一个业务流程或一个整合时，用户仍需要从许多相互冲突的规范中作出选择 — IBM 的 WSFL 和 Microsoft 的 XLANG 之间正存在这种情况。Web 服务的业务流程执行语言（BPEL4WS）是 WSFL 和 XLANG 融合的产物，如果运气好的话，它将成为 Web 服务整合标准的基础。BPEL4WS 集 WSFL 和 XLANG 两家之长（前者支持面向图形的流程，后者则支持流程的结构化构造）于一身，形成了一个支持以极自然的方式实现各种类型的业务流程的结合性的软件包。除了是一种实现语言之外，BPEL4WS 同样还可以用来描述业务流程的接口 — 办法是使用抽象流程这个概念。我们将在以后的文章中进一步讨论这个问题。

BPEL4WS 的最初实现称为 BPWS4J，IBM 在 alphaWorks（请参阅参考资料）上也发布了这个最初实现。用户在学习和试验 BPEL4WS 时可以用这个实现来充当试验地。

我们在本文讨论的是 BPEL4WS 的基本概念。

BPEL4WS 的概念
BPEL4WS 支持两种截然不同的使用情形：

• 实现可执行的业务流程。
• 描述不可执行的抽象流程。

本文中着重阐述第一种情形；本系列以后将会有一篇文章来讨论 BPEL4WS 的一些抽象流程概念。

作为可执行流程的实现语言，BPEL4WS 的作用是将一组现有的服务整合起来，从而定义一个新的 Web 服务。因此，BPEL4WS 基本上是一种实现这样的整合的语言。与其它任何 Web 服务一样，整合服务的接口也被描述为 WSDL portType 的集合。整合（称为流程）指明了服务接口与整合的总体执行的配合情况。图 1 说明了从外部看到的 BPEL4WS 流程的上述情况。

图 1. 作为 BPEL4WS 流程实现的 Web 服务的视图

BPEL4WS 中出现的整合原语主要来自于工作流和业务流程集成方面多年的经验，因此，BPEL4WS 的定位是成为一种业务流程整合语言。

实现服务
上图云块中的是什么东西？不同于用传统的编程语言来实现 WSDL 服务，每个 portType 的每项操作并不映射成 BPEL4WS 中的一个独立的逻辑块。服务的整个类型（即该服务的 portType 集合）由单个 BPEL4WS 流程实现。这样，与调用接口操作的外部用户相对应的特定“入口点”在 BPEL4WS 描述中指明。这些入口点消费 WSDL 操作的从只输入（input-only）操作或输入-输出（input-output）操作传入的消息。对于后一种情况，流程还必须指明输出消息在哪里生成。BPEL4WS 只使用和支持 WSDL 只输入操作和输入-输出（请求-响应（request-response））操作；只输出（output-only）（通知（notification））操作和输出-输入（output-input）（要求-响应（solicit-response））操作既不需要也不支持。

BPEL4WS 流程本身基本上就是一个流程图，类似于用来表达算法的流程图。流程的每一步称为一个活动。存在以下一些基本活动：调用某个 Web 服务上的操作（<invoke>），等待一条消息来响应由某人从外部进行调用的服务接口的操作（<receive>），生成输入／输出操作的响应（<reply>），等待一段时间（<wait>），把数据从一个地方复制到另一个地方（<assign>），指明某个地方出错了（<throw>），终止整个服务实例（<terminate>），或者什么也不做（<empty>）。

通过使用语言所提供的任何结构化活动，可以将这些原语活动组合成更复杂的算法。这些结构化活动提供的能力有：定义一组步骤的有序序列（<sequence>），使用现在常见的“case-statement”办法来产生分支（<switch>），定义一个循环（<while>），执行几条可选路径中的一条（<pick>），以及指明一组步骤应该并行地执行（<flow>）。在并行地执行的一组活动中，您可以通过使用链接（link）来指明执行顺序方面的约束。

BPEL4WS 允许您递归地组合结构化活动，以表达任意复杂的算法，这些算法表示了服务的实现。

与其它东西交互：伙伴
作为一种用来将一组服务组合在一起以形成一个新的服务的语言，BPEL4WS 流程由向其它服务提出调用和／或接收来自客户机（图 1 中服务的用户)的调用组成。前者通过使用 <invoke> 活动来做到，后者则通过使用 <receive> 和 <reply> 活动来做到。BPEL4WS 把与流程交互的其它服务称伙伴（partner）。这样，伙伴或者是流程将其作为算法的一个主要部分进行调用的服务（被调用的伙伴），或者是那些调用流程的服务（客户机伙伴）。

第一种类型的伙伴是显而易见的 — 流程无疑必须调用其它服务以完成一些事情。<invoke> 活动指明要调用的伙伴以及要调用伙伴的哪个 portTypes 的什么操作。不过，请注意，被调用的伙伴最后同样也可以成为客户机 — 流程调用伙伴上的某个操作以请求某种服务这种情况是可能出现的。随后，伙伴将调用流程上的操作以提供所期望的数据。

把流程的客户机当作伙伴对待的原因可能并不这么显而易见。这样做实际上有两个原因：第一个原因是，有时流程可能会需要调用其中一个客户机伙伴上的操作。异步交互的主要支持机制如下：客户机调用流程上的某个操作以请求某种服务。一旦完成，流程会调用客户机伙伴上的操作。此时，客户机伙伴与被调用的伙伴已没有什么明显差别。

第二个原因是，流程所提供的服务可能被不止一个客户机使用（使用全部服务或使用服务的几个部件）。此外，流程可能会希望区别服务的这些不同用户。举例来说，一个表示贷款服务系统的流程提供了单个 Web 服务，但只有其中的一些部件是申请贷款的客户能访问的，其他一些部分则是客户服务代表能访问的，最终是整个服务则只有贷款担保人才能访问。根据某个操作是由客户还是由担保人调用的，所返回的行为可能会有很大不同。另外，由于使用伙伴来模拟客户机，所以流程可以指明某些操作只能被某些客户机调用。

因此，伙伴可以分为以下几种：

• 只由流程调用的服务。
• 只调用流程的服务。
• 或者既由流程调用又调用流程的服务（首先出现哪种情况都有可能）。

前两种分别是被调用的伙伴和客户机伙伴，它们都是简单明了的。请考虑第三种情况下流程首先调用服务时流程和服务之间的关系。这意味着服务提供了（或发布了）一个 portType（PT1），然后流程调用该 portType 的操作。同时，流程必须提供一个服务从其中调用操作的 portType（PT2）。这样，从流程的角度看，流程需要来自服务的 portType PT1 并提供 portType PT2 给服务。从服务的角度来看两者间的关系，则会得到一个相反的结论：服务提供 portType PT1 给流程并需要来自流程的 portType PT2。不管是流程首先调用服务还是相反，服务和流程的关系都同上所述。

服务链接类型
为第三种类型的伙伴建模时引出了服务链接类型。服务链接类型不是从这些参与方中的某一方的角度来定义服务和流程之间的关系，而是表示一种第三方声明，用这个声明来说明了两个（也可能是更多个）服务之间的关系。服务链接类型定义了一组角色，其中每个角色指明一组 portType。其思想是，当两个服务彼此交互时，服务链接类型就是对这两个服务如何交互 — 各方本质上提供了什么 — 的声明。

BPEL4WS 用服务链接类型来定义伙伴。基本上，伙伴是这样来定义的：给伙伴一个名称，然后指明服务链接类型的名称，确定流程在这个服务链接类型中将充当什么角色，确定伙伴将充当什么角色。对于纯被调用的伙伴和纯客户机伙伴的情况，服务链接类型中将只有一个角色，因而在定义伙伴时只指明了一个角色。伙伴名称随后将在 <receive>、<reply> 和 <invoke> 中用来指明所期望的伙伴。

服务引用
伙伴在运行时是如何工作的呢？为了能够在运行时工作，伙伴必须解析成实际的 Web 服务。这样，伙伴实际上最后就是一个有类型的服务引用而已，其类型信息来自服务链接类型和角色。BPEL4WS 流程本身不指定伙伴如何绑定到特定服务；人们认为这是一个部署时或运行时的绑定步骤，这个绑定步骤必须被 BPEL4WS 实现支持。

处理问题
开发者需要有处理业务流程中的错误和从错误恢复的手段。BPEL4WS 通过 <throw> 和 <catch> 构造在语言中内置了异常（故障）。BPEL4WS 的故障概念与 WSDL 的故障概念有直接联系，事实上，前者建立在后者的基础上。

此外，BPEL4WS 支持补偿这个概念，这是一种允许流程设计者为某些不可逆的动作实现一些补偿动作的技术。举例来说，设想有一个旅行预定流程。一旦确认了一项预定，则必须执行一些显式操作才能取消这项预定。这些动作就称为原始动作的“补偿动作”。

BPEL4WS 引入了作用域这个概念，从而递归地支持了故障处理和补偿，作用域本质上是故障处理和／或补偿的单元。详细理解补偿和故障处理，需要一篇以它们为主题的文章，将来会提供一篇这样的文章。

服务的生命周期
这些服务的生命周期是什么样的呢？作为 BPEL4WS 流程实现的 Web 服务有一个实例生命周期模型。也就是说，这些服务的客户机总是与服务（流程）的某个特定实例交互。那客户机如何创建服务的实例呢？

与传统的分布式对象系统不同，BPEL4WS 实例不是通过工厂模式创建的。相反，BPEL4WS 中的实例是在服务的消息到达时隐式地创建的。也就是说，实例不是用显式的“实例标识（instance ID）”来标识，而是用数据消息中的一些关键字域来标识。举例来说，如果流程表示一个订单实现系统，则发票号码可能就是用来标识交互所涉及的某个特定实例的“关键字”域。这样，如果当消息到达流程的“启动”点时没有可用的匹配实例，那么就会自动创建一个新的实例并与消息中的关键字数据关联起来。在定位到了合适的实例之后，只能在流程的非启动点接受消息；也就是说，在这些情况下，消息事实上总是被传送到特定实例。在 BPEL4WS 中，找到一个合适的实例或者创建一个合适的实例（如有必要的话）的流程称为消息相关性（message correlation）。将来也会有一篇讨论消息相关性的文章。

结束语
我们在本文简要地解释了 BPEL4WS 主要的底层概念。我们从总体上讨论了 BPEL4WS 是关于什么的，然后讨论了伙伴、故障、补偿以及生命周期。在本系列以后的文章中，我们打算详细地讨论 BPEL4WS 的各个特定方面。

［编者按：本专栏的每一期将交替地提供讲述 BPEL4WS 背后的概念的系列和讲述如何从技术上实现这些概念的系列。下一期将介绍技术实现。］

参考资料

• 请单击文章顶部或底部的讨论参加关于本文的讨论论坛。
• 从 alphaWorks 下载 Business Processes for Web Services Java Runtime。
• 阅读 Web 服务的业务流程执行语言 规范。
• 阅读以下相关文章：在 Web 服务中将业务流程和事务自动化 和 在 Web 服务世界中的业务流程。

作者简介 Sanjiva Weerawarana 是 IBM T.J. Watson Research Center 的 Component Systems 组的一名研究人员。他是 BPEL4WS 规范、WSDL 规范以及 WSFL 规范的作者之一，也是 BPWS4J、Apache SOAP、WSTK、WSDL Toolkit、WSIF 和 WSGW 的开发者之一。他获得了 Purdue University 的计算机科学博士学位。您可以通过 sanjiva@us.ibm.com 与作者联系。

Francisco Curbera 是 IBM T.J. Watson Research Center 的 Component Systems 组的一名研究人员，也是该组的主管。他是 BPEL4WS 规范、WSDL 规范以及 WSFL 规范的作者之一，也是 BPWS4J、Apache SOAP 和 WSTK 的开发者之一。他获得了 Columbia University 的应用数学博士学位。请通过 curbera@us.ibm.com 与他联系。