CN1679026A

CN1679026A - Web服务设备和方法

Info

Publication number: CN1679026A
Application number: CNA038202530A
Authority: CN
Inventors: 理查德·哈维; 蒂莫西·本特利
Original assignee: Computer Associates Think Inc
Current assignee: CA Inc
Priority date: 2002-08-26
Filing date: 2003-08-25
Publication date: 2005-10-05
Also published as: IL166717A0; AU2003265650A1; US20040205086A1; IL166597A0; AU2003268188A1; WO2004019231A9; WO2004019231A3; BR0313879A; CN1678990A; IL166602A0; US20060020585A1; KR20050035287A; KR20050032616A; WO2004019237A8; US20040215476A1; WO2004019232A8; US20040205104A1; WO2004019232A9; AU2003265651A1; BR0313855A

Abstract

一种在安排Web服务时使用的方法，其包括：在用户(User)对象下安排企业服务(Business Entity)对象，以及至少在用户对象、信息库(Repository)对象和前缀(Prefix)之一下安排相应的TModel对象。

Description

WEB服务设备和方法

相关技术的描述

UDDI(统一描述、发现和集成)是一个标准集，这些标准是为了使使用Web服务的应用程序能够快速、便捷和动态进行交互而定义的。UDDI致力于利用互联网和一个可操作的注册中心，为描述服务、发现企业和集成系统服务创建一个无平台无关的、开放的框架。更多信息请参考网站 www.uddi.org。

UDDI注册中心为利用Web服务构建的系统提供有力的支持。图1a简要描述了基本的Web服务和UDDI概念。图1b简要示出了一个Web服务环境下的简化协议栈。UDDI为Web服务信息提供了一个信息库(repository)，且其本身可以作为一个Web服务提供。

UDDI使应用程序可以公布其希望在网上如何交互。每个“Web服务”是一个自描述、自包含、模块化的应用程序逻辑，并可以通过互联网连接向其他应用程序提供一些系统功能。应用程序通过普遍存在的web协议和数据格式访问Web服务，而不必考虑每个Web服务是如何实现的。Web服务可以和其他Web服务结合和匹配，以执行更大的工作流或企业交易。

UDDI标准描述了一个有特殊目的的信息库，此信息库用于管理对Web服务类型、企业组织的描述以及如何调用Web服务的细节。这些标准不需要规定这些标准应当如何实现，也不需要规定这一实现是否应当包含使用数据库、目录或其他形式介质的存储器。

在负责UDDI标准的组织的网站( http://www.uddi.org/fags.html)上，有许多常见问题(FAQ)。其中一个问题是：“UDDI注册中心是否可以构建在LDAP基础上？”在答案里，该网站声称UDDI和目录之间并没有正式的联系。“UDDI规范没有规定注册中心的实现细节。UDDI规范定义了一个基于XML的数据模型和一个用于访问和操控此数据模型的SOAP API集。这些SOAP API定义了一个UDDI信息库表现的行为。只要与规定的行为一致，UDDI实现就可以构建在一个LDAP目录上。迄今为止，所有的UDDI实现都是构建在关系数据库的基础上。”

需要注意的是，诸如X.500和LDAP的目录技术是可扩展的、通用的数据存储，也是最常用的管理用户和资源的关联语言。它们是被广泛采用的良好构建的技术，并被认为是非常稳定和可靠的。

然而，在一个目录上实现UDDI标准(可以在 www.uddi.org上获得)必须解决许多问题。UDDI标准遗留许多重要问题有待讨论，例如：

●UDDI标准定义了许多对象，其中有些对象以层次关系相关联，但是UDDI没有定义一个包括所有对象的层次关系。例如，企业服务(Business Service)对象将位于企业实体(Business Entity)对象之下，绑定模板(Binding Template)将位于企业服务之下。图2举例说明了这一层次关系。企业实体对象用21表示，企业服务对象用22表示，绑定模板对象用23表示。需要注意的是，例如用24表示的TModel对象和这些对象没有层次关系。还有其他一些概念，例如发行者声明(Publisher Assertion)，也不是分层定义的。

●如何有效实现如下需求：允许一个用户只能更改其控制的那些对象。

●如何有效实现如下需求：允许UDDI注册中心是分布式的；

●如何有效实现如下需求：提高可管理性以及搜索和更新的性能；

●如何以一个相对有效的方法描述复杂的UDDI对象。例如，企业实体、企业服务、绑定模板和/或TModel都有复合的重复元素。这些重复元素又可能依次包含更多重复元素。例如，一个企业实体可能包括联系方式(contact)，联系方式又可能包括地址(address)。地址可能包括地址行(address line)和电话号码(phone number)。图13简要描述了企业实体对象中一个相对复杂的对象的UDDI概念。例如，企业实体对象131包括许多属性132，例如授权名称(AuthorizedName)、企业键(BusinessKey)和名称(Name)。名称有一个或多个名称字段133，例如“文本(text)”(这一字段也可以隐藏在“名称”本身里)或“语言”。可以有一个或多个这样的字段133；

●如何提供一个相对迅速的搜索方法来搜索包含在重复字段中的特定项；

●如何按目录对象的层次表示UDDI信息和需求。

●如何以一种有效的方式来管理UDDI对象及其所有相关信息的删除。以及

●由于目录存储介质是有限的，在搜索操作中如何优化中间搜索结果集合的构建，从而使得目录访问和迭代存储的操作次数最少。实际上，目录条目可以按任意顺序存储和返回，目录结果也可能太大而不能排序。

●如何以有效的方式表示有关发行者声明的数据。

●如何有效实现发行者声明，特别是findrelatedBusiness方法的实现。

●如何有效实现通过关系搜索发行者声明。

●如何管理发行者声明的有效性。

●如何限制与某一企业实体相关的声明的创建和删除只能由企业实体的所有者执行。

●如何如UDDI标准定义的那样有效管理相关的属性集。

●如何定义属性和对象以提高搜索的性能。

目前已提出各种不同的UDDI机制。但是没有一种机制能够解决至少上述问题。例如，有一种计划(schema)提供了一种过于简单的UDDI对象到目录对象的映射，而没有考虑到复杂性和优化以获得有效的商业实现。在这一计划里，许多UDDI服务(尤其是find_series)的实现也不明确。

例如，图14简要示出企业实体里一个相对复杂的对象的Novell表示。企业实体对象141包括许多属性142，每个属性都有一个“类型(type)”和“数值(value)”。如图所示，AuthorizedName的值为“bill”，BusinessKey的值为“890.obale.890......”，Name有多个值143，144，即

En#CA

IN#CATS

UDDI(图13)和Novell(图14)实例表示不能视为Web服务的有效表示。

因此，必须讨论上述一般问题和其他一些问题，以提供一个相对可扩展的、有效的和可靠的基于目录的UDDI实现。

发明内容

一种在安排Web服务时使用的方法，其包括：在用户(User)对象下安排企业服务(Business Entity)，以及至少在用户对象、信息库(Repository)对象和前缀(Prefix)之一下安排相应的TModel对象。

一种安排Web服务时使用的包括计算机可执行的计算机记录介质，其包括：在用户(User)对象下安排企业服务(Business Entity)的代码；及在用户对象、信息库(Repository)对象和前缀(Prefix)中至少一个对象下安排相应的TModel对象的代码。

附图说明

参考优选实施例的以下描述并结合附图，可以更好地理解本发明更多的对象、优点和各个方面：

图1a简要示出了一些Web服务和UDDI概念；

图1b简要示出了一个Web服务环境下的简化的协议栈；

图2简要示出了根据相关技术的层次关系；

图3简要示出了根据相关技术的一个目录服务模型；

图4简要示出了根据本发明的一个实施例的使用X.500目录技术实现的UDDI服务模型的基础组件；

图5简要描述了根据本发明的一个实施例的服务投影(ServiceProjection)；

图6简要描述了根据本发明的一个实施例的绑定模板和TModel之间的关系；

图7简要描述了根据本发明的一个实施例TModel如何在两个实体间建立关系；

图8简要描述了根据本发明的一个实施例请求添加一个发行者声明的逻辑表示；

图9简要描述了根据本发明的一个实施例构建UDDI数据对象的逻辑表示法；

图10简要描述了在用户对象之下设置企业实体对象；

图11简要描述了在用户对象之上设置域(Domain)对象；

图12简要描述了根据本发明的一个实施例的计划的概貌；

图13简要描述了根据相关技术的企业实体中一个相对复杂的对象的UDDI概念；

图14简要描述了企业实体中一个相对复杂的对象的Novell表示；

图15简要描述了为表示企业实体中一个相对复杂的对象而根据本发明的一个实施例引入层次关系；

图16简要描述了根据本发明的一个实施例的绑定模板的分层子结构；

图17简要描述了一个绑定模板子结构的展平(flatten)和/或合并；

图18是一个能够实现本发明各个方面的计算机系统的框图。

具体实施方式

在描述附图中示出的本发明的优选实施例时，为了清楚起见，采用了专用的术语。然而，本发明并不局限于如此选择的特定术语，可以理解每个特定的元素都包括所有以类似方式操作的等同技术。

图18示出了一个可以实施本发明的方法和系统的计算机系统的例子。本发明的系统和方法可以以运行在计算机系统(例如大型机、个人计算机(PC)、便携式电脑、服务器等)上的软件应用程序的形式实现。软件应用程序可以存储在一种可由计算机系统在本地访问的可记录介质(如软盘、压缩磁盘、硬盘等)上，也可以存储在远程，本地计算机系统可以通过一种到某一网络(如局域网或互联网)的硬线或无线连接来访问。

一种可以实现本方法和系统的计算机系统如图18所示。此计算机系统180通常包括一个中央处理单元(CPU)182、存储器184，例如随机访问存储器(RAM)，一个打印机接口186，一个显示单元188，一个局域网(LAN)数据传输控制器190，一个LAN接口192，一个网络控制器194，一个内部总线196和一个或多个输入设备198，例如键盘、鼠标等。如图所示，系统180可以通过一条链路202连接到一个数据存储设备200上，例如硬盘。

下面概括说明本发明的实施例的一些显著特征及其能够提供的一些优点。

根据本发明的一个实施例，在用户层上创建一个信息库层，使得每个信息库可以位于不同服务器上。这个信息库层包括一个或多个目录节点，所有节点共同组成目录前缀。这也就是众所周知的信息库的“域”或“名称”。其优点在于为存储关于一个域的信息提供了一个单一的场所。这一节点的名称表示这一目录的前缀。

可以创建一个用户对象来存储描述UDDI帐户的数据。其优点在于为存储一个用户/帐户的信息提供了一个单一的场所。

企业实体(Business Entity)对象安排在用户(User)对象之下，企业服务(Business Service)对象安排在企业实体对象之下，绑定模板(Binding Template)对象安排在企业服务对象之下。其优点在于一个在用户对象层之上的信息库或“域”层能够发布多个信息库或使这些信息库逻辑互连。域层可以设置在多个层面中，例如不同国家(AU、US、EP等)或按大洲来组织。

另一个优点在于此特性可以利用一个X500目录的分布式特性来实现。例如，要实现此特性，可以把一个“世界(World)”或“公司(Corporation)”节点设置在虚拟目录树的顶部，在每个UDDI子树(UDDI命名空间)的顶部则设置一个名称唯一的节点。这些“节点”前缀尽管对用户来说是不可见的，但是它们使一个UDDI信息库可以对目录分布进行均衡。

根据本发明的一个实施例，企业实体对象可以作为用户对象的一个孩子(child)。在企业实体、企业服务和绑定模板层次之上有一个用户/帐户使每个用户拥有其自己的子树。这一特性可以提高可管理性和安全性。易于限制每个用户只能修改和/或控制其自己的子树。这一特性也可以通过使用目录子树的搜索操作提高性能。

根据一个实施例，一个用户定义的TModels可以作为此用户对象的孩子，从而易于实现安全性。由于用户只能修改和/或控制其自己的子树，这一特性可以提高可管理性和安全性。这一特性也可以利用目录子树的搜索操作提高性能。

本发明的一个实施例描述了一个使用X.500/LDAP目录技术的UDDI环境的“映射”。特别地，已知X.500和LDAP目录技术的分层结构适合UDDI环境。如果仔细设计附加元素(如用户对象)可以使此层次更适合UDDI环境的需求。

在本发明中，术语目录(Directory)包括X.500、LDAP和类似的技术；术语“用户(Users)”被理解为也包括帐户(Account)，反之亦然；术语“信息库(Repository)”被理解为也包括“目录前缀(Directory pre-fix)”、“域(Domain)”和/或“节点(Node)”，反之亦然。

Web服务最初被设计为企业、合作伙伴、消费者、供应商等组织之间的服务。在这一上下文中，UDDI被设计为这些组织提供的服务的单个信息库。

如今，Web服务和UDDI对于在一个企业内部集成组织内部的应用程序来说显然是有用的。Web服务和UDDI显然也可以用于集成一个特定商家的产品集内的产品。其在商业领域之外的领域，如政府部门、大型教育学院及许多其他非商业实体的场合，也是有用的。

尽管以下描述是针对一个企业，但是其在任何类型的环境下都有等价的适用性和在上述环境下的特殊的适用性。

企业UDDI注册中心可以是一个在企业内部开发的服务，为内部消费发布信息和服务。而且，可以调节企业UDDI服务以提供其他功能，譬如分布式应用程序的配置发现。

Web服务正在被在企业内部和合作伙伴之间快速便捷地集成商务过程这一愿望所驱动。有效使用Web服务的一个组件是一个公共的UDDI注册中心，该注册中心使软件可以通过互联网动态发现和连接到合适的服务上。Web服务也承诺能够在企业内部集成商务过程。此时，UDDI注册中心成为企业基础设施(例如一个重要的企业应用程序)的一部分，从而可以提供最高层次的安全、性能、可靠性和可管理性。目录技术提供了一个支持企业UDDI注册中心的严格要求的理想基础架构。

企业UDDI注册中心可以定义为一个支持UDDI规范的Web服务，但除此之外还定义了开发的四个领域。这些领域包括：限制只能对授权用户的访问的安全性(SECURITY)，支持大型开发的分布性(DISTRIBUTION)，适用于真实产系统的可管理型(MANAGEBILITY)以及满足服务层次协议的可用性(AVAILABILITY)。

有力的安全性对某些企业开发者来说是一项重要需求。公共的UDDI注册中心只是为了帮助任何人发现可用的服务这一目的而存在的。一个UDDI注册中心却只是为了让合适的人发现这些服务而存在的。这是一个重要区别。

互联网UDDI注册不适合用来在企业内部开发Web服务。例如，与薪金系统或雇员津贴管理程序交互的Web服务的定义绝不可能发布在一个互联网UDDI注册中心。

安全需求也意味着即使是一个内部使用的UDDI注册中心也要提供强访问控制。这是因为一个UDDI注册中心本质上说是要提供一个可以做什么和如何去做的指南。一个UDDI注册中心可以提供任何可获得的Web服务的商务级描述，并能定位到完整定义了到那些服务的程序接口的WSDL。这为应用程序开发者和黑客都提供了一个高效工具。

因此，应当限制对财务敏感的系统或机密系统(例如医疗记录)的接口定义的访问。甚至在开发组织内部，也应当限制某些特殊Web服务的信息只有授权用户才可以访问。

在企业内部使用不安全的UDDI注册或通过外部网络选择商业伙伴，可能是相当冒险的。由于自由下载工具的存在，具备很少专业知识的人也可以访问和使用Web服务。任何实际的企业解决方案都能够实现一个标准的UDDI服务，该服务能透明地控制对有关Web服务的信息的访问。

考虑到分布性，在许多场合下，UDDI注册的初期开发都是小规模的。然而随着Web服务需求的增长，大规模开发变得越来越普遍。而且，注册的使用和开发将随着UDDI注册的新功能的发现而加速。

在地理上分布式的组织中更大规模的实施和使用将驱使单个组织内实施多个UDDI注册。向分布式注册的演变使得任何单独的注册中心能动态地和其他能提供它们的请求的服务的注册中心交互变得至关重要。一旦建立，注册中心之间的通信应当可以越过防火墙延伸到信任商业伙伴的注册中心，甚至是互联网UDDI注册中心。

考虑两种基本方法来解决注册中心之间的通信需求。一种方法是复制(REPLCATION)，即相同的条目命名空间存在于多个服务器上。另一种方法是分布式(DISTRIBUTION)，即相互连接的服务器有不同的条目命令空间，但是按一个逻辑服务进行操作。

虽然这两种方法常常被误认为是相似的，但实际上它们是相当不同的。

在复制方法中，信息在每个需要查看的服务器上复制。虽然这是一个相对简单甚至过分简单的解决方案，但是会产生同步更新的需求，而且随着注册的数量和注册内容的增长，这肯定会导致网络拥塞。复制技术最适合服务器数量较少、信息量低且变化不频繁的环境。对于企业开发，复制对维护网络容错备援(fail-over)的备份信息库最有用。利用复制技术，保持物理上或功能上分布式的服务器之间的同步是非常困难的。

在分布式方法中，信息在每个参与的服务器上用逻辑表示，但是只存储在一个注册中心。查询只在必要时才传送给其他注册中心。于是返回的信息可以保证是最新的。这就提供了一个更新的关键点，从而消除了复制技术中的同步和占用带宽的问题。真正的分布式被视为是服务器间可扩展连接的一个解决方案。

对一个企业UDDI注册中心来说，分布式通常在两个场景下使用。一种是用于具有物理上分离的办公室的组织，其中每个办公室生成新的UDDI条目和使用UDDI服务。虽然运行一个单一的集中式的注册中心也是可能的，但是带宽限制和时区差异常常使运行这样一个注册中心变得相当困难，甚至无法工作。

分布式注册中心提供了一个灵活的、可扩展的解决方案。在这一场景下，每个参与的办公室有一个独立的注册中心，每个注册中心把其他注册中心作为自身上下文的一个逻辑组成部分。注册服务考虑所有连接细节，消费者不必考虑地理位置问题。

第二种场景是一个企业必须把其内部UDDI系统连接到一个信任伙伴的UDDI系统或公共互联网注册中心上。特别地，在连接到公共注册中心的情况下，复制会产生问题。互联网注册中心可能不愿意把其注册中心的一部分复制到企业的内部注册中心里，分布式方法再次可以解决此问题。目前还没有分布式UDDI标准，有关复制的提议也相当复杂。应当有一种不必修改标准却能提供UDDI分布式方法的优点的解决方案。

考虑到可管理性，作为一个执行企业内至关重要功能的组件，UDDI应当满足性能和可靠性要求，而不仅仅是一个对开发者来说使用便利的设备。客户端的读取访问将是最频繁且最费时的操作。性能被优化，以使得吞吐量最大，查询的响应时间不会因搜索复杂度的提高而有太大影响。支持UDDI注册的数据存储应当具备工业实用性和完全支持交易和自动恢复。而且，UDDI服务器应当具有高度可用性并支持诸如网络容错备援(fail-over)和热备份等特性。系统管理员应当有使UDDI注册中心易于维护、监控和控制的能力。这些能力包括能改变控制、规则和设置而不会引起服务掉线的动态配置(DYNAMIC CONFIGURATION)、能实现高可用性的在线备份和调整(ONLINE BACKUP AND TUNING)、停止注册中心的“搜索(trawling)”和防止拒绝服务攻击的管理员级控制(ADMINISTRATIVE CONTROLS)、通过SNMP或其他类型报警机制的监控(MONITORING)、为安全、统计、查询和信息更新而对独立日志文件进行的审计和诊断(AUDITING ANDDIAGNOSTICS)，以及支持复制、分布式和路由的配置(DEPLOYMENT)选项。

已经提出了许多基于开发者的UDDI注册。这为小型开发队伍提供了有用的功能，但是并不是真正的产品级的系统。Web服务开发正在迅速增长，企业级注册必须能相应地迅速扩展以支持不断增长的Web服务开发。

UDDI注册提供了一种服务。这一服务将依赖于许多应用程序。在在线商务场合下，服务永远存在可能是很重要的。例如，UDDI注册可能必须提供99.99％可用的服务级协议。为了实现这一级别的可用性，UDDI注册可以在两个或更多的机器上复制，并提供一些机制保证这些机器同步，从而一旦某一机器不可用时，任何入查询可以自动路由至一台可用的机器上。

如上所述，UDDI可以看作是电话目录服务的有效类比。这样，信息存储的目录模型就是完美构建一个UDDI注册中心服务的基础架构。目录模型已经按照各种基于目录的服务的特定需要演变和发展，具备企业级开发所必需的安全性、可扩展性和可靠性。

在应用程序架构中，大多数上述条款都是在服务层实现，而不是在数据存储层实现。关系数据库(RDBMS)是许多不同类型的应用程序构建其上的工具包。RDBMS实现致力于提供可靠的数据访问功能，而不是终端应用程序所需要的更多服务功能。

如图3所示的目录服务架构描述了服务层31同其他组件的分离。把接口函数封装到一个服务层31中使服务设施组件可重用。Web服务器就是最好的实例。一个Web服务器提供各种功能(HTTP访问、CGI处理等)的集合，这些功能共同组成一个足以内嵌于一个独立组件的服务。同样地，目录服务模型已经可以提供某一特定类型的应用程序需要的功能。目录技术在认证和授权领域为许多至关重要的应用程序提供了支撑。

UDDI可以认为与另一种目录技术类似。利用目录技术可以解决许多实现UDDI引起的问题。例如，目录技术对于对效率要求极高的查找和搜索操作(这一操作在UDDI电话目录操作中非常普遍)来说是最优的。

前面已经提及，如果要在企业中成功开发，UDDI服务应当提供强安全性、分布性和管理功能。这与已经内嵌于企业级目录服务解决方案的属性正好吻合。

一种构建企业UDDI注册的方法是扩展现有的目录基础设施，这一设施已经在高性能的、实际应用程序中应用和测试。

目录服务体系结构为实现企业级UDDI注册提供了一个最佳工具。二者结合可支持成功实现所必需的性能。图4简要示出的UDDI服务标识了可以为这一基础设施实现的组件。UDDI语义桥(SEMANTIC BRIDGE)41是一个连接UDDI的SOAP实现42和目录44的LADP接口43的服务组件。目录44描述信息访问，并支持安全控制、分布式机制和管理员功能。RDBMS45提供下层物理数据管理、交易完整性以及备份和恢复机制。

UDDI注册产品可以直接在RDBMS技术上构建。虽然关系数据库在许多方面都十分有用和强大，但是它们本身不能满足目录处理的需求。

利用RDBMS或其他下层数据存储系统，通过拼凑构建一个目录型应用程序是可行的，但是这可能并不是最有效的方法。

另一种可选方法是使用目录服务模型来描述UDDI注册和提供这一特殊类型应用程序所必需的功能。现代工业级目录服务甚至可以提供更多UDDI注册中心需要的功能。UDDI注册中心可以看作一个具有专门通信和API的目录服务。在目录上描述UDDI服务可以提高必不可少的安全性、分布性和管理功能，而不必修改UDDI标准。

精心设计这一数据表示法有益于实现UDDI信息库所必需的功能和性能。

以下描述主要涉及各种不同的UDDI概念。有关这些UDDI概念的进一步详细描述可以参考UDDI标准规范( http://www.uddi.org/specification.html)。

按目录的说法，计划(schema)是对目录里存储的数据元素及其如何联系在一起的描述。其包括对每个可能属性(一个属性包括一个数据块)的描述、各种不同对象(一个对象是一个属性集)的描述、以及可能的对象层次的规范。在这一规范中使用的特殊的计划符号是国际计算机联盟公司的产品eTrust目录所使用的，eTrust是国际计算机联盟公司(Computer Associates International Inc.)的产品名称和注册商标。当然，也可以使用其他计划符号。

本发明描述了一个把目录作为数据存储器实现UDDI注册中心的计划。这个计划涉及许多概念。也使用了许多技术来提高UDDI实现的操作性。以下是其中一些概念的概括描述。对这些概念和技术更详细的描述将在后面阐述本发明的实施例时给出。

本计划被设计为提供最优化的操作。本计划的设计包括属性、对象类、实体和层次的定义，按照提高操作性的方式来实施。本计划的设计至少在安全性、性能、管理和分布式方面具有显著的优点。

下面描述本系统的层次关系。X.500目录内部支持分布，因此UDDI层无需任何编码就可以提供一个分布式UDDI信息库。一个层次分割信息库内容。本计划的(可选的)域层使UDDI层编码可以透明地把层、每个域条目和其下所有条目置于独立的目录服务器上。图11描述了本发明这一方面的实施例。更多细节将在后面给出。

根据本发明的一个实施例，用户对象位于企业和TModel对象之上。用户对象为用户相关信息的提供存储空间。它也为用户公开的所有数据提供定位点。图10描述了本发明这一方面的一个实施例。更多细节将在后面给出。

在这样的域/用户层次系统中容易实现安全性。UDDI实现应强制用户在数据对象子树之上进行控制。

可以搜索用户控制的条目。利用用户对象之下的子树搜索能够增强搜索被这一用户控制的条目的能力。

例如，通过指定一个在绑定模板中出现的TModel来发现企业是可行的。这等价于“通过找到其一个(或多个)孩子来发现x”。换句话说，查询可以是“找到所有提供某种服务的企业，其中这一服务具有参考这一TModel的绑定模板。”这样的查询可以通过找到后代对象的DN(特异名称)和丢弃不需要的层次来实现，从而生成企业实体的DN。按这种方式也能消除重复。这一查找特性是因本发明体系结构的层次性而产生的。

可以利用某一对象唯一的属性进行搜索。这是最优化的方法，具备两个优点：简化搜索的书写，通过排除“弱”子句达到较高性能。一个“弱”子句是返回大量条目的过滤器的一部分，或者是指许多条目都包含的一个属性。对一个企业实体来说，每个名称(Name)使用相同的属性明这一设计在搜索时将有两个选择：把对象类包括在对象类或过滤搜索结果。前者只有在企业名称只有一个唯一的对象类时是可行的，即使这样，对象类也是一个弱子句，会导致更多开销。后者则意味着需要额外的代码，潜在地将返回一个比期望结果大得多的结果列表。

例如，有一个名为“McKenna’s Testing Services”的公司，它提供了广泛的Web服务，其中所有服务的名称里都包含“McKenna’s”，如果用名称里包含“McKenna’s”这一条件来搜索一个企业实体就会返回包括所有这些服务在内的中间结果。这些中间结果可以消除，但是这一处理将降低性能。

能够在搜索时指定一个属性名且该属性名唯一标识搜索的对象类是最好的。继续上例，如果我们可以指定：(euBusinessEntityName＝McKenna′s^*)则搜索将简单得多。

这样的设计可以产生有效的强搜索，因为它们只搜索期望的区域。强搜索包括返回少量条目的搜索。目录可以检索euBusinessEntityName属性并根据检索返回结果，从而提供良好的性能，避免处理不必要的中间结果。

对简单查询来说，这样的设计意味着搜索一个企业实体名称只是一个单一的子句，而在其他设计中则可能需要复合句。不妨假设，如果名称属性叫作euName，那么企业实体名称对象就叫作euBusinessEntityName，则将产生如下搜索：

(&(euName＝McKenna′s^*)(oc＝euBusinessEntityName))

如果所有名称都存储在相同的对象类里甚至有更简单的设计。这意味着搜索将再次产生(euName＝McKenna′s)，但此时我们将费力地读完所有名称的结果，试图找出那些有一个父对象是企业实体的结果。最后这种设计的性能可能比较差，编程也稍微复杂些。

阴影(Shadow)属性用于大小写敏感。利用单个索引提供大小写敏感和大小写不敏感是很重要的。一种方案是大小写敏感地检索，则将大小写敏感地对结果进行扫描。这里提供另一种解决方案，即对原始数据进行大小写敏感的检索，并(在相同的数据存储的地方)增加另一个大小写不敏感地检索的属性。这样就只需根据查找限定句选择合适的属性进行搜索。

在这一设计里，每个属性只有一个值。这能提供有效检索、更高的性能和更强的搜索。

使用多值属性可能会产生二义搜索，即可能产生不合直觉和无意识的搜索结果。假设有一个多值的数字属性，名为‘n’，有个包含该属性的条目的值是2和5，则对于(&(n＜3)(n＞4))这样的搜索将返回这一条目，而这并不是事先能很容易预测到的。

单值属性是强搜索使用的一种技术。强搜索是指可以通过索引排除大部分候选结果。强搜索是实现高性能的关键。

别名(aliases)用于服务投影。这是用X.500目录存储数据的一个显著优点。服务投影可以通过X.500的别名巧妙地表示。其主要优点在于保证数据完整性。别名访问原始数据，因此原始数据的任何变化都可以通过别名立即反映出来。如果目录实现支持别名完整性，那么当删除原始数据时，别名自动消失而不会引起额外的工作。

发行者声明(Publisher Assertion)是UDDI标准中定义较不清晰的元素之一，必须精心设计。不适当的实现可能容易导致低性能。

由于发行者声明最常用的是find_relatedBusiness API(此API用于搜索所有和某一特定企业实体有关的已建立的发行者声明)，因此设计最好把每个声明置于其引用的企业实体之下。

通过计算声明的状态并将之存储在声明对象里，可以把搜索限制在已建立的发行者声明中。这意味着返回的结果不会包含将要删除的伪引用。

把关系对象存储为辅助类使得搜索可以排除任意具有不期望的关系的声明。如果关系存储为一个子对象，则不能生成一个能同时描述关系和声明建立状态的单一的搜索条件。

UDDI键存在时可用于命名。UDDI为许多重要的对象类定义了键(keys)，且这些键必须保证是唯一的。这意味着这些键可用作对象的命名属性。把UDDI键作为命名属性意味着不用考虑命名冲突问题，而如果使用缺省名称作为企业实体的命名属性必然要求考虑这一问题。

UDDI键不存在时也可提供键来命名。并非所有UDDI对象都有已定义的键，譬如发行者声明。本系统利用和UDDI定义键相同的算法为这些对象提供了一个键。这一重用思想意味着为其他对象编写的代码和结构可以被重用。

如果一系列UDDI对象是另一对象的孩子，则这些子对象的顺序是很重要的(例如地址行)，分配给子对象的键值应当按单调递增的顺序排列，于是对键值排序就可以产生期望的顺序。这能简化获得期望顺序的过程。

在实际应用中，键值应当按little-endian方式变化。也就是说，键值最左边的字节变化最快，这是因为在作为数据库的X.500目录里这能产生最佳检索性能。

UDDI标准在一些主对象类型里定义了许多子结构体。在许多场合，这些子结构体是可选的，并可能重复(在同一对象里可能出现零次、一次或不止一次)。一个简单的例子是名称子结构，其包括一个字符串(名称)和一个语言标识符。X.500计划定义不支持结构体属性，因此子结构体的映射不能立即清晰。有几种方法可以在X.500里实现这些子结构体。

一种方法是利用某种分隔符划分不同元素从而把子结构体里的所有组件链接成单个属性。这可能不是最优的设计，因为其丧失了单独检索或搜索这些组件的能力，且增加了处理这些数据的复杂度。

在本系统中，选用特殊的设计来表示子结构体，从而使性能和管理性最优。本发明给出的设计使用一种或多种技术在目录里表示子结构体。这些技术可以分成三类：

一种技术是把许多子结构体作为一个子对象处理。名称是最好的例子：企业实体名称存储为企业实体的孩子。另一个例子是描述，其中单独的企业描述是企业实体对象的孩子。图15给出了本发明这一方面的实施例的描述，更多细节将在后面给出。

另一种技术是展平/合并。当至少和另一个对象有关系时，属性可以合并成一个单个对象。此时，由于两个对象合并成一个对象，所以称层次被展平。由于新的对象包含合并对象的属性并集，所以称新对象是合并的。最好把关系对象的内容提升为父对象。

例如，图16简要描述了一个UDDI关系图。图17简要描述了一个目录层次图，其中目录层次由展平的UDDI对象构成。

作为解释，图16描述了关联对象162和对象163的对象161。

依据本发明的一个实施例，如果存在一一对应关系，则“孩子”的层次可以提升。换句话说，其对应的那部分层次可以折叠或展平，对象可以合并。图17里简要描述了这一结果。父对象171包括内容A1、A2、An以及一个或多个孩子，子对象9n包括内容B1、B2、Bn、C1、C2和Cn。

第三种技术是分裂。例如，在某种特殊场合(OverviewDoc子结构体)，子结构体包含一个不重复的元素和一个重复的元素。不重复的元素(OverviewURL)可以转移到父对象中，而重复元素可以作为一个子对象。

本发明的另一方面是管理。删除一个TModel虽然隐藏了find_TModel但是并没有从信息库中去除。因此，要实现对TModel的正确处理，可以使用一个隐藏标志。出现此标志说明一个TModel(或用户对象)是隐藏的。没有此标志则说明不是隐藏的。这是许多TModel都要面对的问题，所以这种方式是高效的。在非隐藏对象里不占用额外空间，也不使用检索。目录将只检索那些有隐藏属性的条目。这也意味着对非隐藏TModel的检索将更快速有效。

X.500目录用作数据存储区时不能存储空值。例如，对象中不存在的一个(可选)值不会存储在目录里。这使存储空间的使用更加有效，搜索更加强大。任意对某一属性的搜索只需考虑那些该属性有数据的对象。

本发明的数据层次满足UDDI标准的目的。当一个删除UDDI对象的请求到达时，其直接映射为删除目录里的一棵子树。例如，删除一个服务包括删除它的名称和描述及其所有绑定模板。这些全是目录中该服务条目的孩子。因此，本系统删除此服务条目下方的子树。这一实现简单而有效。

域(Domain)是一个表示分层子树的根部的名称。在X.500术语中，域被认为是一个上下文前缀。在LDAP术语中，其被认为是一个后缀。给定UDDI信息库，域名允许在信息库中使用(在X.500意义上)真正分布式的数据。UDDI标志只支持复制。通过域节点，本系统可以使用对应用程序透明的目录分布式设备。

例如，假设一个企业在内部开发UDDI，但是有两个开发站点。通过此设备，他们可以在每个站点开发一个分布式UDDI服务器，使每个站点都可以透明地查看在两个注册中心上发布的条目。

本系统的一个优点是“免费”分布式。例如，UDDI服务器不必作任何额外工作且目录系统可以有效地把孤立的信息连接在一起。

UDDI标准里没有说明如何存储用户信息。通过创建用户对象，所有与某一用户相关的信息都可以存储在单个对象里，且该对象可以用作包含次用户发布的所有对象的子树的根。这使安全性的定义更加简单。例如，如果考虑中的对象(可能是企业、服务甚至是TModel)位于该用户的用户对象之下，则此用户可以控制它。

UDDI定义了包含重复元素的对象。出于性能、可搜索性和可管理性方面的考虑，这些重复元素可以用子对象来表示。

把重复数据结构存储为子对象使得数据可以在目录中有效地表示，同时每个字段都可分别用于搜索(和被检索)。

例如，企业实体名称可以存储为企业实体对象的孩子。另一个例子是企业描述可以存储为企业实体对象的孩子。

这类系统的一个优点是能够搜索一个名称，且该条目的DN给出了此名称所属对象的DN。

UDDI定义了冗余“容器”节点(只包含孩子子结构体而没有属性的UDDI结构体)。这些节点可以删除，因为可以根据查询结果以相对低的代价构建它们。在某些情况下，属性可以从一个孩子节点提升为父节点，从而把当前冗余的子结构从目录表示法中删除。

例如，tModelInstanceDetails由于不含属性所以在目录计划中没有对其进行描述。目录计划没有描述InstanceDetails而是把其属性提升为tModelInstanceInfo的父类。，其孩子的属性是OverviewDoc。目录也没有描述分类和标识口袋(bag)，它们的内容作为口袋所有者的孩子。

本系统的一个优点在于减少了目录里的条目数。特别是使DIT的深度最小化，从而可以提高性能。

图12简要描述了对应于本发明一个实施例的层次结构。假定有一个或多个域或前缀121。在每个域121下方，可能有一个或多个用户122。在每个用户122下，可能有一个或多个TModel 123和一个或多个企业实体(BE)124。在每个企业实体124下，可能有一个或多个发行者声明(PA)125、一个或多个企业服务(BS)126和一个或多个服务投影(SP)127。在每个企业服务(BS)126下，可能有一个或多个绑定模板(BT)128。还可以根据某些特殊实现使用别名。例如，服务投影对象(如图12中的三角形)可能源于企业实体对象的别名。

把本发明作为整体来阅读后，图12描述的计划设计的优点将十分明显。

把发行者声明放置在它们引用的企业实体之下是因为它们在find_RelatedBusinesses调用的上下文中使用最频繁，其中find_RelatedBusinesses调用指定了一个企业键并通过发行者声明查询所有与其相关的企业。本系统定位指定的企业，然后读取其下方所有(已建立的)发行者声明。这是一个定位相关声明的快速而有效的方法。

其一个优点在于搜索快速而高效。而且容易维护数据完整性。例如，在删除一个企业时，任何发行者声明也会自动删除。

TModel可以被发布其的用户改变(或撤销/隐藏)。把它们置于描述用户的条目下方使安全性更容易控制。例如，如果一TModel位于该用户条目的下方，则用户可以修改之；反之，不能。

详细说来，如果企图修改TModel的用户的DN(特异名称)和此TModel的DN相匹配，那么此条目就可以被该用户修改；反之，不能。可以使用目录或UDDI服务器作此决策(如果此DN不存在则是命名异常)。

当从信息库中删除一个对象时，与此对象相关的信息也被删除。利用本发明的实施例的分层设计可以大大简化这一过程。在删除对象时，此对象下方整个子树都被删除，从而可以删除所有(且一般只有)相关信息。删除子树可以通过由底至顶的方式执行。每个条目只有当其所有子树被删除时才能删除。这可以通过按DN反序列出所有孩子来管理。这就可以保证在删除父对象前删除其子对象。

其一个优点在于用序列表方式代替了更复杂的递归方式。而且，它相对简单并能充分利用内存。当子树中的所有条目都按照DN排序，且删除按照相反的顺序执行时，就可以保证在删除父对象前删除其子对象。

例如，在删除一个企业服务时，本系统删除所有与之关联的绑定模板、TModel实例信息和各种相关的分类信息。所有这些信息都可以通过删除以该企业服务为根的子树来删除。

因为本计划的设计使用分层结构，一个对象DN就揭示了一个对象的所有者和控制链。需要注意的是此推论有赖于命名属性的精心选择。

其一个优点在于可以减少搜索数或为了搜集信息而读取的次数。例如，由于搜索结果是子对象(例如名称)，每个条目的DN揭示了父对象(例如企业实体)和所有者帐户。

例如，一个企业服务的DN反映了其所属企业和控制其的用户。

目录不保证对结果排序。在处理一个复杂结果(例如一个企业实体及其企业服务，还有它们合适的名称和描述)时，可以通过把搜索结果按DN排序来简化输出结果的构造。这能组织结果从而使输出结果的构造变得相对简单。每个对象在其子对象前构造，从而便于把其子对象置于其下，于是对企业的搜索结果就在其服务之前组织起来。一个对象的所有孩子在下一个相同类型的对象之前出现，一个企业的所有服务在下一个企业之前出现。这可以通过递归来构造，因为每层都做同样的事。

本系统的一个优点在于遍历构建UDDI结构必需的原始条目列表的次数最少。

例如，排序后，企业的搜索结果A之后紧接着是其第一个服务AA，和此服务的名称，然后是A的第二个服务AB及其名称，然后是另一个企业B。

也可以对子对象执行搜索。例如，有如下一个常用的搜索请求：“通过找到x的一个(或多个)子对象来找到x”。例如，可以通过指定在绑定模板中出现的一个TModel的搜索来找到一个企业。换句话说，此查询为“找到所有满足如下条件的企业：其服务包含一个参考这一TModel的绑定模板”。这些查询可以通过查找后代对象的DN并去掉对该企业实体DN的生成无关的层次来实现。这也能去除重复。这一搜索方法产生的部分原因是本发明实施例的分层结构。

使用授权的唯一键值令问题简化。可以通过单个键值搜索条目信息库，且唯一性可以确保或者没有搜索结果(如果该键值不存在)，要么只有一个搜索结果(如果键值存在)，而无需谨慎地把搜索限制在父对象的范围内。这就可以利用目录提高性能，因为它充分利用了数据库索引。

本系统的一个优点在于使用速度最快的目录查询。另一优点在于如果给定对象引用自其他对象则担保唯一名称可能很重要。

大多数索引系统都具有数据间非独立的性质。如果数据是“littleendian”(最左边部分变化最快)则数据趋向于被扩展，因此索引可以使性能最优。反之，如果数据是重复的，索引可能不是非常有效。展示“little endian”性质的UUID(通用唯一标识符)算法被采用。此算法的优点在于使目录性能最大化。

键可以添加到导出对象。当可重复的数据元素组成子对象时，就必须添加一个命名属性，使之构成其DN的最后一部分。在一个目录里，命名属性不同于其同胞对象，因为同一个父对象不存在两个名称相同的子对象。

有两种键可以使用。对于顺序无要求的子对象，可以使用UUID，因为它们保证是唯一的。在顺序比较重要的场合，则可以使用具有单调递增属性的键来保证顺序。

在UDDI标准里，一个企业实体可以提供两种服务：一种是其控制的服务(在信息库里通过子对象来描述)，另一种是其提供接口但实际上由其他企业实体提供的服务。后者在本发明的UDDI信息库里通过别名来描述。别名精确地提供准确的特性。例如，如果原始对象(服务)被其所有者以某种方式改变(可能增加了一个绑定模板)，则通过别名引用的对象也会“改变”。而且，在企业实体下方搜索任意服务能生成真实服务和别名服务。

例如，别名可以用于服务投影，其中一个企业可以指向一个在其他企业下定义的服务。

其优点在于补充别名可以自动提供“可替代名称”的功能。而且，如果目录支持别名完整性，那么删除原始服务时其任何投影也会自动删除。

在UDDI标准里，有许多地方我们并不愿意直接引用其他对象而希望通过中间步骤实现——例如在TModel实例信息情况下，或在一个发行者声明里引用企业实体时。在这些情况下，别名可能使代码复杂。因此本系统用对象的引用代替别名。因为依据此实施例，本发明保证每个对象有一个唯一的键，于是该键表现得就像一个引用，有时其被认为是一个“外来”键。

属性分组可以通过扶助对象类来实现。处理发行者声明时必须能够利用如下三个唯一标识发行者声明的属性来定位一个发行者声明：两个企业实体键和二者间的关系。然而，关系被描述为一个关键字索引，其本身有三个属性：TModel键、键名称和键属性。一种方法是把此关系存储为发行者声明的一个子对象。但是这不允许对特定的发行者声明做最有效的搜索。通过让关键字索引把辅助对象类引入发行者声明条目，就能在单个搜索中查找五个属性，从而能准确地提取出需要的发行者声明对象。

本计划的一种设计可以使用常规的面向对象的设计技术，譬如可能导致所有关键字索引具有相同的属性名称。然而，这一设计使解析更加困难、代价也更高。例如，应当避免把企业实体分类关键字索引和TModel分类关键字索引混淆。这也使得过滤器有必要包含对象类术语且这些术语是弱的(即在信息库里具有高度重复性)。

例如，为每个不同的关键字索引赋予一个不同的对象类和不同的属性名称，则搜索任意一个特定属性都必须包含该对象类。这也意味着目录服务器可以构建一个检索，此检索里只有期望的特殊类型的条目。这样的检索将更小，从而也更快。

例如，一个类似“euBusinessEntityName＝Smith”的搜索将查寻euBusinessEntityName的索引，因此不会被名为euTModelName的属性中包含Smith的条目混淆。

有时很可能会调用在UDDI标准范围之外的工具。这样的工具必须提供超出UDDI标准定义的访问方法。为了允许此类工具的使用，本发明定义了一些抽象类，这些类绑定了所有描述一个UDDI概念的对象类。这样就能定义类似查寻所有名称或所有关键字索引的搜索。

例如，有一个抽象类euName是所有名称类型对象类(包括euBusinessEntityName和euTModelName)的超类。

UDDI标准规定可以同时以大小写敏感和大小写不敏感的方式搜索名称。这可通过如下方式实现：大小写不敏感地进行检索，然后获取这些条目并大小写敏感地对其进行校验，然而这样的方式会降低性能。这一方法最好定义一个包含相同数据的阴影字段，但是以不同方式被检索。同样地，阴影属性可以用作语言上的变换，例如变音符。

例如，euBusinessEntityName对象类包含每个名称的两个副本。第一个版本的索引是大小写不敏感的，而第二个版本的索引是大小写敏感的。这样，无论请求什么行为，都可以构造一个性能最优的搜索过滤器。

本信息库里的每个属性(除了对象类)都是单值的。这使目录可以构造更有效的索引，并提供更好的搜索性能。

这也能消除搜索结果伪匹配的可能性。例如，假设要查找以“Fr”开头，“nk”结尾的名称。预期结果是生成包含类似“Frank”的名称的(有效)条目。然而，如果名称是一个多值属性，可能会得到一个包含类似“Fred”和“Tink”这两个名称的无效的条目，因为这一条目匹配定义的搜索规则。如果使用多个单值名称，每个名称是此条目的一个子对象，那么就可以消除这种对“Fred”和“Tink”的伪匹配。

操作属性是被UDDI应用程序管理但对用户不可见的一些特殊属性。

在UDDI数据存储器里，应当能有办法区分使用中的TModel和已“撤消”的TModel。当一个TModel被删除时，它很可能还被许多条目使用，因此它不能真正被删除。相反它被隐藏起来，即它不会作为find_TModel调用结果的一部分返回，但是它能通过get_TModelDetail调用被查询。这可以利用一个名为euHidden的属性实现，该属性被添加到那些隐藏的TModel中。在任何搜索TModel的过滤器里增加一个排除所有包含euHidden属性的搜索步骤是非常有用和有效的。

在目录实现中，含有一个绝大多数情况下是同一个值的属性通常被视为是效率低的。例如，一个隐藏属性将99％的条目设置为FALSE将导致低性能——其索引几乎不可用。

效率更高的方法是：大部分条目都存储为不含隐藏属性，只把该属性添加到那些即将隐藏的条目里。这种方法还有一个好处是不必占用空间存储所有“FALSE”值。此时找出所有非隐藏的TModel的过滤器将是“(！(euTModel＝^*))”——是一个存在测试取反，存在测试很快，特别是在该属性只在一小部分条目里存在时。

下面描述本发明的一个实施例以说明如何在目录上下文解决其实现和UDDI标准的问题。在一个X.500计划里有许多元素。这些元素包括属性定义、对象类定义和名称绑定定义。属性定义定义一个单个数据元素，并为其赋予一个唯一标识符(OID)、一个名称和一个数据类型。对象类定义定义了一个作为整体操作的一些属性的集合，并为其赋予一个唯一标识符(OID)、一个名称和一个属性列表；属性可能是要求的或可选的。名称绑定定义了部分的可能层次。名称绑定定义了一个可能存储在另一个对象类之下的对象类，并定义了在这一上下文中命名此子对象的子对象的一个或多个属性。

还有许多需要附加设计的查找限定句。譬如关于大小写敏感性的查找限定句，即能有效地地大小写敏感和大小写不敏感的方式搜索文本数据。根据本发明的一个实施例，大小写敏感性问题可以通过在对象里提供按不同方式索引的附加字段来解决。

依据本发明，文本数据以caseExactString类型的属性和caseIgnoreString类型的属性存储两次。然后查找限定句可以决定搜索哪一字段，以使性能最优。

例如，如果某一企业实体的名称为“McKenna’s Iron FoundryServices”，那么这一字符串将被存储两次，一次存储在一个大小写敏感地检索的字段里，一次存储在一个大小写不敏感地检索的字段里——存储的数据是相同的，但是下层目录生成的索引是不同的。

另一个问题是关于如何有效地实现服务投影。依据本发明的一个实施例，可以利用X.500别名解决这一问题。有许多方法可以处理服务投影问题。本发明的实施例通过目录别名的方法处理这一问题。这是一种特别有效的实现服务投影的方法，可以保证投影和基准服务的一致性，因为基准服务可以通过别名直接访问。其也可以保证投影在基准服务删除时消除，从而确保一致性。

例如，如果一个名为Williams Accounting Services的企业实体发布了一个名为General Ledger Cross-Check的Web服务，并期望在另一个名为Williams Auditing Services的企业实体下提供相同的服务，则这可以通过在第二个企业实体下设置一个别名条目来实现。一个期望列出Williams Auditing Services提供的所有服务的查询者将能像找到Williams Auditing Services直接提供的服务一样找到GeneralLedger Cross-Check这一服务。

另一个问题是关于如何有效地实现键。依据本发明的一个实施例，可以通过把UUID用作外部键和对顺序无要求的键来解决这一问题。顺序重要的地方可以使用连续的数字。虽然键被表述为字符串，但是它们不是真正的文本数据。它们相对说来没有大小写或变音符敏感性。

外部可见的键遵循一个规则集。在依照UDDI标准规范版本2实现信息库时，依据ISO-11578，它们支持UUID。在依照UDDI标准规范版本3实现信息库时，它们支持遵循该版本规范的规则的键字符串。

需要注意的是内部使用的用于链接各元素的键遵循另一个规则集。在对顺序无要求时使用UUID，在顺序重要时使用连续数字。

例如，有一个名为William Auditing Services的关键字索引，表示企业实体的分类口袋的一个元素，其可能引用的TModel的键值为12345678-1234-1234-1234-1234567890ab(UDDI v2)。在分类口袋里此关键字索引的顺序无关紧要，但是此关键字索引需要一个键作为此对象的命名属性。于是我们可以为这一对象生成一个UUID键，例如87654321-4321-4321-4321-ba0123456789，并将其作为此对象在目录里的命名属性。

另一个问题是如果要求X.500分布，数据可以组织成域的形式。依据本发明的一个实施例，可以通过在用户上方创建一个信息库层使得每个信息库可以位于不同的服务器上来解决这一问题。

UDDI标准不允许命名空间是分布式的。这意味着多个UDDI注册中心可以通过复制或直接用后台数据存储管理分布式命名空间来互相协作。

如果每个信息库都具有一个命名前缀则容易实现分布式命名空间。此前缀是一些节点的集合，这些节点定义了一个域。可以把这些节点视作每个UDDI注册中心之上的一个信息库层。这些节点位于用户层之上。

图11例举了一个名为“Domain”的节点110。域110是目录前缀，可以包括一个或多个连接到根部的节点。在域110下方，是多个用户112、113和114。安排在域110下方的用户数可以根据特定的配置和/或本系统的用户需要而改变。根据特定的配置和/或本系统的用户需要也可以安排多个域。在本例中，后文将称这些域为信息库对象，并假设它们表示物理上独立的信息库。当然，也并不一定是这样的情况，这将视特定的配置和/或本系统的用户需要而定。

信息库对象仅需要一个命名属性。

set object-class uddiObjectClass：400＝

{ #信息库——可用来把用户分组

Name＝euRepository

subclass-of top

must-contain

euRespositoryName

}；

分布是大型目录开发里的一个重要概念，因为它使数据可以被多个节点共享而不会占用大量带宽和复制引起的同步问题。

在一个实施例中，“eTrust”UDDI利用下层eTrust目录服务器的功能支持分布性，因此本计划也这样组织，允许在树层次的顶部有一个或多个虚拟“域”节点，且在每个节点子树的顶部有唯一的标识符或名称(参见后面的UDDI计划)。

而且，可以配置一个eTrust UDDI服务器是“distribution-aware”的。可以定义两个独立的目录前缀——一个用于搜索和读取，另一个用于添加条目。为了开发一个分布式服务器，下层eTrust目录服务器代理按照eTrust目录管理指南配置成分布式的。每个独立的eTrustUDDI节点配置一个唯一的节点名称。每个节点的搜索/读取前缀设置为“World”或“Corporation”节点名称。每个节点的添加前缀则设置为该节点的唯一名称。

虽然通过这种方法每个节点可以往其自己的目录信息库中添加条目，但是在所有节点上搜索条目却是通过X.500目录的分布式特性。

例如，有一个信息库对象如下：

euRepositoryName＝Melbourne

另一个问题是关于如何组织用户使用的数据。为了解决这一问题，可以创建一个用户对象来容纳这些数据。

尽管UDDI标准规范里没有定义用户对象，但是依据本发明的一个实施例可以使用这样的对象。例如，一个用户对象可以是其它事物中的一个用户证书的存储点和发布的一个定位点。

图10例举了一个这样的排列，其名为“用户”101。在用户101下方，排列着其他对象，本例中列举的是企业实体对象102、企业服务对象103和绑定模板对象104。排列在用户101下的企业实体对象数可以根据特定的配置和/或本系统的用户需要而改变。根据特定的配置和/或本系统的用户需要也可以安排多个用户。

用户对象里包含的数据元素包括用户键(用于为此用户帐户提供一个唯一的名称)、用户名称和证书(可以和一个密码一样简单，也可以和PKI证书一样复杂)。也可以包括一个授权名称(标识授权操作此用户帐户的人或角色)。还可以包含一个隐藏标志，用于处理删除用户帐号而不会丢失任何由此用户定义的TModel这一问题。

set object-class uddiObjectClass：401＝

{ #用户帐户

name＝euUserAccount

subclass-of top

must-contain

euUserKey，

euUserName，

euCredentials

may-contain

euAuthorizedName，

euHidden

}；

一个用户帐户对象的例子如下：

euUserKey＝23456789-2345-2345-2345-234567890abc

euUserName＝Grace

euCredential＝Amazing76sQ

(本例中假设已经实现了一个简单的用户ID和密码系统。)

另一个问题是关于如何以一种有效的方法表示有关企业实体(UDDI标准中描述的一个对象类)的数据。依据本发明的一个实施例，可以通过把唯一字段表示为对象的属性、重复字段表示为子对象来解决这一问题。

企业实体对象是UDDI标准的一个基本组件。其内容由标准定义，但是其许多元素都是重复的复杂对象，X.500计划不支持这些对象。这些元素可以通过分层结构来表示。

企业实体里只有一个必要元素：企业键。可选元素包括一个授权名称、一个运营商(Operator)和一个用户键(其最终将在普通用户发布的企业实体中出现)。

set object-class uddiObjectClass：402＝

{ #企业实体——提供服务的企业的详细信息

name＝euBusinessEntity

subclass-of top

must-contain

euBusinessEntityKey

may-contain

euParentuserKey，

euAuthorizedName

}；

企业实体的子对象可能是：名称(一个包括名称字符串和语言代码的键控排序对象)；描述(一个包括描述字符串和语言代码的键控排序对象)；联系方式(一个复杂的对象，将在后面阐述)；发现URL(一个包含URL字符串和使用类型的键控对象)；关键字索引(通过对象类的选择标志为分类或标识符信息)和企业服务(将在后面阐述)。

一个企业实体对象的例子如下：

euBusinessEntityKey＝34567890-3456-3456-3456-34567890abcd

euParentUserkey＝23456789-2345-2345-2345-234567890abc

需要注意的是大多数企业实体对象的直观内容实际上存储在企业实体对象的直系子对象里。

依据本发明的一个实施例，图15描述了一个为表示企业实体中一个相对复杂的对象而把层次引入子结构体的例子。图15中，如下多值元素

对孩子152有

语言 en

名称 CA

对孩子153有

语言 IN

名称 CATS

表示为企业实体151的孩子152和153。当然也可以没有或有更多的孩子。

另一个问题是关于如何以一种有效的方法表示有关企业服务(UDDI标准中描述的一个对象类)的数据。

依据本发明的一个实施例，可以通过把唯一字段表示为对象的属性、重复字段表示为子对象来解决这一问题。

企业服务至少可以通过两种方法来实现。第一种方法是企业服务表示由企业实体提供的单个概念服务，可以通过一个或多个访问路由获取此服务，每条路由则由绑定模板描述。第二种方法是企业服务是一个服务分组机制，在绑定模板层才细分为单个服务。无论哪种方法，数据字段都在UDDI规范中定义。

一个企业服务的元素包括企业和服务键。企业键定义拥有此项服务的企业实体。在发现此服务的企业实体下此键不是必需的。通过服务投影，一个服务可以在几个企业实体下找到。服务键是整个UDDI信息库中此服务的唯一标识符。两个键都表示为字符串。

set object-class uddiObjectClass：403＝

{ #企业

name＝euBusinessService

subclass-of top

must-contain

euBusinessServiceKey，

euParentBusinessKey

}；

企业服务对象没有可选内容。所有其它内容构成潜在重复的元素，因此被表示成子对象。一个企业服务的潜在子对象有：绑定模板(参见后文)；名称(一个包括名称字符串和语言代码的键控排序对象)；描述(一个包括描述字符串和语言代码的键控排序对象)；和标注为分类信息的关键字索引。

例如，一个企业服务对象如下：

euBusinessServiceKey＝4567890a-4567-4567-4567-4567890abcde

euParentBusinessKey＝34567890-3456-3456-3456-34567890abcd

需要注意的是大多数企业服务对象的直观内容实际上存储在企业实体对象的直系子对象里。

尽管图15描述了一个依据本发明的一个实施例为表示企业实体中一个相对复杂的对象而把层次引入子结构体的例子，但其同样可以描述一个依据本发明的一个实施例为表示企业服务中一个相对复杂的对象而把层次引入子结构体的例子。图15中的企业实体151同样适用于企业服务，企业服务的多值元素表示为企业服务151的孩子152、153。当然也可以没有或有多个孩子。

还有一个问题是关于如何以一种有效的方法表示有关绑定模板(UDDI标准中描述的一个对象类)的数据。依据本发明的一个实施例，可以通过把唯一字段表示为对象的属性、重复字段表示为子对象来解决这一问题。

绑定模板描述了访问某一特定服务的方法。绑定模板里必要元素只有它的键及其应用的服务的键。可选元素包括一个访问点或主机重定向地址(此对象应当至少包含其中之一)。如果包含一个访问点，则应当包含一个访问点类型。

set object-class uddiObjectClass：404＝

{ #绑定模板

name＝euBindingTemplate

subclass-of top

must-contain

euBindingTemplateKey

may-contain

euParentServiceKey，

euHostingRedirector，

euAccessPoint，

euAccessPointType

}；

绑定模板的子对象可能是：TModel实例信息(参见后文)；描述(一个包括描述字符串和语言代码的键控排序对象)。

一个绑定模板对象的例子如下：

euBindingTemplate＝567890ab-5678-5678-5678-567890abcdef

euParentServiceKey＝456789a-4567-4567-4567-4567890abcde

euHostingRedirector＝ http://www.rsps.com.au/wsep

euAccessPointType＝http

尽管图15描述了一个依据本发明的一个实施例为表示企业实体中一个相对复杂的对象而把层次引入子结构体的例子，但其也同样可以描述一个依据本发明的一个实施例为表示绑定模板中一个相对复杂的对象而把层次引入子结构体的例子。图15中的企业实体151同样适用于绑定模板，绑定模板的多值元素表示为绑定模板151的孩子152、153。当然也可以没有或有多个孩子。

还有一个问题是关于如何以一种有效的方法表示有关TModel(UDDI标准中描述的一个对象类)的数据。依据本发明的一个实施例，可以通过把唯一字段表示为对象的属性、重复字段表示为子对象来解决这一问题。

TModel描述了一种思想。这一思想可以是一个要求定义有效值的分类系统，也可以是一个数据通信协议规范。TModel是一个灵活而强大的概念，是UDDI以一种可精确查询的方式描述复杂数据的核心。

TModel里必要元素只有一个TModel键和一个名称。它们表示为字符串。

TModel的可选元素包括一个授权名称，一个概述URL(概述文档对象的一部分)，一个用户键和一个隐藏标志。

隐藏标志是处理TModel的一个元素。隐藏标志描述了如何处理deleteTModel这一调用。当一个TModel“被删除时”，隐藏标志就添加到这一对象中。这意味着该对象不会被findTModel调用返回，但是可被getTModel调用访问。

set object-class uddiObjectClass：405＝

{ #tmodel——某一思想的引用

name＝euTModel

subclass-of top

must-contain

euTModelKey，

euTModelName

may-contain

euAuthorizedName，

euOperator，

euOverviewURL，

euParentUserKey，

euHidden

}；

其子对象可能是：描述(一个包括描述字符串和语言代码的键控排序对象)，标识为分类或标识符信息的关键字索引，以及概述文档描述(一个包括描述字符串和语言代码的键控排序对象)。

一个TModel对象的例子如下：

euTModelKey＝uuid：67890abc-6789-6789-6789-67890abcdef1

euTModelName＝Corporate QA Policy

euOverview URI＝ http://www.rsps.com.au/policy/qa.html

euParentUserKey＝23456789-2345-2345-2345-234567890abc

尽管图15描述了一个依据本发明的一个实施例为表示企业实体中一个相对复杂的对象而把层次引入子结构体的例子，但其也同样可以描述一个依据本发明的一个实施例为表示TModel中一个相对复杂的对象而把层次引入子结构体的例子。图15中的企业实体151同样适用于TModel，TModel的多值元素表示为TModel151的孩子152、153。当然也可以没有或有多个孩子。

还有一个问题是关于如何以一种有效的方法表示有关发行者声明(UDDI标准中描述的一个对象类)的数据。

依据本发明的一个实施例，可以通过把唯一字段表示为对象的属性、利用辅助类描述必需的关系关键字索引来解决这一问题。

发行者声明是一个描述两个企业实体之间关系的对象。

发行者声明的必要元素有：它的键、源/目的企业和用户键、状态和关系。关系定义为一个关键字索引，并存储为发行者声明条目的一个辅助类。状态存储为一个字符串，但从建立状态对象提取值。所有的键都表示为字符串。

set object-class uddiObjectClass：406＝

{ #发行者声明——两个企业之间的关系

name＝euPublisherAssertion

subclass-of top

must-contain

euPublisherAssertionKey，

euFromBusinessKey，

euFromUserKey，

euToBusinessKey，

euToUserKey，

euPublisherAssertionStatus

}；

发行者声明没有可选内容，也没有子对象。

一个发行者声明对象的例子如下：

euPublisherAssertionKey＝7890abcd-7890-7890-7890-7890abcdef12

euFromBusinessKey＝34567890-3456-3456-3456-34567890abcd

euFromUserKey＝23456789-2345-2345-2345-234567890abc

euToBusinessKey＝09876543-6543-6543-6543-dcba09876543

euToUserKey＝98765432-5432-5432-5432-cba098765432

euPublisherAssertionStatus＝status：complete

需要注意的是有一个与此条目关联的辅助类：euPublisherAssertionRelationKeyedReference，其定义了两个已知的企业实体之间声明的关系。例如：

euPublisherAssertionTModel＝uuid：807A2C6A-EE22-470D-ADC7-

E0424A337C03

euPublisherAssertionKeyName＝wholly-owned subsidiary

euPublisherAssertionKeyValue＝parent-child

还有一个问题是关于如何以一种有效的方法表示有关关键字索引(UDDI标准中描述的一个对象类)的数据。这一情况更加复杂，必须能高效地搜索特定的关键字索引集，譬如企业实体上的分类口袋。

依据本发明的一个实施例，可以通过如下方法来解决这一问题：创建一个抽象基类来表示关键字索引，每个期望的集合是其子类。这些集合在目录中没有描述。例如，它们只是作为相同子类(作为相同对象的子对象存在)的关键字索引组而存在。例如，企业实体的分类口袋是euBusinessEntityCategoryKeyedReference类(此类是特定企业实体的孩子)的对象集。需要注意的是一个企业实体对象可能有几个作为孩子的关键字索引对象，只有它们的对象类才能表明哪些是分类口袋的一部分，哪些是标识符口袋的一部分。

在UDDI数据模型里有几个地方使用关键字索引。关键字索引包括一个TModel键、一个键名称和一个键值。关键字索引的两种用法分别是分类口袋和标识符口袋。这些口袋是关键字索引的集合，对搜索来说非常重要。如果利用包含无差别的关键字索引的对象来描述这些口袋，那么可能很难实现高效搜索。这就是为什么要实现几个关键字索引的子类。一个企业实体上的分类口袋可以通过euBusinessEntityCategoryKeyedReference类的一个或多个子对象来描述。这样利用分类口袋里的特殊的关键字索引就可以容易地实现对企业实体的高效搜索。

下面这个例子给出这个抽象类及其一个导出类：如上所述的euBusinessEntityCategoryKeyedReference类。需要注意的是只有关键字索引的键是从基类继承而来的，而TModel键、键名称和键值都是在导出类中定义的，因此它们可以有不同的名称用于搜索。

set object-class uddiObjectClass：201＝

{ #用作所有关键字索引的父类的抽象类

name＝euKeyedReference

subclass-of top

must-contain

euKeyedReference Key

}；

set object-class uddiObjectClass：301＝

{ #企业实体分类关键字索引——其集合组成分类口袋

name＝euBusinessEntityCategoryKeyedReference

subclass-of top

must-contain

euBusinessEntityCategoryTModel，

euBusinessEntityCategoryKeyName，

euBusinessEntityCategoryValue

}；

联系方式是一个复杂的对象，描述了各种各样的信息。和企业实体类似，联系方式包含了多种复合的可重复元素，必须使用子对象类。

直属联系方式对象的数据元素只有一个键和该联系方式对应的人或角色的名称。还有一个可选的使用类型。

其他可能包含的元素都是联系方式对象的子对象。它们是：地址(地址行对象的有序列表的父对象，每个地址包括一个键、使用类型、排序代码和TModel键)；电话(电话号码加使用类型)；E-mail(一个e-mail地址加使用类型)以及描述(描述字符串加语言代码)。

尽管图15描述了一个依据本发明的一个实施例为表示企业实体中一个相对复杂的对象而把层次引入子结构体的例子，但其也同样可以描述一个依据本发明的一个实施例为表示联系方式对象中一个相对复杂的对象而把层次引入子结构体的例子。图15中的企业实体151同样适用于联系方式对象，联系方式对象的多值元素表示为联系方式对象151的孩子152、153。当然也可以没有或有多个孩子。

另一个问题是关于如何以一种有效的方法描述名称和描述(UDDI标准中定义的)，并能快速搜索某一特定类型的名称或描述。

依据本发明的一个实施例，本系统创建一个抽象基类来表示名称，另外还创建一个来表示描述，每个期望的类型则是它们的子类。查找某一特定类型的名称(例如企业实体名)时，搜索子类的属性；查找任意名称时则搜索抽象类。

几个主要的对象(如企业实体、企业服务等)都可以选用多个名称和描述。其原因是多方面的。对一个企业来说有多个名称比较普遍，它可能有一个正式名称和一个或多个口头名称，而且，一个企业在不同语言中可以使用不同名称。例如一个名称被错误地翻译是很普遍的。例如，计算机公司Fujitsu在说英语的国家里有许多年都是使用Facom这个名字。此问题在包含多个字符集的语言里将更加突出。一个日本公司的名称很可能在片假名中有一个版本，在平假名中又有另一个版本。

基于上述或更多原因，名称和描述对象都可能在单个对象里出现多次。每个实例标注一个语言代码。在UDDI版本3里多个实例可能有相同的语言代码(这在版本2里是不允许的)。

查找限定句更增添了混乱。如上所述，UDDI搜索必须同时支持大小写敏感和大小写不敏感的搜索，最好的解决方案是在X.500目录里把存储数据两份。

下面这个例子给出这个抽象类及其一个导出类：euBusinessEntityName——用于企业实体的名称集合：

set object-class uddiObjectClass：202＝

{ #用作所有名称的父类的抽象类

name＝euName

subclass-of top

must-contain

euNameKey

}；

set object-class uddiObjectClass：331＝

{ #企业实体的名称

name＝euBusinessEntityName

subclass-of top

must-contain

euBusinessEntityNameValue，

euBusinessEntityNameValueIC

}；

需要注意的是euBusinessEntityNameValue是包含该名称的大小写敏感版本的属性；而euBusinessEntityNameValueIC是表示“忽略大小写(ignore case)”的版本，即大小写不敏感。euNameKey字段是从基类继承来的，用于控制名称的排序，并提供一个唯一命名属性。

一个名称对象的例子如下：

euNameKey＝890abcde-890a-890a-890a-890abcdef123

euLanguage＝EN

euBusinessEntityNameValue＝McKenna’s Validation Systems

euBusinessEntityNameValueIC＝McKenna’s Validation Systems

尽管图15描述了一个依据本发明的一个实施例为表示企业实体中一个相对复杂的对象而把层次引入子结构体的例子，但其也同样可以描述一个依据本发明的一个实施例为表示名称对象中一个相对复杂的对象而把层次引入子结构体的例子。图15中的企业实体151同样适用于名称对象，名称对象的多值元素表示为名称对象151的孩子152、153。当然也可以没有或有多个孩子。

另一个问题是关于如何有效地实现以下需求：只允许一个用户更改那些受其控制的企业实体。依据本发明的一个实施例，这可以通过使企业实体被该用户对象的一个用户子对象控制来实现。这使得安全性更易于实现。

确保一个发布用户只能更改属于其的信息可能是很重要的。可以通过各种不同的设计方法实现之。但是，最佳设计能够立即知道一个用户是否授权发布一个条款：所有被给定用户控制的数据位于该用户的子树里。

这一设计决策对企业实体整体上的易于访问性没有影响，因为所有对企业实体的查询可以在此层次结构的用户层之上构建，而不会影响通用性和性能。

另一个问题是关于如何有效地实现发行者声明，特别是findRelatedBusiness方法的实现。依据本发明的一个实施例，这可以通过使企业实体关联到该企业对象的一个企业子对象来实现。从而不必搜索那一准则。

发行者声明的主要用途在于find_RelatedBusiness查询。这一查询指定一个特殊的企业实体，并通过已建立的发行者声明请求与其相关的所有企业实体的信息。这一查询可以通过一个分层结构来简化和加速，这一分层结构把发行者声明置于其关联的企业实体之下。这种分层结构还有利于提高一致性。当一个企业实体被删除时，所有与之关联的发行者声明(现在已经无关的)一同被删除。

另一个问题是关于如何有效地实现以下需求：只允许一个用户更改那些受其控制的TModel。依据本发明的一个实施例，这可以通过使一个用户定义的TModel成为该用户对象的子对象来实现。这使得安全性更易于实现。

与在用户条目下放置企业实体的原因类似，用户定义的TModel也应当置于定义这些TModel的用户的条目之下。这对定位TModel没有有害影响，因为所有TModel都有唯一的名称，所以可以通过单个检索访问来定位。

另一个问题是关于如何通过关系实现对发行者声明的有效搜索。依据本发明的一个实施例，这可以通过使关系关键字索引成为发行者声明条目的一个辅助类来实现。如果关键字索引是一个子对象(这也是一种实现方法)，就不能以同样的效率对其进行搜索，且对关系的搜索不能和对发行者声明内容的搜索结合在一起，例如对状态的(至关重要的)过滤(这里只考虑已建立的发行者声明)。

X.500计划系统可能不支持构造把其他对象类作为数据元素的对象类。例如，一个关键字索引不能是发行者声明的一个数据元素。虽然可以把键控应用作为发行者声明的一个孩子，但是这不利于构造一个引用该关键字索引内容的有效搜索。

使关键字索引成为发行者声明条目的一个辅助类是对这一问题的有效解决方案。这一方案能搜索关键字索引的内容，仿佛这些内容就是该声明的一部分。

如上所述，一个发行者声明的例子如下：

euPublisherAssertionKey＝7890abcd-7890-7890-7890-7890abcdef12

euFromBusinessKey＝34567890-3456-3456-3456-34567890abcd

euFromUserKey＝23456789-2345-2345-2345-234567890abc

euToBusinessKey＝09876543-6543-6543-6543-dcba09876543

euToUserKey＝98765432-5432-5432-5432-cba098765432

euPublisherAssertionStatus＝status：complete

euPublisherAssertionTModel＝uuid：807A2C6A-EE22-470D-ADC7-

E0424A337C03

euPublisherAssertionKeyName＝wholly-owned subsidiary

euPublisherAssertionKeyValue＝parent-child

辅助对象类是euPublisherAssertionKeyReference，上面列出的最后三个属性是其数据元素。

依据本发明的一个实施例，一个类似计算机联盟(CA)的eTrust^TM目录的目录可用于实现一个理想的企业UDDI注册平台。eTrust目录和LDAPv3、X.500电子目录完全兼容，可以用于支持UDDIWeb服务的实施。“eTrust”目录使UDDI的实现可以提供非常成熟的目录解决方案——这一点已经被大规模、对企业至关重要的目录服务应用程序所证实。

“eTrust”目录有许多特性，使其作为构建UDDI注册的平台相当有吸引力。这些特性包括：安全特性——包括访问控制策略、角色、安全代理、相互认证、分布式认证、分布式SSL证书主体校验和网络地址有效性；分布性和路由功能——包括并行分布式搜索、负载分担、流水线式查询和最短路径路由；多主控复制机制——把基于重放机制(称作multi-write)的速度和有效性和基于状态的恢复和调节技术相结合；可用性——包括数据库的热交换、网络容错备援(fail-over)和目录系统代理(DSA)排障；快速的高速缓冲(Caching)设计；以及一些配置特性——包括(对数据类型、计划规则、安全、知识等的)动态配置、数据大小不受限、通用信息完整性规则、广泛的管理员级控制和一个交互式命令控制台。

eTrust目录提供了一个已检验的X.500目录解决方案。在这一基础设施的上方可以构造一个UDDI语义桥，以实现一个和标准一致的UDDI注册中心。基于下层目录解决方案的特性，本文描述的实施例可以提供灵活的安全性、分布性和可管理性，而无须改变或扩展现有的UDDI标准。

本实施例要处理的一个问题是如何映射存储在目录的离散区域中的实体间的关系。

由于UDDI数据结构主要是分层的，所以如果在不同对象间有交叉关系时可能会产生问题。

本质上说，关系有两类：可选名称和交叉关系。依据本发明的一个实施例，利用别名的概念描述可选名称可以解决这一问题。本质上说这种方法可以通过主实体的一个虚拟孩子来“关联”外部实体。

下面依据本发明的实施例描述别名的使用。第一个使用场景可以通过UDDI企业服务投影来清楚地描述。一个企业服务投影实际上是一个企业服务的一个可选名称。企业服务投影是这样一个企业服务：看上去属于企业A但实际上却是企业B所有的和定义的。

参考图5，企业服务51是属于企业A的一个服务，但其看上去也属于企业B。企业A对企业服务51作任何改动都将在看上去在企业B之下的投影的服务中反映。类似地，如果企业服务51从注册中心删除，它将不再在企业A或企业B下方出现。而且，企业B不能编辑或修改企业服务51。只有企业A可以访问企业服务51以进行编辑或其他发布操作。

可以利用目录别名系统来实现这一效果。企业服务51的一个别名被添加到企业实体B。这一别名是对目录服务起的一个特殊标记，实际上表示“当有人查看此别名时，在此显示其他条目”。

这意味着在编辑原始服务时，在投影服务里也可以看到其变化。如果目录系统支持别名完整性——eTrust目录支持此特性，那么若该服务被删除，其投影也会自动移除。

而且，目录服务器可以配置为在搜索时显示两次投影的企业服务：每个父对象下各显示一次。当搜索必须解析一个企业服务的父对象时，这将很有用。

某些场合要求目录层次的不相交部分中的对象维护一个关系。

例如绑定模板和TModel之间就要求维护一个关系。在整个UDDI里TModel用于各种不同的目的。它们是分类键、搜索标识符、(UDDI)关系描述符及此例中的技术规范“指纹”。一个“关联”到绑定模板上的TModel描述了这一绑定模板(参见图8)遵守的技术规范。例如一个发行者可以关联一个TModel，声明它们的绑定模板符合SOAP 1.1标准。

一个注册中心典型地包含一组确定的TModel，其中许多TModel将由数百个甚至上千个绑定模板条目所引用。在某些情况下，注册中心会返回所有“关联”的TModel的详细内容以及绑定模板的详细内容。

依据本发明的这一实施例，一个诸如关系数据库系统中使用的主键/外部键系统可以适当修改和应用。每个存储在注册中心里的TModel有一个其自己的唯一(主)键。绑定模板通过添加一个和需要的TModel的唯一键匹配的本地(外部)键来引用TModel。图7描述了这一实例。如果TModel数据必须和绑定模板一起返回那么服务器就可以查看此TModel。

图6描述了一个绑定模板和TModel之间的关系。

图7描述了TModel键如何创建两个实体间的关系。

发行者声明是UDDI注册中心的一个重要元素。如上所述，它使用户能够发现哪个企业实体与感兴趣的企业实体关联，以及它们是如何关联的。

为了防止滥用，发行者声明被设计为：只有当相关的两个企业实体的所有者都公布此关系时，宣称的关系才成为可见的。这一保护措施需要付出一定代价，因为其使实现复杂化，但为了防止低性能这种精心设计是有必要的。

下面讨论完整性问题。相比其他UDDI概念，发行者声明有一个更加复杂的生命周期。其产生于某个企业实体的所有者做出这一企业及其和另一个企业实体的关系的声明时。另一个企业实体的所有者可以请求一个状态报告并查看有哪些关于其企业的声明，或者可以通知他们越权(out-of-band)。无论以哪种方式，另一个企业实体的所有者可以选择对关于这两个实体间关系的做出一个匹配声明。一旦此声明建立，其就对调用findRelatedBusiness的用户可见。如果有任意一个或者两个声明都被修改或删除，该声明将再次成为未完成的，不再对用户可见。而且，删除任意一个企业实体应当立即删除此声明。

发行者声明对象可以通过一种能保持声明完整性的方法来管理。

企业实体的所有者能够创建(和删除)有关受其控制的企业实体的声明，这一点是有必要的。

本发明的这一实施例是建立在如下假设上的：UDDI信息库是一个“read-mostly(大部可读)”的存储——这正是一个X.500目录适用的。总之，本设计的读数据的性能是最优的，这甚至是以加重写数据的负担为代价的。

为了使搜索性能最优，名为发行者声明的对象类包含的数据超出了UDDI标准所要求的。其设计引入一个可操作属性，该属性定义了发行者声明的状态。声明的状态在其写入目录中时确定，而不必每次搜索时都作判断。

本实施例也以用户键的形式使用指针。当一个发行者声明写入目录中时，“to”和“from”企业的用户键就已经确定并写入该对象中。这简化了getAssertionStatusReport查询，因为要生成这样一个报告只需查找一个包含生成此报告的用户的用户键的发行者声明。

反之，如果必须查询该用户下所有企业键，然后再查找包含那些企业键的发行者声明就可能付出相当大的努力才能生成此报告。

发行者声明常用于发现那些与某一特定企业“相关”的那些企业。为了优化该查询的性能，把与某一企业关联的发行者声明设置为该企业的子节点。

而且，每个声明的状态作为一个可操作属性记录在声明里。这使得只查询位于感兴趣的公司下方的已建立的发行者声明成为可能。这简化了findRelatedBusiness搜索，因为此搜索只需调用那些已建立的声明。

为了简化安全性，所有受某一用户控制的企业及其发行者声明都是该用户帐户条目下的子节点。这一实现方法使得只需限制用户只能访问其帐户条目下的子树就能实现访问控制。

需要注意的是表示状态的可操作属性是由UDDI实现管理的。当某一用户发布一个已经被其他企业宣称的声明时，UDDI实现将更新另一个声明(该声明位于受另一个企业用户控制的子树里)的状态。访问控制允许这一操作。

另一种可选实施例是存储两个发行者声明对象，两个相关的企业实体下各放置一个，于是在其自身的子树下就有一个发行者声明对象。例如，发行者声明子树可以在信息库对象下提供。当声明首次存储时，其处于未完成状态(例如，根据哪一方宣称该声明可以是tokeyincomplete或fromkeyincomplete状态)。如果发行者声明被互补用户宣称，则其状态变成已建立。如果发行者声明被两个企业中任意一个删除，其状态又变为未完成。如果发行者声明被双方都删除，则删除该发行者声明对象。此方案的优点在于只有一个声明的拷贝，大部分维护工作只是修改一个表示声明状态的属性。

图12简要描述了一个依据本发明的一个实施例的层次结构。此图例描述了两种实现方法：发行者声明对象可以位于企业实体和/或信息库对象之下。

图8描述了一个请求添加发行者声明的方法。在步骤S80，判断该请求是否有效。如果无效(步骤S80的结果是“否”)，则请求失败(步骤S92)。如果请求有效(步骤S80的结果是“是”)，则判断该请求是否源于企业本身(步骤S82)。如果不是源于企业本身(步骤S82的结果是“否”)，则判断其是否指向企业本身(步骤S84)。如果不是指向企业本身(步骤S84的结果是“否”)，则请求失败(步骤S92)。如果是指向企业本身(步骤S84的结果是“是”)，则判断此声明是否是源所有者创建的(步骤S86)。如果此声明不是源所有者创建的(步骤S86的结果是“否”)，则写入一个未完成声明(步骤S94)。如果此声明是源所有者创建的(步骤S86的结果是“是”)，则写入一个已建立声明(步骤S96)。再回到步骤S82，如果是源于企业本身(步骤S82的结果是“是”)，则判断其是否指向企业本身(步骤S88)。如果不是指向企业本身(步骤S88的结果是“否”)，则请求失败(步骤S92)。如果是指向企业本身(步骤S88的结果是“是”)，则判断此声明是否是目的所有者创建的(步骤S90)。如果此声明不是目的所有者创建的(步骤S90的结果是“否”)，则写入一个未完成声明(步骤S94)。如果步骤S88的结果是“是”(此声明是目的所有者创建的)或者步骤S90的结果是“是”(声明是目的所有者创建的)，则写入一个已建立声明(步骤S96)。

接下来描述如何搜索操作中中间搜索结果的构造，从而使目录访问和迭代存储(in-memory)操作最小，这主要是考虑到目录存储媒介的限制。在实际使用中，目录条目可能按任意顺序存储并返回，目录结果可能大得无法排序。

本发明的一个实施例提供了一个面向对象的存储器数据存储系统，其与一种唯一结果排序机制相耦合，此机制可以通过特异名称对中间结果进行排序。它使搜索可以返回许多不同类型的对象——企业实体、企业服务等——还能是该系统易于构造正确的XML结构以把这些数据返回给用户。需要注意的是Web服务交互是以XML形式进行的。

下面介绍这一系统。在本发明中，UDDI企业实体和任何子数据元素可以按照如下层次在目录中描述：

BusinessEntity(企业实体)

●BusinessService(企业服务)

BindingTemplate(绑定模板)

BindingTemplate(绑定模板)

ServiceName(服务名称)

●BusinessService(企业服务)

BindingTemplate(绑定模板)

BindingTemplate(绑定模板)

ServiceName(服务名称)

●BusinessName(企业名称)

●BusinessDescription(企业描述)

需要注意的是，服务名称、企业名称和企业描述已经在本发明处理子结构体和对象分割的有关部分描述了。

企业实体获取代码根据所需的一个或多个企业实体的唯一键进行目录子树搜索。此搜索将返回找到的条目，以及所有子条目。目录规范不能保证返回的条目按任何特定顺序排列——甚至不能保证子条目紧跟其父条目后面。

因此，获取代码接着要根据特异名称对返回结果进行排序。于是可以保证子条目将排列在其父条目后面，这样父-子关系就很容易区分。可以使用各种不同的排序算法。使用的排序算法应当在条目部分排序时也能显示出高性能的特性。

构建结果的算法基本上是“深度优先，从左到右的树形”操作。这在图论中称为“后序遍历”。排序后的列表被送到一个新企业实体对象的构造器方法。例如，在面向对象程序构造中，这一对象可以被设计成描述一个UDDI企业实体。企业实体对象包含从最后一个条目提供的数据“构建本身”的代码。代码反复遍历整个列表，对每个条目作判断。不难理解，列表里的第一个条目应当是企业实体本身的主条目，一旦其发现另一个企业实体，则构造过程完成——列表的有序性可以保证这一点。一旦发现一个企业服务或其他子条目，就初始化一个合适类型的对象，并把列表传递给新对象的构造器，同时传送的还有一个指针，说明从列表的什么位置开始。

每个对象都包含基本相似的程序代码来处理自身的构造和把其任意子条目构造成合适的子对象的委托构造。

通过这种方法，只需执行单个目录搜索，且生成的列表以高效的方式处理，保证每个条目只处理一次。如果生成的列表仍然是任意顺序或是按照某一其他方式排序，那么将不得不以多条路径传递此列表，直至根据生成的条目正确地构造一个UDDI层次结构。

委托构造和对分层结构种不同编程对象的列表处理将保持此程序代码相对较小，使其执行效率更高，速度也更快。

图9描述了程序构造(对象)的过程，包括对有序条目列表的表述。判断条款列表里是否有其它项。如果没有其它项(步骤S100的结果是“否”)，程序退出(步骤S118)。如果有其它项(步骤S100的结果是“是”)，则取得列表下一项(步骤S102)。接着判断此项是否具有此对象类型(步骤S104)。如果此项具有此对象类型(步骤S104的结果是“是”)，则根据此项设置对象属性(步骤S106)，且程序返回步骤S100。如果此项不是此对象类型(步骤S104的结果是“否”)，则判断此对象类型的项是否已经处理(步骤S108)。如果此对象类型的项还没有处理(步骤S108的结果是“否”)，则判断该项是否是此对象的固有成分(例如：名称、描述等)。如果是固有成分(步骤S110的返回结果是“是”)，就把该项添加到此对象属性中并执行更多处理(步骤S112)，然后程序返回步骤S100。如果不是固有成分(步骤S110的返回结果是“否”)，则判断该项是否是此对象的子对象(例如，如果此对象是企业实体则企业服务是其子对象)。如果是子对象(步骤S114的返回结果是“是”)，系统初始化一个恰当类型的对象，并把此项列表传递给构造器(步骤S116)，且程序返回步骤S100。如果不是子对象(步骤S114的返回结果是“否”)，则程序返回步骤S100。

下面举一个“真实世界”的例子证明可以期望LDAP目录返回任何排序类型。

SearchResultEntry

objectName：

businessKey＝1ba3034aeef738da00eef78599fe0004，userKey＝1ba3034aedb915

4900edb915491c0001，o＝CA

attributes

type：objectClass

value：businessEntity

type：businessKey

value：1ba3034aeef738da00eef78599fe0004

SearchResultEntry

objectName：

descriptionKey＝1ba3034aeef738da00eef786302b0008，businessKey＝1ba3034

aeef738da00eef78599fe0004，userKey＝1ba3034aedb9154900edb915491c0001，o

＝CA

attributes

type：objectClass

value：uddiDescription

SearchResultEntry

objectName：

serviceKey＝1ba3034aeef738da00eef789707f000c，businessKey＝1ba3034aeef

738da00eef78599fe0004，userKey＝1ba3034aedb9154900edb915491c0001，o＝CA

attributes

type：objectClass

value：businessService

SearchResultEntry

objectName：

nameKey＝1ba3034aeef738da00eef78970da000d，serviceKey＝1ba3034aeef738d

a00eef789707f000c，businessKey＝1ba3034aeef738da00eef78599fe0004，userKey＝1ba3034aedb9154900edb915491c0001，o＝CA

attributes

type：objectClass

value：businessServiceName

SearchResultEntry

objectName：

bindingKey＝1ba3034aeef738da00eef7899fb7000e，serviceKey＝1ba3034aeef7

38da00eef789707f000c，businessKey＝1ba3034aeef738da00eef78599fe0004，user

Key＝1ba3034aedb9154900edb915491c0001，o＝CA

attributes

type：objectClass

value：bindingTemplate

SearchResultEntry

objectName：

nameKey＝1ba3034aeef738da00eef7862fe50007，businessKey＝1ba3034aeef738

da00eef78599fe0004，userKey＝1ba3034aedb9154900edb915491c0001，o＝CA

attributes

type：objectClass

value：businessEntityName

表1——粗体标识的名称条目是列表顶部的企业实体条目的一页，如果其在企业服务条目和企业实体的其他分支子对象前出现，将非常有用。然而，在此例中它出现在列表末尾，将迫使任何程序代码搜索此条目列表，以确保已经处理过该企业实体的所有直接子对象。这可能不是最有效的方法。

因此，已经根据规则排序的相同的数据可以根据本发明的实施例表示如下：

SearchResultEntry

objectName：

businessKey＝1ba3034aeef738da00eef78599fe0004，userKey＝1ba3034aedb915

4900edb915491c0001，o＝CA

attributes

type：objectClass

value：businessEntity

type：businessKey

value：1ba3034aeef738da00eef78599fe0004

SearchResultEntry

objectName：

descriptionKey＝1ba3034aeef738da00eef786302b0008，businessKey＝1ba3034

aeef738da00eef78599fe0004，userKey＝1ba3034aedb9154900edb915491c0001，o

＝CA

attributes

type：objectClass

value：uddiDescription

SearchResultEntry

objectName：

nameKey＝1ba3034aeef738da00eef7862fe50007，businessKey＝1ba3034aeef738

da00eef78599fe0004，userKey＝1ba3034aedb9154900edb915491c0001，o＝CA

attributes

type：objectClass

value：businessEntityName

SearchResultEntry

objectName：

serviceKey＝1ba3034aeef738da00eef789707f000c，businessKey＝1ba3034aeef

738da00eef78599fe0004，userKey＝1ba3034aedb9154900edb915491c0001，o＝CA

attributes

type：objectClass

value：businessService

SearchResultEntry

objectName：

bindingKey＝1ba3034aeef738da00eef7899fb7000e，serviceKey＝1ba3034aeef7

38da00eef789707f000c，businessKey＝1ba3034aeef738da00eef78599fe0004，user

Key＝1ba3034aedb9154900edb915491c0001，o＝CA

attributes

type：objectClass

value：bindingTemplate

SearchResultEntry

objectName：

nameKey＝1ba3034aeef738da00eef78970da000d，serviceKey＝1ba3034aeef738d

attributes

type：objectClass

value：businessServiceName

表2——粗体标识的条目现在出现在列表中一个更合理的位置上，可以利用其优点写入程序代码。当条目数增加到现实服务器的负载数时，就可以大大节省处理时间。

以下是本发明的另一个实施例。

#描述UDDI数据和/或目录中关系的计划

......表达式100

#Computer Associates eTrust UDDI Configuration Schema

#Copyright 2002 Computer Associates Inc

set oid-prefix uddiAttributeType＝(1.3.6.1.4.1.3327.80.1)；

set oid-prefix uddiObjectClass＝(1.3.6.1.4.1.3327.80.2)；

set oid-prefix uddiBinding＝(1.3.6.1.4.1.3327.80.3)；

#--------------------------------------------------------

#Key attributes

set attribute uddiAttributeType：201＝

{#用于KeyedReferenc和所有其导出类

name＝euKeyedReferenceKey

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：202＝

{#用于UserAccount

name＝euUserKey

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：203＝

{#用于BusinessEntity，TModel及其它

name＝euParentUserKey

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：204＝

{#用于BusinessEntity

name＝euBusinessEntityKey

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：205＝

{#用于BusinessService及其它

name＝euParentBusinessKey

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：206＝

{#用于BusinessService

name＝euBusinessServiceKey

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：207＝

{#用于BindingTemplate及其它

name＝euParentServiceKey

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：208＝

{#用于BindingTemplate

name＝euBindingTemplateKey

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：209＝

{#用于TModel

name＝euTModelKey

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：210＝

{#用于PublisherAssertion

name＝euPublisherAssertionKey

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：211＝

{#用于PublisherAssertion

name＝euFromBusinessKey

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：212＝

{#用于PublisherAssertion

name＝euFromUserKey

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：213＝

{#用于PublisherAssertion

name＝euToBusinessKey

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：214＝

{#用于PublisherAssertion

name＝euToUserKey

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：216＝

{#用于DiscoveryURL

name＝euDiscoveryURLKey

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：217＝

{#用于Contact

name＝euContactKey

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：218＝

{#用于Address

name＝euAddressKey

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：219＝

{#用于Address

name＝euAddressTModelKey

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：220＝

{#用于AddressLine

name＝euAddressLineKey

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：221＝

{#用于Phone

name＝euPhoneKey

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：222＝

{#用于Email

name＝euEmailKey

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：223＝

{#用于TmodelInstanceInfo

name＝euInstanceTModelKey

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：224＝

{#用于Name及其所有导出类

name＝euNameKey

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：225＝

{#用于Description及其所有导出类

name＝euDescriptionKey

syntax＝caseIgnoreString

single-valued

}；

#------------------------------------------------------

#keyed references中使用的属性

set attribute uddiAttributeType：301＝

{#用于BusinessEntityCategory

name＝euBusinessEntityCategoryKRTModel

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：302＝

{#用于BusinessEntityCategory

name＝euBusinessEntityCategoryKRKeyName

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：303＝

{#用于BusinessEntityCategory

name＝euBusinessEntityCategoryKRKeyValue

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：304＝

{#用于BusinessEntityIdentifier

name＝euBusinessEntityIdentifierKRTModel

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：305＝

{#用于BusinessEntityIdentifier

name＝euBusinessEntityIdentifierKRKeyName

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：306＝

{#用于BusinessEntityIdentifier

name＝euBusinessEntityIdentifierKRKeyValue

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：307＝

{#用于BusinessServiceCategory

name＝euBusinessServiceCategoryKRTModel

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：308＝

{#用于BusinessServiceCategory

name＝euBusinessServiceCategoryKRKeyName

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：309＝

{#用于BusinessServiceCategory

name＝euBusinessServiceCategoryKRKeyValue

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：310＝

{#用于TModelCategory

name＝euTModelCategoryKRTModel

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：311＝

{#用于TModelCategory

name＝euTModelCategoryKRKeyName

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：312＝

{#用于TModelCategory

name＝euTModelCategoryKRKeyValue

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：313＝

{#用于TModelIdentifier

name＝euTModelIdentifierKRTModel

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：314＝

{#用于TModelIdentifier

name＝euTModelIdentifierKRKeyName

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：315＝

{#用于TModelIdentifier

name＝euTModelIdentifierKRKeyValue

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：316＝

{#用于PublisherAssertion

name＝euPublisherAssertionKRTModel

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：317＝

{#用于PublisherAssertion

name＝euPublisherAssertionKRKeyName

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：318＝

{#用于PublisherAssertion

name＝euPublisherAssertionKRKeyValue

syntax＝caseIgnoreString

single-valued

}；

#-----------------------------------------------------

#用于名称和描述的属性

set attribute uddiAttributeType：361＝

{#用于BusinessEntityName

name＝euBusinessEntityNameValue

syntax＝caseExactString

single-valued

}；

set attribute uddiAttributeType：381＝

{#用于BusinessEntityName

name＝euBusinessEntityNameValueIC

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：362＝

{#用于BusinessServiceName

name＝euBusinessServiceNameValue

syntax＝caseExactString

single-valued

}；

set attribute uddiAttributeType：382＝

{#用于BusinessServiceName

name＝euBusinessServiceNameValueIC

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：363＝

{#用于BusinessEntityDescription

name＝euBusinessEntityDescriptionValue

syntax＝caseExactString

single-valued

}；

set attribute uddiAttributeType：383＝

{#用于BusinessEntityDescription

name＝euBusinessEntityDescriptionValueIC

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：364＝

{#用于BusinessServiceDescription

name＝euBusinessServiceDescriptionValue

syntax＝caseExactString

single-valued

}；

set attribute uddiAttributeType：384＝

{#用于BusinessServiceDescription

name＝euBusinessServiceDescriptionValueIC

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：365＝

{#用于TModelDescription

name＝euTModelDescriptionValue

syntax＝caseExactString

single-valued

}；

set attribute uddiAttributeType：385＝

{#用于TModelDescription

name＝euTModelDescriptionValueIC

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：366＝

{#用于TModelInstanceInfoDescription

name＝euTModelInstanceInfoDescriptionValue

syntax＝caseExactString

single-valued

}；

set attribute uddiAttributeType：386＝

{#用于TModelInstanceInfoDescription

name＝euTModelInstanceInfoDescriptionValueIC

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：367＝

{#用于TModelInstanceDetailsDescription

name＝euTModelInstanceDetailsDescriptionValue

syntax＝caseExactString

single-valued

}；

set attribute uddiAttributeType：387＝

{#用于TModelInstanceDetailsDescription

name＝euTModelInstanceDetailsDescriptionValueIC

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：368＝

{#用于OverviewDocDescription

name＝euOverviewDocDescriptionValue

syntax＝caseExactString

single-valued

}；

set attribute uddiAttributeType：388＝

{#用于OverviewDocDescription

name＝euOverviewDocDescriptionValueIC

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：369＝

{#用于BindingTemplateDescription

name＝euBindingTemplateDescriptionValue

syntax＝caseExactString

single-valued

}；

set attribute uddiAttributeType：389＝

{#用于BindingTemplateDescription

name＝euBindingTemplateDescriptionValueIC

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：370＝

{#用于ContactDescription

name＝euContactDescriptionValue

syntax＝caseExactString

single-valued

}；

set attribute uddiAttributeType：390＝

{#用于ContactDescription

name＝euContactDescriptionValueIC

syntax＝caseIgnoreString

single-valued

}；

#----------------------------------------------------------

#其他属性

set attribute uddiAttributeType：400＝

{#用于Name和Description

name＝euLanguage

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：401＝

{#用于Repository

name＝euRepositoryName

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：402＝

{#用于UserAccount

name＝euUserName

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：403＝

{#用于UserAccount

name＝euCredentials

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：404＝

{#用于UserAccount

name＝euAuthorizedName

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：405＝

{#用于UserAccount和TModel

name＝euHidden

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：406＝

{#用于BusinessEntity和TModel

name＝euOperator

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：407＝

{#用于Contact

name＝euContactName

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：408＝

{#用于discoveryURL、contact、address、phone、email

name＝euUserType

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：409＝

{#用于phone

name＝euPhoneName

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：419＝

{#用于email

name＝euEmailAddress

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：411＝

{#用于addresss

name＝euSortCode

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：412＝

{#用于BindingTemplate

name＝euHostingRedirector

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：413＝

{#用于BindingTemplate

name＝euAccessControl

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：414＝

{#用于BindingTemplate

name＝euAccessPointType

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：415＝

{#用于TModel

name＝euTModelName

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：416＝

{#用于TModel

name＝euOverviewURL

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：417＝

{#用于AddressLine

name＝euAddressLineValue

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：418＝

{#用于tmodel instance info

name＝euInstanceParms

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：420＝

{#用于PublisherAssertion

name＝euPublisherAssertionStatus

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：421＝

{#用于DiscoveryURL

name＝euDiscoveryURLValue

syntax＝caseIgnoreString

single-valued

}；

#---------------------------------------------------------

#抽象类——不能在目录中存储该类！

set object-class uddiObjectClass：201＝

{#用作所有关键字索引的父类的抽象类

name＝euKeyedReference

subclass-of top

kind＝abstract

must-contain

euKeyedReferenceKey

}；

#注意：关键字索引也应包含一个tModel键、键名称和键值，每个导出类应当

#添加这些值，于是它们有不同名称，便于搜索如下属性的标准化名称：

#euXXXTModel

#euXXXKeyName

#euXXXKeyValue

#其中，XXX是对象的名称和关键字索引的目标

}；

set object-class uddiObjectClass：202＝

{#用作所有名称的父类的抽象类

name＝euName

subclass-of top

kind＝abstract

must-contain

euNameKey

may-contain

euLanguage

#注意：名称也应有一个包含特有名称的字符串，该字符串往往有一个

#euXXXNameValue格式的名称，其中XXX是父对象的名称

#这将使搜索效率最高

#该属性还有另一个版本：添加IC的忽略大小写版本

}；

set object-class uddiObjectClass：203＝

{#用作所有描述的父类的抽象类

name＝euDescription

subclass-of top

kind＝abstract

must-contain

euDescriptionKey

may-contain

euLanguage

#注意：描述也应有一个包含特有名称的字符串，该字符串往往有一个

#euXXXDescriptionValue格式的名称，其中XXX是父对象的名称

#这将使搜索效率最高

#该属性还有另一个版本：添加IC的忽略大小写版本

}；

#--------------------------------------------------------------------

#关键字索引类型

set object-class uddiObjectClass：301＝

{#BusinessEntityCategory关键字索引——其集合组成分类口袋

name＝euBusinessEntityCategoryKR

subclass-of euKeyedReference

must-contain

euBusinessEntityCategoryKRKeyValue

may-contain

euBusinessEntityCategoryKRTModel

euBusinessEntityCategoryKRKeyName

}；

set object-class uddiObjectClass：302＝

{#BusinessEntityIdentifier关键字索引——其集合组成分类口袋

name＝euBusinessEntityIdentifierKR

subclass-of euKeyedReference

must-contain

euBusinessEntityIdentifierKRKeyValue

may-contain

euBusinessEntityIdentifierKRTModel

euBusinessEntityIdentifierKRKeyName

}；

set object-class uddiObjectClass：303＝

{#BusinessServiceCategory关键字索引——其集合组成分类口袋

name＝euBusinessServiceCategoryKR

subclass-of euKeyedReference

must-contain

euBusinessServiceCategoryKRKeyValue

may-contain

euBusinessServiceCategoryKRTModel

euBusinessServiceCategoryKRKeyName

}；

set object-class uddiObjectClass：304＝

{#TModelCategory关键字索引——其集合组成分类口袋

name＝euTModelCategoryKR

subclass-of euKeyedReference

must-contain

euTModelCategoryKRKeyValue

may-contain

euTModelCategoryKRTModel

euTModelCategoryKRKeyName

}；

set object-class uddiObjectClass：305＝

{#TModelIdentifier关键字索引——其集合组成口袋

name＝euTModelIdentifierKR

subclass-of euKeyedReference

must-contain

euTModelIdentifierKRKeyValue

may-contain

euTModelIdentifierKRTModel

euTModelIdentifierKRKeyName

}；

set object-class uddiObjectClass：306＝

{#PublisherAssertion关键字索引——用作给出关心的辅助类

name＝euPublisherAssertionKR

subclass-of euKeyedReference

kind＝auxiliary

must-contain

euPublisherAssertionKRKeyValue

may-contain

euPublisherAssertionKRTModel

euPublisherAssertionKRKeyName

}；

#---------------------------------------------------------

#名称和描述类型

set object-class uddjObjectClass：331＝

{#BusinessEntity的名称

name＝euBusinessEntityName

subclass-of euName

must-contain

euBusinessEntityNameValue

euBusinessEntityNameValueIC

#从euName继承euNameKey和euLanguage

}；

set object-class uddiObjectClass：332＝

{#BusinessService的名称

name＝euBusinessServiceName

suibclass-of euName

must-contain

euBusinessServiceNameValue

euBusinessServiceNameValueIC

#从euName继承euNameKey和euLanguage

}；

set object-class uddiObjectClass：341＝

{#BusinessEntity的描述

name＝euBusinessEntityDescription

subclass-of euDescription

must-contain

euBusinessEntityDescriptionValue

euBusinessEntityDescriptionValueIC

#从euDescription继承euDescriptionKey和euLanguage

}；

set object-class uddiObjectClass：342＝

{#BusinessService的描述

name＝euBusinessServiceDescription

subclass-of euDescription

must-contain

euBusinessServiceDescriptionValue

euBusinessServiceDescriptionValueIC

#从euDescription继承euDescriptionKey和euLanguage

}；

set object-class uddiObjectClass：343＝

{#TModel的描述

name＝euTModelDescription

subclass-of euDescription

must-contain

euTModelDescriptionValue

euTModelDescriptionValueIC

#从euDescription继承euDescriptionKey和euLanguage

}；

set object-class uddiObjectClass：344＝

{#TModelInstanceInfo的描述

name＝euTModelInstanceInfoDescription

subclass-of euDescription

must-contain

euTModelInstanceInfoDescriptionValue

euTModelInstanceInfoDescriptionValueIC

#从euDescription继承euDescriptionKey和euLanguage

}；

set object-class uddiObjectClass：345＝

{#TModelInstanceDetails的描述

name＝euTModelInstanceDetailsDescription

subclass-of euDescription

must-contain

euTModelInstanceDetailsDescriptionValue

euTModelInstanceDetailsDescriptionValueIC

#从euDescription继承euDescriptionKey和euLanguage

}；

set object-class uddiObjectClass：346＝

{#OverviewDoc的描述

name＝euOverviewDocDescription

subclass-of euDescription

must-contain

euOverviewDocDescriptionValue

euOverviewDocDescriptionValueIC

#从euDescription继承euDescriptionKey和euLanguage

}；

set object-class uddiObjectClass：347＝

{#Contact的描述

name＝euContactDescription

subclass-of euDescription

must-contain

euContactDescriptionValue

euContactDescriptionValueIC

#从euDescription继承euDescriptionKey和euLanguage

}；

set object-class uddiObjectClass：348＝

{#BindingTemplate的描述

name＝euBindingTemplateDescription

subclass-of euDescription

must-contain

euBindingTemplateDescriptionValue

euBindingTemplateDescriptionValueIC

#从euDescription继承euDescriptionKey和euLanguage

}；

#-------------------------------------------------------------------

#主要对象

set object-class uddiObjectClass：400＝

{#repository——用于把用户分组

name＝euRepository

subclass-of top

must-contain

euRepositoryName

}；

set object-class uddiObjectClass：401＝

{#UserAccount——用于存储用户信息

name＝euUserAccount

subclass-of top

must-contain

euUserKey，

euUserName，

euCredentials

may-contain

euAuthorizedName，

euHidden

#注意：该用户公布的所有BusinessEntity和TModel都是该对象的子类

}；

set object-class uddiObjectClass：402＝

{#BusinessEntity——提供服务的实体的细节

name＝euBusinessEntity

subclass-of top

must-contain

euBusinessEntityKey

may-contain

euParentUserKey，

euAuthorizedName，

euOperator

#注意：BusinessEntity的许多属性都存储在该对象的子对象里

#尤其是那些出现不只一次的属性

}；

set object-class uddiObjectClass：403＝

{#BusinessService——企业实体提供的服务的细节

name＝euBusinessService

subclass-of top

must-contain

euBusinessServiceKey

may-contain

euParentBusinessKey

#注意：该服务的所有BindingTemplate都是此服务的子类

}；

set object-class uddiObjectClass：404＝

{#BindingTemplate——如何访问某一特定企业服务的细节

name＝euBindingTemplate

subclass-of top

must-contain

euBindingTemplateKey

may-contain

euParentServiceKey

euHostingRedirector，

euAccessPoint，

euAccessPointType

#注意：HostingRedirector和AccessPoint应当只少该服务的所有BindingTemplate都是此服务的子类

}；

set object-class uddiObjectClass：405＝

{#TModel——对某一思想的引用。一种分类机制可能只是一个标准的引用

name＝euTModel

subclass-of top

must-contain

euTModelKey，

euTModelName

may-contain

euAuthorizedName

euOperator，

euOverviewURL，

euParentUserKey，

euHidden

#注意：Hidden在“删除”TModel时使用

}；

set object-class uddiObjectClass：406＝

{#PublisherAssertion——宣称两个企业之间的某一关系

name＝euPublisherAssertion

subclass-of top

must-contain

euPublisherAssertionKey，

euFromBusinessKey，

euFromUserKey，

euToBusinessKey，

euToUserKey，

euPublisherAssertionStatus

#注意：关系将存储为类型euPublisherAssertionKeyedReference的辅助类

#这允许直接搜索该辅助类的元素

}；

#------------------------------------------------------------

#次要对象——包含重复数据的主要对象的大多数子对象

set object-class uddiObjectClass：501＝

{#DiscoveryURL——存在于企业实体之下

name＝euDiscoveryURL

subclass-of top

must-contain

euDiscoveryURLKey，

euDiscoveryURLValue，

euUseType

}；

set object-class uddiObjectClass：502＝

{#Contact——存在于企业实体之下——十分复杂，可能有许多子对象

name＝euContact

subclass-of top

must-contain

euContactKey，

euContactName

may-contain

euUseType

}；

set object-class uddiObjectClass：503＝

{#Address——存在于Contact之下

name＝euAddress

subclass-of top

must-contain

euAddressKey

may-contain

euSortCode，

euAddressTModelKey，

euUseType

}；

set object-class uddiObjectClass：504＝

{#AddressLine——存在于Address之下，组成地址行

name＝euAddressLine

subclass-of top

must-contain

euAddressLineKey，

euAddressLineValue

}；

set object-class uddiObjectClass：505＝

{#Phone——存在于Contact之下

name＝euPhone

subclass-of top

must-contain

euPhoneKey，

euPhoneNumber

may-contain

euUseType

}；

set object-class uddiObjectClass：506＝

{#Email——存在于Contact之下

name＝euEmail

subclass-of top

must-contain

euEmailKey，

euEmailAddress

may-contain

euUseType

}；

set object-class uddiObjectClass：507＝

{#TModelInstanceInfo——存在于BindingTemplate之下

name＝euTModelInstanceInfo

subclass-of top

must-contain

euInstanceTModelKey

may-contain

euInstanceParms，

euOverviewURL

}；

#---------------------------------------------------------

#名称绑定

schema set name-binding uddiBinding：101＝

{#绑定到顶部——最高层子对象

name＝euRepository-top

euRepository allowable-parent top

named-by euRepositoryName

}；

schema set name-binding uddiBinding：102＝

{#绑定到顶部——最高层子对象

name＝euUserAccount-top

euUserAccount allowable-parent top

named-by euUserKey

}；

schema set name-binding uddiBinding：103＝

{#绑定到euRepository

name＝euUserAccount-euRepository

euUserAccount allowable-parent euRepository

named-by euUserKey

}；

schema set name-binding uddiBinding：104＝

{#绑定TModel到“顶部”——用于标准TModel(不被用户公布)

name＝euTModel-euRepository

euTModel allowable-parent euRepository

named-by euTModelKey

}；

schema set name-binding uddiBinding：105＝

{#绑定到organization——最高层子对象

name＝euRepository-organization

euRepository allowable-parent organization

named-by euRepositoryName

}；

schema set name-binding uddiBinding：106＝

{#考虑到可供选择的配置，把PublisherAssertion绑定到euRepository

name＝euPublisherAssertion-euRepository

euPublisherAssertion allowable-parent euRepository

named-by euPublisherAssertionKey

}；

schema set name-binding uddiBinding：107＝

{#绑定Repository层次——允许多层repository结构

name＝euRepository-euRepository

euRepository allowable-parent euRepository

named-by euRepositoryName

}；

schema set name-binding uddiBinding：201＝

{#把BusinessEntity绑定到UserAccount——第二层

name＝euBusinessEntity-euUserAccount

euBusinessEntity allowable-parent euUserAccount

named-by euBusinessEntityKey

}；

schema set name-binding uddiBinding：202＝

{#把TModel绑定到UserAccount——第二层

name＝euTModel-euUserAccount

euTModel allowable-parent euUserAccount

named-by euTModelKey

}；

schema set name-binding uddiBinding：301＝

{#把服务绑定到企业——第三层

name＝euBusinessService-euBusinessEntity

euBusinessService allowable-parent euBusinessEntity

named-by euBusinessServiceKey

}；

schema set name-binding uddiBinding：302＝

{#把Contact绑定到企业——第三层

name＝euContact-euBusinessEntity

euContact allowable-parent euBusinessEntity

named-by euContactKey

}；

schema set name-binding uddiBinding：303＝

{#把DiscoveryURL绑定到企业——第三层

name＝euDiscoveryURL-euBusinessEntity

euDiscoveryURL allowable-parent euBusinessEntity

named-by euDiscoveryURLKey

}；

schema set name-binding uddiBinding：304＝

{#企业下方的Name

name＝euBusinessEntityName-euBusinessEntity

euBusinessEntityName allowable-parent euBusinessEntity

named-by euNameKey

}；

schema set name-binding uddiBinding：305＝

{#企业下方的Description

name＝euBusinessEntityDescription-euBusinessEntity

euBusinessEntityDescription allowable-parent euBusinessEntity

named-by euDescriptionKey

}；

schema set name-binding uddiBinding：306＝

{#企业下方的PublisherAssertion

name＝euPublisherAssertion-euBusinessEntity

euPublisherAssertion allowable-parent euBusinessEntity

named-by euPublisherAssertionKey

}；

schema set name-binding uddiBinding：307＝

{#企业实体下方的Identifier

name＝euBusinessEntityIdentifier-euBusinessEntity

euBusinessEntityIdentifier allowable-parent euBusinessEntity

named-by euKeyedReferenceKey

}；

schema set name-binding uddiBinding：308＝

{#企业下方的Category

name＝euBusinessEntityCategory-euBusinessEntity

euBusinessEntityCategory allowable-parent euBusinessEntity

named-by euKeyedReferenceKey

}；

schema set name-binding uddiBinding：310＝

{#TModel下方的Description

name＝euTModelDescription-euTModel

euTModelDescription allowable-parent euTModel

named-by euDescriptionKey

}；

schema set name-binding uddiBinding：311＝

{#TModel下方OverviewURL的Description

name＝euOverviewDocDescription-euTModel

euOverviewDocDescription allowable-parent euTModel

named-by euDescriptionKey

}；

schema set name-binding uddiBinding：312＝

{#TModel下方的Identifier

name＝euTModelIdentifierKR-euTModel

euTModelIdentifierKR allowable-parent euTModel

named-by euKeyedReferenceKey

}；

schema set name-binding uddiBinding：313＝

{#TModel下方的Category

name＝euTModelCategoryKR-euTModel

euTModelCategoryKR allowable-parent euTModel

named-by euKeyedReferenceKey

}；

schema set name-binding uddiBinding：401＝

{#Contact下方的Address

name＝euAddress-euContact

euAddress allowable-parent euContact

named-by euAddressKey

}；

schema set name-binding uddiBinding：402＝

{#Contact下方的电话号码

name＝euPhone-euContact

euPhone allowable-parent euContact

named-by euPhoneKey

}；

schema set name-binding uddiBinding：403＝

{#Contact下方的Email

name＝euEmail-euContact

euEmail allowable-parent euContact

named-by euEmailKey

}；

schema set name-binding uddiBinding：404＝

{#Contact下方的Description

name＝euContactDescription-euContact

euContactDescription allowable-parent euContact

named-by euDescriptionKey

}；

schema set name-binding uddiBinding：409＝

{#服务下方的Name

name＝euBusinessServiceName-euBusinessService

euBusinessServiceName allowable-parent euBusinessService

named-by euNameKey

}；

schema set name-binding uddiBinding：410＝

{#服务下方的Description

name＝euBusinessServiceDescription-euBusinessService

euBusinessServiceDescription allowable-parent euBusinessService

named-by euDescriptionKey

}；

schema set name-binding uddiBinding：411＝

{#服务下方的Category

name＝euBusinessServiceCategory-euBusinessService

euBusinessServiceCategory allowable-parent euBusinessService

named-by euKeyedReferenceKey

}；

schema set name-binding uddiBinding：412＝

{#服务下方的BindingTemplate

name＝euBindingTemplate-euBusinessService

euBindingTemplate allowable-parent euBusinessService

named-by euBindingTemplateKey

}；

schema set name-binding uddiBinding：501＝

{#地址下方的AddressLine

name＝euAddressLine-euAddress

euAddressLine allowable-parent euAddress

named-by euAddressLineKey

}；

schema set name-binding uddiBinding：502＝

{#BindingTemplate下方的Description

name＝euBindingTemplateDescription-euBindingTemplate

euBindingTemplateDescription allowable-parent euBindingTemplate

named-by euDescriptionKey

}；

schema set name-binding uddiBinding：510＝

{#BindingTemplate下方的Description

name＝euTModelInstanceInfo-euBindingTemplate

euTModelInstanceInfo allowable-parent euBindingTemplate

named-by euInstanceTModelKey

}；

schema set name-binding uddiBinding：601＝

{#TModelInstanceInfo下方的Description

name＝euTModelInstanceInfoDescription-euTModelInstanceInfo

euTModelInstanceInfoDescription allowable-parent euTModelInstanceInfo

named-by euDescriptionKey

}；

schema set name-binding uddiBinding：602＝

{#TModelInstanceInfo下方的InstanceDetailsDescription

name＝euTModelInstanceDetailsDescription-euTModelInstanceInfo

euTModelInstanceDetailsDescription allowable-parent euTModelInstanceInfo

named-by euDescriptionKey

}；

schema set name-binding uddiBinding：603＝

{#TModelInstanceInfo下方的OverviewDocDescription

name＝euOverviewDocDescription-euTModelInstanceInfo

euOverviewDocDescription allowable-parent euTModelInstanceInfo

named-by euDescriptionKey

}；

本发明可以通过几种方式具体实现，且不偏离本发明的本质特性的主旨，因此上述具体化实施例并非限制本发明不能使用其它定义，而是可以在本发明所附的权利要求书的主旨和范围内广泛构造具体实施例。在本发明所附的权利要求书的主旨和范围内可以进行各种改进和等价安排。

Claims

1.一种在安排Web服务时使用的方法，其包括：

在用户对象下安排企业实体对象；及

至少在用户对象、信息库对象和前缀之一下安排相应的TModel对象。

2.如权利要求1所述的方法，还包括：

在企业实体对象下安排发行者声明对象。

3.如权利要求1所述的方法，还包括：

在企业实体对象下提供服务投影对象。

4.如权利要求3所述的方法，其中服务投影对象作为别名实现。

5.如权利要求4所述的方法，还包括：作为一个或多个发行者声明对象的属性提供一个或多个字段。

6.如权利要求5所述的方法，还包括：通过一个辅助类描述一个关键字索引。

7.如权利要求6所述的方法，还包括：提供一个对象的特异名称，以揭示该对象的所有权和控制链。

8.一种在安排Web服务时使用的包括计算机可执行的计算机记录介质，其包括：

在用户对象下安排企业服务的代码；及

在用户对象、信息库对象和前缀中至少一个对象下安排相应的TModel对象的代码。

9.如权利要求8所述的计算机记录介质，还包括：

在企业实体对象下安排发行者声明对象的代码。

10.如权利要求8所述的计算机记录介质，还包括：在企业实体对象下提供服务投影对象。

11.如权利要求10所述的计算机记录介质中，服务投影对象作为别名实现。

12.如权利要求11所述的计算机记录介质，还包括：作为一个或多个发行者声明对象的属性提供一个或多个字段的代码。

13.如权利要求12所述的计算机记录介质还包括：通过一个辅助类描述一个关键字索引的代码。

14.如权利要求8所述的计算机记录介质，还包括：提供一个对象的特异名称以揭示该对象的所有权和控制链的代码。