Web服务资源框架（精选5篇）
Web服务资源框架 第1篇
1 整合的开源软件概述
所述的语义Web服务开发框架是以Spring为具体的业务开发语言,以CXF为Web服务开发语言,以WSDL2OWL-S为WSDL向OWL-S转换的框架,以EXT JS为表示层的显示框架。这是因为Spring与CXF具有很好的兼容,即CXF可以直接将Spring开发的业务转换为Web服务的形式,而WSDL2OWL-S则可以将WSDL自动转换为OWL-S。如图1所示是语义Web服务开发流程图。
(1)Spring是一种面向方面(Aspect-Oriented Programming,AOP)且控制翻转(Inversion of Control,IoC)的开源框架,是由核心容器、Spring上下文、Spring AOP、Spring DAO、Spring ORM、Spring Web模块和Spring MVC框架组成,以它为基础可以与其它多种开源软件集成整合,形成满足不同需求的开发框架,如它能与Struts、Hibernate等开源软件集成形成一种功能较为强大的软件开发框架。
(2)CXF是一款属于Apache的简单易用的Web服务开源框架,继承了Celtix 和 XFire 两大开源项目的精华,提供了对JAX-WS全面的支持,它能与Spring很好的集成,形成一种良好的Web服务开发平台。它包括支持SOAP、Basic Profile、WS-Addressing、WS-Policy、WS-ReliableMessaging、WS-Security、JAX-WSA等多种标准。
(3)WSDL2OWL-S是用于实现WSDL向OWL-S转换,使Web服务转换为语义Web服务。它是在2004年5月发布的一款支持WSDL1.1的语义Web服务转换框架,支持XML、XML Schema输入,支持OWL、RDF输出,支持接口包括API、SOAP、Web Interface。
(4)EXT JS是一款界面美化开源软件,现可以获得技术支持,但需要支付相关费用。EXT JS的本质是一种强大的 JavaScript库,它通过使用可重用的对象和部件简化了Ajax开发,并且Ext JS也是一种 JavaScript 开发框架,通过所提供的JavaScript 库来达到可重用的对象和部件简化Ajax开发,通过JSON(JavaScript Object Notiation)来实现数据获取和显示。Ext JS 最初是 Jack Slocum 编写的一组 Yahoo! User Interface(YUI)Library 扩展。但是,随着2.0 版的发布,它已经成为市场上最简单最强大的 JavaScript 库。在应用 EXT JS时:若Ext JS 安装在 Web 服务器上的 lib/ext 目录中,则
2 框架整合的关键配置代码
配置代码主要包括在Web.xml的配置,Spring与CXF的配置,以及运行WSDL2OWL-S的.bat配置,满足了这三个配置就可以实现语义Web服务开发。
(1)Web.xml主要配置
(2)Spring与CXF整合配置
(3)运行WSDL2OWL-S的bat格式
java –classpath../WebRoot/WEB-INF/lib/owls-api-3.1-SNAPSHOT;../…
3 应用举例
下面以一个客户的基本偏好为例来说明本文所述的语义Web服务开发框架,其步骤和相关关键代码如下。
(1)配置文件,如配置web.xml和applicationContext.xml,使其在web.xml中的classpath路径中所有位于spring文件夹下的以.xml后缀结尾的文件都作为context的配置文件加载进来。其Spring与CXF的配置见第3节。
(2)设置和安装客户偏好的数据库信息
(3)用Spring编写客户基本偏好的业务实体。
(4)在CXF中用JSON(EXT JS)来实现Web服务发布,如图2所示。其发布Web服务的关键代码为
(5)通过WSDL2OWL-S实现图2中的WSDL语义转换,如图3所示。通过如图3所示转换就将WSDL转换为了OWL-S。
(6)从被转换的OWL-S中获取业务功能,关键代码如下:
(7)通过JSON(EXT JS)显示读取的数据,其关键代码如下:
//使用JSON-Lib转化string 的 json为一个javabean
JSONObject object = JSONObject.fromObject(customer);
(8)通过JSON获取数据显示结果,如图4所示。
以上8个基本步骤就实现了语义Web服务开发流程,包括Web服务开发方法,Web服务语义转换方法,以及对OWL-S读取和显示方法。
4 结束语
整合了一种语义Web服务的开发框架,该框架可以简单、方便地实现语义Web服务的开发。据此,通过该框架的特点还设计了一个具体的应用案例来应用,并且给出了具体的应用流程和相关关键代码,从而为语义Web服务开发者提出一种简单有效的开发框架。
参考文献
①http://www.springsource.org
②http://cxf.apache.org
③http://semwebcentral.org/projects/wsdl2owl-s
④http://extjs.com
[1] Alonso G,Casati F,Kuno H,et al.Web Service Concepts.Architec-tures and Applications.Springer,2004
[2] Ardagna D,Pernici B.Adaptive Service Composition in FlexibleProcesses.IEEE Transactions on Software Engineering,2007;33(6):369—384
Web服务资源框架 第2篇
关键词：本体,语义Web服务,服务组合框架
语义Web服务是对传统单一的语义Web和Web服务更深层次的研究, 研究主要聚焦在自动识别、智能推理和智能抽取上, 直接表现在服务发现和选择上, 最后体现在服务组合上, 其内部关系主要是以语义间的相似度、匹配度等角度实现服务响应。而语义描述主要是基于Ontology的OWL-S和WSMO描述语言, 即通过编制 (orchestration) 和编排 (choreography) [1]实现语义服务组合, 这对传统服务组合模型处理语义等方面进行改进和增强, 提高了服务组合效率, 实现了不同程度的服务识别和抽取, 以及服务深度检索, 并通过服务质量 (QoS) 衡量服务组合的好坏。因此相关研究者建立了多种服务组合方法来实现服务聚集。主要归结有 (1) 形式化描述, (2) 智能计算, (3) 语义识别, (4) 基于服务质量 (QoS) 优化方法, (5) 逻辑推理[2]。而在服务组合框架目前主要有: (1) 基于QoS的服务组合框架[3], (2) 基于形式化描述方法[4], (3) 基于中间件方法[5]。在本文中, 主要根据现有研究基础, 提出一种面向本体的语义服务组合框架, 即从服务组合结构的角度进行分析, 建立一种以信任保障机制、调度机制、映射系统、反射机制的服务组合框架, 并且用JAVA开发一个实验型平台在Amazon提供的服务集进行实验表明, 该框架有效且可用。
1相关基础知识
语义Web是由Tim Berners-Lee等人于1999年提出对Web扩展的方法, 其目的是对网络资源进行分析、推理和识别等, 并于2000年正式提出语义Web的体系结构[6]。而Web服务也是近年WWW兴起的新技术, 因此就产生了语义Web与Web服务相结合的语义Web服务, 而语义Web服务的目标是在Web服务的描述中加入足够的语义信息, 使Web服务成为计算机可以理解的实体, 从而支持Web服务的自动发现、自动组合和自动执行等, 最终达到多样化的分布式计算。直接表现就是将语义Web的特征置入到Web服务中去, 实现Web服务各项工作的自动化。目前, 基于Ontology的OWL-S和WSMO都对Web服务语义描述提供了方法。在OWL-S中, 从ServiceProfile、ProcessModel和ServiceGrounding三个方面对Web服务进行了刻画, 其中, ServiceProfile类似于服务的黄页, 描述了服务的功能及相关属性;ProcessModel对服务的过程模型进行刻画, 描述了服务是如何工作的;ServiceGrounding将过程模型与通信协议及消息格式等联系起来, 描述了如何访问一个服务。在WSMO中, 从Ontologies、Webservices、Goals和Mediators四个角度进行刻画语义描述, 其中Mediators是贯穿整个语义Web服务编排和排列的核心。
2面向本体的语义Web服务组合框架方法
定义1本体由概念, 属性, 关系, 功能, 实例, 推理 (公理) 六个元素描述, 它们之间的关系定义为Ontology=<C, P, R, HC, rel, AO>:其中概念层次HC C×C是一个有关向关系, HC (C1, C2) 表示C1是C2的子概念, 关系函数rel:R→C×C, 公理集AO是本体中的概念C和R必须满足的约束[7]。则一个本体关系是一个三元组:Ont=<Ontology, ξ, ψ>, 其中ξ是一个本体逻辑语言, ψ是本体的词典结构。
定义2语义Web是一个二元组SW=<Ontology, Matchmaker (Sim, express) >, Matchmaker (Sim, express) 表示语义描述方式, Sim表示本体的相似度, express表示本体描述方法。且 (Matchmaker.Ontology※Ontology. (Sim express) , 表示语义Web描述成功。
定义3语义Web服务是一五元组SWS=<SW, RWS, QWS, UDDI, QoS>, 元组元素分别表示语义Web、请求服务、响应服务、UDDI和服务质量。
定义4语义Web服务组合是一个二元组SWSC=<SWS, ω>, 其中ω表示服务组合操作方法, 一般包括串行、并列、选择等方式[8]。
定义5信任保障机制是一个六元组:
TSM=<ServTrust (C, P, A, Rr, F, S) , Rolel, RC, CC, IG, QoS (R, A) >, 其中:
(1) ServTrust (C, P, A, R, F, S) [9]:C表示信任客体集合, P表示信任主体集合, A表示信任属性集合, Rr表示主客体之间信任关系集合, F表示各种信任函数集合, S表示各种安全策略集合。
(2) Rolel表示对服务的权限控制。
(3) RC表示在特定的服务范围内。
(4) CC表示安全管理与引擎连接的访问控制。
(5) IG是对具体的应用系统 (ApplicationSys-tems:AS) 提供安全保障。
(6) QoS (R, A) 是服务组合中的可用性和信赖度。
定义6调度机制是一个六元组:DisM=<Inse, SerPool, DisStr, Mort, Classifier>, 其中:
(1) Inse是一个语义服务实例, 当服务执行请求/响应时, 就是一个实例。用队列Qs1来描述。因此:RWS※QWS (Qs1 (Insei) 。
(2) SerPool是一个服务池, 是多个队列Qs组成, 即:∑Qs1※SerPool。
(3) DisStr是分布调度算法。采用先来先服务 (FCFS) 的队列数据结构原理来实现调度。
(4) Mort服务组合监控器。
(5) Classifier是一个服务分类器, 分类不同类型的服务。
定义7映射系统是一个四元组:
MapS=<Source (List1:xml) , Target (List2:xml) , MapPattern, MapView>, 其中:
(1) Source (List1:xml) 是映射系统原有基础设施, 为提供定位体系设计的专用平台。
(2) Target (List2:xml) 是参考映射的目标流程。
(3) MapPattern表示映射模式, 包括映射规则细节。
(4) MapView是映射视图, 包括两方面的内容:为定义10提供反射, 降低映射成本。如图1所示。
定义8反射[10]是一个七元组:
ReflexS=<Msm, Rsm, Cause, SysDep (xml) , SlefOp (Ontology) , Reg, Router>, 其中:
(1) Msm是一个元模型, 称为元系统。
(2) Rsm是一个基模型, 称为反射系统。
(3) Cause是元系统与反射系统因果关联, 即:Cause (Msm (Rsm;则关联Msm (Rsm对称数ReSym=log2 Msm (Rsm。
(4) SysDep (xml) 是基于XML的系统事务描述, 表示系统自述。
(5) SlefOp (Ontology) 是基于Ontology是系统行为描述, 表示行为状态。
(6) Reg是SysDep (xml) 与SlefOp (Ontology) 按不同的运算方式实现逻辑推理完成反射。因此有:Cause:SysDep (xml) [π:Reg]SlefOp (Ontology) 。π表示一种反射运算方法。
(7) Router是反射的路由设置。如图2所示。
定义9基于本体的语义Web服务组合构架用一个六元组:OSWSCF=<SWSC, TSM, DisM, MapS, ReflexS>。它们之间满足如下关系:
∀ (SWSi, SWSj) →SWSC, ∑SWSC→TSM//∑表示多个语义服务组合状态。
3实验结果分析
实验装置由客户端和基于ApacheTomcat的服务端组成, 其Web服务由Axis管理, 语义采用OWL-S描述, 并用Protégé实现本体推理以及编辑, 并用JAVA编写任何保障机制、调度机制、映射系统、反射机制程序模块, 然后按树形结构的形式存储在com.SWSF.*命名空间中, 并配置servce.xml、web.xml, 使各模块可用。这时把Amazon提供的商品订购相关的服务配置到Tomcat中进行实验, 并在实验过程中设置三个服务计数器和一个计时器, 分别用来计算请求服务数 (RW) 、响应服务数 (RS) 和服务组合数 (WS) , 以及登记完成服务组合所需时间 (T) , 这些服务一般包括登陆服务、验证服务, 订单服务、检索服务、信誉服务、结算服务等。同时, 以服务组合数和服务响应数与传统方法进行比较得到如图3, 图4所示。
4结论
本文从语义Web服务组合结构的角度建立了一种面向本体的语义Web服务组合框架, 并分析了语义Web与Web服务的形态。其通过以数学语言的定义方式定义了该组合构架各个组成部分, 这为JAVA语言编程提供了算法级的支持, 因此, 在编程过程中使用了OWL-S描述语言, Protégé和Axis开源件, 其开发环境使用了MyEclipse来集成各开源件。然后将实验性编程结果部署到了Tomcat上, 并采用了Amazon服务集进行实验。实验结果表明, 此方法可行且有效。
参考文献
[1]Stollberg M, Haller A.DERI-digital enterprise research institute (se-mantic Web services tutorial) .3rd International Conference on Web Services (ICWS2005) .Orlando, Florida, 2005:July.11
[2]王杰生, 李舟军, 李梦君.用描述逻辑进行语义Web服务组合.软件学报, 2008;19 (4) :967—980
[3]Canfora G, Penta MD, Esposito R, et al.A framework for QoS-aware binding and re-binding of composite web services.The Journal of Sys-tems and Software, 2008; (81) :1754—1769
[4]Chi Yuliang, Lee Hsunming.A formal modeling platform for compos-ing Web services.Expert Systems with Applications, 2008; (34) :1500—1507
[5]Wang Shengwei, Xu Zhengyuan, Cao Jiannong.Amiddleware for web service-enabled integration and interoperation of intelligent building systems.Automation in Construction, 2007; (16) :112—121
[6]Berners-Lee T, Handler J, Lassila O.The semantic Web, In:Scientif-ic American, 184, 2001;34—43
[7]Maedche A.Ontology learning for the semantic Web.Kluwer Academ-ic Publishers:Boston/Dordrecht/London.2002:11—2l
[8]周相兵.基于Ontology的语义Web服务聚合自动机研究及应用.Proceedings of the27th Chinese Control Conference, 2007;8:719—723
[9]李海华, 杜小勇, 田萱.一种能力属性增强的Web服务信任评估模型.计算机学报, 2008;31 (8) :1471—1477
Web服务资源框架 第3篇
Web 服务是一种网络应用, 它利用一种标准的功能描述语言来描述, 并利用标准的应用层Web协议和定义良好的接口进行交互[1]。Web服务一旦被部署到网上, 其他的应用和Web服务就可以发现和调用这个Web服务, 但是, 为了提高服务可重用性、分散和简化应用逻辑, 单个Web服务一般都不会做得太复杂[2], 要想完成复杂的需求功能, 就必须对Web服务进行组合, 近年来, 随着Web服务数量的不断增加, 可通过已有的Web服务构造Web服务工作流, 实现Web服务的组合, 来完成更大、更复杂的业务流程。
Web服务工作流是以结构化方式执行的一组Web服务[3]。目前, 已有很多研究力图将Web服务应用于工作流系统。其中一项技术是BPEL4WS, 它定义了一种语言用来以业务流程的形式建立Web服务组合[4]。此外, 为了能够从多视角对Web服务进行描述, 从而消除在服务发现和选择等过程中存在的二义性和模糊性, 为Web服务引入了语义, 形成语义Web服务。从而为服务自动发现、组合、执行等提供了良好的基础。目前主要的语义Web服务描述语言有OWL-S、WSMO (Web Service Modeling Ontology) 和SAWSDL (Semantic Annotations for WSDL and XML Schema) 等。
近年来, 针对基于工作流的Web服务组合的研究, 已经有很多, 在文献[5,6]中分别提到了一种利用BPEL实现Web服务组合的方法。文献[5]重点研究了如何通过Web服务的组合以满足用户的请求, 但并没有阐述Web服务自动集成和组合问题。文献[6]中虽然给出了一种语义Web服务动态工作流组合方法, 但他们并没有探讨怎样利用已有的Web服务构造一个新的Web服务工作流。
本文提出了一种基于BPEL4WS的语义Web服务组合框架, 旨在根据BPEL4WS过程模型, 动态地查找、绑定Web服务, 实现Web服务工作流的动态构造。通过对每一类需求功能的商业流程进行分析, 将每一类商业流程用BPEL4WS定义成抽象流程模板APT (Abstract Process Template) ;为了描述每个流程活动所需服务的相关语义信息, 我们为每个APT中参与流程活动的partner定义了一个流程伙伴契约PPC (Process Partner Contract) ;为了使Web服务具有语义信息, 用OWL-S本体语言对其进行语义描述, 通过 OWL-S/UDDI转换器, 使Web服务的语义信息转化为UDDI (Universal Description, Discovery, and Integration) 的注册记录信息并在UDDI注册中心进行注册。
1 BPEL4WS介绍
BPEL4WS是基于Web 服务的商业流程执行语言。它通过编排一组Web服务的执行顺序来定义业务流程, 主要包括两个部分:服务类型定义和业务流程定义。前者主要定义Web服务使用的一些类型定义, 如数据类型、消息类型、端口类型、伙伴链接类型等, 后者主要定义业务流程本身, 包括如下四种:
活动 BPEL4WS流程的每一步都称为一个活动。活动包括基本活动和结构化活动。基本活动负责实现一定的原子功能, 如接收外部请求、调用外部Web服务 (Invoke) ;结构化活动则利用循环、分支等元素对基本活动进行组装整合以实现系统所需的逻辑功能。
伙伴链接及端点引用 BPEL4WS把与流程交互的其他服务称为伙伴。每个伙伴由伙伴链接类型来描述。伙伴链接类型描述了两个服务间的关系, 定义了关系中每个服务所扮演的“角色”, 并指定每个角色所提供的服务接口。端点引用指定了服务的访问地址等相关信息。
变量 变量用于保存组成业务流程状态的消息, 所保存的消息往往是从伙伴那里接收到的消息或将被发送给伙伴的消息。变量可被指定为Invoke、Receive和Reply等活动的输入/输出变量, 保存在服务间流动的数据消息。
相关性 在业务流程中服务间的交互式有状态的交互, 但松散耦合的Web服务却是无状态的。由此, BPEL4WS提出了相关性概念, 通过使用发送和接收消息中特征属性集, 来解决Web服务与流程实例的关联问题。
2 框架概述
2.1 框架结构
本框架主要组件包括工作流引擎组件、可执行流程生成组件 (包括APT解析组件、APT绑定组件、PPC分析组件、语义匹配组件) 、服务语义信息库组件和服务注册组件 (包括Web服务、OWL/UDDI转换器和UDDI注册) , 结构如图1所示。
组合服务的过程首先应是商业流程的建立, 因此为每一类可能的商业流程定义一个抽象流程模板APT文档, 每个APT其实是用BPEL4WS定义的一个抽象商业流程, 使用XML来描述, 只是在APT中并没有明确指定具体参与流程的服务 (即Partner) 以及相关的服务操作, 所有与具体服务相关的技术信息, 在APT中都用一个占位符”?”表示, 故APT是不能直接用于工作流引擎去执行的。被省略去的信息称为未绑定信息, 每一个与服务交互的活动, 如果含有未绑定信息, 则称为绑定点, 绑定点处对应的具体服务通过APT绑定组件进行绑定。
PPC文档是用来描述在对应的APT中绑定点处所需Web服务的相关语义信息, 这些信息用于在运行时和已在UDDI上注册过的具体的Web服务的语义信息进行匹配, 每个PPC包含一个或者多个流程活动契约条目PPCI (Process Partner Contract Item) 。
在图1中, APT解析组件主要是对工作流引擎发送过来的APT文档中的每个绑定点进行编码, 为以后的服务绑定做准备;PPC分析组件主要作用是负责分析PPC文档并从文档中分析出PPCI, 然后将这些条目发送给语义匹配组件;OWL-S/UDDI转换器的功能是把用OWL-S本体语言描述过的Web服务对应的语义信息转换成UDDI记录信息, 并把Web服务在UDDI上进行注册, 注册时UDDI注册中心会为每一个Web服务产生一个全球唯一标识符UUID, OWL-S/UDDI转换器会将Web服务对应的语义信息和在UDDI上所对应的UUID存入到服务语义信息库中以便用于语义匹配;语义匹配组件主要是把PPC分析组件分析出的PPCI和服务语义信息库中所存的已经在UDDI上注册过的Web服务的语义信息进行匹配, 对于和PPCI相匹配的语义信息根据其所对应的UUID查找UDDI服务器, 得到Web服务相关的UDDI记录信息, 并把它填入到PPC对应的PPCI中并发送给APT绑定组件;APT绑定组件是把PPCI中的信息和APT中对应的绑定点进行绑定, 从而生成可执行流程。
2.2 框架运行流程
整个组合过程开始于工作流引擎根据客户端的需求发送相应的APT文档到APT解析组件, APT解析组件对APT文档进行编码并收集绑定点, 然后工作流引擎发送各个绑定点所对应的PPC文档给PPC分析组件, PPC分析组件对PPC文档进行分析并把分析出的PPCI发送给语义匹配器, 语义匹配器根据服务语义信息库中的Web服务语义信息对PPCI进行匹配, 如果找到匹配的Web服务, 把该Web服务对应的UDDI信息填入到PPC对应的PPCI中并发送给APT绑定组件进行绑定, 生成可执行流程并部署到工作流引擎上进行执行, 过程如图2所示。
3 关键问题
3.1 PPC 模型
PPC模型语法形式是通过一个的XML Schema文件来定义的。在XML Schema中包含的元素如图3所示, 即每个PPC包含一个或者多个流程活动契约条目PPCI, 每个PPCI用于描述对应APT绑定点处所需的Web服务功能、QOS、UDDI引用和全局编码等信息;其结构类似于文献[7]中所给出的PPC模型, 不同之处是我们在PPC模型中引入了相关的UDDI记录信息的引用。PPC模型在服务动态组合过程中扮演着两个重要的角色, 一个是对APT中绑定点处的partner的需求描述;另一个是为APT文档与匹配的partner服务之间的绑定起到一个桥梁的作用, 即对于匹配的partner服务来说需要先把自己对应的UDDI记录信息填入到对应的PPCI中, 才能绑定到APT的绑定点处。
通常来说, 一个Web服务可以看作一组操作的集合, 在部署Web服务时对于服务的描述往往可以包括一些关于服务的功能性和服务质量等方面的信息, 由于PPC是用来描述在APT绑定点处期望参与流程的partner的相关信息, 故也应包括这些相应的信息。在图3中可以看出, 服务的相关信息都是用对应的PPCI来描述的, 在PPCI中的功能性描述方面包括了服务的输入、输出、执行条件和执行效果方面的信息;在QoS方面主要包括七个方面的指标, 即可用性、可访问性、响应时间、可靠性、成本、安全性以及完整性, 这些QoS指标的给出有利于更好地选择较好的服务。UDDI引用项主要用于存放与期望参与流程的partner匹配的Web服务的相关UDDI记录信息, 用于APT绑定。全局编码项与APT中相应的绑定点处的编码相对应, 用来识别匹配的服务与那个绑定点进行绑定, APT中绑定点的编码在APT解析的过程中产生。
3.2 OWL-S/UDDI转换器
在OWL-S/UDDI转换器中, 一个主要的部分就是如何从OWL-S本体语言描述的Web服务的语义信息转换成用于在UDDI注册的UDDI记录信息。OWL-S本体语言一般从三个方面对服务进行描述, 即ServiceProfile 、ServiceModel和ServiceGrounding, 其中ServiceProfile用于描述服务的能力, 用Web服务的input, output, precondition, effects属性 (即IOPE指标) 来表示;ServiceModel用于描述服务如何实现, ServiceGrounding则用于描述如何访问服务;而UDDI注册中心的数据从概念上可以分为四类, 即商业实体信息、服务信息、绑定信息和技术规范信息 (tModel) 。针对OWL-S本体语言和UDDI记录信息的表述不同, 在文献[8]中给出了一种二者的对应映射关系, 根据这种关系OWL-S/UDDI转换器可以利用服务提供者、服务名称和服务功能描述等信息构造一条UDDI记录信息, 并将这条记录发送到UDDI注册中心进行注册。注册成功后会把UDDI为该Web服务产生的UUID和相应的语义信息存储到服务语义信息库, 以便用于匹配。
3.3 语义匹配
在文献[9,10]中分别给出了两种不同的语义匹配算法, 在文献[9]中给出的方法主要针对用本体语言DAML-S描述的Web服务之间的匹配, 该算法为Web服务的动态发现、选择和互操作提供了一个可行的途径。在文献[10]中给出了一种基于相似度的多本体匹配算法, 该算法支持两个待匹配的Web服务用不同的本体描述的情况, 算法分别对服务的输入、输出、操作以及用户自定义的规则进行匹配, 适用性比较强。在我们提出的这个框架中, Web服务的语义描述已经明确说明用OWL-S本体描述, 但是对APT中绑定点处所要参与流程的partner的描述并没有固定用那种特定的本体语言, 为了能使框架有更好的扩展性和较好的适用性, 我们在语义匹配算法设计上采用的是一种基于相似度的多本体匹配算法, 关于两个概念相似度的计算采用的是文献[10]给出的, 公式为:
其中synSim、proSim、conSim和neiSim分别表示两个概念之间语法 (名称和描述) 、属性、上下文和邻近点的相似度的值;WS、WP、WC、Wn则分别为这几项的权值。
在结合已有的匹配算法基础上, 下面给出一种适合本框架的匹配算法, 在整个匹配过程中, 主要涉及到的匹配方面有功能 (包括输入、输出、执行条件和执行效果) , 服务质量以及用户自定义的匹配。在Web服务匹配算法中关于输入匹配的算法如下所示, 其余方面匹配算法与此类似。
算法中参数InputA为发布的服务的输入集合, InputR为请求的服务的输入集合, thresHold为指定的InputA和InputR两个输入集合要匹配所需要达到的最低相似度。如果InputA并没有包含任何的输入, 我们认为他们为精确匹配 (exact) 。InputAElement和InputRelement分别表示InputA和InputR的元素, degreeMatch表示一个输入对 (一个是发布的服务的输入一个是请求的服务的输入) 的匹配度。degreeMax表示的是degreeMatch的最大值。CS ( ) 是在两个不同本体之间计算语义相似度的函数。
4 实例分析
本节用一个电子商务领域的一个例子来简单说明本模型是如何动态地产生可执行的BPEL4WS流程并完成语义Web服务动态组合的过程。
在本例中假设由用户提出购买某件衣服的请求, 服务器端接收到来自客户端的请求后, 完成购买过程, 同时选择第三方物流公司对货物进行配送, 其中该衣服的购买过程和选择第三方物流公司进行派送分别用对应的Web服务来完成。下面我们针对该衣服的购买过程来说明可执行流程动态生成的过程。
针对购买衣服这个绑定点处的PPC文档功能性描述信息如表1所示。
根据PPC文档的描述, 经过语义匹配后, 我们选择合适的Web服务进行操作, 得到该服务操作的具体细节如表2所示。
然后把具体的Web服务信息绑定到抽象流程模板APT中编码与PPC模型中的全局编码一致的绑定点处, 生成可执行的BPEL4WS流程, 完成Web服务的动态组合, 绑定前与绑定后的流程描述如表3所示。
通过以上过程可以看出, 本框架可以自动地完成Web服务工作流的动态构造, 从而实现Web服务的动态组合, 大大提高了服务组合的动态性与灵活性。
5 小 结
本文提出了一种基于BPEL4WS的语义Web服务组合框架, 并对框架中所存在的关键问题进行了详细的分析。在框架中用商业流程执行语言BPEL4WS对相似的商业流程定义一个模板, 即抽象流程模板 (APT) 。为了能反映APT中参与流程活动的partner的语义信息, 为每一个APT中绑定点处的partner定义了一个流程伙伴契约PPC;在服务注册阶段通过OWL-S/UDDI转换器把用OWL-S本体语言描述的Web服务语义信息转换成UDDI注册记录信息, 并完成UDDI的注册, 同时把对应的Web服务语义信息存放到语义服务信息库中用于语义匹配;在语义匹配阶段引入了一种基于相似度的多本体匹配算法, 使框架的适用性和扩展性得到增强。
未来的研究工作主要包括:对匹配算法进行优化, 降低其复杂度并提高算法效率;对PPC中关于QoS的描述进行扩展;以及研究Web服务绑定过程中更为复杂的问题, 比如抽象BPEL4WS和可执行BPEL4WS流程之间的语法差异等。
参考文献
[1]W3C:Web Services, http://www.w3.org/2002/ws/.
[2]Fan J, Kambhampati S.A snapshot of public Web services[C]//ACM SIGMOD Record, 2005.
[3]付燕宁, 刘磊, 张家晨.构造语义Web服务工作流的模型[J].吉林大学学报, 2007.
[4]Curbera F, Khalaf R, Mukhi N.The next step in Web Services[J].Communications of the ACM, 2003:35-40.
[5]Daniel J Mandell, Sheila AMcIlraith.Adapting bpel4ws for the seman-tic web the bottom-up approach to web service interoperation[C]//Proceedings of the2nd International Semantic Web Conference, 2003.
[6]Laukkane M, Helin H.Composing workflows of semantic Web service[C]//Proceedings of the Workshop on Web-Services and Agent-based Engineering.AAMAS Workshop on Web Services and Agent2Based Engineering, 2003.
[7]Zhile Zou, Zhenhua Duan, Jianli Wang.Acomprehensive framework for dynamic web services integration[C]//Proceedings of the European Conference on Web Services (ECOWS′06) , 2006.
[8]Paolucci M, Kawamura T, Payne Terry R, et al.Importing the semantic Web in UDDI[C]//Proceedings of Web Services, E-businessand Se-mantic Web Workshop (CAiSE Workshop) .Berlin Heidelberg:Springer Verlag, 2002, 225-236.
[9]Paolucci M, Kawamura K, Payne TR, et al.Semantic Matching of Web Services Capabilities[C]//Proceedings of the1st International Seman-tic Web Service.Las Vegas, Nevada, USA:[s.n.], 2003.
Web服务资源框架 第4篇
企业信息化可以划分为以下4个阶段。
第一阶段, 信息化工程的基础建设。可以分为三个层次描述:第一层, 信息资源网是信息化工程的根基, 是基础层, 也是信息化工程出发点和归宿;第二层, 通信、计算机网是为利用信息资源而建造的硬件平台;第三层是通过硬件平台使用信息资源的应用系统。
第二阶段, 局部信息资源管理。信息资源是信息化工程的“门槛”和“根基”所在, 因此它是不可逾越的。真正研究“企业以信息化带动工业化”实现“跨越”的途径应该是:从信息资源入手, 完成信息资源的“助跑”阶段, 才能实现信息化的“跨越”。具体说就是要运用科学成熟的信息资源管理 (IRM) 技术和软件工具, 从数据源头抓起, 通过信息资源规划的手段, 快速建立企业信息资源管理的基础标准。
第三阶段, 内部统一, 资源共享。以信息资源为例, 在以前的应用开发过程中, 由于数据平台的不统一, 同样的一个数据项多次录入, 在不同的平台之间保存, 因而不能确保数据的完整性。通过总体数据规划建立统一的数据平台, 不仅适应了信息化发展的要求, 也为后续应用开发工作奠定了坚实的基础。
第四阶段, 企业社区的资源共享。在实现单个企业资源整合后, 企业对资源需求的范围必定会进一步扩大, 这种需求使得一定数量的企业会结成一个企业社区。在企业社区范围内, 企业的资源可以共享, 信息传递更加便捷, 企业间可以及时获得需要的资源。而企业间的资源整合平台正是实现企业间资源共享的技术手段。
随着企业对资源整合范围的扩大, 对实现整合手段的技术要求也越来越高, 而传统的面向对象的技术对解决资源整合显得捉襟见肘。以服务为技术基础的Saa S理论的出现, 为解决这一问题提供了一种可行性。面向服务软件是软件开发的下一次革新。在Saa S理论中, Web服务的功能已经从简单的消息传递扩展成了功能完整的应用。这种新的面向服务的方法可以解决软件在维护和演进中面临的不灵活问题, 同时为实现企业间信息整合提供了一种可能。
Saa S是企业用户通过互联网向厂商定购所需的应用软件服务, 按定购服务的多少和时间的长短向厂商支付费用, 并通过互联网获得厂商提供的服务。利用Saa S模式, 用户不用购买软件, 而改为向提供商租用基于Web的软件来管理企业经营活动, 且无需对软件进行维护, 服务提供商会全权管理和软件维护。软件厂商在向客户提供互联网应用的同时, 也提供软件的离线操作和本地数据存储, 让用户随时随地都可以使用其定购的软件和服务。
二、问题描述
(一) 资源整合的必要性
由于过去的客观条件, 各个信息系统是在实验和探索中分散开发的, 是面向具体业务和部门的, 数据库是面向人工报表建立的, 数据流程大多是模拟手工业务流程的, 信息编码是随意的。因而, 已建成的信息系统之间难以共享信息, 形成了若干大大小小的“信息孤岛”, 沿此方向发展无法从根本上解决数据环境复杂、混乱的问题。随着我国企业信息化进程的发展, 企业对信息量需求的增大已成必然, 而传统的ERP和CRM只能满足企业对自身资源管理的需求, 如何在企业间形成一个资源共享、信息传递便捷的整合平台成为必然。
(二) 资源整合的可行性
近年来, 随着越来越多的成功案例, Saa S成长的势头越来越强。尽管Saa S是通过Internet交付的, 并且基于使用来收费, 但它本质上还是软件应用。Saa S包含了业务数据与业务逻辑, 这些都需要与Saa S用户部署的其他应用集成。Saa S基于Web Service技术, 是Web Service技术的新的应用方式, 在本质上, Saa S是以Web Service为基础的新的软件设计方法论。
三、问题解决方法
企业社区资源整合模型的建立:模型整合的范围包含“信息孤岛”、新增加业务和企业社区内的业务整合, 其平台模型如图1所示。
企业内部资源整合:在此研究过程中, 主要针对企业内部的“信息孤岛”问题, 对企业的遗留系统及新增业务进行研究, 达到企业内部信息的传递畅通、资源共享无障碍。
企业间资源共享:企业社区内各个企业共享信息、资源, 相互之间的业务可以互调。
企业社区内的业务复用:企业内部业务流程多采用电子合约形式, 电子合约管理应用需要支持个性化需求。本项目采用基于软件即服务的新的业务模型, 使一个单个应用实例支持多租约。这种模型的优点在于, 使提供者降低成本, 中小用户可以负担。在模型内部, 企业间的业务可以被其他企业调用, 不同企业的业务可以重新组合成一个新的业务。
(一) 实现跨企业的数据共享和资源整合
平台建立后, 可以整合企业社区内的资源和数据, 以企业社区为资源管理和数据共享的目标, 在这个目标范围内, 企业间资源可以共享, 业务可以互组。对于一些需要跨企业间合作的业务可以达到完美的无缝组合, 例如企业纳税、投标、签订合同等业务都可以在平台内完成。
(二) 完全可配置技术
基于Web服务的企业社区资源整合平台大量采用可配置技术, 从元数据的选取、业务组合到平台界面都可以通过配置完成。不同的企业通过配置可以调用不同的元数据, 组合各种业务, 企业用户也可以配置自己的程序外观。
(三) 灵活的业务可扩展性
可扩展包括元数据的扩展、业务流的扩展和界面的扩展。当企业用户产生新业务的时候, 平台通过扩展接口可以实现自动的数据装载、流程组合, 完全适应企业不断变化的业务需求。
(四) 用户存储及相关设计
数据访问控制和可扩展的数据结构。
(五) 其他技术
1. 安全权限的继承性
系统的授权 (Ahthorization) 一般都是根据用户组角色来进行的, 在对授权的管理上, MS提出了一个“配置域”的概念。存取控制由配置域管理, 每个配置域根据应用的关系策略继承上级配置域的角色、许可和商务规则, 并可在适当的时候对其进行修改、添加和删除。从概念上来说这是非常合理的, 比如一个企业内的部门是一个配置域, 它的上级配置域就是企业, 而下级配置域可能会具体到每个最终用户 (也可能是部门内的小组) 。但具体实现如何去做, 还需要进一步研究并给出方案。
2. 用户的不同等级
Web服务资源框架 第5篇
Web服务是分布式计算的主流技术,为了通过Web服务构建分布式应用,人们制定了一组Web服务技术规范,包括用于服务描述的WSDL、用于服务通信的SOAP和用于服务发现的UDDI等。但是,基于以上基本技术规范的Web服务很难实现Web服务的智能发现和组合,为此,人们提出了语义Web服务概念[1,2]。语义Web服务扩展了WSDL描述机制,以机器能够理解的方式描述了Web服务,使得Web服务的智能发现和组合成为可能。目前人们对基于语义的Web服务技术进行了大量的研究[3,4,5,6,7,8],提出了很多有益的研究成果,建立了OWL-S[9]、WSMF[10] (Web Service Modeling Framework)、SWSF(Semantic Web Services Framework)和WSDL-S等技术框架,这些研究扩展了Web服务语义描述,如服务接口、分类、功能、QoS等,建立了包括服务发现与组合在内的技术模型。这些研究成果提高了Web服务智能处理的能力,促进了Web服务技术的发展,但是仍然远远不能满足人们对Web服务的使用要求。
在语义Web服务技术迅速发展的同时,作为其技术来源之一的语义Web技术也在蓬勃发展,越来越多的Web资源本体库建立了起来,一个自然的想法是能否将两种技术结合起来,利用Web资源本体库实现Web服务的发现和组合。与这种想法相接近,人们已经针对服务的输入输出关系,提出了IOPE(Input、Output、Procontion、Effects)概念,IOPE标识了Web服务的输入输出数据、服务执行的前提条件和服务执行的效果。基于IOPE,产生了很多Web服务的发现和组合算法。文献[11,12]提出了一种等级匹配方法,依据类的继承关系确立了精确匹配(exact)、插入匹配 (plugin)、包含匹配(subsume)和失败匹配(fail)四种匹配方式,根据输入输出的不同匹配程度实施Web服务发现。文献[13]依据请求参数与服务参数的相似程度计算两者相似度,并依据Web服务输入输出之间的关系建立服务链,通过比较各服务链的相似度确定Web服务的组合方案。
基于IOPE的方法有效地界定了服务的适用范围,是Web服务发现和组合的一种重要技术手段,但是,IOPE描述的是参数本身及其前因后果,并不关心参数所代表的资源类及其之间的关系,不能利用Web资源关系来发现Web服务。本文认为Web服务是Web资源的一种动作行为,可用于改变Web资源状态或建立新的Web资源,因而Web资源既可作为Web服务的输入资源也可作为输出资源。利用Web资源之间的关系可以实现资源发现,利用Web资源与服务的关系就可以实现服务发现并进一步实现服务组合,如何通过分析Web资源、Web服务的各种关系实现高效而灵活的Web服务发现和组合就成为一个必须解决的问题。为此,本文提出了基于资源本体的Web服务研究,在介绍相关概念并对Web资源和Web服务作形式化描述的基础上,分别对资源之间的父子关系和资源服务间的输入输出关系进行了分析,建立了相应的发现和组合算法并对计算复杂度进行了分析,最后做了总结。
1 基本概念
Web资源是指使用统一资源描述符(URI)表示的事物或对象,本文的资源均指Web资源,以下对两者不作区分。本体(Ontology)是一个哲学概念,指“对世界上的客观存在的系统化的描述”,在信息和人工智能领域被定义为“概念化的明确的规范说明”。本体一般采用概念、属性、关系、公理等要素来描述客观事物,本文采用OWL语言来描述Web资源:
定义1 资源Resource={ri,0<i<m},其中ri={resourceName,attributeName, WSI,WSO,father,Children}。rsourceName表示资源本体类名;atributeName表示资源的一个数据属性,为了描述的方便,我们只考虑具有一个属性的资源,定义为原子资源,对于资源的其他属性我们把它定义为具有相同资源名的其他原子资源;WSO表示所有以ri为输入资源的Web服务集合;WSI表示所有ri为输出的Web服务集合;father表示Resource的父类,只有一个;Children表示Resource的子类,可以有多个。在这些描述中,resourceName和attributeName定义了资源本体类本身,WSI、WSO、father和Children定义了资源本体的对象属性。
定义2WS={wsj,0<j<n},其中wsj={serviceName,operationName, RI,RO},与Resource类似,serviceName表示服务名,operationName表示操作名, serviceName和operationName共同定义了一个原子服务;RI表示输入参数集,RO表示输出参数集,每个参数在语法上是某种数据类型,在语义上代表了一个原子资源,RI和RO定义了服务本体的对象属性。
定义3 为更好地表示资源与服务的输入输出关系,记资源rk的输出对象属性WSO为WSO(rk), 输入对象属性WSI为WSI(rk)。WSO(rk)={wsoki,0<i<m},WSI(rk)={wsikj,0<j<n}。Web服务wsk的输入资源属性RI为RI(wsk),输出资源属性RO为RO(wsk),RI(wsk)={riki,0<i<m},RO(wsk)={rokj0<j<n}。
定义4 记查找请求中的资源集RR={RRI,RRO},RRI和RRO分别表示输入资源集和输出资源集,RRI={rrii,1<i<m},RRO={rroj,1<j<n},m、n分别表示输入资源数和输出资源数;为表示方便,请求资源集还可以定义为RR={rri,0<i<m+n},rri表示不加区分的资源。
定义5 定义查询条件输入资源rrii与本体库中Web服务输入资源rikj的相似度为输入相似速度ADI(rrii, rikj),查询条件输出资源rroi与本体库中Web服务输出资源rokj的相似度为输出相似度ADO(rroi, rokj)。计算规定如表1所示。
当rrii= rikj 或rroi= rokj时,表示查询条件中资源和某Web服务的资源是同一种资源,此时资源相似度为1;rrii ⊂rikj表示riki是rrii的父类,该Web服务能接受请求资源为输入,此时输入相似度为1,否则,不一定能接受请求资源为输入,输入相似度为α;rroi⊂ rokj表示rokj是rroi的父类,Web服务产生的资源不一定符合用户请求,此时输出相似度为α,否则,输出相似度为1。如果输出资源rokj是rroi的父类的父类或输入资源rikj是rrii的子类的子类,则输入相似度为α·α,以此类推。
2 Web服务发现
基于资源本体的Web服务发现根据用户请求中提供的资源,利用本体库所描述的Web资源类之间的关系、Web资源类与Web服务类的关系组织查找。查找分二大步:第一步直接查找资源对应的服务,对输入资源,查找以其为输入的所有服务,对输出资源,查找以其为输出的所有服务,对各资源的查找结果取交集,返回结果,如结果为空,进入第二步。第二步查询资源的的父类资源或子类资源(统称为二级资源),在查询二级资源对应的服务并取交集,如果有结果则返回否则进入第三级,依次类推,直到达到某个预先设定的条件结束算法。由于第二步是根据资源的继承关系查找Web服务的,因此我们也将其称为上下位资源查找法,与之相对应,我们称第一步的查找算法为直接资源查找法。
查找算法如下:
Step1 采用直接资源查找方式,查找资源rrii的输出Web服务集WS(rrii),查找资源rroj的输入Web服务集WS(rroj),对所有结果取交集WS=(∩
Step2 遍历资源rrii的第j级父类和第k级子类得到新的输入资源集extend(rrii),0<j<c1,0<k<c2,定义所有输入资源RRI的父子类输入资源集合为RRIE,RRIE=∪
Step3 同step1,对RRIE中的每个资源查找输出Web服务,对RROE中的每个资源查找输入Web服务,对所有Web服务取交集得结果集WS。
Step4 根据定义5计算WS集合中每个Web服务wsk的输入资源rikj与rrii的相似度ADI(rrii, rikj);取其中最大值为rikj与请求输入资源集RRI的相似度,即AD(RRI,rikj)=MAXj(AD(rrii,rikj))。计算wsk的输出资源rokj与rroi的相似度ADO(rroi,rokj),取其中最大值为roki与输出资源集RRO的相似度,即AD(RRO,roki)=MAXj(ADO(rroi,rokj))。
Step5 计算备选Web服务wsk与请求资源集RR的总的相似度AD(RR,wsk)=
Step6 返回最高相似度Web服务或高于某个阈值γ的Web服务集。
说明:
(1) 与逐级查找资源和服务的原始算法不一样,我们分别在step2和step3完成了对所有资源的查找和对应服务的查找,这样做是考虑到资源的第i级上下位资源的输入输出服务集可能会和另一资源的第j级上下位资源的服务集有交集,避免了把一些本来符合要求的Web服务给错误的忽略了。
(2) step1中对由每个输入输出资源求出的Web服务取交集确保所求的Web服务输入输出参数均可在给出的资源集RR中找到,确保了封闭性。由于本体并不具有面向对象中严格的继承关系,在本文中WS的Output属性就不能继承,因此我们在计算中手工遍历资源RRi的父类和子类以求取WS(CRj)。
(3) 算法的结束条件一般通过限定资源的搜索级数来实现,搜索级数的设置考虑三个因素:一是针对资源树上小下大的特点,向上搜索深一些,向下搜索浅一些;二是根据相似度计算,输入资源向上搜索浅一些(相似度越来越小),向下搜索深一些,输出资源则相反;三是根据Web服务输入资源一般多于输出资源的特点,输入资源搜索浅一些,输出资源搜索深一些。此外,还可根据服务器的工作状态和用户的QoS要求动态设置。一个参考取值是:c1=3,c2=3,c3=5,c4=1。
下面以一个单输入单输出的Web服务说明查找计算过程:
例1 假定有六个资源类,其中Creature是Human的父类,Writer是Human的子类,Literalworks是book的父类,Fiction是Book的子类。有一个服务类Creation,其输入为Human,输出为Book。各类之间的关系如图1所示,用户不同的查找请求会产生不同的输出。
查找请求:Input={Writer},Output={Fiction}
算法步骤:
不同查找组合下相似度计算结果如表2所示。
本例虽然只有一个Web服务,且该服务也只有一个输入和一个输出,但也基本反映了查找的每个步骤,从中可以看出,上下位资源查找方法简单、易于实施,查找过程的计算复杂度体现在两个方向的搜索和相似度计算。本文规定资源类都是单继承,因此向父类方向的搜索只能找到一个直接父类,计算复杂度位是线性的,向子类方向搜索时,假设每个资源类平均有K个子类,限定搜索级数为c,则计算复杂度为O(Kc),因此总的计算复杂度为O(Kc)。应严格限制c的取值,一般不超过3,当c=0时,上下位资源查找退化为直接资源查找。
3 Web服务组合
Web服务组合将简单Web服务按照一定的方式集成在一起,组成一个功能更复杂的、更接近用户使用的Web服务,主要分为静态组合和动态组合两类。静态组合的组合模型在用户请求之前已经建立好,但用户在调用该服务时可以动态选择服务实例,静态服务组合的研究比较成熟,已经建立多个技术规范,如业务流程执行语言BPEL4WS和Web服务编排定义语言WS-CDL。静态组合遵循严格的组合规范,具备有出错处理机制,能最大程度的保证组合的正确性和可用性,但它不能根据用户请求动态生成组合方案;与之相反,动态服务组合可以根据一定的知识和算法动态地建立服务组合方案并动态调用服务实例,但组合成功率和正确性不如静态组合高。动态组合是当前Web服务研究的热点,主要有基于AI规划服务组合、基于构件组装服务组合等方法,这些方法一般都是对服务进行较为严格的形式化描述,通过对其进行穷举或推理的方式得出服务的执行序列。对于大规模的Web服务集,穷举法效率极低,甚至不可能实现,基于推理的方法一般效率不高,为此,本文提出了基于资源本体的Web服务组合方法,利用本体库中资源与服务的关系,通过逐级查询,最后找到一条满足所给输入资源和输出资源的服务路径。
为了便于描述服务组合,重新定义相关概念:
定义6 定义一个组合请求Request=WS(RI,RO),RI为输入资源集,RO为输出资源集,WS(RI,RO)表示以RI为输入和以RO为输出的组合服务。
定义7 令资源集R={ri,0<i<m},m为资源数,资源ri的输出服务集为WS(ri),资源集R的输出服务集为WS(R),WS(R)=∪
定义8 令Web服务集WS={wsi,0<i<n},n为服务数,服务wsi的输出资源集为R(wsi),服务集WS的输出资源集为R(WS),R(WS)=∪
定义9 令k为循环次数,定义第k次循环的输入资源集为RIk;对应的Web服务集为WSk,WSk=WS(RIk);WSk的输出资源为ROk,ROk=R(WSk)。
资源与服务之间是一种输入输出关系,我们的算法就是利用本体库中这种关系逐层查找的,为了正确反映资源和服务的特征,根据定义1和定义2,我们在算法中分别建立了资源和服务的数据结构,原子资源r={ResourceName,AttributeName, *preService[],*nextService[]},原子服务ws={ServiceName,OperationName, *inputResource[],*outputResource[]},其中*preService[]、*nextService[]、*inputResource[]、*outputResource[]为指针数组,指针分别指向r的输入Web服务、r的输出Web服务、ws的输入资源、ws的输出资源。
算法思想是搜索一系列相互关联的Web服务,其中第一个(一组)Web服务以RI为输入,最后一个(一组)Web服务以RO为输出,利用Web资源和Web服务之间的输入输出关系,从RI开始搜索对应的输出服务,再搜索该服务的输出资源,再以该输出资源作为下一轮的输入资源继续搜索,直到RO中的每个资源都出现在输出资源集中。为了控制算法复杂度的指数级增长,基本的查找算法不再使用资源的父子资源,而是采用直接资源查找法查找Web服务,同时控制循环次数,避免无限循环或穷尽搜索。算法流程如图2所示。
算法步骤如下:
Step1 初始化输入资源集RI1=RI,建立RO标记数组,标记为未找到。
Step2 遍历资源集RIk,对每个资源参数ri查找本体库,求ri的输出Web服务集WS(ri),将结果写入ri数据结构。
Step3 求资源集RIk中所有ri的输出Web服务集的总和WSk=∪
Step4 遍历WSk,对每一个Web服务wsi查找本体库,求wsi的输出资源集R(wsi),将结果写入wsi数据结构。
Step4.1 求RO∩R(wsi),如果结果非空,在RO集合中标记该资源为已找到,在R(wsi)删除该资源。
Step4.2 查找RO标记集合,如果所有资源已找到,退出循环。
Step5 判断循环次k,如已达最高次数,退出算法,返回空。
Step6 求服务集WSk中所有wsi的输出资源集的总合Rk=∪
Step7RIk+1=Rk,k=k+1,跳转至step2进入下一循环。
Step8 返回所有资源和服务链表数据。
算法的结果为Web资源和Web服务链表,由链表可以很容易的构建出表现Web服务组合关系的DAG图或二维表,具体算法不作介绍。
文献[2]中提出了一种基于图的自动Web服务组合方法,该方法也是根据Web服务的输入输出参数搜索Web服务,但是,该方法仅基于Web服务本身进行穷尽搜索,没有Web资源本体库的支持,在Web服务集较大时时间消耗较多。与文献[2]相似,图3展示了一个旅行服务的查找过程,用户提供的输入资源集RI={hotelName,hotelCity,hotelState,foodPreference},输出资源集RO={map},由前三个参数查找到一个共同的Web服务FindHotel,参数foodPreference的输出服务是FindRestaurant和GuideRestaurant两个服务,由这三个服务可进一步查找相关资源,最后查找到输出资源map。从图中我们可以看出,FindHotel是开始服务,FindDirection是结束服务,两者都必须执行,FindRestaurant和GuideRestaurant是两个可以相互替代的服务。在BPEL中,服务之间有顺序、并行、可选、条件执行等多种逻辑关系,本文的算法结果可直接支持前三种关系。在完成搜索过程后,即可根据结果链表求出服务组合结果,这个过程不再讨论。
基于资源本体的Web服务组合算法具有很强的适应性,对用户查询请求中提供的输入输出资源,可以任何方式参与组合,rii可以是参与组合的Web服务中的任何一个服务的输入,roj可以是任何一个服务的输出,rii可以同时作为多个Web服务的输入,roj也可以同时作为多个Web服务的输出。另外,算法还支持没有语义的参数,不是所有的Web服务参数都有语义的,有许多Web服务的一部分参数代表了某种资源,另一些参数可能是纯粹的数据,此时,只需简单的把该参数数据结构的“ResourceName”设为空、把”preService”和”nextService”两者之一设为空即可。
基于资源本体的Web服务组合还具有较强的可扩展性,为了增加查全率,我们还可以利用资源的上下级关系来查找Web服务,为避免计算过程的复杂性,不再采用相似度计算方法,而是采用完全匹配的方法实施查找,即:查找Web服务时,WS(ri)不仅包括ri的输出服务,还包括ri的父类的输出服务,但不包括其子类的输出服务。本文的组合算法是一个从输入资源到输出资源逐级推进的算法,从前面介绍的双向链表可以看出,Web资源和Web服务的数据结构都是对称的,因此,我们还可以从输出资源反向查找输入资源,原则上我们可以得到相同的结果,但从输出到输入与从输入到输出毕竟有所不同,如输入参数一般多于输出参数,因此这种算法的效果有待于实践的检验。
从图2可以看出,基于资源本体的Web服务组合算法以输入资源为起点和中心,逐级查找输出服务和输出资源,呈现出一种指数增长的规律,但是,仔细分析Web资源与Web服务可以发现,有四个方面的因素防止了这种指数级增长的幅度:一是Web服务一般与Web资源具有较强的相关性,因此一个Web资源不会有太多的输出服务;二是用户请求一般基于一个特定目的,因此其输入资源之间具有较强的关联性,很可能多个输入资源共享一个服务;三是Web服务的输出资源一般不会太多;四是某些可替换的服务的输出资源可能是相同的。这四个方面原因决定了查找过程产生的资源数和服务数是以较小的基数增长的,在增长的过程中还会产生多个资源共享一个输出服务和多个服务共享一个输出资源的收缩行为,因此资源数和服务数的增长是介于线性增长和低基数指数增长之间。设算法复杂度为Complex,平均每个资源对应m个输出服务,每个服务对应n个输出资源,迭代次数为k,则O(kmn)<Complex<O((mn)k)。由于m和n都比较低,而且收缩行为大大减少了指数增长的幅度,因此算法具有较高的性能。
4 Web服务描述的语义实现
为了将Web服务与Web资源联系起来,必须扩展Web服务描述,通过增加服务输入输出参数的语义类型描述,将Web服务与Web资源本体库联系起来。学术界对Web服务的语义扩展的研究已经进行了很多年,产生了一些较为成熟的标准,如OWL-S、WSDL-S等,其中WSDL-S专注于Web服务描述的语义扩展,引入了modelReference、schmaMapping等属性来扩展元素的语义,我们可以采用WSDL-S规范,使用modelReference表示Web资源。
modelReference有两种使用方式:
方式一描述了输入参数为HotelName,其数据类型为string,HotelName对应的资源是Hotel,资源和参数构成的共同体Hotel.HotelName表示一个原子资源。
方式二描述了输入参数为HotelName和HotePhone,其数据类型都是string,Hotel.HotelName、Hote. HotelPhone分别表示两个不同的原子资源。
Ecommerce表示资源Goods属于某类资源本体库。
由Hotel.HotelName和Hote. HotelPhone就可以查询本体库,求得对应的父类资源、子类资源和输入Web服务和输出Web服务。采用前文介绍的发现和组合算法就可以最终实现Web服务的发现和组合。至于如何处理原子资源和物理资源的映射关系、如何根据对象类和属性构建本体库以及如何具体化各种查询请求不同系统有不同的实现方法,详细的讨论已超出本文的研究范围。
5 结 语
本文从Web资源入手,通过分析Web资源之间的关系、Web资源与Web服务的关系,发现并提出了基于资源本体的Web服务发现和组合方法。文章利用Web资源和Web服务的输入输出关系,建立起了直接资源查找Web服务方法和逐级查找Web服务组合方法;利用Web资源之间的继承关系,建立了更为灵活的上下位资源查找的服务发现方法和扩展的服务组合方法。与基于关键字的Web服务发现相比,基于资源本体的Web服务发现和组合具有很强的语义,能有效地发现符合用户需求的Web服务或服务组合,大大提高服务查全率;与基于QoS等Web服务本身的语义描述的Web服务发现和组合相比,由于资源是明确的,基于资源本体的Web服务发现和组合天然符合用户需求,具有很高的查准率。此外,许多Web服务组合算法采用穷举的办法,利用相似度计算Web服务组合方案,相比之下,基于资源本体的Web服务组合只需要有限的计算和查找步骤就可以得出结果,其时间复杂度和空间复杂度都是可控的。
基于资源本体的Web服务查找和组合方法既可以单独实施,也可以与其他Web服务发现和组合方法配合使用,在Web资源库很丰富和服务与资源的相关性较强时具有很好的效果,能取得较高的服务查全率、服务查准率和组合质量、组合效率。随着语义Web技术的发展,越来越多的Web资源库建立了起来,基于资源本体的Web服务发现与组合技术的物质基础不断扩大,其应用将会越来越广泛。
摘要：将语义Web技术引入Web服务研究,提出一种基于资源本体的Web服务发现和组合方法。通过分析资源之间关系,建立了基于上下位资源查找的Web服务发现方法;通过分析资源与服务的输入输出关系,建立了一种逐级查找的Web服务组合方法。与基于关键字和Web服务语义的Web服务发现和组合方法相比,基于资源本体的方法能较好地满足服务查全率和查准率的要求,具有较高的组合质量和效率,非常适合与资源密切相关的Web服务。