信息处理装置、信息处理方法

专利名称：信息处理装置、信息处理方法
技术领域：
本发明涉及信息处理装置、信息处理方法及程序。
背景技术：
近年来，为了实现系统基础架构资源(system infrastructure source)的有效利用，进行了系统基础架构的效用化(utility)和云化(cloud)。其结果是，存在与现有的在 特定的系统基础架构中执行应用程序(以下称为APP)的系统不同的，不仅无法唯一地确定 执行APP的环境，而且APP在哪里执行也根据基础架构的空闲状况而不同的系统。另一方面，APP变得复杂化，有时不考虑使用APP的使用环境地进行系统构建。即， 本来应该在实际使用环境下进行APP的关联测试等，但设定这样的测试环境也不容易，仅 进行APP的单体测试来进行系统构建的情况也不少。另外，在设想通过10台性能X的服务 器执行某APP来进行开发的情况下，在执行该APP时，若开发出性能比性能X高的服务器 并投入这种服务器，资源有富余，则随着服务器性能的提高，有时将服务器的数量减少到8 台。而且，通过系统基础架构的效用化，不知道APP在什么时候被分配给哪个服务器，并且 通过系统基础架构的云化，不知道将数据存储在哪里的怎样的存储装置中。专利文献1日本专利第2521020号说明书

发明内容
如上所述，APP有可能在与开发APP时不同的执行环境中运行。即，在APP的执行 环境与开发环境不同的情况下，存在无法保证与APP的运行相关的品质的问题。例如存在 在执行环境中产生响应时间延长或系统服务水平下降这样的问题。本发明是鉴于以上问题而提出的发明，其目的在于提供一种保证APP的运行品质 的技术。本发明的另一发明目的在于提供一种保证包含响应时间在内的与服务水平相关 的品质的技术。因此，本发明的信息处理信息装置具有读入单元，其读入与执行请求所涉及的应 用程序对应的、与所述应用程序的运行相关的运行信息；以及构建单元，其根据通过所述读 入单元读入的所述运行信息，构建使所述应用程序运行的执行环境。本发明的信息处理装置，通过具有读入单元，其读入与执行请求所涉及的应用程 序对应的、与所述应用程序的运行相关的运行信息；以及构建单元，其根据通过所述读入单 元读入的所述运行信息，构建使所述应用程序运行的执行环境，例如可以使APP在根据包 含APP的执行环境等信息在内的运行信息而构建的执行环境中运行，因此可以提供在APP 的执行环境与开发环境不同的情况下也能保证与APP的运行相关的品质的技术。此外，所谓信息处理装置，例如对应于后述的服务器装置2、或客户端装置1等。若 更具体说明，则如后述的实施方式1那样将本发明应用于包含效用系统的系统时，信息处 理装置对应于例如后述的服务器装置2。另外，在如后述的实施方式5那样将本发明应用于单个PC时，信息处理装置对应于例如后述的客户端装置(PC)。另外，所谓运行信息，例如对应于后述的Tag信息(标签信息)。另外，本发明的信息处理方法包含以下步骤读入步骤，信息处理装置读入与执行 请求所涉及的应用程序对应的、与所述应用程序的运行相关的运行信息；以及构建步骤，所 述信息处理装置根据所述读入步骤中所读入的所述运行信息，构建使所述应用程序运行的 执行环境，在所述构建步骤，根据所述运行信息组合被片断化了的虚拟资源，构建使所述应 用程序运行的执行环境。所述信息处理方法中，优选的是，在所述构建步骤，在根据通过所述读入步骤读入 的所述运行信息无法构建使所述应用程序运行的执行环境的情况下，输出表示无法使所述 应用程序运行的含义的信息。所述信息处理方法中，优选的是，在所述运行信息中包含与伴随所述应用程序的 执行的收费相关的基本信息，所述信息处理方法还具有计数步骤，在执行了所述应用程序 的情况下，根据所述基本信息以及与所述执行相 关的信息，对伴随所述应用程序的执行的 收费信息进行计数。所述信息处理方法中，优选的是，在所述运行信息中包含表示所述应用程序的每 种运行环境的性能的性能信息，在所述构建步骤，根据通过所述读入步骤读入的所述运行 信息中包含的性能信息，构建使所述应用程序运行的执行环境。所述信息处理方法中，优选的是，将所述运行信息附加在所述应用程序中，在所述 读入步骤读入在所述应用程序中附加的所述运行信息。所述信息处理方法中，优选的是，将所述运行信息与所述应用程序相对应地存储 在存储装置中，在所述读入步骤从所述存储装置读入与所述应用程序对应的所述运行信 肩、ο所述信息处理方法中，优选的是，将所述运行信息包含在文件系统上的每个应用 程序的标题信息中，在所述读入步骤从所述标题信息读入所述应用程序的所述运行信息。另外，本发明的程序，使计算机作为读入单元和构建单元来工作，所述读入单元， 读入与执行请求所涉及的应用程序对应的、与所述应用程序的运行相关的运行信息；所述 构建单元，根据通过所述读入单元读入的所述运行信息，构建使所述应用程序运行的执行 环境。根据本发明，可以提供保证APP的运行品质、以及包含响应时间在内的与服务水 平相关的品质的技术。


图1是表示在本实施方式中说明的系统的系统结构的一例的图。图2是表示服务器装置的硬件结构的一例的图。图3是表示服务器装置的功能构成的一例的图(其一)。图4是表示APP提供引擎的处理的一例的流程图(其一)。图5是用于说明APP提供引擎的处理的图。图6是表示Tag信息的一例的图。图7是表示应用程序A的Tag信息的一例的图。
图8是表示应用程序B的Tag信息的一例的图。图9是表示应用程序C的Tag信息的一例的图。图10是用于说明APP提供引擎中的执行环境的构建的图。图11是表示服务器装置的功能构成的一例的图(其二)。图12是表示APP提供引擎的处理的一例的流程图(其二)。图13是表示存储了每个用户可以利用的APP以及可以选择的处理性能的表的图。图14是表示将应用程序的性能信息和运行环境对应起来记载的Tag信息的图。图15是表示客户端装置的硬件结构的一例的图。
具体实施例方式以下，根据

本发明的实施方式。在本说明书中，所谓效用系统(utility system)，是指可以自由地追加/削减CPU 或存储装置(存储介质)等系统资源的系统。另外，所谓云系统(cloudsystem)，是指使用 分散在因特网上的各种资源来提供服务(或者接受服务的提供)的系统。在云系统中，用 户仅具有客户端计算机(PC)即可，应用程序由网络的对方一侧(云系统一侧)提供，信息 也由对方一侧(云系统一侧)管理。(实施方式1)图1是表示在本实施方式中说明的系统的系统结构的一例的图。如图1所示，客户端装置1经由网络与共用系统(或效用系统+云系统等)可通 信地连接。在图1中为了简化说明，仅设置了一个客户端装置1，但也可以在网络上连接多 个客户端装置。另外，为了简化说明，在以下表示的实施方式中假定客户端装置1经由网络 与效用系统可通信地连接。如后所述，效用系统包含多个物理资源(硬件等)并对它们进行管理。此外，假定 效用系统整体的控制由服务器装置2来进行。服务器2有时为单个，但在云系统中也可以 存在多个，彼此在相互通信的同时进行控制。另外，在本说明书中，客户端装置、服务器装置 或者效用系统等，关于硬件的形态使用了若干种表现，但这只不过用于帮助理解，把请求利 用APP的一侧暂称为客户端装置，把提供APP的功能的一侧暂称为服务器装置。有的装置 可以在物理上兼任客户端装置和服务器装置，或者该装置也可以作为构成效用系统的装置 之一而存在。图2是表示服务器装置的硬件结构的一例的图。如图2所示，服务器装置2作为 硬件结构而包含CPUl 1。CPUll基于在存储装置12中存储的程序(例如APP提供引擎程序)来进行处理， 由此实现服务器装置2的功能、或者与后述的流程图有关的处理。另外，在CPUll上经由总线连接了存储装置12。存储装置12例如由ROM、RAM、硬 盘装置等构成，除上述的各程序以外还存储在基于程序的处理中所使用的数据。图3是表示服务器装置的功能构成的一例的图(其一)。如图3所示，服务器装置2作为功能构成而包含通过CPUll执行程序而实现的APP提供引擎(provisioning engine)21。另外，APP提供引擎21作为功能而包含读入部31和构建部32。
读入部31从客户端装置1等读入与被请求执行的APP对应的Tag信息。在本实 施方式中，假定Tag信息存储在APP的特定的位置。在此，Tag信息例如包含以下这样的信息。·ΑΡΡ 识别符(单体运行、SOA 模块(Service Oriented Architecture module)或 库(library)等)·对象的种类(机器语言、解释程序使用[依存于OS或不依存于OS])-在机器语 言的情况下，CPU的种类(IA-86、Itanium、Sparc或IBM-P等)·运行OS信息(OS识别符、Ver识别符和补丁识别符等)·编码形式·解释程序(interpreter)的种类
·运行中间件信息1 (DB的种类和APP执行环境的种类等)·运行中间件信息2 (Vet识别符和补丁识别符)·服务水平信息1 (响应时间或可用时间等)·服务水平信息2 (使用CPU资源量或存储器使用量等)·备份存档信息·关联Tag (与该Tag相关的其它Tag)Tag信息可以包含上述全部信息，也可以只包含上述信息的一部分。构建部32根据由读入部31读入的Tag信息，组合片断化了的虚拟资源，构建使 APP运行的执行环境。另外，构建部32在无法根据由读入部31读入的Tag信息组合片断化 了的虚拟资源来构建使APP运行的执行环境时，例如向进行了 APP的执行请求的客户端装 置1等输出(或返回)表示由于无法构建APP可以运行的执行环境，因此无法使APP运行 的含义的信息等。图4是表示APP提供引擎的处理的一例的流程图(其一)。在步骤SlO中，读入部31从由客户端装置1等请求执行的APP中读入Tag信息。在步骤Sll中，构建部32根据步骤SlO中由读入部31读入的Tag信息、和图5所 示的片断化了的虚拟资源中当前可以使用(或者进行了执行请求的客户端装置1的用户可 以使用)的虚拟资源，判定是否能够构建所述APP可以运行的执行环境(例如图5所示的 资源提供组(provisioning resource set))。构建部32，当判定为能够构建APP可以运行的执行环境时进入步骤S13，当判定为 不能够构建APP可以运行的执行环境时进入步骤S12。在步骤S12中，构建部32向进行了 APP的执行请求的客户端装置1等输出(或返 回)表示由于无法构建APP可以运行的执行环境，因此无法使APP运行的含义的信息等。另一方面，在步骤S13中，构建部32根据在步骤SlO中由读入部31读入的Tag信 息，构建使APP运行的执行环境。图5是用于说明APP提供引擎的处理的图。图5所示的物理资源是由效用系统管理的多个物理资源。效用系统将这些物理资 源虚拟化来进行管理。APP提供引擎21读入Tag信息，根据所读入的Tag信息组合这些被 虚拟化管理的虚拟资源来构建执行环境，并在该执行环境上使APP执行。以下，使用更具体的例子来说明APP提供引擎21的处理。首先，作为APP的一例，举例说明考勤信息管理应用程序。设考勤信息管理应用程序具有以下功能1在营业日从各个职员接受工作开始时间、工作结束时间的输入。2在月末提供各个职员的上工信息(休假、缺勤、加班、休息日出勤等信息)，并发 送到系统。另外，考勤信息管理应用程序由以下应用程序构成1管理各个职员的上工状况的应用程序A(用于由职员进行输入的输入界面)2在月末时刻对该月的上工信息进行批处理的应用程序
3管理在应用程序A和应用程序B中使用的职员上工信息的应用程序C，各个应用程序在以下环境下运行1装配了 IA-86体系结构的服务器2Linux0S Ver 〇、补丁〇〇3WebLogic应用程序服务器Ver.〇、补丁〇〇40racle (注册商标)10G DB PSR〇〇。另外，对应用程序A要求24小时365天不停的可用性，对应用程序B要求每月末 处理两小时的可靠执行。另外，为了维持应用程序A的服务水平，假定需要4CPU、存储器2GB、存储装置5GB。 另外，为了维持应用程序B的服务水平，假定需要10CPU、存储器4GB、存储装置5GB。另外， 应用程序C，在应用程序A执行时需要2CPU、存储器2GB，在应用程序B执行时需要16CPU、 存储器4GB，以及维持各个应用程序的服务水平的运算能力、和已经构成了职员DB的300GB 的存储装置的特定区域。另外，假定按照图6所示的顺序来存储Tag信息。图6是表示Tag信息的一例的 图。图7是表示应用程序A的Tag信息的一例的图。图8是表示应用程序B的Tag信息的 一例的图。图9是表示应用程序C的Tag信息的一例的图。另外，图10是用于说明APP提供引擎中的执行环境的构建的图。APP提供引擎21 读入图7、图8、图9中所示的应用程序A的Tag信息、应用程序B的Tag信息、应用程序C 的Tag信息，根据这些Tag信息如图10所示那样构建使各应用程序运行的执行环境。更具体而言，APP提供引擎21读入图7、图8、图9所示的应用程序A的Tag信息、 应用程序B的Tag信息、应用程序C的Tag信息，根据这些Tag信息构建图10的41、42所 示的执行环境。图10的41是用于使应用程序A运行的执行环境，APP提供引擎21从服务 器池中确保4个CPU等，另外，还构建了应用程序C的执行环境。通过该执行环境，用户可以使用应用程序A经由客户端装置1进行上工状况的输 入。此外，图10的42是用于使应用程序B运行的执行环境。如上所述，根据本实施方式，在根据Tag信息构建的执行环境中可以使APP运行， 因此可以提供即使在APP的执行环境与开发环境不同的情况下也能保证与APP的运行相关 的品质的技术。(实施方式2)在实施方式1中，假定Tag信息被存储在APP的特定位置来进行了说明。但Tag 信息也可以与APP分开在DB等中与APP对应地进行存储。在这种结构的情况下，读入部31根据APP识别符等从DB取得并读入与APP对应的Tag信息。通过成为这种结构，可以提供APP提供引擎21对于已经存在的APP也能保证与 APP的运行相关的品质的技术。(实施方式3)另外，Tag信息也可以存储(记载)在存在于效用系统的文件系统上的每个APP的 标题信息中。在这种结构的情况下，读入部31根据APP识别符等从文件系统上的标题信息中取 得并读入与APP对应的Tag信息。(实施方式4)另外，关于Tag信息的存储场所，也可以组合上述各实施方式来实施。即，Tag信 息不限于上述存储场所的某一个，例如存储场所可以根据APP而不同。(实施方式5)包含在Tag信息中的信息不限于上述实施方式中所示的信息。在本实施方式中， 举例说明在Tag信息中包含与收费相关的基本信息的情况。在此，所谓与收费相关的基本信息，例如包含单位利用时间的费用、单位交易数的 费用、单位存储容量的费用、每个用户识别符费用、与收费相关的选项信息(所述单位下的 折扣率等)。图11是表示服务器装置的功能结构的一例的图(其二)。如图11所示，服务器装 置2作为功能结构而包含通过CPUll执行程序而实现的APP提供引擎21。本实施方式的APP提供引擎21，作为功能除上述实施方式1的功能以外，还包含计 数部33。计数部33，在执行了 APP的情况下，根据在Tag信息中包含的与收费相关的基本信 息以及与APP的执行相关的信息，对伴随所述APP的执行的收费信息(即与APP的利用相 伴的费用)进行计数。例如，在作为与收费相关的信息而包含单位利用时间的费用的情况 下，计数部33根据所述单位利用时间的费用、和APP的执行时间的信息，对与APP的利用相 伴的费用进行计数。然后，计数部33将计数而得的收费信息例如发送到可以经由网络与效用系统进 行通信的收费服务器等，并将收费信息存储在收费服务器等中。图12是表示APP提供引擎的处理的一例的流程图(其二)。与图4的流程图相比，图12的流程图新增加了步骤S14 步骤S16的处理。在步骤S14中，计数部33判定APP的执行是否结束。计数部33在APP的执行已 结束的情况下进入步骤S15，在APP的执行未结束的情况下重复步骤S14的处理。在步骤S15中，计数部33根据在Tag信息中包含的与收费相关的基本信息以及与 APP的执行相关的信息，对与所述APP的执行相伴的收费信息进行计数。在步骤S16中，计数部33将在步骤S15中计数而得的收费信息输出到收费服务器寸。以上，根据本实施方式可以保证与APP的运行相关的品质，同时可以快速地进行 与APP的利用相伴的收费的处理。(实施方式6)
在上述实施方式中，说明了在Tag信息中包含为使对应的APP以一定的品质运行 所需要的信息(例如CPU的种类、OS的种类、补丁的信息、用于维持服务水平的资源量等) 的例子。但是，在Tag信息中也可以包含用于使APP以一定的品质运行的禁止信息(例 如为使APP以一定的品质运行，作为OS的种类Linux Ver χχ. χ不行的情况为Linux Ver xx. x-NO等记载)。在由读入部31读入的Tag信息中包含了上述那样的禁止信息时，构建部32以不 含有这样的结构的方式来组合片断化了的虚拟资源，构建使APP运行的执行环境。另外，在Tag信息中不仅记载为了执行APP而最低限度需要的运行环境的信息，还 可以把可以执行APP的多个运行环境的信息、和表示在各运行环境中可以提供的处理性能 的性能信息(响应时间、吞吐量等)对应起来记载。在这种情况下，在Tag信息中包含例如 “在运行环境-χ (CPU-x、OS-x、补丁 -χ)中，响应时间为χ (s)、吞吐量为χ (bps)，，等记载。由此，例如在要求高速应答性的情况下，用户指定必要的APP的处理性能(例如响 应时间或吞吐量等)。构建部32可以参照Tag信息来构建满足由用户指定的处理性能的响 应时间或吞吐量等的运行环境。而且，在Tag信息中包含的与收费相关的基本信息中，可以设定与利用的处理性 能对应的费用(例如，提供的处理性能越高利用费用越高等)。根据该结构，例如在不要求 高速处理的情况下，用户可以选择吞吐量低而费用低的服务，构建部32可以参照Tag信息 来构建能提供用户所选择的处理性能的运行环境。在此，进一步详细说明用户接受服务的提供的方式的一例。用户，首先与提供服务 的公司(以下称为服务公司)之间就APP的利用签订合同。用户不仅可以利用一个APP，也 可以利用多个APP或者以多个处理性能来利用各APP。并且，服务公司把各用户可以利用的 APP以及每个APP的处理性能登记在用户信息管理用的服务器中。图13表示存储了每个用户可以利用的APP以及可以选择的处理性能的表。在图 13所示的例子中，用户001可以利用APP-x以及APP-y，用尸002仅可以利用APP_z。另外， 用户001，根据与服务公司的合同，在利用APP-x时可以选择处理性能a (响应时间Ims以内 运行)或处理性能b (响应时间Is以内运行)的某一个。该处理性能a以及处理性能b例 如表示最低限度保证的响应时间或吞吐量。在这种情况下，进行与处理性能对应的费用设 定(即，处理性能越高，设定越高的费用)。用户001，在利用服务的情况下，从终端装置访问服务公司的认证用的服务器，发 送登录请求。认证用的服务器接受来自用户001的登录请求，当认证完成时，从用户信息 管理用的服务器取得用户001的信息，向终端装置发送用户001的菜单画面用的信息。然 后，用户001的终端装置在菜单画面中向用户提示用于确认利用APP-X和APP-y哪一个的 消息。当用户001选择APP-x时，终端装置在菜单画面中提示确认以处理性能a和处理性 能b哪个处理性能来利用的消息。当用户001选择处理性能a时，终端装置对服务器装置 2请求在处理性能a下的APP-x的利用。然后，在服务器装置2中，APP提供引擎21的构建 部32参照APP-x的Tag信息，检索满足处理性能a的APP_x的运行环境的信息，根据相应 的运行环境的信息来构建APP-x的运行环境。以下，进一步详细说明构建部32参照Tag信息构建满足处理性能a的运行环境时的处理。图14表示对应地记载了 APP-x的性能信息和运行环境的Tag信息。图14(a)表示记载了保证O. 5ms的响应时间的运行环境的Tag信息1，图14(b)表示记载了保证0. 5s 的响应时间的运行环境的Tag信息2。Tag信息1表示保证0. 5ms以内的响应时间的运行 环境由CPU-I、OS-I、DB-I构成，Tag信息2表示保证0. 5s以内的响应时间的运行环境由 CPU-2、0S-2、DB-2构成。图14所示的ΑΡΡ-χ的Tag信息1以及Tag信息2，可以分别作为 独立的Tag信息来管理，也可以针对每个APP包含在一个Tag信息中来管理。在从用户的终端装置请求在处理性能a(响应时间Ims以内)下利用APP_x时，构 建部32参照图14所示的ΑΡΡ-χ的Tag信息1以及Tag信息2，判定各Tag信息的运行环境 是否可以满足所请求的处理性能a(即响应时间Ims以内)。在图14所示的例子中，Tag信 息1中记载了保证响应时间0. 5ms以内的运行环境，构建部32判定为Tag信息1的运行环 境满足处理性能a(响应时间Ims以内)。另一方面，在Tag信息2中记载了保证响应时间 0. 5s以内的运行环境，构建部32判定为Tag信息2的运行环境不满足处理性能a (响应时 间Ims以内)。因此，在这种情况下，构建部32使用Tag信息1来构建由CPU-1、OS-1、DB-I 构成的运行环境。此外，当存在多个满足处理性能a的Tag信息时，通过预 先在Tag信息中 设定好优先顺序，构建部32可以根据设定的优先顺序选择Tag信息并构建运行环境。另外，在图14所示的例子中，作为Tag信息而包含针对每个用户识别符及处理性 能的收费信息，在Tag信息1的运行环境的情况下，表示以1000日元/小时的标准来收费。 并且，在以处理性能a来利用APP的情况下，计数部33以1000日元/小时的标准来计算使 用费用。由此，用户可以根据状况来选择APP的处理性能。因此，在需要高速的应答性的情 况下，能够以高度的处理性能利用APP，另一方面，在并非一定需要高度的处理性能的情况 下，通过以低处理性能利用APP可以节约费用，因此便利性提高。此外，在图13所示的例子中，是用户从菜单画面中选择可以利用的处理性能的结 构，但也可以是以下结构关于处理性能未预先签订合同，而在每次利用时由用户直接输入 需要的处理性能，根据Tag信息在服务器装置2中对满足所输入的处理性能的运行环境下 的每单位时间的利用费用进行估算，在用户对该估算结果确认后开始利用(或者变更为其 他处理性能)。另外，在图13所示的例子中由用户选择处理性能，但在APP的Tag信息中设 定了多个SLA(Service Level Agreement)信息(例如24小时365天运行等)的情况下， 用户也可以在登录(log in)时选择SLA。另外，登录用的服务器和用户信息管理用的服务 器，可以是作为独立的服务器而设置的结构，也可以是作为服务器装置2的功能而一体化 配备的结构，不对其进行特别限定。根据本实施方式可以提供保证与APP的运行相关的品质的技术。(实施方式7)在上述各实施方式中，举例说明了客户端装置1和效用系统(或效用系统+云系 统等)经由网络可通信地连接的系统。但是，本实施方式的系统假定仅包含客户端装置1。 艮口，如上所述，是通过把请求利用APP的一侧即客户端装置、和提供APP功能的一侧即服务 器装置安装在一个装置中的形态来实现的例子。图15是表示客户端装置的硬件结构的一例的图。如图15所示，客户端装置1作 为硬件结构而包含CPTO1。CPTO1，通过根据存储在存储装置53中的程序(例如APP提供引擎程序)来进行处理，实现客户端装置1的功能(所述的图3的APP提供引擎21的功能)、或所述图4的流 程图涉及的处理。另外，在CPU51上经由总线连接有输入装置52、存储装置53以及显示装置54。存 储装置53例如由ROM、RAM、硬盘装置等构成，除上述的各程序以外，还存储在基于程序的处 理中所使用的数据。显示装置54例如是显示信息的显示器等。输入装置52例如是输入信 息的操作键等。如上所述，本实施方式的APP提供引擎21与实施方式1中表示的功能相同，但如 本实施方式那样被安装在客户端装置1中时，构建为了使安装在客户端装置1中的APP运 行所需要的执行环境。例如，在客户端装置1中执行多个APP，要 求使多个APP运行的情况 下，APP提供引擎21读入与各APP对应的Tag信息，使用客户端装置1的物理资源构建为 了使各APP运行所需要的执行环境。并且，APP提供引擎21，在无法构建为了使某个APP运 行所需要的执行环境时，向显示装置54等输出例如表示由于无法构建APP可以运行的执行 环境因此无法使APP运行的含义的信息等。以上，根据本实施方式，也可以保证与在单个装置内运行的APP的运行相关的品质。以上，对本发明的优选实施方式进行了详细说明，但本发明不限于所述特定的实 施方式，在记载于权利要求中的本发明的主旨范围内，可以进行各种变形、变更。另外，也可以将上述各实施方式任意组合。
权利要求
一种信息处理装置，其特征在于，具有读入单元，其读入与执行请求所涉及的应用程序对应的、与所述应用程序的运行相关的运行信息；以及构建单元，其根据通过所述读入单元读入的所述运行信息，构建使所述应用程序运行的执行环境，所述构建单元，根据所述运行信息组合被片断化了的虚拟资源，构建使所述应用程序运行的执行环境。
2.根据权利要求1所述的信息处理装置，其特征在于，所述构建单元，在根据通过所述读入单元读入的所述运行信息无法构建使所述应用程 序运行的执行环境的情况下，输出表示无法使所述应用程序运行的含义的信息。
3.根据权利要求1所述的信息处理装置，其特征在于，在所述运行信息中，包含与伴随所述应用程序的执行的收费相关的基本信息， 所述信息处理装置还具有计数单元，其在执行了所述应用程序的情况下，根据所述基 本信息以及与所述执行相关的信息，对伴随所述应用程序的执行的收费信息进行计数。
4.根据权利要求1所述的信息处理装置，其特征在于，在所述运行信息中包含表示所述应用程序的每种运行环境的性能的性能信息， 所述构建单元，根据通过所述读入单元读入的所述运行信息中包含的性能信息，构建 使所述应用程序运行的执行环境。
5.根据权利要求1所述的信息处理装置，其特征在于， 将所述运行信息附加在所述应用程序中，所述读入单元读入在所述应用程序中附加的所述运行信息。
6.根据权利要求1所述的信息处理装置，其特征在于， 将所述运行信息与所述应用程序相对应地存储在存储装置中，所述读入单元从所述存储装置读入与所述应用程序对应的所述运行信息。
7.根据权利要求1所述的信息处理装置，其特征在于，将所述运行信息包含在文件系统上的每个应用程序的标题信息中， 所述读入单元从所述标题信息读入所述应用程序的所述运行信息。
8.一种信息处理方法，其特征在于， 包含以下步骤读入步骤，信息处理装置读入与执行请求所涉及的应用程序对应的、与所述应用程序 的运行相关的运行信息；以及构建步骤，所述信息处理装置根据所述读入步骤中所读入的所述运行信息，构建使所 述应用程序运行的执行环境，在所述构建步骤，根据所述运行信息组合被片断化了的虚拟资源，构建使所述应用程 序运行的执行环境。
全文摘要
本发明涉及信息处理装置、信息处理方法及程序，其目的在于提供一种保证APP的运行品质、以及包含响应时间在内的与服务水平相关的品质的技术。通过具有读入单元和构建单元来解决问题。所述读入单元读入与执行请求涉及的应用程序对应的、与应用程序的运行相关的运行信息，所述构建单元根据通过读入单元读入的运行信息，构建使应用程序运行的执行环境。
文档编号G06F9/44GK101833445SQ201010128819
公开日2010年9月15日 申请日期2010年3月8日 优先权日2009年3月13日
发明者甲斐龙一郎 申请人:新日铁系统集成株式会社