理解 UDDI我见过最好的.docx
《理解 UDDI我见过最好的.docx》由会员分享，可在线阅读，更多相关《理解 UDDI我见过最好的.docx（16页珍藏版）》请在冰豆网上搜索。
理解UDDI我见过最好的
理解UDDI
跟上规范的不断发展
TomBellwood（bellwood@）,资深技术人员,IBM
TomBellwood是在IBM工作的一位资深技术人员，很多年都从事技术方面的工作，范围从半导体设计领域和设计自动化到开发系统和应用程序。
他是一位UDDI和UDDI如何支持不断发展的Web服务世界方面的专家。
他还是IBMUDDI业务注册中心的技术主管，曾多次在技术会议上发言。
简介：
统一描述、发现和集成（UniversalDescription,Discovery,andIntegration，UDDI）项目继续丰富企业用于在UDDI业务注册中心表示Web服务并建立其模型的工具集。
本文将介绍UDDI和它在Web服务发展过程中所起到的促进作用。
您可以了解到UDDI的工作原理，并发现UDDI规范新的即将出现的功能。
本文的标签：
net1,net2,net3
标记本文！
发布日期：
2002年7月01日
级别：
初级
访问情况：
3753次浏览
评论：
0 （查看 | 添加评论-登录）
平均分（6个评分）
为本文评分
何为UDDI？
UDDI项目鼓励Web服务相互操作和相互采用。
它是一种工商界居于领先地位的企业之间的伙伴关系，这种关系最早是由IBM、Ariba和Microsoft建立的。
现在参加的公司已逾300家。
UDDI提供了一组基于标准的规范用于描述和发现服务，还提供了一组基于因特网的实现。
UDDI继续快速发展，并赢得了业界的支持。
这一规范之所以发展很快，是因为有快速实现在背后提供支持，不仅证明了思想，而且为进一步完善规范提供了丰富的实践基础。
UDDI解决了企业遇到的大量问题。
首先，它能帮助拓展商家到商家（B2B）交互的范围并能简化交互的过程。
对于那些需要与不同顾客建立许多种关系的厂家来说，每家都有自己的一套标准与协议，UDDI支持一种适应性极强的服务描述，几乎可以使用任何接口。
对于一家地处澳洲的花店，虽然很希望能进入世界上的所有市场，但苦于不知道怎样才能成功，UDDI提供了一种能实现这一目标的办法。
规范允许企业在注册中心中发布它所提供的服务，这样发现企业及服务就变得高效而且简单了。
对于B2B交易场所提供者，他们需要获得这一行业内的供应商的分类数据，以及它们与计费服务、包装商、运输商、保险公司等之间的关系，UDDI允许动态发现相关的Web服务并将其集成到聚合的业务过程中。
UDDI提供一站式搜索有关企业和电子化服务的信息。
在UDDI中发布企业与服务信息使其它企业能大范围的访问到这些信息。
UDDI基于现成的标准，如可扩展标记语言（ExtensibleMarkupLanguage，XML）和简单对象访问协议（SimpleObjectAccessProtocol，SOAP）。
UDDI的所有兼容实现都支持UDDI规范。
公共规范是机构成员在开放的、兼容并蓄的过程中开发出来的。
目的在于先生成并实现这个规范的三个连续版本，之后再把将来开发得到的成果的所有权移交给一个独立的标准组织。
UDDI版本1规范于2000年9月发布，版本2于2001年6月发布。
版本3还在开发中，预计到2002年年中发布。
版本1打下了注册中心的基础，版本2则添加了企业关系等功能，版本3接下去要解决正在进行的Web服务开发中的重要领域内的问题，如安全性、改善了的国际化、注册中心之间的互操作性以及为进一步改进工具而对API进行的各种改进。
图1.UDDI的分层Web服务协议栈
如图1中所示，UDDI包含于完整的Web服务协议栈之内，而且是协议栈基础的主要部件之一，支持创建、说明、发现和调用Web服务。
UDDI构建于网络传输层和基于SOAP的XML消息传输层之上。
诸如Web服务描述语言（WebServicesDescriptionLanguage，WSDL）之类的服务描述语言提供了统一的XML词汇（与交互式数据语言（InteractiveDataLanguage，IDL）类似）供描述Web服务及其接口使用。
您可以通过添加分层的功能搭起整个基础，比如使用Web服务流程语言（WebServicesFlowLanguage，WSFL）的Web服务工作流描述、安全性、管理和服务质量功能，从而解决系统可靠性和可用性问题。
回页首
UDDI的工作原理
UDDI注册中心包含了通过程序手段可以访问到的对企业和企业支持的服务所做的描述。
此外，还包含对Web服务所支持的因行业而异的规范、分类法定义（用于对于企业和服务很重要的类别）以及标识系统（用于对于企业很重要的标识）的引用。
UDDI提供了一种编程模型和模式，它定义与注册中心通信的规则。
UDDI规范中所有API都用XML来定义，包装在SOAP信封中，在HTTP上传输。
图2.UDDI消息在客户机和注册中心之间的流动
图2说明了UDDI消息的传输，通过HTTP从客户机的SOAP请求传到注册中心节点，然后再反向传输。
注册中心服务器的SOAP服务器接收UDDISOAP消息、进行处理，然后把SOAP响应返回给客户机。
就注册中心条例而言，客户机发出的要修改数据的请求必须确保是安全的、经过验证的事务。
图3.UDDI工作原理
图3说明了如何往UDDI注册中心送入数据，顾客又如何能发现和使用这一信息。
UDDI注册中心建立在顾客提供的数据的基础之上。
要使数据能在UDDI中物尽其用需要几个步骤。
如第1步中所示，在软件公司和标准组织定义关于在UDDI中注册的行业或企业的规范时，开始向注册中心发布有用的信息。
这些规范叫做技术模型或者更常见的说法是tModel。
在第2步中，公司还会注册关于其业务及其提供的服务的描述。
如第3步中所示，UDDI注册中心会给每个实体指定一个在程序中唯一的标识符，叫做唯一通用标识符（UniqueUniversalIdentifier，UUID）键，从而能随时了解所有这些实体的情况。
UUID键必须是唯一的，并且在一个UDDI注册中心中从来都不会变化。
这些键看上去象格式化好的十六进制随机字符串（例如C0B9FE13-179F-413D-8A5B-5004DB8E5BB2）。
可以利用这些键来引用与之相关联的实体。
在一个注册中心中创建的UUID键只在该注册中心的上下文中有效。
在第4步，诸如电子交易场所（e-Marketplace）和搜索引擎等其它类型的客户机与商业应用程序（例如，基于工作流聚合起来的Web服务）使用UDDI注册中心来发现它们感兴趣的服务。
接着，另外的企业就可以调用这些服务，简便的进行动态集成，如第5步中所述。
UDDI注册中心里的数据从概念上可以分为四类，每一类表示UDDI最上层的一种实体。
每个这样的实体都指定有自己的UUID，利用这个标识符总能在UDDI注册中心的上下文中找到它：
∙技术模型（Technicalmodel）
∙企业（Business）
∙企业服务（Businessservice）
∙服务绑定（Servicebinding）
我们可以把企业与服务的注册信息分成以下三组：
白页、黄页和绿页。
白页表示有关企业的基本信息，如企业名称、经营范围的描述、联系信息等等。
它还包括该企业任何一种标识符，如Dun&BradstreetD-U-N-S®号码。
黄页信息通过支持使用多种具有分类功能的分类法系统产生的类别划分，使您能够在更大的范围内查找在注册中心注册的企业或服务。
这样的类别划分不仅可以关联企业及其服务，还可以关联tModel。
单提供白页和黄页中的一种或者这两种都提供，那么对于通过程序发现和使用服务，注册中心的条目的价值就很有限。
为此，有关怎样、哪里能通过程序的方式调用服务的信息就很有必要了，而绿页就提供了这样的信息。
绿页是指与服务相关联的绑定信息，并提供了指向这些服务所实现的技术规范的引用和指向基于文件的URL的不同发现机制的指针。
UDDI注册中心由UDDI规范的一种或多种实现组成，它们可以互操作以共享注册中心数据。
有一种特殊的UDDI注册中心是由一组对外公开访问的叫做节点的UDDI实现构成。
它们互操作以共享注册中心数据，合在一起就形成了UDDI业务注册中心。
该注册中心免费向大众开放。
在所有的运营商（Operator）站点上都冗余的放着UDDI业务注册中心的全部条目，但只有在创建条目的站点才能对条目进行更改。
IBM和Microsoft共同经营第1版的UDDI业务注册中心节点，这两个公司以及HP和SAP目前正在经营能支持大部分的第2版UDDI规范的beta测试站点。
这四家公司计划于2002年年中支持版本2生产注册中心。
每家公司都支持由UDDI规范定义的SOAPAPI。
通过商务合同来确保一致。
几家公司可以自由提供超出规范所要求的服务范围之外的附加服务，比如，基于浏览器的用户界面（所有公司都做到了这一点）。
回页首
UDDI规范一窥
UDDI规范是由一些文档组成的。
API规范描述允许您执行发现和发布操作的SOAPAPI。
还描述了请求／响应语义和错误处理。
此外，还有大量关于约定和用法的信息。
附带的文档包括数据结构规范（DataStructurespecification）和APISchema，它们定义了消息和数据语义。
UDDIAPI属于Inquiry或Publishing类别。
第1版支持API操作，如清单1中所示。
清单1.UDDIV1API综述
InquiryOperations:
PublishingOperations:
FindSave
find_businesssave_business
find_servicesave_service
find_bindingsave_binding
find_tModelsave_tModel
GetdetailsDelete
get_businessDetaildelete_business
get_serviceDetaildelete_service
get_bindingDetaildelete_binding
get_tModelDetaildelete_tModel
get_registeredInfoget_registeredInfo
Security
get_authToken
discard_authToken
查询API把自身归为三种查询模式：
UDDI版本2.0
UDDI在数据模型内定义了四种核心数据元素：
∙businessEntity（建立企业信息模型）
∙businessService（描述服务）
∙tModel（描述规范、分类或标识）
∙bindingTemplate（在businessService和描述其技术特征的tModel集之间进行映射）
除这些核心元素之外，版本2添加了建立企业之间的关系模型的支持。
UDDI规范和UDDI业务注册中心提供了一组参考实现，它们之间互操作共享注册、依据客户机需要启用支持设计时或运行时发现服务的编程模型。
IBMWeb服务倡议（WebServicesInitiative）的即时集成价值取向加上其它重要的使能技术（例如WSDL）允许机构执行在运行时动态发现和绑定Web服务。
UDDI规范一直以来的不断发展解决了关键领域内的问题（例如数据完整性、访问控制、身份识别、认证、互操作性、改进的数据建模能力、查询和本地化）进一步增加了UDDI注册中心的价值。
∙浏览器模式需要使用查找操作，查找操作允许您在浏览条目时使用不同类型的标准，例如分类法类别、标识符或利用find_xxxAPI查找不完整的名称信息。
∙逐步深入模式涉及到获得有关您已经找到的条目的详细信息。
get_xxxAPI支持这一功能。
∙调用模式是最后一种模式。
调用服务需要使用绑定模板信息，通常客户机将这一信息放在缓存区以供重复使用，不需要客户机在每次需要时再回到注册中心去获取同样的信息。
如果绑定信息变化了，那么一旦无法获得或使用服务，客户机就会返回到注册中心以更新这一信息。
这被称为调用模式。
虽然每个顶层实体都可以被保存和删除（利用save_xxx和delete_xxxAPI），而且主要是自动说明的，但是应该注意，通常UDDI中的保存操作的行为具有破坏性。
举个例子，再次保存同一个服务，但信息有所不同，结果以前代表该服务的那个实体会被完全替换掉。
与authTokens有关的操作要求您向某个UDDI业务注册中心节点预注册，提供确认发布者身份所必需的凭证。
这些凭证用于获取用于执行发布操作（利用save_xxxAPI）的authToken。
如果我们假定authToken没有过期，在紧紧相随的发布操作期间有一小段时间内它是可以重用的。
运营商制订的规定将决定authToken的内容和寿命。
回页首
UDDI版本2中有哪些新内容？
UDDI版本2引入了一些很关键的功能，有了这些功能可以提高版本1规范UDDI注册中心的使用质量和效率。
下面会分几部分描述版本2中的新功能：
∙为复杂机构提供建模支持
∙更强大的客户机分类和标识符支持
∙增强的查询
∙国际化功能
∙基于对等的复制
回页首
支持建模
有关支持建模的更新主要目的在于帮助大的机构更高效的建立其企业和服务的模型。
从牵涉到不同种类的风险的大型集团企业到集中精力经营一种业务而且希望按它们服务的地理区域来划分其Web产品的公司，许多都希望它们在Web上表现为独立却相互关联的企业。
在UDDI版本1中，对于这些情况，唯一的选择就是保持企业独立但却毫无关系。
版本2允许您定义企业之间的关系，例如父－子关系、伙伴－伙伴关系和等同关系。
这样，您就能根据具体情况为有下属子公司、外部业务伙伴或者内部的各种部门的公司建立模型。
任意两个企业（据其独一无二的企业键的定义）之间都可能会形成关系。
新建的BusinessRelationship类型的规范的tModel支持这一能力，而且还有一些新的发布API，允许您定义、删除和请求关系的状态，如清单2中所示。
名叫find_relatedBusinesses的新查询API使您能就给定的公司匿名搜索涉及到它的关系。
清单2中的其它新的发布API都与特定的发布者创建并拥有的关系有关，并且这些关系都不能通过匿名查询来访问。
一个企业关系由一对相同的关系断言组成，每个关系断言都会将这两家企业连在一起，并标志所建立的特定关系。
为了形成外部可见的企业关系，所涉及的两家企业每家必须声明相同的关系断言。
只有那些匹配的关系断言才会作为find_relatedBusinesses（）查询结果返回。
下面的示例展示了关系怎样形成，日后怎样发现关系。
首先，您会得到一个发布授权令牌：
清单2.得到一个authToken
//schemas.xmlsoap.org/soap/envelope/">
xmlns="urn:
uddi-org:
api_v2"
userID="businessA_UserId"
cred="businessA_Password"/>
其返回内容如下：
清单3.得到authToken的响应
//schemas.xmlsoap.org/soap/envelope/">
operator="
xmlns="urn:
uddi-org:
api_v2">
businessA_AuthToken
接着，您建立一个企业断言将企业A和企业B联系起来，在此我们不使用典型的UUID格式，而是把它们的businessKeys分别简写为businessKeyA和businessKeyB。
为了简洁起见，我们不再展示SOAP信封。
xmlns="urn:
uddi-org:
api_v2">
businessA_AuthToken
"businessKeyA"
"businessKeyB"
keyName="Subsidiary"
tModelKey="uuid:
c1acf26d-9672-4404-9d70-39b756e62ab4"/>
一旦企业B的主人也建立了一个相同的断言，就能在注册中心中看到一个对大众公开可见的企业关系。
然后，您可以利用find_relatedBusinesses（）API执行一个简单的查询：
xmlns="urn:
uddi-org:
api_v2">
"businessKeyA"
清单3展示了返回的XML。
更加细粒度的查询可能会包括一个标识正在查找的特定关系的keyedReference。
版本2中为支持大企业的建模需求而新增的另一项重要功能叫做服务投影（ServiceProjection），它允许一家企业创建对另一家企业拥有的服务的引用。
这在有些情况下是很有用的，例如，对于在两个或以上的行业内提供相同的服务的公司和通用服务（例如过夜运输）都很有用，有许多企业都想要把某个通用服务链接到它们自己提供的服务上来鼓励使用这种服务。
投影的服务引用的功能不过如此。
服务投影的创建者不能改变所引用的真正服务，但在其它所有方面，这个服务都好象真的是创建投影的企业所拥有一样。
服务是get_businessDetail（）或get_serviceDetail（）API调用返回的一部分。
通过与服务相关联的具有所有权的企业键，您可以把投影服务与真正的服务区分开来。
这个键始终与拥有服务的真正企业相匹配，而不是与创建服务投影的企业相配。
回页首
强大的分类功能
在版本1中提供了三种内置的分类法供为企业和服务分类使用。
它们是NAICS行业分类法、UNSPC项目和服务分类法和ISO-3166-2地理分类法。
UDDI注册中心会在内部检查这些分类法的使用情况；试图保存无效的代码会遭到拒绝。
在UDDI中有针对性的分类法的重要性再怎么强调也不会过分。
既然查找感兴趣的有用信息功能最为强大的方法只有这一种，那么提高业界创建和控制新的分类法的能力将继续占有较高的优先级。
版本2新增的能力使机构能定义新的外部检查的分类法，可以在UDDI中提供这些分类法供大众使用。
这些外部分类法提供者必须支持validate_valuesWeb服务，并使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，复
升级会员 