具体实施方式

在本文中描述的技术和机制提供了有线网络组件，其使对基于网络的用户接口中数据的访问和更新简化且合理化。许多用户接口依赖于网络组件元数据规范(meta-specification)，其本身是自定义元素规范、影子文档对象模型(DOM)规范、超文本标记语言(HTML)模板规范和ECMAScript(ES)模块规范的组合。这四种规范组合起来，允许开发者定义他们自己的HTML标签(即自定义元素)，其样式被封装和隔离(即影子DOM)、可以多次重新标记(模板)、并且具有一致的集成到应用程序中的方式(即ES模块)。

在常规系统中，网络组件用于呈现静态信息。即，基于网络的用户接口包括开发者定义的自定义网络组件，并且在创建时，该网络组件被填充到在客户端机器的浏览器中呈现的用户接口中，并且具有从服务器获取到的静态信息。与DOM中的大多数元素一样，网络组件可被手动编辑以包括不同的信息。然而，常规的自定义网络组件不支持基于对用户接口或服务器上其他地方的数据所做的更改的自动更新。

在本文中描述的技术和机制提供可动态更新的有线网络组件。根据各实施方案，有线网络组件可以提供可扩展的框架。例如，可以编写HTML来提供布局。HTML可以包括在有线网络组件中，该组件还可以包括用于访问和更新数据值以包括在经渲染的HTML中的编程逻辑。开发者然后可以扩展框架以提供用于生成自定义用户接口部分的自定义有线网络组件。然后可以动态地更新经渲染的用户接口中的有线网络组件，而不需要开发者指定用于执行这种更新的程序指令。

根据各实施方案，有线网络组件图可用于动态地更新用户接口中的数据。例如，每个有线网络组件可包括一个或多个数据字段，且每个数据字段可与可经由相应API获取的数据值相关联。每个有线网络组件、数据字段和API可以表示为有线网络组件图中的节点。然后可以使用有线网络组件图来指导数据访问。例如，可以使用有线网络组件图来整合API请求的数量并避免获取重复数据。

在一些实施方案中，有线网络组件图可用于在渲染用户接口之后动态地更新数据。例如，可以通过将值从API推送到客户端机器来生成更新的数据值。作为另一个示例，更新的数据值可以通过从API向客户端机器拉取值来生成。作为又一示例，可以通过从用户接口中的别处接收信息来生成更新的数据值。例如，用户接口可以显示双并排的工作场所。该接口的一侧然后可以提供诸如当前在接口的可滚动部分中呈现的页码的信息。在更新数据值之后，然后可以将数据值提供给其中包括该数据值的任何网络组件。

在特定实施方案中，声明性框架可以提供静态分析。例如，服务器可以分析用户接口以预测客户端机器可能需要的数据值。作为另一个示例，服务器可以分析用户接口以预测要包括在动态生成的用户接口中的组件定义。作为又一示例，客户端机器可以构建包括在用户接口中的组件图。

在一些实现方式中，组件级逻辑可以提供数据字段的组件级视图。例如，可以针对包括日期值的所有组件更新日期值。然而，对于不同的网络组件，相同的日期值可能会以不同的方式呈现(例如，“5月1日”、“2005年5月1日”或“2005年5月1日下午2:30”)。

在特定实施方案中，可以在渲染用户接口之后从用户接口添加和/或移除有线网络组件。例如，可以将有线网络组件添加到DOM树中。然后可以更新相应的有线网络组件图以包括附加节点，使得访问与有线网络组件相关联的数据以提供给有线网络组件从而在用户接口中显示。作为另一个示例，可以从DOM树中移除有线网络组件。然后可以更新相应的有线网络组件图以根据需要移除节点从而避免下载不必要的数据。

根据各实施方案，在本文中参考基于网络的用户接口描述了一些技术和机制。此外，在本文中描述的一些技术和机制通过采用基于网络的用户接口的示例来说明。然而，在本文中描述的技术和机制适用于各种各样的计算上下文，包括除基于网络的用户接口之外的上下文。例如，虽然用户接口组件可被称为有线网络组件，但是这样的组件不需要在基于网络的环境中实现。实际上，与有线网络组件相关的技术和机制可适用于任何用户接口上下文，其中用户接口远离用户接口中呈现的一些或全部数据的源。

考虑最终用户“Alex”的情况。Alex正在使用常规的用户接口，该用户接口呈现与存储在服务器上的数据库记录相关联的客户关系管理(CRM)信息。当Alex在用户接口的某一部分中更改诸如客户联系人姓名等数据时，该更改不会反映在用户接口的另一部分中。此外，当同事在Alex也正在查看某记录期间更新该记录时，同事的更新不会反映在Alex的用户接口中。这种情况会造成混乱、竞争条件和不准确的数据。

现在代替地假设Alex正在使用根据在本文中描述的技术和机制的实施方案配置的用户接口。当Alex在用户接口的某个部分中更改诸如客户联系人姓名等数据时，该更改会反映在用户接口的其他地方。例如，在详细记录窗口中更新客户联系人姓名会导致客户联系人姓名在客户联系人列表中也发生更改。类似地，当Alex也正在查看某记录期间同事更新该记录时，同事的更新会迅速反映在Alex的用户接口中。例如，当同事另一台计算机上更新Alex也正在工作的联系人记录以包括新的邮寄地址时，该更改会反映在Alex的用户接口中，而无需刷新用户接口。

图1展示了根据一个或多个实施方案执行的有线网络组件生命周期方法100的示例。根据各实施方案，方法100可以在包括与客户端机器通信的服务器的系统处执行，诸如图2中所示的系统200。

一个或多个有线网络组件在102处定义。在一些实现方式中，有线网络组件可以包括自定义HTML元素和相关联的计算机编程代码(例如，JavaScript)，其被配置用于在经由HTML实现的图形用户接口中呈现。根据各实施方案，有线网络组件是特定类型的有线网络组件，其包括用于在客户端和/或服务器侧自动执行诸如自动更新数据等操作的附加逻辑。

在一些实现方式中，定义有线网络组件可涉及创建和存储计算机编程代码，该计算机编程代码指定与有线网络组件相关联的一个或多个属性。有线网络组件的一种此类属性可以是与用于获取和/或存储信息的应用程序接口(API)相关联的标识符和/或地址。另一种此类属性可以是一个或多个数据字段的标识，经由API为其获取数据值。除了要访问的信息之外，有线网络组件定义还可以指定诸如与该信息相关联的一个或多个过滤、处理和/或更新程序的信息。在整个申请中讨论了关于用于定义自定义有线网络组件的过程的附加细节，诸如关于图3中所示的方法300。

在104处，包括在请求的用户接口中的一个或多个有线网络组件在服务器处被预处理。根据各实施方案，客户端机器可以向服务器传送对用户接口的请求。服务器然后可以提供客户端创建用户接口所需的计算编程指令。此外，服务器可以评估所请求的用户接口以标识和预处理包括在用户接口中的任何有线网络组件。该预处理可以包括诸如构建有线网络组件的数据依赖图(data dependency graph)和/或基于有线网络组件的分析来预取客户端机器可能请求的数据等操作。在整个申请中讨论了与预处理一个或多个有线网络组件有关的附加细节，诸如关于图4中所示的方法400。

在特定实施方案中，包括在用户接口中的一个或多个有线网络组件可以不被预处理。也就是说，在某些情况下，预处理可以提高从客户端机器到服务器的后续请求的性能。然而，即使在没有服务器侧预处理的情况下，在本文中描述的技术和机制也起作用。服务器侧预处理可能由于多种原因中的任何一个而被省略，诸如稀缺的计算资源、有线网络组件存在特别复杂的配置、确定预处理可能产生最小性能增益、和/或确定有线网络组件与无法经由与服务器相关联的计算系统进行访问的外部API相关联。

在106处在客户端机器处创建所请求的用户接口。根据各实施方案，创建所请求的用户接口可以涉及执行以下操作：诸如在多个有线网络组件之间构建数据依赖图、从一个或多个API获取有线网络组件的信息、处理所获取的信息、和/或提供所获取的信息以用于填充一个或多个用户接口组件。在整个申请中讨论了关于构建所请求的用户接口的附加细节，诸如关于图5中所示的方法500。在整个申请中讨论了关于构建依赖图的附加细节，诸如关于图6中所示的依赖图的示例600。

该一个或多个有线网络组件在108处更新。在一些实现方式中，只要有线网络组件在客户端机器处进行呈现的用户接口中扮演活动角色，它就可以继续更新。更新有线网络组件可能涉及以下操作：诸如接收从服务器推送的数据、从服务器拉取数据、将数据推送到服务器、响应来自服务器的数据拉取请求、基于在用户接口中其他处所做的更改来更新本地数据、和/或任何其他合适的操作。在整个申请中讨论了关于更新一个或多个有线网络组件的附加细节，诸如关于图7中所示的方法700。

在110处销毁客户端机器处的用户接口。根据各实施方案，整个用户接口可被一次性销毁。替代地，当不再需要诸如某特定有线网络组件的用户接口组件时，可以将其单独地销毁。例如，当用户接口更新为不再包括有线网络组件时，有线网络组件可被销毁。销毁有线网络组件可涉及以下操作：诸如更新依赖图以移除有线网络组件、断开与用于访问与有线网络组件相关联的数据的API的连接、和/或任何其他合适的操作。在整个申请中讨论了关于更新一个或多个有线网络组件的附加细节，诸如关于图8中所示的方法800。

图2展示了根据一个或多个实施方案配置的客户端-服务器通信系统200中的组件布置的示例。客户端-服务器通信系统200可以至少部分地经由云中的一个或多个组件来实现，诸如图9、图10A、图10B和图11中所示的系统。客户端-服务器通信系统200可被配置为实现在本文中描述的一种或多种方法的全部或一部分，诸如图1、图2、图4、图5、图7和图8中所示的方法。

客户端-服务器通信系统200包括服务器202。服务器202包括数据库系统204、有线网络组件分析引擎206、用户API A 208、用户API B 210、用户API C 212、和通信接口214。在一些实现方式中，数据库系统204可以存储任何合适的信息。例如，数据库系统204可以存储客户关系管理(CRM)信息、社交网络信息、或其他这类数据。数据库系统204可以包括单个数据库或潜在地许多不同的数据库。数据库系统204可被布置在集中式结构中或以分布式配置布置。在整个申请中讨论了有关数据库系统的附加细节，诸如关于图9、图10A和图10B。

在一些实施方案中，有线网络组件分析引擎206可以执行与有线网络组件有关的各种操作中的一个或多个操作。例如，有线网络组件分析引擎206可以支持创建和/或供应有线网络组件。这样的操作可涉及与有线网络组件的定义相关联的那些操作(如关于图3所讨论的)和/或有线网络组件的预处理(如关于图4所讨论的)。

根据各实施方案，用户API 208至212可被客户端机器用来从服务器202获取信息。例如，用户API可被用于从数据库系统204中获取信息。不同的API可用于获取不同类型的信息。例如，一个API可用于访问数据库中的记录，而另一个API可用于访问社交网络信息流。每个API可以定义一个协议用于访问信息。以这种方式，信息访问的内部细节可以从客户端机器的操作中抽象出来。

在一些实现方式中，通信接口214可以支持服务器202与一个或多个远程机器(诸如客户端机器)之间的、经由诸如网络230等网络的通信。网络230可以包括任何合适的通信网络。例如，网络230可以包括用于与服务器202进行通信的互联网和/或一个或多个专用网络。

根据各实施方案，用户API D 220和API E 222是外部API，经由服务器202不可访问。在一些配置中，这些外部API中的一个或两个可以是受与服务器相关联的服务提供商控制。替代地，外部API可以受完全不同的实体控制。例如，客户端机器可以与同Twitter相关联的一个外部API进行通信以访问Twitter订阅源，并且可以与另一个外部API通信以访问Facebook订阅源。即，在本文中描述的技术和机制可用于提供被配置为访问各种用户API(在负责提供有线网络组件的服务器202内部或外部)的有线网络组件。

客户端机器252包括通信接口260、处理器254、存储器模块256、显示设备258和网络应用程序实例272。根据各实施方案，客户端机器252可以是台式计算机、膝上型计算机、平板计算机、移动电话或任何其他合适的计算设备。

在一些实施方案中，网络应用程序实例272可以包括用于经由网络访问信息的图形用户接口。网络应用程序实例272可以是至少部分地基于由服务器202提供的计算机编程语言指令生成的。经由网络应用程序实例272访问的信息可由服务器202、由一个或多个外部信息源、或由其某种组合提供。网络应用程序实例272可以在网络浏览器中、在本地应用程序中或以任何其他合适的方式呈现。

网络应用程序实例272包括有线网络组件处理引擎282。根据各实施方案，有线网络组件处理引擎282可用于根据在本文中描述的技术和机制生成、更新和销毁有线网络组件。有线网络组件处理引擎可以包括诸如组件构建模块274、事件处理模块276、组件销毁模块278和数据服务280之类的组件。

在一些实现方式中，组件构建模块274可被配置为创建有线网络组件，如关于图3中所示的方法300所讨论的。事件处理模块276可被配置为更新有线网络组件，如关于图7中所示的方法700所讨论的。组件销毁模块278可被配置为销毁有线网络组件，如关于图8中所示的方法800所讨论的。数据服务280可被配置为管理有线网络组件处理引擎282与一个或多个外部数据源(诸如用户API)之间的通信。

出于说明的目的，客户端-服务器通信系统202仅包括单个客户端机器、单个服务器和有限数量个组件(诸如用户API)。然而，在实践中，系统实际上可以包括任意数量的客户端机器、API或其他此类组件。此外，图2中所示的驻留在服务器202上的组件实际上可以位于不同的物理机器上和/或分布在多个物理机器上。

图3展示了根据一个或多个实施方案执行的用于定义有线网络组件的方法300的示例。方法300可用于定义新的有线网络组件以提供给请求用户接口的客户端设备。

在302处接收定义有线网络组件的请求。根据各实施方案，可以在与客户端机器通信的服务器处接收请求。例如，可以在与客户端机器252通信的有线网络组件分析引擎206处接收请求。

在一些实现方式中，该请求可以由计算服务客户端的开发者生成，该计算服务客户端经由与服务器相关联的按需计算服务系统访问计算服务。替代地，该请求可由开发者在计算服务系统本身处生成。

在304处确定有线网络组件的标识符。根据各实施方案，可以基于用户输入来确定标识符。替代地或附加地，系统可以自动确定标识符的全部或一部分。标识符可以提供一种机制，通过该机制来存储和获取与有线网络组件相关联的信息。例如，当创建图形用户接口的实例时，可在计算编程语言代码内使用标识符以调用有线网络组件。

在306处标识与有线网络组件相关联的API。在一些实现方式中，可以基于用户输入来确定API。替代地或附加地，系统可以自动确定API。API可以标识用于访问与有线网络组件相关联的信息的端点。例如，API可被指定为诸如URI、IP地址或其他此类信息的地址。作为另一个示例，API可被指定为随后可以链接至用于访问信息的地址的标识符。例如，API可被指定为“Twitter”，服务器维护从API标示符到用于访问API的实际地址的映射。

在308处标识要经由API访问的一个或多个数据字段。在一些实现方式中，数据字段可以用作与API通信时的参数。例如，当创建有线网络组件的实例时，客户端可以向API传送诸如对象标识符和数据字段标识符等信息以请求接收与对象标识符相关联的数据字段值。

在特定实施方案中，有线网络组件可以与多于一个的API和/或一组数据字段相关联。例如，有线网络组件可以包括经由外部社交网络订阅源访问的一些数据字段和经由与服务器相关联的API访问的其他数据字段。

在310处确定与有线网络组件相关联的呈现逻辑。根据各实施方案，呈现逻辑可以包括用于组合、过滤或以其他方式处理经由API接收的原始数据以在用户接口中呈现的计算机编程代码。例如，一个数据字段可以是与用户帐户相关联的电话号码。呈现逻辑可用于格式化电话号码以包括将自动拨打电话号码的链接。作为另一个示例，另一个数据字段可以是包括日期和时间信息的时间戳。呈现逻辑可用于提取和格式化日期信息以在用户接口的不需要时间戳的时间部分的部分中呈现。

在312处，有线网络组件被存储以用于基于请求进行获取。根据各实施方案，有线网络组件可以存储在可经由有线网络组件分析引擎206访问的存储介质上。例如，有线网络组件可以存储在数据库系统204中。存储的信息可以包括在方法300中标识的任何或所有信息、以及任何其他合适的信息。

图4展示了根据一个或多个实施方案执行的用于预处理有线网络组件的方法400的示例。根据各实施方案，方法400可以在与客户端机器通信的服务器处执行。例如，当客户端机器向服务器传送访问用户接口的请求时，方法400可以在服务器处执行。

在402处接收向客户端机器提供用户接口的请求。该请求可以从诸如图2中所示的实例272之类的网络应用程序实例内的引擎282之类的处理引擎传送。该请求可以标识诸如要呈现的特定用户接口之类的信息。此外，该请求可以提供上下文信息，诸如一个或多个对象标识符、用户标识符或其他此类信息，以用于标识要包括在用户接口中的信息和/或其他内容。

在404处标识用户接口定义信息。根据各实施方案，用户接口定义信息可以包括一个或多个标记语言文件、有线网络组件定义、或包括在所请求的用户接口中的其他此类计算机编程代码。例如，用户接口请求可以包括一个或多个标识符，诸如URI。服务器可以分析这些标识符以标识在响应用户接口请求和构建用户接口中涉及的计算机编程代码。

在406处确定是否为用户接口构建有线网络组件图。在特定实施方案中，不需要在服务器处构建有线网络组件图。例如，服务器可以向客户端机器提供用户接口定义而无需构建有线网络组件图。客户端机器然后可以在没有来自服务器的进一步输入的情况下构建有线网络组件图。

在一些实现方式中，在406处做出的确定可以至少部分地基于服务器处计算资源的可用性而做出。例如，如果服务器有丰富的可用资源，则可以至少部分地在服务器处构建有线网络组件图。相反，如果服务器具有有限的可用计算资源，则可以不在服务器处构建有线网络组件图。例如，如果服务器正在处理大量用户接口请求或被占用，则可以做出不构建有线网络组件图的决定。

在一些实现方式中，可以至少部分地基于用户接口的复杂性来做出在406所做的确定。例如，如果估计为用户接口构建有线网络组件图涉及过多的时间，则可以确定不在服务器处构建该图。

当确定要在服务器处构建用户接口的有线网络组件图时，在408处构建用户接口的有线网络组件图。根据各实施方案，有线网络组件图至少部分地基于在404处标识的用户接口定义信息来构建。可以通过分析包括在用户接口中的不同有线网络组件定义并且然后将组件及其数据字段添加到图中来构建有线网络组件图。

在一些实施方案中，用于构建有线网络组件图的服务器侧程序可与在客户端机器上执行的操作大量重叠。关于图5所示的方法500讨论了关于有线网络组件图的构建的附加细节。

在一些实现方式中，在408处构建的有线网络组件图可以至少部分地通过获取预先确定的有线网络组件图信息来构建。例如，可以为动态用户接口构建静态图部分并存储以用于基于请求进行获取。然后，通过从获取到的静态部分开始，可以更快地构建针对动态用户接口的特定请求的有线网络组件图。

在410处确定用于从一个或多个API获取数据值的一个或多个输入参数。根据各实施方案，一个或多个输入参数可以基于分析在402处接收的请求来确定。例如，该请求可以包括一个或多个对象标识符或用于构建用户接口的其他API参数。

在一些实现方式中，一个或多个输入参数可以基于与请求源相关联的信息来标识。例如，可以从与用户账户相关联的客户端机器请求用户接口，并且然后可以选择该用户账户的标识符作为一个或多个API的输入参数。

在一些实施方案中，可以通过应用预测模型来确定一个或多个输入参数。预测模型可以基于一个或多个静态或动态规则、一个或多个机器学习算法、和/或任何其他合适的预测程序来实现。例如，对用户接口的连续请求可用于训练深度学习程序，以通过将最终与每个请求一起访问的数据用作结果来标识可能被请求的数据。

在一些实施方案中，预测模型还可用于预测有线网络组件图的一个或多个部分。例如，要包括在用户接口中的特定有线网络组件可能取决于动态确定的值。此类值可被预测并用作标识一个或多个有线网络组件、数据值、API或有线网络组件图的其他此类部分的输入。

在412处，基于数据依赖图从一个或多个API获取一个或多个数据值。根据各实施方案，可以通过将在410处确定的输入参数中的一个或多个传送到数据依赖图中指定的适当API来获取一个或多个数据值。在一些配置中，以这种方式查询的API可能限于与服务器所在的计算环境相关联的API，诸如API 208、API 210和API 212。替代地或附加地，可以查询诸如图2中所示的API 220和API 222之类的外部API。

在414处，所请求的用户接口的用户接口信息被传送到客户端机器。根据各实施方案，传送的信息可以包括在操作404处标识的用户接口定义信息。当在服务器处构建有线网络组件图时，也可以传送与有线网络组件图相关联的信息。这样的信息可以包括在操作408处构建的有线网络组件图的一些或全部和/或在操作412处获取的数据值的一些或全部。

在特定实施方案中，有线网络组件图可以仅部分地在服务器处构建。例如，服务器可试图预测诸如数据字段和/或数据值之类的输入参数，但无法以合理的确定性程度预测某些此类值。例如，可以在客户端侧动态地确定数据值。在这种情况下，服务器能够获取用户接口的而非其他的一些数据值，或者可以完全省略操作412。

作为另一个示例，服务器可以将有线网络组件图构建限制为静态部分。例如，服务器可基于静态有线网络组件定义构建有线网络组件图，但在412处不获取数据值或将有线网络组件的实例包括在有线网络组件图中。

作为又一示例，服务器可以例如通过标识图中的切割点并移除切割点任一侧的图部分来调整有线网络组件图。在这样一种方法中，可以基于预测为对用户立即或几乎立即可见的用户接口的一部分来确定切割点。然后，能够获取可能较早观看的部分，而可以移除切割点的另一侧上可能较晚观看或根本不观看的部分。以这种方式，可以减少服务器侧处理时间和传送到客户端机器的信息量，从而减少从请求到用户接口的呈现之间消逝的时间。

在特定实施方案中，部分构建的图可被传送到客户端机器并在客户端机器处完成。例如，服务器可以构建图的一个或多个静态部分，而客户端可以完成图的一个或多个动态部分。作为另一示例，服务器可以预测一个或多个参数并基于这些预测获取一个或多个数据值，并且客户端可以确定最终呈现在用户接口中的实际数据值。在这种情况下，客户端在某些情况下可能会接收到它不需要的数据，该数据可被丢弃。

根据各实施方案，可以以不同于所示顺序的顺序执行图4中所示的一个或多个操作。例如，在408处构建有线网络组件图可以发生于在410处预测一个或多个输入参数之后。替代地，此类操作可以交错和/或并行执行。例如，输入参数的预测可以作为构建有线网络组件图的过程的一部分来执行。

图5展示了根据一个或多个实施方案执行的用于创建有线网络组件的方法500的示例。根据各实施方案，可以执行方法500以在客户端机器处生成包括一个或多个有线网络组件的用户接口。

在502处接收生成用户接口的请求。根据各实施方案，请求可被接收作为网络应用程序的实例化和/或操作的一部分。例如，服务器可以与客户端机器通信以提供用于经由服务器访问信息的网络应用程序。网络应用程序可以作为本机应用程序或经由网络浏览器呈现。客户端和服务器可以执行以下操作：诸如建立通信会话、认证用户账户、确定账户权限、以及提供用于在客户端机器处生成用户接口的指令。

在504处实例化针对用户接口的有线网络组件图。根据各实施方案，有线网络组件图表示一个或多个API、数据值和/或有线网络组件之间的关系。最初，有线网络组件图可能是空的。然后，随着有线网络组件被处理，该图可被更新以包括一种或多种关系。

在506处选择用户接口中包括的有线网络组件。根据各实施方案，可以以任何合适的顺序选择有线网络组件，诸如按照外观顺序或随机选择。在特定实施方案中，当在用户接口中首次实例化有线网络组件时，可以选择该有线网络组件进行分析。

在508处确定有线网络组件的标识符。在510处标识与有线网络组件相关联的API。在512处标识要经由API获取的一个或多个数据字段。根据各实施方案，可以通过访问如关于图3所讨论的那样构建的有线网络组件定义来标识或确定这样的信息。有线网络组件定义可以由服务器例如响应于在502处接收到的生成用户接口的请求而提供给客户端机器。

在514处，基于所标识的信息来更新有线网络组件图。根据各实施方案，更新有线网络组件图可涉及向图中添加任何尚未存在的节点。例如，如果在508处确定的有线网络组件标识符、在510处标识的API、或在512处标识的一个或多个数据字段尚未存在于有线网络组件图中，则可以将缺失的标识符作为节点添加到图中。

在一些实现方式中，更新有线网络组件图可涉及添加组件之间的关系。例如，如果它们尚未存在，则可以添加将在510处标识的API连接到在512处标识的一个或多个数据字段中的每个的链接。作为另一示例，如果它们尚未存在，则可以添加将在512处标识的一个或多个数据字段连接到在508处确定的有线网络组件标识符的链接。

在516处确定是否选择附加的有线网络组件进行分析。如关于操作506所讨论的，可以以任何合适的顺序选择有线网络组件。

当没有附加的有线网络组件可用于实例化时，则在518处获取与数据字段相关联的一个或多个数据值。在一些实现方式中，该一个或多个数据值可由数据服务280经由网络访问适当的API以获取数据值来获取。这种通信可以涉及数据服务提供信息，诸如认证数据、对象标识符信息、数据字段标识符信息、或根据相应API的任何其他合适的数据。

在特定实施方案中，图5中所示的操作可以以不同于所示出的顺序来执行。例如，可以随着构建有线网络组件来获取数据值。例如，操作518可以在操作512之后执行。作为另一示例，例如如果新有线网络组件被添加到构建的用户接口，可以在构建用户接口之后执行有线网络组件创建方法的全部或部分。

图6展示了根据一个或多个实施方案配置的数据服务280的示例。数据服务包括如关于方法400和/或500所讨论的构建的有线网络组件图604。有线网络组件图604包括用户API A 606、用户API B 608和用户API C 610，数据字段612、614、616、618、620和622，以及有线网络组件624、626、628、630、632和634。节点之间的连接代表依赖关系。

在一些实施方案中，有线网络组件图604可用于执行与更新数据值相关的操作。例如，有线网络组件图604可用于标识从单个用户API获取的一组数据字段，即使这些数据字段由不同的有线网络组件使用。例如，数据字段614由有线网络组件624、626和628使用，而数据字段612仅由有线网络组件624使用。然而，数据字段614和数据字段612都与同一个用户API相关联，并且在同一个API调用中获取两者可以提高效率。

作为另一示例，数据字段612仅由有线网络组件624使用。因此，如果有线网络组件624被禁用，则数据字段612可能不再需要更新。

在一些实现方式中，如结合图4所讨论的，有线网络组件图的全部或一部分可在服务器处被构建为静态表示。然后可以使用静态表示来预取数据以传送到客户端机器用于构建用户接口。

根据各实施方案，如关于图5所讨论的，有线网络组件图的全部或一部分可在客户端机器处被构建为动态表示。客户端侧动态构建可以使用在服务器处构建的静态表示作为输入。替代地，可以独立于或代替服务器侧静态有线网络组件图来创建客户端侧动态构建。

图6展示了根据一个或多个实施方案配置的数据服务280的示例。数据服务280包括有线网络组件图604。有线网络组件图604包括用户API 606、用户API 608和用户API610，数据字段612、614、616、618、620和622，以及有线网络组件624、626、628、630、632、634、636、638，以及有线网络组件实例640、642、644。根据各实施方案，数据服务280可以包括图6中未示出的一个或多个组件，诸如用于创建或编辑有线网络组件图604的组件。

在一些实现方式中，每个用户API都是一个网络端点，通过它可以访问数据。例如，用户API可能允许访问数据库对象、静态或动态文件、或信息流。在一个示例中，用户API可以促进对Twitter订阅源、Salesforce Chatter订阅源、Facebook订阅源的访问。在另一个示例中，用户API可以公开用于访问数据库的查询接口。在又一个示例中，用户API可以提供对云存储库(诸如AWS S3或谷歌云存储)的访问。

在一些实施方案中，可以结合访问用户接口的服务器来提供用户API。例如，可以基于对包括网络服务器的计算系统的HTML请求来提供用户接口，并且该同一计算系统可以包括用于访问信息的一个或多个API。

在一些实施方案中，可以结合不同的服务器来提供用户API。例如，可以基于对包括网络服务器的计算系统的HTML请求来提供用户接口。然而，用于访问信息以包括在用户接口中的一个或多个API可以位于计算系统的外部。例如，用户接口可由Salesforce.com提供，而API可以是Twitter订阅源或Facebook订阅源。

在一些实施方案中，用户API可以是可公开访问的。例如，用于访问公共社交媒体订阅源的API可能不需要进行认证。对于这样的API，请求可能只需要指定这样的信息作为试图被获取的信息。

在一些实施方案中，用户API可能需要认证。例如，公开数据库查询接口的API可能需要认证，以确保请求帐户有权访问所请求的信息。这种认证可以通过证书、通过用户名和密码组合、经由预先建立的认证通信会话、或通过任何其他合适的机制来提供。

根据各实施方案，每个数据字段标识可经由API获取的信息。例如，数据字段可以标识数据库字段、数据库行、文件、来自社交网络订阅源的数据项、或其他此类信息。

在一些实现方式中，数据字段的获取可能需要附加的上下文信息。例如，数据字段可以标识数据库列，该列仅在也提供对象(即，行)标识符时才可以引用定义的值。作为另一个示例，社交网络订阅源的数据字段可以标识诸如评论文本之类的信息，该信息可以仅与诸如要从中获取文本的特定评论之类的其他信息相结合地指代定义的值。

在特定实施方案中，如果一个或多个有线网络组件访问不同上下文信息的相同数据字段，则可以存在多于一个的数据字段副本。例如，有线网络组件能够获取五个不同“联系人”对象的“名称”字段。在这种情况下，五个“名称”字段副本可以包括在与不同上下文信息相关联的图中。

在特定实施方案中，单个数据字段可以包括多于一个的上下文或实例信息副本。例如，“联系人”对象的“名称”字段可以与多于一个的对象标识符相关联，从而为每个对象标识符访问名称字段。

根据各实施方案，每个有线网络组件可以对应于根据在本文中描述的技术和机制配置的用户接口部分的定义。每个有线网络组件可以包括来自一个或多个数据字段的信息，数据字段可以各自可从相应的API获取。例如，有线网络组件632包括可从用户API C610获取的数据字段620和622，以及可从用户API B 608获取的数据字段618。

在一些实现方式中，不同的有线网络组件可以包括相同的数据字段。例如，有线网络组件632、630和628各自包括数据字段618，数据字段618可经由用户API B 608访问。通过构建有线网络组件图，这种重叠的数据访问可被揭示并用于整合查询以提高效率。例如，针对有线网络组件632、630和628中的每个可以进行单次请求，而不是单独地请求数据字段618，其结果可由有线网络组件632、630和628中的每个访问。以这种方式，可能潜在地会显着减少API请求的数量和网络流量的量。

在一些实现方式中，有线网络组件可以包括其他有线网络组件。例如，父有线网络组件626包括子有线网络组件636和638。子有线网络组件可以进而包括其他子有线网络组件。

根据各实施方案，有线网络组件图可以包括有线网络组件定义的一个或多个实例。例如，有线网络组件实例640、642和644是有线网络网组件定义630的实例。此类实例可以标识用于获取数据字段的上下文信息。例如，有线网络组件实例640、642和644中的每个可以对应于用于显示用户帐户对象的有线网络组件的不同实例。在特定实施方案中，可以在静态分析期间生成静态有线网络组件，其中静态有线网络组件的多个动态实例在运行时生成。

在一些实施方案中，有线网络组件图可以是不完整的或仅部分构建的。例如，服务器可以针对用户接口请求部分地构建有线网络组件图，并将部分地构建的图发送到客户端机器。然后，客户端机器可以继续基于客户端机器处的附加信息来构建有线网络组件图。

图6中所示的有线网络组件图604被呈现仅用于说明目的。实际上，有线网络组件图中包括的组件、字段和API取决于正被构建的特定用户接口。因此，为实际用户接口构建的有线网络组件图可能包括比图6中所示可能多得多的API、数据字段、有线网络组件和/或有线网络组件实例。

图7展示了根据一个或多个实施方案执行的用于更新有线网络组件数据的方法700的示例。方法700可以在具有一个或多个有线网络组件的用户接口被创建之后执行，如关于图5所讨论的。当用户接口处于活动状态时，用户接口中表示的数据可能会改变。例如，用户可以经由用户接口提供用户输入，该用户输入改变用户接口中一个或多个位置处的数据值。作为另一个示例，数据可以在服务器上改变。作为又一示例，动作或事件可以触发查询服务器以确定被更新的信息是否可用的请求。

在702处接收获取用户接口数据的请求。根据各实施方案，可以在启动用户接口时或在稍后的时间点接收请求。例如，可以基于事件或用户动作触发请求。作为另一示例，方法700可以针对活动用户接口持续运行。作为又一示例，只要用户接口被激活，方法700就可以运行。例如，用户可以经由不同的浏览器选项卡访问不同的用户接口。然后可以在用户选择相关用户接口所在的浏览器选项卡时启动方法700。

在704处标识与用户接口相关联的有线网络组件图。根据各实施方案，可以如关于图5中所示的方法500所讨论的那样创建有线网络组件图。这样的图可以指定API、数据值和有线网络组件之间的关系。图6中示出了此类图的示例。客户端机器可以维护该图，即使一个或多个有线网络组件被停用，如关于图8所讨论的。

在706处接收对包括在有线网络组件图中的数据字段的数据值进行更新的请求。根据各实施方案，可以以多种方式中的任何一种来生成请求。例如，用户接口的其中呈现数据值的一部分可以例如经由用户输入被更新以包括新的数据值。作为另一示例，服务器可以传送表明数据值已经在服务器上更新的消息。作为又一示例，用户可以提供表明或触发更新数据值的请求的用户输入。作为又一示例，运行时上下文可以提供信号。例如，将指定的数据值加载到网络浏览器用户接口中可能会触发更新不同数据字段的请求。

在708处更新数据值。根据各实施方案，更新数据值可涉及访问适当的API并提供诸如认证数据、对象实例标识符和数据字段标识符之类的信息。然后可以经由通信接口从API接收更新的数据值，并且在存储器中更新有线网络组件以包括被更新的数据值。

在一些实现方式中，更新数据值可涉及从客户端机器的不同位置获取数据。例如，用户接口可以并排呈现两个不同的视图。在该示例中，数据值可以表明与其他视图相关联的页码。作为另一个示例，数据值的不同组件视图可以显示在用户接口中的不同位置处。当这些组件视图之一被改变时(例如，经由用户输入)，与组件视图相关联的数据值可被更新。

在712处确定更新数据字段的更新组件视图。根据各实施方案，组件视图可以显示底层数据值的经过滤和/或经修改的视图。例如，地址的组件视图可以在映射应用程序中添加指向该地址的链接。可以通过根据更新的数据字段应用与有线网络组件相关联的数据字段组件逻辑来确定更新的组件视图。

在714处确定更新的数据字段的组件视图是否改变。根据各实施方案，可以通过分析和/或执行与组件视图相关联的逻辑来做出确定。如在本文中所讨论的，组件视图可以显示底层数据值的经过滤和/或经修改的视图。例如，名称的组件视图可以只显示首字母缩写而不是完整的名字和姓氏。在此示例中，如果名称已更新以更正拼写错误但未更改首字母缩写，则组件视图不会改变。作为另一个示例，时间戳可被修改为仅包括日期和小时分量，而不是年、日期、小时、分钟和秒分量。在此示例中，即使时间戳改变为不同的值，只要新时间戳的日期和小时与前一时间戳的日期和小时相同，时间戳的组件视图就不会改变。

在716处，更新的组件视图被传送到有线网络组件。根据各实施方案，将更新的组件视图传送到有线网络组件可涉及用于更新用户接口的任何合适的操作。例如，可以在存储器中更新被更新的组件视图数据值，使得有线网络组件可以访问该数据值。作为另一示例，DOM树的一个或多个元素可被修改以包括更新的组件视图。

根据各实施方案，文档对象模型(DOM)是跨平台且语言无关的应用程序编程接口，其将HTML、XHTML或XML文档视为树结构，其中每个节点是表示文档一部分的对象。DOM表示具有逻辑树的文档。树的分支结束于节点，且节点可包含对象。DOM方法允许以编程方式访问树。例如，DOM方法可以允许改变文档的结构、样式和/或内容。

在718处确定是否选择附加的有线网络组件进行分析。如关于操作710所讨论的，可以以任何合适的顺序(诸如依次地、随机地或并行地)选择有线网络组件。

在720处确定是否选择附加数据字段进行更新。如关于操作702和706所讨论的，方法700可以持续运行以支持与用户接口中的一个或多个有线有线网络组件相关联的任何数据值的按需和/或定期更新。

根据各实施方案，可以以不同于所示顺序的顺序执行图7中所示的一个或多个操作。例如，可以同时更新与单个有线网络组件相关联的多个数据值。在这样的配置中，有线网络组件可以作为一个单元进行更新，而不是单独更新与有线网络组件相关联的各个数据值。

图8展示了根据一个或多个实施方案执行的用于销毁有线网络组件的方法800的示例。根据各实施方案，方法800可以在客户端机器处的有线网络组件处理引擎处(诸如图2中所示的有线网络组件处理引擎282)执行。

在802处接收到从DOM树中移除有线网络组件的请求。可以基于关于用户接口执行的动作来生成这样的请求。例如，用户可以关闭包括有线网络组件的用户接口部分。作为另一示例，用户可以从用户接口内的一个选项卡导航到用户接口内的一个不同选项卡，致使第一选项卡变为隐藏。作为又一示例，用户接口可以滚动使得有线网络组件不再可见。

在804处确定有线网络组件是否包括子节点。根据各实施方案，DOM树是分层结构，其中表示用户接口部分的代码本身可以包括子部分，该子部分包括表示其他用户接口部分的子节点代码。因此，可以至少部分地通过分析DOM树以标识任何这样的子节点来做出804处的确定。

当确定有线网络组件包括子节点时，可以在操作806处选择子节点之一以进行移除。根据各实施方案，可以以任何合适的顺序选择子节点。例如，可以依次地、并行地或随机地选择子节点以进行移除。在一些实现方式中，可以至少部分地经由递归过程来选择子节点。例如，可以以某种顺序选择有线网络组件的每个子节点以进行移除，其中该子节点的每个后代被递归地处理作为移除子节点的一部分。

在808处从DOM树中移除子节点。根据各实施方案，可以通过调用用于编辑DOM树的DOM树移除函数来移除子节点。

在810处，子节点排队等待从有线网络组件依赖图中移除。在812处，任何孤立的数据字段节点都排队等待从有线网络组件依赖图中移除。根据各实施方案，孤立的数据字段节点是有线网络组件依赖图中不再连接到本身未排队等待移除的任何有线网络组件的数据字段。

在一些实现方式中，有线网络组件处理引擎282可以维护已被标记用于移除的节点队列。替代地或附加地，可以在有线网络组件图中标记节点以用于移除。当节点排队等待移除时，可以在基于诸如计算资源可用性、带宽考虑和/或一个或多个数据访问阈值之类的考虑策略性地确定的时间处移除该节点。

在一些实施方案中，排队等待从有线网络组件依赖图中移除的节点可被立即移除。例如，用户接口可以加载在移动计算设备或具有相对有限的计算能力和/或带宽的其他设备上。作为另一个示例，由于接口的复杂性和/或被访问数据的类型或数量，用户接口可能具有相对较高的计算资源和/或带宽要求。在这种情况下，立即移除节点可有助于缓解资源和/或带宽限制。

在一些实施方案中，排队等待从有线网络组件依赖图中移除的节点可能最终不会被移除。例如，用户接口可在移除发生之前被销毁。作为另一个示例，该节点可以随后被添加回至DOM树。例如，用户可以提供重新激活有线网络组件的用户输入。

替代地，排队等待移除的节点可能会在稍后的时间点被移除。例如，有线网络组件处理引擎可以周期性地评估诸如计算资源和/或带宽的使用和/或可用性的考虑。当带宽和/或计算资源使用超过指定阈值时，有线网络组件处理引擎可以从有线网络组件依赖图中移除节点。例如，可以按照“先进先出”的顺序移除节点。

作为另一个示例，有线网络组件处理引擎可以使节点在指定的时间段(诸如1分钟、5分钟或10分钟)内保持排队等待移除。如果在指定的时间段内尚未重新添加节点，则可以从有线网络组件依赖图中移除该节点。

在特定实施方案中，在810处将节点排队等待移除可以提供用户接口响应性和资源使用之间的平衡。一方面，通过避免更新与节点相关联的数据的成本，更快地(或立即)从有线网络组件依赖图中移除节点可以帮助减少带宽和/或计算资源使用。另一方面，如果相关联的有线网络组件稍后被重新添加到DOM树中，则通过提供对与节点相关联的数据的更快访问，从有线网络组件依赖图中更快地(或立即)移除该节点可有助于提高用户接口响应性。也就是说，如果稍后将有线网络组件重新添加到DOM树中，则该组件的数据在与有线网络组件关联的节点尚未从有线网络组件依赖图移除的情况下将已经可用并且将不需要被取出。鉴于针对最近移除的有线网络组件将组件添加到DOM树的可能性更高，以这种方式将组件排队等待移除可以在一般情况下提供对数据的更快访问。

在814处确定是否选择附加的子节点进行移除。如关于操作806所讨论的，可以以任何合适的顺序选择节点以进行移除。

在816处，有线网络组件排队等待从依赖图中移除。在818处，任何孤立的数据字段都排队等待从依赖图中移除。在820处，从DOM树中移除有线网络组件。根据各实施方案，可以以基本上类似于操作808至812的方式来执行操作816至820。

在特定实施方案中，图8中所示的操作可以以不同于所示出的顺序来执行。例如，在递归程序中，可以在处理节点本身之前处理节点的每个后代。例如，在图6中，移除有线网络组件630可以涉及首先移除有线网络组件实例640、642和644，以及这些节点中的每个的任何子节点。

图9示出了包括根据一些实现方式配置的按需数据库服务的环境910的示例的框图。环境910可以包括用户系统912、网络914、数据库系统916、处理器系统917、应用平台918、网络接口920、租户数据存储装置922、租户数据923、系统数据存储装置924、系统数据925、程序代码926、进程空间928、用户接口(UI)930、应用程序接口(API)932、PL/SOQL 934、保存例程936、应用设置机制938、应用服务器950-1至950-N、系统进程空间952、租户进程空间954、租户管理进程空间960、租户存储空间962、用户存储装置964和应用元数据966。一些这样的设备可以使用硬件或硬件和软件的组合来实现，并且可以在相同的物理设备或不同的设备上实现。因此，在本文中使用的诸如“数据处理装置”、“机器”、“服务器”和“设备”之类的术语不限于单个硬件设备，而是包括被配置为提供所描述的功能的任何硬件和软件。

使用系统916实现的按需数据库服务可以由数据库服务提供商管理。某些服务可以将来自一个或多个租户的信息存储到公共数据库映像的表中，以形成多租户数据库系统(MTS)。如在本文中所使用的，每个MTS可以包括本地或跨一个或多个地理位置分布的一个或多个逻辑和/或物理连接的服务器。在本文中描述的数据库可以实现为单个数据库、分布式数据库、分布式数据库的集合、或任何其他合适的数据库系统。数据库图像可以包括一个或多个数据库对象。关系数据库管理系统(RDBMS)或类似系统可以针对这些对象执行信息的存储和获取。

在一些实现方式中，应用平台18可以是允许在系统916中创建、管理和执行应用程序的框架。此类应用程序可由数据库服务提供商开发，或者由访问该服务的用户或第三方应用程序开发者开发。应用平台918包括支持应用程序开发者创建和管理应用程序的应用设置机制938，其可以通过保存例程936作为元数据保存到租户数据存储装置922中以供订阅者执行作为例如由租户管理进程960管理的一个或多个租户进程空间954。可以使用PL/SOQL 934对此类应用程序的调用进行编码，该PL/SOQL 934为API 932提供了编程语言风格的接口扩展。一些PL/SOQL语言实现的详细描述在Craig Weissman的于2010年6月1日发布的题为“METHOD AND SYSTEM FOR ALLOWING ACCESS TO DEVELOPED APPLICATIONS VIA AMULTI-TENANT ON-DEMAND DATABASE SERVICE(用于允许经由多租户按需数据库服务访问开发的应用程序的方法和系统)”的共同转让的美国专利第7,730,478号中进行了讨论，该专利通过引用将其全部内容并入本文并用于所有目的。可以通过一个或多个系统进程检测对应用程序的调用。这样的系统进程可以为进行这样调用的订阅者管理对应用元数据966的获取。这样的系统进程还可以管理应用元数据966作为虚拟机中的应用程序的执行。

在一些实现方式中，每个应用服务器950可以处理对与任何组织相关联的任何用户的请求。负载均衡功能(例如，F5 Big-IP负载均衡器)可以基于诸如最少连接(least-connections)、轮询(round robin)、观察响应时间(observed response time)等算法将请求分发到应用服务器950。每个应用服务器950可被配置为与租户数据存储装置922和其中的租户数据923通信、以及与系统数据存储装置924和其中的系统数据925通信以服务用户系统912的请求。租户数据923可被划分为单独的租户存储空间962，其可以是数据的物理布置和/或逻辑布置。在每个租户存储空间962内，可以为每个用户类似地分配用户存储装置964和应用元数据966。例如，用户最近使用的(MRU)项目的副本可被存储到用户存储装置964中。类似地，整个租户组织的MRU项目的副本可以存储到租户存储空间962中。UI 930提供用户接口并且API 932向用户和/或用户系统912处的开发者提供到系统916驻留进程的应用程序编程接口。

系统916可以实现基于网络的用户接口客户端-服务器系统。例如，在一些实现方式中，系统916可以包括被配置为实现和执行服务侧数据库访问用户接口软件应用程序的应用服务器。应用服务器可被配置为向和从用户系统912提供相关数据、代码、表格、网页和其他信息。此外，应用服务器可被配置为将信息存储至数据库系统和从数据库系统获取信息。此类信息可包括相关数据、对象和/或网页内容。对于多租户系统，多个租户的数据可以存储在租户数据存储装置922中的同一个物理数据库对象中，然而，租户数据可以布置在租户数据存储装置922的(多个)存储介质中，使得一个租户的数据与另一租户的数据在逻辑上保持分离。在这种方案中，一个租户不得访问另一租户的数据，除非此类数据是明确共享的。

图9所示系统中的几个元素包括常规的、众所周知的元素，在此仅对其作简要说明。例如，用户系统912可以包括处理器系统912A、存储器系统912B、输入系统912C和输出系统912D。用户系统912可被实现为(多个)任何计算设备或其他数据处理装置，诸如移动电话、膝上型计算机、平板电脑、台式计算机或计算设备网络。用户系统12可以运行允许用户系统912的用户(例如，MTS的订阅者)通过网络914访问、处理和查看可从系统916获得的信息、页面和应用程序的互联网浏览器。网络914可以是相互通信的设备的任何网络或网络组合，诸如LAN(局域网)、WAN(广域网)、无线网络或其他适当配置中的任何一个或任何组合。

用户系统912的用户可以在他们各自的能力上不同，并且特定用户系统912访问信息的能力可以至少部分地由特定用户系统912的“权限”来确定。如在本文中所讨论的，权限通常管理对计算资源的访问，计算资源诸如数据对象、组件和计算系统的其他实体，诸如社交网络系统和/或CRM数据库系统。“权限集”通常是指可以分配给这种计算环境的用户的权限组。例如，用户和权限集的分配可以存储在系统916的一个或多个数据库中。因此，用户可能会获得访问某些资源的权限。按需数据库服务环境中的权限服务器可以存储与要相互分配的用户类型和权限集有关的标准数据。例如，计算设备可以向服务器提供表明用户属性(例如，地理位置、行业、角色、经验水平等)和要分配给适合这些属性的用户的特定权限的数据。可以选择满足标准的权限集并将其分配给用户。此外，权限可出现在多个权限集中。以这种方式，用户可以获得对系统组件的访问。

在一些按需数据库服务环境中，应用程序编程接口(API)可以配置为通过适当的基于网络的服务和架构向用户公开一组权限及其分配，例如使用简单对象访问协议(SOAP)网络服务和表征状态转移(REST)API。

在一些实现方式中，权限集可以作为权限容器呈现给管理员。然而，此类权限集中的每个权限可驻留在共享API中公开的单独API对象中，该API对象与同一权限集对象具有子-父关系。这允许给定的权限集扩展到用户的数百万个权限，同时允许开发者利用跨API对象的联接来查询、插入、更新和删除数百万个可能选项中的任何权限。这使得API具有高度可扩展性、可靠性和高效性，以供开发者使用。

在一些实现方式中，使用在本文中公开的技术构建的权限集API可以为开发者提供可扩展的、可靠的和高效的机制，以创建跨各种访问控制集和跨用户类型来管理用户权限的工具。使用此工具的管理员可以有效地减少其管理用户权限、与外部系统集成以及报告权限以进行审计和故障排除的时间。举例来讲，不同的用户在访问和修改应用程序和数据库信息方面可能具有不同的能力，这取决于用户的安全或权限级别(也称为授权)。在具有分层角色模型的系统中，处于一个权限级别的用户可以访问较低权限级别用户可访问的应用程序、数据和数据库信息，但可能无法访问更高权限级别的用户可以访问的某些应用程序、数据库信息和数据。

如上所讨论的，系统916可以使用MTS布置向用户系统912提供按需数据库服务。举例来讲，一个租户组织可以是雇用销售人员的公司，其中每个销售人员使用系统916来管理他们的销售过程。因此，此类组织中的用户可以维护联系人数据、线索数据、客户跟进数据、绩效数据、目标和进度数据等，所有这些都适用于该用户的个人销售过程(例如，在租户数据存储装置922中)。在这种布置中，用户可以从各种设备管理他或她的销售努力和周期，因为与这些数据交互(例如，访问、查看、修改、报告、传送、计算等)的相关数据和应用程序可以由具有网络访问权的任何用户系统912维护和访问。

当在MTS布置中实现时，系统916可以以各种方式在用户之间且以组织级别分离和共享数据。例如，对于某些类型的数据，每个用户的数据可能与其他用户的数据分开，而不管雇用此类用户的组织如何。其他数据可以是组织范围的数据，这些数据由几个用户或潜在地所有用户共享或访问，形成给定的租户组织。因此，由系统916管理的一些数据结构可以以租户级别分配，而其他数据结构可以以用户级别管理。因为MTS可能支持包括可能的竞争对手在内的多个租户，因此MTS可具有将数据、应用程序和应用程序使用分开的安全协议。除了用户特定的数据和租户特定的数据之外，系统916还可以维护可由多个租户使用的系统级数据或其他数据。此类系统级数据可包括可在租户组织之间共享的行业报告、新闻、帖子等。

在一些实现方式中，用户系统912可以是与应用服务器950通信以从系统916请求和更新系统级和租户级数据的客户端系统。举例来讲，用户系统912可以发送一个或多个查询，该查询请求在租户数据存储装置922和/或系统数据存储装置924中维护的数据库的数据。系统916的应用服务器950可以自动生成一个或多个SQL语句(例如，一个或多个SQL查询)，这些语句被设计为访问所请求的数据。系统数据存储装置924可以生成查询计划以从数据库访问所请求的数据。

在本文中描述的数据库系统可用于各种数据库应用。举例来讲，每个数据库通常可被视为对象的集合(诸如一组逻辑表)，其中包含适合预定义类别的数据。“表”是数据对象的一种表示，并且可以在本文中使用以根据一些实现方式简化对象和自定义对象的概念描述。应当理解，“表”和“对象”在本文中可以互换使用。每个表通常包含一个或多个数据类别，这些数据类别在可查看模式中逻辑排列为列或字段。表的每一行或记录都包含字段定义的每个类别的数据实例。例如，CRM数据库可以包括一个表，该表用字段描述了客户的基本联系信息，诸如姓名、地址、电话号码、传真号码等。另一个表可描述采购订单，包括针对诸如客户、产品、销售价格、日期等信息的字段。在一些多租户数据库系统中，可能会提供标准实体表供所有租户使用。对于CRM数据库应用程序，此类标准实体可能包括针对案例、账户、联系人、线索和机会数据对象的表，每个表都包含预定义的字段。应当理解，词语“实体”在本文中也可以与“对象”和“表”互换地使用。

在一些实现方式中，租户可被允许创建和存储自定义对象，或者他们可被允许自定义标准实体或对象，例如通过为标准对象创建自定义字段(包括自定义索引字段)。Weissman等人的于2010年8月17日发布的题为“CUSTOM ENTITIES AND FIELDS IN AMULTI-TENANT DATABASE SYSTEM(多租户数据库系统中的自定义实体和字段)”的共同转让的美国专利第7,779,039号教导了用于在MTS中创建自定义对象以及自定义标准对象的系统和方法，并且该专利通过引用将其全部内容并入本文并用于所有目的。在某些实现方式中，例如，所有自定义实体数据行可以存储在单个多租户物理表中，该单个多租户物理表针对每个组织可以包含多个逻辑表。对客户可以显然的是，他们的多个“表”实际上存储在一个大表中，或者他们的数据可与其他客户的数据存储在同一个表中。

图10A示出了根据一些实现方式配置的按需数据库服务环境1000的架构组件的示例的系统图。位于云1004中的客户端机器可以经由一个或多个边缘路由器1008和1012与按需数据库服务环境通信。客户端机器可以包括上述用户系统912的任何示例。边缘路由器1008和1012可以经由防火墙1016与一个或多个核心交换机1020和1024通信。核心交换机可以与负载均衡器1028通信，该负载均衡器可以通过经由Pod交换机1032和1036的通信将服务器负载分配到不同的Pod，诸如Pod 1040和Pod 1044。Pod 1040和Pod 1044可以各自包括一个或多个服务器和/或其他计算资源、可以执行用于提供按需服务的数据处理和其他操作。环境的组件可以经由数据库防火墙1048和数据库交换机1052与数据库存储装置1056通信。

访问按需数据库服务环境可能涉及在各种不同组件之间传送的通信。环境1000是实际按需数据库服务环境的简化表示。例如，按需数据库服务环境的一些实现可以包括每种类型的从一个到多个设备的任何地方。此外，按需数据库服务环境不需要包括图10A和图10B中所示的每个设备，或者可以包括图10A和图10B中未示出的附加设备。

云1004指任何合适的数据网络或数据网络的组合，其可以包括互联网。位于云1004中的客户端机器可以与按需数据库服务环境1000通信以访问由按需数据库服务环境1000提供的服务。举例来讲，客户端机器可以访问按需数据库服务环境1000以获取、存储、编辑和/或处理有线网络组件信息。

在一些实现方式中，边缘路由器1008和1012在云1004与按需数据库服务环境1000的其他组件之间路由数据包。边缘路由器1008和1012可以采用边界网关协议(BGP)。边缘路由器1008和1012可以维护IP网络或‘前缀’表，它们指定了互联网上自主系统之间的网络可达性。

在一个或多个实现方式中，防火墙1016可以保护环境1000的内部组件免受互联网流量的影响。防火墙1016可以基于一组规则和/或其他标准来阻止、许可或拒绝对按需数据库服务环境1000的内部组件的访问。防火墙1016可以充当数据包过滤器、应用网关、状态性过滤器、代理服务器或任何其他类型的防火墙中的一个或多个。

在一些实现方式中，核心交换机1020和1024可以是在环境1000内传输分组的高容量交换机。核心交换机1020和1024可被配置为在按需数据库服务环境内的不同组件之间快速路由数据的网络桥接器。两个或更多个核心交换机1020和1024的使用可以提供冗余和/或减少的等待时间。

在一些实现方式中，Pod 1040与Pod 1044之间的通信可以经由Pod交换机1032和1036进行。Pod交换机1032和1036可以促进Pod 1040和1044与客户端机器之间的例如经由核心交换机1020和1024的通信。此外或替代地，Pod交换机1032和1036可以促进Pod 1040和1044与数据库存储装置1056之间的通信。负载均衡器1028可以在Pod之间分配工作负载，这可以帮助改进对资源的使用、增加吞吐量、减少响应时间和/或减少开销。负载均衡器1028可以包括多层交换机以分析和转发流量。

在一些实现方式中，对数据库存储装置1056的访问可以由数据库防火墙1048保护，该防火墙可以充当在协议栈的数据库应用层操作的计算机应用防火墙。数据库防火墙1048可以保护数据库存储装置1056免受诸如结构查询语言(SQL)注入、数据库rootkit和未经授权的信息泄露之类的应用程序攻击。数据库防火墙1048可以包括主机，该主机在将流量传递到网关路由器之前使用一种或多种形式的反向代理服务来代理流量和/或可以检查数据库流量的内容并阻止某些内容或数据库请求。数据库防火墙1048可以在TCP/IP堆栈顶部的SQL应用程序级别上工作，管理应用程序与数据库或SQL管理接口的连接，以及拦截和强制执行进出数据库网络或应用程序接口的数据包。

在一些实现方式中，数据库存储装置1056可以是由许多不同组织共享的按需数据库系统。按需数据库服务可以采用单租户方法、多租户方法、虚拟化方法或任何其他类型的数据库方法。与数据库存储装置1056的通信可以经由数据库交换机1052进行。数据库存储装置1056可以包括用于处理数据库查询的各种软件组件。因此，数据库交换机1052可以将由环境的其他组件(例如，Pod 1040和Pod 1044)传送的数据库查询引导到数据库存储装置1056内的正确组件。

图10B示出了根据一些实现方式的进一步展示按需数据库服务环境的架构组件的示例的系统图。Pod 1044可用于向按需数据库服务环境1000的(多个)用户渲染服务。Pod1044可以包括一个或多个内容批处理服务器1064、内容搜索服务器1068、查询服务器1082、文件服务器1086、访问控制系统(ACS)服务器1080、批处理服务器1084和应用服务器1088。此外，Pod 1044可以包括数据库实例1090、快速文件系统(QFS)1092和索引器1094。Pod1044中的服务器之间的一些或所有通信可以经由交换机1036传送。

在一些实现方式中，应用服务器1088可以包括专用于程序(例如，程序、例程、脚本)的执行的框架，以用于支持由按需数据库服务环境1000经由Pod 1044提供的应用程序的构建。App服务器1088的一个或多个实例可被配置为执行在本文中描述的服务的全部或部分操作。

在一些实现方式中，如上所讨论的，Pod 1044可以包括一个或多个数据库实例1090。使用上述技术，数据库实例1090可被配置为MTS，其中不同的组织共享对同一数据库的访问。数据库信息可被传送到索引器1094，该索引器可以将数据库1090中可用信息的索引提供给文件服务器1086。QFS 1092或其他合适的文件系统可以用作快速访问文件系统，以用于存储和访问Pod 1044内可用的信息。QFS 1092可支持卷管理功能，允许将许多磁盘一起分组到一个文件系统中。QFS 1092可以与数据库实例1090、内容搜索服务器1068和/或索引器1094通信以标识、获取、移动和/或更新存储在网络文件系统(NFS)1096和/或其他存储系统中的数据。

在一些实现方式中，一个或多个查询服务器1082可以与NFS 1096通信以获取和/或更新存储在Pod 1044外部的信息。NFS 1096可以允许位于Pod 1044中的服务器以类似于如何访问本地存储装置的方式通过网络访问信息。来自查询服务器1022的查询可以经由负载均衡器1028传送到NFS 1096，该负载均衡器可以将资源请求分布在按需数据库服务环境1000中可用的各种资源上。NFS 1096还可以与QFS 1092通信以更新存储在NFS 1096上的信息和/或向QFS 1092提供信息以供位于Pod 1044内的服务器使用。

在一些实现方式中，内容批处理服务器1064可以处理Pod 1044内部的请求。这些请求可以长期运行和/或不捆绑于特定客户，诸如与日志挖掘、清理工作和维护任务有关的请求。内容搜索服务器1068可以提供查询和索引器功能，诸如允许用户搜索存储在按需数据库服务环境1000中的内容的功能。文件服务器1086可以管理对存储在文件存储装置1098中的信息的请求，该文件存储装置可以存储诸如文档、图像、基本大对象(BLOB)等信息。查询服务器1082可用于从一个或多个文件系统中获取信息。例如，查询系统1082可以从应用服务器1088接收对信息的请求，并且然后将信息查询传送到位于Pod 1044外部的NFS1096。ACS服务器1080可以控制对数据、硬件资源或软件资源的访问，这些资源被调用以渲染由Pod 1044提供的服务。批处理服务器1084可以处理批处理作业，这些作业用于在指定时间运行任务。因此，批处理服务器1084可以将指令传送到其他服务器(诸如应用服务器1088)，以触发批处理作业。

虽然可以参考具有为能够支持多租户的按需数据库服务提供前端的应用服务器的系统来描述所公开的实现方式中的一些，但是所公开的实现方式不限于多租户数据库也不限于应用程序上的部署。在不脱离本公开的范围的情况下，可以使用诸如IBM的等各种数据库架构来实践一些实现方式。

图11展示了计算设备的一个示例。根据各实施方案，适用于实现在本文中描述的实施方案的系统1100包括处理器1101、存储器模块1103、存储设备1105、接口1111和总线1115(例如，PCI总线或其他互连结构)。系统1100可以作为各种设备(诸如应用服务器、数据库服务器或在本文中描述的任何其他设备或服务)运行。尽管描述了特定的配置，但是各种替代配置也是可能的。处理器1101可以执行诸如在本文中描述的那些操作。用于执行这样的操作的指令可以体现在存储器1103中、一个或多个非暂时性计算机可读介质上、或一些其他存储设备上。也可以使用各种特殊配置的设备来取代或代替处理器1101。接口1111可被配置为通过网络发送和接收数据包。所支持接口的示例包括但不限于：以太网、快速以太网、千兆以太网、帧中继、电缆、数字用户线(DSL)、令牌环、异步传输模式(ATM)、高速串行接口(HSSI)和光纤分布式数据接口(FDDI)。这些接口可以包括适于与适当介质进行通信的端口。它们还可以包括独立的处理器和/或易失性RAM。计算机系统或计算设备可以包括监视器、打印机或其他合适的显示器或与之通信以向用户提供在本文中提到的任何结果。

任何公开的实现方式都可以体现在各种类型的硬件、软件、固件、计算机可读介质及其组合中。例如，在本文中公开的一些技术可以至少部分地由包括程序指令、状态信息等的计算机可读介质来实现，以用于配置计算系统来执行在本文中描述的各种服务和操作。程序指令的示例包括机器代码(诸如由编译器生成的)和可以经由解译器执行的更高级别的代码。指令可以以任何合适的语言体现，诸如，Apex、Java、Python、C++、C、HTML、任何其他标记语言、JavaScript、ActiveX、VBScript或Perl。计算机可读介质的示例包括但不限于：诸如硬盘和磁带的磁介质；诸如闪存、光盘(CD)或数字多功能磁盘(DVD)等光学介质；磁光介质；以及诸如只读存储器(“ROM”)设备和随机存取存储器(“RAM”)设备的其他硬件设备。计算机可读介质可以是此类存储设备的任何组合。

在前述说明书中，为了清楚起见，可能已经以单数形式描述了各种技术和机制。然而，应当注意，除非另有说明，否则一些实施方案包括技术的多次迭代或机制的多次实例化。例如，系统在各种上下文中使用一个处理器但可以使用多个处理器，同时保持在本公开的范围内，除非另有说明。类似地，各种技术和机制可能已经被描述为包括两个实体之间的连接。然而，连接并不一定意味着直接、无阻碍的连接，因为两个实体之间可能存在各种其他实体(例如，桥接器、控制器、网关等)。

在前述说明书中，详细参考了包括发明人设想的一种或多种最佳模式的特定实施方案。虽然在本文中已经描述了各种实现方式，但是应当理解，它们仅作为示例而不是限制来呈现。例如，在本文中在包括MTS的按需计算环境的上下文中描述了一些技术和机制。然而，本发明的技术适用于多种计算环境。可以在没有本文中描述的一些或全部特定细节的情况下实现特定实施方案。在其他情况下，为了避免不必要地混淆本发明，没有详细描述众所周知的过程操作。因此，本申请的广度和范围不应受在本文中描述的任何实现方式的限制，而应仅根据权利要求及其等效物来定义。