UDDI 规范 v3.0.2 - UDDI Programmers APIs 之 Custody and Ownership Transfer API Set
2008年, 07月 19日, 星期六 | By javafuns
本系列目录 for 《UDDI 规范 v3.0.2 - APIs》
- UDDI 规范 v3.0.2 - 使用 UDDI APIs
- UDDI 规范 v3.0.2 - UDDI Programmers APIs 之 Inquiry API Set(1)
- UDDI 规范 v3.0.2 - UDDI Programmers APIs 之 Inquiry API Set(2)
- UDDI 规范 v3.0.2 - UDDI Programmers APIs 之 Publication API Set(1)
- UDDI 规范 v3.0.2 - UDDI Programmers APIs 之 Publication API Set(2)
- UDDI 规范 v3.0.2 - UDDI Programmers APIs 之 Publication API Set(3)
- UDDI 规范 v3.0.2 - UDDI Programmers APIs 之 Security Policy API Set
- UDDI 规范 v3.0.2 - UDDI Programmers APIs 之 Value Set API Set
- 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)” 错误 (因为根据策略, 这些节点共享相同的注册, 认证和授权).
Topics: WebService和SOA | Tags: SOAP, UDDI, Webservice, WSDL | 22次浏览 | No Comments »
UDDI 规范 v3.0.2 - UDDI Programmers APIs 之 Value Set API Set
2008年, 07月 15日, 星期二 | By javafuns
本系列目录 for 《UDDI 规范 v3.0.2 - APIs》
- UDDI 规范 v3.0.2 - 使用 UDDI APIs
- UDDI 规范 v3.0.2 - UDDI Programmers APIs 之 Inquiry API Set(1)
- UDDI 规范 v3.0.2 - UDDI Programmers APIs 之 Inquiry API Set(2)
- UDDI 规范 v3.0.2 - UDDI Programmers APIs 之 Publication API Set(1)
- UDDI 规范 v3.0.2 - UDDI Programmers APIs 之 Publication API Set(2)
- UDDI 规范 v3.0.2 - UDDI Programmers APIs 之 Publication API Set(3)
- UDDI 规范 v3.0.2 - UDDI Programmers APIs 之 Security Policy API Set
- UDDI 规范 v3.0.2 - UDDI Programmers APIs 之 Value Set API Set
- UDDI 规范 v3.0.2 - UDDI Programmers APIs 之 Custody and Ownership Transfer API Set
当在 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.
Topics: WebService和SOA | Tags: SOAP, UDDI, Webservice, WSDL | 31次浏览 | No Comments »
如何给Eclipse中的某个Jar添加源代码？
2008年, 07月 15日, 星期二 | By javafuns
右键选择那个Jar，然后选择“属性”菜单，在这里，你可以看到可以设置source和doc。
今儿还发现一个有趣的问题，大家都知道可以使用java -Dname=value 给程序传参数，然后可以在程序中使用System.getProperty(”name”)取得这个value。
不过，当你的 -Dname=value放在最后面的时候，这根本不起作用，只有紧跟着Java后面才有效。
Topics: Java | Tags: Java | 41次浏览 | No Comments »
UDDI 规范 v3.0.2 - UDDI Programmers APIs 之 Security Policy API Set
2008年, 07月 13日, 星期日 | By javafuns
本系列目录 for 《UDDI 规范 v3.0.2 - APIs》
- UDDI 规范 v3.0.2 - 使用 UDDI APIs
- UDDI 规范 v3.0.2 - UDDI Programmers APIs 之 Inquiry API Set(1)
- UDDI 规范 v3.0.2 - UDDI Programmers APIs 之 Inquiry API Set(2)
- UDDI 规范 v3.0.2 - UDDI Programmers APIs 之 Publication API Set(1)
- UDDI 规范 v3.0.2 - UDDI Programmers APIs 之 Publication API Set(2)
- UDDI 规范 v3.0.2 - UDDI Programmers APIs 之 Publication API Set(3)
- UDDI 规范 v3.0.2 - UDDI Programmers APIs 之 Security Policy API Set
- UDDI 规范 v3.0.2 - UDDI Programmers APIs 之 Value Set API Set
- UDDI 规范 v3.0.2 - UDDI Programmers APIs 之 Custody and Ownership Transfer API Set
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 参数值为有效认证信息.
Topics: WebService和SOA | Tags: SOAP, UDDI, Webservice, WSDL | 42次浏览 | No Comments »
UDDI 规范 v3.0.2 - UDDI Programmers APIs 之 Publication API Set(3)
2008年, 07月 7日, 星期一 | By javafuns
本系列目录 for 《UDDI 规范 v3.0.2 - APIs》
- UDDI 规范 v3.0.2 - 使用 UDDI APIs
- UDDI 规范 v3.0.2 - UDDI Programmers APIs 之 Inquiry API Set(1)
- UDDI 规范 v3.0.2 - UDDI Programmers APIs 之 Inquiry API Set(2)
- UDDI 规范 v3.0.2 - UDDI Programmers APIs 之 Publication API Set(1)
- UDDI 规范 v3.0.2 - UDDI Programmers APIs 之 Publication API Set(2)
- UDDI 规范 v3.0.2 - UDDI Programmers APIs 之 Publication API Set(3)
- UDDI 规范 v3.0.2 - UDDI Programmers APIs 之 Security Policy API Set
- UDDI 规范 v3.0.2 - UDDI Programmers APIs 之 Value Set API Set
- UDDI 规范 v3.0.2 - UDDI Programmers APIs 之 Custody and Ownership Transfer API Set
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.
Topics: WebService和SOA | Tags: SOAP, UDDI, Webservice, WSDL | 79次浏览 | No Comments »
开心一笑
2008年, 07月 5日, 星期六 | By javafuns
1、一饿狼觅食，听到有家人在训孩子：再哭就把你扔出去喂狼！
孩子哭一夜，狼在门外痴痴等至天亮，长叹一声：骗子，人都是骗子！
2. 一犯人被执行枪决,由于子弹是劣质的,第一枪没放出,接着又放了
第二枪…第三枪…这时犯人哭了:大哥你掐死我吧,太他妈吓人了!
3. 一老太太看完黑人百米赛后，抹着眼泪说：吓死人！几个挖煤的跪成一排被枪
毙，没瞄准就开了枪，娃儿们吓得那个跑呀，绳子都拦不住哇！
4、你因消化不良向医生抱怨：我近来很不正常，吃什么拉什么， 吃西瓜拉西瓜，吃黄瓜拉黄瓜，怎么才能恢复正常呢？
医生沉思片刻对你说：那你只能吃屎了！
5、昨晚我夜观星象发现你最近命犯孤星，唯一可解之法：
1）走到宿舍门口
2）手拿手帕
3）左手扶门框
4）右手甩手帕
咒语是：大爷上来玩啊！
6.你到云南西双版纳旅游，途中遇到一群野猪的围攻，
旅客均掏出食品、金钱，野猪不为所动，
你掏出仅有的身份证，群猪跪而痛哭道：老大，我们可找到你了！
7、黄先生的儿子叫‘黄军‘，
一天送儿子上课，见公交8路进站，
于是冲儿子大喊：黄军快跑，八路来了！~~~
8、食人族父子打猎，其子擒一瘦子，父曰：放，没肉！
子回，擒一胖子，父曰：放，太腻！
一会儿子擒一美女，父曰：带她回去，今晚把你妈吃了！
9、一只小熊去山里创业，农夫给了他一把镰刀，木匠给了他一把锤子，
小熊来到山里遇到老虎，吓得把镰刀、锤子举在头顶，
老虎说：没看出来，就你这熊样还是个党员来！
10、妻子问丈夫：你是喜欢我的温柔可爱呢？还是我的聪明美丽？
丈夫答：我就喜欢你这样的幽默感！
11、一群蚂蚁爬上了大象的背，但 被摇了下来，
只有一只蚂蚁死死的抱着大象的脖子不放。
下面的蚂蚁大叫：掐死他，掐死他，小样，还他妈反了!
Topics: 我的生活 | Tags: MyLife | 98次浏览 | No Comments »
用UML做好系统分析-(http://www.infoq.com/cn)
2008年, 07月 2日, 星期三 | By javafuns
用UML做好系统分析
作者 邱郁惠 发布于 2008年6月19日 下午11时42分
使用UML如何能让我们做好系统分析的工作呢？就让我们通过本章的基金模拟项目，先睹 为快，抢先体验一番。
CIM-1：定义业务流程
定义及分析业务流程（Business Process）是为了尽快理清系统范围，以便估算开发成本及时间，可不是为了要改造业务流程。系统分析员千万别误解了此步骤的目的。所以，系统分析员在定义及分析业务流程时，要记得挑选跟系统有关的业务流程。
CIM-1定义业务流程的生成，主要有如下的业务用例图和简述。请看图2-1的业务用例图，图中的每一个业务用例代表一条业务流程，业务执行者则代表位于企业外但会启动或参与业务流程的人。投资人到银行临柜申购基金，启动了银行内部的一段关于申购基金的业务流程。再者，投资人也可能临柜办理赎回基金，这又引发了另一条业务流程。
至于业务用例简述，简洁扼要即可，我们主要用它来记录和区分业务流程。
Topics: Java | Tags: UML | 119次浏览 | No Comments »
UDDI 规范 v3.0.2 - UDDI Programmers APIs 之 Publication API Set(2)
2008年, 07月 1日, 星期二 | By javafuns
本系列目录 for 《UDDI 规范 v3.0.2 - APIs》
- UDDI 规范 v3.0.2 - 使用 UDDI APIs
- UDDI 规范 v3.0.2 - UDDI Programmers APIs 之 Inquiry API Set(1)
- UDDI 规范 v3.0.2 - UDDI Programmers APIs 之 Inquiry API Set(2)
- UDDI 规范 v3.0.2 - UDDI Programmers APIs 之 Publication API Set(1)
- UDDI 规范 v3.0.2 - UDDI Programmers APIs 之 Publication API Set(2)
- UDDI 规范 v3.0.2 - UDDI Programmers APIs 之 Publication API Set(3)
- UDDI 规范 v3.0.2 - UDDI Programmers APIs 之 Security Policy API Set
- UDDI 规范 v3.0.2 - UDDI Programmers APIs 之 Value Set API Set
- UDDI 规范 v3.0.2 - UDDI Programmers APIs 之 Custody and Ownership Transfer API Set
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 的旧断言被删除掉.
Topics: WebService和SOA | Tags: SOAP, UDDI, Webservice, WSDL | 120次浏览 | No Comments »
UDDI 规范 v3.0.2 - UDDI Programmers APIs 之 Publication API Set(1)
2008年, 06月 29日, 星期日 | By javafuns
本系列目录 for 《UDDI 规范 v3.0.2 - APIs》
- UDDI 规范 v3.0.2 - 使用 UDDI APIs
- UDDI 规范 v3.0.2 - UDDI Programmers APIs 之 Inquiry API Set(1)
- UDDI 规范 v3.0.2 - UDDI Programmers APIs 之 Inquiry API Set(2)
- UDDI 规范 v3.0.2 - UDDI Programmers APIs 之 Publication API Set(1)
- UDDI 规范 v3.0.2 - UDDI Programmers APIs 之 Publication API Set(2)
- UDDI 规范 v3.0.2 - UDDI Programmers APIs 之 Publication API Set(3)
- UDDI 规范 v3.0.2 - UDDI Programmers APIs 之 Security Policy API Set
- UDDI 规范 v3.0.2 - UDDI Programmers APIs 之 Value Set API Set
- UDDI 规范 v3.0.2 - UDDI Programmers APIs 之 Custody and Ownership Transfer API Set
这个系列的 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> 找到.
Topics: WebService和SOA | Tags: SOAP, UDDI, Webservice, WSDL | 126次浏览 | No Comments »
UDDI 规范 v3.0.2 - UDDI Programmers APIs 之 Inquiry API Set(2)
2008年, 06月 29日, 星期日 | By javafuns
本系列目录 for 《UDDI 规范 v3.0.2 - APIs》
- UDDI 规范 v3.0.2 - 使用 UDDI APIs
- UDDI 规范 v3.0.2 - UDDI Programmers APIs 之 Inquiry API Set(1)
- UDDI 规范 v3.0.2 - UDDI Programmers APIs 之 Inquiry API Set(2)
- UDDI 规范 v3.0.2 - UDDI Programmers APIs 之 Publication API Set(1)
- UDDI 规范 v3.0.2 - UDDI Programmers APIs 之 Publication API Set(2)
- UDDI 规范 v3.0.2 - UDDI Programmers APIs 之 Publication API Set(3)
- UDDI 规范 v3.0.2 - UDDI Programmers APIs 之 Security Policy API Set
- UDDI 规范 v3.0.2 - UDDI Programmers APIs 之 Value Set API Set
- UDDI 规范 v3.0.2 - UDDI Programmers APIs 之 Custody and Ownership Transfer API Set
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)的一种替换用法.
Topics: WebService和SOA | Tags: SOAP, UDDI, Webservice, WSDL | 115次浏览 | No Comments »
| « 前一页 |
