WS-BPEL研究综述1
周进刚，纪勇，王伟
东软软件股份有限公司基础软件事业部，辽宁大连（DS006850）
E-mail：
摘要：随着Web服务技术的成熟和SOA（面向服务的架构）的研究与应用，WS-BPEL（Web Services Business Process Execution Language，业务流程执行语言）成为面向服务计算（SOC）领域研究的热点，并成为SOA应用中的核心技术。围绕BPEL，人们开展了多方面的理论与应用研究。本文首先探讨了Web服务堆栈中与BPEL密切相关的标准技术，然后从工作流相关模式、形式化建模与验证、BPM（Business Process Modeling）领域中BPEL与其它语言模式的比较、转换和集成、面向服务的计算、网格计算和自治计算（Autonomic Computing）等几方面对近年来和当前BPEL相关的领域研究进行了综述，最后对BPEL的发展做了展望。关键词：BPEL，Web服务，BPM，SOA，面向服务计算
中图分类号：TP311
1引言
WS-BPEL（Web Services Business Process Execution Language，业务流程执行语言，以下简称BPEL）是一种从工业界诞生的标准，由于受业界主流服务及技术提供商的拥护和推崇，使得其迅速成为Web服务编排领域事实上的标准，从而使得无论是工业界还是学术界都对其产生了浓厚的兴趣，并围绕BPEL展开了多方面的理论与应用研究。
北京验车
本文首先对BPEL的基本概念进行介绍，之后根据近年来各研究机构和个人对BPEL所作的研究将其分为如下几个研究方面：介绍Web服务支撑技术；工作流相关模式；形式化建模与验证；相关标准间的比较、转换与集成；面向服务的计算2；网格计算；自治计算进行分别介绍，最后对BPEL的研究进行总结与展望。
2BPEL概述
2.1BPEL发展历史
BPEL的前身是Microsoft的XLANG[1]和IBM的WSFL[2]。02年8月，IBM、Microsoft 和BEA为了规范和统一业务流程建模，结合了WSFL和XLANG两种语言的特点，联合发布了BPEL4WS （Business Process Execution Language for Web Services）1.0[3]。BPEL4WS 1.0的发布并没有引起业界的广
泛关注，它只是拉开了BPEL发展的序幕。随后，在Siebel（现已被Oracle公司收购）和SAP的协力帮助下，BPEL4WS 1.0的改良版BPEL4WS 1.1[4]在2003年5月发布，这是一次具有里程碑式的版本升级，同时，BPEL被移交给OASIS（Organization for the Advancement of Structured Information Standards），OASIS成立了WS-BPEL TC （Technical Committee，技术委员会）来负责BPEL（此后，BPEL4WS改称为WS-BPEL，简称BPEL）的升级和技术支持。这使得BPEL开始转变成为业界的标准，此后BPEL引起了业界200多家大公司（包括IBM、Microsoft、Oracle、SAP、BEA、Sun、Unisys、Syba、HP、CA、Collaxa、Choreology、Adobe、NEC）和科研机构的重视和拥护，成为BPM在
1本课题得到国家高技术研究发展计划（863）“支持多企业业务协同的集成平台研究与开发”（项目编号：
2006AA04Z166）的资助。
2广义上讲，网格计算和自治计算都属于面向服务计算的范畴，但由于近年来网格计算和自治计算得到人们的极大关注而成为研究的热点，为了展示BPEL在这两个领域的研究现状，我们把它们独立出来。
演讲比赛新闻稿
老年人活动
Web服务编排领域事实上的标准。2007年4月12日，WS-BPEL TC表决通过了BPEL 2.0标准[5]，使得BPEL在语言完整性、严谨性上更进一步。
2.2BPEL核心概念
文献[6-8]对BPEL的相关概念作了深入而详细的介绍。BPEL业务流程的描述完全采用XML格式，流程分为抽象流程和可执行流程，分别用于不同场景，但两者共用同一套语法元素。这些语法元素的功能包括控制流程逻辑执行顺序、用来执行Web服务调用、Web服务实现、事件响应、故障（及补偿）处理、流程实例匹配（采用相关集）、变量定义与赋值等。BPEL支持域（scope）的概念，一个流程中可用包含（并且支持嵌套）多个域，域范围内可以定义自己使用的变量、故障处理程序和补偿处理程序。BPEL中流程与外部服务间的联系及关系用伙伴链接（Partner Link）来表示，消息类型定义使用XML Schema [9]，数据变量的操作采用XPath[10]和XSLT[11]。BPEL流程就是通过BPEL语法元素把多个细粒度的Web 服务编排（orchestrate）为粗粒度的、有状态的服务的流程。BPEL的主要概念如1[6]所示：
赫兹实验
XLANG是基于π-演算[40]理论的流程语言，易于编程，提出了类似编程语言的元素，像quence、while、if等结构块这样的控制流，而WSFL是基于Petri网理论的流程语言，在结构上是有向图的方式，它通过活动间的link来进行流程遍历。BPEL中的主要概念元素来自XLANG，但是flow元素及相关的死路删除（deadpath elimination）的概念来自WSFL。BPEL比XLANG和WSFL更加高级，它支持流程变量和全局的事件处理，此外，BPEL在Web服务交互上定义了明确的方向，比XLANG和WSFL更加清晰[41]。
3Web服务支撑技术
BPEL在Web服务堆栈中是处于一个高层的位置，受低层Web服务相关标准的支持，
图1 BPEL核心概念
Fig1 Major concepts of BPEL江苏旅游攻略
其中与BPEL密切相关的有：WS-Addressing [12] 、Web服务安全、WS-Policy、WSDL [22, 23]、Web服务事务、WS-Notifications [35-37]。
WS-Addressing为BPEL实现异步Web服务回调提供了标准化的途径。它通过端点引用（endpoint reference）和消息寻址属性为消息在多方传输中的路由和将消息响应发给第三方（或原服务请求调用者）定义了一个标准的方法。文献[17]介绍了Oracle BPEL Process Manager和Microsoft WCF（Windows Communication Foundation）这两种对WS-Addressing 有不同实现版本产品间通过WS-Addressing进行服务调用的示例，阐述了当前主流WS-*服务提供商在WS-Addressing互操作上的应用现状。2002年4月，IBM和Microsoft联合发布了一个概要描述Web服务安全架构和路线图的白皮书[13]，提出了在Web服务环境下描述安全的策略。这个白皮书定义了一个非常广泛而全面的Web服务安全模型，支持、集成和统一了多个流行的安全模型、机制和技术，使得多种系统可以在平台无关和语言无关的方式下安全的互操作。这个白皮书在今天仍然具有指导意义，其中描述的安全模型包含的基本组件包括：WS-Security [14]、WS-Policy、WS-Trust [15]、 WS-Privacy 、WS-SecureConversation [16]，共同构筑了一个可信任会话、安全策略描述及提供消息完整性和机密性保护的环境。当前的Web服务安全依然要靠SSL/TLS来提供传输层的安全性。WS-Policy 提供了一个通用模型和语法来描述Web服务系统中实体的能力、要求和一般特性。它定义了一个框架和一个模型，将这些特性表示为策略。策略表示法既支持简单的声明式断言，也支持比较复杂的条件式断言，策略
断言拥有说明特定Web服务的功能和约束。此外，WS-*中还为WS-Policy提供了许多扩展来提供额外功能：WS-PolicyAttachements[18]定义了用于将 WS-Policy 表达式与 Web 服务（即WSDL）关联的若干方法；WS-SecurityPolicy[19]描述 WS-Security、WS-Trust 和WS-SecureConversation 的 Web 服务的约束和功能；WS-ReliableMessaging Policy[20]说明实现 WS-ReliableMessaging[21]的 Web 服务的功能和约束。随着BPEL引擎的服务调用变得更加普遍，BPEL引擎的实现者需要把他们的实现建立在一个可以理解和增强策略的Web服务框架上。WSDL（Web Services Description Language）基于XML格式将Web 服务描述为能够进行消息交换的服务访问点的集合，为分布式系统提供了可机器识别的SDK文档。当前广泛应用的是WSDL 1.1[22]版本，但由于其在扩展性方面的局限使得它很难与WS-Addressing和WS-Policy等标准相集成，目前W3C正在起草、制定WSDL 2.0[23]的语法规范。BPEL中定义了基于域的故障补偿处理机制事务模型，但这种单一的事务处理模型并不能适应处理当前分布式计算的所有方面，比如：它没有提供一个显式的提交通知，而这对电子交易来说是很重要的；它没有为各服务参与方提供明确的事务环境传播方法；它没有提供对部分执行的域进行补偿的机制，这就迫使流程设计者把域的规模变小，从而导致工作单元在流程中的大小不协调。Web服务堆栈中提供了可供BPEL利用的三种低层事务通信模型：BTP[24]、WS-Transactions[25]和WS-CAF[26]。BTP是一个定义了参与事务的服务如何在事务中运转和发送什么消息的互操作协议。对于原子事务，BTP采用两阶段提交协议，对于由原子事务聚合而成的聚合（cohesion）事务，BTP采用一个事务协调器，由协调器决定哪些服务要提交，哪些可以回退，从而简化了两阶段提交协商中“all or nothing”的
处理方式，因为其对现实中的业务事务限制太强。WS-Transactions是三个标准的结合：WS-Coordination[27]、WS-AtomicTransaction[28]和WS-BusinessActivity[29]。WS-Coordination 为使Web服务环境下服务间能有一个通用的协调框架定义了协调上下文格式；用来创建协调上下文的协议；协调上下文传递的方式和服务参与的注册协议。WS- AtomicTransactions 定义的原子事务具有“all or nothing”的性质，与X/Open定义的原子事务基本是相同的，唯一
的不同是WS-Transactions为XA通信进行了SOAP形式的包装。WS-BusinessActivity定义了可以插入 WS-Coordination 模型，以实现长期运行的、基于补偿的事务处理协议。文献[31]对WS-BusinessActivity和BPEL中的长运行时（long-running）事务进行了对比。WS-CAF 为管理共享上下文环境和保障业务流程获得可预知的结果和从故障中恢复提供了互操作机制，它包括三部分：WS-CTX [32]（一个简单的内容管理框架）；WS-CF[33]（用来管理内容扩充及其生命周期，并保障消息发送的可共享机制）；WS-TXM[34]（包括ACID事务、长运行时行为和业务流程事务来分布支持不同事务模型间的互操作）。事件驱动和基于事件的交互是通用的通讯模式，由此产生的事件驱动的架构（Event-Driven Architecture, EDA）也是企业应用架构技术研究的热点之一。WS-Notification提供了一个标准化的方法，用于给一个Web服务（或其他实体）向其他Web服务集合发布消息（事件），使得Web服务能够以目前在其他领域中广泛使用的对象交互方式来进行通信。WS-Notification制订（包
含）了如下标准：消息生产者和消息消费者间的互操作（WS-BaNotification[36]）；消息通知代理间的互操作（WS-BrokeredNotification[37]）；用来开发主题分类的标准机制和标准化的概念和术语（WS-Topic[38]）。文献[39]为WS-Notification标准家族设立了目标和需求，并描述了每一个标准。
4工作流相关模式
工作流相关模式是指业务流程建模中流程控制逻辑模式和服务间相互交互产生的消息（事件）交互模式。同时，为反映在BPEL扩展规范上所取得的进展，我们把它们分列出来为：人工交互模式、子流程模式和BPELJ。
4.1业务流程模式
埃因霍温科技大学的W. M. P. van der Aalst和昆士兰科技大学的Nick Rusll等人对业务流程模式进行了研究，并在文献[42]中将业务流程的流程控制逻辑抽象为20种业务流程模式，分为6大类别：基本模式；高级分支与合并模式；结构模式；多实例模式；基于状态的模式和取消模式。随后，van der Aalst和Nick Rusll等人对业界的业务流程语言（或标准）及相关产品进行了流程模式上的评估，发布了一系列的研究评估报告，并在文献[43]中分析了BPEL 1.0对这20种流程控制模式的支持情况。随着BPM的发展，为了使流程模式能够更加完整和准确地反映当前最新的业务流程适用的场景，van der Aalst和Nick Rusll等人在文献[44]中提出了43种流程控制模式，在原有20种的基础上新增23种，并
分析BPEL、IBM BPEL、Oracle BPEL及其它流程建模语义和相关产品对这43种模式的支持程度。同时，为了捕捉工作流中数据的表现和使用方式，van der Aalst和Nick Rusll等人通过对既有工作流管理系统和业务流程建模语言的分析，在文献[45]中抽象了39个工作流数据模式，把它们分为：数据可见性；数据交互；数据传输机制和基于数据的路由4大类分别进行了详细描述，并总结了BPEL 1.1及其它工作流系统和建模语言对这些数据模式的支持程度。此外，van der Aalst和Nick Rusll等人还在文献[46]中分析和总结了5大类异常类型：Work Item Failure、Deadline Expiry、Resource Unavailability、External Trigger和Constraint Violation，并总结了BPEL 1.1和其它一些工作流系统及业务流程建模语言的异常处理模式。
4.2消息（事件）交互模式
SAP的Alistair Barros和其他科研人员对服务交互及消息处理方面做了一系列的研究工作。他们在文献[47]中将服务交互抽象为13种交互模式，并根据服务交互参与方的数量、交
互双方的消息交互数目以及双向交互中响应接收者是否是原有请求的发送者，把这13种交互模式分为单发双边交互；单发多边交互；多发交互和路由4组，同时详细分析了BPEL和WS-Addressing对这些交互模式的解决方案。文献[48]对在业务流程（或其它长运行时的会话）服务中消息相关性（correlati
on）进行了研究，将其抽象为19种消息相关性模式，并详细分析了BPEL 1.1和BPEL 2.0对各种消息相关性模式的支持程度。文献[49]从流程定义模型角度对复杂事件处理（Complex Event Processing, CEP）的消息交互抽象为13种复合消息（事件）模式，以此为基础分析了BPEL和BPMN[122]对这13种复合事件模式的支持程度。此外，文献[69]提出了一个引擎无关的事件模型，用来描述流程、活动、域、循环和链接的生命周期中相关的事件和流程的外部激发事件。
4.3人工交互模式
BPEL作为BPM领域中的生力军，虽然广受业界的支持而成为了事实上的标准，但是在语言层次上仍然缺少BPM中的一些重要概念（像人工活动、子流程等），为此，IBM、SAP 希望通过以BPEL扩展规范的形式将人工活动及子流程的概念标准化并将其纳入BPEL阵营。BPEL4People[50]是IBM和SAP在2005年7月联合提出的，目的就是以标准化的形式把人工工作流任务项引入到BPEL流程中，2007年6月，IBM、BEA、Oracle、Active Endpoints、SAP、Adobe等六家SOA领域的厂商共同发布了BPEL4People1.0规范和WS-Human Task1.0[160]规范。BPEL4People1.0负责定义基于BPEL的扩展，即在BPEL流程中通过什么样的语法定义人工节点。WS-Human Task1.0负责人工任务的生成、状态管理、与流程的交互，即用户通过WS-Human Task1.0完成任务的查询、签收、修改数据、完成工作项等任务。BPEL4People1.0和WS-Human Task1.0语法和设计架构全部基于面向服务的思想，这和BPEL 是一致的。
死亡隧道
BPEL4People中并没有定义用户（人工活动参与者）查询语言，在实现中可以采用LDAP、SQL、XQuery[52]，对于参与者的指定可以是流程设计时、发布时或运行时。目前，IBM在WebSpeher中已经实现了符合BPEL4People的人工任务实现[53-55]。BPEL4Peope的出现也引起了另一个更要的问题就是：是否有必要引入这么复杂的扩展来支持人工任务[56]？在BPEL4People出现之前，一些软件提供商像Oracle把用户交互建模为另一个Web服务，由此，所有的接口都通过WSDL，不用给BPEL添加任何扩展，需要的就是在整个业界在此服务接口上达成一致。
4.4子流程模式
当前，BPEL中不支持工作流中子流程的概念，虽然在一个BPEL流程中可以调用另一个BPEL流程，但是由于BPEL流程间的相互访问都是通过Web Service，彼此间是松耦合的，流程间是平等的调用。缺乏子流程的概念使得BPEL在如下两方面功能欠缺[57]：z模块化和流程复用；
z父子流程间的紧耦合。
为此，IBM和SAP联合发布了BPEL-SPE（WS-BPEL Extension for Sub-process）[51]，目的是要满足如下目标：
z允许一个业务流程以子流程的形式来调用另一个业务流程，以使后者的生命周期与父流程（前者）是紧耦合的；
z允许在一个业务流程中定义另一个业务流程，以使后者可以在前者范围内被使用
一聚
（或复用）；
z允许一个定义在另一个业务流程环境中子流程可以访问父流程的数据；
z允许跨越BPEL引擎的子流程的调用，以使一个BPEL引擎中运行的流程可以调用另一个BPEL引擎中的子流程。
规范中描述了两种子流程的定义（standalone和inline），以及父流程和子流程间不同的调用模型和在不同环境下的交互性。
4.5BPELJ
过的四字成语
BPELJ[58]提出了将BPEL与Java结合的技术路线，它是由BEA和IBM联合提出的，此项技术允许同时使用这两种编程（“宏观”编程和“微观”编程）语言来构建业务流程应用。通过实现BPEL和Java的协同工作，BPELJ最大限度地发挥了每种语言的长处。BPELJ允许在BPEL流程定义中引用Java代码片断（称为Java Snippet），从而实现了Java和BPEL的融合。理论上，BPELJ的引入破坏了BPEL代码的
可交换性（Java代码如何在一个非Java 环境下运行呢？），但实际上许多BPEL引擎开发商都引入了类似的BPEL扩展，IBM和Oracle的BPEL引擎可以非常有效的支持BPEL中的Java代码片断。
对于是否引入其他编程语言来处理非BPEL胜任的工作，还有另一种解决方案，就是把由其他编程语言所实现的功能包装为Web服务，通过WSDL来描述，而通过BPEL来调用[59]。这是一种“无侵入”的途径，不需要对BPEL做任何改动，纯BPEL解决方案。WSIF（Web Services Invocaiton Framework）就是用于此目的一个技术框架，它可以调用由WSDL描述的Java类、EJBs（Enterpri JavaBeans）、JMS（Java Message Service）等资源。但同时，这种纯BPEL式的解决方案带来了另外的问题，那就是如果把所有的类似功能都要由Web服务来实现的话，就会产生非常多的小粒度的Web服务，这对于面向流程的编程通常都是粒度不匹配的，也不符合SOA的思想，而且还会对流程复杂性和性能带来影响，远没有Java 代码片断来的自然。
5形式化建模与验证
围绕BPEL相关的形式化建模方法、建模工具、形式化验证，人们作了大量的研究，文献[60]对BPEL相关的建模方法、工具、验证等作了详细的综述，除此之外，文献[68]基于模型检测技术，采用MuSMV model checker 对形式化后的BPEL流程的有效性及正确性进行自动化的验证。文献[61]提出了一个利用形式化方法，并集成原有BPEL流程模型中的机构来自动的生成相容的伙伴BPEL流程的方
法，以此减少在BPEL流程建模和合成方面的复杂性与易错性。文献[62]提出了一个对BPEL数据有效性进行验证的框架，它首先将BPEL描述的工作流转化为数据流网络（dataflow network），进而将其转化为需要验证的PROMELA （Process Meta Language）模型，然后通过SPIN model checker 对其中的线性时序逻辑（linear temporal logic, LTL）表达式进行验证，同时提供了故障仿真。文献[66]提出了一个基于模型的验证框架，其通过模型检测技术对BPEL流程采用UML活动图来建模，然后通过基于原模型的转化框架将UML活动图映射为PROMELA模型，这样通过SPIN model checker对定义阶段流程的正确性进行验证。文献[63]从流程安全出发，提出了一个在BPEL中集成基于角色的访问控制（Role Bad Access Control, RBAC）机制的形式化框架，使得可以通过时序逻辑来描述授权约束，然后可以通过模型检测（model-checking）技术来验证一个BPEL流程是否满足指定的安全约束。文献[64]通过将BPEL流程转化为π-演算，通过模型检测技术
