JP2007226790A - コンテインメントフレームワーク環境で資源を管理する装置および方法 - Google Patents

Abstract

【課題】 コンテインメントフレームワーク環境で資源を管理する装置および方法に関し、ライフサイクルを有する複数のアプリケーションを含むコンテインメントフレームワーク環境で各アプリケーションのための資源の割当および解除を管理するコンテインメントフレームワーク環境で資源を管理する装置および方法を提供する。
【解決手段】 コンテインメントフレームワーク環境で資源を管理する装置は、所定の資源が割当てられたアプリケーションの固有識別子を生成する識別子生成部と、前記資源と前記固有識別子との間の連結を締結または解除するアプリケーション管理部と、前記連結が締結された場合は前記資源使用に対するカウンタを増加させ、前記連結が解除された場合は前記資源使用に対するカウンタを減少させる資源管理部と、前記カウンタが０である場合は前記資源の解除を行う資源解除部とを含む。
【選択図】図４

Description

本発明は、コンテインメントフレームワーク環境で資源を管理する装置および方法に関し、より詳しくは、ライフサイクルを有する複数のアプリケーションを含むコンテインメントフレームワーク環境で各アプリケーションのための資源の割当および解除を管理するコンテインメントフレームワーク環境で資源を管理する装置および方法に関するものである。

ジャバは、作成されたコードをプラットフォーム独立で行うオブジェクト指向のプログラミング言語である。ここで、プラットフォームは、プログラムが実行されるハードウェアまたは運営体系のようなソフトウェア環境をいう。ジャバで作成されたコードは、ジャバコンパイラによってジャババイトコードにコンパイルされ、ジャババイトコードは多様なハードウェア基盤のプラットフォームにポーティングされたジャバ仮想マシーンにより実行される。

図１は、従来のコンテインメントフレームワークの構造を示すブロック図であって、コンテインメントフレームワーク（Ｃｏｎｔａｉｎｍｅｎｔ Ｆｒａｍｅｗｏｒｋ）１０は、アプリケーション管理者１１、アプリケーション１２ａ，１２ｂ，１２ｃ、ミドルウェア１３、ジャバ仮想マシーン１４、および運営体系１５を含んで構成される。

ここで、アプリケーションは、ジャバアプリケーション１２ａ，１２ｂおよびネイティブアプリケーション１２ｃを含む。

アプリケーション管理者１１は、アプリケーションの状態を切替えることによってアプリケーションのライフサイクルを管理する。例えば、ＯＣＡＰ（Ｏｐｅｎ Ｃａｂｌｅ Ａｐｐｌｉｃａｔｉｏｎ Ｐｌａｔｆｏｒｍ）、ＡＣＡＰ（Ａｄｖａｎｃｅｄ ｏｐｅｎ Ｃａｂｌｅ Ａｐｐｌｉｃａｔｉｏｎ Ｐｌａｔｆｏｒｍ）などのミドルウェア１３を介して、アプリケーション管理者１１はアプリケーションの動作を管理する。

ジャバ仮想マシーン１４は、アプリケーションに含まれたクラスをメモリに搭載し、クラスの実行コードを運営体系１５の命令コードに切替え、アプリケーションに割当てられた資源を管理する。

資源管理のために、ジャバ仮想マシーン１４はガーベッジコレクタを備えるが、ガーベッジコレクタはガーベッジオブジェクト（資源を用いないオブジェクト）を捜し出して、ガーベッジオブジェクトが用いたヒープ資源を運営体系に返還することによって、該当ヒープ資源が他のアプリケーションによって再使用できるようにする。

換言すれば、ジャバプラットフォームにおける資源管理は、ガーベッジコレクタによって行われるものであって、ガーベッジコレクタはオブジェクトが参照されるか否かによって、該当オブジェクトの資源割当または資源解除を管理する。ところで、コンテインメントフレームワークのようにライフサイクルを有するフレームワークで複数のアプリケーションが行われる場合、アプリケーション上で資源解除のための作業が正しく行わなければ、アプリケーションが終了した状態であってもガーベッジコレクタはオブジェクトが実際に有効な状態であるかを確認することができないため、適切な資源解除を行うことができないこともある。

このため、ガーベッジコレクタによる資源解除に関する研究が進められているが、たいてい特定のフレームワークを基盤にする資源管理方法を提示し、一般的なコンテインメントフレームワークでアプリケーション終了時に行われる資源管理方法を提示してはいない。

特許文献２は、ガーベッジコレクションのようなＡＰＩ ｃａｌｌの発生の際、どの仮想アドレスが修正されたのかチェックし、ガーベッジコレクションと別途にメモリを管理するメモリマネージャを備えたガーベッジコレクションにおける効率的なＷｒｉｔｅ−Ｗａｔｃｈメカニズムを開示している。

しかし、これはメモリ資源のような一般的なフレームワーク上での資源解除に対する方法のみを開示し、ライフサイクルを有するコンテインメントフレームワークでの資源解除方法に対しては言及していない。

したがって、複数のアプリケーションがライフサイクルをもって動作するコンテインメントフレームワーク環境で終了するアプリケーションの資源を効率的に解除することができる方法の登場が求められる。
韓国特許公開第１０−２００５−００６６２７７号公報 米国特許第６７３８８７５号公報

本発明は、ライフサイクルを有する複数のアプリケーションを含むコンテインメントフレームワーク環境で各アプリケーションのための資源の割当および解除に関する情報を用いて全体フレームワークでの資源を管理することにその目的がある。

本発明の目的は、以上で言及した目的に制限されず、言及していないまた他の目的は下記記載によって当業者が明確に理解できるものである。

前記目的を達成するために、本発明の一態様に係わるコンテインメントフレームワーク環境で資源を管理する装置は、所定の資源が割当てられたアプリケーションの固有識別子を生成する識別子生成部と、前記資源と前記固有識別子との間の連結を締結または解除するアプリケーション管理部と、前記連結が締結された場合は前記資源使用に対するカウンタを増加させ、前記連結が解除された場合は前記資源使用に対するカウンタを減少させる資源管理部と、前記カウンタが０である場合は前記資源の解除を行う資源解除部とを含む。

本発明の他の態様に係わるコンテインメントフレームワーク環境で資源を管理する方法は、（ａ）所定の資源が割当てられたアプリケーションの固有識別子を生成するステップと、（ｂ）前記資源と前記固有識別子との間の連結を締結または解除するステップと、（ｃ）前記連結が締結された場合は前記資源使用に対するカウンタを増加させ、前記連結が解除された場合は前記資源使用に対するカウンタを減少させるステップと、（ｄ）前記カウンタが０である場合は前記資源の解除を行うステップとを含む。

コンテインメントフレームワーク環境で資源を管理する装置および方法によれば、ライフサイクルを有する複数のアプリケーションを含むコンテインメントフレームワーク環境で、各アプリケーションのための資源の割当および解除に関する情報を用いて全体フレームワークでの資源を管理することによって、資源の不要な使用を防止することができる長所がある。

その他、実施形態の具体的な事項は詳細な説明および図面に含まれている。

本発明の利点および特徴、そしてそれらを達成する方法は、添付する図面と共に詳細に後述する実施形態を参照すれば明確になる。しかし、本発明は以下にて開示する実施形態に限定されず、互いに異なる多様な形態によって実施され、単に本実施形態は本発明の開示が完全なものとなるようにし、本発明が属する技術分野で通常の知識を有する者に発明の範疇を完全に知らせるために提供されるものであって、本発明は請求項の範疇によってのみ定義されるものである。明細書の全体に亘り、同一参照符号は同一構成要素を示す。

以下、添付した図面を参照して、本発明の好ましい実施形態を詳細に説明する。

図２は、本発明の実施形態に係わるアプリケーションによって資源が用いられることを示す概念図である。

コンテインメントフレームワーク環境で資源を管理する装置（以下、資源管理装置という）は少なくとも１つ以上のアプリケーション２１１，２１２を用いて資源を用いることができる。ここで、アプリケーション２１１，２１２は、ライフサイクルを有するコンテインメントフレームワーク環境でのジャバアプリケーションであり得るが、例えば、エクスレット（Ｘｌｅｔ）、ミドレット（Ｍｉｄｄｌｅｌｅｔ）、またはアプレット（Ａｐｐｌｅｔ）であり得る。

そして、アプリケーション２１１，２１２によって用いられる資源は、メモリ資源２５１、ファイル資源２５２、およびネットワーク資源２５３のうち、少なくとも１つであり得る。

図２は、第１のアプリケーション２１１が２つのメモリ資源２５１および１つのネットワーク資源２５３を用い、第２のアプリケーション２１２が１つのメモリ資源２５１、２つのファイル資源２５２、および１つのネットワーク資源２５３を用いていることを示す。

すなわち、各々のアプリケーション２１１，２１２は、互いに異なる複数の資源を同時に用いることができ、同一の資源を複数用いることができる。また、１つのアプリケーションによって使用中である資源をまた他のアプリケーションが用いることもできる。

アプリケーションは随時発生して消滅することができるが、特定のアプリケーションによって占有された資源が該当アプリケーションの消滅により解除されなければ、以後に発生したアプリケーションはその資源を用いることができない場合もある。これに伴い、本発明の資源管理装置は、各アプリケーションに割当てられた資源に対する使用および解除要否に対する情報を維持して、特定のアプリケーションが消滅する場合は該当アプリケーションに割当てられたすべての資源を解除する。すなわち、アプリケーションと資源との間の連結関係を切ることによって、以後に発生したアプリケーションが該当資源を用いることができるようにすることである。例えば、資源管理装置がジャバ環境で動作する場合、資源管理装置は修正されたジャバ仮想マシーンを用いてガーベッジコレクタを強制に行うことによって、互いに異なるジャバオブジェクトを回収して資源を再使用することができる。

例えば、図２で第１のアプリケーション２１１が終了する場合、第１のアプリケーション２１１と第１のアプリケーション２１１に割当てられた２つのメモリ資源２５１および１つのネットワーク資源２５３との間の連結関係を切断し、資源の使用権限を運営体系に返還することによって、資源管理装置は第１のアプリケーション２１１に割当てられた資源の解除を行う。

特定の資源を用いるアプリケーションが終了した以後は、そのアプリケーションによって該当資源が用いられる場合にも資源管理装置による資源解除は行うことができる。

図３は、本発明の実施形態に係わるコンテインメントフレームワークの構造を示すブロック図であって、コンテインメントフレームワーク３００は、アプリケーション管理者３１１、アプリケーション３１２ａ，３１２ｂ，３１２ｃ、ミドルウェア３２０、資源管理インターフェース３３０、ジャバ仮想マシーン３４０、および運営体系３５０を含んで構成される。

ここで、アプリケーションは、ジャバアプリケーション３１２ａ，３１２ｂ、およびネイティブアプリケーション３１２ｃを含む。

アプリケーション管理者３１１は、アプリケーションの状態を切替えることによってアプリケーションのライフサイクルを管理する。ここで、アプリケーション管理者３１１は、ＯＣＡＰ（Ｏｐｅｎ Ｃａｂｌｅ Ａｐｐｌｉｃａｔｉｏｎ Ｐｌａｔｆｏｒｍ）、ＡＣＡＰ（Ａｄｖａｎｃｅｄ ｏｐｅｎ Ｃａｂｌｅ Ａｐｐｌｉｃａｔｉｏｎ Ｐｌａｔｆｏｒｍ）などのミドルウェア３２０を介してアプリケーションの動作を管理することができる。

ジャバ仮想マシーン３４０は、アプリケーションに含まれたクラスをメモリに搭載してクラスの実行コードを運営体系３５０の命令コードに切替えてアプリケーションに割当てられた資源を管理する。

この時、資源管理インターフェース３３０が修正されたジャバ仮想マシーン３４０を用いて資源を管理することができる。すなわち、ライフサイクルを有するコンテインメントフレームワーク３００上での資源割当および解除などを管理するものであって、アプリケーションが終了する場合、アプリケーションに割当てられた資源を強制的に解除する役割を行う。資源管理インターフェース３３０に対する詳しい説明は図４を介して後述する。

図４は、本発明の実施形態に係わるコンテインメントフレームワーク環境で資源を管理する装置を示すブロック図であって、資源管理装置４００は、アプリケーション管理部４１０、識別子生成部４２０、格納部４３０、資源制御部４４０、資源管理部４５０、および資源解除部４６０を含んで構成される。

識別子生成部４２０は、所定の資源が割当てられたアプリケーションの固有識別子（以下、アプリケーション識別子という）を生成する。ここで、資源はメモリ資源、ファイル資源、およびネットワーク資源のうち、少なくとも１つを含むことができる。すなわち、アプリケーションは、メモリ資源、ファイル資源、およびネットワーク資源のうち、少なくとも１つを用いることができるものであって、各々の資源を複数用いることもできる。ここで、アプリケーションはエクスレット、ミドレット、またはアプレットのように所定のライフサイクルを有するコンテインメントフレームワーク環境でのジャバアプリケーションであり得る。

そして、識別子生成部４２０は、アプリケーションのスレッド識別子を用いてアプリケーション識別子を生成することができ、アプリケーションの登録順序を用いてアプリケーション識別子を生成することもできる。

アプリケーション管理部４１０は、資源とアプリケーション識別子との間の連結を管理する。すなわち、アプリケーションによって特定の資源が用いられる場合、アプリケーション識別子と資源との間の連結を締結し、特定の資源の使用が完了する場合、アプリケーション識別子と資源との間の連結を解除する。

また、アプリケーション管理部４１０は、アプリケーションの初期化および状態切替えを行うこともできるが、初期化されたアプリケーションをメモリに搭載し、搭載されたアプリケーションが一時停止すればこれを実行させ、実行されたアプリケーションを消滅させる。ここで、アプリケーション管理者は、実行されたアプリケーションの状態を一時停止状態に切替えることもできる。

資源管理部４５０は、アプリケーション管理部４１０による連結が締結された場合は資源使用に対するカウンタを増加させ、連結が解除された場合は資源使用に対するカウンタを減少させる役割をする。前述した通り、資源管理装置４００によって用いられる資源は、メモリ資源、ファイル資源、およびネットワーク資源を含むが、これに伴って資源管理部４５０は、メモリ資源管理部、ファイル資源管理部、およびネットワーク資源管理部を含むことができる。すなわち、資源管理部４５０は、アプリケーション別資源管理だけでなく、資源の種類による管理を行う。

ここで、資源管理部４５０は、１つのアプリケーションに割当てられたすべての資源に対するカウンタの増加または減少を行う。例えば、特定のアプリケーションに１つのメモリ資源と３つのファイル資源が割当てられている場合、資源管理部４５０は資源の種類に関わらず、該当アプリケーションに割当てられた４つの資源に対するカウンタの増加または減少を行う。

一方、資源管理装置４００で実行されるアプリケーションは複数であることができるが、これに伴い、資源管理部４５０はアプリケーションが複数である場合、各々のアプリケーションに割当てられた資源に対するカウンタの増加または減少を行う。例えば、第１のアプリケーションおよび第２のアプリケーションがアプリケーション管理部４１０によってメモリに搭載されて実行される場合、資源管理部４５０は第１のアプリケーションに割当てられた資源に対するカウンタと第２のアプリケーションに割当てられた資源に対するカウンタとを別途に管理する。

アプリケーションによる資源の割当および解除はリアルタイムで行われるが、これに伴い、資源管理部４５０はリアルタイムで資源に対するカウンタを管理することができる。

格納部４３０は、アプリケーション識別子と資源が対応して作成されたテーブル（以下、資源テーブルという）を格納する役割をする。資源テーブルに含まれた内容は資源の割当および解除によって更新することができる。

格納部４３０は、ハードディスク、フラッシュメモリ、ＣＦカード（Ｃｏｍｐａｃｔ Ｆｌａｓｈ Ｃａｒｄ）、ＳＤカード（Ｓｅｃｕｒｅ Ｄｉｇｉｔａｌ Ｃａｒｄ）、ＳＭカード（Ｓｍａｒｔ Ｍｅｄｉａ(登録商標)Ｃａｒｄ）、ＭＭＣカード（Ｍｕｌｔｉｍｅｄｉａ Ｃａｒｄ）、またはメモリスティック（Ｍｅｍｏｒｙ Ｓｔｉｃｋ）など、情報の入出力が可能なモジュールであって、資源管理装置４００の内部に備えられていることもでき、別途の装置に備えられていることもできる。

資源制御部４４０は、資源テーブルの作成および更新を行う。すなわち、アプリケーション管理部４１０によってアプリケーションが初期化されれば、アプリケーションに割当てられた資源を確認して、アプリケーション識別子と共に割当てられた資源の種類を資源テーブルに含ませる。

また、資源制御部４４０は、識別子生成部４２０、アプリケーション管理部４１０、格納部４３０、資源管理部４５０、資源解除部４６０、および資源管理装置４００の全般的な制御を行う。

資源解除部４６０は、資源管理部４５０によって管理された資源使用に対するカウンタが０である場合に該当資源の解除を行う。すなわち、アプリケーションによる資源の占有を解除させるものであって、ジャバ環境でガーベッジコレクタが資源解除部４６０の役割を行うことができる。

図５は、本発明の実施形態に係わる資源テーブルを示す図面であって、ファイル資源に対するテーブルを示す。資源テーブル５００は、アプリケーション識別子と資源が対応して作成されたテーブルであって、アプリケーション識別子フィールド５１０、資源識別子フィールド５２０、および資源使用要否フィールド５３０を含んで構成される。

アプリケーション識別子フィールド５１０には、アプリケーションの固有識別子が含まれる。前述した通り、アプリケーション識別子は、アプリケーションのスレッド識別子を用いて生成することができ、アプリケーションの登録順序を用いて生成することもできる。

資源識別子フィールド５２０にはアプリケーションに割当てられた資源の種類を示す固有識別子（資源識別子）が含まれる。資源には、メモリ資源、ファイル資源、およびネットワーク資源を含むことができ、その他にアプリケーションに割当てられて用いられる資源を含むこともできる。これに伴い、メモリ資源テーブル、ファイル資源テーブル、およびネットワーク資源テーブルが別途に備えられることができ、各資源に対する統合テーブルが備えられることもできる。

１つのアプリケーション識別子に複数の資源を対応することができ、同一の資源に対してもその一連番号を別にして対応することができる。例えば、第１のファイル資源および第２のファイル資源が１つのアプリケーション識別子に対応することができる。

資源使用要否フィールド５３０には該当資源に対するアプリケーションの使用要否を示すフラッグが含まれる。換言すれば、アプリケーションが該当資源を用いる場合は１の値がフラッグに挿入され、アプリケーションが該当資源を用いない場合は０の値がフラッグに挿入され得る。

資源テーブル５００は、資源制御部４４０によって生成して更新されるが、資源制御部４４０はアプリケーション管理部４１０から受信した資源とアプリケーション識別子との間の連結関係を用いて資源テーブル５００を更新し、資源管理部４５０が該当資源使用に対するカウンタを更新するようにする。

図６は、本発明の実施形態に係わるコンテインメントフレームワーク環境で資源が用いられる過程を示すフローチャートである。

コンテインメントフレームワーク環境で資源を用いるために資源管理装置４００のアプリケーション管理部４１０は、先ずアプリケーションの初期化を行う（Ｓ６１０）。すなわち、アプリケーションに割当てられる資源の種類およびその大きさを確認することで、資源管理装置４００で実行されるアプリケーションが複数である場合、アプリケーション管理部４１０は各々のアプリケーションに対する初期化を行うことができる。

アプリケーション初期化が行われることによって、識別子生成部４２０は所定の資源が割当てられたアプリケーションの固有識別子（アプリケーション識別子）を生成する（Ｓ６２０）。ここで、資源は、メモリ資源、ファイル資源、およびネットワーク資源のうち、少なくとも１つであり得る。また、資源管理装置４００で実行されるアプリケーションは、ライフサイクルを有するジャバアプリケーションを含む。

識別子生成部４２０は、アプリケーションのスレッド識別子を用いてアプリケーション識別子を生成することができ、アプリケーションの登録順序を用いてアプリケーション識別子を生成することもできる。アプリケーション識別子が生成されることによって、資源制御部４４０は生成されたアプリケーション識別子と該当アプリケーションに割当てられた資源を対応させて格納部４３０に保存する。すなわち、資源テーブル５００を更新する（Ｓ６３０）。

そして、アプリケーション管理部４１０は、アプリケーションに対する状態切替えを行う。すなわち、初期化されたアプリケーションをメモリに搭載し、一時停止したアプリケーションを実行することで、この時、アプリケーションと割当てられた資源との間の連結を締結する（Ｓ６４０）。アプリケーションの実行の結果は資源制御部４４０に伝えられ、資源制御部４４０は資源テーブル５００で該当資源に対する使用要否フラッグを１に設定し、その結果を資源管理部４５０に伝達する。

これに伴い、資源管理部４５０は、該当アプリケーションの資源使用に対するカウンタを増加させる（Ｓ６５０）。例えば、該当資源がファイル資源である場合、資源管理部４５０のファイル資源管理部（図示せず）がファイル資源使用に対するカウンタを増加させ、該当資源がネットワーク資源である場合、資源管理部４５０のネットワーク資源管理部（図示せず）がネットワーク資源使用に対するカウンタを増加させる。

資源使用に対するカウンタの増加は、アプリケーション管理部４１０によるアプリケーションの状態が実行状態に切替えることによって行われ、複数のアプリケーションに割当てられた資源使用に対するカウンタが同時に増加することもできる。

図７は、本発明の実施形態に係わるコンテインメントフレームワーク環境で資源が解除される過程を示すフローチャートである。

コンテインメントフレームワーク環境で資源を解除するために資源管理装置４００のアプリケーション管理部４１０は、アプリケーションと資源との間の連結を解除する（Ｓ７１０）。連結解除の結果は資源制御部４４０に伝えられ、資源制御部４４０は格納部４３０に保存された資源テーブル５００で該当資源の使用要否フラッグを０に設定し、その結果を資源管理部４５０に伝達する。

これに伴い、資源管理部４５０は、該当アプリケーションの資源使用に対するカウンタを減少させる（Ｓ７２０）。例えば、該当資源がファイル資源である場合は資源管理部４５０のファイル資源管理部（図示せず）がファイル資源使用に対するカウンタを減少させ、該当資源がネットワーク資源である場合は資源管理部４５０のネットワーク資源管理部（図示せず）がネットワーク資源使用に対するカウンタを減少させる。

一方、プログラムコードまたはユーザによるアプリケーション終了命令が入力されることができるが（Ｓ７３０）、アプリケーション終了命令が入力されることによって、アプリケーション管理部４１０は該当アプリケーションの状態を消滅状態に切替えて該当アプリケーションに割当てられたすべての資源の連結を解除する（Ｓ７４０）。連結解除の結果は資源制御部４４０に伝えられるが、資源制御部４４０は資源テーブル５００で該当アプリケーションに割当てられたすべての資源の使用要否フラッグを０に設定し、その結果を資源管理部４５０に伝達する。

これに伴い、資源管理部４５０は、該当アプリケーションに割当てられたすべての資源使用に対するカウンタを減少させる（Ｓ７５０）。カウンタ減少の結果は再び資源制御部４４０に伝えられるが、資源制御部４４０はカウンタが０になったかを確認し（Ｓ７６０）、カウンタが０になったら資源解除部４６０に資源解除制御コードを伝達する。

資源解除制御コードが伝達された資源解除部４６０は、該当アプリケーションに割当てられたすべての資源を解除する（Ｓ７７０）。ジャバ環境である場合、ガーベッジコレクタが資源解除部４６０の役割を行ってアプリケーションに割当てられたすべての資源を強制的に解除することができる。

図４のブロック図の各ブロックと図６〜図７のフローチャートの各ステップの組合せは、コンピュータプログラムインストラクションによって行われる可能性があることが理解できる。これらコンピュータプログラムインストラクションは、汎用コンピュータ、特殊用コンピュータ、またはその他のプログラム可能なデータプロセシング装備のプロセッサに搭載することができるため、コンピュータまたはその他のプログラム可能なデータプロセシング装備のプロセッサを介して行われるそのインストラクションがブロック図の各ブロックまたはフローチャートの各ステップで説明された機能を行う手段を生成するようになる。これらコンピュータプログラムインストラクションは、特定方式で機能を実現するために、コンピュータまたはその他のプログラム可能なデータプロセシング装備を指向することができるコンピュータ利用可能またはコンピュータ読取可能なメモリに格納することも可能であるため、そのコンピュータ利用可能またはコンピュータ読取可能なメモリに格納されたインストラクションは、ブロック図の各ブロックまたはフローチャートの各ステップで説明された機能を行うインストラクション手段を含む製造品目を生産することも可能である。コンピュータプログラムインストラクションは、コンピュータまたはその他のプログラム可能なデータプロセシング装備上に搭載することも可能であるため、コンピュータまたはその他のプログラム可能なデータプロセシング装備上で一連の動作ステップが行われ、コンピュータで実行されるプロセスを生成してコンピュータまたはその他のプログラム可能なデータプロセシング装備を行うインストラクションはブロック図の各ブロックおよびフローチャートの各ステップで説明された機能を実行するためのステップを提供することも可能である。

また、各ブロックまたは各ステップは、特定された論理的機能を実行するための１つ以上の実行可能なインストラクションを含むモジュール、セグメント、またはコードの一部を示すことができる。また、いくつかの代替実行例ではブロックまたはステップで言及した機能が順序を外れて発生することも可能であることを注目しなければならない。例えば、連続して図示されている２つのブロックまたはステップは実質的に同時に行われることも可能であり、またはそのブロックまたはステップが時々該当機能により逆順に行われることも可能である。

以上、添付した図面を参照して本発明の実施形態を説明したが、本発明が属する技術分野で通常の知識を有する者であれば、本発明がその技術的思想や必須の特徴を変更せず、他の具体的な形態によって実施することができるということを理解できる。したがって、以上で記述した実施形態はすべての面で例示的なものであり、限定的なものではないことを理解しなければならない。

従来のコンテインメントフレームワークの構造を示すブロック図である。 本発明の実施形態に係わるアプリケーションによって資源が用いられることを示す概念図である。 本発明の実施形態に係わるコンテインメントフレームワークの構造を示すブロック図である。 本発明の実施形態に係わるコンテインメントフレームワーク環境で資源を管理する装置を示すブロック図である。 本発明の実施形態に係わる資源テーブルを示す図である。 本発明の実施形態に係わるコンテインメントフレームワーク環境で資源が用いられる過程を示すフローチャートである。 本発明の実施形態に係わるコンテインメントフレームワーク環境で資源が解除される過程を示すフローチャートである。

符号の説明

４１０ アプリケーション管理部
４２０ 識別子生成部
４３０ 格納部
４４０ 資源制御部
４５０ 資源管理部
４６０ 資源解除部

Claims (18)

1. 所定の資源が割当てられたアプリケーションの固有識別子を生成する識別子生成部と、
   前記資源と前記固有識別子との間の連結を締結または解除するアプリケーション管理部と、
   前記連結が締結された場合は前記資源使用に対するカウンタを増加させ、前記連結が解除された場合は前記資源使用に対するカウンタを減少させる資源管理部と、
   前記カウンタが０である場合は前記資源の解除を行う資源解除部とを含むコンテインメントフレームワーク環境で資源を管理する装置。
2. 前記資源は、メモリ資源、ファイル資源、およびネットワーク資源のうち、少なくとも１つを含む請求項１に記載のコンテインメントフレームワーク環境で資源を管理する装置。
3. 前記アプリケーションは、ライフサイクルを有するジャバアプリケーションを含む請求項１に記載のコンテインメントフレームワーク環境で資源を管理する装置。
4. 前記識別子生成部は、前記アプリケーションのスレッド識別子を用いて前記固有識別子を生成する請求項１に記載のコンテインメントフレームワーク環境で資源を管理する装置。
5. 前記固有識別子と前記資源が対応して作成されたテーブルを格納する格納部をさらに含む請求項１に記載のコンテインメントフレームワーク環境で資源を管理する装置。
6. 前記テーブルの作成および更新を行う資源制御部をさらに含む請求項５に記載のコンテインメントフレームワーク環境で資源を管理する装置。
7. 前記資源管理部は、１つのアプリケーションに割当てられたすべての資源に対する前記カウンタの増加または減少を行う請求項１に記載のコンテインメントフレームワーク環境で資源を管理する装置。
8. 前記資源管理部は、前記アプリケーションが複数である場合、各々のアプリケーションに割当てられた資源に対する前記カウンタの増加または減少を行う請求項１に記載のコンテインメントフレームワーク環境で資源を管理する装置。
9. 前記資源解除部は、前記アプリケーションが終了した場合、前記アプリケーションに割当てられた資源を解除する請求項１に記載のコンテインメントフレームワーク環境で資源を管理する装置。
10. （ａ）所定の資源が割当てられたアプリケーションの固有識別子を生成するステップと、
    （ｂ）前記資源と前記固有識別子との間の連結を締結または解除するステップと、
    （ｃ）前記連結が締結された場合は前記資源使用に対するカウンタを増加させ、前記連結が解除された場合は前記資源使用に対するカウンタを減少させるステップと、
    （ｄ）前記カウンタが０である場合は前記資源の解除を行うステップとを含むコンテインメントフレームワーク環境で資源を管理する方法。
11. 前記資源は、メモリ資源、ファイル資源、およびネットワーク資源のうち、少なくとも１つを含む請求項１０に記載のコンテインメントフレームワーク環境で資源を管理する方法。
12. 前記アプリケーションは、ライフサイクルを有するジャバアプリケーションを含む請求項１０に記載のコンテインメントフレームワーク環境で資源を管理する方法。
13. 前記（ａ）ステップは、前記アプリケーションのスレッド識別子を用いて前記固有識別子を生成するステップを含む請求項１０に記載のコンテインメントフレームワーク環境で資源を管理する方法。
14. 前記固有識別子と前記資源が対応して作成されたテーブルを格納するステップをさらに含む請求項１０に記載のコンテインメントフレームワーク環境で資源を管理する方法。
15. 前記テーブルの作成および更新を行うステップをさらに含む請求項１４に記載のコンテインメントフレームワーク環境で資源を管理する方法。
16. 前記（ｃ）ステップは、１つのアプリケーションに割当てられたすべての資源に対する前記カウンタの増加または減少を行うステップを含む請求項１０に記載のコンテインメントフレームワーク環境で資源を管理する方法。
17. 前記（ｃ）ステップは、前記アプリケーションが複数である場合、各々のアプリケーションに割当てられた資源に対する前記カウンタの増加または減少を行うステップを含む請求項１０に記載のコンテインメントフレームワーク環境で資源を管理する方法。
18. 前記（ｄ）ステップは、前記アプリケーションが終了した場合、前記アプリケーションに割当てられた資源を解除するステップを含む請求項１０に記載のコンテインメントフレームワーク環境で資源を管理する方法。

Images