CN1678991A

CN1678991A - Web服务设备和方法

Info

Publication number: CN1678991A
Application number: CNA038202026A
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: WO2004019238A8; BR0313775A; WO2004019232A8; KR20050032620A; WO2004019232A9; WO2004019238A2; US20040205104A1; WO2004019234A8; KR20050032619A; US7861251B2; KR20050032618A; JP2006510956A; BR0313855A; EP1532523A2; EP1532524A2; JP2005536808A; WO2004019233A2; BR0313879A; US20040215621A1; WO2004019236A2

Abstract

一种在Web服务系统中使用的方法，包括：在第一企业实体下，提供至少一个第一企业服务，以及在第二企业实体下提供一个企业服务投影，该企业服务投影在第二企业服务实体下反映了所述至少一个第一企业服务。

Description

Web服务设备和方法相关申请的交叉引用

本申请要求临时申请序列号为60/406391、60/406399、60/406325、60/406328、60/406204、60/406205以及60/406319的优先权，上述申请均是在2002年8月26日提交的，并且将其内容在此并入以供参考。

技术领域

本发明大体上涉及UDDI注册以及web服务，尤其是用于为此类服务提供实际效果的方法、设备和系统。

背景技术

UDDI(通用描述、发现和集成)是一个标准集，被定义用于使那些使用web服务的应用程序可以快速、轻松和动态地彼此进行交互作用。UDDI被用于创建一个独立于平台的、开放的框架结构，用于使用因特网以及可操作的注册中心来描述服务、发现交易和集成系统服务。详细情况可查阅web站点www.UDDI.org。

UDDI注册为使用web服务构建的系统提供了有力的支持。图1a示意性地描述了基本的web服务和UDDI概念。图1b示意性地描述了用于所述web服务环境的简化的协议栈。UDDI为web服务信息提供了信息库，并且其本身也是通过web服务提供的。

UDDI允许应用程序公布如何在web上进行交互。每种web服务都是应用逻辑的自描述、自包含的模块化单元，其通过因特网连接为其他应用提高了某些系统功能。应用程序通过普遍存在的web协议和数据格式来访问web服务、因此不需要关心每个web服务是如何实现的。web服务能与其他的web服务混合和匹配，以运行一个较大的工作流程或商业交易。

UDDI标准描述一个专用的信息库，用于管理web服务类型，商业组织的描述，以及如何调用网络服务的细节。这些标准不必详细说明标准是怎样实现的，也不必详细说明其实施方式是否包括使用数据库、目录或任何其他介质的存储器。

在负责UDDI标准的组织所管理的网站上(http：//www.uddi.org/faqs.html)有很多被经常提问的问题。这些问题之一是：″一个UDDI注册能被建造于LDAP之上或基于LDAP吗？″在回答中，该网站披露在UDDI和目录之间没有明确的关系。UDDI规范限定注册的实施细节。UDDI规范定义一种基于XML的数据模型和一组SOAPAPI，以访问和操纵数据模型。SOAP API定义了UDDI出现的状态。UDDI的实施可以建立在一个LDAP目录上，只要其遵从规定的状态。因此迄今为止所有的UDDI实施方式都建立在关系数据库上。

需要注意的是，诸如X.500和LDAP的目录技术是可扩展的、通用的数据存储，也是最常用的管理用户和资源的关联语言。这些是已经良好开发的技术，被广泛采用，并且被认为非常稳定和值得信赖。

然而，在目录上实施UDDI标准(参见www.uddi.org)需要解决许多问题。UDDI标准留下许多重要问题仍未解决，诸如：

●UDDI标准定义了许多对象，其中一些对象通过层次结构而相关联，但UDDI没有定义一个包含所有对象的层次结构。

例如企业服务对象位于企业实体对象之下，而绑定模板对象位于企业服务之下。附图2示出了这种层次结构的一个例子。企业实体对象被标记为21，企业服务对象被标记为22，而绑定模板对象被标记为23。还需注意的是：例如被标记为24的TModel对象按层次与这些对象没有层次关系。还有其他的概念例如发布者声明不是按等级定义的。

●创建该技术要求的有效的实施方式以允许用户改变由他/她控制的那些对象，

●创建一种有效的实施方式，以允许UDDI注册进行分布，

●创建一种有效的实施方式，其改善了可管理性，以及搜索和更新的性能，

●如何以有效的方式表示复杂UDDI对象。例如企业实体，企业服务，绑定模板和/或TModel具有混合的重复要素。而这些重复要素又包含了其他的重复要素。例如，一个企业实体可以包含联系方式，而该联系方式可以包含地址。地址可包含地址行和电话号码。图13示例了在企业实体中一个相对复杂的对象的UDDI概念。企业实体对象131，包括例如一系列属性132，如AuthorizedName，BusinessKey，以及名称。名称具有一个或多个名称字段133，例如“文本”或“名称”自身中固有的。同样还有“语言”。此处可能有一个或多个这种字段133，

●如何为包含在重复要素中的特定项目提供相对快速的搜索，

●如何在目录对象的层次结构中表示UDDI信息和要求，

●如何以有效的方式管理UDDI对象以及所有与它们有关的信息的删除，以及

●如何优化在搜索操作期间中间搜索结果集合的构建，以便在考虑了目录存储介质限制的情况下，使得目录访问和迭代的存储器内操作被最小化。实际上，目录条目可以被存储并以任意的次序返回，并且目录结果太大而难于进行排序，

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

●如何创建发布者声明的有效的实施方式，特别是查找相关企业的实施方式，

●如何根据关系来有效搜索发布者声明，

●如何管理该发布者声明的有效性，

●如何限制为一个企业实体所创建和删除的声明是由企业实体的拥有者做出的，

●如何高效地按照UDDI标准中的定义来管理属性的有关集合，

●如何定义属性和对象来提高搜索的性能。已经建议了各种UDDI方案。然而，没有一个可以被认为解决了至少上述问题。例如，一种方案提供了UDDI对象到目录对象的相对简单的映射，而没有考虑产生有效的商业实施的复杂性和优化。仍然不清楚在这种方案中多个UDDI服务(特别是find_series)是怎样有效实施的。

例如，图14示意性地示出了在一企业实体中相对复杂的对象的Novell表示。该企业实体对象141，包括例如一系列属性142，每个属性都具有“类型”和“数值”。如图所示，授权名字(AuthorizedName)的值是“Bill”，企业键(BusinessKey)的值是“890.obale.890....”，而名称(Name)具有多个值143，144，即

en#CA

IN#CATS

UDDI(图13)和Novell(图14)的示例不是用于Web服务的有效表示。

因而，需要解决上面提到的常见问题以及其他的问题，以便基于目录提供一个相对可扩展的、有效的和可靠的UDDI实施。

发明内容

一种应用在Web服务系统中的方法，包括在第一企业实体之下提供至少一个第一企业服务，在第二企业实体之下提供企业服务投影，该企业服务投影反映了在第二企业实体之下的至少一个第一企业服务。

一种应用在Web服务系统中的包括计算机可执行代码的计算机记录介质，包括用于在第一企业实体之下提供至少一个第一企业服务的代码，在第二企业实体之下提供企业服务投影的代码，该企业服务投影反映了在第二企业实体之下的至少一个第一企业服务。

附图说明

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

图1a示意性地示出了一些Web服务和UDDI概念；

图1b示意性地示出了用于Web服务环境下的简化的协议栈；

图2示意性地示出了现有技术的层次结构；

图3示意性地示出了现有技术的目录服务模型；

图4示意性地示出了根据本发明实施例，使用X.500目录技术实施的UDDI服务模型的基础组件；

图5示意性地示出了根据本发明的实施例的服务投影；

图6用示意图示出了根据本发明实施例，在绑定模板和TModel之间的关系；

图7用示意图示出了根据本发明实施例，TModel如何创建两个实体之间的关系；

图8用示意图示出了根据本发明实施例，增加发布者声明的请求的逻辑表示；

图9示出了根据本发明用于UDDI数据对象的构造程序的逻辑表示；

图10示意性地示出了在用户对象之下设置企业实体；

图11示意性地示出了在用户对象之上设置域对象；

图12示意性地示出了根据本发明实施例的该方案的概述；

图13示意性地示出了根据相关技术在企业实体中一个相对复杂的对象的UDDI概念；

图14示意性地示出了在一企业实体中相对复杂的对象的Novell表示；

图15示意性地示出了介绍了用于企业实体中一个相对复杂的对象的表示的层次结构；

图16用示意图示出了根据本发明实施例的绑定模板层次的子结构；

图17示例示出了被展平和/或合并的绑定模板子结构；以及

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

具体实施方式

在描述由附图所示的本发明优选实施例时，为了清楚起见采用了特定的术语。然而，本申请并不限制在如此选择的具体术语上，应该理解每个具体要素包括了以相似方式工作的所有等同技术。

图18示出了可以实施本发明的方法和系统的计算机系统的实例。本发明的系统和方法可以通过运行于计算机系统上的软件应用程序来实施，例如，大型机、个人电脑(PC)、便携式电脑、服务器等等。所述软件应用程序可存储在可由该计算机系统本地访问的记录介质上(例如软盘、紧致盘、硬盘等)，或者可以远离计算机系统而经由硬连线或无线连线连接到网络上(例如，局域网或因特网)。

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

以下总结了本发明各种实施例的一些显著的特征以及由其提供一些优点。

根据本发明的一个实施例，在不同用户层上创建了一个信息库层(repository layer)因此各信息库可以位于不同的服务器上。这个信息库层包括一个或多个目录节点，它们共同构成了该目录的前缀。这也可以被称为信息库的“域(Domain)”或“名称(Name)”。这样做的优点是，它提供了一个单独的场所来保持关于域的信息。该节点的名称表示这一目录的前缀。

可以创建一个用户对象来保持表示UDDI帐户的数据。这样做的优点是，它提供了一个单独的场所来保持有关用户/帐户的信息。

企业实体对象可以被安排在用户对象之下，企业服务对象在企业实体对象之下，而绑定模板对象在企业服务对象之下。这样做的优点在于：在用户对象层之上的信息库或者“域”层可以被布置在一起或者被逻辑连接到一起。域层可以被设置成多个级别，例如不同的国家：AU，US，EP等，或者按照大洲来组织。

另一个优点是：该特征可以通过使用X500目录的分布式特征来实现。例如，为了实施上述特征，将“世界(World)”或“公司(Corporation)”节点设置在虚拟目录树的顶端，将一个被唯一命名的节点设置在每个UDDI子树(UDDI名称空间)的顶端。这些“节点”前缀对于用户来说是不可见的，但是这些节点前缀允许UDDI信息库对目录的分布进行平衡。

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

根据一个实施例，由用户定义的TModel是用户对象的一个子对象，因而易于实现安全性。因为用户只能修改和/或控制其自己的子树，这提高了可管理性和安全性。通过使用目录的子树搜索操作，性能也得到了提高。

本发明的一个实施例中，使用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注册，它允许软件要素动态地发现因特网上的适当服务并与之连接。网络服务也能够集成企业内部的商务处理。在这种情况下，UDDI注册中心可以变成组织的基础结构(例如一个重要的企业应用)的一部分，并因此供应最高等级的安全性、性能、可靠性和可管理性。目录技术提供了理想的基础架构来支持企业UDDI注册的严格要求。

企业UDDI注册可以被定义为对UDDI提供了与标准兼容的支持，但除此之外还解决了四个方面的展开问题。这些方面包括：安全性—限制只有授权用户才能访问；分布性—以支持大规模配置；用于一个实际生产系统的可管理性；以及有效性—以满足服务级协定。

对于特定企业配置来说，高度的安全性是一个重要的要求。公共的UDDI注册只是用于帮助任何人发现可用服务的单纯目的。而UDDI注册只是用于使适合的人发现这些服务的目的。这是一个重要的区别。

因特网UDDI注册被认为不适于在企业内展开Web服务。例如，与工资单系统或者与雇员利益管理接口的Web服务的定义不能被张贴到因特网的UDDI注册。

安全性要求也意味着，即使一个内部配置的UDDI注册也提供了严格的访问控制。这是因为UDDI注册本质上提供了指导，教导可以做什么以及怎样去做。UDDI注册能够对任何可用Web服务提供企业级的说明，以及对完整定义了这些服务的可编程接口的WSDL提供了指导。这为应用程序开发者和黑客们都提供了高生产效率的工具。

因此，希望限制对于金融敏感或者机密(例如医疗记录)系统的接口定义进行的访问。即便是在开发组织内部，把关于具体Web服务之信息的访问权限制到被批准的人员也是很明智的。

在企业内部使用不安全的UDDI注册，或通过外联网与选定的商务伙伴使用不安全的UDDI注册都是极端危险的。由于可自由下载的工具，专业水平不是很好的人也可以访问和使用Web服务。任何实际的企业解决方案可以实施一个标准的UDDI服务，具有对于有关Web服务的信息进行透明控制访问的能力。

考虑到分布性，在多数情况下，UDDI注册的初始展开可以小规模地进行。然而，随着Web服务要求的增长，大规模展开也变得更为常见。此外，随着UDDI注册的新功能的发现，也会促进注册使用和展开。

地理分布的组织内的较大规模的实施和使用推动了在单个组织内实施多个UDDI注册。这种趋于分布式注册的演进使得对于任何单个注册中心来说能够动态地同其他注册中心进行交互以为它们的请求服务而变得十分苛刻。一旦建立起来，内部注册中心之间的通信可以超出防火墙的范围，延伸到值得信赖的商业伙伴处的注册中心，甚至是因特网UDDI注册。

目前认为有两种基本的方法来解决注册中心之间通信的需要。一种方案是复制(REPLICATION)，其中同一个条目的名称空间位于多个服务器上。另一个方案是分配(DISTRIBUTION)，其中互联的服务器具有不同的条目的域名空间，然而它们作为一个逻辑服务来操作。

虽然这两个方案常被人误以为是相似的，但它们有显著区别。

在复制方案中，在每一个需要查询信息的服务器上复制信息。这是一种相对简单的解决方案，甚至有点过分简单，但是它引入了同步更新的技术要求，而且随着注册数目以及其内容量的增涨，这将会增加网络拥塞。复制技术最适于服务器数目很少、信息量很少并且变化不多的环境。对于企业配置来说，复制有益于在一个容错备援(fail-over)环境中维护备份信息库。使用复制技术时，保持那些在地理上或者功能上分布的服务器之间的同步是非常困难的。

在分布式方案中，信息在每个参与的服务器上被逻辑表示，但只在单个的注册中心内存储。只有在需要时才将查询分配给其它的注册中心。因而保证了所返回的信息是最新的信息。这样提供了一个更新点，并消除了复制技术本身具有的同步和带宽消耗问题。真正的分布被认为是服务器之间的可扩展连接的一种解决方案。

对于企业UDDI注册，分布通常在两种情况下使用。第一种是具有地理上分散的部门的组织，每个部门产生新的UDDI条目和使用UDDI服务。尽管能够运行单一集中式的UDDI注册，但是带宽限制和时区差别通常会使得其难于实现，甚至于不能实行。

分布式注册提供了灵活的、可扩展的解决方案。在这种情况下，每个参与的部门具有一个独立的注册中心，并且每个注册中心把其它的注册中心视为其自身内容的逻辑组成部分。注册服务考虑到所有的连接细节，而客户不需要考虑地理因素。

第二种情况是，企业需要将其内部的UDDI系统连接到可信任的合伙人的UDDI系统上，或者连接到公共因特网注册中心上。特别地，当连接到公共注册中心时，复制将会产生问题。因特网运营商也许不希望将它们的注册的一部分复制到该企业的内部注册中心去。同样，使用分布式方案可以解决这一问题。目前，不存在用于分布式的UDDI标准，而各种复制的建议方案又十分复杂。应当有一种解决方案可以提供UDDI分布式方案的优点而不需要修改该标准。

关于可管理性，由于要素在企业内执行关键任务的功能，因此UDDI应该满足性能和可靠性要求。它不仅仅是开发人员的一种有力工具。客户端的读取访问将会是UDDI注册最为频繁和在时间上要求最严格的使用情形。对性能进行优化以获得最大处理量，而查询的响应时间会受到较复杂的搜索操作的影响。性能将不会因注册的规模和复杂性增加而降低。支持该UDDI注册的数据存储应当有工业实用性，并且完全支持交易和自动恢复。另外，UDDI服务器应具有高度的可用性，并支持诸如网络的容错备援(fail-over)以及热备份的特性。系统管理员应当具有能力使得UDDI注册易于维护、监视与控制。这些能力包括：无需脱机服务就能改变控制、规则和设置的动态配置(DYNAMICCONFIGURATION)，在线备份和调整(ONLINE BACKUPS ANDTUNING)，以获得较高的可用性，管理控制(ADMINISTRATIVECONTROLS)，以停止注册中心的“搜索(trawling)”，并防止拒绝服务的攻击，通过SNMP或者其他类型的告警机制进行监控(MONITORING)，对于安全、统计、查询和更新信息对单独的记录文件进行审计和诊断(AUDITING AND DIAGNOSTICS)，以及支持复制、分布和路由的选择。

已经提出了许多基于开发人员的UDDI注册技术。这些技术可以为小的开发团体提高有益的特性，但并不是真正的产品质量级的管理系统。Web服务开发正在迅速增长，因此也相应地需要这样一种企业质量级注册，其能够快速地扩展以支持当前的Web服务配置。

UDDI注册提供了一种服务。这种服务依赖于许多应用程序。对于在线商务来说，重要的是这种服务必须一直存在。例如，UDDI注册需要提供99.99％可用性的服务等级协定。为了实现这种可用性，可以在两个或者多个机器上复制UDDI注册，并且提供机制来确保这些机器之间的同步，如果任一机器变得不能利用，则将输入的查询自动路由到一个可用机器上。

如已经指出的，UDDI可以被视为与电话目录服务十分类似。因此，信息存储的目录模型是一个良好基础，根据它创建了UDDI注册服务。该目录模型已经被演变和开发以满足基于目录的服务的特定需求，其具有企业级开发所需的安全性、可扩展性和可靠性。

在应用程序体系结构中，上述的大部分项目是在服务层实现的，而非在数据存储层实现。关系数据库(RDBMS)是通用工具包，以之为基础可以构建许多不同类型的应用。关系数据库致力于提供可靠的数据访问功能性，而不是终端应用所需的额外的服务功能。

图3中所示的目录服务体系结构示出了将服务层同其它组件相分离。将接口功能封装到服务层31，由此获得了可重用的服务基础组件。一个很好例子就是web服务器。web服务器提供了许多功能(HTTP访问，CGI处理等等)，它们共同构成了一种能够嵌入一个独立组件的服务。同样地，本目录服务模型已经被开发为一种特定类型的应用程序以提供所需要的功能。在认证和授权领域，目录技术为许多关键的应用提供了基础。

UDDI可以被视为类似于另一种目录服务。因此可以了解，由UDDI带来的许多实施时的问题都可以通过使用目录技术得以解决。例如，对目录进行优化以获得极其有效的查找和搜索操作，这些操作对于UDDI电话目录操作而言是十分普遍的。

已经指出，如果要在一个企业中成功地开展UDDI服务，则它必须提供严格的安全性、分布性和可管理性等能力。有许多十分相同的属性已经被结合进企业级目录服务的解决方案中。

一种构建企业UDDI注册的方法是对已经在高性能、实际应用中被尝试和测试过的现有的目录结构进行扩展。

目录服务结构为实现企业UDDI注册提供了最理想的工具。这种组合可以提供成功注册所需的特性。如附图4所示的UDDI服务表示了有可能被用于实现这种基础结构的要素。UDDI语义桥(SEMANTICBRIDGE)41是一种服务要素，它被设置在UDDI的SOAP实施42和目录44所支持的LADP接口43之间。目录44递送访问的信息，并支持安全控制、分布机制、以及管理能力。RDBMS 45提供基础的物理数据管理、交易完整性以及备份和恢复机制。

UDDI注册产品可以被直接构筑在RDBMS技术上。关系数据库虽然在许多方面都很有用和可靠，但是其自身不能满足目录处理特有的技术要求

也可能以RDBMS或者其他数据存储系统为基础，从头开始来构建一种目录类型的应用。然而，这并不是最为有效的途径。

一种替换的方案是使用目录服务模型来提供UDDI注册和提供这种特定类型的应用所需要的功能。通过现代的工业级目录服务甚至可以提供UDDI注册所需要的更多的功能。UDDI注册可以被视为具有专用通信和API的目录服务。在目录上提供UDDI服务可以提供必需的安全性、分布性和管理能力，而无需修改UDDI标准就可以获得这些益处。

细心地设计数据表示方法将有益于获得UDDI信息库所需的功能性和性能。

以下描述引用了各种UDDI概念。对于这些UDDI概念的更为详细的描述可以通过查阅UDDI规范(http：/www.uddi.org/specification.html)获得。

对目录语来说，模式是对于可以被存储在该目录中的那些数据要素的描述，以及这些要素被连接在一起的方式。它包括了各种可能的属性的描述(一个属性占有一页数据段)，不同对象的描述(一个对象是多个属性的集合)，和可能的对象层次结构的说明。在这个说明中所使用的特别的模式注释是eTrust目录中(它是ComputerAssociates International公司的一种产品)所使用的模式。“eTrust”是Computer Associates International公司的产品名称和商标。当然也可以使用其他的模式注释。

本发明描述了一种模式，其被用于实现一个使用目录进行数据存储的UDDI信息库。在这个模式中涉及许多概念。也有许多的技术被用来提高这种UDDI的执行效果。下面对这些概念中的一些进行了简要描述。对于这些概念和技术的更为详细的描述将在随后描述本发明的实施例时一起描述。

该模式被设计用于提供优化的操作。该模式设计中包括对属性、对象类、条目以及层次结构的定义，以提高操作效果。本模式设计至少在安全性、性能、可管理性以及分布性方面提供了显著的益处。

现在将描述该系统的层次结构。X.500目录支持在内部分布，无须在UDDI层次进行任何编码就能提供一种分布式的UDDI信息库。每个级别对信息库的内容进行了划分。这种模式的(任选的)域级别使得该层、每个域以及该层之下的所有条目都可以被设置在对于UDDI级别的编程为透明的一个独立的目录服务器上。附图11示出了本发明这一方面的一个实施例。将在下面对其进行更为详细的描述。

根据本发明的一个实施例，用户对象可以被置于企业和TModel对象之上。用户对象提供了一个空间来存储与该用户有关的信息。它也为该用户所发布的所有数据提供了一个定位指针。附图10示出了本发明这一方面的一个实施例。将在下面对其进行更为详细的描述。

在这种域/用户的体系结构系统中有利于实现安全性。UDDI实施可以使得用户对于它们的数据对象的子树的控制得以实现。

还提供了对用户控制的条目的搜索。可以通过搜索在用户对象之下的子树来提供对受该用户控制的数据所进行的搜索。

可以通过指定一个在绑定模板中产生的TModel来查找一个企业。这等价于“通过查找x的一个(或多个)孩子来查找x”。换言之，查询可以是“找到提供某种服务的所有企业，这些服务具有一个绑定模板能够定位的TModel”。这样的查询可以通过查找派生对象的DN(识别名称)并抛弃不需要的层来完成，以获得该企业实体的DN。也有可能以这种方式进行复制品的删除。由于本发明的这种结构的层次特性而带来了这种查找特征。

可以使用对象类所独有的属性来执行搜索。这种优化具有两个益处。这简化了搜索的记录，并且通过消除“弱”条件而获得了优越的性能。一个“弱”条件是滤波器的一部分，它会返回许多的条目，或者会引用一个是许多条目的一部分的属性。对于每个名称都使用相同的属性名称的设计在按照名称搜索企业实体时有两个选择：在搜索中包含对象类或者对搜索结果进行筛选。前者只有在企业名称具有唯一的对象类时才是可能的，并且即便如此，对象类也是一个弱条件，会出现很多次。后者意味着额外的代码，以及将有可能返回比期望结果大很多的结果列表。

例如，考虑一个名为“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别名就可以表示服务投影。这对于确保数据完整性很有作用。别名可以访问原始数据，因此对于原始数据的任何改变都可以立即通过别名反映出来。如果目录实施支持别名完整性，则当原始条目被删掉时别名就会消失，而无需附加的工作。

发布者断言是在UDDI标准中定义最不明确的要素之一，因此需要被精心地规划。不适当的实现将很容易导致较差的性能。

由于发布者断言通常用于fin_relatedBusiness API中，该API被用于搜索与一个指定的企业实体有关的所有已完成的发布者断言，好的设计是把每个断言都至于该断言所引用的企业实体之下。

通过计算断言的状态，并将其存储在断言对象中。可以将搜索限制到已完成的断言。这意味着返回的结果不会包含要被删除的错误的引用。

把关系对象作为辅助的类存储使得搜索可以消除任何具有不希望的关系的断言。如果关系作为子对象存储，有不能生成一个单一搜索搜索来解决关系和断言完成状态。

UDDI键值存在时可以为对象命名。UDDI为许多的重要对象类定义键值。并且这些键值被规定为保证其是唯一的。这意味着这些键值可以被用作为对象的命名属性。使用UDDI键值作为命名属性意味着不需要分辨命名冲突-如果例如默认名称被用作为一个企业实体的命名属性时这是需要的。

UDDI键值不存在时也可以提供键值来进行命名。也就是说，并非所有的UDDI对象都具有已定义的键值。一个实例是发布者断言。对于这些断言，当前系统提供了一个键值，使用与UDDI定义的键值相同的算法。该思想的复用意味着为其它对象而编写的代码和结构可以被再次利用。

当一系列的UDDI对象是另一对象的子对象时，则这些子对象的顺序十分重要(例如地址行)，分配给子对象的键值按数值单调增加，因此对这些键值进行排序可以获得期望的顺序。这简化了确保期望顺序的处理。

在实际应用中，期望键值以一种little-endian的方式变化。也就是说，键值最左边的字节变化最快，因为这样可以在使用X.500作为数据存储时获得最佳性能。

UDDI标准在一些主对象类型内定义了多个子结构。在许多情况下，这些子结构是任选的，并且可以重复(在同一对象中可以出现零次、一次或者多次)。一个简单的实例是名称子结构，包含一个字符串(名称)和一个语言标识符。X.500模式定义不支持这种结构化属性的使用，因此不存在十分清楚的子结构映射。有一些方法被用于在X.500模式中实现这些子结构。

一种将子结构的组件连接成单个属性的方法是使用某种分隔符来划分各种要素。这不是最佳的设计选择，因为它丧失了单独对组件进行索引或者搜索的能力，并且增加了在处理这些数据时的处理复杂性。

在本系统中，用于表示子结构的特定设计被选择用来优化性能和可管理性。所公开的设计可以使用众多技术中的一种或者多种来表述目录中的子结构。这些技术可以被归纳为3类：

一类技术是将许多的子结构作为子对象处理。名称是一个很好的例子：企业实体名称作为企业实体的子对象而存储。另一个实例是描述，单个的企业描述对象是企业实体对象的子对象。附图15提供了本发明这一方面的实施例，并且将在下面更详细的进行描述。

另一类技术是展平/合并(flattening/merging)。当至少和另一对象有关系时，可以将属性合并到单个对象中。在这种情况下，层次结构被展平，因为两个对象被组合成一个对象。新对象被合并，因为该新对象包含了来自组成它的对象的属性的组合。优选地，关系对象的内容被提升为父对象。

例如，图16示例了UDDI关系图的一种表示形式。图17示出了一种目录层次结构图，其中通过展平UDDI对象而形成了目录层次结构。

为了解释，图16示出了对象161，它将对象163和对象162联系起来。

根据本发明的一个实施例，当存在一对一的关系时，“子对象”被提升。换言之，该部分的层次结构被折叠或者展平，并且合并对象。其结构如图17中所示。父对象171具有内容A1、A2、An以及一个或者多个子对象，子对象9n包括内容B1、B2、Bn、C1、C2以及Cn。

另一类技术是分割(splitting)。例如，在一种特定情况下(OverviewDoc子结构)，子结构中包含了不重复的要素以及重复的要素。不重复的要素(OverviewURL)可以被移入到父对象中，而重复的要素可以作为子对象。

本发明的另一方面是管理操作。删除一个TModel就会将其从find_TModel隐藏起来，但并不是从信息库中删除它。相应地，为了正确处理TModel，可以使用一个隐藏标志。存在该隐藏标志表示该TModel(或者用户对象)被隐藏。没有隐藏标志表示其未被隐藏。对于绝大多数TModel来说情况确实如此，因此该方案是有效的。未隐藏的对象不会占据空间，也不会使用索引。该目录将只去索引那些不具有隐藏属性的条目。这也意味着搜索未被隐藏的TModel会更快速和有效。

被用作数据存储的X.500目录鼓励了不存储空值的设计。例如，对象中不存在的一个(任选的)值将不会在目录中存储。这样可以有效使用存储空间，并且进行更强的搜索。依赖于属性的任何搜索只需要考虑具有该属性的数据的那些对象。

本系统的数据层次结构与UDDI标准的目的可以很好地匹配。当删除UDDI对象的请求到达时，它直接映射为在目录中删除一个子树。例如，删除一个服务包括删除它的名称和描述，以及它的所有绑定模板。所有这些都是该服务条目在目录中的子对象。相应地，本系统从上到下地从该服务条目中删除子树。这易于实现并且很有效。

域是表示一个层次子树的基础的名称。在X.500术语中，域被称为上下文前缀。在LDAP术语中，它被称为后缀。给UDDI信息库一个域名使得真正可以在信息库中分布式使用该数据(在X.500情况下)。UDDI标准只支持复制。通过具有域节点，该系统可以使用对该应用程序透明的目录分布特性。

例如，假设一个企业在内部配置了UDDI，但是具有两个开发站点。利用该分布特性，它们可以在每个站点都配置一个分布式UDDI服务器，得每个站点都能直接浏览在两个注册上发布的项目。

这样作的优点在于：它允许自由的分布。例如，UDDI服务器不需要作任何额外的工作，并且目录系统有效地把孤立信息联系在一起。

在UDDI标准中没有规定如何存储用户信息。通过创建用户对象，所有与用户有关的信息都可以被存储在单个对象中，并且该对象可以被用作保存该用户所发布的所有对象的子树的根。这使得安全性的定义更加简单。例如，如果用户所考虑的对象(比如企业、服务甚至是TModel)在该用户的用户对象之下，则用户就可以控制它。

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

把重复的结构化对象作为子对象存储可以在目录中有效地表示数据，在搜索时每个字段都单独可获得(以及索引)。

例如，企业实体名称可以作为该企业实体对象的子对象进行存储。另一实例是企业描述，它可以作为子对象存储在企业实体对象之下。

这类系统的优点在于，它允许搜索一个名称(一种普通的UDDI搜索)，并且该条目的DN给出了该名称所属的对象的DN。

UDDI定义了冗余的“信息库”节点(只包含子对象子结构而不是属性的UDDI结构)。因此这些节点可以根据查询结果而以相对较低的代价构建，因此可以被删除。在某些情况下，属性可以从子节点提升为父节点，以从目录表示中删除当前的冗余子节点。

例如，由于TModelInstanceDetails未包含属性，因此没有在目录图表中表示出来。由于instanceDetails的属性被提升到TModelInstanceInfo的父对象overviewDoc中(如同其子对象的属性一样)，因此也没有在目录模式中表示。在目录中也没有表示种类和标识符袋，因为其内容是该袋的拥有者的子对象。

这样作的好处是，减少了目录中的条目数量。特别地，它最小化了DIT的深度，因此改善了性能。

附图12原理性地示出了根据本发明一个实施例的层次结构。提供了一个或者多个域或者前缀121。在每一个域121之下，有一个或者多个用户122。在每一个用户122之下，提供了一个或者多个TModel123以及一个或者多个企业实体(BE)124。在每个企业实体124之下，提供了一个或者多个发布者断言(PA)125、一个或者多个企业服务(BS)126以及一个或者多个服务投影(SP)127。在每个企业服务(BS)126之下，有一个或者多个绑定模板(BT)128。可以按照特定实施的需要来设置别名。例如，服务投影对象(图12中所示的三角)可以作为别名从企业实体对象中产生。

通读本发明将会明了如图12所示的这种模式设计的优点。

发布者断言被设置在它们所引用的企业实体之下，因为它们通常是在find_RelatedBusinesses调用中使用，该调用指定了一个企业键值，并且经由发布者断言来查找与该键值有关的所有企业。本系统定位所知道的企业，然后读取其下的所有(已建立的)发布者断言。

这样做的优点是，允许快速有效的搜索。也易于维护数据的完整性。例如，当一个企业被删除时，任何的发布者断言也都被自动删除。

TModels可以被发布它们的用户改变(或者修复/隐藏)。把它们设置在表示该用户的条目之下可以使得安全性更简单。例如，如果TModel存在于该用户条目之下的子树中，则它可以被修改。反之，则不能。

更为详细地说，如果想要进行改变的用户的DN(区别名称)与该TModel的DN的前缀匹配，则条目可以被该用户修改，否则，则不允许修改。目录可以被用于之下这种判断(当DN不存在时命名异常)。

当从信息库中删除一个对象时，与该对象相关的信息也可被删除。通过根据本模式的实施例而使用的层次设计使之得到了极大的简化。当删除对象时，以之为根的整个子树都被删除，并且这一处理可以删除所有(并且通常是唯一的)相关信息。可以从底部向上执行子树的删除。只有当条目的所有子节点都被删除之后才能删除各个条目。这是通过以逆DN顺序列出所有的子节点来实现的。这样保证了在父节点之前子节点的删除。

这样做的优点在于，用排序列表的方法替代了更加复杂的递归方法。此外，这样也相对简单并且节省存储器。当子树中的所有条目都按照DN进行排序，并且以相反顺序执行删除之后，这样确保了所有的子节点在其父节点之前被删除。

例如，当删除一个企业服务时，系统删除与之相关的所有绑定模板、它们的TModel实例信息以及各种相关的种类信息。所有这些可以通过删除以该企业服务为根的子树来完成。

由于在该方案中所使用的层次结构，一个对象的DN揭示了拥有关系链以及对于该对象的控制。注意，断言也取决于在命名属性时的精心选择。

这样作的优点在于，减少了被用于收集信息的搜索数或者读取的次数。例如，使用作为子对象(例如名称)的搜索结果，每个条目的DN揭示了父对象(例如BusinessEntity)以及拥有帐户。

例如，企业服务的DN揭示了该服务所述的企业，以及控制它的用户。

目录并不保证结果的任何顺序。当处理一个复杂的结果时(例如企业实体以及其企业服务以及它们的适当的名称和描述)，通过按照DN来取这些搜索结果并对之排序可以简化输出的结构。对它们进行组织以使结果的结构变得相对简单。在每个对象的子对象之前对之进行构建，因此易于将子对象设置在其父对象之下，因此在企业的服务之前组织该企业结果。一个对象的所有子对象出现在相同类型的下一对象之前，一个企业的所有服务出现在下一企业之前。这同样也获得了简单的递归结构，因为在每一级别适用相同的事物。

这样做的优点在于最小化了通过构建该UDDI结构所需的原始条目列表的数量。

例如在排序之后，企业A的结果之后是其第一个服务的结果(该服务的名称是AA)，然后是A的第二个服务(其名称是AB)，然后是第二企业B。

也可以对子对象执行搜索。例如，常用的搜索请求可以是“通过查找x的一个(或者多个)孩子来查找x”。通过搜索来找到企业的一种方式是例如通过指定在绑定模板中产生的TModel来实现。换言之，查询是“找到具有一个其绑定模板引用了该TModel的服务的所有企业”。可以通过查找派生对象的DN来完成这种查询，并砍掉不需要的级别来获得企业实体的DN。有益地，这也消除了重复。这种搜索方法部分归功于本发明该实施例的层次结构。

使用得到确保的唯一键值可以使问题简化。可以搜索整个信息库以寻找单个键值，并且唯一性确保了要么没有结果(如果不存在该键值的话)，要么有一个结果(如果键值存在)。不需要考虑将搜索限制在父对象的范围内。可以从目录中获得增强的性能，因为可以充分地利用数据库索引。

这样做的优点在于可以使用最快的目录查询。另一优点在于如果给定对象被另一对象引用，则确保唯一的名称十分重要。

大多数索引系统的一个特性是数据之间的相关性。如果数据是“little-endian”(最左边的部分变化最快)，则数据趋于展开，并且索引可以给出最好的性能。相反，如果数据是重复的，则索引不是十分有效。可以使用UUID(全球唯一标识符)算法，其具有“little-endian”特性。这样做的另一优点是最大化了目录的性能。

可以向派生的对象添加键值。在将重复的数据要素加入到子对象时，需要添加一个命名属性，形成其DN的最后一部分(arc)。在目录中命名属性与其同胞对象不同，因为同一父对象中没有任何两个子对象具有相同的名称。

可以使用两种类型的键值。对于不需要排序的子对象，使用UUID算法，因为这样可以保证唯一性。对于需要排序的情形，使用具有单调增长的键值，以确保顺序。

在UDDI标准中，企业实体可以提供两种服务：控制服务(在信息库中使用子对象表示)，以及提供了接口的服务，但实际上它们也是由其它的企业实体提供的。后者可以在所公开的UDDI信息库中用别名来表示。别名确切地提供了正确的特征。例如，如果原始对象(服务)被其拥有者(也可能是添加了另一绑定模板)以某种方式改变，则通过别名而引用的对象也“改变”。而且，在该企业实体中对服务的任何搜索都能获得实际的以及别名引用的服务。

例如，别名可以被用于服务投影，其中企业指向在另一企业之下定义的一个服务。这样做的优点在于，别名自动提供涉及“可替换名称”的功能。此外，如果目录支持别名完整性，则当删除原始服务时，将自动删掉任何投影。

在UDDI标准中有许多地方不希望被其他对象直接引用，而希望通过一个中间步骤实现—例如，TModel实例信息的情况下，或者在发布者断言中引用企业实体的情况下。在这些情况下，别名将使代码复杂。因此，本发明可以使用对象的引用来代替别名。因为，根据一个实施例，本系统确保每个对象具有唯一的键值，则键值可以确切地被用作引用，有时候也称为“外来”键值。

使用辅助对象类可以执行属性分组。在处理发布者断言时需要使用三个唯一识别该发布者断言的属性来定位发布者断言：两个企业实体键值以及它们之间的关系。然而，该关系被规定为键值引用，其自身也是三个不同属性：TModel键值、键值名称以及键值。一种方式是把关系作为发布者断言的子对象加以存储。然而，这样不能最有效地搜索特定的发布者断言。通过使关系的键值引用成为发布者断言条目的辅助类，有可能在单个搜索中搜索所有的5个属性，因而准确地提取出了所需的发布者断言对象。

这种方案的一种设计可以使用常规的面向对象设计技术，并且导致了例如所有键值引用都具有相同的属性名称。然而这种设计使得难于分开例如企业实体种类的键值引用并且使得分开的成本很高，为了避免与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 Service的企业实体发布了一个名为总帐核对(General Ledger Cross-Check)的Web服务，期望在一个名为Williams Auditing Service的另一个企业实体中提供相同的服务，然后这可以通过在第二企业实体之下设置一个别名条目来实现。列出由Williams Auditing Service所提供的服务的询问者将查找总帐核对服务，就如查找直接使用Williams Auditing Service提供的任何服务一样。

另一问题涉及键值的有效实现。根据本发明的一个实施例，这是通过在顺序不重要的情况下使用UUID作为外部键值和键值来解决的。在顺序重要的情况下可以使用连续数字。尽管键值被表示为字符串，但是它们并不是真正的文本数据。无需大小写敏感或者变音符标记就可以进行比较。

外部可见的键值遵循一组规则。当实施一个与UDDI规范的版本2兼容的信息库时，它们保持UUID，与ISO-11578兼容。当实施UDDI规范的版本3的信息库时它们按照该版本的规范所制定的规则来保持键值字符串。

注意在内部用于将要素联系在一起的键值遵循另外一组规则。那些顺序不重要的键值使用UUID。那些顺序重要的键值使用序列号。

例如，一个键值引用表示被称为Williams Auditing Service的企业实体的种类袋的一个要素，其可以引起一个键值为12345678-1234-1234-1234-1234567890ab(UDDI v2)的TModel。在种类袋中键值引用的顺序不重要，但是键值引用需要键值被用作该对象的命名属性。因而，我们可以为该对象产生一个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

euRepositoryName

}

在大规模目录配置中，分布是一个重要概念，因为它允许数据被多个节点共享，而不需要复制所需的过多的带宽负荷和同步问题。

在一个实施例中，“eTrust”UDDI使用下层eTrust目录服务器的性能来支持分布，为此本方案可以这样来设计：在树层次结构的顶端允许有一个或多个虚拟的“域”节点，在每个节点子树的顶端允许唯一的节点标识符或者名称(参见以下的UDDI模式描述)。

此外，可以将eTrust UDDI服务器配置为“分布式感知的(distribution-aware)”。可以指定两个分开的目录前缀-个用于搜索和读取，另一个用于添加条目。为了配置一个分布式服务器，底层的eTrust UDDI目录服务器代理按照eTrust目录管理指南被配置成分布式的。每个独立的eTrust UDDI节点被设定为“World”或者“Corporation”节点名称。每个节点的Add前缀被设定为该节点的唯一名称。

以这种方式，每个节点把条目添加到其自身的目录信息库中，但是通过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

euCredentials＝Amazing76sQ

(假设在这个例子中采用了一个简单的用户ID和口令系统)

另一问题涉及以有效的方式来表示有关企业实体的数据(在UDDI标准中描述的一个对象类)。根据本发明的一个实施例这是通过将唯一的字段表示为对象的属性，并且将重复的要素表示子对象来解决的。

企业实体对象是UDDI标准的一个基础要素。其内容由标准定义，但是它的大多数要素是不能得到X.500模式支持的重复的复杂对象。这种要素可以用层次结构安排来表示。

在企业实体中唯一需要的要素是企业键值。任选的要素包括授权的名称、操作者以及用户键值(后者将出现在由正常用户发布的企业实体中)。

set object-class UDDIObj ectClass: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，有

Language en

Name CA

对于子对象153，有

Language IN

Name 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实例信息(见下文)；以及描述(一个包含描述字符串和语言代码的对象，具有键值以进行排序)

绑定模板的一个实例是：

euBindingTemplateKey＝567890ab-5678-5678-5678-567890abcdef

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

euAccessPoint＝http：//www.rsps.com.au/wsep

euAccessPointType＝http。

同样地，尽管图15示出了根据本发明将层次引入到子结构中的一个实例以表示企业实体中的一个相对复杂的对象，但是它同样示例了根据本发明将层次引入到子结构中以表示绑定模板中的一个相对复杂的对象的实例。图15的企业实体151同样适用于绑定模板，而绑定模板的多值要素被表示为绑定模板151的子对象152，153。也有可能没有子对象，或者有更多子对象。

要解决的另一问题是以有效的方式表示有关TModel的数据(在UDDI标准中描述的对象类)。根据本发明的一个实施例可以通过用唯一的字段表示对象属性，用重复要素表示子对象来解决。

一个TModel表示一个想法。该想法可以是例如一个分类系统，需要规定有效的值。或者它可以是对数据通信协议的规定。TModel是一个灵活而有力的概念，集中于UDDI以它们能够被精确查询的方式来表示复杂数据的能力。

TModel对象中唯一需要的要素是TModel键值和名称。它们被表示为字符串。

TModel对象的可选要素是被授权的名称、概述URL(概述文档对象(Overview Doc object)的一部分)、一个用户键值以及一个隐藏标志。

隐藏标志是对TModel进行处理的要素。隐藏标志是处理deleteTModel调用的方式。当一个TModel被“删除”时，隐藏标志被添加到该对象。这意味着，对象将不会返回给findTModel调用，但是可以被getTModel调用访问。

set object-class UDDIObjectClass:405＝

{ #TModel-涉及一种想法

name＝euTModel

subclass-of top

must-contain

euTModelKey，

euTModeIName

may-contain

euAuthorizedName，

euOperator，

euOverviewURL，

euParentUserKey，

euHidden

}；

可能的子对象是：描述(Description)(一个包含描述字符串和语言代码的对象，具有键值以进行排序)；键值引用，被标记为种类或者标识符信息；以及Overview Doc Description(一个包含描述字符串和语言代码的对象，具有键值以进行排序)

TModel的一个实例为：

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

euTModeIName＝Corporate QA Policy

euOverviewURL＝http：//www.rsps.com.au/policy/qa.html

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

同样地，尽管图15示出了根据本发明将层次引入到子结构中的一个实例以表示企业实体中的一个相对复杂的对象，但是它同样示出了根据本发明将层次引入到子结构中以表示TModel中的一个相对复杂的对象的实例。图15的企业实体151同样适用于TModel，而TModel的多值要素被表示为TModel 151的子对象152，153。也有可能没有子对象，或者有更多子对象。

另一问题涉及以有效的方式来表示有关发布者断言(UDDI标准中描述的一个对象类)的数据。

根据本发明一个实施例，这可以通过将唯一字段表示为对象的属性以及对于要求的关系键值引用使用辅助类来解决。

发布者断言是一个表示两个企业实体之间的关系的对象。

发布者断言所需要的要素是其键值，去往和来自的企业和用户键值，状态以及关系。关系被规定为键值引用，并且作为辅助类存储到发布者断言条目。状态作为字符串存储，但是从完成状态(CompletionStatus)对象中提取它的可能值。所有的键值被表示为字符串。

set object-class UDDIObjectClass:406＝

{ #发布者断言-两个企业之间的关系

name＝euPublisherAssertion

subclass-of top

must-contain

euPublisherAssertionKey，

euFromBusinessKey，

euFromUserKey，

euToBusinesKey，

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-dcbaO9876543

euToUserKey＝98765432-5432-5432-5432-cbaO98765432

euPublisherAssertionStatus＝status:complete

注意，存在与该条目相关的辅助类；它是对象类euPublisherAssertionRelationshipKeyedReference，并且将规定被断言要插入到两个企业实体之间的关系。一个例子是：

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

euKeyedReferenceKey

}；

set object-class UDDIObjectClass:301＝

{ #企业实体种类键值引用-构成种类袋的集合

name＝euBusinessEntityCategoryKeyedReference

subclass-of euKeyedReference

must-contain

euBusinessEntityCategoryTModel，

euBusinessEntityCategoryKeyName，

euBusinessEntityCategoryKeyValue

}；

联系方式是一个复杂对象，表示各种信息。与企业实体十分相似，一个联系方式保存了各种复合的重复要素，必须使用子对象类。

作为联系方式对象的直接部分的数据要素是键值、联系方式所表示的人或角色的名称。可选的还有使用类型。

所有可能的其它要素是联系方式对象的子对象。它们是：地址(Address)(地址线对象的一个有序列表的父对象，每个都具有键值，使用类型，排序代码，以及TModel键值)；电话(Phone)(电话号码及使用类型)；电子邮件(E-mail)(电子邮件地址及使用类型)；以及描述(Description)(描述字符串及语言代码)

同样地，尽管附图15示例了根据本发明将层次引入到子结构中的一个实例，以表示企业实体中的一个相对复杂的对象，但是它同样示例了根据本发明将层次引入到于结构中以表示联系方式对象中的一个相对复杂的对象的实例。图15的企业实体151同样适用于联系方式对象，而联系方式对象的多值要素被表示为联系方式对象151的子对象152，153。也有可能没有子对象，或者有更多子对象。

另一个问题涉及以有效的方式来表示名称和描述(在UDDI标准中规定的)，以及允许快速搜索特定类型的名称或描述。

根据本发明实施例，系统创建一个抽象基类来表示名称，以及另一个抽象基类来表示描述，以及为每种期望的类型创建子类。当查找特定类型的名称时(例如，企业实体名称)搜索该子类的属性，当查找任何名称时美搜索抽象类。

几个主要对象(企业实体，企业服务等)都可以有多个名称和描述。其原因有多个。一个企业有多个名称的情形并不罕见，有一个正式名称，还会有一个或者多个俗称。而且，企业可以在不同的语言中使用不同的名称。一个名称被不当翻译的情形也很平常。例如，计算机公司富士通在许多英语国家中使用很多年英文名称Facom。在具有多种字符集的语言中该问题会进一步恶化。日本公司也许会有一个片假名的名称版本，还有一个平假名的名称版本。

由于以上的理由，对于单个对象来说名称和描述对象可能出现多次。每个实例都与一种语言代码有关。在UDDI版本3中有多个具有相同语言代码的实例(这在版本2中是不允许的)。

查找限定词会带来其它的问题。如前面指出的，需要UDDI搜索来支持大小写敏感和大小写不敏感的搜索，并且最好通过在X.500目录中把数据存储两次来解决。

以下的实例表示抽象类以及一个衍生类，euBusinessEntityName，被用作企业实体的名称的集合：

set object-class UDDIObjectClass:202＝

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

name＝euName

subclass-of top

must-contain

euNameKey

may-contain

euLanguage

}；

set object-class UDDIObjectClass:331＝

{ #企业实体的名称

name＝euBusinessEntityName

subclass-of euName

must-contain

euBusinessEntityNameValue，

euBusinessEntityNameValuelC

#从euName中继承euNameKey和euLanguage

}；

注意euBusinessEntityNameValue是包含了名称的大小写敏感版本的属性；而euBusinessEntityNameValuelC是被标记为“忽略大小写”的版本，因而对大小写不敏感。从抽象类中继承的euNameKey字段被用于名称的控制和排序，并且提供了唯一的命名属性。

名称对象的一个实例为：

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

euLanguage＝EN

euBusinessEntityNameValue＝McKenna′s Validation Systems

euBusinessEntityNameValuelC＝McKenna′s Validation Systems

同样地，尽管图15示出了根据本发明将层次引入到子结构中的一个实例以表示企业实体中的一个相对复杂的对象，但是它同样示出了根据本发明将层次引入到子结构中以表示抽象类中的一个相对复杂的对象的实例。图15的企业实体151同样适用于抽象类，而绑定模板的多值要素被表示为抽象类151的子对象152，153。也有可能没有子对象，或者有更多子对象。

另一个问题涉及创建一种有效的实施方式来满足只让得到许可的用户去修改那些在他/她控制之下的企业实体的技术要求。根据本发明的实施例，通过使得被用户控制的企业实体成为用户对象的孩子得以实现。这使得安全性更易于实现。

很重要的一点是确保一个发布用户只能修改他/她所拥有的信息。还有可能使用多种设计来完成。然而，最佳设计是立即清楚用户是否被授权发布一个项目：由给定用户控制的所有数据都位于该用户的子树中。

由于到企业实体中的所有查询都是从层次结构中用户层之上执行的，而没有丢失通用性和性能，因此该设计对于以企业实体为整体进行方便的访问没有影响。

另一个问题涉及创建发布者断言的有效实施方式，特别是findRelatedBusiness方法的实施方式。根据本发明的实施例，可以通过使得与一个企业有关的发布者断言成为该企业对象的子对象来实现。这样就消除了对该标准进行搜索的需要。

发布者断言的一种主要用途是find RelatedBusinesses查询。该查询规定了特定的企业实体，并且通过完成的发布者断言请求与该实体相关的所有企业实体的信息。通过一种将发布者断言置于与它相关的企业实体之下的层次可以简化和加速这种查询。这样做可以获得增强一致性的附加益处。当一个企业实体被删除时，所有与之相关的发布者断言也被删除。

另一问题涉及创建一种有效实施，使得允许用户修改受他/她控制的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-dcbaO9876543

euToUserKey＝98765432-5432-5432-5432-cbaO98765432

euPublisherAssertionStatus＝status:complete

euPublisherAssertionTModel＝uuid:807A2C6A-EE22-470D-ADC7-E0424A337C03

euPublisherAssertionKeyName＝wholly-owned subsidiary

euPublisherAssertionKeyValue＝parent-child

辅助对象类是euPublisherAssertionKeyReference，并且上面列出的后三个属性是该类的数据要素。

根据本发明的实施例，诸如计算机联合公司的eTrust^TM目录的目录可以被用于实施理想的企业UDDI注册平台。eTrust目录完全兼容LDAPv3，X.500电子目录，可以被用于巩固UDDI Web服务实施。eTrust目录允许UDDI实施平衡高度成熟的目录解决方案，这已经在大规模，企业关键的目录服务应用中得到验证。

eTrust目录还存在许多独特的特性使得它作为建立UDDI注册的平台及其具有吸引力。其中一些包括：安全特性、包括访问控制策略、规则、安全代理、相互认证、分布式认证、分布式SSL证书主题验证以及网络地址确认；分布和路由能力包括并行分布式搜索，负载分担、查询流以及最短路径路由；多主机复制方案，其组合了基于重放的机制(也成为多写入)的速度和效率与基于状态的恢复和调节；可用特性，包括数据库的热交换，网络的容错备援以及目录系统代理(DSA)备援；被认为非常快速的高速缓冲设计；以及配置特性，包括(数据类型，模式规则，安全性，知识等等的)动态配置，不受限的数据大小，常用信息完整性规则，扩展的管理控制以及交互的命令控制台。

eTrust目录提供了一个可靠的X.500目录解决方案。在这一可靠的基础之上能够实施UDDI语义桥，以便启动完全与标准兼容的UDDI注册。由于其下层的目录方案的能力，此处所公开的实施例可以获得灵活的安全性，分布以及管理性，而不需要对现有UDDI标准进行改变或者扩展。

本实施例的一个问题是处理如何在目录全异部分中存储的实体直接映射关系。

尽管UDDI数据结构是主要的层次，不同对象之间的交叉关系也会产生问题。

基本上有两种关系，即，替换名和交叉关系。根据本发明的一个实施例，通过使用别名的概念来寻址替换名可以解决这个问题。基本上这样作会添加(attach)一个外实体作为主实体的虚拟孩子。

本实施例使用唯一的键值来解决交叉关系的问题。这样做的效果是，与RDBME技术中的主/外键值系统十分相似，创建一个“关系指针”来模拟数据实体之间的关系，这些数据实体存在于一个分层次的目录系统内不相交的子树之间。

现在将描述根据本发明的实施例使用别名。第一种情况是通过实施UDDI企业服务投影非常清晰地表示出来。企业服务投影实际上是企业服务的替换名。企业服务投影是一种看起来属于企业A但实际上属于企业B并且由企业B定义的企业服务。

参考图5，企业A所拥有的企业服务51看起来也属于企业B。企业A对企业服务51所作的任何改变都会在投影的服务中反映出来，似乎是由企业B进行的。相似地，图过从注册中删除企业服务51，则它将不会再出现在企业A和企业B之下。另外，企业B既不能编辑也不能改变企业服务51。为了编辑以及其它的发布目的，只有企业A可以访问企业服务51。

可以利用目录别名系统来获得这一效果。企业服务51的别名被添加到企业实体B。别名是目录服务器的特殊标记，其意思实际上是“当有人看到这个别名时在这里向它们显示其它的条目”。

这意味着，当编辑原始服务时，在投影中的改变也是可见的。如果目录系统支持别名完整性(对于eTrust目录来说确实如此)，当服务被删除时，投影也会被自动删掉。

此外，目录服务器可以被配置用于在搜索被投影的企业服务时显示它两次，分别在每个父亲之下。当执行的搜索需要分别企业服务的父亲时这样做是有益的。

某些情形下要求在目录层次的不相交部分的中的对象维持一个关系。

其实例在绑定模板和Tmodel之间。Tmodel在整个UDDI中被用于各种目的。它们是分类键值，搜索标识符，(UDDI)关系描述符以及在本例中的技术规范“指纹”。被附加到一个绑定模板上的Tmodel描述了该绑定模板(见图8)所遵循的技术规范。例如，发布者可以附加一个Tmodel，断言它们的绑定模板遵循SOAP 1.1标准。

一个注册通常包含了Tmodel的有限集合，其中的许多将被数以百计甚至千计的绑定模板条目所引用。在某些情况下，注册将使用绑定模板的细节来返回任何附加的Tmodel的细节。

根据本发明的实施例，诸如在关系数据库系统中使用的主/外键值系统可以被适当地修改和应用。存储在注册中的每个Tmodel有其自己的唯一(主)键值。绑定模板通过增加一个与所需要的Tmodel的唯一键值匹配的本地(外)键值来引用Tmodel。图7实例了这种情况的一个实例。如果Tmodel数据需要与绑定模板一起返回，则服务器可以查询所关心的Tmodel。

图6示出了绑定模板和Tmodel之间的关系。

图7示出了Tmodel键值怎样创建两个实体之间的关系。

发布者断言是UDDI信息库的一个重要要素。如以上指出的。它为用户提供了发现哪个实体与感兴趣的企业实体相关以及如何相关的能力。

发布者断言被设计用于阻止滥用，因为只有当所涉及的企业实体的拥有者断言了该关系时被断言的关系才变得可见。这种保护是有代价的，它使得实施更加复杂，并且必须精心设计以避免性能降低。

一个问题是完整性。与其它UDDI结构相比，发布者断言具有复杂的生命周期。当企业实体的拥有者对该企业以及其与另一企业实体的关系做出断言时产生发布者断言。另一企业实体的拥有者可以请求一个状态报告，并且发现关于它们的企业已经做出了什么断言，或者它们可以在通道外被通知。另一企业实体的拥有者可以选择任一方式对两个企业实体之间的关系做出匹配的断言。当断言完成并且对用户可见时调用findRelatedBusiness。可以修改或删除一个或者两个断言，并且断言再次变成不完整的，而不再可见。此外，删除任一企业实体都将立即删掉断言。

可以用一种维护断言的完整性的方式来管理发布者断言对象。

希望企业实体的拥有者能够对由他控制的企业实体做出(已经删掉)断言。

本发明的实施例是以如下的假设为基础的，即，UDDI信息库是一个“以读为主(read-mostly)”存储，如专用于X.500目录的存储。为此，可以优化设计以获得更好的读取性能，甚至是以提高写操作的负担为代价。

设计一种被称为发布者断言的对象类来保存UDDI标准所需的数据之外的数据，因此，希望最优化搜索性能。该设计引入一个操作属性，其定义了发布者断言的状态。在写入到目录时确定断言的状态，并且以这种方式不需要在每次执行搜索是都进行确定。

本实施例还使用用户键值形式的指针。当发布者断言被写入到目录时，确定用于“去往的”和“来自的”企业的用户键值，并将其写入到对象中。这简化了getAssertionStatusReport查询，因为产生这种报告所需要的知识搜索发布者断言，其包含了产生该报告的人的用户键值。

与之对照，如果必须查询用户之下的所有企业键值，然后查找包含那些企业键值的发布者断言来产生报告，则将需要相当的工作量。

发布者断言的一种平常用途是发现与给定企业有关的那些企业。为了提供查询的良好性能，与企业有关的发布者断言作为该企业的子节点设置。

此外，每个断言的状态作为一个操作属性被记录在断言中。这样有可能只是查询其状态完全位于感兴趣的公司之下的发布者断言。由于该搜索将只是调用那些完成了的断言，因此简化了findRelatedBusinesses的搜索。

为了简化安全性，由一个用户控制的所有企业以及它们的出版者断言可以是该企业的帐户条目下的子节点。这种实施方式迫使访问控制只是允许用户访问该用户的帐户条目之下的子树。

注意表示该状态的操作属性由该UDDI实施方式进行管理。当用户发布一个已经被另一断言的企业断言过的断言时，UDDI实施将会更新该另一断言的状态，所述另一断言在另一企业的用户所控制的子树中。

作为存储两个发布者断言对象的替换实施例(在所涉及的两个企业实体之下各有一个)，在其自己的子树中提供单个的发布者断言对象。例如，可以在信息库对象之下提供发布者断言子树。在这种情形下当最初存储断言时，赋予其一个不完整状态(根据是哪一方做出断言可以是tokeyincomplete或者fromkeyincomplete)。如果发布者断言被一个互补用户断言，则状态变为完整的。如果发布者断言被二者之一删除，则状态又变成不完整的。如果发布者断言被双方删除，则删掉发布者断言对象。有益地，这样可以只有一个断言的拷贝，并且大部分的维护工作是对保存了断言状态的单个属性进行修改。

图12示意性地示例了根据本发明一个实施例的层次。该示意图示例了两种替换方案，其中发布者断言被置于企业实体和/或信息库对象之下。

图8示出了一种请求添加发布者断言的方法。在步骤S80，判断请求是否有效。如果无效(否，步骤S80)，则请求失败(步骤S92)。如果请求有效(是，不知道S80)，则判断请求是否来自我们的企业(步骤S82)。如果不是来自我们的企业(否，步骤S82)，则判断是否到我们的企业(步骤S84)。如果是到我们的企业(是，步骤S84)，判断该断言是否来自和由拥有者做出(步骤S86)。如果断言不是来自和由拥有者做出(否，步骤S86)，则写入不完整的断言(步骤S94)。如果断言来自并且由拥有者做出(是，步骤S86)，则写入完整断言(步骤S96)。返回到步骤S82，如果判断请求来自我们的企业(是，步骤S82)，判断它是否到我们的企业(步骤S88)。如果不是到我们的企业(否，步骤S88)，判断断言是否到拥有者并且由拥有者做出(步骤S90)。如果断言不是到拥有者和由拥有者做出(否，步骤S90)，写入不完整断言(步骤S94)。如果步骤S88的结果为是(到我们的企业)，或者步骤S90的结果为是(断言由拥有者做出并且到拥有者)，写入完整的断言(步骤S96)。

下一个问题处理在搜索操作期间怎样优化中间搜索结果集合，以便在考虑到目录存储介质限制的情况下，目录访问和迭代的存储器内操作得以最小化。实践中，目录条目可以以任意的顺序被存储和返回，并且目录结果太大而不能排序。

根据本发明的实施例，提供了一种与唯一结果排序方案耦合在一起的面向对象的存储器内数据存储系统，所述排序方案按照区别名称(Distinguished Name)对中间结果进行排序。这使得一个搜索返回许多类型的对象-BusinessEntity，BusinessServices等-并且仍然允许系统容易地构建正确的XML结构来返回数据给用户。注意Web服务交互在XML中。

现在将描述此类系统的描述。UDDI BusinessEntity以及在本发明中的任何数据要素都根据以下结构在目录中表示(部分地)：

BusinessEntity

·BusinessService

obindingTemplate

o BindingTemplate

o ServiceName

·BusinessService

o BindingTemplate

o ServiceName

·BusinessName

·BusinessDescription

注意ServiceName，BusinessName以及BusinessDescription已经结果本发明处理子结构和对象分割(Object Splitting)而进行了描述。

BusinessEntity恢复代码基于所需要的企业实体的唯一键值之下目录子树搜索。该搜索会返回找到的条目，以及子条目。目录标准不能保证返回条目的任何特定顺序-甚至子条目也不一定紧随其父条目。

因此，恢复代码按照区别名称对返回的条目进行排序。这确保了子条目按顺序在去父条目之后，并且可以轻松地区分父子关系。可以使用多种排序算法。如果条目是被部分排序，则所使用的排序算法应当具有高性能的特征。

用于结果构建的算法基本上是以“深度优先，从左向右遍历树(depth-first，left-to-right tree-walk)”。这在图论中也被称为“后序遍历”。

排序后的列表被传递给一个新的BusinessEntity对象的构造器方法。该对象可以是例如被设计用于表示一个UDDI企业实体的面向对象编程的结构。该BusinessEntity对象包含了代码，以根据该条目列表中提供的数据来“构建它自己”。代码迭代地通过列表，对于每个条目进行判断。可以理解该列表中的第一个条目应当是企业实体本身的主条目，并且一旦它发现了另一BusinessEntity，可以理解为已经完成了该结构-列表的有序性保证了这一点。一旦发现了BusinessService或者其它子条目，就为一个适当类型的对象生成实例，并且列表被传送到一个新的对象的构造器，以及一个指针，用于告诉该构造器在列表中的什么地方开始。

每个对象基本上包含相似的代码来处理其自身的构建，并且把任何子条目的构造委托给适当的子对象。

这样，只需要执行单个条目搜索，并且以有效的方式来处理获得的列表，每个条目只被处理一次。如果列表是任意顺序的，或者以其它方式排序，则必须对列表进行多通处理，才能根据获得的条目来构造一个UDDI层次。

构造的委托以及在层次中对不同编程对象的列表处理使得处理代码的尺寸相对较小，因而更加有效和快速。

附图9示例了编程构造(对象)，包括排序的条目列表的表示。判断在列表中是否还有其它项目。如果没有额外的项目(否，步骤S100)，退出进程(步骤S118)。如果存在额外的项目(是，步骤S100)，则检索列表中的下一项目(步骤S102)。然后判断该项目是否属于这种对象类型。如果项目属于这种对象类型(是，步骤S104)，则基于该项目来设置对象属性(步骤S106)，并且进程返回到步骤S100。如果不属于这种对象类型(否，步骤S104)，判断是否已经处理了一个该对象类型的项目(步骤S108)。如果还未处理该对象类型的项目(否，步骤S108)，则进程返回到步骤S100。如果已经处理了一个该对象类型的项目(是，步骤S108)，判断该项目是否为该对象的一个固有组件(例如Name，Description等等)。如果是一个固有组件(是，步骤S110)，则将该项目添加到该对象属性并且执行额外的处理(步骤S112)，并且处理返回到步骤S100。如果不是一个固有组件(否，步骤S110)，判断该项目是否为该对象的子对象(例如，BusinessService，当对象是BusinessEntity时)。如果它是一个子对象(是，步骤S114)，则系统为正确类型的对象生成实例，并将项目列表传递给构造器(步骤S116)，并且进程返回到步骤S100。如果不是一个子对象(否，步骤S114)，则进程返回到步骤S100。

以下是一个“真实世界(real world)”实例，表示期望返回的任意顺序的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＝1ba3034aeef7

38da00eef78599fe0004，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

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＝{#用于BusinessEntityname＝euBusinessEntityKeysyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:205＝{#用于BusinessService及其它name＝euParentBusinessKeysyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:206＝{#用于BusinessServicename＝euBusinessServiceKeysyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:207＝{#用于BindingTemplate及其它name＝euParentServiceKeysyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:208＝{#用于BindingTemplate

name＝euBindingTemplateKey

syntax＝caseIgnoreString

single-valued}；set attribute uddiAttributeType:209＝{#用于TModelname＝euTModelKeysyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:210＝{#用于PublisherAssertionname＝euPublisherAssertionKeysyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:211＝{#用于PublisherAssertionname＝euFromBusinessKeysyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:212＝{#用于PublisherAssertionname＝euFromUserKeysyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:213＝{#用于PubIisherAssertionname＝euToBusinessKeysyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:214＝{#用于PublisherAssertionname＝euToUserKeysyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:216＝{#用于DiscoveryURLname＝euDiscoveryURLKeysyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:217＝{#用于联系方式name＝euContactKeysyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:218＝{#用于Addressname＝euAddressKeysyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:219＝{#用于Addressname＝euAddressTModelKeysyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:220＝{#用于AddressLinename＝euAddressLineKeysyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:221＝{#用于Phonename＝euPhoneKeysyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:222＝{#用于Emailname＝euEmailKeysyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:223＝{#用于TmodelInstanceInfoname＝euInstanceTModelKeysyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:224＝{#用于Name及其所有导出类name＝euNameKeysyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:225＝{#用于Description及其所有导出类name＝euDescriptionKeysyntax＝caseIgnoreStringsingle-valued}；#----------------------------------------------------------------------------------#keyed references中使用的属性set attribute uddiAttributeType:301＝{#用于BusinessEntityCategoryname＝euBusinessEntityCategoryKRTModelsyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:302＝{#用于BusinessEntityCategoryname＝euBusinessEntityCategoryKRKeyNamesyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:303＝{#用于BusinessEntityCategoryname＝euBusinessEntityCategoryKRKeyValuesyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:304＝{#用于BusinessEntityIdentifiername＝euBusinessEntityIdentifierKRTModelsyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:305＝{#用于BusinessEntityIdentifiername＝euBusinessEntityIdentifierKRKeyNamesyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:306＝{#用于BusinessEntityIdentifiername＝euBusinessEntityIdentifierKRKeyValuesyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:307＝{#用于BusinessServiceCategoryname＝euBusinessServiceCategoryKRTModelsyntax＝caselgnoreStringsingle-valued}；set attribute uddiAttributeType:308＝{#用于BusinessServiceCategoryname＝euBusinessServiceCategoryKRKeyNamesyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:309＝{#用于BusinessServiceCategoryname＝euBusinessServiceCategoryKRKeyValuesyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:310＝{#用于TModelCategoryname＝euTModelCategoryKRTModelsyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:311＝{#用于TModelCategoryname＝euTModelCategoryKRKeyNamesyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:312＝{#用于TModelCategoryname＝euTModelCategoryKRKeyValuesyntax＝caseIgnoreString single-valued}；set attribute uddiAttributeType:313＝{#用于TModelIdentifiername＝euTModelIdentifierKRTModelsyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:314＝{#用于TModelIdentifiername＝euTModelIdentifierKRKeyNamesyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:315＝{#用于TModelIdentifiername＝euTModelIdentifierKRKeyValuesyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:316＝{#用于PublisherAssertionname＝euPublisherAssertionKRTModelsyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:317＝{#用于PublisherAssertionname＝euPublisherAssertionKRKeyName

syntax＝caseIgnoreString

single-valued}；set attribute uddiAttributeType:318＝{#用于PublisherAssertionname＝euPublisherAssertionKRKeyValuesyntax＝caseIgnoreStringsingle-valued}；#---------------------------------------------------------------------------#用于名称和描述的属性set attribute uddiAttributeType:361＝{#用于Business Entity Namename＝euBusinessEntityNameValuesyntax＝caseExactStringsingle-valued}；set attribute uddiAttributeType:381＝{#用于Business Entity Namename＝euBusinessEntityNameValuelCsyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:362＝{#用于Business Service Namename＝euBusinessServiceNameValuesyntax＝caseExactString single-valued}；set attribute uddiAttributeType:382＝{#用于Business Service Namename＝euBusinessServiceNameValueICsyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:363＝{#用于Business Entity Descriptionname＝euBusinessEntityDescriptionValuesyntax＝caseExactStringsingle-valued}；set attribute uddiAttributeType:383＝{#用于Business Entity Descriptionname＝euBusinessEntityDescriptionValueICsyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:364＝{#用于Business Service Deseriptionname＝euBusinessServiceDescriptionValuesyntax＝caseExactStringsingle-valued}；set attribute uddiAttributeType:384＝{#用于Business Service Descriptionname＝euBusinessServiceDescriptionValueIC syntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:365＝{#用于TModel Descriptionname＝euTModelDescriptionValuesyntax＝caseExactStringsingle-valued}；set attribute uddiAttributeType:385＝{#用于TModel Descriptionname＝euTModelDescriptionValueICsyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:366＝{#用于TModelInstance Info Descriptionname＝euTModelInstanceInfoDescriptionValuesyntax＝caseExactStringsingle-valued}；set attribute uddiAttributeType:386＝{#用于TModel Iustance Info Descriptionname＝euTModelInstanceInfoDescriptionValueICsyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:367＝{#用于TModel Instance Details Description

name＝euTModelInstanceDetailsDescriptionValue

syntax＝caseExactString

single-valued}；set attribute uddiAttributeType:387＝{#用于TModel Instance Details Descriptionname＝euTModelInstanceDetailsDescriptionValueICsyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:368＝{#用于Overview Doc Descriptionname＝euOverviewDocDescriptionValuesyntax＝caseExactStringsingle-valued}；set attribute uddiAttributeType:388＝{#用于Overview Doc Descriptionname＝euOveryiewDocDescription ValueICsyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:369＝{#用于Binding Template Descriptionname＝euBindingTemplateDescriptionValuesyntax＝caseExactStringsingle-valued}；set attribute uddiAttributeType:389＝{#用于Binding Template Descriptionname＝euBindingTemplateDescriptionValueICsyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:370＝{#用于Contact Descriptionname＝euContactDescription Valuesyntax＝caseExactStringsingle-valued}；set attribute uddiAttributeType:390＝{#用于Contact Descriptionname＝euContactDescriptionValueICsyntax＝caseIgnoreStringsingle-valued}；#----------------------------------------------------------------------------------#其他属性set attribute uddiAttributeType:400＝{#用于Name和Descriptionname＝euLanguagesyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:401＝{#用于Repository name＝euRepositoryNamesyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:402＝{#用于UserAccountname＝euUserNamesyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:403＝{#用于UserAccountname＝euCredentialssyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:404＝{#用于UserAccountname＝euAuthorizedNamesyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:405＝{#用于UserAccount和TModelname＝euHiddensyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:406＝{#用于BusinessEntity和TModelname＝euOperatorsyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:407＝{#用于Contactname＝euContactNamesyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:408＝{#用于discoveryURL、contact、address、phone、emailname＝euUserTypesyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:409＝{#用于phonename＝euPhoneNamesyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:419＝{#用于emailname＝euEmailAddress syntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:411＝{#用于addresssname＝euSortCodesyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:412＝{#用于BindingTemplate

name＝euHostingRedirector

syntax＝caseIgnoreString

single-valued}；set attribute uddiAttributeType:413＝{#用于BindingTemplatename＝euAccessControlsyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:414＝{#用于BindingTemplatename＝euAccessPointTypesyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:415＝{#用于TModelname＝euTModelNamesyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:416＝{#用于TModelname＝euOverviewURLsyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:417＝{#用于AddressLinename＝euAddressLineValuesyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:418＝{#用于tmodel instance infoname＝euInstanceParmssyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:420＝{#用于PublisherAssertionname＝euPublisherAssertionStatussyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:421＝{#用于DiscoveryURLname＝euDiscoveryURLValuesyntax＝caseIgnoreStringsingle-valued}；#-----------------------------------------------------------------------------------#抽象类——不能在目录中存储该类！set object-class uddiObjectClass:201＝{#用作所有关键字索引的父类的抽象类name＝euKeyedReferencesubclass-of topkind＝abstractmust-containeuKeyedReferenceKey}；#注意：关键字索引也应包含tModel键、键名称和键值，#每个导出类添加这些值，使得它们有不同的名称，#便于搜索如下属性的标准化名称：# euXXXTModel# euXXXKeyName# euXXXKeyValue#其中，XXX是对象的名称和关键字索引的目的}；set object-class uddiObjectClass:202＝{#用作所有名称的父类的抽象类 name＝euNamesubclass-of topkind＝abstractmust-containeuNameKeymay-containeuLanguage#注意：名称也应有一个包含特有名称的字符串，该字符串往往有一个#euXXXNameValue格式的名称，其中XXX是父对象的名称#这将使搜索效率最高#该属性还有另一个版本：添加IC的忽略大小写版本}；set object-class uddiObjectClass:203＝{#用作所有描述的父类的抽象类name＝euDescriptionsubclass-of topkind＝abstractmust-containeuDescriptionKeymay-contain

euLangu age#注意：描述也应有一个包含特有名称的字符串，该字符串往往有一个# euXXXDescriptionValue格式的名称，其中XXX是父对象的名称#这将使搜索效率最高#该属性还有另一个版本：添加IC的忽略大小写版本}；#---------------------------------------------------------------------------------------------#关键字索引类型set object-class uddiObjectClass:301＝{#BusinessEntityCategory关键字索引——其集合组成分类口袋name＝euBusinessEntityCategoryKRsubclass-of euKeyedReferencemust-containeuBusinessEntityCategoryKRKeyValuemay-containeuBusinessEntityCategoryKRTModeleuBusinessEntityCategoryKRKeyName}；set object-class uddiObjectClass:302＝{#BusinessEntityIdentifier关键字索引——其集合组成分类口袋name＝euBusinessEntityIdentifierKRsubclass-of euKeyedReferencemust-containeuBusinessEntityIdentifierKRKeyValuemay-containeuBusinessEntityIdentifierKRTModeleuBusinessEntityIdentifierKRKeyName}；set object-class uddiObjectClass:303＝{#BusinessServiceCategory关键字索引——其集合组成分类口袋name＝euBusinessServiceCategoryKRsubclass-of euKeyedReferencemust-containeuBusinessServiceCategoryKRKeyValuemay-contain

euBusinessServiceCategoryKRTModel

euBusinessServiceCategoryKRKeyName}；set object-class uddiObjectClass:304＝{#TModelCategory关键字索引——其集合组成分类口袋name＝euTModelCategoryKRsubclass-of euKeyedReferencemust-containeuTModelCategoryKRKeyValuemay-containeuTModelCategoryKRTModeleuTModelCategoryKRKeyName}；set object-class uddiObjectClass:305＝{#TModelIdentifier关键字索引——其集合组成口袋name＝euTModelIdentifierKRsubclass-of euKeyedReferencemust-containeuTModelIdentifierKRKeyValuemay-containeuTModelIdentifierKRTModeleuTModelIdentifierKRKeyName}；set object-class uddiObjectClass:306＝{#PublisherAssertion关键字索引——用作给出所关心的辅助类name＝euPublisherAssertionKRsubclass-of euKeyedReferencekind＝auxiliarymust-contain

euPublisherAssertionKRKeyValuemay-contain

euPublisherAssertionKRTModel

euPublisherAssertionKRKeyName}；#----------------------------------------------------------------------------------#名称和描述类型set object-class uddiObjectClass:331＝{#BusinessEntity的名称name＝euBusinessEntityNamesubclass-of euNamemust-containeuBusinessEntityNameValueeuBusinessEntityNameValueIC#从euName继承euNameKey和euLanguage}；set object-class uddiObjectClass:332＝{#BusinessService的名称name＝euBusinessServiceNamesubclass-of euNamemust-containeuBusinessServiceNameValueeuBusinessServiceNameValueIC#从euName继承euNameKey和euLanguage}；set object-class uddiObjectClass:341＝{#BusinessEntity的描述 name＝euBusinessEntityDescriptionsubclass-of euDescriptionmust-containeuBusinessEntityDescription ValueeuBusinessEntityDescription ValueIC#从euDescription继承euDescriptionKey和euLanguage}；set object-class uddiObjectClass:342＝{#BusinessService的描述name＝euBusinessServiceDescriptionsubclass-of euDescriptionmust-containeuBusinessServiceDescriptionValueeuBusinessServiceDescriptionValueIC#从euDescription继承euDescriptionKey和euLanguage}；set object-class uddiObjectClass:343＝{#TModel的描述name＝euTModelDescriptionsubclass-of euDescriptionmust-containeuTModelDescriptionValueeuTModelDescriptionValueIC#从euDescription继承euDescriptionKey和euLanguage}；set object-class uddiObjectClass:344＝{#TModelInstanceInfo的描述name＝euTModelInstanceInfoDescriptionsubclass-of euDescription must-contain

euTModelInstanceInfoDescriptionValue

euTModelInstanceInfoDescriptionValneIC#从euDescription继承euDescriptionKey和euLanguage}；set object-class uddiObjectClass:345＝{#TModelInstanceDetails的描述name＝euTModelInstanceDetailsDescriptionsubclass-of euDescriptionmust-containeuTModelInstanceDetailsDescriptionValneeuTModelInstanceDetailsDescriptionValueIC#从euDescription继承euDescriptionKey和euLanguage}；set object-class uddiObjectClass:346＝{#OveryiewDoc的描述name＝euOverviewDocDescriptionsubclass-of euDescriptionmust-containeuOverviewDocDescriptionValueeuOverviewDocDescriptionValueIC#从euDescription继承euDescriptionKey和euLanguage}；set object-class uddiObjectClass:347＝{#Contact的描述name＝euContactDescriptionsubclass-of euDescriptionmust-containeuContactDescriptionValue

euContactDescriptionValueIC#从euDescription继承euDescriptionKey和euLanguage}；set object-class uddiObjectClass:348＝{#BindingTemplate的描述name＝euBindingTemplateDescriptionsubclass-of euDescriptionmust-containeuBindingTemplateDescriptionValueeuBindingTemplateDescriptionValueIC#从euDescription继承euDescriptionKey和euLanguage}；#--------------------------------------------------------------------------------------------------#主要对象set object-class uddiObjectClass:400＝{#repository——用于把用户分组name＝euRepositorysubclass-of topmust-containeuRepositoryName}；set object-class uddiObjectClass:401＝{#UserAccount——用于存储用户信息name＝euUserAccountsubclass-of topmust-containeuUserKey， euUserName，euCredentialsmay-containeuAuthorizedName，euHidden#注意：该用户公布的所有BusinessEntity和TModel都是该对象的子类}；set object-class uddiObjectClass:402＝{#BusinessEntity——提供服务的实体的细节name＝euBusinessEntitysubclass-of topmust-containeuBusinessEntityKeymay-contain

euParentUserKey，euAuthorizedName，euOperator#注意：BusinessEntity的许多属性都存储在该对象的子对象里#尤其是那些出现不只一次的属性}；set object-class uddiObjectClass:403＝{#BusinessService——企业实体提供的服务的细节name＝euBusinessServicesubclass-of topmust-containeuBusinessServiceKeymay-containeuParentBusinessKey#注意：该服务的所有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＝euPublisherAssertionsubclass-oftopmust-contain

euPublisherAssertionKey，

euFromBusinessKey，

euFromUserKey，

euToBusinessKey，

euToUserKey，

euPublisherAssertionStatus#注意：关系将存储为类型euPublisherAssertionKeyedReference的辅助类#这允许直接搜索该辅助类的元素}；#--------------------------------------------------------------------------------#次要对象——包含重复数据的主要对象的大多数子对象set object-class uddiObjectClass:501＝{#DiscoveryURL——存在于企业实体之下name＝euDiscoveryURLsubclass-of topmust-containeuDiscoveryURLKey，euDiscoveryURLValue，euUseType}；set object-class uddiObjectClass:502＝{#Contact——存在于企业实体之下——十分复杂，可能有许多子对象name＝euContactsubclass-of topmust-containeuContactKey，euContactNamemay-containeuUseType}；set object-class uddiObjectClass:503＝{#Address——存在于Contact之下name＝euAddresssubclass-of topmust-containeuAddressKeymay-contain

euSortCode，

euAddressTModelKey，euUseType}；set object-class uddiObjectClass:504＝{#AddressLine——存在于Address之下，组成地址行name＝euAddressLinesubclass-of topmust-contain

euAddress LineKey，

euAddressLineValue}；set object-class uddiObjectClass:505＝{#Phone——存在于Contact之下name＝euPhonesubclass-of topmust-containeuPhoneKey，euPhoneNumbermay-containeuUseType}；set object-class uddiObjectClass:506＝{#Email——存在于Contact之下name＝euEmailsubclass-of topmust-containeuEmailKey，euEmailAddressmay-containeuUseType}；set object-class uddiObjectClass:507＝{#TModelInstanceInfo——存在于BindingTemplate之下name＝euTModelInstanceInfosubclass-of topmust-containeuInstanceTModelKeymay-containeuInstanceParms，euOverviewURL}；#-------------------------------------------------------------------------#名称绑定schema set name-binding uddiBinding:101＝{#绑定到顶部——最高层子对象name＝euRepository-topeuRepository allowable-parent topnamed-by euRepositoryName}；schema set name-binding uddiBinding:102＝{#绑定到顶部——最高层子对象name＝euUserAccount-topeuUserAccount allowable-parent topnamed-by euUserKey}；schema set name-binding uddiBinding:103＝{#绑定到euRepositoryname＝euUserAccount-euRepositoryeuUserAccount allowable-parent euRepositorynamed-by euUserKey}；schema set name-binding uddiBinding:104＝{#绑定TModel到“顶部”——用于标准TModel(不被用户公布)name＝euTModel-euRepositoryeuTModel allowable-parent euRepositorynamed-by euTModelKey}；schema set name-binding uddiBinding:105＝{#绑定到organization——最高层子对象name＝euRepository-organizationeuRepository allowable-parent organizationnamed-by euRepositoryName}；schema set name-binding uddiBinding:106＝{#考虑到可供选择的配置，把PublisherAssertion绑定到euRepositoryname＝euPublisherAssertion-euRepositoryeuPublisherAssertion allowable-parent euRepositorynamed-by euPublisherAssertionKey}；schema set name-binding uddiBinding:107＝{#绑定Repository层次——允许多层repository结构name＝euRepository-euRepositoryeuRepository allowable-parent euRepositorynamed-by euRepositoryName}；schema set name-binding uddiBinding:201＝{#把BusinessEntity绑定到UserAccount——第二层name＝euBusinessEntity-euUserAccounteuBusinessEntity allowable-parent euUserAccount

named-by euBusinessEntityKey}；schema set name-binding uddiBinding:202＝{#把TModel绑定到UserAccount——第二层name＝euTModel-euUserAccounteuTModel allowable-parent euUserAccountnamed-by euTModelKey}；schema set name-binding uddiBinding:301＝{#把服务绑定到企业——第三层name＝euBusinessService-euBusinessEntityeuBusinessService allowable-parent euBusinessEntitynamed-by euBusinessServiceKey}；schema set name-binding uddiBinding:302＝{#把联系方式绑定到企业——第三层name＝euContact-euBusinessEntityeuContact allowable-parent euBusinessEntitynamed-by euContactKey}；schema set name-binding uddiBinding:303＝{#把DiscoveryURL绑定到企业——第三层name＝euDiscoveryURL-euBusinessEntityeuDiscoveryURL allowable-parent euBusinessEntitynamed-by euDiscoveryURLKey}；schema set name-binding uddiBinding:304＝{#企业下方的Namename＝euBusinessEntityName-euBusinessEntity

euBusinessEntityName allowable-parent euBusinessEntity

named-by euNameKey}；schema set name-binding uddiBinding:305＝{#企业下方的Descriptionname＝euBusinessEntityDescription-euBusinessEntityeuBusinessEntityDescription allowable-parent euBusinessEntitynamed-by euDescriptionKey}；schema set name-binding uddiBinding:306＝{#企业下方的PublisherAssertionname＝euPublisherAssertion-euBusinessEntityeuPublisherAssertion allowable-parent euBusinessEntitynamed-by euPublisherAssertionKey}；schema set name-binding uddiBinding:307＝{#企业实体下方的Identifiername＝euBusinessEntityIdentifier-euBusinessEntityeuBusinessEntityIdentifier allowable-parent euBusinessEntitynamed-by euKeyedReferenceKey}；schema set name-binding uddiBinding:308＝{#企业下方的Categoryname＝euBusinessEntityCategory-euBusinessEntityeuBusinessEntityCategory allowable-parent euBusinessEntitynamed-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的Descriptionname＝euOverviewDocDescription-euTModeleuOverviewDocDescription allowable-parent euTModelnamed-by euDescriptionKey}；schema set name-binding uddiBinding:312＝{#TModel下方的Identifiername＝euTModelIdentifierKR-euTModeleuTModelIdentifierKR allowable-parent euTModelnamed-by euKeyedReferenceKey}；schema set name-binding uddiBinding:313＝{#TModel下方的Categoryname＝euTModelCategoryKR-euTModeleuTModelCategoryKR allowable-parent euTModelnamed-by euKeyedReferenceKey}；schema set name-binding uddiBinding:401＝{#联系方式下方的Addressname＝euAddress-euContacteuAddress allowable-parent euContactnamed-by euAddressKey}；schema set name-binding uddiBinding:402＝{#联系方式下方的电话号码name＝euPhone-euContacteuPhone allowable-parent euContactnamed-by euPhoneKey}；schema set name-binding uddiBinding:403＝{#联系方式下方的Emailname＝euEmail-euContacteuEmail allowable-parent euContactnamed-by euEmailKey}；schema set name-binding uddiBinding:404＝{#联系方式下方的描述name＝euContactDescription-euContacteuContactDescription allowable-parent euContactnamed-by euDescriptionKey}；schema set name-binding uddiBinding:409＝{#服务下方的Namename＝euBusinessServiceName-euBusinessServiceeuBusinessServiceName allowable-parent euBusinessServicenamed-by euNameKey}；schema set name-binding uddiBinding:410＝{#服务下方的Descriptionname＝euBusinessServiceDescription-euBusinessServiceeuBusinessServiceDescription allowable-parent euBusinessServicenamed-by euDescriptionKey}；schema set name-binding uddiBinding:411＝{#服务下方的Categoryname＝euBusinessServiceCategory-euBusinessServiceeuBusinessServiceCategory allowable-parent euBusinessServicenamed-by euKeyedReferenceKey}；schema set name-binding uddiBinding:412＝{#服务下方的BindingTemplatename＝euBindingTemplate-euBusinessServiceeuBindingTemplate allowable-parent euBusinessServicenamed-by euBindingTemplateKey}；schema set name-binding uddiBinding:501＝{#地址下方的AddressLinename＝euAddressLine-euAddresseuAddressLine allowable-parent euAddressnamed-by euAddressLineKey}；schema set name-binding uddiBinding:502＝{#BindingTemplate下方的Descriptionname＝euBindingTemplateDescription-euBindingTemplateeuBindingTemplateDescription allowable-parent euBindingTemplatenamed-by euDescriptionKey}；schema set name-binding uddiBinding:510＝{#BindingTemplate下方的Descriptionname＝euTModelInstanceInfo-euBindingTemplateeuTModelInstanceInfo allowable-parent euBindingTemplatenamed-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服务系统中的方法，包括：

在第一企业实体下，提供至少一个第一企业服务；以及

在第二企业实体下提供一个企业服务投影，该企业服务投影在第二企业服务实体下反映了所述至少一个第一企业服务。

2.权利要求1所述的方法，还包括表示一个替换名，包括利用目录技术的别名特征来表示该替换名。

3.权利要求2所述的方法，其中该别名特征是以一个别名对象实现的，该别名对象包含一个命名属性和一个别名对象名称，前者的值等于替换名，后者的值是该别名所指向的目录对象的名称。

4.一种包括计算机可执行代码的计算机记录介质，以便在Web服务系统中使用，包括：

用于在第一企业实体下提供至少一个第一企业服务的代码；以及

用于在第二企业实体下提供一个企业服务投影的代码，该企业服务投影在第二企业服务实体下反映了所述至少一个第一企业服务。

5.权利要求4所述的计算机记录介质，还包括用于表示一个替换名的代码，包括利用目录技术的别名特征来表示该替换名。

6.权利要求5中所述的计算机记录介质，其中该别名特征是以一个别名对象实现的，该别名对象包含一个命名属性和一个别名对象名称，前者的值等于替换名，后者的值是该别名所指向的目录对象的名称。