about uddi root registry and affiliate registry

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.<?XML:NAMESPACE PREFIX = O />

 

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都不会重复了。