UDDI(四)

日期： 2007-12-17 来源：TechTarget中国

　　支持建模

　　有关支持建模的更新主要目的在于帮助大的机构更高效的建立其企业和服务的模型。从牵涉到不同种类的风险的大型集团企业到集中精力经营一种业务而且希望按它们服务的地理区域来划分其 Web 产品的公司，许多都希望它们在 Web 上表现为独立却相互关联的企业。在 UDDI 版本 1 中，对于这些情况，唯一的选择就是保持企业独立但却毫无关系。版本 2 允许您定义企业之间的关系，例如 父－子关系、 伙伴－伙伴关系和 等同关系。这样，您就能根据具体情况为有下属子公司、外部业务伙伴或者内部的各种部门的公司建立模型。任意两个企业（据其独一无二的企业键的定义）之间都可能会形成关系。新建的 Business Relationship 类型的规范的 tModel 支持这一能力，而且还有一些新的发布 API，允许您定义、删除和请求关系的状态，如 清单 2 中所示。

　　名叫 find_relatedBusinesses 的新查询 API 使您能就给定的公司匿名搜索涉及到它的关系。 清单 2 中的其它新的发布 API 都与特定的发布者创建并拥有的关系有关，并且这些关系都不能通过匿名查询来访问。一个企业关系由一对相同的关系断言组成，每个关系断言都会将这两家企业连在一起，并标志所建立的特定关系。为了形成外部可见的企业关系，所涉及的两家企业每家必须声明相同的关系断言。只有那些匹配的关系断言才会作为 find_relatedBusinesses() 查询结果返回。

　　下面的示例展示了关系怎样形成，日后怎样发现关系。首先，您会得到一个发布授权令牌：

　　清单 2. 得到一个 authToken
<Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/">
   <Body>
<get_authToken generic="2.0"
   xmlns="urn:uddi-org:api_v2"
   userID="businessA_UserId"
   cred="businessA_Password" />
   </Body>
</Envelope>
 
　　其返回内容如下：

　　清单 3. 得到 authToken 的响应
<Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/">
   <Body>
<authToken generic="2.0"
   operator="www.ibm.com/services/uddi"
   xmlns="urn:uddi-org:api_v2" >
     <authInfo>businessA_AuthToken</authInfo>
</authToken>
   </Body>
</Envelope>
 
　　接着，您建立一个企业断言将企业 A 和企业 B 联系起来，在此我们不使用典型的 UUID 格式，而是把它们的 businessKeys 分别简写为 businessKeyA和 businessKeyB 。为了简洁起见，我们不再展示 SOAP 信封。

<add_publisherAssertions generic="2.0"
   xmlns="urn:uddi-org:api_v2">
   <authInfo>businessA_AuthToken</authInfo>
     <publisherAssertion>
     <fromKey>"businessKeyA"</fromKey>
<toKey>"businessKeyB"</toKey>
   <keyedReference keyValue="parent-child"
   keyName="Subsidiary"
   tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4"/>
   </publisherAssertion>
</add_publisherAssertions>
 
　　一旦企业 B 的主人也建立了一个相同的断言，就能在注册中心中看到一个对大众公开可见的企业关系。然后，您可以利用 find_relatedBusinesses() API 执行一个简单的查询：

<find_relatedBusinesses generic="2.0"
xmlns="urn:uddi-org:api_v2">
   <businessKey>"businessKeyA"</businessKey>
</find_relatedBusinesses>
 
　　清单 3 展示了返回的 XML。更加细粒度的查询可能会包括一个标识正在查找的特定关系的 keyedReference 。

　　版本 2 中为支持大企业的建模需求而新增的另一项重要功能叫做服务投影（Service Projection），它允许一家企业创建对另一家企业拥有的服务的引用。这在有些情况下是很有用的，例如，对于在两个或以上的行业内提供相同的服务的公司和通用服务（例如过夜运输）都很有用，有许多企业都想要把某个通用服务链接到它们自己提供的服务上来鼓励使用这种服务。

　　投影的服务引用的功能不过如此。服务投影的创建者不能改变所引用的真正服务，但在其它所有方面，这个服务都好象真的是创建投影的企业所拥有一样。服务是 get_businessDetail() 或 get_serviceDetail() API 调用返回的一部分。通过与服务相关联的具有所有权的企业键，您可以把投影服务与真正的服务区分开来。这个键始终与拥有服务的真正企业相匹配，而不是与创建服务投影的企业相配。

　　强大的分类功能

　　在版本 1 中提供了三种内置的分类法供为企业和服务分类使用。它们是 NAICS 行业分类法、UNSPC 项目和服务分类法和 ISO-3166-2 地理分类法。UDDI 注册中心会在内部检查这些分类法的使用情况；试图保存无效的代码会遭到拒绝。在 UDDI 中有针对性的分类法的重要性再怎么强调也不会过分。既然查找感兴趣的有用信息功能最为强大的方法只有这一种，那么提高业界创建和控制新的分类法的能力将继续占有较高的优先级。

　　版本 2 新增的能力使机构能定义新的外部检查的分类法，可以在 UDDI 中提供这些分类法供大众使用。这些外部分类法提供者必须支持 validate_values Web 服务，并使 UDDI 业务注册中心能够访问该服务，以支持对客户机想要与它们在注册中心中的条目相关联的分类法值进行外部检查和验证。这是一个受控的过程。只有得到 UDDI 业务注册中心运营商的批准，外部验证的分类法才能完成注册。

　　这个验证新功能允许分类法提供者以灵活的方式来保证使用它们的分类法客户机只能保存那些有效的分类法值。当客户机请求使用提供者的分类法的时候，提供者在验证请求者是否是合法使用分类法之外，还可以选择进行有上下文的验证。更为常见的无上下文方案也支持将分类法数据缓存在 UDDI 业务注册中心以减少对提供者的外部分类法服务的依赖。

　　增强的查询

　　版本 2 在以前提供的查询能力的基础上添加了一些强大的功能来按更复杂的要求进行查询。为了增强现有的 find_xxx 查询 API 添加了几种新的过滤条件（查找限定符），包括 orLikeKeys 、 orAllKeys 、 combineCategoryBags 、 serviceSubset 和 andAllKeys 。其中，我们特别感兴趣的有 combineCategoryBags 、 serviceSubset 和 orLikeKeys 。

　　combineCategoryBags 限定符允许您将与一个企业相关联的所有分类法数据以及该企业所包含的所有服务（包括任何服务投影）分在一个集合内，然后就对这个集合执行搜索。这个限定符有用的原因在于，通过同时查看企业和它所包括的服务减少了查找感兴趣的企业的步骤。

　　同样， serviceSubset 过滤器允许您使用分类法标准来搜索企业，只对与构成企业的服务相关联的分类进行这样的测试。在这种搜索方法中不包括与企业本身相关联的分类。

　　最后， orLikeKeys 限定符特别有用，因为它支持复杂的伪码查询。例如，您可以查找位于美国、墨西哥或者加拿大同时提供冷藏服务或一般的运输服务的企业。这使您可以搜索分在不同特征级别的类别中的企业，同时允许一个查询条件引用多种不同分类法。

　　国际化

　　一直以来都在努力改进 UDDI 的国际化程度，现在已经添加了一些新功能。已经给 businessEntity 和 businessService 增加了对多个名字和 xml:lang 代码的支持。虽然您必须提供至少一个名字，但是也可以提供多个名字（每个名字使用一种不同的语言代码）。

　　版本 2 中的另一个国际化功能是新增了一类分类法，叫做 postalAddress ，它能让您创建描述本地化邮政地址的 tModel，然后把它们与在业务实体中找到的地址相关联。

　　复制

　　虽然 UDDI 客户机不能直接看到，但版本 2 已经对注册中心运营商之间的复制操作做了重大改进。UDDI 版本 1 仅支持基于文件的复制模式，随参与到 UDDI 注册中心中的注册中心节点实现数目的增长，其复杂程度以 n 的平方增长。版本 2 能满足数目更多的参与节点，它们相互复制。复制可以以一种基于对等的方式进行，在任何一个节点上都可以获得在其它所有节点上发生的注册中心更新。现在由于定义了一组允许处理更改和过程管理的 API，复制得到了更进一步的支持。

　　下一步

　　UDDI 规范的下一版本计划在 2002 年年中推出，重点在安全性、高级数据管理以及进一步的国际化上。通过增强访问控制、身份标识和认证提高 UDDI 数据完整性从而使安全性问题得以解决。这要包括支持如 W3C 和 OASIS 这样的机构提供的现有的和新兴的安全性技术。高级数据管理功能将继续增强搜索能力以提供更为精确和命中率更高的查询、更好的解释查询结果、对企业和服务更为丰富且更有意义的描述的捕捉能力以及更好管理现有数据。对国际化的改进将包括支持跨国公司描述其在国际业务分支所进行全球操作，还将解决 UDDI 数据和服务的本地化问题。

　　结束语

　　UDDI 继续快速发展。由多家 UDDI 业务注册中心运营商于 2001 年提供 UDDI 版本 2 对公众开放测试版实现。随着这个规范的版本 3 将于 2002 年年中出现，注册中心会继续添加通过 Web 做生意、解决安全性和逐步提高的国际化等领域的问题所需要的功能，及一些附加功能以支持使用注册中心和互操作性。

我们一直都在努力坚持原创.......请不要一声不吭，就悄悄拿走。

我原创，你原创，我们的内容世界才会更加精彩！

【所有原创内容版权均属TechTarget，欢迎大家转发分享。但未经授权，严禁任何媒体（平面媒体、网络媒体、自媒体等）以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

相关推荐

  • 基于SOA的企业应用系统集成研究

    随着企业信息化建设的不断加强和计算机技术的快速发展，以及互联网的应用，加强了企业内部和企业之间的信息交流，由于目前我国很多大中型企业部署……

  • 如何评估企业是否适合开发复合业务服务？

    多数组织已经逐渐自动化了它们的业务流程要求，它们的方法是：将业务流程要求分割为应用用例，然后在预算之内基于需求将业务功能实现为IT应用程序。

  • SOA的五种资产重用最佳实践

    重用是面向服务架构之所以成功的最关键因素之一。下面列出您可以使用的五种最佳实践。 结合“自顶向下”和“由下而上”技术，实用地定义服务接口……

  • 如何使用WSRR作为Web服务唯一数据源

    面向服务的架构以其服务复用、松耦合、灵活、高互操作性以及在集成和监管方面的特点促进了商业的敏捷性，及时响应以及可靠性。