UDDI 规范 v3.0.2 – UDDI Programmers APIs 之 Publication API Set(3)
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.
返回值：
本 API 返回一个 bindingDetail 结构包含刚刚注册的已生效的 bindingTemplate elements 信息. 如果在一次调用中不止一个 bindingTemplate 被保存, 作为结果返回的 bindingDetail 必须(MUST)按照 save_binding 调用时相同的参数顺序返回结果信息. 如果同一 bindingTemplate (根据 bindingKey 确定是否相同) 在 save_binding 中出现多次, 它可能(MAY)要为 save_binding 中每次出现的该 bindingTemplate 只返回一个对应结果. 如果同一 bindingTemplate 在响应中出现不止一次, 最后一个出现的该 bindingTemplate 表示最终保存于注册中心的状态. save_binding 调用所返回结果中的 bindingTemplate 都会有 bindingKey.
bindingDetail 可以有 0 个或多个 bindingTemplate.
错误警告：发生错误时, 必须返回一个 dispositionReport element.
· E_accountLimitExceeded: 超出用户的帐户限制.
· E_invalidKeyPassed: 所指定一个或多个 uddiKey 值对要发布的实体来说是无效的 key. tModelKey, serviceKey, or bindingKey 值或者不存在, 或者存在但类型不对, 或者没有经过发布者授权使用. 导致这个错误的 key 应该(SHOULD)清楚地在错误文本中指明. 这个错误代码最终也会被返回, 表示没有提供 serviceKey, bindingKey 或者缺失或者所使用的值并没有在注册中心注册过. 在这种情况下, 错误文本应该(SHOULD)清楚地指明当前使用了一个不完整的 bindingTemplate.
· E_invalidValue: keyValue 属性所使用的这个值没有通过验证. 应用于 checked value sets(使用keyedReferences进行引用). 错误文本应该(SHOULD)清楚地指出验证失败的 key 和 value 值对.
· E_keyUnavailable: 所提供的 key 已被指派给其他发布者使用或者没有在该发布者所拥有的 key generator tModel 定义的键分区中.
· E_requestTimeout: 该请求没有被执行, 因为必须调用的 validate_values 服务并没有在合理时间范围内返回响应. 这个发生失败的 Web service 的详细信息应该(SHOULD)包含在 dispositionReport element.
· E_userMismatch: 略.
· E_valueNotAllowed: 所引用的 value set 中的某个值是不被允许的.
save_business：
save_business API 用于保存或更新一个完整 businessEntity 结构信息. 本 API 在所有 save_xx APIs 中具有最大的作用范围, 能够用于对某个发布者所控制的一个或多个 businessEntity elements 信息做彻底更改.
这个 API 可以用于与其它 businessEntity 所管理的 businessService 结构建立引用关系. 使用这种方式, 原本是一个 businessEntity 一部分的 businessService 能够作为另一个 businessEntity 的一个服务投影. 使用这种方式的投影服务的内容不作为引用它的实体的一部分而进行管理.
businessEntity 结构可能(MAY)会被签名, 可能(MAY)会使用 publisher-assigned keys.
参数：
· authInfo: 略.
· businessEntity: 必需的, 0..∞. 可以通过 get_businessDetail API 或其它方式得到这些 businessEntity.
如果一个 businessEntity element 中的 uddiKey 值(例如这个 businessEntity 中的 businessKey, serviceKey 或 bindingKey)缺失或者只设置了一个空值, 这就表明这个数据是首次插入. 当出现这种情形时, node 必须(MUST)自动为该缺少 key 的数据生成一个新 key. 新实体也可以使用 publisher-assigned keys.
要想用这个 API 对一个已存在的数据执行更新操作, 那么该实体(businessEntity, 以及内含的 businessService or bindingTemplate)必须(MUST)要带有 uddiKey 值.
使用这个 API 可以删除数据. 比如某个 businessEntity 原本有某个 businessService 和 bindingTemplate, 后来在更新这个 businessEntity 时该 businessEntity 并不含这些数据, 结果, 这些数据就从 registry 中删除掉了.
包含在 businessEntity 结构里的数据可以使用这个 API 进行重新整理. 比如重新定义包含关系. 例如, 如果要保存的 businessEntity 带有一个 businessService 信息, 而这个 businessService 已经作为另一个不同的 businessEntity 一部分而注册, 这将使得这个 businessService 被从它当前所在的 businessEntity 移动到这个新 businessEntity. 在上述情形下, 要保存的这个 businessService 的 businessKey 匹配要保存的那个 businessEntity 的 businessKey. 如果某人并非某个 businessService 的发布者, 却想使用这种方式删除或移动这个 businessService, node 必须(MUST)拒绝这种请求, 返回一个 E_userMismatch 错误.
如果要保存的 businessEntity 包含一个 businessService, 该 businessService 的 businessKey 引用了其它 businessEntity 而不是这个要保存的 businessEntity, UDDI registry 注意到note 这个引用, 称之为对其它已存在的 businessService 的 “服务投影(service projection)”. 随后调用 get_businessDetail API, 传递原本这个 businessService 所在的 businessEntity 的 businessKey 或者包含了对这个 businessService 服务投影的 businessEntity 的 businessKey, 都将在结果集中返回一个完全相同的 businessService element.
businessEntity 务必不可同时包含一个 businessService 和对这个 businessService 的服务投影. 因此, 不能将一个 businessService 移动到一个已经包含了该 businessService 服务投影的 businessEntity 中. 不管操作顺序如何, 一个 businessService 和该 businessService 的服务投影永远不能在同一个 businessEntity 中. 在发生这种情况的 save_business 操作时, UDDI 实现要拒绝并返回一个 E_fatalError.
建立一个 businessService 的服务投影不会影响到该 businessService. 一个原本已存在于 businssEntity 中的服务投影, 在更新这个 businessEntity 时不再包含其中, 则该服务投影被自动删除. 这种引用删除不会改变被引用的 businessService. 如果被引用的 businessService 被删除了, 所有的在其它 businessEntity 中对它的引用将保留不动. 像这样”损毁的(broken)”服务投影作为 businessService elements 出现在它们的 businessEntity 中, 所包含的 businessKey 和 serviceKey 属性只是作为内容存在而已. 如果 businessService 移动到其它 business, 所有服务投影都将被更新, 以实时反映这个新的 businessKey. 因此, 最好重新整理一下对发布于其它 businessEntity 下的 businessService 的引用.
当保存一个 businessEntity 含有服务投影的时候, 在 save_business 操作中提供的该 businessService 的内容, 除了 serviceKey 和 businessKey, 其余都将被忽略. 被引用的 businessService 的 businessKey 和 serviceKey 用于决定该 businessService 是否用于服务投影. 如果由 serviceKey 所标识的 businessService 并非由 businessKey 所标识的 businessEntity 的一部分, 将返回错误 E_invalidProjection.
当一个要保存的 businessEntity 带有 identifierBag 或 categoryBag 内容, 且该内容涉及到 checked value set 或者 category group system tModel, 则这些内容中的引用必须(MUST)先于保存操作完成之前接受有效性检查, 或者, node 必须返回 E_unsupported, 指出自己不支持该被引用的 checked value set or category group system.
返回值：
本 API 返回一个 businessDetail 结构, 包含调用的最终结果, 该结果反映了新注册的 businessEntity 信息. 任何被指定 businessKey, serviceKey, 或 bindingKey 属性都将作为 save_business 处理结果而包含于返回的数据中. 对于服务投影的 businessService elements, 响应或者包含发布者所提供的 businessService elements 或者包含真实 businessService elements 的完整内容. 结果包含任何使用引用而包含进来的 businessService elements. 如果同一实体(businessEntity, businessService, or bindingTemplate), -根据key的匹配情况确定是否是同一实体, 在 save_business 调用时列了不止一次, 可能(MAY)会在结果中只列一次. 如果同一实体在响应中出现不止一次, 最后一次出现的实体或者反映了最终保存的状态或者在请求中该发布者所提供的最后一次出现的实体.
businessDetail 具有 0 个或多个 businessEntity.
错误警告：发生错误时, 必须返回一个 dispositionReport element.
· E_accountLimitExceeded: 超出用户的帐户限制.
· E_invalidKeyPassed: 所指定一个或多个 uddiKey 值对要发布的实体来说是无效的 key. tModelKey, serviceKey, or bindingKey 值或者不存在, 或者存在但类型不对, 或者没有经过发布者授权使用. 导致这个错误的 key 应该(SHOULD)清楚地在错误文本中指明. 这个错误代码最终也会被返回, 表示没有提供 serviceKey, bindingKey 或者缺失或者所使用的值并没有在注册中心注册过. 在这种情况下, 错误文本应该(SHOULD)清楚地指明当前使用了一个不完整的 bindingTemplate.
· E_invalidProjection: 要保存的 businessEntity 所含的某个服务投影, 其要投影的服务(businessService being projected)并非是该被投影 businessService 的 businessKey 标识的 businessEntity 的一部分(其实被投影的服务自己也是一个服务投影). 至少一个这样的 businessService 的 serviceKey 应该(SHOULD)包含在 dispositionReport 中.
· E_userMismatch: 略.
· E_invalidValue: keyValue 属性所使用的这个值没有通过验证. 应用于 checked value sets(使用keyedReferences进行引用). 错误文本应该(SHOULD)清楚地指出验证失败的 key 和 value 值对.
· E_keyUnavailable: 所提供的 key 已被指派给其他发布者使用或者没有在该发布者所拥有的 key generator tModel 定义的键分区中.
· E_requestTimeout: 该请求没有被执行, 因为必须调用的 validate_values 服务并没有在合理时间范围内返回响应. 这个发生失败的 Web service 的详细信息应该(SHOULD)包含在 dispositionReport element.
· E_unsupported: 引用了 checked value set 的某个 categoryBag 或 identifierBag 中的某个 keyedReference 不能通过 UDDI node 校验, 因为 node 不支持该被引用的 checked value set. 错误文本应该清楚地指明是哪个 keyedReference 没能通过校验.
· E_unvalidatable: 引用了 checked value set 的某个 categoryBag 或 identifierBag 中的某个 keyedReference 不能通过 UDDI node 校验, 因为被引用的 tModel 已经标记为无效. 错误文本应该清楚地指出哪个 keyedReference 没能通过校验.
· E_valueNotAllowed: 所引用的 value set 中的某个值是不被允许的.
save_service：
save_service API 用于新增或更新一个或多个 businessService elements. 每个 businessService 可能(MAY)被签名, 可能使用 publisher-assigned keys.
参数：
· authInfo: 略.
· businessService: 必需的, 0..∞. 可以通过 get_serviceDetail API 或其它方式得到这些 businessService.
在传递的 businessService 中, 每个新 businessService 必须包含一个 businessKey 值, 对应于该发布者所管理的某个 businessEntity; 一个已存在的 business service 可能包含一个 businessKey 值, 这个值对应于该发布者所管理的某个 businessEntity.
如果一个 businessService element 中的任意某个 uddiKey (即, 该businessService的serviceKey或所包含的bindingTemplate的bindingKey)是一个空值, 这表示是首次插入. 在这种情形下, 必须为这种不带 key 值的数据自动生成一个新 key 值. 新实体也可以使用 publisher-assigned keys.
如果在一次调用中传递了多个同一 businessService 作为参数, 最终这个 businessService 的上级 businessEntity 是哪个将由处理顺序决定 – 请求中这些相同 businessService 的传递顺序. 类似地, 如果同一 bindingTemplate 在调用中包含在多个 businessService 中, 最终结果将是最后一个 businessService 参数才是这个 bindingTemplate 的双亲.
使用这个 API, 可以将一个已存在的 bindingTemplate element 从一个 businessService element 移动到另外一个, 或者将一个已存在的 businessService element 从一个 businessEntity 移动到另外一个, 只需简单地为它指定与原来不同的双亲 businessEntity. 通过这种方式改变双亲关系将使得这两个 businessEntity 或者两个 businessService 结构发生改变. An attempt to move a bindingTemplate or a businessService in this manner by a party who is not the publisher of the businessService that is specified by the serviceKey or the businessEntity that is specified by the businessKey MUST be rejected with an error E_userMismatch.
当一个要保存的 businessService 带有 categoryBag , 且该 categoryBag 引用到一个 checked value set or category group system tModel, 其中的引用必须接受有效性检查, 而且检查要先于保存操作完成之前, 或者 node 必须返回一个 E_unsupported, 指出自己不支持该被引用的 checked value set or category group system.
返回值：
这个 API 返回一个 serviceDetail 包含该次调用的最终结果, 该结果直接反映出已生效(新增或更新成功)的 businessService elements. 当在某次请求中传递了多个 businessService elements, 结果包含所传递的每个 businessService 相对应的最终结果, 它们按照与请求中相同的顺序出现于结果集中. save_service API 结果集中的 businessService 都带有 serviceKey 或 bindingKey 值.
如果同一实体(businessService, or bindingTemplate), 由 key 确定是否相同, 在 save_service API 中出现多次, 那么在结果集中可能为请求中该实体的每个 elementit 只列出一个 element. 如果同一实体不止一次出现于响应中, 最后一次出现的实体反映了其在 registry 中的存储状态.
serviceDetail 包含 0 个或多个 businessService element.
错误警告：发生错误时, 必须返回一个 dispositionReport element.
· E_accountLimitExceeded: 超出用户的帐户限制.
· E_invalidKeyPassed: 所指定一个或多个 uddiKey 值对要发布的实体来说是无效的 key. tModelKey, serviceKey, or bindingKey 值或者不存在, 或者存在但类型不对, 或者没有经过发布者授权使用. 导致这个错误的 key 应该(SHOULD)清楚地在错误文本中指明. 这个错误代码最终也会被返回, 表示没有提供 businessKey, serviceKey或者缺失或者所使用的值并没有在注册中心注册过. 在这种情况下, 错误文本应该(SHOULD)清楚地指明当前使用了一个不完整的 businessService.
· E_userMismatch: 略.
· E_invalidValue: keyValue 属性所使用的这个值没有通过验证. 应用于 checked value sets(使用keyedReferences进行引用). 错误文本应该(SHOULD)清楚地指出验证失败的 key 和 value 值对.
· E_keyUnavailable: 所提供的 key 已被指派给其他发布者使用或者没有在该发布者所拥有的 key generator tModel 定义的键分区中.
· E_requestTimeout: 该请求没有被执行, 因为必须调用的 validate_values 服务并没有在合理时间范围内返回响应. 这个发生失败的 Web service 的详细信息应该(SHOULD)包含在 dispositionReport element.
· E_unsupported: 引用了 checked value set 的某个 categoryBag 或 identifierBag 中的某个 keyedReference 不能通过 UDDI node 校验, 因为 node 不支持该被引用的 checked value set. 错误文本应该清楚地指明是哪个 keyedReference 没能通过校验.
· E_unvalidatable: 引用了 checked value set 的某个 categoryBag 或 identifierBag 中的某个 keyedReference 不能通过 UDDI node 校验, 因为被引用的 tModel 已经标记为无效. 错误文本应该清楚地指出哪个 keyedReference 没能通过校验.
· E_valueNotAllowed: 所引用的 value set 中的某个值是不被允许的.
save_tModel：
save_tModel API 用于添加或者更新一个或多个 tModel elements. tModels 可能被签名, tModels 可能使用 publisher-assigned keys, 包括那些使用 publisher-assigned keys 建立 domain partition 的 tModels, 即常说的 domain key generator tModels.
参数：
· authInfo: 略.
· tModel: 必须的, 1..∞ . 可以使用 get_tModel API 或其它方式得到这些数据.
行为：
如果一个 tModel 的 uddiKey 值(即, tModelKey) 缺失或者是一个空值, 这表示要插入的是一个新的 tModel, UDDI registry 必须为这个 tModel 指派一个新的 tModelKey 标识符. 如果这个新 tModel 使用 uddi:uddi.org:categorization:types category system 中的 keyGenerator 值进行归类, 任何 publisher-assigned key 都必须以字符串 “:keygenerator” 结尾, 使这个 tModel 成为一个 key generator tModel. 如果这个新 tModel 使用 uddi:uddi.org:categorization:types category system 中的 keyGenerator 值进行归类, 但其 tModelKey 是一个空值, 这表示由 node 生成的这个 tModelKey 将以字符串 “:keygenerator” 结尾, 使得这个 tModel 成为一个 key generator tModel.
当 tModel 的 tModelKey 对应于某个已注册了的 tModel 时, 这个 API 能够对该 tModel 进行更新.
如果所传递的 tModelKey 值对应于一个已被 delete_tModel API 隐藏掉的 tModel, save_tModel 可以恢复这个 tModel 使之完全可见, 重新出现于 find_tModel 的返回结果中.
在保存操作中, tModel 中的 deleted 属性值都设置为 false.
可以为 tModel 提供多个 overview document, 例如, 技术的和易于阅读的 overview 文档都可以.
当一个要保存的 tModel 带有 keyedReferences, 在 keyedReferences 中用到的所有 tModelKeys 必须已引用已经存在的 tModels, 这一步先于对包含这些引用的 tModel 的处理. save_tModel API 能够包含一系列 tModels, 在这种情况下, 一个 tModel 中的某个 keyedReference 可能引用了这一系列中先创建的 tModelKeys (A save_tModel API call may contain a sequence of tModels, in which case a keyedReference in a tModel may refer to tModelKeys created earlier but not later in the sequence). 一个要新建的 tModel 务必不能引用它自己. 自引用的(Self-referencing) tModels 可以通过两步 save_tModel API 调用来创建, 第一步不带引用, 然后第二部带引用(引用已经被保存了的tModel,即第一步保存的tModel). 如果这些条件不能满足, node 必须返回 E_invalidKeyPassed.
当一个要保存的 tModel 带有 identifierBag or categoryBag 内容, 而这些内容关联到一个 checked value set or category group system tModel, 这些引用必须接受有效性检查, 这一步先于保存操作, 或者 node 必须返回 E_unsupported, 表示自己不支持该被引用的 checked value set or category group system.
Domain key generator tModels：
对于那些使用推荐的 key 语法的 registries 来说, 一个 domain key generator tModel 就建立了一个 key partition, 从这个键分区可以派生出 uddiKeys 并可用在该发布者所控制的其它实体中. 当首次发布一个 domain key generator tModel 时需要做些额外考虑.
1. tModelKey 必须遵从 domain_key 形式, 并且必须以术语: keyGenerator 结尾.
2. tModelKey 必须在 uddi:uddi.org:categorization:types category system 中使用 keyGenerator 值进行归类.
3. 对于建立 key domains, Registry policy 可能要求 tModel 使用签名.
同样, key generator tModels 的发布者可能使用 overviewDoc 去描述键空间是如何定义的.
save_tModel API 首先检查 tModel 是否合适, 如果根据注册中心策略它是可以保存一个 domain key generator tModels, 那么返回 tModelDetail. 如果不能接受这个 tModel, 会在返回的 dispositionReport 中清楚地指明原因, 不再继续处理下去.
如果注册中心有多个 nodes, 返回 tModelDetail 并不意味着该 domain key generator tModel 已经发布成功. 一个允许 publisher-assigned keys 的 registry 必须具有策略确保不会发生 domainKey 冲突. The custodial node MUST ensure that the domain key generator tModel is not in the process of being published simultaneously on some other node. 如果, 在完整复制周期结束后, 没有其它 UDDI node 已经指派或试图指派这个分区(例如, 没有从其它节点收到任何改变记录-change record), 保管节点就完成这个 domain key generator tModel 的发布操作, 然后指派它给它的发布者. 如果其它节点已经分派了该分区, 该 tModel 就不会被发布.
当发布一个 domain key generator tModel 完成后, 保管节点可能通知它的发布者说这个 tModel 已经准备好可以使用了. 一个 node 是否这样做以及通过何种方式这样做是由节点策略决定的. 一个典型的节点策略是通过 email 通知其发布者, 这个 e-mail 地址是在该发布者帐户创建时所提供的那个.
在发布操作完成之前, domain key generator tModel 将在 find_xx and get_xx API 调用结果中被忽略, 在继续调用 save_tModel 时, 将返回一个 E_keyUnavailable 错误.
如果复制周期完成后, 发布者怀疑发布结果, 可以使用 get_tModelDetail 并指定发布 domain key generator tModel 时所使用的 key 进行验证. 如果得到一个 tModel 且该发布者是这个 tModel 的所有者, 就表明操作已经成功. 如果得到一个 tModel 但其它发布者是这个 tModel 的所有者, 那么之前的 save_tModel 操作就是失败的, 因为其他发布者已经先选用这个 domain_key 发布了一个 domain key generator tModel. 如果没有得到 tModel, 那么就是或者 registry 遭遇到失败, 或者两个发布者”同时(simultaneously)”试图使用相同的 key 发布 tModels, 最终两人都不成功. 在上述情形下, save_tModel 操作可能会重试.
试图从一个已经成功发布的 key generator tModel 中移除下面所列的分类将失败, 错误是 E_fatalError, 因为它是一个非常特殊的分类用于将 key generator tModels 从其它 tModels 中区分开来:
<tModelKey=”uddi:uddi.org:categorization:types” keyValue=”keyGenerator” />
返回值：
大部分情况下这个 API 返回一个 tModelDetail 包含该次调用的最终结果, 该结构反映了受影响 tModel 的新注册信息或者等待处理的(pending)注册信息. 返回的 tModel 都带有 tModelKey 属性. 当首次保存一个 domain key generator, 返回的 tModelDetail 里的 tModel 呈现的是中间状态, 直到注册中心的所有节点都已经确定被请求的 key domain 确实是属于该发布者.
如果在 save_tModel 请求中传递多个 tModel elements, 响应的顺序必须完全匹配在保存操作请求中这些 elements 出现的顺序. 如果同一 tModel, 根据 key 判断是否是相同的 tModel, 在 save_tModel API 中出现多次, 在结果中可能为 save_tModel API 中出现的这些 tModel 只列出一次. 如果同一 tModel 在响应中出现多次, 最后一次出现的 tModel 反映了它在注册中心的存储状态.
tModelDetail 具有 0 个或多个 tModel elements
错误警告：发生错误时, 必须返回一个 dispositionReport element.
· E_accountLimitExceeded: 超出用户的帐户限制.
· E_invalidKeyPassed: 所指定一个或多个 uddiKey 值对要发布的实体来说是无效的 key. tModelKey 值或者不存在, 或者存在但类型不对, 或者没有经过发布者授权使用. 导致这个错误的 key 应该(SHOULD)清楚地在错误文本中指明.
· E_userMismatch: 略.
· E_invalidValue: keyValue 属性所使用的这个值没有通过验证. 应用于 checked value sets(使用keyedReferences进行引用). 错误文本应该(SHOULD)清楚地指出验证失败的 key 和 value 值对.
· E_keyUnavailable: 所提供的 key 已被指派给其他发布者使用, 或者没有在该发布者所拥有的 key generator tModel 定义的键分区中, 或者是该首次保存的这个 domain key generator tModel 已被分派给其他发布者或仍旧在等待处理(pending its first save).
· E_requestTimeout: 该请求没有被执行, 因为必须调用的 validate_values 服务并没有在合理时间范围内返回响应. 这个发生失败的 Web service 的详细信息应该(SHOULD)包含在 dispositionReport element.
· E_unacceptableSignature: tModel 缺少数字签名或者不满足注册中心的要求. errInfo element 提供更多详细信息.
· E_unsupported: 某个 categoryBag 或 identifierBag 中, 引用了 checked value set 的某个 keyedReference 不能通过 UDDI node 校验, 因为 node 不支持该被引用的 checked value set. 错误文本应该清楚地指明是哪个 keyedReference 没能通过校验.
· E_unvalidatable: 在某个 categoryBag 或 identifierBag 中, 引用了 checked value set 的某个 keyedReference 不能通过 UDDI node 校验, 因为被引用的 tModel 已经标记为无效. 错误文本应该清楚地指出哪个 keyedReference 没能通过校验.
· E_valueNotAllowed: 所引用的 value set 中的某个值是不被允许的.
set_publisherAssertions：
set_publisherAssertions API 用于管理某个发布者所有被记录的关系断言.
参数：
· authInfo: 略.
· publisherAssertion: 可选, 0..∞ . 关系断言构成了一个对两个 businessEntity key 值的引用, 这两个 businessKey 值由关系断言的 fromKey 和 toKey elements 指定, 同时在这个关系断言中的 keyedReference element 指定一个关系指向(父子, or peer 2 peer)表达式(该表达式是必需的). fromKey, toKey, 和 keyedReference 中所有的三部分– tModelKey, keyName, 和 keyValue – 必须指定. 如果在 publisherAssertion elements 中这些 elements 中任意一个缺失, 将返回 E_fatalError. 空的(零长度)keyNames 和 keyValues 是允许的.
行为：
当使用这个 API 后, 该发布者具有的完整断言集合将被立即替换掉. 当这个 API 的调用被处理后, 对于一个给定的发布者, 在本次调用之前存在的那些发布者断言将被 UDDI registry 检查. 任何在本次调用前不存在的新断言将被加入到该发布者所属的断言集合中. 任何已存在但没有出现在本次调用中的断言将被删除掉. 结果, 新关系可能建立完成(例如. 决定于是否具有完成状态), 已存在的关系可能被解散掉. 调用本 API 但不带有任何 publisherAssertion elements 将会删除掉该发布者的所有断言.
Any relationships attributed to assertions previously present but not present in the data provided in this call are deactivated and are no longer visible via the find_relatedBusinesses API. 为了在断言集合中确定唯一性, publisherAssertion element 中的 fromKey, toKey, 和整个 keyedReference 是很重要的. 在检测一个新断言时, publisherAssertion element 中任何内容如与所有已存在断言内容不同, 都将构成一个新的唯一的断言. 由 fromKey and toKey elements 中这两个 businessKey 值所指明的关系方向, 也会关系到确定断言唯一性.
发布者必须拥有fromKey, toKey, 或者这两者所引用的 businessEntity. 如果在断言中传递的这两个 businessKey 值都属于该发布者, 那么该断言将自动完成, 并且在断言中所描述的关系通过 find_relatedBusinesses API 也是可见的. 当发布者只拥有这两个 keys 中的某一个时, 要建立一个关系, 所传递给 API 的断言必须完全匹配由拥有另一个 key 引用的 businessEntity 发布者所建立的断言. 断言完全匹配, 当且只有当他们:
1. 它们的 fromKey 引用相同 businessEntity;
2. 它们的 toKey 引用相同的 businessEntity;
3. 它们的 tModelKey 引用相同的 tModel;
4. 具有完全相同的 keyNames; 并且
5. 具有完全相同的 keyValues.
当一个要保存的 publisherAssertion 在 keyedReference 中使用 tModelKey 引用了一个 checked relationship system, 该引用必须接受有效性检查, 检查要在保存操作完成之前, 或者 node 必须返回 E_unsupported, 指出自己不支持该被引用的 checked relationship system. 对一个关系系统引用的校验必须验证:根据为该关系系统所定义的由它的 tModel 所描述的校验算法, 引用是有效的. 对于可缓存的检查型关系系统, 校验算法验证 对于该关系系统这些 keyedReferences 是有效的.
对于任意节点都支持 subscription APIs 的注册中心来说, 有必要为 publisherAssertion elements 记录修改时间, 这样便于节点有足够的信息作为对订阅请求(包括find_relatedBusinesses和get_assertionStatusReport filters)的响应.
返回值：
成功完成后, 会返回一个 publisherAssertions 结构, 包含当前属于该发布者的所有的关系断言. 如果注册中心区分发布者, 这个结构包含与所传递的 authInfo 相关的断言数据.
这个 API 返回该发布者所创建的所有断言.
错误警告：
发生错误的时候, 必须在 SOAP Fault 中返回一个 dispositionReport element.
· E_invalidKeyPassed: 指出某个 uddiKey 值与任何已知的 businessKey or tModelKey 值都不匹配. 导致该问题的 assertion element 和 key 应该在错误文本中清楚的标明.
· E_userMismatch: 内嵌的 fromKey 和 toKey elements 所指定的 businessKey 值都不是由该发布者所掌握的. 错误文本应该明确地指出究竟是哪个断言导致这个错误.
Categorized in: SOA · Tagged with: SOAP, UDDI, Webservice, WSDL
(No Ratings Yet)
Loading ...
(
