JP2016146045A - リソース管理装置およびリソース管理方法 - Google Patents

Abstract

【課題】グループに属するアプリケーションのインストールを管理する場合に、ユーザの環境に応じて、インストールを許可するリソース上限値を柔軟に変更する。
【解決手段】グループに属するアプリケーション１１０〜１１２がインストール、またはアンインストールされた際に、グループに属するアプリケーション１１０〜１１２が使用するリソース領域を確保するために、リソースサービス３０４は、管理者がアプリケーション１１０〜１１２をインストールするリクエストを行うと、リソース定義バンドル元データのリソース上限値にグループのリソース上限値を加算し、リソース定義バンドル３０７をインストールする。
【選択図】図３

Description

本発明は、例えば組込アプリケーション等が使用するリソースの使用量を動的に管理するリソース管理装置およびリソース管理方法に関わる。

従来、組込アプリケーション実行環境においては、アプリケーションが使用する一般的な情報機器資源であるところのリソースの総量に制限があることが一般的である。このために以下のようなことが一般的に行われている。すなわち各アプリケーションが使用するリソースの量について上限値を定める。加えて、アプリケーションインストール時の検査段階において、当該アプリケーションによるリソースの使用量がその上限値を超えないことをアプリケーション管理フレームワークが確認することによって、アプリケーションが安定稼働することを保証している。

従来技術として、情報機器内でアプリケーションが使用するリソース量を１回目の起動時に計測し、２回目以降の起動時にはその計測値を利用して起動するか否かを決定するリソース管理システムがある（例えば、特許文献１参照）。特許文献１によれば、或るアプリケーションの２回目以降の起動時に、計測値と情報機器内で起動されている他のアプリケーションの使用リソース量との総和が情報機器で使用可能なリソース領域を超えない場合は当該アプリケーションを起動し、超える場合は当該アプリケーションの起動を待機する。しかしながら、アプリケーションの使用リソースの上限値（すなわち最大値）による管理を行っていないため、実働中にアプリケーションの使用リソース量が情報機器で使用可能なリソース領域を超える場合があり得る。そのような場合に、アプリケーションを安定稼働させる保証ができない。

特開2009-20609号公報

使用リソースの上限値による管理においては、アプリケーション管理フレームワークは個々のアプリケーションについて使用量の上限値に相当するリソース領域を確保する。複数のアプリケーションが稼働中であれば、それらのリソース使用量が同時に上限に達することはないような場合でも、上限値の合計値に相当するリソースが確保される。このような場合には、実際のリソースの使用量は上限値の合計値よりも小さく、アプリケーションに割り当てられてはいるが使用されることのないリソース領域が生じる。そのため、ユーザが新たにアプリケーションをインストールしたい場合に、実際にはアプリケーションが必要なリソース量を確保できるにも関わらず、アプリケーション管理フレームワークはアプリケーションのインストールを許可できないことがある。このように、アプリケーションのリソース使用量を適切に管理することが困難であり、リソースの使用効率を低下させる原因となっていた。

本願発明は上記従来例に鑑みて成されたもので、アプリケーションをインストールする際のリソース管理をより柔軟におこなってリソースの利用効率を向上したリソース管理装置及びリソース管理方法を提供することを目的とする。

上記目的を達成するために本発明は以下の構成を有する。すなわち、グループ単位でアプリケーションのリソースを管理するためのリソース管理装置であって、
アプリケーションのインストールにより前記アプリケーションの宣言値に応じたリソースを前記アプリケーションのために確保するシステムに対して、グループに属するアプリケーションがインストールされた際には、リソース定義アプリケーションのリソースの宣言値に対し、インストールされた前記アプリケーションが属する前記グループのリソースの宣言値を加算する付け替え手段と、
前記付け替え手段による加算処理後、前記リソース定義アプリケーションを前記システムにインストールするインストール手段と
を有する。

本発明を用いれば、リソースサービスのリソース上限値を柔軟に変更できるようになる。

本発明の第一、第二の実施例の装置の全体の構成を示す図である。 本発明の第一、第二の実施例の画像形成装置（１００）のハードウェア構成を示す図である。 本発明の第一、第二の実施例のアプリケーション実行環境の構成を示す図である。 本発明の第一、第二の実施例のアプリケーションを構成するファイルの内容を示す図である。 本発明の第一、第二の実施例のフラグメントバンドルを構成するファイルの内容を示す図である。 本発明の第一、第二の実施例のグループデータテーブルの内容を示す図である。 、 、 、 本発明の第一の実施例のリソースサービスの処理流れを示すフローチャートである。 本発明の第二の実施例のリソースサービスＵＩの画面の一例を示す図である。 本発明の第二の実施例のリソースサービスの処理流れを示すフローチャートである。 、 、 グループＸの使用リソース領域を確保する時のイメージ図である。

以下、本発明を実施するための形態について図面を用いて説明する。本実施形態では、アプリケーションがリソース取得をリクエストする時にそのアプリケーションが使用リソースの上限値を超えるか否かを判定し、超えていなければリソースを確保する機能を持つリソースサービスを提供する。またリソースサービスは、アプリケーション単位ではなく、複数のアプリケーションを１つのグループとしてグループ単位でリソースを管理する。リソースサービスは、複数のアプリケーションを１つのグループとしてアプリケーション開発者が登録しておくことで、リソースの管理をグループ単位で行うようなグループ機能を持つ。例えば、リソース使用量が同時に上限に達しないアプリケーション同士を１つのグループとして開発者が登録しておくことで、リソースサービスはグループに属するアプリケーションが当該グループのリソース上限値を超えないように管理する。ここで、グループ単位のリソース管理も、アプリケーション管理フレームワークによるアプリケーション単位のリソース管理に則るために、グループが使用するリソースはリソースサービスの使用リソース上限値に含まれる。

ここでリソースサービスのリソース上限値はユーザの環境に柔軟に合わせて変更しなければならない。リソースサービスのリソース上限値を変更しなければならない要因として以下の３つの項目が挙げられる。
（１）ユーザが利用するグループ：ユーザが利用するアプリケーションの組み合わせによってグループのリソース上限値が変わる。
（２）ユーザが利用するリソースサービス非対応のアプリケーション：リソースサービス非対応アプリケーションの利用状況によって、情報機器内の空いているリソース領域が変わる。
（３）ユーザが利用する情報機器：ユーザが利用する情報機器によって、使用可能なリソース領域が変わる。
以上のような要因があるため、ユーザの環境に応じて、リソースサービスのリソース上限値は柔軟に変更しなければならない。

以下に説明する実施形態は、上述したようなリソースのアプリケーショングループ単位の管理を実現し、かつ柔軟で効率的なリソース管理を実現する装置、方法、プログラム等に関する。

［第一の実施形態］
＜画像形成装置の構成＞
図１に掲げるのは本発明の第一の実施形態の装置の全体の構成を示す図である。画像形成装置１００は本実施形態に係る画像形成装置である。ネットワーク１３０は画像形成装置１００と情報処理装置１０１を接続するネットワークである。情報処理装置１０１は画像形成装置１００をネットワーク１３０経由で利用するために用いられる。

アプリケーション１１０は画像形成装置１００上で動作するアプリケーションの一つの例であるアプリケーションＡである。アプリケーション１１１は同様に画像形成装置１００上で動作するアプリケーションのもう一つの例であるアプリケーションＢである。さらにアプリケーション１１２は同様に画像形成装置１００上で動作するアプリケーションのさらなる一つの例であるアプリケーションＣである。画像形成装置１００上では一つ、あるいは複数のアプリケーションを動作させることが可能である。ここではアプリケーションを三つ例示している。以後、「アプリケーション１１ｎ」という表現は、アプリケーションＡ１１０、アプリケーションＢ１１１、アプリケーションＣ１１２にて代表されるような一つまたは複数のアプリケーションを指す。一般利用者および管理者は画像形成装置１００の基本機能、アプリケーション１１ｎ、および、画像形成装置１００やアプリケーション１１ｎを管理するためのリソース管理装置を利用することが可能である。利用に当たっては、画像形成装置１００を直接操作、もしくはネットワーク１３０経由で情報処理装置１０１から操作することが可能である。

図２は画像形成装置１００のハードウェア構成を図式化したものである。コア部２００はプロセッサやメモリ等を有し、オペレーティングシステムやアプリケーション等のプログラムを実行し、本実施形態に係るリソース管理を実現する。ユーザーインターフェース部２０１は、タッチパネルやディスプレイ、キーボード等を有し、ユーザに対する情報を出力（表示）し、またユーザから操作等の入力を受け付ける。記憶装置２０２は、例えばハードディスクなどで構成され、プログラムやデータをファイルとして格納する。ネットワークインターフェース部２０３は、例えばＬＡＮ等のネットワーク１３０に接続するためのネットワークインターフェースである。スキャナー部２０４は、原稿画像をたとえば光学的に読み取って画像データを出力する。プリンター部２０５は、画像データに対応した画像を媒体上に形成する。フィニッシャー部２０６は、プリンター部で画像形成したシート媒体に、ソーティングやステープル、穿孔等の仕上げ処理を施す。

＜画像形成装置のアプリケーション及びその実行環境＞
図３は本実施形態における画像形成装置１００の上でアプリケーション１１ｎを実行するためのアプリケーション実行環境である。アプリケーション実行基盤３０１は、アプリケーションを実行するためにプログラムであり、例えばＪａｖａ仮想マシン（ＪａｖａＶＭ）等である。アプリケーション管理フレームワーク３０２はアプリケーション１１ｎのインストールおよびアンインストール、実行と停止を管理するフレームワークであり、たとえばＪａｖａ（登録商標）ベースのＯＳＧｉ（ＯＰＥＮ Ｓｅｒｖｉｃｅｓ Ｇａｔｅｗａｙ ｉｎｉｔｉａｔｉｖｅ）フレームワークなどである。アプリケーション実行環境内へアプリケーション１１ｎをインストールして実行するには、アプリケーション管理フレームワーク３０２を利用する。アプリケーション管理フレームワーク３０２の一般的な基本動作として、アプリケーション管理フレームワーク３０２は、管理者がアプリケーション１１ｎをインストールするリクエストを行うことにより、インストール動作を行う。その際にアプリケーション管理フレームワーク３０２は、インストール対象のアプリケーションのアプリケーションリソース上限宣言ファイル４０２（図４Ａ参照）を参照して、そこに宣言されているリソース上限値が現在のアプリケーション実行環境内のリソースの空き容量の中に納まるかどうかを判定する。そして、もしも納まらなければインストールを失敗させる。すなわち、たとえばアプリケーションのインストールを行うことなく処理を終了し、失敗した旨を管理者に通知する。サポートライブラリ３０３はアプリケーション１１ｎが画像形成装置１００のさまざまな機能を利用するためのサポートライブラリである。以降は本実施形態を実施するための特別な構成要素の説明である。

リソースサービス３０４はアプリケーション１１ｎが使用するリソースを管理するためのプログラムである。リソースサービス３０４の基本的な動作には、アプリケーション１１ｎが使用するリソースを管理する機能と、複数のアプリケーションをグループとして管理する機能がある。リソースサービス３０４はアプリケーションのひとつであるが、アプリケーション１１ｎには含まれない。リソースサービス３０４は、他のアプリケーションに対して提供するＡＰＩを実装し、リソースサービスを使用するアプリケーションはこれらのＡＰＩを呼び出しリソースの取得や解放、使用をおこなう。リソースサービスにより確保されたリソースは、リソースオブジェクトとしてその要求元に返される。リソースサービスによる管理対象のリソースには、たとえばストレージのリソースとしてファイル、通信のリソースとしてソケット、コンピューティングリソースとしてスレッド等がある。もちろんこれら以外のリソースも管理対象に含まれる。リソースオブジェクトとは、上述したようなリソースの抽象化ということもでき、たとえば確保したリソースを示す情報を含む。リソースオブジェクトをアプリケーションに渡す（返す）ことは、要求されたリソースをアプリケーションに割り当て、引き渡すことに相当する。そのため、以下の説明ではリソースオブジェクトを返すことを単にリソースを返すと表現する。

まず、アプリケーション１１ｎが使用するリソースを管理する機能について説明する。一般的なアプリケーションは、リソースを取得する際および解放する際に、アプリケーション実行基盤にリソース取得リクエスト、リソース解放リクエストをそれぞれ送る。対して、リソースサービス３０４対応のアプリケーション１１ｎは、リソースを取得する際および使い終わって解放する際に、リソースサービス３０４に対してリソース取得リクエスト、リソース解放リクエストをそれぞれ送る。リソース取得リクエストを受けたリソースサービス３０４は、アプリケーション１１ｎに設定されているリソースの使用量の上限値を参照する。その上で、リソース上限に達していなければリソースを確保してアプリケーション１１ｎへ返す。上限を超えてしまう場合にはエラーを返す。

＜グループ管理機能の概略＞
次に、複数のアプリケーションをグループとして管理する機能について説明する。その前にまずバンドルおよびフラグメントバンドルについて説明する。バンドルとは、ＯＳＧｉフレームワークの上で、Ｊａｖａ（登録商標）の実行基盤であるＪａｖａＶＭとは独立してインストールやアンインストール、起動或いは停止可能なプログラム部品（いわゆるプラグイン）である。フラグメントバンドルとは、ＯＳＧｉフレームワークにおいては、その内容を他のバンドル（ホストバンドルと呼ぶ）により共有できるようなバンドルであり、アプリケーションと同様に、マニフェストヘッダー（図４Ｂのフラグメントバンドルリソース上限宣言ファイル）を持つＪａｖａ（登録商標）アーカイブファイルとして提供される。フラグメントバンドルはアプリケーションと同様であるので、本実施形態ではフラグメントアプリケーションと呼ぶこともある。

次に、図４Ａ、図４Ｂを参照してアプリケーションおよびフラグメントバンドルについてその構成を説明する。図４Ａは本実施形態におけるアプリケーション１１ｎを構成する代表的なファイルの内容について解説した図である。アプリケーション１１ｎはいくつかの種類のファイルを抱えている。アプリケーション実行コードファイル４００はアプリケーションの実行コード等を含むファイルである。アプリケーション固定データファイル４０１はアプリケーションが持っている固定データを収めたファイルである。アプリケーションリソース上限宣言ファイル４０２はアプリケーションの使用するリソースの上限値を宣言するためのファイルである。

さらにアプリケーションリソース上限宣言ファイル４０２はその内容として以下の記述を含んでいる。アプリケーションＩＤ４１０はアプリケーション１１ｎのＩＤの値の記載である。グループＩＤ４１１はアプリケーション１１ｎが属するグループを指定するグループＩＤの記載である。リソース上限値４１２はアプリケーション１１ｎが使用するリソースの上限値の宣言であるところの、リソース上限値（あるいは宣言値）である。アプリケーション１１ｎをアンインストールするまで、このリソース上限値を変更してもアプリケーション管理フレームワーク３０２が内部で管理しているリソース上限値に反映されない。リソース上限値４１３は、アプリケーション１１ｎがリソースサービス３０４にリソースのリクエストを行って使用するリソース上限値である。リソースサービス３０４用のリソース上限値４１３は、アプリケーションがグループに属していない状態でリソースサービス３０４に管理される場合に記載してある。

図４Ｂはフラグメントバンドル３０６ｎを構成する代表的なファイルの内容について解説した図である。フラグメントバンドル３０６ｎも、基本的には図４Ａに掲げたアプリケーション１１ｎと同様の構成になっている。フラグメントバンドル実行コードファイル４２０は実行コード等を含むファイルである。フラグメントバンドル固定データファイル４２１は固定データを収めたファイルである。フラグメントバンドルリソース上限宣言ファイル４２２は、フラグメントバンドルが使用するリソースの上限を記述したファイルである。

フラグメントバンドルＩＤ４３０はフラグメントバンドルの識別情報を示している。またグループＩＤ４３１はこのフラグメントバンドル３０６ｎが宣言するグループのグループＩＤを示している。リソース上限値４３２はフラグメントバンドル３０６ｎに記載されているグループＩＤ４３１のグループが有効になった時に、そのグループに対して割り当てられるリソース使用量を宣言するリソース上限値を示している。アプリケーションＩＤ４３３はこのフラグメントバンドル３０６ｎが宣言するグループに属する一つまたは複数のアプリケーション１１ｎのアプリケーションＩＤを示す。グループ情報４３４はグループＩＤ４３１について記載しているグループ情報である。

なおここではフラグメントバンドルという用語の示す概念には、アプリケーション管理フレームワーク３０２がＯＳＧｉフレームワークではないとしても、ＯＳＧｉフレームワークのフラグメントバンドルに相当するソフトウェア部品を含む。

次にグループ管理機能の概略を説明する。アプリケーション管理フレームワーク３０２は、アプリケーションを１つ１つのアプリケーションとして管理する。対して、リソースサービス３０４は、フラグメントバンドル３０６ｎが持つ宣言ファイルに含まれたグループ情報４３４に基づき、複数のアプリケーションをグループとして管理する。リソースサービス３０４は、グループに所属するアプリケーション１１ｎがインストールされた時か、あるいはリソースを取得する時に、グループのリソース上限値４３２を参照する。グループに所属するアプリケーション１１ｎがアプリケーション管理フレーム３０２によってインストールされた際、リソースサービス３０４はそのグループのリソース上限値が現在のアプリケーション実行環境内のリソースの空き容量の中に納まるかどうかを判定する。もしも納まらなければ、リソースサービス３０４はグループに所属するアプリケーションをアンインストールさせる。また、グループに所属するアプリケーション１１ｎがリソースを取得する際、リソースサービス３０４はアプリケーション１１ｎに設定されているリソースの使用量の上限値を参照する。その上で、リソース上限に達していなければリソースを確保してアプリケーション１１ｎへ返す。上限を超えてしまう場合にはエラーを返す。

グループ設定バンドル３０５はリソースサービス３０４に対して補完用モジュールとして動作するプログラムである。フラグメントバンドルのインストール、アンインストールにはホストバンドルが必要で、加えてフラグメントバンドルのインストール時、アンインストール時にはホストバンドルは停止状態でなければならない。従って、グループ設定バンドル３０５は、後に出てくるフラグメントバンドル３０６ｎをインストール、アンインストールするためにリソースサービス３０４に対して補完用モジュールとして動作する。また、グループ設定バンドル３０５はリソースサービス３０４がインストールされているフラグメントバンドル３０６ｎの情報を取得するためにも動作する。

フラグメントバンドル３０６１〜３０６３は、グループ設定バンドル３０５をホストバンドルとして動作するフラグメントバンドルである。開発者はあらかじめフラグメントバンドル３０６ｎにグループ情報４３４を記載する。グループ情報４３４にはグループＩＤ４３１、グループのリソース上限値４３２、グループに所属するアプリケーションＩＤ４３３がある。管理者が複数のアプリケーションを１つのグループとして利用したい場合、管理者はそのグループのフラグメントバンドル３０６ｎをインストールするリクエストを行う。複数のグループを利用する場合、ユーザはそのグループの分だけフラグメントバンドル３０６ｎをインストールするリクエストを行う。

リソースサービス３０４とグループ設定バンドル３０５、及びリソース定義バンドル３０７も基本的にはアプリケーションの一つであり、図４Ａに掲げたアプリケーション１１ｎと同様の構成になっている。したがってリソース定義バンドルをリソース定義アプリケーションと呼びかえることもできる。リソース定義バンドル３０７はリソースサービス３０４に対して補完用モジュールとして動作するバンドルである。リソース定義バンドル３０７をインストールする際に必要なリソース定義バンドル元データ３０８は、リソースサービス３０４の開発者があらかじめリソースサービス３０４の内部に保持させている。リソース定義バンドル元データ３０８には、たとえば或る時点におけるリソース定義バンドル３０７のリソース上限値などが含まれる。その初期値は、たとえばリソース定義バンドル３０７自身が消費するリソースの上限値である。

リソース定義バンドル３０７はグループに属するアプリケーション１１ｎが使用するリソース領域を確保するためのバンドルである。アプリケーション管理フレームワーク３０２がグループに属するアプリケーション１１ｎをインストール、あるいはアンインストールすると、リソースサービス３０４はそのアプリケーション１１ｎのアプリケーションＩＤが所属アプリケーションＩＤ４３３として記載されたフラグメントバンドル３０６ｎのグループ情報４３４を参照する。そして、リソースサービス３０４は、アプリケーション１１ｎが属するグループのリソース上限値４３２を、リソース定義バンドル元データのリソース上限値４１２に加算（増加した場合）、あるいは減算（減少した場合）する。その上で、リソース上限値４１２を変更したリソースサービス定義バンドルの元データに基づいてリソース定義バンドル３０７をインストールするリクエストをリソースサービス３０４が行う。リソース上限値４１２が変更されたリソースサービス定義バンドル３０７がインストールされることにより、リソース定義バンドル元データのリソース上限値４１２のリソースが確保される。すなわち、グループに属するアプリケーション１１ｎが使用するリソース領域を確保することができる。

リソースサービスを区別する特徴は、他の不特定のアプリケーション１１ｎに対してサービスを提供する共通のアプリケーションプログラミングインターフェース（以下「ＡＰＩ」と略す）を提供する点である。また、リソースサービス３０４はアプリケーション管理フレームワーク３０２にグループ設定バンドル３０５を開始、停止するリクエストや、リソース定義バンドル３０７をインストール、アンインストールするリクエストを行う。リソース定義バンドル３０７をインストールするためのリソース定義バンドル元データ３０８は、リソースサービス３０４の内部データとして保持されている。リソースサービス３０４はアプリケーション管理フレームワーク３０２に、保持しているリソース定義バンドル元データ３０８をインストールするリクエストを行う。アプリケーション管理フレームワーク３０２はインストールを指示されるとリソース定義バンドル元データ３０８を使って、新しくリソース定義バンドル３０７をインストールする。

グループ設定バンドル３０５を区別する特徴は、グループ設定が記載されたファイルを保持するフラグメントバンドルを管理している点と、リソースサービス３０４の開始時とグループの設定時以外には開始されない点である。グループ設定バンドル３０５はフラグメントバンドル３０６ｎに対してホストバンドルとして動作しているため、フラグメントバンドル３０６ｎのインストール・アンインストールの前にグループ設定バンドル３０５を一度停止させる必要がある。フラグメントバンドル３０６ｎのインストール・アンインストールそのものはアプリケーション管理フレームワーク３０２により実施される。

リソース定義バンドル３０７をアプリケーション１１ｎと区別する特徴は、フラグメントバンドル３０６ｎに宣言されたリソース上限値をリソース定義バンドルのアプリケーションリソース上限宣言ファイルに加算されている点である。

アプリケーション管理フレームワーク３０２はフラグメントバンドル３０６ｎをインストール指示された場合には、フラグメントバンドル３０６ｎのインストール動作を行う。インストール動作が完了すると、アプリケーション管理フレームワーク３０２はリソースサービス３０４にフラグメントバンドル３０６ｎのインストール完了通知を送信する。リソースサービス３０４はインストール完了通知を受信すると、アプリケーション管理フレームワーク３０２にグループ設定バンドル３０５を開始するリクエストを行う。グループ設定バンドル３０５が開始されたら、リソースサービス３０４はグループ設定バンドル３０５にフラグメントバンドル３０６ｎのグループ情報４３４を要求する。グループ設定バンドル３０５はインストールされているフラグメントバンドル３０６ｎのフラグメントバンドルリソース上限ファイル４２２を参照する。そして、そこに宣言されているグループＩＤ４３１、リソース上限値４３２、所属アプリケーション４３３をリソースサービスに渡す。リソースサービス３０４はこのグループ情報４３４を取得すると記憶装置２０２に記憶し、アプリケーション管理フレームワーク３０２にグループ設定バンドル３０５を停止するリクエストを行う。

＜グループデータテーブルの例＞
図５は本実施形態のリソースサービス３０４がアプリケーション１１ｎのグループ管理を実施するために必要とするデータを保持するためのデータテーブルのうち、グループデータテーブルを模式的に表したものである。グループデータテーブル５００は、リソースサービス３０４がグループ設定バンドル３０５から取得したフラグメントバンドルの情報を記憶装置２０２に記憶するグループデータテーブルである。

５０１はフラグメントバンドルＩＤ４３０の保持欄である。５０２はグループＩＤ４３１の保持欄である。５０３はリソースサービス３０４がフラグメントバンドル３０６ｎを最初に検出した時刻の保持欄である。リソースサービス３０４がフラグメントバンドル３０６ｎを最初に検出するのは、リソースサービス３０４がグループ情報４３４を取得した時刻である。５０４はインストールされて検出したフラグメントバンドル３０６ｎが削除されて消えていたことをリソースサービス３０４が検出した時刻の保持欄である。削除の検出は、記憶装置２０２に記憶していたグループＩＤ４３１を持つフラグメントバンドル３０６ｎがアンインストールされていることをリソースサービス３０４が検出した時刻である。５０５はそのフラグメントバンドル３０６ｎがグループとして管理する対象とするアプリケーションのアプリケーションＩＤ４１０の保持欄である。５０６は当該フラグメントバンドルが有効であるか否かを記録する有効化状態の保持欄である。この有効化状態の保持欄５０６には「有効」「無効」「アンインストール済」の三通りの状態が保持され得る。フラグメントバンドル３０６ｎがインストールされた後、リソースサービス３０４がグループ情報４３４を取得した時には、リソースサービス３０４は有効化状態５０６を「無効」に設定する。そして、管理対象アプリケーションＩＤ５０５に該当するいずれかのアプリケーション１１ｎがインストールされると「有効」に設定する。管理対象アプリケーションＩＤ５０５に該当するアプリケーション１１ｎが全てアンインストールされると、リソースサービス３０４は有効化状態５０５を「アンインストール済み」に設定する。５０７はリソースサービス３０４がグループ設定バンドル３０５から取得したリソース上限値４３２の保持欄である。リソースサービス３０４がアプリケーション１１ｎからリソースのリクエストを受けた時、リソースサービス３０４はそのアプリケーション１１ｎが使用しているリソース量がリソース上限値を超えていないか判定する。この際、リソースサービス３０４はグループデータテーブル５００のリソース上限値５０７を参照する。そして、使用しているリソース量がリソース上限値５０７を超えていれば、リソースサービス３０４はアプリケーション１１ｎにエラーを返す。５１０はある一つのフラグメントバンドル３０６ｎに関するグループデータテーブル５００のエントリーである。

次にリソースサービス３０４がグループデータテーブル５００を参照する例について説明する。アプリケーション管理フレームワーク３０２はアプリケーション１１ｎをインストール指示された場合には、アプリケーション１１ｎのインストール動作を行う。インストール動作が完了すると、アプリケーション管理フレームワーク３０２はリソースサービス３０４にアプリケーション１１ｎのインストール完了通知を送信する。リソースサービス３０４はインストール完了通知を受信すると、インストールされたアプリケーション１１ｎのアプリケーションリソース上限宣言ファイル４０２に記載されているアプリケーションＩＤ４１０とグループＩＤ４１１を参照する。参照したＩＤがグループデータテーブル５００に記憶され、かつ有効化状態５０６が無効になっている場合、リソースサービス３０４はリソース定義バンドル元データ３０８のリソース上限値４１２を変更する。リソース上限値４１２の変更とは、リソースサービス３０４が参照したグループＩＤ４１１のリソース上限値５０７を、リソース定義バンドル元データ３０８のリソース上限値４１２に加算することである。リソース上限値４１２の変更後、リソース定義バンドル３０７がインストールされている場合、リソースサービス３０４はアプリケーション管理フレームワーク３０２にリソース定義バンドル３０７をアンインストールするリクエストを行う。リソース定義バンドル３０７がインストールされていない状態になった後、リソースサービス３０４はアプリケーション管理フレームワーク３０２にリソース定義バンドル３０７をインストールするリクエストを行う。アプリケーション管理フレームワーク３０２はリソース定義バンドル３０７のアプリケーションリソース上限宣言ファイル４０２を参照する。そして、そこに宣言されているリソース上限値４１２が、現在のアプリケーション実行環境内のリソースの空き容量の中に納まるかどうかを判定する。納まる場合にはインストールを完了する。インストールが完了するとアプリケーション管理フレームワーク３０２はリソースサービス３０４にリソース定義バンドル３０７のインストール完了通知を送信する。リソースサービス３０４はその通知を受信すると、参照したグループＩＤ４１１のグループデータテーブル５００に記載されている有効化状態５０６を有効に変更する。

＜リソース定義バンドルのインストールによるリソース領域の確保＞
図９Ａ、図９Ｂ、図９ＣはグループＸに属するアプリケーションＡ１１０が使用するリソース領域をリソース定義バンドル３０７のインストールによって確保するイメージ図である。図９Ａは管理者がフラグメントバンドルＸ３０６１をインストールするリクエストを行う時のイメージ図である。管理者がフラグメントバンドルをインストールする時には、画像形成性装置１００の記憶装置２０２にアプリケーション管理フレームワーク３０２、リソースサービス３０４、グループ設定バンドル３０５はインストールされた状態である。また、フラグメントバンドルＸ３０６１はグループＸのグループ情報４３４が記載されたフラグメントバンドルリソース上限宣言ファイル４２２を持っている。リソースサービス３０４は、リソース定義バンドル３０７のインストールに必要なリソース定義バンドル元データ３０８と、グループデータテーブル５００を持つ。

管理者がグループＸの情報をリソースサービス３０４に登録したい場合、まず図９Ａに示すように、管理者がフラグメントバンドルＸ３０６１をインストールするリクエストをアプリケーション管理フレームワーク３０２に行う。フラグメントバンドルＸ３０６１がインストールされると、リソースサービス３０４はフラグメントバンドルのインストール完了通知を受信する。インストール完了通知の受信後、リソースサービス３０４はフラグメントバンドルＸ３０６１に記載されたグループＸのグループ情報４３４を取得し、そのグループ情報４３４をグループデータテーブル５００に記憶する。グループＩＤ４３１はグループＩＤ５０２に、リソース上限値４４３２はリソース上限値５０７に、所属アプリケーションＩＤは管理対象アプリケーションＩＤ５０４に複製される。この時にグループデータテーブル５００の有効化状態６０６は無効になっている。リソースサービス３０４がグループデータテーブル５００にグループ情報４３４を記憶することによって、リソースサービス３０４へのグループＸの情報登録は完了する。

図９Ｂは、図９Ａの後に管理者がグループＸに属するアプリケーションＡ１１０のインストールリクエストを行い、アプリケーション管理フレームワーク３０２がアプリケーションＡ１１０をインストールした後のイメージ図である。図９ＡでフラグメントバンドルＸ３０６１がインストールされたため、グループ設定バンドル３０５はフラグメントバンドルＸ３０６１を持つ。

アプリケーション管理フレームワーク３０２がグループＸに属するアプリケーションＡ１１０をインストールすると、リソースサービス３０４はアプリケーションのインストール完了通知を受信する。インストール完了通知の受信後、リソースサービス３０４はインストールされたアプリケーションＡ１１０が属するグループＸの、グループデータテーブル５００に登録されたリソース上限値５０７を参照する。そして、リソースサービス３０４は、参照したグループＸのリソース上限値５０７を、リソース定義バンドル元データ３０８が持つアプリケーションリソース上限宣言ファイル４０２のリソース上限値４１２に加算する。リソース定義バンドル元データ３０８のリソース上限値４１２を変更すると、図９Ｃに示すようにリソース定義バンドル３０７のインストールを行う。

図９Ｃは、図９Ｂの後にリソースサービス３０４がリソース定義バンドル３０７のインストールリクエストを行い、アプリケーション管理フレームワーク３０２がリソース定義バンドル３０７をインストールする時のイメージ図である。リソースサービス３０４は、リソース定義バンドル元データ３０８に基づいてリソース定義バンドル３０７をインストールするリクエストをアプリケーション管理フレームワーク３０２に行う。そしてアプリケーション管理フレームワーク３０２はリソース定義バンドル３０７をインストールする。リソース定義バンドル３０７がインストールされることにより、グループＸに属するアプリケーションの使用するリソース領域９３０が確保される。なお、図９ＣではアプリケーションＡ１１０のリソース領域が確保されているが、ここでアプリケーションＡが確保しているリソース領域はアプリケーションのインストール処理に必要な最小限のリソース領域である。この後、管理者がグループＸに属するアプリケーションＢ１１１をインストールする場合、グループＸの使用リソース領域が確保されているので、アプリケーションＢ１１１もリソースを使用することができる。また、アプリケーション管理フレームワーク３０２がリソース定義バンドル３０７をインストールする際、記憶装置２０２に必要なリソース領域が確保できない場合、リソース定義バンドル３０７のインストールに失敗する。その場合は、リソースサービス３０４はアプリケーションＡ１１０のアンインストールリクエストをアプリケーション管理フレームワークに行い、エラー処理をする。

以上より、図９Ａ、図９Ｂ、図９Ｃのイメージ図に示すように、グループのリソース上限値に対して柔軟に、グループに属するアプリケーションが使用するリソース領域を確保することができる。

＜リソースサービスの処理の流れ＞
図６Ａは本実施形態におけるリソースサービス３０４が開始されてから停止するまでの処理の流れを模式的に表したフローチャートである。リソースサービスの処理と並行して、あるいはリソースサービスが停止しているときに、管理者は、各グループのフラグメントバンドルやアプリケーションのインストールやアンストールを例えばアプリケーション管理フレームワーク３０２に対して指図することができる。アプリケーション管理フレームワーク３０２により、これらのインストール或いはアンインストールが実行されると、その完了通知がリソースサービス３０４に出され、リソースサービスはその通知に応じた処理を図６Ａで実行する。

その処理により、ここまでに述べた通りグループ設定バンドル３０５に対してグループ情報４３４を保持するフラグメントバンドル３０６ｎを追加でインストールすることでグループ情報４３４を追加認識させることが可能である。また、グループ情報４３４に記載されているアプリケーションをインストールすることで追加したグループを有効にすることが可能である。同様にグループ情報４３４に記載されているアプリケーションを全てアンインストールすることで、グループを無効にすることが可能である。そして、フラグメントバンドル３０６ｎをアンインストールすることでグループ情報４３４をリソースサービスの制御下より取り除くことも可能である。ここで説明する処理はグループが有効あるいは無効になっている場合に、改めてリソースサービス３０４が停止状態から開始される際に実行されるものである。

処理はＳ６００１から開始する。処理のきっかけは例えば管理者がリソースサービス開始のリクエストをユーザーインターフェース部２０１等から入力したことである。

Ｓ６００２でリソースサービス３０４はまずグループ情報４３４を更新する。ここで、前回のリソースサービス停止時から、リソース定義バンドル３０７のリソース上限値を更新する必要があるか否かを判定し、必要がある場合はリソース定義バンドル元データ３０８のリソース上限値４１２を変更する。Ｓ６００２の処理の詳細は図６Ｂに示す。

Ｓ６００３ではリソースサービス３０４は、アプリケーション管理フレームワーク３０２からフラグメントバンドル３０６ｎのインストール完了通知を受信したかを判定し、受信していればＳ６００４へ進む。受信していなければＳ６００５へ進む。

Ｓ６００４ではリソースサービス３０４はフラグメントバンドルインストール時の処理を行う。詳細には、リソースサービス３０４はアプリケーション管理フレームワーク３０２にグループ設定バンドル３０５を開始するリクエストを行う。グループ設定バンドル３０５が開始されたら、リソースサービス３０４はグループ設定バンドル３０５にフラグメントバンドル３０６ｎのグループＩＤ４３１、リソース上限値４３２、所属アプリケーション４３３を要求する。グループ設定バンドル３０５はインストールされているフラグメントバンドル３０６ｎのフラグメントバンドルリソース上限ファイル４２２を参照する。そして、そこに宣言されているグループＩＤ４３１、リソース上限値４３２、所属アプリケーション４３３をリソースサービス３０４に渡す。リソースサービス３０４はその情報を取得すると記憶装置２０２に記憶する。記憶したグループＩＤ４３１がグループデータテーブル５００に登録されていなければ、グループＩＤ４３１、リソース上限値４３２、所属アプリケーション４３３をグループデータテーブル５００の該当する欄に登録し、有効化状態を「無効」としておく。そしてアプリケーション管理フレームワーク３０２にグループ設定バンドル３０５を停止するリクエストを行う。グループ設定バンドル３０５が再度停止状態になれば、フラグメントバンドルインストール時の処理は完了である。すなわち、フラグメントバンドル３０６ｎのインストールは、フラグメントバンドル３０６ｎに対応するグループのリソースの宣言値をリソースサービス３０４に対して引き渡すための手段として機能する。フラグメントバンドルインストール時の処理が完了したら処理はＳ６００５へ進む。

Ｓ６００５では、リソースサービス３０４はフラグメントバンドルのアンインストール完了通知を受信したかを判定し、受信していればＳ６００６へ進む。受信していなければＳ６００７へ進む。なお、フラグメントバンドル３０６ｎのグループ情報４３４に記載されているアプリケーション１１ｎがインストールされている場合、管理者はそのフラグメントバンドル３０６ｎをアンインストールできない。このような場合にはアンインストール完了通知を受信することはない。

Ｓ６００６ではフラグメントバンドルのアンインストール時の処理を行う。リソースサービス３０４はグループデータテーブル５００から、アンインストールしたフラグメントバンドル３０６ｎのグループ情報４３４を取り除く。あるいは、有効化状態をアンインストール済に設定する。グループ情報４３４を取り除いたらフラグメントバンドルのアンインストール時の処理は完了である。フラグメントバンドルアンインストール時の処理が完了したら処理はＳ６００７へ進む。

Ｓ６００７ではリソースサービス３０４がアプリケーション１１ｎのインストール完了通知を受信したかを判定し、受信していればＳ６００８へ進む。受信していなければＳ６００９へ進む。Ｓ６００８では、リソースサービス３０４はアプリケーションインストール時の処理を行う。Ｓ６００８の処理の詳細は図６Ｃに示す。インストール時の処理が完了したらＳ６００９へ進む。

Ｓ６００９ではリソースサービス３０４がアプリケーション１１ｎのアンインストール完了通知を受信したかを判定し、受信していればＳ６０１０へ進む。受信していなければＳ６０１１へ進む。Ｓ６０１０では、リソースサービス３０４はアプリケーションのアンインストール時の処理を行う。Ｓ６０１０の処理の詳細は図６Ｄに示す。アンインストール時の処理が完了したらＳ６０１１へ進む。

Ｓ６０１１で、リソースサービス３０４がアプリケーション管理フレームワーク３０２によって停止されるかを判定し、停止されるのであればＳ６０１２へ進む。停止されないのであれば、Ｓ６００３へ進む。Ｓ６０１２へ到達したらリソースサービス３０４の開始から停止までの処理は完了する。

＜リソースサービスの処理まとめ＞
以上より、管理者がリソースサービス開始のリクエストを行うと、アプリケーション管理フレームワーク３０２はリソースサービス３０４を開始し、リソースサービス３０４が図６Ａのフローチャートの処理を実行する。そして、管理者がフラグメントバンドル３０６ｎのインストールのリクエストを行うと、アプリケーション管理フレームワーク３０２はフラグメントバンドル３０６ｎをインストールする。インストールが完了すると、アプリケーション管理フレームワーク３０２はリソースサービス３０４に対してインストール完了通知を発行する。Ｓ６００３でリソースサービス３０４がインストール完了通知を受信したと判定すると、Ｓ６００４へ進む。

管理者がフラグメントバンドル３０６ｎのアンインストールのリクエストを行うと、アプリケーション管理フレームワーク３０２はフラグメントバンドル３０６ｎをアンインストールする。アンインストールが完了すると、アプリケーション管理フレームワーク３０２はリソースサービス３０４に対してアンインストール完了通知を発行する。Ｓ６００５で、リソースサービス３０４がアンインストール完了通知を受信したと判定すると、Ｓ６００６へ進む。管理者がアプリケーション１１ｎのインストールのリクエストを行うと、アプリケーション管理フレームワーク３０２はアプリケーション１１ｎをインストールする。インストールが完了すると、アプリケーション管理フレームワーク３０２はリソースサービス３０４に対してインストール完了通知を発行する。Ｓ６００７でリソースサービス３０４はインストール完了通知を受信したと判定すると、Ｓ６００８へ進む。管理者がアプリケーション１１ｎのアンインストールのリクエストを行うと、アプリケーション管理フレームワーク３０２はアプリケーション１１ｎをアンインストールする。アンインストールが完了すると、アプリケーション管理フレームワーク３０２はリソースサービス３０４に対してインストール完了通知を発行する。Ｓ６００９でリソースサービス３０４がアンインストール完了通知を受信したと判定すると、Ｓ６０１１へ進む。管理者がリソースサービス停止のリクエストを行うと、Ｓ６０１１でアプリケーション管理フレームワークがリソースサービスを停止して、図６Ａのフローチャートの処理が完了する。停止しなければＳ６００３からリソースサービスの処理を繰り返す。

図６Ｂは、Ｓ６００２でリソースサービス３０４がグループ情報４３４を更新する処理の流れを模式的に表したフローチャートである。処理はＳ６１０１から開始する。

Ｓ６１０２でリソースサービス３０４はグループデータテーブル５００のグループ情報４３４を更新する。図９Ａ、図９Ｂ、図９Ｃを参照して説明したように、フラグメントバンドル３０６ｎのインストールにより、インストールしたフラグメントバンドル３０６ｎのグループ情報４３４はグループデータテーブル５００に記憶される。ここではその処理を行う。そのためにリソースサービス３０４はグループ設定バンドル３０５の開始のリクエストをアプリケーション管理フレームワーク３０２に行う。アプリケーション管理フレームワーク３０２はグループ設定バンドル３０５を開始する。グループ設定バンドル３０５が開始されると、リソースサービス３０４はグループ設定バンドル３０５からグループ情報４３４を取得する。リソースサービス３０４はグループデータテーブル５００の内容を、取得したグループ情報４３４を基に更新する。更新するとは、たとえば取得したグループ情報３４３の各項目を、グループデータテーブル５００の対応する項目へと複製することで行う。これにより新たにインストールされたフラグメントバンドルがあっても、そのグループ情報がグループデータテーブル５００に反映される。更新が完了したらＳ６１０３へ進む。

Ｓ６１０３でリソースサービス３０４は、更新したグループデータテーブル５００に記載された管理対象アプリケーションＩＤ５０５に該当するアプリケーション１１ｎがインストールされているか判定する。管理対象アプリケーションＩＤ５０５に該当するアプリケーションとはグループに属するアプリケーションである。この判定は例えば、インストール済みのアプリケーションについてそのＩＤを登録したテーブル等を参照するか、あるいはアプリケーション管理フレームワーク３０２に問い合わせることで行う。インストールされていればＳ６１０４へ進み、インストールされていなければＳ６１１２へ進む。Ｓ６１０４で、リソースサービス３０４は、該当するアプリケーション１１ｎが属しているグループの有効化状態５０６を「有効」にする。Ｓ６１０５で、リソースサービス３０４は有効化状態５０６が有効になっているグループのリソース上限値５０７を合計し、その合計値とリソース定義バンドル元データ３０８のリソース上限値４１２が等しいかを判定する。等しくなければＳ６１０６へ進み、等しければＳ６１１２へ進む。Ｓ６１０６で、リソースサービス３０４はリソース定義バンドル元データ３０８のリソース上限値４１２を、有効化状態５０６が有効になっているグループのリソース上限値５０７の合計に記載し直す。リソース上限値４１２の変更後Ｓ６１０７へ進む。

Ｓ６１０７でリソースサービス３０４はリソース定義バンドル３０７がインストールされているかを判定する。インストールされていればＳ６１０８へ進み、インストールされていなければＳ６１０９へ進む。Ｓ６１０８で、リソースサービス３０４はリソース定義バンドル３０７をアンインストールするリクエストをアプリケーション管理フレームワーク３０２に行う。そして、アプリケーション管理フレームワークはリソース定義バンドルをアンインストールする。アンインストールが完了したら、Ｓ６１０９へ進む。

Ｓ６１０９で、リソースサービス３０４はリソース定義バンドル元データ３０８をインストールするリクエストをアプリケーション管理フレームワーク３０２に行う。アプリケーション管理フレームワーク３０２はリソース定義バンドル元データ３０８のリソース上限値４１２を参照して、その上限値が現在のアプリケーション実行環境内のリソースの空き容量の中に納まるかどうかを判定する。そして、もしも納まらなければインストールを失敗させる。納まっていれば、アプリケーション管理フレームワーク３０２はリソース定義バンドル元データ３０８を使って、リソース定義バンドル３０７をインストールする。リソースサービス３０４がインストールのリクエストを行った後、Ｓ６１１０へ進む。

Ｓ６１１０で、リソースサービス３０４はＳ６１０９でインストールリクエストしたリソース定義バンドル３０７がインストールされているかを判定する。インストールされていればＳ６１１２へ進み、インストールがされていなければＳ６１１１へ進む。Ｓ６１１１で、リソースサービス３０４は「有効になっているグループのリソース上限値が現在のアプリケーション実行環境内のリソースの空き容量の中に納まっていない」旨の警告を出す。この警告はユーザーインターフェース部２０１にメッセージとして出力されてもよい。警告を出したらＳ６１１２へ進む。Ｓ６１１２へ到達したら、リソースサービス３０４がグループ情報４３４を更新する処理は完了する。

以上より、管理者がリソースサービス開始のリクエストを行うと、アプリケーション管理フレームワーク３０２はリソースサービスを開始し、リソースサービス３０４が図６Ｂのフローチャートの処理を実行する。リソースサービス３０４はまずグループデータテーブル５００の更新を行い、Ｓ６１０５で有効になっているグループのリソース上限値５０７の合計とリソース定義バンドル元データ３０８のリソース上限値４１２に不整合がないか判定する。不整合な個所が確認されたらＳ６１０６へ進む。そして、リソース上限値４１２に不整合がないリソース定義バンドル元データ３０８をアプリケーション管理フレームワーク３０２がインストールして図６Ｂのフローチャートの処理が完了する。

＜アプリケーションがインストールされた場合の処理＞
図６Ｃはアプリケーション１１ｎのインストール完了通知を受信した後、Ｓ６００８でリソースサービス３０４が行うアプリケーションインストール時の処理の流れを模式的に表したフローチャートである。なおアプリケーションのインストール時には、そのアプリケーションリソース上限宣言ファイル４０２に記述されたリソース上限値４１２が当該アプリケーションのために確保される。このリソース上限値４１２は、グループに属するアプリケーションについては、すべてのリソースについて０とした上で（あるいは予め０と宣言された上で）インストールされ、グループに属さないアプリケーションについては、宣言された値でインストールされる。

処理はＳ６２０１から開始する。Ｓ６２０２で、リソースサービス３０４は、インストールされたアプリケーション１１ｎのアプリケーションリソース上限宣言ファイル４０２にグループＩＤ４１１が記載されているかを判定する。グループＩＤ４１２が記載されていればＳ６２０３へ進み、記載されていなければＳ６２１７へ進む。Ｓ６２１７で図６Ｃの処理は終了する。Ｓ６２０３で、リソースサービス３０４は、Ｓ６２０２で記載されていたと判定されたグループＩＤ４１２が、グループデータテーブル５００のグループＩＤ５０２に記憶されているかを判定する。記憶されていればＳ６２０４へ進み、記憶されていなければＳ６２１１へ進む。Ｓ６２０４で、リソースサービス３０４は、Ｓ６２０２で記載されていたと判定されたグループＩＤ５０２に対応する有効化状態５０６が無効に設定されているかを判定する。無効になっていればＳ６２０５へ進み、有効になっていればＳ６２１７へ進んで処理を終了する。

Ｓ６２０５で、リソースサービス３０４は、リソース定義バンドル元データ３０８に含まれたリソース上限値４１２に、Ｓ６２０２で記載されていたと判定されたグループＩＤ５０２に対応するリソース上限値５０７を加算し、記載し直す。すなわち、グループ単位のリソースの宣言値を、リソース定義バンドルのリソースの宣言値として付け替える。そのグループが既に有効であれば改めてグループのリソースが確保されることはないので、グループのリソース宣言値の付け替えは、同じグループが重複しないように行われるものということもできる。「重複しないように」とは、すなわち、グループに属する１つのアプリケーションが先にインストールされており、その後、同グループに属する別のアプリケーションがインストールされた場合でも、当該グループが有効であればリソース宣言値を加算しないことということができる。リソース上限値４１２に記載した後、Ｓ６２０６へ進む。

Ｓ６２０６で、リソースサービス３０４はリソース定義バンドル３０７がインストールされているかを判定する。インストールされていればＳ６２０７へ進み、インストールされていなければＳ６２０８へ進む。Ｓ６２０７で、リソースサービス３０４はリソース定義バンドル３０７をアンインストールするリクエストをアプリケーション管理フレームワーク３０２に行う。そして、アプリケーション管理フレームワーク３０２はインストールされているリソース定義バンドル３０７をアンインストールする。アンインストールが終わるとＳ６２０８へ進む。Ｓ６２０８で、リソースサービス３０４は、リソース定義バンドル元データ３０８をインストールする（すなわちリソース定義バンドルをインストールする）リクエストをアプリケーション管理フレームワーク３０２に行う。

アプリケーション管理フレームワーク３０２はリソース定義バンドル元データ３０８のリソース上限値４１２を参照して、その上限値が現在のアプリケーション実行環境内のリソースの空き容量の中に納まるかどうかを判定する。そして、納まらなければインストールを失敗させる。納まっていれば、アプリケーション管理フレームワーク３０２はリソース定義バンドル元データ３０８を使って、リソース定義バンドル３０７をインストールする。リソース上限値にグループのリソース上限値を加算したリソース定義バンドルをインストールすることで、グループのリソース上限値５０７もアプリケーション管理フレームワーク３０２の管理に反映することが可能である。

リソースサービス３０４がリソース定義バンドル３０７のインストールのリクエストを行った後、処理はＳ６２０９へ進む。Ｓ６２０９で、リソースサービス３０４はＳ６２０８でインストールをリクエストしたリソース定義バンドル３０７がインストールされているかを判定する。インストールされていればＳ６２１０へ進み、インストールがされていなければＳ６２１４へ進む。Ｓ６２１０で、リソースサービス３０４はＳ６２０２で記載されていたと判定したグループＩＤ４１１の有効化状態５０６を「有効」に設定する。「有効」に設定した後、Ｓ６２１７へ進む。

インストールされたアプリケーションがグループに属するものであるにも関わらずそのグループがグループデータテーブル５００に登録されていない場合には、Ｓ６２１１で、リソースサービス３０４は「グループ情報が記載されたフラグメントバンドルがインストトールされていない」旨の警告を出す。警告を出した後、Ｓ６２１２へ進む。Ｓ６２１２で、リソースサービス３０４は、Ｓ６００７で受信が判定されたインストール完了通知に対応したアプリケーション１１ｎがまだインストールされているかを判定する。インストールされていればＳ６２１３へ進み、インストールされていなければＳ６２１７へ進む。Ｓ６２１３で、リソースサービス３０４は、Ｓ６２１２でインストールされていると判定されたアプリケーション１１ｎをアンインストールするリクエストをアプリケーション管理フレームワーク３０２に行う。アプリケーション管理フレームワーク３０２はＳ６２１３で指示されたアプリケーション１１ｎをアンインストールする。リソースサービス３０４がアンインストールのリクエストを行うと、Ｓ６２１７へ進む。

リソース定義バンドルがインストールされなかった場合には、Ｓ６２１４で、リソースサービス３０４は「インストールしたアプリケーションが属するグループのリソース上限値が現在のアプリケーション実行環境内のリソースの空き容量の中に納まっていない」旨の警告を出す。警告を出した後、Ｓ６２１５へ進む。Ｓ６２１５で、リソースサービス３０４は、リソース定義バンドル元データ３０８のリソース上限値から、Ｓ６２０５で加算したリソース上限値５０７を減算し、記載し直す。記載が終わるとＳ６２１６へ進む。Ｓ６２１６で、リソースサービス３０４はリソース定義バンドル元データ３０８をインストールするリクエストをアプリケーション管理フレームワーク３０２に行う。アプリケーション管理フレームワーク３０２は、リソース定義バンドル元データ３０８を使って、リソース定義バンドル３０７をインストールする。リソース定義バンドル元データ３０８をグループのリソース上限値の加算前の値に戻してインストールし直すことで、確保されたリソースも上限値の加算前の値となり変更されない。リソースサービス３０４がリクエストを行った後、Ｓ６２１２へ進む。

Ｓ６２１２以降では、Ｓ６００７で受信が判定されたインストール完了通知に対応したアプリケーション１１ｎがまだインストールされているならば、それをアンインストールする。以上でＳ６００８でリソースサービス３０４が行うアプリケーションインストール時の処理は完了する。

＜図６Ｃまとめ＞
この図６Ｃの処理の結果、インストール通知を受信したリソースサービス３０４は、インストールされたアプリケーションがグループに属するアプリケーションであり、当該グループのリソースを新たに確保する必要がある場合には、そのグループに対して定義されたリソースの上限値は、リソース定義バンドル３０７のリソースとして確保される。当該グループのフラグメントバンドルがインストールされていない場合、または、リソース定義バンドル３０７のリソース上限値（すなわちインストール済みのフラグメントバンドルに対応するグループのリソース上限値の合計値）の確保ができずにリソース定義バンドル３０７のインストールに失敗した場合には、当該アプリケーションはアンインストールされる。

＜アプリケーションがアンインストールされた場合の処理＞
図６Ｄはアプリケーション１１ｎのアンインストール完了通知を受信した後、Ｓ６０１０でリソースサービス３０４が行うアプリケーションアンインストール時の処理の流れを模式的に表したフローチャートである。処理はＳ６３０１から開始する。

Ｓ６３０２で、リソースサービス３０４はアンインストールされたアプリケーション１１ｎのアプリケーションＩＤ４１０がグループデータテーブル５００の管理対象アプリケーションＩＤ５０５に記憶されているか判定する。テーブルに記憶されていればＳ６３０３へ進み、記憶されていなければＳ６３１０へ進む。Ｓ６３０３で、リソースサービス３０４はアンインストールされたアプリケーション１１ｎと同じグループに属するアプリケーション１１ｎがインストールされているか否かを判定する。インストールされていなければＳ６３０４へ進み、１つでもインストールされていればＳ６３１０へ進む。

Ｓ６３０４で、リソースサービス３０４は、アンインストールされたアプリケーションの管理対象アプリケーションＩＤ５０５の属するグループＩＤ５０２に対応するリソース上限値５０７を、リソース定義バンドル元データ３０８に含まれたリソース上限値４１２から減算し、リソース定義バンドル元データ３０８を記載し直す。その後、Ｓ６３０５へ進む。

Ｓ６３０５で、リソースサービス３０４はリソース定義バンドル３０７をアンインストールするリクエストをアプリケーション管理フレームワーク３０２に行う。そして、アプリケーション管理フレームワーク３０２はインストールされているリソース定義バンドル３０７をアンインストールする。アンインストールが終わるとＳ６３０６へ進む。

Ｓ６３０６で、リソースサービス３０４は、リソース定義バンドル元データ３０８をインストールする（すなわちリソース定義バンドルをインストールする）リクエストをアプリケーション管理フレームワーク３０２に行う。アプリケーション管理フレームワーク３０２はリソース定義バンドル元データ３０８を使って、リソース定義バンドル３０７をインストールする。リソース上限値にグループのリソース上限値を減算したリソース定義バンドルをインストールすることで、所属するアプリケーションがインストールされていないグループのリソースを解放することが可能である。リソースサービス３０４がリソース定義バンドル３０７のインストールのリクエストを行った後、処理はＳ６３０７へ進む。

Ｓ６３０７で、リソースサービス３０４はアンインストールされたアプリケーション１１ｎが属するグループの有効化状態５０６を無効に設定する。設定した後、Ｓ６３０８へ進む。Ｓ６３０８で、リソースサービス３０４はグループデータテーブル５００の全グループの有効化状態が無効になっているかを判定する。全て無効になっていればＳ６３０９へ進み、全て無効になっていなければＳ６３１０へ進む。Ｓ６３０９で、リソースサービス３０４はリソース定義バンドル３０７をアンインストールするリクエストをアプリケーション管理フレームワーク３０２に行う。そして、アプリケーション管理フレームワーク３０２はリソース定義バンドル３０７をアンインストールする。リソースサービス３０４がリクエストを行うと、Ｓ６３１０へ進む。Ｓ６３１０で図６Ｄの処理は終了となる。

＜図６Ｄまとめ＞
以上より、管理者がアプリケーション１１ｎのアンインストールをリクエストすると、アプリケーション管理フレームワーク３０２はアプリケーション１１ｎをアンインストールし、リソースサービス３０４にアンインストール完了通知を送信する。リソースサービス３０４はアンインストール完了通知を受信すると、アンインストールされたアプリケーション１１ｎがグループとして管理されており、かつ、そのグループに属する他のアプリケーションがインストールされていなければ、リソース定義バンドル元データ３０８のリソース上限値４１２から、アンインストールしたアプリケーション１１ｎが属するグループのリソース上限値５０７を減算してリソース定義バンドル３０７をインストールし直す。そして、そのグループの有効化状態５０６を無効に設定する。他のグループも全て有効化状態５０６が無効になっていれば、リソースのグループ管理の必要がなくなるため、リソース定義バンドルをアンインストールする。

以上、本発明の第一の実施形態では、グループに属するアプリケーション１１ｎがインストールされたとき、そのグループのリソース上限値をリソース定義バンドル３０７のリソース上限値４１２に加算してリソース定義バンドル３０７をインストールし直すことにより、当該グループのリソース上限値の宣言が可能であり、上限値に相当するリソースを確保できる。グループに属するアプリケーション１１ｎがアンインスールリクエストされたときも同様に、そのグループのリソース上限値はリソース定義バンドル３０７のリソース上限値４１２から減算してインストールし直すことにより宣言が可能であり、管理対象から外れたグループのリソース上限値に相当するリソースを解放できる。これにより、管理者がインストールするグループに属するアプリに対応して柔軟にリソース上限値を変更することができる。

たとえばグループに属するアプリケーション３０６ｎはリソースサービス３０４に対してリソース要求をする。それに対してリソースサービス３０４は、リソース定義バンドル３０７のインストール時に確保したリソースの中から、当該アプリケーション３０６ｎに対してリソースオブジェクトを返し、リソースを割り当てる。

本実施形態によれば、管理対象グループのためのリソースは、リソース定義バンドルのインストールにより確保される。リソース定義バンドルを、その目的専用のバンドルとすれば、グループのリソースを、リソースサービスを含めた他のアプリケーションの消費するリソースとは独立に管理することができる。

またリソースサービスが停止しても、インストール済みのグループ管理対象のアプリケーションは、リソース定義バンドルが稼働している間は、グループ単位でのリソース管理の対象であり続ける。

なお本実施形態ではフラグメントバンドルリソース上限宣言ファイル４２２にグループ情報４３４を記載し、フラグメントバンドルをインストールすることによりその情報を読み込んでいた。しかし、グループ情報４３４が記載されたファイルをＰＣのブラウザなどで設定し、送信することでグループ情報４３４の読み込みを行っても良い。

［第二の実施形態］
次に本発明の第二の実施形態について図を用いて解説を加える。第一の実施形態では、使用しないリソース上限値を反映させないために、フラグメントバンドル３０６ｎのインストール時ではなく、アプリケーション１１ｎのインストール時に、リソース上限値４１２の変更を行う必要があった。そのため、リソース定義バンドル元データ３０８のインストールに失敗した際には、インストールしたアプリケーション１１ｎをアンインストールする必要があった。しかしながら、リソースサービス３０４のユーザーインターフェース以下、リソースサービスＵＩから、グループ情報の設定とグループに属するアプリケーションのインストールを一連の流れで行うことで、そのようなアンインストールを不要とすることができる。本実施形態では、グループ情報の設定とグループに属するアプリケーションのインストールを行うリソース管理装置を示す。

本発明の第二の実施形態の装置の構成を示す図は図１に掲げるものと同様である。また本実施形態における画像形成装置１００のハードウェア構成は図２に示したものと同様である。本実施形態におけるアプリケーション１１ｎを実行するためのアプリケーション実行環境の構成は図３に示したものと同様である。本実施形態におけるアプリケーション１１ｎを構成するファイルの内容、およびフラグメントバンドル３０６ｎを構成するファイルの内容は図４Ａ、図4Ｂに示したものと同様である。

図７は情報処理装置１０１に表示されるリソースサービスＵＩの画面の一例を示したものである。ユーザはこのユーザーインターフェースを走査してアプリケーションをインストールすることができる。図７において、グループ情報ファイル７０１は設定するグループ情報が記載されたファイル名である。グループ情報ファイルにはグループＩＤ４３１、リソース上限値４３２、所属アプリケーションＩＤ４３３が記載されている。項目７０２はグループ情報ファイル７０１を指定するグループ情報ファイル指定項目である。アプリケーション元データ７０３１、７０３２は、グループ情報ファイルに記載されたグループに属するアプリケーションをインストールするためのアプリケーション元データ名である。項目７０４１、７０４２は、グループ情報ファイルに記載された所属アプリケーションＩＤ４３３のアプリケーション元データ７０３ｎを指定するためのアプリケーション元データ指定項目である。アプリケーション元データはたとえばそのアプリケーションのアプリケーションリソース上限宣言ファイルの内容を含む。項目追加ボタン７０５は、アプリケーション１１ｎを３つ以上インストールする際に、アプリケーション元データ指定項目７０４ｎを追加するためのボタンである。インストール実行ボタン７０６は、指定したグループ情報ファイル７０１の記載に基づきアプリケーション１１ｎをインストールするためのボタンである。

管理者が各指定項目７０２、７０４ｎを入力して、インストール実行ボタンを押すと、リソースサービス３０４はまず、グループ情報ファイルの記載を参照する。必要なグループ情報４３４が記載されていることを確認したら、グループ情報ファイルに記載されたリソース上限値４３２をリソース定義バンドル元データ３０８のリソース上限値４１２に加算する。そして、リソース定義バンドル３０７をインストールするリクエストをアプリケーション管理フレームワーク３０２に行う。リソース定義バンドル３０７がインストールされた場合は、アプリケーション元データ指定項目７０４ｎで指定されたアプリケーション１１ｎをインストールするリクエストをアプリケーション管理フレームワーク３０２に行う。リソース定義バンドルのインストールに失敗した場合、アプリケーション元データ指定項目７０４ｎで指定されたアプリケーション１１ｎのインストールを失敗させる。失敗させるとはたとえば、指定されたアプリケーションをインストールせず、失敗したことをユーザーインターフェースなどを介してユーザに通知することなどである。

＜アプリケーションのインストール処理＞
図８は管理者がインストール実行ボタンを押した後、リソースサービス３０４が行う処理の流れを模式的に表したフローチャートである。処理はＳ８００１から開始する。Ｓ８００２で、リソースサービス３０４はグループ情報ファイル指定項目７０２に指定されたグループ情報ファイルを参照し、Ｓ８００３へ進む。Ｓ８００３で、リソースサービス３０４はグループ情報ファイル７０１にグループ情報４３４が全て記載されているか判定する。記載されていればＳ６２０５へ進み、記載されていなければＳ８００９へ進む。Ｓ８００９で、リソースサービス３０４は「グループ情報フェイルが正しく記載されていない」旨の警告を出す。警告を出した後、Ｓ８０１２へ進む。Ｓ６２０５〜Ｓ６２０９と、Ｓ６２１４〜Ｓ６２１６は図６Ｃに該当する処理と同じ処理なため説明は省略する。Ｓ６２０９で、リソース定義バンドルがインストールされていればＳ８００４へ進み、インストールされていなければＳ６２１４へ進む。

Ｓ８００４で、リソースサービス３０４はＳ８００２で読み込んだグループ情報ファイルに含まれたグループ情報４３４をグループデータテーブル５００に記憶し、このグループの有効化状態を有効に設定する。設定をするとＳ８００５へ進む。Ｓ８００５でリソースサービス３０４はアプリケーション元データ指定項目７０４ｎにまだインストール処理を行っていないアプリケーション１１ｎが指定されているか判定する。指定されていればＳ８００６へ進んでインストール処理を行い、指定されていなければＳ８０１２へ進む。Ｓ８００６で、リソースサービス３０４は指定されているアプリケーション元データ７０３ｎがグループ情報ファイル７０１に記載されているアプリケーションかを判定する。記載されていればＳ８００７へ進み、記載されていなければＳ８０１０へ進む。Ｓ８００７で、リソースサービス３０４は指定されたアプリケーション元データ７０３ｎをインストールするリクエストをアプリケーション管理フレームワーク３０２に行う。このとき、アプリケーション元データ７０３ｎに記述されたリソース上限値４１２は、グループに属するアプリケーションについては、すべてのリソースの上限値が０である。
アプリケーション管理フレームワーク３０２はアプリケーション元データ７０３ｎを使って、アプリケーション１１ｎをインストールする。リソースサービス３０４がリクエストを行うとＳ８００８へ進む。Ｓ８００８で、リソースサービス３０４はＳ８００７でインストールリクエストしたアプリケーション１１ｎがインストールされているかを判定する。インストールされていればＳ８００５へ進み、インストールされていなければＳ８０１０へ進む。

Ｓ８０１０で、リソースサービス３０４は「アプリケーション元データ指定項目で指定されたアプリケーションのインストールに失敗した」警告を出す。警告を出した後、Ｓ８００５へ進む。

Ｓ６２１６でリソース定義バンドルをインストールするリクエストを行うと、Ｓ８０１１へ進む。Ｓ８０１１で、リソースサービス３０４はアプリケーション元データ指定項目７０４ｎで指定されたアプリケーション元データ７０３ｎのインストールを中止し、Ｓ８０１２へ進む。Ｓ８０１２に到達すると、図８のフローチャートの処理が完了する。なおＳ８０１１の段階では、アプリケーションのインストールのリクエストはまだおこなわれていない。そのため、Ｓ８０１１では何もしないか、あるいはＳ８０１０と同様に指定されたアプリケーションがインストールできなかった旨の警告をユーザーインターフェースなどから出力する。

以上より、管理者がインストール実行ボタンを押した後、リソースサービス３０４はまず入力されたグループ情報ファイル７０１を読み込む。ファイルの記載内容に不備や不足があった場合は警告を出し、なかった場合はリソース定義バンドル元データ３０８のリソース上限値４１２を変更し、インストールする。そしてリソース定義バンドル３０７がインストールできなければ、アプリケーション元データ７０３ｎのインストールを中止する。リソース定義バンドル３０７がインストールできれば、アプリケーション元データ指定項目７０４ｎに指定されたアプリケーション元データ７０３ｎをインストールする。指定されたアプリケーション元データ７０３ｎが全てインストールできれば、インストール実行ボタンを押した後のリソースサービス３０４が行う処理は完了する。

以上、本発明の第一の実施例では、アプリケーション１１ｎをインストールする前にリソース上限値４１２を変更したリソース定義バンドル元データ３０８をインストールすることが可能である。これにより、リソース定義バンドルのインストールに失敗した場合は、アプリケーションのインストールを中止することができる。

なお、本実施形態ではリソースサービスはリソースサービスＵＩを情報処装置１０１に表示していたが、ユーザーインターフェース部２０１に表示しても良い。また、グループ情報ファイルはグループごとに予め所定の記憶領域に用意しておき、ユーザがインストールするアプリケーション元データを選択すると、リソースサービス３０４が、そこに記述されたグループＩＤを基にして、用意されたグループ情報ファイルから該当するグループ情報ファイルを選択するよう構成してもよい。さらに、ユーザが選択するのはインストールしようとするアプリケーションの名称やＩＤであり、その名称やＩＤに該当するアプリケーション元データを検索し、さらにその元データに含まれたグループＩＤに相当するグループ情報ファイルを検索するように構成してもよい。もちろんインストール時には検索されたファイルを使用する。また該当するグループ情報ファイルが見つからない場合には、それはグループに属していないので、そのインストールにはリソースサービス３０４は関知せずアプリケーション管理フレームワーク３０２により行われればよい。

また、図８の手順でアプリケーションのインストールを実行した場合でも、リソースサービス３０４は図６Ａの処理を実行できる。図８でアプリケーションがインストールされていれば、図６ＣのＳ６２０４で「ＮＯ」と判定されるため、リソース定義バンドル３０７がひとつのアプリケーションのために重ねてインストールされることはない。

また、図７のユーザーインターフェースは、第１の実施形態に適用することもできる。第１の実施形態では、図７のようにグループとアプリケーションとを１画面で指示させてもよいし、何れかのみを指示させてそのインストール指示を受け付けてもよい。

［その他の実施例］
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路例えば、ＡＳＩＣによっても実現可能である。

１００ 画像形成装置、１０１ 情報処理装置、１３０ ネットワーク、３０２ アプリケーション管理フレームワーク、３０４ リソースサービス、３０５ グループ設定バンドル、３０６ フラグメントバンドル、３０７ リソース定義バンドル、３０８ リソース定義バンドル元データ、４０２ アプリケーションリソース上限宣言ファイル、４１２ リソース上限値

Claims (13)

1. グループ単位でアプリケーションのリソースを管理するためのリソース管理装置であって、
   アプリケーションのインストールにより前記アプリケーションの宣言値に応じたリソースを前記アプリケーションのために確保するシステムに対して、グループに属するアプリケーションがインストールされた際には、リソース定義アプリケーションのリソースの宣言値に対し、インストールされた前記アプリケーションが属する前記グループのリソースの宣言値を加算する付け替え手段と、
   前記付け替え手段による加算処理後、前記リソース定義アプリケーションを前記システムにインストールするインストール手段と、
   を有するリソース管理装置。
2. 前記グループに属するアプリケーションが宣言するリソースの宣言値は０であることを特徴とする請求項１に記載のリソース管理装置。
3. 前記システムに対してグループに属する全てのアプリケーションがアンインストールされた際には、前記付け替え手段は、前記グループのリソースの宣言値を、前記リソース定義アプリケーションのリソースの宣言値から差し引き、
   前記インストール手段は、前記リソース定義アプリケーションを再度インストールすることを特徴とする請求項１又は２に記載のリソース管理装置。
4. グループと、該グループに属するアプリケーションと、前記グループのリソースの宣言値とを対応付けたグループ情報を保持するテーブルを更に有し、
   アプリケーションがインストールされると、前記付け替え手段は、前記アプリケーションに対応したグループのリソースの宣言値を前記テーブルから取得して前記リソース定義アプリケーションのリソースの宣言値に付け替え、前記インストール手段は前記リソース定義アプリケーションをインストールすることを特徴とする請求項１乃至３のいずれか一項に記載のリソース管理装置。
5. 新たなアプリケーションのグループと、該グループに属するアプリケーションと、前記グループのリソースの宣言値とを含むグループ情報を前記テーブルに追加する追加手段を更に有することを特徴とする請求項４に記載のリソース管理装置。
6. 前記追加手段は、前記グループ情報を保持するフラグメントアプリケーションが前記システムへインストールされると、前記フラグメントアプリケーションから前記グループ情報を取得して前記テーブルに追加することを特徴とする請求項５に記載のリソース管理装置。
7. 前記インストール手段は、前記リソース定義アプリケーションが既にインストール済みの場合には、前記リソース定義アプリケーションをアンインストールした後に改めてインストールすることを特徴とする請求項１乃至６のいずれか一項に記載のリソース管理装置。
8. 前記付け替え手段は、前記グループに属するアプリケーションが前記システムにインストールされた後で、前記グループのリソースの宣言値をリソース定義アプリケーションのリソースの宣言値に重複しないように付け替えて前記インストール手段により前記リソース定義アプリケーションのインストールを行い、
   前記リソース定義アプリケーションのインストールに失敗した場合には失敗した旨を出力し、前記アプリケーションをアンインストールすることを特徴とする請求項１乃至７のいずれか一項に記載のリソース管理装置。
9. 前記付け替え手段は、前記グループに属するアプリケーションのインストールが指示されると、前記アプリケーションのインストールの前に、前記アプリケーションの属するグループのリソースの宣言値をリソース定義アプリケーションのリソースの宣言値に重複しないように付け替え、前記インストール手段は前記リソース定義アプリケーションのインストールを行い、
   前記リソース定義アプリケーションのインストールに失敗した場合には、前記アプリケーションのインストールを中止することを特徴とする請求項１乃至７のいずれか一項に記載のリソース管理装置。
10. ユーザーインターフェースを提供するユーザーインターフェース手段を更に有し、
    前記ユーザーインターフェース手段により、前記グループと、該グループに属するアプリケーションとの少なくともいずれかのインストールが指示されることを特徴とする請求項１乃至９のいずれか一項に記載のリソース管理装置。
11. 前記グループに属するアプリケーションからのリソースの要求に応じて、前記リソース定義アプリケーションのために確保されたリソースの中から、前記アプリケーションにリソースを割り当てる手段をさらに有することを特徴とする請求項１乃至１０のいずれか一項に記載のリソース管理装置。
12. 請求項１乃至１１のいずれか一項に記載のリソース管理装置としてコンピュータを機能させるためのプログラム。
13. グループ単位でアプリケーションのリソースを管理するためのリソース管理方法であって、
    アプリケーションのインストールにより前記アプリケーションの宣言値に応じたリソースを前記アプリケーションのために確保するシステムに対して、グループに属するアプリケーションがインストールされた際には、リソース定義アプリケーションのリソースの宣言値に対し、インストールされた前記アプリケーションが属する前記グループのリソースの宣言値を加算する付け替え工程と、
    前記付け替え工程による加算処理後、前記リソース定義アプリケーションを前記システムにインストールするインストール工程と
    を有するリソース管理方法。

Images