说明书一种基于令牌的支持并发侧面编程的BPEL扩展实现方法
技术领域
本发明涉及对BPEL面向侧面编程的扩展实现，特别是涉及侧面与BPEL原 工作流的并发与协作能力，为此提出了一种新的面向侧面编程语言模型，并扩展 了ODE引擎加以实现。
背景技术
BPEL(业务流程执行语言)是由OASIS提出的Web服务集成的标准执行 语言。是一个面向过程的支持Web服务集成的编程语言，该语言已经被Oracle， IBM，Apache等广泛支持以搭建面向服务的体系结构(SOA)。一方面与其它 面向过程(POP)和面向对象(OOP)的编程语言类似，BPEL中诸如调试，日 志，安全，商业规则等非功能性需求不能很好地从主要功能分离出来。面向侧面 软件开发(AOSD)是众所周知的解决方法。另一方面BPEL语言中诸多如并发 分支(flow)，控制连接(link)，事件处理(event handler)，异步调用(asynchronous invoke)等支持并发编程的特性，要求其面向侧面的扩展需要有相应地并发的支 持，从而简洁有效的表达涉及并发控制的侧面。
目前面向侧面编程语言模型主要包括pointcut-advice模型，历史敏感的侧面 模型(EAOP)，支持并发的侧面模型(CEAOP)，区间侧面模型(region aspect)。 所述pointcut-advice模型允许侧面在一组通过逻辑关系，通配，正则表达式选出 来的原程序中的操作(pointcut)之前、之后执行，或者取代原来操作的执行。 该模型为传统的AOP语言模型被广泛应用。所述历史敏感的侧面模型考虑历史 执行信息，将操作抽象为事件，允许侧面在一系列事件即一个执行轨迹之后执行。 所述支持并发的侧面模型是历史敏感的侧面模型的提升，它修改了编织策略，允 许侧面从原程序中分离出来与原程序并发执行。所述区间侧面模型提出 Regioncut机制将两行以上的代码包装在一起形成一个区间，从而可以选择一段 连续的代码作为插入点。
目前BPEL面向侧面的扩展主要有AO4BPEL和Padus两种。AO4BPEL采 用动态编织方式将传统的pointcut-advice模型应用于BPEL语言上，侧面能够在 BPEL的一个活动(activity)之前、之后执行，或者取代原来活动的执行。Padus 采用静态编织的方式将历史敏感的侧面模型应用于BPEL语言上，允许在原工作 流中添加任意的合法BPEL元素。
纵观上述面向侧面的语言模型以及BPEL面向侧面的扩展，均不能完全满足 BPEL侧面与原程序的并发协同执行需求。所述并发协同执行需求包括三点：
1、侧面应当能够与源程序和其他侧面并发执行。
2、侧面能够以开发者的意愿在原程序中的某一点之前与原程序合并。
3、侧面能够和源程序协同合作。
为此，我们提出了一种基于令牌的支持并发侧面编程的BPEL扩展实现方 法。
发明内容
发明目的：BPEL面向侧面编程(AOP)的扩展缺乏对并发的支持，这导致 涉及并发控制的侧面不能方便简洁的表达出来。本发明基于此问题提出了一种基 于令牌的支持并发侧面编程的BPEL扩展实现方法。
技术方案：一种基于令牌的支持并发侧面编程的BPEL扩展实现方法，包括 如下部分：
1)一种基于令牌的支持并发的侧面编程语言模型；
2)一个基于Petri网的侧面定义合法性验证算法；
3)一个基于ODE的支持侧面动态编织的BPEL执行引擎。
基于令牌的支持并发的侧面编程语言模型，区别于传统AOP语言模型的以 操作(方法调用，对类成员的访问)作为插入点(join point)定义的最小单元。 所述模型将操作的前置条件和后置条件作为插入点定义的最小单元。用一个四元 组(Pre，Post，T，N)来定义一个侧面。其中Pre为前置条件，Post为后置条 件，T为advice是BPEL中的一组活动，N为skip或proceed表明是否要执行 原工作流中相关的活动。T与BPEL工作流并发执行，通过获取前置条件令牌和 释放后置条件令牌完成同步。前置条件规定了T开始运行的时机，后置条件则 规定了T合并到原程序的条件。将工作流建模为Petri网，当原工作流Pre中所有 的库所都曾经有过令牌，T开始运行；Post后的变迁需要T执行结束释放额外的 令牌才能继续执行。该语言模型的语义由Petri网变迁的偏序关系形式化定义。 从而达到支持BPEL面向侧面的扩展并发和协作需求。
所述语言模型中不是任意的前置条件和后置条件的组合都是合法的。侧面的 协同合作不能与原程序中的依赖关系产生冲突。为此侧面的定义需要满足相关的 约束规则，所述约束规则主要有四个，所述验证算法根据这四个约束设计和实现。
所述约束规则包括：
规则1：一个侧面CTA＝(Pre,Post,T,proceed/skip)涉及的活动不能穿梭于 正常流程，事件处理，出错处理和补偿处理之间。
规则2：一个侧面CTA＝(Pre,Post,T,proceed/skip)涉及的活动不能穿梭于 循环内外。
规则3：一个侧面CTA＝(Pre,Post,T,proceed/skip)不能与原程序的依赖关 系产生冲突。
规则4：一个侧面CTA＝(Pre,Post,T,skip)，前置条件Pre与后置条件Post 代表的必须是一个区间。
所述基于ODE的支持侧面动态编织的BPEL执行引擎对现用的BPEL执行 引擎ODE的扩展，该引擎引入Aspect编译器对侧面进行编译。引入Aspect运 行环境，控制原程序与侧面的执行。从而实现侧面于原程序的协同合作。
所述编译器编译输入为侧面文件(.aspect)，及相关WSDL文件，所述WSDL 文件为侧面中所调用Web服务描述文件。编辑器首先根据输入验证侧面定义以 及侧面内BPEL活动定义是否合法。如果合法则将侧面文件编译为OAspect Java 对象存取。OAspect包含相应的OAdivce，OPrecondition，OPostcondition，skip 等对象和属性。OAdvice继承了ODE引擎中OProcess描述侧面活动。
引入Aspect运行环境，所述Aspect运行环境包含了aspect部署模块，工作 流状态监控模块，Aspect同步运行管理模块。所述aspect部署模块用于部署侧面； 所述工作流状态监控模块通过ODE提供的BPEL运行时事件监听器监控BPEL 工作流实例OProcess的运行状态；所述Aspect同步运行管理模块在侧面OAspect 前置条件满足时阻塞侧面后置条件相对应活动的执行，并执行侧面相应活动，在 侧面活动执行完成后，取消阻塞之前阻塞活动，使其继续执行。若侧面OAspect 的skip属性为true(默认为false)，则需要跳过执行在前置条件和后置条件之间的 活动，从而实现侧面于原程序的协同合作。
有益效果：与现有技术相比，本发明提供的基于令牌的支持并发侧面编程的 BPEL扩展实现方法，支持BPEL面向侧面编程的侧面与原工作流的并发和协作 能力。
附图说明
图1为BPEL工作流中基本活动的Petri网语义；
图2为BPEL工作流中结构化活动的Petri网语义；
图3为基于偏序关系的支持并发的面向侧面编程语言模型的Petri网语义；
图4为在BPEL工作流中加入典型的侧面的Petri网语义；
图5为基于Petri网的侧面定义合法性验证算法；
图6为基于ODE的支持侧面动态编织的BPEL执行引擎的框架；
图7为旅行代理服务使用案例及其三个侧面的需求；
图8为侧面XML描述表示语法；
图9为旅行代理服务三个侧面需求的侧面定义。
具体实施方式
下面结合具体实施例，进一步阐明本发明，应理解这些实施例仅用于说明本 发明而不用于限制本发明的范围，在阅读了本发明之后，本领域技术人员对本发 明的各种等价形式的修改均落于本申请所附权利要求所限定的范围。
1、基于令牌的支持并发的侧面编程语言模型
为了更好地描述和验证BPEL面向侧面编程的语言模型，我们将BPEL工作 流建模为Petri网。在BPEL中一个操作为一个活动(activity)，活动有两种类型， 基本活动和结构化活动，基本活动代表了原子操作，如:invoke，调用一个web 服务；receive：接收消息；reply：发送消息；assign：给变量赋值。结构化活动 用于组合其他的活动，如：sequence，定义一个顺序结构；if，定义一个分支结 构；while，定义一个循环结构；flow,定义一个并发结构。图1显示了基础活 动的Petri网语义，左边(虚线部分)显示的是基于BPEL的死锁路径消除(DPE)而 跳过活动X的语义，右边(实现部分)显示的是活动X正常流程下的语义。其 中rx(“ready”)表示活动X开始运行的状态，fx(“finish”)表示活动X运行结束的状 态，其他库所和变迁描述活动X的内部转换。结构化活动将其他活动以一定的 依赖关系进行组合，其Petri网语义主要描述了活间的依赖关系，如图2所示。
从图1和图2中我们可以看出基础活动和结构化活动均有rx(“ready”)和 fx(“finish”)这两个库所表示一个活动的开始和结束状态。每个活动的rx(“ready”) 和fx(“finish”)库所就是基于令牌的支持并发的侧面编程语言模型的插入点。
用四元组CTA＝(Pre,Post,T,N)来定义一个侧面。所述四元组的语义由Petri 网变迁的偏序关系形式化定义。CTA中N为proceed的语义是：
∀ p ∈ Pre , t = I ( p ) → T ]]>
∀ p ∈ Post , T → t = O ( p ) ]]>
其中→(“happened before”)规定了变迁之间的偏序关系。I(p)代表库所p的唯一输 入变迁，O(p)代表库所p的唯一的输出变迁。图3显示了有两个前置条件和两个 后置条件情况下的切面Petri网语义，在Petri网中→O→表示“happened before” 关系。CTA中N为skip的语义与之类似，区别在于，活动T要取代前置条件 和后置条件之间的活动执行。它有非常严格的约束来确保“前置条件和后置条件 之间的活动”是有意义的。CTA＝(Pre,Post,T,proceed)同样也有相应的约束。
当原工作流Pre中所有的库所都曾经有过令牌，T开始运行；Post后的变迁 需要T执行结束释放额外的令牌才能继续执行。从而达到支持BPEL面向侧面的 扩展并发和协作需求。
图4描述了典型的侧面描述和其的Petri网语义，从图4中，我们可以看出， 该语言模型不仅可以描述传统的before，after，around侧面，如图4-a，4-b，4-c 所示；还可以描述任意区间(如图4-d)，协同合作侧面(如图4-e)，并发侧面 (如图4-f)。
2、验证算法
在所述语言模型中不是任意的前置条件和后置条件的组合都是合法的。侧面 的协同合作不能与原程序中的依赖关系产生冲突。为此侧面的定义需要满足相关 的约束。所述约束规则包括：
规则1：一个侧面CTA＝(Pre,Post,T,proceed/skip)涉及的活动不能穿梭于正常流 程，事件处理，出错处理和补偿处理之间。
规则2：一个侧面CTA＝(Pre,Post,T,proceed/skip)涉及的活动不能穿梭于循环内 外。
规则3：一个侧面CTA＝(Pre,Post,T,proceed/skip)不能与原程序的依赖关系产生 冲突。
规则4：一个侧面CTA＝(Pre,Post,T,skip),前置条件Pre与后置条件Post代表 的必须是一个区间。
根据这四个约束规则设计和实现一个验证算法。所述验证算法如图5所示。
规则1,2规定了一个侧面的界限。规则3,4则规定了CTA的语义是有意义 的。
将所述规则1,2转换为寻找Pre和Post涉及的活动的结构化活动，并确保Pre 和Post的相关活动没有分布在结构化活动内，正常流程，事件处理，出错处理 和补偿处理和循环内外。如图5步骤1-5所述。
将所述规则3转换为检测原工作流对应的Petri网添加侧面Petri网语义后的 Petri网是否有环路。如图5步骤11-13所述。
将所述规则4装换为检测Pre和Post是否各自代表一个活动A,B。并且这两 个活动为同一个活动，或者包含A的结构化活动和包含B的结构化活动相同并 且是一个sequence。如图5步骤6-10所述。
3、执行引擎
所述基于ODE的支持侧面动态编织的BPEL执行引擎对现用的BPEL执行 引擎ODE的扩展框架如图6所示，灰色部分显示为原ODE引擎框架，黑色部 分显示了扩展的部分。引入Aspect编译器对侧面进行编译。所述编译器编译输 入为侧面文件(.aspect)，及相关WSDL文件，所述WSDL文件为侧面中所调用 Web服务描述文件。编辑器首先根据输入验证侧面定义以及侧面内BPEL活动定 义定义是否合法。如果合法则将侧面文件编译为OAspect Java对象存取。OAspect 包含相应的OAdivce，OPreCondition，OPostCondition，skip等对象和属性。 OAdvice继承了ODE引擎中OProcess描述侧面活动。
引入Aspect运行环境，所述Aspect运行环境包含了aspect部署模块，工作 流状态监控模块，Aspect同步运行管理模块。所述aspect部署模块用于部署侧面； 所述工作流状态监控模块通过ODE提供的BPEL运行时事件监听器监控BPEL 工作流实例OProcess的运行状态；所述Aspect同步运行管理模块在侧面OAspect 前置条件满足时阻塞侧面后置条件相对应活动的执行，并执行侧面相应活动，在 侧面活动执行完成后，取消阻塞之前阻塞活动，使其继续执行。若侧面OAspect 的skip属性为true(默认为false)，则需要跳过执行在前置条件和后置条件之间的 活动，从而实现侧面于原程序的协同合作。
4、使用案例
图7描述一个用旅行代理的服务BPEL工作流程及其三个侧面需求。上述语 言模型的4元组由XML描述表示。其XML语法规范及其说明如图8所示。
所述旅行代理服务工作流程为：当travel收到一个来自用户的请求后，它首 先调用一个web服务获取用户信息。然后初始化flight和hotel两个并发的任务。 这两个任务均完成搜索，选择，和预定这三个流程。最终，旅行代理服务将结果 返还给用户。
所述侧面需求R1以日志为例，我们需要记录飞机搜索的结果。其实我们只 需要在searchFlight之后执行日志记录操作，并不关心日志记录操作是否在 selectFlight之前完成。它可以与searchFlight之后的操作并发执行。这样的日志 服务应当具备于源程序的并发执行能力。不同的日志服务之间同样不应该优先后 执行顺序。该侧面定义如图9(a)所示。
所述侧面需求R2以添加商业规则“根据请求信息给用户回复附加一些广告” 为例。这意味着当程序开始后我们需要调用一个广告生成服务，该广告生成服务 需要在回复给用户之前完成并于源程序合并。该侧面定义的如图9(b)所示。
所述侧面需求R3以添加商业规则“将搜索到的旅馆以到机场的远近排序供 用户选择”为例，在searchFlight之后程序才能得到机场的位置信息，所以旅馆 排序服务需要在searchFlight和searchHotel之后开始，并在selectHotel之前完成。 这样的需求使得原先没有控制依赖关系的flight和hotel两个子任务需要和旅馆 排序服务协同合作。该侧面定义的如图9(c)所示。
将所述3个侧面部署到扩展的BPEL引擎上。调用原BPEL工作流，其运行 结果符合预期设想。