|
UDDI v2新特性:关联关系和发布者断言广告 UDDI v2新特性:关联关系和发布者断言
Chief System Architect 2001年10月12日 本文介绍了UDDI v2中引入的新特性：为支持大企业集团注册多个彼此具有某种关联关系的businessEntity提供了
关联关系断言的这个特性。通过关联关系断言，使得大企业集团在UDDI注册中心中能以多个组成部分的形式来实施注册。UDDI
v2的这一设计在完成必须的功能需求的同时，兼顾了可管理性和可控制性，为我们在UDDI
v2注册中心中管理复杂的商业实体提供了有力的支持。 随着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数据是一个大公司的一个组成部分，那么将会对这个未同意该断言的大公司带来损失。对于该项注册数据的阅读者而言，他们就有可能被虚假地引导，而相信这个注册的商业实体的的确确是那另一个大公司的组成部分。 在具体的设计中包含了这样一个需求的表现，管理控制商业实体的发布者与该实体所在的关联关系的断言表现，对于双方发布者而言是对等的。当在一个关联关系表示的双方中，如果是由不同的两个发布者个体分别控制管理一个businessEntity的话，那么两个实体都需要就相同的关联关系的事实下断言，当双方的断言一致后，UDDI将会使与这样一个关联关系相关的所有信息令公共可见。而如果当在一个关联关系表示的双方中，如果是由不同的两个发布者个体分别控制管理一个businessEntity的，双方中有一方对所下的关联关系断言有异议。那么这个关联关系将无法通过查询API查询到，也就是说对公众是不可见的。 关联关系模型 在UDDI v2中，关联关系的基本模型是使用了publisherAssersion这个断言元素，一个发布者断言(publisherAssertion)表示了一个用户对businessEntity之间的关联关系的断言。发布者断言(publisherAssertion)的基本结构如下：
一个发布者断言(publisherAssertion)由三个子元素fromKey、toKey和keyedReference组成，形成了如下图所示的有向关系： Figure 1. 关联关系表示
我们看到，keyedReference元素仍然遵循UDDI v1中的keyedReference的结构，tModelKey指明了是使用何种关联关系定义的规范，这里用了"uuid:tbd"是UDDI内置的关联关系表示规范。keyValue指明了关联关系的代码，而keyName则是keyValue所指明的关联关系代码的名称描述。 在UDDI v2中，内置了三种关联关系代码： parent-child:
用于指明由断言中fromKey引用的businessEntity(如，控股公司)是由断言中toKey引用的businessEntity(如，子公司)的父辈实体。
我们知道关联关系断言中的fromKey和toKey都是关联某个businessEntity的，一般来说是关联不同的businessEntity，只有当这两个businessEntity的管理用户都对这一关联关系下了断言，才认为这个关联关系是确立的，对公众可见的。如果有一方没有确认这个关联关系，那么这个关联关系就没有生效，对公众不可见。如果这两个businessEntity的管理用户是同一个用户，也就是一个用户管理了这两个businessEntity，那么只需要下一次关联关系断言就可以了，这也是UDDI v2规范的注册方法。 另外需要注意的是fromKey和toKey都可以为空，这时候同样表示了一个尚未生效的关联关系(一种中间状态)。 应用示例 下面我们通过一个商业注册的例子来具体介绍关联关系注册的使用模式。 Emerson和Christine两个人分别在UDDI注册中心中管理了一个businessEntity。Emerson注册的是Business E实体，而Christine注册的是Business C实体。在这个假想场景的一开始，Emerson和Christine都已经在他们各自使用的UDDI操作入口站点(Public UDDI Operator)上注册了一个businessEntity。Emerson和Christine都希望使UDDI的使用者能够发现这样一个事实，这两个businessEntity都是事实上同一商业实体的一个组成部分，其中Business E是Business C的父辈商业实体(比如Business E是Business C的控股公司或者是母公司等)。 为了使所有通过传入双方任意一个businessKey(Business E或Business C)而调用find_relatedBusinesses的用户能发现这样一个关联关系，Emerson和Christine都必须创建一个发布者断言。如同这一操作的名称所暗示的，发布者断言是由一个发布者所创建的断言，该发布者是想表述一个关于某个注册的商业实体的事实，这个商业实体与UDDI注册中心中另一个商业实体存在着某种关联关系。 这个流程如下，Emerson将会使用一个应用程序来帮助他管理他的UDDI注册中心中的数据，同时将会创建一个关于Business E和Business C的发布者断言，这个发布者断言表述了Business E是集团控股公司这个事实。Emerson通过自己的软件来表述了这个事实，具体来说就是使用这个软件向UDDI注册中心发送了一条add_publisherAssertions消息。该消息的内容如下：
在这个例子中，我们可以看见Emerson断言了：businessKey取值为BK1的businessEntity是businessKey取值为BK2的businessEntity的父辈控股公司。 由于现在仅有Emerson一人断言了这个事实，关于该关联关系的信息还无法通过查询API调用find_relatedBusinesses来获得。Emerson知道如果要让这个断言公共可见，那么BK2这个businessEntity的发布者也必须表述同样的断言。于是，Emerson通过电话告诉Christine，希望她能够创建这个断言。 Christine为了查阅她自己必须表述的信息，因此她向她的UDDI操作入口站点发送了一条get_assertionStatusReport消息。从assertionStatusReport返回消息中，Christine发现对于她的BK2这个businessEntity确实列着一条未匹配的断言。当Emerson联络她，同时她也就这个应当在UDDI注册中心中公共可见的关联关系达成一致之后，Christine向她的UDDI操作入口站点发出了完全相同的断言(当然，使用了另一个authInfo认证令牌)。 UDDI操作入口站点现在发现了由这两个发布者所创建的断言，这两个发布者分别控制管理了关联关系中涉及的一个商业实体。在检验了请求方分别控制了关联关系中各自的一半之后，UDDI操作入口站点匹配了这两个断言，同时将该关联关系的状态置为完整。 当以上操作完成后，任何通过传入BK1或BK2作为businessKey的值而实施对find_relatedBusinesses这个查询API进行调用的用户都会发现这个关联关系。在这两个发布者都断言了这同一个事实之前，与该关联关系相关的数据在查询API中不可见。 管理关联关系的可见性 发布者API定义了若干条消息，以使得UDDI发布者能够管理断言。这些消息可以分为两大类：协助管理功能和维护功能。协助管理类别的消息为发布者提供检阅他所管理的商业实体所关联的断言。特别的，get_assertionStatusReport对于判断发布者所管理的所有商业实体所涉及的断言是否完整非常有用。该消息不仅能使你发现那些断言是你尚需要去完成的，同时也可以让你发现是否有其他发布者在尝试创建与你的商业实体相关的断言，而这个断言可能是你并不知道的或者不同意的。 维护功能类消息能够使发布者既能对所有断言执行单条操作(如，add_publisherAssertions和delete_publisherAssertions)也能对所有断言作为一组(如，get_publisherAssetions和set_publisherAssertions)一起操作。如果发布者在某个时刻想要增加一条断言，但又不想在此刻了解其之前所下的所有断言，那么使用那些面向单条断言的消息是非常方便的。 注意：set_publisherAssertions消息能够通过在一次调用中删除所有断言而用于令所有断言不再有效。 add_publisherAssertions add_publisherAssertions API调用会将一个或多个publisherAssertion加入到某个发布者的断言聚集(assertion collection)中去。 delete_publisherAssertions delete_publisherAssertions API调用会将一个或多个publisherAssertion从某个发布者的断言聚集(assertion collection)中删除。 get_assertionStatusReport get_assertionStatusReport消息为确定当前未决的发布者断言的状态提供管理上的支持，这些断言涵盖了当前发布者帐号所管理的所有商业注册所关联的所有断言。通过使用这个消息，发布者可以查阅他创建的断言的状态，同时也可以查阅由其他的发布者帐号所创建的与自身管理的某个businessEntity结构相关联的断言。 get_publisherAssertions get_publisherAssertions API调用用于获取与指定发布者帐号相关联的发布者断言的全集。 set_publisherAssertions set_publisherAssertions API调用用于管理指定发布者帐号所关联的所有可追踪的关联关系断言。 小结 本文介绍了UDDI v2中引入的新特性：为支持大企业集团注册多个彼此具有某种关联关系的businessEntity提供了 关联关系断言的这个特性。通过关联关系断言，使得大企业集团在UDDI注册中心中能以多个组成部分的形式来实施注册。UDDI v2的这一设计在完成必须的功能需求的同时，兼顾了可管理性和可控制性，为我们在UDDI v2注册中心中管理复杂的商业实体提供了有力的支持。 参考资料
作者简介
如果您希望与本文章的作者或其所在机构，进一步交流，请联系：畅享网 姜小姐 jill.jiang@amteam.org | 021-51096826-112 | 在线联系 |
 节能与优化IT 企业CIO过冬良策当前金融危机的影响还在继续漫延，很多企业都在苦寻过冬的良策，在这种情况下，节能与优化技术与产品无疑成为CIO们关注的首要对象，本次选题就是针对节能与优化IT来为CIO们提供过冬的良……  观08软件并购风潮 议09巨头何处生花2008，似乎注定是不平静的一年。有人说2008是并购年。业内人士表示，在全球软件行业，并购一直是大企业谋求做大做强的捷径之一，包括甲骨文、SAP，微软等全球软件巨头都为了扩大自己…… |
|
|