[论文笔记] 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做为例子说明问题. 集成创新类的论文经常没有实验, 本文也是如此.
读完这篇, 我没产生什么想法, 或许是这篇论文偏早, 又或许集成类论文就是不会给人太多启发?
Vikas Agarwal(阿加瓦尔)
作者部分论文列表
Understanding approaches for web service composition and execution. Bangalore Compute Conf. 2008DECO: Data Replication and Execution CO-scheduling for Utility Grids. ICSOC 2006 (gs:7)Building Applications Using End to End Composition of Web Services. AAAI 2005A 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做为例子说明问题. 集成创新类的论文经常没有实验, 本文也是如此.
读完这篇, 我没产生什么想法, 或许是这篇论文偏早, 又或许集成类论文就是不会给人太多启发?
