[论文笔记] A service creation environment based on end to end composition of Web services (WWW, 2005)

Time:  4.5 hours
Vikas Agarwal(阿加瓦尔)
作者部分论文列表
Understanding approaches for web service composition and execution. Bangalore Compute Conf. 2008
DECO: Data Replication and Execution CO-scheduling for Utility Grids. ICSOC 2006 (gs:7)
Building Applications Using End to End Composition of Web Services. AAAI 2005
A service creation environment based on end to end composition of Web services, WWW, 2005 (gs:76)
Synthy: A system for end to end composition of web services. J. Web Sem. 2005 (gs:34)

问题背景:
快速发布应用程序很重要
-->WS有很大潜力帮助实现B2B/EAI无缝集成
-->当时针对WS组合工作比较零散, 不充分, 缺乏标准化的工具与平台.
    business world: WSDL+BPEL+SOAP
    academia: 使用本体来表示WS, 使用AI planning方法(基于目标推理)来实现组合

本文工作:
第一次提出了点对点服务组合的集成工作(specification -> deployment). 提供了相应工具与平台的原型系统.
本文的创新类型属于集成创新, 主要介绍了一个集成的系统, 全文按照系统的最初输入(用户输入)到最终输出(可部署的BPEL文件)的过程为主线展开.

系统组成部分(S3)
Service Registry:     使用domain ontology来形式化描述service type
Logical Composer:     Service Specification -> Abstract Workflow
Physical Composer:    Abstract Workflow -> deployable workflow(instance selected)
Execution Environment: partition the workflow by the Decentralized tool and execute in a decentralized fashion concurrently(文中只是提了一下, 没有讲怎么partition)

本文的一个主要概念是将WS composition分成2个阶段(S3)
Logical Composition:
    根据功能, 在service types层面来组合
Physical Composition:
    根据QoS, 基于service instance层面进行服务选择

Logical Composition(S4)
如何表示Service Types?
作者使用OWL-S中的ServiceProfile来表示WS类型定义. 并提议将ServiceType class hierarchy引入到OWL-S upper ontology中, 对应于现有的Service hierarchy.
如何表示用户请求(Requirement Specification)?
使用OWL-S, 以IOPE的形式来描述.
基于AI Planning进行组合.(S4.3)
Planning问题形式如下
<I, G, A>:
    I: complete description of the initial state
    G: partial description of the goal state
    A: set of executable (primitive) actions.
目标就是要找出一组action sequence S(a plan), 可以从I到达G
我没有系统地学习过AI Planing, 涉及到这部分也只能粗浅看个大概意思.

Physical Composition(S5)
Web Service Matchmaking Engine(WSME)
用来替代UDDI, 功能更加强大, 支持QoS, 运行定义规则(比如return(my.MaxCost<your.cost)
WSME是一个注册匹配平台, provider将advertisement record发布上去, consumer将query record提交上去.
匹配之后, 将结果返回给consumer. 如果结果多于1条, 则使用"greedy heuristic approach"根据优化目标来进行选择(S5.2), 文中没有详细讨论这个过程, 也没有提到是局部最优还是全局最优.

此外, 本文以Helpline Service做为例子说明问题. 集成创新类的论文经常没有实验, 本文也是如此.
读完这篇, 我没产生什么想法, 或许是这篇论文偏早, 又或许集成类论文就是不会给人太多启发?