（系统工程专业论文）WebService架构下UDDI机制和UDDI技术的研究.pdf

硕t 论文w c bs e r v i c e 架构下u d d t 机铷鞠u d d i 技术的研究 摘要 随着w e bs e r v i c e s 架构的不断成熟，利用和研究其中的技术就变得越 来越必要。w e bs e r v i c e s 是一种全新的架构，是下一代电子商务的基石， 它通过引入注册中心和服务发现、发布机制实现了系统间的动态集成和动 态w e b 服务模式，u d d f 是w e bs e r v i c e s 架构中的核心技术之一。u 1 3 1 3 1 技术以规范的形式出现，主要包括三部分内容，即注册中心的实现，服务 的发现和描述，它们都建立在规范中所定义的基本数据结构的基础上。 本文主要研究了w e bs e r v i c e s 架构中的u d d i 机制和u d d i 技术，分 析了u d d i 中的数据结构、服务发现、服务发布操作以及注册中心实现技 术等，设计了u d d i 客户应用程序，提出并实现了对服务发现操作的改进 羡赂。 关键字：x m lw e bs e r v i c e su d d i 发现策略 j a 、，a 第l 页 硕士论文w e bs e r v i c e 架构下u d d i 机制和u d d i 技术的研究 a b s t r a c t w i t hw e bs e r v i c e sc o n f i g u r a t i o n 。sc o n t i n u o u s l ym a t u r i n g ，i ti sg e t t i n gm o r e a n dm o r e n e c e s s a r yf o ru st ou t i l i z ea n dr e s e a r c hi t st e c h n o l o g y w e bs e r v i c e s i san e w c o n f i g u r a t i o n ，a n di sa l s ot h ef o u n d a t i o ns t o n eo ft h en e x te b u s i n e s s g e n e r a t i o n w e bs e r v i c e sh a sr e a l i z e dd y n a m i cc o r p u sa n dw e b s e r v i c em o d e l b yi n t r o d u c i n gc e n t e rr e g i s t e r s e r v i c ed i s c o v e r y & p u b l i c a t i o n u d d ii so n e o ft h ec o r et e c h n o l o g i e si nw e bs e r v i c e sc o n f i g u r a t i o n u d d it e c h n o l o g yi s m a d eu po fs o m ep r e s c r i p t i o n ，m a i n l yi n c l u d i n gt h r e ep a r t s ：t h er e a l i z a t i o no f c e n t e r r e g i s t e r ，s e r v i c ed i s c o v e r ya n d s e r v i c ep u b l i c a t i o n a l lo ft h e ma r e e s t a b l i s h e di nt h eb a s i cd a t as t r u c t u r ew h i c hi sd e f i n e di np r e s c r i p t i o n t h eu d d im e c h a n i s ma n du d d i t e c h n o l o g yi nw e b s e r v i c e sc o n f i g u r a t i o n a r em a i n l yr e s e a r c h e di nt h i sp a p e r s e v e r a lt e c h n o l o g i e sa r ea n a l y z e d ，s u c h a st h ed a t as t r u c t u r e ，s e r v i c ed i s c o v e r y ，s e r v i c ep u b l i c a t i o na n dt h er e a l i z a t i o n o fc e n t e rr e g i s t e r t h eu d d ic l i e n ta p p l i c a t i o np r o g r a mi s d e s i g n e d ，a n dt h e i m p r o v e ds t r a t e g yi ns e r v i c ef i n d i n gi sp u tf o r w a r da n di m p l e m e n t e d k e y w o r d s ：x m lw e bs e r v i c e su d d i d i s c o v e r ys t r a t e g y j a v a 第2 页 硕士论文 w e bs e r v i c e 架构下u d d i 机制和u d d i 技术的研究 1绪论 1 1 论文研究的背景和意义 在过去的十年，是i t 产业“疯狂发展“的阶段，很多企业和组织在 信息化方面投入了大量的资金，取得了很大的发展。但同时应该看到的是 由于在整个发展的过程中，缺少统一的规划，企业( 也包括其他类型的组 织，为了简单以下就单提企业) 的各项服务就成为一个个孤岛，它们之间 缺乏或很难实现互操作。 现在，把各个已有的服务孤岛连接起来，提供一套整体的服务的任务 变得越来越紧迫。这样做主要有两个方面的原因：首先是企业发展的需要， 企业若要作出快速、准确的决策，就需要随时了解本企业的情况。比如一 个企业的办公决策系统应该可以随时调用财务系统里当前的财务状况等。 另外，从节约企业成本的角度来看，企业已经为已有的各项服务系统投入 了大量的资金，而且这些服务就其本身来说是符合要求的，所以企业必须 让这些已存在的服务系统继续发挥作用，这也符合企业员工的要求。对于 企业中已经使用的服务系统，员工比较熟悉，如果重新编写一套新的系统， 就需要投入大量人力物力对员工重新进行培训。 除了上面讨论的企业内部集成的问题外，在企业之间，电子商务( b 2 b ) 变得越来越普及，越来越必要。比如对于一个汽车生产商来说，它的一个 降低成本的方法就是减少库存。而要做到这一点，就必须和零部件供货商 密切合作。从企业信息化的角度来说，汽车零部件供货商必须能够随时调 用汽车厂的服务，从而得到如订单数量、对零部件的质量的要求、何时交 货等等信息。在本质上我们可以把电子商务也看作是一种系统的集成，只 是它是一种跨越i n t e r n e t 的集成，我们同样需要解决这种类型的集成问题。 要实现各个系统之间的互操作( 也就是系统集成) ，可以有很多种方 法。比如当前使用较多的是基于x m l 的远程过程调用( x m l r p c ) 。该 方法与其它方法相比，拥有很多的优点。首先因为该远程过程调用是基于 x m l 的，所以就具有了平台和语言的独立性。另外，因为x m l 可以依附 于h t t p 协议进行传输，所以这种方法可以很方便地穿过防火墙。但是， 该方法有一个致命的缺点，就是它不够灵活。因为在编写调用程序时，完 全依据了被调用的接口的情况，一旦接口发生了改变，或者说调用者需要 改变调用对象时，就必须重新编写程序。而在实际工作中，改变调用对象 预上论义 w e bs e r v i c e 架构下u d d i 机制和u d d | 技术的研究 又是非常平常的事。比如上面提到的汽车生产商的例子中，汽车生产商可 以按要求决定选择不同的零部件供货商。对于零部件供货商来说，它也可 以把产品卖给出价高的汽车商。 那么怎样才能满足这种动态互调用呢? 一个可行的方法就是在调用 者和被调用者之间放一个中间环节，通过这个中间环节方面隔离两者的 个性，另一方面把调用方法连接起来，这就是w e bs e r v i c e 技术的关键。 w e bs e r v i c e 是最近发展起来的一项新技术，它很好地解决了企业当前 面临的多系统集成难的问题，通过使用注册中心这一方式使系统集成变成 一种动态的行为。w e bs e r v i c e 是一项比较复杂的技术，它建立在其它多项 相关技术的基础上。首先w e bs e r v i c e 使用了x m l 作为最低层的数据传输 格式，这样使得它具有x m l 的一切优点。在应用层上，w e bs e r v i c e 使用 了s o a p 协议，该协议以x m l 为基础。最后，w e bs e r v i c e 采用w s d l 进 行统一的服务描述，在服务的发现和发布过程中，采用了u d d i 规范。 在w e bs e r v i c e 架构中，u d d i 是一项最重要的技术，也是整个架构的 核心，所以要研究w e bs e r v i c e ，关键就是要研究u d d i 。该技术最主要的 思想是引入一个注册中心的概念，通过注册中心把服务的提供者和服务请 求者联系起来。这样服务的提供者和调用者之间就属于一种松散的连接， 很方便实现改变调用关系，也就是说，实现了集成的动态性。 w e bs e r v i c e 是一项新兴的技术，同时它也是一项发展很快的技术。随 着w c bs e r v i c e 技术被不断的了解和接受，将有越来越多的企业采纳它作 为系统集成的方式，随之将会出现一大批私有的和公有的u d d i 注册中心。 1 2 本论文的主要内容 本论文主要研究了w e bs e r v i c e 架构下的u d d i 机制和u d d i 技术， 设计了u d d i 客户应用程序，提出并实现了对服务发现操作的改进策略。 本文首先在第二章论述了w e bs e r v i c e 架构，详细论述了w e bs e r v i c e 架构是一种用来动态实现系统集成非常合适的方式。w e bs e r v i c e 架构是一 项复杂的技术，其中包括了x m l 、s o a p 、w s d l 和u d d i 等内容。 在本论文的第三章，详细讨论了u d d i 规范和u d d i 机制，u d d i 规 范是w e bs e r v i c e 架构的核心。该章内容包括了u d d i 中的数据结构、服 务发现、服务发布以及注册中心实现技术等，并通过两个具体的例子进行 分别说明。 在第四章，介绍了本人的主要创新工作，包括对u d d i 客户端产品的 进一步封装，为用户提供了一个统一的接口。使用封装好的包编写了客户 硕i 论文 w e bs e r v i c e 粜构下【) i ) d i 机制和u i ) d i 技术的研究 应用程序，使得用户可以利用可视化界面方便地进行服务的发现和发布操 作。同时提出了对服务发现部分的改进策略，主要是扩展服务发现的范围， 在不改变已有的用户程序接口的前提下，使得服务发现可以在多个注册中 心进行，并对此提供了代码实现。 最后是本文的总结。 硕i ：论文w e bs e r v i c e 絮构下u d d i 机制和u d d i 技术的研究 2w e bs e r v i c e 研究 随着信息化步伐的不断推进，企业的发展越来越依赖于计算机技术， 各企业均建立了不同用途的信息系统。但随着应用范围的扩展，企业系统 集成已经变成当前迫切需要解决的问题，这主要有两方面的原因： 一方面是企业内部需要进行集成。由于历史的原因，企业内部可能拥 有多个不同的信息系统，而这些已存在的系统可能是基于不同平台。利用 不同的编程语言来开发的。而随着企业的发展，原有的单个系统已不能满 足需求。企业需要把已存在的系统组合起来，使一个系统可以调用另外一 个系统的服务，达到扩展功能的目的。比如企业的办公决策系统可以随时 调用财务系统里当前的财务状况，这样可以让企业的领导层更正确、更快 捷地做出决策。但从节约成本的角度来说，企业不可能完全抛弃已有的系 统来重新开发一套新的系统，一个较好的方案是修改现有的系统，通过一 套适当的机制来达到系统集成的目的。 另一方殛是企业之间需要进行集成。以前的电子商务主要发生在客户 和企业之间( b 2 c ) ，而现在企业和企业之间的合作变得越来越重要( b 2 b ) 。 比如对于一个汽车生产商来说，它的个降低成本的方法就是减少库存。 丽要做到这一点，就必须和零部件供货商密切合作。从企业信息化的角度 来看，汽车零部件供货商必须能够随时调用汽车厂的服务，从而得到如订 单数量、对零部件的质量的要求、何时交货等等信息。而这里就存在两个 问题。首先，各企业的内部系统可能不一样，数据格式不同，从而导致数 据传输和数据理解的困难。另外，企业之间的关系也不是固定的，汽车生 产商可以按要求决定选择不同的零部件供货商；而对于零部件供货商来 说，它也可以把产品卖给出价高的汽车商。也就是说，企业之间的系统集 成是动态的。 那么应该怎样才能做到系统之间的动态集成呢? 通过分析，要实现动 态集成，我们必须解决三个问题： ( 1 ) 数据格式 要使一个系统能够调用另一个系统，首先必须定义一种这两个系统都 能够解析的数据格式。另外考虑到系统的复杂性和使用的灵活性，定义的 数据格式必须是独立于平台和编程语言的，同时应该具有可扩展性。 ( 2 ) 协议 在定义了数据格式后，系统之间只是在数据层上具有了集成的能力。 硕l 论文 w e bs e r v i c e 架构下u d d i 机制和u d d i 技术的研究 然而从技术的角度来看，这仅仅完成了应用领域中最低层次的集成：数据 层集成。而集成的双方必须就数据之外的系统细节达成一致，必须了解对 方的接受方式，网络协议，访问入口，安全性要求等。也就是从模块层的 角度来说，仍然停留在一个不利于集成的阶段。为了能让模块层能够以一 种开放的，自说明的，统一的方式进行集成和交互，我们必须定义一种协 议，而且这种协议必须得到现有的网络协议( 如h t t p ) 的很好支持。 ( 3 ) 动态集成 我们在上面的分析中提到，企业之间的系统集成必须是动态的。也就 是说，任何一家符合一定要求的企业应该可以很方便地进入现有的系统 中。或者说，现有的系统也应该可以很容易地调用任何一家符合一定要求 的企业的服务，而这家被调用的企业在调用之前可能是不确定的。 当前出现的w e bs e r v i c e 技术能够很好地解决企业之间的动态集成问 题。那么w e bs e r v i c e 技术是怎样解决上述三个问题的呢? 首先，w e b s e r v i c e 以x m l 作为底层数据传输的格式；在应用层，使用了s o a p 协议； 关于集成动态的问题，w e bs e r v i c e 引入了注册中心的概念，同时规范了整 个服务发布和发现的实现方式。 2 1x m l w e bs e r v i c e 以x m l 作为各个系统之间进行传输的一种通用数据格 式，那么到底什么是x m l ? 我们为什么会选择x m l 呢? 在接下来的部分 将进行详细的论述。 2 1 1x m l 介绍 1 、什么是x m l x m l ( e x t e n s i b l e m a r k u pl a n g u a g e ) 即可扩展的标记语言，它是一种 用于描述信息的标记性语言，与所用的编程语言和操作平台无关。 为了了解x m l ，下面先给出一个例子。假设有一个有关计算机游戏 信息的属性集合，需要表达的信息包括该游戏的名称和它出现的年代。我 们就可以用下面的代码来表达： ? x m lv e r s i o n = “10 “? g a m ey e a r = 1 2 0 0 3 。 x m li n v a d e r s 需要说明的是，以上代码包含3 个标记：g a m e s ，g a m e 和n a m e 。其中g a m e 预j ：论文 w e bs e r v i c e 架构下u d i ) i 机制和u i ) d i 技术的研究 元素有一个属性y e a r ，该属性的值为2 0 0 3 。n a m e 元素的值为x m l i n v a d e r s ，该元素包含在g a m e 元素的起始和结束标记之间。 x m l 允许用户创建自己的结构，可以根据自己的需要和习惯来定义 标记和属性，从而可以以一种更有意义的方式描述信息。这方面与h t m l 存在根本性的区别，h t m l 使用标签( 所谓标签就是包含在一对尖括号中 的标识符，例如 ) 的目的是用来描述数据的显示方式，这些标签起 到标记的作用。例如，我们要将一行字显示成粗体就可以这样来描述： w o r d st h a tw i l lb eb o l d 与h t m l 不同的是，x m l 中的标签是用来标识数据内容本身的，就像我 们在程序中给变量取一个比较容易理解的名称一样，它将一个数据片断用 友好的名字标识起来以易于使用，例如： 小明 姓名，这样的描 述可以很方便地知道“小明”是一个人的姓名。 2 、x m l 文档的正规性和有效性 与h t m l 相比，x m l 的格式要严格的多。它包括两方面的要求，即 格式的正规性和文档的有效性。下面列出了格式正规的x m l 文档的几个 主要的要求： 每个元素都要有一个起始标签和一个结束标签； 每个x m l 文档都要有一个唯一的根元素： 元素和属性的名字区分大小写； 元素必须正确的嵌套，在结构上不能交迭，如下的嵌套是不正确 的： ； 有些字符内容不能直接使用，必须由其它的字符组合代替( 例如 使用l t ；代替 ) ； 属性的值必须包含在引号( 单引号或双引号) 之中； 空元素可以用简单的方式描述( 如 可以简化成 ) 。 完整的规则详见x m l 规范，x m l 规范由万维网联盟( w 3 c ，w o r l dw i d ew e b c o n s o r t i u m ) 维护，w 3 c 的网址为：h t t p ：w w w w 3 c o r g 。x m l 规范规定 了创建x m l 文档的规则和语法。 有时候x m l 文档只是格式正规还不够，它还必须是有效的( v a l i d ) 。 但有效的x m l 文档首先必须是格式正规的，同时还要遵循d t d 或s c h e m a 所建立的规则( d t d 将在下面介绍) 。一个有效的x m l 文档只能包含d t d 或s c h e m a 所规定的元素和属性，而且还要符合它们所确定的嵌套规则和 数据类型。x m l 文档的有效性是相对的，即相对于某个d t d 或s c h e m a 有效。 利用d t d 和s c h e m a 检验x m l 文档的有效性就是对x m l 文档的确认。 第6 页 硕l ：论义w e bs e r v i c e 聚构下i h ) d i 机制和u d d i 技术的研究 3 、文档类型定义( d t d ) 因为x m l 文档在文档结构上很少有限制，这样在建立x m i 。文档的时候 就具有很大的随意性，这将给x m l 的应用带来麻烦。所以需要使用些方 法将约束条件置于文档上。 文档类型定义( d t d ，d o c u m e n tt y p ed e f i n i t i o n ) 就是一种将约束 置于x m l 文档的结构上的方法。它可以规定x m l 文档中元素的名称、嵌套 关系等。以下是一个简单的d t d 的示例。 f i n a lf a n t a s y 这个d t d 有两个元素类型声明，分别由 标记来指定。d t d 可以用予描述元素、每个元素包含多少子元素以及元素在x m l 文档中的 次序。而且，d t d 可以为元素的属性提供约束信息。 2 1 2w e bs e r v i c e 选择x m l 的原因 w e b s e r v i c e 之所以选用x m l 作为底层的数据传输格式，主要是考虑 到x m l 拥有的诸多优点。 1 、基于纯文本 由于x m l 是纯文本的，所以很容易进行数据交换，不必为解析复杂 而且专用的数据格式费力( 如将一个m i c r o s o f to f f i c e 文档转换成另一种格 式的代价) 。 2 、面向内容的标签 x m l 的标签告诉的是它有什么样的内容，而不是如何显示它，这使 得x m l 中的数据具有自描述能力，也就使彳导应用程序可以很容易的理解 x m l 文档的含义。 3 、易处理性 由于x m l 文档具有格式正规性，且内容又是自描述的，这样它就可 以很容易被分析处理。使用x m l 解析器来查询、修改、转换一个x m l 文档是非常方便的。 4 、层次结构和可扩展性 硕士论文 w e bs c r v i c c 架构下u d i ) i 机制和u d d i 技术的研究 x m l 文档的层次结构( 一种树型的结构) 使得它更容易被理解、操 作。同时，x m l 文档是很容易进行扩展的，这使得x m l 能满足各种要求。 5 、国际化能力 因为x m l 对u n i c o d e 字符集的支持( 可以在x m l 文档中声明所用的 编码方式来确定所采用的字符集) 。w 3 c 规定使用的x m l 解析器都必须 能够处理u n i c o d e ，也就是使x m l 的使用国际化了。 2 2s o a p s o a p 协议解决了本章开头提到的协议的问题，它使得系统有能力在 模块级上进行集成。 s o a p 即简单对象访问协议( s i m p l e o b j e c t a c c e s sp r o t o c 0 1 ) ，这是一 种基于x m l 的应用协议，用来在分布式环境中交互信息。s o a p 的1 1 版 本由d e v e l o p m e n t o r 、i b m 、m i c r o s o f t 和u s e r l a n d 一起开发，并且在2 0 0 0 年5 月完成草案。它包括i b m 和l o t u s 的技术，具有供应商中立性、跨平 台、编程语言和对象模型中立性等优点。最新草案1 2 版本在2 0 0 2 年6 月完成，由w 3 c 成立的x m lp r o t o c o lw o r k i n gg r o u p 开发。s o a p 的正式 w 3 c 标准规范可在h t t p ：w w w w 3 o r g t r s o a p l 2 处找到。 图2 - 1 所示为s o a p 的架构，它定义了一个消息框架、编码规则和协 议绑定。 图2 1s o a p 架构 s o a p 架构的底层传送协议可以为h t t p 、s m t p 等，通过绑定将信息与消 息框架连接。s o a p 的两个主要设计目标是简单性和可扩展性。 s o a p 有两个方面的应用，一是用来发送消息，另一个是用来发送用 x m l 格式编码的远程过程调用。对应这两种应用，就有两种相应类型的 s o a p 消息： 习圈习圆 颀卜论文w e bs e r v i c e 架构下u i d i 机制和u d d i 技术的研究 l 、d o c u m e n t 类型的s o a p 消息 d o c u m e n t 类型s o a p 消息的 中包含一个或者多个元 素( 叫做p a r t s ) 。没有s o a p 规则来限制 中包含什么( x m l 格式的文档即可) 。它可以包含任何内容( 只要发送方和接受方同意) 。 2 、r p c 类型的s o a p 包含了要调用方法名( 或者是远程过程名) 以及一些 元素( 每个元素对应方法中的一个参数) 。以下得代码就是一个r p c 类型 的s o a p 请求消息的例子，其中略去了h t t p 头信息。 s o a p e n v e l o p e s o a ph d 口 i h e a d e r p a r t s i s o a p b o d y 1l i 助d yp a r t s ( p a y l o a d ) l s o a p f a u l t l 图2 2s o a p 梢息结构 s o a p 消息编码为x m l 文档，其结构如图2 2 所示，它由一个强制的 s o a p 封皮、一个可选的s o a p 消息头以及一个强制的s o a p 消息体组成。 3 e m p l d 2 3w e b s e r v i c e 架构 以上我们定义了数据传输的格式，同时规定了在模块层次上的应用协 议，这样互异系统之间就可以进行集成了。但是这种集成一般是比较固定 的，如个系统需要和另一个系统进行集成，也就是说需要调用另一个系 统的某项服务，调用者需要预先知道被调用服务的特性，然后根据这些特 硕士论文w e bs e r v i c e 槊构下u d d i 机制和u d d i 技术的研究 住编写相应的调用程序代码。这种方法存在的一个突出问题就是缺乏灵活 性，当被调用的服务特性发生改变，或者需要被调用对象发生改变时，就 需要重新编写相应的调用程序。这和我们的最终目的是不相符的，我们的 最终目的是要让集成变成一种动态的行为。 为了达到这样的要求，就需要建立一套机制，而w e bs e r v i c e 架构就 能满足这样的要求。 2 3 1w e bs e r v i c e 定义 从表面上看，w e bs e r v i c e 就是一个应用程序，它向外界提供一个能够 通过w e b 进行调用的a p i ，也就是说，我们能够使用编程的方法通过w e b 来调用这个应用程序。我们把调用这个w e bs e r v i c e 的应用程序叫作客户 ( 也叫服务请求者) 。例如你想创建一个w e bs e r v i c e ，它的作用是取得 某个公司的股票价格，那么你可以建立一个j s p 页面，它接受股票代号作 为查询参数( 字符串) ，然后返回这个股票的当前价格。可以通过h t t pg e t 请求方法调用这个服务： h t t p ：w w w m y c o m p a n y c o m s t o c k q u o t e js p ? s t o c k = 1 l1 它返回的结累可能是这样：7 2 3 这个j s p 页面就算作是一个w e bs e r v i c e 了，因为它基于h t t pg e t 请求， 提供了一个透过w e b 调用的a p i 。 这里，我们给w e bs e r v i c e 一个更精确的定义：w e bs e r v i c e 是一种用 于应用程序集成的新技术；是一个建立要操作分布式应用程序的新平台。 2 3 2w e bs e r v i c e 架构 1 、w e bs e r v i c e 中的角色及其相互关系 在w e bs e r v i c e 架构中，首先定义了三耱角色：服务提供者( s e r v i c e p r o v i d e r ) ，服务注册处( s e r v i c er e g i s t r y ) 或者叫注册中心和服务请求者 ( s e r v i c er e q u e s t o r ) ，分别说臻如下： ( 1 ) 服务提供者 从企业的角度来看它是服务的所有者，从整个体系的角度看它是容纳 服务的平台。 ( 2 ) 服务请求者 从企业的角度来看它是一个寻求一定服务功能的请求者，从整个体系 的角度来看它也是个寻找和调用服务的应用程序。服务请求者可以是浏 览器( 由入操作) ，也可以是一个没有用户界面的程序( 如另外一个w e b 第1 0 页 颅 论文 w c bs e r v i c e 架构下u i ) i ) i 机制和t j d d i 技术的研究 s e r v i c e 应用程序) 。 ( 3 ) 服务注册处 它是服务提供者发布其服务描述的地方，同时也是服务请求者发现服 务并且得到绑定信息( 包含在服务描述之中) 的场所。这种绑定可以是静 态的绑定( 开发过程中) 也可以是动态的绑定( 运行过程中) 。对于静态 的情况来说，服务注册处在整体的结构体系中是一个可选的角色，因为服 务提供者可以将相关的服务描述直接送到服务请求处。同样，服务请求者 亦可以从其它的地方得到服务描述，例如本地文件、f t p 站点、w e b 站点、 a d s ( a d v e r t i s e m e n ta n dd i s c o v e r yo f s e r v i c e s ) 、d i s c o ( d i s c o v e r y o fw e b s e r v i c e ) 等等。 图2 3w e bs e r v i c e 角色及相互关系 下面说明他们之间的关系，见图2 3 。服务提供者把自己的服务发布 到服务注册处，而服务请求者到服务注册处查找自己感兴趣的服务，得到 相应的服务信息后，接着对该服务进行绑定，这样服务请求者就可以调用 服务提供者提供的服务了。从这个过程中我们可以看出，服务提供者和服 务请求者之间不是直接相连的，而是通过了服务注册处这个中间环节。这 样做可以满足动态绑定的要求，因为如果一个服务提供者想要加入到系统 中，它只要把自身的服务发布到服务注册处以供服务请求者调用就可以 了。而从服务请求者的角度来说，它可以方便地调用已经在服务注册处注 册的服务提供者提供的服务。 2 、w e bs e r v i c e 中的操作 w e b s e r v i c e 中存在三种操作：发布( p u b l i c a t i o n ) 、发现( d i s c o v e r y ) 和绑定( b i n d i n g ) ： ( 1 ) 发布( p u b l i c a t i o n ) 如果想要一个服务能被访问，就必须先发布有关它的服务描述，至于 要发布在什么地方则取决于应用程序的要求。 倾j 论文 w e bs e r v i c e 架构下i j i ) 【) i 机制和i j d d i 技术的研究 ( 2 ) 发现( d i s c o v e r y ) 在发现这一操作中服务请求者可以直接得到服务描述，亦可以从服务 注鹏处查询到所需的服务。有两个阶段服务请求者可能会使用发现操作； 在设计阶段，使用该操作以得到服务的接口描述；在运行时则使用该操作 来获得与服务相关的绑定和位置信息以便于调用。 ( 3 ) 绑定( b i n d i n g ) 运行时，绑定操作中服务请求者利用服务描述中的有关绑定的详细信 息来定位、连接和调用一个w e b 服务。 通过以上的分析可知，w e bs e r v i c e 架构通过一个中间环节( u d d i 注 册中心) 来实现系统的动态集成。当处于集成系统中的两方要发生调用关 系时，它们就将分别扮演服务请求者和服务提供者的角色，它们之间的关 系是通过注册中心来建立的。 但这里还存在几个问题需要解决。首先是怎样描述服务? 服务提供者 在发布服务时第一步要做的就是描述服务，然后把描述信息发布到注册中 心。另一个问题是关于发现、发布和绑定操作的标准。因为可能存在多个 注册中心，如果没有一个统一的标准，那么就很难统一地使用这些注册中 心了。2 3 3 节和2 3 4 节介绍的两种技术将解决这两个问题。 3 、w e bs e r v i c e 的执行过程 当服务调用者找到一个具体的服务，完成动态绑定之后。具体的调用 服务的过程如图2 - 4 所示： 薰windows 圈i 固_ j s o a pr e s d o i ) $ e 二 图2 4w e bs e r v i c e 的执行过程 由图可以看出，w e bs e r v i c e 中对客户端没有作特殊的要求，客户端可 以是浏览器，也可以是一个应用程序，客户端可以属于各种平台。另外， 客户端和服务器之间一般传送的是s o a p 消息。 硕士论文 w e b s e r v i c e 架构下u d d i 机制和u d d | 技术蝗卿窭 2 3 3w s d l w s d l 即w e b 服务描述语言( w e bs e r v i c ed e s c r i p t i o nl a n g u a g e ) 是 用于描述w e b 服务的一种x m l 语言，它将w e b 服务描述为一组对消 息进行操作的网络端点。一个w s d l 服务描述包含对一组操作和消息的 一个抽象定义，绑定到这些操作和消息的一个具体协议和这个绑定的一个 网络端点规范。w s d l 文档分为两种类型：服务接口( s e r v i c ei n t e r f a c e ) 和服务实现( s e r v i c ei m p l e m e n t a t i o n s ) ，结构如图2 5 所示： 图2 5w s d l 文档类型 服务接口文档包含t y p e s 、i m p o r t 、m e s s a g e 、p o r t t y p e 和b i n d i n g 等 元素，它们一起将用于实现一个或多个w e b 服务的定义。服务接口是w e b 服务的抽象定义，并被用于描述某种特定类型的服务。通过使用一个 i m p o r t 元素，一个服务接口文档可以引用另一个服务接1 3 文档。例如， 一个仅包含m e s s a g e 和p o r t t y p e 元素的服务接口可以被另一个仅包含 此p o r t r y p e 的绑定的服务接口引用。 w s d l 服务实现文档包含i m p o r t 和s e r v i c e 元素，它包含实现一个 服务接口的服务的描述。i m p o r t 元素将至少包含一个对w s d l 服务接口 文档的引用。一个服务实现文档可以包含对多个服务接口文档的引用。 服务接口文档由服务接口提供者开发和发布，服务实现文档由服务提 供者创建和发布。服务接口提供者与服务提供者这两个角色在逻辑上是分 离的，但在一般情况下他们为同一个商业实体。比如一个企业一方面定义 了自己的接口规范，另一方面也提供具体的实现。 接下来的两段代码分别为服务接口和服务实现的例子，它们一起用来 描述一个股票查询服务。其中服务接口清单中包含了一个d o c u m e n t a t i o n 硕i 论文 w c bs e r v i c e 架构下u | ) d i 机制和u d d 技术的研究 元素，它描述了这个接口的特性。与图2 - 4 中有一点不同的是，接口清单 中没有定义t y p e s 元素，这是因为在下面的元素定义中用到的数据类型都 是简单类型。接下来我们看m e s s a g e 元素，这里有两个m e s s a g e 元素，分 别是s i n g l e s y m b o l r e q u e s t 和s i n g l e s y m b o l q u o t e r e s p o n s e 。它们分别在定 义操作的时候被引用。操作在元素p o r t t y p e 中定义，每一个操作对应一个 o p e r a t i o n 元素。这里只定义了一个操作( g e t q u o t e ) 。 s t a n d a r dw s d ls e r v i c ei n t e r f a c ed e f i n i t i o nf o ras t o c kq u o t es e r v i c e o p e r a , o nn a m e = 。g e t q u o t e 。 s o a p ：o p e r a l a o ns o a p a c t i o n = ”h t t p ：l w w wg e t q u o t ec o m o e t q u o t e 。 到这里我们已经抽象定义了整个服务，接下来我们还需要指定服务真 正的物理网络实现。因为我们希望通过s o a p 使用服务，所以这里定义了 一个s o a p 绑定。在关于s o a p 的介绍中已经提到，s o a p 可以和h t t p 第1 4 页 硕i 论文 w e bs e r v i c e 架构下u d d i 机制和u d d ! 技术的研究 协议绑定，也可以和s m t p 等其他的协议绑定。这里s o a p ：b i n d i n g 元素表 示这是一个s o a p 和h t t p 协议的绑定。另外，s t y l e 属性表示所使用的 s o a p 类型，同样在上面的介绍中我们可以知道，该属性值可以为d o c u m e n t 或r p c ，而默认情况下是d o c u m e n t 。在这里，我们采用r p c 。 有一点需要注意的是，w s d l 是通过其他元素的n a m e 属性值来引用 的。例如在定义操作时对m e s s a g e 元素的引用。 至此，我们已经编写了一个w s d l 文档。该文档定义了一个抽象端 口类型。这种类型的文档可以用作一个通用的服务定义，在不同的服务器 或服务代理程序上可重复利用这类文档，只是实现的方法可能会有所不 同。接下来我们看一个具体的服务实现，它就是利用了上面我们已经定 义的接口( 通过i m p o r t 元素) 。这个实现文档指定了具体的服务，同时定 义了一个真实的网络地址以便用户连接。 s t o c kq u o t es e r e i c e s i n 西es y m b o ls t o c kq u o t es e r v i c e $ e r v i c e 2 3 4u d d i 统一描述、发现和集成协议( u d d i ，u n i v e r s a ld e s c r i p t i o n ，d i s c o v e r y a n di n t e g r a t i o n ) 是套基于w e b 的、分布式的、为w e b 服务提供信息的注 册中心的实现标准规范，同时也包含一组使企业能将自身提供的w e b 服务 注册以便使别的企业能够发现的访问协议的实现标准。也就是说，u d d i 包括了三部分内容，首先是注册中心，包括定义注册中心需要提供的标准 服务接口及其所用到的数据结构，这部分是服务器端的技术。剩下两部分 是客户端的技术：一个是关于发布服务的规范，也就是定义了发布服务的 a p i 接口；还有一个就是发现服务的规范，也就是定义了发现服务的a p i 接口。 第1 5 页 硕i 论文 w e bs e r v i c e 架构下u d d i 机制和u d i ) i 技术的研究 如图2 - 6 所示，u d d i 包含于完整的w e b 服务协议栈之内，而且是 协议栈基础的主要部件之一，支持发现和发布w e b 服务。 u d d i 构建于网络传输层协议( 如h t t p ) 和基于s o a p 的x m l 消 息传输层之上。诸如w e b 服务描述语言( w e bs e r v i c ed e s c r i p t i o n l a n g u a g e ，w s d l ) 之类的描述服务的语言提供了统一的x m l 词汇，这 与交互式数据语言( i n t e r a c t i v e d a t al a n g u a g e ，i d l ) 类似，以供描述w e b 服务及其接口使用。用户可以通过添加分层的功能搭起整个基础，比如使 用w e b 服务流程语言( 、e bs e r v i c ef l o wl a n g u a g e ，w s f l ) 来实现w e b 服务工作流描述、安全性、管理和服务质量功能，从而解决系统可靠性和 可用性问题。 u d d i w s d l s o a p h t t p ，f t p ，目n a m q ，i i o p ，既c 图2 6w e bs e r v i c e 协议栈 u d d i 解决了企业当前遇到的大量问题。它能帮助拓展商家到商家 ( b 2 b ) 交互的范围并能简化交互的过程。对于那些需