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程序依赖图（相关技术） Web服务行为相容性分析及原型实现(2):http://www.751com.cn/jisuanji/lunwen_72349.html