从传统Web服务到多维度语义模型的Web服务转换方法
【专利摘要】本发明涉及Web服务【技术领域】，为提高语义Web服务描述模型的可用性，实现对现有WSDL描述的Web服务的语义化。本发明采用的技术方案是，从传统Web服务到多维度语义模型的Web服务转换方法，包括如下步骤：1)从WSDL描述的服务文档中获取功能语义：2)从WSDL描述的服务文档中获取上下文语义；3)通过调用该Web服务，按照MSDL规范定义Web服务的性能语义，多维度语义模型的性能语义描述了该服务的质量属性；4)从WSDL描述文档获取服务的时空语义；5)从WSDL描述文档获取服务的技术语义；6)按照MSDL规范定义Web服务的交互语义。本发明主要应用于Web服务技术。
【专利说明】从传统Web服务到多维度语义模型的Web服务转换方法
【技术领域】
[0001]本发明涉及Web服务【技术领域】，具体来说，涉及从传统Web服务到多维度语义模型的Web服务转换方法。
【背景技术】
[0002]Web服务是一种基于Web环境的具有自适应、自描述、模块化并具有良好互操作能力的应用程序。随着互联网上Web服务的持续增加，以服务为中心的互联网正在悄然形成。目前，已有的Web服务绝大部分是使用WSDL (Web Services Description Language)描述，这些传统的Web服务都缺乏充足的语义信息，影响了服务发现和服务组合的结果，并使得自动的服务组合产生困难。因此，很有必要给现有的Web服务添加缺失的语义信息。
[0003]为了实现语义Web服务，一方面的研究致力于对现有WSDL描述的Web服务进行语义扩展，试图从现有的Web服务中提取语义信息，通过使用本体中机器可理解的元数据标注服务资源描述的各种概念。如METEOR-S语义标注框架通过对Web服务描述文档中的XMLSchema和本体进行转化，再对其进行匹配，并选出最优的匹配作为标注结果。但是此类方法的自动化程度还不够高，并且扩展的语义也有限制。
[0004]另一方面的研究致力于提出语义Web服务的描述规范。由于语义Web服务的描述是Web服务有关操作或处理的基础，因此，在服务开发阶段通过本体描述服务，使Web服务在底层就具备语义信息，从根本上消除服务交互处理间的异质或歧义性，为服务的互操作提供语义基础。目前已经提出了多种语义Web服务描述模型，如基于本体的Web语言服务(OffL-S)，Web服务模型本体(WSMO)，轻量级服务语义描述(WSMO-1ite)，语义Web服务本体(SWSO)，SOA参考模型，WSDL语义标注(SAWSDL)和通用语义服务描述语言(USDL)等，其中前五种模型都抛弃了现有的 WSDL (Web Services Description Language)架构；而 SAWSDL和USDL是在WSDL基础上，使用本体概念对WSDL文档添加语义信息。
[0005]以上技术对实现语义Web服务提出了不同的解决方案，但是仍然存在如下的问题:
[0006]I)现有的Web服务进行语义扩展的方法完全建立在传统Web服务的架构上，对于服务的语义扩展程度及能力很有限，绝大部分的扩展算法只是增加了服务的功能语义，但缺乏其他方面的语义，如服务的上下文语义。
[0007]2)现有的Web服务描述规范尽管提出了一种新的Web服务描述语言，极大地增强了 Web服务的语义信息，但它们都抛弃了传统Web服务语言WSDL的结构，且没有提出相应的方法来弥补WSDL语目和语义Web服务语目之间的差异。
[0008]3)现有的Web服务语义模型各不统一，存在描述方式的差异。如由于服务提供者之间、以及服务提供者与用户之间缺少对Web服务共同的语义约束，妨碍了 Web服务之间的互操作以及服务的发现和组合的效率。
[0009]针对以上问题，有必要提出一个语义Web服务模型来弥补WSDL语言和语义Web服务语言之间的差异，同时，不仅要考虑Web服务简单的功能方面的语义，还应该从多个角度考虑Web服务的语义，如Web服务的时空和上下文等语义信息，以及Web服务的交互语义，并且实现从传统Web服务到该语义Web服务模型的Web服务转换。
【发明内容】
[0010]本发明旨在解决克服现有技术的不足，Web服务的多维度语义模型通过Web服务多维度语义描述语言(Multidimensional Semantic Description Language,MSDL)规范了Web服务的定义，MSDL能够兼容基于语义的WSDL。Web服务的多维度语义模型不仅包含Web服务的功能语义，还包含Web服务的时空、上下文、服务关系等语义信息。本发明旨在提高语义Web服务描述模型的可用性，实现对现有WSDL描述的Web服务的语义化。本发明采用的技术方案是，从传统Web服务到多维度语义模型的Web服务转换方法，包括如下步骤:
[0011]I)从WSDL描述的服务文档中获取功能语义，多维度语义模型的功能语义是指调用Web服务能够实现的功能，主要包括了四个部分:服务目标(Goal)，服务输入(Input)，服务输出(Output)以及服务约束(Constraint),由巴克斯范式(I)给出:
[0012]〈FunSem〉:: =〈Goal>〈Input>〈Output>〈Constraint> { " and " " or " " not" } (I)
[0013]1-1由WSDL文档中的操作信息获取Web服务的目标，将WSDL中的〈operation〉元素的操作名称及描述信息，按照MSDL关于服务目标的规范，提取出Web服务的目标；多维度语义模型的Web服务的目标使用行为(Behavior)和意图(Intention)组成的动宾短语来描述，如巴克斯范式(2)所示，Behavior表示操作针对于某意图进行的行为和动作，用某领域表示意图相关行为 的概念集合Bn表示,如式(3)所示，Intention是操作的意图,通过本体的概念(Concept)、属性(Attribute)或者实例(Instance)来描述Web服务的意图，如式
(4)所示；
[0014]〈Goal〉:: =〈BehaviourXIntention〉 (2)
[0015]〈Behaviour〉:: = B1" or" B2" or"..." or" Bn (3)
[0016]〈Intention〉— Concept I Instance I Attribute (4)
[0017]1-2由WSDL文档中的输入和输出参数获取多维度语义服务的输入和输出，将WSDL中的〈input〉元素和〈output〉元素中的参数名称信息，按照MSDL关于服务输入和输入的规范，提取出Web服务的输入和输出，多维度语义模型中，服务的输入和输出作为功能的重要组成部分，由本体的概念、属性或者实例进行描述，如式(5) (6)所示；
[0018]〈Input〉— Concept I Instance I Attribute (5)
[0019]〈Output〉 — Concept|Instance Attribute (6)
[0020]1-3由WSDL文档中的服务和操作的描述获取Web服务约束，将WSDL中的〈service〉元素的服务描述信息，以及〈operation〉元素的操作描述信息，按照MSDL的关于服务约束的规范，提取出Web服务的约束，多维度语义模型中，Web服务约束对服务功能进行限定和说明，用原子谓词Ci, i = 1,2,…，m，表示一个具体的功能约束，多个原子谓词通过逻辑符“and”连接，如式(7)所示；
[0021]〈Constraint〉::= C1" and" C2" and"…"and" Cm (7)
[0022]2)从WSDL描述的服务文档中获取上下文语义。多维度语义模型中，上下文信息包括了服务所属领域(Domain)，服务提供商(Provider)以及服务的标签(Tag)，如式(8)所示，其中，服务所属领域在式(9)中被列举出，服务可能会属于不同的领域，Provider描述了 Web服务的提供商信息，如公司或组织名称，根据WSDL描述文档中的输入和输出信息，按照MSDL关于服务领域的规范，定义多维度语义Web服务的领域；根据WSDL描述文档中的〈definitions〉元素,提取targetNamespace属性，按照MSDL关于服务提供商的规范，定义多维度语义Web服务的提供商；通过服务的来源网站上的服务标签获取服务的标签，或根据服务的功能语义手动添加服务的标签；
[0023]〈ConSem〉:: = <DomainXProviderXTag> (8)
[0024]<Domain> — Travel|Education|Medical|Food|Communication|Economy|WeaponsI Geography I Simulation I… (9)
[0025]3)通过调用该Web服务，按照MSDL规范定义Web服务的性能语义，多维度语义模型的性能语义描述了该服务的质量属性，包括如式(10)所示的六个部分；
[0026]<PerSem>:: = <ResponseTimeXPriceXAvaiIabiIityXReliabiIityXThroughput><Security> (10)
[0027]〈ResponseTime〉:: =〈Number〉 (11)
[0028]〈Price〉:: =〈Number〉 (12)
[0029]〈Availability〉:::: =〈Number〉 (13)
[0030]〈Reliability〉:: =〈Number〉 (14)
[0031]〈Throughput〉:: =〈Number〉 (15)
[0032]〈Security〉:: =〈Degree〉 (16)
[0033]〈Degree〉 — General Medium|Advanced (17)
[0034]3-1计算服务的响应时间(ResponseTime),由数字表示,如巴克斯范式(11)所示，服务S对应的操作OP的响应时间等于发送请求到接受响应信息的间隔时间，是该服务操作的处理时间Tpmmss和服务传输时间Ttaans之和，由公式(18)给出:
[0035]qrt (s，op) = Tprocess (s，op)+Ttrans (s，op) (18)
[0036]3-2计算调用服务的花费(Price)，包括了服务请求者要执行操作的费用，如巴克斯范式(12)所示；
[0037]3-3计算服务的可访问性(Availability)，如巴克斯范式(13)所示，可访问性是指在一段时间内服务可被访问的概率，由公式(19)给出:
[0038]qav (s) = Ta(S)/Θ (19)
[0039]其中，Ta(S)是在Θ时间段内服务s可以被访问的总的时间；
[0040]3-4计算服务的可靠性(Reliability)，如巴克斯范式(14)所示，可靠性是指在最大预期时间内，请求被正确响应的概率，由公式(20)给出:
[0041]qrel(s) = Nc (s)/K (20)
[0042]其中，N。(S)是在最大预期时间内服务s被成功交付的次数，K是指总的调用次数；
[0043]3-5计算吞吐率(Throughput),是指给定的一段时间内，服务总的调用次数，如巴克斯范式(15)所示，吞吐率增加，则响应时间也将变大；
[0044]3-6评价服务的安全性(Security)，如巴克斯范式(16)所示，服务的安全性可以用级别(Degree)进行衡量,包括了一股(General)、中等(Medium)和高级(Advanced)三个级别的描述，如巴克斯范式(17)所示；[0045]4)从WSDL描述文档获取服务的时空语义，记录Web服务在时间和空间上的状态信息，多维度语义模型的时空语义定义见巴克斯范式(21)；
[0046]〈SpTSem〉::=〈SpaceXTime〉 (21)
[0047]〈Space〉— Cyberspace I PhysicalLocation (22)
[0048]〈Time〉:: =〈LifeCycleXStatus〉 (23)
[0049]〈LifeCycle〉:: =〈PubDateXDeathDate〉 (24)
[0050]〈Status〉— Innovation | Offering | Matchmaking | Usage | Feedback (25)
[0051]4-1由WSDL文档中的服务描述获取Web服务的空间(Space)语义，将WSDL中的〈service〉元素的location属性值,按照MSDL的关于服务空间语义的规范,定义Web服务的空间语义。多维度 语义模型中，服务的空间语义说明了 Web服务在物理上所处的位置信息或者所部属的虚拟地址，如式(22)所示，任何Web服务在空间上都会有相对固定的物理位置(PhysicalLocation)或者虚拟空间(Cyberspace)地址；
[0052]4-2通过调用该Web服务，由返回结果获取该服务的时态(Time)语义,按照MSDL的关于服务约束的规范，定义多维度语义Web服务的时态语义。多维度语义模型中，Web服务的时态语义定义如式(23)所示，它说明了 Web服务在整个生命周期不同时间点所处的状态(Status),如服务提供(Offering)、匹配(Matchmaking)和反馈(Feedback)等阶段状态信息，如式(25)所示；同时也表征了 Web服务“存活”的周期(LifeCycle)，包括服务的发布时间(PubDate)和死亡时间(DeathDate)JnS (24)所示。若调用服务成功，则记录服务的死亡时间为空，若调用失败，则记录当前时间为服务的死亡时间，此外，在服务的来源网站上获取服务的发布日期；
[0053]5)从WSDL描述文档获取服务的技术语义，多维度语义模型的Web服务的技术语义在技术层面上描述了如何与Web服务进行交互，如式(26)所示；
[0054]〈TecSem〉: =〈ProtocolXDataFormat〉 (26)
[0055]〈Protocol〉— SOAPlRESTful (27)
[0056]〈DataFormat〉— XMLIWSDLI Text (28)
[0057]5-1由WSDL文档中的通信信息定义Web服务的通信协议(Protocol)，将WSDL中〈binding〉元素定义的消息协议信息，按照MSDL的关于服务通信协议的规范，定义Web服务的通信协议。多维度语义模型中，Web服务的通信协议描述了服务之间进行数据交换应遵守的规则，包括SOAP和RESTful协议，如式(27)所示；
[0058]5-2由WSDL文档中的数据格式信息定义Web服务的数据格式(DataFormat),按照MSDL的关于数据格式的规范，定义Web服务的数据格式为WSDL文档。多维度语义模型中，Web服务的数据格式是用来描述Web服务并说明如何与该Web服务进行通信，如WSDL和XML文档，如式(28)所示；
[0059]6)按照MSDL规范定义Web服务的交互语义，从而描述了 Web服务之间的动态交互关系，通过服务之间的交互关系可以将众多孤立的服务组织成一个关系网络，交互语义的定义如式(29)所示；
[0060]〈IntSem〉::= 〈Competitive〉I〈Collaborative〉I〈Others〉 (29)
[0061]〈Competitive〉— " Exact" " Plugin" " Subsume" " Intersection"(30)[0062]〈Collaborative〉—" Sequential_total" " Sequential_part" (31)
[0063]〈Others〉—" Community" " MemberOf;/ " Alliance" (32)
[0064]6-1定义服务的竞争(Competitive)关系，该关系主要是从两个Web服务的功能相似性的角度定义服务间的关联关系，包括了恒等(Exact)关系、插接(Plugin)关系、继承(Subsume)关系和相交(Intersection)关系，如式(30)所示；
[0065]6-2定义服务的协作(Collaborative)关系,该关系主要是从两个Web服务间的功能连接的角度定义服务级关联关系，分为完全后继(Sequential_total)关系和部分后继(Sequential_part)关系,如式(31)所示；
[0066]6-3定义服务的社区(Community)关系,该关系是由Web服务之间具有因某种属性相同得到；
[0067]6-4定义服务的成员(MemberOf)关系,该关系是服务之间存在隶属特性；
[0068]6-5定义服务的联盟(Alliance)关系，该关系是指提供商之间签订的战略协议，服务提供商之间的联盟关系势必将会影响到服务的选择。
[0069]本发明具有如下优点:
[0070]本发明从不 同维度描述了 Web服务的语义信息，极大地扩展了传统Web服务的多个维度的语义信息，弥补WSDL语言和语义Web服务语言之间的差异，通过MSDL对Web服务的语义信息进行了规范和约束，实现了 Web服务发现、组合和监控全方位的语义支持。
【专利附图】
【附图说明】
[0071]图1是本发明Web服务多维度语义模型概念图。
[0072]图2是一个Web服务的功能结构示意图。
[0073]图3是本发明从WSDL到MSDL映射关系示意图。
[0074]图4是本发明MSDL语义和语法部分的基本结构。
【具体实施方式】
[0075]本发明提出了从传统Web服务到多维度语义模型的Web服务的转换方法，多维度语义模型的概念图参见图1，该模型的服务描述语言是MSDL，它是一种基于XML的描述语言，为了兼容现在主流的Web服务描述语言，MSDL的语法描述兼容传统的WSDL对Web的接口、参数和通信等信息，语义描述部分使用0WL(Web Ontology Language),对服务的语义进行规范。因此，从传统Web服务到多维度语义模型的Web服务的转换需要遵循MSDL的规范。
[0076]本发明采用的技术方案是:
[0077]I)从WSDL描述的服务文档中定义多维度语义模型的功能语义。多维度语义模型的功能语义是指调用Web服务能够实现的功能，主要包括了四个部分:服务目标(Goal)，月艮务输入(Input),服务输出(Output)以及服务约束(Constraint),由巴克斯范式⑴给出:
[0078]〈FunSem〉::=〈Goal>〈Input>〈Output>〈Constraint> { " and " " or " " not" } (I)
[0079]1-1由WSDL文档中的操作信息获取Web服务的目标，使用hasGoal字段描述。将WSDL中的〈operat ion>元素的操作名称及描述信息，按照MSDL关于服务目标的规范，提取出Web服务的目标。多维度语义模型的服务目标使用行为(Behavior)和意图(Intention)组成的动宾短语来描述,如巴克斯范式(2)所示。Behavior表示操作针对于某意图进行的行为和动作，用某领域表示意图相关行为的概念集合Bn表示，如式(3)所示，用IntentionConcept概念类的hasConcept字段描述行为；Intention是操作的意图，通过本体概念、属性或者实例来描述Web服务的意图，如式(4)所示,用BehaviorConcept概念类的hasConc印t字段描述意图。通过解析一个WSDL描述的查询邮政编码的Web服务，图2示出了该Web服务服务ZipCodeLookup的功能结构,它包含一个操作GetZipInfo,该操作的输入参数为城市名称City，输出参数为getZipByCityResult，则该WSDL的服务目标可以描述为 “Get http://dbpedia.0rg/resource/ZIP_code” 的形式，其中 “Get” 是行为，而“http://dbpedia.0rg/resource/ZIP_code” 是对应的意图，使用开源本体 DBpedia 的实例来描述；
[0080]〈Goal〉:: =〈BehaviourXIntention〉 (2)
[0081]〈Behaviour〉:: = B1" or" B2" or"..." or" Bn (3)
[0082]〈Intention〉 — Concept|Instance Attribute (4)
[0083]1-2由WSDL文档中的输入和输出参数获取多维度语义服务的输入和输出，分别使用has Input和hasOutput字段进行描述。将WSDL中的〈input〉兀素和〈output〉兀素中的参数名称信息，按照MSDL关于服务输入和输入的规范，提取出Web服务的输入和输出。在多维度语义模型中，服务的输入输出作为功能的重要组成部分，在某种程度上可以认为是对Web服务所实现功能的补充，例如两个Web服务都是获取天气，一个服务的输入是城市名称，而另一个服务的输入是城市编码，因此在功能语义描述中只有加入输入和输出才 能实现对功能的精确描述。输入和输出作为功能的重要组成部分，由本体概念、属性或者实例进行描述，如式(5) (6)所示。例如图2所示的服务ZipCodeLookup,其WSDL文档中记录的输入参数City，在多维度语义模型中的Web服务输入为“http://dbpedia.0rg/ontology/City”,使用DBpedia的本体概念来描述；WSDL文档中记录的输出参数为getZipByCityResult,在多维度语义模型中的服务输出为“http://dbpedia.0rg/resource/ZIP_code”,使用 DBpedia 的实例来描述；
[0084]〈Input〉 — Concept|Instance Attribute (5)
[0085]〈Output〉 — Concept|Instance Attribute (6)
[0086]1-3由WSDL文档中的服务和操作的描述获取Web服务约束,使用hasConstraint进行描述。将WSDL中的〈service〉元素的服务描述信息，以及〈operation〉元素的操作描述信息，按照MSDL的关于服务约束的规范，提取出Web服务的约束。多维度语义模型中，Web服务约束是对服务功能进行进一步的限定和说明，用原子谓词CiQ = 1,2,…，m)表示一个具体的功能约束，多个原子谓词通过逻辑符“and”连接，如式(7)所示。服务约束可能包括服务范围限制、时间限制、频率、输入格式、输出格式、返回结果数量、主体属性等，例如服务约束表示为:(O < Day ( 3) “and”(Region = China),它是一个查询天气的服务的约束，那么该约束包括两方面含义:①定义了该服务只能查询未来三天的天气定义该服务只能查询中国的天气状况。通过对Web服务语义约束进行规范，可以增强Web服务之间的互操作性，从而提高Web服务发现和组合的效率；
[0087]〈Constraint〉::= C1" and" C2" and"…"and" Cm (7)
[0088]2)按从WSDL描述的服务文档中获取上下文语义。多维度语义模型中，上下文信息包括了服务所属领域(Domain)，服务提供商(Provider)以及服务的标签(Tag)，如式(8)所示。Web服务的上下文语义是指会影响到Web服务发现和组合结果的上下文相关信息。因此，规范定义服务上下文语义，可为自动的Web服务发现提供奠定基础，也克服了现有的Web服务语义扩展方法的缺陷。按照MSDL对于上下文语义的规范，需要实现以下信息转换:
[0089]〈ConSem〉: = <DomainXProviderXTag> (8)
[0090]<Domain> — Travel|Education|Medical|Food|Communication|Economy|WeaponsI Geography I Simulation I… (9)
[0091]2-1根据WSDL描述文档中的输入和输出信息，按照MSDL关于服务领域的规范，定义多维度语义Web服务的领域，使用belongTo字段描述。在多维度语义模型中，服务所属领域在式(9)中被列举出，如旅游(Travel)、教育(Education)、医疗(Medical)等领域。通常来说用户在选定某一领域的服务时，从某种程度上说明用户对该领域的其它服务也有兴趣，因此在服务推荐的过程中优先会推荐相同领域的服务，与此同时领域又是相对笼统的概念，并无明确的划分，因此同一服务可能会分属不同的领域；
[0092]2-2 根据 WSDL 描述文档中的〈definitions〉元素，提取 targetNamespace 属性，按照MSDL关于服务提供商的规范，定义多维度语义Web服务的提供商，使用provideBy字段描述。提供商(Provider)描述了 Web服务的提供商信息，即由谁提供的Web服务，一股是公司、组织或者个人。不可否认在服务组合的过程中相同提供商提供的服务组合完成更大粒度功能的可能性更大，而且适配性更强。如在地图服务的组合应用中，如若用户选择了Google地图服务，那么后续在调用相关地图的服务过程中会优先选择Google的地图服务；
[0093]2-3通过服务的来源网站上的服务标签获取服务的标签，或根据服务的功能语义手动添加服务的标签，使用hasTag字段描述。例如ProgrammableWeb网站上一个AmazonQueue 的服务，其标签是`“infrastructure”、“queue，，和 “messaging” ；
[0094]3)通过调用该Web服务，按照MSDL规范定义Web服务的性能语义。多维度语义模型的性能语义描述了该服务的质量属性，包括如式(10)所示的六个部分。服务的响应时间、可用性、可靠性等性能指标可以定义为Web服务性能语义的一种属性，用is A来表示Web服务的性能概念；在服务发现的过程中，除了满足用户对Web服务功能语义的需求之外，用户可能会存在一些对服务性能的需求。Web服务的性能表征了 Web服务定性与定量方面的特征，因此通过服务的性能语义，可以方便选择最佳服务，从而优化服务发现的结果；
[0095]<PerSem>:: = <ResponseTimeXPriceXAvaiIabiIityXReliabiIityXThroughput><Security> (10)
[0096]〈ResponseTime〉:: =〈Number〉 (11)
[0097]〈Price〉:: =〈Number〉 (12)
[0098]〈Availability〉:: =〈Number〉 (13)
[0099]〈Reliability〉:: =〈Number〉 (14)
[0100]〈Throughput〉:: =〈Number〉 (15)
[0101]〈Security〉:: =〈Degree〉 (16)
[0102]〈Degree〉 — General Medium|Advanced (17)
[0103]3-1计算服务的响应时间(ResponseTime),由数字表示,如巴克斯范式(11)所示，服务S对应的操作OP的响应时间等于发送请求到接受响应信息的间隔时间，是该服务操作的处理时间Tpmmss和服务传输时间Ttaans之和，由公式(18)给出:
[0104]qrt(s, op) = Tprocess (s, op)+Ttrans (s, op) (18)
[0105]3-2计算调用服务的花费(Price)，包括了服务请求者要执行操作的费用，如式
(12)所示；
[0106]3-3计算服务的可访问性(Availability)，如式(13)所示，可访问性是指在一段时间内服务可被访问的概率，由公式(19)给出:
[0107]qav (s) = Ta(S)/Θ (19) [0108]其中，Ta(S)是在Θ时间段内服务s可以被访问的总的时间；
[0109]3-4计算服务的可靠性(Reliability),如式(14)所示,可靠性是指在最大预期时间内，请求被正确响应的概率，由公式(20)给出:
[0110]qrel(s) = Nc (s)/K (20)
[0111]其中，N。(S)是在最大预期时间内服务s被成功交付的次数，K是指总的调用次数；
[0112]3-5计算吞吐率(Throughput),是指给定的一段时间内，服务总的调用次数,如式
(15)所示；吞吐率增加，则响应时间也将变大；
[0113]3-6评价服务的安全性(Security)，如式(16)所示，服务的安全性可以用一股(General)、中等(Medium)和高级(Advanced)来描述；
[0114]4)从WSDL描述文档获取服务的时空语义，记录Web服务在时间和空间上的状态信息，多维度语义模型的时空语义定义见巴克斯范式(21)；
[0115]〈SpTSem〉::=〈SpaceXTime〉 (21)
[0116]〈Space〉— Cyberspace I PhysicalLocation (22)
[0117]〈Time〉:: =〈LifeCycleXStatus〉 (23)
[0118]〈LifeCycle〉:: =〈PubDateXDeathDate〉 (24)
[0119]〈Status〉— Innovation | Offering | Matchmaking | Usage | Feedback (25)
[0120]4-1由WSDL文档中的服务描述获取Web服务的空间语义，使用1cationIn来描述。将WSDL中的〈service〉兀素内的〈soap:address>兀素的location属性值，转换为物理位置的IP地址，按照MSDL的关于服务空间语义的规范，定义Web服务的空间语义。多维度语义模型中，Web服务的空间语义说明了 Web服务在物理上所处的位置信息或者所部属的虚拟地址，如式(22)所示，任何Web服务在空间上都会有相对固定的物理位置(PhysicalLocation)或者虚拟空间(Cyberspace)地址，即服务提供商的主机所在位置。一股用户更有意愿选择距离自己位置更近的服务，以便能够快速的调用服务，Web服务的位置信息一股都是由服务提供商提供的。如名为“GetBookName”的服务所部署的主机位置处于美国西雅图。
[0121]4-2通过调用该Web服务，由返回结果获取该服务的时态语义。按照MSDL的关于服务约束的规范，定义多维度语义Web服务的时态语义。多维度语义模型中，Web服务的时态语义定义如式(23)所示，它说明了 Web服务在整个生命周期不同时间点所处的状态(Stams)，使用hasStams来描述，如服务提供、匹配和反馈等阶段状态信息，如式(25)所示；同时也表征了 Web服务“存活”的周期(LifeCycle)，包括服务的发布时间和死亡时间，分别用hasPubDate和hasDeathDate来描述,如式(24)所示。若调用服务成功，则记录服务的死亡时间为空，若调用失败，则记录当前时间为服务的死亡时间，此外，在服务的来源网站上获取服务的发布日期。用户在服务发现和组合的过程中，应该会优先选择当前死亡时间为空的Web服务，即仍然存活的Web服务；
[0122]5)从WSDL描述文档获取服务的技术语义。多维度语义模型的Web服务的技术语义在技术层面上描述了如何与Web服务进行交互，如式(26)所示；
[0123]<TecSem> ； = <ProtocolXDataFormat> (26)
[0124]〈Protocol〉— SOAPlRESTful (27)
[0125]〈DataFormat〉— XMLIWSDLI Text (28) [0126]5-1由WSDL文档中的通信信息定义Web服务的通信协议(Protocol)，使用kindof_protocol字段来描述。将WSDL中〈binding〉元素定义的消息协议信息,按照MSDL的关于服务通信协议的规范，定义Web服务的通信协议。多维度语义模型中，Web服务的通信协议描述了服务之间进行数据交换应遵守的规则，包括SOAP和RESTful协议，如式(27)所示。SOAP作为Web服务调用协议主要是用来在Web服务应用程序之间以对象的形式交换双方所需要的数据，它是一种基于XML的平台无关的通信协议；而RESTful作为一种新兴的Web服务调用协议受到越来越多的关注。
[0127]5-2由WSDL文档中的数据格式信息定义Web服务的数据格式(Data Format)，使用kindof dataFormat字段来描述。。按照MSDL的关于数据格式的规范,定义Web服务的数据格式为WSDL文档。多维度语义模型中，Web服务的数据格式是用来描述Web服务并说明如何与该Web服务进行通信，如WSDL和XML文档，如式(28)所示；
[0128]6)按照MSDL规范定义Web服务的交互语义，从而描述了 Web服务之间的动态交互关系，通过服务之间的交互关系可以将众多孤立的服务组织成一个关系网络，交互语义的定义如式(29)所示；由于现有的Web服务语义模型没有考虑服务的交互语义，本模型中定义的交互语义，能够提高服务组合的效率。
[0129]〈IntSem〉::=〈Competitive〉I〈Collaborative〉I〈Others〉 (29)
[0130]〈Competitive〉— " Exact" " Plugin" " Subsume" " Intersection"(30)
[0131]〈Collaborative〉—" Sequential_total" " Sequential_part" (31)
[0132]〈Others〉—" Community" " MemberOf;/ " Alliance" (32)
[0133]6-1定义服务的竞争(Competitive)关系，该关系主要是从两个Web服务的功能相似性的角度定义服务间的关联关系，包括了恒等(Exact)关系、插接(Plugin)关系、继承(Subsume)关系和相交(Intersection)关系，如式(30)所示；通过服务的竞争关系,可以实现在服务的发现过程中，将多个尽可能的候选服务提供给请求者，从而让服务请求者选择满足最佳的服务；
[0134].恒等关系:服务之间满足恒等关系，则要求两个服务在功能上具有等价关系，其定义为=WSpWS2分别表示两个Web服务，WS1至少存在一个操作与WS2的一个操作在语义上是功能等价，则WSnWS2满足恒等关系，记做XWSpWSp e Exact。因此，恒等关系的定义是很严格的，事实上Web服务之间这种严格的等价匹配是非常少的，一股情况下除非服务提供商特别声明，否则两个独立的Web服务很难满足恒等关系。
[0135].插接关系:服务之间满足插接关系，则要求两个服务在语义上具有包含关系，其定义为=WS1，WS2分别表示两个Web服务，WS1至少存在一个操作的输出参数集合在语义上包含WS2 —个操作的输出参数集合，且WS2的该操作的输入参数集合在语义上包含WS1该操作的输入参数集合，则WS1,WS2满足插接关系，记做XWSpWSp e Plugins。在服务发现的过程中遵循插接关系，可以发现语义更强的服务。例如两个服务RentalCar和RentalVehicle,其中“交通工具”在语义上包含了“汽车”，因此〈RentalCar，RentalVehicle〉e Pluqin0
[0136].继承关系:继承关系是插接关系的逆关系，其定义为=WS1, WS2分别表不两个Web服务，WS2至少存在一个操作的输出参数集合在语义上包含WS1 —个操作的输出参数集合，且WS1该操作的输入参数集合在语义上包含WS2该操作的输入参数集合，则WS1, WS2满足继承关系，记做XWS1, WS2> e Subsume。继承关系描述了 Web服务在功能上从大到小的偏序关系，在服务发现的过程中按照继承关系可以排除功能较小的服务，同样对于上述两个租车和交通工具的服务，满足〈RentalVehicle, RentalCar〉e Subsume。
[0137].相交关系:服务之间的相交关系，描述了 Web服务在功能上的相似关系，其定义为:WS1; WS2分别表示两个Web服务，WS1至少存在一个操作的输出参数集合在语义上与WS2一个操作的输出参数集合相似，且WS2该操作的输入参数集合在语义上与WS1该操作的输入参数集合相似，则WSnWS2满足相交关系，记做XWS1, WS2> e Intersection。这里的参数集合的相似是指两个服务的一个或多个输入和输出参数存在相似的关系，参数的相似关系可以由本体中的intersectionOf关系推导得到。服务之间的相交关系描述了服务在一定程度上具有相似的特点，例如服务的功能、输入和输出消息类似等，具有相似关系的服务，为在服务资源匮乏的情况下服务的替换提供一种可能。
[0138]6-2定义服务的协作(Collaborative)关系,该关系主要是从两个Web服务间的功能连接的角度定义服务级关联关系，可分为完全后继(Sequential_total)关系和部分后继(Sequentialpart)关系，如式(31)所示；服务间的协作关系主要是从两个服务之间功能连接的角度定义了服务级的语义关系，通过这种合作关系，一方面将功能单一的服务通过连接后组成具有更大粒度功能的复合服务；另一方面用户请求了某个服务后，也可以将相关的服务作为候选推荐给用户；
[0139].完全后继关系:完全后继关系的定乂为=WS1, WS2分别表不两个Web服务，WS2至少存在一个操作的输入参数集合在语义上包含WS1 —个操作的输出参数集合，则WS1, WS2满足完全后继关系，记做:〈WS1; WS2> e Sequential_total。完全后继关系要求两个服务之输入与输出参数集合能够语义匹配，例如两个服务getCountryCodeByCountryName和getExchangeRateByCountryCode,前者通过城市名称得到国家编码(CountryCode),后者则通过国家编码获取国家之间的汇率，因此两个服务构成了完全后继关系。
[0140].部分后继关系:部分后继关系的定义为=WS1, WS2分别表不两个Web服务，WS2至少存在一个操作的输入参数集合在语义上部分包含WS1 —个操作的输出参数集合，则WS1, WS2满足部分后继关系，记做XWS1, WS2> e Sequential_part。这里的参数集合的语义部分包含是指两个服务的一个或多个输入和输出参数存在本体中的 Equivalent-of, Kind-of, Attribute-of 或 Part-of 关系。部分后继关系表不一个服务的输出参数集合只能部分满足另一个服务的输入参数集合，同样是前面的两个服务，如果getExchangeRateByCountryCode还需要提供日期信息，因为国家之间的汇率每天都在变更，而getCountryCodeByCountryName服务输出只能部分满足服务getExchangeRateByCountryCode,此时两个服务之间构成部分后继关系。[0141]6-3定义服务的社区(Community)关系,该关系是一种粗粒度的关系,是指Web服务在某一语义维度上有相同语义特征而形成的服务社区集合，社区内的服务之间拥有某一相同的属性，进而形成社区关系。在Web服务多维度语义模型的基础上，可以进行Web服务的社区挖掘；
[0142]6-4定义服务的成员(MemberOf)关系,该关系是服务之间存在隶属特性,如抽象服务和具体服务之间的关系；Web服务间成员关系的建立是伴随着服务本体生成过程而产生的，将具有相同和相似功能的具体服务操作接口通过本体建模形成抽象服务，即抽象服务是具有相同或相似功能服务操作接口的集合，因此抽象服务和具体服务之间的成员关系是一对多的关系，即每一个抽象服务对应了多个具体服务；
[0143]6-5定义服务的联盟(Alliance)关系，该关系描述了不同Web服务提供商之间存在的战略合作关系，其关系存在与否随着提供商之间的结盟与解盟而变化。Web服务不同提供商之间的联盟关系，势必将会影响服务的选择。例如当当网和招商银行之间的战略联盟关系导致用户在购买图书的同时会优先选择使用招商银行提供的支付功能的服务进行在线支付。
[0144]按照以上步骤，从WSDL到MSDL的转换来建立Web服务的多维度语义模型，从而得到一个语义Web服务的描述文档，该过程的一个简单示例参见图3。
[0145]本发明的MSDL语言在语法部分采用WSDL对其描述，因此弥补了 WSDL语言和语义Web服务语言之间的差异。对于语义部分，MSDL定义了一组通用的服务概念(Service Concept)用于描述Web服务不同维度语义信息，这些服务概念来自于形式化本体的概念类，包括功能概念(FunctionalityConcept)、性能概念(PerformanceConcept)、上下文概念(ContextConcept)、时空概念(SpatioTemporalConcept)和技术概念(TechnicalConcept)构成的服务概念的集合,MSDL基本结构参见图4。下面是本发明使用OffL描述多维度语义模型的服务概念。本发明使用OWL描述Web服务功能语义:
[0146]
【权利要求】
1.一种从传统Web服务到多维度语义模型的Web服务转换方法，其特征是，包括如下步骤: 1)从WSDL描述的服务文档中获取功能语义，多维度语义模型的功能语义是指调用Web服务能够实现的功能，主要包括了四个部分:服务目标(Goal)，服务输入(Input)，服务输出(Output)以及服务约束(Constraint),由巴克斯范式(I)给出:
〈FunSem>:: =〈Goal>〈Input>〈OutputXConstraint> {〃 and" " or " " not " }(I) 1-1由WSDL文档中的操作信息获取Web服务的目标，将WSDL中的〈operation〉元素的操作名称及描述信息，按照MSDL关于服务目标的规范，提取出Web服务的目标；多维度语义模型的Web服务的目标使用行为(Behavior)和意图(Intention)组成的动宾短语来描述，如巴克斯范式(2)所示，Behavior表示操作针对于某意图进行的行为和动作，用某领域表示意图相关行为的概念集合Bn表示,如式(3)所示，Intention是操作的意图,通过本体的概念(Concept)、属性(Attribute)或者实例(Instance)来描述Web服务的意图，如式(4)所示； <Goal>:= <Behaviour><Intention) (2) 〈Behaviour〉!!=B/7 or" B2" or"..." or" Bn (3) 〈Intention〉 — Concept|Instance|Attribute (4) 1-2由WSDL文档中的输入和输出参数获取多维度语义服务的输入和输出，将WSDL中的〈input〉元素和〈output〉 元素中的参数名称信息，按照MSDL关于服务输入和输入的规范，提取出Web服务的输入和输出，多维度语义模型中，服务的输入和输出作为功能的重要组成部分，由本体的概念、属性或者实例进行描述，如式(5) (6)所示； <Input> — Concept|Instance|Attribute (5) <Output) — Concept|Instance|Attribute (6) 1-3由WSDL文档中的服务和操作的描述获取Web服务约束，将WSDL中的〈service〉元素的服务描述信息，以及〈operation〉元素的操作描述信息，按照MSDL的关于服务约束的规范，提取出Web服务的约束，多维度语义模型中，Web服务约束对服务功能进行限定和说明，用原子谓词Ci, i = 1,2,…，m，表示一个具体的功能约束，多个原子谓词通过逻辑符“and”连接,如式(7)所示； 〈Constraint〉!!=C/7 and" C2" and"…"and" Cm (7) 2)从WSDL描述的服务文档中获取上下文语义，多维度语义模型中，上下文信息包括了服务所属领域(Domain)，服务提供商(Provider)以及服务的标签(Tag)，如式(8)所示，其中，服务所属领域在式(9)中被列举出，服务可能会属于不同的领域，Provider描述了Web服务的提供商信息，如公司或组织名称，根据WSDL描述文档中的输入和输出信息，按照MSDL关于服务领域的规范，定义多维度语义Web服务的领域；根据WSDL描述文档中的〈definitions〉元素,提取targetNamespace属性，按照MSDL关于服务提供商的规范，定义多维度语义Web服务的提供商；通过服务的来源网站上的服务标签获取服务的标签，或根据服务的功能语义手动添加服务的标签； <ConSem>:= <DomainXProviderXTag> (8)
<Domain> — Travel|Education|Medical|Food|Communication|Economy|Weapons|Geography I Simulation 1...(9) 3)通过调用该Web服务，按照MSDL规范定义Web服务的性能语义，多维度语义模型的性能语义描述了该服务的质量属性，包括如式(10)所示的六个部分；
<PerSem>:: = <ResponseTime><Price><Availability><ReliabilityXThroughput>〈Security〉 (10) <ResponseTime>:: =〈Number〉 (11) 〈Price〉:: =〈Number〉 (12) 〈Availability〉:: =〈Number〉 (13) 〈Reliability〉:: =〈Number〉 (14) 〈Throughput〉；! = <Number> (15) 〈Security〉； = <Degree> (16) 〈Degree〉 — General|Medium|Advanced (17) 3-1计算服务的响应时间(ResponseTime),由数字表示,如巴克斯范式(11)所示,服务s对应的操作op的响应时间等于发送请求到接受响应信息的间隔时间，是该服务操作的处理时间Tpmmss和服务传输时间Ttaans之和，由公式(18)给出:
Qrt (S，op) = Tproc`ess(s，op) +Ttrans(s，op) (18) 3-2计算调用服务的花费(Price)，包括了服务请求者要执行操作的费用，如巴克斯范式(12)所示； 3-3计算服务的可访问性(Availability),如巴克斯范式(13)所示,可访问性是指在一段时间内服务可被访问的概率，由公式(19)给出:qav(s) = Ta(S)/ Θ (19) 其中，Ta(S)是在Θ时间段内服务s可以被访问的总的时间； 3-4计算服务的可靠性(Reliability)，如巴克斯范式(14)所示，可靠性是指在最大预期时间内，请求被正确响应的概率，由公式(20)给出:
Qrel (s) = Nc (S)/K (20) 其中，Ne(S)是在最大预期时间内服务S被成功交付的次数，K是指总的调用次数； 3-5计算吞吐率(Throughput),是指给定的一段时间内，服务总的调用次数,如巴克斯范式(15)所示，吞吐率增加，则响应时间也将变大； 3-6评价服务的安全性(Security)，如巴克斯范式(16)所示，服务的安全性可以用级别(Degree)进行衡量,包括了一股(General)、中等(Medium)和高级(Advanced)三个级别的描述，如巴克斯范式(17)所示； 4)从WSDL描述文档获取服务的时空语义，记录Web服务在时间和空间上的状态信息，多维度语义模型的时空语义定义见巴克斯范式(21)； 〈SpTSem〉:: =〈SpaceXTime〉 (21) <Space> — Cyberspace|PhysicalLocation (22) 〈Time〉:: = <LifeCycleXStatus> (23) <LifeCycle>:: =〈PubDateXDeathDate〉 (24) <Status> — Innovation|Offering|Matchmaking|Usage|Feedback (25) 4-1由WSDL文档中的服务描述获取Web服务的空间(Space)语义，将WSDL中的〈service〉元素的location属性值,按照MSDL的关于服务空间语义的规范,定义Web服务的空间语义，多维度语义模型中，服务的空间语义说明了 Web服务在物理上所处的位置信息或者所部属的虚拟地址，如式(22)所示，任何Web服务在空间上都会有相对固定的物理位置(PhysicalLocation)或者虚拟空间(Cyberspace)地址； 4-2通过调用该Web服务，由返回结果获取该服务的时态(Time)语义，按照MSDL的关于服务约束的规范，定义多维度语义Web服务的时态语义，多维度语义模型中，Web服务的时态语义定义如式(23)所示，它说明了 Web服务在整个生命周期不同时间点所处的状态(Status),如服务提供(Offering)、匹配(Matchmaking)和反馈(Feedback)等阶段状态信息，如式(25)所示；同时也表征了 Web服务“存活”的周期(LifeCycle)，包括服务的发布时间(PubDate)和死亡时间(DeathDate)JnS (24)所示,若调用服务成功,则记录服务的死亡时间为空，若调用失败，则记录当前时间为服务的死亡时间，此外，在服务的来源网站上获取服务的发布日期； 5)从WSDL描述文档获取服务的技术语义，多维度语义模型的Web服务的技术语义在技术层面上描述了如何与Web服务进行交互，如式(26)所示； 〈TecSem〉:: =〈ProtocolXDataFormat〉 (26) 〈Protocol〉 — SOAP|RESTful (27) <DataFormat> — XML|WSDL|Text (28) 5-1由WSDL文档中的通信信息定义Web服务的通信协议(Protocol)，将WSDL中〈binding〉元素定义的消息协议信息，按照MSDL的关于服务通信协议的规范，定义Web服务的通信协议，多维度语义模型中，Web服务的通信协议描述了服务之间进行数据交换应遵守的规则，包括SOAP和RESTful协议，如式(27)所示； 5-2由WSDL文档中的数据格式信息定义Web服务的数据格式(DataFormat)，按照MSDL的关于数据格式的规范，定义Web服务的数据格式为WSDL文档，多维度语义模型中，Web服务的数据格式是用来描述Web服务并说明如何与该Web服务进行通信，如WSDL和XML文档，如式(28)所示； 6)按照MSDL规范定义Web服务的交互语义，从而描述了Web服务之间的动态交互关系，通过服务之间的交互关系可以将众多孤立的服务组织成一个关系网络，交互语义的定义如式(29)所示；
〈IntSem〉::= 〈Competitive〉|〈Collaborative〉|〈Others〉 (29)
〈Competitive〉一 " Exact " | " Plugin " | " Subsume " | " Intersection "(30) 〈Collaborative〉一" Sequential_total" " Sequent ial_part" (31)
〈Others〉—" Community" " MemberOf;/ " Alliance" (32) 6-1定义服务的竞争(Competitive)关系，该关系主要是从两个Web服务的功能相似性的角度定义服务间的关联关系，包括了恒等(Exact)关系、插接(Plugin)关系、继承(Subsume)关系和相交(Intersection)关系，如式(30)所示； 6-2定义服务的协作(Collaborative)关系，该关系主要是从两个Web服务间的功能连接的角度定义服务级关联关系，分为完全后继(Sequential_total)关系和部分后继(Sequential_part)关系,如式(31)所示；6-3定义服务的社区(Community)关系，该关系是由Web服务之间具有因某种属性相同得到； 6-4定义服务的成员(MemberOf)关系，该关系是服务之间存在隶属特性； 6-5定义服务的联盟(Alliance)关系，该关系是指提供商之间签订的战略协议，服务提供商之间的联盟关系势必将会影响到服务的选择。
【文档编号】G06F9/44GK103699391SQ201310755092
【公开日】2014年4月2日 申请日期:2013年12月30日 优先权日:2013年12月30日
【发明者】冯志勇, 张祯, 陈世展, 胡小草 申请人:天津大学