1.1 现有服务兼容性分析方法
现在很多工作都是在抽象的控制流量模型级。形式化模型(例如自动机,进程代数)通常都是用在以下这些方法上:使用基于状态的代表服务,基于状态的模型服务等等,方便用户用行之有效的概念以及正式的方法来确定服务的兼容性。
然而,这些方法有一定的局限性。
首先,由于他们的模型的局限性,现有的方法只是考虑同步或异步一个沟通机制,例如,服务建模为自动和进程代数通常只使用同步通信机制,而Petri网建模为服务使用异步通信机制。
其次,因为它们可能含有一些不必要的序列之间的PEL活动导致BPEL控制流图不适合服务兼容性分析,如果BPEL用于兼容性控制流图分析,将会错过一些合格的BPEL流程。
为了解决现有的方法的局限性,基于BPEL控制流图,我们利用BPEL程序依赖图,服务中间表示一个服务的行为特征。BPEL程序依赖图只捕获必要“ happens-before ”活动之间的关系。基于BPEL程序依赖图,我们提出了一个结构
服务兼容性分析的分析方法。
2 现有方法的问题(开发背景)
在本节中,我们将阐述现有服务兼容性方法的缺陷,同时以此来证明我们新方法的优点。为了使过程更加直观,我们可以使用UML活动图。
图1(a )显示了BPEL流程,P1的同步调用一个旅行社服务以及航空公司的服务,但酒店服务使用异步调用;图1(b )和图1 (c)显示的BPEL流程P2以及航空公司的服务和酒店服务BPEL流程中的P3 ,分别在服务发现和选择阶段,这之中可能存在一个问题,那就是旅游服务和航空公司服务以及酒店服务相互兼容吗?这个问题被称为服务的兼容性。在现有的兼容性分析方法中。它的必要条件是有兼容接口,即通信活动。
沟通活动只能发生在成对数,例如,如果一个服务有一个消息发送活动-M,其它服务应该有一个相应的消息接收活动+米。因此,这些方法并不适用于分析,BPEL流程P1 〜 P3因为P1的兼容性没有对应的专用活动,补充活动活动时, P1 A1 A6的P2视为互补的活动A4的P2 。
服务的现有方法的另一个局限性在于它们只适用于集中服务。请注意,当服务环境只有一个单一的合作伙伴服务时,这被视为集中的合作伙伴服务; 当一个服务的环境中有多个自治合作伙伴服务,这些合作伙伴的服务被视为独立行事伙伴。如果一个服务有多于一个独立行事的合作伙伴服务,这些方法不能被用来分析该服务是否兼容其合作伙伴服务。这是因为在本组服务中的任何两个服务仍然是一个开放的系统,而方法是仅适用于服务组合物封闭系统,使用户可以利用行之有效的概念,以确定这两个服务是否兼容。因此,在图1的实施例中,现有的方法是不适用于个别分析是否P1和P2 , P1和P3是兼容的。
上面的讨论,我们可以看到,来自服务的兼容性分析的挑战。主要集中在以下两个方面。首先, BPEL流程均采用同步和异步通信机制。对于异步通信机制,一个单向<invoke>活动对应到一个<receive>的活性伙伴。而对于同步通信机制,一个请求响应的<invoke>的活动; 对应增加一个<reply>到<receive>活动的合作伙伴。这是具有挑战性检查采用同步任何两个服务的相容性沟通机制,因为通信这两个服务的活动不是成对的,服务可以有多个独立的代理伙伴服务。它仍然是一个挑战,分别检查这项服务是否与它的每一个合作伙伴服务兼容。
3 3. BPEL程序依赖图(相关技术)