（计算机软件与理论专业论文）soa服务互操作性的研究.pdf

华 中 科 技 大 学 硕 士 学 位 论 文 华 中 科 技 大 学 硕 士 学 位 论 文 i 摘摘 要要 面向服务的架构思想是指根据需求通过网络对松散耦合的粗粒度的应用组件 (服务)进行分布式部署、组合和使用。这种方式有利于解决异构系统之间在相互通 信、交换数据中发生的困难，实现架构中服务之间的互操作性。但是在服务的实施 过程中仍然存在很多互操作问题。这里所做的工作是基于服务调用接口的实现，通 过相关的测评技术排除调用接口中潜在的互操作问题，从而实现架构中服务的互操 作性。 要充分体现面向服务构架体系中服务之间的互操作性，重点在于准确实现对服 务的描述。在实现服务描述的研究过程中，重点研究对象是基于模块的服务描述语 言。结合服务描述协议和相关规范的分析，通过结构化的方式实现对服务中数据类 型、服务访问方式、通信消息的构建与传递和服务访问地址的描述。并借助 java 反射机制和延伸性标签语言技术，设计并程序实现服务描述协议。 进一步对服务描述协议的程序实现实施一致性测试的方案。分别对服务描述文 档中语言格式规范、数据类型的描述、服务访问入口的描述、通信消息构建与传送 的描述和服务访问地址的描述共 5 个方面进行一致性测试。并结合服务描述文档描 述性验证的策略，最终实现对服务描述的互操作性测试。 针对一致性测试方法和描述性验证策略分别进行相关实验。实验表明，服务描 述的程序实现完成了调用服务所需的完整信息的描述，但是生成的服务描述文档主 要涉及到数据类型和命名空间两类互操作问题。 关键词： 关键词： 面向服务的架构，服务描述语言，互操作性，互操作性测试 华 中 科 技 大 学 硕 士 学 位 论 文 华 中 科 技 大 学 硕 士 学 位 论 文 ii abstract service oriented architecture (soa) is an architecture that aims to achieve distributed deployment, composition, and utilization for loose coupling and coarse grained interacting software agents. soa is conducive to resolve the problems of mutual communication and data exchange between heterogeneous systems and is propitious to achieve high-quality interoperability for the services in the architecture. however, there are some interoperability problems in the process of service implementing. the interoperability problems are resolved by means of the test and evaluation involved technologies, which is based on the service description for soa. in order to achieve high-quality interoperability between services, we must make accurate description of the services in the architecture. we propose an approach which implements the service description for soa. based on the module-based methods for service description and the web service description language (wsdl), we analyze the relevant agreements, standards and protocols for wsdl. the descriptions for data type, service access interface, construction & transfer of communication information and service access entrance in web service are also proposed. using the techniques of java reflection and extensible markup language, a prototype system is developed to implement the service description in the protocol of wsdl. further more, an approach of consistency test on service description for the service description document generated by the prototype system is proposed. we test the consistency of the generated service description document from the following aspects: the format of the service description document, the description of data types, service access interface, construction & transfer of communication information and service access entrance. based on this approach, the interoperability test is implemented on the service description in accordance with the standard confirmation process for common service description documents. finally, the interoperability test and the standard confirmation are proposed in experiments. the experiments show that the documents generated by the prototype 华 中 科 技 大 学 硕 士 学 位 论 文 华 中 科 技 大 学 硕 士 学 位 论 文 iii system contain all the service description information for the services, with the interoperability problems on data type and naming space involved. keywords： soa, wsdl, interoperability, interoperability test 独创性声明独创性声明 本人声明所呈交的学位论文是我个人在导师指导下进行的研究工作及取得的 研究成果。尽我所知，除文中已经标明引用的内容外，本论文不包含任何其他个人 或集体已经发表或撰写过的研究成果。对本文的研究做出贡献的个人和集体，均已 在文中以明确方式标明。本人完全意识到，本声明的法律结果由本人承担。 学位论文作者签名：汪雪琼 日期： 2008 年 6 月 9 日 学位论文版权使用授权书学位论文版权使用授权书 本学位论文作者完全了解学校有关保留、使用学位论文的规定，即：学校有权 保留并向国家有关部门或机构送交论文的复印件和电子版，允许论文被查阅和借 阅。本人授权华中科技大学可以将本学位论文的全部或部分内容编入有关数据库进 行检索，可以采用影印、缩印或扫描等复制手段保存和汇编本学位论文。 保密，在_年解密后适用本授权书。 不保密。 （请在以上方框内打“” ） 学位论文作者签名：汪雪琼 指导教师签名：冯玉才 日期：2008 年 6 月 9 日 日期： 2008 年 6 月 9 日 本论文属于 华 中 科 技 大 学 硕 士 学 位 论 文 华 中 科 技 大 学 硕 士 学 位 论 文 1 1 绪论绪论 1.1 课题背景 课题背景 二十世纪后期以来， 世界经济进入全球一体化和快速增长期， internet 迅速发展， 网络资源呈几何级数激增，计算资源的整合和信息的共享成为当务之急1。要达到 这一目标就需要选择一种具有互操作性的途径。根据 iso2382-1 的定义，互操作性 是指多种功能单元相互通信、执行程序、传递数据的能力，而在整个过程中，功能 调用者不需要知道这些功能单元的实现细节2。这种具有互操作性的途径就是开放 标准。开放标准是指通过应用编程接口、通信协议以及数据和文件格式，使用公开 发布并为公众所认可的技术规范来实现异构系统之间的互操作性3,4。 开放标准的全 部价值在于它对异构系统灵活性的支持，只有采用开放标准才能建立支持异构系统 互联互通、互操作、信息共享、资源整合的统一平台。 面向服务的架构(service-oriented architecture， soa)的实施过程就充分体现了开 放标准的思想。如文献5,6所述，soa 是一种有利于异构系统之间相互通信、交换 数据的符合开放标准的架构，是可以采用虚拟化技术的架构，是一种扩大了互操作 性概念的架构。 soa 最早是 gartner 公司于 1996 年就提出了， 但是它的广为传播却是由于近年 来 web 服务的兴起和普及7。soa 从本质上说是一种理念和体系架构，它的思想 体现在，我们可以根据需求通过网络对松散耦合的粗粒度的应用组件(即服务)进行 分布式部署、 组合和使用。 服务的具体作用可以理解为： 服务提供者完成一组工作， 为服务调用者交付所需的最终结果，最终结果通常会使调用者的状态发生变化，但 也可能改变提供者的状态，或者双方都产生变化8,9。不难看出，soa 就是服务的 集合，在这个集合里服务之间是粗粒度的、松耦合的关系，它们通过简单、精确定 义的接口进行通信。 综上所述，要想真正实施 soa 的架构思想，架构中服务之间的互操作性的实 现显得尤为重要。要实现服务之间的互操作性就要求服务提供者为服务调用者提供 服务调用接口，这个接口的具体实施就是通过一种系统之间共同认可的表示方式对 华 中 科 技 大 学 硕 士 学 位 论 文 华 中 科 技 大 学 硕 士 学 位 论 文 2 服务的部署细节进行描述4,10。如果服务描述本身存在描述不清的地方，就会引起 许多互操作问题，那么服务的互操作性就无从体现11,12。本课题就是在快捷有效地 实现服务描述的基础上，研究如何测试和解决服务描述中的互操作问题。 1.2 国内外概况 国内外概况 互操作问题出现在计算机行业发展的早期阶段，当时开发软件是为了适应某一 个特定的硬件，而在近期则是为了适应特定配置的操作系统1,13,14。然而，操作系 统经常会发生变更，并且它所依附的硬件也会发生更新和升级。所以，尽管计算机 应用程序的实现使用的是一些更高级别的在抽象层中进行开发的编程语言，也会受 到操作系统变更的冲击，再加上各个行业领域的知识结构的差异，使得应用组件之 间的互操作问题层出不穷15。 1. 软件的互用性 软件互用性一般定义为：软件系统在不同的网络环境、操作系统和应用程序间 共享信息的能力2。 计算机在体现出重要的商业用途之后，人们开始关注应用程序的接口连接和整 合。然而，商业操作的自动化和相关投资保护，使得软件的互用性问题变得更加尖 锐。如文献 16,17 中的描述，在企业计算环境中，必须面临的操作环境是：由各 类操作系统、数据库和应用程序所组成的复杂系统，它们通过不同的编程语言、数 据结构以及调用接口来进行交互，将这种系统称为异构系统。这种异构系统发展迅 速，已经成为企业计算环境的主流。如何保证这些异构系统之间的互操作性，使这 些异构系统能够在一个公共运行平台上紧密地集成，已成为目前信息化建设中最核 心、最关键、最基础和最具有全局性的问题，其重要性超过了安全性、服务质量和 功能性等其他方面。目前，制约软件互用性的因素具体表现在两个方面18。 (1) 数据资源方面 对于相同的数据资源，不同的机构会根据不同的标准规定数据的格式；各个机 构会根据自己的需求对数据资源采用不同的存储格式；在对数据资源进行整理和保 存的过程中，不同的机构会有自己惯用的命名资源的方式；如果涉及到商务运行方 式，各个机构会使用不同的技术对数据资源加密。 华 中 科 技 大 学 硕 士 学 位 论 文 华 中 科 技 大 学 硕 士 学 位 论 文 3 (2) 系统资源方面 由于各个机构的软件开发方式不同，软件所依附的系统平台环境之间会存在较 大的差异， 常常会发生系统不兼容的问题。 当前有多种创建软件服务的系统平台(主 要是.net 和 j2ee)，但每种平台都习惯于使用自身的协议(本质上通常是二进制代 码)来实现机器间的集成。 因此， 跨平台的应用程序在数据共享方面的能力相当有限。 认识到这些限制后，人们一直在致力于建立有关数据格式和数据交换方面的标 准，通过一种协调统一的方式实现“不论服务采用何种软件，使用何种硬件，都能 够跨越这一传统的界限以 web 的形式无缝地将它们集成在一起” 这远景目标。 目 前，这一目标已经迅速发展成为一种新的计算范例。该目标的核心就是是互操作性 概念， 即不同系统能够无缝地进行通信和共享数据， 这也是 web 服务追求的目标19。 2. web 服务的互操作性 web 服务是一种可以用标准 internet 协议来访问的可编程应用逻辑；从另一个 角度来说， web 服务是有关机器间和应用程序间透明通信的、 借助于 web 标准的具 体实现20。 (1) web 服务的发展现状 web 服务作为在网络异构平台下的软件调用方式，近几年来发展迅猛，而互操 作性是 web 服务的特色，同时也是其顺利实现的保证。大多数情况下，web 服务 之间的交互基于延伸性标签语言(extensible markup language，xml)和超文本传输 协议(hypertext transfer protocol，http)。xml 是一个基于文本的开放标准，服务 之间进行通信的消息就是由 xml 组成的，而消息的传递则是基于 http 协议。消 息通常通过http从一个系统进入另一个系统， 接受消息的系统对该消息进行解释， 并做出相应的处理，然后发送另一个消息作为响应。在 web 服务的领域里主要有 三种基于 xml 的方法用于发送消息，它们是简单对象访问协议(simply object access protocol，soap)、代表性声明传输(representational state transfer，rest) 和 xml-rpc。这三种方法最重要的区别在于对消息处理的方式21。由于在实际应 用中需要考虑到安全、互操作性等问题，soap 方式得到了更好的推广。 一直以来，web 服务缺乏统一的协议版本的指导，又因为开发工具和实现语言 的不同以及部署环境的差异，使得在服务的实现中存在许多互操作问题22。为了保 华 中 科 技 大 学 硕 士 学 位 论 文 华 中 科 技 大 学 硕 士 学 位 论 文 4 证 web 服务能较好地实现互操作性，一种方法是尽量隐藏 web 服务中底层的访问 协议(如 soap)的复杂性，建立一种独立的、通用的调用 web 服务的方法，通过某 种方式对服务加以描述，并提供了一组标准的应用程序调用接口(application programming interface，api)来调用 web 服务24,25。这样 web 服务实现层就变得透 明，不管 web 服务以何种形式提供，开发人员都可以直接与 web 服务的抽象形式 进行交互。另一种方法就是通过互操作性测评来保证 web 服务的互操作性26。测 评的方法是通过严格的互操作性测评规范，以及测试评价标准来运用测试工具对已 经实现的 web 服务进行互操作测评，从而发现 web 服务实现中的互操作问题。通 过所发现问题的来源，完善 web 服务的相关规范和 web 服务实现本身的功能，从 而提高 web 服务的互操作性。 (2) web 服务的互操作问题 web 服务规范由十几个规范组合而成的，而且相关规范还在不断扩大。由于规 范本身的开放性，以及同一规范不同版本之间的差异性，导致基于这些 web 服务 规范的实现平台和 web 服务实例出现了一些互操作性问题。这些互操作问题主要 体现在两个方面。 1 soap 消息的解析问题 服务交互使用的 soap 消息是基于 xml 的，它具有一个简单的结构：信封、 信息头及其有效负载。在实际通信中，消息所包含的内容往往很复杂，就会出现接 收 soap 消息的服务无法理解消息中的内容，从而不能做出响应27。 2 规范描述不清 web 服务互操作性的实现需要依附一定的规范，如 soap、web 服务描述语言 (web service description language，wsdl)、服务发现和集成(universal description discovery and integration，uddi)等，而这些规范本身存在很多含糊不清的语言和示 例28。这样，在协议的实现过程中就会带入很多潜在的互操作问题。 由以上分析得知，互操作性的实现需要从两方面入手：第一，构建结构良好、 内容清晰明了的 soap 消息；第二，在实现相关协议的时候，需要通过一定的测评 手段排除协议实现过程中带入的互操作问题。因为构建 soap 消息依据的是该消息 所访问服务的服务描述文件，所以解决 web 服务的互操作问题的落脚点是 web 服 华 中 科 技 大 学 硕 士 学 位 论 文 华 中 科 技 大 学 硕 士 学 位 论 文 5 务描述文件。 3. web 服务的互操作性测评技术 目前 web 服务互操作性测评技术发展迅速，优秀的互操作性测试工具和科研 成果不断涌现，这里主要介绍以下 3 种测评技术。 (1) soaptest parasoft 公司研究开发的商业产品 soaptest 提供了一个跨越整个服务开发生命 周期的 web 服务测试资源30，它鼓励团队共享测试，并且提供了单元测试套件， 扩充了 web 服务的负载测试。它最突出的功能就是异步 web 服务确认和复杂的安 全验证。 (2) soap performer soap performer 是一种 soap 协议性能测试工具， 用以模拟多个 soap 客户端 向 soap 服务器端发送请求的场景31。 该工具通过解析服务描述文件或者监听网络 的方式生成测试脚本，然后利用脚本进行性能/压力测试。 (3) web 服务互操作性基本大纲 web 服务互操作性组织分别于 2004 年 4 月和 8 月推出了 web 服务互操作性基 本大纲 1.0 和 1.126。大纲并不是要推出新的规范，而是力求在现有的 web 服务相 关规范的基础上加以澄清、提炼、解释、详述，通过消除现有规范中的二义性来达 到统一的目的，是一组宝贵的最佳实践经验。但是，大纲本身的描述也比较复杂难 懂，并且其实践的覆盖面还有待提高32。 同时 wsi 组织还推出了 wsi 测试工具包，该软件由两大部分组成，即监 视器和分析器33。其中监视器处于 web 服务的客户端和服务端中间，负责截取服 务请求响应消息并存于日志文件中。日志文件、web 服务注册信息以及测试断言文 档一起被作为分析器的输入。分析器将运行测试断言文档作为测试用例，对日志文 件和 web 注册信息进行测试分析，发现其中不符合 wsi 基本大纲的地方，帮助 开发人员定位 web 服务中的互操作性问题。但是，该测试的实现过程较为复杂， 涉及内容过泛，没有针对性34,35。 综上所述，我们需要借鉴现有的测评经验，找到一种便利、有效的针对服务描 述文档进行测评的方法。 华 中 科 技 大 学 硕 士 学 位 论 文 华 中 科 技 大 学 硕 士 学 位 论 文 6 4. web 服务的实施方法 互操作性作为 web 服务的一个重要特性， 与服务提供端有着直接的关系， 具体 来说，就是和服务的开发、部署和发布的具体实施有关。目前有两种类型的实施方 法36-38：自底向上的方法和自顶向下的方法。 (1) 自底向上的方法 首先，根据服务实现的类文件得到服务描述文件；然后，把服务和服务描述部 署到服务器上；最后，发布服务的描述信息。这种方式使得实施效率比较高，但是 常常会带来服务描述中的互操作问题。 (2) 自顶向下的方法 首先，根据所需的功能设计服务的描述文档；然后，根据服务描述文档生成服 务的程序实现；最后，部署和发布服务。这种方式有效回避了服务描述中的互操作 问题，但是，服务描述文档的设计过程一般比较繁琐，根据服务描述生成的程序实 现一般经过修改才能正常运行，因此使得实施效率非常低。 综上所述，服务的实施需要找到一种快捷、有效的方式来部署服务和发布服务 信息。这里可以考虑根据服务实现通过相关工具生成对应的服务描述文件，即在保 证高效率的前提下，结合相关的测评技术排除实现过程中潜在的互操作问题。 1.3 课题主要研究工作 课题主要研究工作 soa 的实施可以不基于 web 服务，而且 web 服务也不必通过 soa 方式来实 现， 但是目前业界普遍承认 web 服务是实施 soa 的理想途径， 基于 soa 的架构原 则是保障 web 服务互操作性的有效方法。web 服务提供了一整套相关技术，例如 xml、soap、wsdl、uddi 等等，这些技术为 web 服务自身的消息传送和接收， 以及消息传输协议的绑定提供了灵活的、可扩展的语言支持，能够帮助人们针对具 体的消息和应用找到编程的方法，从而实现 soa 架构所提出的理念。因此，web 服务又可以看成是一系列的标准规范，而 soa 是一系列的设计原则。 基于以上的分析，针对 soa 中服务之间互操作性的研究我们从下面 3 个方面 展开。 华 中 科 技 大 学 硕 士 学 位 论 文 华 中 科 技 大 学 硕 士 学 位 论 文 7 1. 服务描述方法和语言的分析 在面向服务的架构里， 不同服务之间应该保持松耦合、 相互独立无依赖的关系， 服务调用者(可以是系统用户也可以是另一个服务)无需了解体系中的服务具体是如 何用程序实现其操作功能的，也无需知道服务的确切位置。为了实现服务的互操作 性，营造一种用户与服务之间、服务与服务之间无障碍交互的运作环境，使用一种 优良的服务描述语言准确、有效地描述服务的相关信息是关键。 2. 服务描述程序实现的研究 目前，针对服务描述的实现，主要有两种方式，即服务开发人员手写和服务部 署系统自动生成。开发人员手写显然会影响服务开发的效率；然而，现有许多系统 自带的服务描述功能的实现程序很复杂，这样会带来很多与程序自身相关的错误， 并且针对系统生成的服务描述文档没有简便的测试途径，即使发现描述中有互操作 问题也无法修改。因此，开发一个快捷有效的服务描述工具是非常必要的。 3. 服务描述中互操作性测试的研究 基于现有的互操作测评技术，针对服务描述程序实现进行一致性测试，发现服 务描述中潜在的互操作问题；还应该针对服务描述文档的描述性进行分析，验证服 务描述文档对服务调用细节描述的一致性和完整性，还可以根据验证过程发现的问 题，修改服务的程序实现，巩固服务的强壮性。 华 中 科 技 大 学 硕 士 学 位 论 文 华 中 科 技 大 学 硕 士 学 位 论 文 8 2 soa 服务描述的研究服务描述的研究 鉴于服务描述功能在 soa 架构平台中的重要作用， 为了更好的实现对一个网络 服务的准确描述，我们需要选择一个合适的描述方法和语言，并且对它的相关标准 和规定进行程序实现。基于这个目标，本章对服务描述相关理论和实现分别进行分 析研究。首先分析比较目前比较经典的服务描述方法和语言；然后对所选择的服务 描述语言进行理论分析，并通过对相关实现技术的分析，研究如何用这种描述语言 快捷有效地实现对服务的准确描述，最后给出服务描述实现的设计与相关算法。 2.1 服务描述方法的分析 服务描述方法的分析 本节需要完成的工作可以分为两部分，首先，根据服务描述所需要发挥的作用 总结服务描述必须达到的要求和需要具有的性能；然后，基于前面所总结的要求标 准，比较分析几种描述方法及其描述语言，选取一种最佳方式用于描述服务。本节 所做的分析工作是为后面实施服务描述定好研究方向。 1. 服务描述需要达到的要求 我们已经清楚地知道，在 soa 架构中，不同服务之间是一种松耦合的、相对 独立无依赖的关系，并且所有服务对于它的调用者来说是位置透明的。所以，要实 现系统间服务的协作和共享，服务提供者就必须清晰、准确地描述其服务并且发布 描述信息；另一方面，服务请求者也需要采取同样的机制和原理来解释自己的服务 需求，通过与服务描述进行匹配，找到需要调用的服务。在这样的实际需求下，服 务描述语言应该满足如下 4 个方面的要求。 (1) 语义表达能力 服务描述必须具备很强的语义表达能力，这样就足以让其他服务或代理在没有 人为操作的帮助下能够理解该服务的基本信息。服务语言的表达能力主要体现在它 对服务功能的描述，比如，服务的输入数据类型和输出数据类型，输入和输出之间 的转换，服务的执行对外界造成的影响。并且，描述语言不能太复杂，因为语言越 复杂，服务需求描述和服务信息描述之间正确匹配的可能性就越小。 总的说来，服务描述语言需要具有在不同层面抽象描述服务的能力。 华 中 科 技 大 学 硕 士 学 位 论 文 华 中 科 技 大 学 硕 士 学 位 论 文 9 (2) 自动比较能力 服务描述应该能够在不需要人为分析的帮助下进行自动比较，匹配服务需求和 服务描述，从而实现服务的调用。因此，服务描述语言需要有良好的语言结构。 (3) 灵活性 这点要求跟良好的结构化是相矛盾的，但是对于需要清晰描述多样化服务的需 求，服务描述语言不应该是固定的结构模块，其原因主要表现在以下三个方面： 服务的多样化决定了服务之间功能的差异也会很大，不可能使用一个通用 的模块对所有的服务进行描述； 服务调用中涉及到的数据来源于不同领域，这就要求描述语言可以进行适 当扩展才能适用于不同的知识领域； 服务描述语言的灵活性还有助于解决对一些描述者事先不理解的服务要素 的描述问题。 (4) 可编辑性 服务描述必须可以被创建、阅读和编辑。因为在目前的网络需求下，越来越多 的服务可能在移动的环境下提供给用户使用，这样该服务的服务描述就需要可以足 够容易地被阅读和编辑，实现对服务调用环境的适应。 2. 服务描述方法的比较分析 根据描述的不同层面和描述方法所基于的原理，可以把描述方法归为四类：基 于关键词的描述、基于模块的描述、基于对象的描述和基于本体的描述37。 (1) 基于关键词的描述 基于关键词是服务描述中最简单的方法。 这种方法利用若干关键词或者文本来 表达服务的语义。在采用这种服务描述的系统中，文件以服务下载的形式提供给服 务调用者，文件下载服务用若干关键词来描述，而这些关键词都来自于文件的文件 名。基于关键词描述方法的典型例子有 gnutella 和 napster。 这种描述方法的优点是能够很好的实现服务描述于服务需求之间的匹配， 具有 很好的自动比较能力；而致命的缺点就在于语义表达能力很差，服务调用者可能需 要对众多查询结果进行筛选。 华 中 科 技 大 学 硕 士 学 位 论 文 华 中 科 技 大 学 硕 士 学 位 论 文 10 (2) 基于模块的描述 基于模块的服务描述方法的原理是将服务描述分成几个属性，每个属性在描述 中含有具体的关键词或特定的属性值，分别描述关于服务的各种信息。这种描述方 法的典型例子有 wsdl、电子商务 xml(e-business xml，ebxml)和服务定位协议 (service location protocol，slp)。其中 wsdl 具有一整套语法、句法和词汇规范， 是真正意义上的服务描述语言。 这种描述方法的突出优点在于该方法的描述语言具有很好的语言结构，可以满 足自动化比较的要求；并且通过属性对信息分类的描述以及属性的扩展机制提高了 描述的准确性。 (3) 基于对象的描述 基于对象的描述方法和基于模块的描述方法类似，除了将服务描述分成几个属 性外，还在服务描述中提供对象参照将对象连接起来。描述的主体是针对服务的非 功能特性、输入和输出，对于服务功能的语义表达必须从服务的名称、文本描述以 及相关参数推导得到。 这种描述方法在基于模块描述方法的基础上提高了描述的准确性，却牺牲了描 述的自动比较性，服务调用者必须对查询结果进行人为的分析，因此在很多情况下 并不能实现系统之间的自动交互。 (4) 基于本体的描述 由于引入了丰富的本体，并且使用若干不同的属性描述这些本体，基于本体的 描述具有较高的准确性和复检性，大大提高了描述的表达能力。这种描述方法的典 型例子有资源描述框架(resource description framework，rdf)、代理标记性语言 (darpa agent markup language， daml)、 网络本体语言(web ontology language， owl)和基于 owl 的 web 服务本体(owl-s)，其中 owl-s 专为描述服务而设计。 owl-s 为所有类型的服务提供了一个顶层本体，这个本体定义了一套通用属性来 描述服务的输入、输出、前提条件等非功能性和功能性特征。 这种描述方法具有高度概括和一般性的特点，最突出的优点就是具有很强的语 义表达能力；然而，该方法的描述语言 owl-s 对很多属性类型没有具体定义，很 难对若干个服务描述进行比较筛选。 华 中 科 技 大 学 硕 士 学 位 论 文 华 中 科 技 大 学 硕 士 学 位 论 文 11 3. 分析小结 综上分析，从服务描述要求中最重要的语义表达能力和自动比较能力两个要素 进行比较，分析结果如图 2.1 所示。 自动比较能力自动比较能力 基于关键词基于关键词 基于模块基于模块 基于对象基于对象 基于本体基于本体 o 高 高 高 高 图 2.1 根据语义表达能力和自动比较能力对描述方法的比较 对于四种类型的描述方法，基于模块和基于对象的描述方法能够更加有效地描 述服务从而实现对服务的调用， 其中基于模块的服务描述语言 wsdl 具有规范化的 语法体系和灵活的扩展机制。wsdl 以 xml 的相关标准作为语言格式规范，通过 一种标准、灵活的可扩展的数据格式，解决了适用于多种应用场合的一个关键技术 需求。 (1) wsdl 不受专业领域的限制。允许为不同领域开发与自己特定领域相关的 数据类型，不用担心数据接收端是否有特定的软件来创建数据。 (3) wsdl 更有利于应用程序间的数据交换。wsdl 使用的是非专有的格式， 不论对于人类还是计算机程序都是易于编写和阅读的。 (2) wsdl 具有较好的保质性。过去大部分计算机数据的丢失不是自然损害或 者备份介质的磨损，而是没有相应文档来说明如何读取这些数据介质和格式。比如 使用不常见的格式保存二进制数据，数据也许会永远消失。wsdl 使用的则是非常 简单的数据格式。 语义表达能力 华 中 科 技 大 学 硕 士 学 位 论 文 华 中 科 技 大 学 硕 士 学 位 论 文 12 2.2 wsdl 协议的研究 协议的研究 wsdl 以一种结构化方式对服务的调用和通信加以描述， 把服务描述成一组对 消息进行操作的网络端点。一个 wsdl 服务描述包含对一组操作和消息的抽象定 义、绑定到这些操作和消息的具体协议和这个绑定所遵循的网络端点规范。wsdl 为分布式系统提供了机器可识别的 xml 文档，用于描述自动执行应用程序的通信 中所涉及的细节。 下面我们就从 wsdl 文档的结构分析出发， 逐步解决文档元素的 描述问题，并通过程序实现 wsdl 协议从而完成对服务的描述。 2.2.1 wsdl 文档结构的分析文档结构的分析 1. wsdl 元素的结构 wsdl 文档的主体部分由 types、message、porttype、binding 和 service 6 大元素 组成，它们之间有如图 2.2 的结构关系。其中 types、message 和 porttype 3 个元 素描述的是服务的抽象定义，主要描述了服务使用的消息结构和服务的接口标准， 这三个部分描述与服务本身具体的部署细节无关，是可以用于复用的描述；然而， 有关服务的交互是如何实现的、消息通信是遵从哪种平台的细节规范以及服务是被 部署在哪台计算机上等，这些细节信息是由 binding 和 service 两个元素来描述。 图 2.2 wsdl 元素的对象结构示意图 华 中 科 技 大 学 硕 士 学 位 论 文 华 中 科 技 大 学 硕 士 学 位 论 文 13 (1) types types 元素是一个定义数据类型的容器，必须包括所有与该服务通信的消息中 需要涉及到的数据类型。准确描述数据类型是正确描述服务的基础，因为服务本身 需要通过各种类型的数据执行功能操作，并且服务之间的通信也是通过各种数据来 实现的。 (2) message message 元素具体定义通信中使用的消息的数据结构，每个 message 元素包含 一组并列的 part 元素。这一组 part 元素将是最终通信消息的组成部分，每个 part 元素引用一个 datatype 来表示它的结构，并且通过 datatype 支持嵌套。 (3) porttype porttype 元素具体定义一种服务访问入口的类型，即传入传出消息的模式和格 式。一个 porttype 包含若干 operation，而一个 operation 指明了访问入口支持的一 种调用类型。这里有四种访问入口调用模式：单请求、单响应、请求/响应、响应/ 请求。 (4) binding binding 元素具体定义某一个 porttype 元素与某一种具体的网络传输协议或者 消息传输协议相绑定，绑定对象主要是 soap/http。 (5) service service 元素描述一个服务具体提供的所有访问入口的部署细节，因此一个 service 可能包含多个服务访问入口，而每个访问入口由一个 port 元素来描述，port 元素描述的访问细节主要包括通过哪个地址来访问服务，需要使用怎样的消息调用 模式来访问服务等，其中消息的调用模式是使用 binding 元素来描述的。 2. wsdl 文档的结构规范 wsdl 以 xml 作为语言格式， wsdl 文档可以说就是 xml 文档。 对于 wsdl 文档，有文档类型定义(document type definition，dtd)和 xml schema 定义(xml schema definition，xsd)两种规范负责描述 xml 文档的结构与约束。相比较 dtd 而言，xml schema 可以定义 wsdl 文档中存在哪些元素和元素之间的关系，可以 定义元素和属性的数据类型，并且它定义了一套标准的数据类型(int、float、boolean 华 中 科 技 大 学 硕 士 学 位 论 文 华 中 科 技 大 学 硕 士 学 位 论 文 14 等)。 简单地说，wsdl 文档就是一系列定义的集合，每个定义作为一个元素，而具 体的定义内容则在该元素里进行描述。所有的 wsdl 文档的根元素都是 definition 元素，它封装了整个文档，其它文档元素就在这个根元素下进行定义。在该元素中 提供了一个命名空间的声明。为排除 wsdl 文档中元素之间命名上可能发生的冲 突，首先做好所需要的命名空间的声明。definition 元素的结构如清单 2.1 所示。 清单 2.1 definition 元素的声明 清单 2.1 中列举的是几种常用的命名空间，他们将被引用到文档各个元素的定 义中，具体表示形式为：命名空间前缀元素名称，这种命名方式简称为 qname。 2.2.2 wsdl 文档中元素描述的实现文档中元素描述的实现 在实现 wsdl 协议的过程中，实施工作涉及到与 wsdl 文档中各个元素相关 的描述细节，具体来说就是元素需要包含的具体属性、属性的表现结构、各个属性 需要遵循的标准规范及其注意事项。 本节所做的分析， 不仅是程序实现 wsdl 协议 的必要工作步骤， 也是后期针对 wsdl 服务描述文档进行互操作性测试和描述性分 析的理论基础。 华 中 科 技 大 学 硕 士 学 位 论 文 华 中 科 技 大 学 硕 士 学 位 论 文 15 1. types 为了更好地实现服务之间的互操作性，协调平台之间的差异性，wsdl 直接使 用的内置类型作为基本的数据类型系统。types 元素被用作一个容器，专门用于定 义 xsd 内置类型系统中没有描述的数据类型。在下面要提到的消息抽象定义中， 使用到的数据类型和相关元素都被封装在 types 元素里。 (1) 当数据类型是 xsd 中的基本数据类型，types 中的内容可以省略，或者直 接引用 xsd 数据类型，结构如清单 2.2 所示。 清单 2.2 types 元素的声明 * (2) 在信息多元化的网络环境中， 服务的调用常常会遇到结构复杂的数据类型， 这是 xsd 中的基本数据类型无法直接表示的。当服务实现中涉及到用户自定义的 复杂数据类型，即由多种基本数据类型衍生而来的复合数据类型，可以通过以下途 径来进一步描述复合数据类型： 1 定义 xsd:element 用于支持数据类型的扩展； 2 定义 xsd:complextype 用于表示复合数据类型； 3 定义 arraytype 用于扩展数组类型。 2. message message 元素描述的是服务交互时的通信消息的有效负载，是对消息的抽象定 义。 定义 message 元素的方式取决于消息传递所使用的样式， 远程过程调用(remote procedure call，rpc)样式或者文档(document)样式。message 元素的结构如清单 2.3 所示。 清单 2.3 message 元素的声明 清单 2.3 中，每个 wsdl:message 使用若干个 wsdl:part 来标识消息的结构，每个 华 中 科 技 大 学 硕 士 学 位 论 文 华 中 科 技 大 学 硕 士 学 位 论 文 16 wsdl:part 都是最终消息的有效组成部分。其中，wsdl:part 包含两个属性，name 和 element/type。各个属性具体的作用及注意事项描述如下： name用于标识 wsdl:part 的名字。当消息结构中只含有一个 wsdl:part 时， name 的属性值可以设定为 parameters，没有实际意义；当消息中需要包含若干 wsdl:part 时，它用于唯一标识该 wsdl:part 元素。 element用于表示 types 元素中定义的 xsd 扩展类型，对应于文档样式。 type用于表示xsd中的基本数据类型或者types元素中定义的复合数据类 型，对应于 rpc 样式。 3. porttype message 元素定义了服务的抽象接口，也就是定义了一个抽象类型和方法，但 是没有定义具体的实现。它描述的是一组抽象操作的集合，引用了与操作相关的消 息结构。在 wsdl 文档中，porttype 元素的实现是由之后的 binding 元素和 service 元素来完成的。message 元素的结构如清单 2.4 所示。 清单 2.4 porttype 元素的声明 * 清单 2.4 中，服务端口的访问方式具体是由 operation 元素定义的。前文分析已 知， wsdl 中服务的访问方式有四种， 下面分别就这四种访问方式来分析 operation 元素的结构。 (1) 单请求方式：该访问端口只接收消息。operation 元素的结构如清单 2.5 所 示。 清单 2.5 operation 元素单请求方式的声明 清单 2.5 中，wsdl:input 引用了该访问端口对应的消息结构。 (2) 请求/响应方式：该访问端口需要先接收到一条消息，然后发送一条与之相 华 中 科 技 大 学 硕 士 学 位 论 文 华 中 科 技 大 学 硕 士 学 位 论 文 17 关的消息作为响应。operation 元素的结构如清单 2.6 所示。 清单 2.6 operation 元素请求/响应方式的声明 清单 2.6 中，wsdl:input 和 wsdl:output 分别引用了该端口接收消息的结构和发 送消息的结构。 (3) 响应/请求方式：该访问端口需要先