(本文最初由 IBM developerWorks 中国网站发表，其网址是http://www.ibm.com/developerWorks/cn/)
(本文是我在developerWorks专栏发表的UDDI v2新特性: 关联关系和发布者断言
的缩减版，需要浏览未缩减版原文，请访问http://www.ibm.com/developerWorks/cn/)
企业的需求促成了关联关系特性
随着UDDI 1.0注册中心的发布和测试使用的进行中，许多大型的企业集团，以及一些诸如交易市场和贸易团体等的虚拟商业实体认为UDDI规范第1版对于注册复杂的商业信息的支持不够。同时，对于UDDI规范第1版的实现的反馈信息表明，为每个独立的商业实体复制服务和绑定信息(可能他们使用了同一个服务)可实施性很强，但是不够优化。另外，另一些反馈表明要求用户对于区分商业实体，仅能使用的这一商业实体的一个名称来实现，这常常使的用户感到迷惑(因为一些企业往往有多个习惯使用的名称)。
而在2001年7月发布的UDDI规范2.0版为了解决这一使用中的核心问题，引入了一个基于”发布者断言(publisher assertion)”的断言特性。发布者断言是这样一种机制的基础，这种机制能令多于一个的已注册的businessEntity元素以某种方式互相链接，用以表示一种特定类型的关联关系。这也是这一特性常常被成为关联关系特性的原因。发布者断言一旦完整创建，即被用于在已注册的数据中建立公共可见的关联关系，这样一种断言的表现结果将可通过新增的UDDI v2中的通用查询消息find_relatedBusinesses进行证实，find_relatedBusinesses是用于在UDDI注册中心中寻找与指定businessEntity具备某种关联关系的那些businessEntity的API调用。
围绕使得商业实体能在不同的组成部分之间描述关联关系的设计目标是为了满足大型商业实体为在UDDI中描述数据的需要，使得他们在UDDI注册中心中能以多个组成部分的形式来实施注册。毕竟，大型商业实体是由很多小型的组成部分所组成的，同时对于其中的每个商业个体都有很多不同种类的Web服务需要描述。在UDDI规范2.0版之前，那些想对非常复杂的商业实体进行建模的注册者是无法完成需要的功能的。
为了使得关联关系中的任一方对于关联关系的公共可见性都具有一定的控制能力，因此另一个设计目标就是确保在一个潜在的关联关系中双方在同一时刻都表示同意该假设事实，那么才使该关联关系可见。这个设计目标是针对以下潜在问题的：当一个实体虚假地宣称其注册的businessEntity数据是一个大公司的一个组成部分，那么将会对这个未同意该断言的大公司带来损失。对于该项注册数据的阅读者而言，他们就有可能被虚假地引导，而相信这个注册的商业实体的的确确是那另一个大公司的组成部分。
关联关系模型
在UDDI v2中，关联关系的基本模型是使用了publisherAssersion这个断言元素，一个发布者断言(publisherAssertion)表示了一个用户对businessEntity之间的关联关系的断言。发布者断言(publisherAssertion)的基本结构如下：
<publisherAssertion>
<fromKey> [businessKey] </fromKey>
<toKey> [businessKey] </toKey>
<keyedReference tModelKey=”uuid:tbd” keyName=”[relationship_name]” keyValue=” [relationship]” />
</publisherAssertion>
一个发布者断言(publisherAssertion)由三个子元素fromKey、toKey和keyedReference组成，形成了如下图所示的有向关系：
其中fromKey和toKey分别是一个businessKey，指向一个现有的已注册的businessEntity。keyedReference表示了从fromKey所指代的businessEntity到从toKey指代的businessEntity之间的是何种关系。
我们看到，keyedReference元素仍然遵循UDDI v1中的keyedReference的结构，tModelKey指明了是使用何种关联关系定义的规范，这里用了”uuid:tbd”是UDDI内置的关联关系表示规范。keyValue指明了关联关系的代码，而keyName则是keyValue所指明的关联关系代码的名称描述。
发布者API定义了若干条消息，以使得UDDI发布者能够管理断言。这些消息可以分为两大类：协助管理功能和维护功能。协助管理类别的消息为发布者提供检阅他所管理的商业实体所关联的断言。特别的，get_assertionStatusReport对于判断发布者所管理的所有商业实体所涉及的断言是否完整非常有用。该消息不仅能使你发现那些断言是你尚需要去完成的，同时也可以让你发现是否有其他发布者在尝试创建与你的商业实体相关的断言，而这个断言可能是你并不知道的或者不同意的。
维护功能类消息能够使发布者既能对所有断言执行单条操作(如，add_publisherAssertions和delete_publisherAssertions)也能对所有断言作为一组(如，get_publisherAssetions和set_publisherAssertions)一起操作。如果发布者在某个时刻想要增加一条断言，但又不想在此刻了解其之前所下的所有断言，那么使用那些面向单条断言的消息是非常方便的。
注意：set_publisherAssertions消息能够通过在一次调用中删除所有断言而用于令所有断言不再有效。
本类阅读TOP10