CN1678997A

CN1678997A - 网络服务装置和方法

Info

Publication number: CN1678997A
Application number: CNA038201682A
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: KR20050032616A; WO2004019233A8; CN1678992A; CA2495806A1; KR20050042168A; BR0313855A; AU2003268188A1; WO2004019232A2; EP1532524A2; WO2004019238A8; WO2004019234A2; CA2495803A1; WO2004019232A8; WO2004019232A9; AU2003270003A1; AU2003265649A1; BR0313869A; JP2005539295A; WO2004019236A2; US7861251B2

Abstract

一种网络服务目录，包括至少一个企业实体对象和至少一个用户对象，其中至少一个企业实体对象位于至少一个用户对象之下。

Description

网络服务装置和方法

相关技术

UDDI(通用描述、发现和集成)是一个标准集，其使得使用网络服务的应用程序能够快速、便捷且动态地交互作用。UDDI是用于建立一个与平台无关的开放式框架，用于通过因特网以及可操作的注册中心，描述服务、发现企业以及集成***服务。更多细节可参看网址 www.uddi.org。

UDDI注册为使用网络服务的结构化***提供有力的支持。图1a示意性地阐释了基本网络服务和UDDI概念。图1b示意性阐释了网络服务环境的简化协议栈。UDDI提供了网络服务信息的信息库，这本身也可以作为一种网络服务来提供。

UDDI允许应用程序公开其如何通过网络相互作用。每种“网络服务”是自描述、自包容、模块化单元的应用程序逻辑，通过网络连接为其他应用程序提供某些***功能。应用程序借助于普遍的网络协议和数据格式访问网络服务，而不必考虑各个网络服务是如何实现的。网络服务可以和其他网络服务结合和匹配，来执行较大的工作流程或商业企业。

UDDI标准描述了一个特定用途的信息库，用来管理网络服务类型、商业组织的描述以及如何调用网络服务的细节。该标准不必详细说明如何执行标准，也不必说明其实现是否应该包括使用了数据库、目录或任何其他介质的存储器。

制定UDDI标准的组织创办的网址上( http：//www.uddi.org/faqs.html)有许多常见问题(FAQ)。其中一个问题是：“能够建立一个或基于LDAP的UDDI注册吗？”网站给出的答案中证实在UDDI和目录之间没有明确的关系。UDDI说明书没有规定注册执行细节。UDDI说明书定义了一种基于XML的数据模型以及一组SOAP APIs来访问和使用数据模型。SOAP APIs定义了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，如授权名称，企业键，以及名称。名称有一个或多个名称字段133，如“文本”或“名称”自身中固有的。还有“语言”。此处可能有一个或多个该类字段133，

●如何相对快速搜索重复要素所包含的特定项目，

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

●如何有效地处理UDDI对象以及其所有相关信息的删除，以及

●如何优化搜索过程中获得的中间搜索结果的结构，考虑到目录存储介质的限制，从而把目录访问和重复访问存储器的操作最小化。实际中，可以存储目录条目并以随机顺序返回，且目录结果太大以至于不能对其排序，

●如何有效地表示与发行者声明相关的数据，

●如何创建有效的发行者声明的实现方法，尤其是考虑到寻找相关企业的实现方法，

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

●如何处理发行者声明的有效性，

●如何限制创建的声明以及删除企业实体所有者生成的企业实体，

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

●如何定义属性和对象来增强搜索性能。

现在已经提出了许多种UDDI模式。但是没有一个模式解决了至少上述问题。例如一种模式提出了相对简单化地把UDDI对象映射到目录对象，而没有考虑复杂性和优化以获得有效的商业实现。但仍然不清楚许多UDDI服务(尤其是find_series)如何能够在该模式下有效实现。

例如，图14示意性地阐释了企业实体中相对复杂对象的Novell表示形式。企业实体对象141，包括例如一系列属性142，分别具有“类型”和“数值”。如图所示，授权名字的值是“Bill”，企业键的值是“890.obale.890......”，而名称有多个值143，144即

en#CA

IN#CATS

UDDI(图13)和Novell(图14)实例中的表示形式不是用于网络服务的有效表示形式。

因此需要解决上述的一般问题和其他问题，以提供一种相对可扩展的、有效且可靠的基于目录的UDDI实现。

发明内容

网络服务目录包括至少一个企业实体对象以及至少一个用户对象，其中至少一个企业实体对象设置在至少一个用户对象之下。

网络服务***包括一个其中可以对企业进行注册的注册中，该注册中心包括一个有层次结构的目录，该目录包括至少一个企业实体对象和至少一个用户对象，该企业实体对象被设置在至少一个用户对象之下，以及一个存储***，其用于存储商业信息，并可通过层次结构目录访问。

附图说明

参照优选实施例的以下描述并结合附图，能够更好地理解本发明的其他目标、优点及方面，其中：

图1a示意性地阐释了一些网络服务和UDDI概念；

图1b示意性地阐释了一个网络服务环境下的简化协议栈；

图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，LAN接口192，网络控制器194，内部总线196，及一个或多个输入设备198，例如键盘、鼠标等。如图所示，***180可以通过链路202连接到数据存储设备，例如硬盘200。

下面概括描述本发明的实施例的几个突出特征以及其具有的一些优点。

根据本发明的实施例，在用户层之上创建一个信息库层，这样可以在各个不同的服务器上设置一个信息库。这种信息库层包括一个或多个目录节点，它们共同构成了目录前缀。这也认为是信息库的“域”或“名称”。这样做的优点是能够提供一个单独的空间来保存关于域的信息。节点的名称表示这一目录的前缀。

可创建一个用户对象来保存表示UDDI帐户的数据。这样做的优点是能够提供一个单独的空间来保存关于用户/帐户的信息。

企业实体对象位于用户对象之下，商业服务对象位于企业实体对象之下，而绑定模板对象位于商业服务对象之下。这样做的优点是用户对象层之上的信息库或‘域’层能够将多个信息库互相传递或逻辑连接。域层可设置成多个级别，例如不同的国家，AU、US、EP等；或按大洲进行组织。

另一个优点是此特性可以使用X500目录的分布特性来实现。例如为了实现该特征，可以在虚拟目录树的顶端设置“世界(World)”或“企业(Corporation)”节点，而在各个UDDI子树(UDDI名称空间)的顶端设置一个名称唯一的节点。这些“节点”前缀对用户是不可见的，能允许UDDI信息库对目录分布进行平衡。

根据本发明的一个实施例，企业实体对象可以是用户对象的子对象(child)。企业实体、商业服务和绑定模板层次结构之上的用户/帐户使每个用户拥有自己的子树。这样能提高可管理性和安全性。容易限制用户仅能修改和/或控制他们自己的子树。使用目录子树搜索操作同样能提高性能。

根据一个实施例，用户定义的TModel可以作为此用户对象的子对象，因此更容易实现安全性。因为用户仅能修改和/或控制其自身的子树，从而加强了可管理性和安全性。使用目录子树搜索操作同样能提高性能。

本发明的一个实施例表示了使用X.500/LDAP目录技术的UDDI环境的“映射”。尤其是X.500和LDAP目录技术的层次结构已证明适用于UDDI环境。仔细设计附加的要素(例如用户对象)使得层次结构更适合UDDI环境的需求。

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

网络服务最初被设计为企业、合伙人、顾客、供应商等组织之间的服务。本文中，UDDI被设计为这些组织提供的服务的一个信息库。

现在很明显网络服务和UDDI在企业内是很有用的，可以用于在组织内集成应用程序。同样很明显网络服务和UDDI能用于集成特定商家的产品集内的产品。其同样适用于商业领域之外，例如政府部门、大型教育机构，以及许多非企业实体的其他情况中。

下列描述尽管也是关于企业方面，它对于任何类型的环境具有同等的适用性，尤其适用于上述类型的环境。

企业UDDI注册是一种能在企业内配置的服务，用于发布内部消费的信息和服务。另外，企业UDDI服务可以进行平衡以提供其他功能，如用于分布应用程序的配置发现。

目前期望网络服务能在企业内部以及合作伙伴之间快速和容易地集成商业过程。有效应用网络服务的一个要素是公共的UDDI注册，其能够让软件要素动态发现并通过因特网连接到适合的服务。网络服务也能够在商业公司内集成商业进程。此种情况下，UDDI注册中心变成组织的基础结构的一部分(例如一个重要的企业应用程序)，且因此提供了最高级别的安全性、性能、可靠性和易管理性。目录技术提供了一个理想的基础架构来满足企业UDDI注册最苛刻的要求。

企业UDDI注册可以定义成能够为UDDI提供标准兼容支持的注册，但除此之外还定义了四个用于配置的领域。这些区域包括安全性以限制仅允许授权用户访问，分布性以支持大规模配置，可管理性用于实际生产***，以及可用性以满足服务级别协定。

有力的安全性是一个对特定企业配置的重要要求。公共UDDI注册的唯一用途是帮助任何人都能发现可用的服务。UDDI注册的唯一用途使得合适的人发现这些服务。这是一个重要的区别。

因特网UDDI注册被认为不适合用于企业内的网络服务配置。例如与工资单***或员工福利管理程序接口的网络服务的定义，不能传递到因特网UDDI注册。

安全性需求也意味着即使内部配置的UDDI注册也能提供有力的访问控制。这是因为UDDI注册基本上具备一个指南，指示可以做什么以及如何做。UDDI注册能够对任何可用的网络服务提供商业级的说明，以及对完整定义了这些服务的可编程接口的WSDL提供指导。这为程序开发者和黑客都提供了一个高效工具。

因此期望能限制访问用于金融敏感或机密(例如医疗记录)***的接口定义。即使在开发组织内部，对于这些授权用户限制访问特殊网络服务的信息也是很明智的。

企业内部使用不安全的UDDI注册，或通过外部网的选定商业伙伴，是非常冒险的。由于有免费下载工具，具有很低专业水平的人也可以访问和使用网络服务。任何实际的企业方案都能实现标准UDDI服务，同时具有透明的控制访问网络服务信息的能力。

考虑到分布性，在许多情况下，可以小规模进行UDDI注册的初期配置。但是随着网络服务的需求日益增长，大规模配置将变得更加普遍。另外由于发现UDDI注册的新功能会加速注册的使用和配置。

地理分布组织内的较大规模的实现和使用能驱使一个组织内实现多个UDDI注册。解决分布式注册的方案使得其对任意单个注册很苛刻，要能够动态连接到其他注册以满足它们的请求。一旦确定，注册中心之间的通信可以越过防火墙，延伸到值得信任的商业伙伴的注册中心，或者甚至是因特网UDDI注册。

目前认为有两种基本的方法来解决注册中心之间通信的需求。一种方法是复制，其中同一个条目的名称空间位于多个服务器上。另一种方法是分布，其中互连的服务器有不同的条目的名称空间，但作为一个逻辑服务进行操作。

尽管这两种方法常被误认为是相似的，但实际上是完全不同的。

在复制方法中，信息在每个需要查询的服务器上被复制。这是一种相对简单，甚至过于简单的方案，但它引入了同步更新的需求，且随着注册数量和内容的增长，这肯定会增加网络拥塞。复制技术更适用的环境是服务器数量较少，信息量少而且较少改变的环境。对于企业配置，复制对于保持容错备援(fail-over)环境中的备份信息库是非常有用的。使用复制技术很难保持地理上或功能上分布式服务器的同步。

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

对于企业UDDI注册，分布通常在两个的环境下使用。第一个是用在带有地理上分离的办公室的组织，其中每个办公室分别产生新的UDDI条目和使用UDDI服务。虽然能够运行一个单一的集中式UDDI注册中心，但带宽限制和时区差别使得这种方案很难实现。

分布注册提供了一种灵活的，可扩展的方案。在这种情况下，每个参与的办公室有一个单独的注册中心，而各个注册中心把其他注册中心看作其自身内容的逻辑部分。注册服务考虑到所有的连接细节，而顾客不需要考虑地理因素。

第二种情况发生在当企业需要将自身内部的UDDI***连接到可信赖的合作伙伴，或者是公共网络注册时。尤其在公共注册的情况下，复制是难以实现的。网络运营商可能不愿意把其注册部分复制到企业的内部注册中心去。分布方法再次可以解决该问题。现在还没有用于分布方面的UDDI标准，而且复制方案也认为是十分复杂。应当有一种方案能够具有UDDI分布方法的优点，而且不需要对标准进行修改。

考虑到可管理性，作为企业内部实现关键任务功能的要素，UDDI应该满足性能和可靠性的要求。其不应该仅作为开发者的一个有力工具。客户端的读取访问将是UDDI注册的最常见以及最关键的操作。对性能进行优化以满足最大吞吐量，而搜索查询的响应时间不应受较复杂搜索的影响。随着注册大小和复杂性的增加不会损害***性能。作为UDDI注册基础的数据存储应该有工业实用性和完全支持交易以及自动修复。另外，UDDI服务器应具有较高的可用性和支持特性如网络容错备援(fail-over)和热备份。***管理者应该具有能力使得UDDI易于维护、监视和控制。这些能力包括能改变控制、规则和设置的动态配置，而不需离线服务，在线备份和调整用于较高的可用性，管理控制以停止注册中心的“搜索(trawling)”以及防止拒绝服务的攻击，通过SNMP或其他类型的报警机制进行监控，为安全、统计、查询以及信息更新而对单独的日志文件进行审核及诊断，以及支持复制、分布和路由的配置选项。

已经提出了许多基于开发者的UDDI注册。这些注册能够为小型的开发团队提供有用的特性，但并不是真正的产品级的***。网络服务开发目前飞快增长，从而产生了相应的对企业级注册的需求，这种注册能够快速升级以满足日益增长的网络服务配置。

UDDI注册提供了一种服务。这种服务依赖于许多应用程序。在线商务的情况下，服务始终存在可能是非常重要的。例如UDDI注册需要提供99.9％可用性的服务水平协定。为了能达到这种可用性，UDDI注册可以在两个或多个机器上复制，并且提供机制确保这些机器能保持同步，如果某些机器不可用，任何输入的查询能够自动路由至一台可用的机器。

前面已经指出，UDDI认为与电话目录服务十分类似。因此信息存储的目录模型是一个用于在其上建立UDDI注册服务的非常好的基础。目录模型已经为基于目录服务的特定需求进行了演变和开发，具有企业级开发所需的安全性、可扩展性和可靠性。

在应用程序结构中，以上描述的大多数项目是在服务层实现的，而不是在数据存储层实现的。关系数据库(RDBMS)是很普通的工具包，许多不同种类的应用程序都可以构建在其上。RDBMS致力于提供可靠的数据访问功能，而不是终端应用程序需要的额外服务功能。

图3中显示的目录服务结构阐释了服务层31与其他要素相分离。将接口功能封装到服务层31产生了可重复使用的服务基础结构要素。一个非常完美的实例就是网络服务器。网络服务器提供了一系列功能(HTTP访问、CGI处理等等)，这些功能共同组成了一种有用的服务，其能够嵌入一个独立的组件。同样，已经将目录服务模型开发成为一种特定类型的应用程序提供其所需功能。目录技术为鉴定和授权领域的许多关键的应用提供了基础。

UDDI认为与另一种类型的目录服务相似。UDDI造成的许多实现问题可以通过目录技术来解决。例如对于UDDI电话目录操作中很普遍的非常有效的查找和搜索操作，需要对UDDI进行优化。

已经引起注意的是如果企业中成功配置了UDDI服务，UDDI服务需要提供很强的安全性、分布性和可管理性。这与已经被嵌入企业级目录服务的方案非常相似。

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

目录服务结构提供了一种用于实现企业UDDI注册的最优的工具。二者的结合提供了成功注册所必需的特性。图4中示意性阐释的UDDI服务表示了实现这种基础构造的要素。UDDI语义桥(SEMANTIC BRIDGE)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目录中使用的，是Computer Associates 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”的公司，其提供了较宽的网络服务的范围，所有名称中包括“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标准中定义明确的要素之一，并且其需要认真的设计。不适当的实现方法可能导致很差的性能。

因为发行者声明的最普遍的用途是寻找相应的企业API，其搜索与一个特定的企业实体相关的所有完备的发行者声明，在企业实体之下设置每个声明是很好的方案。

通过计算声明的状态，并把其存储在声明对象中，这样能够限制对完备的发行者声明的搜索。这意味着返回的结果不会包含要删除的伪参考。

把相关性对象存为辅助类允许搜索能消除任何有不需要的相关性的声明。如果相关性被存成一个子对象，就不能生成一个单一的能解决相关性和声明完备状态的搜索条件。

UDDI键存在时可以为对象命名。UDDI为许多重要的对象类定义了键，这些键必须保证是唯一的。这意味着这些键可以用作这些对象的命名属性。UDDI键作为命名属性意味着不需要解决命名冲突的问题—如果缺省名称被用于一个企业实体的命名属性时，就需要尝试解决命名冲突的问题。

UDDI键不存在时也可以提供键来命名。并非所有的UDDI对象都有已定义的键。一个实例就是发行者声明。为此，本***使用与UDDI定义键相同的算法提供了一种键。这种重用思想意味着为其他对象写的编码和结构也可以再利用。

如果一系列UDDI对象是另一个对象的子对象，则这些子对象的顺序是很重要的(例如地址行)，分配给予对象的键按照数值单调增加，这样把键排序就能产生所期望的顺序。这样简化了确保期望顺序的程序。

在实际过程中，希望键能按照little-endian的方式变化。即键的最左面的字节变化最快，因为这在X.500目录用作数据库时进行索引会产生最好的性能。

UDDI标准在一些主要对象类型内部定义了大量的子结构。在许多情况下这些子结构是可选而且可重复的(在同一对象内可能出现零次、一次或不止一次)。一个简单的例子是名称子结构，包含一个字符串(名称)和一个语言标识符。X.500方案定义不支持使用结构化属性，因此不能直接对子结构立即清楚地映射。现在有几种方法可以在X.500模式中实现子结构。

一种方法是利用某些类型的分隔符来区分不同的要素，从而把子结构的所有要素链接成一个单个属性。这也许不是最优的设计选择，因为其失去了独立检索或搜索这些要素的能力，并且其增加了处理数据时的复杂度。

本***中，需要选择特定方案来表示子结构，从而使得性能和可管理性最优。本发明公开的方案使用一种或多种不同的技术在目录内表示子结构。这些技术可以归结为3类：

一类技术是许多子结构被当作子对象进行处理。名称是一个较好的实例：企业实体名称被存储为企业实体的子对象。另一个实例是描述，其中一个单独的企业描述对象是企业实体对象的子对象。图15对本发明这一方面的实施例进行了阐释，并在下面详细描述。

另一类技术是展平/合并。当至少和另一个对象有关系时，该属性可以合并成一个对象。在这种情况下，由于两个对象结合成一个对象，层次结构被认为展开了。由于新的对象包括了合并对象的属性并集，所以称新的对象是合并的。最好把关系对象的内容提升为父对象。

例如图16示意性地显示了一种UDDI关系图的表示形式。图17示意性地显示了一种目录层次结构框图，其中该目录层次结构是由UDDI对象展开形成的。

通过说明，图16阐释了将对象162和对象163联系起来的对象161。

根据本发明的实施例，如果有一对一的关系，则‘子对象’的层次能够提升。换句话说，层次结构的一部分可以被折叠或展平，对象可以合并。图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下面，可能有一个或多个TModel 123和一个或多个企业实体(BE)124。在各个企业实体124下面，可能有一个或多个发行者声明(PA)125，一个或多个商业服务(BS)126以及一个或多个服务投影(SP)127。在各个企业服务(BS)126下面，可能有一个或多个绑定模板(BT)128。按照特定实现方法的要求来设置别名。例如服务投影对象(图12中所示的三角形)可能源于企业实体对象的别名。

图12中表示的模式方案的优点根据本发明的整体说明变得更清楚。

发行者声明位于其所引用的企业实体下面，因为它们最常用于find_RelatedBusiness请求内容中，其中规定了一个企业键，并通过发行者声明搜寻所有和该键相关的企业。本***定位了特定的企业，然后读取位于其下的所有(已建立的)发行者声明。这是定位相关声明的快速和有效的方法。

这种方法的优点是能够快速和高效地搜索。其同样能很容易地维护数据完整性。例如当删除一个企业时，也自动删除了所有发行者声明。

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”(最左边的部分变化最快)，那么数据趋于展开，因此索引能提供最优的性能。相反，如果数据是重复的，索引可能就不是十分有效。使用UUID(通用唯一标识符)算法能产生“little endian”特性。这样做的优点是能够将目录性能增强到最大。

可以给派生对象添加键。当可重复的数据要素加入到子对象时，需要添加一个命名属性，其构成了它的DN的最后一部分。在一个目录中，命名属性不同于其同胞对象，因为同一个父对象不存在两个名称相同的子对象。

可以使用两种类型的键。对于不要求顺序的子对象，使用UUID算法，因为其保证独一无二。在顺序很重要的地方，使用具有单调增加特性的键来保证顺序。

UDDI标准中，企业实体能提供两类服务：控制服务(信息库中用子对象描述)，以及为这些对象提供一个接口，但实际上由另一个企业实体提供的服务。后者在公开的UDDI信息库用别名来描述。别名能准确地提供正确的特征。例如，如果原始对象(服务)由其所有者做某种变化(也许添加了另一个绑定模板)，那么通过别名参考的对象也“变化”。并且对于一个服务，企业实体之下的任何搜索都会产生实名和别名服务。

例如，别名可被用作服务投影，其中企业可以指向另一个企业之下定义的一个服务。

这样做的优点是平衡别名能够自动提供基本包括“可替换名称”的功能。另外，如果目录能支持别名完整性，那么如果删除了原始服务，任何投影也自动删除。

UDDI标准中有许多地方不希望被其他对象直接引用，而希望通过一个中间步骤—实现—例如TModel实例信息的情况下，或者发行者声明中引用企业实体时。在这些情况下，别名会把编码复杂化。因此本***用对象的引用来代替别名。因为根据一个实施例，本***能保证每个对象有一个唯一的键，那么键确切地表现为引用，有时被认为是一个“外来”键。

使用辅助对象类能实现属性分组。在处理发行者声明时，需要使用三个能唯一识别发行者声明的属性，来定位发行者声明：两个企业实体键，以及它们之间的相关性。但是该相关性被规定为关键字索引，其自身有三个不同的属性：TModel键，键名称以及键值。一种方法是把这种相关性存为发行者声明的子对象。但是这不能对特定的发行者声明作最有效的搜索。通过把这种相关性关键字索引作为发行者声明条目的辅助类，能够一次搜索中搜索全部五个属性，并且因此准确地提取出所需的发行者声明对象。

本发明的一种方案使用了常规的面向对象的设计技术，例如产生具有同一属性名称的全部关键字索引。但是这种方案很难并且很昂贵，为了分离例如一个企业实体类别关键字索引，且避免将其与TModel类别关键字索引相混淆。同样其必需在滤波器中包括对象类别术语，且这些术语是弱的(信息库中有较高的重复率)。

例如为各种不同类型的关键字索引分配一种不同的对象类和不同的属性名称，意味着对于特定属性名称的任何搜索必须包含该对象类。同样意味着目录服务器能构造一个检索，其中仅包含对于所需的特定类型的条目。这种检索会较小，因此也更快。

例如，类似“euBusinessEntityName＝Smith”的搜索会查阅euBusinessEntityName的索引，因此不会被任何称为euTModelName的属性中包含Smith的条目所混淆。

同样可能需要UDDI标准范围之外的工具。这种工具需要提供UDDI标准规定之外的访问方法。为了使用这些工具，本发明定义了抽象类，这些类绑定了表示单个UDDI概念的所有对象类。这样定义了能考虑所有名称或所有关键字索引的搜索。

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

UDDI标准规定了能够用敏感性的和非敏感性的方法来搜索名称。可以用非敏感性的索引来处理，然后获取条目并敏感性地对其进行检验，但这种方法会降低性能。在这种情况下最好定义一个包含相同数据的阴影域，但是以不同方式被检索。同样，阴影属性也可用于语言上的不同，如变音符标记。

例如，euBusinessEntityName对象类包含各个名称的两份拷贝。第一个版本的索引是非敏感性，同时第二个版本的索引是敏感性。不管请求什么行为，都能最优地构造搜索滤波器。

信息库中的各个属性(除了对象类)都是单值的。这样能够使目录构造更有效地索引，并在搜索过程中提供更好的性能。

这样也消除了在搜索过程中出现伪匹配(false positive)结果的可能性。例如考虑搜索一个以“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)、名称、以及一个数据类型。对象类定义规定了一个作为整体操作的一些属性的集合，并为其赋予一个唯一的标识符(OID)，名称以及一个属性列表；属性可能是要求的/或可选的。名称绑定规定了可能的层次结构的一部分。名称绑定规定了能存储在另一个对象类之下的对象类，并规定了在本文中用于为子对象命名的子对象的一个或多个属性。

还有很多需要附加设计的查找限定词。如一个敏感性的查找限定词能够有效地同时用敏感性的和非敏感性的方法搜索文本数据。根据本发明的一个实施例，通过在对象中提供不同索引的附加字段解决了敏感性问题。

根据该实施例，文本数据以caseExactString类型的属性和caseIgnoreString类型的属性存储两次。然后查找限定词能确定搜索哪一字段，从而产生了最好的性能。

例如，如果企业实体的名称类似“Mckenna’s Iron FoundryServices”，那么该字符串将会存储两次，一次存在敏感性索引的字段里，一次存储在非敏感性索引的字段里—存储的数据是相同的，但是下层目录产生的索引是不同的。

另一个要点是关于如何有效地实现服务投影。根据本发明的一个实施例，可以用X.500别名特性来解决。现在有许多方法可以处理服务投影问题。本发明的实施例是通过目录别名来处理。这是一种特殊有效的处理服务投影的方法。这样能够保证投影和基础服务的连续性，因为是直接通过别名访问基础服务。其也保证了一旦删除了基础服务，投影就会消失，因此确保了连续性。

例如，如果名为Williams Accounting Service的企业实体发布了一种名为总帐核对(Gereral Ledger Cross-Check)的网络服务，现在希望能在名为Williams Auditing Service的另一个企业实体下提供同样的服务，这可以通过在第二个企业实体之下设置一个别名条目来实现。希望列出Williams Auditing Service提供的所有服务的查询者会发现总帐核对服务，因为其能够发现Williams Auditing Service直接提供的任何服务。

另一个要点是关于如何有效地实现键。根据本发明的一个实施例，这可以使用用于外部键、以及对顺序无要求的键的UUID来解决。顺序重要的地方可以使用连续的数字。尽管键用字符串表示，但它们并不是真正的文本数据。这些键相对来说没有敏感性或变音符标记。

外部可见的键遵循一个规则集。当实现一个和UDDI标准版本2兼容的信息库时，依照ISO-11578，其能够保持UUID。当实现一个和UDDI标准的版本3兼容的库时，其能保持遵循该版本说明书中设置的规则的键字符串。

需要注意的是内部使用的用于连接各要素的键遵循另一个规则集。顺序不重要的键使用UUID算法。顺序重要的键使用连续数字。

例如，表示名为Williams Auditing Service的企业实体的类别口袋中一个元素的关键字索引，可能引用的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

euRepositoryName

}

分布是大规模目录配置中一个重要概念，其能够使多个节点同时共享数据，而不会占用大量带宽和复制引起的同步问题。

在一个实施例中，‘eTrust’UDDI用下层eTrust目录服务器的性能来支持分布功能，为此本方案相应地这样构造：允许在树结构的顶端有一个或多个虚拟‘域’节点，并且在每个节点子树的顶端有唯一的标识符或名称(见下面的UDDI方案)。

而且，可以将eTrust UDDI服务器配置为‘分布式感知的’。可以规定两个独立的目录前缀—一个前缀用于搜索和读取，而另一个用于添加条目。为了开发一个分布式服务器，下层eTrust服务器代理按照eTrust目录管理指南配置成分布式的。每个独立的eTrust UDDI节点都有一个唯一的节点名称。各个节点的搜索/读取前缀被设置成“世界”或“企业”节点名称。各个节点的添加前缀则设置成该节点的唯一节点名称。

这样，尽管每个节点把条目添加到其所有的目录信息库，但在所有节点中搜索条目却是借助于X500目录的分布特征实现的。

一个信息库对象的实例可能是：

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 uddiObjectClass：402＝

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

name＝euBusinessEntity

subclass-of top

must-contain

euBusinessEntityKey

may-contain

euParentUserKey，

euAuthorizedName，

}；

企业实体的子对象可能是：名称(包含名称字符串和语言编码的键控排序对象)；描述(包含描述字符串和语言编码的键控排序对象)；联系方式(一个复杂对象—稍后在下面描述)；发现URL(包含URL字符串和用途类型的键控对象)；通过选择对象类而标记为类别或标识符信息的关键字索引；以及商业服务(下面将描述)。

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

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

euParentUserKey＝2345678-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＝euBindingemplate

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对象的一部分)、用户键以及一个隐藏标志。

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

set object-class uddiObjectClass：405＝

{#TModel-涉及一种思想

name＝euTModel

subclass-of top

must-contain

euTModelKey，

euTModelName

may-contain

euAuthorizedName，

euOperator，

euOverviewURL，

euParentUserKey，

euHidden

}；

可能的子对象是：描述(包含描述字符串和语言编码的键控排序对象)；标记为类别或标识符信息的关键字索引；以及overview Doc说明(包含描述字符串和语言编码的键控排序对象)。

TModel的一个实例如下：

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

euTModelName＝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标准中描述的对象类)有关的数据。根据本发明的实施例，可以用唯一字段表示对象属性，以及用重复性要素表示子对象来解决该问题。

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

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

set object-class uddiObjectClass：405＝

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

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

需要注意的是有一个与条目相关的辅助类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

}；

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

直属于联系方式对象的仅有数据元素是一个键，以及该联系方式对应的人或任务的名称。这是一个可选的用途类型。

所有其它可能的要素是联系方式对象的子对象。包括：地址(地址行对象的有序列表的父对象，分别有一个键、用途类型、排序编码以及TModel键)；电话(电话号码加上用途类型)；电子信箱(电子信箱地址加上用途类型)；以及描述(描述字符串加上语言编码)。

而且，尽管图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

may-contain

euLanguage

}；

set object-class uddiObjectClass：331＝

{#企业实体的名称

name＝euBusinessEntityName

subclass-of euName

must-contain

euBusinessEntityNameValue，

euBusinessEntityNameValueIC

#inherits euNameKey and euLanguagef from euName

}；

需要注意的是euBusinessEntityNameValue是包含敏感性的名称版本的属性；同时euBusinessEntityNameValueIC是标记为“忽略情况”的版本，因此是非敏感性的。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_RelatedBusinesses查询。该查询规定了一个特殊的企业实体，并通过已建立的发行者声明请求与该实体相关的所有企业实体的信息。这一查询通过一种把发行者声明设置在与其相关的企业实体之下的层次结构来简化和加速。其额外的优点是增加了一致性。当删除了一个企业实体时，与其同时也删除了所有相关联的发行者声明(目前已经不相关)。

另一个要点是如何创建一种有效的实现方法，只允许用户改变那些受其控制的企业实体。根据本发明的一个实施例，***把用户定义的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，且上面列出的最后三个属性是该类的数据要素。

根据本发明的一个实施例，如计算机协会的eTrust^TM目录可以用来实现一个理想的企业UDDI注册平台。eTrust目录和LDAPv3、X.500电子目录完全兼容，能够用于支持UDDI网络服务实现方法。‘eTrust’目录使得UDDI方法能够平衡那些已经证明在大规模、商业要求的目录服务应用程序中高度成熟的目录解决方案。

‘eTrust’目录有许多独特的特征使得其作为构建UDDI注册的平台相当具有吸引力。其中一些特征包括：安全特征—包括访问控制决策、任务、安全代理、相互认证、分布式认证、分布式SSL证明内容核实以及网络地址有效性确认；分布和路径特性-包括并行分布式搜索、负载分配、流水线式查询以及最短路径路由；多主控复制机制-其结合了基于重播机制(称为多记录机制)的速度和基于状态修复及平衡技术的效率；可用性特征-包括数据库的热交换、网络容错备援(fail-over)和目录***代理(DSA)容错备援；快速的缓冲存储设计；以及配置特征-包括动态设置(数据类型、模式规则、安全性、知识等等)，不限的数据大小、通用信息完整性规则、广泛的管理员级控制以及一个交互式的命令控制台。

eTrust目录提供了一个已检验的X.500目录方案。在这种已证明的基础上可以构造一个UDDI语义桥，以建立一个与标准完全兼容的UDDI注册。由于基础目录方案的性能，此处公开的实施例能提供灵活的安全性、分布性和可管理性，而不需要对现有UDDI标准进行改变或扩展。

本实施例要处理的一个要点是如何映射存储在目录的不同部分中的实体之间的关系。

而UDDI数据结构主要是分层次的，不同对象之间有交叉关系时可能会出现问题。

基本上有两类关系，即可供选择的名称和交叉关系。根据本发明的一个实施例，可以使用别名概念描述可供选择的名称，从而解决该问题。基本上该方法可以通过主实体的一个虚拟子对象来“关联”外来实体。

本实施例使用专有键来解决交互相关性的问题。创建类似RDBMS技术中的基本/外来键***的‘相关性指针’，来调整层次化目录***内拆散的子树之间存在的数据实体的相关性。

现在根据本发明的实施例来描述别名的使用。UDDI商业服务投影可以很清楚地演示第一种情况。商业服务投影实际上是商业服务的一个可选择的名称。商业服务投影是这样一种商业服务，其看起来属于企业A，但实际上是属于企业B且由企业B来定义的。

参照图5，商业服务51是属于企业A的服务，看起来也属于企业B。企业A对商业服务51做出的任何改变会在看起来是企业B之下的投影服务中产生反映。同样地，如果从注册中删除了商业服务51，其就不会出现在企业A或企业B下面。另外，企业实体B不会编辑或改变商业服务51。只有企业A能访问商业服务51以进行编辑或其它发布操作。

可以使用目录别名***来获得这种效果。商业服务51的别名被添加到企业实体B。别名是一种特殊的目录服务器的标志，当有人看到这个别名，就向他们展示另外的条目。

这意味着当编辑原始服务时，在投影服务中也可以看到变化。如果目录***支持别名完整性-这是eTrust目录的情况，此时如果删除了服务，其投影也会被自动删除。

另外，目录服务器可以被设置为当搜索投影商业服务时立即两次显示投影的商业服务，在每个父对象之下各显示一次。当搜索时需要分解商业服务的父对象时，这是很有用的。

一些情况需要目录层次结构中不相交的部分的对象能维持一定关系。

一个这样的例子是在绑定模板和TModel之间。TModel在整个UDDI中可用于多种不同的目的。它们是类别键、搜索标识符、(UDDI)关系描述符，以及在这种情况下的技术规范“指纹”。“关联”到绑定模板上的TModel描述了这一绑定模板所遵守的技术规范(参见图8)。例如一个发行者可以关联一个TModel，声明它们的绑定模板符合SOAP1.1标准。

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

根据本发明的这一实施例，例如用在关系数据库***中的主键/外部键***可以进行适当的修改和应用。每个存储在注册中心中的TModel有其自身唯一的(主)键。通过添加一个与所需TModel的唯一键相匹配的本地(外部)键，绑定模板可以引用TModel，。图7阐释了一个实例。如果TModel数据需要和绑定模板一起返回，则服务器就可以查询所讨论的TModel。

图6显示了绑定模板和TModel之间的关系。

图7显示了TModel键如何创建两个实体之间的关系。

发行者声明是UDDI信息库的一个重要要素。如上所述，其可以让用户发现哪个企业实体与感兴趣的企业实体相关，以及它们如何相关。

为了防止滥用，发行者声明可设计为只有当两个相关的企业实体的所有者都声明了这种关系时，所宣称的关系才变得可见。这种保护措施的代价是实现方法复杂化，但这种精心设计对于避免较差的性能是有必要的。

一个问题是关于完整性。发行者声明比其他任何UDD构造有更复杂的生命周期。其产生于当企业实体的所有者做出关于该企业的声明以及该企业与另一个企业实体的关系时。另一个企业实体的所有者可以请求一个状态报告，并查看有哪些关于其企业的声明，或者通知他们已经超出权限(out-of-band)。不管以哪种方法，另一个企业实体的所有者可以选择对两个企业实体之间的关系作出一个匹配声明。一旦此声明完成，就对搜索findRelatedBusiness的用户可见。如果修改或删除任意一个或两个声明，而声明再次变成不完整的，而且不可见。另外，不管删除哪个企业实体都应立即删除其声明。

发行者声明对象以能够保持声明完整性的方式来管理。

现在希望企业实体的所有者能够对该所有者控制的企业实体做出(以及删除)声明。

本发明的实施例是基于假定UDDI信息库是一个“大部分可读(read-mostly)”的存储器，正适用于X.500目录。为此，本设计的读数据的性能是最优的，甚至以加重写数据的负担为代价。

被称为“发行者声明(Publisher Assertion)”的对象类被设计为超出UDDI标准要求之外来保持数据，因为希望能优化搜索性能。该方案引入了一个可操作属性，其定义了发行者声明的状态。在写入目录的时刻确定声明的状态，而不需要每次执行搜索时确定其状态。

本实施例也使用了用户键形式的指针。当发行者声明写入到目录时，确定了“源”和“目的”企业的用户键，并写入到对象中。这简化了getAssertionStatusReport查询，因为要产生这样一个报告所需全部就是搜索一个包含了产生报告的人的用户键的发行者声明。

相反，如果必须查询该用户下的所有企业键，那么要寻找包含这些企业键的发行者声明，要产生该报告需要相当大的劳动量。

发行者声明的一个常见用途是发现与给定企业‘相关’的那些企业。为了提供更好的查询性能，把与企业相关的发行者声明设置在该企业的子节点上。

另外，每个声明的状态作为可操作属性记录在声明中。这使得能够只查询位于感兴趣的公司之下带有完整状态的发行者声明。这简化了findRelatedBusinesses搜索，因为该搜索仅检索那些完整的声明。

为了简化安全性，一个用户控制的所有企业以及它们的发行者声明都可以是该用户帐户条目之下的子节点。只允许用户访问用户帐户条目之下的子树的这种实现方法加强了访问控制。

需要注意的是表示状态的可操作属性由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的结果是“否”)，则判断是否是到达企业所有者做出的声明(步骤S90)。如果声明不是由到达商业所有者做出的(步骤S90的结果是“否”)，则写入了未完成的声明(步骤S94)。如果步骤S88的结果是肯定的(到达我们的企业)，或者步骤S90的结果是肯定的(到达商业所有者做出的声明)，就写入完成的声明(步骤S96)。

下一个要点处理如何在搜索操作中优化中间搜索结果的构造，考虑到目录存储介质的限制，从而使目录访问和信息库内迭代操作减到最小。实际过程中，目录条目可以用任意顺序存储并返回，且目录结果可能太大而无法排序。

根据本发明的一个实施例，提供了一个面向对象的存储器内数据存储***，其与一个唯一结果排序机制相耦合，该机制根据特异名称对中间结果进行排序。这使得搜索能返回许多不同类型的对象—企业实体，商业服务等—并且仍允许***容易地构造正确的XML结构以把数据返回到用户。需要注意的是网络服务交互是以XML形式进行的。

下面描述这种***的说明。本发明的UDDI企业实体和任何子对象数据元素可以根据下列层次结构在目录中表示：

企业实体(BusinessEntity)

●商业服务(BusinessService)

○绑定模板(BindingTemplate)

○服务名称(ServiceName)

●商业服务(BusinessService)

○绑定模板(BindingTemplate)

○服务名称(ServiceName)

●企业名称(BusinessName)

●企业描述(BusinessDescription)

需要注意的是服务名称、企业名称和企业描述已经在本发明的处理子结构和对象分离的相关内容中进行了描述。

企业实体获取编码基于所需的一个或多个企业实体的唯一键来执行目录子树搜索。搜索返回所发现的条目与所有子条目。目录标准不能保证返回的条目有任何特定顺序—甚至不能保证子条目会紧跟在其父条目之后。

因此获取编码根据特异名称对返回的条目进行排序。这能保证子条目在其父条目之后排列，因此很容易区分从属关系。可以使用不同的排序算法。所用的排序算法在对条目部分排序时能产生高性能。

结果构造的算法在操作时基本上是“深度优先、从左至右的树形”。这在图论中称为“后序遍历”。

排序列表被送到一个新企业实体对象的构造方法。在面向对象程序结构中，该对象例如被设计成描述UDDI企业实体。企业实体对象包含从最后一个条目提供的数据‘构造自身’的编码。编码反复遍历整个列表，对每个条目做出判断。可以理解列表中的第一个条目是企业实体自身的主条目，一旦它寻找到另一个企业实体就认为构造已经完成—列表顺序确保能实现该点。一旦其寻找到商业服务或其他子条目，就初始化一个适当类型的对象，并把列表和一个说明列表开始位置的指针一起传送到新对象的构造器。

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

通过这种方式，仅需执行一个目录搜索，且用有效的方式来处理生成的列表，每个条目只处理一次。如果生成的列表仍然是任意顺序的，或以某些其他方式进行排序，列表必须用多条路径来处理，以便正确地根据生成的条目来构造UDDI层次结构。

对于层次结构中不同编程对象的委托构造和列表处理能把程序代码保持得相对较小，从而使执行效率更高，速度也更快。

图9阐释了程序构造(对象)，包括排序后的条目列表的描述。判断项目列表中是否有其他项目。如果没有其他项目(否，步骤S100)，该程序退出(步骤S118)。如果有其他额外的项目(是，步骤S100)，就取回列表中的下一个项目(步骤S102)。然后就判断该项目是否属于这种对象类型。如果该项目属于这个对象类型(是，步骤S104)，就根据该项目设置对象属性(步骤S106)且程序返回到步骤S100。如果不属于该对象类型(否，步骤S104)，就判断该对象类型的项目是否已经被处理(否，步骤S108)。如果该对象类型的项目还没有被处理(否，步骤S108)，程序返回到步骤S100。如果该对象类型的项目已经被处理(是，步骤S108)，就判断该项目是否是该对象的一个固有要素(如名称、描述等)。如果它是一个固有要素(是，步骤S110)，就把该项目添加到对象属性中并执行备用的程序(步骤S112)，且程序返回到步骤S100。如果它不是一个固有要素(否，步骤S110)，就判定该项目是否是该对象的一个子对象(例如商业服务，如果这是个企业实体)。如果它是一个子对象(是，步骤S114)，***对正确类型的对象进行初始化，并把项目列表传送到一个构造器(步骤S116)，且程序返回到步骤S100。如果它不是一个子对象(否，步骤S114)，程序返回到步骤S100。

下列“real word“的实例阐释了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

#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＝caselgnoreString

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＝

{#用于Business Entity Name

name＝euBusinessEntityNameValue

syntax＝caseExactString

single-valued

}；

set attribute uddiAttributeType：381＝

{#用于Business Entity Name

name＝euBusinessEntityNameValueIC

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：362＝

{#用于Business Service Name

name＝euBusinessServiceNameValue

syntax＝caseExactString

single-valued

}；

set attribute uddiAttributeType：382＝

{#用于Business Service Name

name＝euBusinessServiceNameValueIC

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：363＝

{#用于Business Entity Description

name＝euBusinessEntityDescriptionValue

syntax＝caseExactString

single-valued

}；

set attribute uddiAttributeType：383＝

{#用于Business Entity Description

name＝euBusinessEntityDescriptionValueIC

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：364＝

{#用于Business Service Description

name＝euBusinessServiceDescriptionValue

syntax＝caseExactString

single-valued

}；

set attribute uddiAttributeType：384＝

{#用于Business Service Description

name＝euBusinessServiceDescriptionValueIC

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：365＝

{#用于TModel Description

name＝euTModelDescriptionValue

syntax＝caseExactString

single-valued

}；

set attribute uddiAttributeType：385＝

{#用于TModel Description

name＝euTModelDescriptionValueIC

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：366＝

{#用于TModel Instance Info Description

name＝euTModelInstanceInfoDescriptionValue

syntax＝caseExactString

single-valued

}；

set attribute uddiAttributeType：386＝

{#用于TModel Instance Info Description

name＝euTModelInstanceInfoDescriptionValueIC

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：367＝

{#用于TModel Instance Details Description

name＝euTModelInstanceDetailsDescriptionValue

syntax＝caseExactString

single-valued

}；

set attribute uddiAttributeType：387＝

{#用于TModel Instance Details Description

name＝euTModelInstanceDetailsDescriptionValueIC

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：368＝

{#用于Overview Doc Description

name＝euOverviewDocDescriptionValue

syntax＝caseExactString

single-valued

}；

set attribute uddiAttributeType：388＝

{#用于Overview Doc Description

name＝euOverviewDocDescriptionValueIC

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：369＝

{#用于Binding Template Description

name＝euBindingTemplateDescriptionValue

syntax＝caseExactString

single-valued

}；

set attribute uddiAttributeType：389＝

{#用于Binding Template Description

name＝euBindingTemplateDescriptionValueIC

syntax＝caseIgnoreString

single-valued

}；

set attribute uddiAttributeType：370＝

{#用于Contact Description

name＝euContactDescriptionValue

syntax＝caseExactString

single-valued

}；

set attribute uddiAttributeType：390＝

{#用于Contact Description

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＝

{#用于tmodelinstance 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 uddiObjectClass：331＝

{#BusinessEntity的名称

name＝euBusinessEntityName

subclass-of euName

must-contain

euBusinessEntityNameValue

euBusinessEntityNameValueIC

#从euName继承euNameKey和euLanguage

}；

set object-class uddiObjectClass：332＝

{#BusinessService的名称

name＝euBusinessServiceName

subclass-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 setname-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：3l2＝

{#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.一种网络服务目录包括：

至少一个企业实体对象；以及

至少一个用户对象，其中至少一个企业实体对象设置在至少一个用户对象之下。

2.如权利要求1中所述的网络服务目录，还包括：

至少一个商业服务对象；以及

至少一个绑定模板对象；其中至少一个商业服务对象设置在至少一个企业实体对象之下，且至少一个绑定模板对象设置在至少一个商业服务对象之下。

3.如权利要求1中所述的网络服务目录，其中借助于至少一个相应的用户子对象，至少一个企业实体对象设置在至少一个用户对象之下。

4.如权利要求1中所述的网络服务目录，还包括至少一个域对象，其中至少一个用户对象设置在至少一个域对象之下。

5.如权利要求1中所述的网络服务目录，还包括适用于实现网络服务目录的装置，且其中调用了目录服务。

6.如权利要求5中所述的网络服务目录，其中使用X.500和LDAP协议中的至少一个协议来调用目录服务。

7.一种网络服务***，包括：

一个注册中心，其中可以进行企业注册，该注册中心包括一个具有层次结构的目录，所述目录包括至少一个企业实体对象和至少一个用户对象，至少一个企业实体对象设置在至少一个用户对象之下；以及

一个存储***，用于存储企业信息，并通过具有层次结构的目录进行访问。