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