作者：曹洪江
出版社：湖北科学技术出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
语义Web服务组合理论研究试读：
前言
Web服务的研究在近年来越来越多的受到了包括工业界和学术界的广泛关注，其根本原因在于，以往的单个Web服务提供的功能只是单一的功能单元，而随着业务需求复杂性的上升，越来越多的需求向定制服务，多样性服务，复杂流程服务方向转变，因此，对于Web服务的研究重点也随即转变为更多的关注Web服务组合领域的各个环节。作为一种崭新的分布式计算模型，是一种利用Web进行服务集成的有效机制。随着Web服务在技术解决方案中采用的越来越多，适用的范围越来越广，这使得动态Web服务组合技术成为面向服务的计算的核心技术。目前，许多国内外学术研究机构围绕动态Web服务组合技术展开研究工作，并取得了一些成果。然而，Web服务组合还有许多需要进一步研究的问题。主要在以下几个方面：（1）Web服务组合存在组合效率低，组合结果合理性不够的问题，主要的原因是以往的服务组合主要依据服务的接口信息，通过信息的匹配来形成服务组合方案。这样的组合方式在Web服务大量存在的时候，服务匹配的计算量大，效率较低。而仅仅通过接口信息来决定组合方案，还会导致接口语义信息的缺失，服务组合中的带来组合合理性不够的问题。（2）用户需求的多样性，随着领域的不同，用户的不同，用户的需求存在着多样性的问题。通常情况下，一个服务组合系统中，更多的是关注服务的组合机制，从用户角度出发，用户需求存在表达途径缺乏，被表达现象普遍的问题。业务流程也是按照事先制定的模板来进行服务的对应查找，缺乏灵活性。在传统模式下，我们可以看到整个业务开发和维护的环节基本上只是专业人员单方面参与，而缺乏必要的灵活性，这样的应用系统的弊端就是当面临需要能适应快速需求变化时缺乏应对能力。而这种需求的变化来自于用户，因此也就必须以用户需求为中心，以用户需求为服务组合的主要依据才能构造出能将适应用户需求多样性以及Web服务的分布性的两大特点为融为一体的切实可用的服务组合系统。（3）服务组合的QoS属性评价体系不够完善。如何从服务组合方案中功能节点对应的服务候选集中选择出合适的服务存在一个服务评价的问题。要对服务评价则需要考虑服务的QoS信息，但目前的QoS体系主要集中在一些常规的QoS指标上，对能反映领域特征的领域属性缺乏表达和评价机制。（4）互联网环境中的网络化软件从传统的精细编程发展为服务资源的动态组合，使得服务组合的可信性度量从针对软件实体的独立度量变成面向服务组合的综合度量。也就是说，较之传统的软件度量，Web服务组合的可信性度量的关注点有了一定的扩充和演变：在单一、封闭的运行环境下，传统度量研究的是软件自身的可信属性；而在开放、动态的网络环境下，服务组合的可信性度量更加关注服务组合如何高效提供预定功能、并持续满足用户需求。因此，需要研究一种专门针对Web服务组合的可信性度量机制，从独立第三方的客观视角，采用科学、有效的方法，量化组成服务、组合过程和网络环境等种种因素对Web服务组合的影响，指导组合过程的正确进行，并对组合结果进行个性化分析和持续优化。
本书对Web服务组合中的上述问题做了重点研究，利用本体论，图论，模糊数学等学科的相关知识和方法来寻求这些问题的解决途径。第一章绪论1.1背景和意义
纵观网络技术的发展历程，日新月异的网络技术发展过程其实也是一条随着网络在各个领域被广泛应用。在国民经济中发挥的作用越来越大，随着相关应用越来越复杂，涉及领域也越广泛而不断延伸的道路。在网络应用初期，使用者更多的需要只是能将网络进行互联并能传递一些信息，对网络这个载体的要求停留在比较简单的层面，研究也大多停留在网络底层技术上面。随着应用程度的不断加深，各种不同类型网络的不断出现，以及计算机领域本身技术的发展和变革，人们对网络的需求已经脱离了原来的初级阶段，转而向能够有效控制网络资源，对不同的服务需求要求能实现定制化的服务以及网上的各种信息（即包括个人信息也包括商业信息）能够进行有效的管理和利用这些更为复杂的应用延伸，因此，从初期的网络互联层向网络应用层的重心迁移成了一个必然的转变。而整个网络中的一个显著特点就是面向用户的需求，以网络技术为手段，提供满足用户需求的具有一定服务质量的网络服务为主要目标。随着电子商务等一些同网络技术结合较紧密的行业的不断发展以及跨组织应用的日益复杂，复杂业务的需求随之日益增加，仅靠单个Web服务的实现已经无法满足这一发展要求，对像Internet这种集合了各种硬件平台，多种操作系统以及使用了各种类型的软件技术和数据库技术的环境下实现部署在上面的应用能够很好地进行互操作甚至是能够在必要时进行集成。并且具备一定的智能性，减少人为参与的过程。使应用的集成能够自发现，自组合，自连接，自应用。使之成为一个有机的自治系统。更好的为使用者提供有效服务这一方面提出了较为迫切的需求。正是在这样的一个大的需求背景下。SOA体系结构随之提出。但SOA的广泛传播与应用却归功于近年来Web服务的新兴与迅速发展。从发展的本质上，SOA是一种思想理念与软件发展的体系构架，而Web服务仅是实现这种架构的有效路径之一。目前学术界与产业界普遍认同SOA的思想实现，Web服务无疑是一种理想方式。Web服务的实现有其配套的技术保障，其中，XML、SOAP、WSDL、UDDI等等，Web服务的过程实现是通过上述的技术组合完成服务的信息透明传输与信息资源的发布，并提供灵活、可动态扩展与响应的平台支撑，帮助人们在这种动态服务的环境中，针对具体的应用找到软件编程可实现的方法与渠道，从而使SOA架构的思想得以顺利实现。因此，可以理解Web服务动态过程是一系列的标准规范的有机关联与组合应用，而可依据的设计原则可从SOA中找到线索。二者相得益彰，互相促进，应用前景广阔，发展迅猛。SOA（service-oriented architecture）作为一种对象组件模型，这种组件模型能够有效地将不同服务通过事先定义良好的软件服务接口及软件应用程序契约集成起来。软件接口具备跨平台的中立形态，独立于实现服务的软硬环境、异构操作系统和软件编程语言，保证动态服务过程实现能够以一种可靠、统一的形式进行人机友好交互。
具体特性体现在5个方面：
特性一：SOA技术架构可提供安全的网络传输与运行环境。体现在：软件模块互相通讯时，所需的保密需求，可由WSSecurity来达成；同时带来组织成员在环境中的权限控管方式，可在SOA架构内，集成单点登录、PKI模式与数字签名等机制来配合。
特性二：SOA工作协调与应用系统集成。常规应用模块在SOA的世界里，可以采用SOA规定的服务界面对外开放模块的功能。应用模块之间，透过SOA的服务界面透明传输信息，是最简单的Web Services应用实例。价值在于：所有SOA内的应用模块，只要提供SOA的标准服务界面，就可以不受开发语言限制，互相调用或传递信息资源。这里的服务界面，就是WSDL；而SOAP则是规定应用模块之间互相调用或互传信息资源时的封包格式。至于WSDL或SOAP的内容与格式应该如何构造，将由中介系统完成，透过service adaptor直接把常规应用模块包转化成Web Services模块。
特性三：SOA的服务组合柔性化与松散耦合（loosely couple）的特性。SOA内的应用模块能够透明改变组合方式，若改变运行位置，就要借助SOA的两个技术特性：松散耦合以及UDDI机制。松散耦合，得以实现某一模块抽取或添加系统，并不影响其他模块；因有UDDI机制，新应用模块添加时，仅需与UDDI服务器建立联系与确认，服务资源的交互将动态生成。UDDI的存在，某项应用模块发生位置迁移，原有使用此应用模块的其他模块，可以透过UDDI查找服务，原有的服务将继续激活。这种特性满足经常需要把服务节点拆解再重组的BPM（Business Process Management）服务导向模式。
特性四：可管理的SOA Web Services．尽管目前没有统一的标准来规范管理软件与被管理模块的行为，但当前稍具知名度的SOA环境（特别是application server）多半提供系统管理工具环境，方便系统管理，协助管理SOA架构下所辖模块的安装、移除、启动、停用，以及应用模块的状态监控与安全机制。
特性五：SOA技术架构可以透明实现在原有SOA环境添加和扩展新的组件模块，渐进式提升BPM（Business Process Management）技术的成熟度。从ZapThink（2005）整理的SOA蓝图中，可以得知达到不同SOA成熟阶段所需具备的SOA技术。假定SOA有阶段实施的计划，中间过程可以从点对点集成开始，首先提供松散耦合的服务，通过搜索发现网库服务资源，实现可组装与再利用的服务，实现服务用户需求多样化的目标。SOA是一种基于服务的分布式系统，Web服务是实现SOA架构的有效途径。新一代互联网的发展，Web服务将在全球人类多领域信息资源服务中产生前所未有的影响。基于语义的Web动态服务组合研究与应用是实现Web服务朝着动态化、人性化、智能化、精准化方向发展的有效解决方案。近年来，得到了学术界、产业界及其相关领域的重点关注。
Web服务的发展历程经历了一个从无到有的过程。最初的概念是由微软和IBM提出的，其目的就是针对网络的分布性的特点，向分布在网络上的不同应用提供一种可以相互进行沟通和操作的可能。作为一种全新的Web应用方式，首先要具备一定的被发现以及可以进行交互的可能性，通过将XML技术应用到对其接口信息的描述中，使其具备了一种能和分布式环境下的其他应用进行交互的能力。而在自身的功能设计上，Web服务还具备了功能模块化，描述上自包含的特点。其最终应用目标也由满足单一的简单功能请求向支持复杂的业务流程，实现复杂功能转变。从具体的表现我们可以总结出，Web服务应该具备以下几个特性：可被描述；可以被发布；可以被查找；可以被绑定；可以被调用，最后是可以被组合。即通过使用符合规范的描述语言并将服务发布在一个注册机构上，使之能被服务使用者通过提交查询请求查询到，并实现具体服务的绑定从而被调用。在单一服务无法完成请求的任务的时候。能够有一种机制来使单个服务组合成能满足用户复杂需求的服务组合。Web服务主要依托一系列开放的协议和
[1]标准。如图1-1所示。图1-1 Web服务协议栈
从上图的服务协议栈我们看到。Web服务以网络为实现其功能的载体。因此在底层的网络联通，数据传递方面是以HTTP、SMTP、[2][3][4]SOAP、WSDL、UDDI这些因特网标准为基础。还有一些是对针对业务流程，业务编排，服务质量表达及控制方面的协议。诸如WS-[5]BPEL、WS-CDL的服务组合描述语言，QoS以及服务的描述机制，服务的注册机制，服务的发现机制。通过这样一些协议标准的使用，使原来设想的在网络应用中，不同的硬件平台，软件技术构建的应用服务以一种标准化的服务形式表现出来，从而从上层的应用层屏蔽掉因为底层不同带来的服务应用之间的互通鸿沟。使Web服务之间表现出一种松耦合的形态。而在使用者使用这些服务的时候。Web服务对用户呈透明状态。[6,7]
Web服务的技术是多种技术的一种融合。如分布式计算、网[8]格计算（Grid Computing）和XML（Extensible Markup Language）[9]等技术，结合了不同技术各自的优点，采用WSDL（Webservices [10]Description Language）、UDDI（Universal Description, Discovery [11][12]And Integration）和Soap等基于XML的标准和协议，从而具有高度的互操作性、跨平台性和松散耦合等特点，使其成为一种Internet上跨平台，跨系统，跨应用进行数据和应用集成的有效机制。越来越多的网络功能和应用程序通过Web服务的方式提供。Web服务已经成为在Internet上提供服务的有效解决方案。随后出现的基于Web服务[13,14]技术的SOA（Service Oriented Architecture）技术和[15]SOC（Service Oriented Computing）技术，为分布式应用的复用性、灵活性和可扩展性提供了技术路线上的一种理论支持。
面向服务的计算技术通过面向服务架构SOA显示出对分布式应用集成所带来的明显的好处。在SOA的架构中，SOA不能被简单地看做是一种开发应用的手段，它还具有较多的对应用进行管理的内涵。在运用了SOA的企业应用体系中。能对单一的应用模块进行管理显然不是我们使用SOA这一体系架构的唯一诉求。更重要的是对在一个平台上的若干服务之间的相互调用的数据信息的背后所反映出来的一些业务逻辑。在对开发企业的业务应用平台，对应用的业务流程做进一步的优化。搭建出更好的企业应用系统的时候。这些信息都是非常有帮助的。[16]
在上图的这个架构中，服务使用者调用满足其需求的服务是一个动态的。多方交互的过程。一般要经过发布，查找，绑定三个阶段。最终实现服务请求提出的服务与满足请求的具体服务之间的准确绑定。调用并执行服务，使之满足用户的需求。因此在整个架构中也就会相应的存在着三种不同的角色：服务注册中心、服务提供者、服务请求者（服务使用者）。图1-2 面向服务的架构
服务请求者：服务请求者并非指一般概念上的服务使用方，事实上，一个已经存在的Web服务也可以是一个服务请求者只要能以规范的形式发出服务请求，无论是应用程序，还是某个程序中的某个模块。都可以扮演服务请求者这个角色。
服务提供者：顾名思义，这个角色应该是将自己能实现的某种服务功能提供出来供系统中的其他需要的人去使用。而在SOA这个架构中，就必须首先将自己的服务发布到注册中心中，因为服务使用者是通过服务注册中心来查找可以使用的有哪些服务。而不是同服务提供者去进行直接联系。一旦服务绑定到了具体的服务后。才会进行服务的调用。
服务注册中心：这个角色的作用类似于一个中介，服务提供者把能提供的服务放在服务注册中心，服务请求者到服务注册中心来查找自己需要的服务。因此服务注册中心对于服务提供者来说，应该有个服务发布的接口，而对于服务请求者，则有个服务查询的接口。
从上述角色定位来看，特定的角色具备特定的功能，但作为SOA架构，一个具体的服务可以同时扮演多种角色，服务提供者也可以同时是一个服务请求者，而服务请求者本身也可以是服务提供者。因此并没有特定的固定角色。到底是什么取决于服务在整个过程中所起到的作用。
但由于在服务资源和用户需求方面存在着如下的一些特征，因而用户主动参与应用构造并不是一件容易的事。特征主要是以下这些：
SOA架构是一种基础性的架构。这种架构有其不可取代的优势，但在实际中还是会存在一些具体的问题。要比较理想的实现当初设想的目的从现实的角度来看依然存在着诸多问题。
首先，就是网络上的动态性的环境所带来的对SOA架构应用集成所造成的威胁，其原因就在于对服务提供者缺乏一种强制的约束行为。服务提供者提供服务后，对其是否能履约执行没有强行约束。会有在注册中心注册了服务，但随后终止服务的现象，而在服务注册中依然存有该服务提供者的注册信息。这给服务发现的结果带来了不确定性。同时，也会存在某些服务提供者没有在服务注册中心进行注册，从而使服务无法发现的问题存在。这些都是因为网络的动态性所造成的。其次，前面提及对于Web服务的描述一般是采用XML来进行，XML的最大特点就是能自定义标签，而这些标签的确切含义确有可能因为不同人的不同理解而带来二义性，要真正实现网络范围内的对不同的提供者提供的Web服务认识上的统一，单凭XML显然还是不够。因此才有语义网的相关知识的融入。再次则是用户层面的问题。其一是用户的需求不确定性，很多情况下，用户的需求是无法事先预知，或者用一种模板先固定下来。对不确定的需求在Web服务上表现出来的就是一个任务请求提出后。可能没办法去要求有一种固定的服务搜寻，服务组合来满足这个服务请求，这种时候就强调服务的即时搜索，即时组合。强调的是一种时效性。其二就是用户的多样性所带来的服务上的个性化需求，哪怕是同一类服务，也会因为具体使用者的不同而带来的具体要求的不同，比如住旅店。有的人喜欢便宜的，有的人则强调地理位置好的，而有的则强调旅店的软硬件的水准。等等。针对不同用户提供适合他们不同需求的服务正是当前Web服务领域研究的热点之一。
这几点概括起来可以用几个短语来归纳：服务数量多，统一理解困难，要求的速度快，需求经常变。从这里可以看出，一个实用的应用集成系统，光考虑IT架构层面的实现是远远不够的。必须给那些非专业的，但确是系统的真正使用者提供一个参与进来的渠道。从而确保服务组合的可用性。[18,19]
当前，由于基于本体论（Ontology）的语义网（Semantic [20-24]Web）技术的出现，从而使得某些具备一定智能特点的应用软件能够自动准确理解和操作以Web本体语言（Web Ontology Language, [25,26]OWL）所描述的网络资源。这就使得Web服务的自动化程度有[27-30]了某种可能性。其中用到的语义Web服务技术集成了Web服务技术和语义网技术的优点，成为了较具竞争力的新一代互联网服务解决技术路线。目前，对于语义Web服务的研究主要集中在自动服务发现[31,32][33,34][35,36][37,38]、服务组合、服务协商和QoS保障上。相对于传统应用构造来说语义Web服务最为显著的特点是它支持自动服务组合。作为一个单一的Web服务只能满足相对单一的客户需求。无论是服务提供商和还是使用该服务的客户来看，都迫切希望现有的服务能够被方便地组合成功能更加强大的复杂服务用来满足更为多样化的需求。[39]从概念上讲，组合过程包括任务规划、服务发现和QoS感知的服务[34]选择过程，其主要任务分别是：基于工作流技术生成组合服务的执行路径；通过语义匹配的方法为执行路径中的每个任务找到满足功能性需求的服务实例；在该过程结束后，对于组合工作流中的每个任务都会产生多个功能相似的候选服务，每一个可能的候选服务组合被称作一个组合服务执行计划。此时QoS将作为一个重要指标用来对这些执行计划加以区分和优选，该过程可通过综合评估执行计划的QoS，在满足客户QoS限制的前提下，选择出最优的组合方案。本文对QoS在语义Web服务组合中起的作用以及相关的机制进行了深入的研究。
QoS即服务质量，对于这个概念的理解也是不存在一个唯一的定义，其原因就在于，对于不同用户，不同领域的服务来说，随着服务的内涵不同，视角的不同，关注点自然各不相同，对于服务质量的理解也就不一样。以往谈到QoS概念是在底层通信领域，比较常见于底层网络的数据传输。如：QoS被定义为“通信系统中网络层特性的度量”[40]。而从更抽象的层次来说，国际电联对它的定义为“QoS是服务性能的整体效果，为用户对服务的满意程度”[42]，在分布式的多媒体领域，QoS则更强调在多媒体系统满足用户请求方面所能达到[41]质量属性ISO定义QoS为“同一个或多个对象（Object）的整体行为相关的一组特性”[43]。从这些对QoS不同的理解我们还是可以找到一个共同点就是，QoS描述的不是服务功能层面上的东西，更多的是对一些服务非功能方面的一些定义。服务功能层面的东西在Web服务中可以用接口信息去进行描述，而QoS则更多的关注功能实现之外的内容。比如：服务耗时，服务可靠性等等。在Web服务体系中，我们可以从两个层面来看服务是否能被较好的使用，首先是要使服务能从功能上完全满足用户的请求，其次就是应该考虑如何使这种服务能更好地满足服务的请求。这两者的区别就在于，一个是提出一种基本的解决方案，另一个则更强调对服务有效性，服务合理性等方面的要求，而我们认为服务的功能满足是一种基本需求，实现服务的有效性和合理性则为一种高层次需求，这种需求对前面所提及的服务的个性化，服务的即时性都会起到一种重要的影响。因此在服务组合中显得意义重大。当考虑了服务QoS需求的服务组合的时候。根据这些非功能属性的指标，会在服务进行功能组合的时候对参与组合的服务起到一个重要的指导作用。如：如何在众多功能相似的服务中选择合适的服务，如何组合合乎流程要求的服务等。因此从这点上来看，对于Web服务组合中QoS属性的考虑就显得尤为重要。结合到前面提到的Web服务目前存在的几个问题我们可以同样在服务的QoS上面找到相同点，QoS属性的作用就是从非功能需求上来对服务乃至服务组合的结果进行区别性描述，更好的指导服务的选取和服务组合方案的构成。但同时也存在不同的应用集成系统对QoS的属性描述要求，描述范围要求不同的现象。如何使网络范围内的相同服务在QoS方面不会因注册系统的不同，不会因描述方法的不同，不会因描述内容要求的不同而不同，这是一个目前存在的很现实的问题。还有一点就是，因为不同的使用者对一些描述的不同理解，也会存在对QoS属性理解上的差异问题。如果统一这种认识，消除对服务非功能属性含义的理解不一致性，也是一个亟待解决的方面。在这些方面，一些学者已经开始了系统的研究。如Meteor-S项目中，美国的研究者利用语义网的相关知识来实现基于语义的服务组合。将非工作流属性的计算和评价作为重点考虑的内容，不以单个服务的查找和定位为目标而将服务组合列为研究的对象，从QoS属性的描述，计算，如何监控和当发生异常时的处理机制几个方面入手。建立起了一套较好的基于非功能属性的计算和监控机制，对服务组合的过程进行有效的监控和指导。澳大利亚新南威尔士大学和昆士兰大学合作的一个项目中也对如何对QoS进行建模进行了研究，建立了一个相对完整的QoS指标体系。如：服务的费用、服务的执行时间、服务的可用性、服务的信誉度等。并将该指标体系在服务组合中动态选取服务时进行验证。采用全局优化理论[44]设计选取算法来指导具体服务的选择。增强了服务组合方案的可用性。
从上述内容可知，Web服务的请求者在提出的请求中除了包含所要求实现的功能以外，经常还会伴有服务质量也就是非功能属性方面的要求。而在目前既有服务数量增长快速，服务请求者所提需求的不确定性和服务组合方案所要求的即时性这些特点存在的情况下，怎样才能使服务组合既能是一种高效率的组合，又能很好地满足服务请求者的需求，是一个值得深入研究的课题。在传统的服务发现的机制中，往往是依靠注册中心上已经注册的服务描述单元中的关键词进行匹配来做到服务发现，而这种匹配方式会因为语义上的差异导致服务查找效率和合理性都有所欠缺。因此对于服务实现组合自动化，组合合理化仅靠服务的关键词描述显然已经不能满足这一要求，而基于服务功能语义的服务查找和组合能较好地解决这一问题。为服务描述参数之间注入语义的信息，是解决服务准确查找，合理组合的一种有效的方法。除此以外，服务组合的合理性越来越显现出其重要性，一个满足所有功能要求的服务组合结果。在合理性上的表现有时还存在着这样活着那样的问题。因此，在这个方面注重服务QoS的因素，来指导服务组合中组件服务的选择，方案的优化就显得尤为重要。最后一点就是在海量服务存在时，如何更有效率的提供即满足用户功能需求，又满足用户非功能需求的服务组合方案，也是关系到Web服务组合是否能向前稳步发展的主要问题。1.2国内外研究现状1.2.1 Web服务组合语言及组合平台研究现状
将处于分布形态下的数量众多的Web服务进行有效合理的组合，切实满足请求者实际的需要，并使之能支持功能更丰富、流程更复杂的企业、商业应用，是目前Web服务领域一个重要的研究方向，而在这个方向中，服务组合发挥这至关重要的作用，没有服务的有效组合，Web服务依然停留在单个服务的发现，选择上。这将难以实现对复杂功能的实现，没有了这点，Web服务应用的前景将变得暗淡无光，SOA这种概念也终究会停留在纸上，论文中。因此，作为Web服务领域的关键一环—服务的有效合理组合就显得尤为重要。大量的研究人员对于这个问题也进行了细致的研究，并取得了相当多的成果。但对于Web服务组合的定义，目前还缺乏一个统一的表述。由于立场和视角的不同，Web服务组合的定义也有着多种表述，主要的描述方向[45][46]有以下几个：服务组合的目标、企业的功能、客户需求的满足[47][48]、任务规划业务流程等。其中，从组合目标的角度来看，Web服务组合是在特定的服务集合中寻找完成用户提出的目标为最终目的；从企业功能角度则将通过对企业间业务过程管理的共享的同时，考虑服务的数据流，以及服务的执行顺序，将Web服务组合看成是一个将分布于不同单位的基本服务组合成一个增值服务的过程；从任务规划角度则更多的是将用户需求视为一个大的目标任务，通过将这个大的任务分解成若干小的目标任务后，再分别绑定各自的服务来完成服务的组合；业务流程则偏重与将Web服务组合中的流程因素提取出来。通过流程之间来的连接性，协作性来完成服务的组合。
在本文中，对Web服务组合的理解偏重于通过Web服务组合这一手段，使在单一服务无法满足用户需求的情况下，能够使各个不同的服务单元有机的组合起来，从而实现对复杂需求的较好满足。达成业务应用支持的过程。从驱动机制和类型上可以分为即时任务求解和业务流程驱动两个大的类型。即时任务求解类型的Web服务组合，是以将用户需求任务化，以完成这一任务为最终目标，服务组合时将用户需求视为临时提交的任务，通过从已知的服务集合中自动选择能完成任务的若干服务，并将其自动组合。这类组合方法的优点在于，灵活性高，不受一些任务流程模板的约束，在完成任务以后。现有组合方案即完成了使命，对具体服务没有任何影响。因此，即时任务求解Web服务组合多用于一次性问题求解，如行程安排、用户出行设计、一次服务的联合计算等问题。该方法是综合运用了服务匹配、任务规划、逻辑推理等相关技术以将用户的任务形式化表达为目标任务为前提。高自动化的一种服务组合思路。而业务流程驱动的服务组合则是借鉴一些服务社区、服务模板里出现的机制，将工作流技术引用进来，在具体处理上以业务流程为基础，遵循流程中的步骤，每一个步骤再来临时选择和绑定对应的Web服务。最终形成一个以流程为主线的组合结果。从中可以看出，这种组合思路下的组合方法，是围绕业务流程来展开，服务组合不同服务之间的信息传递，数据流也都由流程事先决定下来。流程中的数据流决定服务之间的参数映射和参数的传递。组合方案中的具体服务也是依据流程中的步骤来临时选取和绑定。
在这些服务组合的研究思路下，各国的研究者都从不同的切入点和细分环节对这些问题进行了深入的研究。在工作流技术的引入方面，微软、BEA、IBM等提出了BPEL4WS这样的用于服务组合的描述语言，目前已经成为OASIS推荐的标准，而美国的Naml结合项目则推[50]出了名为DAML-OIL语言规范。该项目是由DAPPA资助，将Oil和[49]SHOE两者相结合而产生。利用语义对Web服务进行语义信息标注[52]方面，则主要是W3C的OWL工作组公布的OWL草案，这个草案的[51]基础是DAML-OWL。在这方面，则又分为两个研究方向，其中一个研究方向是与现有标准方向保持一致的一种改进方法，例如，IBM[54]和Georgia大学Meteor-S团队联合推出的WSDL-S参考标准，通过扩展WSDL来实现对Web服务添加语义标注，而另一个方向则表现的改[53]变的较为根本和彻底，即以DAML-S为早期版本的OWL-S。当前已经成为语义Web服务描述语言的标准。在这方面颇具代表性的还有在Hierarchical Task Network（HTN）中以任务分解的思路对用OWL-S描述的Web服务来实现服务组合的方法以及美国佐治亚大学LSDSI实验室提出的使用语义标注的流程模板来来指导进行服务组合的方法等。
在研究平台方面，早期的平台和研究思路主要是以围绕工作流方[56][55][57]法来进行，典型的有Ninja平台，E-Flow系统，Sword以及Self-[58]Serv等其中还包含由微软开发的并且已经实现了产品化的[59]Biztalkserve平台。下面对几种典型的平台做简要介绍。[60,61]
E-FLOW系统是HP公司设计的支持将各种程序部署为Web服务并支持服务的注册、查询和调用。在这个平台的设计中，还提出了SCM（Service Composition Model）服务组合模型。将服务组合抽象化为流程模型。支持以嵌套的形式表现的服务组合形式。并且在此基础之上提出了CSDL（Compostion Service Deseription Language），用来定义服务组合。该系统最主要的特点是使提高了服务组合中应对业务变化的能力。实现了柔性的工作流程安排。
另外一个典型的系统为美国佐治亚大学LSDIS实验室的[62,63]METEOR-S项目。这个项目研究的平台以两大模块为基础，分别针对服务发现和服务组合提出了两个框架性的结构[64]MWSDI（METEOR-S Webservice Discovery Infrastructure）和MWSCF（METEOR-Web service composition framework），并在MWSDI中提出了WSDL-S语言，在MWSCF中提出了SWP（Semantic web process）的概念，通过运用WSDL-S语言使常规的Web服务的语义信息在服务功能、服务的接口参数以及服务的QoS属性上得到了表达，而自SWP中，则通过定义使用抽象流程和可执行流程将服务流程分成了两个不同的层次，在抽象流程中进一步使用模板和服务接口对要完成的目标服务进行了描述，通过该方法实现服务和流程之间的一种动态绑定的机制。在MWSCF中则主要通过利用语义网中的本体推理性来实现服务的匹配。然后再利用服务QoS属性来对选定的服务进行筛选，从而实现快速准确的服务组合。[65-67]
Self-Serv是一个支持对Web服务组合进行快速开发和执行的系统平台，在该平台中，提出了服务按照粒度来分类的思想，其中社区服务的概念在这个平台中首次提出，社区服务不是一个特定具体的服务，在服务组合中，可以由用户进行指定，因此该平台有较好的灵活性，并对服务组合的动态性有较好的支持。与前面两种平台不同的是，Self-Serv平台借鉴了P2P的思想，服务之间是以一种直接通讯的方式来进行交互。这种方式的好处是可以避免中央引擎堵塞引起的瓶颈效应。
另外值得一提的是FLAME系统，该系统是面向2008北京奥运的服务中间件平台，其目的是通过建立即时的服务组合支撑环境，使用户能自主的对各种服务资源实现自我配置。从而较好地满足不同用户[68]的个性化需求，在FLAME平台中，为了使用户的需求最终转化为[69]业务层所能理解的逻辑。提出了CAFISE服务组合模型和用于描述[70]服务的服务组合语言VINCA。在这个平台中，有一个非常重要的思想就是根据不同的领域建立语义本体形成了不同的服务社区。从效率上和准确性上较好地支持了服务在语义上的查询和注册。1.2.2 Web服务组合方法的研究现状
由于服务有效组合问题在系统中的关键作用，因此对于它的研究吸引了学术界和工业界的广泛关注，由于所采用的标准不同，因此目前对于服务组合的方法分类也表现的差异较大，常见的几种分类方法包括：按服务组合的具体应用技术领域分类，服务组合的自动化程度的高低来进行分类，按服务组合所面对的待解决的问题本身的类型来进行分类。其中按问题本身的类型分类最为复杂。又分为需求驱动的[71][72-74]即时任务求解类型和业务流程驱动的服务组合，在本文前面部分已经对即时任务的求解问题进行了阐述，对于此类问题的具体解决方法包含了图搜索和AI理论两方面知识的运用。在按服务组合所应用的技术领域分类中，工作流和人工智能是两种不同的解决思路。而在按服务组合的自动化程度高低的分类中，则进一步分为，人工操作、系统半自动、系统全自动三个自动化程度来进行分类。
文献[75]以及文献[76]都是采用的基于人工智能对服务组合进行规划的技术，但在这个领域，实现Web服务自动组合还存在着许多方面的问题。在现在的方法中，大多数都是考虑服务组合的最后结果。是以服务是否能正确组合为衡量标准。至于算法的复杂度，在实际中的可用性以及对服务使用者的习惯、偏好这些因素考虑的并不多。而这些因素从某种意义上来说会影响这类方法的具体使用效果。另外和AI理论的运用一样常见的还有图论知识的应用，具体表现的形式往往是将不同的Web服务映射为图中的不同节点，节点间联系的边则是以服务间的语义关系为依据，通过运用语义网本体论中的语义相似度计算确定不同边对应的权值。而整个图的输入点为用户输入的服务请求初始信息，图的终点为用户输入的服务目标信息。在这样的图中使得服务组合问题最终演化为图的路径搜索问题。在文献[78]提出的组合系统中，提出了在服务的input, output参数间利用哈希表进行映射然后利用后向搜索来确定构成服务组合的具体服务。在文献[79]中，提出了根据服务组合的任务分支和具体服务的接口参数数目的启发式方法来确定服务组合方案，而在文献[77]中，提出了通过建立Web Services Index来实现服务的匹配。文献[80]提出了利用服务的接口参数作为服务匹配的依据的方法，文献[81]中则是由李曼等提出的利用组合图的概念来确定服务的组合结果，文献[82]则是在基于事先存在一个服务图的基础上，通过概念集合间的语义相似度，来选择用来替换服务类的具体服务。文献[83]提出了服务关联度和服务满意度这两个概念，并将这两个指标的控制阈值根据用户的反馈来确定。从而从质量和服务组合的时间上对服务组合进行控制。文献[84]的基本思路是利用本体论中本体的概念之间存在的内在关系。设定服务接口参数信息的语义关联，使不同的服务在语义层面形成一个语义联系图。然后采用和文献[78]所提及的方法一样，在图上采用前向搜索的方法寻找起点到终点的最短路径，得出服务的组合方案。文献[85]则是利用服务请求的input、output信息构造完备生成树，最后将树转化为服务组合的具体流程，再对流程中的各个步骤实现服务的动态绑定来形成最终的服务组合方案。文献[86]则是将语义Web同图搜索的理论结合起来，基本上是前述几种方法的一种综合应用。在文献[87]和文献[88]中则是通过分析服务之间存在的依赖关系，建立起服务之间的依赖关系图。图中的节点以服务的接口参数为依据，节点之间的边则以服务之间的交互来定义，通过对图的转化最终求得服务组合方案。
在上述文献提及的若干方法中可以看出。将服务的接口参数考虑成服务关系图中的顶点，然后利用参数间的各种关系，有的是语义关系，有的则为依赖关系。构造节点之间的联系边，然后将图像服务组合流程进行转换，或者搜寻图中的最短路径。大部分解决的是快速即时解决组合方案问题。但在这样的一些方案中，对服务节点具体服务的选择缺乏一种筛选机制，对于服务较为简单的情况下尚能适用，对于复杂服务则显得有些力不从心。服务参数在语义上的匹配也存在着匹配精度不够的问题。因此在加强匹配准确度，确保组合流程有效，服务选择正确等若干方面还有大量的工作要做。1.2.3 Web服务QoS的研究现状
由于相似功能的Web服务存在，在进行服务组合时，不可避免会碰上在众多服务中选取出更适合的Web服务的问题。除了在服务的功能属性上可以进行相似度匹配，更多的时候需要依靠服务的非功能属性来进行选择，服务的非功能属性则通常由QoS属性来表达。因此对于Web服务QoS的研究也成为Web服务研究领域的一个重要分支。其主要的研究内容包括：基于Web服务QoS属性的选择方法、QoS属性评估值计算方法、QoS属性的表示模型几个方面
在服务请求者提出服务请求后，服务就进入了一个相对来说自动处理的流程，首先去查找服务，然后选择服务，按完成用户的请求来对相关的服务进行组合，这个过程对于服务请求者来说是不可见的，对于请求者来说，只关心自己的请求是否能被较好的完成，所提供的服务从功能到服务质量上是否都能达到自己所希望的标准。在现实中，这种希望更多的是由服务的非功能属性来体现出来，比如在都能完成请求者功能的服务中，哪种服务是可靠性更高，可用性最好的服务。而且对于不同的服务请求者来说，所关注的侧重点也会不同。因此在利用服务的QoS对服务组合进行控制的时候，要考虑不同请求者所关注的不同侧重点。目前在利用服务QoS对服务进行选择方面，通常的[89]做法就是对服务的QoS值做服务评估值的计算，通过计算出来的评估值来确定不同服务的优劣程度，整个过程是一个按某种既定的算法进行运算的过程，缺乏一个对服务请求者的偏好或者个人需求考虑的[90]环节。在文献提出的算法中在这方面做了适当的考虑，在计算过程中纳入了对服务请求者偏好的考虑，将服务请求者提出的一些限制因素在进行QoS属性值计算的时候予以考虑，在提出的限制因素的限[93]制值范围内计算Web服务的QoS值，文献则是引入了遗传算法来作为服务选择的算法，将QoS指标序列化为基因，利用全局策略对服务[91,92]的QoS指标进行计算选择相应的Web服务。与此类似，在文献中则是利用局部策略对Web服务的QoS属性进行计算，这两种基于不同策略计算QoS属性各有优缺点，局部策略的运算量小于全局策略，但表现出来的缺点是，局部策略适合选取单独功能节点上的最优服务，但在实现全局约束上显得乏策。因此在相关研究中，基于全局策略的QoS属性计算来进行服务选择占的比例偏大。通常的做法是将服务请求者提出的QoS需求分析提取转化成一种基于全局的QoS限制。其基本的出发点就是考虑到由于Web服务数量上日益增多。因此构成能满足服务者请求的组合方案往往也不是单一的，针对不同的组合方案，功能相同，但QoS属性不同，利用这个特点，根据服务组合方案的QoS属性从中选取在全局属性指标达到要求的服务组合方案就成了一个可行之道。从这个角度来看Web服务组合中的QoS所扮演的角色显[94,95]然非常重要。本文正是基于此点，在服务组合中考虑用户的需求，以服务的QoS属性上表现出来的限制为Web服务选择的依据。从而实现根据用户需求的不同，提供不同的服务组合方案这一目标。只有能做到随需而变的服务提供，才有可能使以Web服务为基础应用得到更好的发展。也正是因为这样，Web服务QoS的研究逐渐成为该领域的[96,97-104]重要分支。对于基于用户需求QoS限制的服务选择问题可以总结为具有以下这些特点：（1）选择条件的单一性：以服务组合过程中获取的用户需求QoS限制为选择条件。（2）QoS属性计算的可扩展性：QoS属性计算由常规属性和领域QoS属性共同构成，领域QoS又由用户的需求决定，因此随着用户需求的不同，参与计算的QoS的属性也会不同。计算复杂度也会不同。（3）QoS属性的不确定性：对于服务的QoS属性包含的内容没有一个确定的规范，在服务请求者提交服务请求时，对选择的QoS属性也存在一个不确定性的问题。（4）动态的计算环境：Web服务是处在一个服务组合的各个参与方动态参与的环境中，无论是服务请求者，服务提供者从某种程度上来看都具有明显的动态性的特征。
在基于用户需求QoS限制的服务选择问题方面目前存在着两个研究思路：其一是将语义网的相关技术引入进来，实现QoS语义化[97-100]，另一类就是运用全局策略，计算QoS的属性评估值来对服务[96,101-104]进行选择1.2.4 QoS的语义模型
目前语义Web服务中，对于服务QoS的语义模型研究也较多。为了达到对Web服务做到QoS属性敏感的，服务组合结果有效的，并能适应动态的组合环境，文献[97]引入了一个基于QoS语义表达的WS-QoS模型，在这个模型中，分别包含几个执行不同功能的功能组件，主要是：需求管理器、Web服务代理，属性编辑器。该模型通过需求管理器对用户的服务需求进行获取，通过编辑器对其进行属性上的编辑，然后通过服务代理将用户需求中的QoS同编辑好的QoS进行匹配，选择出满足QoS需求的具体服务实例。在这个模型中建立了一个Web服务QoS属性本体，并在DAML的基础上建立了一种新的查询和操作QoS本体的语言。文献[99]中提及的方法同这种有些类似，通过建立DAML-QoS本体为原有的DAML-S本体提供了补充，强化了对服务组合中QoS的语义表达，在补充的这个QoS本体中，采用了分层结构来表示本体中不同层次的含义，分别是QoS属性定义层、QoS属性度量层、QoS配置层。文献[100]中采用的办法更偏向对服务的动态选择能力，基于这点，设计了一种智能代理的机制，提出了一个支持服务动态选择的智能代理框架（WSAF），在该框架中，也采用QoS本体来表述服务选择的依据，该本体在服务请求方，服务提供方，智能代理三方面都起着不同的作用，服务请求方使用该本体来描述具体的服务请求，服务提供方使用它来对提供的服务进行描述，而智能代理方用该本体来确定服务请求方的QoS需求。从这些已有的方法来看，我们可以看出，采用对Web服务的QoS指标语义化的方法属于局部策略的一种具体方法，在对单个服务进行服务选择时能起到较好的作用，但在要求对全局性的QoS属性限制目标达成时，由于自身的局限性，很难做到这一点。因此如果要想采用全局策略则要采用其他的技术路线来实现。1.2.5 QoS属性的计算方法
全局策略的QoS属性限制考虑，是以服务组合的全局QoS属性指标为限制因素，因此这类型的优化方法和前面提及的QoS属性语义化有较大的区别。最终的结果是对若干候选的服务组合方案进行按某种规则的统一计算，比较之间的计算值，选取计算值较优的服务组合方[101-103]案。具体的算法包含两类，其一是穷尽算法，其二是近似算法[97,104]。而在这两类算法中的一个共同之处就是建立QoS属性矩阵，假设存在一组N个具有相同功能属性的Web服务集合S（S={Sl, S2, …, Sn}），存在M个QoS属性需要被限制，这样，当存在N个Web服务与M个QoS属性时，矩阵大小为N*M。这样的QoS属性矩阵Q矩阵如下所示，矩阵每行代表Web服务S;，每列代表QoS属性，基于用户提出的QoS限制，Web服务计算算法将决定哪个服务Si被选上。
在矩阵建立起来以后，就是按QoS属性值的规格化方法对矩阵中的具体值进行规格化计算，为后面的综合QoS值计算奠定基础。在算出各个Web服务的综合QoS值后，根据这个计算值对各个Web服务排序。该方法虽然可以选出相对较好的Web服务，但从QoS属性矩阵构成来看，当Web服务数量或QoS属性数量较大时，矩阵会响应的变得庞大，计算量也会随之增大很多，另外，它虽然可以选出单个相对较好的Web服务，但依然无法满足用户对整个Web组合服务的QoS要求，所以从本质上来看，它依然只是个局部优化算法，而不是基于全[102,103]局策略的全局优化算法。文献中阐述了基于全局策略的和局部策略的优化算法，并对它们各自适用的场景进行了论证。提出了通过引入MCDM（Multiple criteria decision making）来简化QoS计算，从[103]而达到降低计算量的目的。文献则通过转化QoS的计算方式，引入状态图，将QoS计算同路径计算联系起来，并通过使用整数规划IP（Integer programming）来实现QoS值的全局优化的计算策略。全局策略的优点在于能够求得基于全局的最优解，实现全局QoS限制的服务组合方案的选择，但同样存在计算量大的弊端，因此无论是局部还是全局策略。计算量过大都是它们共同的弊端。
综上所述，在目前的利用QoS的属性值来选择具体的Web服务的方法中，有几个明显的缺陷：服务的选择结果的有效性和合理性欠缺，服务请求者的参与较少，在计算效率上和优化计算存在较明显的冲突。因此，如何高效的选择出高质量的Web服务是一个亟待解决的问题。1.2.6 基于云计算技术的Web服务管理
随着互联网上Web服务的数量和种类的与日俱增，其信息量也随即增加。因此，增加了对web服务的QoS信息以及web服务其他信息进行管理的负担，而且对这些信息的提取和挖掘等操作都将会给服务器带来很大的负载开销。人们当然希望能有是够大的web服务管理库能支持用户的快速检索和查询。而由于Web服务的描述信息属于松散结构，如不同领域的Web服务其功能描述各种各样且QoS所包含的指标数量也不一样，所以，传统的数据库无法高效地对其进行管理。针对这些情况，现有的研究对如何将其同云计算技术相结合做了初步的尝试。部分学者提出了一种基于云计算的Web服务管理平台。在该管理平台中，云计算环境是由Hadoop提供，HDFS作为整个平台的根基用于支撑上层结构。在上层结构中，HBase主要是用作管理Web服务中的功能和非功能信息。另外，为了提升HBase中QoS获取的效率，HBase同时也保存了前面所提出QoS-Tree作为索引机制。除了HBase的信息管理，为支撑QoS的存取，预测等操作，提出了基于MapReduce的QoSETL，数据挖掘以及统计分析算法。最后，为了满足服务选择的需求，运用MapReduce机制用于搜索所有可能的路径，并帮助用户找出最优解。基于云计算的Web服务管理框架如下所述。
基于云计算的Web服务的管理框架分为四个部分，从上往下分别是：应用层、核心层、注册层和管理层。其结构如下：
应用层：该层以三种方式提供给用户，包括：基于Web浏览方式，基于Web服务的调用和基于API方式的调用。这些接口主要是用于展示Web服务的描述信息，方便用户进行Web服务的发现或选择操作。
核心层：该层的主要目的除了帮助用户选择出一个满足需求的最优方案，还包括用于Web服务的QoS提取的ETL算法，可信推荐的统计分析算法和Web服务相似性的聚类以及匹配关系获取的关联规则算法。该层的算法是基于MapReduce实现的并行计算。
注册层：该层除了维护用WSDL描述的Web服务信息，还维护了Web服务的索引信息，包括支持语义的功能属性索引结构的本体树以及用于非功能属性索引的QoS-Tree。由于HBase表是疏松的存储的，一个数据行拥有一个可选择的键和任意数量的列。因此，很适合于管理这些松散的数据。
管理层：该层主要是由HDFS构成，由于分布式环境的高扩展性和可靠性，它能为Web服务的执行提供保证。除了提供Web服务的部署，同时还包括相关的算法的部属以及处理过程中产生的数据和元数据信息的管理。图1-3 基于云计算的Web服务管理框架1.2.7 目前研究存在的问题
虽然近些年对基于语义的Web服务发现的研究取得了丰硕的成果，但距离语义Web服务的目标——计算机能根据服务的语义自动地、智能地进行服务发现、组合和处理，存在一定的差距，还有很多值得进一步研究的问题。（1）基于语义的服务描述虽然基于语义的服务描述语言已被几大组织提出和推荐，并且具有较强的描述能力，但是如何利用这些描述语言对某一具体工程领域的服务进行语义描述还有待进一步研究。其难点一是既要考虑服务描述的能力，又要考虑服务描述的复杂度，更要考虑实际工程服务描述的要求和特点；二是如何检验和评估服务描述的好坏。（2）基于语义的服务匹配在单服务匹配中，虽然已提出了很多方法，但存在匹配复杂度高、相似度函数较难确定等问题。因此，如何对服务本体逻辑推理进行改进，在服务的匹配精度和匹配复杂度之间进行折中；如何定义一个更准确描述语义本体之间相似度的函数；如何评价和比较各种不同相似度函数的性能；如何对单服务匹配算法进行改进，以提高服务匹配的速度，虽然目前大量的语义Web服务匹配算法被提出，但还存在很多问题值得进一步研究：①匹配时间复杂度以及服务的查全率和查准率是衡量服务匹配算法的三个重要指标。但是这三个指标是互相制约的，很难同时达到最优。因此，如何根据实际应用的需求对这三个指标进行很好的折中是当前研究的一个难点；②由于影响概念间相似度计算的因素有很多，如概念在本体中的深度、概念间的密度和距离等。因此，很难提出一个相似度计算函数适合所有不同的应用场景和需求；同时，如何评价一个相似度计算函数的优劣也是当前研究的一个难点；③语义Web服务匹配算法不仅仅需要考虑服务之间的参数匹配，还要考虑服务执行时间以及服务费用等非功能属性匹配。因此，合理地结合功能性匹配算法和非功能性匹配算法以提高服务匹配算法的精度和效率是当前研究的一个热点在服务组合匹配中，Bottom-up组合匹配是一种服务的自动组合方式，更能满足人们的需求，但目前Bottom-up组合匹配方法的服务组合能力比较弱，并且只能支持简单的串行或者并行组合。因此，如何支持更加灵活、多样的服务组合结构，如何更加准确地描述服务之间的关系，以提高服务匹配的准确度，如何提高Bottom-up组合匹配的性能，使组合的服务更加符合用户的需求等问题还需要研究。Bottom-up组合匹配适合于服务挖掘，如何更加有效进行服务挖掘和评估还有待研究，同时，将服务挖掘与Top-down服务组合匹配相结合可以提高服务组合匹配的性能，具有较大的研究意义和前景，但是如何很好地结合将有待进一步的研究。虽然服务组合的理论研究比较多，方法也相对成熟，但服务组合在实际工程中实现还存在很多问题，还值得研究，如语义Web服务组合中的复合语义、事务处理、复杂服务质量模型以及服务组合当中的安全问题；如怎样实现服务的自动组合并满足用户的服务需求，怎样自动发现服务等。
试读结束[说明：试读内容隐藏了图片]