UDDI 规范 v3.0.2 – UDDI Programmers APIs 之 Custody and Ownership Transfer API Set
本节定义 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)” 错误 (因为根据策略, 这些节点共享相同的注册, 认证和授权).
Overview
有许多关于发布者可能选择转移实体保管人或所有权关系的场景.
节点内所有权转移(Intra-Node Ownership Transfer)
节点内所有权转移包括在同一 UDDI 节点内, 从一个发布者向另一个发布者转移实体所有权. 这类转移的使用场景包括如下:
· 商业实体或者组织合并: 多个组织需要整合到一个单一发布者进行管理.
· Domain key generators: 所有权转移的一个用处是由一个发布者向另一个发布者转移一个 derived key generator 所有权, 使得后者可以使用这个 domain 内的 keys 发布实体.
save_xx APIs 也可以用于在(由同一发布者所拥有的)双亲实体间移动实体. save_service API, 例如, 能够用于在一个 business entity 和另一个 business entity 间(使用save_service API)移动 services (和 binding templates). 使用这种方式改变双亲关系将使得两个 businessEntity 结构发生改变. 见以下使用场景:
· 剥夺: 一个组织需要重新分配一组服务的控制权给两个或多个发布者.
· 注册中心实体的合并: 某个商业实体有多个实体要合并到单一一个发布者名下.
节点间保管关系转移(Inter-Node Custody Transfer)
节点间保管关系转移包括跨越 UDDI 注册中心多个节点的一组实体的保管关系转移. 所有权转移会跟随着保管关系转移而发生. 除了以上描述的节点内的使用场景, 节点间保管关系转移还可能用于下面这些用例:
· 令人不满的服务水平: 某节点提供的功能和服务水平不够, 发布者希望将他们的数据转移到另一个节点.
· UDDI 节点可用性发生变化: 某节点不再提供 UDDI 服务, 所有发布者都需要迁移到注册中心的其它节点上.
· 组织合并, 剥夺或巩固: 组织结构变化可能导致需要更改负责管理注册中心各节点上实体的发布者.
对于节点内和节点间的这些使用场景, 本系列提供了一个机制便于在节点间转移 businessEntity 和 tModel 实体的保管关系, 不管是否实体是在单一一个节点内转移, 或者不管是否是在注册中心的多个节点间转移这种保管关系.
保管关系转移时的特殊考虑
当一个 businessEntity 被转移时, 所有相关 businessService and bindingTemplate elements 也被转移. 另外, 任何引用了这个 businessEntity element 的 businessKey 的 publisherAssertion elements 也会被转移.
注意, 在一次保管关系转移请求中, 并不会要求该放弃保管关系的发布者转移他的所有 UDDI 实体(也就是 businessEntity 和/或 tModel 实体), 也不会要求他将他的所有实体转移给同一接收发布者或者接收节点. UDDI 注册中心实体可以转移给任意数目的接收发布者或者接收节点.
转移执行过程
Custody and Ownership Transfer API 能够使在一个 registry 中的两个发布者 P1 and P2 和两个节点, N1 and N2, 相互配合, 将一个或多个现有 businessEntity 或 tModel, E1…En, 的保管权, 从 N1 转移到 N2, 同时也会将这些实体的所有权从 P1 转移给 P2. 相关的 businessService, bindingTemplate, and publisherAssertion 也将随它们的 businessEntities 而被转移. 从 Registry 角度来看, 这些发布者总是不同的, 尽管可能有这种情况: P1 和 P2 是同一个组织. 这两个节点可能是同一节点或者也可能不是; 在节点内从 P1 向 P2 转移所有权是一种退化情况, 节点保管关系没有改变.
Custody and Ownership Transfer API 分为两部分, 2个 client APIs 和 1 个节点间 API. client APIs 包括 get_transferToken 和 transfer_entities; 简而言之, 这构成了这个 API 集的 Ownership Transfer API 部分. 节点间 API 包括 transfer_ custody, 与 replication 联合使用, 组成了这个 API 集的 Custody Transfer API 部分.
保管权和所有权转移的总体流程如下:
Publisher P1 调用 N1 的 get_transferToken, 指定要转移的实体 E1…En 的 keys K1…Kn. 如果 P1 获得许可 (即, 如果 P1 具有 E1…En 所有权), N1 返回一个结构 T, 称作转移令牌, 代表了可以转移实体的授权, 包括所有与要转移的 businessEntity(owned by P1) 有关的天生所包含的那些孩子和 publisherAssertion. 转移令牌(transferToken) 结构包含一个不易阅读的只有产生它的节点才能理解的字符串, 一个过期时间, 和一个节点标识符.
P1 然后将 T 交给 P2 (通常是通过安全方式, 因为 T 是很重要的). 欲获得保管信息的发布者在他/她能够完成保管权的转移之前, 需要先获取接收该实体保管权的节点上的一个发布者帐号. P2 接着调用 N2 的 transfer_entities, 传递 K1…Kn 和 T. 如果 transfer_entities 调用成功, 实体 E1…En 和它们相关的数据结构 (businessService, bindingTemplate, and publisherAssertion) 将位于 N2 保管之下, 由 P2 持有(own). 如果操作失败, 不会对这些实体产生影响. transfer_entities 的实际转移处理步骤如下.
如果 N1 and N2 并非是不同节点(即同一节点), 从 P1 向 P2 转移所有权完全就是节点内部操作 – 操作是如何发生的取决于实现. 如果 N1 and N2 是不同的, 当在 N2 上处理 transfer_entities 请求时, 将遵循下面的协议.
Upon receipt of a transfer_entities request, N2 checks that K1…Kn are valid keys. There is the possibility that P1 might transfer more data than P2 can accept due to policy-based restrictions on the limit of entities allowed to be owned by P2 at N2. As is described below, replication is used to complete the custody transfer process. A question that arises is at the time of accepting the datum related to the transfer, could N2 throw a replication error because the data being transferred exceeds the limits of user P2? Such limits can not be enforced during replication because they are node-local policy decisions from the perspective of enforcement. Thus, it is therefore possible that as a result of a custody transfer a publisher may be caused to hold more data that he/she would have been able to publish. Should this situation occur, P2 MUST not be allowed to publish any additional data unless P2 first reduces the number of entries it owns to an allowable limit.
If all is well, N2 invokes the inter-node API transfer_custody on N1, presenting the keys of top-level entities to be transferred, K1…Kn, P2’s identity (using the publisher’s authorizedName), N2’s node identifier (as known in the Replication Configuration structure, see Section 7.5.2 Configuration of a UDDI Node – operator element), and T. The transferToken, T, implies permission to transfer the entire content of the entities it identifies, including all of the contained entities and related publisherAssertions, if any. N1 checks to see whether T is a valid transferToken that it issued and that T represents the authority to transfer E1…En. If the validation is successful, N1 prevents further changes to entities E1… En. N1 then updates the authorizedName and nodeID of the operationalInfo of E1…En and related entities so that they are shown to be in the custody of N2 and owned by P2. Finally, N1 responds to N2 which triggers N2 to respond to the transfer_entities caller. This completes the processing for the transfer_entities request.
In the case that the datum being transferred is a key generator tModel, N1 will disallow further generation of keys associated with this key partition at its node.
Following the issue of the empty message by N1 to the transfer_custody call, N1 will submit into the replication stream a changeRecordNewData providing in the operationalInfo, N2’s nodeID identifying it as the node where the datum is being transferred to, and the authorizedName of P2. The acknowledgmentRequested attribute of this change record MUST be set to “true”.
The last modified date timestamp in the operationalInfo must change to reflect the custody transfer.
Figure 2 depicts the flow of a custody transfer between P1 and P2.
Figure 2 – Custody Transfer
Once N2 receives the changes via the replication stream it assumes custody of E1…En and assigns ownership of the entities and related entities owned by P1 to P2.
Categorized in: SOA · Tagged with: SOAP, UDDI, Webservice, WSDL
(No Ratings Yet)
Loading ...
(
