Web服务组合验证（共7篇）
Web服务组合验证 篇1
0 引 言
Web服务是一种自包含、自解释、模块化的应用程序,能够被发布、定位、并且从Web上的任何位置进行调用。Web服务组合可以利用较小的、较简单的、且易于执行的轻量级服务来创建功能更为丰富、更易于用户定制的复杂服务,从而能够将松散耦合的、分散在Internet上的各类Web服务有机地组织成一个更为可用的系统,支持企业内、外部的应用集成(EAI)和电子商务等网络应用。
基于Petri网的形式化方法是Web服务组合建模的一个重要手段。由于Web服务的独立性和自治性,通过多个Web服务组合完成的业务流程正确性难以保证,因此必须对其进行验证。本文采用可达图作为分析工具,通过对基于Petri网的Web服务组合模型的可达性、有界性、安全性和活性等特性进行分析,进而验证服务组合模型的正确性。
1 基于Petri网的Web服务组合
Petri网已经成为一种应用广泛的形式化过程建模技术。它是一个有向连通图,其节点分别称为库所或变迁。库所中含有托肯,表示资源的个数。
定义1 Petri网的结构是一个四元有向图:PN = (P,T,W,M0)。其中:
(1) P是有限库所集;T是有限变迁集;且P∩T=ϕ。
(2) W⊆(P×T)∪(T×P)是一组有向弧的集合,代表从库所到变迁或者从变迁到库所的二元关系。
(3) M0→{0,1,2,…}表示初始标识。
若W: (P×T)∪(T×P) →{0,1},则PN称为普通Petri网。在普通Petri网中,当变迁t在标识M下的所有输入库所中都至少含有一个托肯时,t就可以使能。本文中所涉及的PN都是普通Petri网。
一个Web服务的行为是一系列操作的偏序集合,因此,可以将其直接映射为一个Petri网:Web服务的状态和操作分别映射为Petri网的库所和变迁。假设代表Web服务网的Petri网都有一个输入库所i和一个输出库所o。
下面分别给出服务网和Web服务的Petri网描述[1]。
定义2 服务网是一个扩展的Petri网SN=(PN,i,o,to)=(P,T,W,M0,i,o,to)。其中:
⑴ PN是定义1中的基本Petri网。
⑵ i是输入库所,并且·i ={ x∈P∪T|(x,i)∈W }=∅。
⑶ o是输出库所,并且o·={ x∈P∪T|(o,x)∈W }=∅。
⑷ to:T→A∪{τ},其中A是Web服务中的操作集,τA,τ是一个空操作。
定义3 一个Web服务WS是一个六元组WS=(SName,SDesc,SLoc,URL,CS,SN)。其中:
(1) SName是Web服务的名称,是Web服务的唯一标识。
(2) SDesc是服务的描述。
(3) SLoc是服务的定位。
(4) URL是服务的调用。
(5) CS是构成Web服务的组件服务。如果CS={ SName },则WS是一个基本服务;否则WS是一个组合服务。
(6) SN是定义2中的服务网。
Web服务组件由原子服务(可能是基本服务,也可能是组合服务)和合成操作组合而成。基本的组合操作有顺序(Sequence)、并行同步(AND-Split和AND-Join)、选择(XOR-Split和XOR-Join)、循环(Lteration)类型[2](如图1所示)。其他更复杂的服务组合操作可以由这些基本操作组合构成。
2 Web服务组合验证
组合Web服务是由几个概念上相互独立而实际上又交互的原子服务构成,它们之间是一种紧耦合的关系,组合成的服务正确性难以保证,因此在组合服务发布之前要进行验证。Petri网提供了许多强大的分析手段,如可达图分析、马尔可夫分析、矩阵分析等,本文采用可达图作为分析工具。
定义4 可达性 若从初始标识M0开始激发一个变迁序列产生标识Mr,则称Mr是从M0可达的。所有从M0可达的标识的集合称为可达集,记为R(M0)。
定义5 有界性 给定Web服务网SN和可达集R(M0),一个库所p∈P是k-有界的,当∀M ∈R(M0):M (p)≤k。若所有的库所都是k有界,则SN是k有界的。当k=1时,称库所或SN是安全的。
定义6 死变迁 对于t∈T,∀M ∈R(M0):M [ t≯。即变迁t在任何标识下都不是使能的,则称t是死变迁。
定义7 活性 对于t∈T,∀M ∈R(M0),若存在某一变迁序列Sr,该变迁序列的激发使得此变迁t使能,则称变迁是活的。若一个SN的所有变迁都是活的,则该SN是活的。
Web服务组合的正确性可以由合理性[3]来验证。
定义8 一个Web服务组合模型是合理的当且仅当:
⑴ 每个模型都有一个输入库所i和一个输出库所o;
⑵ 在终止状态时,只有输出库所o中含有托肯;
⑶ 任何从初始状态M0可达的状态M′都可以到达终止状态;
⑷ 任何变迁都不是死变迁。
对于一个Web服务组合模型SN =(P,T,W,i,o,M0),我们定义它的一个扩展服务网SN=(P,T,W,i,o,M0) ,其中:P=P,T=T∪{t*},W=W∪{<o,t*>,<t*,i>},M0= M0。
定理 一个Web服务组合模型SN是合理的当且仅当SN具有有界性和活性[3]。
推论 Web服务组合模型的正确性验证有两种方法:
(Ⅰ) 分析服务组合模型SN的可达性,有界性和有无死变迁。
(Ⅱ) 分析服务组合模型的扩展服务网SN是否具有活性和有界性。
可达图构造算法
(1) 由初始标识M0开始,并标记为“new”。
(2) 若“new”标识存在则执行步骤⑶;否则算法终止。
(3) 选择某一“new”标识M,若在M下无任何变迁使能,转向步骤(5);否则执行步骤(4)。
(4) 对于在M下使能的所有变迁t,激发产生新的标识M′,作如下判断:
①若M′与已有可达图中的某个标识相等,则从M到已有标识画一条有向弧,将其标记为t,然后执行步骤(5)。
②若在从M0到M的路径上存在一标识M″,使得M′覆盖M″,则对于那些使M′(p)>M″(p)成立的p,用ω(无穷大)取代M′(p)。然后从M到M′画一条有向弧,将其标记为t,同时将M′标记为“new”,然后执行步骤(5)。
③若M′不满足①和②的条件,则将M′添加到可达图中,并从M到M′画一条有向弧,将其标记为t,同时将M′标记为“new”,然后执行步骤(5)。
(5) 去掉标识M的“new”标记,返回到步骤(2)。
Web服务网SN基于可达图的正确性验证方法:
(1) 可达图中所有结点的最大托肯数≤k,则SN是k-有界的。
(2) 当且仅当可达图中所有结点上仅包含0或1时,SN是安全的。
(3) 若某变迁在可达图中不出现,则该变迁是死变迁。
(4) 在不包含ω的可达图中,给定任意的两个结点之间,都存在一有向路径,则SN是活的。
(5) 若SN满足(1)、(2)和(3)或者SN满足(1)和(4),则组合服务是正确的。
3 Web服务组合验证实例
例 模拟一个ATM机的服务,包括:(1)操作过程:{开始、插卡、输入密码、查询子服务、取款子服务、转账子服务、返回、结束};(2)查询子服务:{选择查询};(3)取款子服务:{选择取款、输入取款金额};(4)转账子服务:{选择转账、输入转入账号、输入转账金额}。其组合服务网模型如图2所示。
该组合服务网中库所和变迁的含义如下所示:
i 服务的初始标识
p1 服务开始状态
p2 插卡完成状态
p3 密码输入成功状态
p4 查询成功状态
p5 进入取款状态
p6 进入转账状态
p7 转账账号输入完成状态
p8 操作完成状态
o 服务的结束状态
t1 启动服务操作
t2 插卡操作
t3 输入密码操作
t4 选择查询操作
t5 选择取款操作
t6 选择转账操作
t7 查询辅助操作
t8 输入取款金额操作
t9 输入转入账号操作
t10 输入转账金额操作
t11 返回操作
t12 结束操作
t13 结束操作根据组合服务网模型,生成可达图如图3所示。
Mi=(i,p1,p2,p3,p4,p5,p6,p7,p8,o)
利用可达图对该组合服务进行验证分析:①该组合服务模型有一个输入库所和一个输出库所。②所有状态都在从M0到终止状态M9的有向路径上,所以该组合服务是是可达的。③系统结束时到达状态M9=(0,0,0,0,0,0,0,0,1),此时只有输出库所o中有托肯。④所有的变迁在可达图中都出现,所以组合服务中没有死变迁。根据推论(Ⅰ)可知该服务组合是合理的,满足正确性的要求。
我们也可以构造该组合服务的扩展服务网SN,生成SN的可达图,然后根据推论(Ⅱ)证明SN具有活性和有界性,同样可以验证组合服务的正确性。这里就不再赘述。
4 结 论
形式化方法是Web服务组合的一个研究思路。本文在基于Petri网的Web服务组合模型基础上,利用Petri网的可达图作为分析工具,提出了两种Web服务组合正确性的验证方法,并进行了实例分析。Petri网在解决问题的复杂度方面还存在一定的不足,下一步主要研究Web服务更为通用的、具有更好扩展性、可伸缩性和开放性的形式化描述和验证方法。
摘要：针对基于Petri网的Web服务组合形式化建模,给出了Web服务网的正确性定义和可达图的构造算法。采用可达图作为分析工具,对Web服务网的可达性、有界性、安全性和活性等特性进行分析,给出验证Web服务组合正确性的方法,并举例说明了这种方法的应用。
关键词：Web服务组合,验证,Petri网,可达图
参考文献
[1]Rachid Hamadi Boualem Benatallah.A Petri Net-based Model for Web Service Composition[C]//14th Australasian Database Conference,Adelaide,Australian,2003:191-200.
[2]Yu Liang Chi,Hsun Ming Lee.A formal modeling platform for compos-ing web services[J].Expert System with Application Systems,2008,34(2):1500-1507.
[3]W MP,van der Aalst.The application of Petri nets to workflow man-agement[J].The journal of Circuits Systems and Computers,1998,8(1):21-66.
[4]Srini Narayanan,Sheila McIlraith.Analysis and simulation of Web serv-ices[J].Computer Networks,2003,42(5):675-693.
[5]Liu Bing,Chen Huaping.A Web Service Composition and Analysis:A Petri-net Based Approach[C]//Proceedings of the First International Conference on Semantics,Knowledge,and Gird,2005:191-200.
[6]Tadao Murata.Petri Nets:Properties,Analysis and Applications[C]//Proceedings of the IEEE,1989:541-580.
[7]袁祟义.Petri网原理[M].北京:电子工业出版社,1998.
Web服务组合验证 篇2
关键词：ETPN(扩展时间Petri网),T-不变量,时间成本,冲突检测
0 引 言
随着社会信息化的快速发展,Web服务技术得到了广泛应用和完善。Web服务是基于网络的、分布式的、自描述的、自包容模块化的组件,它执行特定的服务,遵循一定的技术规范,提供了面向Internet应用的统一服务注册、发现、绑定和集成机制,使得在广域环境下实现互操作成为可能的一种主要机制[1],然而在面向服务的体系结构SOA(Service Oriented Architecture)中对服务的功能需求越来越多,为了满足多功能服务需求,基于原子服务的独立性和重构性,在单个WEB服务技术的基础上发展了服务组合的技术。该技术将多个原子服务按照一定的组合机制组合成一个满足用户最大需求的服务群。
由于研究技术的多样性使得Web服务组合方法也出现很多种,在最后形成的组合机制需要经过建模来仿真验证其合理性、可行性和高效性,在这种情况下多种验证工具应发挥出自身的强大功效,例如:自动机、进程代数、PI演算、Petri网等等。由于Petri网具有图形化和形式化证明的强大优势,其建模技术随之受到很多研究者的欢迎,文献[2]用WS-CDL对Web服务组合进行描述,并通过Petri网对生成的服务组合进行建模,进而分析验证了组合方案的有效性;文献[3]利用建模语言BPEL对组合进行描述,并通过Petri网对生成的组合服务进行建模和合理性验证。本文基于BPEL工作流建模语言使用了扩展TPN( Time Petri Nets)模型来对组合方案进行合理建模和高效分析验证。
1 Petri网模型及BPEL
1.1 Petri网模型
Petri网的概念是1962年由德国科学家Carl Adam Petri在他的博士论文中首先提出来的。Petri网是一种系统模型,其模型不仅可以对系统的结构进行描述,还可以刻画系统的动态行为,Petri网即可用直观的图形表示,又可引入许多数学方法对其性质进行形式化的证明分析[4]。对于复杂的系统,Petri网还可以对其进行分层描述,自顶向下逐步求精,有利于和面向对象的思想方法相沟通。
1.2 BPEL
BPEL(Business Process Execution Language)是IBM、Microsoft和BEA三家在2002年7月共同提出,它针对IBM的Web Services Flow Language(WSFL)和Microsoft的XLANG specification进行合并和修改,最后加入了来自SAP和Siebel Systems的研究。BPEL是一种基于XML的业务流程描述语言,它提供了一种可以将业务流程和业务交互协议进行正规描述的方法。BPEL可以将Web服务通过组合、编排和协调自上而下地实现面向服务的体系结构。进而结合Web服务的需要制定了一项规范标准BPEL4WS[5],它的作用是将一组现有的服务通过不同的活动整合起来,从而定义为一个新的Web服务。
2 组合分析验证框架和扩展时间Petri网模型
本节提出了一种具体的将BPEL和Petri网的分析验证相结合的流程框架,在输入服务需求后,经过BPEL语言对流程描述建立工作流程,再转换成ETPN模型进而形式化分析验证组合的合理性和高效性,最后输出高效的服务组合。结合目前越来越多用户希望从时间角度获得服务质量最高的一个服务组合,并且更好地解决Petri网建模的并发冲突问题的需求,本文提出了一种扩展时间Petri网,定义了变迁冲突检测规则和发生规则,在解决变迁冲突问题上做了进一步探索,并且提出了一个累计状态时间成本计算规则来求出时间成本最小的服务组合方案。
2.1 组合分析验证框架
本节提出的将BPEL和Petri网的分析验证相结合的流程框架是一种基于ETPN的Web服务组合分析验证框架,该框架主要包括三大部分:BPEL工作流引擎、Petri网建模分析引擎以及执行验证引擎。BPEL工作流引擎中有BPEL处理器,流程模块和活动模块三部分组成。Petri网建模分析引擎由ETPN建模、分析模块和组合结果三个模块组成。由于本文的主要研究工作是建模分析,执行验证部分将在后续工作中进一步研究,所以执行验证引擎不做详细描述,具体的框架图如图1所示。
Web服务组合方案的分析验证框架的具体步骤描述如下:
(1) 服务提供者通过服务注册将服务信息发布到注册中心的服务库。
(2) 服务请求者提交的服务需求经BPEL处理器分析处理,创建流程和管理流程实例的生命周期。
(3) 在流程模块中根据BPEL处理器的分析结果建立具体的工作流程模型,初始化参数信息。
(4) 在活动模块中结合服务注册中心的已有的服务和工作流模型添加活动信息,确认活动间的逻辑关系和参数信息。
(5) ETPN建模中心将形成的BPEL工作流模型转换成ETPN模型,生成符合服务要求的ETPN模型。
(6) 在分析验证模块中对该模型进行可达性和优先级的分析进而生成符合服务要求的组合方案。
(7) 将通过分析验证模块的组合方案传递给执行引擎。
(8) 执行引擎将生成的组合方案进行有效的执行。
(9) 最终将执行结果传递给服务请求者,并将最后的组合方案通过服务请求者放入服务注册中心。
2.2 扩展时间Petri网模型
在Web服务组合流程建模中由于研究时间成本预算分析的需要,本文在基本的Petri网基础上引用了时间Petri网,在变迁上添加了变迁触发时间区间,并且在变迁上扩展引入了变迁发生优先级函数,更好地解决了可达分析中出现的冲突问题,提出了带有优先级的扩展时间Petri网ETPN(Expanded Time Petri Net)。
定义1 ETPN是一个八元组的网模型
PTPN=(P,T,F,α,β,W,M0,r),其中:
(1) P为库所集,∀p∈P。
(2) T为变迁集,∀t∈T,P∩T=ϕ,T∪P≠ϕ。
(3) F为流关系,F=(P×T)∪(T×P)。
(4) α:T→R+,为全局时钟下变迁最早进入触发时期的时间可以记作GET。
(5) β:T→R+,为全局时钟下变迁最晚进入触发时期的时间可以记作GLT。
(6) M0是系统的初始状态标识。
(7) W是权函数,表示所需要的资源数量。
(8) r是优先级函数,表示变迁触发的优先级别。
定义2 变迁冲突检测规则
变迁冲突是Petri网及其高级Petri网模型的一种非常重要的行为,在Petri网建模中不可避免地会出现变迁冲突的现象。本文结合多资源情况下的ETPN的结构对变迁冲突检测做了如下的定义:
(1) 如果token(pi)=1∧M[ti>M′∧M[tk>M′变迁ti和tk在状态M下的全局时间延迟区域为α和β,且α∩β=ϕ,则称变迁ti和tk在状态M下无冲突,并发可以正常发生。其中M和M′是状态标识且pi∈M,ti和tk是两个不同的变迁,token(pi)=1表示库所pi在状态M下的资源数为1。
(2) 如果token(pi)=1∧M[ti>M′∧M′[tk>M″∧M′[ti>M″变迁ti和tk在状态M′下的全局时间延迟区域为α和β,且α∩β≠ϕ,则称变迁ti和tk在状态M′下相互冲突,并发发生无法正常执行。其中M,M′和M″是状态标识且pi∈M,ti和tk是两个不同的变迁,token(pi)=1表示库所pi在状态M下的资源数为1。
定义3 变迁发生规则
对于一个已知的状态标识M,系统中的变迁t可以发生的充分必要条件是:
(1) t在M有发生权,满足:
∀p∈●t:M(p)≥W(p,t)∧∀p∈t●:M(p)+W(p,t)≤K(p)
t在M有发生权记作M[t>。
(2) 变迁前集的每个库所托肯的拥有时间必须足够长,即满足变迁触发时间中的GET。
(3) 变迁的最小GLT不得小于当前系统的全局时钟。
(4) 当判定变迁触发出现冲突时,根据变迁的优先级来判定,优先级最高的变迁先触发,若两个优先级别一样则随机挑选一个变迁触发。
定义4 状态转移规则
若M[t>,则t在M可以发生,你给标识M改变为M的后继M′,M′的定义是:
对∀p∈P,
M′为M之后继的事实记作M[t>M′。
2.3 BPEL工作流模型向ETPN模型的转换
在BPEL工作流模型的每一个过程中的元素都称为一个活动,分为原子活动和结构化活动。原子活动执行简单的任务,包括reply、receive、invoke、assign、wite以及empty。在原子活动中只用一个简单的变迁来表示,库所表示一个活动的前提条件和后继状态;结构化活动包括Sequence、While、Swith、Flow。Sequence活动是表示若干原子服务按照顺序关系来执行,While活动定义的是特定一些原子服务多次循环执行,Swith活动定义的是给予变迁赋予选择条件根据条件来选择服务流程,Flow活动定义的是若干个原子服务并行执行。其活动转化的具体Petri网模型可参考文献[6]。根据其基本的模型可以建立满足用户需求的服务组合的Petri网模型。
3 时间成本计算规则及算法
3.1 状态方程和T—不变量
设ETPN是一个扩展时间Petri网则该网结构用一个关联矩阵C来表示,将Petri网中的状态标识M都用一个非负整数向量来表示,T向量用U来表示,其中U(ti)表示变迁ti在变迁序列中出现的次数,利用关联矩阵就可以将M0[t>M这一事实表示成等式M0+C·U=M,即为状态方程,根据T—不变量的定义[7],由公式C·U=θP即可求出T—不变量,进而找出满足用户需求的可达变迁序列。
3.2 时间成本计算规则
(1) 状态类局部时间计算
根据时间Petri网的定义,每个变迁都有一个时间延迟区域[GET,GLT],这个时间区域是基于全局时钟的局部时间段,与此可以生成一个基于变迁触发时钟的全局时间延迟区域,以闭区间[EET,LET]表示,初始值[EET,LET]=[0,0],则有:
[EETi,LETi]=[GETi+EETj,GLTi+LETj] (1)
其中i表示变迁ti,j表示变迁tj,tj是发生在ti前面的变迁。
(2) 状态类累计时间计算
给定一个状态M其状态累计成本记为C以及一个可击发的变迁t,可以达到一个新的状态M′其状态累计成本记为C′:
C′=C+wt×[EETt,LETt] (2)
其中初始值C0=0,wt是到达变迁t的权值。
给定一个状态M其状态累计成本记为C以及经过并发发生的变迁t1,t2,…,tj,可以达到一个新的状态M′其状态累计成本记为C′:
C′=C+max(wtj)×max([EETtj,LETtj]) (3)
其中j∈[1,i],wtj是到达变迁tj的权值。
由状态累计时间成本计算方法可知:终止状态Me中的状态累计成本区间Ce即为该可达序列的总成本区间。
在计算状态类最小时间成本问题上,本文借鉴了文献[8]中提出的成本覆盖和状态空间构造算法,在构建可达的状态类空间时计算出其对应的最小成本。
3.3 服务组合算法描述
寻找最小时间成本的服务组合的算法描述如下:
输入:基于BPEL流程的ETPN模型。
输出:满足用户需求的最小时间成本无冲突的服务组合。
其中M0表示初始状态标识,Tc表示满足当前状态条件的所有变迁,Te表示满足用户要求的可达变迁序列,M′表示下一个状态标识。
(1) 在ETPN模型中找出所有含有初始token的库所,得到初始状态M0,若M0=ϕ,则返回error表示建模有误。
(2) 根据初始状态M0获得满足发生条件的变迁集合Tc,令Te=Tc,若Tc=ϕ则返回fail算法结束,若Tc≠ϕ则跳转到(3)。
(3) 使集合Tc中的变迁都触发,并检测是否存在变迁冲突,若存在冲突则根据变迁优先级来判别优先级高的变迁触发,若优先级别相同则从中随机触发一个变迁,然后根据定义4中的规则计算下一个状态M′。
(4) 根据状态M′获得满足发生条件的变迁集合Tc,若Tc=ϕ,则跳转到(5),若Tc≠ϕ,则令Te=Tc+Te,返回到(3)。
(5) 根据初始状态M0和变迁序列Te,对Petri网模型进行化简,删除不需要的变迁和库所,求出关联矩阵C。
(6) 根据等式C·U=θP求出T—不变量,再根据上述变迁序列Te中找出符合T—不变量的可达变迁序列Ta。
(7) 根据式(1)逐步求出可达变迁序列中的各个变迁的本地时间区间。
(8) 根据各个变迁的本地时间区间由式(2)和式(3)求出累计时间成本,并从中找出最小成本的可达变迁序列。
4 实例分析验证
本节以旅游行程安排程序为例,对最小时间成本的无冲突组合方案的可行性进行验证。图2为具体的工作流程图,图3是将工作流程图转换为对应的ETPN模型,表1为ETPN模型中变迁和库所的具体定义和参数设定。
根据图3的ETPN模型求出该模型的关系矩阵C,关系矩阵的具体求法参见参考文献[7]。
结合算法中查询可达序列和公式C·U=θP,可计算出2个满足T—不变量的可达变迁序列为(计算步骤从略):
T1=(t1,t2,t4,t5,t6,t7,t9,t10)
T2=(t1,t3,t4,t5,t6,t7,t9,t10)
根据式(1)求出这两个可达变迁序列中每个变迁的全局时钟,再由式(2)、式(3)求出各自的累计状态时间成本C1、C2分别为:C1=[7],C2=[5]。经计算可知C1>C2。由此可见,在这2个可达变迁序列中第2个序列是时间成本最小的可达变迁序列,其对应的服务组合即乘坐飞机到达目的地然后选择自由旅行是时间成本最小的服务组合。
5 结 语
本文根据当前的Web服务组合的研究情况,使用BPEL工作流建模语言对组合模型进行描述,利用直观的、图形化的Petri网建模工具进行Web服务组合的建模和分析验证。考虑到在实际应用中对时间成本的特殊需求,本文提出了扩展时间Petri网ETPN的定义,给出了从BPEL到ETPN的合理转换规则;为了有效解决时间延迟和变迁冲突的问题,定义了冲突检测规则并提出了解决冲突的办法;之后给出了累计状态时间成本的计算公式,并对服务组合的算法进行了描述;最后用实例验证了该组合方案的可行性。下一步主要的工作是研究Web服务组合的执行验证过程,并综合QoS中的所有参量进行综合分析服务组合,找出综合服务质量最高的服务组合,并且在Petri网模型中引入模糊的概念,更加精准地建模并扩大模型在建模实例中的应用范围。
参考文献
[1]李景霞,等.Web服务组合综述[J].计算机应用研究,2005(12):4-7.
[2]Valero V,Cambronero E M.A Petri net approach for the design and a-nalysis of Web services Choreographies[J].The Journal of Logic Alge-braic Programming,2009(78):359-380.
[3]Taejong Yoo,Buhwan Jeong,Hyunbo Cho.A Petri Nets based function-al validation for services composition[J]Expert Systems with Applica-tions,2010(37):3768-3776.
[4]廖军,谭浩,刘锦德.基于Pi演算的Web服务组合的描述和验证[J].计算机学报,2005,28(4):635-643.
[5]Web服务:BPEL4WS专题[EB/OL].http://www.ibm.com/devel-opworks/cn/webservices/ws-theme/ws-bpel.html.
[6]Transformation of BPEL Processes to Petri Nets[J].Theoretical As-pects of Software Engineering,2008:166-173.
[7]袁崇义.Petri网原理与应用[M].北京:电子工业出版社,2005.
Web服务组合验证 篇3
Web服务是一种新型的Web应用程序。随着Web服务技术日趋完善, 利用Web服务组合满足应用需求成为可能。现有的Web服务组合标准BPEL4WS[1]、WSCI[2]等都是基于XML的Web服务组合描述语言, 为描述Web服务组合流程制定了语法规则, 主要依靠设计人员的经验完成组合服务的创建。由于没有流程建模和验证过程, 流程设计者水平决定了流程正确与否。用手工方法进行Web服务组合分析和验证已经变得非常复杂, 且工作效率低, 因此研究利用工具对Web服务组合进行建模, 进而进行分析、验证和仿真成为当前研究的热点。在文献[3]中提出了基于一般Petri网Web服务组合代数, 通过将操作符直接映射到Petri网结构来表达组合操作符的形式语义。任何以该代数结构表达的Web服务组合都能转换成对应的Petri网描述。这种方法能够对服务组合进行验证, 确保组合Web服务逻辑正确性。然而一般Petri网不能精确表达Web服务的数据流。文献[4, 5]中提出了一种方法:借鉴模型驱动体系结构MDA (model driven architecture) 的思想, 用UML活动图模型来描述Web服务组合, 可产生以不同组合语言表示的可执行规范描述。该方法利用扩展的UML来描述Web服务组合, 为Web服务组合提供了一种图形化的描述方式, 但没有提供服务组合正确性验证方法。在文献[6]中给出了一个面向服务的分布式系统的设计与分析框架。该框架的基础是一个基于颜色Petri网的服务模型WSPNet, 该框架还包括一个支持组合模型建模和分析的工具集。WSPNet是描述服务组合一个较粗略的模型, 没有对流程中并行、选择、循环的具体表达做具体描述, 在文中仅针对BPEL4WS可表达的流程模式给出了模型的相应表达, 没有给出主要流程结构的WSPNet模型表达, 不独立于流程描述语言。
针对已有建模方法不独立于流程描述语言且不能全面刻画流程这两个问题, 本文结合模型驱动体系结构和形式化方法思想提出了一种描述Web服务的颜色Petri网模型, 较全面地描述服务组合流程的同时, 还能进行流程正确性分析验证。
1 Web服务组合的颜色Petri网模型
Petri[7]网是一种基于图的形式化描述模型, 用于分析离散的并发系统。由于Petri网严格的数学基础和图形化的规范语义, 在系统建模中得到广泛应用:系统建模分析, 协议分析验证等, 但也存在严重不足:无数据概念。因此在本文中利用颜色Petri网CPN (Colored Petri Net) [8]来对Web服务组合进行形式化建模, CPN中库所的托肯 (token) 是有类型的, 可是不同的数据类型, CPN不仅在描述系统静态模型方面有严格的形式化定义, 而且对系统动态行为的模拟仿真分析也具有形式化定义和描述。
1.1 Web服务的颜色Petri网模型
一个Web服务为一个 (sName, sDescription, sComponent, sModel) , 其中sName是Web服务的名称, 唯一标识该服务;sDescription是Web服务的描述信息, 包括服务功能、输入输出参数、服务质量、服务调用等;sComponent是组成该服务的组件Web服务的集合。如果sComponent={sName}表示该Web服务是一个原子服务, 否则既是一个组合服务;sModel是描述该Web服务的颜色Petri网。
定义1sModel= (∑, P, T, A, C, G, E, I) , 式中:
(1) ∑是Web服务中涉及的数据类型的集合;
(2) P为托肯非空有限库所集, 是Web服务参数的缓冲区;
(3) T=Tc∪T0为非空有限变迁集。其中Tc是普通变迁集, 是调用的Web服务集合;T0是零变迁集, ∀t∈T0不关联到任何Web服务, 不执行任何处理仅辅助流程的表达;
(4) A⊆P×T∪T×P是一有限弧集, 且P∩T=P∩A=T∩A=ϕ;
(5) C是一数据类型函数, 定义为C:P→∑, 指定库所p∈P中的托肯类型为C (p) ;
(6) G是一防卫函数, 定义为G:T→G (t) 。满足∀t∈T:[Type (G (t) ) =B∧Type (Var (G (t) ) ) ⊆∑], 指定变迁引发须满足的前提条件;
(7) E是弧A上的函数, 定义为E:A→E (a) 。满足∀a∈A:[Type (E (a) ) =C (p) MS∧Type (Var (E (a) ) ) ⊆∑, 其中p是A (a) 中的库所, C (p) MS是库所p的数据类型集上的多重集。E表示Web服务的输入、输出;
(8) I是一初始化函数, 定义为从P到一个封闭表达式I (p) , 满足∀p∈P:[Type (I (p) ) =C (p) MS]。
1.2 Web服务组合
Web服务组合由各个小粒度的Web服务相互之间通信和协作来实现大粒度的服务功能;通过有效的联合各种不同功能的Web服务, 服务开发者可以借此解决较为复杂的问题, 实现增值功能。Web服务组合包括五种基本结构:
(1) 调用 调用基本Web服务。
(2) 顺序 一个Web服务在另一Web服务之后执行。
(3) 选择 选择满足条件的分支, 执行该Web服务分支。
(4) 并行 在一个Web服务后多个Web服务同时执行。
(5) 循环 一个或者多个Web服务被重复的执行。
2 Web服务组合验证
使用形式化模型描述Web服务的目标是协助组合流程设计, 对流程设计进行分析验证, 发现流程设计中的错误。Web服务组合被表示为一个颜色Petri网后, 可利用CPN的性质来对其进行分析验证。
2.1 Web服务组合流程逻辑正确性
利用CPN建立了Web服务组合的模型后, 首先要确保组合流程的逻辑正确性。在此将CPN中的托肯都视为一种类型, 将CPN简化成普通Petri网。
Web服务组合流程逻辑正确性可使用Petri网的分析方法[11]加以分析验证。将CPN中所有托肯视为一种类型, 此过程可利用CPN Tools[9]完成, CPN Tool工具由丹麦Aarhus大学开发的CPN建模与仿真工具, 实现CPN的编辑、语法检查、状态空间分析及仿真运行等功能。
2.2 Web服务组合流程实例正确性
确保了Web服务组合流程逻辑正确性后, 通过CPN的初始化函数实例化流程, 利用CPN的动态行为定义来验证流程实例的正确性, 同时仿真流程实例的执行过程。
定义2 给定初始标识M0, 标志Mi称为是可达的, 当且仅当∃M0:Mi∈R (M0) 。
定义3 变迁绑定是定义在Var (t) 上的函数b, 满足:
(1) ∀v∈Var (t) :b<v>∈Type (v) ;
(2) G (t) <b>为“真”。
变迁t的绑定就是把变迁t的每个变量Var (t) 用合适的数值代替, 且防卫表达式G (t) <b>为真。变迁t所有绑定的集合记为B (t) 。
定义4 绑定元素是一 (t, b) 对, 其中t∈T, b∈B (t) , 所有绑定元素的集合用BE表示。
定义5 完全发生图是一有向图OG= (V, A, N) , 其中:
(1) V=[M0>
(2) A={ (M1, b, M2) ∈V×BE×V|M1[b>M2]}
(3) a= (M1, b, M2) ∈A:N (a) = (M1, M2)
其中M1[Y>M2表示:模型在标识M1步Y发生后, 模型的标识变为M2。完全发生图是由从标识M0的所有可达标识作为结点构成的图, 其有向弧线由BE元素标注。节点M1到节点M2的有向弧线标注为b, 当且仅当在绑定b时网标识实现从M1到M2的转变。完全发生图通过描述网标识的转变过程, 仿真了模型实例的动态执行。
利用CPN Tools对Web服务组合流程中变量赋值实例化流程后, 可生成Web服务组合流程对应颜色Petri网模型的状态发生图, 从而验证流程实例的正确性, 同时可仿真组合流程实例的执行过程。
3 建模实例
以行程安排服务组合为例:用户从A地到B地参加一个会议, 希望制定一个会议行程, 包括预订行程的交通方式和酒店房间。这个服务组合涉及以下7个Web服务操作: (1) getDriveTime (A, B) :查询从A到B的行车时间, 返回行车时间; (2) getFlightInfo (A, B) :查询从A到B的航班, 返回航班信息; (3) bookAirline (C, FNo, Date) :订购C航空公司日期为Date航班号为FNo的机票, 返回订票是否成功; (4) getTrainInfo (A, B) :查询从A到B的车次, 返回车次信息; (5) bookTrain (TNo, Date) :订购日期为Date车次为TNo的火车票, 返回订票是否成功; (6) getHotelInfo (B) :查询B地的酒店, 返回酒店信息; (7) bookHotel (H, Date1, Date2) :预定酒店H的一个房间, 时间从Date1到Date2, 返回预定是否成功。
该组合服务包含Sequence和Choice两种控制结构。Choice结构隐含那2种可能的执行序列, 是互斥选择结构, 其中服务 (2, 3) 和 (4, 5) 只需要执行其一即可。而服务1、6、7必须都执行。假设用户在选择交通方式上的约束为:如果两地的行车时间小于等于6小时, 就坐火车去;若两地的行车时间大于6小时则乘飞机去。该服务组合的CPN表示如图6所示。
通过CPN Tools建立会议行程的CPN模型后, 首先将行程模型中的托肯看作一种类型, 利用CPN Tools的家态、活性、公平性分析等功能可验证该行程安排的逻辑正确性。部分验证结果如图7所示, 通过验证结果可得出该流程是逻辑正确的。
接着对流程中的变量进行绑定, 实例化流程。对具体流程通过求解流程的完全发生图来分析验证流程实例的正确性。流程实例的仿真执行过程如图6表示, 可得出该流程实例是正确的。
4 总结与展望
Web服务技术日趋成熟, 利用网上共享的Web服务组合成功能更强大的增值服务可满足实际应用需求。工业界从不同角度出发已给出了多种Web服务组合描述语言, 但是这些语言仅给出了Web服务组合流程的定义, 无法验证流程的正确性。已有的Web服务描述模型不独立于具体的流程描述语言且不能全面地描述Web服务组合, 在本文中提出了一个Web服务的颜色Petri网模型, 在此基础上利用调用、顺序、选择、并行、循环基本组合结构可将Web服务组合成一个服务流程。该模型建立在颜色Petri网基础上, 能较全面描述流程, 同时还能够对流程的逻辑正确性、实例正确性进行分析验证, 最后通过建模实例说明了模型的实用性。在下一步的研究中准备将Web服务的执行时间、服务质量纳入建模中, 寻找最优Web服务组合方案, 结合不同Web服务的调度算法, 计算流程的执行效率, 提供效率最佳、质量最优的Web服务组合。
参考文献
[1] Tony Andrews, Francisco Curbera, Hitesh Dholakia, et al.Business Process Execution Language for Web Services Version 1.1.Specification[S].2003.
[2]Assaf Arkin, Sid Askary, Scott Fordin, et al.Web Service Choreography In-terface (WSCI) 1.0.http://www.w3.org/TR/wsci/.
[3]Rachid Hamadi, Boualem Benatallah.A Petri Net-based Model for WebService Composition[C]//Proceedings of the Fourteenth Australasian da-tabase conference on Database technologies, 2003:191-200, Adelaide, Australia.
[4]David Skogan, Roy Grφnmo, Ida Solheim.Web Service Composition inUML[C]//Proceeding of the 8th International IEEE Enterprise Distrib-uted Object Computing Conference, 2004:47-57, California, USA.
[5]Roy Grφnmo, Ida Solheim.Towards Modeling Web Service Compositionin UML[C]//ProceedingsOf The 2nd Intl.Workshop on Web Services:Modeling, Architecture and Infrastructure, 2004:72-86, Porto, Portugal.
[6]Xiaochuan Yi, Krys J Kochut.A CP-nets-based Design and VerificationFramework for Web Services Composition[C]//Proceedings of the IEEE In-ternational Conference on Web Services, 2004:756-760, San Diego, Califor-nia, USA.
[7] Murata T.Petri nets:Properties, analysis and applications[C]//Proc.IEEE, 1989, 77 (4) :541-580.
[8] Jensen K.Colored Petri Nets.Basic Concepts, Analysis Methods and Practical Use Volume 1, Basic Concepts[M].2nd ed.Monographs in Theoretical Computer Science.Berlin, Heidelberg, New York:Springer-Verlag, 1997.
Web服务组合验证 篇4
到目前为止, 一些Web服务组合语言, 譬如WSCI、WSFL和BPEL4WS, 对如何将多个基本服务组合成一个复杂服务做了描述, 但都仍然是语法级别的, 它们无法验证服务组合是否正确及组合服务是否能在有限步骤内结束。因此需要对Web服务组合流程进行形式化描述, 以实现可靠的组合服务。由于Web服务的组合是一种拓扑结构动态变化的分布式通信系统, 而Pi-演算可以用来描述结构不断发生变化的并发系统, 所以本文拟采用Pi-演算对服务组合进行形式化描述, 并进一步给出验证。
1 Pi演算及服务组合的形式化方法
Pi演算是Robin Milner提出的, 以进程间的移动通信为研究重点的并发理论, 它是对CCS (Calculus of Communication System) 的发展。其基本计算实体为名字和进程。进程间的通信通过传递名字来完成。由于Pi演算不但可以传递CCS中的变量和值, 还可以传递通道名, 并且将这几种实体都统称为名字而不再区分, 这使得Pi演算具有了建立新通道的能力。因此Pi演算成为用来描述结构不断变化的并发和分布式系统的高效语言。对于Pi-演算的基本语法及操作见文献[1]。限于篇幅原因, 本文中不再详述。因要对服务组合进行正确性验证, 在此特指出Pi-演算中的互模拟的概念。
Pi-演算中互模拟分为强互模拟和弱互模拟。强互模拟是指, 进程P能完成的所有动作和变迁 (内部的和外部的) , 进程Q都能完成, 则称进程P和Q是强相似的。
弱互模拟是指外部观察者所观察到的P和Q的外部行为和变迁是一致的, 则称进程P和Q是弱相似的。也称观察等价。
Web服务组合研究领域的一个重要问题是如何形式化描述Web服务组合, 如何验证服务组合的正确性。Web服务组合的形式化模型可以用来检查、验证Web服务组合以保证组合的正确性。服务组合的主要方法见文献[2], 而目前较常见服务组合的形式化方法为:基于Petri网的, 基于进程代数 (CCS, LOTOS及Pi演算) 的以及基于半形式化语言UML的。而对于基于本体 (如OWL-S) 以及基于可执行语言 (如WS BPEL) 的方法, 因为他们都可以使用形式化的方法来进行建模和验证, 所以一般不将其列入形式化方法的范围。
考虑到Petri网所引起的状态空间爆炸以及对CPU资源的消耗问题, 如果状态空间比较大, 则很有可能将系统资源耗尽, 从而无法完成验证工作。另外, 虽说基于Petri网的模型易读, 但却降低了其伸缩性。而Pi演算方法提供了精确的符号和强大的推理机制, 这促进了复杂服务的规范化。并且Pi演算可以用来描述结构不断发生变化的并发系统, 而Web服务组合是一种结构可能会发生变化的系统, 所以本文将采用Pi演算对服务组合进行描述及验证。
2 服务组合的正确性及其验证方法
从技术上说, 服务计算的价值在于服务重用, 而重用的目的则是使服务增值。除了服务本身的重用外, 组合不同的服务以产生不同于各个单一服务的功能, 也是研究的重点之一。服务组合是指:由各个小粒度的服务相互之间通信和协作来实现大粒度的服务功能;通过有效地联合各种不同功能的服务, 服务开发者可以借此解决较为复杂的问题, 实现增值服务。比如常见的旅行预定服务、订单服务等, 都是组合已有的组织内和组织外的服务来实现单个服务所不能完成的复杂功能。
但是, 如何使得服务真正进入实用的阶段, 使得服务实现跨组织、跨管理域的系统集成和自动交互, 这就要求我们对组合服务的正确性进行验证即判断组合服务是否与期望中的服务等价。考虑到服务是在整个网络上进行交互和组合, 其面对的组合对象和环境复杂多变, 同时鉴于专门用于描述移动进行的Pi演算在描述此类问题上具有一定的优势, 所以, 本文将利用Pi演算的方法来进行服务组合的正确性验证。
2.1 服务组合的正确性
文献[2]给出了服务组合的正确性定义。但没有考虑QoS属性。本文中对其定义如下:
定义1服务组合如果是正确的, 设该服务组合能够被建模为解决方案模型S, 而客户需求可表示为规范P, 那么如果S的功能及非功能属性均能满足P, 即:若S与P使用进程代数来表示, 而S与P的逆之间存在弱互模拟关系, 则称S是正确的。
2.2 正确性的验证方法
工程上常常采用直接验证方法, 所谓直接验证, 就是直接对流程描述进行分析。但是, 这种分析在单个语法上是较为容易进行的, 而却难以保证组合逻辑整体上的正确性。因此, 各研究组织和机构都提出了相应的形式化解决方法, 对组合的正确性进行严格的判定。本文采用基于Pi演算的方法对组合正确性进行验证。验证的主要内容包括:
模型的正确性:如同步是否正确?是否存在死锁?消息是否会丢失?
行为等价性:两个Web服务行为等价是指从Web服务使用者的角度来看这两个Web服务的行为完全一致。在进程代数中, 有两种行为的等价性定义:强相似 (strong bisimilarity) 和弱相似 (weak bisimilarity) 。
下一节中我们以一个旅行计划服务为例来给出用Pi演算对Web服务组合的形式化描述以及验证方法。
3 实例
一个典型的旅行计划服务的业务流程如下:客户通过通道order发出旅行计划请求 (包括功能及非功能方面需求) , 旅行代理收到旅行计划后, 向航空公司及酒店预定机票和房间, 同时并搜索旅游景点。航空公司、酒店及景点搜索将结果反馈给旅行代理, 代理依据景点与酒店距离, 向交通公司预定交通方式, 交通公司将预定结果返回给旅行代理, 最后旅行代理返回结果给客户。我们用Pi-演算流图来描述这个组合的业务流程如图1所示, 图中矩形代表进程, 实线为进程间固定通信通道, 虚线为动态通道。从客户的角度来看, 与之交互的服务是一个单一的组合服务, 组合服务和客户间的交互通道为order和ans, Travel服务作为一个中心协调者来负责调用和组合子服务FlightAndHotel、Attraction和CarOrBike, 其内部通道fAh、att、tra、f Ahres、attres、trares以及内部交互对客户来言是不可见的。
3.1 旅游信息系统中服务的描述
(1) Customer沿通道order向Travel发送旅行计划请求req和动态通道ans, 同时在通道ans等待结果。Pi演算进程建模Customer如下:
(2) Travel从通道order收到通道名ans和旅行计划请求req后, 分别沿着通道f Ah、att向FlightAndHotel和Attraction发送旅行计划及内部通道f Ahres、attres, 并从内部通道fAhres、attres等待处理结果resultFH、resultAtt。Travel根据resultFH及resultAtt, 在旅行计划请求req中添加预定酒店与景点间的距离信息, 则请求变为reqT, 再沿通道tra向CarOrBike发送reqT及内部通道trares, Travel在通道trares等待处理结果resultTra。最后, Travel将结果返回给Customer。Pi-演算进程建模Travel如下:
(3) FlightAndHotel从通道fAh收到旅行计划req和内部通道f Ahres后, 根据票务及住宿情况沿通道f Ahres向Travel返回结果。用Pi-演算进程建模如下:
同样Pi-演算建模Attration及CarOrBike如下:
(4) 由Travel、FlightAndHotel、Attraction、CarOrBike所组成的组合服务TravelService表示如下:
3.2 利用Pi演算进行正确性验证
使用形式化工具的目标是协助系统设计和验证。当系统模型建立后, 则可利用Pi-演算来推演系统的行为, 同时验证模型的正确性, 如发现系统行为不完整、死锁、缺少同步等。每次修改模型时, 都要进行这些检查, 以保证系统是一直按照需求设计, 并且在正确地实现。
作为一种强大和成熟的形式化方法, Pi-演算有支持其正确性验证和相关应用的工具, 如JACK工具集、基于Pi-演算的语言PICT[4]、可执行的Pi-演算EPI以及传值进程代数工具VPAM等。本文采用基于New Jersey SML语言编译器的MWB (Mobility Workbench) 工具。MWB工具是用于操作和分析移动并发系统的自动化Pi-演算工具, 它使用函数式编程语言SML (即标准元语言) 构建, 具体使用的是朗贝尔实验室实现的SML/NJ110版。验证时的软件实验环境为:Windows XP SP2, MWB'99, version 4.135, SML/NJ版本为110.0.7。下面对组合的Web服务模型进行推演和验证。
使用MWB工具对代数表达式进行语法分析可以发现进程定义的一些基本错误:如类型错误、缺少同步、不完整的行为等, 并可利用工具的推理功能排除一些最常见的错误。用Pi-演算描述的客户与组合服务应该是观察等价的, 也即客户的行为与组合服务的动作是互补的。如果组合服务满足客户需求, 则客户的逆进程与组合服务进程应该是等价的。下面对客户进程求逆如下:RevCustomer (order, resultFH, resultAtt, resultTra) =order (ans) .order (req) . ('ans
将组合服务系统消除内部行为, 即?动作, 则组合服务系统变为:
将进程Customer、Travel、FlightAndHotel、Attraction、CarOrBike、TravelService及RevCustomer写入到文件"TravelSystem ag"中, 并将此文件放置到MWB的目录下。利用命令input"TravelSystem.ag"建立各个进程、命令deadlocks对TravelService进程及RevCustomer进程进行检测, 结果表明各个进程均无死锁现象、命令weq RevCustomer TravelService进行弱相似判定, 得出结果:
The two agents are equal.
Bisimulation relation size=10.结果显示了此服务组合的正确性。
4 结束语
Web服务及其组合的形式化描述和验证, 是Web服务中一个重要的研究工具。因Pi-演算的优势, 所以用其作为描述Web服务组合的形式化工具。本文利用Pi-演算对Web服务组合建立形式化模型, 给出了基于Pi-演算的形式化描述及Web服务组合的正确性验证方法, 并给出一个实例来说明。将来的研究工作包括:形式化工具MWB自动求逆操作及语义方面的问题。
摘要：对于Web服务及其组合而言, 保证其正确性并实现增值服务是十分必要的。Pi-演算是一种移动进程代数, 可用于对并发和动态变化的系统进行建模。通过建立一个实际的模型, 用Pi-演算对Web服务及其组合进行建模, 并利用形式化工具对建立的组合模型是否正确以及是否满足需求进行了验证。
关键词：Pi-演算,进程代数,Web服务,服务组合,形式化方法
参考文献
[1]Parrow J.An introduction to theπ-calculus[A].Jan A Bergstra, Al-ban Ponse, Scott A Smolka.Chapter to appear in handbook of Pro-cess Algebra[C].Elsevier, 2001.
[2]廖军.面向服务的计算 (SOC) 中服务组合的研究——服务计算中一个关键问题的解决方案[D].成都:电子科技大学, 2006.
[3]Milner R., Parrow J., Walker D.A Calculus of mobile processes, part I/II.Journal of Information and Computation, 1992 (100) .
[4]Pierce, B.C., “Programming in the Pi-Calculus:An Experiment in Programming Language Design.”Lecture notes for a course at the LFCS, University of Edinburgh., 1994.
[5]Riccardo Pucella.Notes on Programming Standard ML of New Jer-sey[M].Cornell University.2001 (1) .
语义Web服务组合方法研究 篇5
一般地，语义Web服务的组合方法按其关注点的不同可分为：面向Web服务行为的组合方法、面向Web服务功能的组合方法和基于Web服务类型的组合方法;按其实现方式的不同可分为：面向状态搜索算法的组合方法、面向自动推理的组合方法和面向人工智能规划的算法。
1 基于情景演算的人工智能规划方法
这类方法的基本思想是使用人工智能规划中的动作来对Web服务进行建模，利用人工智能中的规划算法来进行Web服务组合。它所找到的组合服务通常比基于服务输入、输出参数的类型匹配的方法要来得准确，但是这类方法所能适用的Web服务范围比较有限。
我们可以把Web服务看作是AI规划中的动作。在经典的规划问题中，动作由动作的前提条件和效应所刻画，而动作的前提条件和效应是参与动作的个体的一组状态构成，动作的执行将使得某些个体处于新的状态之中。例如在经典的积木世界里面，使用手臂举起物体的动作pickup可用PDDL(Planning Domain Definition Language)描述如下：
情景演算最基本的思想就是通过把动作和情境(situation)具体化(reify)以方便进行一阶逻辑推理。所谓情景，形式上就是参与规划的个体所处的状态。在情景演算中，我们用流(fluent)来抽象整个个体的某一特性随情景变化的过程，而个体的状态则就是个体在特定情境下所具有的特性。假设初始情景S0恰好满足动作pickup(a)的前提，也即是说S0为{clear(a,So),arm-empty(S0),…}，那么我们只要通过一步的推理就可得出执行动作pickup(a)后的情景是{holding(a,do(pickup(a),So,…}，其中do(pickup(a))是情景集合上的一函词，指定了执行动作pickup(a)之后相应的情景迁移。
情景演算通常包含两类公理，一类是动作的前提公理，用于指定各个动作能够被触发的条件;另一类是流的后继公理，用于指定各个状态在每个动作执行之后的变化情况。就上例来说，动作pickup的前提公理是Poss(pickup(ob),S)≡坌ob.cleat(ob)∧armempty。而流on-table的后继公理是on-table(x,do(action,S))≡on-table(x,S)∧action≠pickup(x)∨…其显得更为复杂些。
Web服务的并发行为特性和经典规划中的动作的行为特性是非常不一样的，而针对经典规划问题提出的情景演算仅能产生由一组顺序动作构成的计划，因此在处理循坏、非不确定性和并发性时的行为需要一个解释器，而不是一个规划产生器。Web服务的执行通常会导致新的个体产生，这些个体通常作为Web服务执行的结果返回给用户;而经典规划中假定参与规划的个体不会在规划的过程中产生或消失，动作执行只是导致个体的状态发生变化。
2 基于模型检验的人工智能规划方法
如果把Web服务进一步细分为感知动作(sending action)和实效动作(effect action)两类，则Web服务组合问题可以转化为不确定领域中的条件规划问题。下面我们将要介绍的用于服务交响自动化的规划算法正是反映了上述思想，这个思想对服务组合的自动化来说具有极大的借鉴意义。另外，我们可以在BPEL4WS上使用不确定领域中的规划算法，利用规划中的动作来刻画Web服务的交互信息，能够较好地处理Web服务的非确定性，产生非常健壮的Web服务组合方案。虽然这种方法避免了处理Web服务产生的新个体，但在Web服务的交互信息的层面上进行程序综合并不十分适合于面向功能的语义Web服务组合。所以使用这一类方法的服务组合方案一般是两段式的，即先使用基于输入输出参数的类型匹配或面向服务功能的人工智能规划的服务组合方法寻找满足查询的组合服务，然后针对这个组合服务使用这类方法找出与该组合服务交互的其他Web服务。
这里的规划算法的基本思想是先用迁移系统(transition system)来刻画初始状态在各个动作执行后的迁移过程，然后用模型检验检查目标状态的可达性。目标状态的可达性蕴含了规划算法处理不确定性时的健壮性。如果在其中定义了多种可达性，每种可达性的迁移过程是不一样，但是每个迁移过程都可以通过OBDD进行编码。下面我们简单的介绍一下OBDD(Ordered Binary Decision Diagram)和用于刻画这个迁移过程的程序框架。
例如对于有三个命题变量〈P,Q,V〉的系统，状态集合{〈T,T,F〉，〈T,T,T〉}可以用命题逻辑的表达式PQ来表示，它的一个OBDD表示如图1所示，其中实边表示把源节点的变量赋为真T，虚边表示把源节点的变量赋为假F。
在规划中，我们习惯于用一阶逻辑谓词来刻画规划中的动作和状态。但注意到参与规划的个体数量n是有限的，我们就把一阶逻辑谓词转化为命题词。由于任意的动作都可以看作从一组状态集合到另一组状态集合的迁移，我们令rn(Old)为状态集合上的一个函数，用于计算这样的状态集合New，使得New中的元素不包含于状态集合Old中但却能迁移至状态集合Old中的状态。设规划问题的初始状态集合为I，目标状态集合为G，我们可以使用下面程序刻画与这个迁移过程相对应的迁移系统：
对上面这个程序进行模型检验，若GENERATEPLAN(I,G)=Ф，则不存在满足要求的规划。否则，存在满足要求的规划。
3 基于参数匹配的形式化推理方法
参数匹配的形式化推理方法(Rao)依赖于输入输出参数类型的上下位匹配，只不过该方法借鉴了自动化程序综合的思想，提出了采用线性逻辑推理进行Web服务组合，因而具备对Web服务进行参数个数的匹配的能力。由于该方法所采用的线性逻辑具有不可判定性，这从一定程度上削弱了它能够对Web服务进行参数个数的匹配的优势。
线性逻辑不同于经典逻辑，它以资源的观点来看待命题，茚表示两个资源都存在，茌表示两个资源中必有一个，表示消耗前面的资源可以产生后面的资源。例如，分别用D和C表示一美元和一包烟，那么“两美元能购买一包烟”可以表示为D茚DC。
Rao用线性逻辑来刻画Web服务和参数类型的上下位关系。譬如一个具有I1和I2类型输入参数和O类型输出参数的Web服务可表示为I1茚I2O;又譬如SbSp可以表示Sb是Sp的子类。
线性逻辑和并发系统两个重要的计算模型———Petri网和进程代数都有着深刻的联系。图2给出了一个用线性逻辑对Petri网进行形式化的例子，其中!是模态词，用于产生无限个拷贝。
组合服务的进程构造子实质上就是进程代数中的顺序运算符“.”，不确定选择“+”和并发运算符“|”。通过对每个推理赋予一定的操作语义(即产生对应的Web服务的进程代数表达式)，我们可以从推理序列获得组合Web服务的进程代数表达式，这个表达式又可以直接翻译成组合Web服务的服务模型。
例如Web服务exchange可以让客户用一张礼券换取一支铅笔，即Coupon ExchangePencil;Web服务buy可以让客户付一美元买一支铅笔，即DolarBuyPencil;那么我们可以得出结论;无论客户是选择Web服务exchange还是buy，都可以获得一支铅笔，即Coupon茌DollarExchange+buyPencil。在Rao的方案中，与这对应的推理步骤是，其对应的进程代数表达式是exchange+buy。
4 基于搜索的方法
语义Web服务组合和语义Web服务匹配的联系是非常密切的，这里所讨论的一类服务组合算法就是建构于服务匹配之上的。
一个Web服务S能够满足一个查询Q意味着：对于查询Q提供的所有输入，Web服务S必须都能接受;对于查询Q所要求的所有输出，Web服务S必须至少满足其中之一。根据Web服务类型之间是否存在互相包含或相交的关系，我们可以定义一个Web服务S能够满足一个查询Q的程度(按从高到低的顺序)：
1)Exact
type(P,Q)≡type(P,S);
2)plugIn
type(P,Q)哿type(P,S)如果P是输入参数;type(P,S)哿type(P,Q)如果P是输出参数;
3)subsume
type(P,Q)哿type(P,Q)如果P是输入参数;type(P,Q)哿type(P,S)如果P是输出参数;
4)overlap
如果P输入参数;如果P输出参数。
在确定Web服务满足查询的程度时，输入参数类型的上下匹配方向和输出参数类型的上下匹配方向正好相反。例如有四个在线销售书籍的Web服务S1,S2,S3和S4。S1接受中国银行的和花旗银行的人民币信用卡，S2接受所有的人民币信用卡，S3接受中国银行的人民币信用卡，S4接受花旗银行的多币种信用卡。如果用户希望使用手中的中国银行和花旗银行的人民币信用卡来购得一些书籍，那么从输入的角度看，服务S1满足用户查询的程度是exact;服务S2满足用户查询的程度是plugIn;服务S3满足用户查询的程度是subsume;服务S4满足用户用查询的程度是overlap。如果进一步考虑输出的话，假定Web服务S1只出售科技书，那么服务S1满足用户查询的程度就降为plugIn。
根据上面的定义可知，仅是在subsume或overlap程度上满足查询的Web服务是无法单独满足我们的确切需要的。为此，它必须与其他Web服务“相加”，并且这些相加的Web服务必须能够囊括查询提供的输入。这正是文献[1]中的服务组合算法的基本出发点，该算法通过一个矩阵对服务进行初步的“相加”以得到一个在exact或pluhIn程度上满足查询的组合Web服务，然后再不断的向前搜索直至获得要求的输出。
矩阵的维数由需要匹配的输入参数的个数决定，矩阵的每个维对应着一个输入参数，矩阵中的元素是一组Web服务，它们在矩阵的各个维上的分量是对应的输入参数所能接受的类型。在上述的例子中，需要匹配的输入参数只有一个，即购买书籍所使用的信用卡，我们用图3来示意这个一维矩阵。由图3可以看出，将S3和S4组合在一起也能够在plugIn程度上满足查询。
目前大多数的语义Web服务匹配算法都局限于服务参数类型的匹配，但这不等于说不能从服务的功能上和从服务的外部行为上来进行服务匹配。如果从服务的功能上和从服务的外部行为上来进行服务匹配，那么多少都有计算性和复杂性方面上的诟病(最显著的如计算的不可判定性)，难以获得普遍的适应性，这也是目前大多的语义Web服务匹配算法仍停留于参数类型匹配的原因之一。
5 基于自动机的形式化推理方法
自动机和进程代数都可以很自然的刻画Web服务的行为以及相应的状态变化，例如一个接收search消息然后发送result消息的Web服务S可以用图4(a)中的进程代数公式来刻画：
如果不区分动作前缀“?”和“!”在意义上的不同，那么图4(a)中的各式同时也刻画了一个自动机。它的字母表为{?search,!result}，状态集为{S0,S1}，并且S0既是初始状态也是终止状态。
另外，图4(b)和图4(c)分别给出了另外一个Web服务R和我们想要获取的组合服务Q。我们的目标是在自动机S,R和Q的基础上构造一个“组合”自动机，并使用PDL对其进行编码以检验其可满足性。由于“组合”自动机中所有的动作都来自于自动机S和R，我们用命题变量MovedS和MovedR分别来模拟自动机S和R在“组合”自动机中的动作。设u是由所有原子程序的并构成的程序，即，我们有：
自动机S,R和Q在“组合”自动机的动作遵循图5中的PDL公式。
(a)刻画自动机S的各个状态在每种输入下的动作的PDL公式
(b)刻画自动机R的各个状态在每种输入下的动作的PDL公式
显然，这个“组合”自动机还须满足初始状态和接受状态等其他一系列的要求。具体的说，这个“组合”自动机的初始状态必须满足
Q0∧S0∧R0，并且“组合”自动机的接受状态必须满足[u](Q0→S0∧R0)。最后，我们必须指明各个自动机中的每个状态都是不同的，即在自动机Q中有[u](Q0→┐Q1);在自动机R中有[u]R0→┐R1);在自动机S中有[u](S0→┐S1)。
从上面构造“组合”自动机的过程中，我们可以看出文献[2]的基本思想与模型检验的原理如出一辙。这不是偶然的，因为从理论上讲，一个迁移系统与一组动态逻辑公式是对等的。所以不论这个迁移系统是用于刻画动态逻辑中的Kripke语义结构，或是用于刻画自动机，还是用于刻画进程代数的操作语义，它从形式上总是与一组动态逻辑公式相对应。
6 结束语
Web服务组合和服务描述是分不开。Web服务的输入输出参数类型、执行前提和效果和消息交互序列等信息不仅是服务描述的对象，也是Web服务组合的根基。从本论文的论述可以看出，Web服务组合问题很难获得一个统一的解决方案。这是因为Web服务组合所依赖的计算理论基础决定了Web组合方法必须根据其关注的焦点在计算能力和可行性作出适当的折衷。
参考文献
[1]Ion Constantinescu,Boi Faltings,Walter Binder.Large Scale,Type-Compatible Service Composition.In:Proc.IEEE Int Conf.Web Services.IEEE CS Press,2004.
[2]Daniela Berardi,Diego Calvanese,Giuseppe De Giacomo,Maurizio Lenzerini and Massimo Mecella.Automatic Service Composition Based on Behavioral Descriptions.Int.J Coop.Inf.Sys,14(4),2005.
[3]陈旭辉.基于规划的语义Web服务组合技术研究[D].福州大学,2006.
Web服务组合方法综述与分析 篇6
随着因特网的发展,基于Web的应用数量以惊人的速度增长。在Web服务出现以前,由于各个组织、机构之间平台的互异性,分布式网络面临的一个重大问题是各种平台之间的互操作性太差。Web服务标准(WSDL、SOAP和UDDI)的出现解决了这个问题。Web服务并不仅仅是一种技术,更是一种应用框架,一种系统架构的方式和一种应用的思想。它的优势在于无缝互操作性,它允许在一个平台上用一种语言编写的应用程序可以使用在另一个完全不同的平台上以完全不同的语言编写的应用程序的服务[1]。
但是目前单独的Web服务已经不能满足用户的要求,于是研究者开始考虑Web服务组合。Web服务组合是重用已有的一系列Web服务,形成了新的复杂的服务。
本文介绍了Web服务组合的概念,给出了目前常用的五种Web服务组合方法,然后,根据服务组合的四种特性,对这五种方法进行了分析比较,为研究者完善现有方法提供参考。
1 Web服务组合
虽然越来越多的稳定易用Web服务共享在网络上,但单个的Web服务能够提供的功能有限。为了更加充分地利用已有的Web服务,有必要把已有的Web服务组合起来,以提供更为强大的服务功能。
Web服务组合方法从组合方案生成方式来分有两大类:静态组合和动态组合。静态组合意味着请求者应在组合计划实施前创建一个抽象的过程模型。抽象的过程模型包括任务的集合以及任务间的数据依赖关系,每个任务包含一个查询的子句,用来查找完成任务的真正的Web服务。因此这里的自动仅指Web服务的选择和绑定是由程序自动完成的。静态组合中最常用的是用图来描述过程模型。而动态组合不仅自动地选择、绑定Web服务,同时更重要的是自动地创建过程模型。这需要请求者指定一些约束关系,包括Web服务间的依赖关系、用户的偏爱等[2]。
2 Web服务组合方法
一旦组合的本地能力被充分开发完以后,服务组合就应运而生,由于第一代的组合语言,比如:IBM公司的WSFL(Web Service Flow Language),BEA系统的WSCI(Web Services Choreography Interface)等等,都是不可兼容的语言,所以开发者们进行了下一代语言的研究。比如BPEL(Business Process Execution Language),就是结合了WSFL和WSCI,用Microsoft公司的XLANG进行说明。这里,我们选择了四种目前常用的Web服务组合方法进行介绍[2,3]。
2.1 BPEL
BPEL称为商业流程执行语言,是一门基于XML的语言,它支持面向过程的Web服务组合方法,最初由BEA、IBM、Microsoft开发,然后由OA-SIS进行标准化,是为了整合Web服务而制定的一项规范标准。组合的结果称为一个过程,参与组合的服务称为参与者,消息交换称为活动,参与者通过WSDL进行相互活动。
BPEL流程是一个流程图,用来表达特定业务的处理逻辑和算法,流程的每一步成为一个活动。BPEL4WS主要利用WSDL使得服务的动态绑定成为可能,但它没有提供具体方式来选取动态绑定时需要调用的服务,并且BPEL4WS不支持在应用运行时的流程模型的调整。
2.2 基于语义的Web服务组合方法(OWL-S)
基于语义的Web服务可以使Web资源通过内容和关键字被获得,DARPA Agent Markup Language(DAML)语言扩展了XML和RDF(Resource Description Framework)来提供一些构架,这些构架能创建机器可读的本体和标记信息。OWL-S(以前被称为DAML-S)是一个服务的本体,能够自动的发现、调用、组合、执行监测等[4]。
OWL-S主要用三类本体对服务进行建模:ServiceProfile、ServiceModel和ServiceGrounding。
(1)ServiceProfile用来描述用户的需求以及服务能给予用户说明需求;
(2)ServiceModel用来描述服务怎么工作;
(3)ServiceGrounding给出的是如何使用服务的信息。
过程模型是一个服务模型的子集,通过输入、输出、前提条件、后置条件和自己的子过程进行描述服务。OWL-S分成三种类型的过程:原子过程、简单过程和组合过程。原子过程没有子过程;简单过程不能被直接调用,也不能被用作为一个抽象的元素;组合过程由一系列子过程组成,并由控制流结构描述。
2.3 网络组件方法(Web Components)
网络组件方法把Web服务看作一个个组件,这样做的目的是为了支持基本的软件开发准则,比如重用、扩展等。主要思想就是组件把组合逻辑信息封装成为一个类,而且Web组件的公共接口可以发布并能重用。
组合逻辑由组合类型和信息依赖组成,组合类型包括两种:顺序和选择执行。顺序决定是否一个组件能够执行构成组合部分服务;选择直接定义了是否一个组件能调用选择的服务,直到成功。信息依赖定义了输入输出消息映射,包括三种:合成、分解和信息匹配。合成通过组合组件的输出消息产生一个组合服务的输出消息;分解把组合服务的输入消息绑定进入组件服务的输入消息;消息映射允许组件服务的输入输出映射。
2.4 Petri网
Petri网是一个成熟的流程建模方法,一个Petri网就是一个有向、连接的双向图。Petri网由两种结点:库所和变迁,有向弧,以及令牌等元素组成。有向弧是库所和变迁之间的有向弧;令牌是库所中动态对象,当变迁引发时,动态对象从一个库所移到另一个库所,两个库所或变迁之间不允许有弧。
我们可以把Web服务建模成一个Petri网,把变迁看成方法,库所看成状态,这样每个Web服务都可以用Petri网来描述服务行为并且有两个端口:一个输入库所和一个输出库所。在任何时候,一个服务都处在以下的状态之一:非实例化、准备、运行、挂起、完成。当我们为每个服务定义了一个Petri网后,组合运算符就开始进行组合:序列、选择、无序序列、重复等,这些运算符保证了一定能够转移终结的特性。
2.5 Model Checking and Finite State Machines
在其它的组合方法中,有模型检验方法,一般把Web服务组合过程建模成梅尔利机(Mealy machines)和自动的服务组合有限状态机(FSM)等。模型检验方法被用来规范地验证有限状态并发系统,我们能利用像工作流方式一样应用模型检测方法到Web服务组合,然后检测它的正确性。事实上,自动的服务组合方法是大部分组合方法努力的最终目标。
3 对比分析
在文献[2]和[3]中,作者使用了几种标准来对Web服务组合方法性能进行了分析比较,综合以上文献,给出五个标准分别是:
3.1 连接性(Connectivity)
虽然Web服务有不同的描述方式,但是所有的方法都必须保证具有连接性。因为Web服务组合方法本身就是把候选服务组合成以满足用户要求的其他服务,只有具备了可靠地连接性,服务组合才有可能,所以连接性是组合方法的基本要求。
3.2 非功能性(Nonfunctional Properties)
尽管所有的方法都保证了连接性,但是大部分组合方法却忽视了非功能QoS(Quality of Service)属性的描述,比如:安全(security)、可靠(dependability)、价格(cost)、反应时间(Execution duration)等[5]。以上方法中,只有OWL-S允许用户定义部分非功能属性,但也没有得到完全的支持。
3.3 组合正确性(Composition Correctness)
组合方法的正确性需要通过服务和服务组合方法规范来验证,其中,BPLE和OWL-S没有提供有效的正确性验证。BPEL是一个更多为了处理执行的语言,因此,很难提供一个形式化的标准来验证正确性。除此之外,其他组合方法都提供有效的正确性验证。比如,OWL-S可以通过转换成Petri网或其他形式来进行正确性的验证。
3.4 自动组合特性(Automatic Composition)
自动服务组合一直是服务组合方法的研究热点,而许多组合方法也是因为这个目标被提出来的,自动组合提供一个更快的应用开发,更安全的复用,便利的用户交互等等。如果没有自动服务组合,终端用户和应用程序开发者只能详细地指定一个目标和一个聪明的组合引擎来选择合适的服务,然后透明地提供给用户。自动组合主要的问题是如何识别候选服务,然后组合它们,再来验证它们和用户的请求是否接近。目前,利用FSM建模Web服务的方法是最有前景的自动组合方法。
3.5 组合规模可扩展性(Composition Scalabili-ty)
在现实环境中,终端用户需要与许多服务进行交互,然而企业应用将会调用很多相关联的服务。因此,一个重要的问题是,以上提出的方法如何同这些众多的关联服务进行很好的规模扩展。
根据以上五种特性,给出了前面提到的四种Web服务组合方法性能对比表,如表一所示。
服务组合首先必须保证可连接性,只有保证了可连接性,我们才能确保服务能够通过合理的输入输出被组合成功。其次,非功能QoS属性也是必要的,因为只有合理的非功能特性,服务才能被用户接受。服务组合的正确性保证了服务的安全性和可靠性。
4 结束语
Web服务组合已经成为Web服务领域的研究重点,虽然当前有很多的Web服务组合方法,但是都是抽象方法和工业方法并存,还没有一种能够结合两者的组合方法,也还没有一种方法能够同时满足以上提到的四个特性的方法。这是因为科学研究方法在工业上成熟应用还有一定差距,也就是说,形式化的研究方法很难应用到现实的工业环境,其中扩展性就是一个典型的问题。
从上面的对比分析,我们可以看到,如何把形式化的研究方法成功的结合或是引入到工业化的生产中是未来研究的方向。所以说,产生一个工业化的Web服务组合标准,并推广到科研的领域将是以后的热点和难点。
摘要：本文介绍了Web服务和服务组合的概念,根据Web服务组合方法的四个特性,对几种当前常用的Web服务组合方法进行了详细的分析和比较,探讨了未来Web服务组合的发展方向——自动组合方法,为研究自动Web服务组合提供借鉴。
关键词：Web服务,服务组合,自动组合
参考文献
[1]倪晚成,刘连臣,吴澄.Web服务组合方法综述[J].计算机工程,2008,34(4):79-81.
[2]Maurice H.ter Beek,Antonio Bucchiarone,and Stefania Gnesi“.A Survey on Service Composition Approaches:From Industrial Standards to Formal Methods,”Second International Conference on Internet and Web Applications and Services,ICIW'07,2007,pp.1-19,ICIW'07.
[3]N.Milanovic and M.Malek,“Current Solutions for Web Service Composition,”IEEE Internet Computing,vol.8,no.6,pp.51-59,2004.
[4]A.Ankolekar et al.,“DAML-S:Web Service Description for the Semantic Web,”Proc.Int’l Semantic Web Conf.(ISWC),LNCS2342,Springer-Verlag,2002,pp.348-363.
Web服务组合验证 篇7
伴随着Internet的飞速发展和web服务的跨平台、语言独立、松散耦合等特性,越来越多的企业将其业务功能通过web服务的形式发布在Internet上。单个web服务通常只提供惟一的调用函数完成单一的功能,为了有效利用Internet上分布的易于执行的轻量级服务,创建功能丰富且易于用户订制的复杂服务,将松散耦合的web服务有机组织成更为可用的系统,用来在不同的web服务之间共享信息,所以出现了web服务组合技术。近年来web服务组合技术也得到了广泛的应用。
然而web服务组合在应用中还存在着很多的问题。特别是在web服务组合应用程序的开发和测试过程中,需要动态的改变程序的结构和行为,以对开发的web服务组合应用程序进行改进,在开发过程中对web服务结构的重复修改是极其繁重的。针对这种情况,本文提出了一种web服务组合仿真的方法,动态的模拟各服务程序的运行情况,验证各个服务之间的合作关系,减少真实开发中的重复修改,提高开发过程的效率。
2 Web服务组合
服务组合(service composition)是以特定方式,按照实际应用逻辑,将若干服务组织成为一个逻辑整体的方法、过程和技术[1]。
服务组合本质是一个分布式的设计过程,其特点是在原有服务的基础上进行扩展和限定,而不是原始开发[2]。web服务组合需要解决以下几个主要问题:
(1) 采用怎样的web服务组合模型作为组合研究的框架基础;
(2) 在可替换的服务中如何根据QoS要求进行质量驱动的服务选择;
(3) 建立怎样的代价模型以评估web服务组合的代价;
(4) 怎样定义各个组成部分之间的关系;
(5) 怎样验证和测试组合的web服务;
(6) 如何对QoS或其他行为进行监控,保证在满足需要的同时,能够高效的利用资源。
当前解决服务组合的方法主要有:基于工作流(workflow)的方法、基于AI Planning的方法和基于软件工程的方法。
本文的仿真是建立在基于工作流的方法上,利用web服务业务流程执行语言BPEL[3]来实现对业务流程的建立。对web服务组合这些问题的解决,决定了我们工作复杂程度,如果这些问题的解决能在仿真过程中实现,那么实际业务开发进程的速度将会大大提高。当前我们主要的工作集中对基于BPEL的服务组合的实现进行研究。
3 基于BPEL的web服务组合机制
BPEL(Business Process Execution Language)是由IBM、BEA、Microsoft提出的业务流程执行语言,是基于 XML的流程描述语言,支持web服务技术系列,包括SOAP、WSDL、UDDI、Web服务可靠性消息、Web服务寻址、Web 服务协调以及Web 服务事务。BPEL主要基于WSDL1.1、XML Schema1.0和XPath1.0 规范,对WSDL 的依赖性最大,所有需要的外部资源和伙伴都被描述为WSDL 服务[4]。
3.1 BPEL的关键元素
BPEL引入了活动、伙伴、伙伴链接类型和服务引用、变量、相关性、错误处理、作用域和消息属性等关键元素。
(1)活动:
流程的每一步称为一个活动。活动包括基本活动和结构化活动。基本活动是与外界进行交互的最简单形式。基本活动:
结构化活动规定了一组活动发生的顺序,结构表达了业务协议中所涉及的控制模式、数据流、故障和外部事件的处理以及在流程实例之间进行消息交换的协调。结构化活动有:
(2)伙伴、服务链接和服务引用:
BPEL把与流程交互的其他服务称伙伴(Partner)。
服务链接用来直接模拟对等伙伴关系。服务链接类型定义了关系中每个服务所扮演的“角色”,并指定每个角色所提供的端口类型。
BPEL定义服务引用(Service Reference)来 描述服务伙伴所需的动态数据,指定服务的描述信息、服务名称及服务引用相关的信息,且能动态地为服务选择提供者和调用它们的操作。
(3)变量:
variables部分定义了流程使用的数据变量,变量使流程可以根据交换的消息来保存状态数据和流程历史信息。
3.2 BPEL的绑定技术[5]
BPEL利用WSDL规范[6]提供的抽象功能描述与具体实现细节的分离机制,结合工作流模型的建模,对流程结点与具体的web服务之间的绑定可采取静态和动态两种方式。在静态方式中建模时直接绑定任务,如果能够确定任务在应用过程中不变更,可以节省动态绑定时查找任务所带来的系统开销,否则是存在缺陷的。动态方式中流程执行时,根据结点的抽象定义和该抽象定义与其实现定义的关联关系,动态查询UDDI注册中心,获取该抽象定义的所有web服务实现,并通过一定的选择策略来从中过滤选择最优的,完成任务执行。
3.3 BPEL的工作引擎
在选择工作流引擎时,主要从以下几个方面考虑:
·支持WS-*,尤其是BPEL4WS。可以与标准的WS通信;
·可以与模拟仿真进行整合;
·代码开源;
·有工具支持。例如GUI界面友好。
支持BPEL的工作流引擎主要有:Oracle BPEL工具套件、ActiveBPEL引擎、OBE(Open Business Engine)、PXE-Process Execution Engine、XFlow。通过验证和比较,我们选择了ActiveBPEL引擎作为构建仿真平台的工作流引擎。ActiveBPEL引擎有如下优势:
·完整性:ActiveBPEL引擎完整地实现了BPEL标准。
·方便性:ActiveBPEL引擎除了完全实现标准,还在包的发布,流程持久化,事件通知等方面加强了方便性,且易于扩展。
4 基于BPEL的web服务组合的实现
我们以智能卡注册控制过程的实例为基础,用BEPL实现了各种web服务的组合,并建立了业务流程,实现对智能卡注册业务的仿真。下面主要介绍服务组合模块的BPEL流程的实现和部署。
所用到的web服务主要有:提供CA信息web服务(CA Information service), 提供 certificate 模板的服务 (Certificate Template Service),提供CSP (Cryptographic Service Provider)的服务(CSP Service),还有用户服务(user service)。设定所用到的web服务都是已经准备好了,并且能够提供我们建立流程所需要的WSDL文件。
4.1 BPEL流程的实现
在BPEL中用receive、invoke和reply这三个简单活动分别定义了获取消息、调用外部web服务和返回结果这三个操作,通过使用结构化活动来定义这些简单活动彼此间的关系。在Active BPEL Designer中,可通过编辑界面的工具箱实现对基本活动图标和结构化活动容器图标的拖放,在增加这些活动的同时必须创建或者指定已经绑定到BPEL文件的WSDL文件。在WSDL文件里面,定义了的WSDL元素,如type/message/portType/operation/partnerLinkType等。
4.1.1 BPEL流程结构的设计
根据对智能卡注册业务流程分析,可将流程分成两步执行,首先是获取注册信息资料,包括数字认证中心信息服务(CA Information service), 证书模板服务(Certificate Template Service), 密码服务(CSP Service),用户服务(user Service)。调用这四个web服务在消息上不存在相关性,可以并行执行,所以将这四个web服务对应的活动置于一个flow容器中,其BPEL流程如图1所示:
第二步是调用具体CA服务,提交请求,获取注册号。在调用此web服务出错时,利用FaultHandler指出流程的出错处理。如图2所示:
4.1.2 BPEL的消息和赋值行为设计
在系统的BPEL执行模块中,有和各调用服务进行交互的消息,还有BPEL本身的输入输出消息,需要导入定义了这些消息格式的WSDL文件到BPEL工程里面。
按照将外部消息和内部变量分离开的赋值思想,在第一个invoke行为的前后、receive行为的后面和reply行为的前面添加了assign行为,专用于外部消息和内部变量的交互。
4.1.3 错误处理设计
利用FaultHandler指出流程出错的处理,出错处理的思想为:如果出现错误,抛给外层出错处理,如果不能处理则设置一个出错标记,暂停程序执行,等待人为处理。对错误的处理还需要对Active Designer添加程序插件来完成。
4.1.4 BPEL流程的完整设计
综合前面的设计,就可以得到整个BPEL流程的完整设计,如图3是 Designer图形化编辑界面生成的结果,此流程图对应的是一个完整的抽象BPEL文件。图中错误处理没有被显示。
4.2 BPEL流程的部署
对设计好的BPEL流程要进行部署到工作引擎运行。首先生成流程部署描述(Process deployment descriptor,简称pdd)文档,将在BPEL文件中定义的各个PartnerLink元素和实际的web服务终端联系起来,将消息发送给对应的具体web服务,从web服务中获得表示结果的消息。然后,将整个程序打包,生成业务流程存档(Business Process archived,简称bpr)文件。
当上述两个步骤结束后,BPEL引擎就能识别出该BPEL流程,完成部署。同时,引擎自带的Axis服务器会将BPEL流程生成一个web服务。流程运行的参数可以在BPEL引擎管理界面的Deployed Processes内查看。
查看的内容包括程序结构,运行路径,运行起止时间等,Active Designer工具还存在许多的不足,有许多结果参数,需要添加程序插件的方式来获得。通过得到的这些参数,能优化服务之间的结构,各个组成部分之间的关系;监控QoS或其他行为,保证在满足需要的同时,高效的利用资源,选择最优的服务组合方式。
4.3 服务组合模块的测试
开发测试是能够验证应用程序系统的开发是否达到设计目标的重要方式。部署所用的各个web服务和服务组合的BPEL流程后,部署SOAPClient客户应用程序,最后启动所有的J2EE容器,进行测试。依据BPEL规范,一个BPEL流程可对外发布成web服务,测试中可对此服务进行调用。如图4所示,BPEL引擎测试时对流程运行记录,每个被勾上的活动代表已经执行过了。
5 小结
本篇论文中介绍了web服务组合技术 ,以及基于BPEL的web服务组合机制,针对web服务组合在开发过程中的问题提出了对web服务组合进行仿真的思想。并利用Active Designer工具实现了对智能卡注册业务过程中服务的组合。实现web服务组合的仿真,我们要搭建完整的web服务组合仿真平台,当前我们的工作只是起步阶段,要完全实现对web服务组合应用程序开发过程的仿真,还有更多的工作要做。
参考文献
[1] 喻坚,韩燕波.面向服务的计算———原理和应用[M].北京:清华大学出版,2006年.
[2] 岳昆,王晓玲,周傲英.Web服务核心支撑技术[J]:研究综述[J].《软件学报》,2004,15(3):428~442页.
[3] Web服务:BPEL4WS专题[EB/OL].http://www-900.ibm.com/developerWorks/cn/Webservice/ws-theme/ws-bpel.shtml.
[4] 单既如,马殿富,朱岩.Web服务和BPEL规范在人力资源管理系统中的应用[J].计算机工程与设计,2007,28(16):3989~3993.
[5] 穆林.基于BPEL的WEB服务组合技术研究与实现[D][硕士学位论文].南京:河海大学,2006年.