背景技术：
在协作环境中，云服务可以用于针对用户提供计算、软件、数据访问、和存储服务，以及其它用途。例如，服务可以包括目录服务、通信服务、协作服务、云存储服务、生产力服务背景框架、即时消息传送服务、和/或社交网络服务，以及其它示例。服务可以包括与实体(例如，用户、分组、文件、邮件、日历、联系人、和/或对话)相关联的数据，其中每个服务可以包括应用编程接口(api)。
在常规网络环境中，服务的api可能不被连接和/或可能在网络的不同端点处被托管。因此，为了获得与多个服务相关联的实体相关的数据，可能需要请求客户端单独地向服务的api中的每一个api提交查询，以从服务获得相应的实体相关的数据，并且然后确定如何聚合所获得的实体相关的数据。
技术实现要素：
提供本发明内容以便以简化的形式来引入在下面的具体实施方式中进一步描述的概念的选择。本发明内容并非旨在唯一地识别所要求保护的主题的关键特征或必要特征，也并非旨在作为对确定所要求保护的主题的范围的辅助。
实施例涉及分布式服务实体和关联的聚合与联合。可以从客户端接收针对实体相关的数据的请求，其中该请求可以包括实体类型和一个或多个实体属性。可以从多个服务中确定包括与实体类型和实体属性中的至少一个相关联的数据的一个或多个服务。可以向一个或多个服务提交查询以获得数据，可以对从一个或多个服务接收到的对查询的响应进行聚合，并且可以将经聚合的响应发送到客户端。
通过阅读以下具体实施方式并且阅览相关联的附图，这些特征和优点以及其它特征和优点将是显而易见的。应当理解，前面的总体描述和下面的具体实施方式都是解释性的，并且不限制所要求保护的方面。
附图说明
图1包括其中可以对分布式服务实体和关联进行聚合与联合的示例网络环境；
图2示出了用于对分布式服务实体和关联进行聚合与联合的示例系统；
图3包括示出了用于对分布式服务实体和关联进行聚合与联合的聚合器服务与一个或多个其它服务之间的交互的概念图。
图4是其中可以实现根据实施例的系统的联网环境；
图5是可以用于对分布式服务实体和关联进行聚合与联合的示例通用计算设备的框图；以及
图6示出了根据实施例的用于对分布式服务实体和关联进行聚合与联合的方法的逻辑流程图。
具体实施方式
如上面简要描述的，与网络相关联的多个服务(例如，云)可以包括与实体(例如，用户、分组、文件、邮件、日历、联系人、和/或对话)相关联的数据，其中每个服务可以包括应用编程接口(api)。聚合器服务可以在网络的单个端点处托管服务的相应api。服务可以使用相应api的元数据文档来声明并注册与服务中的每一个服务相关联的实体，以建立被公布给聚合器服务的服务中的每一个服务的api模式。响应于接收到来自客户端的针对实体相关的数据的请求，聚合器服务可以针对所建立的api模式来解析该请求，以便确定与实体相关的数据相关联的适当服务以向其提交查询，以及确定在将响应发送回请求客户端之前如何对从服务接收到的对查询的响应进行聚合。另外，因为服务的相应api在网络的单个端点处被托管，所以实体(包括从服务的数据之间的导航中推断出的实体之间的关联和关系)可以被联合。
在下面的具体实施方式中，参考形成其一部分的附图，并且其中通过图示的方式示出了具体实施例或示例。可以对这些方面进行组合，可以利用其它方面，并且可以在不脱离本公开的精神或范围的情况下进行结构改变。因此，以下具体实施方式不应被认为是限制意义的，并且本发明的范围是由所附权利要求及其等同内容限定的。
虽然将在与在个人计算机上的操作系统上运行的应用程序相结合地执行的程序模块的一般上下文中描述一些实施例，但是本领域技术人员将认识到，各方面还可以与其它程序模块组合地实现。
一般地，程序模块包括例程、程序、组件、数据结构、以及执行特定任务或实现特定抽象数据类型的其它类型的结构。此外，本领域技术人员将理解，可以利用以下其它计算机系统配置来实践实施例，包括：手持设备、多处理器系统、基于微处理器的或可编程的消费电子设备、小型计算机、大型计算机、以及可类比的计算设备。实施例还可以在其中任务由通过通信网络链接的远程处理设备来执行的分布式计算环境中实践。在分布式计算环境中，程序模块可以位于本地存储器存储设备和远程存储器存储设备两者中。
一些实施例可以被实现为计算机实现的过程(方法)、计算系统，或者实现为诸如计算机程序产品或计算机可读介质的制品。计算机程序产品可以是可由计算机系统读取并且对计算机程序进行编码的计算机存储介质，计算机程序包括用于使计算机或计算系统执行(多个)示例过程的指令。计算机可读存储介质是计算机可读存储器设备。计算机可读存储介质可以例如经由易失性计算机存储器、非易失性存储器、硬盘驱动器、闪存驱动器、软盘、或压缩盘、以及可类比的硬件介质中的一个或多个来实现。
在整个说明书中，术语“平台”可以是用于对分布式服务实体和关联进行聚合与联合的软件组件与硬件组件的组合。平台的示例包括但不限于在多个服务器上执行的被托管的服务、在单个计算设备上执行的应用、以及可类比的系统。术语“服务器”一般指代典型地在联网环境中执行一个或多个软件程序的计算设备。然而，也可以将服务器实现为在被视为网络上的服务器的一个或多个计算设备上执行的虚拟服务器(软件程序)。下面提供了关于这些技术和示例操作的更多细节。
图1包括其中可以对分布式服务实体和关联进行聚合与联合的示例网络环境。如图100所示，聚合器服务102可以由一个或多个服务器104托管。服务器104中的至少一个服务器可以是处理服务器，其可操作以用于执行通信接口106和经联合的聚合层108，以及聚合器服务102的其它组件。在一些实施例中，服务器104中的至少另一服务器可以是存储服务器，其被配置为对包括与例如聚合器服务102相关联的数据的一个或多个数据存储库进行管理。如本文所描述的，聚合器服务102的组件可以实现为软件、硬件、或其组合。
通信接口106可以促进通过一个或多个网络(例如，网络130)在聚合器102、多个客户端110、以及多个服务120之间进行通信。客户端110可以包括用户关联的设备，例如，智能电话112、台式计算机114、膝上型计算机116、平板计算机118、车载计算机、或可穿戴计算设备、以及其它类似的设备。服务120可以是网络130的基于云的服务，并且可以包括目录服务122、协作服务124、云存储服务126、通信服务128、生产力服务背景框架、即时消息传送服务、和/或社交网络服务、以及其它服务。服务120可以包括与一个或多个实体(例如，用户、分组、文件、邮件、日历、联系人、和/或对话)相关联的数据，并且服务中的每一个服务可以包括api。
经联合的聚合层108可以被配置为在网络130的单个端点处托管服务120的api。服务120可以通过声明式实体模型将服务120的数据与其相关联的实体注册到经联合的聚合层108。例如，服务120可以使用与服务120的相应api相关联的元数据文档来声明并注册实体，以建立服务120中的每一个服务的api模式。然后，可以将服务120中的每一个服务的api模式公布给经联合的聚合层108。通过采用声明式实体模型，聚合器服务102可以支持分布式读取和分布式写入两者，以及添加/创建操作和删除操作。另外，因为服务的相应api在网络的单个端点处被托管，所以经联合的聚合层108可以被配置为对实体进行联合，包括从服务的数据之间的导航中推断出的实体之间的关联和关系。
聚合器服务102还可以包括用于对服务120的api的版本化以及聚合器服务102本身的版本化进行处理的机制。服务120中的每一个服务可以独立地演进其api模式并且定义api契约。服务120中的每一个服务可以包括用于指定由服务在请求中公布的api版本的应用。聚合器服务102可以将api的公共公开版本公开，其提取出单独的服务104的api契约，以使得最新公开的api版本可以是例如由服务120公布给聚合器服务102的最新版本的编译。
在一些实施例中，经联合的聚合层108还可以采用共同同意和授权模型来基于由客户端110提供的单个令牌对一个或多个服务120中的每一个服务进行认证。令牌可以指示一组一个或多个作用域(scope)，以及与作用域中的每一个作用域相关联的功能。如果来自该组的作用域中的一个或多个作用域在经联合的聚合层108与服务120之间共享，则可以授权对来自服务120的一组数据进行访问。作用域可以包括日历、联系人、邮件、用户简档、文件、目录、以及所有站点，其中每个作用域可以包括相关联的读取、写入、发送、管理、和/或完全控制函数。例如，如果令牌指示“目录.读取(directory.read)”或“目录.读取写入(directory.readwrite)”作用域，则可以授权对来自目录服务122、协作服务124、通信服务128、和/或生产力服务背景框架的数据进行读取访问和写入访问。
在示例实施例中，经联合的聚合层108可以通过通信接口106通过网络130来接收来自客户端110中的一个客户端的针对实体相关的数据的请求。例如，该请求可以包括实体类型和一个或多个实体属性。经联合的聚合层108还可以接收来自请求客户端的令牌，其中经联合的聚合层108可以基于令牌来对服务120中的一个或多个服务进行认证。
响应于接收到请求，经联合的聚合层108可以采用声明式实体模型来确定包括实体相关的数据的适当服务以向其提交查询，以及确定在将响应发送到请求客户端之前如何对从服务120接收到的对查询的响应进行聚合。例如，通过针对服务120中的每一个服务的所建立的api模式来解析请求，经联合的聚合层108可以确定包括与实体类型和/或实体类型的属性相关联的数据的服务120中的一个或多个服务。
经联合的聚合层108可以通过通信接口106通过网络130向所确定的服务中的每一个服务提交查询以获得数据。在一些示例中，经联合的聚合层108可以基于与所确定的服务的相应api相关联的元数据文档的注释来生成对所确定的服务中的每一个服务的查询。例如，注释可以指示相应的所确定的服务是主机服务还是可扩展服务，其中包括与实体类型相关联的数据的服务是该实体类型的主机服务，而包括与一个或多个实体属性相关联的数据的服务是对实体类型进行扩展的服务。注释还可以指示可用的访问(例如，读取和写入)以及哪些操作被允许，例如，添加/创建、更新、以及删除操作。在一些实施例中，可以生成查询，以使得查询指示实体属性将由所确定的服务中的每一个服务在查询响应中返回。在其它实施例中，可以生成查询，以使得查询使得服务中的每一个服务能够选择要在查询响应中返回的默认实体属性。
然后，经联合的聚合层108可以被配置为对通过通信接口106通过网络130从所确定的服务接收到的对查询的响应进行聚合。在一些实施例中，经联合的聚合层可以被配置为对从每个服务接收到的响应进行检查，并且转换响应，以使得响应可以是一致的以进行聚合。然后，经联合的聚合层108可以被配置为通过通信接口106通过网络130将经聚合的响应发送到请求客户端。
在一些实施例中，可以跨所确定的服务连同聚合器服务102对请求、查询、以及查询响应进行跟踪。例如，使用连同请求一起的“客户端-请求-id”报头，查询客户端可以连同请求一起发送跟踪标识，和/或经联合的聚合层108可以生成“客户端-请求-id”报头。该报头可以包括在由经联合的聚合层108生成/提交给所确定的服务的每个查询中，并且还可以包括在从所确定的服务接收到的对查询的响应中。
在常规网络环境中，各种网络服务的api可能不被连接和/或可能在网络的不同端点处被托管。因此，为了获得与多个服务相关联的实体相关的数据，请求客户端可能需要单独地向服务的api中的每一个api提交查询，以从服务获得相应的实体相关的数据，并且然后确定如何对所获得的实体相关的数据进行聚合。如在上面的实施例中所描述的，聚合器服务102可以移除请求客户端单独地向服务120中的每一个提交查询以获得与实体相关联的数据的需求，这可以降低处理负载并且提高客户端的处理速度，因为获得所请求的数据需要更少的对查询的生成和随后传输。
另外，由于请求客户端不再必须单独地向服务120中的每一个提交查询，所以与请求客户端相关联的用户可以不再必须确定如何针对所存储的一组属性和/或数据来对服务120中的每一个服务进行查询，这改进了可用性并且提高了用户效率。此外，通过采用共同同意和授权模型，聚合器服务102可以移除对使用由请求客户端提供的分离的令牌来单独地对服务120中的每一个服务进行认证的需求，这可以进一步降低处理负载并且提高处理速度，这是因为可以提供一个令牌并且将其用于对服务120中的每一个服务进行认证。
此外，聚合器服务102可以确定如何对在来自服务的响应中返回的数据进行聚合，以使得可以实现强大的导航，进一步针对与请求客户端相关联的用户改进可用性，因为这些用户不再需要确定如何对响应于提交的每个单独的查询而获得的数据进行聚合。例如，聚合器服务102可以被配置为引用协作服务中的在两个用户之间共享的一个或多个文件，导航到最新修改的文件，确定哪个用户最后修改了文件，并且然后确定用户的管理者。
如本文描述的实施例解决了从由不能被人管理的联网计算和基于云的服务创建的非常大规模的操作中引起的需求。本文描述的动作/操作不仅仅是计算机的使用，还是作为软件的直接成果的系统用作服务(例如，与大量用户、客户端、以及服务相结合地提供的聚合器服务102)的解决结果。
图2示出了用于对分布式服务实体和关联进行聚合与联合的示例系统。如图200所示，聚合器服务202可以由一个或多个服务器204来托管。服务器204中的至少一个可以是处理服务器，其可操作以用于执行通信接口206和经联合的聚合层208，以及聚合器服务202的其它组件。
通信接口206可以促进通过网络在聚合器服务202、多个客户端(例如，客户端210)、以及多个服务220之间进行通信。服务220可以是网络的基于云的服务，并且可以包括目录服务222、协作服务224、云存储服务226、通信服务228、生产力服务背景框架、即时消息传送服务、和/或社交网络服务、以及其它示例。服务220可以包括与一个或多个实体相关联的数据，并且服务220中的每一个可以包括api。
经联合的聚合层208可以被配置为在网络的单个端点处托管服务220的api。服务220可以通过声明式实体模型将服务220的数据与其相关联的实体注册到经联合的聚合层208。例如，服务220可以使用与服务220的相应api相关联的元数据文档来声明并注册实体，以建立服务220中的每一个服务的api模式。然后，可以将服务220中的每一个服务的api模式公布给经联合的聚合层208。响应于接收到来自客户端210的针对实体相关的数据的请求，经联合的聚合层208可以采用声明式实体模型来确定服务220中的哪些服务与实体相关的数据相关联，以使得可以向这些服务提交一个或多个查询(例如，230和234)，以及确定如何对从服务接收到的对查询的响应(例如，232和236)进行聚合以供发送到客户端210。
声明式实体模型可以被定义为一组实体类型以及关联类型和/或导航属性。实体类型可以包括例如用户、分组、文件、邮件、日历、联系人、和/或对话。每个实体类型可以由服务来主管。例如，实体类型e可以由服务a来主管。主管实体类型的服务能够接受post/delete(发布/删除)请求。因此，当接收到与实体类型e相关联的客户端请求时，经联合的聚合层208可以向主管实体类型e的服务a的端点提交具有post/delete请求的查询。
在一些示例中，实体类型可以包含由服务而不是主机服务主管的属性和关联。例如，实体类型e可以由服务a主管，并且当服务b公布api模式(该api模式声明其关于实体e主管的一组属性)时，实体类型e可以由服务b来扩展。在一些示例中，一个服务可以主管给定实体类型的给定属性。因此，当接收到包含由服务而不是实体类型主机主管的实体属性的客户端请求时，经联合的聚合层208可以向主管相应实体类型的服务的端点以及向主管相应属性的其它服务的端点提交查询，以写入经扩展的一组属性。对实体进行扩展的其它服务可以负责管理其主管的相应属性，然而，这些服务可能不支持针对该实体类型的post/delete请求。
另外，由于服务的相应api在网络的单个端点处被托管，所以经联合的聚合层208可以被配置为对实体进行联合，包括从服务220的数据之间的导航中推断出的实体之间的关联和关系。例如，声明式实体模型中的导航属性可以支持从由一个服务主管的实体类型到由相同服务或另一服务主管的实体类型的导航。导航属性定义可以包括名称、源实体类型、以及目标实体类型。主管导航属性的服务可以主管或者可以不主管源和/或目标实体类型。例如，导航属性可以由服务a来主管，其中被指定为源的实体由服务b来主管并且被指定为目标的实体由服务c来主管。
在第一示例中，“管理者”可以是由目录服务222主管的导航属性，其中“用户”实体类型是关系中的源和目标。“用户”实体类型还可以由目录服务222来主管。因此，导航属性以及其源实体和目标实体可以由目录服务222来主管。在第二示例中，“喜欢的分组”可以是由通信服务228主管的导航属性。“用户”实体类型可以是源并且“分组”实体类型可以是目标，其中源和目标两者都可以由目录服务222来主管。在一些实施例中，如果服务主管描述第一实体与第二实体之间的关系的导航属性，则相同的服务可以主管描述第二实体与第一实体的相反关系的导航属性。然而，这并不总是准确的。例如，通信服务228可以不对“组”实体类型声明导航属性以描述喜欢给定分组的用户(喜欢的分组的相反关系)。因此，在所有情况下，导航属性可以被明确地定义。例如，“直接报告(directreports)”可以是描述管理者与管理者的直接报告的相反关系的导航属性，其在实体模型中被明确地定义。
经联合的聚合层208可以与用于匹配部分实体表示的规范化标识符相关联，以便能够针对经扩展的实体类型合并结果，以及对表示给定导航属性的源和目标的实体进行定位。标识符跨服务可以是一致的。对于可以声明复合键作为标识符的实体类型，服务220可以向聚合器服务202提供代替键以用于“键作为区段(key-as-segment)”表示。例如，对于与协作服务224相关联的文件api，标识符可以是{<容器全局唯一标识符(containerguid)>，<完整文件路径>}的元组。标识符可以表示为级联值，其被转化以确保安全的统一资源定位符(url)表示，其中特殊字符的位置以标识符本身的值被编码。url可以特定于聚合器服务202的api，其中url中的命名空间区段可以对应于服务的租期。在一些示例中，还可以定制命名空间。
返回到图200，在示例场景中，经联合的聚合层208可以通过通信接口206接收来自客户端210的针对实体相关的数据的请求212。请求212可以包括实体类型和一个或多个实体属性。例如，请求可以指示“用户”实体类型。响应于接收到请求，经联合的聚合层208可以采用声明式实体模型来确定服务220中的哪些服务包括实体相关的数据以向其提交查询，以及确定在将响应发送到客户端210之前如何对从服务220接收到的对查询的响应进行聚合。例如，通过针对服务中的每一个服务的所建立的api模式来解析请求212，经联合的聚合层208可以确定包括与“用户”实体类型相关联的数据的服务220中的一个或多个服务。例如，经联合的聚合层208可以确定目录服务222和通信服务228包括与“用户”实体类型相关联的数据。目录服务222可以是“用户”实体类型的主机，并且通信服务228可以通过对例如包括在请求212内的“用户”实体类型的一个或多个实体属性进行管理来扩展“用户”实体类型。
在一些实施例中，经联合的聚合层208还可以采用共同同意和授权模型214来基于由客户端210连同请求212一起提供的单个令牌216来对一个或多个服务220中的每一个服务进行认证。令牌可以指示一组作用域，以及针对每个作用域的相关联的函数，其中在经联合的聚合层208与服务220之间共享的作用域可以授权对一组数据进行访问。作用域可以包括日历、联系人、邮件、用户简档、文件、目录、以及所有站点，并且每个作用域可以包括例如相关联的读取、写入、发送、管理、和/或完全控制函数。在一个实施例中，可以定义一组全局唯一共享作用域，以针对经联合的聚合层208和服务220形成数据的逻辑分区，其中，服务220的工作负载基于服务220公开的数据类型来理解这些共享作用域的子集。例如，通信服务228可以理解日历、联系人、邮件、以及用户简档作用域。当客户端210准许通过提供指示特定作用域的令牌216来访问特定作用域时，其转化为客户端210准许在该特定作用域下公开其数据的服务220中的任一个服务进行访问。换言之，客户端210同意对数据的该逻辑分区进行访问，而不论其来自何处。例如，如果客户端210准许对“邮件.读取(mail.read)”、“邮件.写入(mail.write)”、以及“邮件.发送(mail.send)”作用域进行访问，则客户端准许通信服务228和/或生产力服务背景框架进行访问。
经联合的聚合层208可以通过通信接口206分别向目录服务222和通信服务228提交查询230和234，以获得“用户”实体类型相关的数据。在一些示例中，经联合的聚合层108可以基于与目录服务222和通信服务228的相应api相关联的元数据文档中的注释来生成查询230和234。例如，注释可以指示目录服务222和通信服务228分别是主机服务和可扩展服务，针对每一个指示对数据的可用访问(例如，读取和写入)，以及针对每一个指示哪些操作是被允许的，例如，添加/创建、更新、以及删除操作。
在一些实施例中，可以跨目录服务222和通信服务228连同聚合器服务202来跟踪查询230和234。例如，使用连同请求一起的“客户端-请求-id”报头，客户端210可以连同请求212一起发送跟踪标识。如果客户端210不包括伴随请求的跟踪标识，则经联合的聚合层208可以生成“客户端-请求-id”报头。该报头可以是由经联合的聚合层208生成并分别向目录服务222和通信服务228提交的查询230和234中的每一个的一部分，并且还可以包括在分别来自目录服务222和通信服务228的查询响应232和236中。
经联合的聚合层208可以被配置为对通过通信接口206分别从目录服务222和通信服务228接收到的查询响应232和236进行聚合。在一些实施例中，例如，经联合的聚合层208可以被配置为对查询响应232和236进行检查并且转换查询响应232和236，以使得它们可以是一致的以进行聚合。然后，经联合的聚合层208可以被配置为通过通信接口206向请求客户端210发送经聚合的响应238。可以将任何一致性和/或错误连同经聚合的响应238一起报告给客户端210。
图3包括示出了用于对分布式服务实体和关联进行聚合与联合的聚合器服务与一个或多个其它服务之间的交互的概念图。
如图300所示，网络的各种服务304可以各自包括应用编程接口(api)306。服务304可以是基于云的服务，并且可以包括目录服务、通信服务、协作服务、云存储服务、即时消息传送服务、和/或社交网络服务、以及其它示例。服务304还可以包括生产力服务背景框架308，其它服务中的每一个服务可以与生产力服务背景框架308相关联。例如，生产力服务背景框架308可以注册在服务304的租户下作为任何其它第一方服务。服务304可以包括与实体(例如，用户、分组、文件、邮件、日历、联系人、和/或对话)相关联的数据。聚合器服务302可以在网络的单个端点处托管api306，并且服务304可以通过声明式实体模型将服务304中的每一个服务的数据与其相关联的实体注册到聚合器服务302。例如，服务304可以使用与服务304的相应api相关联的元数据文档来声明并注册实体，以建立服务304中的每一个服务的api模式，该api模式可以被公布给聚合器服务302。因此，实体(包括从数据之间的导航中推断出的和/或由生产力服务背景框架308确定的实体之间的关联和关系)可以被联合并且呈现为实体的连接图形。
在示例实施例中，包括通信接口和经联合的聚合层、以及其它组件的聚合器服务302可以被配置为对其属性和/或数据存储在服务304中的实体进行聚合与联合。例如，与“对话”实体相关联的属性可以主要存储在通信服务中，并且因此，通信服务可以是“对话”实体的主机。附加的服务(例如，即时消息应用和社交网络应用)还可以包括关于给定对话的一些属性。因此，这些附加的服务可以通过管理其它属性来扩展“对话”实体。
响应于来自客户端的针对给定对话的请求，聚合器服务302可以被配置为确定服务304中的哪些服务具有与“对话”实体类型和/或一个或多个“对话”实体属性相关联的数据，例如，通信服务、即时消息应用、以及社交网络应用，如在上面的示例中描述的。聚合器服务302可以向通信服务、即时消息应用、以及社交网络应用提交查询，以获得与“对话”实体类型和/或“对话”实体属性相关联的数据。在一些示例中，聚合器服务302可以生成查询，以指定要在对查询的响应中返回的“对话”实体属性。在其它示例中，聚合器服务302可以不指定要在响应中返回的任何属性，并且可以使得服务能够选择要在对查询的响应中返回的默认的一组属性。然后，聚合器服务302可以对在响应中返回的数据进行聚合，并且向请求客户端发送经聚合的数据。
为了实现上述聚合器服务302与服务304之间的高级别交互，服务304可能需要兼容的端点。为了使端点兼容，可以针对服务建立以下特征：服务304可以托管兼容的内容类型，接受全局请求结构，支持用于所有实体类型的规范化标识，提供一致的错误语意并请求跟踪/校正，以及支持共同同意和授权模型，如在以下段落中所描述的。
服务304中的每一个服务可以支持“应用/atom+xml”内容类型以及变型(例如，“最小元数据”和“冗长(verbose)”)，以使得当对响应进行聚合时聚合器服务302能够具有一致的内容类型。如果客户端请求“应用/atom+xml”内容类型，则聚合器服务302可以完成“应用/json”内容类型的必要对话。
关于接受全局请求结构，具有实体的冗长元数据的来自服务304的查询响应可以包含表示实体的唯一可寻址url的标识属性。为了容纳可能不符合寻址方案的服务304中的一个或多个服务，标识属性可以在聚合器服务302中被重写。在一个示例中，聚合器服务302可以从一个或多个服务304的api模式中取回键属性，并且使用键属性来生成标识属性。在另一示例中，聚合器服务302可以包括作为报头的公开端点名，其指导服务304基于服务304已知的相应api模式来生成标识属性。
另外，可以使用请求、查询、以及查询响应等中的“客户端-请求-id”报头来跨服务304连同聚合器服务302对请求和随后的查询进行跟踪。可以支持跨服务304一致的规范化标识符以匹配部分实体表示，以便能够针对经扩展的实体类型合并结果，以及对表示给定导航属性的源和目标的实体进行定位，如结合图2详细讨论的。
此外，服务304可以支持由聚合器服务302采用的共同同意和授权模型。共同同意和授权模型可以基于由客户端连同请求一起提供的单个令牌来对服务304进行认证。令牌可以指示一组作用域以及与作用域中的每一个作用域相关联的函数。如果该组中的一个或多个作用域在聚合器服务302与服务304之间共享，则可以授权对服务304的一组数据进行访问。作用域可以包括日历、联系人、邮件、用户简档、文件、目录、以及所有站点，其中每个作用域可以包括例如相关联的读取、写入、发送、管理、和/或完全控制函数。在一个实施例中，可以定义一组全局唯一共享作用域，以针对服务304形成数据的逻辑分区，其中，服务304的工作负载基于服务304公开的数据类型来理解这些共享作用域的子集。在一些实施例中，生产力服务背景框架308可以被注册在服务的租户之下作为任何其它第一方服务，其中生产力服务背景框架308可以公开对应于所支持的实体中的每一个实体的一组作用域。
在示例同意和授权过程中，第三方应用310可以请求允许一组作用域使用关于作用域查询参数的列表。在用户同意之后，可以基于所请求的作用域针对第三方应用310来记录同意准许。例如，对于全局唯一共享作用域，同意准许可以在支持其作为[应用，生产力服务背景框架，作用域，用户]的任何资源的作用域上被记录，其中资源字段被忽略，并且生产力服务背景框架用作用于替换资源字段的通配符。对于其它作用域，同意准许可以基于支持作用域作为[应用，资源，作用域，用户]的资源针对应用被记录。如果没有任何资源由令牌指定，则生产力服务背景框架308可以表明资源和以下作用域被添加到令牌：同意准许针对所请求的资源的应用被记录，同意准许针对共享作用域的应用被记录(例如，资源＝“*”)，以及同意准许针对共享作用域被记录而不管资源(其中这些同意准许可以被更新以将资源设置为“*”)，以用于实现现有应用的向后兼容。
图1至图3中提供的示例以特定服务、设备、组件、以及配置示出。实施例不限于根据这些示例的环境。分布式服务实体和关联的聚合与联合可以在采用更少或附加的服务、设备、组件、以及配置的环境中实现。例如，本文描述的服务和应用可以在云场景中实现，其中一些或所有邮箱可以托管在云中，而其它可以托管在本地。此外，图1至图3中示出的示例服务、设备、组件、以及配置可以以与其它值类似的方式使用本文描述的原理来实现。
图4是其中可以实现根据实施例的系统的联网环境。被配置为对分布式服务实体和关联进行聚合与联合的聚合器服务可以经由在一个或多个服务器406上执行的软件(例如，托管的应用)来实现。平台可以通过(多个)网络410与在单独的计算设备(例如，个人数字助理(pda)401、台式计算机402、膝上型计算机403、智能电话404、或平板电脑405(“客户端设备”))上的客户端应用进行通信。
客户端设备401-405用于访问由托管的服务或应用提供的功能。聚合器服务可以被配置为接收针对实体相关的数据的客户端请求，实体相关的数据包括实体类型和一个或多个实体属性。聚合器服务可以被配置为从多个服务中确定包括与实体类型和/或一个或多个实体属性相关联的数据的一个或多个服务，并且向所确定的服务提交查询以获得数据。然后，聚合器服务可以被配置为对从服务接收到的对查询的响应进行聚合，以及将经聚合的响应发送到客户端。聚合器服务可以直接或通过数据库服务器412将与实体相关的数据相关联的数据存储在(多个)数据存储库414中。
(多个)网络410可以包括服务器、客户端、互联网服务提供方、以及通信介质的任何拓扑。根据实施例的系统可以具有静态拓扑或动态拓扑。(多个)网络410可以包括安全网络(例如，企业网络)、不安全网络(例如，无线开放网络或互联网)。(多个)网络410还可以协调通过其它网络(例如，pstn或蜂窝网络)进行通信。(多个)网络410提供本文所描述的节点之间的通信。通过示例而非限制的方式，(多个)网络410可以包括无线介质，例如，声学、rf、红外、以及其它无线介质。
计算设备、应用、数据源、以及数据分布系统的许多其它配置可以对服务实体和关联进行聚合与联合。此外，图4讨论的联网环境仅用于说明目的。实施例不限于示例应用、模块、或过程。
图5和相关联的讨论旨在提供对通用计算设备的简要总体描述，该通用计算设备可以用于对分布式服务实体和关联进行聚合与联合。
例如，计算设备500可以用作服务器、台式计算机、便携式计算机、智能电话、专用计算机、或类似设备。在示例基本配置502中，计算设备500可以包括一个或多个处理器504，以及系统存储器506。存储器总线508可以用于在处理器504与系统存储器506之间进行通信。在图5中，基本配置502由内部虚线内的那些组件示出。
取决于期望的配置，处理器504可以是任何类型的，包括但不限于微处理器(μp)、微控制器(μc)、数字信号处理器(dsp)、或其任何组合。处理器504可以包括一个或多个级别的高速缓存(例如，分级高速缓存存储器512)、一个或多个处理器核心514、以及寄存器516。示例处理器核心514可以(各自)包括算术逻辑单元(alu)、浮点单元(fpu)、数字信号处理核心(dsp核心)、或其任何组合。示例存储器控制器518也可以与处理器504一起使用，或者在一些实现方式中，存储器控制器518可以是处理器504的内部部分。
取决于期望的配置，系统存储器506可以是任何类型的，包括但不限于易失性存储器(例如，ram)、非易失性存储器(例如，rom、闪速存储器等)、或其任何组合。系统存储器506可以包括操作系统520、聚合器服务522、以及程序数据524。聚合器服务522可以包括经联合的聚合层526，其可以是聚合器服务522的集成组件，或者是独立组件。聚合器服务522的经联合的聚合层526可以被配置为接收针对包括实体类型和一个或多个实体属性的实体相关的数据的客户端请求，确定包括与实体类型和/或一个或多个实体属性相关联的数据的一个或多个服务，以及向服务提交查询以获得数据。然后，聚合器服务522的经联合的聚合层526可以被配置为对从服务接收到的对查询的响应进行聚合，以及将经聚合的响应发送到客户端，如本文所描述的。程序数据524可以包括实体相关的数据528以及其它数据，如本文所描述的。
计算设备500可以具有附加的特征或功能，以及用于促进在基本配置502与任何期望的设备和接口之间进行通信的附加的接口。例如，总线/接口控制器530可以用于促进经由存储接口总线534在基本配置502与一个或多个数据存储设备532之间进行通信。数据存储设备532可以是一个或多个可移除存储设备536、一个或多个不可移除存储设备538、或其组合。举几个为例，可移除存储设备和不可移除存储设备的示例包括磁盘设备(例如，软盘驱动器和硬盘驱动器(hdd))、光盘驱动器(例如，压缩盘(cd)驱动器或数字通用盘(dvd)驱动器、固态驱动器(ssd))、以及磁带驱动器。示例计算机存储介质可以包括易失性和非易失性的、可移除和不可移除的介质，其以任何方法或技术实现以用于存储信息(例如，计算机可读指令、数据结构、程序模块、或其它数据)。
系统存储器506、可移除存储设备536、以及不可移除存储设备538可以是计算机存储介质的示例。计算机存储介质包括但不限于ram、rom、eeprom、闪速存储器、或其它存储器技术，cd-rom、数字通用盘(dvd)、固态驱动器、或其它光存储装置，磁带盒、磁带、磁盘存储装置、或其它磁存储设备，或者可以用于存储期望的信息并且可以由计算设备500存取的任何其它介质。任何这样的计算机存储介质可以是计算设备500的一部分。
计算设备500还可以包括接口总线540，以用于促进经由总线/接口控制器530从各种接口设备(例如，一个或多个输出设备542、一个或多个外围接口544、以及一个或多个通信设备546)到基本配置502进行通信。示例输出设备542中的一些包括图形处理单元548和音频处理单元550，其可以被配置为经由一个或多个a/v端口552与各种外部设备(例如，显示器或扬声器)进行通信。一个或多个示例外围接口544可以包括串行接口控制器554或并行接口控制器556，其可以被配置为经由一个或多个i/o端口558与诸如输入设备(例如，键盘、鼠标、笔、语音输入设备、触摸输入设备等)的外部设备或其它外围设备(例如，打印机、扫描仪等)进行通信。示例通信设备546包括网络控制器560，网络控制器560可以被布置为促进经由一个或多个通信端口564通过网络通信链路与一个或多个其它计算设备562进行通信。一个或多个其它计算设备562可以包括服务器、计算设备、以及可类比的设备。
网络通信链路可以是通信介质的一个示例。通信介质典型地可以由计算机可读指令、数据结构、程序模块、或调制数据信号中的其它数据(例如，载波或其它传输机制)实施，并且可以包括任何信息递送介质。“调制数据信号”可以是其特性中的一个或多个特性以使得信息编码在信号中的方式来设置或改变的信号。通过示例而非限制的方式，通信介质可以包括有线介质(例如，有线网络或直接有线连接)以及无线介质(例如，声学、射频(rf)、微波、红外(ir)、以及其它无线介质)。如本文所使用的术语计算机可读介质可以包括存储介质和通信介质两者。
计算设备500可以被实现为通用或专用服务器、主机、或包括以上功能中的任一个的类似计算机的一部分。计算设备500还可以被实现为包括膝上型计算机和非膝上型计算机配置的个人计算机。
示例实施例还可以包括用于对分布式服务实体和关联进行聚合与联合的方法。这些方法可以以包括本文描述的结构的任何数量的方式来实现。一种这样的方式可以是通过在本公开中描述的类型的设备的机器操作。另一可选方式可以是，方法的单独的操作中的一个或多个操作与执行操作中的一些操作的一个或多个的人类操作者相结合地执行，而其它操作可以由机器来执行。这些人类操作者不需要彼此同地协作，而是每个人类操作者仅利用执行程序的一部分的机器。在其它实施例中，人类交互可以是例如通过预先选择的标准而自动进行的，该预先选择的标准可以是机器自动化的。
图6示出了根据实施例的用于对分布式服务实体和关联进行聚合与联合的方法的过程600的逻辑流程图。过程600可以在服务器或其它系统上实现。示例系统可以包括网络和聚合器服务，其中网络包括多个服务，多个服务包括与一个或多个实体相关联的数据，聚合器服务在单个网络端点处托管服务的相应api。服务可以通过声明式实体模型将服务中的每一个服务的数据与其相关联的实体注册到聚合器服务。例如，服务可以使用与服务的相应api相关联的元数据文档来注册实体，以建立服务中的每一个服务的api模式，该api模式被公布给聚合器服务。
过程600开始于操作610，在该处聚合器服务的经联合的聚合层可以被配置为通过聚合器服务的通信接口来接收针对实体相关的数据的客户端请求。请求可以包括实体类型和一个或多个实体属性。实体类型可以包括例如用户、分组、文件、邮件、日历、联系人、和/或对话。
在操作620处，经联合的聚合层可以被配置为确定多个服务中的包括与实体类型和/或实体属性相关联的数据的一个或多个服务。例如，经联合的聚合层可以针对多个服务中的每一个服务的api模式来解析请求，以确定包括与请求内的实体类型和/或实体属性相关联的数据的服务。
在操作630处，经联合的聚合层可以通过通信接口向被确定包括与实体类型和/或实体属性相关联的数据的服务提交查询，以获得实体相关的数据。查询可以是基于与服务中的每一个服务的相应api相关联的元数据文档内的注释来生成的。在一些实施例中，查询可以指示实体类型的属性将由服务中的每一个服务在查询响应中返回。在其它实施例中，查询可以使得服务中的每一个服务能够选择要在响应中返回的默认实体属性。
在操作640处，经联合的聚合层可以被配置为对通过通信接口从服务接收到的对查询的响应进行聚合。在一些示例中，经联合的聚合层可以被配置为对从每个服务接收到的响应进行检查和转换，以使得响应可以是一致的以进行聚合。在操作650处，经联合的聚合层可以通过通信接口将经聚合的响应发送到客户端。
在过程600中包括的操作是用于说明性目的的。分布式服务实体和关联的聚合与联合可以通过具有更少或附加的步骤的类似过程来实现，以及以与使用本文描述的原理的操作不同的顺序来实现。本文中描述的操作可以由在一个或多个计算设备上操作的一个或多个处理器、一个或多个处理器核心、专用处理设备、和/或通用处理器、以及其它示例来执行。
根据一些示例，描述了被配置为对分布式服务实体和关联进行聚合与联合的计算设备。示例计算设备可以包括被配置为存储指令的存储器和处理器，该处理器与存储器耦合并且被配置为执行聚合器服务。聚合器服务可以包括通信接口，该通信接口被配置为促进聚合器服务、多个客户端、以及多个服务之间的通信，其中服务中的每一个服务均包括与一个或多个实体相关联的数据。聚合器服务还可以包括经联合的聚合层，该经联合的聚合层被配置为接收来自客户端的针对实体相关的数据的请求，其中请求包括实体类型和一个或多个实体属性，并且从服务中确定包括与实体类型和/或实体属性相关联的数据的一个或多个服务。经联合的聚合层还可以被配置为向一个或多个服务提交查询以获得数据，对从服务接收到的对查询的响应进行聚合；以及将经聚合的响应发送到客户端。
在另外的示例中，经联合的聚合层还可以被配置为在单个网络端点处托管服务的api，其中通过声明式实体模型将服务中的每一个服务的数据与其相关联的实体注册到单个网络端点，以建立服务中的每一个服务的api模式。经联合的聚合层还可以被配置为：采用声明式实体模型，通过针对服务中的每一个服务的所建立的api模式解析请求，来从服务中确定包括与实体类型和/或实体属性相关联的数据的一个或多个服务。经联合的聚合层还可以被配置为采用用于对服务的api和聚合器服务的api的版本化进行处理的机制，其中聚合器服务的api的公共公开版本可以是被公布给聚合器服务的服务的api的最新版本的编译。
在另外的示例中，经联合的聚合层还可以被配置为采用共同同意和授权模型来基于由客户端提供的令牌对服务中的每一个服务进行认证，其中令牌指示一组一个或多个作用域，以及与作用域中的每一个作用域相关联的函数。服务可以包括目录服务、通信服务、协作服务、云存储服务、生产力服务背景框架、即时消息传送服务、和/或社交网络服务。实体类型可以包括用户、分组、文件、电子邮件、日历、联系人、和/或对话。
根据一些实施例，描述了用于对分布式服务实体和关联进行聚合与联合的方法。示例方法可以包括接收来自客户端的针对实体相关的数据的请求，其中请求包括实体类型和一个或多个实体属性，以及从多个服务中确定包括与实体类型和/或实体属性相关联的数据的一个或多个服务。示例方法还可以包括向服务提交查询以获得数据，对从服务接收到的对查询的响应进行聚合，以及将经聚合的响应发送到客户端。
在其它实施例中，使用与服务的相应的api相关联的元数据文档，使得服务中的每一个服务的数据与其相关联的一个或多个实体能够被注册到单个网络端点，以建立服务中的每一个服务的api模式。确定包括与实体类型和/或实体属性相关联的数据的一个或多个服务还可以包括针对服务中的每一个服务的所建立的api模式来解析请求。
在另外的实施例中，基于与服务中的每一个服务的相应api相关联的元数据文档的注释，可以生成对服务中的每一个服务的查询。可以生成查询，以使得查询指示实体属性将在对查询的响应中被返回。可以生成查询，以使得服务能够在对查询的响应中返回默认的一组实体属性。对从服务接收到的对查询的响应进行聚合包括：在接收到对查询的响应之后检查对查询的响应，以及基于检查来转换对查询的响应以使得对查询的响应是一致的以进行聚合。
根据一些实施例，描述了计算机可读存储器设备，其上存储有用于对分布式服务实体和关联进聚合与联合的指令。示例指令可以包括接收来自客户端的针对实体相关的数据的请求，其中请求包括实体类型和一个或多个实体属性，以及通过采用声明式实体模型针对服务中的每一个服务的所建立的api模式解析请求，来从多个服务中确定包括与实体类型和/或实体属性相关联的数据的一个或多个服务。示例指令还可以包括向服务提交查询以获得数据，对从服务接收到的对查询的响应进行聚合，以及将经聚合的响应发送到客户端。
在其它实例中，被确定包括与实体类型相关联的数据的服务可以是该实体类型的主机服务，而被确定包括与一个或多个实体属性相关联的数据的服务可以是对实体类型进行扩展的服务。请求可以包括请求的报头中的跟踪标识，其在查询的报头和对查询的响应的报头中被保持。
上述说明书、示例、以及数据提供了对实施例的构成的制造和使用的完整描述。虽然已经以特定于结构特征和/或方法动作的语言对主题进行了描述，但是应当理解，所附权利要求中限定的主题不一定限于上述特定特征或动作。相反，上述特定特征和动作作为实现权利要求和实施例的示例形式而公开。