CN101873323B - 基于程序切片技术的Web服务平台 - Google Patents

Abstract

基于程序切片技术的Web服务平台的设计方法提出了通过服务间的依赖关系进行Web服务平台开发的模型。本发明包括服务识别、服务生成、服务发布、服务发现、服务度量以及服务调用这几个功能模块。以用户上传的遗留系统为输入，对遗留系统进行分析，生成构件依赖图，对遗留系统进行构件抽取，进行服务识别。之后为每个服务代码生成WSDL文档，实现服务生成。分析WSDL文档以及WSBD文档，为服务生成带有依赖关系的tModel文档和UDDI文档，完成服务发布。分析所有tModel文档，生成服务依赖图，并对其切片，进行服务发现和服务度量。最终，Web服务平台为每个服务建立一个代理服务，帮助用户方便快捷的调用Web服务。

Description

基于程序切片技术的Web服务平台

技术领域

本发明给出了一种基于程序切片技术的Web服务平台的设计方案，主要解决Web服务平台中所涉及到的服务间的依赖关系问题，属于Web服务的开发和应用领域。

背景技术

Web服务(Web Service，简称WS)是一种面向服务架构的技术，通过标准的Web协议提供服务，采用模块化的方式给出对服务的描述，目的是实现不同平台的应用服务之间的互操作。根据W3C的定义，Web服务应当是一个软件系统，用以支持网络间不同机器的互动操作。网络服务通常是许多应用程序接口所组成的，例如国际互联网的远程服务器端，执行客户所提交服务的请求。尽管W3C的定义涵盖诸多相异且无法切分的系统，不过通常我们指有关于主从式架构(Client-server)之间根据SOAP(简单对象访问协议)协议进行传递XML格式消息。无论定义还是实现，Web服务过程中会由服务器提供一个机器可读的描述(通常基于WSDL)以辨别服务器所提供的Web服务。另外，虽然WSDL不是SOAP服务端点的必要条件，但目前基于Java的主流Web服务开发框架往往需要WSDL实现客户端的源代码生成。一些工业标准化组织，比如WS-I，就在Web服务定义中强制包含SOAP和WSDL。综上所述可以看出，Web服务基于XML技术，使用WSDL对服务进行表示和描述，通过远程过程调用(RPC)的方式，利用SOAP消息进行客户端和用户端的通信。Web服务屏蔽了应用程序的细节信息，从参数输入直接到结果输出，从而实现了应用程序最简便的调用。

Web服务作为近年来Internet研究中的热门课题，因其编程语言和平台的无关性以及使用上的便利性，正受到学术界和工业界的广泛关注。国内外的许多学者和很多科研机构以及大学机构都纷纷投入了大量的研发力量和精力从事Web服务方面的研究。很多公司或者企业也都在进行相关性的Web服务平台的研发工作，试图将Web服务商业化，其中最具代表性的就是IBM和Microsoft公司的Web服务平台，已经有上百家公司或者企业加入了他们的Web服务平台。

一个完善的Web服务平台应包含服务识别，服务生成，服务发布，服务发现，服务度量以及服务调用。IBM和Microsoft公司的Web服务平台注重的是对服务进行发布，服务发现和服务调用。公司或者企业将封装好的服务提交给Web服务平台，服务平台则为其生成描述文档，并将文档公布在网上，其他的公司或者企业就可以通过该文档的描述，按照规范对该服务进行调用，输入服务需要的参数，服务平台就会将调用该服务的结果作为输出返回。

服务发现的目的是根据用户提出的要求(这个要求可以是服务名称，服务的ID，服务的关键词等)，在服务库中对服务进行搜索，将符合用户要求的服务发现出来。在服务发现时，一般存在两种发现方法：基于语法级别的服务发现和基于语义级别的服务发现。基于语法级别的服务发现实际上是基于关键词匹配技术的，将用户提供的关键词和服务库中服务的描述进行匹配，若匹配成功，则将给服务反馈给用户。尽管，关键词匹配技术也一直在发展，但是改进的仅仅是匹配模式和匹配效率，关键词匹配时没有考虑到语义环境，这个技术上的瓶颈使得利用关键词匹配技术的服务发现方法发现的服务往往不是用户需要。现在，基于语法级别的服务发现方法已经被渐渐弃用，取而代之的是基于语义级别的服务发现方法。因为每个服务都有一定的意义，所以在发布服务时，对每个服务进行语义描述，将语义加入到服务描述中。在服务发现时，通过对服务语义的检查，进一步筛选服务发现的结果。许多学者定义了不同的语义对服务进行描述，通过定义Web服务描述模型，规范服务提供者和使用者对Web服务的描述；同时构建了领域功能本体，提出语义标注的机制，从而让用户可以基于语义发现Web服务。许多学者都自己定义了基于Web语义的各种各样的语义来对服务进行描述，在工业界中已经采用的有WSMO，OWL-S，通过这些语义确实达到了高效准确的进行服务发现，但是由于语义定义的复杂性，基于语义的服务发现技术代价比较高。

W3C在制定Web服务标准时，没有制定关于服务发现的标准，而在实际中一般采用UDDI(统一描述、发现和集成协议)注册中心对服务进行发布和注册，例如IBM和Microsoft公司都是用UDDI注册中心对服务进行发布和注册的。在对某个服务进行发布时，首先会根据它的WSDL文档生成tModel，这是一个服务接口文档，用于发布服务的接口，然后根据WSDL文档生成UDDI文档，这是一个服务实现文档，用于记录调用该服务时候所需要查看的WSDL文档的位置。UDDI注册中心通过建立黄页，白页，绿页来对发布的服务进行分类管理。

服务的度量也是Web服务中研究的一个热门，一个服务的质量的好坏直接关系到服务结果的准确性以及调用服务的效率性。近年来，许多研究者都立足于服务的本质，即将一个服务看做是一个可以运行的软件，从软件度量角度去评价一个服务的好坏。有学者提出用Petri网来描述各种复杂结构的系统，并介绍一种自底向上的可靠性计算过程，该过程能对并行结构进行分解和综合计算，高效、准确地计算出系统的可靠性，该方法从兼顾效率和使用范围这两方面入手，估算出组件对系统的重要性，从而大大增强了可靠性评估在服务度量时的作用。

在本发明中我们创新性的使用了程序切片技术。程序切片的思想是于1979年在Mark Weiser博士论文中首次被建立的，程序切片在程序理解、分析、调试以及软件的测试、度量和维护等方面有着广泛的应用。程序切片可以被划分为前向切片和后向切片：前向切片包含受该变量影响的所有语句和断言；后向切片包含影响该变量的所有语句和断言。程序切片还可分为静态切片和动态切片方法：静态切片仅仅在静态程序中被使用，动态切片考虑输入值所带来的影响，更方便分析切片，但是存在着有效性的限制。直观上讲，程序切片技术可以根据服务间的依赖关系来发现服务所依赖的其他服务。在Web服务中，服务是与语言无关的，理论上，这个服务可以是使用任意语言编写的，可以是C，Java，Haskell等等一系列的语言。其中Haskell是现代的、描述式的、高价的、纯函数式程序设计语言，具有代码简洁、安全可靠、无副作用、易扩展、易理解、高组合性等特性，它还拥有表达力强的语法，以及丰富的内置数据类型，包括任意精度的整数和有理数。国内外已有越来越多的程序设计爱好者使用该语言，用该语言实现的软件系统也越来越多，规模也越来越大。考虑到该Web服务平台的安全性和易用性，采用Haskell语言来开发本发明中的Web服务平台系统。

由于近年来Web服务还处于研究中，虽然IBM和Microsoft公司已经实现所谓的Web服务平台，但是他们的平台功能还不够完善，只包含服务发布，服务发现和服务调用这几个功能，没有完全实现Web服务的基本框架，至今W3C仍没有制定相关的Web服务平台标准，国内外对服务平台框架设计的研究也如火如荼，可惜至今仍没有出现完善实现Web服务平台框架的技术。本发明从另一个角度出发，从遗留系统出发，根据遗留系统构件之间的依赖关系，使用程序切片技术实现服务识别，服务生成，服务发现，服务发布，服务发现，服务度量以及服务调用。目的是通过对Web服务平台中需要实现的每个功能的详尽研究，设计出具有自主知识产权的Web服务平台，以期能够达到进一步推动Web服务的发展。

参考文献：

[1]Web-Service website，2009.http://en.wikipedia.org/wiki/Web_service.

[2]张迎周，徐宝文.一种新型形式化程序切片方法.中国科学 E辑：信息科学，2008，38(2)：161-176.

发明内容

技术问题：本发明的目的是提出一种基于程序切片技术的Web服务平台设计方法。该方案从遗留系统中构件之间的依赖关系出发，对遗留系统进行分析，构建一个识别服务以及对服务进行设计管理的服务平台。针对现有服务平台在功能上的匮乏以及在服务发现上存在的效率和准确率上的技术瓶颈。

技术方案：本发明着手于服务构件之间的依赖关系，结合程序切片技术，构建一个功能完善的Web服务平台。最终目的是开发一个基于程序切片技术的包含服务识别、服务生成、服务发布、服务发现、服务度量以及服务调用等功能的Web服务平台。

在本发明中，所有的功能模块都是基于程序切片技术的。服务的识别是Web服务平台产生服务的基本模块，利用服务识别功能从遗留系统中识别出服务，然后利用生成和发布功能将识别出的服务进行发布，通过服务度量功能可以给出对服务的评价。用户可以通过服务发现功能来查找自己需要的服务，然后使用服务调用功能对服务进行调用。每个模块的具体功能与实现方法如下：

(1)服务识别：在进行服务识别之前，用户需先上传遗留系统和服务发布描述文件WSBD文件(该文件指定遗留系统中的哪些构件将被作为服务发布出来)至Web服务平台，然后Web服务平台就会根据WSBD中的信息对遗留系统进行分析，生成构件依赖图，再对构件依赖图进行切片操作，生成子图，最终从遗留系统中抽取出需要被发布成为服务的构件。服务识别完成的是构件抽取的功能，最终生成的是服务的切片代码。

(2)服务生成：服务识别的结果只是生成了服务的切片代码，而在服务发布之前必须先进行服务生成，确切地说，是生成服务描述文档WSDL。Web服务平台对服务的切片代码进行解析，获取服务的参数、返回类型等在生成WSDL文档时有用的信息，然后对这些信息进行处理，最终生成WSDL文档。

(3)服务发布：服务发布分为两个步骤，一是生成带有依赖关系的服务接口文档tModel，二是生成统一描述、发现和集成文档UDDI。在生成tModel文档时，也会对服务的切片代码进行分析，得到此服务所依赖的其他服务，并将这些依赖关系记录到tModel文档中，生成带有依赖关系的tModel文档。在生成UDDI文档时，Web服务平台会对服务生成时生成的WSDL文档和用户上传的WSBD文件进行解析，生成UDDI文档。

(4)服务发现：Web服务平台就会将所有的带有依赖关系的tModel文档进行解析，根据其中的依赖关系生成服务依赖图(SDG)，并根据用户服务发现的要求，找到一个合适的切片节点，对SDG进行切片得到切片后的服务依赖子图，向用户列出子图中记录的服务的信息(这些信息从UDDI文档中获取)就实现了服务发现功能。

(5)服务度量：在度量服务质量好坏时，Web服务平台将该服务的依赖图作为计算单元，基于图论知识，利用图的性质，使用程序切片技术，以图中节点的个数，边的个数以及图的层次为参数计算该服务的内聚度以及它与其他服务之间的耦合度。

(6)服务调用：Web服务平台会为每一个服务生成代理服务。用户输入一个服务运行时所需要的参数，然后Web服务平台就会通过代理服务使用HTTP协议将参数传给服务器端的服务，然后服务运行得到结果，最后仍通过代理服务使用HTTP协议将返回结果返回给用户。

具体方法如下：该方法以图论知识为理论基础，以程序切片为技术手段，提出了通过服务间的依赖关系进行Web服务平台开发的模型；该方法包括服务识别、服务生成、服务发布、服务发现、服务度量以及服务调用这几个功能模块；该方法以企业或者公司的上传给服务平台的遗留系统作为输入，对遗留系统中的构件进行分析，结合程序切片技术完成Web服务平台的各种功能，始终结合程序切片技术，解决服务之间的依赖关系问题，所包含的步骤为：

步骤1：用户向Web服务平台上传遗留系统和服务发布描述文件WSBD，

步骤2：对遗留系统进行语法分析，生成这个遗留系统的抽象语法树AST，抽象语法树是一个多叉树，树的根节点是这个遗留系统的名称，根节点的下面是N个记录构件依赖关系的多叉子树，子树中的儿子节点是父节点所依赖的构件，

步骤3：根据步骤2的抽象语法树生成构件依赖图，

抽象语法树记录了一个遗留系统中所有构件之间的依赖关系，包含可能存在的隐式依赖，只要分析这个抽象语法树，除去构件的参数，返回类型，在遗留系统代码中的位置等信息，只将某个构件依赖哪些其他构件这个信息从抽象语法树中抽取出来，然后用图显示所有的依赖关系，

步骤4：根据切片标准，将步骤1中服务发布描述文件WSBD中记录的要被发布成服务的构件作为切片节点即切片的起始点，对函数依赖图进行切片操作；以某个构件为切片的起始点，对构件依赖图进行切片，得到这个构件所依赖的其他所有构件，切片的结果包括直接，间接，隐式依赖关系，根据这些依赖关系生成构件依赖子图，构件依赖子图中记录就是要从遗留系统代码中抽取出来的构件，

步骤5：将步骤2生成的抽象语法树和步骤4生成的函数依赖子图进行比较，删除抽象语法树中没有被记录在函数依赖子图中的函数，生成一个抽象语法子树，

步骤6：将抽象语法子树和遗留系统源码进行比较，将抽象语法子树中记录的构件的定义从遗留系统中抽取出来，生成切片代码，

步骤7：对步骤6中生成的服务的切片代码进行解析，获取服务的参数、返回类型等信息，然后对这些信息进行处理，最终生成服务描述文档WSDL，完成Web服务的生成，

步骤8：对步骤6中生成的服务的切片代码进行分析，得到此服务所依赖其他的服务，将这些服务记录到这个服务的服务接口文档tModel中的依赖元素<dependences>元素中，并为此服务生成服务描述以及接口标识值tModelKey，将他们写入服务接口文档tModel中，完成服务接口文档tModel的生成，

步骤9：对步骤1中的服务发布描述文件WSBD、步骤7中的服务描述文档WSDL以及步骤8中的服务接口文档tModel进行分析，获得服务的作者、服务的遗留系统名称、服务的公司或者企业名称、接口标识值tModelKey，并为每个服务生成一个服务标识值serviceKey，将这些信息进行处理，按照统一描述、发布和集成文档UDDI的生成规则，为一个用户上传的所有服务生成一个UDDI文档，

步骤10：Web服务平台为步骤8中的服务接口文档tModel和步骤9中的UDDI文档分配网络中的地址，使得用户可以通过网络访问到服务接口文档tModel和UDDI文档，即将服务接口文档tModel和UDDI文档的接口暴露到网络中，实现Web服务的发布，

步骤11：对服务注册表进行更新，将步骤10中的发布的服务加入到服务注册表中，并将每个服务的作者、发布者、服务描述、接口标识值tModelKey、服务标识值serviceKey这些信息详细记录到注册表中，方便Web服务平台进行查看和管理，

步骤12：对所有已经发布的服务的接口文档tModel进行解析，得到服务平台中所有服务之间的服务依赖关系，生成服务依赖图SDG，

步骤13：对步骤12中的SDG图进行切片，为每个服务生成一个以该服务为切片节点的服务依赖子图，然后基于图论知识，利用图的性质，使用程序切片技术，以图中节点的个数，边的个数以及图的层次为参数计算单个服务的内聚度以及它与其他服务之间的耦合度，在进行服务度量时，使用了如下的定义：

定义1：图的体积用V表示

假设图中节点的总个数为n个，图的层次为m层，那么这个图的体积V＝n*m，

定义2：内聚度用COH表示

假设图中边的条数为e条，图的体积为V，那么这个图所代表的模块的内聚度COH＝e/V，

内聚度是用来度量图单位体积里所包含的边的条数的，单位体积里包含的边的条数越多，那么内聚度就越强，反之，如果单位体积里包含的边的条数越少，那么内聚度就越弱，

定义3：依赖率用η表示

用一个依赖图的两个子图A，B分别代表两个模块，假设图A中有n₁个节点与B中的节点存在边，图B中有n₂个节点与A中的节点存在边，则A对B的依赖率η_A＝n₂/n₁，B对A的依赖率η_B＝n₁/n₂，

依赖率反映的是一个图对另一个图的依赖程度，依赖率越大，表示依赖程度越大，反之亦然，

定义4：耦合度用COU表示

假设子图A中的节点与子图B中的节点存在的边的条数为e₁条，A对B的依赖率为η_A，那么A对B的耦合度为COU_A＝e₁*η_A；假设子图B中的节点与子图A中的节点存在的边的条数为e₂，B对A的依赖率为η_B，那么B对A的耦合度为COU_B＝e₂*η_B，

步骤14：将所有的服务操作的类型都转化为XML格式的，Web服务在数据传输与显示的时候都是基于XML的，将类型转化成XML格式有助于高效传输和正确显示，

步骤15：Web服务平台会为每一个服务生成代理服务，用户输入某个服务运行时的参数，然后Web服务平台的客户端将此参数封装进SOAP请求消息中，将SOAP请求消息打包成HTTP的包，使用HTTP协议传输到服务端，服务端进行解析取出参数，传递给服务运行，将运行的结果封装到SOAP反馈消息中，同样是用HTTP协议传输给客户端，客户端解析得到服务的运行结果，

步骤16：用户向服务平台输入需要发现某类服务的特征，可以是服务的名字、服务的接口标识值tModelKey、服务的描述等，然后Web服务平台就会在服务注册表中进行搜索，找到最合适的一个服务，之后就将这个服务作为切片节点，对步骤12中的服务依赖图SDG进行切片，生成切片后的该服务的依赖子图，依赖子图中记录的服务就是服务发现的结果，

步骤17：调用步骤16中发现的服务，输入中服务的参数，Web服务平台就会调用步骤15中的代理服务，最终返回服务调用的结果，完成服务发现后对服务的调用。

有益效果：作为Web服务平台，本发明基本上实现了Web服务平台所应该具有的功能。具有以下的一些特点和创新之处：

粗粒度的程序切片技术：本发明中使用的程序切片技术是基于构件依赖图的程序切片，它不同于传统的程序切片在断言或者语句的细粒度级别上的切片方法，它属于一种粗粒度的切片方法，在这种切片方法中，最小单位是一个构件，对比细粒度的切片方法，粗粒度的切片方法有如下的优点：

●模块性好：粗粒度的切片对象是构件，构件在遗留系统中并不是某个单独的语句，而是一个定义块。Web服务主要体现了一个封装的概念，因此从遗留系统中抽取出来的东西是要具有模块性的，所以粗粒度的切片方法便于将构件抽取出来进行封装。

●精确度高：粗粒度的切片方法将一个定义块作为整体从遗留系统中抽取出来，而不去考虑这个定义块里面变量，语句之间关系的这些细节问题，所以可以精确地抽取出需要的构件。

●可复用性强：粗粒度的切片方法可以将某个构件以及它所依赖的其他所有的构件的定义都抽取出来放在一个源代码文件中，这个源代码文件经过少量修改甚至不需要修改就可以编译。当别人需要调用这个构件的时候，只需要使用切片后的代码。

利用切片技术对遗留系统进行构件抽取：本发明从企业或者公司的遗留系统出发，对遗留系统进行分析，因为遗留系统中的每个构件之间都存在着互相依存的关系，构件之间存在着相互调用。一个遗留系统中所有构件之间的依赖关系对于理解遗留系统，分析遗留系统以及切分遗留系统都可以起到很重要的作用。本发明对遗留系统中的所有构件进行分析，从中抽取出所有构件之间的依赖关系，得到一个构件依赖关系图，然后用程序切片技术来分析这个构件依赖图，将某一个构件作为切片节点，对构件依赖图进行切片，得到这个构件所依赖的其他所有构件。将所有切片后得到的构件的定义从遗留系统中抽取出来，生成一个切片代码，这个代码就包含了运行这个构件所需要的所有的、最精简的代码，从而实现源代码的切分，达到生成服务代码的目的。通过对遗留系统的构件抽取可以使遗留系统能够达到更高的构件复用率。

基于程序切片技术的服务发布：本发明中的tModel文档与传统的tModel文档相比较，除了是一个服务的技术接口外，同时也是一个服务的依赖关系描述，因为我们在本发明中的tModel文档中加入了<dependences>元素，用来记录一个服务所依赖的其他服务。我们根据程序切片对遗留系统的切片结果(一个服务所依赖的其他所有服务)，将该结果记录到<dependences>元素中。然后分析所有服务的tModel文档就可以得到所有服务之间的依赖关系。通过带有<dependences>元素的tModel文档，Web服务平台可以将所有的服务联系起来。

基于程序切片技术的服务发现：在Web服务中，服务之间都是相互依存的，他们之间都存在着依赖关系，这种依赖关系可以构建成服务依赖图。在服务发布时候，tModel文档中就记录了服务之间的依赖信息，通过分析所有的tModel文档就可以生成服务依赖图。服务发现时，Web服务平台根据用户提供的关键词等信息，找到一个合适的服务，然后以这个服务为切片节点对服务依赖图进行切片，将该服务依赖的其他所有服务也作为服务发现的结果反馈给用户。本发明中用到的发现方法不同于传统的关键字匹配的服务发现方法，而是利用软件“服务”的本质，并结合程序切片技术，使服务发现效率更高，更强，更方便用户使用。

基于图论和程序切片技术的服务度量：在软件工程中经常使用内聚度和耦合度来度量一个软件的质量。一个服务就可以看成是一个软件，所以本发明中使用内聚度和耦合度这两个指标来对服务进行度量。不同于软件工程中的内聚度和耦合度的定性分析方法，本发明中对内聚度和耦合度进行了定量计算，我们对服务的依赖图以及切片后的服务依赖子图进行分析，基于图论的知识，将依赖图中节点的个数，边的个数以及图的层次作为参数，提出并实现了定量计算该服务的内聚度以及它与其他服务之间的耦合度的算法。通过服务度量，可以在用户进行服务选择时提供一些参考。

便捷的服务调用：在很多的已有的Web服务平台中，服务调用的过程是首先用户向服务端发送SOAP请求消息，这个消息中包含了用户提供的参数，然后这个请求会被服务器接受并解析，得到参数，将参数传递给服务程序，服务程序运行得到结果，并将其封装到SOAP反馈消息中，再发送给用户。用户最终得到的是一个SOAP反馈消息，用户可以通过解析SOAP反馈消息得到服务运行结果。而在本发明中，Web服务平台为每个服务生成一个代理服务，用户只需要提供服务的参数，然后代理服务会自动完成发送SOAP请求消息到最终解析SOAP反馈消息得到返回结果的过程。所以，本发明中的服务调用实现了从参数的输入到服务运行结果的输出，更方便用户使用，也更便捷。

附图说明

图1是本发明的Web服务平台的整体流程框图。

图2描述了利用程序切片技术进行构件抽取的过程。

图3描述了从服务描述文档WSDL生成服务接口文档tModel的过程。

图4描述了从服务描述文档WSDL生成统一描述、发现和集成文档UDDI的过程。

图5描述了从服务描述文档WSDL生成SOAP消息的过程。

图6给出了在服务调用时，服务端和客户端SOAP消息的产生、解析以及传输的过程。

具体实施方式

本发明中基于程序切片的Web服务平台包含服务识别、生成、发布、发现、度量以及调用等功能。图1给出了本发明平台的一个整体的流程框图，描述了各个模块的作用以及模块之间的联系。下面的内容是对本发明中的Web服务平台各个功能在实现上的详细描述。

1，服务识别

本发明中的的Web服务平台是从遗留系统作为研究的基础的。公司或者企业上传遗留系统，服务平台从遗留系统中识别出服务，然后对其进行发布，发现以及管理等其他一系列的操作。本节着重讲述如何从遗留系统中识别出服务。

一个遗留系统中存在着很多的构件，因此在进行服务发布前，先要将要发布成服务的构件识别出来。公司或者企业有权利选择将哪些构件作为服务发布出来，哪些不需要发布出来。因此，在上传遗留系统的时候，公司或者企业还需要上传一个服务发布描述文件WSBD。

在对遗留系统切片进行构件抽取之前，先对服务发布描述文件进行解析，从中获得要作为服务发布的构件的名称以及相关的其他信息。得到要被发布成服务的构件名后，将这些构件作为起始节点对遗留系统进行切片，得到最终的切片代码，实现构件的抽取。图2给出了利用程序切片技术进行构件抽取的过程，具体步骤如下所示：

步骤1：将遗留系统进行语法分析，生成这个遗留系统的抽象语法树AST(abstract syntax tree)。抽象语法树是一个多叉树，树的根节点是这个遗留系统的名称，根节点的下面是N个记录构件依赖关系的多叉子树，子树中的儿子节点是父节点所依赖的构件。

步骤2：根据步骤1的抽象语法树生成构件依赖图。

抽象语法树记录了一个遗留系统中所有构件之间的依赖关系(包含可能存在的隐式依赖)，只要分析这个抽象语法树，除去构件的参数，返回类型，在遗留系统代码中的位置等信息，只将某个构件依赖哪些其他构件这个信息从抽象语法树中抽取出来，然后用图显示所有的依赖关系。

步骤3：根据切片标准，选择切片节点(切片的起始点)，对函数依赖图进行切片操作。

以某个构件为切片的起始点，对构件依赖图进行切片，得到这个构件所依赖的其他所有构件。切片的结果包括直接，间接，隐式依赖关系，根据这些依赖关系生成构件依赖子图。构件依赖子图中记录就是要从遗留系统代码中抽取出来的构件。

步骤4：将步骤1生成的抽象语法树和步骤3生成的函数依赖子图进行比较，删除抽象语法树中没有被记录在函数依赖子图中的函数，生成一个抽象语法子树AST′。

步骤5：将AST′和遗留系统源码进行比较，将AST′中记录的构件的定义从遗留系统中抽取出来，生成切片代码。

2，服务生成

对遗留系统进行服务识别后，要为每一个服务的切片代码生成相应的服务描述文档WSDL，有了这个文档，才算生成了一个Web服务。WSDL文档也是基于XML格式的，它提供了一个描述服务的模板。

为了方便生成WSDL文档，定义了如下的一个新类型来记录WSDL中一些重要元素的内容。

data Opr_Info＝{Opr_InN，Opr_InT，Opr_OutT，Opr_Name}

类型Opr_Info有四个子类型：Opr_InN(输入参数的名称)，Opr_InT(输入参数的类型)，Opr_OutT(返回值的类型)，Opr_Name(服务中操作的名称)。

WSDL文档中的<message>和<portType>元素可以通过类型Opr_Info生成，而Opr_Info类型可以通过分析服务的代码得到。而WSDL文档中的<binding>元素主要定义了服务端和客户端的传输协议，它告诉服务端和客户端用哪种方式进行通信，<service>元素则描述了一个服务的细节信息，例如服务的名称，服务在客户端存放的地址等。

一个最基本的完整的WSDL文档包括<message>，<portType>，<binding>和<service>元素。只要将这四个元素结合到一起就可以生成一个完整的WSDL文档。

3，服务发布

为服务生成WSDL文档完成服务的生成后，要将服务进行发布。只有发布的服务才在网络中暴露接口，才能被外界访问到。

W3C还没有制定服务发现时的标准，现在最常用的是用UDDI注册中心进行发布。在UDDI注册中心有四种数据类型：businessEntity，businessService，bindingTemplate以及tModel。

businessEntity提供关于公司或者企业的信息，可以包含一个或多个businessService，这个公司或者企业是服务提供者。Web服务的技术和业务描述在businessService和其bindingTemplate中被定义。每个bindingTemplate包含一个对一个或多个tModel的引用。tModel被用于定义服务的技术接口。

一个完整的WSDL文档包括服务接口和服务实现。服务接口描述了一个服务的抽象的定义，在UDDI注册中心将服务接口发布成tModel文档。服务实现描述了服务的实例，WSDL中的服务实例(<service>元素)在UDDI注册中心将被发布成UDDI文档。

将一个服务进行发布需要两个步骤：一是将服务接口发布成tModel，二是将服务实现发布成UDDI文档。

3.1 带有依赖关系的tModel

本本发明中，我们对传统的服务接口文件tModel进行扩展，增加一个依赖元素<dependences>元素。我们用这个元素来记录一个服务所依赖的其他所有服务。然后通过分析UDDI注册中心的所有tModel，将其中的依赖关系抽取出来，生成服务依赖图。可以对服务依赖图进行切片以此来发现服务。

传统的tModel是一个Web服务的接口，它描述服务的名称，服务所属的公司或者企业以及通用唯一识别码(UUID)等信息。tModel的名称根据WSDL中的targetNamespace设置，描述是根据与definitions元素相关联的documentation元素设置的，overviewURL被设置为WSDL服务接口文档可通过网络访问到的位置。

在生成一个tModel文档之前，需要对服务生成的WSDL文档进行解析获得有用的信息。定义了如下数据类型来记录需要用到的WSDL中的信息。

data WSDLInfo＝{TargetNamespace，Document，BindingName，PortTypeName}

TargetNameSpace记录了WSDL文档所在的服务端的地址，Document是对服务的描述，BindingName记录的是服务接口名称，PortTypeName记录的是服务的名称。

事实上，没有UDDI注册中心没有哪个服务是绝对孤立存在的，每个服务都可能会依赖其他的服务，就像遗留系统中的构件之间存在依赖关系一样。因此，我们在tModel中加入了<dependences>元素，<dependences>元素有很多的<dependence>子元素，每一个子元素都记录所依赖的一个服务。

将这个<dependences>元素加入到传统的tModel中就可以生成带有依赖关系的tModel。这些tModel文档对后面的服务发现中生成服务依赖关系有巨大的作用。图3描述了从服务描述文档WSDL生成服务接口文档tModel的过程。

3.2 UDDI文档

UDDI文档也是一个基于XML格式的文件，在这个文件中，它包含businessEntity，businessService和businessTemplate这三种数据类型。

生成UDDI文档中businessService的name根据WSDL服务实现文档中的service的name设置。description根据service元素中的documentation元素设置。bindingTemplate中的description是根据port元素中的documentation元素设置，accessPoint根据soap:address扩展元素设置，tModelKey被设置到与服务接口文档关联的tModel的UUID，overviewURL是服务实现文档的位置。根据WSDL文档可以很容易地生成一个UDDI文档。图4描述了从服务描述文档WSDL生成统一描述、发现和集成文档UDDI的过程。

将上一小节生成的带有依赖关系的tModel文档和这一小节生成的UDDI文档放到UDDI注册中心，就可以实现服务的发布，用户就可以通过访问UDDI注册中心来进行服务发现。

4 服务发现

对于服务发现，现在通用的一般有两种：基于语法的发现和基于语义的发现。两种方法都有各自的优缺点：

●基于语法级别的发现方法就是关键词匹配技术，在实现上比较简单，但是发现的准确性上比较欠缺，不能够另人满意。

●基于语义级别的发现方法对每个服务本体进行语义描述，在实现上比较复杂，但是在发现的准确性上比较高，发现结果往往还是比较令人满意的。

在本文中的Web服务平台中，我们将提出一种新的服务发现方法，这种发现方法是基于程序切片技术的，与传统的服务发现方法比较，有如下优势：

●立足于服务的本质，在发布服务时，将服务的依赖关系写入到发布的tModel中，通过分析服务的tModel文件得到UDDI注册中心服务之间的依赖关系。

●用程序切片对依赖关系图进行切片，发现服务之间存在的依赖关系。存在着依赖关系的服务必定在功能上会有相似之处，这样保证了服务发现的结果尽可能的都满足用户对功能上的需求，可以在一定程度上保证服务发现的准确性。

在基于程序切片的服务发现方法中，最重要的步骤是获得服务依赖图。每个服务在发布的时候，它所依赖的其他服务被写入了tModel文档中，因此只需对UDDI注册中心所有发布的tModel文档进行分析就可以获得服务依赖图。

生成服务依赖图后，就可以对服务进行发现了。得到一个切片节点的服务，然后对服务依赖图进行切片，这个服务所依赖的其他所有服务就都可以被发现了。

UDDI注册中心提供三种服务发现接口，分别为findAll，findExactUUID和findSlice。findAll接口的作用是将注册中心所有的服务列出。findExactUUID则是通过某一个确定的UUID对服务进行发现。findSlice接口是基于程序切片技术服务发现接口。这个接口需要用户提供字符型的参数，这个参数可以是服务的名称，服务的key，tModel key甚至可以是某个服务的关键字。当findSlice接收到一个参数的时候，它就会在注册中心找到一个最符合要求的服务，然后以这个服务为切片节点，对注册中心的服务依赖图进行切片，最终将切片结果作为服务发现结果返回给用户。

5 服务度量

当服务发布的时候，应该给用户一些关于这个服务质量的好坏的提示。在本发明，我们立足于软件服务的本质，提出了一种基于构件依赖图的内聚度和耦合度算法，用构件的内聚度和构件之间的耦合度来评价服务的质量。

内聚度是指一个模块内部各成分相关联的程度。关联程度越大，则内聚度越强，反之亦然。耦合度是指模块间的相关联程度，关联程度越大，则耦合度越强，反之亦然。通常，人们希望一个模块的内聚度强，而和其他模块之间的耦合度弱。内聚度强说明了模块内部之间的联系比较紧密，而和其他模块间的耦合度弱说明了此模块和其他模块的联系小，互相影响的程度小。在本文中，将遗留系统中抽取出来的几个构件看作是几个模块，借助于构件依赖图来讨论他们自身的内聚度和他们之间的耦合度。下面给出计算内聚度和耦合度的定义。

定义1：图的体积(用V表示)

假设图中节点的总个数为n个，图的层次为m层(这里的层次类似于树的深度)，那么这个图的体积V＝n*m。

定义2：内聚度(用COH表示)

假设图中边的条数为e条，图的体积为V，那么这个图所代表的模块的内聚度COH＝e/V。

内聚度是用来度量图单位体积里所包含的边的条数的，单位体积里包含的边的条数越多，那么内聚度就越强，反之，如果单位体积里包含的边的条数越少，那么内聚度就越弱。

定义3：依赖率(用η表示)

用一个依赖图的两个子图A，B分别代表两个模块。假设图A中有n₁个节点与B中的节点存在边，图B中有n₂个节点与A中的节点存在边。则A对B的依赖率η_A＝n₂/n₁，B对A的依赖率η_B＝n₁/n₂。

依赖率反映的是一个图对另一个图的依赖程度，依赖率越大，表示依赖程度越大，反之亦然。

定义4：耦合度(用COU表示)

假设子图A中的节点与子图B中的节点存在的边的条数为e₁条，A对B的依赖率为η_A，那么A对B的耦合度为COU_A＝e₁*η_A；假设子图B中的节点与子图A中的节点存在的边的条数为e₂，B对A的依赖率为η_B，那么B对A的耦合度为COU_B＝e₂*η_B。

6 服务调用

6.1 SOAP消息的生成和传输

简单对象访问协议(SOAP)是一个基于XML格式的协议，它允许应用程序通过HTTP进行信息交换。访问Web服务所用到的协议就是SOAP协议。

现在的许多应用程序都使用远程过程调用(RPC)来实现相互间的通信，例如DCOM和CORBA。然而，RPC并不是为HTTP设计的，RPC会因为兼容性和安全性的问题被防火墙以及代理服务器阻止。但是，由于现在的服务器和客户端都支持HTTP，所以通过HTTP来实现网络间的相互通信是最好的选择。出于这样的考虑，SOAP协议被提出。它提供了让处于不同平台，不同技术，不同实现环境下的应用程序可以互相通信的方法。

一个SOAP消息就是一小段简单的XML文档。当用户想调用某个已经发布的服务时，他必须向服务器发送SOAP请求。一个SOAP消息包含服务的操作名和操作所需要的参数值。SOAP消息可以通过分析某个服务的WSDL文档而生成。在本发明中，我们所说的SOAP消息只包含两个必须的元素<envelope>和<body>。SOAP消息<body>元素中的name和types的内容来自WSDL文档中的<message>元素。

上面已经提到用HTTP来进行消息的传输，所以要将SOAP消息封装成一个HTTP的包，然后将HTTP的包发送给服务端，服务端对HTTP包中的SOAP消息进行解析并返回调用服务的结果。在发送SOAP消息给服务器前，必须知道服务端的地址(通常称为endpoint)。这个地址也可以通过分析WSDL文档而得到，在WSDL文档中的<service>元素中有一个location的属性，这个属性的值就是endpoint。向这个地址发送SOAP请求，服务端就可以接收到。服务端接收到SOAP请求后，便会对其进行解析，然后返回一个反馈消息，这个反馈消息中包含用户调用服务的结果。图5描述了从服务描述文档WSDL生成SOAP消息的过程。

在传输过程中，我们使用了一个重要的函数runService。runService函数的主要功能是向服务器发送HTTP包，传递参数给服务，并将服务调用结果封装成HTTP包返回给客户端进行解析。runService的代码如下：

runService＝do

  Request request；

--package a SOAP message，named request

  result＝simpleHTTP request operation ；

--use one simple HTTP function to send request package

 case result of

    error→putout(“service error”+error)；

    right soap→case soap of

--if right，return response SOAP message and parse it

           error→putout(“soap error”+error)；

          right body→getbodyContent body；

    --if right，get the content of<body>element

通过runService函数，服务端和客户端之间的通信就可以被建立了。图6给出了在服务调用时，服务端和客户端SOAP消息的产生、解析以及传输的过程。

6.2 代理服务

尽管已经实现了从WSDL生成SOAP消息再到发送给服务器解析并返回反馈SOAP消息的功能，但是在实际的应用中，仍需要一个函数可以自动地完成这些功能，这个函数称之为代理服务。如果这样的函数可以被实现，那么用户只需要提供服务运行的参数值，代理服务就可以自动完成SOAP请求消息的生成和对SOAP反馈消息的解析，最终返回给用户服务调用的结果。代理服务屏蔽了中间的细节，将用户提供的参数作为输入，将服务调用的结果作为输出，使得服务调用更加方便。

为了保证代理服务可以正常地运行，必须符合以下两点要求：

●所有服务操作中用到类型都要被转化为XML格式的。因为Web服务在数据传输与显示的时候都是基于XML的，所以将类型转化成XML格式有助于高效传输和正确显示。

●必须将服务操作作为代理服务的一个参数。因为代理服务实际上调用的还是一个真实的服务，所以必须将真实的服务操作作为代理服务的参数，以期达到代理的目的。

一个XML文件是基于文本的，它仅包含字符类型(String)。因此，服务中用到的所有数据类型都要被转化成XML格式的类型。在Haskell中，定义了一个类来实现这样的转换。

class Xmlable a where

  toContent ::a→[[Content]]

  fromContent ::[[Content]]→a

在这个类中，有两个操作：toContent和fromContent。toContent的目的是将一个任意的类型转化成XML格式的类型，而fromContent则是将一个XML格式的类型转化成它原来的类型(在使用toContent转化成XML格式类型之前的类型)。在Haskell中，只要将某一个类型声明称Xmlable类的实例就可以实现类型转换了。

事实上，代理函数的原型已经在上一小节中给出了，就是runService函数。根据用户给出的服务操作参数生成SOAP请求消息，然后传递给runService函数就可以实现代理服务的功能。在一个服务名称的前加上前缀“ws_”来命名代理服务。与此同时，要将服务操作中用到的类型声明为Xmlable类，达到类型转换的目的。代理服务使得服务调用过程变得简便。

Claims (1)

1.一种基于程序切片技术的Web服务平台的设计方法，其特征在于该方法以图论知识为理论基础，以程序切片为技术手段，提出了通过服务间的依赖关系进行Web服务平台开发的模型；该方法包括服务识别、服务生成、服务发布、服务发现、服务度量以及服务调用这几个功能模块；该方法以企业或者公司的上传给服务平台的遗留系统作为输入，对遗留系统中的构件进行分析，结合程序切片技术完成Web服务平台的各种功能，始终结合程序切片技术，解决服务之间的依赖关系问题，所包含的步骤为：

步骤1：用户向Web服务平台上传遗留系统和服务发布描述文件WSBD，

步骤2：对遗留系统进行语法分析，生成这个遗留系统的抽象语法树AST，抽象语法树是一个多叉树，树的根节点是这个遗留系统的名称，根节点的下面是N个记录构件依赖关系的多叉子树，子树中的儿子节点是父节点所依赖的构件，

步骤3：根据步骤2的抽象语法树生成构件依赖图，

抽象语法树记录了一个遗留系统中所有构件之间的依赖关系，包含可能存在的隐式依赖，只要分析这个抽象语法树，除去构件的参数，返回类型，在遗留系统代码中的位置信息，只将某个构件依赖哪些其他构件这个信息从抽象语法树中抽取出来，然后用图显示所有的依赖关系，

步骤4：根据切片标准，将步骤1中服务发布描述文件WSBD中记录的要被发布成服务的构件作为切片节点即切片的起始点，对函数依赖图进行切片操作；以某个构件为切片的起始点，对构件依赖图进行切片，得到这个构件所依赖的其他所有构件，切片的结果包括直接，间接，隐式依赖关系，根据这些依赖关系生成构件依赖子图，构件依赖子图中记录就是要从遗留系统代码中抽取出来的构件，

步骤5：将步骤2生成的抽象语法树和步骤4生成的函数依赖子图进行比较，删除抽象语法树中没有被记录在函数依赖子图中的函数，生成一个抽象语法子树，

步骤6：将抽象语法子树和遗留系统源码进行比较，将抽象语法子树中记录的构件的定义从遗留系统中抽取出来，生成切片代码，

步骤7：对步骤6中生成的服务的切片代码进行解析，获取服务的参数、返回类型信息，然后对这些信息进行处理，最终生成服务描述文档WSDL，完成Web服务的生成，

步骤8：对步骤6中生成的服务的切片代码进行分析，得到此服务所依赖其他的服务，将这些服务记录到这个服务的服务接口文档tModel中的依赖元素<dependences>元素中，并为此服务生成服务描述以及接口标识值tModelKey，将他们写入服务接口文档tModel中，完成服务接口文档tModel的生成，

步骤9：对步骤1中的服务发布描述文件WSBD、步骤7中的服务描述文档WSDL以及步骤8中的服务接口文档tModel进行分析，获得服务的作者、服务的遗留系统名称、服务的公司或者企业名称、接口标识值tModelKey，并为每个服务生成一个服务标识值serviceKey，对这些信息进行处理，按照统一描述、发布和集成文档UDDI的生成规则，为一个用户上传的所有服务生成一个UDDI文档，

步骤10：Web服务平台为步骤8中的服务接口文档tModel和步骤9中的UDDI文档分配网络中的地址，使得用户可以通过网络访问到服务接口文档tModel和UDDI文档，即将服务接口文档tModel和UDDI文档的接口暴露到网络中，实现Web服务的发布，

步骤11：对服务注册表进行更新，将步骤10中的发布的服务加入到服务注册表中，并将每个服务的作者、发布者、服务描述、接口标识值tModelKey、服务标识值serviceKey这些信息详细记录到注册表中，方便Web服务平台进行查看和管理，

步骤12：对所有已经发布的服务的接口文档tModel进行解析，得到服务平台中所有服务之间的服务依赖关系，生成服务依赖图SDG，

步骤13：对步骤12中的SDG图进行切片，为每个服务生成一个以该服务为切片节点的服务依赖子图，然后基于图论知识，利用图的性质，使用程序切片技术，以图中节点的个数，边的个数以及图的层次为参数计算单个服务的内聚度以及它与其他服务之间的耦合度，在进行服务度量时，使用了如下的定义：

定义1：图的体积用V表示

假设图中节点的总个数为n个，图的层次为m层，那么这个图的体积V＝n*m，

定义2：内聚度用COH表示

假设图中边的条数为e条，图的体积为V，那么这个图所代表的模块的内聚度COH＝e/V，

内聚度是用来度量图单位体积里所包含的边的条数的，单位体积里包含的边的条数越多，那么内聚度就越强，反之，如果单位体积里包含的边的条数越少，那么内聚度就越弱，

定义3：依赖率用η表示

用一个依赖图的两个子图A，B分别代表两个模块，假设图A中有n₁个节点与B中的节点存在边，图B中有n₂个节点与A中的节点存在边，则A对B的依赖率η_A＝n₂/n₁，B对A的依赖率ηB＝n₁/n₂，

依赖率反映的是一个图对另一个图的依赖程度，依赖率越大，表示依赖程度越大，反之亦然，

定义4：耦合度用COU表示

假设子图A中的节点与子图B中的节点存在的边的条数为e₁条，A对B的依赖率为η_A，那么A对B的耦合度为COU_A＝e₁*η_A；假设子图B中的节点与子图A中的节点存在的边的条数为e₂，B对A的依赖率为η_B，那么B对A的耦合度为COU_B＝e₂*η_B，

步骤14：将所有的服务操作的类型都转化为XML格式的，Web服务在数据传输与显示的时候都是基于XML的，将类型转化成XML格式有助于高效传输和正确显示，

步骤15：Web服务平台为每一个服务生成代理服务，用户输入某个服务运行时的参数，然后Web服务平台的客户端将此参数封装进SOAP请求消息中，将SOAP请求消息打包成HTTP的包，使用HTTP协议传输到服务端，服务端进行解析取出参数，传递给服务运行，将运行的结果封装到SOAP反馈消息中，同样是用HTTP协议传输给客户端，客户端解析得到服务的运行结果，

步骤16：用户向服务平台输入需要发现某类服务的特征，可以是服务的名字、服务的接口标识值tModelKey、服务的描述，然后Web服务平台就会在服务注册表中进行搜索，找到最合适的一个服务，之后就将这个服务作为切片节点，对步骤12中的服务依赖图SDG进行切片，生成切片后的该服务的依赖子图，依赖子图中记录的服务就是服务发现的结果，

步骤17：调用步骤16中发现的服务，输入中服务的参数，Web服务平台就会调用步骤15中的代理服务，最终返回服务调用的结果，完成服务发现后对服务的调用。

Images