Open your thoughts

本节定义 UDDI Custody and Ownership Transfer API Set. 通过创建一个实体, 一个发布者可以拥有该实体的所有权, 称他为这个实体的所有者. 一个保管节点必须通过授权机制维护一个实体和它的发布者的所有权关系. 多节点注册中心的每个节点必须保证集成了实体保管功能. 同样, 一个节点务必不可允许改变一个实体, 除非这个节点已经保管了这个实体.

Custody and Ownership Transfer API Set 使得一个注册中心的任意节点能够相互间从一个节点向另一个节点转移一个或多个 businessEntity or tModel 的保管关系, 也允许从一个发布者向另一个发布者转移这些数据的所有权. 一个 businessEntity 所包含的实体例如它的 businessService, bindingTemplate, 和 publisherAssertion 结构作为这个 businessEntity 保管关系转移的一部分进行转移.

从保管转移的视角来说, 参与这种转移的发布者总是不同的人, 尽管可能具有这种情况: 这些发布者都是同一个人. 这两个节点可能是不同的节点, 也可能是相同的节点; 两者发布者间的节点内(intra-node)转移简单退化为节点保管关系没有变化这种情况. 因而, 在节点内(规范上为inter-node, 注:这里应该是规范笔误)转移的情况下, 暗含的是所有权转移. 在节点内(intra-node)转移时, 这种转移使得两个发布者间进行所有权转移.

例如, 一个 UDDI 注册中心, UDDI-1, 可能允许每个节点(由节点1A, 1B and 1C组成)定义节点自己的注册, 认证, 授权策略. 在这种情况下, 一个”人(person)”, (P1) 会需要审视一下所有3个节点的策略, 决定注册到哪个节点上. P1 可能选择注册了多个节点. P1 注册了 node1A. Node1A 也指定了怎样验证 P1. 如果 P1 成功通过认证, 然后发布了一个 business entity (BE1), 这样 P1 成为 BE1 的 “owner”. Node1A 称之为 BE1 的 “保管人(custodian)”. P1 也可能注册到了 node1B. 如果成功通过认证并发布了一个 business entity (BE2), 这样 P1 成为 BE2 的 “owner”. Node1B 称之为 BE2 的 “保管人(custodian)”. 注册中心 UDDI-1 或者它的节点(node1A and node1B)不会意识到 P1 其实是同一个人.

另一个 UDDI 注册中心, UDDI-2, 可能需要它的每个节点(node2-1, node2-2 and node2-3)使用相同的注册, 认证和授权机制. 在这种情况下, 这些策略在所有节点中都是一样的. 它们的注册, 发布和所有权关系都保持相同. 如果 P1 想要注册到 UDDI-2 中的不同节点, 那就需要在这些不同的节点中区分这些注册关系, 因为在已经注册到了 node2-1 后又试图注册到 node2-2, 将会遭遇 “已经注册过(already registered)” 错误 (因为根据策略, 这些节点共享相同的注册, 认证和授权).

当在 save_xxx 操作中使用到 keyedReference 时, 它可能会被检查是否是有效的. 类似的, 在 save_xxx 操作中使用到一个 keyedReferenceGroup element 可能也要接受检查确定其是否有效. 检查针对那些被 UDDI 注册中心认为是 “checked” 的 tModels.
UDDI 提供了让第三方注册 value set 的能力, 然后控制检验过程(由 UDDI 使用)去执行这种检查. UDDI 注册中心可能支持缓存这些外部 value sets. UDDI 注册中心也可能支持外部校验. 由节点和注册中心策略确定使用哪种校验方式去执行对外部值集引用的检查. 这一系列 APIs 能够供 UDDI 注册中心和节点用在它们的校验策略中.
想提供一个外部检验能力的第三方实体可能需要使用跟 UDDI 一样的方式去实现一个 Web service(举例来说, 使用 literal encoding SOAP 作为消息传递机制), 这个 Web service 只暴露一个方法 validate_values. validate_values 接口将在随后描述.
在某些情况下, 一个节点可能希望消除或者减少对外部校验 Web service 的调用次数. 它能够通过缓存那些 允许缓存的外部值集 的有效值来达到这一目的. 一个节点有两种标准选项用于获得有效值的集合. 一个是周期性从那些实现了 get_allValidValues API Web service 的值集提供者那里获得有效值集合. 另一种获得有效值缓存的方式是累积每次从 validate_values 成功获得的有效值.

Value Set 编程接口

本系列的 APIs 提供了一种能力: UDDI registry 可能使用这种能力对值集的引用进行校验. 注册中心策略确定哪个外部值集是受支持的, 如何支持.
公共可访问的用于支持外部值集校验的 APIs 如下:

· validate_values: 由节点使用, 允许外部值集校验 Web service 的提供者评估 keyedReferences or keyedReferenceGroups 是否是有效的. 返回一个 dispositionReport 结构.
· get_allValidValues: 由支持从可缓存检查型值集缓存有效值的节点使用, 用于获得有效值的集合. 返回一个空消息或者一个 dispositionReport 结构.

注册中心策略可能需要提供其中一种 Web service 的值集提供者通过特定方式为这个 service 发布 bindingTemplate, 为该值集发布 tModel, 这样才能够找到正确的 Web service. 当一个值集提供者提供了其中一种 Web service, 应该在任何该提供者想要提供该值集的注册中心中为该检查型值集发布一个 tModel, 为值集提供者为该检查型值集提供的 Web service 发布一个 bindingTemplate. 该 tModel 应该具有 uddi-org:types category system 的分类, 表明值集类型(categorization, identifier, relationship, categorizationGroup), 是检查型的(checked), 并且, 如果该值集提供者允许根据节点对有效值的缓存进行校验, 也应该标明是 cacheable 类别.
为了让一个值集成为检查型的, 该 tModel 必须首先引用 uddi-org:types category system 使用 checked 值将其划为 checked 的.  检查这样的值集是由注册中心和节点策略决定的.
如果一个值集 tModel 被划分为 checked, 那么在试图发布一个使用到这个 checked tModel 的 keyedReference 时, 节点必须或者执行必要的校验, 或者返回 E_unsupported.
该 tModel 也应该具有一个到 get_allValidValues or validate_values Web service 的 bindingTemplate 的分类引用, 这需要使用 uddi-org:validatedBy category system.
get_allValidValues or the validate_values Web service 的 bindingTemplate 应该在它 tModelInstanceDetails 中引用适当的值集 tModel, 和其它该服务所适用的所有的值集 tModels.

security API 包括下面 APIs:

· discard_authToken: 用于通知节点以前得到的某 authentication token 不再需要了, 如果在接收到这个消息之后还有使用它的, 应该认为它是无效的.
· get_authToken: 用于从一个节点请求一个使用 authInfo element 样式的 authentication token. 在使用 Inquiry API Set, Publication API Set, Custody and Ownership Transfer API Set, 和 Subscription API Set 中的 API 时, authInfo element 可能是必需的.

API 是否需要 authInfo elements 是由节点策略决定的. 如果一个 authInfo element 最后并没有被丢弃, 节点可能会选择使这个 authentication token 过期, 这样可以让它不再有效. 如果一个过了期的 token 被传递给一个 API, 除了 discard_authToken 外, 将返回错误 E_authTokenExpired.
如果一个 UDDI 节点不支持在 API set 中使用 authInfo element, 通常它也不支持 Security API set. 如果节点支持在该节点所提供的任何 API set 中使用 authInfo element, 它应该也支持 Security API set. 一个节点可能提供另一种可替代(security api的)机制用于获得 authInfo elements.

discard_authToken：

参数：

· authInfo: 这个必需的参数包含一个 authentication token. Authentication tokens 可使用 get_authToken API 获得.

行为：

Discarding an expired authToken is processed and reported as a success condition.

返回值：

完全成功的话, 返回一个空消息(return null).

错误警告：

如果在处理这个 API 调用时发生错误, 将在 SOAP Fault 中返回一个 dispositionReport 结构给调用者.

get_authToken：

get_authToken API 用于获得一个 authentication token. 在使用 Inquiry API Set, Publication API Set, Custody and Ownership Transfer API Set, 和 Subscription API Set 中的 API 时, 一个 authToken element 可能是必需的.

参数：

· userID 属性: 这个必需的属性是 UDDI 节点分配给一个已授权过用户的标识符. 节点应该提供一种方式供用户获得一个在给定节点有效的 userID and password 认证信息.
· cred 属性: 这个必需属性是密码或者与该用户相关联的 credential.

返回值：

这个 API 调用完全成功后会返回一个 authToken 结构, 包含一个有效 authInfo element, 这个 authInfo element 就可以在接下来的请求中使用.
authToken element 包含一个 authInfo element. authToken element 总是作为对 get_authToken 调用的同步响应而返回.

错误警告：发生错误时, 必须返回一个 dispositionReport element.

· E_unknownUser: UDDI node 不接受和认可请求所传递的 userID and/or cred 参数值为有效认证信息.

save_binding：

save_binding API 用于保存或更新一个完整的 bindingTemplate element. 它可以用于添加或更新一个或多个 bindingTemplate elements, 也可以用于调整与某 businessService element 的包含关系. 每个 bindingTemplate 可能(MAY) 被签名, 可能(MAY)使用 publisher-assigned keys.

参数：

· authInfo: 略.

· bindingTemplate: 必需的. 可有1个或多个 bindingTemplate. 如要保存一个新的 bindingTemplate, 则提供一个 bindingTemplate element,
或者 bindingKey 属性值为空, 或者使用 publisher-assigned bindingKey.

每个新的 bindingTemplate 必须(MUST)包含一个 serviceKey 值, 该 serviceKey 所对应的 businessService 也是由该发布者所控制的. 一个已存在的 bindingTemplate 可能(MAY)包含一个 serviceKey 值, 对应于该同一发布者所控制的 businessService. 调用这个 API 将影响到每个 bindingTemplate 参数的父 businessService(即其父businessService可能会更改为其它businessService). 如果同一 bindingTemplate (由 bindingKey 值决定是否相同) 出现多次, 它的上级 businessService 具体是哪个将由处理顺序确定, 即决定于从第一个到最后一个(该相同的) bindingTemplate 的位置.
如果一个 bindingTemplate element 的 bindingKey 缺失或是一个空值, 这表示 bindingTemplate 首次被插入. 当出现这种情况的时候, node 必须(MUST) 自动为该没有 key 的 bindingTemplate 生成一个新 key. 新的 bindingTemplate 结构也可以使用 publisher-assigned keys.
使用这个 API, 可以将一个已存在的 bindingTemplate 从一个 businessService 移动到另一个 businessService, 只需要简单地为该 bindingTemplate 指定一个另一个不同的父 businessService 的 serviceKey. 通过这种方式改变父 businessService, 将对这两个 businessService 结构都产生影响. The net result of such a move is that the bindingTemplate still resides within one, and only one businessService based on the value of the serviceKey passed. 如果一个发布者尝试通过这种方式移动一个 bindingTemplate, 但并非该 bindingTemplate 中 serviceKey 所对应 businessService 的所有者, 那么该操作请求必须(MUST)被拒绝, 并返回一个 E_userMismatch 错误.
当一个 bindingTemplate 被保存, 且使用了 categoryBag 关联到一个 checked value set 或 category group system tModel, 这些 references 必须(MUST)先于保存操作完成之前接受有效性检查, 或者 node 必须返回 E_unsupported 指出它并不支持引用 checked value set 或 category group system.

Publisher API 概要：

• add_publisherAssertions: 用于向已存在的断言集合中添加关系断言.
• delete_binding: 用于从 registry 中移除一个已有的 bindingTemplate.
• delete_business: 用于删除已有的 businessEntity 信息.
• delete_publisherAssertions: 用于从一个特定发布者所控制的断言集合中删除该特定发布者的断言. 从断言集合中删除断言影响到商业实体关系的可见性. 删除一个断言导致任何基于那个断言的关系都将成为不完整的.
• delete_service: 用于删除一个已有的 businessService.
• delete_tModel: 用于隐藏已有的 tModel 的信息. 任何使用这个方式隐藏掉的 tModel, 对于引用来说, 仍将是可用的, 并且可以通过 get_tModelDetail API 访问, 但从 find_tModel 结果集中是看不到的(即被hidden). 没有任何方式可以(真正、物理)删除一个 tModel.
• get_assertionStatusReport: 用于获得包含发布者断言和状态信息的状态报告. 这种报告对于帮助管理员管理发布者断言来说是非常有用的. 返回的 assertionStatusReport 包括发起该请求的发布者所控制的任何 businessEntity 构成的所有断言的状态.
• get_publisherAssertions: 用于获得一列由某发布者控制管理的发布者断言. 返回的 publisherAssertions 结构包含所有与这个发布者有关联的发布者断言.
• get_registeredInfo: 用于请求一个给定发布者当前所管理的 businesses 和 tModels 的简要列表.
• save_binding: 用于注册新 bindingTemplate 信息或更新已有的 bindingTemplate 信息. 使用这个 API 去管理某注册商业实体所暴露出来的技术能力信息.
• save_business: 用于注册新 businessEntity 信息或更新已有的 businessEntity 信息. 使用这个 API 去管理整个商业实体的全部信息集合, 包括它的 businessService 和 bindingTemplate 结构. 这个 API 在所有 save_xx APIs 中有最广泛的影响.
• save_service: 用于注册或更新一个 businessService 的完整信息.
• save_tModel: 用于注册或更新一个 tModel 信息.
• set_publisherAssertions: 用于保存一个发布者的发布者断言的全部集合. 这个 API 将替换任何已有断言, 导致任何的没有被重新 reasserted 的旧断言被删除掉.

这个系列的 API 用于发布和更新 UDDI registry 中的数据.
根据 UDDI registry 的 policy, 发布者选择 UDDI node 用于发布信息.
从调用者的角度来看, 这一系列的 API 必须(MUST)全部实现为 synchronous 且 “atomic”. 即, 每个调用必须(MUST)或者完全成功或者完全失败. 务必不能(MUST NOT)返回部分结果.

发布实体时使用节点指定的(node-assigned) keys
当发布者没有为新实体提供 keys 时,  UDDI node 将依照 registry policy 指定 keys. Node-assigned keys 必须(MUST)遵从 Section 4.4 关于 uddiKeys 的语法.

发布实体时使用发布者指定的(publisher-assigned)keys

registry 键策略可能(MAY)允许一个实体的 key 由发布者提供. 如果发布者没有为实体提供 key, registry 必须为其指定一个. 因为实体 keys 在一个 registry 中必须(MUST)唯一, 不管它是什么实体类型(即在所有类型的实体中key都必须唯一), 并且, 因为 registries 必须定义关于哪些发布者可以发布何种 keys 的强制性策略, 所以, publisher-assigned keys 是受 UDDI registry 所施行的规则所支配的. 对所有 registry 来说, 必须保证对所有的实体类型来说 key 都是唯一的(Behavior that ensures uniqueness across entity types (businessEntity, businessService, bindingTemplate, tModel and subscription) is REQUIRED for all registries). 这一系列讨论 registry 所应该使用的受推荐的 “uddi:” key 结构. 这种方式提供了唯一性, 并且提升了在多个 registry 间的互操作性, 同时允许建立各种不同的 registry-specific policies. 对这种方式的实践指南可以在规范(Section 9.4.2 <General Keying Policy> and Section 9.4.3 <Policy Abstractions for the UDDI keying scheme> 找到.

find_service：

查找 businessService elements, 返回 serviceList.

参数：

maxRows 属性：可选, 同上

businessKey 属性：可选. 查找这个 businessKey 的 businessEntity 中的 businessService.

投影服务也会包含在结果集中, 除非指定了 “suppressProjectedServices” findQualifier. 如果 businessKey 被省略或指定了一个空值(i.e., businessKey=”"), 这表示要搜索所有 businessEntities 下的 services, 但不包括投影服务.

listHead 属性：可选, 同上

authInfo 元素：可选, 同上

findQualifiers 元素：可选, 同上

name 元素：0..∞. 多个 name 一般会使用 xml:lang 属性.

因为 “exactMatch” 是默认匹配方式, 所以对 name 参数将进行精确匹配(exact match). 如果使用了 “approximateMatch” findQualifier 同时在 name 中又使用了适当的通配符, 那么包含在指定 businessEntity(或者, 如果省略了businessKey或者指定空值, 那么就搜索所有的business) 中的任何匹配 name 值的 businessService 数据将作为结果返回. 如果传递了多个 name 参数, 对这些 name 的匹配方式将是逻辑 OR. 每个 name 可能(MAY)会使用 xml:lang 修饰. 如果指定了语言标记, 那么匹配同时基于 name 和语言. 对语言的匹配将是从左至右、忽略大小写的比较.

categoryBag 元素：包含一列分类引用, 只有匹配所有分类的service才会被返回.(默认是逻辑 AND)

指定适当的 findQualifiers 能够覆盖这个默认匹配方式.

tModelBag 元素：所包含的bindingTemplates具有由这些tModelBag中的tModelKey所指向的技术指纹的businessService.

在 UDDI 中每个 Web service instance 都是用一个 包含于 businessService 中的 bindingTemplate 表示的. 一个bindingTemplate 包含一组 tModel 引用, 称之为它的”技术指纹(technical fingerprint)”. tModelBag 参数是一组 tModelKey 值, 表示搜索出的结果应限于那些 所包含的 bindingTemplates 具有这些(由这些tModelKey指定的)技术指纹的 businessServices.

find_tModel 元素：这是对指定tModelKey(指使用tModelBag)的一种替换用法.

UDDI 的 APIs 分为 inquiry API, publication API and the OPTIONAL security, custody transfer, subscription and value set APIs.

Inquiry API 支持 3 种方式的查询：

1. browse pattern

先进行宽泛查找, 得到大的结果集, 从中选择更具体的信息进行更细微的查找(drill-down).

规范通过提供 find_xxx APIs 支持这种查询. 这种查询得到的是比较粗略的信息. 比如, 调用 find_business, 传递给一个 business name, 或者 business name 的一部分, 也可以使用通配符.  然后会返回一个 businessList 结果, 包含的是一些概要信息, 如keys, names and descriptions.

2. drill-down pattern

核心数据结构的每个实例 – businessEntity, businessService, bindingTemplate and tModel – 都有一个 key, 当使用 find_xx APIs 时, 这个 key 也会出现在概要信息中. 通过把这个 key 传递给相关的 get_xx API, 很容易取得对应实例的全部注册信息.

3. invocation pattern

开发阶段用到, 不详述.

Find Qualifiers：

每个 find_xx APIs 都接受一个可选的 findQualifiers 参数, 可以包含多个 findQualifier 值.  Find qualifiers 可以是 tModelKeys, 也可以是一个包含简短名字的字符串. UDDI 中每个预定义的 findQualifiers 都能用适当的 tModelKey 或者它的简短名字(short name)而被引用. registry 必须支持这两种方式, 必须在接受 find qualifiers 时不区分大小写. 可以增加新的 find qualifiers, 但注册中心没有义务和责任去支持它们. 当 Find qualifiers 没有被 node 识别时, 会返回错误 E_unsupported.

UDDI 必有的API：

1. Inquiry

UDDI 应有的API：

1. Publication
2. Security
3. Custody and Ownership Transfer API
4. Replication

UDDI 可选的API：

1. Subscription
2. Value Set API

SOAPAction 的支持：

UDDI 要求 SOAP 消息具有名为 SOAPAction 的 HTTP Header, 为了最广泛的兼容各工具, SOAPAction 可以包含任何值, 包括空字符串.

SOAP Actor 的支持：

UDDI 不支持 SOAP Actor 特性.

UDDI nodes 必须拒绝任何在 SOAP Header element 中带有 SOAP Actor 属性的请求, 返回一个不带详细元素(detail element)的 SOAP fault, 和一个 “客户端” 错误码(faultcode). 错误字符串(faultstring)会清晰地指出问题所在.

SOAP encoding 的支持：

UDDI 不支持 SOAP encoding 特性.

在 “urn:uddiorg:*” namespace 下的任何元素都不能有任何 encoding style 声明. 如果有这种声明, node 必须以一个 SOAP fault(不带有详细element) 和一个 “客户端” 错误码(faultcode)作为响应. 错误字符串(faultstring)会清晰地指出问题所在.

在 UDDI 核心数据被发布的时候, 该发布操作的信息会被记录下来.
这个数据包含了该数据结构创建和修改的日期和时间, 该发布操作发生的 UDDI node 的标识符, 和发布者的身份标识(identity). UDDI 数据结构的操作信息可以通过 get_operationalInfo inquiry API 访问.

operationalInfo 数据结构用于传输 UDDI 核心数据结构的操作信息, 即 businessEntity, businessService, bindingTemplate and tModel structures.

1). entityKey 属性：必需的, 唯一标识与该操作信息相关联的 UDDI 实体

2). created 元素：可选. 与该操作信息相关联的 UDDI 实体的创建时间

3). modified 元素：可选. 指明与该操作信息相关联的 UDDI 实体的最后(被save操作)修改的时间. 开始时, 这个值与 created 的值是相等的.

有些实体具有包含关系, 如一个 businessEntity 可包含一个 businessService, 如果单独对该 businessService 做了更改(如save_service对该 businessService 进行修改), 不会改变该 businessService 的父实体 businessEntity 的最后修改时间.

4). modifiedIncludingChildren 元素：没搞懂什么意思

Instead, the modifiedIncludingChildren element in the containing entity contains the maximum of its own
modified element and the modifiedIncludingChildren elements of each of the entities it contains (if any).
If a contained entity is deleted or moved elsewhere, the modifiedIncludingChildren element is also updated, since such operations would otherwise not be documented elsewhere. Changes in a service that is being projected do not affect the modifiedIncludingChildren element of the businessEntity in which it is projected. The modifiedIncludingChildren element should not be returned for operationalInfo elements corresponding to bindingTemplate or tModel elements since there are no contained elements that can be modified independently.
The degree to which the clocks of each UDDI node used to generate the created, modified, and modifiedIncludingChildren elements are synchronized is not architecturally specified, but rather is a matter of registry policy. Likewise, the frequency with which each clock is incremented (e.g.: 60Hz, 100Hz, etc.) is also a matter of registry policy.
5). nodeID 元素：唯一标识了与 operationalInfo 相关联的实体的 custody node

在对 UDDI Node 进行配置时 – 对于实现了 UDDI Replication 的 node, 这个 element 必须匹配与这个 node 相关联的 Replication Configuration element 中指定的值.
6). authorizedName 元素：

一个 node 可能会在 authorizedName element 中提供一个对应于 entityKey 的数据所有者的标识. 这个 authorizedName element 的准确内容和 authorizedName element 应当如何被解释是依赖于 registry 和 node 的 authentication, identification 和 privacy policy.
在一个拥有多 node 的 registry 中, operationalInfo 必须包括必要的信息, 这样 inquiry 的结果才会跨越所有 node 而保持一致. nodeID, authorizedName, modified 和 created element 在多 node 的 registry 中是强制性的, 包括在 get_operationalInfo 调用的响应中和在 replication changeRecords 所包含的 operationalInfo element 中. 在多 node 的 registry 中, 对应于 businessEntity 和 businessService element 的 operationalInfo element 必须带有 modifiedIncludingChildren element.