Time: 3.0 hours
Kareliotis Christos, Costas Vassilakis, Efstathios Rouvas, Panayiotis Georgiadis, "QoS-Driven Adaptation of BPEL Scenario Execution," icws, pp.271-278, 2009 IEEE International Conference on Web Services, 2009 (Research Track 12 # Services Adaptation)
浏览ICWS09的目录时, 这篇论文的题目让我有点兴趣, 就打开看了一下abstract, 方向与我有点相关, 又翻到最后一页看references, 发现有好几个熟悉的条目(QoS-aware middleware for web service composition, Multiple Criteria Decision Making, Non-Intrusive Monitoring and Service Adaption for WS-BPEL, The QWS Dataset等), 于是决定读一下.
这篇论文的作者来自希腊, 名字不太好记没印象, 翻了一下他的publication list, 发现以前还是看过他的文章的(ICWS07那篇). Kareliotis是雅典大学的博士生, 从他的发表论文来看, 至少从2006年开始就已经在从事这个点的研究了(组合服务的dynamic, exeception处理, middleware等).
以下是他的相关论文: 
QoS-aware Exception Resolution for BPEL Processes: A Middleware-based Framework and Performance Evaluation, Kareliotis Christos, Costas Vassilakis, Efstathios Rouvas, Panayiotis Georgiadis, to appear in the International Journal on Web and Grid Services (IJWGS) Exception Resolution for BPEL Processes: a Middleware based Framework and Performance Evaluation, Christos Kareliotis, Costas Vassilakis, Efstathios Rouvas and Panayiotis Georgiadis, Proceedings of the tenth International Conference on Information Integration and Web-based Applications & Services (iiWAS2008) Enhancing BPEL scenarios with Dynamic Relevance-Based Exception Handling, Chris Kareliotis, Costas Vassilakis, Panayiotis Georgiadis, Proceedings of the IEEE 2007 International Conference on Web Services (ICWS) Towards Dynamic, Relevance-Driven Exception Resolution in Composite Web Services, Kareliotis Christos, Vassilakis Costas, Georgiadis Panagiotis, Proceedings of OOPSLA 2006, Fourth International Workshop on SOA & Web Services Best Practices
以下是论文笔记:
1. 问题描述:
BPEL是目前服务组合的"predominant approach", 但是存在以下欠缺:
(1) 不支持QoS. 因此无法满足用户的QoS要求, 也不能确保动态环境中持续变化的服务一直满足要求.
(2) infrastructure failures(非逻辑错误, 指service unavailable等这类情况, 可以通过调用替换服务来解决).
总结一下, 作者认为当前BPEL存在2个问题: 不支持QoS, 不支持动态服务替换
针对以上的问题, 本文提出的framework可以
(1) 允许用户指定QoS需求, 系统会"locating and invoking"恰当的服务.
(2) 发生错误时替换服务
(3) service selection affinity: 比如选定一个travel agency提供的hotel reservation服务后, 紧接着很可能会选同一个traval agency提供的payment服务
2. (S2)作者将本文介绍的middleware同VieDAME(Non-Intrusive Monitoring and Service Adaption for WS-BPEL, WWW08)做了比较, 认为VieDAME有以下欠缺:
(1) QoS parameters和selection strategy是predetermined through pluggable model (去年5月WWW08的论文刚上线时, 曾经很认真地读过VieDAME这篇论文, 不过现在细节记不大清, 待核实), 而本文则是预先在BPEL文件里使用特殊含义的变量来指定QoS constraints等信息(这个特殊含义的变量需要通过本文的predecessor来解析)
(2) 不支持service affinity.
(3) extension only available for ActiveBPEL engine.
我觉得本文的系统和VieDAME系统比较类似, 都是开发了一个middleware来解决QoS for BPEL和BPEL中动态服务替换这两个问题.
3. 基于标准的BPEL执行环境, 本文引入了2个模块
(1) middleware layer named ASOB (Alternate Service Operation Binding)
实现以下功能
a. 根据desinger指定的QoS要求, 动态选择服务.
b. 通过transform messages/results来解决sytactical differences.
c. 截获系统级别的exception, 通过调用等价服务来恢复.
(2) preprocessor
BPEL文件中使用了两个特殊的变量, ASOB_QoSconstraints, ASOB_QoSweight, 需要这个预处理器来解析, 生成ASOB-aware BPEL scenario(作者称为SC_ASOB).
关于SC_ASOB与普通的BPEL文件的区别见论文第4页的描述.
ASOB这个模块类似于一个proxy, 对于所有成员服务的调用, ASOB会截获SOAP消息, 获取相关信息(比如QoS constraints), 然后才去调用原服务.
因此本文提出的解决方案是要依赖特定的模块(即ASOB和preprocessor), 并不是直接针对标准BPEL环境的解决方案. 
4. 最后, 总结性地谈一下我读了这篇论文的理解
(1) 最初的文件是标准的BPEL文件(能正确编译), 这个文件指定了组合流程, 并使用特殊的变量来表示QoS constraints等信息.
然后predecessor对这个文件进行处理, 生成ASOB-aware BPEL文件.
这个ASOB-aware BPEL文件也是标准的BPEL文件(编译正确, 并且能被标准的BPEL引擎完全理解). 但是这个预处理过的文件里被硬编码了一些ASOB相关的信息(调用成员服务时会将请求发到ASOB模块).
ASOB模块就相当于proxy了, 在SOAP message层面进行截获, 因此具有基于QoS的服务动态选择和替换的能力,
(2)本文的系统和VieDAME的系统, 进行基于QoS的服务选择时, 都只是local selection. 并不支持end-to-end QoS constraints.
(3) 整篇文件的idea其实很简单, 谁看了都能明白, Kareliotis能够发ICWS是因为他有这么一个系统
(4) 以上都是个人粗浅看法, 敬请指正.