UDDI技术白皮书

 

本文摘自：

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服务并且同这些服务进行交互。 简介 概览 统一描述、发现和集成协议(UDDI, Universal Description, Discovery and Integration)标准定义了Web服务的发布与发现的方法。所谓的"Web服务"，它是指由企业发布的完成其特别商务需求的在线应用服务，其它公司或应用软件能够通过Internet来访问并使用这项在线服务。 Web服务将逐渐成为电子商务应用构建的基础体系架构。例如，一个公司通过另一个公司所提供的服务，直接在Internet上发送一份订货单。又例如，某一个服务用于计算某一尺寸或是重量的货物通过某种方法(如海运)运输一定距离需要花费多少费用。 最初，大家可能会将它看做是一个管理如何发现Web服务的过程。其实，如果现有的商务合作伙伴已经有了一个已知的电子商务入口，那还有什么需要发现的呢？当然这是建立在一个默认的假定情况"信息都是已知的"这样一个基础上的。而且无论在哪种情况下，当需要找出哪些商业伙伴可以提供什么样的服务时，快速地发现并找到答案仍然将会变得十会困难。其中一个可选的方法是使用电话和每个合作伙伴进行联系，然后找出合适的对象。对于一个提供Web服务的商业实体来说，需要配备具备相当技术能力的专业人员去满足这样随机的服务发现需求显然是不合适的。 另一个解决该问题的办法是在公司的每个网站上放置一个Web服务的描述文件。这样，至少那些依靠已经注册的URL 来工作的网络爬虫程序能够发现并为它们建立索引。可是这种通过"robots.txt"来定位Web 服务的方法完全依赖爬虫程序的能力。这种分布式的机制是可扩展的，但它缺少一种机制来保证服务描述格式的一致性，也不能便捷的跟踪不断发生的变化。 UDDI 提供了一种基于分布式的商业注册中心的方法，该商业注册中心维护了一个企业和企业提供的Web 服务的全球目录，而且其中的信息描述格式是基于通用的XML 格式的。 UDDI的商业注册与UDDI商业注册中心 UDDI 计划的核心组件是UDDI商业注册，它使用一个XML文档来描述企业及其提供的Web服务。从概念上来说，UDDI商业注册所提供的信息包含三个部分："白页(White Page)" 包括了地址，联系方法，和已知的企业标识；"黄页(Yellow page)"包括了基于标准分类法的行业类别；"绿页(Green Page)"则包括了关于该企业所提供的Web服务的技术信息，其形式可能是一些指向文件或是URL的指针，而这些文件或URL是为服务发现机制服务的。所有的UDDI商业注册信息存储在UDDI商业注册中心中。 使用UDDI UDDI规范包含了对基于Web的UDDI商业注册中心可以实施的整套共享操作。一般来说，程序或程序员通过UDDI商业注册中心来获得Web服务的位置及其技术信息。其中对于程序员来说，是对自己的系统实现进行准备，以使自己的系统能和那些Web服务实现访问兼容，或是描述自己的Web服务从而能让别人使用。从商业层次上来说，UDDI商业注册中心可以被用于核查某个合作伙伴是否拥有特定的Web服务的调用界面，或是去找出在某一个行业中能提供某种类型服务的公司，并确定某一个合作伙伴或是潜在的合作伙伴的Web服务的技术描述以了解要与该Web服务进行交互所必须的技术细节。 阅读过本文后，读者能对UDDI规范所定义的能力以及依据该规范实现的Web服务注册中心的角色认识有一个非常清晰的了解。 背景 各个公司在如何使用Web的方法上存在很大程度上的差异。许多公司开始利用新出现的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) 简单对象访问协议 (SOAP) 扩展标注语言 (XML) 通用Internet协议 (HTTP, TCP/IP) UDDI是为了实现Web应用服务诸多协议的"下一层"，使用诸如TCP/IP、HTTP、XML和SOAP标准，来创建统一的服务描述格式和服务发现协议。 UDDI - 技术发现层 统一描述、发现和集成协议(UDDI)规范一个由Web服务所构成的逻辑上的云状服务，同时也定义了一种编程接口，这种编程接口提供了描述Web 服务的简单框架。规范包括几份相关的文档和一份XML Schema ，用来定义基于SOAP 的注册和发现Web 服务的协议。这些规范由来自多家业界主要公司的技术人员和管理人员花费了几个月的时间制定完成。这些公司也担负起实现第一批UDDI商业注册中心服务的任务，这些服务将可以被所有人所访问，同时其多个合作站点之间能够无缝地共享注册信息。 图2描述了UDDI 规范、XML Schema 和UDDI 商业注册中心集群之间的关系，UDDI 商业注册中心集群能为Web 服务提供"一次注册，到处发布"的功能。 图 2 UDDI规范和调用模式用来在Internet上建立起发现服务。这些发现服务提供了一致的发布接口，以使得能通过编程进行发现。 通过使用UDDI的发现服务，企业可以单独注册那些希望被别的企业发现的自身提供的Web服务。企业可以通过UDDI商业注册中心的Web界面，或是使用实现了"UDDI Programmer's API标准"所描述的编程接口的工具，来将信息加入到UDDI的商业注册中心。UDDI商业注册中心在逻辑上是集中的，在物理上是分布式的，由多个根节点组成，相互之间按一定规则进行数据同步。当一个企业在UDDI商业注册中心的一个实例中实施注册后，其注册信息会被自动复制到其它UDDI 根节点，于是就能被任何希望发现这些Web服务的人所发现。 下一步 正如图1 所示，UDDI 并没有完成所有的发现服务所需要的特性。UDDI 服务的目标是为了在技术上实现服务的发现。借助UDDI所定义的功能，程序或程序员能够定位到合作伙伴所提供的W服务的信息，知道对方是否提供了与自己的技术相兼容的服务，然后按照这些合作伙伴的Web服务所提供的调用标准进行集成并与之相容。企业也可以使用UDDI找到潜在的合作伙伴，或者说，更可能的情况是，从一个以UDDI为数据来源并加入自身增值服务的在线交易市场或搜索引擎中找到潜在的合作伙伴。由于技术上的兼容性是可以被发现的，所以软件提供商也可以借助UDDI 注册中心，在用户安装软件或注册登记时自动配置某种技术连接。 商业发现与UDDI UDDI 的设计目的是作为对现有的在线交易市场和搜索引擎的补充，为电子商务和服务发现机制提供标准的格式。UDDI 规范中没有直接涉及到具体的商业发现流程，例如找出一个以某一个给定的价格或在某一特定区域内的提供某种特定的产品或服务的企业。高级的发现特性需要买方和卖方更进一步的合作与设计。UDDI只是为定义这些上层应用提供了基础。 图 3 图3 显示了UDDI 的技术发现层和商业发现层上的集成的或专用的搜索机制之间的关系。目前，在线市场和搜索引擎被用来完成这个功能，使用UDDI 分布注册中心集群中的注册信息可以被利用于它们之间的集成，并促进它们自身的发展。 进一步的工作 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服务的相关信息。(请参阅 附录A，其中给出了完整的UDDI信息模型。) 商业实体信息：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) 等。 杂凑集合 (注释7) ，组成了类似指纹的技术标识，用来查找、识别实现了给定行为或编程接口的Web 服务。 (注释8) 等。在我们的例子中，在bindingTemplate中可以得到指向描述订单服务的关于调用规范的信息的tModel引用。这个引用本身可以被看作是提供这项Web 服务的公司的承诺，承诺他们已经实现了一个与所引用的tModel 相兼容的服务。通过这种方式，很多公司可以提供与该调用规范相兼容的Web 服务。 (注释9) 并保存留待以后使用。 (注释10)，不过所有的签署协议的公共的UDDI注册中心操作入口站点都需要满足规定协议中定义的最小安全规范以提供类似的安全机制。 规范描述的指针和技术标识 调用一个服务所需要的信息是在bindingTemplate的结构中定义的，这在前面一节中已经阐述了。不过一般来说，仅知道Web服务所在的地址是不够的。例如，如果我知道我的合作伙伴提供一个Web服务来让我下订单，同时也知道这个服务的URL，不过如果不知道一些具体的信息，如订单的具体格式，应该使用的协议，需要采用的安全机制，调用返回的响应格式等，那样的话，通过Web服务将两个系统集成起来仍然是非常困难的。 当一个程序或是程序员需要调用某个特定的Web服务时，必须根据应用要求得到了足够充分的调用规范等相关信息，以使调用被正确地执行。因此，每一个bindingTemplate元素都包含一个特殊的元素，该元素包含了一个列表，列表的每个子元素分别是一个调用规范的引用。这些引用作为一个标识符的 在我们的订单例子中，接受订单的Web 服务提供了一套定义良好的处理方法，当然前提是格式正确的信息以正确的方式被送到了正确的地点。这项服务的UDDI 注册将包括这些内容：用于描述商业合作伙伴的信息条目，描述订单服务的逻辑服务的信息条目，描述订单服务技术调用规范的bindingTemplate信息条目，其中bindingTemplate信息条目包含了服务的URL 和一个tModel引用 。 实际上，这些引用是访问服务所需要的关键的调用规范信息。被称为"tModel "的数据项是关于调用规范的元数据，它包括服务名称，发布服务的组织以及指向这些规范本身的URL指针 程序员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 基于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)，操作入口站点被允许定义他自己的用户授权机制 回页首 其它信息 关于UDDI Schema 和UDDI 程序员API 规范(UDDI Programmer's API Specification)的详细信息，请参见uddi.org 站点提供的相关文档。 这些规范以一组相互链接的HTML 文档形式发布，其中为提供的相关子服务定义了一些特殊的tModel。这些独立的tModel引用实际上是整个规范中关于概览、API调用和附录信息的概览信息的共享链接。 供打印的Microsoft Word 和PDF 格式的规范文档也在uddi.org提供下载。 回页首 附录A：UDDI信息模型 下图描述了构成UDDI信息结构的各个核心信息元素之间的关系 回页首 资源 这里给出了许多规范、文档参考和有用的信息的链接，这些信息可以帮助你理解本技术白皮书。 W3C XML and related recommendations: http://www.w3.org/TR SOAP 1.1 W3C note: http://www.w3.org/TR/#Notes UDDI Web site: http://www.uddi.org UDDI Programmer's API Specification: http://www.uddi.org/pubs/UDDI_Programmers_API_Specification.pdf UDDI Data Structure Reference: http://www.uddi.org/pubs/UDDI_XML_Structure_Reference.pdf UDDI Revision 1.0 schema: http://www.uddi.org/schema/uddi_1.xsd 注释 注释1： 商业实体标识可以包括D&B号，税号，或是其它一些能够让合作伙伴唯一标识一个商业实体的信息类型。 注释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规范的独立实现不可以被强制要求遵循某些特别的约定或需求。因此，如果你对安全性或是信息访问控制策略有疑问的话，需要和实现者进行协商。 作者简介   阮文骏: 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月进行技术中心站点发布。