JP2021189487A - 管理装置およびその制御方法 - Google Patents

Abstract

【課題】アプリケーションによるファイルディスクリプタの消費を低減する。【解決手段】情報処理装置上で動作する複数のアプリケーションを管理する管理装置は、アプリケーションが、単独で動作可能な独立アプリケーションであるか独立アプリケーションに紐づいてのみ動作可能な従属アプリケーションであるかを判定する判定手段と、従属アプリケーションと判定された第１アプリケーションと、独立アプリケーションと判定されかつ第１アプリケーションが紐づく第２アプリケーションと、を結合して結合アプリケーションを構成する構成手段と、を有する。【選択図】図５

Description

本発明は、アプリケーションによるファイルディスクリプタの消費を低減する技術に関するものである。

Ｊａｖａ（登録商標）の実行環境において、クラス（実行に必要なコード）のロードはクラスローダによって行われる。クラスは、ＪＡＲ（Java Archive）形式のファイル（ＪＡＲファイル）の中にあるクラスファイルで定義されている。Ｊａｖａの実行環境では、パフォーマンスを向上させるため、一度参照したＪＡＲファイルは、実行環境上で動作するプログラムが終了するまで参照され続ける。そのため、クラスローダがＪＡＲファイルを参照するために消費したファイルディスクリプタはプログラムが終了するまで消費され続けることになる。

組込機器においては、アプリケーションプログラム（以降アプリケーションと呼ぶ）の実行環境において使用可能なリソースに制限がある。例えば、リソースの１種であるファイルディスクリプタも、使用可能なファイルディスクリプタ数に制限がある。そのため、開発者はアプリケーションが使用するリソース量について予め上限値を設定することがある。これにより、アプリケーションの実行する際にアプリケーション管理フレームワークは設定された上限値に基づいて使用可能なリソース量を超えるか否かを確認することができる。また、例えば特許文献１には、リソース上限を超えると判定された場合に、アプリケーションに含まれるライブラリ（ＪＡＲファイル）を統合してからアプリケーションを実行する技術が開示されている。

特開２０１７−１５７１７５号公報

しかしながら、特許文献１に記載の技術ではアプリケーションに含まれるライブラリを統合する構成であるため、クラスを含まないアプリケーションでは効果がないという課題がある。また、インストールされるアプリケーション数が増えると、アプリケーション数分のファイルディスクリプタは必ず消費してしまうという問題がある。

本発明は、このような問題に鑑みてなされたものであり、ファイルディスクリプタの消費を低減可能とするアプリケーション管理技術を提供することを目的としている。

上述の問題点を解決するため、本発明に係る管理装置は以下の構成を備える。すなわち、情報処理装置上で動作する複数のアプリケーションを管理する管理装置は、
アプリケーションが、単独で動作可能な独立アプリケーションであるか独立アプリケーションに紐づいてのみ動作可能な従属アプリケーションであるかを判定する判定手段と、
前記判定手段により従属アプリケーションと判定された第１アプリケーションと、前記判定手段により独立アプリケーションと判定されかつ前記第１アプリケーションが紐づく第２アプリケーションと、を結合して結合アプリケーションを構成する構成手段と、
有する。

本発明によれば、ファイルディスクリプタの消費を低減可能とするアプリケーション管理技術を提供することができる。

画像形成装置のハードウェア構成を示す図である。 アプリケーションの実行に係るソフトウェアの機能構成を示す図である。 マージ処理前のアプリケーションのファイル配置の例を示す図である。 マージ処理後のアプリケーションのファイル配置の例を示す図である。 属性定義ファイルの例を示す図である。 アプリケーションをインストールする際の処理を示すフローチャートである。 アプリケーションをアンインストールする際の処理を示すフローチャートである。 ファイルのマージ処理を説明するフローチャートである。 ファイルのリストア処理を説明するフローチャートである。 アプリケーションをインストールする際の処理を示す他のフローチャートである。

以下、添付図面を参照して実施形態を詳しく説明する。なお、以下の実施形態は特許請求の範囲に係る発明を限定するものではない。実施形態には複数の特徴が記載されているが、これらの複数の特徴の全てが発明に必須のものとは限らず、また、複数の特徴は任意に組み合わせられてもよい。さらに、添付図面においては、同一若しくは同様の構成に同一の参照番号を付し、重複した説明は省略する。

（第１実施形態）
本発明に係る管理装置の第１実施形態として、仮想化された情報処理装置であるＪａｖａ（登録商標）仮想マシン（ＶＭ：Virtual Machine）を搭載した画像形成装置を例に挙げて以下に説明する。

＜装置構成＞
図１は、第１実施形態に係る画像形成装置のハードウェア構成を示す図である。画像形成装置１００は、コア部１０１、ユーザインタフェース部１０２、記憶装置１０３、ネットワークインタフェース部１０４、スキャナ部１０５、プリンタ部１０６、フィニッシャ部１０７を含む。

コア部１０１は、記憶装置１０３に格納されているファームウェアを呼び出して実行することで画像形成装置１００の基本機能を提供する。ファームウェアが提供する基本機能としては、コピー機能、送信機能、アプリケーション管理機能等が挙げられる。アプリケーション管理機能は、外部ネットワーク１０８やＵＳＢメモリ等を経由してアプリケーションを取得して画像形成装置１００内にインストールすることにより画像形成装置１００で利用可能な機能を追加する。アプリケーションは、コア部１０１で実行され、ユーザインタフェース部１０２〜フィニッシャ部１０７を制御することで様々な機能をユーザに提供する。

ユーザインタフェース部１０２は、メインメニュー画面や各種アプリケーションの設定画面を表示したり、ユーザ操作からの入力を受け付けたりする。記憶装置１０３は、ファームウェアやアプリケーションを格納するための装置である。また、記憶装置１０３は、各種アプリケーションの設定情報の格納も行う。ネットワークインタフェース部１０４は、外部ネットワーク１０８に接続するためのインタフェースである。

スキャナ部１０５は、原稿を読み取り画像データを生成するための装置である。プリンタ部１０６は、画像データに基づく画像を用紙などの記録媒体に印刷するための装置である。フィニッシャ部１０７は、出力した用紙に対して各種フィニッシング処理を行うための装置である。

図２は、アプリケーションの実行に係るソフトウェアの機能構成を示す図である。より具体的には、画像形成装置１００で動作するアプリケーション管理機能をブロック図で示したものである。画像形成装置は、情報処理装置上（ＪａｖａＶＭ上）でＪａｖａアプリケーションプログラムを実行するすることにより様々な機能を提供することが出来る。

ＪａｖａＶＭ２００は、ＪａｖａＶＭであり、Ｊａｖａプログラムを動作させるための実行モジュールである。アプリフレームワーク２０１は、アプリケーションを動作させるためのフレームワークであり、アプリ管理部２０２、マージ制御部２０３、認証制御部２０４、画面制御部２０５、デバイス制御ライブラリ２０６から構成される。

アプリ管理部２０２は、アプリケーションのインストール（追加）・アンインストール（削除）・開始・停止などのライフサイクル制御を行う。また、画像形成装置上で使用可能なファイルディスクリプタの上限（所定の上限値）を保持し、アプリケーションのファイルディスクリプタ使用数の合計が利用可能上限を超えないようにアプリケーションの起動制御を行う。マージ制御部２０３は、アプリ管理部２０２からの要求を受けてアプリケーションファイルの結合（以降マージと呼ぶ）や復元（以降リストアと呼ぶ）を行う。

認証制御部２０４は、ユーザ認証を行うための機能を備え、アプリケーションからログイン中のユーザの情報を取得する手段を提供する。画面制御部２０５は、ユーザインタフェース部１０２へのアプリケーションの表示制御を行う。初期状態ではユーザ認証画面を表示し、ユーザからの認証情報入力を受け付け、認証制御部により認証された場合にアプリケーション２０７の画面に切り替える。

デバイス制御ライブラリ２０６は、アプリフレームワーク２０１上で動作するアプリケーション２０７からユーザインタフェース部１０２〜フィニッシャ部１０７を制御するためのＡＰＩ群である。

アプリケーション２０７は、追加や削除することが可能なアプリケーションであり、デバイス制御ライブラリ２０６のＡＰＩを呼び出すことによりユーザに対してさまざまな拡張機能を提供する。アプリケーション２０７には、ホストアプリケーション２０８、フラグメントアプリケーション２０９の２種類の異なる種類のアプリケーションが存在する。

ホストアプリケーション２０８は、単独で動作可能なアプリケーション２０７である。ホストアプリケーションは独立アプリケーションとも呼ばれる。例えば、スキャンして外部サーバに送信するアプリケーションや、ユーザが投入した印刷ジョブの一覧を表示して選択されたジョブを印刷するアプリケーションなどがあげられる。

フラグメントアプリケーション２０９は、ホストアプリケーション２０８の機能を拡張するためのアプリケーションであり、単体では動作せずホストアプリケーション２０８に紐づいてのみ動作可能なアプリケーションである。フラグメントアプリケーションは従属アプリケーションとも呼ばれる。例えば、送信を行うようなホストアプリケーション２０８において、選択可能な送信先を増やしたり、ＵＩの表示言語を拡張したりする。一つのホストアプリケーション２０８に対して複数のフラグメントアプリケーション２０９を追加して機能拡張を行うことも可能である。

クラスローダ２１０は、Ｊａｖａプログラムをロードするためのモジュールであり、ブートクラスローダ２１１、システムクラスローダ２１２、アプリクラスローダ２１３の３種類が存在する。ブートクラスローダ２１１は、Ｊａｖａの標準クラスをロードするためのクラスローダである。システムクラスローダ２１２は、アプリフレームワーク２０２のＪａｖａプログラムをロードするためのクラスローダである。アプリクラスローダ２１３は、後から追加されたアプリケーション２０７のプログラムをロードするためのモジュールである。なお、アプリクラスローダ２１３はホストアプリケーション２０７毎に別々のクラスローダが割り当てられる。

なお、フラグメントアプリケーション２０９は、親となるホストアプリケーション２０８に対応したアプリクラスローダ２１３を使ってクラスロードされるため、フラグメントアプリケーション用のアプリクラスローダは用意されない。また、クラスロードの優先順位はホストアプリケーションよりもフラグメントアプリケーションが優先される。これによりフラグメントアプリケーションを追加することでホストアプリケーションの機能を差し替えたり拡張したりすることが容易になっている。

図３Ａは、後述するマージ処理前のアプリケーションのファイル配置の例を示す図である。また、図中の矢印はクラスローダがどのＪＡＲファイルを開くかを模式的に示している。図３Ａでは、３つのホストアプリケーション（ホストアプリＡ〜Ｃ）と２つのフラグメントアプリケーション（フラグメントＡ１〜Ａ２）がインストールされている構成の例を示している。

領域３０１は、ＪａｖａＶＭのシステムのファイルが保存される領域であり、ここに配置されたファイルはブートクラスローダ２１１によってロードされる。領域３０２は、アプリフレームワーク２０２の各種ＪＡＲファイルが配置される領域である。ここに配置されたファイルはシステムクラスローダ２１２からローダされる。領域３０３は、アプリケーションのファイルが格納される領域である。

アプリケーションがインストールされると、そのアプリケーション用のディレクトリが作られ、その下にファイルが配置される。また、インストールされたアプリケーションが、ホストアプリケーション２０８の場合は、新たなアプリクラスローダが割り当てられる。フラグメントアプリケーション２０９の場合は、新たなアプリクラスローダは割り当てられず、対応するホストアプリケーション２０８のクラスローダが使われる。

ブートクラスローダ２１１およびシステムクラスローダ２１２は、画像形成装置の起動時にＬｉｂ以下にあるすべてのＪＡＲファイルを開いた状態となる。アプリクラスローダ２１３は、アプリケーションを起動するタイミングでＪＡＲファイルを開く。

全てのクラスローダは一度ロード対象のＪＡＲファイルをオープンすると常にオープンするようになっており、クローズすることはない。そのため、動作させるアプリケーション数の増加に伴いファイルのオープン数も増える。例えば、ホストアプリケーションを１０種類インストールして開始した状態で、それぞれに対して言語拡張のためのフラグメントアプリケーションを３０種類ずつ存在するような場合、アプリクラスローダだけで３００ファイルを常にオープンする状態となる。

図３Ｂは、フラグメントアプリケーション２０９をホストアプリケーション２０８にマージした後の結合アプリケーションを含むファイルの配置を示す図である。図３Ｂでは、ホストアプリＡとプラグ面とＡ１とフラグメントＡ２とをマージした結合アプリケーションである「ホストアプリＡ＋フラグメント１／２．ｊａｒ」が例示されている。Ｂａｃｋｕｐ３０４は、ホストアプリケーションのマージする前のオリジナルファイルを残すためのディレクトリである（以降バックアップディレクトリと記す）。ここに保存されたファイルは、マージしたファイルをアンインストールする場合に、ＪＡＲファイルを元の状態に戻すために利用される。なお、別の結合アプリケーションである「ホストアプリＢ＋Ｃ．ｊａｒ」も例示されているが、これについては第２実施形態において説明する。

フラグメントアプリケーション（フラグメントＡ１〜Ａ２）のＪＡＲファイルはアプリケーション毎のディレクトリに残っている。ただし、アプリクラスローダ２１３がこれらのＪＡＲファイルを開くことがなくなるためファイルのオープン数（ファイルディスクリプタ使用数）が削減される。なお、ここでは説明を簡単にするためにマージする側やマージされる側のファイルをそのまま残す構成としているが、各ファイル構成情報および復元に必要な必要最低限のファイルだけを保存するようにしてもよい。

図４は、属性定義ファイルの例を示す図である。属性定義ファイルは、アプリケーションの属性情報を定義するファイルである。図４（ａ）はホストアプリケーションの属性情報の一例を、図４（ｂ）はフラグメントアプリケーションの属性情報の一例を、それぞれ示している。

Ａｐｐ−Ｉｄ４０１は、アプリケーションを一意に識別するための識別情報であり、他のアプリケーションと重複しない値が設定される。ここではＡｐｐ−Ｉｄは８桁の英数字としているが、ＵＵＩＤであってもよい。Ａｐｐ―Ａｃｔｉｖａｔｏｒ４０２はホストアプリケーションを起動する際のクラス名である。アプリ管理部２０２がアプリケーションを起動する際にここに記載されたクラスのメソッドを実行することでアプリケーションの処理を開始する。なお、この属性はホストアプリケーションのみに存在するため、この属性が存在すればホストアプリケーションであると判断できる。

Ａｐｐ−Ｖｅｎｄｏｒ４０３はアプリケーションの開発元を示す。Ａｐｐ−Ｎａｍｅ４０４はアプリケーションの名前を示す。ＭａｘｉｍｕｍＦｉｌｅｄｅｓｃｒｉｐｔｏｒＵｓａｇｅ４０５は、そのアプリケーションを利用した際に同時に使用される最大ファイルディスクリプタ数を示す。Ｌｏｃａｌｅｓ４０６は、そのアプリケーションが対応している言語を示す。

ＨｏｓｔＡｐｐ４０７は、そのフラグメントアプリケーションが紐づくホストアプリケーションのＡｐｐ−Ｉｄを示す属性である。この属性はフラグメントアプリケーションにしか存在しないためこの属性があればフラグメントアプリケーションであると判断できる。

表１は、アプリ管理部２０２が、アプリケーションを管理する際のアプリ管理テーブルの例である。

アプリ管理部２０２は、アプリケーションのインストールが行われる際に、アプリケーションに含まれる属性定義ファイルを読みだしてテーブルに情報を追加する。また、アンインストールされる際に、テーブルから情報を削除する。また、アプリケーションを開始したり停止したりＪＡＲファイルをマージしたりリストアしたりするタイミングでこのテーブル内の情報を更新する。アプリ管理テーブルの情報は不揮発メモリに保存され、デバイス再起動時にこの情報を読み込むことにより再起動前の状態に復帰する。

Ａｐｐ−Ｉｄ〜ＨｏｓｔＡｐｐまでの列はアプリケーションインストール時に属性定義ファイル（図４）を読み取って設定が行われる。ＭａｘｆｄＵｓａｇｅは、アプリ属性のＭａｘｉｍｕｍＦｉｌｅｄｅｓｃｒｉｐｔｏｒＵｓａｇｅを読み取って設定されるが、アプリケーションファイルをマージしたりリストアしたりするタイミングで値が更新される。Ｔｙｐｅは、アプリケーションの種類を示す情報である。Ａｐｐ−Ａｃｔｉｖａｔｏｒの属性があればホストアプリケーションを示す“Ｈ”が設定され、ＨｏｓｔＡｐｐの属性があればフラグメントアプリケーションを示す“Ｆ“が設定される。

Ｓｔａｔｕｓは、アプリケーションの状態を示す。アプリケーションを実行（開始）している場合は「開始」状態に、停止している場合は「停止」状態となる。なお、クラスローダがＪＡＲファイルをオープンするのはアプリケーションを開始した時であり、停止中のアプリケーションについてはファイルがオープンされない。また状態を持つのはホストアプリケーションのみであり、フラグメントアプリケーションは対応するホストアプリケーションの状態に準ずる。よって、対応するホストアプリケーションが開始状態であればフラグメントアプリケーションのＪＡＲファイルもオープンされる。また、ホストアプリケーションが停止状態であればフラグメントアプリケーションのＪＡＲファイルはオープンされない。なお、開始状態のホストアプリケーションにフラグメントアプリケーションを追加するとすぐにＪＡＲファイルが開かれファイルディスクリプタを消費することになる。

ＩｎｓｔａｌｌＰａｔｈは、そのアプリケーションをインストールしたパスを示す。ＭｅｒｇｅｄＦｌａｇは、そのアプリケーションのＪＡＲファイルが他のアプリケーションのＪＡＲファイルとマージされているか否かを示すフラグである。ＭｅｒｇｅＰａｔｈは、そのアプリケーションがマージされている場合に、どのパスのＪＡＲファイルにマージされているのかを示す情報である。もしＭｅｒｇｅＰａｔｈとＩｎｓｔａｌｌＰａｔｈが等しい場合は、他のアプリケーションのＪＡＲファイルがそのアプリケーションのＪＡＲファイルにマージされていることを意味する。

表２は、Ｓｅｎｄアプリケーションに対してマージ処理を行った後のアプリ管理テーブルの例を示す。

ここでは、２つのフラグメントアプリケーション「Ｓｅｎｄ＿ｆｒ」および「Ｓｅｎｄ＿ｊａ」をホストアプリケーション「Ｓｅｎｄ」にマージした場合の例を示している。そのため、これら３つに対するＭｅｒｇｅＦｌａｇがＴｒｕｅに設定され、ＭｅｒｇｅＰａｔｈは／Ａｐｐ／ａａａに設定される。また、Ｓｅｎｄ＿ｆｒおよびＳｅｎｄ＿ｊａはマージされることで元のＪＡＲファイルは開かれなくなりファイルディスクリプタが消費されなくなるため、ＭａｘＦｄＵｓａｇｅの値が−１されて「０」になる。

＜装置の動作＞
図５は、アプリケーションをインストールする際の処理を示すフローチャートである。当該処理は、アプリ管理部２０２が、アプリケーションのインストール要求を受信することにより実行開始される。

ステップＳ５０１では、アプリ管理部２０２は、アプリケーションのインストール要求を受けると、要求されたアプリケーションをインストールする。ステップＳ５０２では、アプリ管理部２０２は、アプリケーションの使用リソース（ここでは使用ファイルディスクリプタ数）の合計が、画像形成装置の使用可能ファイルディスクリプタ数の上限（所定の上限値）を超えているかをリソース判定する。上限を超えていないと判定した場合は処理を終了し、上限を超えていると判定した場合はＳ５０３に進む。

ステップＳ５０３では、アプリ管理部２０２は、インストールしたアプリケーションの種類を判定する。具体的にはアプリ管理テーブルのＴｙｐｅの情報を参照して判定する。フラグメントアプリケーションであると判定した場合はＳ５０４に進み、ホストアプリケーションであると判定した場合はＳ５０７に進む。

ステップＳ５０４では、アプリ管理部２０２は、インストールしたフラグメントアプリケーションをマージした場合のアプリケーション（つまり結合アプリケーション）の使用ファイルディスクリプタ数の合計を算出する。そして、合計が、画像形成装置で利用可能なファイルディスクリプタ数の上限を超えているかを判定する。上限を超えていないと判定した場合はＳ５０５に進み、上限を超えていると判定した場合はＳ５０６に進む。

ステップＳ５０５では、アプリ管理部２０２は、インストールしたフラグメントアプリケーションをホストアプリケーションにマージして処理を終了する。マージ処理の詳細は図７を参照して後述する。

ステップＳ５０６では、アプリ管理部２０２は、対象のアプリケーションの識別情報をマージ対象リストに追加する。ここではフラグメントアプリケーションとホストアプリケーションの識別子の組を追加する。なお、マージ対象リストはどのアプリケーションをどのアプリケーションにマージするかの情報を保持するためのリストである。

ステップＳ５０７では、アプリ管理部２０２は、Ｓ５０５でマージしたフラグメントアプリケーション以外の、インストールされている未マージ状態のフラグメントアプリケーションが存在するかを判定する。未マージ状態のフラグメントがあると判定した場合はＳ５０８に進み、未マージ状態のフラグメントアプリケーションがないと判定した場合はＳ５１１に進む。

ステップＳ５０８では、アプリ管理部２０２は、Ｓ５０７での判定時に特定したフラグメントアプリケーション情報をマージ対象リストに追加する。ステップＳ５０９では、アプリ管理部２０２は、マージ対象リストに存在するアプリケーションをマージした場合のファイルディスクリプタ使用数の合計を算出する。そして、合計が、画像形成装置で利用可能なファイルディスクリプタ数の上限を超えているかを判定する。上限を超えていると判定した場合はＳ５０７に進み、上限を超えていないと判定した場合はＳ５１０に進む。

ステップＳ５１０では、アプリ管理部２０２は、マージ対象リストに記載されたアプリケーションの識別情報をもとにマージ処理を行い、処理を終了する。一方、ステップＳ５１１では、アプリ管理部２０２は、Ｓ５０１でインストールしたアプリケーションをアンインストールしてインストールエラーを返し、処理を終了する。

図６は、アプリケーションをアンインストールする際の処理を示すフローチャートである。当該処理は、アプリ管理部２０２が、アプリケーションのアンインストール要求を受信することにより実行開始される。

ステップＳ６０１では、アプリ管理部２０２は、アンインストール対象のアプリケーションの種別を判定する。ホストアプリケーションであると判定した場合はＳ６０２に進み、フラグメントアプリケーションであると判定した場合はＳ６０７に進む。

ステップＳ６０２では、アプリ管理部２０２は、アンインストール対象のホストアプリケーションに対応するフラグメントアプリケーションが存在するか否かを判定する。フラグメントアプリケーションが存在すると判定した場合はＳ６０３に進み、存在しないと判定した場合はＳ６０４に進む。

ステップＳ６０３では、アプリ管理部２０２は、アンインストールエラーを返し処理を終了する。なお、ここではフラグメントアプリケーションが存在する場合は事前にフラグメントアプリケーションをアンインストールしておかないとホストアプリケーションをアンインストールできない仕様を想定している。

ステップＳ６０４では、アプリ管理部２０２は、アンインストール対象のアプリケーションがマージ済みであるかどうかをアプリ管理テーブルのＭｅｒｇｅＦｌａｇを参照して判定（結合判定）する。もしマージ済みであると判定した場合はステップＳ６０５に進み、マージ済みでないと判定した場合はステップＳ６０６に進む。ステップＳ６０５では、アプリ管理部２０２は、アンインストール対象のホストアプリケーションのリストア処理を行う。リストア処理の詳細は図８を参照して後述する。ステップＳ６０６では、アプリ管理部２０２は、要求されたホストアプリケーションをアンインストールして処理を終了する。

ステップＳ６０７では、アプリ管理部２０２は、アンインストール対象のフラグメントアプリケーションがホストアプリケーションにマージ済みであるかを判定する。もしマージ済みであると判定した場合はＳ６０８に進み、マージ済みでないと判定した場合はＳ６０９に進む。ステップＳ６０８では、アプリ管理部２０２は、フラグメントアプリケーションのリストア処理を行う。ステップＳ６０９では、アプリ管理部２０２は、フラグメントアプリケーションをアンインストールして処理を終了する。

図７は、ファイルのマージ処理（Ｓ５０５、Ｓ５１０）を説明するフローチャートである。なお、マージ処理の呼び出し元からはマージ対象のアプリケーションの識別情報が渡されてくるものとする。ここではマージ元のフラグメントアプリケーションを「アプリケーションＡ」、マージ先のホストアプリケーションを「アプリケーションＢ」と呼ぶ。

ステップＳ７０１では、マージ制御部２０３は、アプリ管理部２０２からマージ処理要求を受けると、アプリケーションＢのオリジナルのＪＡＲファイルが退避済みかを判断する。具体的には、アプリケーションＢのインストールパスの下のバックアップディレクトリにＪＡＲファイルが存在していれば退避済みであると判定する。Ｓ７０１において退避済みでないと判定した場合はＳ７０２に進み、退避済みであると判定した場合はＳ７０３に進む。

ステップＳ７０２では、マージ制御部２０３は、アプリケーションＢのＪＡＲファイルをバックアップディレクトリにコピーしてステップＳ７０３に進む。

ステップＳ７０３では、マージ制御部２０３は、アプリケーションＡのＪＡＲファイルに含まれるファイルをアプリケーションＢのＪＡＲファイルに追加する。この際、アプリケーションＡの属性定義ファイル以外のファイルを追加する。もしファイルの重複があった場合は、フラグメントアプリケーションのファイルが使われるようにするため、アプリケーションＢのファイルをアプリケーションＡのファイルに上書きする。

ステップＳ７０４では、マージ制御部２０３は、管理テーブルの内容を更新する。具体的には、アプリケーションＡの情報に関して、ＭｅｒｇｅＦｌａｇを「Ｔｒｕｅ」に設定し、ＭａｘＦｄＵｓａｇｅの値を−１した値に設定する。また、ＭｅｒｇｅＰａｔｈにアプリケーションＢのインストールパスを設定する。さらに、アプリケーションＢの情報に関して、ＭｅｒｇｅＦｌａｇを「Ｔｒｕｅ」に設定し、ＭｅｒｇｅＰａｔｈにアプリケーションＢのインストールパスを設定する。

図８は、ファイルのリストア処理（Ｓ６０５、Ｓ６０８）を説明するフローチャートである。なお、リストア処理の呼び出し元からはリストア対象のアプリケーションの識別情報が渡されてくるものとする。ここではリストア対象のアプリケーションを「アプリケーションＡ」と呼ぶ。

ステップＳ８０１では、マージ制御部２０３は、リストア処理の要求を受けると、アプリケーションＡのＪＡＲファイルのマージ先を特定する。具体的にはアプリ管理テーブルのＭｅｒｇｅＰａｔｈの情報を参照して特定する。ここでは仮にアプリケーションＢにマージされていたものとする。

ステップＳ８０２では、マージ制御部２０３は、アプリケーションＢのＪＡＲファイルを退避ファイルから復元する。

ステップＳ８０３では、マージ制御部２０３は、管理テーブルを更新する。具体的には、アプリケーションＡのＭｅｒｇｅＦｌａｇを「Ｆａｌｓｅ」に設定し、ＭａｘＦｄＵｓａｇｅを＋１した値に設定する。また、ＭｅｒｇｅＰａｔｈの情報を削除する。また、アプリケーションＢのＭｅｒｇｅＦｌａｇを「Ｆａｌｓｅ」に設定し、ＭｅｒｇｅＰａｔｈの情報を削除する。

ステップＳ８０４では、マージ制御部２０３は、他にアプリケーションＢにマージしていたアプリケーションを特定する。具体的には、アプリ管理テーブルのＭｅｒｇｅＰａｔｈにアプリケーションＢのパスが設定されているアプリケーションを特定することで特定を行う。

ステップＳ８０５では、マージ制御部２０３は、Ｓ８０４で特定した情報をもとに他にアプリケーションＢにマージしていたアプリケーションが存在するかを判定する。存在すると判定した場合はＳ８０６に進み、存在しないと判定した場合は処理を終了する。

ステップＳ８０６では、マージ制御部２０３は、Ｓ８０４で特定した全てのアプリケーションについてアプリケーションＢへのマージ処理を行う。マージ処理の詳細は図７を参照して説明した通りである。

以上説明したとおり第１実施形態によれば、フラグメントアプリケーションのＪＡＲフィルをホストアプリケーションのＪＡＲファイルに結合（マージ）する。これにより、ホストアプリケーションを開始する際にクラスローダが開くファイル数を削減することが出来る。

すなわち、ファイルディスクリプタの使用量を抑えることができるようになるため、従来よりも多くのアプリケーションをインストールして利用することが可能になる。たとえば、対応言語追加用のフラグメントアプリケーションが大量に追加された場合においても開くＪＡＲファイルを増加することがなくなる。そのため、他のアプリケーションをより多くインストールして利用可能になりユーザの利便性が向上する。

（第２実施形態）
上述の第１実施形態ではフラグメントアプリケーションをホストアプリケーションにマージする形態であるため、フラグメントアプリケーションが存在しない場合にはファイルディスクリプタを削減することが出来ない。そこで、第２実施形態では、ホストアプリケーション同士であってもマージする形態について説明する。なお、装置の構成（図１〜図４については第１実施形態と同様であるため説明を省略する。また、アプリケーションをインストールする際の処理（図５）以外の処理（図６〜図８）についても第１実施形態と同様であるため説明を省略する。

図９は、アプリケーションをインストールする際の処理を示すフローチャートである。当該処理は、アプリケーションのインストール要求を受信すると実行される。なお、Ｓ９０１〜Ｓ９１０の処理は第１実施形態（図５）のＳ５０１〜Ｓ５１０と同様であるため説明を省略する。

ステップＳ９１１では、アプリ管理部２０２は、未マージのホストアプリケーションのうち重複ファイルがないアプリケーションの組が存在するかを判定する。ここで重複ファイルのチェックは、属性定義ファイル以外の構成ファイルに重複がないことを確認することにより行う。構成ファイルに重複のないアプリケーションが存在すると判定した場合はＳ９１２に進み、存在しないと判定した場合はＳ９１６に進む。

なお、ＪＡＲファイルの仕様として属性定義ファイルの名前は固定で必ず重複するためこのファイルはチェックから除外する。また、同名で異なるクラスファイルやリソースファイルが存在した状態でマージすると、一方のアプリケーションが想定した処理を行えなくなる。あるいは、中身が同じクラスだとしてもスタティック変数の競合が発生するなどして正常動作しなくなる場合がある。そのため、属性定義ファイル以外に重複がないホストストアプリケーションだけをマージ対象にしている。

ステップＳ９１２では、アプリ管理部２０２は、Ｓ９１１の判定時に特定したホストアプリケーションの製造元（ベンダ）が同一であるかを判定する。同一ベンダでないと判定した場合はＳ９１１に進み、同一ベンダであると判定した場合はＳ９１３に進む。

ホストアプリケーションのＪＡＲファイルをマージするとクラスローダも共通になるため各ホストアプリケーションが保持しているデータに相互にアクセスできるようになってしまう。そのため、セキュリティ上の問題が発生し得る異なるベンダのアプリケーションのマージは行わないようにしている。

ステップＳ９１３では、アプリ管理部２０２は、Ｓ９１１での判定時に特定したアプリケーションの組をマージ対象リストに追加する。

ステップＳ９１４では、アプリ管理部２０２は、マージ対象リストに存在するアプリケーションをマージした際のファイルディスクリプタ使用数を算出する。そして、ファイルディスクリプタ使用数が、画像形成装置で利用可能なファイルディスクリプタ数の上限を超えているか否かを判定する。上限を超えていると判定した場合はＳ９１１に進み、上限を超えていないと判定した場合はＳ９１５に進む。

ステップＳ９１５では、アプリ管理部２０２は、マージ対象リストに記載されたアプリケーションの識別情報をもとにリストに記載されているすべてのアプリケーションの組に対してマージ処理を行い、処理を終了する。一方、ステップＳ９１６では、アプリ管理部２０２は、Ｓ９０１でインストールしたアプリケーションをアンインストールしてインストールエラーを返し、処理を終了する。

以上説明したとおり第２実施形態によれば、構成ファイルに重複がなくかつ製造元（ベンダ）が同一である場合にはホストアプリケーション同士であってもマージ処理を行う。これにより、第１実施形態に比較し、より多くのファイルディスクリプタを削減できるようになり、より多くのアプリケーションを利用することが可能になる。

（変形例）
上述の実施形態においては、アプリケーションをインストールするタイミングで、アプリケーションのマージ処理を行うよう説明した。しかしながら、マージ処理のタイミングはインストール時に限られるものではなく、ホストアプリケーションの開始指示を受けたタイミングで実施するようにしてもよい。また、アプリケーションをアンインストールするタイミングで、リストア処理を行うよう説明した。しかしながら、リストア処理のタイミングはアンインストール時に限られるものではなく、ホストアプリケーションの停止指示を受けたタイミングで実施するようにしてもよい。

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

発明は上記実施形態に制限されるものではなく、発明の精神及び範囲から離脱することなく、様々な変更及び変形が可能である。従って、発明の範囲を公にするために請求項を添付する。

２０１ アプリフレームワーク； ２０２ アプリ管理部； ２０３ マージ制御部； ２０８ ホストアプリケーション； ２０９ フラグメントアプリケーション； ２１３ アプリクラスローダ

Claims (12)

1. 情報処理装置上で動作する複数のアプリケーションを管理する管理装置であって、
   アプリケーションが、単独で動作可能な独立アプリケーションであるか独立アプリケーションに紐づいてのみ動作可能な従属アプリケーションであるかを判定する判定手段と、
   前記判定手段により従属アプリケーションと判定された第１アプリケーションと、前記判定手段により独立アプリケーションと判定されかつ前記第１アプリケーションが紐づく第２アプリケーションと、を結合して結合アプリケーションを構成する構成手段と、
   を有することを特徴とする管理装置。
2. 前記第１アプリケーションと前記第２アプリケーションとにより使用されるリソースの合計が所定の上限値を超えているか否かを判定するリソース判定手段をさらに有し、
   前記構成手段は、前記リソース判定手段により前記合計が前記所定の上限値を超えていると判定された場合に前記結合アプリケーションを構成する
   ことを特徴とする請求項１に記載の管理装置。
3. 前記第２アプリケーションに紐づく前記第１アプリケーション以外の従属アプリケーションである第３アプリケーションを特定する特定手段をさらに有し、
   前記構成手段は、前記第１アプリケーションと前記第２アプリケーションと前記第３アプリケーションとを結合して第２の結合アプリケーションを構成する
   ことを特徴とする請求項２に記載の管理装置。
4. 前記リソース判定手段は、前記構成手段が前記結合アプリケーションを構成した後、前記結合アプリケーションと前記第３アプリケーションとにより使用されるリソースの第２の合計が前記所定の上限値を超えているか否かを更に判定し、
   前記構成手段は、前記リソース判定手段により前記第２の合計が前記所定の上限値を超えていると判定された場合に前記第２の結合アプリケーションを構成する
   ことを特徴とする請求項３に記載の管理装置。
5. 前記リソースは、ファイルディスクリプタであり、
   前記所定の上限値は、前記情報処理装置で使用可能なファイルディスクリプタの上限値である
   ことを特徴とする請求項２乃至４の何れか１項に記載の管理装置。
6. 前記構成手段が前記結合アプリケーションを構成する場合に、前記第２アプリケーションに含まれるファイルのバックアップを保存する保存手段をさらに有する
   ことを特徴とする請求項１乃至５の何れか１項に記載の管理装置。
7. アプリケーションが、前記結合アプリケーションであるか否かを判定する結合判定手段と、
   アプリケーションを削除する削除手段と、
   をさらに有し、
   前記削除手段は、前記結合判定手段により前記結合アプリケーションであると判定されたアプリケーションを削除する場合、前記保存手段により保存されたバックアップを利用して前記第２アプリケーションを復元する
   ことを特徴とする請求項６に記載の管理装置。
8. アプリケーションをインストールするインストール手段をさらに有し、
   前記構成手段は、前記インストール手段が前記第１アプリケーションと前記第２アプリケーションとをインストールするタイミングで前記結合アプリケーションを構成し、前記インストール手段は、前記結合アプリケーションをインストールする
   ことを特徴とする請求項１乃至７の何れか１項に記載の管理装置。
9. 前記複数のアプリケーションの各々は属性定義ファイルを含み、
   前記インストール手段は、インストール対象のアプリケーションの属性定義ファイルに基づいて管理テーブルを生成する
   ことを特徴とする請求項８に記載の管理装置。
10. 前記構成手段は、第１の独立アプリケーションと第２の独立アプリケーションとに関して含まれるファイルに重複がなくかつ製造元が同一である場合、前記第１の独立アプリケーションと前記第２の独立アプリケーションとを結合して結合アプリケーションを構成する
    ことを特徴とする請求項１乃至９の何れか１項に記載の管理装置。
11. 情報処理装置上で動作する複数のアプリケーションを管理する管理装置の制御方法であって、
    アプリケーションが、単独で動作可能な独立アプリケーションであるか独立アプリケーションに紐づいてのみ動作可能な従属アプリケーションであるかを判定する判定工程と、
    前記判定工程により従属アプリケーションと判定された第１アプリケーションと、前記判定工程により独立アプリケーションと判定されかつ前記第１アプリケーションが紐づく第２アプリケーションと、を結合して結合アプリケーションを構成する構成工程と、
    を含むことを特徴とする制御方法。
12. 請求項１１に記載の制御方法をコンピュータに実行させるためのプログラム。

Images