（计算机软件与理论专业论文）web服务架构下注册中心的研究与实现.pdf

i 摘 要 摘 要 web service 作为一种新的分布式计算技术，凭借其平台无关性、消息导向性和 协议可组性等特点，从出现以来就在工业界得到广泛认可，使世界上的很多个国际 性组织研究和制定各种规范、协议来规范其发展，其中的一个核心问题是如何找到 并调用所需的服务，针对寻找服务的问题，以发现、描述和集成服务(universal description discovery and integration,uddi)规范为基础，设计一个 uddi 注册中心 可以满足对服务管理的需要。 针对当前web service体系中公有uddi注册中心应用时存在的准确性、安全性 等问题，提出建立私有uddi注册中心的方案，并构建了此方案的理论模型。通过 web服务及私有uddi注册中心，为企业跨平台的异构应用程序模块提供web服务， 并使用uddi注册中心集中注册，从而可以根据需要查找到相应模块，构建一个更 强大的应用程序模块。 在建立的私有注册中心中，结合 uddi 规范中的数据结构特点，对其中的商业 实体元素、服务元素、绑定元素和技术模型元素分别创建相应的数据库表，使用基 于简单对象传输协议（simple object access protocol，soap）消息机制调用相关接 口实现与注册中心的通信，并根据元素中的唯一键值对服务、企业还有相关信息进 行绑定，然后根据数据库表里的信息查到服务描述的地址，实现服务的调用。 注册中心采用了三层体系结构，并分 uddiproxy、注册模块、查询模块和数据 库连接模块四个部分进行实现。 实现的系统可以利用 web 服务和 uddi 注册中心来 进行内部应用系统的集成与企业间的合作伙伴的系统无缝对接。通过建立一个开放 式、全球化的、面向服务的体系架构，使得在不同平台上，以不同语言编写的各种 应用程序可以在基于标准的方式下相互通信。 关键词：关键词：注册中心，统一描述、发现和集成协议，简单对象访问协议 ii abstract abstract as a new distributed computing technology, web services attracts attention of industry since it appeared in 2001 with many advantages. now some international groups and organizations are founded to research and constitute various protocols and specifications to specify its development. a critical problem in web services is how to discover, describe and integrate services in open networks environment.we have designed a registry centre based on uddi （universal description discovery and integration） to solve this problem. there are some problem on the public registry centre, so we use web service and private uddi registry center build a theory model of a resolution. by providing web service for these heterogeneous applications and registrying these applications on the uddi registry centre, we can build stronger applications based on those web services in a standard. in the private registration centre, the establishment of the web services database tables is be implementation with uddi standard features in the data structure, the use of information mechanism called soap （simple object access protocol） interface with the registry centre, and in accordance with the only key element in the service, business-related information is also available bundled, according to the information available database table, could find service described file address, and service calls are implementation. registration centre adopts the three-tier architecture, and it is divided into four modules- the uddiproxy, registration module, inquire module and database connecting module. it puts forward a realizable method of using web services and uddi registry center to integrate applications within enterprise and between enterprises and its partners. by building such an open, global, service-oriented architecture, the heterogeneous application can communicate in standard method. key words： registry centre, uddi, soap 独创性声明独创性声明 本人声明所呈交的学位论文是我个人在导师指导下进行的研究工作及取得 的研究成果。尽我所知，除文中已经标明引用的内容外，本论文不包含任何其 他个人或集体已经发表或撰写过的研究成果。对本文的研究做出贡献的个人和 集体，均已在文中以明确方式标明。本人完全意识到本声明的法律结果由本人 承担。 学位论文作者签名： 日期： 年 月 日 学位论文版权使用授权书学位论文版权使用授权书 本学位论文作者完全了解学校有关保留、使用学位论文的规定，即：学校 有权保留并向国家有关部门或机构送交论文的复印件和电子版，允许论文被查 阅和借阅。本人授权华中科技大学可以将本学位论文的全部或部分内容编入有 关数据库进行检索，可以采用影印、缩印或扫描等复制手段保存和汇编本学位 论文。 保密 ，在_年解密后适用本授权书。 本论文属于 不保密。 （请在以上方框内打“” ） 学位论文作者签名： 指导教师签名： 日期： 年 月 日 日期： 年 月 日 1 1 绪 论 1 绪 论 1.1 论文的研究背景1.1 论文的研究背景 面向服务的体系结构1（service-oriented architecture,soa）个这个概念在很早 就已经提出，但一直没有找到很好的实现方案，一直到上世纪末，web service2技 术的提出为soa提供了一种可能的实现方案，并且事实证明了web service是迄今为 止实现soa的最优方案。 web services体系结构基于soa主要体现在三个角色之间的 交互上，它们是：服务提供者、服务请求者和服务注册中心3。它们之间交互的内 容包括发布、查找和绑定三个操作，在web services体系结构中，这些角色和操作一 起作用于web构件。随着soa的被接受，使用的企业也逐渐增多，随之带来的web 服务的数量越来越多，对web服务的使用也越来越复杂，面对众多的web服务，怎 样寻找到需要的web服务，如何才能访问这些web服务，如何更方便的管理这些服 务成为值得关注的问题。为了解决这一系列的问题，出现了web服务注册中心对这 些web服务进行管理，因为web service生来就是开放的和基于标准的4，基于统一描 述、发现和集成协议（universal description discovery and integration，uddi）的注 册中心就是当前用得最广泛的web服务注册中心。uddi作为web服务的高层协议， 它的调用模型和web服务的调用模型一致的，web服务调用的是一个实现某一特定 功能的服务，而uddi的调用是注册中心所提供的固定不变的服务，例如发布和查找 等服务。 uddi 注册中心的作用是以一种结构化的方式来保存有关各公司及其服务的信 息。在 uddi 注册中心中，企业和个人都可以发布和发现有关某个公司及其 web 服 务的信息。这些数据使用标准的分类法进行分类，为查找相应类别的相关信息带来 了方便。uddi 还包含有关公司服务的技术接口的信息。通过这些方法，uddi 注册 中心可以用作基于 web 服务的软件系统的基础结构。uddi 这项技术最开始的目的 是要建立一套使用 uddi 规格的在线数据库， 来帮助企业寻找基于网络的软件服务。 本课题来源于 dm 公司的预研项目“soa 基本框架的搭建” ，做为该项目的一 部分，要求使用 uddi 规范来建立一个私有的注册中心，以满足 web 服务的注册与 查询的需要。 2 1.2 国内外研究现状 1.2.1 发展现状 1.2 国内外研究现状 1.2.1 发展现状 web service 是当今全球信息产业关注的热点，它是 web 发展的自然产物5，是 一项极具发展潜力的重要技术，它作为一套标准，定义了应用程序如何在 web 上实 现互操作性，是建立可互操作的分布式应用的新平台。我们可以用任何一种语言， 在不同的平台下编写 web 服务，一个 web 服务是一个接口，这个接口可以用来完 成某种服务6，然后通过 web service 的标准来对这些服务进行注册、查询和调用等 操作。我们利用 web 服务就能够创建出可供任何人在任何地方使用的、功能非常强 大的应用程序，它极大地拓展了应用程序的功能，实现了软件的动态提供7,8，使异 构平台的电子商务能够很容易地整合在一起9-11。学术上也对 web 服务开展了大量 的研究工作，包括 web 服务工作流12,13、web 服务事务模型14,15、web 服务的安全 问题16-18以及如何验证 web 服务有效性19-22等。 作为web service技术的重要组成部分之一， uddi是一套基于web的、 分布式的、 为web服务提供的信息注册中心的实现标准规范，同时也包含一组使企业能将自身 提供的web服务注册以使得别的企业能够发现的访问协议的实现标准。web service 作为一种在internet上共享数据和功能的新手段，通过使用超文本传输协议http、 可扩展标记语言 （extensible markup language ， xml） 23的web服务描述语言 （web services description language， wsdl） 24、 与平台无关的简单对象传输协议 （simple object access protocol， soap） 25等标准的互联网协议在计算机系统之间进行通信， 所以uddi也都用到这些协议。 一些著名的计算机公司如microsoft， ibm， bea， hp， sap等都建立了自己的uddi注册中心节点， 供世界各地的用户在这些注册中心上注 册、查找自己所需要的web服务。随着wbe服务技术的广泛应用，各个技术提供商 得以专注于自身技术的发展，而将与其他技术供应商的互操作问题转移给web service技术，这将为各个技术提供商节省相当大的研发成本26。 1.2.2 相关技术 1.2.2 相关技术 1uddi 与 web service 到目前，web service技术己相当成熟，web service的体系结构以及web service 3 协议栈，许多已经成为工业界的标准27-30，如图1.1所示，uddi包含在完整的web service协议栈里面，是协议栈基础的主要部件之一，最下面两层是已经定义好并且 广泛使用的传输层和网络层的标准xml、http、tcp/ip等。而3，4，5层是目前开 发web服务的相关标准协议，有简单对象访问协议soap，服务描述协议wsdl和统 一描述、发现和集成协议uddi。uddi构建在网络传输层和基于soap的xml消息 传输层之上，wsdl服务描述语言为它提供了统一的规范供描述web服务及其接口。 可以通过加入wsfl(web service flow language)服务流程语言31-33中的web服务工 作流描述、安全性、管理和服务质量功能等搭起整个基础，解决系统的安全性和可 用性问题。图右边是各个协议层的公用机制，这些机制一般由外部机制来完成。 图 1.1 web service 协议栈 web service 的标准实现模型是： 服务的提供者拥有一个可通过网络访问的软件 模块即 web 服务实现，它为这个模块定义服务说明，并将此发布到服务注册处。服 务的请求者查找服务注册处得到服务说明， 利用其中的信息与服务提供者实现绑定， 与 web 服务交互，调用其中的操作。如图 1.2 所示在 web 服务体系中，所有的应用 实体都被抽象成服务，其中包括三种角色、三种操作和两种元素 34。 web service 的三种角色： 服务流 服务查找 服务发布 消息通信 服务描述 网络 wsfl uddi wsdl soap http、ftp、smtp 等等 安全 管理 服务质量 4 （1）服务提供者：服务的所有者。一般情况下，它是指开发服务的商业实体， 比如一些公司；从架构看，它是托管访问服务的平台，也可以说是服务的运行环境。 图 1.2 web 服务结构图 （2）服务使用者：对特定功能有需求的一方。从体系结构的角度看，这是寻找 并调用服务的应用程序。发送服务请求的客户端可以是浏览器，或者是无用户界面 的应用程序。 （3）注册中心：查找所发布的服务，主要功能为搜索服务描述。服务提供者在 此发布他们的服务描述。对于动态的服务使用者，服务注册中心是体系结构中的可 选项角色，因为服务提供者可以把描述直接发送给服务请求者，建立一个注册中心 的目的只是为了更方便的管理与查找服务。 web service 的三种操作： （1）发布：使服务成为共享资源，可被别的实体访问，服务提供者需要发布服 务描述以使服务使用者可以查找它。 （2）查找：在查找操作中，服务使用者有时可以直接得到服务的描述，或者在 服务注册处查询得到所要求的服务类型。 （3）绑定：在绑定操作中，服务使用者利用服务描述中的绑定细节来定位、联 系和调用服务，从而在运行时调用或启动与服务的交互。 web service 的两个元素： （1）服务：在网络上，web 服务是由服务描述定义的接口，这个接口的实现就 是服务本身。服务被服务提供者部署在可以通过网络访问的各种平台上，服务的使 用者可以调用它。当服务的实现过程中用到了其它的服务时，它自身也是服务的使 服务注册中心 服务提供者 服务使用者 发布（uddi） 查找（uddi） 绑定（soap） 5 用者。 （2）服务描述：包含服务的实现细节，如数据类型、操作、传输协议、访问入 口等， 为了协助服务使用者发现和使用服务，服务描述也可能包括其它元数据信息。 服务提供者可以将服务描述直接发送给服务使用者，或者发送到服务注册中心。 2注册中心的问题 现在一些大公司的公共注册中心，可以让我们发现全球范围内潜在的服务，但 是 uddi 企业注册的广泛性限制了它动态绑定的有用性。公共操作站点中包含了在 不同行业和不同地理位置的不同种类的企业的 web 服务。在它存放的这些数据中， 有些数据是企业的 web 服务和合法的商业信息，有些数据是企业放的有关 web 服 务，但是并不提供 web 服务，另外还有一些数据是错误的或者是一些可能给人产生 误导的信息。所以，公有 uddi 注册中心在做动态服务的发现和绑定操作时很可能 达不到预期的效果， 因为在众多的服务中发现可能符合操作的目标的几率非常的小， 会搜索出很多不符合要求的错误的合作伙伴，降低了效率。 这个时候可以建立一个私有的注册中心解决这些问题，一个私有目录可提供一 份统一的网络服务清单供企业用来与客户、供货商与伙伴作联络。将 uddi 目录设 在公司内部，可以当作统一式的网络服务数据库，用户可以直接修改目前的服务来 当作新用途。可以使用 uddi 建立内部 web 服务项目的索引，使部门之间或相关企 业之间的沟通与交互变得简单。 虽然公有 uddi 对动态形式的 web 服务的绑定的支持很有限，uddi 的接口函 数和数据模型在面向服务的架构中仍然有用。可以应用这些接口函数和数据模型来 构建企业内部的私有 uddi 注册中心，实现面向服务的体系架构。私有 uddi 注册 中心与 uddi 规范兼容，在内部网络进行注册的 uddi 注册中心，使用的仍然是 uddi 规范的结构，所以在构建企业内部的 uddi 注册中心时就可以使用这些接口 函数以及数据模型。 1.3 论文的研究内容 1.3 论文的研究内容 鉴于前面提出的课题背景和国内外研究现状，本课题将主要研究基于 uddi 规 范的注册中心相关技术，针对现在的公有注册中心存在的问题，提出目前的解决方 案，实现 web 服务的注册与查找。使用注册中心管理 web 服务分为制做服务，根 6 据服务描述发布服务和查找服务三个阶段，本文将对这三个阶段进行介绍。在注册 中心的实现方面，采用三层体系结构，主要研究的是功能层的实现，整个注册中心 将以 uddi 规范为基准，结合 soap，wsdl 及 http 等协议提供一个可供网络上 互通的 web 服务交互平台。本课题主要研究工作主要包括以下两个方面： 1uddi 注册中心的总体结构设计。对注册中心的结构和使用情况进行分析， 结合 uddi 规范的数据结构特点及通信原理，对设计一个灵活，易于扩展的私有注 册中心。通过 businessentity，businessservice，bindingtemplate，tmodel 这几个基本 元素对企业、服务信息进行标识、绑定，通过 save_xx 完成服务的发布工作，find_xx 完成服务的查找工作。 2uddi 注册中心的实现。在具体的实现中，解决从客户端提出请求发送 soap 消息，在服务端对 soap 消息进行解析并调用相关 api 对数据库进行操作的问题。 用 uddiproxy，注册，查询和数据库连接这几个模块搭建起一个完整的 uddi 注册 中心，完成 web 服务的注册与查找工作。 7 2 注册中心总体设计 2 注册中心总体设计 本章主要首先对注册中心工作方式， 根据服务描述调用 web 服务原理和注册中 心通信机制与基本结构进行分析，然后对比公有注册中心提出建立一个私有注册中 心的设计方案，在设计方案中分模块介绍了注册中心的详细设计过程。 2.1 注册中心工作原理 2.1.1 注册中心工作方式 2.1 注册中心工作原理 2.1.1 注册中心工作方式 uddi 的所有的商业注册信息存放在运营商(即承诺运营一个公共节点的公司) 节点，也就是公有的 uddi 注册中心上。这些公共节点遵循 uddlorg 组织管理的 规范，他们之间能互相复制数据，这样就为整个 uddi 网络提供了数据共享。图 2.1 是公有注册中心节点的关系图，提供 web 服务的企业到注册中心进行注册，将数据 发布到一个节点上后，节点之间通过复制，可以把这个企业的数据复制到所有的节 点上。其他希望使用该服务的企业就可以到任何一个注册中心进行查找，发现这些 数据。目前，microsoft 和 ibm 的公共节点每隔 24 小时就进行一次复制。在将来， 由于有更多的应用程序要依赖 uddi 数据，复制的时间间隔还将缩短。 图 2.1 注册中心交互图 对于数据寄存运营商实现其节点的方式， 没有专门的要求， 只要节点遵循 uddi 规范就可以。例如，microsoft 的节点完全用 c#写成，并运行于.net 公共语言运行 uddi 注册 中心节点 web 服务 uddi 注册 中心节点 查找 相互复制 注册 web 服务 用户 8 时环境下。它的代码充分利用了.net 系统类提供的本地 soap 支持和序列化。在后 端，microsoft 运营商节点使用 microsoft sql server 2000 作为其数据仓库。而 ibm 使用其他技术来运行其节点。但是，这两个节点的行为是相同的，因为它们都遵循 相同的一套基于 soap 的 xml api 调用。 客户端工具可以和这些节点进行无缝的交 互操作。 因此， uddi 公共注册中心使得 web 服务模型可以跨越异构环境进行工作。 公有 uddi 注册中心的远程调用过程是这样的，首先在编写调用远程 web 服务 的程序时，程序员通过使用 web 接口或其它基于查询 api 的工具来定位 businessentity 信息，注册该 web 服务的企业一般会提供这些信息。然后可以获得 更详细的 businessservice 资料或者得到完整的 businessentity 信息。 在 businessentity 结构里包含了有关已发布 web 服务的所有信息。通过获得的信息，可以知道包含在 该服务 bindingtemplate 中的 tmodel 结构中得到有关该 web 服务的详细描述，程序 员可以按照该 web 服务的调用规范编写程序。 2.1.2 web 服务准备 2.1.2 web 服务准备 1web 服务描述文件 web 服务提供者在发布服务时通常同时需要提供 wsdl 文件，uddi 注册中心 最重要的功能就是将根据企业提供的 wsdl 文件注册 service 信息。如图 2.2，在发 布服务的时候，web 服务提供者将一个指向 web 服务的 wsdl 文档的地址在注册 中心里发布，服务使用者用客户端程序搜索注册中心寻找 web 服务，根据注册中心 中的信息查找到 web service 的 wsdl 文件的地址， 获得该 web service 的描述文件 wsdl，然后用相应的 xml 解析器解析该 wsdl 文件，得到该 web service 提供的 operation 及其对应的输入输出参数类型，就可以进行调用了。 图 2.2 服务调用流程图 wsdl 文件是用 xml 文档来描述 web 服务的标准， 是 web 服务的接口定义语 注册中心 客户端 web 服务实例 检索 wsdl 文档 发布服务 调用服务 9 言，wsdl 文件描述了服务的功能、服务在 web 上的位置，以及一些有关如何对服 务进行访问的指令。web 服务所发送和接收的消息的结构也在 wsdl 文档中描述。 通过使用这些信息，web 服务的请求者可以对 wsdl 文档进行分析，从而调用所需 的 web 服务。业务之间将通过交换 wsdl 文件来理解对方的服务。当发现一个服 务并希望调用它们，可以使用一定的通信方式进行传递，soap 消息提供了良好的 支持，soap 支持 http 或 smtp 等方式，这里可以将服务看作是通过 soap 访问 的对象，用户就可以方便地在互联网上发现并交换 wsdl 文档了解服务信息了。 在使用过程中，可选择相应的工具处理 wsdl 文档，并抽取出需要的信息。大 多数的 web 服务开发工具可以自动生成 wsdl 文档。在建立和部属 web 服务的过 程中，软件开发人员不需要完全理解 wsdl 的语法。wsdl 文档以端口集合的形式 来描述 web 服务，wsdl 服务描述包含对一组操作和消息的一个抽象定义，绑定到 这些操作和消息的一个具体协议，和这个绑定的一个网络端点规范。wsdl 文档被 分为两种类型,服务接口和服务实现。服务实现文档中的主要元素作用分别为： types：定义了 web 服务使用的所有数据类型集合，可被元素的各消息部件所引 用。它使用某种类型系统(一般地使用 xml schema 中的类型系统)。 message：通信消息数据结构的抽象类型化定义。使用 types 所定义的类型来定 义整个消息的数据结构。 operation：对服务中所支持操作的抽象描述。一般单个 operation 描述了一个访 问入口的请求/响应消息。 porttype：对于某个访问入口点类型所支持操作的抽象集合。这些操作可以由 一个或多个服务访问点来支持。 binding：包含了如何将抽象接口的元素(porttype)转变为具体表示的细节，具体 表示也就是指特定的数据格式和协议的结合；特定端口类型的具体协议和数据格式 规范的绑定。 port：定义为协议/数据格式绑定与具体 web 访问地址组合的单个服务访问点。 service：这个命名的元素，代表端口的集合，相关服务访问点的集合。 porttype(与 message 和 type 元素的细节相结合)描述了 web 服务是什么， binding 元素描述了如何使用 web 服务，port 及 service 元素描述了 web 服务的位置。 一个 web 服务在被描述信息描述之后将在 uddi 注册中心发布，uddi 提供发 10 布服务和查找服务描述的方法， 其中 uddi 中的数据类型实体封装了 web 服务的描 述信息。完整的 wsdl 服务描述是由一个服务接口和一个服务实现文档组成的，服 务接口表示服务的可重用定义，它在 uddi 注册中心被作为 tmdoel 发布。服务实现 描述服务的实例，每个实例都是使用一个 service 元素定义的，服务实现文档中的每 个 service 元素都被作为 uddi 注册中心的 businessservice 元素发布， service 元素的 port 元素作为 uddi 注册中心的的 bindtemplate 发布。当发布一个 wsdl 服务描述 时，在服务实现被作为 businessservice 发布之前，必须将一个服务接口作为一个 tmdoel 发布。 2描述文件与 uddi 的连接 在 uddi 注册中心， 服务接口被作为 tmdoel 发布， tmodel 由服务接口提供者发 布。tmodel 中的一些元素是使用来自 wsdl 服务接口描述中的信息构建的，下面 简要介绍 wsdl 服务接口描述文档中的元素到 udditmdoel 核心数据结构的映射规 则。 tmodel 的 name 子元素：与 wsdl 服务接口描述文档中根元素 definitions 的 targetnamespaee 属性对应，名称需要一致以确保只使用服务实现文档中的信息就可 以定位 tmdoel。 tmodel 的 description 子元素：与 wsdl 服务接口描述文档中根元素 definitions 的 documentation 元素对应。 tmodel 的 overviewurl 子元素：用作 wsdl 服务接口文档可通过网络访问到 的 位 置 。 businessservice 元 素 根 据 服 务 实 现 文 档 的 service 元 素 创 建 ， 而 bindingtemplate 是根据该 service 元素的子元素 port 定义的。 下面简要介绍从服务实现文档到 uddi 核心数据结构 businessservice 和 bindingtemplate 的映射。 businessservice 的 name 子元素： 来自服务实现文档中的 service 元素的 name 属 性。 businessservice 的 description 子元素：来自服务实现文档 service 元素的 documentation 子元素的内容，如果 documentation 元素不存在，description 元素就不 被设置。 bindingtemplate 的 description 子元素：如果服务实现文档的 port 元素包含一个 11 documentation 元素，则 description 元素根据 documentation 元素的前 256 个字符设 置，否则 description 元素不被设置。 bindingtemplate的accessspoint子元素： 对于与网络传输协议的绑定， accesspoint 是根据与 port 元素关联的扩展元素的 location 属性设置，这个元素将包含 url，且 urltype属性是根据此中的协议设置。 对于不使用 url规范的协议绑定， accesspoint 应该使用 urltype 属性指出协议绑定的类型， 并且还应该包含一个可用于定位使用 指定协议的 web 服务的值。 bindingtemplate 的 tmodelinstanceinfo 子元素： tmdoelinstanceinfo 元素包含对 服务接口文档的 tmodel 的直接引用。 bindingtemplate 的 overviewurl 子元素： wsdl 服务实现文档在网络上的位置， 通过这个地址可以在网络上找到该文档。如果服务实现文档包含多个端口，则 overviewurl 应该包含对端口名的直接引用。 通过 wsdl 与 uddi 的映射关系， web 服务使用者可以先向 uddi 注册中心搜 索特定的服务，获取服务地址和服务接口，通过服务实现描述可以知道有关服务的 详细信息，然后就可以对所需的服务进行调用了。 2.1.3 通信机制与基本结构 2.1.3 通信机制与基本结构 如图 2.3 所示， uddi 注册中心消息的传输是通过 http 从客户机的 soap 请求 传到注册中心节点，然后再反向传输。注册中心服务器的 soap 服务器接收 soap 消息、进行处理，然后把 soap 响应返回给客户机。 1soap 封装器：封装器的主要功能就是将用户的请求打包成 soap 消息，并 将消息传递给相应的解析器。 2soap 解析器：解析器主要接收从封装器传递过来的 soap 消息，并进行解 析。服务端将解析后的数据转换成相应的分类法内部的数据实体；客户端解析消息 后，还必须将解析后的数据以恰当的形式显示给用户35。 3控制和校验器：控制和校验器主要有验证和分发两种作用。验证包括对用户 权限的验证和对用户提交的分类法文档是否符合分类法 schema 的验证； 分发功能主 要是将转换后的请求分发和对响应的整合。 4 发布和查找模块： 主要负责对元数据的增减删除等操作， 和数据库进行交互。 12 图 2.3 注册中心基本结构 简单说来，uddi 注册中心的执行过程分为这几个步骤：首先在客户端通过一 个 uddiproxy 把用户的操作请求转化为 soap 消息通过 http 协议传到 uddi 服务 端，进入最外层的 web 服务器，然后对传过来的 soap 消息进行解析，调用相应的 操作模块与 uddi 数据库交换数据。现有的 uddi 注册中心一般都遵循这个结构， 使得各节点之间的相互通信更容易实现，但现有公有的 uddi 注册中心因为一些技 术与非技术的问题，使用情况并不乐观。 2.2 注册中心存在的问题及解决 2.2.1 公有注册中心存在的问题 2.2 注册中心存在的问题及解决 2.2.1 公有注册中心存在的问题 uddi 这项技术早在 2000 年的时候微软和 ibm 就提出了，而且都建立了公共 的 uddi 注册中心，但是并没有被大多数的商业客户所重视。很多的公司仅仅将 uddi 公共注册中心作为一个黄页来使用，通过 uddi 注册中心来查询一些公司的 联系信息，比如公司名称、联系人、电话等等。这与 uddi 建立全球的公共网络服 务目录的目标有很大的差距。根据文献36了解到发生这种情况很多方面的原因，主 要由于公有 uddi 注册中心的以下几个问题： 1特定需求方面 发送 soap 请求 返回 soap 响应 发布模块 控制和校验模块 查找模块 客户端 服务端 http soap 解析器 soap 封装器 soap 封装器 soap 解析器 数据库 服务器 13 因为公有 uddi 注册中心是面向公众的，使得他在这些特定的需求情况下不能 适用。有些时候，公司实现了一个 web 服务，但是希望在这个 web 服务在真正投 入使用之前先进行测试，如果测试成功，也就是 web 服务能够成功地被调用，并且 得到正确合理的结果，再将这个 web 服务发布到公有的 uddi 注册中心，以供全球 的贸易伙伴来发现并调用。 如果不成功，就需要继续修改，不能发布到公有的 uddi 注册中心。还有一种情况就是某个企业内部使用了很多的 web 服务，一些 web 服 务又是不希望被外部的用户所发现，更不希望被外部的用户调用，那么，这时候就 需要有一个注册中心仅仅对公司内部开放，只有公司内部人员有权利调用它们。也 会遇到这种情况，在公司和商业合作伙伴之间有业务往来，他们就有一些 web 服务 供对方使用，这样的一些 web 服务仅仅想被商业合作伙伴发现，而不想被第三方发 现或使用， 那么这时候就需要有一个注册中心只对公司内部以及商业合作伙伴开放。 2使用问题 使用 uddi 的公共注册中心， 虽然可以发现全球范围内潜在的服务， 但是 uddi 企业注册的广泛性限制了它动态绑定的有用性。在公共操作站点中包含了在不同行 业和不同地理位置的不同种类企业的 web 服务。在它存放的这些数据中，有些数据 是企业的 web 服务的合法的商业和信息；而有些数据显示的是与企业有关的 web 服务，但它并没有真的提供 web 服务；另外还有一些数据是错误的或者是一些可能 误导的信息。所以，公有 uddi 注册中心在做动态服务的发现和绑定操作时不是一 个目标丰富的环境，它在众多的服务中发现可能符合操作的目标的几率非常的小， 会搜索出很多不符合要求的错误的合作伙伴。 根据上面的分析，我们可以看到公共 uddi 的开放性，以及它的某些技术上的 不完善性严重阻碍了它进一步的推广应用。uddi 的演进其实在某种程度上正反映 了网络服务的市场发展。目前网络服务却以企业内部应用最多，尽管许多创始公司， 如微软、ibm 都希望能发生在公开的网络上。公共 uddi 注册中心现在并没有真正 地在网络上发挥它应该发挥的作用。但是，从技术上的角度来看，这些问题都是可 以克服的，所以，公有注册中心依旧是未来使用的趋势。但现在，我们应该找到一 种更灵活，也便于扩展的实现办法解决上述问题。 2.2.2 解决方案 2.2.2 解决方案 公共 uddi 注册中心现在还在还并没有形成成熟的网络服务市场， 但私有 uddi 14 目录可以提供一份统一的网络服务清单供企业用户用来与客户、供货商及伙伴作联 络。 现在， 有许多大型的企业开始采用 uddi 建立企业内部的 web 服务项目的索引， 开发人员可以直接修改目前的服务来作新用途，这样可以使得跨部门间的沟通与服 务能够更加容易。 公有 uddi 对于动态形式的 web 服务的绑定的支持现在还是很有 限的，但是在面向服务的架构中 uddi 的接口函数和数据模型仍然是有用的，所以 我们可以应用这些接口函数和数据模型来构建企业内部的私有 uddi 注册中心，实 现面向服务的体系结构。使用私有 uddi 注册中心能够为一些特定的授权用户提供 专门的或者定制的功能和服务，另外，私有的 uddi 节点在使用上也有一定的优势， 可以缓解 uddi 注册中心中存放的数据过于繁多，从而在作动态服务和绑定操作时 达不到一个目标丰富的环境的问题。私有 uddi 注册中心还可以制定一定的规则来 限制发布的信息内容， 这样就可以让私有的 uddi 注册中心适合在构建 web 服务应 用程序的运行模式下进行调用。 uddi 可以分为 uddi 操作站点、电子商务 uddi、门户 uddi、商业伙伴目录 uddi、企业内部应用程序集成 uddi、测试 uddi 这六种。在这六种 uddi 中除第 一种是公共的 uddi 节点外，其余的五种都是私有节点。私有 uddi 节点不需要去 实现节点之间的复制，它是轻量的，他们不用在数据传输时进行限制，这样它们处 理的事务量相对于公共节点要小得多，这使得开发者将信息发布到公有节点之前可 以确认它的正确性。私有 uddi 注册中心和公有注册中心一样，都是基于标准的 uddi 接口函数，但私有 uddi 注册中心的有其自身的特点。 1复制节点信息：在私有 uddi 中可以选择某一项，如公司的名称，将它复制 到另外一个节点，那么该公司的所有信息包括公司的联系人信息，web 服务，绑定 信息都将会复制到另外一个节点。 2 分发 uuid： 在 uddi 中存放的数据， 每一项都有它的标识号， 也就是 uuid。 它是由 uddi 操作节点来分配的，并不是由注册的企业所决定的。uuid 在保存企 业实体信息的时候设计到 save_businessentity 的结果。 当 businesskey 的值为空时，它就会保存一个新项，而其值不为空时，它就会 更新一个现有的项，这是因为注册中心在存放数据时，使用 businesskey 作为判断 标准。 3订购符合模式的服务：请求者在对 uddi 节点做一个查询操作的时候，会得 15 到现有的一些结果。但是他希望当一个新的满足查询条件的项被发布后，也能够通 知他。这种功能可以被称作订购服务。 4通知现有项的改变：当将某一项从某个节点复制到另外的一个节点后，如果 原来节点中这一项的信息有所改变，那么这个改变可以通知给另外的那个节点。当 那一个节点收到消息后，会改变为相应的信息，保持和原节点信息上的同步。这样 便使得所有节点上公有的信息是一致的。 5缓存和委派：在私有 uddi 注册中心中，用户可以使用缓存和委派的方法来 保持私有 uddi 节点和它的合作点之间的信息同步。用户不需要复制某些项，而是 做一个间接的委派。表面上看这个委派好像是一个真实的完整的项，使用查找方法 可以找到所有需要的服务信息，但是对这个委派的使用实际上是到存放的实际节点 上进行引用的。 当公有 uddi 注册中心发展成熟之后，可以逐步向它过渡。但现在考虑的私有 uddi 注册中心，相对公有的 uddi 注册中心来说提供了更多的机会去发现和继承 服务，这些改变让私有的 uddi 注册中心受到了越来越多的关注和应用。它可以作 为公司内部的 web 服务的注册中心，使得跨部门的沟通和服务更加的容易。待过渡 完成之后， 可以将私有注册中心中需要公开的企业信息和 web 服务复制到公有注册 中心中去，和公有的注册中心连接，实现信息的共享，此时公司内部的私有注册中 心如果没有需要，可以移除，如果还有需要，也可以留作内部使用。 2.3 注册中心原型系统的设计 2.3.1 原型系统结构设计 2.3 注册中心原型系统的设计 2.3.1 原型系统结构设计 在设计私有注册中心系统时，采用了三层体系结构，表示层、功能层和数据层， 这三层分成相对独立的单元， 这样设计的优点是加强了系统的可移植性和可伸缩性， 而且还方便管理和维护。表示层一般采用 web 浏览器，在 b/s 模式下用户可以通过 浏览器向分布在网络上的许多服务器发出请求，极大的简化了客户机的工作，客户 机上只需安装、配置少量的客户端软件即可，服务端将担负更多的工作。在表示层 中包含显示逻辑，它的功能是由 web 浏览器向网络上的某一 web 服务器提出服务 请求，然后 web 服务器用 http 协议把相应的页面传给客户端，并显示在 web 浏 16 览器上。功能层应该包含系统的事务处理逻辑，作用为接收用户服务的请求，然后 根据请求执行相应应用程序与数据库连接， 得到数据处理的结果再提交给 web 服务 器，最后由 web 服务器传回客户端。数据层包含系统的数据处理逻辑，它在接收 web 服务器对数据库操作的请求后，实现对数据库的增删查改等功能，并把结果传 回 web 服务器，再到客户端。 在图 2.4 中 uddiproxy 模块用于处理 soap 消息， 并根据客户端的请求来调用 相应的接口。比如，当客户只是执行注册服务操作时，uddiproxy 模块就把操作 权限交给注册模块，由该模块完成相对应的注册操作，并把注册的结果返回给 uddiproxy。然后些模块再把结果封装成 soap 消息，发送给 soap 引擎。数据 库接口层是完成注册中心和数据库服务器连接的中间层，该层的实现主要是采用 一个 jdbc 驱动与数据库进行连接。 图 2.4 原型系统结构图 web服务器接收并处理客户端调用web服务的http消息，将处理后得到的 soap消息传给uddi注册中心， 同时将uddi注册中心的soap响应消息封装成http 消息回送到客户端。数据库服务器主要存储各种注册信息。 可以看出，uddi注册中心包括4个主要部分，它们协同工作构成了一个轻量级 的web服务注册中心。当用户执行查找操作时，uddi服务代理模块把操作权交给查 询模块，由查询模块完成用户的查找操作。当用户进行发布操作时，代理模块首先 判断用户是否为合法用户，如为合法用户，便生成