uddi学习总结

概述

UDDI的概念前几年炒的特别火,好像最近有些降温.正好在工作中用到了UDDI,于是写篇文章,简单介绍一下UDDI.

统一描述,发现和集成协议(UDDI)是一套基于Web的,分布式的,为Web服务提供的信息注册中心的实现标准规范,同时也包含一组使企业能将自身提供的Web服务注册以使得别的企业能够发现的访问协议的实现标准.它定义了对web service的信息公开以及搜索方法, 提供了一组基于因特网的实现. UDDI的意图是作为一个注册簿,就象黄页是一个地区企业的注册簿一样.象在黄页中那样,在UDDI注册簿中,企业将在不同的目录下注册它们自己或其服务.通过浏览一个UDDI注册簿,开发人员能够查找一种服务或一个公司,并发现如何调用该服务. 除了黄页外,UDDI还使用了白页和绿页.白页是企业实体列表,绿页是调用一项服务所必需的文档.

Web Service发展的理想状态就是开发商开发通用的Web Service,然后在UDDI中心注册,这样在互联网上有谁需要这个Web Service就可以调用.开发商可以把Web Service一次性卖给客户,也可以按次收钱,或按时间收钱.但从目前的发展来看这种形势的Web Service的发展并不是很充分,至少在国内这样的.所以UDDI的概念也没概念刚提出来的时候那么火了.好像Web Service更多的和SOA联系在一起,侧重企业内部系统的开发,集成.所以这几年UDDI好像要被搁置,IBM等大公司都在开发自己的Registry中心,而不太重视UDDI中心的概念.但不管怎样,作为业界通用的Web Service注册中心的规范,绝大多数公司在实现自己的Registry的时候,都会支持UDDI规范的.这样才能为客户提供一个统一的操作方式.所以我们在做自己产品的时候,还是需要在技术上对它进行支持.UDDI是建立在XML,SOAP,WSDL之上的一个规范.

UDDI Registry (UDDI注册中心)：UDDI Registry是所有提供公共UDDI注册服务的站点的通称.UDDI Registry是一个逻辑上的统一体,在物理上则是以分布式系统的架构实施的,而不同站点之间是采用P2P(对等网络)架构实施的,因此访问其中任意一个站点就基本等于访问了UDDI Registry.

UDDI Operator Site (UDDI注册中心操作入口站点,简称UDDI操作入口): UDDI Operator Site是UDDI Registry中每一个对等结点,对于UDDI Operator Site的查询所获得的结果是覆盖全UDDI Registry中的信息的,信息查询无需身份认证；而在UDDI       Operator Site上进行信息发布则必须使用该UDDI Operator Site自身的用户方能实施,同时以后的更新,删除都必须通过这个Operator Site,并使用初始发布时使用的用户进行权限认证.

Compatible UDDI Registry(兼容的UDDI注册中心): 所有兼容UDDI规范但并非属于提供公共服务的UDDI Registry的个别UDDI注册中心,都称为兼容的UDDI注册中心.

UDDI 的所有兼容实现都必须支持UDDI 规范.公共规范是机构成员在开放的,兼容并蓄的过程中开发出来的.目前UDDI规范有三个版本.UDDI 版V1规范于 2000年9月发布,V2于2001年6月发布.V3于2002年9月发布.

V1打下了注册中心的基础,实现了作为服务注册查询中心的基本功能.

V2是基本是对V1规范完善和功能上的补充,并无本质区别.V2引入了一些很关键的功能,如企业关系.有了这些功能可以提高V1规范UDDI注册中心的使用质量和效率.例如,如下功能：

更强大的客户机分类和标识符支持

增强的查询

国际化功能

基于对等的复制

而且,V2规范现在已经成为商家协同开发UDDI注册服务中心的通用标准.如现在所知道的几个代表性的UDDI注册服务中心都是遵从V2规范实现的.

V3则在前有基础上作出很多变动,形成了层次化Registry 管理体系模型,并提出了很多新概念.V3解决正在进行的 Web 服务开发中的重要领域内的问题,如安全性,改善了的国际化,注册中心之间的互操作性以及为进一步改进工具而对 API进行的各种改进.

2 技术

信息模型

UDDI 注册使用的核心信息模型由XML Schema 定义, 定义了四种主要信息类型: 商业实体信息,服务信息,绑定信息和服务调用规范的说明信息.

·businessEntity：简单说就是表示一个实际的企业.它包括了商业实体的名称和一些关键性的标识 ,以及该商业实体是属于那个具体工业分类之类的分类信息,以及联络方法(包括Email,电话,URL)等信息. 所有"businessEntity"中的信息支持"黄页"分类法.

·businessService：就是一个企业提供的服务.它描述了企业提供的这个服务的基本信息. businessService和下面要提到的bindingTemplate一起构成了"绿页"信息.

·bindingTemplate：就是关于如何调用服务的说明.包括应用程序连接远程Web 服务并与之通讯所必须的信息.这些信息包括Web应用服务的地址,应用服务宿主和调用服务前必须调用的附加应用服务等.

·tModel：在UDDI 的数据模型中,tModel是一个很特殊的数据项,也是最难懂的一个数据项. 在UDDI中使用tModel的目的如下：
对商业实体进行标识和分类
对商业服务进行标识和分类
对tModels进行标识和分类
将商业服务绑定到它们抽象的tModel定义上

tModel描述了UDDI技术信息,tModel的全体组成了UDDI 中的所有技术注册信息.我的理解tModel就是一个名字空间,一个模版或者说一个schema.这个schema定义了一个模型,而一个服务就是符合这个模型的一个实例.比如说一个电话号码就可以是一个tModel,它就是个模型,在中国就可以把这个模型定义成:区号+电话号码.这样一个公司要有电话号码的属性,它会引用这个tModel,这样这个电话号码就会符合这个tModel定义的模型.在给这个公司的电话号码赋值的时候就要符合区号＋电话号码的格式。复杂一点,对于一个Web Service,我们也可以定义一个tModel.这个tModel规定了个模型:如何访问这种类型的Web Service.这个Web Service提供了什么样的接口,需要什么样的参数,可以得到什么类型的结果等等.定义了tModel之后,不同的企业或个人就可以实现自己的Web Service,使这个Web Service符合这个tModel定义的模型.这样,用户就可以通过tModel来查询有什么企业提供了这种类型的服务,就可以根据tModel的规范来调用这样的Web Service.

结合一个WSDL文件来讲,tModel就是WSDL的服务接口部分,businessService就是WSDL的service部分,bindingTemplate就是service的port.

API

对于程序员来说,需要了解的就是查询API与发布API.这里简单介绍一下:

查询API包含两类调用,使程序能快速地定位候选商业实体,Web服务及其调用规范,然后在最初调用获得的初始信息的基础上,获得进一步的相关信息的细 节.这类以find_xx命名的API提供了多种搜索标准,从而能对注册中心中的数据进行广泛地搜索.另一方面,如果事先已经知道所需数据的关键字,则可 以通过直接调用get_xx API得到相应的结构数据(如：businessEntity,businessService,bindingTemplate,tModel).

发布API包括四个save_xx 函数和四个delete_xx 函数,每个对应于一个UDDI主要结构(businessEntity, binsinessService, bindingTemplate,tModel).一旦得到授权,一个独立的机构可以注册任意数量的businessEntity 或tModel信息,也可以修改原先发布的信息.API设计模型很简单：可以更改特定的相关信息,也可以使用save功能来保存新信息.要删除整个结构则可以调用delete功能.详细信息请参见程序员API规范(Programmer's API Specification).

至于一个发布一个服务的具体过程,可以参看下面的一篇文章,个人觉得很不错，相信看过后会对tModel有更进一步的理解：     http://www.ibm.com/developments/cn/webservices/ws-uwsdl/part1/

V3规范则提出了一个全新的UDDI体系框架.V3规范认为将会有很多不同的UDDI Registry存在,而每一个UDDI Registry具体是由很多或者一个Node（可以看作等同于V2 规范中的Operator Site）组成的.这些Registry共同形成一个庞大的系统.如果仍然采用V2规范体系框架的话,就难以保证所有Registry的键值KEY完全没有冲突Collision.解决办法是建立一个UDDI Root Registry,它统管着其他的Registry,这些Registry就成为Root Registry 的Affiliate（隶属的）Registry.例如,有一个root Registry 是UDDI Business Registry（UBR）,它拥有一套用来生成唯一UUIDKEY 和通过数字签名验证DomainKey 有效性的机制.这些策略就保证了在整个UDDI Business Registry中DomainKey和UUIDKey的全局唯一性,而且这个UBR也就理论上成为一个root Registry.

V3 规范下的UDDI体系框架可如下图所示：

V3这种构架使得UDDI能够具有很多以前构架不能实现的功能,如一个Publisher希望将在一个Registry注册的全部UDDI Registry Entity在保持同一键值（KEY）的情况下复制到另一个Registry中.另外,V3还提供了数据共享功能（Data Sharing）,实现更广泛的分布.V3规范对于UDDI的发展来说是相当重要的.

这里详细介绍一下KEY的概念。

在V3版本中，由于有了多Registry中心的概念，就需要定义一个可以在所有Registry中都唯一的KEY，这样我们的数据才可以自由的移动。这个KEY的格式：uddi:partition（1..n）:KEY.具体这个KEY机制是怎么实现的呢：

我们有一个根的UDDI Business Registry,这是有IBM,Microsoft,NTT Communications和SAP共同运作的。这样其他的Registry由这个根Registry赋予一个值，在规范中这个值就是指一个partition（域）。也就是说这个根Registry会给不同的子Registry分配一个值域，这个子Registry只能在这个值域里发布自己的KEY或生成自己的下一级partition。

比如说IBM公司，根Registry付给它一个值：com.ibm。这就是属于IBM的partition。这样在这个子的Registry中，IBM的程序员就不用关心其他公司的Registry的信息，也就是说他们会以为这个com.ibm的Registry就是他们的根。这样这个Registry的管理员就可以在这个Registry中建立自己的公司的partition，并赋给不同的服务发布者；也可以在这个域上直接发布KEY。比如说，我们可以发布一个服务，来完成IBM网站的登陆功能，给它设定KEY＝login。这时候，这个KEY的完整的值就应该是它所在的域加它的值，中间以冒号分开：uddi:com.ibm:login。

再比如说com.ibm这个子Registry的管理员建立了一个新的partition，并付给开发部门：develop。这时候我们开发部门的发布者就可以在这个域中创建KEY了。为了登陆开发部门自己的网站我们可以发布一个登陆服务，它的KEY也叫login。这个KEY的完整值就是：uddi:com.ibm:develop:login。这样，在这个开发部门的域中，这个登陆服务的KEY为login。它的值在开发部门的域中是唯一的。而到了IBM的域中，开发部门的服务，我们就在这个KEY值前加develop的域名,这样我们的KEY就变成了develop:login,这样以来我们就保证了在IBM公司内这个KEY是不重复的.同理，在整个世界的根Registry中，我们的服务的KEY就变成了com.ibm:develop:login，这样就保证了我们的KEY在任何地方都不会重复。

同时发布者也可以再创建自己的子partition，在子partition上还可以继续创建partition，这样无限递归下去。就可以创建一个树型的partition结构了，我们可以在这个结构的任一个节点发布KEY，这样的KEY都不会重复了。