CN102279748A - 远程存储本地执行的软件使用方法、系统、服务器及客户端 - Google Patents

Abstract

本发明提供一种远程存储本地执行的软件使用方法、系统、服务器及客户端。所述软件运程存储于云端并能够在本地客户端执行，该方法包括：步骤一：确定按需软件运行时所需要的软件资源，步骤二：采用用户层文件系统将远程存储于云端的按需软件的存储位置加载为本地客户端的一个虚拟文件系统以至于在本地客户端直接启动按需软件。使得现有软件不用修改源代码就能够远程存储、本地(客户端)运行，实现兼容性与高性能的兼得。

Description

远程存储本地执行的软件使用方法、系统、服务器及客户端

一、技术领域

本发明涉及云计算应用领域，尤其涉及一种远程存储本地执行的软件使用方法、系统、服务器及客户端。

二、背景技术

云计算就是一种通过互联网向使用者提供IT资源的应用模式。在这一模式中，使用者如何利用“云”端提供的资源是决定云计算应用前景的关键技术之一。在现阶段，云计算应用的客户端到云解决方案主要有远程虚拟机访问、Web应用与中间件应用三种模式，尤其以前两大模式为主。但这些模式存在兼容性与高性能不可兼得的问题，限制了云计算的推广使用。

远程虚拟机访问模式，如Amazon提供的EC2，就是在云计算中心运行各类虚拟机以及虚拟机上的应用软件，并通过远程桌面访问协议来给用户提供访问与使用接口。一方面，用户可以灵活的按需部署其所需的虚拟机资源；同时因为虚拟机屏蔽了底层硬件系统的差异，所以这一模式可以兼容现有软件，即用户可以通过远程虚拟机访问模式来使用云端的现有软件资源。但另一方面，在这一模式下虚拟机及其上的软件实际上是运行在云计算中心的服务器上(简称云端，下同)，用户所在的客户端仅仅是作为一个图形界面来使用，这样就存在着网络响应延迟以及远程集中计算所可能引起的性能降低问题，尤其是前者对于桌面软件的操作而言是致命的，而且难以通过高速网络建设来解决——延迟主要取决于网络传输经过的hop数目，而不仅仅是带宽。

Web模式，如Google App Engine，则是以客户端的浏览器为主要运行平台，通过一系列Web 2.0程序(与云端相配合)来提供全面的应用解决方案，著名的有G oogleDoc&SpreadSheet，Web OS等。这样，应用是运行在本地浏览器上，性能较高，但是现有的软件却无法被直接使用，需要重新开发，因此兼容性不好。

中间件应用模式以微软推出的Azure云计算服务平台为代表，用户需要采用.Net技术来实现基于该平台的应用(不限于web应用)，因此同样存在着兼容性问题。

由此可见，现有模式存在应用兼容性与运行高性能不可兼得的问题，限制了云计算的推广使用。

三、发明内容

基于这些现有模式的分析，本发明提出了一种新的软件使用方法、系统、服务器及客户端，使得现有软件不用修改源代码就能够远程存储(在云端)、本地(客户端)运行，实现兼容性与高性能的兼得。

根据本发明的第一方面，提供一种远程存储本地执行的软件使用方法，所述软件运程存储于云端并能够在本地客户端执行，该方法包括：

步骤一：确定按需软件运行时所需要的软件资源，其中按需软件被定义为无需将所述软件运行所需要的软件资源注入到本地客户端操作系统就能在本地客户端运行；

其中所述软件资源包括以下三个部分：

第一部分，所有由本地客户端操作系统提供的已有软件资源；

第二部分，软件运行过程所创建、修改的软件资源；

第三部分，软件运行过程中创建新的软件资源或者修改的第一和/或第二部分的软件资源，

其中第一部分软件资源由本地客户端操作系统提供，且该操作系统为初始安装的操作系统；

其中第二部分软件资源通过在上述初始安装的操作系统上安装目标软件，记录下安装过程所创建、修改的软件资源并将其单独存储而提供；

第三部分软件资源按照如下方式获得，通过使用系统调用插装显示用户层虚拟化运行环境，从而实时截获所述软件运行时的系统调用，并将系统调用重定向到软件资源的实际存储位置，

步骤二：采用用户层文件系统将远程存储于云端的按需软件的存储位置加载为本地客户端的一个虚拟文件系统从而可以在本地客户端直接启动按需软件。

根据本发明第一方面，其中用户层文件系统定义为在系统内核空间插入文件系统过滤驱动，截获所有的文件系统访问请求，将其中的访问目标位于虚拟文件系统上的所有访问请求重定向到用户空间，由用户层文件系统来完成实质的数据/元数据访问于操作。

根据本发明第一方面，其中用户层虚拟化运行环境定义为：在本地客户端操作系统之上通过系统调用包裹，在应用与系统之间实现一个虚拟层，由该虚拟层来重新实现或者扩展原有的系统调用，从而实现不同的功能，其中通过应用程序透明插装来实现应用层虚拟化，对可迁移软件的相关软件资源访问API进行包裹，实现虚拟资源层。

根据本发明第一方面，其中所述虚拟资源层对各类软件资源进行如下访问操作：

(1)所有读取操作都在存储的当前位置完成；

(2)如果是修改操作，则采取Copy-on-Write机制，即首先将被修改的软件资源移至第三部分软件资源所在的位置，再进行修改，从而避免对于本地资源的直接修改；

(3)浏览或者枚举操作则分别列出这三个部分的相关内容并进行合并；如果有重复项，其优先级从高往低依次是：第三部分、第二部分、第一部分。

根据本发明第二方面，提供一种远程存储本地执行的软件使用系统，所述软件运程存储于云端并能够在本地客户端执行，该系统包括：

第一装置，用于确定按需软件运行时所需要的软件资源，其中按需软件被定义为无需将所述软件运行所需要的软件资源注入到本地客户端操作系统就能在本地客户端运行；

其中所述软件资源包括以下三个部分：

第一部分，所有由本地客户端操作系统提供的已有软件资源；

第二部分，软件运行过程所创建、修改的软件资源；

第三部分，软件运行过程中创建新的软件资源或者修改的第一和/或第二部分的软件资源，

其中第一部分软件资源由本地客户端操作系统提供，且该操作系统为初始安装的操作系统；

其中第二部分软件资源通过在上述初始安装的操作系统上安装目标软件，记录下安装过程所创建、修改的软件资源并将其单独存储而提供；

其中第三部分软件资源按照如下方式获得，通过使用系统调用插装显示用户层虚拟化运行环境，从而实时截获所述软件运行时的系统调用，并将系统调用重定向到软件资源的实际存储位置，

第二装置，用于采用用户层文件系统将远程存储于云端的按需软件的存储位置加载为本地客户端的一个虚拟文件系统从而可以在本地客户端直接启动按需软件。

根据本发明第二方面，其中用户层文件系统定义为在系统内核空间插入文件系统过滤驱动，截获所有的文件系统访问请求，将其中的访问目标位于虚拟文件系统上的所有访问请求重定向到用户空间，由用户层文件系统来完成实质的数据/元数据访问于操作。

根据本发明第二方面，其中用户层虚拟化运行环境定义为：在本地客户端操作系统之上通过系统调用包裹，在应用与系统之间实现一个虚拟层，由该虚拟层来重新实现或者扩展原有的系统调用，从而实现不同的功能，其中通过应用程序透明插装来实现应用层虚拟化，对可迁移软件的相关软件资源访问API进行包裹，实现虚拟资源层。

根据本发明第二方面，其中所述虚拟资源层对各类软件资源进行如下访问操作：

(1)所有读取操作都在存储的当前位置完成；

(2)如果是修改操作，则采取Copy-on-Write机制，即首先将被修改的软件资源移至第三部分软件资源所在的位置，再进行修改，从而避免对于本地资源的直接修改；

(3)浏览或者枚举操作则分别列出这三个部分的相关内容并进行合并；如果有重复项，其优先级从高往低依次是：第三部分、第二部分、第一部分。

根据本发明第三方面，提供一种应用本发明第二方面的服务器。

根据本发明第四方面，提供一种应用本发明第二方面的客户端。

本发明技术方案的技术效果如下：

本发明提出了一种新的软件使用模式，使得现有软件不用修改源代码就能够远程存储、本地(客户端)运行，实现兼容性与高性能的兼得。

一方面，用户可以以使用本地软件的模式来直接使用这些存储在远程的软件；另一方面，软件本地运行，能够充分客户端的处理能力，降低服务端负载；再者，因为软件存储在远程，用户可以在不同的机器上使用其习惯使用的软件而无需安装。

四、附图说明

图1示意性示出了按需软件运行时候所需要的软件资源及用户层虚拟化运行环境框图；

图2示意性示出了根据本发明所述方法的流程图；

图3示意性示出了根据本发明所述系统的框图；

图4示意性示出了根据本发明的用户层文件系统的数据访问；

图5示意性示出了根据本发明的用户层虚拟化环境中应用程序操作注册表的流程图，以及

图6示意性示出了根据本发明的用户层虚拟化环境中应用程序操作注册表的另一流程图。

五、具体实施方式

接下来，将参考图1-6对本申请进行详细的描述。本领域技术人员应该清楚，本发明不限于这些示出的实施方式，而是本发明还包括各种修改和实施方式。因此，应将本描述看作示范性而非限制性。虽然易于对本发明进行各种修改和替换构造，但是应该理解，不存在将本发明限制到具体公开形式的意图，相反，本发明覆盖落在如由权利要求书限定的本发明的精神和范围内的修改、替换构造和等同物。

实现软件存储于云端(称之为远程软件，下同)并能够在本地运行这一方案的关键在于分离软件的运行环境与存储位置(分别在客户端与云端)，使得现有软件不修改代码，就能够透明的访问非本地资源，且完全在本地运行。为实现这一方案，需要解决两个关键问题：

(一)解决现有软件无需安装就能运行的问题。

(二)解决这类软件在网络环境下的透明使用问题。

(一)解决现有软件无需安装就能运行的问题是整个方案的前提。

一般情况下，大多数软件需要在本地安装后才能运行。而在上述的远程虚拟机模式或者Web模式中，使用者均不需要在本地实际安装所需使用的软件，而是通过远程客户端软件或者浏览器来使用云端提供的软件应用。因此在本模式中必须实现软件无需安装就能本地执行的功能。

软件安装的过程实际上就是把软件运行所需的资源注入到操作系统中。可以确定，只要能够让软件完全透明地访问到这些资源，软件不用安装就可以运行。

一般而言，一个软件运行所关系到的软件资源(对于Windows系统，资源一般指文件与注册表；而对于Linux等系统，则主要是文件资源)可分为三个部分：

(1)第一部分指的是所有由本地操作系统提供的已有资源(而不是新安装的)；

(2)第二部分包含软件安装过程所创建、修改的资源；

(3)软件运行过程中会创建新资源或者修改1)与2)的资源，这些被归为第三部分。

因此，要使得软件不用安装就能在本地运行(这些软件称为按需软件，下同)，其必须能够在不安装的前提下可以直接访问到这三部分资源，本文称之为“按需访问”。这样就可以把问题1)的解决方案分成两步，一是分离出这三个部分；二是使之可按需访问。

本发明只支持用户在兼容的计算机上使用，所以客户端操作系统默认为可以提供第一部分资源，无需对其做特殊处理；对于第二部分，本发明采用软件安装监控的方法——在一个新安装的操作系统上安装目标软件，记录下安装过程所创建/修改的资源并将其单独存储，从而可以获得完整的第二部分。

对于第三部分，使用系统调用插装的方法实现用户层的虚拟化运行环境，从而可以实时截获软件运行实例的系统调用，并将系统调用重定向到资源的实际存储位置，也即这一部分的分离与按需访问是一并实现的。详细介绍如下：

用户层虚拟化运行环境，指的是在操作系统之上通过系统调用包裹等方法，在应用与系统之间实现一个虚拟层，由该虚拟层来重新实现或者扩展原有的系统调用，从而实现不同的功能。此处所需的主要功能是对于软件各部分资源的按需访问。

本发明采用应用程序透明插装的方法实现应用层虚拟化，对可迁移软件的相关资源访问API(如文件/目录/注册表相关的系统调用)等进行包裹，实现虚拟资源层。

这一虚拟资源层对各类资源访问的处理流程是：

(1)所有读取操作都在存储的当前位置完成；

(2)如果是修改操作，则采取Copy-on-Write机制，即首先将被修改的资源移至第三部分所在的位置，再进行修改，从而避免对于本地资源的直接修改；

(3)浏览或者枚举操作则分别列出这三个部分的相关内容并进行合并；如果有重复项，其优先级从高往低依次是：第三部分、第二部分、第一部分。

具体的“应用程序透明插装的方法”详见本发明优选实施例的说明。

(二)解决这类软件在网络环境下的透明使用问题。

接下来需要解决的问题就是如何对用户提供一个透明、友好的界面来访问与操作“按需软件”。本发明采用用户层文件系统技术来提供解决方案，其将远程的按需软件的存储位置加载为客户端本地的一个虚拟文件系统，这种方式对于使用者与软件而言都是透明的。

用户层文件系统一般是指在系统内核空间插入文件系统过滤驱动，截获所有的文件系统访问请求，将其中的访问目标位于虚拟文件系统上的所有访问请求重定向到用户空间，由一个用户层文件系统程序来完成实质的数据/元数据访问与操作。这种方式的优点在于其开发工作可以避开复杂的内核编程而在用户空间实现，而且与操作系统的耦合度较小，如图2所示。

本发明的用户层文件系统的总体运行策略是：

1)读操作会被定向到远程位置以获取数据；

2)对于任何写操作，Copy-on-Write机制被触发：整个目标文件将会从远程被取回来，缓存于本地，后续操作会直接针对这个本地版本进行。

具体的“用户层文件系统实现方法”详见本发明优选实施例的说明。

本发明优选实施例

针对Windows应用软件，本发明的一个实施例如下：

运行环境：客户端是一台安装有Windows XP的PC机；远程的用于存储按需软件的服务器是一台运行Windows 2003 Server的X86服务器，安装有Apache Web服务。两者间通过互联网连接。

支持的远程软件：OpenOffice、VLC、7Zip、UltraEdit、ClamWin(反病毒程序)、FileZilla、Gimp开源的图形编辑器)、Coolplayer等

具体的实施流程如下——

1)确定软件运行时所需的资源

软件运行所需要的资源(指的是第二部分资源)，就是软件安装后的系统与原系统的差集，必须把这个集合成功地抽取出来。

为实现上述目的，我们在一台刚安装完系统的Windows XP系统上安装软件——在安装前采用系统快照方式，扫描操作系统的资源状态并保存下来；安装后，再扫描一次，并与安装之前的快照进行比较，从而可以得到软件安装过程中对操作系统的修改，并将修改分为文件系统资源与注册表资源两类，分别单独存储起来。

具体的存储方式为：

假设安装一个名为AppA的软件，其默认的安装目录为C：\program file\AppA，并且在系统注册表的\HKEY_CURRENT_USER\Software\AppA下存储了其注册表资源。那么通过快照方式，我们就把其所有安装的文件拷贝到服务器的一个单独目录下，设为d：\远程目录\programfile\AppA；同时将其注册表资源存于一个文件中，放于服务器的d：\远程目录\注册表\AppA目录下。

2)用户层虚拟化的实现

为程序构建用户层虚拟化环境的关键在于对其访问相关资源的系统调用的截获与插装，这些系统调用包括对文件、注册表等系统配置、资源的访问。仍以AppA为例，因为我们不对AppA程序本身进行修改(所谓兼容性就体现在这儿)，这样AppA运行的时候就会在\HKEY_CURRENT_USER\Software\AppA下访问其注册表资源(文件资源也是类似)，如果不处理的话访问肯定是失败的(因为客户端上没有安装，实际的资源在服务器上)。

这就要对这些系统调用进行包裹，并且使这个过程对程序本身透明。本实施例在应用程序的执行文件中插入代码，通过重写所要包裹的系统调用在文件中的入口来实现系统调用插装。这样一旦应用程序使用此调用，就会先进入插入的代码，由后者进行适当的处理后再调用真正的系统函数或直接返回。微软的开发工具Detours可以通过为目标函数重写在内存中的代码从而截获win32系统调用以实现这一功能，其他类似的工具还有不少。

适当的处理流程的梗概已在前述内容给出给出，不是一般性，这儿以注册表访问为例来给出详细流程：

本实施例对软件安装时修改的注册表项进行分类处理。一种是向系统注册表添加的注册表项，把这一类记作Added_Registry；另一种是对系统注册表已有项进行修改，把这一类记作Modified_Registry。两者的内容统称为Private_Registry。

本实施例实现了一组针对Private_Registry操作的调用接口(以MyReg_XXXX()表示)，以Private表示Private_Registry，Local表示Windows Registry，RealReg_XXX()表示原装的Windows系统调用。

本实施例主要包裹Windows中与注册表相关的部分API，基本涵盖了应用程序对注册表的所有操作。我们针对应用程序操作注册表对象的属性，选择不同的操作策略。

如图5所示，注册表操作为读操作(包括RegQueryValue、RegEnumKey、RegEnumValue、RegQueryInfoKey)，若操作对象存在于私有配置中，则调用MyReg__XXX()；若操作对象存在于Modified_Registry，则在必要时需要同时操作Local和Private，然后返回合并之后的信息；若既不是Added_Registry也不是Modified_Registry，则直接调用RealReg__XXX()操作Local。

如图6所示，若注册表操作为写操作(包括RegCreateKey、RegDeleteKey、RegSetValue。RegDeleteValue等)，则流程与读类似，但删除操作例外。删除的对象为Added_Registry时，直接调用MyReg__XXX()删除Private；删除对象为Modified_Regsitry时，除了删除Private，还需要置一标志位表示该项已被删除；若删除对象为Local，则只是置一标志位表示该项已被删除，并不真正删除此项。

3)用户层文件系统的实现

在本实施例中，用户层文件系统把远程服务器上的存储按需软件的目录映射为本地的一个虚拟盘(如把服务器上的d：\远程目录\program file\映射为本地的X盘)，这样使用者可以像直接启动本地已安装的软件那样，直接启动按需软件。

我们使用针对Windows系统的开源用户层文件系统开发框架DOKAN来实现这一用户层文件系统。DOKAN提供了一个内核文件系统访问过滤模块，同时要求开发者针对其接口开发一个用户层文件系统程序，该程序需要实现一系列的文件访问回调函数(callback function)，其中绝大多数与Windows的文件系统API相对应，包括CreateFile、CloseFile、ReadFile、WriteFILE、FindFiles等。这样一旦内核文件系统访问过滤模块截获到针对X盘的文件访问请求，就可以回调用户层文件系统程序实现的相应函数进行实际的数据处理。

在这个实施例中，远程服务器就是一个普通的HTTP服务器：所有的数据读取，都被转换为HTTP的GET请求。选择HTTP作为后端主要是出于实现简便性考虑，而不是设计上的必须——即也可以使用其他的数据发布机制作为服务端存储。

具体的处理流程如下——

任何一个存储于该用户层虚拟文件系统之上的文件都被赋予一个属性——

●Remote：该文件存于远程服务端；

●New：该文件是新建的或者是被修改过的；

●Deleted：已被删除。

当某个用户的文件系统第一次被启动时，所有的文件与目录都被认为具有remote属性，即存储在服务端。在运行过程中，当任何文件/目录被删除时，这些文件/目录属性会被设为deleted(而不是物理上被删除)。任何修改或者新创建的文件则会被至为new。特别的，当某一远程文件被修改时，它会首先被下载到本地缓存，后续操作将针对此本地版本进行。

用户层虚拟文件系统的整个运行过程如下所述：

●系统初始化

用户选择某一按需软件部署后，虚拟文件系统首先下载这个按需软件的元数据包。后者包括该软件的所有文件、目录的层次结构信息、路径名、以及文件属性(大小、访问权限、时间戳等)。因为服务端实际上是个只读存储，这类元数据包可以事先在服务端压缩好，以随时访问。原型系统的测试表明，元数据包压缩后的尺寸非常有限：系统中的所有按需软件共有约11600个文件(包括目录)，包压缩后的大小为190KB。

下载完成后，虚拟文件系统程序会在本地某个事先指定的位置创建一个“锚文件目录”(anchor folders)：在这一目录下，按需软件所有的文件(包括目录)均会被创建，其目录结构、名字、文件属性均与服务端的一样；唯一的区别在于所有的“锚文件”都是空的。

与前一工作比较，这一设计的优点在于所有与文件元数据相关的操作(如SetFileAttributes/GetFileAttributes/SetFileTime/FindxxxFile等)可以直接在“锚文件系统”上完成，使得虚拟文件系统程序专注于处理数据操作；同时，“锚文件”也可以直接作为相应文件的缓存以简化其管理。

●运行时

总的设计原则是：服务端的内容为只读；客户端采用Copy-on-write机制，即任何用户使用软件过程中的修改都存于本地的锚文件系统，包括新文件/新目录以及修改的原有远程文件。几个主要函数的操作流程如下：

(1)CreateFile

如果一个新的文件被创建，则其被赋予new属性，且存于锚文件目录中；

如果一个remote文件被打开且被清空，其被赋予new属性，原先的remote属性无效，该文件存于锚文件目录中；

如果一个属性为new的文件被打开，那么所有的后续操作都会在本地完成；

如果是一个remote文件被打开，后续操作如何完成取决于其操作的具体类型。

(2)WriteFile

如果是针对属性为new的文件，则写入的内容保存在本地(的锚文件目录中)。

如果是针对remote文件，则整个文件会首先被下载到本地缓存，后续操作将针对此本地版本进行，其属性置为new。

(3)ReadFile

如果是针对属性为new的文件，则在本地完成读取。

如果是针对remote文件，那么就从远程服务器读取，而且数据会缓存在本地，以便下次使用。

(4)FindFiles

因为所有的元数据信息已经提前获得，而且所有的new属性文件都在本地，所以这个操作可以直接在锚文件目录中完成。

●系统退出

用户层文件系统退出时，所有的“锚文件系统”内容以及所有的文件属性都会被保存在客户端本地以便下次使用。

●本地缓存

为管理方便起见，所有远程文件访问的数据大小与起始位置都被设为8KB的整数倍，而所获取的数据块(8KB的整数倍)都将被缓存在本地(即锚文件目录中)。

本地缓存(锚文件目录)保存有二类数据，一是具有new属性文件的数据(即属于本地修改的或者新创建的文件)；二是具有remote属性文件的缓存于本地的数据。第一类数据实际上就是一个完整的文件，可以对其进行直接的文件层次访问；重点是第二类数据——本实施例维护了单独的缓存信息，以文件的全路径名为键值，建立一个Hash表，来记录哪些文件的哪些数据块已被缓存。进一步的，每个文件的历史访问信息都被记录下来。当本地缓存的总容量接近系统预设的上限时，会向用户提出警告以扩大容量，或者采用LRU策略来删除文件以腾出空间；但是第一类数据是不会被删除的。

4)性能测试

在上述的运行环境下部署了本实施例，这样使用者就可以以使用本地软件的模式来直接使用按需软件。

测试表明，如果客户端与服务器都部署在某大学的校园网内，那么在客户端本地缓存为空(相当于是这个系统第一次运行)时，按需软件启动时间被大大延长：平均是基准时间(即如果相同的软件被安装在本地，直接启动)的7.65倍。这是因为本地缓存为空，导致大量的虚拟文件系统访问被转换为远程HTTP访问。

而在运行测试中，这一状况好了很多：运行时间平均被延长约87％。这是因为启动过程缓存了大量数据。

一次运行后，再次运行一遍并记录时间(相当于在缓存已填充的情况下运行)。这一测试情况好了很多：启动时间被延长了约90％；而运行时的额外时间开销仅为12％。这明显归功于第一次运行已将大部分所需数据填入了本地缓存，使得远程数据访问次数大大降低。

另外，第一次运行后本地缓存的容量为260MB，而所有测试软件的总的大小为900MB。本发明技术方案带来的有益效果

本发明提出了一种新的软件使用模式，使得现有软件不用修改源代码就能够远程存储、本地(客户端)运行，实现兼容性与高性能的兼得。

一方面，用户可以以使用本地软件的模式来直接使用这些存储在远程的软件；另一方面，软件本地运行，能够充分客户端的处理能力，降低服务端负载；再者，因为软件存储在远程，用户可以在不同的机器上使用其习惯使用的软件而无需安装。

本发明的技术关键点

●采用用户层虚拟化技术在不改变软件的前提下，实现了其运行时访问所需资源的重定向；

●采用虚拟文件系统技术，使得按需软件在网络环境下的能被直接使用；

●采用Copy-on-write技术与本地缓存技术，使得运行时按需软件的修改以及经常访问的数据被缓存于本地，提升了实际的使用性能。

虽然已经示出并描述了本发明的各种优选实施方式，但是应当清楚地理解本发明不限于此，而是可以多样地具体化在以下权利要求书的范围内实现。根据上述描述，应当理解可以进行各种改变而不脱离如由权利要求书限定的本发明的精神和范围。

Claims (10)

1.一种远程存储本地执行的软件使用方法，所述软件运程存储于云端并能够在本地客户端执行，该方法包括：

步骤一：确定按需软件运行时所需要的软件资源，其中按需软件被定义为无需将所述软件运行所需要的软件资源注入到本地客户端操作系统就能在本地客户端运行；

其中所述软件资源包括以下三个部分：

第一部分，所有由本地客户端操作系统提供的已有软件资源；

第二部分，软件运行过程所创建、修改的软件资源；

第三部分，软件运行过程中创建新的软件资源或者修改的第一和/或第二部分的软件资源，

其中第一部分软件资源由本地客户端操作系统提供，且该操作系统为初始安装的操作系统；

其中第二部分软件资源通过在上述初始安装的操作系统上安装目标软件，记录下安装过程所创建、修改的软件资源并将其单独存储而提供；

其中第三部分软件资源按照如下方式获得，通过使用系统调用插装显示用户层虚拟化运行环境，从而实时截获所述软件运行时的系统调用，并将系统调用重定向到软件资源的实际存储位置，

步骤二：采用用户层文件系统将远程存储于云端的按需软件的存储位置加载为本地客户端的一个虚拟文件系统从而可以在本地客户端直接启动按需软件。

2.如权利要求1所述的方法，其中用户层文件系统定义为在系统内核空间插入文件系统过滤驱动，截获所有的文件系统访问请求，将其中的访问目标位于虚拟文件系统上的所有访问请求重定向到用户空间，由用户层文件系统来完成实质的数据/元数据访问操作。

3.如权利要求1所述的方法，其中用户层虚拟化运行环境定义为：在本地客户端操作系统之上通过系统调用包裹，在应用与系统之间实现一个虚拟层，由该虚拟层来重新实现或者扩展原有的系统调用，从而实现不同的功能，其中通过应用程序透明插装来实现应用层虚拟化，对可迁移软件的相关软件资源访问API进行包裹，实现虚拟资源层。

4.如权利要求3所述的方法，其中所述虚拟资源层对各类软件资源进行如下访问操作：

(1)所有读取操作都在存储的当前位置完成；

(2)如果是修改操作，则采取Copy-on-write机制，即首先将被修改的软件资源移至第三部分软件资源所在的位置，再进行修改，从而避免对于本地资源的直接修改；

(3)浏览或者枚举操作则分别列出这三个部分的相关内容并进行合并；如果有重复项，其优先级从高往低依次是：第三部分、第二部分、第一部分。

5.一种远程存储本地执行的软件使用系统，所述软件运程存储于云端并能够在本地客户端执行，该系统包括：

第一装置，用于确定按需软件运行时所需要的软件资源，其中按需软件被定义为无需将所述软件运行所需要的软件资源注入到本地客户端操作系统就能在本地客户端运行；

其中所述软件资源包括以下三个部分：

第一部分，所有由本地客户端操作系统提供的已有软件资源；

第二部分，软件运行过程所创建、修改的软件资源；

第三部分，软件运行过程中创建新的软件资源或者修改的第一和/或第二部分的软件资源，

其中第一部分软件资源由本地客户端操作系统提供，且该操作系统为初始安装的操作系统；

其中第二部分软件资源通过在上述初始安装的操作系统上安装目标软件，记录下安装过程所创建、修改的软件资源并将其单独存储而提供；

其中第三部分软件资源按照如下方式获得，通过使用系统调用插装显示用户层虚拟化运行环境，从而实时截获所述软件运行时的系统调用，并将系统调用重定向到软件资源的实际存储位置，

第二装置，用于采用用户层文件系统将远程存储于云端的按需软件的存储位置加载为本地客户端的一个虚拟文件系统从而可以在本地客户端直接启动按需软件。

6.如权利要求5所述的系统，其中用户层文件系统定义为在系统内核空间插入文件系统过滤驱动，截获所有的文件系统访问请求，将其中的访问目标位于虚拟文件系统上的所有访问请求重定向到用户空间，由用户层文件系统来完成实质的数据/元数据访问于操作。

7.如权利要求5所述的系统，其中用户层虚拟化运行环境定义为：在本地客户端操作系统之上通过系统调用包裹，在应用与系统之间实现一个虚拟层，由该虚拟层来重新实现或者扩展原有的系统调用，从而实现不同的功能，其中通过应用程序透明插装来实现应用层虚拟化，对可迁移软件的相关软件资源访问API进行包裹，实现虚拟资源层。

8.如权利要求7所述的系统，其中所述虚拟资源层对各类软件资源进行如下访问操作：

(1)所有读取操作都在存储的当前位置完成；

(2)如果是修改操作，则采取Copy-on-Write机制，即首先将被修改的软件资源移至第三部分软件资源所在的位置，再进行修改，从而避免对于本地资源的直接修改；

(3)浏览或者枚举操作则分别列出这三个部分的相关内容并进行合并；如果有重复项，其优先级从高往低依次是：第三部分、第二部分、第一部分。

9.一种应用如权利要求5-8任意所述系统的服务器。

10.一种应用如权利要求5-8任意所述系统的客户端。

Images