JP2016051395A - 画像形成装置およびリソース管理方法 - Google Patents

Abstract

【課題】組込アプリケーションを複数インストールし実行するための実行環境におけるアプリケーションが使用するリソースの使用量を動的に管理する画像形成装置、およびリソース管理方法を提供する。
【解決手段】リソースサービス３０４はアプリケーション１１０〜１１２が必要とするリソースについて、その効率的管理を実現する。フラグメントバンドル３０５はリソースサービス３０４に対して補完用モジュールとして動作する。リソースサービスに対してフラグメントバンドルで導入されるグループに対してリソース量の上限値を設け、グループ導入時には、当該グループに属するアプリケーションの使用するリソースの量をグループ単位での管理に移管する。
【選択図】図３

Description

本発明は、組込アプリケーションを複数インストールし実行するための実行環境における、それらアプリケーションが使用するリソースの使用量を動的に管理する画像形成装置、およびリソース管理方法に関わる。

従来、組込アプリケーション実行環境においては、アプリケーションが使用する一般的な計算機資源であるところのリソースの総量に制限があることが一般的である。このために以下のようなことが一般的に行われている。すなわちアプリケーションが使用するリソースの量について上限値を定める。またそれとともに、検査段階において当該アプリケーションの使用量がその上限値を超えないことを確認することによって、アプリケーションが安定稼働することを保証する。

またそのようなアプリケーションを複数稼働させることを想定した組込アプリケーション実行環境では、アプリケーション管理フレームワークが当該実行環境にインストールされたアプリケーションの使用するリソースの使用量を監視している。すなわちアプリケーションを実行環境にインストールする際に、その上限値がインストールされたアプリケーションの全体で実行環境が提供するリソースの総量を超えないよう制御する。この際、その制限内におさまらないアプリケーションについてはインストールを許可しない、という方法である。このようなリソース管理装置、およびリソース管理方法が一般的に提供される。

一方で、リソースの使用について複数のアプリケーションが競合する状態を検出してそれらを制御することにより複数のアプリケーション間でのリソースの使用量を抑制する技術も提供されている。例えば特許文献１に掲げる技術によれば、リソース管理装置は予め複数のアプリケーションについて当該リソースを使用する際の優先順位を与えるデータベースを備える。ここでは一つのアプリケーションが当該リソースを使用する際により優先順位の高い別のアプリケーションが使用中であればエラーにするという仕組を設けることによりリソースの使用を制御している。

また特許文献２においては、リソース管理装置は予め複数のアプリケーションについて当該リソースを使用する際の優先順位を与えるのに加え、排他制御の必要性を示す管理テーブルを備える。ここで優先度の低いアプリケーションが、排他制御が必要なリソースを使用する場合には優先度の高いアプリケーションのリソースの使用が完了するまでアプリケーションを停止することで競合を制御している。

また特許文献３に掲げる技術ではアプリケーションが特定の別のアプリケーションとリソースの使用について競合する場合に、当該別のアプリケーションの中に以下のような仕組を設けている。すなわち、当該別のアプリケーションが現在どのくらい当該リソースを使用しているかを管理者が知ることができるような画面が設けられている。そして、当該アプリケーションが、別のアプリケーションによるリソースの消費量を知ることができるようなインターフェースを設けられている。これらにより、当該アプリケーションが当該別のアプリケーションのリソースの使用量を確認してから自身のリソースの使用を開始することで競合を回避している。

特開２００４−３６２４２５号公報 特開平８−３２８８８４号公報 特開２０１０−３９６８９号公報

しかしながら、これらの技術では、以下のような課題があった。すなわち、複数のアプリケーションについてそれぞれに与えられる上限値同士を加算するとシステム全体の提供可能なリソースの使用量を超えてしまう場合には、それら複数のアプリケーションを同時にインストールすることができない。しかしながら実際には、動作中にそれらのアプリケーションのリソースの使用量が同時に上限に達することはほとんどない。この結果として、実際には必要なリソースの使用量を提供可能であるにも関わらずそれらのアプリケーションを同時にシステム内に配置することはできないという課題がある。

また、特許文献１および特許文献２により示される技術では、優先順位を設けることによりリソースの競合時には優先順位の低いアプリケーションがリソースを使用できないようにしている。これにより使用量が上限に到達することを阻止することでそれらのアプリケーションを同時に配置することは可能となる。しかしながら、優先順位の低いアプリケーションは結局のところリソースが利用可能になるまでその処理を停止されてしまうため、リソースを共有し、そのリソースに対する優先順位が異なる複数のアプリケーションを同時に利用することが困難となるという課題がある。

また、特許文献３により示される技術にも課題がある。アプリケーションは自身がリソースを使用する前に他のアプリケーションの使用量を確認し、自身の動作を制御するため、例えば別の処理を先に行うなどの対応により処理が進まなくなることはないという利点は備えている。しかしながら、この目的のためにはアプリケーションはあらかじめそのようなインターフェースを実装している必要があり、それを実装していないアプリケーションには適用できない。またアプリケーションはリソースが不足した場合にはどのアプリケーションに問い合わせるかをあらかじめ定めておく必要があるため、想定外の組合せに対してはそのような解決手段を行使することができないという課題がある。

以上のように、アプリケーションによるリソース消費量が実行環境により提供可能なリソース量を超えないように管理するリソース管理を、アプリケーションのインストール時に静的に行っても、またインストールされたアプリケーションの実行時に動的に行っても、適切なリソース管理を行うことが困難であるという問題があった。

本発明は上記従来例に鑑みて成されたもので、アプリケーション間のリソースの競合を適切に調整し、リソースの効率的な利用を可能とする画像形成装置及びリソース管理方法を提供することを目的とする。

上記の課題を解決するために本発明では以下のような構成を有する。すなわち、アプリケーション群に属するアプリケーションの識別子と、前記アプリケーション群に対する使用リソース宣言量とが定義された情報を取得する取得手段と、
アプリケーションからリソース取得ＡＰＩが呼び出されたことに応じて、前記アプリケーションの識別子を基に前記アプリケーションが属するアプリケーション群を特定し、特定されたアプリケーション群に対する使用リソース宣言量を、前記情報から特定する特定手段と、
前記アプリケーションが要求するリソース量を現在前記アプリケーション群が使用しているリソース量の総計に加算した結果、その値が前記特定手段により特定された使用リソース宣言量を超えてしまう場合は、前記アプリケーションにリソースオブジェクトを渡さず、そうでない場合には前記アプリケーションに前記リソースオブジェクトを渡すリソース管理手段とを有する。

本発明を用いれば、リソースサービスがそれぞれのアプリケーションについて単独管理状態とグループ管理状態の双方で適切にリソースの上限値管理が可能となり、管理者がアプリケーションを適切に管理運用するための手間が大幅に軽減されるという効果を持つ。

本発明の第一、第二の実施例の装置の全体の構成を示す図である。 本発明の第一、第二の実施例の画像形成装置１００のハードウェア構成を示す図である。 本発明の第一、第二の実施例のアプリケーション実行環境の構成を示す図である。 本発明の第一、第二の実施例のアプリケーションおよびフラグメントバンドルを構成するファイルの内容を示す図である。 本発明の第一の実施例のアプリケーション管理フレームワークの画面の一例を示す図である。 本発明の第一、第二の実施例のグループデータテーブル、第一の実施例のアプリケーションデータテーブルの内容を示す図である。 本発明の第一の実施例のリソースサービスによる起動時の処理のフローチャートである。 本発明の第一の実施例のリソースサービスによる起動時の処理のフローチャートである。 本発明の第一の実施例のリソースサービスによる起動時の処理のフローチャートである。 本発明の第一の実施例のリソースサービスによる起動時の処理のフローチャートである。 本発明の第一の実施例のリソース操作の概念図である。 本発明の第一の実施例のアプリケーションのインストール処理のフローチャートである。 本発明の第一の実施例のアプリケーションのアンインストール処理のフローチャートである。 本発明の第二の実施例のアプリケーション管理フレームワークの画面の一例を示す図である。 本発明の第二の実施例のフラグメントバンドルの起動時処理のフローチャートである。 本発明の第二の実施例のフラグメントバンドルの起動時処理のフローチャートである。 本発明の第二の実施例のアプリケーションのインストール処理のフローチャートである。 本発明の第二の実施例のアプリケーションのアンインストール処理のフローチャートである。

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

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

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

＜画像形成装置のアプリケーション及びその実行環境＞
図３は本実施例における画像形成装置１００の上でアプリケーション１１ｎを実行するためのアプリケーション実行環境である。アプリケーション実行基盤３０１は、アプリケーションを実行するためにプログラムであり、例えばＪａｖａ（登録商標）仮想マシン（ＪａｖａＶＭ）等である。アプリケーション管理フレームワーク３０２はアプリケーション１１ｎのインストールおよびアンインストール、実行と停止を管理するフレームワークであり、たとえばＪａｖａ（登録商標）ベースのＯＳＧｉ（ＯＰＥＮ Ｓｅｒｖｉｃｅｓ Ｇａｔｅｗａｙ ｉｎｉｔｉａｔｉｖｅ）フレームワークなどである。サポートライブラリ３０３はアプリケーション１１ｎが画像形成装置１００のさまざまな機能を利用するためのサポートライブラリである。リソースサービス３０４は本実施例においてアプリケーション１１ｎが必要とするリソースについて、その効率的管理を実現するために利用するためのプログラムである。リソースサービス３０４はアプリケーションのひとつであるが、アプリケーション１１ｎには含まれない。フラグメントバンドル３０５はリソースサービス３０４に対して補完用モジュールとして動作するプログラムである。なお、本実施形態におけるアプリケーションとは、アプリケーション管理フレームワーク３０２がＯＳＧｉフレームワークである場合にはバンドルに相当する。バンドルとは、ＯＳＧｉフレームワークの上で、Ｊａｖａ（登録商標）の実行基盤であるＪａｖａＶＭとは独立してインストールやアンインストール、起動或いは停止可能なプログラム部品（いわゆるプラグイン）である。フラグメントバンドルとは、ＯＳＧｉフレームワークにおいては、その内容を他のバンドル（ホストバンドルと呼ぶ）により共有できるようなバンドルであり、アプリケーションと同様に、マニフェストヘッダーを持つＪａｖａ（登録商標）アーカイブファイルとして提供される。これについては図４等を参照して詳述する。なお本例でいうフラグメントバンドルは、上記のような一般的な物を指しているのではなく、後述する実施例で説明するような、リソースサービスの一部となり、リソースのグループ管理のために機能するフラグメントバンドルのことを指す。このようなフラグメントバンドルを他のアプリケーションのフラグメントバンドルと区別するために、特にリソースサービスフラグメントバンドルとも呼ぶ。フラグメントバンドルはアプリケーションの環境がＯＳＧｉフレームワークではない場合であっても、ＯＳＧｉフレームワークのフラグメントバンドルに相当するソフトウェア部品を含む。

リソースサービス３０４は基本的な動作として、アプリケーション１１ｎからのリソースのリクエストを受け付ける。アプリケーション１１ｎはリソースを取得する際、および使い終わって解放する際にリソースサービス３０４に対してリソース取得リクエスト、リソース解放リクエストを送る。リソースサービス３０４はリクエストを送ってきたアプリケーション１１ｎがリソースを使用する権利を持った状態で動作しているかを確認して持っていない状態であればエラーを返すという動作をする。また権利がある場合には、リソースサービス３０４は当該アプリケーション１１ｎに設定されているリソースの使用量の上限値を参照する。そのうえでリソース上限に達していなければリソースを確保してアプリケーション１１ｎへ返す。上限を超えてしまう場合にはエラーを返す。リソースサービス３０４はリソースを確保した場合には現在そのアプリケーション１１ｎがいくらリソースを使用しているかを数値で把握するべく、新たに確保したリソースの量を加算する、という動作を行う。また解放時には解放したリソースの量を減算する、という動作を行う。リソースの解放に失敗することはほとんどないが、解放に失敗した場合にはエラーを返すとともに管理者に対して警告を出力する。なお、このような警告は、他にも出力されることがある。この種の警告は具体的には、例えばリソースサービス３０４の管理者向けインターフェース上へ表示する、あるいは、システムログへ追記する、などの手段を用いて管理者に伝達されるように出力される。

図４（ａ）は本実施例におけるアプリケーション１１ｎを構成する代表的なファイルの内容について解説した図である。アプリケーション１１ｎは内容としていくつかの種類のファイルを抱えている。アプリケーション実行コードファイル４００はアプリケーションの実行コード等を含む。アプリケーション固定データファイル４０１はアプリケーションが持っている固定データを収めたファイルである。アプリケーションリソース上限宣言ファイル４０２はアプリケーションの使用するリソースの上限値、すなわち使用リソース宣言量を宣言するためのファイルである。さらにアプリケーションリソース上限宣言ファイル４０２はその内容として以下の記述を含んでいる。アプリケーションＩＤ４１０はアプリケーション１１ｎのアプリケーションＩＤすなわち識別子の値の記載である。グループＩＤ４１１はアプリケーション１１ｎが属するグループを指定するグループＩＤの記載である。リソース上限値４１２はアプリケーション１１ｎが使用するリソースの上限値の宣言であるところの、リソース上限値である。アプリケーションリソース上限宣言ファイル４０２は、ＯＳＧｉフレームワークの下ではマニフェストに相当する。

アプリケーション実行環境内へアプリケーション１１ｎをインストールして実行するには、アプリケーション管理フレームワーク３０２を利用する。基本動作として、アプリケーション管理フレームワーク３０２は、管理者がアプリケーション１１ｎをインストールするリクエストを行うと、インストール動作を行う。その際にアプリケーション管理フレームワーク３０２はそのアプリケーションリソース上限宣言ファイル４０２を参照して、そこに宣言されているリソース上限値が現在のアプリケーション実行環境内のリソースの空き容量の中に納まるかどうかを判定する。そして、もしも納まらなければインストールを失敗させる。

リソースサービス３０４も基本的にはアプリケーションの一つであり図４（ａ）に掲げたアプリケーション１１ｎと同様の構成になっている。リソースサービスをアプリケーション１１ｎと区別する特徴は、他の不特定のアプリケーション１１ｎに対してサービスを提供する共通のアプリケーションプログラミングインターフェース（以下「ＡＰＩ」と略す）を提供するところである。このＡＰＩをリソース取得ＡＰＩと呼ぶ。リソース取得ＡＰＩを介して他のアプリケーションはリソースサービスによるサービスを受けることができる。ただし、リソースサービスのＡＰＩの呼び出しはアプリケーションにコーディングされて初めて当該アプリケーションにより利用されるので、アプリケーションによりリソースサービスを利用するものとしないものとがあり得るが、本例ではすべてのアプリケーションがリソースサービスを利用してリソースを取得することを前提とする。

図４（ｂ）はフラグメントバンドル３０５を構成する代表的なファイルの内容について解説した図である。フラグメントバンドル３０５も、基本的には図４（ａ）に掲げたアプリケーション１１ｎと同様の構成になっている。フラグメントバンドル実行コードファイル４２０はフラグメントバンドルの実行コードを含むファイルである。フラグメントバンドル固定データファイル４２１はフラグメントバンドルが持っている固定データを収めたファイルである。フラグメントバンドルリソース上限宣言ファイル４２２はフラグメントバンドルの使用するリソースの上限値を宣言するためのファイルである。フラグメントバンドルＩＤ４３０はフラグメントバンドルのＩＤを示している。またグループＩＤ４３１はこのフラグメントバンド３０５が宣言するグループのグループＩＤを示している。リソース上限値４３２は、フラグメントバンドル３０５をリソースサービス３０４に対して追加した時に、増加するリソース使用量をリソースごとに宣言するリソース上限値を示している。この値は、単にフラグメントバンドル３０５により消費されるリソースの上限を示しているのではなく、フラグメントバンドル３０５により定義されたグループ単位で管理されたアプリケーションが消費するリソース上限値（すなわちグループのリソース上限値）を示している。ただしグループに属するアプリケーションがインストールされた際に本体ファイルが占めるストレージサイズはこの上限値には含まれない。換言すれば、グループ管理されたアプリケーション各々は、リソース上限値４３２で宣言された値を上限として各リソースを使用でき、ストレージに関してはさらに各アプリケーションの本体ファイルが占める領域を使用できる。所属アプリケーションＩＤ４３３はこのフラグメントバンドル３０５が宣言するグループに属する一つまたは複数のアプリケーション１１ｎ（これをアプリケーション群とも呼ぶ。）のアプリケーションＩＤを示す。

＜フラグメントバンドルのインストールおよびアンインストール＞
アプリケーション管理フレームワーク３０２はフラグメントバンドル３０５をインストール指示された場合には、アプリケーションと同様にフラグメントバンドル３０５のアプリケーションリソース上限宣言ファイル４２２を参照する。そして、そこに宣言されている各リソースのリソース上限値４３２をリソースサービス３０４の各リソースの現在のリソース上限値に対して加算しても全体として現在のアプリケーション実行環境内のリソースの空き容量の中に納まるかどうかを判定する。換言すればリソース上限値に記述されたリソースを確保する。現在のアプリケーション実行環境内で提供可能なリソース容量は予め与えられている。また現在のリソース上限値は、リソースサービス３０４がもともと宣言しているリソース上限値に、インストール済みのフラグメントバンドルが宣言しているリソース上限値を加算した値となっている。納まる場合にはフラグメントバンドル３０５のインストールを完了する。これは他のアプリケーションの意ストール時も同様である。インストールが完了すると、インストールされたフラグメントバンドル３０５の宣言したリソース上限値４３２は、追加先であるリソースサービス３０４の現在のリソース上限値に対して加算される。この加算演算により、グループ管理されたアプリケーションのリソース上限値は、リソースサービス３０４のリソース上限値として管理される。これにより、たとえばグループ管理されたアプリケーションのリソース（たとえばストレージ）は、リソースサービス３０２により代替的に確保されることになる。そこで、リソース上限値４３２としては、当該グループに属するアプリケーション個々のリソースの上限値のうち、最大の値以上の値が設定されることが望ましい。

逆にフラグメントバンドル３０５がアンインストールされると、フラグメントバンドル３０５が宣言しているリソース上限値４３２がリソースサービス３０４の現在のリソース上限値から減算される。もちろん減算はリソース種別ごとに行われる。なおこの減算は、アンインストールされるフラグメントバンドルを通してリソースサービスにより管理された共有リソースを解放してから行うべきなので、後述する図７Ｄの処理を完了してから行うことが望ましい。

このようにフラグメントバンドルはホストバンドルであるリソースサービスに対して後付け的に機能を付加したり、あるいは交換したりするために用いることができる。

図５はアプリケーション管理フレームワーク３０２の画面（アプリケーション管理画面と呼ぶ）の一例を示したものである。図５（ａ）に示したものがフラグメントバンドル３０５のインストールされる前の画面である。図５（ｂ）に示したものがフラグメントバンドル３０５がインストールされた後の画面である。

図５（ａ）において、アプリケーション名５０１はアプリケーション名の表示欄である。ここにはアプリケーション１１ｎ、リソースサービス３０４の名称が表示される。図５（ａ）では示されていないが、図５（ｂ）で示されるようにフラグメントバンドル３０５がインストールされた場合にもここに一覧される一つとして表示される。図５（ｂ）で示される通り、フラグメントバンドル３０５に対しても、アプリケーション名の表示欄５０１にフラグメントバンドル３０５の名称（この例では「アプリＡＢＣグループ設定 ０．１」）が表示される。

更新日時５０２はアプリケーション１１ｎ、リソースサービス３０４、フラグメントバンドル３０５の更新された日時を示す更新日時の表示欄である。また状態５０３はそれらのアプリケーションなどの稼働状況を表す状態欄である。この例では稼働時は「開始」、非稼働時は「停止」などと表示される。管理行為実行ボタン５０４は管理行為実行ボタン表示欄である。この例では「開始」状態にあるアプリケーションについては「停止」ボタン５１０および「アンイストール」ボタン５１１が表示される。開始／停止ボタン５１０は、それら各行に示されるアプリケーション１１ｎ、リソースサービス３０４、フラグメントバンドル３０５を開始、または停止を指示するためのボタンであり、稼働状態に応じて「開始」か「停止」かのいずれかが表示される。アンインストールボタン５１１は、それらをアンインストールを指示するためのアンインストールボタンである。このように本実施例においては管理行為実行ボタン表示欄５０４には開始／停止ボタン５１０およびアンインストールボタン５１１が表示される。ライセンス５０５は、これら各行に示されるアプリケーション１１ｎ、リソースサービス３０４、フラグメントバンドル３０５についてライセンスが必要であるか否かを表示するためのライセンス表示欄である。

図５（ａ）に示した画面例ではフラグメントバンドル３０５がまだインストールされていない。この図では「アプリケーションＡＬＰＨＡ」「アプリケーションＢＥＴＡ」「アプリケーションＧＡＭＭＡ」と表示されている３つのアプリケーションが一つのグループに属している。それらアプリケーションの更新日時５２０が示す通り、フラグメントバンドル３０５がまだインストールされていない状態ではこれらのアプリケーション１１ｎの更新日時はそれぞれのインストールされた時刻である。図５（ｂ）に示した画面例はフラグメントバンドル３０５をインストールした後の状態である。フラグメントバンドル３０５を管理者がインストールするには、リソースサービス３０４を開始／停止ボタン５１０で停止する。その後に通常の手順に従ってフラグメントバンドル３０５をインストールする。そしてリソースサービス３０４を再び開始／停止ボタン５１０により開始する。すると、フラグメントバンドルの表示行５３０に示されるように、フラグメントバンドル３０５がインストールされていることが画面上でも示される。またこの状態ではフラグメントバンドル３０５が示すグループ情報のグループに属するアプリケーション１１ｎはフラグメントバンドル３０５がインストールされた直後に上書きインストールされる。このインストールでは新たなアプリケーションリソース上限宣言ファイル４０２が適用されている。このため、グループに属するアプリケーションの更新日時５４０が示す通り更新日時が書き換えられる。

この画面例ではフラグメントバンドル３０５は、それが管理対象とするグループに属するアプリケーション１１ｎがインストールされた後からインストールされることになっている。しかしながら、本実施例においても、アプリケーション１１ｎを後からインストールすることは可能である。

図５に示したアプリケーション管理画面は、フラグメントバンドルを含むアプリケーションの属性や状態等に基づいて表示され、それら属性や状態は、たとえばアプリケーション管理テーブルなどといったインストールされているアプリケーションの属性や状態を格納するテーブルにより保存される。属性としてはたとえばライセンスの要・不要の別やアプリケーション名、更新日時等が含まれ、状態として稼働状態が含まれる。いったんインストールされた後でアンイストールされた場合にも当該アプリケーションの項目をテーブルに残し、インストール／アンインストールの別を示す状態を保持してもよい。そのテーブルはアプリケーションのインストールやアンインストール、状態の変化をトリガとして更新される。ただし、図６に示すグループデータテーブルやアプリケーションデータテーブルが保持する項目についてはアプリケーション管理テーブルで管理する必要はない。ただしテーブルのリンクのための情報、たとえはアプリケーションＩＤおよびフラグメントバンドルＩＤは重複して保持する必要がある。なお図５のアプリケーション管理画面は、アプリケーション管理フレームワーク３０２がＯＳＧｉフレームワークであれば、ＯＳＧｉフレームワークにより管理され、表示され、その表示のために必要なアプリケーション管理テーブルもまたＯＳＧｉフレームワークにより管理される。

＜リソースサービス＞
ここでリソースサービス３０５について改めて説明する。リソースサービス３０５はアプリケーション管理フレームワーク３０２上で動作するアプリケーションのひとつである。アプリケーション管理フレームワーク３０２がＯＳＧｉフレームワークであれば、ＯＳＧｉフレームワークは複数のＪａｖａ（登録商標）アプリケーションを並列に実行し、そのうち機能提供アプリケーション（サービスバンドルとも呼び、本例ではリソースサービスに相当する。）が、アプリケーションプログラムインターフェース（ＡＰＩ）を介して機能利用アプリケーション（サービス消費バンドルとも呼ぶ）にサービスを提供する仕組みを持つ。アプリケーションは、ＡＰＩを介してリソースサービスに対するリソース要求あるいはリソース解放によりリソースの取得や解放を行う。リソースの取得や解放はＪａｖａ標準クラスとして提供されたオブジェクト（ＡＰＩ）で行われ、リソースサービスは、それら標準クラスをラップしたラッパークラスを提供することでリソース管理のための追加的なサービスを実現している。追加的なサービスは、たとえばリソース要求元のアプリケーションに割り当てるリソースが、宣言されたリソース上限値を超えるかチェックし、超えるなら要求を拒絶し、超えないなら割り当てを行う、といったサービスである。リソースの生成及びアプリケーションへの提供は、ラップされた標準クラスで提供する機能により行われる。

リソースサービスが提供する機能は前述のとおりＡＰＩを介して行われ、ＡＰＩはサービス利用アプリケーションごとに生成されるオブジェクトにより実現される。ＯＳＧｉでは、ＡＰＩはそれを利用するサービス利用アプリケーションの要求に応じて生成され、提供される。サービス利用アプリケーションは、生成したＡＰＩを用いてサービス提供アプリケーションであるリソースサービスに対してリソース取得や解放などのサービスを要求する。

一方リソースサービスは、リソースサービスを用いるアプリケーション、たとえばリソースサービスのＡＰＩを生成済みのアプリケーションごとに、割り当て済みのリソースの量と、割り当てられる上限であるリソース上限値とを、アプリケーションＩＤと関連付けて記憶している。リソース上限値は当該アプリケーションのアプリケーションリソース上限宣言ファイル４０２のリソース上限値４１２から取得した値である。さらに、フラグメントバンドルごとのリソース上限値、すなわちグループごとのリソース上限値も、たとえばそのインストール時にフラグメントバンドルリソース上限宣言ファイル４２２から読み取って記憶しておき、それとともにそのグループに対して割り当て済みのリソース量も、グループＩＤと関連付けて記憶しておく。リソースサービス３０５によるアプリケーションリソース上限宣言ファイルからのリソース上限値の特定と読み取りは、たとえばＯＳＧｉであればリソースサービスを利用するアプリケーションがインストールされ、実行が開始されてリソースサービスに対してＡＰＩの生成を要求する際に、そのアプリケーションのためのＡＰＩの初期化処理の一部として行えばよい。あるいはＰＳＧｉ以外のフレームワークの場合、ＡＰＩオブジェクトを生成しないならば、リソース取得要求毎にリソース上限値４１２を参照してもよい。

そしてリソースサービスがたとえばリソース取得要求をアプリケーションから受け取ると、要求元のアプリケーションが単独管理されるアプリケーションであれば、その要求元アプリケーションに割り当て済みリソース量を参照し、その値と要求されたリソース量との和を、当該アプリケーションのリソース上限値と比較する。前者が後者を超えていればリソース要求を拒否し、その旨要求元アプリケーションに応答する。超えていなければリソースオブジェクトを要求元アプリケーションに対して返すとともに、要求元アプリケーションに割り当て済みリソース量に、要求されたリソース量を加算する。リソースオブジェクトは、リソースをアプリケーションプログラムで扱うためにオブジェクト化したものであり、リソースオブジェクトをアプリケーションに渡すことは、要求されたリソースをアプリケーションに割り当てることに相当する。

一方、リソース取得要求元のアプリケーションがグループ管理されるアプリケーションであれば、その要求元アプリケーションの属するグループに割り当て済みリソース量を参照し、その値と要求されたリソース量との和を、当該グループのリソース上限値と比較する。前者が後者を超えていればリソース要求を拒否し、その旨要求元アプリケーションに応答する。超えていなければリソースオブジェクトを要求元アプリケーションに対して返すとともに、当該グループに割り当て済みリソース量に、要求されたリソース量を加算する。換言すれば、リソースをグループ管理されたアプリケーション群により共有する。そしてそのアプリケーション群に属するアプリケーションからのリソース要求があれば、そのアプリケーション群が使用しているリソース量の総計に要求されたリソース量を加算し、その結果が当該グループのリソース上限値すなわち使用リソース宣言量を超えていないか判定する。超えていなければリソースは要求元に割り当てられる。なおグループ管理されるアプリケーションであることは、後述する図６のアプリケーションデータテーブル６２０を参照し、アプリケーションＩＤがアプリケーションデータテーブル６２０に登録されており、かつグループ管理状態が有効であることを確認することで行える。

＜グループデータテーブルおよびアプリケーションデータテーブル＞
図６（ａ）は本実施例のリソースサービス３０４がアプリケーション１１ｎのグループ管理を実施するために必要とするデータを保持するためのデータテーブルのうち、グループデータテーブル６００を模式的に表したものである。グループデータテーブル６００はたとえば記憶装置２０２に格納される。フラグメントバンドルＩＤ欄６０１はフラグメントバンドルＩＤ４３０の保持欄である。グループＩＤ欄６０２はグループＩＤ４３１の保持欄である。検出時刻欄６０３はリソースサービス３０４がフラグメントバンドル３０５を最初に検出した時刻の保持欄である。リソースサービス３０４がフラグメントバンドル３０５を最初に検出するのは、管理者がリソースサービス３０４を開始／停止ボタン５１０にて停止後、フラグメントバンドル３０５のインストールを行ったのち、再び開始した時刻である。同様に削除検出時刻欄６０４はリソースサービス３０４がいったんインストールされて検出したフラグメントバンドル３０５が削除されて消えていたことを検出した時刻の保持欄である。削除の検出も同様に、管理者がフラグメントバンドル３０５のアンインストール操作を行ったのち、再び開始した時刻である。管理対象アプリケーションＩＤ欄６０５はそのフラグメントバンドル３０５がグループとして管理する対象とするアプリケーションのアプリケーションＩＤ４１０の保持欄である。有効化状態欄６０６は当該フラグメントバンドルが有効であるか否かを記録する有効化状態の保持欄である。この有効化状態欄６０６には「有効」「無効」「アンインストール済」の三通りの状態が保持され得る。エントリー６１０は、ある一つのフラグメントバンドル３０５に関するグループデータテーブル６００のエントリーである。

図６（ｂ）は本実施例のリソースサービス３０４がアプリケーション１１ｎのグループ管理を実施するために必要とするデータを保持するためのデータテーブルのうちアプリケーションデータテーブル６２０を模式的に表したものである。アプリケーションデータテーブル６２０も例えば記憶装置２０２等に保持される。アプリケーションＩＤ欄６２１はアプリケーションＩＤ４１０の保持欄である。グループＩＤ欄６２２はグループＩＤ４３１の保持欄である。バージョン欄６２３は各行のアプリケーション１１ｎのバージョンの保持欄である。そして単独管理時リソース上限値欄６２４は、これらのアプリケーション１１ｎのグループ管理の管理下にない状態におけるアプリケーションリソース上限宣言ファイル４０２に宣言されたリソース上限値４１２を保持する単独管理時リソース上限値の保持欄である。本体ファイルサイズ欄６２５はこれらのアプリケーション１１ｎのプログラム本体のファイルの大きさの値である。リソース上限値４１２に宣言されたストレージの値からプログラム本体のファイルの大きさの値６２５を引いた値がそのアプリケーション１１ｎがグループ管理の管理下にない状態において利用する可能性のあるデータ用ストレージ領域の大きさである。グループ管理状態欄６２６はそのアプリケーション１１ｎがグループ管理の管理下にあるかどうかを示すグループ管理状態の保持欄である。

＜リソースサービス起動手順＞
図７Ａは本実施例におけるリソースサービス３０４が起動された時のリソースサービスによる処理の流れを模式的に表したフローチャートである。ここまでに述べた通りリソースサービス３０４に対してグループ情報を保持するフラグメントバンドル３０５を追加でインストールすることでグループ情報を追加認識させることが可能である。同様にフラグメントバンドル３０５をアンインストールすることでグループ情報をリソースサービスの制御下より取り除くことが可能である。この際に、リソースサービス３０４はフラグメントバンドル３０５に対してホストバンドルとして動作しているため、フラグメントバンドル３０５のインストールおよびアンインストールの前にリソースサービスをいったん停止させる必要がある。フラグメントバンドル３０５のインストールおよびアンインストールそのものはアプリケーション管理フレームワーク３０２により実施される。ここで説明する処理は、フラグメントバンドル３０５がインストールあるいはアンインストールされた後に、改めてリソースサービス３０４が停止状態から起動される際に実行されるものである。

処理はステップＳ７００１から開始する。ステップＳ７００２でリソースサービス３０４はまずフラグメントバンドル３０５のインストール状態を確認する。つまり、前回終了時までに存在しなかったフラグメントバンドル３０５が新たにインストールされていないか、または、前回終了時まで存在していたフラグメントバンドル３０５がアンインストールされていないか、などチェックする。このチェックは、アプリケーション管理フレームワーク３０２により管理されたアプリケーションに関する情報例えば図５に関連して説明したアプリケーション管理テーブルを参照することで実現できる。参照は例えばアプリケーション管理フレームワークが提供する機能を介して行える。ステップＳ７００３では新たにインストールされたフラグメントバンドル３０５が存在するかを判定し、そのようなフラグメントバンドル３０５が存在していればステップＳ７００４へ進む。存在していなければステップＳ７００５へ進む。ステップＳ７００４ではリソースサービス３０４はフラグメントバンドル３０５インストール時の処理を行う。フラグメントバンドル３０５インストール時の処理が完了したら処理はステップＳ７００５へ進む。

ステップＳ７００５では、リソースサービス３０４はアンインストールされたフラグメントバンドル３０５が存在するかを判定し、そのようなフラグメントバンドル３０５が存在すればステップＳ７００６へ進む。存在しなければステップＳ７００７へ進む。ステップＳ７００６ではリソースサービス３０４はフラグメントバンドル３０５アンインストール時の処理を行う。フラグメントバンドル３０５アンインストール時の処理が完了したら処理はステップＳ７００７へ進む。ステップＳ７００７へ到達したらリソースサービス３０４の起動処理は完了する。

図７Ｂ、図７Ｃはさらにフラグメントバンドル３０５インストール時の処理であるステップＳ７００４の内容について説明したフローチャートである。ステップＳ７１０１は一連の処理の開始である。ステップＳ７１０２にてまずリソースサービス３０４は新たにインストールされたフラグメントバンドル３０５から、そのグループ情報、具体的にはグループＩＤ４３１を取得する。続いてステップＳ７１０３で、取得したグループ情報はグループデータテーブル６００に登録済みであるかどうかを判定する。登録済みでなければ処理はステップＳ７１０４へ進む。ステップＳ７１０４ではグループデータテーブル６００に取得したグループ情報を登録し、処理はステップＳ７１０６へ進む。登録済みであれば処理はステップＳ７１０５へ進む。ステップＳ７１０５では取得したグループ情報を用いてグループデータテーブル６００のデータを更新し、ステップＳ７１０６へ進む。ステップＳ７１０４、Ｓ７１０５では、図６（ａ）に示した各項目を登録又は更新する。フラグメントバンドルＩＤ欄６０１、グループＩＤ欄６０２、管理対象アプリケーションＩＤ欄６０５の内容は、たとえばフラグメントバンドル上限宣言ファイル４２２のフラグメントバンドルＩＤ４３０、グループＩＤ４３２、所属アプリケーションＩＤ４３３からそれぞれ取得する。検出時刻は、検出した時刻を実時間クロックやインターネットの時刻サイト等から読み取り、それを記録する。ステップＳ７１０６では、インストール済みであるアプリケーション１１ｎの中に、インストールされたフラグメントバンドル３０５の保持しているグループ情報の示すグループに属するものが存在するかをチェックする。もしもそのようなアプリケーション１１ｎが存在しなければ処理はステップＳ７１１７へ進む。存在している場合には、それらアプリケーションを対象として処理はステップＳ７１０７へ進む。

ステップＳ７１０７からステップＳ７１１３ではそのようなアプリケーション１１ｎについて繰返し処理を実行する。ステップＳ７１０８ではリソースサービス３０４はアプリケーション管理フレームワーク３０２を通じて処理対象のアプリケーション１１ｎが開始済みの状態であるかどうかを確認する。開始済みであれば処理はステップＳ７１０９へ進む。停止状態であれば処理はステップＳ７１１０へ進む。ステップＳ７１０９では処理対象のアプリケーション１１ｎを、アプリケーション管理フレームワーク３０２を通じて停止する。その後処理はステップＳ７１１０へ進む。ステップＳ７１１０では処理対象のアプリケーション１１ｎのマニフェストに記載され宣言されているストレージの上限値を取得する。続くステップＳ７１１１で処理対象のアプリケーションの現在のストレージ使用量を取得する。この値は、たとえばアプリケーション管理フレームワーク３０２を通じてアプリケーション実行基盤３０１から取得する。さらにステップＳ７１１２にてリソースサービス３０４はアプリケーション管理フレームワーク３０２を通じて処理対象のアプリケーション１１ｎのプログラム本体ファイルのサイズを取得する。ここでプログラム本体ファイルのサイズとは、プログラムコードの収容されたファイルおよびインストール時に展開されプログラム実行に必要なファイルが画像形成装置１００上で展開された時にストレージを占有するサイズの合計を指す。続くステップＳ７１１３で処理対象のアプリケーション１１ｎについての繰返し処理が完了したかを判定し完了していなければ処理はステップＳ７１０７から続行される。完了していれば処理はステップＳ７１１４へ進む。

ステップＳ７１１４ではステップＳ７１０７からの繰返し処理により算出された処理対象のアプリケーション１１ｎそれぞれについてのストレージ使用量のうちデータ部分の使用量の合計を算出する。データ部分の使用量とは、ステップＳ７１１１で取得したストレージ使用量からステップＳ７１１２で取得したプログラム本体ファイルのサイズを差し引いた値を指す。すなわちアプリケーション１１ｎがインストール時に展開されたプログラム本体ファイル以外に、稼働時に後から追加で使用したストレージの使用量に等しい。ステップＳ７１１４ではこのデータ部分の使用量についてインストールされているグループに属するアプリ全てに関して合計を算出する。続くステップＳ７１１５にてこの合計した値が、処理対象のフラグメントバンドル３０５が宣言しているグループのストレージの上限値４３２を超えているかどうかをチェックする。超えている場合には処理はステップＳ７１１６へ進む。超えていない場合には処理はステップＳ７１１９へ進む。

ステップＳ７１１９からステップＳ７１３０では再びインストールされていてグループに属しているアプリケーション１１ｎを処理対象として繰返し処理を行う。まずステップＳ７１２０にて処理対象のアプリケーション１１ｎのアプリケーションリソース上限宣言ファイル４０２のリソースの上限値４１２部分を書き換えた新たなアプリケーションリソース上限宣言ファイル４０２を生成する。この新たなアプリケーションリソース上限宣言ファイル４０２は、ストレージについてはステップＳ７１１２で取得した処理対象のアプリケーション１１ｎのプログラム本体ファイルのサイズを上限値として宣言するものとなっている。その他のリソースについては上限値はゼロである。続くステップＳ７１２１にてステップＳ７１２０で生成したアプリケーションリソース上限宣言ファイル４０２とその他のプログラム本体ファイルをまとめてインストール用ファイルを作成する。そして続くステップＳ７１２２にてリソースサービス３０４はステップＳ７１２１にて作成したインストール用ファイルを用いてアプリケーション管理フレームワーク３０２を通じて上書きインストール操作を行う。続くステップＳ７１２３にて上書きインストールに成功したかどうかをチェックする。成功していれば処理はステップＳ７１２４へ進む。失敗していれば処理はステップＳ７１２８へ進む。ステップＳ７１２４では処理対象のアプリケーションのグループ管理状態６２６をアプリケーションデータテーブル６２０上で有効に変更する。続くステップＳ７１２５にて処理対象のアプリケーション１１ｎがここまでに使用しているデータ部分のストレージリソースおよびその他のリソースをグループ管理下へ移管する。すなわちアプリケーション１１ｎ単位の管理を行っていたものをインストールされたフラグメントバンドル３０５が示すグループ単位での管理に変更する。そしてステップＳ７１２６にてインストールされたフラグメントバンドル３０５のグループ管理はグループデータテーブル６００上で無効であるかどうかを判定し、無効でなければ、すなわち有効であれば処理はステップＳ７１２８へ進む。無効である場合には処理はステップＳ７１２７へ進み、グループデータテーブル６００上で有効化状態６０６を有効に変更する。そして処理はステップＳ７１２８へ進む。ステップＳ７１２８では処理対象のアプリケーション１１ｎは停止状態であるかどうかを判定する。開始済みである場合には処理はステップＳ７１３０へ進む。停止状態である場合には処理はステップＳ７１２９へ進み、リソースサービス３０４はアプリケーション管理フレームワーク３０２を通じて処理対象のアプリケーション１１ｎを開始させる。そして処理はステップＳ７１３０へ進む。ステップＳ７１３０では処理対象のアプリケーション１１ｎについての繰返し処理が完了したかどうかを確認し、完了していなければステップＳ７１１９へ戻って続行する。完了していれば処理はステップＳ７１３３へ進む。
ステップＳ７１０６にてインストールされたフラグメントバンドル３０５のグループに属するアプリケーション１１ｎが一つもインストールされていなかった場合には処理はステップＳ７１１７へ進む。ステップＳ７１１７ではリソースサービス３０４は「インストールされたフラグメントバンドル３０５のグループに属するアプリケーション１１ｎがインストールされていない」という警告を出す。そして処理は
ステップＳ７１３１へ進む。

ステップＳ７１１５にてインストールされたフラグメントバンドル３０５のグループに属するアプリケーション１１ｎのストレージのデータ部分の使用量の合計がグループの上限を超えている場合には処理はステップＳ７１１６へ進む。ステップＳ７１１６ではリソースサービス３０４は「インストールされたフラグメントバンドル３０５のグループに属するアプリケーション１１ｎのストレージの使用量総計がグループ上限を超えている」という警告を出す。そして処理はステップＳ７１３１へ進む。

ステップＳ７１３１ではインストールされたフラグメントバンドル３０５のグループの有効化状態６０６が無効になっているかどうかをチェックする。無効であれば処理はステップＳ７１３３へ進む。無効になっていない場合には処理はステップＳ７１３２へ進み、インストールされたフラグメントバンドル３０５のグループの有効化状態６０６を無効に設定する。そして処理はステップＳ７１３３へ進む。ステップＳ７１３３では他にインストールされたフラグメントバンドル３０５があるかどうかを判定し、あるのであればそのフラグメントバンドル３０５についての処理をステップＳ７１０２より続行する。他にインストールされたフラグメントバンドル３０５が存在しないのであれば処理はステップＳ７１３４へ進む。ステップＳ７１３４にて一連の処理を完了する。

図７Ｄはさらにフラグメントバンドル３０５アンインストール時の処理であるステップＳ７００６の内容について説明したフローチャートである。ステップＳ７２０１は一連の処理の開始である。ステップＳ７２０２にてまずリソースサービス３０４はアンインストールされたフラグメントバンドル３０５のグループ情報を、グループデータテーブル６００から取得する。続くステップＳ７２０３にてグループデータテーブル６００上の有効化状態６０６をアンインストール済状態に変更する。続くステップＳ７２０４にてインストール済みであるアプリケーション１１ｎの中にアンインストールされたフラグメントバンドル３０５の保持していたグループ情報の示すグループに属していたものが存在するかをチェックする。もしもそのようなアプリケーション１１ｎが存在しなければ処理はステップＳ７２２０へ進む。そんざいしている場合には処理はステップＳ７２０５へ進む。

ステップＳ７２０５からステップＳ７２１９ではそのようなアプリケーション１１ｎについて繰返し処理を実行する。ステップＳ７２０６では処理対象のアプリケーション１１ｎのアプリケーションリソース上限宣言ファイル４０２のリソース上限４１２の部分を書き換えたものを生成する。この際書き換えられるリソース上限４１２の値は、処理対象のアプリケーション１１ｎがグループ管理へ移管される際にリソースサービス３０４によって書き換えられる前の値を用いる。すなわち処理対象のアプリケーション１１ｎが単独管理で動作している時に宣言されている上限値が用いられる。この値はアプリケーションデータテーブル６３０に保存されている。続くステップＳ７２０７で処理対象のアプリケーションのプログラム本体ファイルおよびステップＳ７２０６にて生成したアプリケーションリソース上限宣言ファイル４０２からインストール用ファイルを生成する。そしてリソースサービス３０４は続くステップＳ７２０８にてステップＳ７２０７にて生成したファイルを用いてアプリケーション管理フレームワーク３０２を通じて上書きインストールを実行する。ステップＳ７２０９では上書きインストールが成功したかどうかをチェックする。成功した場合には処理はステップＳ７２１０へ進む。成功していなかった場合には処理はステップＳ７２１７へ進む。

ステップＳ７２１０では処理対象のアプリケーション１１ｎが開始済であるかをチェックする。停止状態であれば処理はステップＳ７２１２へ進む。開始済であれば処理はステップＳ７２１１へ進む。ステップＳ７２１１では処理対象のアプリケーション１１ｎを開始する。そして処理はステップＳ７２１２へ進む。ステップＳ７２１２では処理対象のアプリケーション１１ｎについてグループ管理の下で確保されていたリソースをそのアプリケーション１１ｎの単独管理の下で確保している領域へ振り替えるとともに使用量を単独の使用量として集計し直す処理を行う。続くステップＳ７２１３においてアプリケーションデータテーブル６２０のグループ管理状態６２６を無効に変更する。そして続くステップＳ７２１４で処理対象のアプリケーション１１ｎが使用しているデータ用のストレージの使用量をプログラム本体のファイルの使用量と足し合わせた値をチェックする。つまり、その値が処理対象のアプリケーション１１ｎの単独管理におけるストレージの上限の宣言値を上回っていないかを確認する。上回っている場合には処理はステップＳ７２１８へ進む。上限値内に納まっている場合には処理はステップＳ７２１５へ進む。ステップＳ７２１５では処理対象のアプリケーションが停止中であるかどうかを確認し、停止中であれば処理はステップＳ７２１６へ進む。ステップＳ７２１６ではリソースサービス３０４は処理対象のアプリケーション１１ｎを、アプリケーション管理フレームワーク３０２を通じて開始させる。そして処理はステップＳ７２１９へ進む。

ステップＳ７２０９にて上書きインストールが失敗したと判定した場合には処理はステップＳ７２１７へ進む。ステップＳ７２１７では「グループ管理下にあったアプリケーション１１ｎを単独管理に戻す処理においてエラーが発生した」ことを示す警告を出す。そして処理はステップＳ７２１９へ進む。

ステップＳ７２１４にてその足し合わせた値が処理対象のアプリケーション１１ｎの単独管理におけるストレージの上限値を上回っていた場合には処理はステップＳ７２１８へ進む。ステップＳ７２１８ではリソースサービス３０４は「グループ管理下にあったアプリケーション１１ｎを単独管理へ戻したがストレージの使用量が上限を超過するため、アプリケーション１１ｎの実行を一時的に停止する」ことを示す警告を出す。そして処理はステップＳ７２１９へ進む。

ステップＳ７２１９では処理対象となるアプリケーション１１ｎについての繰返し処理が全て完了したかを判定し、まだ処理していない処理対象となるアプリケーション１１ｎが存在する場合にはステップＳ７２０５から続行する。全ての処理対象となるアプリケーション１１ｎについての処理が完了していたら処理はステップＳ７２２０へ進む。ステップＳ７２２０ではアンインストールされたフラグメントバンドル３０５が他にもあるかどうかをチェックする。あれば処理は次のフラグメントバンドル３０５についてステップＳ７２０２から続行される。ない場合には処理はステップＳ７２２１へ進む。ステップＳ７２２１にて一連の処理は完了する。

＜リソース管理の具体的説明＞
図８は本実施例においてリソースサービス３０４がストレージのグループ管理を行う方法をさらに模式的に図示したものである。

状態８００は、リソースサービス３０４はフラグメントバンドル３０５がインストールされていない状態を示している。この時アプリケーションＡＬＰＨＡが宣言している上限値は上限値８０９で示される大きさである。このうちアプリケーションＡＬＰＨＡのプログラム本体のファイルが占有する使用量は使用量８０１で示される大きさである。そしてアプリケーションＡＬＰＨＡが動作時にデータ目的でファイルを作成して使用しているストレージの量は使用量８０２で示される大きさである。そして空き容量が容量８０３である。アプリケーションＢＥＴＡについても同様であり、上限値は上限値８１９で示される。プログラム本体のファイルが占有している量は使用量８１１で示される大きさであり、データ目的でファイルを作成して使用している量は使用量８１２で示される。空き容量は容量８１３で示される。アプリケーションＧＡＭＭＡについても同様に上限値が上限値８２９で示される。プログラム本体のファイルの占有量が使用量８２１であり、データ目的の使用量が使用量８２２であり、空き容量が容量８２３である。なおこれらのうちそれぞれのアプリケーション１１ｎがインストールされている状態でプログラム本体のファイルの容量を占有している容量はそれぞれ容量８０１、容量８１１、容量８２１である。アプリケーション管理フレームワーク３０２の原則により、これらの容量をアプリケーションと切り離して管理することはできない。

状態８９０は、フラグメントバンドル３０５がインストールされた状態を示している。フラグメントバンドル３０５がインストールされた状態におけるグループ全体で使用可能なデータ目的のストレージの量は容量８９９で示される。すでに述べた原則により、例えばアプリケーションＡＬＰＨＡに対しては、プログラム本体のファイルの占有する容量８０１だけはアプリケーションリソース上限宣言ファイル４０２によって確保しなくてはならない。アプリケーションＢＥＴＡについても同様に容量８１１で示される容量だけは確保する必要がある。アプリケーションＧＡＭＭＡについても容量８２１を確保する必要があるのは同様である。このため本実施例ではフラグメントバンドル３０５がインストールされた状態でもそれらの容量についてはこれらアプリケーションのアプリケーションリソース上限宣言ファイル４０２で宣言して確保する必要がある。このためにフラグメントバンドル３０５のインストールの過程で、それらアプリケーションリソース上限宣言ファイル４０２を書き換える処理を行っている。この結果、矢印８３１が示すようにプログラム本体ファイルの使用量８０１、８１１、８２１は各アプリケーションのリソースの使用量として残る。一方で単独管理時には、各アプリケーションの宣言している領域内で確保されていたデータ目的の領域の使用量８０２、８１２、８２２は移管される。これらは矢印８３２が示すようにフラグメントバンドル３０５が新たに確保したグループのためのリソース領域内で管理されるようになる。これによりリソースサービス３０４はこれらのストレージの使用量の合計がフラグメントバンドル３０５に割り当てられた領域８９９の大きさを超えないように管理を続行することができる。フラグメントバンドル３０５をアンインストールする際には逆の操作を行う。

＜アプリケーションのインストール手順＞
図９は本実施例におけるアプリケーション１１ｎのインストールの処理のシーケンスを模式的に表したフローチャートである。アプリケーション管理フレームワーク３０２よりアプリケーション１１ｎのインストールが行われたという通知を受け取ったリソースサービス３０４がこのシーケンスを実行する。ステップＳ９００１から処理を開始する。ステップＳ９００２にてリソースサービス３０４はアプリケーション管理フレームワーク３０２よりインストールされたアプリケーション１１ｎのデータを受け取る。続くステップＳ９００３にてリソースサービス３０４はアプリケーションデータテーブル６２０にインストールされたアプリケーション１１ｎのデータを登録する。次にステップＳ９００４にてインストールされたアプリケーションはいずれかのグループに属しているかを判定する。属していなければ処理はステップＳ９０１７へ進む。属している場合には処理はステップＳ９００５へ進む。ステップＳ９００５ではインストールされたアプリが属しているグループの情報がグループデータテーブル６００に登録されているかどうかを判定する。登録されていなければ処理はステップＳ９０１７へ進む。登録されていれば処理はステップＳ９００６へ進む。ステップＳ９００６ではインストールされたアプリケーション１１ｎの属するグループのグループ情報はグループデータテーブル６００の有効化状態６０６において有効状態であるかどうかをチェックする。有効ではない場合処理はステップＳ９０１７へ進む。有効である場合には処理はステップＳ９００８へ進む。ステップＳ９００４からステップＳ９００７の判定は、グループデータテーブル６００およびアプリケーションデータテーブル６２０を参照して行うことができる。続くステップＳ９００８ではインストールされたアプリケーション１１ｎが開始済みの状態であるかどうかを判定する。

停止状態であれば処理はステップＳ９０１０へ進む。開始済みであれば処理はステップＳ９００９へ進む。ステップＳ９００９ではリソースサービス３０４はアプリケーション管理フレームワーク３０２を通じてインストールされたアプリケーション１１ｎを停止する。その後処理はステップＳ９０１０へ進む。ステップＳ９０１０ではリソースサービス３０２はインストールされたアプリケーション１１ｎのプログラム本体のファイルのサイズを取得する。そして続くステップＳ９０１１にてインストールされたアプリケーション１１ｎのアプリケーションリソース上限宣言ファイル４０２のリソースの上限値４１２部分を書き換えた新たなアプリケーションリソース上限宣言ファイル４０２を生成する。この新たなアプリケーションリソース上限宣言ファイル４０２はストレージについては前段で取得した、インストール対象のアプリケーション１１ｎのプログラム本体ファイルのサイズを上限値として宣言するものとなっている。その他のリソースについては上限値はゼロである。すなわち、グループ管理が可能な状態であれば、単独管理用のリソース上限値を、グループ管理用のリソース上限値で置き換える。続くステップＳ９０１２にてステップＳ９０１１で生成したアプリケーションリソース上限宣言ファイル４０２とその他のプログラム本体ファイルをまとめてインストール用ファイルを作成する。そして続くステップＳ９０１３にてリソースサービス３０４はステップＳ９０１２にて作成したインストール用ファイルを用いてアプリケーション管理フレームワーク３０２を通じて上書きインストール操作を行う。続くステップＳ９０１４にて上書きインストールに成功したかどうかをチェックする。成功していれば処理はステップＳ９０１５へ進む。失敗していれば処理はステップＳ９１０９へ進む。ステップＳ９０１５ではインストールされたアプリケーション１１ｎのアプリケーションデータテーブル６２０におけるグループ管理状態６２６を有効に変更する。その後処理はステップＳ９０１９へ進む。

ステップＳ９０１７へ処理が進むとリソースサービス３０４はアプリケーション管理フレームワーク３０２を通じてインストールされたアプリケーションが停止状態であるかをチェックする。停止状態であれば処理はステップＳ９０１８へ進む。開始済みであれば処理はステップＳ９０１９へ進む。ステップＳ９０１８ではリソースサービス３０４はアプリケーション管理フレームワーク３０２を通じてインストールされたアプリケーション１１ｎを開始させる。その後処理はステップＳ９０１９へ進む。ステップＳ９０１９にて一連の処理が完了する。

この手順により、グループ管理対象のアプリケーションがインストールされても、グループ管理できる状態でなければ、アプリケーション単独でリソースが管理され、実行される。

＜アプリケーションのアンイストール手順＞
図１０は本実施例におけるアプリケーション１１ｎのアンインストールの処理のシーケンスを模式的に表したフローチャートである。アプリケーション管理フレームワーク３０２よりアプリケーション１１ｎのアンインストールが行われたという通知を受け取ったリソースサービス３０４がこのシーケンスを実行する。ステップＳ１０００１から処理を開始する。ステップＳ１０００２にてリソースサービス３０２はアンインストールされたアプリケーション１１ｎのデータを受け取る。次にステップＳ１０００３にてアンインストールされたアプリケーション１１ｎの取得していたリソースの中で解放されていないものがあるかどうかをチェックする。そういうものがない場合には処理はステップＳ１００１０へ進む。存在する場合にはステップＳ１０００４へ進む。

ステップＳ１０００４ではアンインストールされたアプリケーション１１ｎの取得していたリソースのうち解放されていないものについて繰り返し処理を実行する。ステップＳ１０００５でリソースの解放が可能かどうかをチェックする。可能であれば処理はステップＳ１０００６へ進む。できない場合には処理はステップＳ１０００８へ進む。ステップＳ１０００６ではリソースを解放する。そして続くステップＳ１０００７にて解放されたリソースの量を管理単位の使用量から減算する。たとえば単独管理であれば全体の使用量から減算し、グループ管理であればグループの使用量から減算する。そして処理はステップＳ１０００９へ進む。ステップＳ１０００８へ処理が進んだ場合にはリソースサービス３０４は「リソースの解放に失敗した」という警告を出す。その後処理はステップＳ１０００９へ進む。ステップＳ１０００９では繰り返し処理の対象となるリソースを全て処理し終わったかを判定しまだであればステップＳ１０００４へ戻って続行する。全て終わったのであれば処理はステップＳ１００１０へ進む。

ステップＳ１００１０ではアンインストールされたアプリケーション１１ｎはグループに属していたかを判定する。属していなければ処理はステップＳ１００１３へ進む。属していた場合には処理はステップＳ１００１１へ進む。ステップＳ１００１１ではアンインストールされたアプリケーション１１ｎが属していたグループにはまだインストールされた状態にある他のアプリケーション１１ｎが存在しているかを判定する。この判定では、例えばアプリケーションデータテーブル６３０からアンインストールされたアプリケーションと同じグループに属する他のアプリケーションを検索し、該当するものがあればそれに対応するグループ管理状態６２６を参照する。「有効」なものがあれば、存在していると判定できる。そのような他のアプリケーション１１ｎが存在していれば処理はステップＳ１００１３へ進む。存在していなければ処理はステップＳ１００１２へ進む。ステップＳ１００１２ではアンインストールされたアプリケーション１１ｎが属していたグループの有効化状態６０６を無効に変更する。このステップでは、たとえばグループデータテーブル６００の該当するグループの有効化状態６０６を「無効」に書き換える。その後処理はステップＳ１００１３へ進む。ステップＳ１００１３ではアンインストールされたアプリケーション１１ｎの情報をアプリケーションデータテーブル６２０から消去する。その後処理はステップＳ１００１４へ進む。ステップＳ１００１４にて一連の処理を完了する。

ここまで見てきたように本発明の第一の実施例においては、リソースサービス３０４を用いることでアプリケーション１１ｎは、アプリケーションごとにリソースを排他的に管理する単独管理の下で動作することが可能である。そしてリソースサービス３０４はそのようなアプリケーション１１ｎが単独管理の下でもそのアプリケーションリソース上限宣言ファイル４０２によって宣言したリソース上限４１２を超えないよう制御することができる。加えて本実施例においてリソースサービス３０４はグループ情報を保持したフラグメントバンドル３０５をインストールすることによりアプリケーション１１ｎを、グループに属するアプリケーション間でリソースを共有するグループ管理の下で動作させることが可能である。この時リソースサービス３０４はアプリケーション１１ｎがグループ管理の下で動作する時にはグループに対して設定されたリソースの上限値を超えないように制御することができる。そして本実施例では、リソースサービス３０４はアプリケーション１１ｎが動作している状態でフラグメントバンドル３０５がインストールされた場合であっても矛盾なくリソース管理を継続することができる。この場合アプリケーション１１ｎは単独管理からグループ管理へ継続的に移行することが可能である。同様にフラグメントバンドル３０５がアンインストールされる時にアプリケーション１１ｎをグループ管理の下から単独管理の下へ移行して継続的に使用することが可能である。このように、本実施例ではアプリケーション１１ｎのリソース管理に関する単独管理とグループ管理の二つの様相を、自在に切り替え適用することを可能にする。

結果として、本実施例に依れば複数のアプリケーション１１ｎを組み合わせて導入する際にグループ情報を保持するフラグメントバンドル３０５を利用することができる。そのことにより、グループのリソースの上限を、それぞれのアプリケーション１１ｎ単独で宣言している上限の単純な合計値よりも少なく抑えることが可能になる。従って本実施例のリソース管理装置を設けない場合にはリソース上限値の合計がアプリケーション実行環境の制限を超えるために導入できなかった組合せのアプリケーション１１ｎを導入することが可能になるという効果が得られる。加えて本実施例に依ればグループ情報を有するフラグメントバンドル３０５は、グループ管理が必要になった時に初めて導入することで事足りる。これによりアプリケーション１１ｎの導入のハードルを低めることができ、画像形成装置１００を管理する管理者の負担が大幅に軽減するという効果が得られる。

また、グループ管理対象のアプリケーションであっても、当該グループのフラグメントバンドルがインストールされていない場合、あるいはインストールされていても無効状態の場合には、当該アプリケーションは、単独管理対象のアプリケーションとしてリソースが管理される。

［第二の実施例］
次に本発明の第二の実施例について図を用いて解説を加える。第一の実施例ではアプリケーション１１ｎを単独管理状態でも稼働させるために、アプリケーションリソース上限宣言ファイル４０２のリソース上限値４１２には単独管理の下での稼働時の値が記載されている必要があった。しかしながら、グループ管理状態での稼働が前提であれば、そのような値の宣言は不要である。本実施例では、グループ管理状態に正しく置かれていないアプリケーション１１ｎは停止状態に移行させることにより、グループ管理によるアプリケーション１１ｎのリソース管理を容易に行うリソース管理装置を示す。

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

図１１は本実施例におけるアプリケーション管理フレームワーク３０２の画面（ユーザーインターフェース）の一例を示したものである。図５との差分についてのみ説明を加える。本実施例においてはグループに属するアプリケーション１１ｎは、そのグループ情報を有するフラグメントバンドル３０５がインストールされていない状態では停止状態に置かれる。それが図１１（ａ）の状態欄１１００に示した部分である。グループに属するアプリケーションＡＬＰＨＡ、アプリケーションＢＥＴＡ、アプリケーションＧＡＭＭＡは停止状態に置かれていることが示されている。これに対して、行５３０で示すようにフラグメントバンドル３０５がインストールされると、図１１（ｂ）の状態欄１１０１に示される通りこれらのアプリケーション１１ｎが開始状態に移行する。

本実施例におけるグループデータテーブル６００の内容を示した図は図６（ａ）と同様である。本実施例におけるリソースサービス３０４が起動された時の処理の流れは図７Ａに示したものと同様である。

＜第二実施例におけるフラグメントバンドルのインストール処理＞
さらに図１２Ａにフラグメントバンドル３０５インストール時の処理であるステップＳ７００４の内容をフローチャートに表し説明を加える。なお本実施例では、アプリケーションリソース上限宣言ファイル４０２のリソース上限値４１２としては、ストレージとしてプログラム本体のファイルサイズが与えられ、他の種類のリソースとして０が与えられている。すなわち、第一の実施例におけるグループ管理下における各アプリケーションのリソース上限値がアプリケーションリソース上限宣言ファイル４０２に定義されている。

ステップＳ１２１０１は一連の処理の開始である。ステップＳ１２１０２においてまずリソースサービス３０４はインストールされたフラグメントバンドル３０５から、そのグループ情報を取得する。続いてステップＳ１２１０３で、取得したグループ情報はグループデータテーブル６００に登録済みであるかどうかを判定する。登録済みでなければ処理はステップＳ１２１０４へ進む。ステップＳ１２１０４ではグループデータテーブル６００に取得したグループ情報を登録し、処理はステップＳ１２１０６へ進む。登録済みであれば処理はステップＳ１２１０５へ進む。ステップＳ１２１０５では取得したグループ情報を用いてグループデータテーブル６００のデータを更新し、ステップＳ１２１０６へ進む。ステップＳ１２１０６では、インストール済みであるアプリケーション１１ｎの中に、インストールされたフラグメントバンドル３０５の保持しているグループに属するものが存在するかをチェックする。もしもそのようなアプリケーション１１ｎが存在しなければ処理はステップＳ１２１１３へ進む。存在する場合には処理はステップＳ１２１０７へ進む。

ステップＳ１２１０７からＳ１２１１０ではそのようなグループに属しているアプリケーション１１ｎに対して繰返し処理を行う。ステップＳ１２１０８で処理対象であるアプリケーション１１ｎは停止状態であるかどうかを判定する。停止状態ではない場合には処理はステップＳ１２１０９へ進む。停止状態であれば処理はステップＳ１２１１０へ進む。ステップＳ１２１０９ではリソースサービス３０４がアプリケーション管理フレームワーク３０２を通じて処理対象であるアプリケーション１１ｎを開始し、ステップＳ１２１１０へ進む。ステップＳ１２１１０ではさらに処理対象となるアプリケーション１１ｎが存在するかどうかを判定し、存在する場合にはステップＳ１２１０７からの繰返し処理を続行する。存在しない場合にはステップＳ１２１１２へ進む。ステップＳ１２１０９ではインストールされたフラグメントバンドル３０５の保持しているグループに関してグループ管理を有効化して処理はステップＳ１２１１４へ進む。また処理がステップＳ１２１０６からステップＳ１２１１３へ進んだ場合には、リソースサービス３０４は「グループに属するアプリケーションがインストールされていない」警告を出力する。ステップＳ１２１１３の処理が完了したら処理はやはりステップＳ１２１１４へ進む。ステップＳ１２１１４では他にもインストールされたフラグメントバンドル３０５があるかどうかをリソースサービスがチェックする。もしも存在する場合にはステップＳ１２１０２へ戻り、そのフラグメントバンドル３０５について同様の処理を実行する。もうそのようなフラグメントバンドル３０５は存在しない場合には処理はステップＳ１２１１５へ進み、一連の処理を終了する。

＜第二実施例におけるフラグメントバンドルのアンインストール手順＞
またフラグメントバンドル３０５アンインストール時の処理であるステップＳ７００６の内容について図１２Ｂを用いて説明を加える。ステップＳ１２２０１は一連の処理の開始である。ステップＳ１２２０２においてまずリソースサービス３０４はグループデータテーブル６００を参照しアンインストールされたフラグメントバンドル３０５のグループ情報を取得する。そして続くステップＳ１２２０３にてグループデータテーブル６００の当該グループに関して削除検出時刻６０４を更新し、有効化状態６０６をアンインストール済に更新する。ステップＳ１２２０４では、インストール済みのアプリケーション１１ｎの中にアンインストールされたフラグメントバンドル３０５の保持していたグループ情報のグループに属していたアプリケーション１１ｎがあるかどうかをチェックする。ない場合には処理はステップＳ１２２１６へ進む。ある場合には処理はステップＳ１２２０５へ進む。ステップＳ１２２０５からＳ１２２１５では該当するアプリケーション１１ｎについて繰返し処理を行う。ステップＳ１２２０６ではまず処理対象であるアプリケーション１１ｎは開始中であるかどうかを判定する。開始中ではなく停止状態である場合には処理はステップＳ１２２０８へ進む。開始中である場合には処理はステップＳ１２２０７へ進む。ステップＳ１２２０７ではリソースサービス３０４がアプリケーション管理フレームワーク３０２を通じて処理対象であるアプリケーション１１ｎを停止しステップＳ１２２０８へ進む。ステップＳ１２２０８ではリソースサービス３０４は処理対象であるアプリケーション１１ｎの取得していたリソースで解放されていないものがあるかどうかを判定する。ある場合には処理はステップＳ１２２０９へ進む。ない場合には処理はステップＳ１２２１５へ進む。

ステップＳ１２２０９からＳ１２２１４ではそのような解放されていないリソースについて繰返し処理を行う。ステップＳ１２２１０にて処理対象である解放されていないリソースについて解放可能であるかどうかをチェックする。そして可能である場合には処理はステップＳ１２２１１へ進む。ステップＳ１２２１１ではリソースを実際に開放する処理を行い、ステップＳ１２２１３へ進む。ステップＳ１２２１３では解放したリソースの使用量を全体の管理しているリソースの使用量から減算する。そしてステップＳ１２２１４へ進む。可能でない場合にはステップＳ１２２１３へ進む。ステップＳ１２２１３では「リソースの解放に失敗した」警告を出力してステップＳ１２２１４へ進む。ステップＳ１２２１４では処理対象のリソースがまだ存在するかを判定し、存在する場合にはステップＳ１２２０９へ戻って繰返し処理を続行する。存在しない場合にはステップＳ１２２１５へ進む。ステップＳ１２２１５では処理対象のアプリケーション１１ｎがまだ存在するかを判定し、存在する場合には処理はステップＳ１２２０５へ戻って繰返し処理を続行する。存在しない場合には処理はステップＳ１２２１６へ進む。

ステップＳ１２２１６では他にもアンインストールされたフラグメントバンドル３０５が存在するかどうかをチェックする。そのようなフラグメントバンドル３０５が存在する場合には処理は、そのフラグメントバンドル３０５を処理対象としてステップＳ１２２０２から続行される。そのようなフラグメントバンドル３０５が存在しない場合には処理はステップＳ１２２１７へ進み、一連の処理を終了する。

＜アプリケーションインストール時のリソースサービスの動作＞
図１３は本実施例におけるアプリケーション１１ｎのインストールが行われた時のリソースサービス３０４の動作を模式的に表したフローチャートである。ステップＳ１３００１から処理を開始する。ステップＳ１３００２ではまずリソースサービス３０４はアプリケーション管理フレームワーク３０２からアプリケーション１１ｎがインストールされたと言う通知を受け取る。そして続くステップＳ１３００３でリソースサービス３０４はアンインストールされたアプリケーション１１ｎがグループ管理の対象であったかどうかをチェックする。グループ管理に属しないアプリケーション１１ｎであった場合には処理はステップＳ１３０１２へ進む。属しているアプリケーション１１ｎであった場合には処理はステップＳ１３００４へ進む。ステップＳ１３００４ではアンインストールされたアプリケーション１１ｎが属するグループのグループ情報がグループデータテーブル６００に存在しているかどうかをチェックする。存在していなければ処理はステップＳ１３００９へ進む。存在している場合には処理はステップＳ１３００５へ進む。ステップＳ１３００５ではさらに当該グループのグループ管理が削除されていないインストールされた状態であるかどうかをチェックする。この判定では、グループデータテーブル６００に該当するグループのエントリーがあれば、インストールされた状態であると判定できる。インストールされた状態であれば処理はステップＳ１３００６へ進む。アンインストール済状態であった場合には処理はステップＳ１３００９へ進む。ステップＳ１３００６では当該グループのグループ管理が有効な状態であるかをチェックする。グループデータテーブル６００上有効であれば処理はステップＳ１３００７へ進む。無効であれば処理はステップＳ１３００６へ進む。ステップＳ１３００６にて、当該グループのグループ管理を有効化する。有効化が完了したら処理はステップＳ１３００７へ進む。ステップＳ１３００７ではインストールされたアプリケーション１１ｎ停止中であるかどうかを確認する。もしも停止中であれば処理はステップＳ１３００８へ進む。開始済みであれば処理はステップＳ１３０１２へ進む。ステップＳ１３００８ではリソースサービス３０４はインストールされたアプリケーション１１ｎを開始して、ステップＳ１３０１２へ進む。

ステップＳ１３００４あるいはステップＳ１３００５からステップＳ１３００９へ進んだ処理はここで「グループ情報がインストールされていない」警告を出す。すなわち、インストールされたアプリケーション１１ｎに対応するグループ情報がインストールされていないというケースである。この場合は警告を出した後続くステップＳ１３０１０でインストールされたアプリケーションが開始済みであるかどうかをチェックする。開始済みであれば処理はステップＳ１３０１１へ進む。開始しておらず停止状態であれば処理はステップＳ１３０１２へ進む。ステップＳ１３０１１ではリソースサービス３０４はインストールされたアプリケーション１１ｎをアプリケーション管理フレームワーク３０２を通じて停止する。ステップＳ１３０１２にて一連の処理を完了する。

＜アプリケーションアンインストール時のリソースサービスの動作＞
図１４は本実施例においてアプリケーション１１ｎがアンインストールされた時のリソースサービス３０４の動作を模式的に表したフローチャートである。ステップＳ１４００１から処理を開始する。ステップＳ１４００２でリソースサービス３０４はアプリケーション管理フレームワーク３０２からアプリケーション１１ｎがアンインストールされたと言う通知を受け取る。そして続くステップＳ１４００３にてそのアンインストールされたアプリケーション１１ｎはグループ管理の対象であったかどうかをチェックする。そうでない場合には処理はステップＳ１４０１６へ進む。グループ管理の対象であった場合には処理はステップＳ１４００４へ進む。ステップＳ１４００４ではアンインストールされたアプリケーション１１ｎが属しているグループの情報がグループデータテーブル６００に存在していたかどうかをチェックする。存在していた場合には処理はステップＳ１４００５へ進む。していなかった場合には処理はステップＳ１４０１５へ進む。

ステップＳ１４００５ではアンインストールされたアプリケーション１１ｎが属しているグループのグループ管理がインストールされた状態であるかどうかをチェックする。アンインストール状態であれば処理はステップＳ１４０１６へ進む。そうでなければ処理はステップＳ１４００６へ進む。ステップＳ１４００６ではアンインストールされたアプリケーション１１ｎが属するグループのグループ管理が有効であるかどうかをチェックする。有効でなければ処理はステップＳ１４０１６へ進む。有効であれば処理はステップＳ１４００７へ進む。ステップＳ１４００７ではアンインストールされたアプリケーション１１ｎが取得していたリソースで解放されていないものがあるかどうかをチェックする。あれば処理はステップＳ１４００８へ進む。なければ処理はステップＳ１４０１４へ進む。ステップＳ１４００８ではアンインストールされたアプリケーション１１ｎが取得していて解放されていないリソースについて繰返し処理を行う。ステップＳ１４００９では処理対象のリソースが解放可能であるかをチェックし、解放可能であれば処理はステップＳ１４０１０へ進む。ステップＳ１４０１０では処理対象のリソースを解放する。そののち処理はステップＳ１４０１１へ進み、解放したリソースの量を全体の使用量から減算する。そののち処理はステップＳ１４０１３へ進む。ステップＳ１４０１２ではリソースサービス３０４は「リソースの解放に失敗した」という警告を出力する。そして処理はステップＳ１４０１３へ進む。ステップＳ１４０１３では処理対象のリソースについてすべて処理が終わったかを判定し終わっていなければステップＳ１４００８から繰返し処理を続行する。処理が終わっていたら処理はステップＳ１４０１４へ進む。

ステップＳ１４０１４では、アンインストールされたアプリケーション１１ｎが属していたグループについて、そのグループに属する他のアプリケーション１１ｎがインストールされた状態で存在しているかどうかを判定する。存在していれば処理はステップＳ１４０１６へ進む。存在していなければ処理はステップＳ１４０１５へ進む。ステップＳ１４０１５ではグループデータテーブル６００上で当該グループのグループ管理を無効化し、ステップＳ１４０１６へ進む。ステップＳ１４０１６へ進むと一連の処理を完了する。

ここまで見てきたように本発明の第二の実施例においては、リソースサービス３０４を用いることで、グループ管理対象のアプリケーション１１ｎを必ずグループ管理の下で動作させることができるようになる。

結果として本実施例に依れば複数のアプリケーション１１ｎを組み合わせて導入する際にグループ情報を保持するフラグメントバンドル３０５を利用することができる。これにより、管理者はアプリケーション１１ｎを本来、それぞれを単独で導入しようとするとリソースが足りないために導入できなかったところを、グループとして導入することができるようになるという効果が得られる。

また第一の実施例と比較して、グループ管理対象のアプリケーションを単独管理下で実行することがないため、処理手順が簡潔になり、また、よりリソースの効率的利用を促進できる。

［その他の実施例］
なお本発明は以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

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

Claims (12)

1. アプリケーション群に属するアプリケーションの識別子と、前記アプリケーション群に対する使用リソース宣言量とが定義された情報を取得する取得手段と、
   アプリケーションからリソース取得ＡＰＩが呼び出されたことに応じて、前記アプリケーションの識別子を基に前記アプリケーションが属するアプリケーション群を特定し、特定されたアプリケーション群に対する使用リソース宣言量を、前記情報から特定する特定手段と、
   前記アプリケーションが要求するリソース量を前記アプリケーション群が使用しているリソース量の総計に加算した結果、その値が前記特定手段により特定された使用リソース宣言量を超えてしまう場合は、前記アプリケーションにリソースオブジェクトを渡さず、そうでない場合には前記アプリケーションに前記リソースオブジェクトを渡すリソース管理手段と
   を有することを特徴とする画像形成装置。
2. 前記リソース取得ＡＰＩを呼び出したアプリケーションが、前記アプリケーション群に属しており且つ前記アプリケーション群で共有するリソースからリソースを割り当てられるグループ管理の対象となっていることを判定する判定手段を更に有し、
   前記特定手段は、前記アプリケーションが前記グループ管理の対象でない場合には、前記アプリケーションに対する使用リソース宣言量を前記情報から特定し、
   前記リソース管理手段は、前記アプリケーションが前記グループ管理の対象となっていない場合には、前記アプリケーションが要求するリソース量を前記アプリケーションが使用しているリソース量の総計に加算した結果、前記アプリケーションが前記特定手段により特定された使用リソース宣言量を超えてしまう場合は、前記アプリケーションにリソースオブジェクトを渡さず、そうでない場合には前記アプリケーションに前記リソースオブジェクトを渡すことを特徴とする請求項１に記載の画像形成装置。
3. 前記特定手段は、前記アプリケーションが前記グループ管理の対象となっている場合には、前記アプリケーション群に対する使用リソース宣言量を前記情報から特定し、
   前記リソース管理手段は、前記アプリケーションが前記グループ管理の対象である場合には、前記アプリケーションが要求するリソース量を前記アプリケーション群が使用しているリソース量の総計に加算した結果、前記アプリケーションが前記特定手段により特定された使用リソース宣言量を超えてしまう場合は、前記アプリケーションにリソースオブジェクトを渡さず、そうでない場合には前記アプリケーションに前記リソースオブジェクトを渡すことを特徴とする請求項２に記載の画像形成装置。
4. 前記アプリケーション群に属し且つ前記グループ管理の対象になっていないアプリケーションのグループ管理を開始する場合には、前記アプリケーションに対して割り当てたリソースを解放し、前記アプリケーションの属するアプリケーション群に対して該アプリケーション群の前記使用リソース宣言量のリソースを確保する手段を更に有することを特徴とする請求項２または３に記載の画像形成装置。
5. 前記グループ管理の対象になっているアプリケーションのグループ管理を停止する場合には、前記アプリケーション群に対して割り当てたリソースを解放し、前記アプリケーションに対して該アプリケーションの前記使用リソース宣言量のリソースを確保する手段を更に有することを特徴とする請求項４に記載の画像形成装置。
6. アプリケーションがインストールされた際に、該アプリケーションが前記グループ管理の対象であるか判定し、該当する場合には、前記アプリケーションに対して割り当てたリソースを解放し、前記アプリケーションの属するアプリケーション群に対して該アプリケーション群の前記使用リソース宣言量のリソースを確保する手段を更に有することを特徴とする請求項２乃至５のいずれか一項に記載の画像形成装置。
7. アプリケーションがアンインストールされた際に、該アプリケーションが前記グループ管理の対象であったか判定し、該当する場合には、さらに当該アプリケーション群に属しているアプリケーションがインストールされているか判定し、インストールされていない場合には、前記アプリケーション群に対して割り当てたリソースを解放し、前記アプリケーション群に対するグループ管理を停止することを特徴とする請求項２乃至６のいずれか一項に記載の画像形成装置。
8. 前記リソース取得ＡＰＩを呼び出したアプリケーションが、前記アプリケーション群に属しており且つ前記アプリケーション群で共有するリソースからリソースを割り当てられるグループ管理の対象となっていることを判定する判定手段を更に有し、
   前記グループ管理の対象になっているアプリケーションのグループ管理を停止する場合には、前記アプリケーションに対して割り当てたリソースを解放し、前記アプリケーションを停止させることを特徴とする請求項１に記載の画像形成装置。
9. アプリケーションがアンインストールされた際に、該アプリケーションが前記グループ管理の対象であったか判定し、該当する場合には、さらに当該アプリケーション群に属しているアプリケーションがインストールされているか判定し、インストールされていない場合には、前記アプリケーション群に対して割り当てたリソースを解放し、前記アプリケーション群に対するグループ管理を停止することを特徴とする請求項８に記載の画像形成装置。
10. 前記グループ管理は、前記アプリケーション群に属するアプリケーションの識別子と、前記アプリケーション群に対する使用リソース宣言量とが定義された前記情報を追加することにより開始され、該情報の削除により停止されることを特徴とする請求項２乃至９のいずれか一項に記載の画像形成装置。
11. アプリケーション群に属するアプリケーションの識別子と、前記アプリケーション群に対する使用リソース宣言量とが定義された情報を取得する取得工程と、
    アプリケーションからリソース取得ＡＰＩが呼び出されたことに応じて、前記アプリケーションの識別子を基に前記アプリケーションが属するアプリケーション群を特定し、特定されたアプリケーション群に対する使用リソース宣言量を、前記情報から特定する特定工程と、
    前記アプリケーションが要求するリソース量を前記アプリケーション群が使用しているリソース量の総計に加算した結果、その値が前記特定工程により特定された使用リソース宣言量を超えてしまう場合は、前記アプリケーションにリソースオブジェクトを渡さず、そうでない場合には前記アプリケーションに前記リソースオブジェクトを渡すリソース管理工程と
    を有することを特徴とするリソース管理方法。
12. 請求項１乃至１０のいずれか一項に記載の画像形成装置としてコンピュータを機能させるためのプログラム。

Images