[論文筆記] Gradual Removal of QoS Constraint Violations by Employing Recursive Bargaining Strategy for O

來源:互聯網
上載者:User

Time: 3.7 hours
K. Ren, N. Xiao, J. Song, C. Yang, M. Zhu and J. Chen. Gradual Removal of QoS Constraint Violations by Employing Recursive Bargaining Strategy for Optimizing Service Composition Execution Path. Proceedings of IEEE 7th International Conference on Web Services (ICWS2009) (Research Track 21#Controlled Services Coordination), Los Angeles, CA, USA, July 2009. pp. 485-492

    作者是國防科技大學的任開軍, 網上找了一下, 只有一些零星的個人介紹(1975年生, 博士). 國外研究人員基本上都有個人首頁, 且及時在維護更新, 體現出了開放, 自信的心態, 而出於多種原因(氛圍, 環境, 態度, 成果等), 國內人員在這方面則比較欠缺. 從這一點, 也能體會出一些國內與國外研究狀況的差距. 
DBLP上收錄的作者幾篇論文:
A QSQL-based Efficient Planning Algorithm for Fully-automated Service Composition in Dynamic Service Environments. IEEE SCC (1) 2008: 301-308 
A Reverse Order-Based QoS Constraint Correction Approach for Optimizing Execution Path for Service Composition. OTM Workshops 2008: 29-30

以下是論文筆記:
1. 本文要解決的也是"QoS-aware service composition"問題. 與之前看過的幾篇論文不同, 本文沒有使用global selection方法, 而是在基於local selection的基礎上, 通過多次與provider協商逐步改進, 來確保組合服務最終達到end-to-end QoS要求.
作者闡述的本文idea的"源頭":
"Our method mainly exploits the hidden market competitive relationships which widely exist in real business world for developing a novel bargaining strategy."
"(current methods) do not pay much attention to the hidden competition between service providers which usually forces service providers to dynamically adjust their service properties such as time and cost to offer better QoS."
"… in order to maximize the profits, the initial QoS values advertised by service providers are generally somewhat higher than the real ones. Hence, there exists a possibility for service providers to reduce the benefits from their initial QoS proposals if a user launches a bargaining process with them."
主要是在說, 挑選服務時要跟供應商討價還價.

2. (S2)在講local selection方法, 比較福士化(normalization->score)
這裡用到的normalization方法不是Zeng LZ的那一套, 而是採用了與平均值的比率:
 
公式(1)用於positive quality dimension, 公式(2)用於negative qualitydimension.
記得我以前在一篇博文裡就說過, 這些不同的normalization方法各有什麼特點, 分別適用於web service的領域中哪些場合, 好像還沒有看到過這方面比較的資料. 我猜現有相關論文中應用何種normalization方法, 大概多是拍拍腦袋決定的結果(反正相關的實驗也是在類比環境中進行, 只要實驗結果在可接受的範圍即可).

3. (S3) 討論群組合服務的QoS彙總, 也是福士化的內容. 彙總後驗證local selection的結果是否滿足end-to-end QoS的要求.

4. (S4) 這部分將近2頁的內容是本文的核心了.
演算法的關鍵點:
(1) 判斷哪些是critical nodes (which have strong impacts on the corresponding constraint violation) (Step 7)
作者舉了個例子: 對於price constraint, 價格越高的node越critical.
(2) 對於bargain過程(S4.2), 本文只是做了概念性的描述, 並沒有開發實際的協議來支援.
(3) 演算法包含了2重迴圈,
    第一重迴圈是針對不同的violated QoS(比如price ,response time), 根據使用者的preferences依次進行;
    第二重迴圈針對不同的nodes(一個node對應一個service class), 按照critical程度依次進行.
迴圈中是不是少了一個中間退出的出口? 即對於某個violated QoS的bargain成功之後, 應該有一個break, 進入下一個violated QoS, 而不需要再繼續當前的keyNodeVector鏈.
(4) Step18中進行了服務的重選擇, 結果自然能改進當前迴圈中的violated QoS, 但是如果選擇了不同的服務, 怎麼保證這個服務的其他QoS屬性仍使組合服務滿足end-to-end QoS呢?
比如在(S4.3)的例子中, 針對WS1, 經過bargaining後, 由於HKB1的response time有改進: 11ms->8ms, 且其price優於AMB3, 所以原來的AMB3出局, HKB1被選中. 要注意的是, HKB1的reputation是97%, 而AMB3的reputation是99%,  ws1綁定的服務reputation下降了2%, 或許在這個例子中, 這個2%的下降沒有導致全域QoS約束被違反, 但是如果全域QoS約束嚴格點, 是會有問題的. 論文中似乎沒有討論如何避免這種情況.

5. 會議論文最後上傳到IEEE時缺乏必要的檢查(有些會議是作者自己上傳的), 即便是好會議, 其收錄的論文在格式排版等方面也難免會有問題. 比如ICWS09, 不同論文的格式並不一致, 有些有keyword, 有些沒有, 有些abstract是粗體, 有些不是. 本文第7頁的圖沒有caption.

6. (S6) related work讀起來比較輕鬆, 提到的有些論文都是熟悉的, 有幾篇陌生的如下, 有空要看看:
Swaroop Kalasapur, Mohan Kumar, et al. Dynamic Service Composition in Pervasive Computing. IEEE Transaction on Parallel and Distributed Systems. 18(7): pp. 907-918. 2007 
Raouf Boutaba Jin Xiao. QoS-Aware Service Composition and Adaptation in Autonomic Communication.  IEEE Journal on Selected Areas in Communications. 23(12): pp. 2344-2360. 2005
Yi Sun, Shaoyi He, et al. Syndicating Web Services: A QoS and user-driven approach. Decision Support Systems. 43(1): pp. 243-255. 2007

歡迎討論.

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.