Zeng Liangzhao的經典論文之一 “Quality driven web services composition” (WWW03)

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實驗驗證部分)暫時沒有細看
 
看這種層級的論文很耗腦細胞.