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.

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