CN1678992A

CN1678992A - Web服务设备和方法

Info

Publication number: CN1678992A
Application number: CNA038202697A
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: CN1678993A; BR0313870A; EP1532523A2; BR0313868A; AU2003265649A1; AU2003265762A1; WO2004019233A8; JP2005539295A; BR0313853A; WO2004019237A2; CA2495807A1; CA2497956A1; WO2004019231A2; IL166602A0; JP2005536808A; WO2004019237A8; KR20050033077A; US20060020585A1; WO2004019234A9; BR0313775A

Abstract

一种用于具有复杂UDDI对象的WEB服务系统的方法，所述复杂UDDI对象具有至少一个非复合数据结构和至少一个复合数据结构，每个复合数据结构具有至少一个值，每个值具有多个字段。该方法在目录父对象中提供表示每个非复合数据结构的属性，并且为每个至少一个值提供具有表示复合数据结构的每个字段的属性的目录子对象。

Description

WEB服务设备和方法

对相关专利申请的交叉引用

本申请要求均于2002年8月26日提交的临时专利申请60/406,391；60/406,399；60/406,325；60/406,328；60/406,204；60/406,205；和60/406,319的优先权，并且这里参考引用了所述每个专利申请的内容。

技术领域

本发明通常涉及UDDI注册中心和WEB服务，尤其涉及在这样的服务的实际实施中使用的方法，设备和系统。

背景技术

UDDI(统一描述，发现和集成(Universal Description，Discoveryand Integration))是一组标准，其被定义以允许使用WEB服务的应用迅速、容易和动态地彼此交互。UDDI被用来建立平台无关的开放式框架，用于描述服务，发现企业和集成使用因特网的系统服务，并且用于描述工作注册中心。参照WEB站点www.uddi.org以了解详情。

UDDI注册中心(UDDI registry)对利用WEB服务构造的系统提供有价值的支持。图1a示意性图解了基本WEB服务和UDDI概念。图1b示意性图解了WEB服务环境的简化协议堆栈。UDDI提供WEB服务信息的数据库(repository)，并且自身通过WEB服务来提供。

UDDI允许应用公开其希望如何在WEB上进行交互。每个′WEB服务′是自描述的、自包含的应用逻辑模块单元，其通过因特网连接为其它应用提供某个系统功能。应用通过通用的Web协议和数据格式访问WEB服务，但不必关心如何实现每个WEB服务。WEB服务能够与其它WEB服务混合和匹配以执行较大的工作流程或企业事务。

UDDI标准描述了被用来管理WEB服务类型的说明，企业组织和关于如何调用WEB服务的细节的专用数据库。标准不必规定应当如何实现标准，也不必规定实现是否应当包含利用数据库，目录或任何其他介质的存储。

在负责UDDI标准的组织托管的WEB站点(http：//www.uddi.org/faqs.html)上有一些常见问题解答(FAQ)。这些问题之一是：″UDDI注册中心能够被建立在LDAP上或基于LDAP吗？″作为回答，这个WEB站点公开道：在UDDI和目录之间没有正式的关系。″UDDI规范没有规定注册中心实现细节。UDDI规范定义了基于XML的数据模型和一组SOAP API，以访问和操作该数据模型。SOAP API定义了UDDI数据库所表现出的特性。UDDI实现能够建立在LDAP目录上，只要它符合规定的特性。到目前为止，所有UDDI实现均建立在关系数据库上。″

应当注意，例如X.500和LDAP的目录技术是可扩展的通用数据存储，并且其相关语言经常被用来管理用户和资源。它们是非常精心设计的技术，得到广泛采用，并且被认为是非常稳定和可靠的。

然而，在目录上实现UDDI标准(可从www.uddi.org得到)需要解决若干问题。UDDI标准留下许多重要的问题有待解决，例如：

●UDDI标准定义了若干对象，其中一些对象通过层次结构相关，但是UDDI没有定义全包括的层次结构。例如，企业服务对象会处于企业实体对象下面，而绑定模板对象会处于企业服务下面。图2图解了这个层次结构的例子。企业实体对象被表示为21，企业服务对象被表示为22，绑定模板对象被表示为23。还应当注意，例如表示为24的TModel对象在层次上与这些对象无关。还存在例如发布者声明(Publisher Assertion)、在层次上没有定义的其它概念。

●建立满足只允许用户改变在其控制下的那些对象的要求的高效实现，

●建立允许UDDI注册中心为分布式的高效实现，

●建立增强管理特性和搜索与更新的性能的高效实现。

●如何以相对高效的方式表示复杂UDDI对象。例如，企业实体，企业服务，绑定模板和/或TModel具有复合的重复单元。于是这些重复单元能够包含进一步的重复单元。例如，企业实体可以包含联系(contacts)，而联系可以包含地址。地址可以包含地址行(address line)和电话号码。图13示意性图解了企业实体中相对复杂对象的UDDI概念。企业实体对象131例如包含若干属性132，例如授权名字(AuthorizedName)，企业关键字(BusinessKey)和名字(Name)。名字具有一或多个名字字段133，例如′文本′，或者这可以隐含在′名字′自身中。还有′语言′。可以存在这些字段133的一或多个。

●如何对重复单元中包含的特定项提供相对快速的搜索。

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

●如何以高效方式管理UDDI对象和所有其相关信息的删除，以及

●考虑到目录存储介质的限制，如何优化搜索操作期间中间搜索结果集合的构造，使得目录访问和迭代存储器内(in-memory)操作最小化。实际上，可以以任意顺序存储和返回目录项，并且目录结果可能过大以致不能排序。

●如何以高效方式表示涉及发布者声明的数据，

●如何建立发布者声明的高效实现，尤其是对于findrelatedBusiness方法的实现，

●如何通过关系实现发布者声明的高效搜索，

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

●如何约束由企业实体的所有者针对企业实体建立和删除的声明。

●如何高效管理UDDI标准中定义的相关属性集合，

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

已经提出各种UDDI模式(UDDI Schema)。然而没有任何UDDI模式被认为解决了至少上述问题。例如，一个模式提供了相对简单的UDDI对象到目录对象的映射，而不必涉及到产生高效商用实现的复杂度和优化。同样不清楚在这样的模式中如何能够高效实现若干UDDI服务(尤其是find_系列的服务)。

例如，图14示意性图解了企业实体中的相对复杂对象的Novell表示。企业实体对象141包含例如若干属性142，每个属性具有′类型′和′值′。如图所示，存在具有值′Bill′的授权名字，具有值′890.obale.890......′的企业关键字，和具有多值143,144，即

en#CA

IN#CATS

的名字。

UDDI(图13)和Novell(图14)的示例性表示不被认为是对于WEB服务的高效表示。

于是，需要解决上述一般性问题以及其它问题，以提供一种基于目录的UDDI的可扩展、高效和可靠的实现。

发明内容

一种用于具有复杂UDDI对象的WEB服务系统的方法，所述复杂UDDI对象具有至少一个非复合数据结构和至少一个复合数据结构，每个复合数据结构具有至少一个值，每个值具有多个字段。该方法包括在目录父对象中提供表示每个非复合数据结构的属性，和为每个至少一个值提供具有表示复合数据结构的每个字段的属性的目录子对象。

一种使WEB服务结构中的层次结构扁平化的方法，该方法包括确定WEB服务结构中的层次结构或关系的任何部分是否具有对象之间的′一对一′关系，和通过将属性的内容移动到层次结构的至少一个子部分中，清除层次结构中被确定为具有一对一关系的该部分。

附图说明

参照以下结合附图对优选实施例进行的说明可更好地理解本发明的其它目的，优点和方面，其中：

图1a示意性图解了某些WEB服务和UDDI概念；

图1b示意性图解了WEB服务环境的简化协议堆栈；

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

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

图4根据本发明实施例示意性图解了利用X.500目录技术实现的UDDI服务模型的基础部件；

图5根据本发明实施例示意性图解了服务投影(ServiceProjection)；

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

图7根据本发明实施例示意性图解了TModel如何建立2个实体之间的关系；

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

图9根据本发明实施例图解了UDDI数据对象的构造函数(constructor)的逻辑表示；

图10示意性图解了将企业实体对象放在用户对象下面的情况；

图11示意性图解了将域对象放在用户对象下面的情况；

图12根据本发明实施例示意性图解了模式的概况；

图13根据现有技术示意性图解了企业实体中的相对复杂对象的UDDI概念；

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

图15根据本发明实施例示意性图解了引入层次结构以表示企业实体中的相对复杂对象的情况；

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

图17示意性图解了扁平化和/或合并的绑定模板子结构；而

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

具体实施方式

在描述附图中图解的本发明的优选实施例时，为了清楚而使用特定的术语。然而本发明不限于选择的特定术语，应当理解，各个特定单元包含所有以类似方式工作的技术等价特征。

图18示出了可以实现本发明的方法和系统的计算机系统的例子。可以以在例如大型机，个人计算机(PC)，手持计算机，服务器等等的计算机系统上运行的软件应用的形式实现本发明的系统和方法。软件应用可以存储在计算机系统本地可访问的记录介质，例如软盘，光盘，硬盘等等中，或者可以远离计算机系统并且可通过针对例如局域网或因特网的网络的硬连线或无线连接来访问。

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

下面总结了本发明实施例的一些显著特征，以及因而提供的一些优点。

根据本发明的实施例，在用户之上建立数据库层，因而每个数据库能够被放到不同的服务器上。这个数据库层包含共同形成目录前缀(Directory pre-fix)的一或多个目录节点。这也可以被称作数据库的′域′或′名字′。其优点在于提供单独位置以保存关于域的信息。这个节点的名字表示目录前缀。

可以建立用户对象以保存表示UDDI帐户的数据。其优点在于提供单独位置以保存关于用户/帐户的信息。

企业实体对象可以被排列在用户对象下面，企业服务对象可以被排列在企业实体对象下面，绑定模板对象可以被排列在企业服务对象下面。其优点在于用户对象层之上的数据库或′域′层允许将若干数据库布置或逻辑连接在一起。域层可以按若干层次排列，例如使不同国家，即AU，US，EP等等按大陆组织。

另一个优点在于通过使用X.500目录的分布特性可以为这个特征提供效果。例如，为实现这个，′世界′或′公司′节点被放在虚拟目录树的顶端，并且唯一命名的节点被放在每个UDDI子树(UDDI名字空间)的顶端。虽然对用户不可见，然而这些′节点′前缀允许UDDI数据库影响到(leverage)目录分布。

根据本发明的实施例，可以使企业实体对象作为用户对象的子节点。使用户/帐户在企业实体，企业服务和绑定模板层次上，提供了使每个用户具有其自身的子树的效果。这增强了可管理性和安全性。用户被容易地限制于只修改和/或控制其自身的子树。这也通过利用目录子树搜索操作增强了性能。

根据实施例，用户定义的TModel可以作为用户对象的子节点，于是使得安全性易于实现。由于用户只能修改和/或控制其自身的子树，这增强了可管理性和安全性。这也通过利用目录子树搜索操作增强了性能。

本发明的实施例表示利用X.500/LDAP目录技术的UDDI环境的′映射′。尤其是，已经发现X.500和LDAP目录技术的层次结构适用于UDDI环境。附加单元(例如用户对象)的精心设计使得层次结构更加适合UDDI环境的需要。

在本发明中，术语目录要包含X.500，LDAP和类似技术；术语′用户′被理解为也包含′帐户′，并且反之亦然；而术语′数据库′被理解为也包含′目录前缀′，′域′和/或′节点′，并且反之亦然。

WEB服务最初被认为是例如企业，伙伴，客户，供应商的组织之间的服务。在这个环境中，UDDI被考虑为这些组织提供的服务的单独数据库。

现在显然WEB服务和UDDI可用于企业内以在组织内集成应用。也显然WEB服务和UDDI可用于在来自指定厂商的产品集合内集成产品。这同样适用于商用环境以外的领域，例如政府部门，大型教育机构，和许多其它非商用实体的实例。

尽管针对的是企业，然而以下说明同样适用于任何类型的环境，尤其适用于上述类型的环境。

企业UDDI注册中心可以是这样的服务，其能够部署在企业内以发布供内部使用的信息和服务。另外，企业UDDI服务可以受到影响以提供其它功能，例如用于分布式应用的配置发现。

希望WEB服务能够迅速和容易地在内部和与伙伴集成企业过程。有效利用WEB服务的一个部件是公共UDDI注册中心，其允许软件部件动态发现和连接到因特网上的适当服务。WEB服务也提供能够集成企业内的业务过程的承诺。在这种情况下，UDDI注册中心可以变成组织的基础设施的一部分(例如重要企业应用)，因此提供最高等级的安全性，性能，可靠性和可管理性。目录技术提供理想基础以支持企业UDDI注册中心的严格要求。

企业UDDI注册中心可以被定义成提供对UDDI的符合标准的支持，但是又进行超越以解决有关部署的4方面问题。这些方面包含将访问仅限于授权用户的安全性，支持大型部署的分布，用于真实生产系统的可管理性，和满足服务等级协议的可用性。

强安全性可以是某些企业部署的重要要求。公共UDDI注册中心的存在完全是为了帮助任一方发现可用服务。UDDI注册中心的存在完全是为了使正确的人们发现这些服务。这是重要的区别。

因特网UDDI注册中心被认为对于在企业中部署WEB服务是不适当的。例如，接口到薪水系统或雇员收益管理应用的WEB服务的定义不会发布到因特网UDDI注册中心上。

安全性要求也可以意味着甚至内部部署的UDDI注册中心也要提供强访问控制。这是由于UDDI注册中心基本上提供关于能够做什么和如何做的指导。UDDI注册中心提供任何可用WEB服务的企业级的描述，并且对完全定义那些服务的编程接口的WSDL提供指示。这为应用开发人员以及黑客提供高生产率工具。

因此，期望限制对财务敏感或机密(例如医药记录)系统的接口定义的访问。甚至在开发组织内部，最好限制对关于授权的特定WEB服务的信息的访问。

在企业内，或由选定企业成员通过企业外部互联网使用非安全UDDI注册中心是非常危险的。借助可自由下载的工具，技能水平相对较低的人们能够访问和使用WEB服务。任何真正的企业解决方案均能够以透明控制对有关WEB服务的信息的访问的能力，实现标准UDDI服务。

对于分布，在许多情况下，UDDI注册中心的初始部署将具有较小规模。然而随着WEB服务需求的增长，通常会变成大型部署。另外，注册中心的应用和部署会随着UDDI注册中心的新功能的发现而得到加速。

更大型的实现和地理上分布的组织内的使用会促使在单独组织内实现多个UDDI注册中心。向分布式注册中心的演变使得任何个体注册中心能够与其它注册中心动态交互以服务于其请求的能力变得重要。一旦被建立，注册中心间的通信能够扩展超出防火墙，以包含受信企业伙伴的注册中心，或甚至与因特网UDDI注册中心通信。

考虑有2个基本方案以满足注册中心间通信的需要。一个方案是复制，其中多个服务器上存在相同的名字空间项。另一个方案是分布，其中互连服务器具有不同的名字空间项，然而它们提供一个逻辑服务。

尽管这2个方案经常被混淆为类似的，然而它们有相当的不同。

在复制方案中，在可能需要查找信息的每个服务器中复制信息。这是相对简单的，甚至过分简单的解决方案，但是它引入了同步更新的需求，并且根据定义，它会随着注册中心数量和其内容量的增长而增加网络阻塞。复制技术最适于服务器数量较少，信息量较低并且很少改变的环境。对于企业部署，复制经常用于在故障恢复环境中维护备份数据库。使用复制技术非常难以保持地理上或功能上分布的服务器的同步。

在分布方案中，在每个参与的服务器上逻辑表示信息，但是信息只存储在单个注册中心中。仅在需要时查询才被分布到其它注册中心。于是保证返回的信息是最新的。这提供了单点更新，并且消除了复制技术固有的同步和带宽消耗问题。真正分布被认为是服务器之间可伸缩连通性的一个解决办法。

对于企业UDDI注册中心，存在2种通常会使用分布的情况。第一种情况用于具有地理上分隔的办公室的组织，其中每个办公室产生新的UDDI项并且使用UDDI服务。虽然可能能够运行单个的集中式UDDI注册中心，然而带宽约束和时差经常使得难以运行，以致不可工作。

分布式注册中心提供灵活、可伸缩的解决方案。在这种情况下，每个参与的办公室具有分立的注册中心，并且每个注册中心将其它注册中心视为其自身内容的逻辑部分。注册中心服务负责所有的连通细节，并且客户不必关心地理问题。

第二种情景出现在企业需要将其内部UDDI系统连接到受信伙伴的UDDI系统或公共因特网注册中心时。尤其在公共注册中心的情况下，复制是有问题的。因特网注册中心操作人员可能不希望将其注册中心的部分复制到企业的内部注册中心。于是，分布式方案是一个办法。当前，没有针对分布的UDDI标准，并且关于复制的建议被认为是复杂的。一个解决方案会提供UDDI分布式方案的益处，而无需修改标准。

对于可管理性，作为执行企业内的任务关键功能的部件，UDDI应当满足性能和可靠性要求。它不应只是作为开发人员的方便实用程序而存在。客户端的读取访问将是对UDDI注册中心的最频繁和时间要求最严格的应用。为最大吞吐率而优化性能，并且查找查询的响应时间不应受更复杂搜索的影响。随着注册中心的规模和复杂度的增长，性能不应受影响。支持UDDI注册中心的数据存储应当是工业级的，并且完全支持事务和自动恢复。另外，UDDI服务器应当具有高度可用性，并且支持例如网络故障恢复和热后备的特性。系统管理员应当有能力使得UDDI注册中心易于维护，监视和控制。这些能力包含无需使服务脱机而改变控制，规则和设置的动态配置，用于高可用性的在线备份和调整，停止注册中心″搜索″和防止拒绝服务攻击的管理控制，经由SNMP或其它类型的提醒机构的监视，利用针对安全，统计，查询和更新信息的分立日志文件的审计和诊断，以及支持复制，分布和路由的部署选项。

已经引入了许多以开发人员为焦点的UDDI注册中心。这些为小型开发团队提供了有用的能力，但不是真正的生产级的系统。WEB服务部署正迅速增长，并且对能够迅速升级以支持正在进行的WEB服务部署的企业级注册中心存在相应的需求。

UDDI注册中心提供服务。许多应用会依赖此服务。在在线企业的情况下，一起提供这个服务可能是重要的。例如，可能需要UDDI注册中心提供99.99％可用性的服务等级协议。为了利于这个可用性水平，UDDI注册中心可以复制在两个或更多机器上，并且提供机制以确保机器保持同步，并且确保在任何机器变得不可用的情况下，任何传入查询被自动路由到可用机器。

如已经指出的，UDDI可以被看作类似于电话目录服务。于是，最好基于信息存储的目录模型建立UDDI注册中心服务。已经针对基于目录的服务的特定需求演变和开发了目录模型，其具有企业级部署所需的安全性，可伸缩性和可靠性。

在应用体系结构中，如上所述的大部分项目被实现在服务级，而不是数据存储级。关系数据库(RDBMS)是能够借以建立许多不同类型的应用的通用工具包。RDBMS实现侧重于提供坚实的数据访问功能，而不是终端应用中需要的额外服务功能。

图3示出的目录服务体系结构图解了服务层31与其它部件的分离。将接口功能封装到服务层31中，产生了可重用服务基础设施部件。其一个极好的例子是Web服务器。Web服务器提供一个功能集合(HTTP访问，CGI处理等等)，其共同构成足够可用于建立到独立部件中的服务。以相同方式，已经开发了目录服务模型以提供特定类型的应用所需的功能。目录技术提供对认证和授权领域的许多任务关键应用的支持。

UDDI可被视作类似于另一个类型的目录服务。于是可以发现，通过使用目录技术能够解决UDDI产生的许多实现问题。例如，针对对于UDDI电话目录操作而言非常普遍的非常高效的发现和搜索操作而优化目录。

已经注意到，UDDI服务应当提供强安全性，分布和可管理性能力，如果它要成功部署在企业中的话。这些是已经建立到企业级目录服务解决方案中的非常相同的属性。

一个构造企业UDDI注册中心的方式是扩展现有的目录基础设施，这种现有的目录基础设施已经在高性能真实世界应用中得到尝试和测试。

目录服务体系结构提供优化的工具以实现企业UDDI注册中心。这种组合支持为成功而需要的能力。图4示意性示出的UDDI服务标识出可以针对这个基础设施实现的部件。UDDI语义桥41是介于UDDI的SOAP实现42和目录44支持的LADP接口43之间的服务部件。目录44传送其中支持安全控制，分布机制和管理能力的信息访问。RDBMS45提供基础物理数据管理，事务完整性和备份与恢复机制。

UDDI注册中心产品可以直接建立在RDBMS技术上。尽管在许多方面都是非常有用和强大的，然而关系数据库自身不满足目录处理所特有的要求。

使用RDBMS或下面的其它数据存储系统能够初步建立目录型应用。然而这不可能是最高效的方案。

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

精心设计的数据表示会有利于提供UDDI数据库所需的功能和性能。

以下描述涉及各个UDDI概念。参照UDDI规范(http：//www.uddi.org/specification.html)可获得这些UDDI概念的更加详细的描述。

在目录用语中，模式是有关目录中能够存储的数据单元和那些单元如何可以被连接在一起的描述。这包含每个可能属性(属性保存单段数据)的描述，各个对象(对象是属性的集合)的描述，和可能对象层次结构的说明。本说明书中使用的特定模式符号是eTrust目录，即Computer Associates International公司的产品所使用的符号。′eTrust′是Computer Associates International公司的产品名称和商标。当然，可以使用其它模式符号。

本发明描述用来通过使用目录作为数据存储来实现UDDI数据库的模式。存在与这个模式有关的若干概念。也存在用来增强UDDI实现的操作的若干技术。以下是对这些概念中的一些的简要描述。后面当描述本发明的实施例时会提供这些概念和技术的更加详细的描述。

本发明的模式被设计成提供优化操作。以增强操作的方式实施本发明的模式设计，其包含属性，对象类，项(entry)和层次结构的定义。本发明的模式设计至少在安全性，性能，可管理性和分布方面提供显著的优点。

现在描述系统的层次结构。X.500目录在内部支持分布，从而在无需UDDI层次的任何编码的情况下提供分布式UDDI数据库。层次分割数据库的内容。这个模式的(可选)域层次假定该层次，每个域项和在其下面的全部项均能够对UDDI层次编程透明地被放到分立目录服务器上。图11图解了本发明这个方面的实施例。下面会更详细地对此进行描述。

根据本发明的实施例，用户对象被放置在企业和TModel对象之上。用户对象提供用于存储涉及用户的信息的位置。它也提供针对用户发布的全部数据的锚标点(anchor point)。图10图解了本发明这个方面的实施例。下面会更详细地对此进行描述。

这个域/用户层次系统有利于安全性。UDDI实现能够保证用户具有对其数据对象子树的控制。

提供对用户控制的项的搜索。通过在用户对象下面使用子树搜索，能够增强对这个用户控制的数据的搜索。

通过例如指定在绑定模板中出现的TModel，可以发现企业。这等同于″通过发现一个(或更多)其子节点来发现x″。换言之，查询可以是″发现具有一服务的所有企业，该服务具有引用这个模型的绑定模板″。通过发现派生对象的DN(区别名字)并且丢弃不期望的层次以产生企业实体的DN，进行这样的查询。

也可以通过这种方式进行复制消除。这个发现特性源于本发明的结构的层次性质。

可以使用对对象类唯一的属性来执行搜索。这是具有2个优点的优化。这通过消除′弱′子句简化了搜索的编写，并且产生出众的性能。′弱′子句是过滤器的一部分，其返回大量的项，或者是指作为许多项的一部分的属性。对每个名字使用相同属性名字的设计在按照名字对企业实体进行搜索时会具有2个选择：它在搜索中包含对象类，或过滤搜索结果。前者只在企业名字具有唯一对象类的情况下才可能出现，并且即使如此，对象类仍是弱子句，从而导致更多开销。后者意味着额外的代码，和返回远大于期望结果的结果列表的可能性。

例如，考虑称作″McKenna的测试服务″的公司，其提供各式各样的WEB服务，所有的WEB服务均在其名字中包含″McKenna的″-以在其名字中具有″McKenna的″为条件对企业实体进行的搜索会返回全部服务的中间结果。这些中间结果可以被消除，但是处理它们降低了性能。

最好能够在搜索中指定属性名字，并且使该属性名字唯一标识正搜索的对象类。继续上述例子，如果我们能够进行以下指定，则搜索会更加简单：

(euBusinessEntityName＝McKenna′s^*)

这样的设计产生强搜索，由于它们单纯搜索期望区域，因而是高效的。强搜索包含返回少量项的搜索。目录能够索引euBusinessEntityName属性，并且根据该索引返回结果-这产生良好的性能，并且避免处理不必要的中间结果。

对于简单查询，这样的设计意味着针对企业实体名字的搜索是单个子句，而不是在另一个设计中可能必要的复合子句。想象如果名字属性被称作euName，并且企业实体名字对象被称作euBusinessEntityName。这会产生以下搜索：

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

存在甚至更加简单的设计，其中所有名字被存储在相同对象类中。这意味着搜索再次缩减到(euName＝McKenna′s^*)，但是现在我们遍历所有名字的结果，以尝试找到那些具有作为企业实体的父对象的结果-这个最后设计可能会产生不良性能，和更加复杂的编程。

影像属性(shadow attribute)可以被用于大小写敏感(case-sensitivity)。使用单个索引提供大小写敏感和大小写不敏感的搜索完全不是无效的。一个选择是大小写不敏感地进行索引，接着大小写敏感地扫描结果。另一个解决方案是大小写敏感地索引原始数据，并且增加大小写不敏感地被索引的第二属性(其中存储相同数据)。于是需要做的只是选择适当属性以根据发现限定条件进行搜索。

这个设计中的每个属性可以是单值的。这允许高效索引，更高性能和更强搜索。

使用多值属性使得能够进行模糊搜索。也就是说，可以得到不直观和不期望的搜索结果。假定一个称作′n′的多值数字属性，并且包含这个属性的项具有值2和5；这个项会响应搜索(&(n＜3)(n＞4))而被返回，这不是容易预测的。

单值属性是用于强搜索的技术之一。强搜索是能够通过索引消除大多数候选结果的搜索。强搜索是改进性能的关键。

别名可以被用于服务投影。这是使用X.500目录作为数据存储的显著益处。能够使用X.500别名巧妙地表示服务投影。这是保证数据完整性的主要优点。别名访问原始数据，所以通过别名立即反映对原始数据的任何改变。如果目录实现支持别名完整性，则当原始项被删除时，别名无需附加工作便会消失。

发布者声明是UDDI标准中定义最不清楚的元素之一，它们需要精心的设计。不适当的实现能够容易地产生不良的性能。

由于发布者声明的最通常的使用是搜索涉及指定企业实体的所有完整发布者声明的find_relatedBusiness API，将每个声明放置在其所针对的企业实体下面会是良好的设计。

通过计算声明的状态并且在声明对象中存储该状态，可以将搜索限于完整发布者声明。这意味着返回的结果不会包含要清除的虚假引用。

将关系对象存储为辅助类允许搜索消除具有不期望关系的任何声明。如果关系被存储为子对象，则不能编写出访问到关系和声明完成状态的单个搜索。

UDDI关键字可以被用于对存在的目标进行命名。UDDI对许多重要对象类定义了关键字，并且这些关键字被指定为保证唯一。这意味着关键字能够被用作对象的名字属性。使用UDDI关键字作为名字属性意味着不必尝试消除命名冲突-而在例如缺省名字被用作企业实体的名字属性的情况下会需要消除命名冲突。

可以提供关键字以对不存在的目标进行命名。也就是说，不是所有的UDDI对象都具有定义的关键字。一个例子是发布者声明。对于这些，本系统使用与UDDI定义的关键字相同的算法提供关键字。这个思路的重用意味着能够重用针对其它对象编写的代码和结构。

在一系列UDDI对象是另一个对象的子对象并且子对象的顺序是重要的(例如地址行(address lines))的情况下，分配给子对象的关键字被构造成其值单调增加，使得对关键字的排序产生期望的顺序。这简化了保证期望顺序的处理。

实际上，期望关键字按照由小到大(little-endian)的方式发生改变。也就是说，关键字的最左字节改变最迅速，因为这在被用作数据存储的X.500目录中产生最优的索引性能。

UDDI标准在一些主对象类型内定义若干子结构。在许多情况下，这些子结构是可选的，并且可以重复(它们在相同对象中可以出现零次，一次或不止一次)。一个简单例子是名字子结构，包含串(名字)和语言标识符。X.500模式定义不支持结构化属性的使用，所以不存在现成的、清楚的子结构映射。

存在一些能够在X.500模式中实现这些子结构的方式。

一种方式是通过使用某种分隔符分割各个元素，从而将子结构的成分串联成单个属性。这可能是最优的设计选择，因为它失去分别索引或搜索成分的能力，并且增加了处理复杂度以处理数据。

在本系统中，选择用来表示子结构的特定设计以使性能和可管理性最大化。所公开的设计可以使用各种技术中的一或多个表示目录中的子结构。这些技术可以被概括为3个类别。

一个技术是将许多子结构处理为子对象。名字是良好的例子：企业实体名字被存储为企业实体的子对象。另一个例子是描述，其中单独的企业描述对象是企业实体对象的子对象。图15提供了关于本发明这个方面的实施例的说明，并且会在下面更详细地加以描述。

另一个技术是扁平化/合并。在可能最多存在一个针对另一个对象的关系的情况下，属性可以被合并成一个单独的对象。在这种情况下，层次结构被称作是扁平化的，因为2个对象已经合并成一个对象。新对象被称作是合并的，因为新对象包含来自组合对象的属性的组合。关系对象的内容最好被提升到父对象。

例如，图16示意性图解了UDDI关系图的表示。图17示意性图解了目录层次结构图，其中通过UDDI对象的扁平化形成了目录层次结构。

通过说明，图16图解了具有针对对象163的关系对象162的对象161。

根据本发明的实施例(其中存在一对一关系)，′子对象′能够得到提升。换言之，该部分层次结构能够被缩减或扁平化，并且对象被合并。图17示意性图解了结果。父对象171具有内容A1，A2，An，并且具有一或多个子对象，即子对象9n，其具有内容B1，B2，Bn，C1，C2和Cn。

另一个技术是分割。例如，在一个特定情况(OverviewDoc子结构)中，子结构包含非重复单元和重复单元。非重复单元(OverviewURL)能够移入父对象，而重复单元可以成为子对象。

本发明的另一个方面是管理。删除TModel使得将其从find_TModel隐藏掉，但是不将其从数据库中清除。因此，为实现正确的TModel处理，可以实现隐藏标记。这个标记的存在指示TModel(或用户对象)被隐藏。标记的不存在指示它没有被隐藏。对于绝大多数TModel均是如此，所以这个方案是高效的。非隐藏对象中没有占用空间，并且也不使用索引。目录会只索引那些具有隐藏属性的项。这也意味着对非隐藏TModel的搜索会是快速和高效的。

被用作数据存储的X.500目录促使产生不存储空值的设计。例如，对象中不存在的(可选)值不存储在目录中。这使得高效使用存储空间，并且得到更强搜索。任何对属性的搜索只需要考虑那些具有该属性的数据的对象。

本系统的数据层次结构很好地与UDDI标准的意图相匹配。当请求到达以删除UDDI对象时，它直接映射到目录中子树的删除。例如，删除服务包含删除其名字和描述，以及全部其绑定模板。所有这些均是目录中的服务项的子对象。因此，本系统自服务项向下删除子树。这容易实现并且高效。

域是表示层次子树的基部的名字。在X.500术语中，域被称作上下文前缀。在LDAP术语中，它被称作后缀。为UDDI数据库提供域名允许在数据库中使用数据的真正分布(就X.500而言)。UDDI标准仅支持复制。通过本系统能够对应用透明地使用目录分布设备。

例如，假定企业内部部署UDDI，但是具有2个开发位置。对于此设施，它们能够在每个位置部署UDDI服务器，其中分布允许每个位置透明地观看两个注册中心上发布的项目。

其优点是允许分布′免费(for free)′。例如，UDDI服务器不必进行任何额外工作，并且目录系统有效地将信息岛链接在一起。

UDDI标准中没有规定如何存储用户信息。通过建立用户对象，涉及用户的全部信息能够被存储在一个单独的对象中，并且该对象能够被用作保存用户发布的全部对象的子树的根。这使得安全性的定义更加简单。例如，如果所考虑的对象(企业，服务或甚至TModel)在用户的用户对象下面，则用户控制它。

UDDI定义包含重复单元的对象。对于例如性能，可搜索性和可管理性的益处，这些重复单元能够被表示成子对象。

将重复的结构化数据存储为子对象允许在目录中高效地表示数据，其中每个字段分别可用于搜索(和为搜索而索引)。

例如，企业实体名字能够被存储为企业实体对象的子对象。另一个例子是能够被存储为企业实体对象下面的子对象的企业描述。

这类系统的优点是允许搜索名字(是常见的UDDI搜索)，并且该项的DN提供名字属于的对象的DN。

UDDI定义冗余′容器′节点(只包含子对象子结构而不是属性的UDDI结构)。这些可以被从查询结果中清除，因为它们能够以相对较低的成本构造。在某些情况下，属性能够被从子节点提升到其父节点，以从目录表示中清除现在冗余的子节点。

例如，由于不包含属性，在目录模式中不表示tModelInstanceDetails。象其子对象OverviewDoc的属性那样，由于其属性被提升到tModellnstancelnfo父对象，在目录模式中不表示instanceDetails。在目录中不表示类别和标识符包(bag)，使其内容作为包的所有者的子对象。

其优点是减少了目录中项的数量。尤其是，它使DIT的深度最小，从而能够改进性能。

图12根据本发明实施例示意性图解了层次结构。提供一或多个域或前缀121。在每个域121下面，可以有一或多个用户122。在每个用户122下面，可以有一或多个TModel 123和一或多个企业实体(BE)124。在每个企业实体124下面，可以有一或多个发布者声明(PA)125，一或多个企业服务(BS)126和一或多个服务投影(SP)127。在每个企业服务(BS)126下面，可以有一或多个绑定模板(BT)128。通过特定实现，能够根据需要放置别名。例如，服务投影对象(如图12中三角所示)可以从企业实体对象生出以作为别名。

通过读取整个公开内容可理解如图12所示的这个模式设计的优点。

发布者声明被放置在它们所针对的企业实体下面，因为它们在find_RelatedBusinesses调用的环境中最频繁使用，所述调用指定企业关键字，并且正经由发布者声明寻找与企业关键字相关的所有企业。本系统找到指定的企业，接着读取它下面的所有发布者声明(是完整的)。这是找到相关声明的快速和高效的方式。

其优点是允许快速和高效的搜索。它也允许容易地维护数据完整性。例如，当删除企业时，任何发布者声明也被自动删除。

发布它们的用户能够改变(或撤消/隐藏)TModel。将它们放置在表示用户的项下面使得安全性变得简单。例如，如果TModel位于用户项下面的子树中，则能够修改它。如果不是这样，则不能修改。

更详细地，如果尝试进行改变的用户的DN(区别名字)与TModel的DN的前缀匹配，则该用户能够修改该项，否则不能。目录能够被用来进行这个确定(如果DN不存在，则发生命名异常)，UDDI服务器也能够进行这个确定。

当从数据库中删除对象时，与该对象相关的信息也可以被删除。通过根据本模式的实施例使用的层次设计可对此进行大大简化。当删除对象时，能够删除以其为根的整个子树，并且这个处理能够删除所有相关信息(并且通常只删除该相关信息)。能够自底向上地删除子树。当删除所有其子对象时，只能删除每个项。通过按照相反DN顺序列出所有子对象来对此进行管理。这保证删除在其父对象之前的子对象。

其优点是排序列表方法是更加复杂的递归使用的替代。此外，它相对简单和存储器高效。当按照DN对子树中的所有项进行排序并且以相反顺序执行删除时，这保证在其父对象之前删除所有子对象。

例如，当删除企业服务时，系统删除与之相关的所有绑定模板，其TModel实例信息，和各种相关类别信息。通过删除以企业服务为根的子树，可以删除所有这些。

由于这个模式的设计中使用的层次结构，对象的DN揭示了所有关系链和对象的控制。注意，推论也取决于名字属性的精心选择。

其优点是能够减少用来收集信息的搜索或读取的数量。例如，对于作为子对象(例如名字)的搜索结果，每个项的DN揭示出父对象(例如企业实体)和所有者帐户。

例如，企业服务的DN揭示出它属于的企业，以及控制它的用户。

目录不保证结果的任何顺序。当处理复杂结果(例如企业实体及其企业服务，以及其适当名字和描述)时，通过得到搜索结果并按DN对其排序，能够简化输出的构造。这对它们进行组织，使得结果的构造变得相对简单。在其子对象之前构造每个对象，所以易于将子对象放置在其父对象下面，使得在其服务之前组织企业的结果。对象的所有子对象出现在相同类型的下一对象之前，一个企业的全部服务在下一企业出现之前。这也允许简单的递归构造，因为相同的道理适用于每个层次。

其优点是使构造UDDI结构所需的遍历原始项列表的次数最小。

例如，在排序之后，企业A的结果后面跟有其第一服务AA的结果，该服务的名字，A的第二服务AB，及其名字，接着是第二企业B。

也可以对子对象执行搜索。例如，频繁搜索请求可以是″通过发现一个(或更多)其子对象来发现x″。通过搜索能够发现企业的一个方式是指定例如绑定模板中出现的TModel。换言之，查询是″发现具有一服务的所有企业，该服务具有引用这个模型的绑定模板″。通过发现派生对象的DN并且丢弃不期望的层次以产生企业实体的DN，能够进行这些查询。有利的是，这也消除了复制。这个搜索方法部分源于本发明实施例的层次结构。

保证唯一的关键字的使用简化了工作。能够针对单个关键字搜索整个数据库，并且唯一性保证或者没有结果(如果不存在该关键字)，或者有一个结果(如果它存在)。不必费心将搜索限制在父对象的范围内。这由目录产生增强的性能，因为它能够使用数据库索引进行优化。

其优点是利用了最快速类型的目录查询。另一个优点是在从另一个对象引用指定对象的情况下，保证唯一的名字是重要的。

多数索引系统的特性在于它们是数据相关的。如果数据是″从小到大的″(最左部分最迅速地改变)，则该数据往往被扩展，所以索引能够提供最大性能。反之，如果数据是重复的，则索引不能非常有效。能够使用UUID(全局唯一标识符)算法，其表现出″从小到大″特性。其优点是使目录性能最大。

关键字可以被加到导出对象上。在重复数据单元被加到子对象的情况下，需要增加名字属性，这会形成其DN的最后的弧。在目录中，名字属性不同于其兄弟对象，因为相同父对象的任意2个子对象均不会具有相同名字。

可以使用两种关键字。对于不要求顺序的子对象，使用UUID，因为这些被保证是唯一的。如果顺序是重要的，则具有单调增加特性的关键字被用来保证顺序。

在UDDI标准中，企业实体能够提供两种服务：它控制的服务(在数据库中通过子对象表示)，和它对其提供接口的服务，尽管它们由另一个企业实体提供。在公开的UDDI数据库中通过别名表示后者。别名确切地提供正确的特性。例如，如果其所有者以某种方式改变初始对象(服务)(或许增加另一个绑定模板)，则通过别名引用的对象也″改变″。此外，在企业实体下面对服务的任何搜索会产生真实和带别名的服务。

例如，别名能够被用于服务投影，其中企业能够指向另一个企业下面定义的服务。

其优点是起作用的别名允许基本上涉及要自动提供的″替代名字″的功能。此外，如果目录支持别名完整性，则如果删除原始服务，那么任何投影会被自动清除。

在UDDI标准中，存在若干地方，其中我们不希望直接引用到另一个对象，而是希望引用到中间步骤-例如在TModel实例信息的情况下，或是引用到发布者声明中的企业实体。在这些情况下，别名会使代码复杂。因此，本系统可以使用对对象的引用。因为根据实施例的本系统保证每个对象具有唯一关键字，则该关键字确切充当引用，有时被称为″外″键。

能够使用辅助对象类执行属性分组。在处理发布者声明时，需要使用唯一标识发布者声明的3个属性：2个企业实体关键字，和其间的关系找到发布者声明的能力。

然而，关系被指定为键值标识引用(keyed reference)，其自身是3个不同属性：TModel关键字，键名和键值。一种方式是将这个关系存储为发布者声明的子对象。然而这不允许对特定发布者声明进行最高效的搜索。通过使关系键值标识引用(relationship keyed reference)作为发布者声明项的辅助类，可以在单个搜索中搜索所有5个属性，于是确切隔离出所需的发布者声明对象。

这个模式的一个设计可以使用普通面向对象设计技术，并且产生例如具有相同属性名字的所有键值标识引用。然而，这个设计会使得更加难以隔离例如企业实体类别键值标识引用和避免使其与TModel类别键值标识引用的混淆，并且使之成本更高。也会使得有必要在过滤器中包含对象类项，并且这样的项是弱的(在数据库中高度重复)。

例如为每个不同类型的键值标识引用提供不同对象类和不同属性名字意味着对特定属性名字的任何搜索有必要隐含对象类。也意味着目录服务器能够构造这样的索引，该索引只在其中具有针对特定类型的期望项的项。这种索引会更小并且因此更快速。

例如，类似：″euBusinessEntityName＝Smith^*′的搜索会查询针对euBusinessEntityName的索引，所以不能与在称作euTModeIName的属性中包含Smith的项混淆。

这需要UDDI标准范围以外的工具。这种工具可能需要提供进行超出UDDI标准中指定的范围的访问的手段。为允许这种工具，本发明定义抽象类，抽象类绑定表示单个UDDI概念的所有对象类。这允许定义能够查看例如所有名字或所有键值标识引用的搜索。

例如，存在抽象类euName，它是包含euBusinessEntityName和euTModeIName的所有名字型对象类的超类。

UDDI标准规定可以以例如大小写敏感和大小写不敏感的方式搜索名字。这可以通过大小写不敏感地进行索引，并且接着检索各个项并且大小写敏感地对其进行检查来实现，但是这种方案以性能为代价。在这些情况下最好定义包含相同数据但是被不同索引的影像字段。类似地，影像属性能够被用于语言中的变化，例如可区别标记。

例如，euBusinessEntityName对象类包含每个名字的2个拷贝。大小写不敏感地索引第一版本，大小写敏感地索引第二版本。这允许构造无论请求何行为均最优执行的搜索过滤器。

这个数据库中的每个属性(对象类之外)可以是单值的。这使得目录能够构造更加高效的索引，并且提供更好的搜索性能。

这也排除了搜索中产生虚假肯定结果的可能性。例如，考虑寻找以″Fr″为开始并且以″nk″为结束的名字的搜索。可能预计这个搜索会产生具有类似″Frank″的名字的(有效)项。然而如果名字为多值属性，则会得到具有类似″Fred″和″Tink″的2个名字的无效项，因为这一个项与两个规定的准则匹配。通过使用单值名字(其每个是项的子对象)，可排除″Fred″和″Tink″的虚假匹配。

操作属性是由UDDI应用管理但是用户不可见的特殊属性。

在UDDI数据的存储中，应当能够具有将使用中的TModel与已经″撤消″的TModel区别开的方式。当TModel被删除时，它仍然会被通过许多使用，所以它不能被真正删除。而是将其隐藏，这意味着它不会作为find TModel调用的结果的一部分被返回，而是仍然能够通过get TModelDetal调用来查询。这通过使用称作euHidden的属性来实现，该属性被加到被隐藏的TModel中。向搜索TModel的任何过滤器中增加排除包含euHidden属性的任何项的搜索步骤是有好处和高效的。

在目录实现中，具有主要为一个值的属性通常被认为是非常低效的。例如，99％的项具有被设置成假的隐藏属性会产生不良性能-索引会相当多地不可用。

被认为是更多有效的方式是没有隐藏属性地存储大多数项，并且只向要隐藏的那些项增加属性。这具有不需要存储空间保存所有那些″假″值的附加好处。现在，用于发现所有那些不被隐藏的TModel的过滤器变成″(！(euTModei＝^*))″-这是存在测试的否定，并且存在测试是快速的，尤其是当属性只存在于小部分的项中时。

现在描述用于解决在目录环境中的实现和UDDI标准的问题的本发明实施例。存在若干针对X.500模式的元素。这些元素包含属性定义，对象类定义和名字绑定定义。属性定义规定单个数据单元，从而为其指定唯一标识符(OID)，名字和数据类型。对象类定义规定作为整体操作的属性集合。它指定唯一标识符(OID)，名字和属性列表；属性可以是所需的或可选的。名字绑定规定可能的层次结构的部分。名字绑定规定可以存储在另一个对象类下面的一个对象类，并且规定子对象的属性(多个属性)，它在这个上下文中命名该子对象。

存在若干提出附加设计要求的发现限定符。一个发现限定符是大小写敏感性，用于提供以大小写敏感和大小写不敏感的方式高效搜索文本数据的能力。

根据本发明的实施例，通过在对象中提供不同索引的附加字段能够解决大小写敏感问题。根据这个实施例，文本数据在类型caseExactString的属性和类型caseIgnoreString的属性中被存储两次。发现限定符确定搜索的字段，从而产生最大性能。

例如，如果企业实体具有类似″McKenna′s Iron FoundryServices″的名字，则该串会被存储两次，一次是在大小写敏感地索引的字段中，一次是在大小写不敏感地索引的字段中-存储的数据相同，但是基础目录所产生的索引不同。

另一个问题涉及高效实现服务投影。根据本发明的实施例，可以使用X.500别名设施解决这个问题。存在若干能够处理服务投影的方式。本发明的这个实施例通过目录别名处理它们。这是实现它们的特别高效的方式。它保证投影与基服务的一致性，因为通过别名直接访问基服务。它也保证投影会在删除基服务时消失，于是保证一致性。

例如，如果称作Williams会计服务的企业实体发布称作总帐交叉核对的WEB服务，并且希望在称作Williams审计服务的第二企业实体下面提供这个相同服务，这可以通过将别名项放置在第二企业实体下面来实现。列举Williams审计服务提供的服务的查询方会发现总帐交叉核对服务，就象其会发现Williams审计服务直接提供的任何服务那样。

另一个问题涉及高效实现关键字。根据本发明的实施例，这通过使用外部关键字和其中顺序不重要的关键字的UUID来解决。在顺序很重要的情况下可以使用序号。尽管关键字被表示成串，然而它们不是真正的文本数据。在对大小写或可区别标记不敏感的情况下对其进行比较。

外部可见的关键字遵循一组规则。当实现符合UDDI规范的版本2的数据库时，它们保存符合ISO-11578的UUID。当实现符合UDDI规范的版本3的数据库时，它们保存遵循该版本规范中设定的规则的键串。

注意，内部用来将单元链接在一起的关键字遵循另一个组规则。那些顺序不重要的关键字使用UUID。在顺序很重要的情况下使用序号。

例如，表示称作Williams审计服务的企业实体的类别包的单元的键值标识引用可以引用具有关键字12345678-1234-1234-1234-1234567890ab(UDDIv2)的TModel。类别包中键值标识引用的顺序不重要，但是键值标识引用需要充当对象的名字属性的关键字。于是我们可以产生这个对象的有些类似于87654321-4321-4321-4321-ba0123456789的UUID关键字，并且使用其作为这个对象在目录中的名字属性。

另一个问题是在期望X.500分布的情况下，数据可以被组织到域中。根据本发明的实施例，这通过在用户之上建立数据库层来解决，因而每个数据库能够被放到不同的服务器上。

UDDI标准不允许名字空间是分布式的。这意味着通过复制或通过透明地具有管理分布式名字空间的后台数据存储，多个UDDI注册中心能够彼此配合操作。

具有名字前缀的每个数据库能够利于分布式名字空间。这个前缀是定义域的一组节点。这些节点能够被认为是每个UDDI注册中心之上的数据库层。这些节点被放置在用户层之上。

图11图解了称作″域″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服务器′了解分布′。能够指定2个分立的目录前缀-一个用于搜索和读取，另一个用于增加项。为部署分布式服务器，按照eTrust目录管理指南为分布而构造基础eTrust目录服务器代理。每个分立eTrust UDDI节点配有唯一节点名字。每个节点的搜索/读取前缀被设置成′世界′或′公司′节点名字。每个节点的增加前缀被设置成该节点的唯一名字。

通过这种方式，每个节点向其自身的目录数据库增加项，但是通过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

(在这个例子中假定已经实现简单的userid和口令系统)

另一个问题涉及以高效方式表示涉及企业实体(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＝23456789-2345-2345-2345-234567890abc

注意，企业实体对象的大部分明显内容实际被存储在作为企业实体对象的直接子对象的对象中。

图15根据本发明实施例图解了引入层次结构到子结构中以表示企业实体中相对复杂对象的例子。在图15中，多值单元：

对于子对象152

语言en

名字CA

对于子对象153

语言IN

名字CATS

被表示成企业实体151的子对象152,153。可以没有子对象，也可以有更多的子对象。

另一个要解决的问题涉及以高效方式表示涉及企业服务(UDDI标准中描述的对象类)的数据。

根据本发明的实施例，通过将唯一字段表示为对象的属性并且将重复单元表示为子对象来解决此问题。

可以以至少两个方式实现企业服务。第一个方式是企业服务表示企业实体提供的、可通过一或多个访问路径得到的单个概念性服务，其中每个访问路途由绑定模板表示。第二个方式是企业服务作为服务的分组机制，其中在绑定模板层次划分为各个服务。在任一情况下，在UDDI规范中定义了数据字段。

企业服务的单元是企业和服务关键字。企业关键字指定拥有服务的企业实体。这不必是在其下进行发现的企业实体。通过服务投影可以在若干企业实体下面发现单个服务。服务关键字是整个UDDI数据库中服务的唯一标识符。两个关键字被表示成串。

set object-class uddiObjectClass：403＝

{#企业

name＝euBusinessService

subclass-of top

must-contain

euBusinessServiceKey，

euParentBusinessKey

}；

没有企业服务对象的可选内容。所有其它内容包括可能的重复单元，所以被表示成子对象。企业服务的潜在子对象是：绑定模板(见下文)；名字(为排序而加键值标识、包含名字串和语言代码的对象)；描述(为排序而加键值标识、包含描述串和语言代码的对象)；和标记为类别信息的键值标识引用。

例如，企业服务对象可以是：

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

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

注意，企业服务对象的大部分明显内容实际被存储在作为企业服务对象的直接子对象的对象中。

尽管图15根据本发明实施例图解了引入层次结构到子结构中以表示企业实体中相对复杂对象的例子，然而它同样图解了根据本发明实施例将层次结构引入到子结构中以表示企业服务中相对复杂对象的例子。图15的企业实体151同样适用于企业服务，其中企业服务的多值单元被表示成企业服务151的子对象152,153。可以没有子对象，也可以有更多的子对象。

另一个问题涉及以高效方式表示涉及绑定模板(UDDI标准中描述的对象类)的数据。根据本发明的实施例，通过将唯一字段表示为对象的属性并且将重复单元表示为子对象来解决此问题。

绑定模板表示可以访问具体服务的方式。唯一需要的绑定模板的单元是其关键字，和它应用到的服务的关键字。可选单元可以包含接入点或驻留重定向器(对象应当确切具有其中的一个)。如果提供接入点，则也应当提供接入点类型。

set object-class uddiObjectC1ass：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(概述文档对象的部分)，用户关键字和隐藏标记。

隐藏标记是TModel的处理的单元。隐藏标记是如何处理deleteTModel调用。当TModel被″删除″时，隐藏标记被加到对象中。这意味着不会向findTModel调用返回对象，但是可被getTModel调用访问。

set object-class uddiObjectClass：405＝

{#tmodel-对概念的引用

name＝euTModel

subclass-of top

must-contain

euTModeIKey，euTModeiName

may-contain

euAuthorizedName，

euOperator，

euOverviewURL，

euParentUserKey，

euHidden

}；

可能的子对象是：描述(为排序而加键值标识、包含描述串和语言代码的对象)；标记为类别或标识符信息的键值标识引用；和概述文档描述(为排序而加键值标识、包含描述串和语言代码的对象)。

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的多值单元被表示成TModel151的子对象152,153。可以没有子对象，也可以有更多的子对象。

另一个问题涉及以高效方式表示涉及发布者声明(UDDI标准中描述的对象类)的数据。

根据本发明的实施例，通过将唯一字段表示为对象的属性并且将辅助类用于所需关系键值标识引用来解决此问题。

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

发布者声明的所需单元是其关键字，到达和来自企业(to andfrom business)和用户关键字，状态和关系。关系被指定为键值标识引用，并且被存储为发布者声明项的辅助类。状态被存储为串，但是从完成状态对象提出其可能的值。所有关键字被表示成串。

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

euToUserKey＝98765432-5432-5432-5432-cba098765432

euPublisherAssertionStatus＝status：complete

注意，会存在与这个项相关的辅助类；它会具有对象类euPublisherAssertionRelationshipKeyedReference，并且会指定在所命名的2个企业实体之间声明的关系。一个例子可以是：

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

euPublisherAssertionKeyName＝wholly-owned subsidiary

euPublisherAssertionKeyValue＝parent-child

另一个问题涉及以高效方式表示涉及键值标识引用(UDDI标准中描述的对象类)的数据。能够高效搜索键值标识引用的特定集合的需要使得这个更加复杂：例如企业实体上的类别包。

根据本发明的实施例，通过建立表示键值标识引用的抽象基类并且针对每个期望集合将分为子类来解决这个问题。集合在目录中不具有表示。例如，它们的存在不超过相同子类的一组键值标识引用，从而作为相同对象的子对象存在。例如，企业实体的类别包是类euBusinessEntityCategoryKeyedReference的对象，其作为指定企业实体的子对象。注意，企业实体对象能够具有作为子对象的若干键值标识引用对象，其中只有其对象类清楚哪些是类别包的一部分，哪些是标识符包的一部分。

在UDDI数据模型内的若干位置使用键值标识引用。它们包含TModel关键字，键名和键值。键值标识引用的2个用途是类别包和标识符包。这些包是键值标识引用的集合，并且对于搜索是重要的。如果这些包通过包含无差别键值标识引用的对象来表示，则可能相当难以实现高效搜索。这就是实现键值标识引用的若干子类的原因。通过类euBusinessEntityCategoryKeyedReference的一或多个子对象表示企业实体上的类别包。这使得易于用其类别包中的指定键值标识引用实现对企业实体的高效搜索。

下面的例子示出如上所述的抽象类和导出类之一euBusinessEntityCategoryKeyedReference。注意，从抽象类继承针对键值标识引用的关键字，而TModel关键字，键名和键值全部在导出类中指定，所以它们可以具有用于搜索的有区别的名字。

set object-class uddiObjectClass：201＝

{#作为所有键值标识引用的父节点的抽象类

name＝euKeyedReference

subclass-of top

must-contain

euKeyedReferenceKey

}；

set object-class uddiObjectCalss：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

#从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被唯一命名，能够通过单索引访问来找到它们。

另一个问题涉及通过关系实现发布者声明的高效搜索。根据本发明的实施例，通过使关系键值标识引用作为发布者声明项的辅助类来实现此目的。如果键值标识引用是子对象(一个实现)，则不能以同样的效率对其进行搜索，并且对关系的搜索不能与对发布者声明内容的搜索，例如关于状态的(关键)过滤器(仅考虑完整声明)相结合。

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，并且上面列出的最后三个属性是该类的数据元素。

根据本发明的实施例，诸如Computer Associates的eTrust^TM的目录可以被用来实现理想的企业UDDI注册中心平台。作为完全符合LDAPv3，X.500电子目录的eTrust目录可以被用来支持UDDI WEB服务实现。‘eTrust’目录允许UDDI实现影响到已经在大规模业务关键级目录服务应用中得到证明的高度成熟的目录解决方案。

‘ eTrust’有许多独特的特性，使得其在作为建立UDDI注册中心的平台方面极有吸引力。其中一些包含：访问控制策略，角色，安全代理，相互认证，分布式认证，分布式SSL证书主题验证和网络地址确认；分布和路由能力，包含并行分布式搜索，负载分担，查询流和最短路径路由；多主复制模式(multi-master replication scheme)，其将基于应答的机制(称为多写(multi-write))的速度和效率与基于状态的恢复和调节技术结合起来；可用性特性，包含数据库热切换，网络故障恢复和目录系统代理(DSA)故障恢复；被认为是快速的高速缓存设计；和部署特性，包含动态配置(数据类型，模式规则，安全，知识等等)，无限制的数据长度，一般信息完整性规则，广泛的管理控制和交互式命令控制台。

eTrust目录提供得到证明的X.500目录解决方案。在其得到证明的基础上可实现UDDI语义桥，以允许建立完全符合标准的UDDI注册中心。由于基础目录解决方案的能力，这里公开的实施例可以实现灵活的安全性，分布和可管理性，而不必改变或扩展现有UDDI标准。

本实施例的一个问题涉及如何映射在目录的分离部分中存储的实体之间的关系。

虽然UDDI数据结构主要是层次化的，然而在不同对象的交叉关系方面会存在问题。

主要有两类关系，即替代名字(alternative names)和交叉关系(cross relationship)。根据本发明的实施例，通过利用别名的概念来实现替代名字，从而解决该问题。这基本上具有将外部实体‘连接’作为主实体的虚拟子实体的效果。

本实施例利用唯一关键字解决交叉关系的问题。这基本上具有建立相当类似于RDBMS技术的主/外键系统的‘关系指针’，以模拟层次目录系统内不相交子树之间存在的数据实体之间的关系的效果。

现在描述基于本发明实施例的别名的使用。通过UDDI企业服务投影的实现可最清楚地说明第一种情形。企业服务投影实际上是企业服务的替代名字。企业服务投影是看上去属于企业A，但实际上由企业B拥有和定义的企业服务。

参照图5，企业服务51，即企业A所拥有的服务看上去也属于企业B。企业A对企业服务51作出的任何改变均会反映在企业B下面出现的投影的服务中。类似地，如果企业服务51被从注册中心中删除，则它不再出现在企业A和企业B下面。另外，企业实体B不可以编辑或改变企业服务51。为了编辑和所有其它发布目的，只有企业A必须访问企业服务51。

目录别名系统可以被用来实现这个效果。企业服务51的别名被加到企业实体B中。该别名对于目录服务器是特殊的标记，实际告知‘当某方查看此别名时，向其出示在此的这个其它项’。

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

另外，目录服务器可以被配置成当其在每个父对象下面被搜索一次时，将投影的企业服务显示再次。当进行需要解析企业服务的父对象的搜索时，这是有用的。

某些情况下需要目录层次结构的不相交部分中的对象保持关系。

这个的一个例子是绑定模板和TModel之间。在整个UDDI中TModel被用于各种目的。它们是分类关键字，搜索标识符，(UDDI)关系描述符，以及在这个实例中的技术规范‘指纹(fingerprints)’。‘连接’到绑定模板的TModel描述绑定模板(参见图8)遵从的技术规范。例如，发布者可以连接一个声明其绑定模板遵从SOAP 1.1标准的TModel。

注册中心通常包含有限的TModel集合，其中的许多TModel会被数百或甚至数千绑定模板项引用。在某些情况下，注册中心会返回任何‘连接’的TModel的细节和绑定模板的细节。

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

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

图7示出了TModel关键字如何建立两个实体之间的关系。

发布者声明是UDDI数据库的重要元素。如上所述，它为用户提供发现与有关企业实体相关的企业实体，以及它们如何相关的能力。

发布者声明被设计成防止滥用，其中仅当所涉及的两个企业实体的所有者已经声明关系时，所声明的关系才变得可见。这种保护的代价是使得实现复杂，并且需要精心的设计以避免性能恶化。

一个问题是完整性。发布者声明比任何其它UDDI构造具有更加复杂的生命周期。当企业实体的所有者作出关于该企业及其与另一企业实体的关系的声明时，发布者声明便开始存在。另一企业实体的所有者可以请求状态报告，并且发现已经作出哪些关于其企业的声明，或者它们被通知排除(out-of-band)。在任一情况下，另一企业实体的所有者可以选择对两个企业实体之间的关系作出匹配的声明。此时，声明是完整的，并且对调用findRefatedBusinesses的用户可见。可以修改或删除一或两个声明，并且声明再次变得不完整，而且应当不再可见。另外，任一企业实体的删除应当立即清除声明。

可以通过保持声明完整性的方式来管理发布者声明对象。

期望企业实体的所有者能够作出(或清除)关于该所有者控制的企业实体的声明。

本发明的实施例基于这样的假设，即UDDI数据库是“以读为主”的存储，主要用于X.500目录。为此，优化设计以得到更好的读取性能，甚至以加重写入的负载为代价。

被称作发布者声明的对象类被设计成保存超过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)。

下一个问题涉及如何在搜索操作期间优化中间搜索结果集合的构造，使得考虑到目录存储介质的限制，目录访问和迭代存储器内操作最少。实际上，可以以任意顺序存储和返回目录项，并且目录结果可能过大以致不能排序。

根据本发明的实施例，提供一个面向对象的存储器内数据存储系统，该系统与一个按区别名字对中间结果进行排序的唯一结构排序模式相结合。这允许一个搜索返回许多不同类型的对象-企业实体(BusinessEntities)，企业服务(BusinessServices)，等等-并且仍然允许系统容易地构造正确的XML结构以向用户返回数据。注意，通过XML进行Web服务交互。

现在说明这个系统的描述。根据以下层次结构在目录中提供(部分地)本发明的UDDI企业实体和任何子数据元素：

企业实体

●企业服务

○绑定模板

○服务名字

●企业服务

○绑定模板

○服务名字

●企业名字

●企业描述

注意，已经结合本发明涉及子结构和对象分割的方面说明了服务名字，企业名字和企业描述。

企业实体检索代码根据所需企业实体的唯一关键字执行目录子树搜索。这个搜索将返回找到的项和所有子项。目录标准不保证返回的项具有任何特定的顺序-或者甚至子项紧跟在其父项后面。

因此，检索代码接着按照区别名称对返回的项进行排序。这保证子项将排列在其父项之后，并且能够容易地区分父子关系。可以使用各种排序算法。所使用的排序算法应当在各个项被部分排序的情况下表现出高性能特征。

用于结构构造的算法在操作上主要是′深度优先、从左到右的树遍历′。这在图论中也称为′后序遍历′。

排序的列表被传递到新企业实体对象的构造函数方法。这个对象可以是例如被设计成表示UDDI企业实体的面向对象编程构造。企业实体对象包含根据最后的项中提供的数据′构造其自身′的代码。该代码迭代地移动通过列表，对每个项作出判决。可以理解，列表中的第一项应当是企业实体本身的主项，并且一旦发现另一个企业实体，可以理解，构造已经完成-列表的顺序保证了这一点。一旦发现企业服务或其它子项，实例化合适类型的对象，并且将列表和告知从列表中何处开始的指针传递到新对象的构造函数。

每个对象基本上包含类似的处理代码以处理其自身的构造，以及将任何子项的构造委托给合适的子对象。

通过这种方式，只需进行单次目录搜索，并且以高效方式处理结果列表，其中每个项只被处理一次。如果列表保持任意顺序或以某种其它方式排序，则列表必须经过多遍处理，以便根据结果项正确地构造UDDI层次结构。

将构造和列表处理委托给层次结构中的不同编程对象使得处理代码的长度相当小，从而更加高效和更加快速。

图9图解了编程构造(对象)，包含排序项列表的表示。确定在项的列表中是否存在任何其它的项。如果没有额外的项(否，步骤S100)，则过程退出(步骤S118)。如果有额外的项(是，步骤S100)，则取出列表中的下一项(步骤S102)。接着确定该项是否具有这个对象类型。如果该项具有这个对象类型(是，步骤S104)，则根据该项设置对象属性(步骤S106)，并且过程返回到步骤S100。如果不具有这个对象类型(否，步骤S104)，则确定是否已经处理过具有这个对象类型的项(步骤S108)。如果尚未处理过具有这个对象类型的项(否，步骤S108)，则过程返回到步骤S100。如果已经处理过具有这个对象类型的项(是，步骤S108)，则确定该项是否这个对象的固有部件(例如名字，描述等等)。如果是固有部件(是，步骤S110)，则该项被加到对象属性中，并且可以执行额外的处理(步骤S112)，过程返回到步骤S100。如果不是固有部件(否，步骤S110)，则确定该项是否这个对象的子对象(例如BusinessService是BusinessEntity的子对象)。如果是子对象(是，步骤S114)，则系统实例化正确类型的对象，并且将项的列表传递到构造函数(步骤S116)，过程返回到步骤S100。如果不是子对象(否，步骤S114)，则过程返回到步骤S100。

以下的‘实字’例子演示了LDAP目录可能预计返回的任意顺序的种类。

SearchResultEntry

objectName：

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

attributes

type：objectClass

value：businessEntity

type：businessKey

value：1ba3034aeef738da00eef78599fe0004

SearchResultEntry

objectName：

descriptionKey＝1ba3034aeef738da00eef786302b0008，businessKey＝1ba3034aeef738da00eef78599fe0004，userKey＝1ba3034aedb9154900edb915491c0001，o＝CA

attributes

type：objectClass

value：uddiDescription

SearchResultEntry

objectName：

serviceKey＝1ba3034aeef738da00eef789707f000c，businessKey＝1ba3034aeef738da00eef78599fe0004，userKey＝1ba3034aedb9154900edb915491c0001，0＝CA

attributes

type：objectClass

value：businessService

SearchResultEntry

objectName：

nameKey＝1ba3034aeef738da00eef78970da000d，serviceKey＝1ba3034aeef738da00eef789707f000c，businessKey＝1ba3034aeef738da00eef78599fe0004，userKey＝1ba3034aedb9154900edb915491c0001，o＝CA

attributes

type：objectClass

value：businessServiceName

SearchResultEntry

objectName：

bindingKey＝1ba3034aeef738da00eef7899fb7000e，serviceKey＝1ba3034aeef738da00eef789707f000c，businessKey＝1ba3034aeef738da00eef78599fe0004，userKey＝1ba3034aedb9154900edb915491c0001，o＝CA

attributes

type：objectClass

value：bindingTemplate

SearchResultEntry

objectName：

nameKey＝1ba3034aeef738da00eef7862fe50007，businessKey＝1ba3034aeef738da00eef78599fe0004，userKey＝1ba3034aedb9154900edb915491c0001，o＝CA

attributes

type：objectClass

value：businessEntityName

列表1-以粗体突出的名字项是位于列表顶端的企业实体项的叶节点，并且如果在企业服务项和企业实体的其它分支子节点之前出现，则会有利。然而，它出现在列表的末端，迫使任何处理代码搜索整个列表以确保已经处理企业实体的所有直接子节点。

因此，按照根据本发明实施例制定的规则而排序的相同数据的一个版本：

SearchResultEntry

objectName：

attributes

type：objectClass

value：businessEntity

type：businessKey

value：1ba3034aeef738da00eef78599fe0004

SearchResultEntry

objectName：

attributes

type：objectClass

value：uddiDescription

SearchResultEntry

objectName：

attributes

type：objectClass

value：businessEntityName

SearchResultEntry

objectName：

serviceKey＝1ba3034aeef738da00eef789707f000c，businessKey＝1ba3034aeef738da00eef78599fe0004，userKey＝1ba3034aedb9154900edb915491c0001，o＝CA

attributes

type：objectClass

value：businessService

SearchResultEntry

objectName：

attributes

type：objectClass

value：bindingTemplate

SearchResultEntry

objectName：

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＝

{#在KeyedReference及其所有导出类中使用

name＝euKeyedReferenceKey

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：202＝

{#在UserAccount中使用

name＝euUserKey

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：203＝

{#在BusinessEntity，TModel，可能的其它类中使用

name＝euParentUserKey

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：204＝

{#在BusinessEntity中使用

name＝euBusinessEntityKey

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：205＝

{#在BusinessService，可能的其它类中使用

name＝euParentBusinessKey

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：206＝

{#在BusinessService中使用

name＝euBusinessServiceKey

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：207＝

{#在BindingTemplate，可能的其它类中使用

name＝euParentServiceKey

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：208＝

{#在BindingTemplate中使用

name＝euBindingTemplateKey

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：209＝

{#在TModel中使用

name＝euTModelKey

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：210＝

{#在PublisherAssertion中使用

name＝euPublisherAssertionKey

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：211＝

{#在PublisherAssertion中使用

name＝euFromBusinessKey

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：212＝

{#在PublisherAssertion中使用

name＝euFromUserKey

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：213＝

{#在PublisherAssertion中使用

name＝euToBusinessKey

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：214＝

{#在PublisherAssertion中使用

name＝euToUserKey

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：216＝

{#在DiscoveryURL中使用

name＝euDiscoveryURLKey

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：217＝

{#在Contact中使用

name＝euContactKey

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：218＝

{#在Address中使用

name＝euAddressKey

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：219＝

{#在Address中使用

name＝euAddressTModelKey

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：220＝

{#在AddressLine中使用

name＝euAddressLineKey

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：221＝

{#在Phone中使用

name＝euPhoneKey

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：222＝

{#在Email中使用

name＝euEmailKey

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：223＝

{#在Tmodellnstancelnfo中使用

name＝eulnstanceTModelKey

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：224＝

{#在Name，和所有导出类中使用

name＝euNameKey

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：225＝

{#在Decription，和所有导出类中使用

name＝euDescriptionKey

syntax＝caselgnoreString

single-valued

}；

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

#键值标识引用中使用的属性

set attribute uddiAttributeType：301＝

{#在BusinessEntityCategory中使用

name＝euBusinessEntityCategoryKRTModel

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：302＝

{#在BusinessEntityCategory中使用

name＝euBusinessEntityCategoryKRKeyName

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：303＝

{#在BusinessEntityCategory中使用

name＝euBusinessEntityCategoryKRKeyValue

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：304＝

{#在BusinessEntityidentifier中使用

name＝euBusinessEntityldentifierKRTModel

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：305＝

{#在BusinessEntityldentifier中使用

name＝euBusinessEntityidentifierKRKeyName

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：306＝

{#在BusinessEntityldentifier中使用

name＝euBusinessEntityldentifierKRKeyValue

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：307＝

{#在BusinessServiceCategory中使用

name＝euBusinessServiceCategoryKRTModel

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：308＝

{#在BusinessServiceCategory中使用

name＝euBusinessServiceCategoryKRKeyName

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：309＝

{#在BusinessServiceCategory中使用

name＝euBusinessServiceCategoryKRKeyValue

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：310＝

{#在TModelCategory中使用

name＝euTModelCategoryKRTModel

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：311＝

{#在TModelCategory中使用

name＝euTModelCategoryKRKeyName

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：312＝

{#在TModelCategory中使用

name＝euTModelCategoryKRKeyValue

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：313＝

{#在TModelldentifier中使用

name＝euTModelidentifierKRTModel

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：314＝

{#在TModelidentifier中使用

name＝euTModelidentifierKRKeyName

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：315＝

{#在TModelidentifier中使用

name＝euTModelidentifierKRKeyValue

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：316＝

{#在PublisherAssertion中使用

name＝euPublisherAssertionKRTModel

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：317＝

{#在PublisherAssertion中使用

name＝euPublisherAssertionKRKeyName

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：318＝

{#在PublisherAssertion中使用

name＝euPublisherAssertionKRKeyValue

syntax＝caselgnoreString

single-valued

}；

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

#在名字和描述中使用的属性

set attribute uddiAttributeType：361＝

{#在企业实体名字中使用

name＝euBusinessEntityNameValue

syntax＝CaseExactString

single-valued

}；

set attribute uddiAttributeType：381＝

{#在企业实体名字中使用

name＝euBusinessEntityNameValuelC

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：362＝

{#在企业服务名字中使用

name＝euBusinessServiceNameValue

syntax＝CaseExactString

single-valued

}；

set attribute uddiAttributeType：382＝

{#在企业服务名字中使用

name＝euBusinessServiceNameValuelC

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：363＝

{#在企业实体描述中使用

name＝euBusinessEntityDescriptionValue

syntax＝CaseExactString

single-valued

}；

set attribute uddiAttributeType：383＝

{#在企业实体描述中使用

name＝euBusinessEntityDescriptionValuelC

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：364＝

{#在企业服务描述中使用

name＝euBusinessServiceDescriptionValue

syntax＝CaseExactString

single-valued

}；

set attribute uddiAttributeType：384＝

{#在企业服务描述中使用

name＝euBusinessServiceDescriptionValuelC

syntax＝caselgnoreString

single-valued}；

set attribute uddiAttributeType：365＝

{#在tmodel描述中使用

name＝euTModelDescriptionValue

syntax＝CaseExactString

single-valued}；

set attribute uddiAttributeType：385＝

{#在tmodel描述中使用

name＝euTModelDescriptionValuelC

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：366＝

{#在tmodel实例信息描述中使用

name＝euTModellnstancelnfoDescriptionValue

syntax＝CaseExactString

single-valued

}；

set attribute uddiAttributeType：386＝

{#在tmodel实例信息描述中使用

name＝euTModellnstancelnfoDescriptionValuelC

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：367＝

{#在tmodel实例细节描述中使用

name＝euTModeIInstanceDetailsDescriptionValue

syntax＝CaseExactString

single-valued

}；

set attribute uddiAttributeType：387＝

{#在tmodel实例细节描述中使用

name＝euTModelinstanceDetailsDescriptionValuelC

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：368＝

{#在概述文档描述中使用

name＝euOverviewDocDescriptionValue

syntax＝CaseExactString

single-valued

}；

set attribute uddiAttributeType：388＝

{#在概述文档描述中使用

name＝euOverviewDocDescriptionValueiC

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：369＝

{#在绑定模板描述中使用

name＝euBindingTemplateDescriptionValue

syntax＝CaseExactString

single-valued

}；

set attribute uddiAttributeType：389＝

{#在绑定模板描述中使用

name＝euBindingTemplateDescriptionValueIC

syntax＝caselgnoreString

single-valued}-

set attribute uddiAttributeType：370＝

{#在Contact描述中使用

name＝euContactDescriptionValue

syntax＝CaseExactString

single-valued

}；

set attribute uddiAttributeType：390＝

{#在Contact描述中使用

name＝euContactDescriptionValuelC

syntax＝caselgnoreString

single-valued

}；

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

#其它属性

set attribute uddiAttributeType：400＝

{#在名字和描述中使用

name＝euLanguage

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：401＝

{#在数据库中使用

name＝euRepositoryName

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：402＝

{#在UserAccount中使用

name＝euUserName

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：403＝

{#在UserAccount中使用

name＝euCredentials

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：404＝

{#在UserAccount中使用

name＝euAuthorizedName

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：405＝

{#在UserAccount和TModel中使用

name＝euHidden

syntax＝boolean

single-valued

}；

set attribute uddiAttributeType：406＝

{#在企业实体和tmodel中使用

name＝euOperator

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：407＝

{#在Contact中使用

name＝euContactName

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：408＝

{#在discoveryURL，contact，address，phone，email中使用

name＝euUseType

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：409＝

{#在phone中使用

name＝euPhoneNumber

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：419＝

{#在email中使用

name＝euEmailAddress

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：411＝

{#在address中使用

name＝euSortCode

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：412＝

{#在绑定模板中使用

name＝euHostingRedirector

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：413＝

{#在绑定模板中使用

name＝euAccessPoint

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：414＝

{#在绑定模板中使用

name＝euAccessPointType

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：415＝

{#在tmodel中使用

name＝euTModelName

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：416＝

{#在tmodel中使用

name＝euOverviewURL

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：417＝

{#在address line中使用

name＝euAddressLineValue

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：418＝

{#在tmodel实例信息中使用

name＝eulnstanceParms

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：420＝

{#在PublisherAssertion中使用

name＝euPublisherAssertionStatus

syntax＝caselgnoreString

single-valued

}；

set attribute uddiAttributeType：421＝

{#在discovery URL中使用

name＝euDiscoveryURLValue

syntax＝caselgnoreString

single-valued

}；

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

#抽象类-不要试图在目录中存储它们！

set object-class uddiObjectClass：201＝

{#作为所有键值标识引用的父节点的抽象类

name＝ehKeyedReference

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-classuddiObjectCalss：203＝

{#作为所有描述的父节点的抽象类

name＝euDescription

subclass-of top

kind＝abstract

must-contain

euDescriptionKey

may-contain

euLanguage

#注意：描述也应具有包含描述所有者的串。

#该串通常具有euXXXDescriptionValue模式的名字，

#其中XXX是父对象的名字

#这使搜索的效率最大

#存在属性的第二拷贝，其附有IC-这是忽略大小写的版本

}；

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

#键值标识引用类型

set object-class uddiObjectClass：301＝

{#企业实体类别键值标识引用-集合构成类别包

name＝euBusinessEntityCategoryKR

subclass-of euKeyedReference

must-contain

euBusinessEntityCategoryKRKeyValue

may-contain

euBusinessEntityCategoryKRTModel，

euBusinessEntityCategoryKRKeyName

}；

set object-class uddiObjectClass：302＝

{#企业实体标识键值标识引用-集合构成标识包

name＝euBusinessEntityidentifierKR

subclass-of euKeyedReference

must-contain

euBusinessEntityldentifierKRKeyValue

may-contain

euBusinessEntityldentifierKRTModel，

euBusinessEntityldentifierKRKeyName

}；

set object-class uddiObjectClass：303＝

{#服务类别键值标识引用-集合构成类别包

name＝euBusinessServiceCategoryKR

subclass-of euKevedReference

must-contain

euBusinessServiceCategoryKRKeyValue

may-contain

euBusinessServiceCategoryKRTModel，

euBusinessServiceCategoryKRKeyName

}；

set object-class uddiObjectClass：304＝

{#tmodel类别键值标识引用-集合构成类别包

name＝euTModelCategoryKR

subclass-of euKeyedReference

must-contain

euTModelCategoryKRKeyValue

may-contain

euTModelCategoryKRTModel，

euTModelCategoryKRKeyName

}；

set object-class uddiObjectClass：305＝

{#tmodel标识键值标识引用-集合构成标识包

name＝euTModelidentifierKR

subclass-of euKeyedReference

must-contain

euTModelldentifierKRKeyValue

may-contain

euTModelldentifierKRTModel，

euTModel IdentifierKRKeyName

}；

set object-class uddiObjectClass：306＝

{#发布者声明键值标识引用-用作辅助类以提供关系

name＝euPublisherAssertionKR

subclass-of euKevedReference

kind＝auxiliary

must-contain

euPublisherAssertionKRKevValue

may-contain

euPublisherAssertionKRTModel，

euPublisherAssertionKRKevName

}；

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

#名字和描述类型

set object-class uddiObjectClass：331＝

{#企业实体的名字

name＝euBusinessEntityName

subclass-of euName

must-contain

euBusinessEntityNameValue，

euBusinessEntitvNameValuelC

#从euName继承euNameKey和euLanguage

}；

set object-class uddiObjectClass：332＝

{#企业服务的名字

name＝euBusinessServiceName

subclass-of euName

must-contain

euBusinessServiceNameValue，

euBusinessServiceNameValuelC

#从euName继承euNameKey和euLanguage

}；

set object-class uddiObjectClass：341＝

{#企业实体的描述

name＝euBusinessEntityDescription

subclass-of euDescription

may-contain

euBusinessEntityDescriptionValue，

euBusinessEntityDescriptionValuelC

#从euDescription继承euDescriptionKey和euLanguage

}；

set object-class uddiObjectClass：342＝

{#企业服务的描述

name＝euBusinessServiceDescription

subclass-of euDescription

may-contain

eu BusinessServiceDescri ptionValue，

euBusinessServiceDescriptionValuelC

#从euDescription继承euDescriptionKey和euLanguage

}；

set object-class uddiObjectClass：343＝

{#tmodel的描述

name＝euTModelDescription

subclass-of euDescription

may-contain

euTModel DescriptionValue，

euTModelDescriptionValuelC

#从euDescription继承euDescriptionKey和euLanguage

}；

set object-class uddiObjectClass：344＝

{#tmodel实例信息对象的描述

name＝euTModelInstancelnfoDeseription

subclass-of euDescription

may-contain

euTModellnstancelnfoDescriptionValue，

euTModellnstancelnfoDescriptionValuelC

#从euDescription继承euDescriptionKey和euLanguage

}；

set object-class uddiObjectClass：345＝

{

#tmodel实例细节对象的描述

name＝euTModeIInstanceDetaiisDescription

subclass-of euDescription

may-contain

euTModellnstanceDetailsDescriptionValue，

euTModeIInstanceDetaiIsDescriptionValueIC

#从euDescription继承euDescriptionKey和euLanguage

}；

set object-class uddiObjectClass：346＝

{#概述文档对象的描述

name＝euOverviewDocDescription

subclass-of euDescription

may-contain

eu OverviewDocDescriptionValue，

euOverviewDocDescriptionValuelC

#从euDescription继承euDescriptionKey和euLanguage

}；

set object-class uddiObjectClass：347＝

{#contact的描述

name＝euContactDescription.

subclass-of euDescription

may-contain

euContactDescriptionValue，

euContactDescriptionValuelC

#从euDescription继承euDescriptionKey和euLanguage

}；

set object-class uddiObjectClass：348＝

{#绑定模板的描述

name＝euBindingTemplateDescription

subclass-of euDescription

may-contain

euBindingTemplateDescriptionValue，

euBindingTemplateDescriptionValuelC

#从euDescription继承euDescriptionKey和euLanguage

}；

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

#主要对象

set object-class uddiObjectClass：400＝

{#数据库-可以用于将用户分成组

name＝euRepository

subclass-of top

must-contain

euRepositoryName

}；

set object-class uddiObjectClass：401＝

{#用户帐户-其中隐藏我们有关用户的知识

name＝euUserAccount

subclass-of top

must-contain

euUserKey，

euUserName，

euCredentials

may-contain

euAuthorizedName，

euHidden

#注意：这个用户发布的所有企业实体和TModel均被发现为这个对象的子对象

}；

set object-class uddiObjectClass：402＝

{#企业对象-提供服务的实体的细节

name＝euBusinessEntity

subclass-of top

must-contain

euBusinessEntityKey

may-contain

euParentUserKey，

euAuthorizedName，

euOperator

#注意：在这个对象的子对象中保存企业实体的许多属性，

#尤其是可能不止一次出现的属性

}；

set object-class uddiObjectClass：403＝

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

name＝euBusinessService

subclass-of top

must-contain

euBusinessServiceKey

may-contain

euParentBusinessKey

#注意：这个服务的所有绑定模板会被发现为这个服务的子服务

}；

set object-class uddiObjectClass：404＝

{#绑定模板-如何访问特定企业的细节

name＝euBindingTemplate

subclass-of top

must-contain

euBindingTemplateKey

may-contain

euParentServiceKey，

euHostingRedirector，

euAccessPoint，

euAccessPointType

#注意：应当具有驻留重定向器或接入点之一

}；

set object-class uddiObjectClass：405＝

{#tmodel-对概念的引用。可以是分类模式，可以只是对标准的引用

name＝euTModel

subclass-of top

must-contain

euTModelKey，

euTModeiName

may-contain

euAuthorizedName，

euOperator，

euOverviewURL，

euParentUserKey，

euHidden

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

}；

set object-class uddiObjectClass：406＝

{#发布者声明-作出有关两个企业之间的关系的声明

name＝euPublisherAssertion

subclass-of top

must-contain

euPublisherAssertionKey，

euFromBusinessKey，

euFromUserKey，

euToBusinessKey，

euToUserKey，

euPublisherAssertionStatus

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

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

}；

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

#次要对象-多数为主要对象的子对象，保存重复数据

set object-class uddiObjectClass：501＝

{#discoveryURL-在企业实体下面发现

name＝euDiseoveryURL

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＝

{#address line-在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＝

{#tmodel实例信息-在绑定模板下面发现

name＝euTModellnstancelnfo

subclass-of top

must-contain

eulnstanceTModelKey

may-contain

eulnstanceParms，

euOverviewU RL

}；

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

#名字绑定

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到″顶端″-用于标准TModels(非由用户发布)

name＝euTModel-euRepository

euTModel allowable-parent euRepository

named-by euTModelKey

}；

schema set name-binding uddiBinding：105＝

{#绑定到组织最高层子对象

name＝euRepository-organization

euRepository allowable-parent organization

named-by euRepositoryName

}；

schema set name-binding uddiBinding：106＝

{#绑定发布者声明到数据库以允许可选配置

name＝euPublisherAssertion-euRepository

euPublisherAssertion allowable-parent euRepository

named-by euPublisherAssertionKey

}；

schema set name-binding uddiBinding：107＝

{#绑定数据库层-允许多层数据库结构

name＝euRepository-euRepository

euRepository allowable-parenteuRepository

named-by euRepositoryName

}；

schema set name-binding uddiBinding：201＝

{#绑定企业实体到用户帐户-第二层

name＝euBusinessEntity-euUserAccount

euBusinessEntity allowable-parent euUserAccount

named-by euBusinessEntityKey

}；

schema set name-binding uddibinding：202＝

{#绑定tmodel到用户帐户-第二层

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＝

{#绑定联系到企业-第三层

name＝euContact-euBusinessEntity

euContact allowable-parent euBusinessEntity

named-by euContactKey

}；

schema set name-binding uddiBinding：303＝

{#绑定企业下面的discoveryURL

name＝euDiscoveryURL-euBusinessEntity

euDiscoveryURL allowable-parenteuBusinessEntity

named-by euDiscoveryURLKey

}；

schema set name-binding uddiBinding：304＝

{#企业下面的名字

name＝euBusinessEntityName-euBusinessEntity

euBusinessEntityName allowable-parent euBusinessEntity

named-by euNameKey

}；

schema set name-binding uddiBinding：305＝

{#企业下面的描述

name＝euBusinessEntityDescription-euBusinessEntity

euBusinessEntityDescription allowable-parent euBusinessEntity

named-by euDescriptionKey

}；

schema set name-binding uddiBinding：306＝

{#企业下面的发布者声明

name＝euPublisherAssertion-euBusinessEntity

euPublisherAssertion allowable-parent euBusinessEntity

named-by euPublisherAssertionKey

}；

schema set name-binding uddiBinding：307＝

{#企业实体下面的标识

name＝euBusinessEntityidentifierKR-euBusinessEntity

euBusinessEntityldentifierKR allowable-parenteuBusinessEntity

named-by euKeyedReferenceKey

}；

schema set name-binding uddiBinding：308＝

{#企业实体下面的类别

name＝euBusinessEntityCategoryKR-euBusinessEntity

euBusinessEntityCategoryKR allowable-parenteuBusinessEntity

named-by euKeyedReferenceKey

}；

schema set name-binding uddiBinding：310＝

{#TModel下面的描述

name＝euTModelDescription-euTModel

euTModel Description allowable-parent euTModel

named-by euDescriptionKey

}；

schema set name-binding uddiBinding：311＝

{#TModel下面的概述URL的描述

name＝euOverviewDocDescription-euTModel

euOverviewDocDeseription allowable-parent euTModel

named-by euDescriptionKey

}；

schema set name-binding uddiBinding：312＝

{#tmodel下面的标识

name＝euTModelIdentifierKR-euTModel

euTModelIdentifierKR allowable-parent euTModel

named-by euKeyedReferenceKey

}；

schema set name-binding uddiBinding：313＝

{#TModel下面的类别

name＝euTModelCategoryKR-euTModel

euTModelCategoryKR allowable-parent euTModel

named-by euKeyedReferenceKey

}；

schema set name-binding uddiBinding：401＝

{#联系下面的地址

name＝euAddress-euContact

euAddress allowable-parent euContact

named-by euAddressKey

}；

schema set name-binding uddiBinding：402＝

{#联系下面的电话号

name＝euPhone-euContact

euPhone allowable-parent euContact

named-by euPhoneKey

}；

schema set name-binding uddiBinding：403＝

{#联系下面的email

name＝euEmail-euContact

euEmail allowable-parent euContact

named-by euEmailKey

}；

schema set name-binding uddiBinding：404＝

{#联系下面的描述

name＝euContactDescription-euContact

euContactDescription allowable-parent euContact

named-by euDescriptionKey

}；

schema set name-binding uddiBinding：409＝

{#服务下面的名字

name＝euBusinessServiceName-euBusinessService

euBusinessServiceName allowable-parent euBusinessService

named-by euNameKey

}；

schema set name-binding uddiBinding：410＝

{#服务下面的描述

name＝euBusinessServiceDescription-euBusinessService

euBusinessServiceDescription allowable-parenteuBusinessService

named-by euDescriptionKey

}；

schema set name-binding uddiBinding：411＝

{#服务下面的类别

name＝euBusinessServiceCategoryKR-euBusinessService

euBusinessServiceCategoryKR allowable-parenteuBusinessService

named-by euKeyedReferenceKey

}；

schema set name-binding uddiBinding：412＝

{#绑定服务下面的模板

name＝euBindingTemplate-euBusinessService

euBindingTemplate allowable-parent euBusinessService

named-by euBindingTemplateKey

}；

schema set name-binding uddiBinding：501＝

{#地址下面的行

name＝euAddressLine-euAddress

euAddressLine allowable-parent euAddress

named-by euAddressLineKey

}；

schema set name-binding uddiBinding：502＝

{#绑定模板下面的描述

name＝euBindingTempiateDescription-euBindingTemplate

euBindingTemplateDescription allowable-parenteuBindingTemplate

named-by euDescriptionKey

}；

schema set name-binding uddiBinding：510＝

{#绑定模板下面的tmodel实例信息

name＝euTModellnstancelnfo-euBindingTemplate

euTModellnstancelnfo allowable-parent euBindingTemplate

named-by eulnstanceTModelkey

}；

schema set name-binding uddiBinding：601＝

{#tmodel实例信息下面的描述

name＝euTModellnstancelnfoDescription-euTModellnstancelnfo

euTModellnstancelnfoDescription allowable-parenteuTModellnstancelnfo

named-by euDescriptionKey

}；

schema set name-binding uddiBinding：602＝

{#tmodel实例信息下面的实例细节描述

name ＝euTmodellnstanceDetailsDescription-euTModellnstancelnfo

euTmodel lnstanceDetailsDescription allowable-parenteuTModel Instancel nfo

named-by euDescriptionKey

}；

schema set name-binding uddiBinding：603＝

{#tmodel实例信息下面的概述文档描述

name＝euOverviewDocDescription-euTModellnstancelnfo

euOverviewDocDescription anowable-pa renteuTModelinstanceinfo

named-by euDescriptionKey

}；

由于能够在不偏离本发明的必要特征的实质的前提下以各种形式实施本发明，应当理解，上述实施例不是为了限制本发明(除非专门指出)，而是应当在所附权利要求限定的公开内容的实质和范围内进行广义的解释。各种修改和等同方案均应被包含在本公开和所附权利要求的实质和范围内。

Claims

1.一种用于具有复杂UDDI对象的WEB服务系统的方法，所述复杂UDDI对象具有至少一个非复合数据结构和至少一个复合数据结构，每个复合数据结构具有至少一个值，每个值具有多个字段，该方法包括：

在目录父对象中提供表示每个非复合数据结构的属性；和

为每个至少一个值提供具有表示复合数据结构的每个字段的属性的目录子对象。

2.如权利要求1所述的方法，还包括针对其中字段为复合的每个至少一个值重复进行提供。

3.如权利要求1所述的方法，其中复杂UDDI对象是企业实体，企业服务，绑定模板和TModel中的至少一个。

4.一种使WEB服务结构中的层次结构扁平化的方法，该方法包括：

确定WEB服务结构中的层次结构或关系的任何部分是否具有对象之间的′一对一′关系；和

通过将属性的内容移动到层次结构的至少一个子部分中，清除层次结构中被确定为具有一对一关系的该部分。

5.一种包含用于执行WEB服务方法的计算机可执行代码的计算机记录介质，所述WEB服务方法用于具有复杂UDDI对象的WEB服务结构中，所述复杂UDDI对象具有至少一个非复合数据结构和至少一个复合数据结构，每个复合数据结构具有至少一个值，每个值具有多个字段，所述计算机可执行代码包括：

用于在目录父对象中提供表示每个非复合数据结构的属性的代码；和

用于为每个至少一个值提供具有表示复合数据结构的每个字段的属性的目录子对象的代码。

6.如权利要求5所述的计算机记录介质，还包括用于针对其中字段为复合的每个至少一个值重复进行提供的代码。

7.如权利要求5所述的计算机记录介质，其中复杂UDDI对象是企业实体，企业服务，绑定模板和TModel中的至少一个。

8.一种包含计算机可执行代码的计算机记录介质，所述计算机可执行代码用于使WEB服务结构中的层次结构扁平化，包括：

用于确定WEB服务结构中的层次结构或关系的任何部分是否具有对象之间的′一对一′关系的代码；和

用于通过将属性的内容移动到层次结构的至少一个子部分中，清除层次结构中被确定为具有一对一关系的该部分的代码。