1 简介
　　业务流程管理(BPM)可以看成是工作流、企业应用集成和Web服务的完美结合，用来建构实现企业内或企业间的业务协作，是流程自动化和系统设计领域的最新发展方向。目前，已经出现了一些业务流程建模的语言，如WSFL(Web Services Flow Language)、XLANG(Web Services for
　　Business Process Design)、BPEL4WS(Business Process Execution Language for Web Services)、BPMLfBusiness Process Management)、WSCI(Web Service Choreograph Interface)等，其中最有影响的是BPEL4WS和BPML。但国内在它们的性能评估方面却很少甚至几乎没有进行什么工作。而若对其加以比较评估，必将有助于在其间建立一致性和互余性，确定其性能和局限性，及检测其不一致性和多义性。作为在这个方向上的初步探索，文中对这两种语言中进入较深入的比较与分析。
　　本文的分析建立在工作流模式和通讯模式两方面之上。其中，工作流模式(WPS)已经通过对现存的工作流语言的分析而编制出来了，它们通常捕获工作流建模过程中遇到的那些典型的控制流依存关系。WPS定程度上适合用以分析BPM，因为它们所捕获的情况与该领域也相关。另一方面，通讯模式(CPS)与系统模型在EAI环境中进行交互的方式有关，并按同步．异步和点到点，广播两种划分标准来加以组织。考虑到在EAI和BPM技术之间存在很多重叠，因而一定程度上通讯模式也适合用以分析BPM语言的通讯建模能力。
　　本文随后部分安排如下：第2节概述BPEL4WS和BPML，第3与第4节分别运刚：C作流模式和通讯模式对两者进行比较与分析，最后，在第5节得出结论。
　　2 概述BPEL4WS和BPML
　　BPEL4WS(Business Process Execution Language for Web Services)是融合IBM的WSFL(Web Services Flow Language)和微软的XLANG(Web Services for Business Process Design)而成的一个BPM标准；而BPML是由BPMI．org所开发和倡导的另一个重要的BPM标准，受到包括SunIntalio、SAP和Versata在内的许多组织的支持。BPEL4WS把继承自XLANG的块结构语言的特点与源自WSFL的有向图的特点有机地结合了起来，以支持流程的建模。BPEL4WS流程中的每个元素被称作活动(activity)，一个活动既可以是基本的也可以是结构化的活动。基本活动集包括：调用(invoke)，在某个web service上调川某个操作：接受(receive)，等待来自外部资源的消息；应答(reply)，对外部资源进行应答：等待(wait)，等待一段时间：分配(assign)，将数据从一处拷贝到另一处；抛出(throw)，指示执行过程中的错误；终止整个服务实例：空，什么也不做。为了能表达复杂的结构，又定义了几种结构化活动：次序(sequence)，定义执行顺序；开关(switch)。处理条件选择；while，处理循环；挑选(pick)，处理基于计时或外部触发器的竞争条件；流(flow)，处理并行路由选择：域(scope)，把将由同一故障处理程序进行处理的活动加以分组。这些结构化活动能随意地组合或嵌套。在并行执行的活动的范围内，执行顺序还可能进一步地由另一结构化活动链接(1inks)来控制，链接有时也称作控制链接或受限链接，并可以用有向图来定义，这些有向图可以嵌套但不能循环。
　　BPML的，相对应地，主要成分有活动(activity)、流程(process)、上下文(context)、性质(property)利信号(signal)。
　　活动是执行特定功能的组件，主要有两种：简单活动和复杂活动。简单活动具有原子性，包括有action(执行或调用交换输入／输出消息的单个操作)、assign(为property指定新值)、call(实例化一个流程并等待其完成)、compensate(为给定的流程调川校正操作)、delay(等待一段特定的时
　　间)、empty(不做任何事情的操作)、fault(于当前上下文中抛出故障)、raise(引发信号)、spawn(实例化一个流程但不等待其完成)和synch(等待某个信号被引发)等几种：而，复杂活动可分解成更小的活动，包括all(将活动并行执行)、choice(对多个选择进行抉择)、foreach(逐一执行列
　　表的各个元素)、sequence(依次执行各活动)、switch(有条件地执行活动集中的某一个)、until(根据山口条件执行活动一次或多次)和while(根据出口条件执行活动零次或多次)等几种。
　　流程就是一个能被其它流程调用的复杂活动：上下文为相关联的活动定义一个执行环境，供其交换信息并协调其执行；性质可以被视作流程的属性(或实例变量)；信号用以协调在共同的上下文中的活动的执行情况，但不同于通过诸如sequence等基础结构处理方式。
　　3 BPEL4WS和BPML中的工作模式
　　业务流程管理(BPM)和工作流管理都与可执行流程相关，可见两者是关联的。因此，工作流管理系统的许多功能也就与BPM建模语言(主要是BPEL4WS和BPML)相关了。
　　在本节。本文将考虑如下20种工作流模式，并据此讨论BPEL4WS和BPML如何支持这些模式以及支持到何种程度。
　　WPI Sequence一个活动完成之后，在工作流的同一流程中的另一个活动才能启动。BPEL4WS中对这种模式有两种可能的解决方案，一是使用继承自XLANG的sequence操作符(如Listing l所示)，二是使用继承自WSFL的control link概念(如Listing 2所示)：BPEL中则很简沽，用sequence直接支持。BPEL4WS中，①并行分裂是通过定义那些将作为flow活动类型的组件而并行运行的活动来实现的。若在某个flow中没定义任何控制链接，则其中的活动并行执行；若在该flow后添加一个活动，本模式就能转化为同步模式(Synchronization)。②与WPl相似，基于控制链接的方案对于WP2和
　　WP3也是可行的。BPEL中，①并行分裂是通过定义那些将作为复杂活动类型all的组件而并行运行的活动来实现的，②也可以用活动spawn和synch来代替复杂活动all以启动和将并行活动同步。
　　WP4 Exclusive Choice根据某个判定或工作流控制数据，对一个或多个分枝做出选择。WP5 Simple Merge将两个以上分枝合并起来，而无需同步。本模式中假定这些可选的分枝中没有一个并行执行过(否则，请参见Multi Merge和Discriminator模式)对WP4和WP5支持情况的分析：
　　BPML中，用活动switch来实现本模式。
　　BPEL4WS中，与前述模式相仿，也有两个方案。一种方案依赖于继承自XLANG(如Listing 3所示)的switch活动，每个case指定一个相应condition满足后将要执行的活动。另一种方案应用继承自WSFL的控制链接(如Listing 4所示)。各种条件(如Cl和C2)表示为transitionConditions，
　　一一对应于相应的链接(L1或L2)。这意味着只有相应条件满足后，规定为这些链接(例中的Al和A2)的目标的活动才会执行。这两种方案之间的区别之一是，在Listing 3所示的方案中，只有一个活动被触发，指定条件的第一个测试为真。相对地，在Listing 4所示的方案中，如果有多于一个的条件测试为真，则多个分枝可以被触发。若要确保只有一个分枝被触发，这些条件必须分开。如果不是这种情况，Listing 4则对下述的Multi Choice模式提供一种方案。WP6 Multi．Choice根据判定或控制数据，选择若干个分枝且以并行线程方式执行。
　　WP7 Synchronizing Merge将多个路径合并成一个单一的线程。其中部分路径是“激活的”(即正在执行中)而其余则不是。如果只有一条路径是激活的，则一等该路径合并完成后就触发活动：如果多条路径是激活的，则在触发下个活动前需要将所有激活态的路径同步。本模式中假定，一个已经激活的分枝，当其它分枝仍在等待完成合)寸，不得再次激活。对WP6&wP7支持情况的分析：BPEL4WS对这两种模式都支持，且与WP4和WP5中WSFL形式的方案是一样的。这是消除死路径的原则所要求的，该原则要求入射链接的真实值要传播给出射的链接。在例子Listing 4中。如果条件cl(或C2)测试为真，活动AI(或A2)接受一个正值并由此而开始执行。另一方面，如果条件CI(或C2)测试为假，活动A1(或A2)接受一个负值，它将不能执行但仍将此负值传播给它的出射链接Lls(或L2s)。特别地，如果条件Cl和C2都测试为真时， A1和A2则均被执行。但任一种情况下，假如活动Al或A2之一执行着，则条件OR loinCondition都要附加给C，以确保C总是执行。
　　BPML对这两种模式却都不直接支持。虽然结合WP2、WP3、WP4和WP5，可以对Multi．Choice模式提供折中方案，但根据同步合并在流程中出现的位置，要想为Synchronizing Merge模式也提供一个折中方案，则十分困难。WPS Multi-Merge两个以上的分枝重新汇合而不必同步。如果一个以上的分枝(也可能并发地)激活了，紧随合并之后的活动就启动，以满足各个入射分枝的所有操作。
　　BPEL4WS不直接支持本模式。XLANG和WSFL也不允许在同一路径上有两个激活态的线程而不创建另一个流程的新实例；但BPML对本模式提供部分支持，如Listing 5所示。使用一个an活动和两个switch活动，启动活动acitivityA和(或)acitivityB。当两者中任一个执行后，流程就创建一个新实例activityC。因此，如果Cl和C2都测试为真，就能创建activityC的两个实例，也就实现了本模式。之所以认为是部分支持，是因为流程的其余部分还是必须要以分离的方式进行。从而限制了本模式的应用，尤其是当Multi．Merge嵌在一个循环中时。而且也因为这还涉及到创建另一个流程的新实例。WP9 Discriminator工作流等待入射分枝之一完成才再激活随后的活动。从这一刻起鉴别器(discriminator)就等待所有剩余分枝完成并“忽略”它们。当所有入射分枝都触发后，鉴别器重置以便能再次触发(这很重要，否则它不能真正地在循环中发挥作用)。BPEL4WS不直接支持本模式。既没有结构化活动用以实现它，也没有链接用以捕获它。不能在OR joinCondition中使用链接的原因是，当确定所有入射链接的状态时，首先测试的就是joinCondition(见上例)，而不会像本模式要求的那样，等到第一个正值链接确定之后。
　　BPML也不直接支持本模式，尽管使用活动spawn、raise和synch可提供一个折中方案。WPIO Arbitrary Cycles工作流在该点处，部分流程(包括一个或多个活动及连接口)需要被反复“访问”而对其数量、地点和嵌套情况不加限制。BPEL4WS不支持本模式，虽然while活动允许结构循环，但不可能跳转到流程的任意部分，即只能支持具有一个入口和一个出口中的循环。
　　BPML也不支持本模式，虽然活动while、foreach和until允许各种结构化循环，但同样也不可能跳转到流程的任意部分。BPEIAWS中，流结构支持隐式终。当其最外层活动完成时，结构化活动(没有流和链接)也就完成了，这相当于显式终止。使用流结构和链接，子流程可以拥有多个汇点活动(sink)(即非任何链接的源的活动)而不需要一个独特的终止活动。BPML中，使用spawn活动类型，可以将本不需要走到一起的不同分枝连到一个单一的终止点上。因此，BPML通过spawn活动类型的存在支持本模式。
　　WPl2 M1 without Synchronization在单个情况的上下文范围内，可以创建某个活动的多个实例，即存在一种创建新控制线程的功能，它们彼此相互独立。这些实例可以连续创建，但应能并行运行，使之与Arbitrary Cycles模式相区别。
　　BPEL4WS使用嵌套在while循环中的invoke活动，可以为某个活动创建多个实例：BPML则使用嵌套在while、until或foreach循环中的spawn活动，为某个活动创建多个实例。WPl3·WPl5 M1 with Synchronization启动某个给定活动的若干个实例，这些实例被同步之后，才再进行流程的剩余部分。在WPl3中，设计时就明确了将开始／同步的实例的数量；在WPl4中，于运行之后、开始启动实例之前的某些阶段才知道这些数量；而在WPl5中，将要创建的实例的数量无法事先知道，因为新实例都是由命令创建的，直到满足需要为止。
　　对于WPl3，如果设计阶段明确了将要同步的实例的数量，则BPEIAWS和BPML都可以一个简单的方案，即该活动需要实例化多少次，就将其复制多少次，然后将这些拷贝置于一个flow活动中并行运行：而如果(WPl4)将被创建或同步的实例数量只有在运行期间才能知道，或者(WPl5)无法预测，尽管可以实现本模式，但方案将变得很复杂，只能是一种折中方案，因为这些模式的逻辑不能由BPEL4WS或BPML的结构直接捕获。所以，很明显BPEL4WS和BPML都不直接支持WPl4和WPl5。
　　WPl6 Deferred Choice根据信息，流程在此点选取到达该点的数个可选分杖中的一个。这与通常的排他选择有所不同，当到达该点时，并不立即做出选择，而是代之以提供数个选项，并且延迟直至一些事件出现后才对它们进行抉择。BPEL4WS通过pick结构而BPML通过choice结构来实现本模式。pick的语义是等待若干消息之一的签收并据此执行下一步。而choice的语义是等待一个事件的到达并据此事件选择一个事先规定的路由，它们都描述了本模式的关键思想，即当到达某个特定点(即pick／choice活动)后并不立即做出选择。而是延迟直至收到消息。
　　4 结论
　　本文通过一个基于现有的工作流模式和通讯模式的框架，对BPEL4WS和BPML的性能进行了比较与分析，分析的结果汇总在表l中。表中单元格里的“+”表示直接支持(即该语言中有一种结构直接支持模式)，而“一”表示不直接支持。有时存在某种特征只部分支持模式，例如某个构件对流程的结构隐含一定的限制，这种情况支持的标称值记为“+／一”。
　　根据表l能得出以下结论：
　　一、对通讯模式，两种语言的支持情况完全相同。
　　二、而对于：作流模式，则有所不同：
　　1．因为前五种模式对应于基本的路由结构件，所以BPEL4W和BPML这两种语言都支持它们：相反，涉及到高级构件的模式通常在这两者中都缺乏支持。
　　2．两种语言都支持Implicit Termination、M1 without Synchronization、M1 with a Priori Design Time Knowledge、Deferred Choice、Cancel Activity、Cancel Case等模式。
　　3．两种语言都不支持Arbitrary Cycles、Discriminator、M1 with a Priori Runtime Knowledge、M1without a Priori Runtime Knowledge、Milestone等模式。
　　4．BPML不支持Multi Choice和Synchronizing Merge这两种模式，而BPEL4WS支持，这得益于BPEL4WS源自WSFL和IBM MQSeries的“死路径消除”特性。
　　5．BPML部分支持Multi Merge模式而BPEL4WS不支持，但是，BPEIAWS部分支持Interleaved Parallel Routing模式而BPML不支持。概括起来，BPEL4WS共直接支持17种模式，部分支持1种模式，不直接支持8种模式；相对应地，BPML的分别是15种、1种和lO种。应当说，BPEL4WS比BPML多支持2种模式，具有一定的优势。
　　三、但是，另一方面，业务流程建模都注重图形化语言(表1中没有显示出来)，以满足最终用户理解和交流流程模式之需。BPEIAWS作为XLANG和WSFL的继承者，自然拥有一些源自WSFL的图形化特点。而BPMI．org正积极研发BPMN(Business Process Modeling Notation)，以期实现一种专用的图形化语言，井可转换为BPML和BPEL4WS。这又使得BPML在图形化方面赢得了相当的优势。
　　综上所述。本文通过对BPELAWS和BPML的比较与分析，有助于理解两者之间的一致性和互余性以及其性能差异和各自的局限性。在根据业务流程建模的需要来选择采用它们时。希望本文起到一定的参考作用。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。