用于在万维网服务架构中对服务进行排名的方法和系统

摘要

提供一种用于在万维网服务架构中对服务进行排名的方法和万维网服务架构。该万维网服务架构具有服务分层结构(401、406、408、410)，其中该服务分层结构包括根发起服务请求者(401)，并且该分层结构中第一层的服务调用低层的服务。发起服务请求者指示关于一个或多个服务的偏好，并且排名机(405)提供基于该偏好的选择算法。发起服务请求者调用分层结构的一层或多层的服务。在分层结构的每一层，服务使用目录(411)来查找可能低层服务的集合，并且排名机对该可能低层服务的集合施加选择算法。在一个实施例中，将可能低层服务的集合从目录提交到排名机，并且排名机将首选序列返回给该目录。

说明书

技术领域

本发明涉及一种用于在万维网(web)服务架构中对服务进行排名(ranking)的方法和系统。具体地说，本发明涉及一种具有服务提供者分层结构的万维网服务架构，其中由顶层调用者指定排名。

背景技术

在文档“Wed Services Conceptual Architecture(WSCA 1.0)”(IBM软件组，2001年5月)中描述了万维网服务。万维网服务提供程序对程序的通信模型，其建立在现有和新兴标准如HTTP(超文本传输协议)、可扩展标记语言(XML)、简单对象访问协议(SOAP)、万维网服务描述语言(WSDL)、以及统一描述、发现和集成(UDDI)上。

万维网服务通过接口来描述，所述接口描述一组通过标准化的XML消息传递而可网络访问(network-accessible)的功能。万维网服务使用称作服务描述的标准、正式的XML表示法来描述。服务描述覆盖与服务交互所必需的所有细节，包括消息格式、传输协议和位置。该接口隐藏了服务的实现细节，从而允许独立于在其上实现该服务的硬件或软件平台并且还独立于编写该服务所采用的编程语言而使用该服务。它还独立于调用者的硬件和软件环境。这允许基于万维网服务的应用成为松散耦合、面向组件的交叉技术实现，该实现可跨越网络来发布、定位和调用。

万维网服务在网络中实现。该网络可以是可公共访问的网络如因特网、内联网或者任何其他形式的网络。因特网可用的万维网服务使用常用的网络协议。这些协议可以是HTTP或其他因特网协议如SMTP或FTP。其他网络(例如，内联网)可使用可靠的消息传递调用基础结构如MQSeries、COBRA等。

所述方法和系统涉及对UDDI/WSDL协议和XML/SOAP语法的扩展，以提供当前在万维网服务架构内得不到的功能。

参考下面可通过www.uddi.org得到的文献：

UDDI 2.0 Data Structure Reference；

UDDI 2.0 API Specification；

UDDI 2.0 Operators Specification；以及

Wed Services Description Language(WSDL)1.1。

万维网服务中的UDDI的目标是基于目录或注册中心(registry)查询提供对功能的开放访问。这些服务由WSDL部分描述，并由XML/SOAP功能调用。调用者与服务的绑定是动态的而不是固定的。由于目录是可免费获得的并且对于如何进行查询或选择未施加任何约束，因此它是开放的。UDDI极好地满足这一目标。然而，它的不足之处在于诸如服务质量的概念。

所述方法和系统提供了可由此将服务质量问题和其他选择影响因素引入到UDDI/WSDL领域中的手段。

在万维网服务中，使用目录或注册中心来以组件化的方式组合软件。UDDI的思想是将具有WSDL格式的请求发送到目录或注册中心服务器以选择服务。该服务选择可根据特定一般适用标准如提供它的公司和它执行的功能来指定。该选择信息是非常一般性的；它对于所有用户都相同，并且不特定于对所提到的服务的请求的发起者。

所述方法和系统提供了可由此引入特定于发起者的标准以对查询施加影响的手段。不同于公知的现有技术万维网服务，服务的选择受到服务选择的发起者或请求者的影响。

下面是一个实际例子。用户的软件将要买书。用户在‘售书者’类别下的目录中进行查询，并且取回提供该服务的公司列表。然而，用户已经与比方说两个供应者协商了优惠率，并因此想要将购买请求首先发送给这两个供应者中的任一个，而把其他供应者作为第三选择。

由于搜索将信息直接返回给用户，并且用户控制接下来发生什么，因此用户可通过过滤从搜索返回的公司列表来完成此操作。

如果作为由其他人提供的服务的功能的一部分来执行购书请求，则有所区别。例如，用户可能正在构建星际旅行书籍的图书库。用户使用‘构建图书库’选择，并取回合适的销售者的列表。用户将他的“向我提供星际旅行图书库(Get-me-a-library-for-StarTrek)”请求发给将做这项工作的供应者。然而，由于购书功能现在由其他人处理，因此用户现在不再处于使用其喜爱的售书者列表的地位。实际上，他们使用他们自己而非该用户的首选供应者。

所描述的本发明的一个结果提供了获得向用户的首选销售者而非中间人购买的书籍(或其他项目)的方法。

用户：图书库构建者：销售者1  用户首选销售者2

现有技术：构建图书库--->购买书籍1--------->购买

本发明：构建图书库--->购买书籍1------------------->购买

所述方法和系统涉及如何根据发起者的偏好(preference)来偏袒(bias)WSDL/UDDI请求。什么条件影响用户的偏好不作讨论并且其取决于用户。可影响用户偏好的条件的例子包括成本、效率、速度和可靠性这些标准。

发明内容

根据本发明的第一方面，提供了一种用于在具有服务分层结构的万维网服务架构中对服务进行排名的方法，其中该服务分层结构包括根(root)发起服务请求者，该分层结构中第一层的服务调用低层的服务，该方法包括：发起服务请求者指示关于一个或多个服务的偏好，并且排名机具有基于该偏好的选择算法；发起服务请求者调用分层结构的一层或多层的服务；在该分层结构的每一层，服务使用目录来查找可能低层服务的集合；以及排名机对可能低层服务的集合施加选择算法。

低层服务可以是服务请求者或服务提供者。

在一个实施例中，可以将可能低层服务的集合从目录提交(refer)给排名机，并且排名机可将首选序列返回给该目录。提交到排名机的步骤对使用该目录的服务可以是不可见的。

在另一实施例中，使用该目录的服务可将可能低层服务的集合发送到排名机，并且排名机可将首选序列返回给该服务。

可以将单个结果或结果序列返回给使用该目录的服务。

优选地，分层结构中的低层服务调用对高层服务是不可见的。

发起服务请求者的偏好可以按照该发起服务请求者希望使用服务的次序对服务进行排名，可排除服务以使其不被使用和/或可提供其他选择影响标准。

发起服务请求者的偏好可基于包括例如成本、效率、速度和可靠性的服务质量标准。

在存在发起服务请求者的偏好的情形下，该偏好可优先于使用目录的服务的选择。如果该首选服务不可用，则可通过参考发起服务请求者的偏好来获得随后的服务。

在没有存储发起服务请求者的偏好的情形下，使用目录的服务可进行选择。

根据本发明的第二方面，提供了一种万维网服务架构，包括：根发起服务请求者；服务分层结构，其中第一层的服务调用低层的服务；目录，用于在分层结构中查找服务；排名机，具有用于根据关于一个或多个服务的发起服务请求者的偏好施加服务选择算法的装置；其中，在分层结构的每一层，目录提供可能服务的集合，并且排名机施加选择算法以提供首选服务序列。

低层服务可以是服务请求者或服务提供者。

排名机优选地通过端口连接到目录，并且通过目录将可能服务的集合提交给排名机，并且由排名机将首选服务序列返回给目录。

第一层的服务可通过UDDI目录查找低层服务。排名机可具有UDDI目录上的端口，并且可处理将TModel包(bag)转变成所选Tmodel集合的流程。

每个UDDI操作可被提交给排名机，并可作为遵循服务请求者偏好的序列而被返回。

底层UDDI应用代码可执行该提交，并且可将排名机的位置附加到随后的XML流中。

根据本发明的第三方面，提供了一种存储在计算机可读存储介质上的计算机程序产品，其用于具有服务分层结构的万维网服务架构，其中该服务分层结构包括根发起服务请求者，第一层的服务调用低层的服务，该计算机程序产品包括用于执行以下步骤的计算机可读程序代码装置：发起服务请求者指示关于一个或多个服务的偏好，并且排名机具有基于该偏好的选择算法；发起服务请求者调用分层结构的一层或多层的服务；在该分层结构的每一层，服务使用目录来查找可能低层服务的集合；以及排名机对可能低层服务的集合施加选择算法。

附图说明

现在将参照附图仅作为示例来描述本发明的实施例，其中：

图1是万维网服务模型的示意图；

图2是万维网服务栈的示意图；

图3是UDDI数据结构的方框图；

图4A是根据本发明的万维网服务分层结构的示意方框图；

图4B是根据本发明的万维网服务架构的示意方框图；

图5A是从现有技术得知的服务选择的流线图；

图5B是根据本发明的服务选择的第一实施例的流线图；以及

图5C是根据本发明的服务选择的第二实施例的流线图。

具体实施方式

在本描述中，使用了术语“万维网服务”。这不应当被解释为表示必须通过万维网(即从浏览器)调用万维网服务。万维网服务可采用任何形式的网络包括因特网、内联网、LAN、WAN等来实现。如前面所定义的那样，万维网服务提供程序对程序的通信模型，并且通过描述万维网服务功能的接口来描述。

图1示出万维网服务模型100，其示出服务提供者101、服务注册中心102和服务请求者103这三个角色。交互包括发布104、查找105和耦合106操作。耦合操作106是松散耦合的环境中实体之间的访问流(access flow)。这些角色和操作一起作用于作为万维网服务软件模块107及其描述108的万维网服务制品(artefact)。

在典型的场景中，服务提供者101驻留(host)作为万维网服务实现的可网络访问的软件模块107。服务提供者101定义万维网服务107的服务描述108，并将其发布到服务注册中心102。服务请求者103也能直接从服务提供者101获得服务描述108或者其一部分，作为拉(pull)操作而非推(push)操作。服务请求者103使用查找操作105来从服务注册中心102检索服务描述108，并使用服务描述108来与服务提供者101耦合106，并且调用万维网服务实现107或者与之交互。服务提供者101和服务请求者103是角色，并且服务可表现这两者的特征。

服务提供者101是驻留对至少服务前端的访问的平台。服务请求者103是查找和调用或启动与服务的交互的应用程序。服务请求者角色可由人驱动的浏览器或没有用户接口的程序例如另一万维网服务扮演。服务注册中心102是可搜索的服务描述108的注册中心，服务提供者101在其中发布它们的服务描述108。服务请求者103查找服务并且从服务描述108中获得耦合信息以建立对服务的通信和执行。

为了可访问，需要发布104服务描述108，使得服务请求者103可查找它。在查找操作105中，服务请求者103直接检索服务描述108，或者在服务注册中心102中查询使用服务发现过程所需的服务类型。在耦合操作106中，服务请求者103使用服务描述108中的耦合细节来在运行时调用或启动与服务的交互，以便联系和调用服务。

服务描述108包含接口细节以实现该服务。这包括其数据类型、操作、耦合信息和网络位置。它还可包括类别化(categorisation)以帮助由服务请求者103进行的发现和利用。

参照图2，为了以可互操作的方式执行发布、查找和耦合这三个操作，必须有在每层都包括标准的万维网服务栈200。

由于万维网服务必须可网络访问以便由服务请求者调用，因此万维网服务栈200的基础是网络层201。应用于栈200的网络层201的标准技术包括HTTP、FTP、电子邮件、MQSeries、IIOP等。

下一层是基于XML的消息传递层202，其表示使用XML作为消息传递协议的基础。可使用SOAP作为对XML消息传递协议的增强。

下一层是服务描述层203，它是描述文档的集合。该描述被分组成三种类型的事物(thing)，即位置、活动和接口。WSDL是基于XML的服务描述的标准。WSDL定义服务交互的接口和机制。WSDL文档可由其他服务描述文档补充，以描述万维网服务的较高层方面，例如，除了WSDL文档之外，还使用UDDI数据结构来描述商业上下文。

提供或使用任何万维网服务需要网络层201、基于XML的消息传递层202和服务描述层203的前三层。

图2示出的栈200的下两层是服务发布和服务发现层204、205，其可采用多种解决方案来实现。使服务请求者可获得WSDL文档的任何动作是服务发布。公共UDDI注册中心保存服务发布的副本。

如果万维网服务尚未被发布，则它不能被发现，因此服务发现层205依赖于服务发布层204。各种发现机制对应于发布机制。允许服务请求者在运行时获得对服务描述的访问并使其可用于应用程序的任何机制都有资格作为服务发现。

图2的最顶层206是服务流层206，其描述如何执行服务对服务的通信、协作和流动。

完整的万维网服务描述建立在服务的基本WSDL描述上。完整的万维网服务描述表达以下内容：驻留服务的商业机构(business)；商业类型；与服务相关联的产品；商业或万维网服务相关联的类别；将影响请求者选择或调用服务的多个方面；可被提供使得更易于查找服务的关键字等等。

UDDI提供用于保存万维网服务描述的机制。虽然UDDI经常被认为是目录机制，但是它也采用XML定义用于表示服务描述信息的数据结构标准。图3示出具有四个基本数据结构的UDDI条目300。

UDDI条目以商业实体301开始。商业实体301对关于商业机构的信息进行建模。商业实体301包含商业服务302的集合，每个商业服务302用于该商业机构希望发布的每个万维网服务。每个商业服务302包含关于商业实体的万维网服务的技术和描述性信息。商业服务302包含绑定模板303的集合。

绑定模板303描述访问信息如终点地址，并且描述商业服务302如何使用各种技术规范。技术规范被建模为tModel 304。tModel 304可对很多不同的概念例如：服务类型、平台技术如HTTP或分类法进行建模。商业实体301、商业服务302和绑定模板303使用已定义类型的tModel来实现。与商业服务302相关联的绑定模板303的集合表示由商业服务302使用的技术的指纹(fingerprint)。

tModel 304定义调用接口和结果。它在高层采用XML而在不会被用户看到的低层通过API来呈现。tModel 304具有称作键(key)的唯一标识符。UDDI支持通过指定相同的键而在多处使用给定tModel 304，并随后保证：就外部而言，这两处的行为完全相同，而没有任何附加的特定于平台的返回代码。

所述方法和系统包括关于对请求发起者的所有UDDI操作的基准(reference)。一旦目录或注册中心处理了该请求，就将结果提交给该基准以进行过滤。

现在参照图4A，示出了万维网服务分层结构400。树分层结构400的根节点是希望调用万维网服务的服务请求者401。

树分层结构400具有多个服务层402、403，其表示可由服务请求者401(直接或间接)调用以便查找服务请求者401希望调用的最终万维网服务的中间服务。最终万维网服务404是树分层结构400上的叶子节点。层402可以是由服务请求者401进行的服务选择，而层403和404可以是对服务请求者401不可见的隐藏子服务的选择。

现在参照图4B，仅示出了层402、403、404的每一层上的选定服务406、408、410。提供了目录411，其用来查找形式为服务或服务提供者的可能结果的组或包(bag)。

提供了排名机405，其存储服务请求者401的服务选择偏好的细节。这是以在任何相关时候提供的选项之间的选择算法的形式提供给排名机405的。服务请求者401向排名机405通知其对任何服务提供者的偏好，并且保存对服务提供者偏好进行排名的选择算法。

在第一实施例中，排名机405在目录411的端口412上监听。当目录411执行查询并且产生结果包时，排名机405正在端口412上监听，并且该结果包被发送407到排名机405。排名机405向该结果包施加其选择算法，并且以服务请求者401的首选次序将结果序列返回409到目录411。目录411以排名机405提供的结果序列回答该查询。

在目录中查询服务的所有中间服务提供者402、403将查询提交给排名机405，其中排名机405根据所指示的服务请求者401的偏好对搜索结果进行过滤。如果存在存储在排名机405中的偏好，则排名机405根据该偏好进行选择，并且当调用下一层的服务提供者时，中间服务提供者402、403将遵循该偏好。

在图4A和4B的所示例子中，服务请求者401希望使用涉及使用低层服务的第一层402的中间服务提供者的服务。然而，使用任何低层服务的事实不被泄露给服务请求者401。服务请求者401使用目录411执行搜索以查找第一层402的服务提供者，并获得可能的服务提供者402的序列。可能的服务提供者402的序列已被排名机405过滤，以去除明显的非竞争者，或者强加特定选择(即，如果在包中只有一个结果)。如果在包中存在多于一个结果，则服务请求者401选择第一层402的服务提供者406之一。

由目录411提供的每个查询响应产生被排名机405过滤的潜在候选者包。目录411中的软件进行向排名机405的提交。如同不存在排名机405一样，向请求目录411中的查询的实体返回结果列表。请求查询的实体具有对由目录411返回给它的结果的自由选择权，但是所返回的结果已经受到排名机405限制。

服务请求者401只与第一层402的服务提供者406进行通信。然而，为了执行其工作，服务提供者406使用第二层403的服务提供者408，服务提供者408又使用最终服务410。服务请求者401不知道第二层的服务提供者408或者最终服务410。类似地，第一层的服务提供者406不知道由第二层的服务提供者408使用的最终服务410。

第一层402的服务提供者406执行目录411的查询，以查找第二层403的服务提供者408。类似地，第二层403的服务提供者408执行目录411的查询以查找最终服务410。在每个查询中，根据发起服务请求者401的偏好，排名机405对由目录411查找到的结果包进行排名。排名机405在其选择算法中使用的偏好在分层结构中是全局的并且与层无关。

在第二实施例中，目录将查询请求的结果返回给可以是发起服务请求者或中间服务提供者的请求者，并且请求者将结果包发送到排名机以进行排名。排名机将结果序列返回给请求者。

在这两个实施例中，服务请求者的偏好都可与服务质量问题如成本、效率、速度和可靠性相关，或者都可与影响偏好的任何其他选择相关。偏好可以按照服务请求者希望使用服务的次序对服务进行排名，或者可以特定地排除服务以使其不被使用，或者可以提供任何其他偏好指示。

对于为什么记录偏好，服务请求者不需要任何理由，并且偏好不需要由中间服务提供者可见或者理解。原始服务请求者将对子服务选择的控制从供应者处移开，或者至少影响对子服务选择的控制。

例子1

下面是由称作用户的服务请求者调用万维网服务的例子。图5A示出现有技术UDDI查询请求将如何工作。UDDI目录返回包作为其结果，这里以{集合}表示。

用户501想要构建图书库，因此他询问UDDI目录502，以便为他查找执行此工作的服务提供者503。用户501将请求511发送到用于UDDI查询的目录502，以查找图书库构建者。在此情况中，仅存在一个该类别的服务提供者503，从而目录502返回512{图书库构建者1}的集合的结果。

然后，用户501将“构建图书库”的请求513发送到服务器图书库构建者1504。然后，图书库构建者1504在UDDI目录502中查询514、515书籍供应者505的列表。目录502返回516{销售者1、用户首选销售者2}的集合。然后，图书库构建者1504挑选517要使用以从其购书的第一供应者，其中第一供应者是销售者1506或者被他认为是最适合的供应者。这导致从有利于图书库构建者1的地方而非该用户的首选销售者购买书籍，其中，在此情况中，用户的首选销售者是用户首选销售者2507。

图5B示出与图5A相同的UDDI查询，但是其根据本发明的第一实施例。所述方法和系统要求应该将每个UDDI请求提交到可以按照根据用户偏好的次序对所返回的包进行排名的地方。对于在该排名中使用什么标准是无关紧要的，只要进行排名即可。

因此，作为<序列>返回{包}，其中首选项目位于列表的前部。该序列可包含包的所有成员、子集或者甚至是完全不同的某些东西。执行该提交的是底层UDDI查询代码(换句话说，底层UDDI API)。调用者不需要额外的代码步骤。

图5B具有排名器508的附加组件，其保存反映用户501指示的对书籍供应者509的偏好的选择算法。

用户请求521 UDDI目录502查找图书库构建者。目录502查找到集合{图书库构建者1}。然而，这不被暴露给用户501，因为服务提供者的底层知道没有提交的局部(local)请求必须被排名，并且这通过配置选项来完成，并因此对用户不可见。因此，来自UDDI目录502的返回流随后被提交522到局部排名器508以进行分析。由于只有一个选择，该选择是可接受的<图书库构建者1>，因此结果不变，并因此被初始发送523回UDDI目录502，UDDI目录502将该结果发送524回用户501。

然后，用户501挑选第一(并且在本例中是唯一的)供应者504，并在其上调用构建图书库操作525。底层知道这是对服务的XML/SOAP请求，并因此将所需排名器508的位置附加到XML流上。

然后，供应者即图书库构建者504请求526 UDDI目录502查找售书者504的列表，并在该流上附加相关排名器508的位置。该目录查询527返回所保存的售书者的集合{销售者1，用户首选销售者2}。然后，底层像以前一样将该集合提交528给排名器508。在此情况中，排名器508想要强制使用用户的首选书籍供应商509，并因此将UDDI结果改变成序列<用户首选销售者2>，然后将该结果发送529回UDDI目录502，UDDI目录502将该结果发送530回图书库构建者504作为其查询527的结果。因此，现在从用户首选销售者2507而非销售者1506订购321、322书籍。

图5C示出与图5A和5B相同的UDDI查询，但是其根据本发明的第二实施例。如同图5B一样，所述方法和系统要求应该将每个UDDI请求以根据用户偏好的次序提交到可对所返回的包进行排名的地方。对于在该排名中使用什么标准是无关紧要的，只要进行排名即可。

同样地，作为<序列>返回{包}，其中首选项目位于该列表的前部。在第二实施例中，对UDDI目录502的查询的请求者接收结果的{包}，并将这个包提交给排名器508以进行排名，然后，请求者根据用户501的偏好从排名器508接收<序列>。

实现

在第一实施例中，排名机在UDDI/排名器端口上监听，并且处理将tModel包转变成所选tModel包的前述流程。

根据UDDI API，通过添加排名机的URL：端口来扩展10个find_xx动词。

例如，

<find_tModel[maxRows＝″n″]generic＝″2.0″xmlns＝″urn：uddi-org：api_v2″>

[<findQualifiers/>][<name/.>][<identifierBag/>][<categoryBag/>]

</find_tModel>]

将变成：

<find_tModel[maxRows＝″n″]generic＝″3.0″xmlns＝″urn：uddi-org：api_v3″>

[<Ranker>ranker_url</Ranker>]

[<findQualifiers/>][<name/>][<identifierBag/>][<categoryBag/>]

</find tModel>]

根据服务的SOAP/XML执行，这将被扩展以包括排名器URL。这必须被传递给随后的UDDI相关调用是UDDI范例的要求。

<wsdl：declarations>

......

......

      <wsdl：ranker>？

            <wsdl：rankerurl[port＝″nn″]>url</wsdl：rankerurl>

      </wsdl：ranker>

......

......

</wsdl：declarations>

这个流由WSDL供应者插入或处理，或者至少该功能潜伏在UDDI服务器(当给A地址：端口传递了查询请求时)或者用于UDDI处理的调用者的DLL中。在任一情况中，UDDI查询过程执行过滤，而无需调用者的干预。

如果接收该排名器地址的服务没有费心传递它以便执行随后的UDDI/XML/SOAP操作，则这将违反协议，从而服务将不根据规则工作。如同该领域中的所有其他标准一样，这将是自律的。

然而，新条目被添加到绑定模板和商业服务tModel中，以示出服务是否遵循这些规则。该元素可被认为是<RankingSupported/>。如果在调用上提供了<RANKER>元素但是不存在<RankingSupported>，则find_xx AP1将不选择tModel。

在API执行方面，本质上，这是在驻留UDDI目录的盒(box)上执行的。进行选择的代码被修改成支持新API和tModel标记。

因此，本描述示出了使用排名机来处理URL请求以及相关联的对UDDI/WSDL协议的扩展如何能够将新的发起者偏好选择功能引入到UDDI范例中。

在一个服务提供者不可用而需要选择另一个的情形中，以下内容适用。通过特定绑定tModel，在接口(参数调用)层指定实际服务本身。如果想要特定服务，则必须使用称作绑定模板的特定tModel(否则对大量不同的XML调用进行编码)。如果使用特定tModel的供应者不理想(太慢、太贵、不工作等)，则出现问题，并且不能更改代码来通过不同接口使用另一供应者。

为了避免重新编码问题，必须以完全相同的接口选择另一供应者：换句话说，使用相同绑定tModel的供应者。这容易地通过UDDI查询来完成。

应当注意，UDDI支持公开(即普遍可用)目录和私有(即特定于调用者)目录。如果整个所请求的服务处于私有目录的范围之内(在相同组织内，并因此使用相同的-或复制的-UDDI服务器)，从而可通过在该私有目录中实际进行的内容来解决偏好问题，那么这是良好的。然而，如果在私有目录的范围之外执行请求，则该方法失效。所述方法和系统克服了这一问题。

还应当注意，UDDI支持PublisherAssertion(发布者断言)的tModel。这旨在将供应者链接到某种较大的实体中。由于PublisherAssertion是公开、静态的并且不保证其将被注意到，因此这不是与所述方法和系统的重叠。

在不脱离本发明的范围的情况下，可以对前文进行改进和修改。