大家好，我是讯享网，很高兴认识大家。

A Failure-Aware Model for Estimating and Analyzing the Efficiency of Web Services Compositions

  

 

§1 介绍

介绍了近两年来，WS体系结构的快速发展充实了互操作这一概念。关键使能技术已经出现了一系列开发友好的标准（SOAP， UDDI， WSDL）。

S：State

SRC：State Reliability Contribution

TSS: Terminal State Set

STS: State Tendency Set

 

§2 WS组合（WSC）的Qos建模和分析

2.1 组合规范模型

我们描述了一个n个组件的WSC方法。三种基本的聚合模式：顺序，并行、互斥。

 

 

2.2 组合执行模型

WSCs的动态执行模型：每个组件C_i可以被Runtime映射到任一个可用的WS_ip （WS_ip∈S(C_i)，并且p∈(1, |S(C_i)|)。

没有涉及具体如何执行，有很多方法可以用来提高执行的可靠性，但是这里没有具体叙述。

可靠性如何提高也是可以研究的嘛 

 

 

2.3 WS发现和选择模型

动态执行的WSCs：映射WSs至选择的组件是运行时的。文献已经提出过很多动态WSCs方法。

我们呢，假设采用一个方法来发现WSs不存在任何问题。对于每个组件C_i，可以被发现的WS_i都在S_i中被排序了，发现就是按照这个顺序。什么样的顺序是不是可以有点新想法呐？ 

 

 

2.4 组合失败模型

容错是系统的一种能力，当错误发生时的能以良好定义的方法来处理。当考虑一个容错系统是，一些首先的先决条件指定哪些错误类型需要被容错。

l         fail-stop: 一旦fail系统就stop，不output任何data

l         Byzantine: 一旦fail不stop，转而return错误信息

l         fail-fast: fail不马上stop，在短时间内return错误信息，然后再stop

environment-dependent failures: 冲突、超时

application-specific failures: 错误的输入、异常

 

 

transient failures  

forward recovery  

backward recovery

2.5 执行时间属性描述

通过估计单个组件的执行时间来衍生出整个组合的等价估计

2.5.1 单个组件的执行时间

文献[2][5]定义了三个要素：执行WS任务所需的服务时间S；SOAP消息发送接受的消息延迟时间M；WS调用?启用时间W。

仅consider这些要素还是不够的，因为这个定义仅考虑了ont-to-one的WS组件映射，没有考虑计算的eventual failures。

定义1：最优执行时 Optimistic Execution Time

一个WSC组合c中的一个组件C_i的最优执行时间T(C_i)_opt，是运行时dynamically-map到C_i的上的WS的执行时间。

是不是应该这样：？ 

 

 

定义2：可能执行时间 Probable Execution Time

 

T(C_i)_prob是C_i的执行时间的估计。

定义3：失败信息时间 Failure Information Time

I(C_i) 作为一个特定失败通知的不同的SOAP消息发送/接受的时间。

 

定义4：失败恢复时间 Failure Recovery Time

R(C_i)是从一个特定的组件C_i错误中恢复需要的时间

with：

   重试C_i的其他WS所花的总时间，即：Ci在第q次执行时调用成功，这时分配给了ws_iq。因此前q-1次分配失败，这些所有的相关执行时间就是C_i前向恢复时间For(C_i))。

   在后向恢复中，依赖于采用的组合规范模型，rolling-back, aborting, compensation。这里的Back(C_i))是这三种模型的时间之一。

讯享网

 

2.5.2 组件初始执行时间估计

第一次根据组件advertise的时间来估计，以后就可以根据先前每次的执行时间来估计。

   

2.5.3 组合的执行时间尺度

估计具体的WSC的执行时间，需要遍历所有的组件，而WSC的组件结构又存在好多种组合方式。我们提出使用[13]中的工作流模式来解决。这些模式capture工作流建模中遇到的典型的控制流程的相关性，因为他们capture的情况和本领域很相关，因此arguably apply的用于WSCs。

Pattern1 顺序 Sequence  

 

Pattern2 并行  Parallel Split 

 

单独执行而后同步合并

Pattern3 互斥选择 Exclusive Choice

 

  2.6 可靠性特性描述

可靠性趋势Reliability Tendency

RT build on：

State

Terminal State Set, TSS

State Tendency Set, STS

State Reliability Contribution, SRC

定义5：每个C_i在被调用执行后，都有一个TS表明调用结束。经过m次调用，对于每个组件，TSS就形成了，记为TSS(C_i)。

定义6：m次调用C_i后，至少有一个TS是所有TSs中拥有最大发生概率的。即STS(C_i)是一个状态set，包含于TSS(C_i)中，并且拥有最大的发生概率。

定义7：从一个TS转换到另一个，对于reliability的共享不一致。结束一个处于Failed状态的C_i将对reliability产生negatively的影响，相反的，Committed状态将会对于增加reliability有positively的贡献。定义这为某个TS的状态可靠性贡献（SRC， State Reliability Contribution）。SRC取决于每个状态依靠的环境特性，比如TS的数目、可能的状态、状态转移等。这也将在以后的工作中进行。

 

定义8：组件C_i可靠性趋势 Reliability Tendency，RT

Ci的RT由下面的共识定义，定义了m次调用后各个组件的可靠性rate（reliability rate）。

定义9：WSC的RT

   

§3 验证

使用JOpera，执行一个currency for a user-provided stock symbol例子，JOpera：一个快速的组合工具，为利用reusable的服务建立分布式应用提供了可视化的语言和可执行的平台，具有很强的practicability。

11次执行图1的流程：组件和WSC的结果如图2和图3示。

Failures的原因：

  SOAP消息传输途中的Internet连接fail

  WS超时，因为netwrok连接failure

  WS返回failure消息，因为数据的不一致性

   

§4 相关工作

4.1 传统组合系统Context

传统组合系统的QoS，许多技术proposed，这些技术被underlying modeling formalisms支持，比如block diagrams, Markov Chains, Petri网, logics等等。

同样的，在软件工程context中，很多数学化的技术被开发。和本文最相关的模型是reliability的结构化模型和Markov reward模型。以前，状态图描述系统比较常见。基于Markov链属性，状态之间的转移被看做是一个Markov Process。以后，系统被建模程一个Markov process with 有限状态空间，并且每个状态有个reward rate与之相关。

  

4.2 WS Context

现有文献中对于WSCs的QoS的估计和分析的工作还很少。有一种是由WS用户来进行的QoS rating。文献20中提出的根据使用者/提供者给出的QoS估计来选择服务可能会因为用户的公证性原因导致不正确或者偏差。在我们的工作中，我们不依赖于使用者/提供者的QoS Rating，相反，设计者观察WSCs的执行情况并collect历史执行结果作为以后估计QoS属性的基础。

文献21中，作者讨论了一个SLA模型（Service Level Agreement，服务层一致？）作为提供者和消费者之间的桥梁。但是对于WSCs，使用SLA将变得很复杂。

HQML（Hierarchical QoS Markup Language），Web Ontology Language（OWL-S），WSLA都是定位一个QoS模型需求的规范的例子。这些规范之间的共同点在于它们描述了WSs的QoS。例如，DAML-S构建了几个详细的QoS参数，quality rating和the degree of quality。但是，这些规范都没有为不同参数提供精确的描述，并且这些only for WSs。

文献6中提出了一个 基本 和 组合服务 的QoS评估模型。但文6中全局调用的相互作用导致的潜在的failure没有被考虑。Reliability被直接map到每个WS各自的Reliability。这定义为访问一个WS的请求在最大期望时间内得到正确响应的概率。

这种方法来表征reliability，缺乏对于动态组装的WSCs的扩展性。

 

4.3 工作流管理系统（WFMS）Context

Crossflow项目[22][23]，METEOR项目[5] [2] [24] [25] [26]在QoS方面做了主要贡献。METEOR项目从QoS的4个方面做了研究：time, cost, reliability和fidelity。但是它没有从任何方面考虑动态的WSCs。它focus on 分析、预测和监控工作流的QoS。事实上它是derive from一个更加通用的工作[7]，这个工作描述了工作流context下任务的reliability，文[27]中提出的离散时间稳态可靠性模型。在这个WFMS中，任务结构[28]有一个数字做前缀的状态，并且所有的状态对于reliability的贡献相等。这种任务建模具有局限性。当模型很容易和其他状态扩展时才有效。

以上所有的模型都是对静态的WSCs有效的。

 

§5 Conclusions and future directions

提出了一个表征、估计和分析动态执行的fault-tolerant WSCs的新模型。

1 提出了在WSCs context下，用术语执行时间和reliability来估计QoS的创新方法

2 在WSCs效率方面failure repercussion具有十分的重要性

3 由于WS的Stateless，追踪failures决定错误地点非常困难，因此我们对每个组件attach了一个state ongoing work主要集中在用在以前工作得到的WS-SAGAS已完成的仿真系统来进行实验。我们将介绍一个新的模块来从历史执行中收集。最后我们将使用其他的efficiency评价元来enrich我们的模型。