进一步的工作

　　UDDI工作小组正在计划对规范草案进行扩展，加入技术发现以外的内容。将来的特性将包括：对产品或服务进行定位的能力；定义Web服务的实现模式；提供对商业组织、团体和贸易集团的分层结构进行管理的能力。所希望的目标是，针对B2B(商家到商家)和M2M(市场到市场)，为Web服务的互操作能力提供的一个公共规范。

　　本文档的其余部分将从技术角度概述UDDI发现服务和规范的各种特性。

　　技术概述

　　统一描述、发现和集成协议(UDDI)标准包括了SOAP消息的XML Schema和UDDI规范API的描述。它们两者一起建立了基础的信息模型和交互框架，具有发布各种Web服务描述信息的能力。

　　四种信息类型

　　UDDI注册使用的核心信息模型由XML Schema定义。使用XML是因为它提供了平台无关的数据描述并很自然的描述了数据的层次关系。而选择XML Schema是因为它支持丰富的数据类型，便捷的描述方式及其按信息模型对数据进行验证的能力。

　　UDDI XML Schema定义了四种主要信息类型，它们是技术人员在需要使用合作伙伴所提供的Web服务时必须了解的技术信息。它们是：商业实体信息、服务信息、绑定信息和服务调用规范的说明信息。

　　图4
 
　　如图4所示，层次信息与关键的XML元素名被用于描述与发现Web服务的相关信息。

　　商业实体信息：businessEntity元素

　　许多合作伙伴希望能准确地定位到你提供的服务的相关信息，并把这些信息作为了解你们企业的开始。技术人员、程序员或应用程序希望知道你的企业名称和一些关键性的 标识(注释1)，以及那些可选的分类信息和联络方法等。支持对UDDI商业注册的商业信息发布和发现的核心XML元素被包含在”businessEntity”(注释2)结构中。这个结构是商业机构专属信息集的最高管理者，位于整个信息结构的最上层(注释3)。

　　所有”businessEntity”中的信息支持”黄页”分类法。因此可以执行这样的搜索，如可以定位属于某个行业分类或提供某种产品的企业，也可以是定位处于某个地域范围内的企业。

　　服务信息：businessService元素和bindingTemplate元素

　　”绿页”数据是Web服务的技术和商业描述，是businessEntiry的子结构。在这一层次，定义了两个结构：businessService和bindingTemplate 。businessService结构是一个描述性的容器，它将一系列有关商业流程或分类目录的Web服务的描述组合到一起。其中，一个可能的商业流程的例子是一组相关的Web服务信息，包括采购服务、运输服务和其它的高层商业流程。

　　这些businessService的信息集合可以再次加以分类，使Web应用服务的描述可以按不同的行业、产品、服务类型或是地域划分来进行。

　　对于每一个businessService，存在一个或多个Web服务的技术描述。这些技术描述包括应用程序连接远程Web服务并与之通讯所必须的信息。这些信息包括Web应用服务的地址、应用服务宿主(注释4)和调用服务前必须调用的 附加应用服务(注释5)等。另外，通过附加的特性还可以实现一些复杂的路由选择，诸如 负载平衡(注释6)等。

　　规范描述的指针和技术标识

　　调用一个服务所需要的信息是在bindingTemplate的结构中定义的，这在前面一节中已经阐述了。不过一般来说，仅知道Web服务所在的地址是不够的。例如，如果我知道我的合作伙伴提供一个Web服务来让我下订单，同时也知道这个服务的URL，不过如果不知道一些具体的信息，如订单的具体格式，应该使用的协议，需要采用的安全机制，调用返回的响应格式等，那样的话，通过Web服务将两个系统集成起来仍然是非常困难的。

　　当一个程序或是程序员需要调用某个特定的Web服务时，必须根据应用要求得到了足够充分的调用规范等相关信息，以使调用被正确地执行。因此，每一个bindingTemplate元素都包含一个特殊的元素，该元素包含了一个列表，列表的每个子元素分别是一个调用规范的引用。这些引用作为一个标识符的 杂凑集合(注释7)，组成了类似指纹的技术标识，用来查找、识别实现了给定行为或编程接口的Web服务。

　　在我们的订单例子中，接受订单的Web服务提供了一套定义良好的处理方法，当然前提是格式正确的信息以正确的方式被送到了正确的地点。这项服务的UDDI注册将包括这些内容：用于描述商业合作伙伴的信息条目，描述订单服务的逻辑服务的信息条目，描述订单服务技术调用规范的bindingTemplate信息条目，其中bindingTemplate信息条目包含了服务的URL和一个tModel引用 。

　　实际上，这些引用是访问服务所需要的关键的调用规范信息。被称为”tModel “的数据项是关于调用规范的元数据，它包括服务名称，发布服务的组织以及指向这些规范本身的URL指针(注释8)等。在我们的例子中，在bindingTemplate中可以得到指向描述订单服务的关于调用规范的信息的tModel引用。这个引用本身可以被看作是提供这项Web服务的公司的承诺，承诺他们已经实现了一个与所引用的tModel相兼容的服务。通过这种方式，很多公司可以提供与该调用规范相兼容的Web服务。

　　程序员API

　　UDDI规范包括Web服务的接口定义，使得能通过编程实现对UDDI注册中心的信息访问。程序员API规范(Programmer’s API Specification)文档详细定义了程序员API，下面只是关于API的简单讨论。

　　API分为两个逻辑部分：查询API和发布API。查询API又分为两个部分:一部分被用来构造搜索和浏览UDDI注册信息的程序，另一部分在Web服务出现错误时使用。程序员可以利用发布API创建各种类型的工具，以直接与UDDI注册中心进行交互，便于企业技术人员管理businessEntity或tModel结构的发布信息。

　　构建于SOAP之上

　　简单对象访问协议(SOAP)是W3C草案，描述了一种使用XML和HTTP进行信息传送和远程过程调用的方法。包括IBM、Microsoft、DevelopMentor和Userland Software在内的多家公司向W3C提交了该草案，其中一个目的就是在Internet上对RPC(简单消息)协议进行标准化。目前看来，草案所描述的规范对定义Web服务非常有效。因此，在UDDI技术开发中合作的多家公司决定将UDDI API建立在SOAP规范之上。在API规范的附录中定义了UDDI注册中心的操作入口站点应该怎样使用SOAP和XML 。

　　UDDI程序员API规范文档中定义的所有API调用都是同步的，而且所有分布的UDDI注册中心的操作入口站点都支持程序员API规范中定义的全部API 。

　　查询API

　　查询API包含两类调用，使程序能快速地定位候选商业实体、Web服务及其调用规范，然后在最初调用获得的初始信息的基础上，获得进一步的相关信息的细节。这类以find_xx命名的API提供了多种搜索标准，从而能对注册中心中的数据进行广泛地搜索。另一方面，如果事先已经知道所需数据的关键字，则可以通过直接调用get_xx API得到相应的结构数据(如：businessEntity、businessService、bindingTemplate、tModel)。

　　UDDI调用模型

　　每一个独立发布的Web服务都是使用一个bindingTemplate结构来建模的。对这个Web服务的调用通常通过缓存bindingTemplate 数据来实现。注意到这一点后，在你准备编写调用某种Web服务的程序时，该如何使用UDDI就很清楚了。下面列出了基本步骤：

　　·编写调用远程Web服务的程序时，程序员使用UDDI商业注册中心(通过使用Web界面或其它基于查询API的工具)来定位businessEntity信息，这些信息是由(或为)提供该Web服务的企业注册的。
　　·程序员可以进一步获得更详细的businessService信息，或是得到一个完整的businessEntity结构。因为businessEntity结构包含了有关已发布的Web服务的所有信息，因此程序员只需简单地选择一个bindingTemplate(注释9)并保存留待以后使用。
　　·基于Web服务在bindingTemplate的tModel中提供的调用规范的相关信息，程序员可以按照该Web服务的调用规范编写程序。
　　·在运行时，程序可以按需要使用已保存下来的bindingTemplate的信息来调用Web服务。

　　一般说来，只要远程Web服务和调用它的程序都准确的实现了必要的接口(按照在tModel中所引用的调用规范)，对远程服务的调用就一定会成功。下面将就错误和恢复问题进行详细讨论。

　　远程Web服务调用失败后的恢复

　　在分布式的UDDI注册中心中维护Web服务的信息的一个主要好处是，是获得为技术人员提供的”自我服务”功能。上一节中，已经给出了程序员使用UDDI注册中心中的信息的大致步骤，我们还可以得到更多的好处。这些通过使用UDDI注册中心的操作入口站点来维护注册信息所带来的好处非常明显地体现于灾难恢复的情况下。

　　商业实体使用Web服务同他们的合作伙伴进行交易的时候，必须能够处理通讯故障或一些其它的问题。一个关键问题是无法预计、检测和恢复在合作伙伴的远程系统中出现的错误。即使是由于夜间备份或是维护所引起的临时存储空间溢出这样的问题，在Web服务中都变得非常地棘手。

　　另一方面，如果你的公司使用直接的Web服务连接，你必须非常重视灾难恢复以及能否将所有与商业合作伙伴的交易迁移到一个备份系统中去等问题。

　　为了解决这些”服务质量”问题，UDDI定义了一个方法使用缓冲存诸bindingTemplate信息来进行具体调用。当发生调用失败的时候，使用UDDI注册中心中的最新信息来刷新缓存信息。具体过程是这样的：

　　·准备调用Web服务，缓存必需的bindingTemplate数据以备运行时使用。
　　·在调用一个远程Web服务的时候，使用从UDDI注册中心获得的，被缓存的bindingTemplate数据。
　　·如果调用失败，使用bindingKey的值和get_bindingTemplate API调用得到此Web服务的bindingTemplate的最新副本。
　　·把新的数据和原来的数据进行比较，如果是不同的，使用新的数据并重试刚才失败的调用操作。如果重试成功，则将新的数据更新到缓存中。

　　此外，当企业需要将调用重定向到新地址或是备份系统时，他们只需要启动备份系统并在binding Template中将服务地址更新。这种方法称之为”失败重试”，它的效率比在每次调用前刷新bindingTemplate数据的方式要高。

　　发布API

　　发布API包括四个save_xx函数和四个delete_xx函数，每个对应于一个UDDI主要结构(businessEntity，binsinessService，bindingTemplate，tModel)。一旦得到授权，一个独立的机构可以注册任意数量的businessEntity或tModel信息，也可以修改原先发布的信息。API设计模型很简单：可以更改特定的相关信息，也可以使用save功能来保存新信息。要删除整个结构则可以调用delete功能。详细信息请参见程序员API规范(Programmer’s API Specification)。

　　安全：识别与授权

　　使用UDDI的发布API的关键原则是只允许被授权的用户进行发布或修改UDDI商业注册中心中的数据。每一个分布式的UDDI商业注册中心维护一张唯一的授权用户列表，并跟踪所有用户创建的businessEntity或tModel数据。只有信息的创建者才允许对该信息进行更改或删除。

　　每个UDDI商业注册中心的实例被称为一个操作入口站点(Operator Site)，操作入口站点被允许定义他自己的用户授权机制(注释10)，不过所有的签署协议的公共的UDDI注册中心操作入口站点都需要满足规定协议中定义的最小安全规范以提供类似的安全机制。

　　作者简介

　　阮文骏: UDDI-China首批成员，上海得易电子商务技术有限公司系统架构师。将于2001年6月获复旦大学计算机科学硕士学位，曾在中国XML技术研讨会(北京)发表XML技术论文。专长于基于XML技术，软件工程，同时对管理信息系统及企业管理科学等比较擅长。
 
　　柴晓路: 上海得易电子商务技术有限公司(DealEasy)首席系统架构师、XML技术顾问。2000年获复旦大学计算机科学硕士学位，曾在国际计算机科学学术会议(ICSC)、亚太区XML技术研讨会(XML Asia/Pacific’99)、中国XML技术研讨会(北京)、计算机科学期刊等各类国际、国内重要会议与期刊上发表论文多篇。专长于基于XML的系统集成和数据交换的技术研究，同时对数据库、面向对象技术及CSCW等技术比较擅长。2001年加入UDDI Advisor Group，参与了UDDI Specification V2的开发。目前在与UDDI.org合作筹备UDDI-China.org，后者将在2001年6月进行技术中心站点发布。