您好,欢迎您来到我的个人博客!
柳正利的个人博客
文章内容

【论文分享】基于搜索的web服务反模式探测

0
发布时间:『 2018-04-25 22:52』  博客类别:学术研究  阅读(482) 评论(0)

【论文分享】,本文发表在2017年第10卷第4期的CCF B类期刊IEEE Transaction on Service Computing(TSC)上,作者提出了一种基于启发式搜索的web服务反模式探测方法,能够有效识别服务设计中的反模式。


作者:Ali Ouni, Marouane Kessentini, Katsuro Inoue, Member, IEEE

 

摘要 SOA被产业界广泛采用,并且被看作是架构设计技术的一个优先选择。和其他软件系统一样,因为一些一些原因,例如:计划的改变,时间压力或者糟糕的设计选择,基于服务的系统SBSs也可能会遭受糟糕的设计,例如反模式。因此,这可能会导致SBS产品很难演化并且表现出很差的服务质量。对于软件开发者来说,探测Web服务的反模式是一个手动、耗时和易错的操作。在这篇论文中,我们提出了一种基于协作并行进化算法的自动化方法来实现Web服务反模式的探测。这个思想是将多种探测方法相结合并且并行执行优化过程来找到识别Web服务反模式的一致方法。我们给出了八种常见的Web服务的反模式的实验结果。我们将提出的协作的P-EA方法和随机搜索,两种基于人口的方法以及一种先进的不是基于启发式搜索的方法进行了对比。实验结果的统计分析表明我们的方法在反模式探测方法更有效率,准确率和召回率分别达到了89%93%.

 

关键词  Web服务,Web服务设计,反模式,面向服务的计算,基于搜索的软件工程

简介

面向服务的架构(SOA)通过运用第三方提供的功能应用,已经成为设计复杂分布式软件系统的逻辑方法。在一个SOA架构中,一个服务请求者通过已经发布的和可发现的接口来使用服务提供者提供的服务,来满足他们特殊的需求。服务可以通过各种技术来实现,例如Web服务,OSGi,和SCA

Web服务是实现面向服务架构(SOC)模式的共同技术抉择。这样的例子有很多,像Google地图,PayPalFedExDropbox,和其他一些应用。Web服务必须仔细的设计和实现,才能同时满足所需的系统的设计和所需的QoS。实际上,对于正确的服务设计并没有一个实际的秘诀。一系列指导面向服务设计的指导性质量准则是存在的,如服务的灵活性,可操作性,可组合性,松散耦合性。但是,服务的设计被上下文,环境,和其他服务设计任务的决策所强烈影响,并且这些因素可能导致对质量准则的违反。与糟糕的设计和编程实践的编程模式的存在,是这种违反准则的表征。此外,普遍认为这些反模式导致各种各样的维护和演化问题,包括日益增多的bug率,脆弱的设计和不够灵活的代码。

尽管Web服务技术被广泛采用,但是对于这些反模式的自动化探测方法并没有被提出来。和面向对象编程的代码异味和反模式不同,SBS系统中反模式探测仍处于初级研究阶段。实际上,已经存在的针对Web服务反模式探测的工作都尝试提供一个定义和能表示常见反模式的主要特征。最近的工作在维度组合,结构和词法信息等更高层次的抽象层依赖一个声明式的基于规则的语言来描述反模式的主要特征。然而,在实际情境中,可以手动和有规则计算的反模式的数量可能会非常巨大。如果情况更糟,找到一个一致意见来描述和精确表示这些特征将会非常困难。因为这些原因,针对反模式的探测任务仍然是一个手动地,耗时的和主观的过程。

为了处理这些问题,我们提出了一个基于搜索的方法,这也是第一个自动的反模式探测方法。本文提出的方法是基于遗传编程方法,从Web服务反模式案例中利用静态的服务接口属性来生成探测规则。然而,生成规则的质量依赖于对反模式可疑情况的覆盖情况,并且保证这样的覆盖很困难。由于反模式案例覆盖情况很难评估,因此对于探测的反模式认定仍然有一些不确定性。此外,仅仅使用静态的服务接口属性可能并不能完全覆盖这些反模式特征。另一方面,在某些情况下,确定的Web服务反模式实例可能实际上不能作为常规实践被一致接受。

这篇文章继承了我们以前的工作。我们提出将Web服务反模式的探测看做是协作并行优化问题。思想是在优化过程中将不同方法并行组合到一起,目的是寻找针对Web服务反模式探测的一直规则。为此,我们使用并行进化算法,具有不同适应性的不同进化算法以并行协作方式被执行,来实现反模式探测这个共同的目标。

我们相信一个P-EA方法适合于解决我们的问题,因为它聚合不同的视角和专家水平来探测潜在的反模式,就像在适应性方面和一个相似问题说明的那样,这个问题就是Java项目中的代码味道探测。在我们的P-EA方法中,许多种群的个体同时进化。第一个种群运用遗传编程生成一系列的探测规则,与此同时第二个种群运用遗传算法探测反模式。两个种群在被评估过的Web服务同时演化,并且基于一致的发现对被采用的探测规则的质量进行更新,例如所有种群的探测结果的交互部分。P-EA方法没有涉及到两种进化算法的并行化,也没有基于一些交互部分在适应度函数水平在他们之间构建一致性来分类待探测的候选集合。这篇文章的主要贡献可以总结如下:

(1)我们提出来一个新颖的自动化方法,并将Web服务的反模式探测看做是一个协作的并行优化问题。在我们的方法中,有不同的适应模式的不同的进化算法被并行的执行来满足一个一致性的反模式探测。

(2)我们扩展了初始的属性套件,这一套件仅仅限制在Web服务接口水平。我们的方法包括i)Web服务代码水平的属性集合;ii)Web服务动态属性更好的揭示潜在的反模式特征。因此,从服务接口道人工代码都是可再次覆盖的。相反的是,通过调用Web服务可以获得动态属性。

(3)我们扩展了Web服务反模式案例的基础。为了鼓励在Web服务反模式探测领域的未来研究,我们将数据集放到了网上。

(4)我们扩展了方法的可评估性。我们在以下一些方面提出了一种关于我们方法的经验评估,i)我们从10种不同应用领域的选取了415Web服务;ii)三种额外的常见Web服务反模式。我们将P-EA方法和随机搜索,基于单种群的方法,已经存在的基于规则的方法进行了对比。统计分析说明了我们所提方法在探测Web服务反模式的效率,准确率达到了89%,召回率达到了93%

本文的如下部分组织如下:第二部分介绍相关背景材料。第三部分介绍了与Web服务探测相关的问题。第四部分详细说明了我们所提的P-EA方法。第五部分说明和讨论了所取得的实验结果。第六部分讨论了验证的不足。第七部分总结了相关工作。第八部分阐述了未来的研究工作。

相关背景

2.1 Web服务和Web服务反模式

依据WWW联盟的定义,一个Web服务被定义为一个被URL标识的软件应用,它的接口和绑定以XML来定义,描述和发现Web服务的接口用WSDL文档来描述,这个文档包括了这个Web服务的位置,提供的操作,输入/输出参数等这些结构信息。Web服务平台的目的是提供不同应用间的可操作性。

反模式是糟糕的设计和实践的征兆,描述了坏的解决方案以重现设计问题。他们通常会导致软件很难维护和演化,并且由于坏的设计决策,紧缩计划和时间压力,可能会在初始设计或者软件开发过程中引入难以预料的情况。

最近关于反模式的不同类型研究在于提升他们的探测和建议提升的路径。常见的Web服务反模式包括:

上帝对象Web服务(GOWS):将与不同商业和技术抽象有关的多个方法写在了同一个服务中。这将会导致Web服务很难被复用,因为这些方法的低内聚,并且很难被终端用户使用因为它常常会出现过载的情况。

细粒度Web服务(FGWS):一种开销超过其功用的太细粒度的服务。这种反模式涉及到一种小的只有少数操作并且只实现了一部分抽象的服务。它通常需要耦合的Web服务来完成一个抽象,这导致了过高的开发复杂度和减少了可用性。

健谈”Web服务(CWS):代表一种反模式,需要大量的操作来完成一个抽象。这种反模式可能有许多的细粒度的操作,这将会降低整体性能和增加响应时间。

数据Web服务(DWS):包含典型的数据访问操作,例如,getters()setters()操作。在一个分布式的环境下,一些Web服务可能仅仅执行一些简单的信息检索和数据访问操作。一个数据Web服务通常处理原始类型的很小的信息或者具有很高的数据耦合的信息。

模糊Web服务(AWS):它是一种反模式。开发者模糊或者没有意义的名字来描述接口的主要元素,如端口类型,操作,消息。模糊的名字在语义和句法都不明确,这影响了服务的可发现性和可重用性。

冗余的接口类型(RPT):多个接口类型拥有一系列相似的操作。一般来讲,这样的接口类型处理相同的信息。冗余接口反模式可能会消极的影响服务的评分。

CRUD 接口:它是一种反模式,设计的时候通过声明了创建,读取,更新等操作引入了一些像RPC的行为。像这种方式设计的可能会是健谈的,因为实现一个目标的时候需要调用多个操作。一般来讲,CRUD操作不应该通过接口来暴露。

也许不是RPC(MNR):它是这样的一种反模式,Web服务为重要的商业流程主要提供CRUD类型的操作。这些操作可能需要指定一些重要的参数或者这些参数比较复杂。因为客户端经常等待同步响应,所以这种反模式会引起系统性能下降。

在这篇文章中,我们主要关注在基于搜索的软件系统里经常出现的8种反模式。

2.2示例说明

 1 说明了上帝对象服务反模式的主要方面。判断一个上帝对象服务的主要方法是观察其是否通过非内聚的方式实现了多个核心商业技术抽象。这体现在涉及不同实体或者抽象的作为公共方法的服务接口上。在这个案例中,它可以被看做是在不同核心功能上运行的方法。例如:bookFlight()方法被用来预定机票,而reserveHotel()方法试图预定指定的房间。总而言之,这个上帝Web服务支持机票,汽车和酒店预定、支付、发票服务等等。这里的每一个都是一个重要的核心商业抽象,并且显然将会有很多关联方法。因此,这个案例虽然简单并且仅仅是说明性的,实际上,一个典型的上帝对象服务会包含许多和每一个抽象有关的方法,导致一个服务包含过多的方法。

                                              

 1 上帝对象服务示例

在另一个案例中,例如FGWS,我们考虑Apache Geronimo提供的一个真实的计算器服务。一个基本的并不复杂的计算器服务;它支持一些简单的操作,例如加减乘除。图2展示了Apache计算器服务的WSDL文件,它执行两个整数的相加。这是一个细粒度的服务,它仅仅能接收两个数字并且返回两数之和。然而,这样简单的操作却有很多的代码。服务通常是通过网络来调用,他们可能会由于局限性和网络通信引起的费用所束缚(例如,发送消息和接收消息的时间)。在其他复杂的现实生活服务中考虑这种粒度水平时,问题变得更加棘手。

对于非专家客户,GOWS,FGWS和类似尺度的服务之间的界限并不明显。此外,即使对于服务提供者,服务逻辑在设计水平上也许看起来很好,但是当他们实现的时候可以被证明是反模式。让情况更糟糕的是,一个全面的服务契约并不能保证一个服务不是反模式。因此,为服务提供者和服务调用者提供一个高效的探测技术就显得非常重要。

问题描述

在这个部分,我们介绍被本文所提方法处理的特定的Web服务反模式探测问题和挑战。

怎么判断一个候选的反模式是否真的是一个反模式?Web服务反模式探测的一个主要问题是没有一个一致的规则来判断一个特殊的设计违反了质量准则。实际上,探测一个症状和诊断所探测的情形这就是反模式有很大的不同。判断哪些服务是反模式依赖于每一次分析的演绎。在一些上下文中,对设计原则的明显违反可能会勉强被接受正常的实践。例如,一个翻译Web服务的接口可能只有一个操作,负责将文本从一种语言翻译为另一种语言。尽管这种服务可能设计良好,从严格的反模式定义上,它可能会被看做一种细粒度的服务。

怎么找到一个合适的维度来刻画反模式?当探测Web服务反模式的时候,最具挑战性的问题是怎么找到一个合适的维度来刻画这种反模式,并且更重要的是,怎么找到这些维度的最佳组合。实际上,已有的工作仅仅局限于为反模式提供一个定义或者刻画他们共同的特征。最近的工作依赖于申明式的规则指定,这些规则是手动定义来识别Web服务反模式的特征。不幸的是,把这些特征转换为维度非常困难。更糟糕的是,同样的特征可能会关联许多反模式类型,这可能会影响反模式识别的精确性。实际上,将反模式的定义从自然语言转换到维度是一项主观性的工作。

 2 Apache Geronimo提供的一个细粒度Web服务接口的案例

怎么找到合适的维度阈值?另一个内在的问题是当处理量化信息的时候,关系到阈值如何定义。实际上,对于Web服务反模式的表现没有一致性意见。对每一个反模式,依据维度指定的规则,需要大量的校准来找到最佳的阈值。

 3 本文所提的协作并行模型

为了处理和避免以上提到的问题和挑战,我们介绍了一种基于协作的并行式搜索方法来自动探测Web服务反模式和根据优先级排序。

所提方法

在这部分,我们描述所提协作并行进化算法,这种方法克服了前文提到的局限性。然后,我们提出更多用来处理Web服务反模式的P-EA算法的自适应性的细节。

4.1 所提的协作并行模型

展示了所提方法的概览。我们的方法所用的知识来自于Web服务反模式的真实实例。基于Web服务的维度和阈值,这些案例用于生成新的反模式探测规则。作为输出,我们的方法导出一系列探测规则。

案例包含了来自于各个应用领域的不同Web服务反模式,这些可以从不同的服务搜索引擎,例如ServiceXplorerprogrammableWeb.Com等等。基于已有文献的准则,这些反模式被手动审视和验证。

维度。在早期工作中,我们采用了23Web服务接口。在本文中,我们扩展了维度来包含一系列静态和动态的Web服务维度。静态维度旨在从wsdl和代码水平上度量Web服务的结构性属性,而动态属性旨在调用Web服务来度量其动态属性,如响应时间。我们的扩展维度套件是基于这些度量的变化以揭示尽可能多的不同模式的症状。

Web服务接口水平维度(WSDL):表1总结了所采用的维度。前15个维度是在文献[13][27][28]中定义的。我们基于已存在的维度也衍生和定义了8种其它的维度。最后三个维度,AMTO,AMTMAMTP,是基于WordNet来实现的。每一个操作,端口类型和消息id都是用骆驼划分器来划分的。然后我们假设从WordNet抽取的标记越多,就认为这个消息id含义越丰富。对于COH,我们用一个知名的面向服务的聚合维度,叫做服务的总的接口聚合度,它聚合了服务的四个方面。对于COUP,我们使用文献[28]定义的标准的耦合度。

所用的Web服务接口维度列表

Web服务代码水平维度。除了WSDL维度,我们的方法运用了代码水平的维度。虽然Web服务技术建议通过WSDL来访问,我们使用java API来生成Web服务的代码。然后我我们的方法使用长期以来一直使用的面向对象的维度来评估设计的质量。广泛采用的维度是由ChidamberKemerer在文献[30]中定义的。表2描述了这些属性。包括内在树的深度,每个类的加权方法和对象之间的耦合度。我们的方法基于ckjm工具。对于所有代码水平维度,我们计算实现这个Web服务的所有类的平均值。

Web服务动态属性。由于Web服务自然具备的动态属性,我们扩展了我们的维度来包含更多的新的动态属性,代表性的如响应时间。为了度量服务的响应时间,我们使用了SAAJ实现标准和SOAPUI工具。为了减少服务的网络延迟和地理位置的影响,对于每一个Web服务,我们随机的调用5个操作,度量响应时间并且计算平均值。

可能会出现多个维度的组合,因此探测规则的生成过程也是一个组合优化问题。在维度的数量和可能的阈值增长的时候,候选的解决方案的数量也会急剧增长。一个确定性的搜索不再适用,而启发式搜索成为更好的选择。解空间的维度由属性,阈值以及维度之间的逻辑关系来设定。一个解由分配给每一个属性的阈值来决定。

我们的建议是基于搜索算法之间没有相互影响的并行化。实际上,在每一代,最佳解的适应度值基于交互部分的评分来更新。,这部分将在4.2节详细描述。

 

 2 所用的Web服务代码维度列表

4.2并行进化算法的自适应性

这个部分主要展示怎么用P-EA来实现反模式探测。为了让这个计算易于理解,我们首先用伪代码描述了适应性,解编码方式,目标函数优化和采用的影响操作。

算法12描述了P-EA里用到的算法。第一个描述了基于遗传编程的进化算法来生成反模式探测规则。第二个被并行化的执行,并且采用了基于遗传算法的进化算法来从设计良好的服务里面生成探测器。这两个方法都是被广泛使用的功能强大的启发式搜索算法,在解决此类问题时,展现出了良好的性能。这两个算法的基本思想都是先构造种群,并让种群向最优解的方向进化,以此来搜索最优解。为了评估算法,两个算法的适应度函数都有两个部分。适应度函数的第一部分,GP基于反模式的覆盖度来评估探测规则,而GA从设计良好的Web服务中计算异常行为来评估探测器。然后在每一次迭代中,两个算法求出的最优解被选择出来。算法之间通过适应度函数的第二个部分来交互,这个部分叫做intersection_function。因此,一些没有获得一致性的解可能会被惩罚,而另外一些会被支持。

算法1和算法2在更高水平上描述了我们P-EA方法所用到的算法。在这一节的余下部分,我们描述这两种算法。在P-EA算法的初始化时,我们的案例被拆分成10个子集,每一个代表不同的应用类别。例如,金融,旅游等。一个子集作为测试数据集,其他的作为训练集。这样,P-EA在所选的子集上探测反模式,它当然不是训练集的一部分。

5-6行和4-6行分别构造了GPGA的初始种群,它是一个代表了可能的解空间的个体集合。9-207-17行分别编码了GPGA的主要循环部分,它主要用来搜索解空间和通过组合新的维度构造新的个体为GP生成新的规则,生成新的元素来为GA生成探测器。就像之前描述的那样,由评估解的好坏的适应度函数来驱动流程。在计算出两个算法的交互部分以后,基于算法的精英解的适应度值来更新算法1的最佳解的适应度。然后,每个算法的最优解被保存并且通过从种群POP选择父代个体,通过遗传操作来生成一个新的种群个体。在新的种群中包括了父代和子代的变异。然后对变异算子对父代和子代进行变异操作来扩大种群多样性,这样产生下一代。当应用影响算子,在并行的GA/GP中没有个体交换。当算法达到最大迭代次数时,算法终止并输出已经发现的一系列规则。开发者可以在任何新的反模式上使用这些最佳规则和探测器来探测潜在的反模式。探测工具基于下一节要讨论的交互评分来排序探测的反模式。

 4 GP解决方案的案例

 

在接下来的部分,我们描述所采用的GAGA算法的主要的3个步骤。

1)解的表示

该问题的候选解是反模式的探测规则。一个解决方案可以表示为一系列的IF-THEN规则,每一个都具有如下结构:

如果组合的维度超过了他们的阈值” 那么 “这就是一个反模式类型

IF声明的前件运用逻辑操作(AND,OR)组合了一些维度和他们的阈值。如果一个Web服务满足这些条件,那么就可以判断它是THEN语句中的反模式类型。图4提供了一个示例。每一个候选解S都是一个探测规则的序列,每一个规则用一个二叉树来表示。

1)        每个叶子节点L表示一个维度,和它对应的阈值,这个阈值是随机生成的。

2)        每一个内部节点N表示一个逻辑操作,是AND或者OR

我们会有和反模式类型一样多的规则需要探测。在这篇文章中,我们重点关注在2.1节定义的8种常见的反模式类型。

对于GA来说,探测器表示的是人工生成的Web服务。因此,探测器表示成一个向量,向量中的每一个元素是生成的Web服务的一个键值对(维度,阈值)。具体参照图5的示例。

2)评估函数

GP的适应度函数。对于GP来说,和期望相比较,我们的适应度函数旨在最大化所探测到的反模式的数量,用准确率和召回率来评估。

 5 GA算法的表示案例


这里t代表案例集中反模式的数量,p表示探测到的反模式的数量,如果第i个被探测的服务存在于案例集中,那么ai值为1,否则就为0

GA的适应度函数。对于GA来说,我们寻求最优化以下的两个对象:1)通过减小良好的设计模式的相似性来最大化探测器的通用性,2)最小化探测器之间的相似度。这两个目标定义了探测器的适应度函数,用来评估探测器的质量。一个解D的适应度用其包含的探测器的平均值来评估。我们提取探测器di的适应度值,作为异常和相似性权重的平均,用公式表示如下:

Dev用一个异常行为值来度量,这个值在探测器di的维度值和案例集所有的Web服务的值之间。直观的说,在我们维度套件里考虑的每一个维度,维度值在极端值之外,表示我们的案例很可能不标准,因此,可能存在风险,因为他们背离了共同的设计实践。如果用M’={m1,m2,..,mn}M={m1’,m2’,…,mn’}分别表示探测器di的维度值和B的平均维度值。相似性Oi由探测器di和解决方案D中所有探测器d的平均维度值的不同来度量。所有的维度都被规范化到[0,1]之间。

交互评分。在每次迭代中,从两种算法里选择一系列最优解,然后在新的一系列Web服务上评估。构造矩阵M,行由GP的最优解{SCPi}组成,列由GA的最优解{SGAj}组成,并且每一个案例(SGPi, SGAj)用准确率Pint和召回率Rint来定义。

这里detect(A,D)利用算法A从数据集D中返回探测的反模式。

然后,每一个解决方案的评分用fintersection(SGPi)=Min(Mintersection(SGPi,SGAj))finsection(SGAi)=Min(Mintersection(SGPi,SGAj))。因此,对于GPGA,解Si的适应度可分别表示如下:

对于GA,最好的探测器被用来探测反模式。待评估的服务和获得的探测器比较。Web服务ws被判断为反模式的风险由服务WS和数据集D中所有的探测器di差异值定义。

这里,dev(ws,di)返回wsD中探测器的差异值。反模式就可以按照风险值排序。在我们的方法里,只有当风险值大于0.75,才会被看作是反模式。

3)遗传算子

变异。对于GP来说,变异算子可以被应用在函数节点或者内部节点。它开始的时候,从树中随机选择一个节点。如果被选的节点是叶子节点,它将会被另一个代替;如果它是函数节点,它会被一个新的函数代替;并且树变异将会被执行,节点和子树被一个新的随机生成的子树替代。对于GA,这个变异算子包含了很多的改变或者在它的向量中有更多的维度。

交叉。我们使用标准随机单点交叉法。对于GP,两个父代解被选中,并且每个里选择一个子树。然后,交叉算子交换节点和子树。对于GA,交叉通过替换从开始部分到交叉点的维度结合了两个方案。

实验评估

这节描述研究的设计,并展示实验结果。

5.1 研究问题

我们设计我们的实验来回答以下研究问题:

RQ1.GP,GA和随机搜索相比,我们的P-EA算法性能如何?

RQ2.本文所提算法在何种程度上能够有效探测反模式?

RQ3.它能够有效探测什么类型的反模式?

RQ4.和已存在的反模式探测方法相比,P-EA算法性能如何?

5.2 实验设计

为了评估我们的方法,我们利用不同的搜索引擎收集了一系列的Web服务。表3总结了收集到的Web服务。为了使我们的实验公正,我们收集了不同领域的Web服务,如金融,科学,旅游,天气,多媒体,教育,消息和位置等类型服务。依据文献[4],[22]的方法,所有服务都是手动检测和检测是否是反模式。而且,我们的数据集公开到了网上,以鼓励未来关于Web服务反模式的研究。

我们考虑了8种常见的反模式类型,分别是上帝对象服务,细粒度服务,健谈Web服务,数据Web服务,模棱两可的Web服务,冗余接口类型,CRUD接口和未断定RPC。在我们的研究中,我们采用了一种十折交叉验证。我们将数据拆分成训练集和测试集。对每一份,用剩下的9个分类来评估一个分类。例如,用旅游,购物,搜索,科学,金融,多媒体,教育,消息和位置服务的反模式来分析天气服务。我们使用准确率和召回率来评估方法的正确性。准确率表示的是探测到的真正的反模式的占比,召回率预示已存在的全部反模式的探测到的真正的反模式的占比。

总的来说,当执行P-EA方法以后,最好的探测器和探测规则将会用来在新的服务中寻找新的反模式。这些反模式用严重性程度来排序:

这里,Risk(wsi)由公式8来定义,如果服务wsi被一系列规则检测出来,那么RuleDetect(wsi)值为1,否则为0。我们设置风险值为0.75为可接受的值,来识别一个服务是否为反模式。在方法执行30次以后,我们使用一个试错策略来寻找合适的阈值。然而,这个阈值需要用户调整。

为了回答RQ1,我们调查和报告了P-EA的效率,由于我们的方法的一个创新之处是采用了协作的P-EA方法。两种独立的研究方法GAGP以及P-EA最后都被实现了。对于GPGA,所有的研究过程都是独立的,并且最终收集最优结果。在P-EA中,我们希望通过交换信息,搜索的EA算法的全局搜索效率能得到有效提高。而且,我们实现了和P-EA算法有相同适应度函数的随机搜索算法。实际上,将我们的算法和随机搜索进行比较是非常重要的,如果一个智能搜索算法的性能比随机搜索还要差,那么所提的计算方法是不能采用的。

为了回答问题2,我们用准确率和召回率来评估所提方法在识别反模式上的有效性。

为了回答问题3,我们探究了探测的反模式的类型来找出是否对特定反模式类型存在偏置。

为了回答问题4,我们将本文方法和文献[13]所提的SOAD-W方法以及我们之前的方法做了对比。SODA-W方法基于Web服务设计的观点手动地将反模式特征转换为探测规则和算法。在我们早期的工作中,我们扩展了前期工作的方法。在前期工作中,仅仅基于Web服务接口维度,我们使用了标准的遗传编程算法来生成Web服务反模式规则。这三个方法都在表3所述的测试集上进行了测试。

5.3 参数调整和设置

当同时使用多个进化算法解决这个问题时,降低了所选参数的敏感性。但是仍然是启发式搜索的重要方面,选择和调整参数来实现公平比较和潜在的反馈。对于GAGP,初始种群随机生成。种群数量设置为100,代数设置为3500.对于GA算法,树的最大深度设置为10。对于P-EA和随机搜索,种群大小为100,代数为1750。在这种设定下,所有的算法执行35万次适应度函数评估,因此可以得到一个公平的比较。交叉率设置为0.9,变异率设置为0.4。我们使用了一个较高的变异率来确保种群的多样性和阻止早熟现象的发生。实际上,在仿真运行多次以后,这些参数值将会固定不变。没有通用的规则来决定这些参数的取值,因此我们用被SBSE委员会广泛使用的试错法设置参数值的组合。

 6 准确率和召回率的实验结果

5.4推断统计检验

我们以成对的方式用Wilcoxon秩和检验来比较不同算法的性能差异。我们设置置信度a0.05。在这个设置下,每个实验重复31次,对每个算法和分类。对每个算法的结果进行统计分析来比较P-EA算法、GPGARS算法的性能。实验结果取31次实验的平均值。为了掌握有效尺寸,我们使用科恩d统计方法。我们将有效尺寸设置为:(1)小,如果0.2≤d<0.5(2)中,如果0.5≤d<0.8,(3)高,d≥0.8

5.5 实验结果

问题1的结果。问题1的目的是评估协作的P-EA的性能和单独的EA的性能相比如何。表4和图6报告了对比结果。在31次运行之后,随机搜索的准确率和召回率只有36%41%,和P-EA相比,表现不佳。这主要是因为需要探索维度组合的可能大的搜索空间。对于不同的分类,统计分析表明,我们的P-EA算法比GAGP要好。

 4各个算法的p值和有效尺寸的比较

更重要的是,我们观察到P-EA可以在不同分类中探测到反模式,并且准备率和召回率分别为89%93%Wilcoxon测试结果表明,在20组实验中,P-EA算法比GA表现更好,在20个案例中,有18个的有效尺寸为。相似的是,P-EAGA更好,在20个案例中有14个有效尺寸是,值为的有4个。在其他案例中,有效尺寸为额只有一个案例。另一方面,总的来看,GP在大多数案例中比GA取得了更好的结果。这表明从反模式中学习比从共同实践中可以取得更好的效果。因此,我们可以得到结论,P-E算法的适应性和有效性比GAGPRS要好。

如此,协作并行搜索算法应对不确定性决策问题的有效性证明了软件工程结论性消息:如果你的决策问题不确定,考虑使用并行协作算法来获得好的结果

问题2的结果。表展示了问题2的实验结果。从表中可知,我们可以从不同的分类中探测到反模式,平均准确率高出了87%。旅游和金融的平均准确率更高,因为这些服务的大量的操作和复杂的类型,匹配了GOWS反模式。对于航运服务,准确率更低,只有82%,但仍然是一个可以接受的分数。这是由于反模式的特性涉及到什么是典型的数据和健谈Web服务。实际上,对于DWSCWS的反模式,一些假阳性会被记录。使用单独的维度,这些反模式很难被探测,但是如果我们使用的严重程度低于75%,从常见的做法可以被检测到这样的反模式。类似的解释可作召回率。所得结果表明,我们的方法能够实现92%的召回率。旅行服务的最高纪录为96%,所检测服务反模式大部分是GOWSAWS。记录的最低召回分数为气象服务(87%),主要归因于对FGWS。事实上,天气Web服务通常提供一个或两个接口,返回温度或特定的城市,这不符合FGWS特征。

问题RQ3的结果。基于图7的结果,我们观察到P-EA针对任何特定的反模式类型,没有任何偏差。如图所示,每个反模式的类型分布几乎相等。在某些Web服务(如天气)中,分布并不均衡。这主要是由于检测到的实际反模式的数量类型。总的来说,所有的8种反模式类型的检测具有良好的精确度和召回率(超过85%)。大多数现有准则/定义在很大程度上依赖于尺寸检测反模式的概念。这是合理的,如对反模式GOWSFGW,它们是一个概念的大小有关,然而,像反模式AWS,尺寸的概念并不那么重要。这使得这种类型的异常难以用结构信息来检测。这个困难限制了GPGA单独检测这种类型的反模式。因此,我们可以得出这样的结论:我们的P-EA方法可以检测所考虑的所有类型的反模式(RQ3)。

 7 每一种类型的探测结果

此外,我们在表6报告了一个由P-EA探测到的Web服务反模式的一个随机案例。例如,XigniteRegistration这个Web服务被探测到是一个上帝对象Web服务,因为它有3个接口,107个操作,这使得Web服务非常庞大。这个服务的响应时间也非常高,达到了4.28秒。此外,在它的实例中,定义了251种复杂类型,这导致了它也被识别为数据服务反模式。相似的是,XigniteQuotes也被探测为既是GOWS也是DWS反模式,因为它有3个接口类型,大量声明的操作(98),其中有95个是可以访问的操作,有大量的消息,相对应的的低内聚,也有大量的复杂类型。此外,XigniteQuotes的代码也出现了高耦合,很高的RFC值,和很低的功能抽象度量。客户端使用这种相互独立的精密耦合的Web服务,将会暴露这些依赖,然而这些可能仅仅希望只使用一种操作。成功的服务重用可能希望是设计良好和定义良好的组件。一个模糊的Web服务会混淆,出现不可信和可靠,大多数开发商会选择别处或去实现它。

P-EA探测到的反模式实例

XigniteOutlook也被看做是一个模糊服务,提供了多个操作,消息和有很长签名的类型。例如,接口元素签名包括一些包洛克风格的名字,如MarketReflectionsAndWhosSpeakingAndFYIAlertsGetOutlookForRangeLengthBackwardResultGetOutlookForRangeLengthBackwardHttpPostOut.如此,这个服务的开发者忽略了服务接口的命名规则和在编纂软件API的正确方法。建议开发者按照共同的名字写名字,用于促进Web服务重用的实践,自动化分析和解释。

问题RQ4的结果。图8报告了和P-EA和欧尼[ 14 ]的方法以及SODA-W的比较结果。而SODA-W显示了良好的结果,平均精度为71%83%的召回率,它仍然是低于P-EA的结果,在所有的八个被认为是反模式的类型。我们猜想与SODA-W的一个关键问题是,它简化了对某些反模式检测有用的不同的概念/症状。事实上,SODA-W对一组WSDL接口度量是有限的,但忽略Web服务构件的源代码。事实上,服务设计在界面层也许看起来很有前途,如果源代码设计不好,也可以被证明是一个反模式。相比之下,我们的方法是基于接口和代码度量。另一个限制SODA-W的是,在一个详尽的场景中,可以用手动规则度量的反模式数量非常大,由维度组合构成的规则需要大量的努力,来为每个度量找到合适的阈值。通过对比,我们的方法只需要生成一些反模式检测规则。图8还展示出我们早期的工作[ 14 ]提供了较低的检测结果,8种反模式的平均精确度和召回率只有72%。因为我们以前的工作仅基于接口度量,因此捕捉不到所有可能的反模式的症状。

一个重要的考虑因素是案例大小对检测质量的影响。来自与天气相关的Web服务分类,图9的结果表明我们的方法也提出了相当好的效果。只有少数Web服务的反模式的例子是可用的(这个案例中只有94个实例可用)。精确度和召回率似乎稳步增长,并与实例的数目成线性关系,并迅速增长到可接受的值(87%)。因此,我们的方法不需要大量的例子来获得好的检测结果。

 8 P-EAOuni 所提方法和SODA-W的比较结果

 9 案例大小对实验结果的影响

有效性分析

这部分描述验证我们工作的风险。

外部威胁的有效性可能会出现,因为我们没有评估所有类型的检测。然而,这八种类型的Web服务,我们使用的8种反模式具有广泛代表性。此外,我们仅在SOAP Web上验证了我们的方法。因此不能将我们的结果推广到其他诸如REST Web服务等技术。然而,大量的Web服务使用SOAP,因此对这种体系结构的反模式探测就非常重要。

对有效性的威胁涉及到理论与观察之间的关系。大多数我们在实验中测量的是标准度量,如被广泛接受的准确度和召回率等,作为反模式和代码的气味质量指标检测解决方案[ 12 ][ 13 ][ 14 ]。另一个威胁是相关的反模式案例的代码库,对反模式实例的代码,开发者可能不是所有人都同意这个候选Web服务是否是一种反模式。因为这是第一次尝试自动探测方法解决Web服务反模式这个问题,目前还没有确定的最先进的技术。事实上,我们发现只有很少的文献指导我们应该考虑什么构成了Web服务反模式[ 13 ][ 22 ][ 23 ]。此外,在实验中,基于试错法来设置各种阈值的值,但是,这些值可以配置一次,独立于Web服务用于评估。另一个威胁与用JAX-WS自动生成代码有关。在使用其他工具时(例如WSDL2Java)可能会产生不同的代码,这不影响我们的结果,我们使用相同的工具进行所有的实验。

相关工作

SOA框架和Web服务中识别指定的反模式是一个比较新的领域。只有少数工作解决SOA反模式的问题。第一本书是由Dudney在文献 [ 22 ]所写,提供一套Web服务的反模式的非正式定义。最近,Rotem Gal Oz描述一系列的SOA反模式的症状[ 4 ]。此外,Kralzemlicka [ 7 ]列举了七种流行的违反了公认的SOA原则的反模式这。此外,大量的研究工作已经解决了此类反模式的检测。最近,Moha等人在[ 41 ]提出了一种基于规则SCA系统称为SODA-W(服务组件体系结构)。后来,Palma等人在[ 13 ]中扩展这项工作为Web服务反模式探测.所提方法依赖声明性规则规范,使用特定于领域的语言(DSL)来指定/标识反模式的主要症状,使用WSDL度量集合。在另一项研究中,Rodriguez等人[ 24 ][ 42 ]Mateos等人[ 23 ]为服务提供者提供了一套指导方针,在写作WSDLs时避免坏习惯。基于一些启发式方法,作者检测编写WSDL的八个坏习惯。在其他工作[ 43 ]中,作者提出了45SOA的一般反模式。这项工作的目的是全面的审视这些反模式,将帮助开发者对软件开发阶段的模式有清晰的理解,避免许多潜在的问题。马特奥斯等人在[ 44 ]提出了一个有趣的建议用文本挖掘技术生成WSDL文档,避免较少的反模式。最近,Ouni等人在[ 14 ]提出了一种基于搜索的方法从Web服务反模式的例子中找到规律性的标准反模式,将其转化为检测规则。然而,所提出的方法只处理Web服务接口维度和不能考虑Web服务反模式的所有症状。类似于[ 13 ],后者既不考虑偏离一般设计实践也不考虑代码维度,这导致了一些误报。

与面向服务的计算不同,有广泛的研究,试图发现面向对象的反模式和代码的气味[ 9 ][ 10 ][ 11 ][ 12 ][ 45 ]。第一个尝试自动为java程序代码气味检测是由van EmdenMoonen [ 46 ]提出的。作者检查了一系列代码气味,发现它们中每个的特点是有许多嗅觉方面,在源代码实体(如包、类、方法)中可见,当在代码中找到了所有方面的时候,代码味道可以探测出来。识别方面主要与不符合编码标准有关。后来,Marinescu el al[ 9 ]提出了一种机制被称为检测策略来检测面向对象的代码,这种机制基于度量的规则是从设计原理和启发式来捕捉偏差的气味。和文献[13]中的SODA-W相同,Moha等人在文献[ 10 ]提出了一个描述反模式的症状,使用了特定于域的语言,他们的反模式的检测方法称为DECOR。基于在文献中发现的关于代码气味的工作的审视,他们提出了一个一致的词汇和DSL指定反模式。反模式描述症状涉及到不同的概念,如类角色和结构。症状描述稍后映射到检测算法。最近,欧尼等人在[ 11 ]提出基于搜索的面向对象的代码气味检测方法软件系统,这是第一种方法从实例推断的检测规则。kessentini等人在[ 12 ]提出了一种使用协作并行的扩展的搜索技术检测java系统的代码味道。

     然而,代码嗅觉检测技术是不适用于在Web服务的上下文中,我们处理不同的粒度级别(服务与类级别),以及不同的技术和度量。此外,不像面向对象软件系统,Web服务源代码不是开源的,也就是说,只有Web服务接口是公开的。可供客户使用,其中只有骨架的代码可以自动生成。这使得检测这种反模式更具挑战性。

结论和未来工作

在本文中,我们介绍了一种新的SBSE的方法来实现Web服务反模式的检测。在我们合作的并行元启发式算法的适应性,两种群同时进化以达成共识为识别目标Web服务的反模式。建议方法在415Web服务和八常见的Web服务反模式的类型进行评估。对所得结果的统计分析提供了令人信服的证据,协作P-E比个体种群、随机搜索和最新方法的准确度超过89%,平均召回率超过93%

作为未来的工作,我们计划在个人服务和商业服务的额外的反模式类型中全面验证我们的方法,以使其具有普遍适用性。此外,我们计划包括其他SOAP静态和动态维度和实证研究它们对Web服务质量的影响。除了个体Web服务反模式,我们还计划将这种方法推广到检测商业流程反模式。最后,另一个期望的研究方向是通过重构,对检测到的反模式自动校正。



关键字:   软件工程     web服务     反模式  
声明:本站部分资源来源于互联网,如果侵犯了您的权利,请来信告知,我们将在24小时以内删除. 联系邮箱:zhengli_liu@126.com
Powered by liuzhengli.com 豫ICP备18011046号
Copyright © 2018 liuzhengli.com All rights reserved.