云计算环境的分布式标准注册中心

摘要

提供了用于提供分布式标准注册中心的技术。DSR系统可以包括多个分布式标准注册中心参与者，这些参与者被共同配置为使用共识投票机制为分布式标准注册中心提供控制逻辑，以做出控制决策。DSR系统包括在多个分布式标准注册中心参与者上被维护并存储多个本体模型的分布式本体模型库，以及跨多个分布式标准注册中心参与者被维护的分布式联盟代理注册中心。多个分布式标准注册中心参与者中的第一分布式标准注册中心参与者包括发现处理器和注册中心处理器，发现处理器可操作为接收并处理联盟参与者查询，注册中心处理器可操作为接收并处理注册请求以将联盟代理注册为提供与多个本体模型之一所描述的联盟服务相关的代理服务。

说明书

相关申请的交叉引用

本专利申请要求2018年6月6日提交的标题为“云环境的分布式标准注册方法”美国临时专利申请第62/681，438号的优先权权益，并通过引用将其全部内容结合于此。

技术领域

本公开涉及云计算，并且更具体地，涉及用于促成联盟的云计算环境中联盟的基于云的服务提供商和服务消费者之间的连接的分布式标准注册中心(distributedstandards registry，DSR)。

背景技术

云计算通常是指允许利用互联网技术进行各种软件服务的可扩展交付的一系列过程。目前存在若干云环境，并且其中包含大量有益的服务，诸如软件即服务(Software asa Service，SaaS)和基础设施即服务(Infrastructure as a Service，IaaS)。这些云服务为消费者提供弹性服务，以满足不断变化的需求，而无需消费者自己进行物理重新配置。

然而，根据相应的云和/或云服务，各种组件在本质上可能是异构的和/或同质的。在同一云环境中获得服务可能会受到各种限制，因为各种云环境不是为了互操作而设计的，并且允许消费者无限制地选择针对它们的选择的云服务。当从不同的云环境中寻求服务来为消费者形成完整系统时，这个问题就变得复合了。因此，随着通过各种各样的云可获得的各种云服务的异构性，高效地连接、分析和控制该数据成为一项严峻的挑战。

附图说明

本公开的更详细描述(上文简要概述的)可通过参考各种实施例来获得，其中一些实施例在附图中示出。虽然附图示出了本公开的选定实施例，但是这些附图不应被认为是对其范围的限制，因为本公开可以允许其它同等有效的实施例。

图1示出了根据本公开各种实施例的示例性云联盟，其中可以使用元联盟代理(Meta Federation Broker，MFB)；

图2示出了根据本公开各种实施例可以使用MFB注册和发现的示例性本体；

图3示出了根据本公开各种实施例的MFB的示例性架构；

图4A-图4B示出了根据本公开各种实施例的MFB的示例性实施方式；

图5示出了根据本公开各种实施例的用于MFB的示例性本体模型注册工作流程；

图6示出了根据本公开各种实施例的用于MFB的示例性FCB注册工作流程；

图7示出了根据本公开各种实施例的用于MFB的示例性本体模型和FCB发现工作流程；

图8示出了根据本公开各种实施例的示例性MFB参与工作流程；

图9是根据本文描述的一个实施例的用于将潜在DSR参与者添加到DSR集群的工作流程；

图10是根据本文描述的一个实施例的用于从DSR集群中移除DSR参与者的工作流程；

图11是根据本文描述的一个实施例的用于将联盟代理添加到DSR集群的代理注册中心的工作流程；

图12是根据本文描述的一个实施例的用于从DSR集群的代理注册中心移除联盟代理的工作流程；

图13是根据本文描述的一个实施例的用于向DSR集群注册本体模型的工作流程；

图14是可用于实施本公开各种实施例的通用计算机系统的功能框图；和

图15是可用于实施本公开各种实施例的通用储存系统的功能框图。

在可能的情况下，使用相同的附图标记来指代附图共有的相同元件。然而，在一个实施例中公开的元件可以有益地用于其它实施例而无需专门叙述。

发明内容

本文描述的一个实施例提供了一种用于为联盟计算环境提供分布式标准注册中心(DSR)的系统。该系统包括多个分布式标准注册中心参与者，这些参与者被共同配置为使用共识投票机制为分布式标准注册中心提供控制逻辑以做出控制决策。该系统还包括分布式本体模型库的同步副本，该分布式本体模型库在多个分布式标准注册中心参与者的每一个上被维护并且存储多个本体模型，每个本体模型包含基于联盟计算环境的组件之间的关系来描述联盟服务的本体数据。该系统还包括跨多个分布式标准注册中心参与者分布并存储多个联盟代理的注册信息的分布式联盟代理注册中心，每个联盟代理提供与由多个本体模型描述的至少一个联盟服务相关的代理服务。多个分布式标准注册中心参与者中的第一分布式标准注册中心参与者包括发现处理器和注册中心处理器，发现处理器可操作为从潜在联盟参与者接收包括语义查询数据的联盟参与者查询，该发现处理器还可操作为基于处理被包括在联盟参与者查询中的语义查询数据从多个本体模型中识别至少一个本体模型，注册中心处理器可操作为从潜在联盟代理接收注册请求，以将联盟代理注册为提供与由多个本体模型中的一个描述的联盟服务相关的代理服务，注册中心处理器还可操作为在联盟代理注册中心上存储联盟代理的注册信息。

本文描述的另一实施例提供了一种实施联盟计算环境的方法。该方法包括在分布式标准注册中心的多个分布式标准注册中心参与者中的第一分布式标准注册中心参与者处，从联盟参与者接收包括语义查询数据的联盟参与者查询。该方法还包括由第一分布式标准注册中心参与者基于处理被包括在联盟参与者查询中的语义查询数据来查询分布式标准模型库。另外，该方法包括由第一分布式标准注册中心参与者查询代理由分布式标准模型库中的至少一个标准模型描述的至少一个联盟服务的联盟代理，其中分布式联盟代理注册中心跨多个分布式标准注册中心参与者被维护。该方法还包括，在成功验证联盟代理后，由第一元联盟代理促成从联盟代理到联盟参与者的与至少一个联盟服务相关的代理服务。

本文描述的另一实施例提供了一种用于实施联盟计算环境的系统，该系统包括一个或多个计算机处理器和包含计算机程序代码的存储器，当该计算机程序代码由一个或多个计算机处理器的操作执行时，执行操作。该操作包括：向多个分布式标准注册中心参与者中的第一分布式标准注册中心参与者注册新的标准模型，其中多个分布式标准注册中心参与者被配置为彼此结合操作以形成分布式标准注册中心，并且其中新的标准模型被注册在跨多个分布式标准注册中心参与者被维护的、分布式标准注册中心的分布式标准模型库中。该操作还包括将第一分布式标准注册中心参与者注册为新的标准模型的联盟代理，其中新的标准模型根据联盟计算环境的组件之间的关系来表征联盟服务，并且其中第一分布式标准注册中心参与者被配置为在跨多个分布式标准注册中心参与者被维护的分布式联盟代理注册中心中冗余地存储注册信息。此外，该操作包括在从联盟参与者接收对联盟服务的请求时，验证联盟参与者。该操作还包括，在成功验证联盟参与者后，为联盟参与者促成代理所请求的联盟服务。

本文描述的另一实施例提供了一种实施联盟计算环境的方法。该方法包括：从分布式标准注册中心的多个分布式标准注册中心参与者中的第一分布式标准注册中心参与者请求使用联盟云计算环境的组件之间的关系来描述联盟服务的标准模型，其中多个联盟代理参与者被配置成将标准模型存储于在多个分布式标准注册中心参与者中的每一个上被维护的分布式标准模型库中。该方法还包括识别代理标准模型中描述的联盟服务的联盟代理。此外，该方法包括与联盟代理协商联盟服务的供应。该方法还包括从联盟代理接收与联盟服务相关的代理服务。

具体实施例

本公开总体上提供了用于为联盟计算环境实施分布式标准注册中心(DSR)的系统和技术。可以使用多个DSR参与者来形成DSR，这些参与者可以包括一个或多个元联盟代理。总得来说，元联盟代理使多个联盟云服务提供商能够注册用于它们可以提供的云服务的标准模型，并且这样的元联盟代理可以提供一个或多个应用程序接口(Application ProgramInterface，API)，联盟参与者可以通过这些应用程序接口提交请求特定云服务的查询。例如，一个这样的标准模型可以包括描述由标准定义的一个或多个组件以及组件之间的一个或多个关系的本体模型。然后，元联盟代理可以促成云服务提供商之一为联盟参与者提供云服务，同时还在联盟计算环境中验证云服务提供商和联盟参与者。

在一个实施例中，分布式标准注册中心包括多个分布式标准注册中心参与者，这些参与者被共同配置为使用共识投票机制为分布式标准注册中心提供控制逻辑以做出控制决策。在特定实施例中，分布式标准注册中心参与者包括一个或多个元联盟代理。此外，分布式标准注册中心可以包括在多个分布式标准注册中心参与者的每一个上被维护并且存储多个标准模型的分布式标准模型库的同步副本，每个标准模型基于联盟计算环境的组件之间的关系描述联盟服务。分布式标准注册中心还可以包括跨多个分布式标准注册中心参与者分布并存储多个联盟代理的注册信息的分布式联盟代理注册中心，每个联盟代理提供与由多个标准模型描述的至少一个联盟服务相关的代理服务。

在一个实施例中，分布式标准注册中心参与者配置有发现处理器和注册中心处理器。在特定实施例中，发现处理器可操作为从潜在联盟参与者接收包括语义查询数据的联盟参与者查询，该发现处理器还可操作为基于处理被包括在联盟参与者查询中的语义查询数据从多个标准模型中识别至少一个标准模型。另外，在一个实施例中，注册中心处理器可操作为从潜在联盟代理接收注册请求，以将联盟代理注册为提供与由多个标准模型中的一个描述的联盟服务相关的代理服务，注册中心处理器还可操作为在联盟代理注册中心上存储联盟代理的注册信息。通常，通过提供分布式标准注册中心，实施例可以提供分散的解决方案，同时仍然以可扩展和可靠的方式提供元联盟代理的所有功能。

现在参照图1，根据一个或多个实施例，可以作为联盟云计算环境的示例性联盟计算环境100被示出为具有多个联盟成员或参与者。在该示例中，联盟参与者包括云服务提供商102、104，它们已经通过联盟云代理(federation cloud broker，FCB)106联盟或以其它方式使它们的一些(或全部)服务和/或资源可被彼此访问。就它们可以通过FCB 106提供的云服务而言，它们的服务和/或资源的联盟向云服务提供商102、104提供了更大的灵活性和互操作性。该示例中的云服务提供商102、104可以是身份服务提供商，因此FCB 106可以是身份FCB 106。云服务提供商102、104和身份FCB 106可以一起形成身份联盟。其它联盟参与者可以包括云服务提供商108、110，它们已经通过另一FCB 112联盟或以其它方式使得它们的一些或全部服务和/或资源可被彼此访问。这些云服务提供商108、110和FCB 112可以一起形成另一种类型的联盟，诸如储存联盟。可以形成的其它类型的联盟包括计算联盟、消息传递联盟、电子邮件联盟等。

通常，云服务提供商102、104、108、110可以是通过FCB 106、112联盟云服务的任何个人、组织或实体。云服务提供商的示例包括亚马逊

类似地，联盟云代理106、112可以是管理从云服务提供商102、104、108、110到一个或多个云服务消费者114、116的云服务和资源的发现、使用、性能和交付的任何个人、组织或实体。通常，FCB 106、112为由云服务提供商102、104、108、110提供的联盟云服务提供代理服务。这意味着每个FCB 106、112负责处理它们的云服务提供商102、104、108、110和其它联盟参与者之间的任何交互以消费服务。应该注意的是，FCB在技术上是独立的，并且不同于联盟代理(federation broker，FB)(见图3)，其中FB是管理云服务的使用、性能和交付，并且在云服务提供商和消费者之间协商财务关系和技术关系的任何个人、组织或实体。也就是说，针对本文讨论的各种实施例，FB可以操作和执行与FCB相同的许多功能和服务，反之亦然。

云服务消费者114、116可以是与云服务提供商102、104、108、110维护业务关系并使用来自云服务提供商102、104、108、110的服务的任何个人、组织或实体。这些云服务消费者114、116可以包括至少部分地基于手动来访问和使用云服务的个人消费者114，以及自动访问和使用云服务的系统消费者116。尽管在图中1没有明确示出，但其它联盟参与者可以包括，对云服务(包括信息系统运营和云参与者安全性)进行独立评估的审计机构，以及为各种云联盟参与者提供网络连接性和云服务的传输的运营商。

网络连接118为联盟云环境100提供网络连接性和云服务的传输。这种网络连接118可以是无线连接或有线连接，包括任何物理布线方法，诸如类别5电缆、同轴电缆、光纤、铜线、双绞线以及用于传播电信号的任何其它物理介质。无线连接可以包括但不限于个人区域网络(personal area network，PAN)、局域网(local area network，LAN)、Wi-Fi、蓝牙、蜂窝、全球或基于空间的通信网络。

根据一个或多个实施例，可以为联盟云环境100提供元联盟代理(MFB)120。如前所述，现有的联盟云环境没有为云服务消费者和其它联盟参与者提供用于搜索联盟云代理和/或由此代理的云服务的任何能力。MFB 120通过提供注册中心形式的技术解决方案来解决这个技术问题，该注册中心允许联盟参与者可以登录到合适的URI(例如，网页)并搜索一个或多个联盟云代理106、112及其代理的云服务。同样，每个FCB 106、112可以登录到MFB120，并注册它们的联盟类型或模型以及它们代理的云服务以及诸如成本模型、定价和关于服务的其它信息的信息。不作为代理的联盟参与者也可以登录并注册联盟类型和云服务。事实上，即使不参与任何给定联盟的实体(即，非联盟参与者)，诸如标准团体或研究机构，也可以登录并注册联盟类型和云服务。MFB 120可以要求联盟云代理106、112使用标准模型(例如，本体模型)和语义语言注册它们的联盟类型和它们的云服务。标准模型和语义语言的使用允许云消费者114、116和其它联盟参与者使用语义查询来搜索MFB 120，从而产生在上下文上更准确的搜索结果。简而言之，MFB 120是存储和管理语义上描述特定云联盟类型和能力的本体的实体，以及在这样的本体下协调联盟服务的供应的联盟代理。

术语“本体”在本领域中是众所周知的，并且通常是指使用语义语言来表示或描述关于特定主题或概念的知识或信息的一种结构化或正式的方式，其捕获主题或概念的各种组件之间的上下文关系和关联。MFB 120可能需要用于定义本体的语义语言的示例包括资源描述框架(Resource Description Framework，RDF)、网络本体语言(Web OntologyLanguage，OWL)和OWL-S等等。使用语义语言来创建本体允许MFB 120接受和处理对本体的语义查询，并因此返回上下文上更有意义的搜索结果。这种语义查询或包含语义查询数据的查询能够基于数据中包含的句法、语义和结构化信息来检索显式和隐式导出的信息。作为结果，通过利用模式匹配和数字推理能力，即使在相对模糊或开放的搜索中，查询通常也可以返回更高精度的搜索结果。

在一些实施例中，MFB 120可以将语义语言扩展到其当前能力之外，以便捕获联盟计算环境的附加属性。例如，利用OWL-S，MFB 120可以向本体添加属性，诸如服务水平协议(service level agreement，SLA)、服务质量、成本模型、定价信息、用户评论和反馈、社交-媒体-风格评级等。对OWL-S的这种联盟扩展(出于本公开的目的可以被称为OWL-FED)包括顶层扩展的OWL-S模型，就扩展的服务简档属性和扩展的服务模型定义而言，OWL-S模型将联盟描述为整体。可以定义一组这种扩展的OWL-S模型来与其它联盟参与者和联盟云代理一起描述联盟参与模型的各个阶段(例如，经由MFB的发现、与FCB的协商、联盟服务消费、供应、审计等)。

图2示出了可以由MFB 120管理的本体中的一些的示例，包括基于OWL-S(202)及其上述扩展OWL-FED(203)的公共本体200和特定本体201。公共本体200的示例包括认证204、PaaS 206、SaaS 208、IaaS 210、计算212、DaaS 214等，它们之间的潜在连接和关系由线216表示。特定本体202的示例包括建筑物监测系统218、工厂控制器220、建筑物监视器222、房间传感器224等，它们之间的潜在连接和关系由线226表示。线228指示公共本体200中的一个或多个与特定本体202中的一个或多个之间的潜在连接和关系。

图3示出了根据本公开的一个或多个实施例的可以部署在联盟计算环境300中的MFB 120的示例性架构，该联盟计算环境300可以是联盟云计算环境。如同联盟计算环境100(参见图1)，联盟云环境300具有几个联盟参与者，包括一个或多个云服务提供商302、云服务消费者304、联盟代理306、云服务审计机构308、云网络运营商310等。这些联盟参与者302-310可以在角色和功能上类似于上述联盟计算环境100中的它们的对应者。特别地，云服务提供商302已经经由一个或多个联盟云代理联盟了它们的云服务，如312所示，并且每个FCB 312可以转而以无缝方式向云服务消费者304和其它云联盟参与者提供这些联盟云服务。

在图3示例中，一个或多个联盟云代理312包括OpenID FCB A(314)、另一openIDFCB B(316)、活动目录(active directory，AD)FCB 318、计算市场FCB 320、储存市场FCB322以及其它类型的联盟云代理324。简言之，openID联盟云代理314、316提供openID服务，其基本上是由第三方服务提供商进行的分散认证服务。类似地，活动目录FCB 318代理活动目录服务，其是微软为Windows域网络开发的目录服务。计算市场FCB 320和储存市场FCB322，顾名思义，分别代理计算服务和数据储存服务。

根据一个或多个实施例，每个联盟云代理312可以登录并在MFB 120注册其相应的联盟类型和云服务，以允许其它联盟参与者302-310发现联盟云代理312和它们代理的云服务。在一些实施例中，其它联盟参与者302-310也可以登录并在MFB 120注册联盟类型和云服务。如前所述，MFB 120可能要求使用语义语言将联盟类型和云服务定义为本体模型，以便增强本体模型的搜索。为此，MFB 120可以包括以可搜索方式(例如，经由一个或多个数据库)存储本体模型的本体联盟模型库328和以可搜索方式(例如，经由一个或多个数据库)存储关于联盟云代理312的信息的FCB注册中心330。

通常，本体联盟模型库328存储由联盟云代理312创建并被上传到MFB 120的本体模型。替代地(或附加地)，本体模型可以由联盟参与者302-310创建，然后被上传并被存储在联盟云代理312处，以供代理服务使用。在后一种情况下，联盟云代理312可以简单地将预定义和预存储的本体模型上传并存储在本体联盟模型库328中。在任一情况下，本体模型使用语义语言来表示和以其它方式描述联盟云计算环境300的各种组件之间的关系。联盟云代理312还可以对本体模型进行改变和添加，并且通常可以管理本体模型。此外，本体联盟模型库328还可以支持本体模型的用户反馈和社交-媒体-风格评级，其随后可以用作用于查询目的的过滤器。

FCB注册中心330提供联盟云代理的注册中心，其允许联盟云代理312发布关于它们自己和它们代理的云服务的信息。联盟云代理312同样可以对其注册进行改变和添加，并且通常可以根据需要管理该注册。并且如同本体联盟模型库328，FCB注册中心330也可以支持用户反馈和社交-媒体-风格评级，其随后可以被用作用于查询目的的过滤准则。

在MFB 120中还提供了信任管理模块332和货币化管理模块334。信任管理模块332操作为允许联盟云代理312和其它联盟参与者确定彼此的身份、特权和/或信任特性。任何合适的认证技术(例如，OpenID，AD等)可以由信任管理模块332使用，包括涉及重复使用来自本体联盟模型库328和FCB注册中心330的数据的技术。货币化服务模块334基于联盟云代理312和其它联盟参与者对云服务的消耗来促成联盟云代理312和其它联盟参与者之间的金融交易，如本体联盟模型库328和FCB注册中心330中所述。任何合适的货币化方法论(例如，一次性支付、订阅支付、按使用支付等)可以被货币化服务模块334用来货币化云服务，包括允许MFB 120收取交易费和/或其它费用的那些服务。

图4示出了根据一个或多个实施例的MFB 120的示例性实施方式。继续按照图3的架构，MFB 120包括本体联盟模型库328、FCB注册中心330、信任管理模块332和货币化管理模块334。如所讨论的，本体联盟模型库328存储本体模型，本体模型使用语义语言来表示或以其它方式描述联盟计算环境的组件之间的关系，而FCB注册中心330存储联盟云代理及其代理的云服务的注册信息。在一些实施例中，储存器可以是集中式数据库，或者在一些实施例中，它可以分布在若干数据库中。

在一些实施例中，MFB 120还可以包括被编程为实施FCB发现功能410和FCB注册中心功能412的一个或多个计算机处理器。通常，发现处理器410操作为允许联盟参与者发现本体模型和联盟云代理，并且注册中心处理器412操作为允许联盟云代理上传并存储它们的本体模型和相应的注册信息。这些处理器410、412可以是物理处理器，或者它们可以是使用软件或硬件和软件的组合来实施的虚拟处理器。

在图4的示例中，发现处理器410具有多个子处理器，包括语义查询子处理器414和查询匹配子处理器416。语义查询子处理器120操作为从用户接收语义查询，包括由用户手动输入的查询以及由系统自动生成的查询。查询匹配子处理器416操作为对照本体联盟模型库328和/或FCB注册中心330处理语义查询，并且确定是否有任何本体模型和/或联盟云代理具有匹配该语义查询的云服务。此后，查询匹配子处理器416向提交了查询的用户和/或系统提供关于任何匹配的联盟云代理及其云服务的查询结果，该查询结果包括超链接和/或其它识别信息，在一些实施例中可以包括定价信息和用户评级。用户接口子处理器418操作为允许用户(例如，经由图形用户界面)参与与MFB 120的各种交互，并且用户/系统认证子处理器418操作为在准许与MFB 120进行交互之前以已知的方式认证用户/系统凭证。

注册中心处理器412同样具有多个子处理器，包括本体数据子处理器422和代理数据子处理器424。本体数据子处理器422操作为对由联盟云代理上传或以其它方式存储在本体联盟模型库328中的本体模型强加一个或多个本体规则，以确保模型符合本体要求。这样，本体数据子处理器422可以验证本体模型具有特定的数据结构，并使用MFB 120所需的特定语义语言，如下面进一步讨论的。代理数据子处理器424以类似的方式操作，以提供针对由联盟云代理输入到FCB注册中心330中的注册信息的类型的验证。FCB接口子处理器426操作为提供被联盟云代理要求的任何应用接口(例如，API等)，以与MFB 120交互，并且FCB认证子处理器428操作为在准许任何本体模型或FCB注册的输入之前以已知的方式认证FCB凭证。

可以向MFB注册并被存储在FCB注册中心中的FCB注册的示例如下例1所示。在该示例中，示例性FCB注册可以包括FCB的联盟类型、已经通过FCB联盟其云服务的云服务提供商、以及由FCB代理的云服务的列表。本领域技术人员将理解，FCB注册可能比所示的示例更复杂，包括关于FCB、联盟云服务提供商及其云服务的更详细的信息，诸如成本模型和定价信息。然后，当联盟参与者使用匹配该FCB注册的语义查询在FCB注册中心和本体联盟模型库中搜索联盟云代理和/或云服务时，可以发现该FCB注册。

示例1：联盟云代理注册

云服务可以使用扩展到覆盖必要联盟特性的本体模型中的语义语言来描述，诸如前面提到的RDF、OWL或OWL-S。OWL-S的扩展在本文被称为OWL-FED。本体模型的使用提供了一种正式或结构化的方式来捕获云服务的各种功能和特性之间的上下文关系和关联。例如，使用OWL-FED语言的本体模型将使用以下OWL-S组件来描述云服务：服务简档、服务模型和服务基点(Service Grounding)。一般来说，服务简档描述服务要做什么，而服务模型告知如何使用服务，包括输入、输出、前提条件和服务执行的结果。服务模型还可以描述过程以及不同联盟参与者之间的交互。该过程可以基于例如原子事务(atomic transaction)或合成事务(例如，组装各种原子事务)。服务基点描述如何通过技术手段来使用服务，诸如REST API、或者特定协议或网络套接字。

本体模型还可以包括联盟参与者与云联盟的交互的描述。通常，联盟参与者与云联盟的交互可以被概念化为一系列服务交互。这是因为当使用云联盟服务时，联盟参与者与特定网络服务进行交互并且执行特定请求和动作。这些请求和动作包括联盟发现(即，联盟参与者与MFB交互以发现云服务)、联盟协商(即，联盟参与者与联盟云代理进行交互以建立定价和其它货币条款)和联盟参与(即，联盟参与者作为提供者、消费者、审计机构等与其它联盟参与者进行交互等)。

在一个实施例中，联盟交互被定义为本体模型中的一系列OWL-S服务定义，共同表示对OWL-S的扩展(以上称为OWL-FED)。在这样的实施例中，每个服务定义可以对应于一组服务交互，在提供联盟的总体观点的单个联盟级的OWL-FED描述下，服务定义是统一的。这种联盟级的OWL-FED描述可以包括目前在OWL-S之外而在OWL-FED中被指定的某些联盟特定信息。联盟特定信息可以包括联盟特定服务模型，该服务模型定义单独的联盟服务的合成，其使用OWL-S来指定。该信息还可以包括定义联盟特性的联盟特定服务简档，其也使用OWL-S来指定。这些特性可以包括例如服务质量(QoS)、成本模型、定价信息、用户评论和反馈、社交-媒体-风格评级等。然后，云联盟参与者可以“查找”联盟云代理，寻找满足其需求和要求的特定联盟云服务。

可以存储在MFB的本体联盟模型库中的本体模型的示例在下面的示例2中示出。如上所述，本体模型(本体模型A)可以包括本体数据，诸如联盟特定服务、联盟特定服务模型、联盟特定服务简档和联盟特定服务基点，所有这些都使用OWL-S来描述。本领域技术人员将再次理解，本体模型可能比所示出的示例更复杂，包括关于FCB、联盟云服务提供商及其云服务的更详细的本体数据，诸如成本模型和定价信息。然后，当联盟参与者搜索本体联盟模型库时，可以发现本体模型。

示例2：联盟本体模型

如上所述，MFB可以使用语义查询来引用存储在本体联盟模型库中的本体模型。查询可以是由用户使用用户界面执行的手动查询，或者查询可以由使用MFB所提供的功能性的系统自动执行。这种查找可以返回精确匹配、仅针对查询请求的一部分找到匹配的降级匹配、或者其中MFB识别了一起匹配查询请求的若干联盟云代理和/或云服务的组合的复合匹配。

除发现功能之外，MFB还可以提供增加价值的其它功能性，并支持和鼓励联盟云代理和其它联盟参与者使用MFB，而不是直接相互交易。因此，如上所述，MFB可以提供货币化平台，用于联盟云代理和联盟参与者彼此交易，以及用于MFB在所有级(例如，参与者对参与者、参与者对FCB、FCB对MFB和参与者对MFB)货币化整个生态系统。此外，MFB可以向联盟参与者提供与FCB注册中心集成的货币化管理功能性、关于云服务和服务提供商、审计机构等的专门信息，以及联盟云代理，以便参与者可以有效地找到和利用服务。交易管理功能性还可以支持供应商评级或声誉的创建，因为这些信息为参与者提供了价值。

作为一个示例，联盟参与者可以使用关于可用云服务的规范化本体信息来查找和选择云服务。在本示例中，MFB可以基于一组相关的服务维度出现该信息，所有这些维度都可以用作过滤器。例如，服务搜索的一个维度是相关性。相关性可用于确定消费者需要的服务简档与由FCB公司代理的服务简档之间的明确匹配。其次，消费者通常会有服务级别要求(高服务级别意味着更高的成本)。消费者可以要求对服务的搜索在结果列表中仅包括由FCB代理的具有足够高的提供商评级和/或支持各种服务特性(成本模型、服务质量保证等)的服务。成本也可以用作云服务提供商候选的排名和其它过滤准则。

考虑消费者需要计算平台服务来完成隔夜批处理作业的服务的示例，这是基于云的大数据集成和分析操作的常见要求。在本示例中，消费者将搜索联盟计算平台服务。由于批处理作业可以在夜间任何时间执行，所以消费者可以选择按联盟类型进行过滤，然后选择联盟和允许消费者能够以所需的成本/质量水平消费该服务的FCB支持服务质量特性，因为消费者愿意接受相对较低的服务水平来降低成本。从消费者的角度来看，如果能够保证在未来8小时内以更低的服务水平完成处理作业，这就足够了。

另一方面，虽然低服务质量是可以接受的，但消费者可能不会接受FCB参与的FCB或云联盟的低评级。例如，消费者可能需要云联盟或FCB的最低评级为5星中的4星。一旦消费者选择了云联盟和FCB，它们就可以将相同的选择准则应用于它们对联盟服务提供商(例如，计算服务提供商)的选择。通过提供这种详细级别的信息和高效找到合适的联盟和服务的能力，消费者很可能会继续使用MFB。

MFB的货币化管理功能性也有利于云联盟的参与者，这有助于确保云服务消费者、提供商和FCB不会在MFB之外执行交易。此外，提供在其它地方找不到的价值也可以鼓励联盟参与者留在MFB内。例如，MFB可能表示非标准计算产品和服务供应的市场和清算所。这有利于服务提供商，因为它们可以为可能只是暂时可用或可能不是经由标准渠道可销售的服务添加额外的销售渠道。这也有利于消费者，因为它们可以找到可能带来卓越价值的服务。联盟云代理也可能以类似于服务提供商的方式受益，但适用于云代理服务。

继续计算平台服务的示例，请考虑具有可供销售但无法经由正常的订阅生命周期销售过程被高效销售的额外计算资源的云服务提供商。MFB可以使这样的提供商在可用时以更低成本和/或更低服务级别协议(SLA)计算平台服务通过联盟云代理轻松引入和代理服务，然后在不再可用时禁用服务。通过为云服务消费者提供一种使用有限时间或特殊情况服务供应的方式，提供商可以最大限度地利用可用的平台资源，从而从在没有MFB的情况下可能尚未被使用的资源中产生收益。

因此，通过为联盟云代理供应一种简单的方式来销售各种各样的代理服务，提供商销售更广泛的各种各样的云服务，并由此产生的消费者的额外选择，MFB提供了联盟云代理、提供商和消费者在MFB之外找不到的价值。该价值还在于消除了交易摩擦，从而进一步降低了联盟云代理、提供商和消费者在MFB以外直接执行交易的可能性。

如前所述，MFB可以使用不同的货币化模式产生收益，每种模式用于特定场景。一种可能性是将MFB服务作为订阅出售给消费者和/或提供商。另一种可能性是从通过MFB进行的每笔交易中收取一定比例的费用，或者收取作为交易担保的固定费用，或者收取作为使用MFB总成本的一定比例的费用。这些费用可能由消费者或提供商或两者共同承担。这两种场景都假设交易受到MFB的监控。分析论可用于经由资料收集产生收益，可以将关于最需要哪些类型的服务定义的数据提供给服务提供商以指导它们。可以将关于与消费者的使用模式匹配的可用服务类型的数据提供给消费者，等等。

在特定实施例中，MFB 120可以使用分布式模型来实施，其中多个MFB参与者一起工作来实施MFB 120的控制逻辑和功能性。这样做提供了MFB 120的分散实施方式，从而防止任何单个实体控制集中式注册中心基础设施。在特定实施例中，多个MFB参与者以分布式对等(peer-to-peer，P2P)方式操作(与由单个组织或实体控制的集中式系统或集群相反)，以管理分布式标准注册中心(DSR)。相对于集中式标准注册中心，这样的DSR可以提供优越的可扩展性和弹性，并且DSR可以由多个MFB参与者使用分散的控制机制来管理。例如，多个MFB参与者可以被配置成实施P2P集群和分发机制，诸如区块链实施方式或分布式哈希表(Distributed Hash Table，DHT)算法。在一个实施例中，由多个MFB参与者实施的P2P集群和分发机制可以是拜占庭容错(Byzantine fault tolerant，BFT)，从而提高分布式系统抵抗攻击和故障的弹性。

图4B示出了根据本文描述的一个实施例的包括这种分布式标准注册中心450的系统440。如图所示，系统440包括多个元联盟代理460(1)-(N)。MFB 460(1)-(N)中的每一个包含相应的本体模型库328、联盟云代理注册中心330、对等集群组件470(1)-(N)、信任管理模块332(1)-(N)和货币化管理模块334(1)-(N)。尽管在所描绘的示例中，每个MFB 460(1)-(N)包含本体模型库328，但更一般地，MFB 460(1)-(N)可以包含使用任何合适的格式来描述标准的标准模型库，并且本体的使用仅出于说明的目的而非限制。

在所描绘的图示中，DSR注册中心450由MFB 460(1)-(N)的本体模型库328(1)-(N)、联盟云代理注册中心330(1)-(N)和对等集群组件470(1)-(N)形成。通常，对等集群组件470(1)-(N)被配置为实施P2P集群和分发机制(例如，DHT的实施方式)。例如，多个MFB参与者460(1)-(N)可以提供(多个)API，参与者可以通过API使用模型数据(以及诸如评级数据、定价数据等其它数据)来查询分布式标准模型。此外，这样的(多个)可以进一步使参与者能够使用例如，实施者元数据和其它信息(例如，评级数据)来查询各种提供商。多个MFB参与者460(1)-(N)还可以提供信任基础设施，以供验证与分布式标准注册中心450的交易中涉及的各方时使用。例如，多个MFB参与者460(1)-(N)可以在返回对特定云服务提供商的指示作为提交给(多个)API的查询的一部分之前，使用信任基础设施来验证特定的云服务提供商。

在一个实施例中，分布式标准注册中心450被配置为存储分布式本体模型库(在本文也称为分布式标准库)。在特定实施例中，分布式标准库的相同副本存储在DSR 450内的多个MFB 460(1)-(N)的每一个上。在这样的实施例中，多个MFB参与者460(1)-(N)可以被配置成实时地保持这样的副本彼此同步。在另一实施例中，标准库的部分可以跨DSR 450内的多个MFB 460(1)-(N)分布。

此外，分布式MFB 450还可以跨多个DSR参与者460(1)-(N)维护分布式联盟代理注册中心。在特定实施例中，分布式联盟代理注册中心的相同副本被存储在MFB 460(1)-(N)中的每一个上，并且当在注册中心上执行修改操作时，这些副本保持彼此同步。在一个实施例中，分布式联盟代理注册中心跨多个MFB参与者460(1)-(N)冗余地分布。这样做使得MFB参与者460(1)-(N)中的每一个能够仅存储分布式联盟代理注册中心的一部分，但是允许分布式联盟代理注册中心以容错的方式存储，从而在MFB 460(1)-(N)中的一个发生攻击或故障的情况下增加系统的弹性。此外，DSR 450可以维护(多个)反馈和评级数据库，以用于存储关于本体模型、服务提供商等的用户提交的评级信息。这种(多个)反馈和评级数据库可以跨多个MFBs 460(1)-(N)冗余地分布。

通常，DSR 450可以被配置为支持MFB 120的所有能力，包括对标准注册中心的管理。这种管理可以包括例如标准注册、提供商注册、标准查询、提供商查询、标准和提供商元数据等。此外，这些不同的功能可以由多个MFB 460(1)-(N)中的一个或多个使用分布式标准注册中心来执行，该分布式标准注册中心使用对等集群机制来实施。结果，分散的DSR450可以使用分散的、共识驱动(consensus-driven)的决策制定(decision-making)来提供MFB 120的功能。此外，分布式标准注册中心可以是拜占庭容错的，并且多个MFB 460(1)-(N)可以被配置为使用拜占庭容错决策制定来动态地添加和移除特定MFB参与者。同样，多个MFB 460(1)-(N)可以被配置为使用BFT决策制定来动态地添加和移除已注册的标准和标准提供商。

参照图5，示出了根据一个或多个实施例的用于向MFB注册本体模型的示例性工作流程500。工作流程500通常在箭头502处开始，其中联盟参与者向MFB的本体模型库提交语义查询以发现匹配某些感兴趣的准则的本体模型。对于本体模型注册工作流程500，联盟参与者通常是联盟云代理，但也可以是寻求向MFB注册本体模型的任何联盟参与者。在箭头504处，MFB对照本体模型库处理查询，并返回匹配或部分匹配联盟参与者的某些感兴趣的准则的模型列表(如果有的话)。示例可以包括各种识别服务模型、存储服务模型、计算服务模型等。

如果返回的模型列表不包括与感兴趣的准则匹配的任何本体模型，则联盟参与者可以在箭头506处向本体模型库提交新的(即，没有预先注册的)本体模型。新的本体模型的示例可以包括消息服务模型、电子邮件服务模型、物联网(IoT)服务模型等。在接收新的本体模型注册请求之后，在箭头508处，MFB经由信任管理模块验证联盟参与者。信任管理模块检查联盟参与者是否是合法的联盟参与者，如果是，则信任管理模块在箭头510处确认联盟参与者的有效。此后，MFB将新的本体模型存储在本体模型库中，如512所示，并在箭头514处向联盟参与者确认新的本体模型的注册。

虽然已建立的MFB参与者460(1)-(N)的集群可以使用P2P集群技术可靠地添加或移除特定MFB参与者，但是MFB参与者460(1)-(N)的集群的初始建立可能是重大挑战(目标是消除任何单点故障)。在一个实施例中，为了能够安全地创建集群，可以使用带外共识(例如，可信方的面对面会议)来形成MFB参与者460(1)-(N)的初始集群。在一个实施例中，该初始集群包括可信管理域中的建立者节点，以进一步确保分布式MFB 450的安全性和可靠性。这种可信的建立者节点可用于为愿意加入集群的新节点分发参与者注册中心和其它信息。

通常，初始形成集群所需的MFB参与者460(1)-(N)的最小数量可以随着BFT算法的选择而变化。例如，一些算法可能需要至少3个MFB参与者来形成初始集群，而其它算法可能需要4个或更多MFB参与者。然而，提供这样的示例仅仅是为了说明的目的而非限制，并且更一般地，任何合适数量的MFP参与者都可以用于形成初始集群，这与本文描述的功能一致。

关于向形成分布式MFB 450的MFB参与者460(1)-(N)的集群添加新的MFB参与者，试图加入集群的新节点可以查询已知的MFB参与者460(1)-(N)(其可以是建立者节点)以请求集群成员注册中心。潜在的新节点然后可以向已知的MFB参与者提交加入请求，并且已知的MFB参与者然后可以经由复制行为(即，根据分布式MFB 450的MFB参与者460(1)-(N)实施的P2P集群算法)将所提交的请求传播到集群中的其它MFB参与者460(1)-(N)。现有的多个MFB参与者460(1)-(N)然后可以对潜在新节点的应用进行投票，并且可以基于投票的共识做出决策。例如，如果收到的多数票赞同对潜在新节点的承认，则潜在新节点可以被接受。在特定实施例中，多个MFB参与者460(1)-(N)被配置为使用拜占庭容错投票过程来进一步增加分布式MFB 450的安全性和可靠性。

在一个实施例中，为了避免虚假加入请求的泛滥，多个MFB参与者460(1)-(N)可以对来自潜在新节点的加入请求进行速率限制，并且可以将试图超过这种限制的滥用客户端(或者以其它方式表现出滥用、恶意或潜在错误行为的客户端)列入黑名单。一旦成功加入，新的MFB参与者可以在DSR参与者注册中心和标准库上执行追赶操作，以便新的MFB参与者可以开始履行其作为MFB参与者的角色。

图6示出了根据本公开的各种实施例的MFB的示例性FCB注册工作流程600。工作流程600通常从箭头602开始，其中FCB向MFB的本体模型库提交语义查询，以发现匹配某些感兴趣的准则的本体模型。在箭头604处，MFB对照本体模型库处理查询，并返回匹配或部分匹配FCB感兴趣的准则的模型列表(如果有的话)。

在接收与感兴趣的准则匹配的本体模型的列表时，在箭头606处，FCB可以向MFB的FCB注册中心将自己注册为在本体模型之一中描述的给定联盟模型或联盟类型的代理。在接收到该FCB注册请求后，在箭头608处，MFB使用信任管理模块来验证FCB。信任管理模块检查FCB是否是合法的FCB，如果是，则在箭头610处，信任管理模块确认FCB的有效性。

此时，在箭头612处，MFB可以可选地请求FCB支付以换取允许FCB向FCB注册中心注册自己。如果支付条款是可接受的，则在箭头614处，FCB经由MFB的货币化管理模块向MFB提交支付。在箭头616处，货币化管理模块处理并确认收到对MFB的支付，之后MFB在FCB注册中心注册FCB。此后，在箭头618处，MFB确认FCB的注册。

图7示出了根据本公开各种实施例的MFB的示例性本体模型和FCB发现工作流程700。工作流程700通常从箭头702开始，其中联盟参与者向MFB的本体模型库提交语义查询，以发现匹配某些感兴趣的准则的本体模型。联盟参与者可能是该发现工作流程700的联盟云代理，但也可以是寻求发现本体模型和来自MFB的FCB的任何联盟参与者。在箭头704处，MFB对照本体模型库处理查询，并返回匹配或部分匹配联盟参与者感兴趣的准则的模型列表(如果有的话)。

然后，在箭头706处，联盟参与者向MFB的FCB注册中心提交语义查询，以发现代理与由所返回的本体模型列表中的一个或多个本体模型所描述的服务对应的云服务的联盟云代理。在接收对FCB注册中心的查询后，在箭头708处，MFB经由信任管理模块验证联盟参与者。信任管理模块检查联盟参与者是否是合法的联盟参与者，如果是，则在箭头710处，信任管理模块确认联盟参与者的有效性。此后，在箭头712处，MFB对照FCB注册中心处理该查询，并向联盟参与者返回与所返回的本体模型列表对应的联盟云代理列表(如果有的话)。

图8示出了根据本公开各种实施例的示例性MFB参与工作流程800。工作流程800通常从箭头802开始，其中联盟参与者向MFB的本体模型库提交语义查询，以确定特定联盟模型或联盟类型当前是否被本体模型库中的本体模型描述。在箭头804处，MFB对照本体模型库处理查询，并向联盟参与者返回匹配或部分匹配所请求的联盟模型的本体模型列表(如果有的话)。

在箭头806处，联盟参与者接下来从所返回的列表中选择代理与期望的本体模型中的一个对应的云服务的FCB，并请求对来自MFB的所选择的FCB进行验证。在接收到验证请求后，MFB经由信任管理模块检查所选择的FCB是否是合法的FCB，如果是，则在箭头808处，MFB向联盟参与者确认所选择的FCB的有效性。然后，在箭头810处，联盟参与者可以从所选择的FCB请求联盟服务的供应。

在接收对供应联盟服务的请求之后，在箭头812处，FCB请求对来自MFB的联盟参与者的验证。然后，MFB经由信任管理模块检查联盟参与者是否是合法参与者，如果是，则在箭头814处，MFB向FCB确认联盟参与者的有效性。

在箭头818处，FCB可以可选地向联盟参与者请求支付以交换联盟服务的供应。如果支付条款是可接受的，则在箭头818处，联盟参与者经由MFB的货币化管理模块向FCB提交支付。货币化管理模块810处理并验证支付的接收，并且MFB在箭头820处确认对FCB的支付。此后，在箭头822处，FCB向联盟参与者供应或安排供应所请求的联盟服务。

图9是根据本文描述的一个实施例的用于将潜在DSR参与者添加到DSR集群的工作流程。如图所示，方法900开始于操作910，其中第一DSR参与者向第一DSR集群参与者发送加入DSR集群的请求。第一DSR参与者验证潜在DSR参与者(操作920)。例如，第一DSR参与者可以接收识别潜在的DSR参与者的安全证书(例如，安全套接字层(SSL)证书)，第一DSR参与者可以通过确保安全证书是由可信机构授予的并且安全证书仍然有效来验证潜在DSR参与者。

在验证潜在DSR参与者的身份后，第一DSR参与者向DSR集群中的所有DSR参与者请求对是否承认潜在DSR参与者进行投票(操作930)。集群中的DSR参与者确定并向彼此发送它们相应的投票(操作940)。在所描绘的实施例中，DSR集群中的DSR参与者基于它们自己的投票和从其它DSR参与者接收的投票来确定共识投票是赞成的(操作950)。在确定共识投票是将潜在DSR参与者添加到集群的赞成票时，DSR参与者将潜在DSR参与者添加到DSR集群(操作960)。在所描绘的实施例中，第一DSR参与者向潜在DSR参与者发送对承认的确认(操作970)。

在接收确认之后，潜在DSR参与者从DSR集群中的各个DSR参与者请求各种注册和其它参与者数据(操作980)。例如，潜在DSR参与者可以请求标准注册中心、服务提供商注册中心等的副本。此外，在所描绘的实施例中，DSR集群参与者(包括新添加的潜在DSR参与者)执行操作以重新平衡跨集群中的DSR参与者的任何分布式集群数据(操作990)。例如，在一个实施例中，服务提供商注册中心可以以确保拜占庭容错的方式跨各个DSR参与者分布(例如，使用DHT形式)。将新的DSR参与者添加到集群之后，服务提供商注册中心中的数据的至少一部分可以跨DSR参与者重新分布，以考虑到新添加的DSR参与者。

图10是根据本文描述的一个实施例的用于从DSR集群中移除DSR参与者的工作流程。如图所示，工作流程1000开始于操作1010，其中DSR集群中的第二DSR参与者确定从DSR集群中移除第一DSR参与者。一般来说，许多场景可能导致DSR参与者决定尝试从DSR集群中移除另一个DSR参与者。例如，这种场景可以包括(但不限于)另一个DSR参与者表现出错误行为，另一个DSR参与者表现出响应时间慢或完全变得没有响应，等等。

在确定移除第一DSR参与者之后，第二DSR参与者向DSR集群的其它成员请求对移除第一DSR参与者进行投票(操作1020)。作为响应，DSR集群中的DSR参与者确定并向彼此发送它们的关于移除第一DSR参与者的投票(操作1030)。DSR集群中的DSR参与者确定共识投票是否赞成移除第一DSR参与者(操作1040)。在所描绘的实施例中，DSR参与者确定共识投票是赞成的，并且从DSR集群中移除第一DSR参与者(操作1050)。第二DSR参与者向第一DSR参与者发送通知，指示第一DSR参与者从DSR集群被移除(框1060)。此外，在所描绘的实施例中，跨剩余的DSR参与者重新平衡任何分布式数据(操作1070)。

图11是根据本文描述的一个实施例的用于将联盟代理添加到DSR集群的代理注册中心的工作流程。如图所示，工作流程1100开始于操作1110，其中联盟代理向第一DSR参与者发送向分布式标准注册中心注册的请求。第一DSR参与者验证联盟代理(操作1120)。例如，第一DSR参与者可以验证由联盟代理提供的安全证书是由可信机构提供的，并且该安全证书仍然有效并且没有过期。

在验证联盟代理之后，第一DSR参与者请求DSR集群中的其它DSR参与者对是否承认联盟代理进行投票(操作1130)。DSR参与者确定它们相应的投票并将它们的投票发送给彼此(操作1140)，并且在所描绘的示例中，DSR参与者确定共识投票是赞成的(操作1150)。结果，DSR参与者将联盟代理添加到代理注册中心(操作1160)。此外，在当前示例中，第一DSR参与者向联盟代理发送确认，指示联盟代理被DSR承认(操作1170)。

图12是根据本文描述的一个实施例的用于从DSR集群的代理注册中心移除联盟代理的工作流程。如图所示，工作流程1200开始于操作1210，其中第一DSR参与者确定从DSR移除联盟代理。一般来说，第一个DSR参与者可以出于各种不同的原因确定移除联盟代理，包括例如但不限于联盟代理的错误行为、联盟代理的响应时间慢或无响应、指示联盟代理表现不佳的用户评级等等。更一般地，设想DSR参与者可以出于与本文描述的功能一致的任何合适的原因确定尝试从代理注册中心移除联盟代理。

第一DSR参与者向其它DSR参与者发起对是否移除联盟代理进行投票(操作1220)。集群中的DSR参与者确定它们相应的投票，并将这些投票相互发送(操作1230)。DSR参与者随后确定投票的共识是否是移除联盟代理。在所描绘的实施例中，DSR参与者确定关于移除第一联盟代理的共识是赞成的(操作1240)，并且DSR参与者从DSR的代理注册中心移除联盟代理(操作1250)。此外，在所描绘的实施例中，第一DSR参与者向第一联盟代理发送通知，指示第一联盟代理从DSR的代理注册中心被移除(操作1260)。

图13是根据本文描述的一个实施例的用于向DSR集群注册本体模型的工作流程。如图所示，工作流程1300开始于操作1310，其中标准注册者向第一DSR参与者发送请求，请求向DSR注册新的标准模型。例如，标准注册者可以是学术机构、研究组织或更一般的任何有兴趣在DSR注册标准的实体。在接收请求之后，第一DSR参与者验证新的标准模型(操作1320)。在成功验证新标准模型之后，第一DSR参与者向其它DSR参与者发起对是否注册新标准进行投票(操作1330)，并且其它DSR参与者彼此提供它们相应的投票(操作1340)。

在所描绘的实施例中，DSR参与者确定投票的共识是赞成注册新的标准模型(操作1350)。结果，DSR参与者将新的标准模型添加到DSR的标准注册中心(操作1360)。第一DSR参与者还向标准注册者发送确认，确认新的标准模型已被成功添加到DSR的标准注册中心中。

图14示出了可用于实施本公开各种实施例的示例性计算系统。通常，在本公开的各种实施例中使用的任何通用计算机系统可以是，例如诸如基于英特尔奔腾型处理器、摩托罗拉PowerPC、

例如，本公开的各种实施例可以实施为在通用计算机系统1400中执行的专用软件，诸如图14所示。计算机系统1400可以包括连接到一个或多个存储器设备1430的处理器1420，诸如磁盘驱动器、存储器或用于存储数据的其它设备。存储器1430通常用于在计算机系统1400的运行期间存储程序和数据。计算机系统1400还可以包括提供额外存储容量的储存系统1450。计算机系统1400的组件可以通过互连机制1440耦合，互连机制1440可以包括一个或多个总线(例如，集成在同一机器内的组件之间)和/或网络(例如，驻留在独立的分立机器上的组件之间)。互连机制1440使得可以在系统1400的系统组件之间交换通信(例如，数据、指令)。

计算机系统1400还包括一个或多个输入设备1410，例如键盘、鼠标、轨迹球、麦克风、触摸屏，以及一个或多个输出设备1460，例如打印设备、显示屏、扬声器。此外，计算机系统1400可以包含将计算机系统1400连接到通信网络的一个或多个接口(未示出)(作为互连机制1440的补充或替代)。

在图15中更详细示出的储存系统1450典型地包括其中存储了定义由处理器1420执行的程序的信号的计算机可读和可写非易失性记录介质1510、或者存储在介质1510上或介质1510中由该程序处理以执行与本文描述的实施例相关联的一个或多个功能的信息。该介质例如可以是磁盘或闪存。典型地，在操作中，处理器1420使得数据从非易失性记录介质1510被读取到储存系统存储器1520中，这允许处理器比介质1510更快地访问信息。该储存系统存储器1520通常是易失性随机存取存储器，诸如动态随机存取存储器(DRAM)或静态存储器(SRAM)。如图所示，该储存系统存储器1520可以位于储存系统1450中，或者位于系统存储器1430中。处理器1420通常操纵存储系统1520内的数据，然后在处理完成后将数据复制到介质1510。已知多种机制用于管理介质1510和集成电路存储元件1520之间的数据移动，并且本公开不限于此。本公开不限于特定的存储器1520、存储器1430或储存系统1450。

计算机系统可以包括专门编程的专用硬件，例如专用集成电路(ASIC)。本公开的各方面可以在软件、硬件或固件或其任意组合中实现。此外，这些方法、动作、系统、系统元件及其组件可以作为上述计算机系统的一部分或作为独立组件来实施。

尽管计算机系统1400通过示例的方式被示出为可以在其上实践本公开的各个方面的一种类型的计算机系统，但是应当理解，本公开的各方面不限于在如图14所示的计算机系统上实施。本公开的各个方面可以在具有图14所示的不同架构或组件的一个或多个计算机上实施。此外，在本文(或在权利要求中)将本公开的实施例的功能或过程描述为在处理器或控制器上执行的情况下，这种描述旨在包括使用多于一个处理器或控制器来执行这些功能的系统。

计算机系统1400可以是使用高级计算机编程语言可编程的通用计算机系统。计算机系统1400也可以使用专门编程的专用硬件来实施。在计算机系统1400中，处理器1420通常是商业上可获得的处理器，诸如可从英特尔公司获得的众所周知的奔腾类处理器。还有许多其它处理器可用。这种处理器通常执行操作系统，例如，可以是Windows 95、Windows98、Windows NT、Windows 2000、Windows ME、Windows XP、Vista、Windows 7、Windows 10，或可从微软公司获得的子操作系统、或可从苹果计算机获得的MAC OS System X或其后代操作系统、可从Solaris公司获得的Solaris操作系统、UNIX、Linux(任何发行版)，或可从各种来源获得的后代操作系统。可以使用许多其它操作系统。

处理器和操作系统共同定义了针对其编写高级编程语言的应用程序的计算机平台。应当理解，本公开的实施例不限于特定的计算机系统平台、处理器、操作系统或网络。此外，对于本领域技术人员来说，显然本公开不限于特定的编程语言或计算机系统。此外，应当理解，也可以使用其它合适的编程语言和其它合适的计算机系统。

在前面，参考了各种实施例。然而，本公开的范围不限于具体描述的实施例。相反，所描述的特征和元素的任何组合，无论是否与不同的实施例相关，都被设想来实施和实践所设想的实施例。此外，尽管实施例可以实现优于其它可能的解决方案或现有技术的优点，但是特定的优点是否由给定的实施例实施并不限制本公开的范围。因此，前面的方面、特征、实施例和优点仅仅是说明性的，并且不被认为是所附权利要求的要素或限制，除非在权利要求中明确陈述。

应当理解，结合所公开的实施例的各方面的实际商业应用的开发将需要许多实施特定的决策来实现商业实施例。这种实施特定的决策可以包括并且可能不限于符合系统相关的、商业相关的、政府相关的和其它的约束，这些约束可以根据特定的实施、位置和时间而变化。虽然开发者的努力可能被认为是复杂和耗时的，但是对于受益于本公开的本领域技术人员来说，这种努力仍然是常规任务。

还应该理解，本文公开和教导的实施例易于进行大量和各种修改和替代形式。因此，单数术语的使用，例如但不限于“一”等，并不旨在限制项目的数量。类似地，在书面描述中使用的任何相关术语，例如但不限于“顶部”、“底部”、“左”、“右”、“上部”、“上部”、“下”、“上”、“侧”等，是为了清楚起见，具体参考附图，而不是为了限制本发明的范围。

本公开在其应用中不限于以下描述中阐述的或附图所示的构造细节和部件布置。本公开能够有其它实施例，并且能够以各种方式实践或执行。此外，本文使用的措辞和术语是为了描述的目的，不应被视为限制。本文使用的“包括”、“包含”、“具有”、“含有”、“涉及”及其变体是开放式的，即，“包括但不限于”。

本文公开的各种实施例可以实现为系统、方法或计算机程序产品。因此，各方面可以采取完全硬件实施例、完全软件实施例(包括固件、常驻软件、微代码等)或结合软件和硬件方面的实施例，这些方面在本文中通常被称为“电路”、“模块”或“系统”。并且，这些方面可以采取计算机程序产品的形式体现在具有计算机可读程序代码的一个或多个计算机可读介质中。

可以利用一个或多个计算机可读介质的任何组合。计算机可读介质可以是非暂时性计算机可读介质。非暂时性计算机可读介质可以是例如但不限于电子、磁、光、电磁、红外或半导体系统、装置或设备，或前述的任何合适的组合。非暂时性计算机可读介质的更具体的示例(非穷举列表)可以包括以下：具有一条或多条导线的电连接、便携式计算机磁盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或闪存)、光纤、便携式光盘只读存储器(CD-ROM)、光存储设备、磁存储设备或前述的任何合适的组合。包含在计算机可读介质上的程序代码可以使用任何适当的介质来传输，包括但不限于无线、有线、光纤电缆、射频RF等，或前述的任何合适的组合。

用于执行本公开各方面的操作的计算机程序代码可以用一种或多种编程语言的任意组合来编写。此外，这种计算机程序代码可以使用单个计算机系统或者通过彼此通信的多个计算机系统来执行(例如，使用局域网(LAN)、广域网(WAN)、互联网等)。虽然前面的各种特征是参照流程图和/或框图描述的，但是本领域普通技术人员将理解，流程图和/或框图的每个框以及流程图和/或框图中的框的组合可以由计算机逻辑实现(例如，计算机程序指令、硬件逻辑、两者的组合等)。通常，计算机程序指令可以被提供给通用计算机、专用计算机或其它可编程数据处理设备的处理器。此外，使用处理器执行这样的计算机程序指令产生了能够执行流程图和/或框图块中指定的功能或动作的机器。

计算机系统的一个或多个部分可以分布在耦合到通信网络的一个或多个计算机系统上。例如，如上所述，确定可用功率容量的计算机系统可以远离系统管理器。这些计算机系统也可以是通用计算机系统。例如，本公开的各个方面可以分布在被配置为提供服务(例如，服务器)，或者作为分布式系统的一部分来执行整体任务。例如，本公开的各个方面可以在客户端服务器的或多层的系统上执行，该系统包括分布在一个或多个服务器系统中的组件，这些组件根据本公开的各个实施例执行各种功能。这些组件可以是通过通信网络(例如，互联网)使用通信协议(例如，TCP/IP)通信的可执行代码、中间代码(例如，IL)或解释代码(例如，Java)，例如一个或多个数据库服务器可用于存储诸如预期功耗的设备数据，其在设计与本公开的实施例相关联的布局时使用。

应当理解，本公开不限于在任何特定系统或系统的组上执行。此外，应当理解，本公开不限于任何特定的分布式架构、网络或通信协议。

本公开的各种实施例可以使用面向对象的编程语言来编程，例如SmallTalk、Java、C++、Ada或C#(C-Sharp)。也可以使用其它面向对象的编程语言。或者，可以使用函数、脚本和/或逻辑编程语言，如BASIC、Fortran、Cobol、TCL或Lua。本公开的各个方面可以在非编程环境中实施(例如，分析平台或以HTML、XML或其它格式创建的文档，当在浏览器程序的窗口中查看时，呈现图形用户界面(GUI)的各方面或执行其它功能)。本公开的各方面可以被实施为编程或非编程元件或者它们的任意组合。

附图中的流程图和框图例示了本公开的各种实施例的可能实施方式的架构、功能和/或操作。在这点上，流程图或框图中的每个框可以表示模块、代码段或代码部分，其包括用于实施指定(多个)逻辑功能的一个或多个可执行指令。还应当注意，在一些替代实施例中，块中提到的功能可以不按附图中提到的顺序发生。例如，连续示出的两个框实际上可以基本上同时执行，或者这些块有时可以以相反的顺序执行，这取决于所涉及的功能。还将注意到，框图和/或流程图例示的每个框以及框图和/或流程图例示中的框的组合可以由执行指定功能或动作的基于专用硬件的系统或者专用硬件和计算机指令的组合来实施。

应当理解，以上描述旨在说明性而非限制性的。通过阅读和理解以上描述，许多其它实施例是显而易见的。尽管本公开描述了具体的示例，但是应当认识到，本公开的系统和方法不限于本文描述的示例，而是可以在所附权利要求的范围内进行修改来实施。因此，说明书和附图被认为是说明性而不是限制性的。因此，本公开的范围应当参照所附权利要求以及这些权利要求所赋予的等同物的全部范围来确定。