专利名称：软件应用中计算逻辑的按需远程执行方法
技术领域：
本发明属于软件技术领域，针对由于从原部署节点所获计算资源不足而导致的软件应用性能低下问题提供一种程序执行优化方法，具体涉及一种软件应用中计算逻辑的按需远程执行方法，适用于软件维护演化。
背景技术：
对计算资源(如CPU、内存等)的按需使用是软件应用增强其性能并改善用户体验的一种主要手段。所谓按需(on-demand)，是指当计算资源不足时，应用可以占有并使用额外的资源，从而保障其高效运行；而当资源过剩时，应用又可以释放掉多余的资源，从而减 少浪费。随着Internet的飞速发展，软件应用所处的环境变得越来越开放。而开放性则进一步促使软件应用需要实现对计算资源的按需使用。例如，随着移动互联网的兴起，越来越多的软件应用被下载运行在不同能力的移动终端上。这些以智能手机为代表的移动终端所拥有的计算资源本身极其有限，常常导致应用性能低下，带来不佳的用户体验。并且由于不同型号的移动终端配置不同，在运行同一应用时也会产生不同的性能效果。因此，只有应用做到按需使用资源才能从根本上缓解开放环境下软硬件不匹配的矛盾，促进用户体验的改
盡
口 o对计算资源按需使用必须同时具备两个条件一是具有额外可用的资源；二是应用可以真正使用到这些资源。在Internet环境下，虽然网络单节点的计算资源仍然有限，然而互连起来的网络节点其整体所拥有的计算资源则极为丰富。当应用需要额外资源时，可以通过网络而获得其他节点所拥有的资源。因而，可以看到，实现对资源按需使用的根本还是在于应用自身。应用对分散资源的使用方式主要有两种复制式使用和分割式使用。复制式的资源使用方式通过对应用进行复制，将副本运行在额外的节点上，并在原应用和其副本前端加上负载平衡器来将用户请求转发到多个应用实例组成的集群上(Chuliang Weng,MingluLi， ZhigangWang, and Xinda Lu， Automatic Performance Tuning for the VirtualizedCluster System,29th IEEEInternational Conference on Distributed ComputingSystems, 2009, pp. 183 190)。这种方式可以有效地应对由于用户请求激增而导致地应用性能急剧下降的情况。然而，该方式的使用范围有限，主要用于web应用，但对于那些完整安装在智能手机等网络节点且与用户直接交互的本地应用来说却不适用。此外，有研究已经指出，这种以整个应用为粒度的复制在较大程度上会造成资源浪费(DuncanJohnston-Watt, Get Smart The Case for Intelligent Application Mobilityin theCloud, the Cloud Computing Journal, 2010)。原因在于,通常情况下不是组成应用的所有模块都急需资源。那些不急需资源但占有资源的模块会与那些真正急需资源的模块相竞争，反而导致资源没有充分被急需资源的模块所用，造成了隐性浪费。有介于此，分割式资源使用将组成应用的模块分别部署在不同的节点上，让那些真正急需资源的模块充分占有计算资源，以此实现对应用性能的保障和对资源的有效利用。在此基础上，又可将两种使用方式相结合，在较细粒度上实现复制式资源使用，以进一步高效地保障应用性能。由此可以看见，应用对计算资源的按需使用要以应用模块的按需分布式部署执行为保障，也就是说，需要实现应用中计算的按需远程执行。当从原有节点所获资源不足，导致应用性能下降时，可将应用中对资源需求较大的一部分计算转移到新获取的网络节点上执行，从而通过占有额外的资源来保障应用的整体性能；而当资源过剩或网络条件不佳导致获取额外资源的难度增大时，又可将计算移回，从而实现对资源的节省并保障应用正常运行。目前实现计算逻辑的远程执行主要有两种方式1)编写分布式应用。将应用中对资源消耗较大的计算在设计和实现时就安排到拥有较多资源的网络节点上运行。然而，由于分布式应用要求开发者处理远程方法调用、序列化、同步等与程序分布相关的问题，因而编写起来通常费时费力。即便是使用分布式中间件，开发者也必须编写特定于中间件但与程序业务逻辑无关的代码，带来相当的编程负担。此外，更重要的是，开发者很难在设计实现时就准确预料到应用对资源的使用，因而所开出的应用程序中的本地/远程调用方式通常固定不变，这就使得应用对资源难以实现真正的按需使用。2)通过程序转换器，自动将给定应用中的程序代码转换后分为两部分一部分继续留在原有节点上运行，而另一部分则被移动到其他网络节点上运行。这两部分之间所需要的跨网络的互操作代码由该转换器以打补丁的方式自动加入到原有应用当中，从而保证了转换后应用的正确运行。这种方式不要求开发者编写与程序分布相关的代码，可极大降低应用开发的难度。然而，现有工作中，一个被转换后应用中代码间的本地/远程调用方式仍然固定不变，导致当资源变化而需要调整计算的本地/远程调用关系时，必须停机、重转换、重启，因而难以实现应用在运行时对资源的按需使用。
发明内容
本发明的目的是提供一种软件应用中计算逻辑的按需远程执行方法，其核心是支持软件应用中的计算逻辑实现按需远程执行的设计模式，其主要手段是通过对软件应用代码进行重构，自动将原始应用转换为符合所提出的设计模式的计算逻辑可按需远程执行的应用。本发明的软件应用中计算逻辑的按需远程执行方法，其步骤包括I)将软件应用的应用类分为执行位置固定类(Anchored)和执行位置可变类(Movable)；2)将所述应用类的程序代码从源结构转换为目标结构；所述目标结构包含代理(Proxy)和端点(Endpoint):所述代理与调用类运行于同一地址空间，负责将方法调用经由所述端点转发至在本地或远程运行的被调用类；所述端点负责识别所述被调用类的当前位置；3)将转换为所述目标结构的应用类封装为原始应用格式的应用和可远程执行的 软件制品，分别部署在原网络节点上和远程网络节点上；4)预测当一应用类远程执行时该应用类所属的软件应用的性能，如果该性能提高，则在远程执行该应用类，否则在本地执行该应用类。进一步地所述源结构包括直接内存调用结构和RCS(Remote CommunicationService，远程通讯服务)远程调用结构；当被调用类在远程运行时，所述端点利用RCS获得对被调用类的远程引用，调用类通过该引用而远程调用被调用类；当被调用类和调用类运行于同一地址空间时，所述端点直接获得对被调用类的内存引用，调用类通过该引用而直接调用被调用类。进一步地，所述软件制品包含执行位置可变类、代理类、端点以及相关资源文件。所述相关资源文件可以是图像文件、XML配置文件等。所述软件制品可以有多个副本分别运行在不同的网络节点上。进一步地，所述软件应用的性能可以采用多种衡量方式，比如可以采用时间开销、吞吐量开销、能耗开销中的一种或多种来衡量。进一步地，本发明可对转换为目标结构的应用类进行聚类，将相互间调用频繁的类在必要时作为一个整体放到远端执行。可以采用静态程序分 析方法或动态程序分析方法进行所述聚类。本发明的方法可作为一款单独的工具或是一款插件而集成到各种软件开发平台(如Eclipse,参见www. eclipse, org)或软件下载平台中(如豌豆夹手机精灵，参见www.wandoujia. com)。通过自动对软件应用的代码进行重构，将其转换为可按需远程执行的程序结构，从而帮助软件应用实现对计算资源的按需占有，以提高性能并改善用户体验。
图I为直接内存调用结构示意图。图2为远程调用结构示意图。图3为计算逻辑可按需远程执行的目标程序结构示意图。图4为实现软件应用中计算逻辑按需远程执行的代码重构步骤的示意图。图5为实现计算逻辑按需远程执行的软件应用的运行时系统结构示意图。
具体实施例方式为使本发明的目的、特征和优点能更明显易懂，下文通过具体实施例并配合附图，作详细的说明。本发明的技术方案包含两部分支持软件应用中计算逻辑实现按需远程执行的设计模式；将软件应用的代码转换成可按需远程执行模式的自动重构方法。对其分别说明如下I.支持软件应用中计算逻辑实现按需远程执行的设计模式一个给定的软件应用中的程序代码无外乎具有两种结构一种是直接内存调用结构(Iocalinvocation),如图I所示；另一种是远程调用结构(remote invocation),如图2所示。图I中应用类X调用应用类N的过程是首先获得对N的内存引用，然后通过该引用去调用所需要的方法。显然，这种直接内存调用结构并不允许N中的计算被按需转移到远程执行。这是因为，倘若N转移到远程网络节点后，X不能从它所在的内存地址空间获得对在远端的N的引用。在一个给定的软件应用中，还可能存在如图2所示的远程调用结构。X通过Remote Communication Service (RCS,远程通讯服务)而获得运行在远端的N的一个引用，然后使用该引用去远程调用N中的方法。在该结构中，由RCS负责将N的引用与N相关联。尽管该结构允许N远程执行，然而却仍然不能支持N实现按需远程执行。原因在于，当N和X在同一个地址空间中执行时，X对N的方法调用仍需要RCS发消息给网络栈才能传递到N，而网络栈中的消息传递相比直接内存引用来说极为耗时且耗资源，从而导致应用性能下降。这与通过计算逻辑的按需转移来保障应用性能的初衷相违背。为了实现计算逻辑的按需远程执行，目标程序结构必须要允许X能够有效调用N中的方法而不管当前X与N运行在同一个地址空间还是在不同的网络节点上。本发明给出了一种支持软件应用中计算逻辑按需远程执行的目标程序结构，主要包含如下两个核心元素Proxy (代理)和Endpoint (端点)。此外,N类自身的内部实现也要做相应的修改。比如，实现一些特殊的接口及对应的一些特殊方法。新添加这些接口及方法的目标是为了使N能够被代理和端点所使用，但修改后的N和修改前的N的功能和外部表现没有本质区别。如图3所示，本发明将X和N之间的直接内存调用以及通过RCS的远程调用都转换成了经 全一致，只是它本身不执行任何实际的计算操作，只负责将方法调用转发到N执行。如果N的位置改变，比如从X所在的内存地址空间转移到了远程网络节点，或是从某一远程网络节点转移到了另一节点，X并不会知道N位置的变化。其原因在于NProxy保持不变且始终与X运行在同一地址空间中。Endpoint负责识别N当前的位置并且负责X和N之间根据具体需要而进行的跨网络互操作或直接内存调用。倘若N运行在远程节点，则Endpoint会利用给定的RCS获得对N的远程引用，并把该引用以NProxy的形式供X使用，使得X能够通过该引用而远程调用N。当X和N都运行在同一地址空间时，Endpoint会直接获得对N的内存引用，并同样以NProxy的形式供X所用，使得X调用N时不必经过耗时的网络栈。2.将软件应用的代码转换成可按需远程执行模式的自动重构方法在确定了软件应用的源结构(图I和图2)以及目标结构(图3)后，本发明逐步实施如图4所示的程序转换步骤来实现给定软件应用中计算逻辑的按需远程执行并保障远程执行后应用整体性能的提升。首先，应用类分类。对于一个给定的软件应用，本发明自动将其应用类分成如下两类执行位置固定类(Anchored)和执行位置可变类(Movable)两种。Anchored类型的应用类必须留在原网络节点上执行。原因在于，这些类使用到了一些只能在原节点才能获取的特殊资源(比如图形用户界面显示器以及特殊的文件等)。倘若这些类被转移到远端网络节点上执行，它们会因找不到所需要的资源而造成执行错误。这些类之外的其他应用类都被自动归为Movable类型的类。例如,一个用于数学处理的Math类就通常是一个Movable类型的类。在必要时，这些类可以远程执行，从而通过对远程计算资源的占有来提高整个应用的性能。其次，应用类转换。在这一步中，会将给定软件应用类代码从源结构转换为目标结构，使之可远程执行。当一个应用类放到远端执行时，与之交互的应用类都需要被转换成可按需远程调用的结构，即，生成被调用者的代理类Proxy，重写调用类来使用Proxy。需要注意的是，如果一个Anchored类被在远端执行的Movable类所调用，后者同样需要前者的代理类。由于只有根据运行时信息才能最终决定Movable类的本地/远程执行以提高应用整体性能，因此，必须对所有的被调用类生成相应的代理，并重写调用类来使用这些代理，除非调用类和被调用类都是Anchored的情况。在本发明所提出的方法中，一个Proxy与其被代理的应用类在外部表现及功能上完全一致。也就是说，这两个类继承了同样的父类，实现了同样的业务接口，具有同样的方法签名。这样，才能使那些原本使用被代理类的应用类在使用Proxy时不能感觉到差别。接着，应用类聚类。通过聚类可以使计算逻辑的远程执行能够进一步提高应用的性能，避免频繁的网络调用带来负面影响。因为网络调用通常极为耗时，若调用过于频繁则 反而会影响应用性能的提高。因此需要把相互间调用频繁的类作为一个整体在必要时放到远端执行。倘若在应用运行才去发现应用类的调用关系，通常会带来巨大的开销。因此，本步骤的目的就是要简化对应用中哪些计算逻辑需要被真正远程执行的运行时决策。本发明基于应用类聚类的方法来实现这种简化。例如，通过聚类发现类X和N调用频繁。在运行时，Endpoint可以只监控X的执行轨迹来决定是否需要将X和N —起放到远端执行。这样做不但可以避免X和N被分到网络两端时所需要进行地频繁的跨网络互操作，并且可以简化运行时X和N之间关系的分析以及对N的监控，从而降低开销。上述聚类可以采用多种方法，比如使用静态程序分析方法，基于调用应用类之间的关系图(call-graph)进行聚类，也可以采用动态程序分析方法。最后，应用类封装。本发明所提出的方法的输入是一个给定的软件应用的组成代码以及相应的资源文件(原始应用所拥有的全部资源文件)，如图像、XML配置文件等。在经历了以上步骤之后，输出包含两类制品一个是转换后封装为原始应用格式的应用，该应用留在原网络节点运行；另一类是原始应用中那些Movable类型的应用类、代理、端点以及相关资源文件所组成的一个可在远程网络节点部署执行的软件制品。图5展示了一个可实现计算逻辑按需远程执行的软件应用的运行时系统结构。该应用包含了 6个类,名字分别从a到i。通过步骤I,发现类b和g都是Anchored类,必须留在原网络节点上执行。其他类都是Movable类，它们既可在原网络节点上执行，也可在新增的远程网络节点上执行。通过步骤2，每一个应用类都生成了对应的Proxy类，并且应用类间的调用都通过Proxy和Endpoint来完成。经过步骤3发现a, c, d, e和f是关系紧密的类，因此它们被聚类在了一起已备在必要时作为一个整体运行在远端。步骤4将所有的Movable类型的应用类、代理、端点以及相关资源文件封装为可在远端节点部署执行的软件制品，该制品允许有多个副本分别运行在不同的网络节点上(每个副本运行在一个网络节点)，以支持本发明所提出的通过计算逻辑的远程执行来实现的对资源的占有。同样，会将全部应用类、它们的代理以及Endpoint都按照原有应用格式进行封装为转换后的应用，将其部署在原网络节点上进行。不同之处在于，转换后应用中Movable类的计算可以根据需要而调用在远端的对应Movable类执行或是直接本地执行。在运行时，通过Endpoint预测当一应用类远程执行时该应用类所属的软件应用的性能，如果发现远程执行能够提高性能，则远程执行(即调用部署在远程节点的执行位置可变类)，否则就本地执行(即调用部署在本地节点的执行位置可变类)。具体来说，Endpoint预测到若应用类d远程执行时可以提高应用性能，则通过RCS获得对d的远程引用，调用类通过该引用而远程调用d。具体过程是首先激活在远端的d，并且把本地d的状态通过Endpoint注入到远端的d,实现状态同步,接着将本地的d停用。此后，d的Proxy将会通过Endpoint把对原节点d的调用请求转发到远端的d上执行。由于d、C、e和f在第3步时已经被聚类为了一个逻辑整体。因此，当d被转移到远端执行时，该聚类中的其他类也跟着被移到远端执行，以减少频繁的跨网络调用。该过程也一样要经历激活、状态同步、停用等阶段。因此可以从图中看到，在原节点，a、C、d、e和f的Proxy在起作用，而这些类中计算逻辑的真正执行是在远端的网络节点上。当网络条件不佳时或是发现仅原节点的资源就足以保障应用性能时，可以通过停用在远端的a、c、d、e和f，并重新激活在原节点的对应类实例来将远程执行的计算移回，以节约资源并保障应用正常运行。所有对这些类的调用都将通过Proxy和Endpoint而转发回原节点，从而以一种按需的方式实现了应用中计算逻辑的远程执行。
上述过程中，应用系统的性能可以采用多种衡量方式，比如可以采用时间开销、吞吐量开销、能耗开销其中的一种或多种来衡量。吞吐量开销可由应用所能处理的用户请求量来衡量。能耗开销可由节点(如手机)端的电池续航时间来衡量。时间开销可包含发送调用某一方法的请求给该应用类所用的时间、该应用类执行该方法所用的时间以及返回执行结果所用的时间。具体来说，应用类d远程执行的时间开销由如下三部分构成I. Tsend,发送需要执行方法m的请求给远程的d所花的时间；2. Texecute，远程的d执行方法m所花的时间；3. Tback，返回执行结果所花的时间。而当d本地执行时m方法耗时为T’ execute。如果d所在的远程节点的计算资源比d原来所在的本地节点的计算资源丰富，比如d所在的远程节点为PC，而d所在的本地节点为手机(其CPU处理能力远不如PC的CPU处理能力)。这导致 Texecute << (表不远小于)T’execute,以至于 Tsend+Texecute+Tback<< T’ execute。如果网络不佳，或是远程资源不丰富，使得Tsend+Texecute+Tback >T’execute，则本地执行就没有必要了。此时endpoint就直接获得对被调用类的内存引用，调用类通过该引用而直接调用被调用类。因此，endpoint可以预测出d是否应该本地执行或远程执行以通过占有计算资源来提高应用性能。须说明的是，本发明并非必须通过端点进行性能的预测。端点还可以通过收集应用运行数据，将这些数据发送给第三方的预测器来预测性能。该预测器通过分析数据并进行预测后返回结果给端点，然后端点根据结果来决定哪些应用类实例(比如上述的应用类d)需要远程执行或是本地执行。下面通过一个具体应用的实施例说明本发明的方法。该实施例是将一个真实的JavaAndroid应用即“GoGame (围棋对战)”中的计算逻辑按需移动到服务器端执行。GoGame 是由 INSA (法国国立应用科学学院 Institut National des SciencesAppliquees)研究人员开发出的一款Android围棋对战游戏。它的游戏模式中有人人对战/人机对战两种。人机对战中还可以选择机器棋手所采取的智能算法，如基于模式的Pattern算法以及基于统计模拟的MonteCarlo算法。通常情况下，机器棋手需要进行大量耗能耗时的计算才能决定落子的位置，而由于手机所拥有的处理器配置通常不高，因此导致该应用的性能较低，对用户的输入不能快速做出响应，且耗电量很大，带来不佳的用户体验。本实施例使用三星Samsung S5660型号的Android手机(CPU 800MHz,内存160M，Android22手机操作系统平台，锂电EB494358VU，1350mAh)作为实验手机。使用联想SL400笔记本作为服务器(CPU Intel Core Duo，T6570，2. 1GHz，内存1G)。手机和笔记本通过wifi关联。相互间的RTT (往返行程时间)为50ms。
本实施例按照图3所示的设计模式以及图4的重构方法，自动将原始的GoGame应
用转换为计算逻辑可按需远程执行的GoGame应用。首先，识别出原始GoGame中哪些类是Anchored以及Movable,如表I所示。表I. GoGame转换后得到的类簇
类簇编号可移动性类簇中包含的Android应用类
1Anchored insa. android, andgoid. AndGOid
insa. android, andgoid. AndGOidS Iinsa.android.andgoid.Board insa. android, andgoid. Constants insa. android, andgoid. GameManager insa. android, andgoid. GameManagerS I insa. android, andgoid. GobanView insa. android. andgoid. Group insa. android, andgoid. GroupBoard insa.android.andgoid.Player insa.android.andgoid.HumanPlayer insa.android.andgoid.ComputerPlayer insa.android.andgoid.R insa.android.andgoid.RS array insa.android.andgoid.R$attr insa.android.andgoid.R$drawable insa. android. andgoid.R$layout ___insa.android.andgoid.R$string_
2Movable insa.android.andgoid.strategy.MoneCarloAI
insa. android, andgoid. strategy.UCTNode
3Movable insa. android, andgoid. strategy. PattemAI
insa.android.andgoid.strategy.pattem.PattemBoardSide
insa.android.andgoid.strategy.pattem.PattemCutl
insa.android.andgoid.strategy.pattem.Pattem_Cut2
insa.android.andgoid.strategy.pattem.PattemHane
insa.android.andgoid.strategy.pattem.Pattem
insa. android, andgoid. strategy.pattem. PattemConfiguration
insa.android.andgoid.strategy.pattem.PattemStoneAny
insa.android.andgoid.strategy.pattem.PattemStoneColored
insa.android.andgoid.strategy.pattem.PattemStoneEmpty
insa.android.andgoid.strategy.pattem.PattemStoneMove
insa.android.andgoid.strategy.pattem.PattemStoneOutOfBoard
insa.android.andgoid.strategy.pattem.PattemStoneRestricted
insa.android.andgoid.strategy.pattem.PattemStone接着自动地对这些类进行转换,并生成对应的Proxy以及Endpoint。随后,通过聚
类发现GoGame中的应用类可以聚为如表I所示的类簇，并将聚类信息存储在转换后应用的
Endpoint中。最后通过封装，自动生成转换后的Android GoGame应用以及由Movable应用
类、Proxy等所组成的可执行的Apk文件。转换后的GoGame应用被部署在手机上,Movable
类对应的Jar文件被部署在服务器上。实验选择将类簇2移动到服务器端端执行，并使用MonteCarloAI人机对战的方式
进行测试，游戏进行5分钟(即300秒)。测试方案如下I. GoGame的计算全部在手机上执行(300秒)。2. GoGame中的类簇2 (即表I中包含MonteCarloAI的类簇)移动到服务器端执行(时间300秒)。3.使手机逐渐远离wifi路由器，在300秒时间内使RTT逐渐增大到600ms (用以模拟用户离开服务器端的场景)，在240秒到300秒这一个时间段内将类簇2移动回手机端执行。实验得到的机器棋手下棋的响应性能比较和电能消耗如表2所示。表2.性能和能耗 比较(测试时长为300秒)
权利要求
1.一种软件应用中计算逻辑的按需远程执行方法，其步骤包括 1)将软件应用的应用类分为执行位置固定类和执行位置可变类； 2)将所述应用类的程序代码从源结构转换为目标结构；所述目标结构包含代理和端点所述代理与调用类运行于同一地址空间，负责将方法调用经由所述端点转发至在本地或远程运行的被调用类，所述端点负责识别所述被调用类的当前位置； 3)将转换为所述目标结构的应用类封装为原始应用格式的应用和可远程执行的软件制品，分别部署于原网络节点和远程网络节点； 4)预测当一应用类远程执行时该应用类所属的软件应用的性能，如果该性能提高，则在远程执行该应用类，否则在本地执行该应用类。
2.如权利要求I所述的方法，其特征在于，对转换为目标结构的应用类进行聚类，将相互间调用频繁的类作为一个整体放到远端执行。
3.如权利要求2所述的方法，其特征在于，采用静态程序分析方法或动态程序分析方法进行所述聚类。
4.如权利要求I所述的方法，其特征在于，所述源结构包括直接内存调用结构和RCS远程调用结构。
5.如权利要求4所述的方法，其特征在于当被调用类在远程运行时，所述端点利用RCS获得对被调用类的远程引用，调用类通过该引用而远程调用被调用类；当被调用类和调用类运行于同一地址空间时，所述端点直接获得对被调用类的内存引用，调用类通过该引用而直接调用被调用类。
6.如权利要求I所述的方法，其特征在于，所述软件制品包含执行位置可变类、代理、端点以及相关资源文件，所述相关资源文件包括图像和XML配置文件。
7.如权利要求6所述的方法，其特征在于，所述软件制品的多个副本分别运行在不同的网络节点上。
8.如权利要求I所述的方法，其特征在于，所述软件应用的性能通过时间开销、吞吐量开销以及能耗开销中的一种或多种来衡量。
9.如权利要求8所述的方法，其特征在于，当一应用类远程执行时，所述时间开销包含发送调用某一方法的请求给该应用类所用的时间、该应用类执行该方法所用的时间以及返回执行结果所用的时间。
10.如权利要求1-9任意一项所述的方法，其特征在于，在远程执行一应用类的步骤包括激活、状态同步、停用。
全文摘要
本发明提供一种软件应用中计算逻辑的按需远程执行方法。首先将软件应用的应用类分为执行位置固定类和执行位置可变类，再将应用类的程序代码从源结构转换为目标结构。通过所述目标结构将应用类之间的直接内存调用和远程调用转换成经由代理和端点进行的间接远程调用。并通过预测当一应用类远程执行时是否能改善该应用类所属的软件应用的性能，实现软件应用中计算逻辑的按需远程执行。本发明方法通过自动对软件应用的代码进行重构，将其转换为可按需远程执行的程序结构，实现对计算资源的按需占有，以提高性能并改善用户体验。
文档编号G06F9/48GK102629198SQ20121005071
公开日2012年8月8日 申请日期2012年2月29日 优先权日2012年2月29日
发明者刘譞哲, 张颖, 梅宏, 黄罡 申请人:北京大学