本文摘自：
http://www.ibm.com/developerworks/cn/xml/specification/index2.html
UDDI技术白皮书 |  |
|
级别： 初级 2001 年 5 月 01 日 摘要：统一描述、发现和集成协议(UDDI)是一套基于Web的、分布式的、为Web服务提供的信息注册中心的实现标准规范，同时也包含一组使企业能将自身提供的Web服务注册以使得别的企业能够发现的访问协议的实现标准。 Web服务是下一代的WWW，它允许在Web站点上放置可编程的元素，使得能进行基于Web的分布式计算和处理。UDDI商业注册中心的创建目的就是为促进企业的Web服务的发展及为企业发现适当的Web服务。本文描述了这些基于Web的UDDI商业注册中心的能力。 本文针对的读者群包括所有想要从概念上理解什么是UDDI，谁来使用UDDI，以及分布式的商业注册中心如何使得程序能发现别的商业实体在Web上提供的Web服务并且同这些服务进行交互。 概览 Web服务将逐渐成为电子商务应用构建的基础体系架构。例如，一个公司通过另一个公司所提供的服务，直接在Internet上发送一份订货单。又例如，某一个服务用于计算某一尺寸或是重量的货物通过某种方法(如海运)运输一定距离需要花费多少费用。 最初，大家可能会将它看做是一个管理如何发现Web服务的过程。其实，如果现有的商务合作伙伴已经有了一个已知的电子商务入口，那还有什么需要发现的呢？当然这是建立在一个默认的假定情况"信息都是已知的"这样一个基础上的。而且无论在哪种情况下，当需要找出哪些商业伙伴可以提供什么样的服务时，快速地发现并找到答案仍然将会变得十会困难。其中一个可选的方法是使用电话和每个合作伙伴进行联系，然后找出合适的对象。对于一个提供Web服务的商业实体来说，需要配备具备相当技术能力的专业人员去满足这样随机的服务发现需求显然是不合适的。 另一个解决该问题的办法是在公司的每个网站上放置一个Web服务的描述文件。这样，至少那些依靠已经注册的URL 来工作的网络爬虫程序能够发现并为它们建立索引。可是这种通过"robots.txt"来定位Web 服务的方法完全依赖爬虫程序的能力。这种分布式的机制是可扩展的，但它缺少一种机制来保证服务描述格式的一致性，也不能便捷的跟踪不断发生的变化。 UDDI 提供了一种基于分布式的商业注册中心的方法，该商业注册中心维护了一个企业和企业提供的Web 服务的全球目录，而且其中的信息描述格式是基于通用的XML 格式的。 UDDI的商业注册与UDDI商业注册中心 使用UDDI 阅读过本文后，读者能对UDDI规范所定义的能力以及依据该规范实现的Web服务注册中心的角色认识有一个非常清晰的了解。 背景 W3C 近期来的工作让我们看到了希望，XML(Extensible Markup Language 扩展标注语言)将会对简化企业之间的商业数据交换起到很大作用。而且，计算机工业的巨头们和很多其它小公司一起，推出了SOAP ，这项技术使应用程序可以通过Internet调用各种服务的界面，而无须考虑使用的具体是什么样的编程语言以及底层使用的分布式对象结构。这些振奋人心的消息使得诸多公司认识到，原先由于电子商务的交互标准的不同而产生的交互代价已经显著降低了。因为有了这些技术和标准，原来难以处理的问题，现在变得容易解决了。 借助XML 和SOAP ，集成和交互的问题将从层次上被简化。XML 提供了跨平台的数据编码和组织方法，而SOAP 建立在XML 之上，定义了一种跨系统平台的信息交换的简单包装方法。绑定于HTTP之上的SOAP协议，可以跨语言、跨操作系统进行远程过程调用(RPC)，实现了编程语言和系统平台的无关性。而以前的调用方式则和复杂的分布式对象标准或是中间件有密切的关系，从长期的眼光来看，这些都不是高效的解决方案。XML 和SOAP 这样的跨语言、跨平台的解决方案大大简化了不同企业系统之间的交互问题。 但如果仅仅是XML和SOAP的话，对于公司间的交流仍存在着巨大的鸿沟。工业界的任何一个权威人士都会这样告诉你："我们需要的是一种真正端到端的解决方案，它建立在任何计算机平台都支持的全球性标准之上。" 显然，要达到这一点还需要很多的努力。UDDI 规范在XML 和SOAP 的基础之上定义了新的一层，在这一层次，不同企业可以用相同的方法描述自己所能提供的，并能查询对方所能提供的服务。 以下图表描述了这些协议的层次关系：图1
UDDI - 技术发现层 图2描述了UDDI 规范、XML Schema 和UDDI 商业注册中心集群之间的关系，UDDI 商业注册中心集群能为Web 服务提供"一次注册，到处发布"的功能。 图 2  UDDI规范和调用模式用来在Internet上建立起发现服务。这些发现服务提供了一致的发布接口，以使得能通过编程进行发现。 通过使用UDDI的发现服务，企业可以单独注册那些希望被别的企业发现的自身提供的Web服务。企业可以通过UDDI商业注册中心的Web界面，或是使用实现了"UDDI Programmer's API标准"所描述的编程接口的工具，来将信息加入到UDDI的商业注册中心。UDDI商业注册中心在逻辑上是集中的，在物理上是分布式的，由多个根节点组成，相互之间按一定规则进行数据同步。当一个企业在UDDI商业注册中心的一个实例中实施注册后，其注册信息会被自动复制到其它UDDI 根节点，于是就能被任何希望发现这些Web服务的人所发现。 下一步 商业发现与UDDI 图 3  图3 显示了UDDI 的技术发现层和商业发现层上的集成的或专用的搜索机制之间的关系。目前，在线市场和搜索引擎被用来完成这个功能，使用UDDI 分布注册中心集群中的注册信息可以被利用于它们之间的集成，并促进它们自身的发展。 进一步的工作 本文档的其余部分将从技术角度概述UDDI发现服务和规范的各种特性。
统一描述、发现和集成协议(UDDI)标准包括了SOAP消息的XML Schema和UDDI规范API的描述。它们两者一起建立了基础的信息模型和交互框架，具有发布各种Web 服务描述信息的能力。 四种信息类型 UDDI XML Schema 定义了四种主要信息类型，它们是技术人员在需要使用合作伙伴所提供的Web 服务时必须了解的技术信息。它们是：商业实体信息、服务信息、绑定信息和服务调用规范的说明信息。 图 4  如图4 所示，层次信息与关键的XML元素名被用于描述与发现Web服务的相关信息。(请参阅 附录A，其中给出了完整的UDDI信息模型。) 商业实体信息：businessEntity 元素 所有"businessEntity"中的信息支持"黄页"分类法。因此可以执行这样的搜索，如可以定位属于某个行业分类或提供某种产品的企业，也可以是定位处于某个地域范围内的企业。 服务信息：businessService元素和bindingTemplate元素 这些businessService的信息集合可以再次加以分类，使Web应用服务的描述可以按不同的行业、产品、服务类型或是地域划分来进行。 对于每一个businessService，存在一个或多个Web 服务的技术描述。这些技术描述包括应用程序连接远程Web 服务并与之通讯所必须的信息。这些信息包括Web应用服务的地址、 应用服务宿主 (注释4) 和调用服务前必须调用的 附加应用服务 (注释5) 等。另外，通过附加的特性还可以实现一些复杂的路由选择，诸如 负载平衡 (注释6) 等。 杂凑集合 (注释7) ，组成了类似指纹的技术标识，用来查找、识别实现了给定行为或编程接口的Web 服务。 (注释8) 等。在我们的例子中，在bindingTemplate中可以得到指向描述订单服务的关于调用规范的信息的tModel引用。这个引用本身可以被看作是提供这项Web 服务的公司的承诺，承诺他们已经实现了一个与所引用的tModel 相兼容的服务。通过这种方式，很多公司可以提供与该调用规范相兼容的Web 服务。 (注释9) 并保存留待以后使用。 (注释10)，不过所有的签署协议的公共的UDDI注册中心操作入口站点都需要满足规定协议中定义的最小安全规范以提供类似的安全机制。 规范描述的指针和技术标识 当一个程序或是程序员需要调用某个特定的Web服务时，必须根据应用要求得到了足够充分的调用规范等相关信息，以使调用被正确地执行。因此，每一个bindingTemplate元素都包含一个特殊的元素，该元素包含了一个列表，列表的每个子元素分别是一个调用规范的引用。这些引用作为一个标识符的 在我们的订单例子中，接受订单的Web 服务提供了一套定义良好的处理方法，当然前提是格式正确的信息以正确的方式被送到了正确的地点。这项服务的UDDI 注册将包括这些内容：用于描述商业合作伙伴的信息条目，描述订单服务的逻辑服务的信息条目，描述订单服务技术调用规范的bindingTemplate信息条目，其中bindingTemplate信息条目包含了服务的URL 和一个tModel引用 。 实际上，这些引用是访问服务所需要的关键的调用规范信息。被称为"tModel "的数据项是关于调用规范的元数据，它包括服务名称，发布服务的组织以及指向这些规范本身的URL指针 程序员API 构建于SOAP之上 查询API UDDI调用模型
一般说来，只要远程Web 服务和调用它的程序都准确的实现了必要的接口(按照在tModel 中所引用的调用规范)，对远程服务的调用就一定会成功。下面将就错误和恢复问题进行详细讨论。 远程Web服务调用失败后的恢复 商业实体使用Web服务同他们的合作伙伴进行交易的时候，必须能够处理通讯故障或一些其它的问题。一个关键问题是无法预计、检测和恢复在合作伙伴的远程系统中出现的错误。即使是由于夜间备份或是维护所引起的临时存储空间溢出这样的问题，在Web服务中都变得非常地棘手。 另一方面，如果你的公司使用直接的Web 服务连接，你必须非常重视灾难恢复以及能否将所有与商业合作伙伴的交易迁移到一个备份系统中去等问题。 为了解决这些"服务质量"问题，UDDI 定义了一个方法使用缓冲存诸bindingTemplate信息来进行具体调用。当发生调用失败的时候，使用UDDI 注册中心中的最新信息来刷新缓存信息。具体过程是这样的：
此外，当企业需要将调用重定向到新地址或是备份系统时，他们只需要启动备份系统并在binding Template中将服务地址更新。这种方法称之为"失败重试"，它的效率比在每次调用前刷新bindingTemplate 数据的方式要高。 发布API 安全：识别与授权 每个UDDI 商业注册中心的实例被称为一个操作入口站点(Operator Site)，操作入口站点被允许定义他自己的用户授权机制
关于UDDI Schema 和UDDI 程序员API 规范(UDDI Programmer's API Specification)的详细信息，请参见uddi.org 站点提供的相关文档。 这些规范以一组相互链接的HTML 文档形式发布，其中为提供的相关子服务定义了一些特殊的tModel。这些独立的tModel引用实际上是整个规范中关于概览、API调用和附录信息的概览信息的共享链接。 供打印的Microsoft Word 和PDF 格式的规范文档也在uddi.org提供下载。
下图描述了构成UDDI信息结构的各个核心信息元素之间的关系 
这里给出了许多规范、文档参考和有用的信息的链接，这些信息可以帮助你理解本技术白皮书。
注释2：参见UDDI XML schema - http://www.uddi.org/schema/uddi_1.xsd 注释3：复杂的商业实体信息应该注册在独立的businessEntity中。 注释4：其它公司可能是该应用服务宿主的用户，这一般是基于费用考虑的。交易市场就是一个很好的例子，使得各个商业实体并不一定需要建立自己的在线站点，就可以进行电子商务。 注释5：软件包是这种需求的一个很好的例子。一个软件包的安装可能需要先和一个服务建立连接并得到一些必要的初始参数。 注释6：主机重定向的特性使得主从服务器的能力都能被充分利用到。参考UDDI程序员API标准中的关于重定向的附录。 注释7：杂凑集合在这里意味着只要知道一个特定调用规范的主键值，就等同于了解了兼容该规范的Web服务。 注释8： 注意： tModel并不包含实际的规范。UDDI定义了一个利用URL和Web服务优点的框架，使每个组织能够集中地维护自己的调用规范。可以通过对键值的访问来确定一个具体的实现是否是基于给定的调用规范的。 注释9：通过使用查询API find_xx，一个与UDDI兼容的浏览器可以按用户的需要，显示更多或更少的搜索信息的细节。当信息被定位以后，get_xx调用就可以得到这四个UDDI主要的XML结构之一的详细信息。 注释10：基于UDDI规范的独立实现不可以被强制要求遵循某些特别的约定或需求。因此，如果你对安全性或是信息访问控制策略有疑问的话，需要和实现者进行协商。
| ||||||||||||||||||||||||||||||||||||||||||
813
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
