Zeng Liangzhao本科在国内的中山大学, 硕士和博士都在澳大利亚的新南威尔士大学(UNSW), 之后在IBM Watson研究中心工作. 他在03, 04写的3篇论文是基于QoS的Web服务组合方面的经典, 写这方面的论文几乎是必引的(按照发表先后顺序排列):
    Liangzhao Zeng, Boualem Benatallah, et.al: Quality driven web services composition (gs: 359). WWW 2003 (gs表示Google Scholar, 之后的数字是Google Scholar上显示的该文被引用数)
    Liangzhao Zeng, Boualem Benatallah, Anne H. H. Ngu et.al: QoS-Aware Middleware for Web Services Composition.(gs: 496) IEEE Trans. Software Eng. 30(5): 311-327 (2004)
    Yutu Liu, Anne H. H. Ngu, Liangzhao Zeng: QoS computation and policing in dynamic web service selection. (gs: 224) WWW  2004

以下是DBLP上查到的Zeng LZ做为第一作者发表的部分论文
Event-Driven Quality of Service Prediction. ICSOC 2008
Dynamic composition and optimization of Web services. Distributed and Parallel Databases 24(1-3)(2008)
Monitoring the QoS for Web Services. ICSOC 2007
Semantic Service Mediation. ICSOC 2006
Policy-Driven Exception-Management for Composite Web Services. CEC 2005
AgFlow: Agent-based Cross Enterprise Workflow Management System. VLDB 2001

Quality driven web services composition笔记
1. 建模
本文使用statechart和DAG进行建模
考虑的服务组合结构有sequence, concurrent, condition;对于loop, 根据历史数据, 得到该循环的平均执行次数, 由此将循环"unfolding"以消除loop.
没有提及更加复杂的结构, 比如1-out-of-N(这个应该也可以属于AND STATE, 不过在计算部分QoS时跟同步情况是不一样的), WS间有communication等.

statechart用来对Web服务组合进行建模, 主要用于直观演示.
DAG用来对Execution Path(执行路径)进行建模, 之后的计算和分析都是基于此.

2. 本文涉及的相关概念
Execution Path
服务组合运行一次, 涉及到的task集(按一定顺序排列)(task可以认为是abstract service), 都可以认为是一个Execution Path.
一个WS组合如果没有condition branch, 那么就只有一个Execution Path, 否则就有多个Execution Path.

Execution Plan
Execution Path中的task实例化以后就是Execution Plan了

WS community
一个服务集合, 集合中的服务具有相同的功能, 不同的QoS指标. 在设计阶段, 只对task指定WS community, 在运行时, 才选择具体的服务. 这样就达到了运行时进行服务选择的目的.

Critical Path Algorithm (CPA)
有向图中, 每个节点均有一个权重, 指定起点和重点, CPA可以找出一条路径, 该路径中所有节点的权重和是最大的.
本文中, 涉及到时间的QoS属性(Execution Duration和Reliability, 见S3.1中有关Reliability的定义)需要用到critical path这个概念.

3. 问题: 本文要解决的问题很明白, 基于QoS的Web服务选择(在Web服务组合的场景中), 这是Web服务组合领域内的一个基本问题.
如果只考虑Web服务的一个属性, 显然组合中每个task只要选择最优的WS, 组合起来也肯定是最优的; 但是在WS具有多属性(price, duration, reliability等)的情况下, 不同的QoS属性在组合结构(比如同步等)中具有不同的计算方法, 无法通过局部最优解来获得全局最优解.

4. (S4) 是本文重点, 讨论了几种全局服务选择方法
(S4.1) 只讨论statechart中不包含conditional branching, 服务组合只有一条execution path的场景.
使用了MADM中的SAW方法: 将QoS属性归一化处理, 并加权相加得到一个分数(每个Execution Plan都有一个分数). (这种评估方法后来被很多其他WS选择论文中借用)
(S4.2) 在S4.1的基础上, 讨论具有多个Execution Path时的情况, 作者没有从理论上说明这个方法可以选出全局最优解.
    1) 对于服务组合的每一条Execution Path, 使用S4.1中的方法计算出最优解
    2) 如果某个task只属于一条Execution Path, 那么这个task就选择这条Execution Path上选中的服务.
    3) 如果某个task属于多条Execution Path, 那么选择被选中的次数最多的WS.
(S4.3) 使用线性规划(LP)方法来求最优解. LP有三个输入: variables, objective function, constraints
对于reliability和availability这些属性, 首先要线性化.
问题: 作者没有明确说明LP方法针对的statechart是否可以有conditional branching, 不过从公式(9)来看, 应该是只针对不具有conditional branching的情况求解. 公式(9)是说, 对于任意一个task, 有且只有一个WS会被选中. 假如存在conditional branching, 那么有些task就不会选中WS. 这个问题需要进一步确认.

5. 实现
以SELF-SERV prototype为平台, 实现了本文讨论的算法.
使用IBM Web Services Toolkit 2.4 (WSTK2.4) 作为Web服务开发的工具

调用IBM's Optimization Solutions and Library (OSL) 来求解LP问题

6. 问题: (S4.3.1)"By introducting a budget constraint the above problem needs to be explicitly solved as an integer programming problem".
为什么在引入budge限制后才必须明确做为IP(Integer Programming)问题? 变量yij取值范围是1, 0(表示选中和不选中), 应该本来就是一个IP问题啊?
这是knapsack问题的一个特例, 因此是NP难的.
[20:18 2009-2-24]

在引入budge先之前, 没有"背包容量"的限制, 因此不是背包问题, 可能不是NP难的.

7. 勘误
(S2.1) "Note that when two transitions stem from the same state (in this case the state t4)"
这句话中的t4应该是t5 (参考QoS-Aware Middleware for Web Services Composition中相关内容便知)

(S5.2实验验证部分)暂时没有细看
  看这种级别的论文很耗脑细胞.