CN105391745A - 应用间资源级共享用企业系统内数据资源服务方法、系统 - Google Patents

Abstract

本发明涉及应用间资源级共享用企业系统内数据资源服务方法、系统。公开了在企业系统内提供数据资源服务以用于多个应用之间的资源级共享，以及相关方法、系统和计算机可读介质。在一个实施例中，提供了一种用于在企业系统内提供数据资源服务的方法。该方法包括接收来自具有位于企业系统外部的应用逻辑的web应用的要访问存储在企业系统内的存储器中的用户数据的用户数据请求。该方法还包括响应于来自web应用的用户数据请求而访问存储在企业系统内的存储器中的用户数据。该方法还包括响应于用户数据请求而向web应用提供对存储在企业系统内的存储器中的用户数据的访问。

Description

应用间资源级共享用企业系统内数据资源服务方法、系统

优先权申请

本申请要求2013年8月22日递交的标题为“PROVIDINGOFDATARESOURCESERVICES,PARTICULARLYCLOUDRESOURCESERVICES,WITHINENTERPRISESYSTEMSFORRESOURCELEVELDATAMASHUPFORUSEBYAPPLICATIONLOGIC,SUCHASWEBCOMMUNICATIONSWIDGETS”的美国临时专利申请序列号61/868,603的优先权，特此通过引用将该美国临时专利申请全部并入在此。

相关申请

本申请与2013年4月16日递交的标题为“DISTRIBUTEDAPPLICATIONOFENTERPRISEPOLICIESTOWEBREAL-TIMECOMMUNICATIONS(WEBRTC)INTERACTIVESESSIONS,ANDRELATEDMETHODS,SYSTEMS,ANDCOMPUTER-READABLEMEDIA”的美国专利申请序列号13/863,662相关，特此通过引用将该美国专利申请全部并入在此。

本申请还与2013年6月21日递交的标题为“APPLICATION-TO-REPOSITORYDATAMAPPINGINDATAREPOSITORIES,ANDRELATEDMETHODS,SYSTEMS,ANDCOMPUTER-READABLEMEDIA”的美国专利申请序列号13/923,748相关，这里通过引用将该美国专利申请全部并入在此。

技术领域

本公开的技术涉及企业系统内的数据可访问性。

背景技术

web应用的共同元素涉及管理和控制由个人提供的用户数据。例如，诸如和之类的社交网络网站内的web应用向每个用户提供从用户提供的数据生成的个人简档。虽然用户数据由用户提供，但每个web应用通常控制用户数据并且将其使用限制于web应用的特定需求。在此，图1A-1B示出了典型的数据控制方案10。图1A示出了数据控制方案10，其中用户12与web应用14交互。另外，web应用14控制对用户数据16的访问，这与用户12能够直接访问用户数据16形成对照。这样，用户数据16被直接束缚到web应用14的逻辑(未示出)，意思是用户数据16只能被web应用14访问和使用。更具体而言，图1B示出了数据控制方案10的另一个视图，示出了为了使得用户，例如图1A中的用户12，访问特定的web应用，例如图1A中的web应用14，web浏览器18与web服务器20通信。web服务器20访问被直接束缚到web应用逻辑22的用户数据16。因为用户数据16与web应用逻辑22直接关联，所以用户数据16只能被web应用逻辑22访问。从而，特定的web应用控制与该web应用相关联的用户数据，并且可防止其他web应用访问这种用户数据。

由于采用图1A和1B所示的数据控制方案10，会出现若干个问题。例如，因为web应用不可向其他web应用提供对用户数据的访问，所以数据控制方案10要求用户向多个网站提供类似的信息。这产生了用户数据在多个web应用上的冗余实例。另外，因为每个网站控制对它的用户数据的实例的访问，而不是用户控制这种访问，所以每个网站确定其他web应用是否可访问用户数据。结果，用户数据被锁入为被由进行控制的web应用所确定的有限数目的web应用访问和处理(称为“应用锁入”)。图1A和1B中的数据控制方案10还导致僵硬的数据边界，因为企业系统经常由于某些公共网站未能将用户数据的使用限制于仅限企业的功能而阻止对这种网站的访问。在此，企业系统是因特网域，这些因特网域采用企业应用软件(EnterpriseApplicationSoftware，EAS)以便控制哪些用户和应用能够访问由给定企业控制的因特网域。最后，在图1A和1B中的数据控制方案10下，用户数据寿命——在此期间可访问用户数据——对应于网站的寿命，从而导致一旦网站不再被用户访问，则用户数据就变得过时。例如，在上具有简档的用户如果决定将他或她的社交网络活动完全转移到则该用户不再能够使用该简档内的用户数据。从而，数据控制方案10导致了某些负面后果。

以上描述的数据控制方案10也用于企业应用。例如，企业系统可包括内部企业应用，例如IP语音电话服务、即时消息传递、电子邮件和Web实时通信(WebReal-TimeCommunications，WebRTC)电话会议。然而，与web应用的情况一样，这种企业应用经常要求企业用户向每个应用单独提供用户数据，因为这种数据被直接束缚到企业应用逻辑。例如，与企业用户在电子邮件应用内的联系人列表相关联的用户数据可与用户在即时消息传递应用内的联系人列表相同。然而，企业系统内的图1A和1B中的数据控制方案10会阻止企业应用共享用户数据，要求用户单独向每个企业应用提供相同的信息。从而，由于将数据控制方案10用于企业应用，在企业系统内出现与先前联系web应用描述的问题类似的问题。

补救由于数据控制方案10而出现的问题的一种解决方案涉及在企业系统内使用共享的用户数据。更具体而言，配置企业系统访问被束缚到web应用逻辑的用户数据可消除企业用户对于各企业应用单独管理用户数据的需要。例如，企业特定电子邮件应用可以针对某些电子邮件服务和特征而接口到账户。或者，企业应用逻辑可被配置为访问和共享受web应用控制的用户数据。例如，企业特定电子邮件应用可被配置为仅访问受应用逻辑控制的用户的联系人列表。然而，允许web应用在企业系统内运行或者与企业应用共享与web应用逻辑相关联的用户数据产生了通过容宿这种web应用的公共web服务器在没有授权的情况下访问私有的、受保护的企业信息的可能性。另外，与web应用共享数据的企业应用仍要求用户更新用户数据的多个实例以便跨企业应用访问类似的信息。

从而，企业应用能够以高效的方式访问被web应用使用的用户数据，而不让受保护的企业信息容易遭受通过公共web服务器的未经授权的访问，将是有利的。

发明内容

详细描述中公开的实施例包括在企业系统内提供数据资源服务以用于多个应用之间的资源级共享。也公开了相关方法、系统和计算机可读介质。在本文公开的实施例中，在企业系统内提供数据资源服务以允许用户数据与访问用户数据的应用逻辑分离。数据资源服务是如下的服务：其将用户数据在服务器或另一存储介质上存储为由路径或统一资源定位符(URL)标识的层次化资源(本文也称为“数据资源”)。数据资源被创建为暂态的或持久的。暂态数据资源在创建了该数据资源的客户端连接被断开连接时被服务器自动删除，而持久数据资源在断开连接时不被删除。利用暂态数据资源帮助提供了自动清除和对抗浏览器崩溃的鲁棒性。另外，在企业系统内提供数据资源服务，以使得使用企业系统内的应用的用户，以及具有企业系统外的逻辑的web应用，能够基于关联的权限来访问存储的用户数据的相同实例。用户数据集中在企业系统内，使得用户可控制和更新企业系统内的用户数据的单个实例。

作为非限制性示例，企业系统内的用户可将企业系统内的基于Web实时通信(WebRTC)的聊天应用(WebRTCChat)用于即时消息传递，并且通过的网站将用于电子邮件通信。每个应用，即WebRTCChat和使用由用户提供的联系人列表，该联系人列表由用户经常与之通信的人的姓名和联系信息构成。使用数据资源服务使得用户能够创建和控制被存储在企业系统内的联系人列表的一个实例，而不是向WebRTCChat和提供联系人列表的单独实例。WebRTCChat和都能够访问和使用存储在企业系统内的联系人列表，从而只要求用户更新和管理联系人列表的一个实例来供两个应用使用。

这样，可以跨企业系统内的多个应用以及跨具有企业系统外的逻辑的多个web应用来使用由用户提供给企业系统的数据。从而，不是要求企业系统内和外的每个应用管理其自己的、可能过期的用户数据，而是每个应用对于与应用逻辑分离的所有用户数据可依赖于一个中央实例。这样允许一个应用使用原本创建来供另一应用使用的用户数据——也称为应用“混聚”——提供了多个示范性益处。例如，可独立于特定的web或企业应用，在企业系统内搜索和备份用户数据。与为各个企业应用执行相似的任务相比，统一数据搜索和数据备份以使得这种任务不依赖于应用逻辑可提供企业系统内的效率和时间节省。此外，企业系统内的安全性可受益于数据资源服务，因为内部资源数据可在组织内保持私密，而不允许公共web服务器对私有信息的访问。另外，数据资源服务可被附加到其他设备或联网的应用，以将某些信息暴露给web应用。数据资源服务还提供了将被web和原生(native)企业应用两者使用的灵活性。此外，不是要求相似数据的实例存在于每个企业和web应用的逻辑内、从而对于每个实例要求单独的数据管理，数据资源服务而是在企业系统内集中用户数据的一个可使用实例并且按照用户的许可提供对这种应用的访问。

在此，在一个实施例中，提供了一种用于在企业系统内提供数据资源服务以用于多个应用之间的资源级共享的方法。该方法包括接收来自具有位于企业系统外部的应用逻辑的web应用的要访问存储在企业系统内的存储器中的用户数据的用户数据请求。该方法还包括响应于来自web应用的用户数据请求而访问存储在企业系统内的存储器中的用户数据。该方法还包括响应于用户数据请求而向web应用提供对存储在企业系统内的存储器中的用户数据的访问。作为非限制性示例，提供对用户数据的访问可包括允许web应用读取、写入、附加或发送事件到用户数据，以及遍历与用户数据相关联的资源树。

在另一实施例中，提供了一种用于在企业系统内提供数据资源服务以用于多个应用之间的资源级共享的系统。该系统包括企业系统内的存储器，被配置为存储用户数据。该系统还包括数据资源服务器，被配置为接收来自具有位于企业系统外部的应用逻辑的web应用的要访问存储在企业系统内的存储器中的用户数据的用户数据请求。数据资源服务器还被配置为响应于来自web应用的用户数据请求而访问存储在企业系统内的存储器中的用户数据。数据资源服务器还被配置为响应于用户数据请求而向web应用提供存储在企业系统内的存储器中的用户数据。

在另一实施例中，提供了一种存储一个或多个程序的非暂态计算机可读介质。一个或多个程序包括指令，这些指令当被电子设备执行时使得电子设备实现用于在企业系统内提供数据资源服务以用于多个应用之间的资源级共享的方法。该方法包括接收来自具有位于企业系统外部的应用逻辑的web应用的要访问存储在企业系统内的存储器中的用户数据的用户数据请求。该方法还包括响应于来自web应用的用户数据请求而访问存储在企业系统内的存储器中的用户数据。该方法还包括响应于用户数据请求而向web应用提供对存储在企业系统内的存储器中的用户数据的访问。

附图说明

结合在本说明书中并形成本说明书的一部分的附图图示了本公开的几个方面，并且与描述一起帮助说明本公开的原理。

图1A是示范性数据控制方案的框图，其中对用户数据的访问由web应用来控制和管理；

图1B是图1A中的数据控制方案的框图，示出了用户数据被束缚到web应用逻辑，其中web浏览器与web应用逻辑通信并且经由web服务器来访问用户数据；

图2A是企业系统内的示范性数据资源服务的框图，其中对用户数据的访问是由用户而不是web应用来管理和控制的；

图2B是示范性关系的框图，其中对用户数据的访问是由用户通过数据资源服务来控制的，而不是被束缚到web应用逻辑，其中web应用逻辑在web浏览器中运行并且经由数据资源服务来访问用户数据；

图3A是示范性流程图，示出了被配置为向web应用提供对用户数据的访问的企业系统内的数据资源服务的示范性功能；

图3B是示范性流程图，示出了被配置为如果用户数据包括允许web应用的用户访问这种用户数据的关联访问权限则向web应用提供对用户数据的访问的企业系统内的数据资源服务的示范性功能；

图4是示范性消息流程图，示出了基于数据资源服务的系统内的数据访问和事件通知；

图5是示出在数据资源服务的情境中使用Web实时通信(WebRTC)微件的两个用户之间的WebRTC交互式会话的示范性拓扑的概念图；

图6是在企业系统内的数据资源服务内工作的WebRTCvideo-io微件的示范性消息流程图；

图7是电话微件的示范性状态机；

图8是列出可结合企业系统内的数据资源服务使用的示范性微件的表格；并且

图9是示范性的基于处理器的系统的示意图表示，该系统可包括图2A中的企业系统内的数据资源服务并且被配置为执行来自示范性计算机可读介质的指令以执行本文描述的功能。

具体实施方式

现在参考附图，描述本公开的若干个示范性实施例。“示范性”一词在本文中用来指“充当示例、实例或例示”。本文描述为“示范性”的任何实施例不一定要被解释为比其他实施例更优选或有利。

本文公开的实施例包括在企业系统内提供数据资源服务以用于多个应用之间的资源级共享。也公开了相关方法、系统和计算机可读介质。在本文公开的实施例中，在企业系统内提供数据资源服务以允许用户数据与访问用户数据的应用逻辑分离。数据资源服务是如下的服务：其将用户数据在服务器或另一存储介质上存储为由路径或统一资源定位符(URL)标识的层次化资源(本文也称为“数据资源”)。数据资源被创建为暂态的或持久的。暂态资源在创建了该数据资源的客户端连接被断开连接时被服务器自动删除，而持久数据资源在断开连接时不被删除。利用暂态数据资源帮助提供了自动清除和对抗浏览器崩溃的鲁棒性。另外，在企业系统内提供数据资源服务，以使得使用企业系统内的应用的用户，以及具有企业系统外的逻辑的web应用，能够基于关联的权限来访问存储的用户数据的同一实例。用户数据集中在企业系统内，使得用户可控制和更新企业系统内的用户数据的单个实例。

作为非限制性示例，企业系统内的用户可将企业系统内的基于Web实时通信(WebRTC)的聊天应用(WebRTCChat)用于即时消息传递，并且通过的网站将用于电子邮件通信。每个应用，即WebRTCChat和，使用由用户提供的联系人列表，该联系人列表由用户经常与之通信的人的姓名和联系信息构成。使用数据资源服务使得用户能够创建和控制被存储在企业系统内的联系人列表的一个实例，而不是向WebRTCChat和提供联系人列表的单独实例。WebRTCChat和都能够访问和使用存储在企业系统内的联系人列表，从而只要求用户更新和管理联系人列表的一个实例来供两个应用使用。

这样，可以跨企业系统内的多个应用以及跨具有企业系统外的逻辑的多个web应用来使用由用户提供给企业系统的数据。从而，不是要求企业系统内和外的每个应用管理其自己的、可能过期的用户数据，每个应用对于与应用逻辑分离的所有用户数据可依赖于一个中央实例。这样允许一个应用使用原本创建来供另一应用使用的用户数据——也称为应用“混聚”——提供了多个示范性益处。例如，可独立于特定的web或企业应用，在企业系统内搜索和备份用户数据。与为各个企业应用执行相似的任务相比，统一数据搜索和数据备份以使得这种任务不依赖于应用逻辑可提供企业系统内的效率和时间节省。此外，企业系统内的安全性可受益于数据资源服务，因为内部资源数据可在组织内保持私密，而不允许公共web服务器对私有信息的访问。另外，数据资源服务可被附加到其他设备或联网的应用，以将某些信息暴露给web应用。数据资源服务还提供了将被web和原生企业应用两者使用的灵活性。此外，不是要求相似数据的实例存在于每个企业和web应用的逻辑内、从而对于每个实例要求单独的数据管理，数据资源服务而是在企业系统内集中用户数据的一个可使用实例并且按照用户的许可提供对这种应用的访问。

在此，在一个实施例中，提供了一种用于在企业系统内提供数据资源服务以用于多个应用之间的资源级共享的方法。该方法包括接收来自具有位于企业系统外部的应用逻辑的web应用的要访问存储在企业系统内的存储器中的用户数据的用户数据请求。该方法还包括响应于来自web应用的用户数据请求而访问存储在企业系统内的存储器中的用户数据。该方法还包括响应于用户数据请求而向web应用提供对存储在企业系统内的存储器中的用户数据的访问。作为非限制性示例，提供对用户数据的访问可包括允许web应用读取、写入、附加或发送事件到用户数据，以及遍历与用户数据相关联的资源树。

在此，图2A-2B示出了示范性数据资源服务控制方案24。更具体而言，图2A示出了数据资源服务控制方案24，其中用户26向位于企业系统32内的数据资源服务30提供用户数据28。虽然此示例示出了用户26存在于企业系统32之外，但用户26在企业系统32内也可按类似的方式工作。另外，向数据资源服务30提供用户数据28允许了用户26保持对于对用户数据28的访问的控制权。这与先前描述的图1A中的数据控制方案10形成对比，其中web应用14控制对各个用户数据16的访问。此外，因为图2A中的用户数据28被提供给数据资源服务30，所以用户26只提供用户数据28的一个实例，而不是为每个web应用34(0)-34(1)创建单独的实例。因此，每个web应用34(0)-34(1)为了访问用户数据28则必须向数据资源服务30发送用户数据请求(未示出)。例如，若数据资源服务30接收到来自web应用34(0)的对于用户数据28的用户数据请求，则数据资源服务30将把请求的用户数据28提供给web应用34(0)。

在此，图2B示出了数据资源服务控制方案24的另一视图，其示出了如何在设备级从图2A中的数据资源服务30访问用户数据28的示例。图2B中的数据资源服务控制方案24包含与图2A共同的某些组件，它们在图2A和2B之间以共同的元素编号示出。更具体而言，在此示例中，web应用逻辑36在web浏览器38内运行，而不是如图1B中所示那样被web浏览器18通过web服务器20访问。虽然web应用逻辑36在此示例中在web浏览器38内运行，但如果图1B的web服务器20与数据资源服务30相接口，则可以构造图2A的数据资源服务30以使得web应用逻辑36在web服务器20上运行。web应用逻辑36向数据资源服务器40发送对于用户数据28的用户数据请求(未示出)，数据资源服务器40实现图2A中的数据资源服务30。例如，数据资源服务器40可将用户数据28存储和管理为由路径或URL标识的层次化资源。虽然图2A中的数据资源服务30在此示例中是利用数据资源服务器40实现的，但数据资源服务30可利用任何其他提供额外的服务器功能的设备来实现。另外，在接收到用户数据请求后，数据资源服务器40访问被存储在企业系统32内的存储器42中的用户数据28。数据资源服务器40将所请求的用户数据28经由web应用逻辑36提供给web应用34(图2B中未示出)以便处理。在此示例中，web应用34的web应用逻辑36位于企业系统32的外部。然而，其企业应用逻辑(未示出)在企业系统32内的企业应用(未示出)可以按类似的方式请求和接收用户数据28。通过使用图2A中的数据资源服务30来存储和提供所请求的用户数据28，用户26(图2B中未示出)能够创建和管理用户数据28的仅一个实例。这允许了在跨多个web应用34和企业应用管理和访问用户数据28时的更高效率。

在此，图3A示出了示范性流程图44，其描述了在图2A中描述的由图2B中的数据资源服务器40实现的数据资源服务30的示范性功能。图3A中的流程图44引用与图2A-2B共同的某些组件，这些组件在各图之间以共同的元素编号示出。更具体而言，在图3A中，数据资源服务30接收来自其web应用逻辑36位于企业系统32外部的web应用34(0)的用户数据请求。web应用34(0)发送这种用户数据请求以便获得对于存储在位于企业系统32内的存储器42中的用户数据28的访问(块46)。响应于在块46来自web应用34(0)的用户数据请求，数据资源服务30访问存储在企业系统32内的存储器42中的用户数据28(块48)。数据资源服务30随后向web应用34(0)提供对所请求的用户数据28的访问(块50)。重要的是，即使用户数据28原本是用户26为不同的web应用34(1)创建的，数据资源服务30也可向web应用34(0)提供对用户数据28的访问。此外，虽然图3A示出了数据资源服务30从web应用34(0)接收用户数据请求的示例，但当这种用户数据请求源自于企业应用(例如，其逻辑位于企业系统32内的应用)时，数据资源服务30也以类似的方式工作。另外，数据资源服务30可从用户26接收用户数据更新并将这种更新内的用户数据28存储在存储器42中。从而，数据资源服务30使得用户26能够管理被多个web应用34和企业应用使用的用户数据28的一个实例，从而产生了对用户数据28的更高效的使用和管理。

在此，图3B示出了示范性流程图52，其描述了图3A中描述的数据资源服务30的功能，并且包括安全性功能以便为用户数据28提供增加的保护。图3B的流程图52引用了与图2A-2B和图3A共同的某些组件，这些组件在各图之间以共同的元素编号示出。更具体而言，图3B示出了数据资源服务30接收用户数据请求(块46)并且访问用户数据28(块48)，如先前在图3A中所述。作为非限制性示例，用户数据28的访问可包括读取、写入、附加或发送事件到用户数据28，以及遍历与用户数据28相关联的资源树。每种类型的访问可要求单独的访问权限。在块48访问用户数据28之后，数据资源服务30在向作出请求的web应用34(0)提供对任何用户数据28的访问之前审核与用户数据28相关联的任何访问权限(块54)。例如，为了访问用户数据28可能需要“读取”权限。如果与用户数据28相关联的任何访问权限允许使用作出请求的web应用34(0)的用户26访问用户数据28，则数据资源服务30向web应用34(0)提供用户数据28(块50)，如图3A中所述。相反，如果与用户数据28相关联的访问权限都不允许使用作出请求的web应用34(0)的用户26访问用户数据28，则数据资源服务30将不响应于用户数据请求向web应用34(0)提供对用户数据28的访问(块56)。从而，除了产生在管理用户数据28方面的效率以外，数据资源服务30还可为用户数据28提供额外的安全性权限以帮助防止对私有的用户和企业信息的未经授权的访问。

先前在图2A-2B和图3A-3B中描述的数据资源服务30可按各种方式与web应用34通信。在此，图4示出了示范性消息流程图58，其示出了基于数据资源服务的系统内的数据访问和事件通知。图4中的消息流程图58包含与图2A-2B共同的某些组件，这些组件在各图之间以共同的元素编号示出。更具体而言，在此示例中，数据资源服务器40从存储器42访问用户数据28(未示出)，两者都位于企业系统32(未示出)内。在此示例中，用户0通过建立从web浏览器38(0)到数据资源服务器40的WebSocket连接来与数据资源服务30(未示出)通信，如箭头60所指示。一旦建立了这种连接，用户0就对于经由路径“/room/1234”可访问的数据通过“GET”命令发出用户数据“读取”请求，如箭头62所指示。响应于接收到用户数据请求，数据资源服务器40访问存储器42。另外，数据资源服务器40将所请求的用户数据28提供给用户0，表明用户数据请求“成功”，并且还将资源数据内容(或者实体表示)提供给用户0，如箭头64所指示。除了请求用户数据28以外，用户0还可通过数据资源服务器40来更新存储器42中的用户数据28。在此示例中，用户0通过使用“POST”命令来提供用户数据“创建”以为“用户0”存储可标识为经由路径“/room/1234/members”可访问的“资源”，如箭头66所指示。在此示例中，数据资源服务器40以“成功”的确认指出用户数据更新完成，如箭头68所指示。

继续参考图4，在用户0连接到数据资源服务器40的同时，用户1可与数据资源服务器40通信。在此示例中，与用户0类似，用户1通过建立从web浏览器38(1)到数据资源服务器40的WebSocket连接(未示出)来与数据资源服务30(未示出)通信。利用此连接，用户1通过发出“SUBSCRIBE”请求来发送用户数据请求以便在经由路径“room/1234/members”可访问的资源内发生任何变化时接收通知，如箭头70所指示。从而，响应于先前在箭头66描述的由用户0作出的用户数据更新，数据资源服务器40向用户1提供“NOTIFY”消息，指出用户0对于经由“room/1234/members”路径可访问的资源作出了“POST”，如箭头72所指示。

除了图4中的消息流程图58中示出的数据访问和事件通知场景以外，先前描述的数据资源服务30还可与通信应用一起使用。例如，数据资源服务30可与其应用逻辑在web浏览器内运行的通信应用交互。例如WebRTC应用之类的通信应用可利用可包括超文本标记语言(HTML)、JavaScript和/或层叠样式表代码的集合的微件(widget)来实现，并且可被嵌入在诸如web浏览器之类的客户端内。微件隐藏应用的实现细节或要求并且暴露应用的简单属性和互连。微件可用作独立的应用或者可与其他微件互连。另外，多个微件可经由包含的属性、附加或属性附加来互连。在此，图5示出了在数据资源服务的情境中使用利用WebRTC微件实现的WebRTC应用的两个用户之间的WebRTC交互式会话的示范性拓扑74。具体地，企业系统76包括实现数据资源服务80的数据资源服务器78。数据资源服务器78耦合到存储企业系统76内的用户数据84的存储器82。在此示例中，企业系统76包括防止对企业系统76的未经授权的访问的网络设备86，例如防火墙。

继续参考图5，在企业用户设备88与外部用户设备90之间建立WebRTC交互式会话。当在本文中使用时，WebRTC交互式会话指的是用于执行WebRTC提议/应答交换、建立对等连接以及在两个或更多个端点之间开始WebRTC交互流的操作。在企业系统76内，企业用户设备88执行企业web客户端92，例如web浏览器。在此示例中，企业web客户端92包括使能以脚本语言编写的客户端侧应用的脚本引擎94(0)。脚本引擎94(0)还提供应用编程接口(API)(未示出)以促进与企业web客户端92和/或企业用户设备88内的其他功能提供者的通信。企业web客户端92还包括WebRTC功能提供者96(0)，用于实现使能经由WebRTC的实时交互式会话所必要的协议、编解码器和API。在企业系统76的外部有向作出请求的web客户端提供使能了WebRTC的web应用(未示出)的web应用服务器98。在企业系统76的外部还有外部用户设备90，其执行外部web客户端100，例如web浏览器。在此示例中，外部web客户端100包括脚本引擎94(1)和WebRTC功能提供者96(1)，其功能分别对应于脚本引擎94(0)和WebRTC功能提供者96(0)的功能。

继续参考图5，为了建立WebRTC交互式会话，企业web客户端92和外部web客户端100都从web应用服务器98下载相同的WebRTCweb应用(未示出)。企业web客户端92和外部web客户端100分别与web应用服务器98建立安全web连接102和104，并且参与WebRTC提议/应答交换。一旦WebRTC提议/应答交换完成，就可经由企业web客户端92与外部web客户端100之间的安全对等连接108来建立WebRTC交互流106。此外，企业web客户端92和外部web客户端100各自分别与数据资源服务器78建立WebSocket连接110和111。外部web客户端100必须具有必要的权限来通过企业系统76的网络设备86建立WebSocket连接111。另外，在分别建立WebSocket连接110和111之后，企业web客户端92和外部web客户端100可各自向数据资源服务器78发送用户数据请求和用户数据更新。响应于这种请求和更新，数据资源服务器78如先前所述访问存储在存储器82内的用户数据84。

在此，图6示出了WebRTCvideo-io微件的示范性消息流程图112，该WebRTCvideo-io微件在诸如web浏览器之类的客户端内运行，并且结合企业系统内的数据资源服务工作。在此示例中，video-io微件允许了应用在两个web浏览器之间创建对等连接以利用交互式连通性建立(InteractiveConnectivityEstablishment，ICE)交换诸如实况视频之类的实时媒体流。video-io微件具有视频盒以发布本地捕捉的相机和麦克风或者播放来自web的远程流或媒体文件，同时隐藏信令协商。具体地，video-io微件创建从video-io发布者到同一数据资源路径上的video-io播放器的对等连接。在此示例中，video-io发布者114通过分开的对等连接向video-io播放器116(0)-116(1)发布视频。更具体而言，video-io播放器116(0)与位于企业系统内的数据资源服务器118建立WebSocket连接，如箭头120所指示。在建立这种连接之后，video-io播放器116(0)预订资源“{root}/publisher”，如箭头121所指示。video-io播放器116(0)还利用“POST”方法在父“{root}/players”资源下创建子资源，如箭头122所指示，其中“{root}”表示该流资源的根路径，例如/path/to/stream1(未示出)。数据资源服务器118通知video-io播放器116(0)这种子资源已被创建，其id为“2142”，如箭头124所指示。video-io播放器116(0)随后预订资源“{root}/players/2142”以便被通知关于在该资源处发布的任何视频，如箭头126所指示。

继续参考图6，video-io发布者114与数据资源服务器118建立WebSocket连接，如箭头128所指示。另外，video-io发布者114在“{root}”下创建“publisher”资源，并且预订接收对于“{root}/publisher”和“{root}/players”下的资源的改变通知，如箭头130所指示。因为video-io播放器116(0)先前预订了被通知关于对“{root}/publisher”处的资源的改变，所以video-io播放器116(0)接收到关于video-io发布者114的活动的通知，如箭头132所指示。类似地，因为video-io发布者114预订了接收关于资源“{root}/players”的通知，所以video-io发布者114接收到对于在该资源内创建了“2142”的指示，如箭头134所指示。作为响应，video-io发布者114通过发送关于“{root}/players/2142”资源的通知，来提议与video-io播放器116(0)建立对等连接，如箭头136所指示。这种提议被数据资源服务器118传播到进行预订的video-io播放器116(0)(箭头138)，并且video-io播放器116(0)接受该提议(箭头140)，这被video-io发布者114所接收(箭头142)。从而，video-io发布者114和video-io播放器116(0)建立对等连接以利用video-io微件来流传输视频，其中经由路径“{root}/players/2142”通过数据资源服务器118可访问用于这种视频流的信令和数据。

继续参考图6，新的video-io播放器116(1)也与数据资源服务器118建立WebSocket连接，如箭头144所指示。在建立这种连接之后，video-io播放器116(1)预订资源“{root}/publisher”，如箭头145所指示。video-io播放器116(1)利用“POST”方法在父“{root}/players”资源下建立子资源，如箭头146所指示。video-io发布者114接收到通知，该通知指出video-io播放器116(1)请求的子资源将被创建，其id为“9635”，如箭头148所指示。数据资源服务器118通知video-io播放器116(1)这种子资源已被创建，其id为“9635”，如箭头150所指示。video-io播放器116(1)随后预订资源“{root}/players/9635”，以便被通知关于在该资源处发布的任何视频，如箭头152所指示。与video-io播放器116(0)类似，video-io发布者114提议与video-io播放器116(1)建立对等连接，这可由“{root}/players/9635”资源来标识，如箭头154所指示。这种提议被传播到video-io播放器116(1)(箭头156)，并且video-io播放器116(1)接受该提议(箭头158)，这被video-io发布者114所接收(箭头160)。从而，video-io发布者114和video-io播放器116(1)建立对等连接以利用video-io微件来流传输视频，其中经由路径“{root}/players/9635”通过数据资源服务器118可访问用于这种视频流的信令和数据。最后，video-io微件也可使得video-io发布者114、video-io播放器116(0)和video-io播放器116(1)能够终止其各自到数据资源服务器118的WebSocket连接。

除了图6中描述的video-io微件以外，微件还可用于实现利用数据资源服务工作的其他web应用。在此，图7示出了可结合企业系统内的数据资源服务使用的电话微件的示范性状态机162。更具体而言，电话微件利用两个用户——第一用户164和第二用户166——之间的一系列信令消息来模拟现有的电话。在双方呼叫中，第一用户164和第二用户166采用各自的电话微件的实例来基于触发器在多个呼叫状态之间转变，如状态机162中所示。例如，从空闲状态168，第一用户164可点击呼叫按钮以利用邀请消息170邀请第二用户166加入电话呼叫，从而将该呼叫对于第一用户164置于邀请状态172中。第二用户166在处于空闲状态168中的同时接收到邀请消息170，这提示第二用户166关于进入的呼叫，并且将第二用户166从空闲状态168转变到被邀请状态174。第二用户166或者可通过点击呼叫按钮来应答该呼叫，从而指示电话微件发送接受消息176以接受邀请消息170。相反，第二用户166可通过点击结束按钮来拒绝该呼叫，从而指示电话微件发送拒绝消息178。如果第一用户164对于外出的未决呼叫点击结束按钮，则第一用户164的电话微件发送取消消息180，这被第二用户166的电话微件所接收，并且最终取消对于第二用户166的进入呼叫。这对于第一用户164和第二用户166两者都将呼叫转变到空闲状态168。如果第二用户166拒绝邀请消息170，则第一用户164的电话微件接收到拒绝消息178并且转变到空闲状态168。如果第二用户166接受邀请消息170，则呼叫进入活动状态182并且发送接受消息176到第一用户164的电话微件，从而对于两个用户都将呼叫转变到活动状态182。在呼叫处于活动状态182中的同时，如果任一用户164或166发送数据消息184，则呼叫保持在活动状态182中。然而，如果第一用户164或第二用户166点击结束按钮以终止呼叫，则相应的电话微件在处于活动状态182中的同时发送结束消息186。这终止了呼叫并将其对于第一用户164和第二用户166两者都置于空闲状态168中。

作为非限制性示例，从图7中描述的电话微件发出的示范性消息可源自于一用户，其中该用户邀请另一用户加入呼叫，其中该邀请由编号“5324”来标识。这种呼叫的示范性消息可包括以下的：{“type”:“invite”,“invite-id”:“5324”,“from”:“/path/to/user1”}(未示出)。除了图6中描述的video-io微件和图7中描述的电话微件以外，微件还可被配置为互连到一个或多个其他微件以便充当与数据资源服务一起工作的单个web应用。

在此，图8提供了可与数据资源服务一起使用的示范性微件的表格188。例如，点击呼叫微件是具有发起、应答或终止呼叫的按钮的web音频电话。点击呼叫微件将呼叫控制逻辑委托给所包括的电话微件，并且将基于WebRTC的媒体处理委托给两个audio-io微件，一个用于发布，另一个用于播放。例如，点击呼叫微件将电话微件的资源属性绑定到进行发布的audio-io微件的发布属性，并且将其target_resource属性绑定到进行播放的audio-io微件的播放属性。web开发者可修改这些微件以改变web电话的行为；例如，将audio-io引用互连到video-io微件允许了电话微件在使用相同的呼叫控制的同时被用作视频电话。电话引用可被设定到另一个基于电话的微件，例如呼叫队列或自动呼叫分发器。呼叫队列将电话微件扩展为将接收到的呼叫邀请放入显示给用户的列表中，并且允许用户一次选择一个邀请来应答或拒绝。分发器微件将电话微件扩展为允许多个目标。当呼叫被发出时，邀请被基于相应的分发属性来并行地或者依次地或者以这两种方式的组合发送到所有目标资源。这些电话术微件与电话微件兼容，因为它们每个使用相同类型的信令消息并且在电话微件适用的任何地方它们每个都可被使用。

继续参考图8中的表格188中列出的示范性微件，会议微件表示被绑定到数据资源路径的多方会议，其中所有其会议和成员资格资源被创建在该数据资源路径下。当多个微件将其数据资源属性设定到相同路径时，它们预订相同的会议并且侦听其成员的变化。例如，如果数据资源是“/path/to/conf1/”，则“/path/to/conf1/members”是其成员的阵列资源。当“me”属性被设定到本地用户的数据时，会议微件代表用户加入会议并且将该数据添加到成员阵列。这两个属性足以控制会议微件。此外，会议微件定义“join_id”和“myid”属性以便根据需要控制和指示本地成员的子标识符。电话和会议微件具有在许多应用中有用的核心电话术概念。另外，点击加入微件提供了用于加入或离开会议的按钮。此外，邀请微件将电话微件扩展为用于会议中，其中用户利用与电话微件相同的协议邀请另一参与者到会议。

继续参考图8中的表格188中列出的示范性微件，名册微件显示用户的列表、其在场状态和基于阵列资源路径的定制消息。名册微件可以在即时消息传递器中示出联系人列表或者当被附加到会议微件时显示成员资格列表。视频微件支持数据资源路径上的视频会议并且对于每个参与者包括一个video-io项目。如果附加了视频微件，则视频被添加到否则仅限音频的会议或者电话应用。另外，视频微件可基于参与者的数目提供瓦片或画中画布局。然而，应用可通过提供静态的一组video-io微件来推翻该布局；例如，应用可提供具有2x2布局的固定四方视频会议。另外，文本聊天微件实现多方文本聊天功能。更具体而言，文本聊天微件具有文本馈送以示出阵列资源中的消息，并且具有文本输入控件以向该资源张贴消息。消息包含发送者数据、创建的日期/时间、消息类型和纯文本或者HTML的实际消息。持久属性控制消息资源是持久还是暂态的。聊天历史存储和访问是资源模型中暗含的。文本馈送微件可在页面上显示诸如论坛发贴或评论之类的消息的任何列表。文本聊天微件包括流行的即时消息传递器特征，例如表情和使用数据资源模型的文件共享。此外，用户可将文件从桌面拖动到此微件以将其与其他连接的用户共享。文件内容被封装为聊天消息资源中的数据URL，而没有显式的文件共享协议。

继续参考图8，对话微件包括用于完整的多媒体对话的会议、文本聊天、视频和名册。与会议微件类似，对话微件定义了根资源路径和myid来分别预订和加入会议路径。用户界面允许了音频和视频能力的发起，或者对话中的文本消息的发送。对话微件内的call_type资源属性指示出对话是否具有音频、视频或仅限文本的能力。额外的微件，例如视频、文本聊天、记事本和白板，可被附加到会议或电话微件，或者附加到兼容的扩展以便构建应用。这种附加决定了应用逻辑是使用会议成员的还是电话订户的资源路径。互连多个微件以构建应用的能力是一种创建诸如视频博客、视频在场或者具有交互的在线游戏之类的模块化且可扩展的应用的非常有力且灵活的方式。

在此，可利用图8中的表格188中列出的微件的组合来构建各种应用，例如公共聊天服务。例如，当用户访问网站时，客户端应用加入公共房间的资源，比如/apps/public-chat/public。一个房间具有两个子阵列资源，userlist和chathistory，用于当前参与者的列表和聊天消息。客户端预订这些资源以显示用户名册和聊天历史。公共聊天服务允许了使用video-io微件的固定3x2布局的视频会议。与现有的对称视频会议不同，公共聊天服务允许了非对称的媒体路径，其中每个用户决定该用户想要看到谁和该用户想要听到谁的消息。用户可经由目标用户的资源上的直接NOTIFY而不是chathistory上的POST来向目标用户发送私密消息。

除了公共聊天服务以外，也可利用微件来实现通信器应用。例如，用户注册可创建数据资源，比如/users/namecompany.com。所有的联系人和简档数据，例如在场状态，都根源于这个特定的数据资源下，并且名册微件绑定到用户的联系人。对话微件使得多媒体聊天能够以双方开始并且在用户将更多联系人项目拖动到对话窗口中时扩展到多方。对话绑定到消息线程资源，从而允许了对话的合并，其中从用户对于其已经具有对话的人接收的新的进入线程被与现有的对话合并。然而，用户简档和对话数据不受单个应用控制。例如，在场图标被绑定到目标的在场资源，并且可被嵌入在其他地方，例如公司目录或者用户的主页。点击该图标将打开与目标的通信器无缝交互的对话微件，因为两个应用都共享相同的数据资源设计。

此外，利用图8中的表格188中列出的微件也可创建视频在场应用。例如，视频在场网页可基于由拥有者管理的阵列资源路径来示出联系人的列表。列表中的每个项目是来自该联系人的实况视频馈送。拥有者可点击联系人的视频以发起语音(和文本)呼叫。这种应用在列表项目中使用video-io微件，并且在呼叫中使用会议、邀请者、文本聊天和一个或多个audio-io微件。另外，利用类似的微件可构建个人墙应用。例如，个人墙可用作企业社交网络，其中用户访问另一用户的墙以张贴消息或者共享日历事件、名片或者文件。所有这种共享的数据都是具有关联的访问权限的资源。此外，也可添加企业数据的情境式共享。例如，当用户A访问用户B的墙时，用户A可看到他们在该应用外部进行的最后几个对话和共享的文件。先前描述的应用相当地小，具有不到一千至几千行代码，但示范了可利用数据资源模型构建的许多种应用。

图9提供了适于执行来自示范性计算机可读介质的指令以执行本文描述的功能的采取示范性计算机系统192的示范性形式的处理系统190的示意图表示。在此，处理系统190可包括计算机系统192，在该计算机系统192内可执行用于使得处理系统190执行本文论述的方法中的任何一种或多种的一组指令。处理系统190可连接到(作为非限制性示例，联网到)局域网(LAN)、内联网、外联网或因特网中的其他机器。处理系统190可在客户端-服务器网络环境中操作，或者作为对等(或分布式)网络环境中的对等机器操作。虽然只图示了单个处理系统190，但术语“控制器”和“服务器”也应被理解为包括单独或联合执行一组(或多组)指令以执行本文论述的方法中的任何一种或多种的机器的任何集合。处理系统190可以是服务器、个人计算机、桌面型计算机、膝上型计算机、个人数字助理(PDA)、计算平板、移动设备或者任何其他设备，并且作为非限制性示例可表示服务器或用户的计算机。

示范性计算机系统192包括处理设备或处理器194、主存储器196(作为非限制性示例，只读存储器(ROM)、闪存、诸如同步DRAM(SDRAM)之类的动态随机访问存储器(DRAM)，等等)以及静态存储器198(作为非限制性示例，闪存、静态随机访问存储器(SRAM)，等等)，它们可经由总线200与彼此通信。或者，处理设备194可直接地或经由某种其他连通手段连接到主存储器196和/或静态存储器198。

处理设备194表示一个或多个处理设备，例如微处理器、中央处理单元(CPU)，等等。更具体而言，处理设备194可以是复杂指令集计算(CISC)微处理器、精简指令集计算(RISC)微处理器、超长指令字(VLIW)微处理器、实现其他指令集的处理器、或者实现指令集的组合的处理器。处理设备194被配置为执行指令202和/或缓存的指令204中的处理逻辑以便执行本文论述的操作和步骤。

计算机系统192还可包括网络接口设备206形式的通信接口。其还可以包括或不包括输入208来接收在执行指令时要传达给计算机系统192的输入和选择。其还可以包括或不包括输出210，输出210包括但不限于(一个或多个)显示器212、视频显示单元(作为非限制性示例，液晶显示器(LCD)或阴极射线管(CRT))、字母数字输入设备(作为非限制性示例，键盘)、光标控制设备(作为非限制性示例，鼠标)、和/或触摸屏设备(作为非限制性示例，平板输入设备或屏幕)。

计算机系统192可以包括或不包括数据存储设备214，数据存储设备214包括利用(一个或多个)驱动器216来将本文描述的功能存储在计算机可读介质218中，在计算机可读介质218上存储有实现本文描述的方法或功能中的任何一种或多种的一组或多组指令220(例如软件)。一组或多组指令220在其被计算机系统192执行期间也可完全或至少部分地驻留在主存储器196内和/或处理设备194内，主存储器196和处理设备194也构成机器可访问存储介质。还可经由网络接口设备206通过网络222来发送或接收指令202、204和/或220。网络222可以是内联网或互联网。

虽然计算机可读介质218在示范性实施例中被示为单个介质，但术语“机器可访问存储介质”应当被理解为包括存储一组或多组指令的单个介质或多个介质(作为非限制性示例，集中式或分布式数据库，和/或关联的缓存和服务器)。术语“机器可访问存储介质”还应当被理解为包括任何能够存储、编码或承载一组指令来供机器执行的介质，该组指令使得机器执行本文公开的实施例的方法之中的任何一种或多种。术语“机器可访问存储介质”相应地应当被理解为包括但不限于固态存储器以及光介质和磁介质。

根据本文公开的实施例的在企业系统内提供数据资源服务以用于多个应用之间的资源级共享以及相关方法、系统和计算机可读介质可设于任何基于处理器的设备中或者被集成到任何基于处理器的设备中。示例——而非限制——包括机顶盒、娱乐单元、导航设备、通信设备、固定位置数据单元、移动位置数据单元、移动电话、蜂窝电话、互联网电话、计算机、便携式计算机、桌面型计算机、个人数字助理(PDA)、监视器、计算机监视器、电视、调谐器、卫星无线电装置、音乐播放器、数字音乐播放器、便携式音乐播放器、数字视频播放器、视频播放器、数字视频盘(DVD)播放器和便携式数字视频播放器。

本领域技术人员还将明白，联系本文公开的实施例描述的各种说明性逻辑块、模块、电路和算法可实现为电子硬件、存储在存储器中或另外的计算机可读介质中并且被处理器或其他处理设备执行的指令，或者两者的组合。作为非限制性示例，本文描述的仲裁器、主设备和从设备可使用在任何电路、硬件组件、集成电路(IC)或IC芯片中。本文公开的存储器可以是任何类型和大小的存储器并且可被配置为存储所期望的任何类型的信息。为了清楚说明这个可互换性，各种说明性组件、块、模块、电路和步骤在上文中被就其功能加以了概括描述。如何实现这种功能取决于特定的应用、设计选择和/或施加在整体系统上的设计约束。本领域技术人员对于每个特定应用可按不同方式实现描述的功能，但这种实现决策不应当被解读为导致脱离本公开的范围。

联系本文公开的实施例描述的各种说明性逻辑块、模块和电路可以用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或者其他可编程逻辑器件、分立门或晶体管逻辑、分立硬件组件或者被设计为执行本文描述的功能的其任何组合来实现或执行。处理器可以是微处理器，但在替换方案中，处理器可以是任何传统的处理器、控制器、微控制器或者状态机。处理器也可实现为计算设备的组合，作为非限制性示例，可实现为DSP和微处理器的组合、多个微处理器、与DSP核心联合的一个或多个微处理器、或者任何其他这种配置。

本文公开的实施例可实现为硬件和存储在硬件中的指令，并且可驻留在作为非限制性示例的如下介质中：随机访问存储器(RAM)、闪存、只读存储器(ROM)、电可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)、寄存器、硬盘、可移除盘、CD-ROM或者任何其他形式的本领域已知的计算机可读介质。示范性存储介质耦合到处理器，以使得处理器可从存储介质读取信息并向存储介质写入信息。在替换方案中，存储介质可以与处理器一体。处理器和存储介质可驻留在专用集成电路(ASIC)中。ASIC可驻留在远程站中。在替换方案中，处理器和存储介质可作为分立的组件驻留在远程站、基站或服务器中。

还要注意，本文在任何示范性实施例中描述的操作步骤是为了提供示例和论述而描述的。所描述的操作可以按除了所说明的序列以外的许多不同的序列执行。另外，在单个操作步骤中描述的操作可实际上在多个不同步骤中执行。此外，在示范性实施例中论述的一个或多个操作步骤可被组合。要理解，在流程图中图示的操作步骤可经历本领域技术人员容易清楚的许多不同修改。本领域技术人员还将会理解，信息和信号可利用多种不同的科技和技术中的任何一种来表示。作为非限制性示例，以上描述中各处可提及的数据、指令、命令、信息、信号、比特、符号和芯片可由电压、电流、电磁波、磁场或粒子、光场或粒子或者其任何组合来表示。

提供以上对本公开的描述是为了使得任何本领域技术人员能够作出或使用本公开。本领域技术人员将容易清楚对本公开的各种修改，并且本文定义的一般原理可应用到其他变体，而不脱离本公开的精神或范围。从而，本公开并不打算限于本文描述的示例和设计，而是应符合与本文公开的原理和新颖特征一致的最宽范围。

Claims (10)

1.一种用于在企业系统内提供数据资源服务以在多个应用之间进行资源级共享的方法，包括：

接收来自具有位于企业系统外部的应用逻辑的web应用的对于访问存储在所述企业系统内的存储器中的用户数据的用户数据请求；

响应于来自所述web应用的所述用户数据请求而访问存储在所述企业系统内的存储器中的用户数据；以及

响应于所述用户数据请求而向所述web应用提供对存储在所述企业系统内的存储器中的用户数据的访问。

2.如权利要求1所述的方法，还包括：

从用户接收具有用户数据的用户数据更新；以及

将所述用户数据更新内的用户数据存储在所述企业系统内的存储器中。

3.如权利要求2所述的方法，还包括：

将所述企业系统内的存储器中的用户数据更新通知给对所述用户数据的多个订户。

4.如权利要求1所述的方法，其中，与所述用户数据请求相关联并被存储在所述企业系统内的存储器中的用户数据是为与提供所述用户数据请求的web应用不同的web应用而创建的。

5.如权利要求1所述的方法，还包括：

审核与所述用户数据相关联的至少一个访问权限；以及

如果与所述用户数据相关联的至少一个访问权限允许使用所述web应用的用户访问所述用户数据，则响应于所述用户数据请求而向所述web应用提供对所述用户数据的访问。

6.如权利要求5所述的方法，还包括：

审核与所述用户数据相关联的至少一个访问权限；以及

如果与所述用户数据相对应的至少一个访问权限不允许使用所述web应用的用户访问所述用户数据，则不响应于所述用户数据请求而向所述web应用提供对所述用户数据的访问。

7.如权利要求1所述的方法，还包括使用多个Web实时通信(WebRTC)应用，其中每个WebRTC应用被配置为充当所述web应用。

8.一种用于在企业系统内提供数据资源服务以在多个应用之间进行资源级共享的系统，包括：

企业系统内的存储器，被配置为存储用户数据；以及

数据资源服务器，被配置为：

接收来自具有位于所述企业系统外部的应用逻辑的web应用的对于访问存储在所述企业系统内的存储器中的用户数据的用户数据请求；

响应于来自所述web应用的所述用户数据请求而访问存储在所述企业系统内的存储器中的用户数据；以及

响应于所述用户数据请求而向所述web应用提供对存储在所述企业系统内的存储器中的用户数据的访问。

9.如权利要求8所述的系统，其中，所述数据资源服务器进一步被配置为：

从用户接收具有用户数据的用户数据更新；以及

将所述用户数据更新内的用户数据存储在所述企业系统内的存储器中。

10.如权利要求8所述的系统，其中，与所述用户数据请求相关联并被存储在所述企业系统内的存储器中的用户数据是为与提供所述用户数据请求的web应用不同的web应用而创建的。