基于程序切片技术的Web服务平台的制作方法

专利名称：基于程序切片技术的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文档生成tMode 1，这是一个服务接口文档，用于发布服务的接口， 然后根据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/ffeb_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)，并根据用户服务发现的要求，找到一个合适的
6切片节点，对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中的依赖元素〈cbpendences〉 元素中，并为此服务生成服务描述以及接口标识值tModelKey，将他们写入服务接口文档 tModel中，完成服务接口文档tModel的生成，
步骤9 对步骤1中的服务发布描述文件WSBD、步骤7中的服务描述文档WSDL 以及步骤8中的服务接口文档tModel进行分析，获得服务的作者、服务的遗留系统名称、 服务的公司或者企业名称、接口标识值tModelKey，并为每个服务生成一个服务标识值 serviceKey，将这些信息进行处理，按照统一描述、发布和集成文档UDDI的生成规则，为一 个用户上传的所有服务生成一个UDDI文档，步骤10 :ffeb服务平台为步骤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 内聚度用C0H表示假设图中边的条数为e条，图的体积为V，那么这个图所代表的模块的内聚度C0H =e/V,内聚度是用来度量图单位体积里所包含的边的条数的，单位体积里包含的边的条 数越多，那么内聚度就越强，反之，如果单位体积里包含的边的条数越少，那么内聚度就越 弱，定义3 依赖率用n表示用一个依赖图的两个子图A，B分别代表两个模块，假设图A中有ni个节点与B中 的节点存在边，图B中有n2个节点与A中的节点存在边，则A对B的依赖率nA = n2/ni, B 对A的依赖率nB = n,/^,依赖率反映的是一个图对另一个图的依赖程度，依赖率越大，表示依赖程度越大， 反之亦然，定义4 耦合度用C0U表示假设子图A中的节点与子图B中的节点存在的边的条数为ei条，A对B的依赖率 为nA，那么A对B的耦合度为C0UA = ei* nA ；假设子图B中的节点与子图A中的节点存在 的边的条数为e2，B对A的依赖率为nB，那么B对A的耦合度为C0UB = e2* nB，步骤14 将所有的服务操作的类型都转化为XML格式的，Web服务在数据传输与显 示的时候都是基于XML的，将类型转化成XML格式有助于高效传输和正确显示，步骤15 :ffeb服务平台会为每一个服务生成代理服务，用户输入某个服务运行时 的参数，然后Web服务平台的客户端将此参数封装进S0AP请求消息中，将S0AP请求消息打
8包成HTTP的包，使用HTTP协议传输到服务端，服务端进行解析取出参数，传递给服务运行， 将运行的结果封装到SOAP反馈消息中，同样是用HTTP协议传输给客户端，客户端解析得到 服务的运行结果，步骤16 用户向服务平台输入需要发现某类服务的特征，可以是服务的名字、月艮 务的接口标识值tModelKey、服务的描述等，然后Web服务平台就会在服务注册表中进行搜 索，找到最合适的一个服务，之后就将这个服务作为切片节点，对步骤12中的服务依赖图 SDG进行切片，生成切片后的该服务的依赖子图，依赖子图中记录的服务就是服务发现的结 果，步骤17 调用步骤16中发现的服务，输入中服务的参数，Web服务平台就会调用步 骤15中的代理服务，最终返回服务调用的结果，完成服务发现后对服务的调用。有益效果作为Web服务平台，本发明基本上实现了 Web服务平台所应该具有的功 能。具有以下的一些特点和创新之处 粗粒度的程序切片技术本发明中使用的程序切片技术是基于构件依赖图的程序 切片，它不同于传统的程序切片在断言或者语句的细粒度级别上的切片方法，它属于一种 粗粒度的切片方法，在这种切片方法中，最小单位是一个构件，对比细粒度的切片方法，粗 粒度的切片方法有如下的优点 模块性好粗粒度的切片对象是构件，构件在遗留系统中并不是某个单独的语 句，而是一个定义块。Web服务主要体现了一个封装的概念，因此从遗留系统中抽取出来的 东西是要具有模块性的，所以粗粒度的切片方法便于将构件抽取出来进行封装。 精确度高粗粒度的切片方法将一个定义块作为整体从遗留系统中抽取出来， 而不去考虑这个定义块里面变量，语句之间关系的这些细节问题，所以可以精确地抽取出 需要的构件。 可复用性强粗粒度的切片方法可以将某个构件以及它所依赖的其他所有的构 件的定义都抽取出来放在一个源代码文件中，这个源代码文件经过少量修改甚至不需要修 改就可以编译。当别人需要调用这个构件的时候，只需要使用切片后的代码。利用切片技术对遗留系统进行构件抽取本发明从企业或者公司的遗留系统出 发，对遗留系统进行分析，因为遗留系统中的每个构件之间都存在着互相依存的关系，构件 之间存在着相互调用。一个遗留系统中所有构件之间的依赖关系对于理解遗留系统，分析 遗留系统以及切分遗留系统都可以起到很重要的作用。本发明对遗留系统中的所有构件进 行分析，从中抽取出所有构件之间的依赖关系，得到一个构件依赖关系图，然后用程序切片 技术来分析这个构件依赖图，将某一个构件作为切片节点，对构件依赖图进行切片，得到这 个构件所依赖的其他所有构件。将所有切片后得到的构件的定义从遗留系统中抽取出来， 生成一个切片代码，这个代码就包含了运行这个构件所需要的所有的、最精简的代码，从而 实现源代码的切分，达到生成服务代码的目的。通过对遗留系统的构件抽取可以使遗留系 统能够达到更高的构件复用率。基于程序切片技术的服务发布本发明中的tModel文档与传统的tModel文档相 比较，除了是一个服务的技术接口外，同时也是一个服务的依赖关系描述，因为我们在本发 明中的tModel文档中加入了 <d印endences〉元素，用来记录一个服务所依赖的其他服务。 我们根据程序切片对遗留系统的切片结果(一个服务所依赖的其他所有服务)，将该结果记录到〈cbpendences〉元素中。然后分析所有服务的tModel文档就可以得到所有服务之 间的依赖关系。通过带有〈cbpendences〉元素的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 0pr_Info = {0pr_InN, 0pr_InT, 0pr_0utT, 0pr_Name}
类型0pr_Info有四个子类型0pr_InN(输入参数的名称)，0pr_InT (输入参数的 类型)，0pr_0utT (返回值的类型)，0pr_Name (服务中操作的名称)。WSDL文档中的〈message〉和<portType>元素可以通过类型0pr_Info生成，而 0pr_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进行扩展，增加一个依赖元素 <d印endences〉元素。我们用这个元素来记录一个服务所依赖的其他所有服务。然后通过 分析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>子元素，每一个 子元素都记录所依赖的一个服务。将这个〈cbpendences〉元素加入到传统的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 是 t艮据 port 7Π 素中白勺 documentation 7Π 素设置， 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表示)假设图中节点的总个数为η个，图的层次为m层(这里的层次类似于树的深度)， 那么这个图的体积V = n*m。定义2:内聚度(用COH表示)假设图中边的条数为e条，图的体积为V，那么这个图所代表的模块的内聚度COH
=e/V0内聚度是用来度量图单位体积里所包含的边的条数的，单位体积里包含的边的条 数越多，那么内聚度就越强，反之，如果单位体积里包含的边的条数越少，那么内聚度就越 弱。定义3 依赖率(用η表示)用一个依赖图的两个子图Α，Β分别代表两个模块。假设图A中有Ii1个节点与B中 的节点存在边，图B中有Ii2个节点与A中的节点存在边。则A对B的依赖率ηΑ = Ii2Ai1, B 对A的依赖率η β = Ii1Ai2。依赖率反映的是一个图对另一个图的依赖程度，依赖率越大，表示依赖程度越大， 反之亦然。定义4 耦合度(用COU表示)假设子图A中的节点与子图B中的节点存在的边的条数为ei条，A对B的依赖率 为ηΑ，那么A对B的耦合度为COUa = e^nA ；假设子图B中的节点与子图A中的节点存在 的边的条数为e2，B对A的依赖率为ηΒ，那么B对A的耦合度为COUb = e2* ηΒ。6服务调用6. 1 SOAP消息的生成和传输简单对象访问协议(SOAP)是一个基于XML格式的协议，它允许应用程序通过HTTP 进行信息交换。访问Web服务所用到的协议就是SOAP协议。
现在的许多应用程序都使用远程过程调用(RPC)来实现相互间的通信，例如DCOM和C0RBA。然而，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 = doRequest request ；__package a SOAP message, named requestresult = simpIeHTTP request operation ；__use one simple HTTP function to send request packagecase result oferror — putout ( "service error，，+error)；right soap case soap of__if right, return response SOAP message and parse iterror — 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 wheretoContent ::a— [[Content]]fromContent ::[[Content]]— a在这个类中，有两个操作toContent禾口 fromContent。toContent的目的是将一 个任意的类型转化成XML格式的类型，而fromContent则是将一个XML格式的类型转化成 它原来的类型(在使用toContent转化成XML格式类型之前的类型)。在Haskell中，只要 将某一个类型声明称Xmlable类的实例就可以实现类型转换了。事实上，代理函数的原型已经在上一小节中给出了，就是runService函数。根据 用户给出的服务操作参数生成SOAP请求消息，然后传递给runService函数就可以实现代 理服务的功能。在一个服务名称的前加上前缀“ws_”来命名代理服务。与此同时，要将服 务操作中用到的类型声明为Xmlable类，达到类型转换的目的。代理服务使得服务调用过 程变得简便。
权利要求
一种基于程序切片技术的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文档，步骤10Web服务平台为步骤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中有n1个节点与B中的节点存在边，图B中有n2个节点与A中的节点存在边，则A对B的依赖率ηA＝n2/n1，B对A的依赖率ηB＝n1/n2，依赖率反映的是一个图对另一个图的依赖程度，依赖率越大，表示依赖程度越大，反之亦然，定义4耦合度用COU表示假设子图A中的节点与子图B中的节点存在的边的条数为e1条，A对B的依赖率为ηA，那么A对B的耦合度为COUA＝e1*ηA；假设子图B中的节点与子图A中的节点存在的边的条数为e2，B对A的依赖率为ηB，那么B对A的耦合度为COUB＝e2*ηB，步骤14将所有的服务操作的类型都转化为XML格式的，Web服务在数据传输与显示的时候都是基于XML的，将类型转化成XML格式有助于高效传输和正确显示，步骤15Web服务平台会为每一个服务生成代理服务，用户输入某个服务运行时的参数，然后Web服务平台的客户端将此参数封装进SOAP请求消息中，将SOAP请求消息打包成HTTP的包，使用HTTP协议传输到服务端，服务端进行解析取出参数，传递给服务运行，将运行的结果封装到SOAP反馈消息中，同样是用HTTP协议传输给客户端，客户端解析得到服务的运行结果，步骤16用户向服务平台输入需要发现某类服务的特征，可以是服务的名字、服务的接口标识值tModelKey、服务的描述等，然后Web服务平台就会在服务注册表中进行搜索，找到最合适的一个服务，之后就将这个服务作为切片节点，对步骤12中的服务依赖图SDG进行切片，生成切片后的该服务的依赖子图，依赖子图中记录的服务就是服务发现的结果，步骤17调用步骤16中发现的服务，输入中服务的参数，Web服务平台就会调用步骤15中的代理服务，最终返回服务调用的结果，完成服务发现后对服务的调用。
全文摘要
基于程序切片技术的Web服务平台的设计方法提出了通过服务间的依赖关系进行Web服务平台开发的模型。本发明包括服务识别、服务生成、服务发布、服务发现、服务度量以及服务调用这几个功能模块。以用户上传的遗留系统为输入，对遗留系统进行分析，生成构件依赖图，对遗留系统进行构件抽取，进行服务识别。之后为每个服务代码生成WSDL文档，实现服务生成。分析WSDL文档以及WSBD文档，为服务生成带有依赖关系的tModel文档和UDDI文档，完成服务发布。分析所有tModel文档，生成服务依赖图，并对其切片，进行服务发现和服务度量。最终，Web服务平台为每个服务建立一个代理服务，帮助用户方便快捷的调用Web服务。
文档编号H04L29/06GK101873323SQ201010204709
公开日2010年10月27日 申请日期2010年6月21日 优先权日2010年6月21日
发明者周国强, 张卫丰, 张迎周, 杨庚, 符炜, 许碧欢, 陆柳敏, 陈蕾 申请人:南京邮电大学