CN100383731C - 一个Web Services的实时、动态合成方法 - Google Patents

Abstract

本发明是一种Web Services的实时、动态合成方法。包括：Web ServiceS产生式建模、参数级本体构造、无回溯反向链合成算法和基于SLA的最优合成算法。合成的流程为：首先根据Web Services的WSDL文件进行产生式建模，并由模型来构造一个参数级本体，用于消除参数之间的语义冲突；然后根据用户给定的输入和所期望的输出，利用无回塑反向链合成算法找出一个合成方案，或者根据用户的SLA要求找出最优的合成方案；最后把生成的合成方案转换为BPEL4WS代码，调用BPEL引擎执行并返回结果给用户。本发明只需用户要给出一定的输入和所期望的输出，就可实时、动态地在现有的Web Services基础上合成一个新的Web Service，来完成所要求的查询。

Description

一个Web Services的实时、动态合成方法

技术领域

本发明属于Web Services技术领域，具体涉及到Web Services的一种实时、动态合成方法。利用该合成方法，用户只要给定的输入和所期望的输出，就可自动合成一个合成方案，或者可以根据用户给定的SLA(Service Level Agreement)来合成一个最佳的WebService，并转换为可执行的BPEL4WS(Business Process Execution Language for WebService)代码，然后由BPEL4WS引擎来执行并返回用户所需要的输出。

背景技术

Web Services是当今的研究热点之一，也是一项发展前景颇为看好的重要技术，它作为一套技术标准，定义了应用程序如何在Web上实现互操作性，是建立可互操作的分布式应用程序的新平台。人们可以用任何所喜欢的语言，在不同的平台中编写Web Services，然后通过Web Services的标准来对这些服务进行查询和访问。利用Web Services，能够创建出可供任何人从任何地方使用的、功能强大的应用程序，极大地拓展了应用程序的功能，实现了软件的动态提供。

Web Services是一种部署在Web上的对象，因此具有对象技术所承诺的所有优点；同时，Web Services的基石是以XML(Extensible Markup Language)为主的、开放的Web规范技术，具有比任何现有的对象技术更好的开放性。

我们看到各大技术提供商陆续地推出Web Services的构建工具，比如：Microsoft的Visual Studio.NET；IBM的Web Service Toolkit；SUN的Sun ONE等等。基于Web Service的公共技术标准SOAP/WSDL/UDDI/WSFL或是已经成为事实行业标准，或是正在制订的进程中，各大技术提供商和传统商业企业都投入到了标准的制定和应用的架构中去。作为Web Services的体系架构的领导者IBM和Microsoft也开始在全球推广Web Services技术。我们有理由相信Web Services将成为将来动态商务Web的主流技术。

虽然Web Services给应用程序的集成带来了方便，但是单个Web service提供的功能有限，不能满足实际应用的需要。要想仅仅通过单一的、简单Web Services的交互来实现真正跨企业边界的应用集成是显然不够的，因为每一个Web service都具有一定的片面性，没有也不可能有一个能满足各种查询需要的Web service；而如果针对所有的查询都专门开发一个与之对应的Web Services是代价很高的，也是不现实的。因此，有时为了完成某个查询，需要对现有的Web Services进行合成。只有对现有的单个Web Services进行合成，从而形成新的Web Services以提供更多功能的时候，Web Scrvices的真正潜力才算发挥出来，这对于提高应用程序的集成，增加Web Services的重用度，以支持应用过程中的长时间交互，减少Web Services的开发数量具有重要的意义。

Web Services本身具有严格自治性、松散耦合和协议规范性等特点，而合成的WebServices又要求具有灵活性、可重用性等，所以Web Services合成的研究工作带来了许多新的挑战。对Web Services合成的研究，目前已提出了许多方法，这些方法大体上可以分成两大类：基于工作流的合成和基于语义的合成。

基于工作流的Web Services合成是通过定义一个Web Services的执行流程来实现的，在流程中详细指明了Web Services之间的控制流和数据流。IBM和微软2002年联合发布的BPEL4WS结合了WSFL(Web Services Flow Language)面向图形和XLANG结构化的特点，因此它允许一个流程模型中可以进行“结构化块”和“结构化图形”混合描述，虽然复杂度增加了，但是其表述能力也大大加强了。BPEL4WS的模型和它的XML语法定义了企业中流程之间以及与合作伙伴之间使用Web Services进行交互的情况。同时，BPEL4WS也定义了这些交互之间的状态、协调逻辑以及在碰到异常情况下系统的处理方式。商业交互协议被称之为抽象流程，它指定了不同参与者之间的公共、可视的消息交换情况，但是并不关心所涉及的参与者的内部行为和实现情况。另一方面，这个可执行的流程类似使用基本的和结构化的活动的工作流描述，这些活动指明了Web Services的执行模式。BPEL4WS定义的流程模型是基于WSDL(Web Service Description Language)的，流程中的基本的调用和响应活动是利用它们的WSDL描述来表示的。

除BPEL4WS外，其它如WSCI(Web Services Choreography Interface)、ebXML、BPML(Business Process Modeling Language)、XPDL(XML Process Definition Language)、WSMF(Web Services Modeling Framework)等也都是近年来新提出面向工作流的合成标准。利用这些标准虽然能够较方便地定义企业内部、企业之间的业务流程是如何相互协作的，但是这些流程需要用户手工来明确定义，自动化程度不高，也没有解决合成过程中的语义问题。

DAML-S是从语义Web上发展起来的一种比较典型的基语义的Web Services合成方法，它是一种由DARPA(Defense Advanced Research Projects Agency)资助的由多家研究机构共同创建的用于描述Web Services的DAML+OIL本体语言。在DAML-S的官方网站是这样描述DAML-S的：DAML-S为Web Services供应商提供了一套核心的标记语言集，使之可以以一种明确的、计算机能够解释执行的方式来描述Web Services的属性和功能。DAML-S是在若干Web Services工业标准之上开发的，同时加入了丰富的类型和类信息，可以使用这些信息来描述和限制Web服务。而且它采用一种获取Web服务的控制流和数据流的处理模型，集成了更多的类表示。这样的语言能够把Web Services聚合成分类的层次结构，并且还带有类以及类实例之间关系和限制的丰富定义。这种定义良好的语义信息通过现有的功能强大的推理技术，就能实现对这些结构的自动操作。简而言之，DAML-S使语义Web Services的自动交互成为可能。设计DAML-S是针对语义Web Services自动执行的任务，包括自动发现、自动调用、自动交互、自动集成、自动执行监控与恢复、自动模拟和验证。

DAML-S主要由三部分组成：

Service Profile：描述“What the services does”，指明所描述的Web Services的功能与接口，以便于服务代理能够搜索与匹配该Web Services；

Service Model：描述“how the services works”，指明当服务被调用时的操作，以便服务代理进一步匹配，以及服务合成和服务的协调工作和监控；

Service Grounding：指定调用服务的具体细节，比如通信协议，调用端口等。

DAML-S是利用DAML+OIL本体来对Web Services的属性和函数进行的语义描述，并通过预先定义的处理过程来实现自动合成。DAML-S虽然能利用对象和对象之间的复杂联系来定义Web Services之间的关系和约束，提供了一种比WSDL支持更多特征的语言，在一定程度上解决了合成中的语义问题，但是它所描述的概念模型之间的联系不是很清晰，模型参数会出现多态现象，而且映射到WSDL上时限制了DAML-S本身具有的丰富表达性特点；另外，DAML-S的支持工具有限，学习起来也比较困难。

Thakkar等提出了一种基于Mediator的Web Services的AI(Artificial Intelligence)合成方法，该合成方法首先用属性绑定形式对Web Services进行统一建模，并通过属性级本体来描述这些属性之间关系，以解决合成过程中的语义问题，然后在Mediator中使用一个前向链算法来自动生成一个合成方案并进行优化，最后由一个执行引擎来执行该合成方案。但是他并没有对该方法给出一个明确的合成框架，而且当Web Services数量很大的时候，需要对合成方案进行优化，尤其是当需要进行多次合成时，而且前向链算法存在着回溯问题，总体效率并不高。另外，该合成方法也不能找出所有的合成方案，没有办法找出服务质量最优的合成方案。

发明内容

本发明的目的在于提出一种新的Web Services实时、动态合成方法，使得用户只需要给定输入和所期望的输出，系统就可以实时、动态地生成一个Web Service合成方案来完成用户给定的查询任务，以减少合成过程中的人工干预程度，增加在线Web Services的数量，满足实际应用中的需要。

下面先介绍一些相关的基本概念。

Web Service是一种部署在Web上的、自包含的、模块化的应用程序，它可以在网络中被描述、发布、查找以及调用。Web Services具有对象技术所承诺的所有优点；同时，Web Services的基石是以XML为主的、开放的Web规范技术，因此具有比任何现有的对象技术更好的开放性，是建立可互操作的分布式应用程序的新平台。

Web Services合成就是将多个自治的Web Services根据应用需要，通过服务查找以及服务之间的接口集成来提供新的、功能更强的Web Services，或者说提供一些value-added的Web Services。一个合成的Web Services是一些独立的、相互交互的Web Services的聚集，并把它所聚集的Web Services作为自己的组件来看待，从而获得比原先Web Services具有更新的功能。从“粒度”意义上讲，Web Services合成是对Web Services进行更大部分的封装并把该封装后作为一个Web Service暴露给外界；而从“顺序”意义上讲，合成是定义一系列Web Services的调用顺序。

从Web Services合成过程来看，Web Services可以分为基本服务(elementary service)和合成服务(composite service)。基本服务是指事先已经存在、开发好的服务，对于其它服务或者用户来说，它是透明的；而合成服务是指对一些其它服务(可能是基本服务，也可能是合成服务)的合成，并以一个接口的形式提供给用户或者其它服务使用。Web Services的合成方法从技术上大体可以分为静态合成和动态合成两种。静态合成是在开发设计过程中就决定了Web Services之间的控制流和数据流是如何进行的；而动态合成是在系统运行过程中进行的，它们之间的控制流和数据流是自动产生的。采用静态合成还是动态合成可根据Web Services的特点和用户需要决定，如果合成的Web Services之间的内在关系比较固定，则采用静态合成；如果合成的Web Services需要经常根据环境进行动态调整，则采用动态合成技术。动态合成以静态合成为基础，而且其难度要大于静态合成。

本发明提出的Web Services实时、动态合成方法，有一个Web Services的实时、动态合成框架，该框架包括Web Services建模、参数级本体构造、无回溯反向链合成算法和基于SLA的最优合成算法；框架中还具有建模工具、本体构造工具、模型库和本体库，具体步骤为：首先根据Web Services的WSDL文件进行产生式建模，并由模型来构造一个参数级本体，用于消除参数之间的语义冲突；然后再根据用户给定的输入和所期望的输出，利用无回塑反向链合成算法来找出一个合成方案，或者根据用户的SLA要求来找出最优的合成方案；最后可把生成的合成方案转换为BPEL4WS代码，调用BPEL引擎执行并返回结果给用户。

下面对各步骤作进一步描述：

(1)Web Services建模：

建模(见图2)是利用一个建模引擎来进行的。通过导入Web Services的WSDL描述文件给建模引擎生成头部只有单项的产生式作为模型，并在产生式上附加一些其它的WebServices的描述信息(在从合成方案向BPEL4WS转换过程中，这些附加信息有助于转换算法的自动进行)，然后把模型存放在一个Web Services模型库中(对应图1中的流程①)。

(2)参数级本体构造：

本体构造(见图2)是利用模型库中的Web Services模型，根据模型的语义和领域情况，利用本体构造工具来构造一个参数级(指Web Services的输入和输出参数)本体，来解决合成过程中可能存在的语义冲突问题。也就是说在本体中定义领域术语、Web Services输入输出参数之间的语义关系，包括同名异义和异名同义等(对应图1中的流程②)。具体来说，该参数级本体共分为两层，上层为领域内术语，下层为Web Services的输入、输出参数，并通过实线和虚线来关联那些同名异义和异名同义的参数或者术语，消除合成过程中可能出现的语义冲突。

(3)合成：

合成包括两类算法：无回溯反向链合成算法和基于SLA的优化合成算法。其中，无回溯反向链合成算法(见图3)是首先根据用户给出的输入、已经生成的模型库和语义本体库来计算一个输入闭包(输入闭包也就是用户输入在模型库中所能推出的所有可能输出)，并把该输入闭包存放在一个合成缓冲区中以用于下次合成(只要用户输入和Web Services模型不变，那么该输入闭包可以被利用多次)；然后通过反向推导来找出合成中要用到的所有Web Services(对应图1中的流程③)。

基于SLA的最优合成算法(见图4)，首先根据用户输入和现有的Web Services模型计算一个推导网络，再按照用户所期望的输出、利用推导网络来求出各种可能的合成方案，并可依照用户的SLA要求选择一条最优的合成方案(对应图1中的流程③)。

(4)BPEL4WS代码生成与执行：

BPEL4WS代码生成与执行(见图5)是根据上述合成算法得到的合成方案，参考WebServices模型库的信息，可以自动把合成方案转换为BPEl4WS代码，并调用引擎来执行，返回用户所期望的输出结果(对应图1中的流程④)。

附图说明

图1为Web Services实时、动态合成方法总体框架图示。

图2为Web Services建模与本体构造。

图3为无回溯反向链合成算法。

图4为基于SLA的最优合成算法。

图5为BPEL4WS代码的转换与执行。

图6为给定3个输入{A，B，D}，输出{E，F}的查询方案图示。其中，(a)为方案(1)，(b)为方案(2)，(c)为方案(3)。

图7为4种推导关系图示。其中，(a)为”∧”关系，(b)为”∨”关系，(c)为”→”关系，(d)”＝＞”关系。

图8为给{A，B，D}的推导网络图示。

图9为本发明的合成流程图示。

图中标号：1为Web Services，2为Web Services模型库，3为语义本体库，4为用户，5为合成方案，6为BPEL4WS代码，7为Web Services输入和输出。①为Web Services建模，②为本体构造，③为合成算法，④为BPEL4WS代码转换和执行。

具体实施方式

本发明的具体实施步骤如下：

(1)首先利用protege建模工具进行建模。输入的是Web Services的WSDL文档，输出的是Web Services模型。

(2)利用本体构造工具构造一个参数级本体，用来消除合成中可能出现的语义冲突。输入的是模型库，输出的是一个参数级本体库。

(3)根据用户的输入、模型库和参数级本体，计算一个输入闭包，并把该闭包放入一个合成缓冲区中，以防止逆向推导时产生回溯，并加快合成速度。

(4)根据用户的输入和所期望的输出，利用无回溯反向链合成算法来找出一条合成方案。使得通过该合成方案中，可以从用户给定的输入中，得到用户所需要的输出。

(5)根据用户的输入和期望的输出，可以事先计算一个推导网络。在该推导网络的基础上，利用基于SLA的最优合成算法来找出所有合成方案，并从中选择一条SLA最优合成方案。

(6)两个合成算法所生成的合成方案都可以自动转换为可执行的BPEL4WS代码，并调用BPEL4WS引擎来执行，返回执行结果。

下面结合两个例子来详细介绍整个合成方法。

实施例1说明无回溯反向链合成方法的详细过程，该例子中只找出一条合成方案，并没有找出所有的合成方案；

实施例2描述了基于SLA的最优合成方法的详细过程。首先找出所有的合成方案，然后根据用户的SLA要求选择一条最佳的合成方案。

实施例1

在股票行业中，用户想通过一个“跨国公司名字”和“某一特定时刻”，找出该公司在某一股市(比如：纽约股市、伦敦股市)的股票折合成人民币后的价格以及该公司所在国家名称和国家其它信息。不妨假定有以下几个Web Services：

①Country(CountryCodeⁱ，CountryName^o，Info^o)

②UStoRMB(USpriceⁱ，Datetimeⁱ，RMBprice^o)

③UKtoRMB(UKpriceⁱ，GivenDatetimeⁱ，RMBprice^o)

④NewYorkStock(CompanyIDⁱ，SomeDatetieⁱ，USprice^o)

⑤YellowPages(CompanyNameⁱ，CompanyID^o，Address^o，CountryID^o，Phone^o，Info^o)

我们可把Web Services写成带有绑定模式的谓词形式，谓词中的属性的上标i表示的是Web Services的输入参数，上标o表示该Web Services的输出结果项。例如，Country服务要求输入一个“国家编码”，返回“国家名称”和“国家其它信息”。UStoRMB服务要求输入“美元价格”和“日期时间”，返回对应的“人民币价格”。同样，UKtoRMB也是要求输入“英镑价格”和“给定时刻”，返回对应的“人民币价格”。NewYorkStock服务是查询某一个公司在纽约股市的股票价格，它要求输入“公司代码”和“某一日期时间”，则返回该公司在纽约的“股票价格(美元)”；最后，YellowPages是一个企业黄页服务，通过输入“公司名称”，可以获得有关企业的一些基本信息，比如：“公司代码”，“地址”，“国家代码”，“电话”和“公司其它信息”等。

利用上面的几个Web Services，用户可以进行各种查询。比如查询企业黄页，某公司的股票价格，人民币汇率等，但是上述的每一个Web service都具有一定的片面性。没有也不可能有一个能满足各种查询需要的Web service，而如果针对所有的查询都专门开发一个与之对应的Web Services是代价很高的，也不现实。因此，有时为了完成某个查询，需要对现有的基本Web Services进行合成。比如：要找出某一跨国公司在某一给定时刻在纽约股市的股票折合成人民币后的价格以及该公司所在国家名称和国家的其它信息，需要分以下几步来进行查询：

(1)根据需要，对输入分解；此例可分解为“公司名称”和“某一特定时刻”；

(2)利用YellowPages服务，输入公司名称获取公司代码和国家代码；

(3)利用NewYorkStock服务，输入公司代码和给定的时刻，获取该公司在纽约股市的股票美元价格；

(4)利用UStoRMB服务，根据给定日期把股票美元价格转换成人民币价格；

(5)利用Country服务，根据国家代码查询出该国家的名称和国家具它信息；

(6)合并股票人民币价格、国家名称和国家其它信息，返回给用户。

由此例可以看出，虽然利用现有几个的Web Services可以完成该查询任务，但是需要分多步来完成，不但查询分解以及分解后的每一步查询都要用户来进行，对查询结果的合并也要由用户自己来处理，而且其中存在的语义问题(如：NewYorkStock中的输入项“SomeDatetime”和UStoRMB中的输入项“DateTime”虽然形式不一，但实际上表示的是同一个意思)也需要用户自己解决，这是一个费时、费事的手工查询工作。因此，如果能对现有的Web Services进行自动、动态合成，就可避免繁琐的手工查询分解、查询合并和语义问题处理的工作，这对于提高应用程序的集成，增加Web Services的重用度，减少Web Services的开发数量具有重要的意义。

(1)Web Service产生式建模

产生式建模，是把一个Web Service表示为一个或者多个产生式，具体部和头部分别表示Web Service的输入和输出。由于这种建模采用产生式的形式，清晰直观地区分了输入和输出，更适合于使用人工智能的各种推理控制算法进行合成。

假定一个Web service要求m个输入：I₁，I₂，...，I_m，可产生n个输出：O₁，O₂，...，O_n，那么它就可以表示为n个产生式：

I₁&I₂&...&I_m-＞O₁

I₁&I₂&...&I_m-＞O₂

......

I₁&I₂&...&I_m-＞O_n

这样的话，前面例子中的Web Services共有10个输出项，可以表示成如下的10个产生式：

表1

产生号	产生式	Web Services号	其它信息
				(1)	CountryCode-＞CountryName	①	…
(2)	CountryCode-＞Info	①	…
				(3)	USprice & Datetime-＞RMBprice	②	…
(4)	Ukprice & GivenDatetime-＞RMBprice	③	…
				(5)	CompanyID & SomeDate Time-＞USprice	④	…
(6)	CompanyName-＞CompanyID	⑤	…
				(7)	CompanyName-＞Address	⑤	…
(8)	CompanyName-＞CountryID	⑤	…
				(9)	CompanyName-＞Phone	⑤	…
(10)	CompanyName-＞Info	⑤	…

(2)参数级本体构造

本发明采用的是一种称为参数级本体来描述模型参数之间的语义关系，参数级本体也就是根据Web Services模型的输入输出参数(即产生式的头部项和体部项)建立的本体，该本体分为两层即领域模型参数和Web Services模型参数。在下层的模型参数之中，同名异义和异名同义的参数之间分别用虚线和实线连接；另外在下层的模型参数上附加一个模型标号用于指明该参数是属于哪个模型(产生式)。这样在Web Services模型数量很多的时候，也可以很方便地通过底层参数之间的实线连接或者通过领域模型找出异名同义的参数，也可以通过底层参数的虚线连接方便地找出用同名异义的参数。也就是说，给定任何一个参数，就可以知道该参数是属于哪个Web service模型以及它在领域模型中的意义是什么。

(3)合成缓冲区

设置一个合成缓冲区，用来存放经过语义冲突处理后的Web Services模型和算法生成输入闭包。缓冲区由两个部分组成，一个是持久保存的存储区，另一个是临时内存区。每当进行一次合成，就把数据从持久存储区调入到临时内存区。Web Services模型放在合成缓冲区一方面是为了加快合成的速度，另一方面是为了不改变模型库中模型本来的形式。而输入闭包存放在合成缓冲区是为了下次合成时再次使用，以避免重新计算同样的输入闭包，提高算法的合成效率。

在算法合成开始之前，语义处理模块先利用Web Services模型描述库和本体库，把Web Services模型描述库中的某些输入项和输出项(产生式的体部项和头部项)替换为领域模型参数(领域术语)，消除同名异义、异名同义等语义问题并放入合成缓冲区后，然后再利用无回溯反向链算法进行合成。

(4)无回溯反向链算法

在一般反向链算法中，如果头部相同的产生式很多，则在算法中可能会导致大量回溯而影响算法合成的效率。为了防止产生回溯，本发明采用先根据用户的输入求出一个输入闭包，如果在反向链合成过程中碰到满足当前匹配的产生式有多个时，则选择体部包含在输入闭包中的产生式进行合成。假定I是用户输入集，s是Web Services模型输入输出参数的一个参数，我们定义I的输入闭包ε_Closure(I)为：

①若s∈I，则s∈ε_Closure(I)；

②若s∈I，s′是从s出发，利用模型可以得到的输出，那么s′∈ε_Closure(I)。

无论头部相同的产生式有多少，输入闭包最多只需计算一次，如果在合成过程中没有遇到匹配当前目标有多个产生式的情况，则不需要计算输入闭包。无回溯反向链算法的步骤是：从用户所想要得到的查询结果开始，试图找出能得到该结果所需要的所有产生式。如果和当前目标匹配的产生式有多个，则先去缓冲区查找有无对该用户输入的输入闭包，若没有则计算出输入闭包，并放入缓冲区中，然后选用产生式体部项全部包含在输入闭包中的产生式进行合成。输入闭包只需调用一次，只要用户的输入和模型描述库不变，以后的合成都可以从缓冲区中取出使用。

无回溯反向链算法最后得到的是一个扩展的DAG图，该图可以方便、自动地转换为BPE14WS代码，并调用BPEL4WS来执行。

实施例2

假定有以下6个Web Services，每一个Web Service都接受一定的输入，并产生一定的输出(这里我们假定每个Web Service只有一个操作)，而且每个Web Service具有一定的执行代价。如下表所示：

表2

Web Services序号	Web Services	执行代价(元/次)
			(1)	WS<sub>1</sub>(A<sup>i</sup>，B<sup>i</sup>，C<sup>o</sup>)	0.5
(2)	WS<sub>2</sub>(D<sup>i</sup>，C<sup>o</sup>，E<sup>o</sup>)	1.5
			(3)	WS<sub>3</sub>(D<sup>i</sup>，C<sup>i</sup>，E<sup>o</sup>)	0.7
(4)	WS<sub>4</sub>(E<sup>i</sup>，A<sup>o</sup>)	0.2
			(5)	WS<sub>5</sub>(B<sup>i</sup>，G<sup>i</sup>，D<sup>o</sup>)	1.0
(6)	WS<sub>6</sub>(B<sup>i</sup>，F<sup>o</sup>)	0.4

其中，WS₁(Aⁱ，Bⁱ，C^o)表示该Web Service要求输入两个参数’A’和’B’，输出一个’C’，它的执行代价为0.5元/次；而WS₃(Dⁱ，C^o，E^o)则意味着该Web Service输入一个参数’D’，则会返回’C’和’E’两个输出，它的执行代价为1.5元/次。其余WS_i的含义类似。

例如：“用户给定三个输入{A，B，D}，要得出一个输出{E，F}”，要完成这个查询，在现有的Web Services下，用户可有三种不同的查询方法，如图6所示：

在查询过程中，我们假定这些Web Services的输入/输出参数具有唯一性，也就是说这些参数之间不存在“同名异义”和“异名同义”的情况。上面的3个方案中，方案(1)的总执行代价最小。由此例可以看出，在完成同样任务的前提下，如何选择一条执行代价最小查询方案以满足用户实际需要也具有重要的意义。

为了找出所有的合成方案，并根据需要从中选择一个优化的合成方案，本发明事先计算一个推导网络，该推导网络中存放了各种可能合成方案。在计算推导网络之前，首先也要进行建模和参数级本体的构造，以消除合成过程中的语义冲突。在建模过程中，需要把Web Services的执行代价等SLA信息附加到模型中去(下表所示)，以便在以后的步骤作为选择合成方案的依据。

表3

一个给定“输入集合”在某个“规则库(模型库)”中的推导网络实际上是该“输入集合”在该“规则库(模型库)”中推导过程的一个闭包，也就是该“输入集合”的所有可能推导的一个集合。与一般的其它网络不同，推导网络中允许存在回路，并且允许有多个起始节点和终止节点。形式地，我们可以把推导网络定义为一个三元组DNet(PN，RN，DR)，其中：

①PN(parameter node)是网络中的输入输出参数节点的结合。其中有若干个节点为起始节点，我们用SPN来表示；

②RN(rule node)是网络中所有规则节点(模型代号)的集合；

③DR(deduce relationship)是网络中的推导关系的集合，这些推导关系中主要包括4种，即”∧”关系、”∨”关系、”→”关系和”＝＞”关系，其中：

“∧”关系是作用于规则节点前的一种”and”关系。(PN1，PN2，...，PNn)∧RN x意味着只有当输入参数PN1，PN2，...，PNn都同时具备的时候，规则节点RN x才可以执行下去。事实上，如果规则节点RNx的前驱输入参数的个数大于1，那么它们之间肯定是一种“∧”关系，如下图7(a)所示。

“∨”关系是作用于参数前的一种”or”关系。(RN1，RN2，...，RN n)∨PN x意味着RN 1，RN 2，...，RN n中任何一个规则节点都可以推出参数节点PN x。事实上，如果参数PN x的前驱规则的个数大于1，那么它们之间肯定是一种”∨”关系，如下图7(b)所示。

“→”关系是“∧”关系n＝1的一种特殊情况。在(PN1，PN2，...，PNn)∧R x中，当n＝1时就变为”→”关系，即PNx→RN x，它意味着当输入参数节点PNx具备的时候，规则节点RN x就可以以执行下去。事实上，这种关系对应于规则节点中的输入参数只有一个时候的情况，如图7(c)所示。

“＝＞”关系是“∨”关系中n＝1的一种特殊情况。在(RN1，RN2，...，RNn)∨PN x中，当n＝1时就变为”＝＞”关系，即RNx＝＞PN x，它意味着规则RNx可以推出输出参数PN x。事实上，当模型库中如果只有一条规则可以得出某个输出参数时，那么该规则和该参数就具有这种”＝＞”关系，如图7(d)所示。

我们考虑表3的7个规则(模型)：{①A，B-＞C；②D-＞C；③D-＞E；④D，C-＞E；⑤E-＞A；⑥B，G-＞D；⑦B-＞F；}，那么在这个规则集合中，可以得出给定输入{A，B，D}的推导网络如图8所示，其中规则⑥B，G-＞D在推导网络中不出现，因为G不在输入中，该规则也不出现在A，B，D可能的推导中。

在该推导网络为中，PN，RN和DR的值分别为：

PN＝{A，B，C，D，E，F}，其中SPN＝{A，B，D}；

RN＝{①，②，③，④，⑤，⑦}；

DR＝{(A，B)∧①；D→②；(①，②)∨C；(C，D)∧④；D→③；(③，④)∨F；F→⑤；⑤＝＞A；B→⑦；⑦＝＞F；}

由此可以看出，推导网络DR中存放了网络中的全部可能的推导关系，因此给定任意一个节点，都可以在该推导网络中逆向找出该节点的所有可能推导路径。例如在该推导网络中节点E的推导路径有三条：

{①A，B-＞C；④D，C-＞E；}

{②D-＞C；④D，C-＞E；}

{③D-＞E；}

为了能够在用户给定的输入/期望输出的条件下，找出现有的Web Services模型库中存在的所有可能合成方案，并选择一条执行代价最优的合成方案，基于SLA的最优合成主要分为以下4个步骤：

(1)根据用户的输入和Web Services模型库求出推导网络；其步骤是根据用户给定的输入集合，利用Web Services模型库来进行各种可能推导，在推导过程中记录各种推导关系DR，直到推导关系集合DR不再增大为止；

(2)在找出用户期望输出集合的所有合成方案之前，首先必须为单个输出求出其所有合成方案。算法在搜索过程中利用一个栈来存放所生成的合成方案，并采用逆向的方法来进行搜索。在搜索过程中，碰到“参数节点”和“规则节点”分别做不同的进栈和退栈处理，如果碰到“∨”关系，则需要从栈顶派生出多个新的合成方案来代替栈顶的方案。如果栈顶合成方案的所有起始节点全部包含在用户输入中，则输出该栈顶合成方案。

(3)上一步是求解单个输出的所有合成方案，但是用户所期望的输出往往具有多个，因此当用户所期望输出多于一个的时候，则需要分别为每一个输出求出其所有合成方案，然后把各个输出的合成方案进行自然乘积的合并，就可以求得整个输出集合的所有合成方案。

(4)在求出用户给定输入/输出条件下的所有合成方案之后，就可以根据用户的SLA要求分别计算各个方案的SLA(如执行代价、响应时间等)情况。合成方案的SLA计算非常直观，只需要找出各个合成方案中各个Web Services，并对各个Web Services的SLA进行求和。

从上面的介绍可以看出，整个合成过程的可以归纳为如下图所示的几个阶段，用户只要给定一些输入和所期望的输出，那么就可以在已有的Web Services模型库下，根据用户的SLA要求自动生成一个最优的合成方案。由于生成的合成方案中规则节点只存在单个输出的情况(它实际上可以看成是一个扩充的DAG图)，所以与无回溯反向链算法生成的合成方案一样，完全可以利用改进的拓朴排序算法将合成方案自动转换为BPEL4WS代码，并调用BPEL4WS引擎来执行，返回所需要结果，整个过程如图9所示。

Claims (5)

1.一种Web Services的实时、动态合成方法，其特征在于有一个Web Services的实时、动态合成框架，该框架中包括Web Services建模、参数级本体构造、无回溯反向链合成算法和基于SLA的最优合成算法；框架中还具有建模工具、本体构造工具、模型库和语义本体库，具体步骤为：首先根据Web Services的WSDL文件进行产生式建模，并由模型库中的模型来构造一个参数级本体，用于消除参数之间的语义冲突；然后再根据用户给定的输入和所期望的输出，利用无回溯反向链合成算法来找出一个合成方案，或者根据用户的SLA要求来找出最优的合成方案；最后把生成的合成方案转换为BPEL4WS代码，调用BPEL引擎执行并返回结果给用户；其中，所述产生式建模是通过导入Web Services的WSDL描述文件给建模工具生成头部只有单项的产生式作为模型，并在产生式上附加一些由合成方案向BPEL4WS转换自动进行所需的Web Services的描述信息，然后把模型存放在模型库中。

2.根据权利要求1所述的合成方法，其特征在于所述构造参数级本体中，该参数级本体共分为两层，上层为领域内术语，下层为Web Services的输入、输出参数，并通过下层参数之间的虚线连接同名异义的参数，使用实线连接异名同义的参数，以消除合成过程中可能出现的语义冲突。

3.根据权利要求1所述的合成方法，其特征在于所述的无回溯反向链合成算法是首先根据用户给出的输入、模型库和语义本体库来计算一个输入闭包，并把该输入闭包存放在一个合成缓冲区中，用于下次合成；然后通过反向推导来找出合成中要用到的所有WebServices；所述的基于SLA的最优合成算法，首先进行建模和参数级本体的构造，以消除合成过程中的语义冲突，然后根据用户输入和现有的Web Services模型计算一个推导网络，再按照用户所期望的输出，利用推导网络来求出各种可能的合成方案，并依照用户的SLA要求选择一条最优的合成方案。

4.根据权利要求3所述的合成方法，其特征在于设置有一个用于存放经过语义冲突处理后使用无回溯反向链合算法生成的输入闭包的合成缓冲区，该合成缓冲区分为持久保存存储区和临时内存区，每当进行一次合成，就把数据从持久保存存储区调到临时内存区。

5.根据权利要求3所述的合成方法，其特征在于所述的推导网络定义为一个三元组DNet(PN，RN，DR)，其中：

①PN是网络中的输入输出参数节点的结合，其中有若干个节点为起始节点，用SPN来表示；

②RN是网络中所有规则节点的集合；

③DR是网络中的推导关系的集合，这些推导关系中主要包括4种，即“∧”关系、“∨”关系、“→”关系和“＝＞”关系，其中：

“∧”关系是作用于规则节点前的一种“and”关系；

“∨”关系是作用于参数节点前的一种“or”关系；

“→”关系是“∧”关系中规则节点的前驱输入参数的个数为1的一种特殊情况；

“＝＞”关系是“∨”关系中参数节点的前驱输入参数的个数为1的一种特殊情况。

Images