(57)【要約】      （修正有）【課題】ソフトウェアモジュールを安全に停止させると共に、何らかの理由でソフトウェアモジュールが正常に停止できなかった場合に、直ちに次の処理へ移行することが可能なソフトウェアシステムを提供する。【解決手段】個々のソフトウェアモジュールを停止する停止手段（Ｓ７０２）と、前記ソフトウェアモジュールに対応するタイムアウト時間を取得するタイムアウト時間取得手段（Ｓ７０４）と、前記停止手段による前記ソフトウェアモジュールの停止処理時間を計測する停止処理時間計測手段（Ｓ７０７，Ｓ７１３）と、前記タイムアウト時間が経過した際にタイムアウトした旨を通知するタイムアウト通知手段（Ｓ７０８，Ｓ７１４）とを備えた。【選択図】図７
2006155239.tif 000002
【特許請求の範囲】
【請求項１】
停止処理のためのタイムアウト時間を備えた複数のソフトウェアモジュールから成るソフトウェアシステムであって、
前記個々のソフトウェアモジュールを停止する停止手段と、
前記ソフトウェアモジュールに対応するタイムアウト時間を取得するタイムアウト時間取得手段と、
前記停止手段による前記ソフトウェアモジュールの停止処理時間を計測する停止処理時間計測手段と、
前記タイムアウト時間が経過した際に前記停止手段による前記ソフトウェアモジュールの停止後に実行する処理を実行する実行手段と
を備えたことを特徴とするソフトウェアシステム。
【請求項２】
前記タイムアウト時間とは、前記ソフトウェアモジュールに備えられたファイルに記述された情報であることを特徴とする請求項１記載のソフトウェアシステム。
【請求項３】
前記タイムアウト時間とは、前記ソフトウェアモジュールのプログラムコード内に記述された情報であることを特徴とする請求項１記載のソフトウェアシステム。
【請求項４】
停止処理のためのタイムアウト時間を備えた複数のソフトウェアモジュールから成るソフトウェアシステムの制御方法であって、
前記個々のソフトウェアモジュールを停止する停止ステップと、
前記ソフトウェアモジュールに対応するタイムアウト時間を取得するタイムアウト時間取得ステップと、
前記停止ステップによる前記ソフトウェアモジュールの停止処理時間を計測する停止処理時間計測ステップと、
前記タイムアウト時間が経過した際に前記停止ステップでの前記ソフトウェアモジュールの停止後に実行する処理を実行する実行ステップと
を備えたことを特徴とするソフトウェアシステムの制御方法。
【請求項５】
前記タイムアウト時間とは、前記ソフトウェアモジュールに備えられたファイルに記述された情報であることを特徴とする請求項４記載のソフトウェアシステムの制御方法。
【請求項６】
前記タイムアウト時間とは、前記ソフトウェアモジュールのプログラムコード内に記述された情報であることを特徴とする請求項４記載のソフトウェアシステムの制御方法。
【請求項７】
請求項４乃至６のいずれかに記載のソフトウェアシステムの制御方法を実現するためのコンピュータ読み取り可能なプログラムコードを有することを特徴とする制御プログラム。
【請求項８】
請求項７記載の制御プログラムを格納したことを特徴とする記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のソフトウェアモジュールから成るソフトウェアシステム、そのソフトウェアシステムを制御する制御方法、制御プログラム及びその制御プログラムを格納した記憶媒体に関する。
【背景技術】
【０００２】
従来、組み込み機器におけるソフトウェアモジュールは、システムの作成時に静的にコンパイルとリンクが行われてシステムに組み込まれており、システムの稼動中にソフトウェアモジュールをインストールすることが不可能な場合が多かった。
【０００３】
しかし、近年、ネットワーク接続機能を備える組み込み機器が増え、PC（パーソナルコンピュータ）のブラウザから組み込み機器に対してソフトウェアモジュールをインストールしたり、組み込み機器自身がネットワークを介してソフトウェアモジュールを動的にダウンロード及びインストールすることも行われるようになってきた。
【０００４】
一例として、Java（登録商標）言語で記述されたJava（登録商標）アプレットやJava（登録商標）アプリケーションを、Java（登録商標）の実行環境であるJava（登録商標）仮想マシンが実装された組み込み機器に動的にダウンロードして実行することが行われている。例えば、組み込み機器にダウンロードされたソフトウェアモジュールのインストールや、起動及び停止等の管理を行うJava（登録商標）ベースのプラットフォームとして、OSGサービスプラットフォーム（例えば、非特許文献１参照）がある。
【０００５】
ところで、システム停止に関して従来の組み込み機器では、電源スイッチを切断することで電源供給を遮断して、ソフトウェアの実行を強制的に停止させてしまうことが多かった。
【０００６】
このように強制的に電源供給を遮断してしまうと、それまでダイナミックRAM（ランダムアクセスメモリ）等の不揮発性メモリ中に保存されていてスタティックRAM（ランダムアクセスメモリ）やハードディスク等の不揮発性メモリ中に移動されないデータは失われることになる。
【０００７】
また、ハードディスクを搭載しているシステムでは、ハードディスクに書き込み中に電源供給が遮断されることに起因して、ハードディスクの物理的な破損や、記憶していたデータの消失等の事態を招くことになる。
【０００８】
そこで、従来、組み込み機器でもシャットダウン処理を実行するようにしたものが提案されている。シャットダウン処理とは、情報処理装置の運用を終了するための処理のことであり、ディスクキャッシュのフラッシュや、実行中のソフトウェアモジュールの停止等を正しく行った後に電源を遮断するものである。
【０００９】
しかし、起動中のソフトウェアモジュールの誤動作、リソース不足等の原因で異常な状態になり、ソフトウェアモジュールの停止処理が途中でハングアップしてしまうことがある。ハングアップするとシャットダウン処理がそこで停止して続行できないために、電源供給を遮断することができなくなる。
【００１０】
このような場合でも、シャットダウン処理を続行して電源供給の遮断を実行するため、システムがデフォルトのタイムアウト時間を規定し、ソフトウェアモジュールの停止処理にタイムアウトを設けている場合がある。停止処理がタイムアウト時間を超えても完了しなければ、その時点で停止処理が完了したとみなし、次に控えている処理を実行する。その結果、シャットダウン処理を続行することが可能になる。
【非特許文献１】「OSG Service Platform Release 3」、Open Service Gateway Initiative、２００３年３月
【発明の開示】
【発明が解決しようとする課題】
【００１１】
しかしながら、上記従来例においては、ソフトウェアモジュールの通常の停止処理に時間がかかる場合には、通常の停止処理中にタイムアウトが発生してしまう場合があった。
【００１２】
すなわち、実行中のソフトウェアモジュールは、シャットダウンに伴って、ソフトウェアモジュール毎に必要な停止処理を行う。例えば、あるソフトウェアモジュールがネットワークを介してデータの送受信を行っていた場合は、データ不整合が起こらない状態になるまで通信を維持するための処理を、また、あるソフトウェアモジュールが他のソフトウェアモジュールの機能を使用するようなものである場合は、相互のソフトウェアの使用状態を保存する処理等を停止処理の中で行う。
【００１３】
そのような状況においては、ソフトウェアモジュールによっては、正常な停止処理中にタイムアウトが起こり、電源が遮断され、そのために、データの不整合、消失及びハードディスクの破損等が起こる虞があった。
【００１４】
また、上述したようなデータの不整合、消失及びハードディスクの破損等を回避するために、長いタイムアウト時間を設定すると、シャットダウン時間が冗長にとられてしまい、ユーザの使い勝手が悪くなるという問題があった。
【００１５】
本発明は、このような従来技術の有する問題点を解決するためになされたもので、その目的は、ソフトウェアモジュールを安全に停止させると共に、何らかの理由でソフトウェアモジュールが正常に停止できなかった場合に、直ちに次の処理へ移行することが可能なソフトウェアシステム、このソフトウェアシステムを制御する制御方法、制御プログラム及びその制御プログラムを格納した記憶媒体を提供することである。
【課題を解決するための手段】
【００１６】
上記目的を達成するために本発明のソフトウェアシステムは、停止処理ためのタイムアウト時間を備えた複数のソフトウェアモジュールから成るソフトウェアシステムであって、前記個々のソフトウェアモジュールを停止する停止手段と、前記ソフトウェアモジュールに対応するタイムアウト時間を取得するタイムアウト時間取得手段と、前記停止手段による前記ソフトウェアモジュールの停止処理時間を計測する停止処理時間計測手段と、前記タイムアウト時間が経過した際に前記停止手段による前記ソフトウェアモジュールの停止後に実行する処理を実行する実行手段とを備えたことを特徴とする。
【００１７】
また、上記目的を達成するために本発明のソフトウェアシステムの制御方法は、停止処理のためのタイムアウト時間を備えた複数のソフトウェアモジュールから成るソフトウェアシステムの制御方法であって、前記個々のソフトウェアモジュールを停止する停止ステップと、前記ソフトウェアモジュールに対応するタイムアウト時間を取得するタイムアウト時間取得ステップと、前記停止ステップによる前記ソフトウェアモジュールの停止処理時間を計測する停止処理時間計測ステップと、前記タイムアウト時間が経過した際に前記停止ステップでの前記ソフトウェアモジュールの停止後に実行する処理を実行する実行ステップとを備えたことを特徴とする。
【発明の効果】
【００１８】
ソフトウェアモジュールを安全に停止させると共に、何らかの理由でソフトウェアモジュールが正常に停止できなかった場合に、直ちに次の処理へ移行することが可能である。
【発明を実施するための最良の形態】
【００１９】
以下、本発明のソフトウェアシステム、ソフトウェアシステムの制御方法、制御プログラム及び記憶媒体の実施の形態を図面に基づき説明する。
【００２０】
本発明の特徴は、システムで一意に決められたタイムアウト時間ではなく、ソフトウェアモジュール毎にタイムアウト時間を設定することである。
【００２１】
（第１の実施の形態）
まず、本発明の第１の実施の形態を、図１乃至図９に基づき説明する。
【００２２】
図１は、本実施の形態に係るソフトウェアシステム上で稼動するソフトウェアの構成を示す図で、上述した非特許文献１に記載されているOSGサービスプラットフォームで規定されているものである。
【００２３】
図１において、１００はハードウェア、１０１はオペレーティングシステムで、ハードウェアやソフトウェアを制御するためのものである。１０２はJava（登録商標）仮想マシンで、オペレーティングシステム１０１上で稼動し、Java（登録商標）言語から生成された中間言語であるバイトコードを解釈して実行するためのものである。１０３はフレームワークで、Java（登録商標）言語で記述された各種アプリケーション・プログラムを１つのJava（登録商標）仮想マシン１０２の上で実行可能にするためのものである。１０４はバンドルで、フレームワーク１０３上で動作するアプリケーションのフレームワーク上の管理単位である。このバンドル１０４は、複数（１からＮまで）設けられており、アプリケーションを構成するJava（登録商標）言語によって記述されたプログラムや、そのプログラムが使用する画像データや、各種ファイルデータ等を内包している。
【００２４】
フレームワーク１０３は、バンドル１０４を各々独立してフレームワーク１０３に対してインストール／アンインストールする機能や、インストールされているバンドルを新しいものに更新する機能や、インストールされているバンドルを起動／停止する機能等を有する。
【００２５】
図２は、本実施の形態に係るソフトウェアシステムにおけるフレームワーク１０３を構成する主なJava（登録商標）言語のクラスの構成を示す図である。
【００２６】
図２において、２０１はフレームワーク実装クラスで、フレームワーク１０３の主な機能を実現しているものである。２０２はバンドルコンテクストインタフェース（Bundle Context interface）で、フレームワーク実装クラス２０１が実装している機能をフレームワーク１０３以外からアクセスするためのインタフェースである。２０３はバンドルインタフェース（Bundle interface）で、他のバンドル１０４から該バンドル１０４に対してアクセスするためのインタフェースである。２０４はバンドル制御実装クラスで、フレームワーク１０３上でバンドル１０４を管理するために生成されるものである。２０５はバンドルアクチベーターインタフェース（Bundle Activator interface）で、バンドル１０４を起動／停止する際にフレームワーク１０３が呼び出すメソッドを規定したインタフェースである。２０６はバンドル実装クラスで、バンドル１０４内でバンドルアクチベーターインタフェース２０５を実装しているものである。２０７はサービス制御実装クラスで、バンドル１０４が他のバンドル１０４に対して提供しているサービスをフレームワーク１０３上で管理するためのものである。２０８はサービス実装クラスで、バンドル１０４内で該バンドル１０４が提供するサービスを実際に実装しているものである。２０９はバンドルレジストレーションインタフェース（Bundle Registration interface）で、サービス登録データにアクセスするためのインタフェースである。２１０はサービスレファレンスインタフェース（Service Reference interface）で、サービスを使用する際にサービスのデータにアクセスするためのインタフェースである。
【００２７】
図３は、本実施の形態に係るソフトウェアシステムにおけるバンドル１０４をインストールする際に用いられるアーカイブファイルであるJarファイルの構造と、バンドルを構成するファイル（以下、バンドルファイルと。）の際にJarファイルのヘッダであるマニフェストヘッダに設定されるバンドルの属性とを示す図である。
【００２８】
但し、これらのバンドル属性は、必ずしも指定する必要はなく、順番も規定されているものではない。
【００２９】
図３において、Jarファイルには、マニフェストヘッダ３００ａと、複数のエントリ３０１ｂが記述されている。
【００３０】
マニフェストヘッダ３００ａは、バンドル名ヘッダ３０１、静的参照パッケージヘッダ３０２、提供パッケージヘッダ３０３、動的参照パッケージヘッダ３０４、参照サービスヘッダ３０５、提供サービスヘッダ３０６、バンドルアクチベーター（Bundle Activator）実装クラス名ヘッダ３０７及びタイムアウト時間ヘッダ３０８を有している。
【００３１】
バンドル名ヘッダ３０１は、バンドル１０４の名前を記述している。静的参照パッケージヘッダ３０２は、バンドル１０４が参照する他のバンドル１０４が提供するJava（登録商標）パッケージのパッケージ名のリストである。提供パッケージヘッダ３０３は、バンドル１０４が他のバンドル１０４に対して提供しているJava（登録商標）パッケージ名のリストである。動的参照パッケージヘッダ３０４は、静的参照パッケージヘッダ３０２と同様にバンドル１０４が参照するJava（登録商標）パッケージ名のリストであるが、静的参照パッケージヘッダ３０２がバンドル１０４の起動時に参照関係の解決が必要であるのに対して、実際に必要となる場合に参照関係が解決できれば良いものである。参照サービスヘッダ３０５は、他のバンドル１０４が提供しているサービスのうち、どのサービスを使用するかを宣言するものである。提供サービスヘッダ３０６は、他のバンドル１０４に提供可能なサービスを宣言するものである。バンドルアクチベーター（Bundle Activator）実装クラス名ヘッダ３０７は、バンドルアクチベーターインタフェース２０５を実装しているクラスの名前を宣言するものである。タイムアウト時間ヘッダ３０８は、バンドル１０４の停止処理に必要な時間を宣言するものである。このタイムアウト時間ヘッダ３０８は、バンドル１０４の停止処理の際に、該バンドル１０４が安全に停止処理を完了することができる時間を宣言するものである。
【００３２】
以下、本実施の形態に係るソフトウェアシステムにおけるバンドル１０４のインストール処理、起動／停止処理、システム停止処理について説明する。
【００３３】
≪バンドルのインストール処理≫
まず、バンドル１０４がフレームワーク１０３にインストールされる際の処理について、図４を用いて説明する。
【００３４】
図４は、バンドル１０４がフレームワーク１０３にインストールされる際の処理動作の流れを示すフローチャートである。
【００３５】
図４において、まず、システムのオペレータ４００がバンドルファイルの格納されている場所をURL（Uniform Resource Locator）を使用して指定し、指定された場所に格納されているバンドルファイルをフレームワーク１０３にインストールすることを、フレームワーク実装クラス２０１に指示する（ステップＳ４０１）。
【００３６】
フレームワーク実装クラス２０１は、指定された格納場所からバンドルファイルを読み込み、その読み込んだバンドルファイルのデータを、フレームワーク１０３内で参照し易いように設けられたキャッシュに格納する（ステップＳ４０２）。
【００３７】
読み込まれたバンドルファイルのマニフェスト（Jarファイルの属性等を定義するヘッダ）から提供パッケージヘッダ３０３と静的参照パッケージヘッダ３０２を読み出す。各バンドル１０４が提供しているJava（登録商標）パッケージは、提供しているバンドル１０４のバンドルID（識別子）と共にフレームワーク実装クラス２０１の持つ提供パッケージレジストリに格納されている。静的参照パッケージヘッダ３０２に記述されている参照パッケージが、この提供パッケージレジストリに既に登録されている、若しくは自身の提供パッケージヘッダ３０３に記述されている場合は、処理を続行する。そうでない場合は、インストール処理が失敗したことを示す例外を発生させた後、本処理動作を停止する。
【００３８】
パッケージ参照関係の解決が完了すると（ステップＳ４０３）、バンドル制御実装クラス２０４のオブジェクトを生成し（ステップＳ４０４）、バンドルファイルのマニフェストの情報によって初期化を行う（ステップＳ４０５）。マニフェストの内容は、バンドル制御実装クラス２０４によって管理され、各マニフェストヘッダのエントリを表す文字列をキーにして参照可能となっている。また、バンドル１０４には、該バンドル１０４を一意に特定するためのバンドルIDが付与される。
【００３９】
新たにインストールされたバンドルに関するエントリを、バンドルID及びキャッシュ内の格納位置等の情報によって作成し、バンドルリストの最後に追加する（ステップＳ４０６）。このバンドルリストは、ハードディスク等の不揮発なメモリに格納される。
【００４０】
最後にバンドル制御実装クラス２０４にインストールされたことを示すINSTALLED状態を設定し（ステップＳ４０７）、この状態をバンドルリストからバンドルIDをキーにして、対象となるバンドルに対するバンドルリストエントリを検索し、そのエントリに登録されている状態をINSTALLEDに変更する（ステップＳ４０８）。
【００４１】
このようにして、バンドル１０４がフレームワーク１０３にインストールされる。
【００４２】
図５は、フレームワーク実装クラス２０１によって生成されるバンドル起動順リスト及びバンドルリストの構造を示す図である。
【００４３】
図５において、バンドル起動順リストには、複数のバンドルID５０１が記述されている。また、バンドルリストには、各バンドルID５０１を１つのグループ単位として、各グループ単位毎にキャッシュ場所５０２、状態５０３及び属性５０４が、それぞれ記述される。
【００４４】
≪バンドルの起動／停止≫
次に、本実施の形態に係るソフトウェアシステムにおけるバンドル１０４が起動／停止される場合の処理について、図６を用いて説明する。
【００４５】
図６は、本実施の形態に係るソフトウェアシステムにおけるバンドル１０４が起動／停止される場合の処理動作の流れを示すフローチャートである。
【００４６】
図６において、まず、システムのオペレータ６００がバンドルIDを指定して、バンドルを起動するように指示する（ステップＳ６０１）。バンドルIDに対応するバンドルを起動するように指示されたフレームワーク実装クラス２０１は、そのバンドルIDに対応するバンドル制御実装クラス２０４を検出する。
【００４７】
フレームワーク実装クラス２０１は、バンドル制御実装クラス２０４に対してバンドルアクチベーター実装クラス名ヘッダ３０７を表す文字列をキーとして指定し、バンドルアクチベーター実装クラス名ヘッダ３０７のデータを取得する（ステップＳ６０２）。
【００４８】
バンドルアクチベーター実装クラス名ヘッダ３０７が定義されている場合は、このバンドルアクチベーター実装クラス名ヘッダ３０７が示すクラスをロードし、オブジェクトの生成を行う（ステップＳ６０３）。ここで生成されたバンドルアクチベーターオブジェクトは、バンドル制御実装クラス２０４に記憶される。
【００４９】
次に、生成されたバンドルアクチベーターオブジェクトに対してスタート（start）メソッドを呼び出し、バンドル１０４毎に定義された該バンドル１０４の初期化ルーチンを実行する（ステップＳ６０４）。この初期化ルーチンの中で、バンドル１０４が提供するサービスをフレームワーク実装クラス２０１に登録して（ステップＳ６０５）、その登録されたサービスを表すサービスレジストレーション（Service Registration）オブジェクトを取得したり、フレームワーク実装クラス２０１に登録されているサービスからバンドル１０４が使用するサービスを検索し、その検索したサービスを表すサービスリフェレンス（Service Reference）オブジェクトを取得して、サービスオブジェクトを取得する（ステップＳ６０６）等の処理を行うことが一般的である。
【００５０】
起動が成功すると、バンドル１０４が起動されていることを示す状態であるACTIVE状態にバンドル制御実装クラス２０４が設定される（ステップＳ６０７）。また、このACTIVE状態は、バンドルリストの対応するエントリの状態フィールドにも設定されて、永続的に記憶される。
【００５１】
更に、フレームワーク実装クラス２０１は、図５に示すバンドル起動順リストを保持しており、このバンドル起動順リストも、バンドルリストと同様に永続的に記憶される。このバンドル起動順リストの最後に、起動したバンドル１０４のバンドルIDを追加する（ステップＳ６０８）。
【００５２】
次に、停止処理について説明する。
【００５３】
図６において、システムのオペレータ６００がバンドルIDを指定して、バンドル１０４を停止するように指示する（ステップＳ６０９）。指定されたバンドルIDに対応するバンドル１０４を停止するように指示されたフレームワーク実装クラス２０１は、バンドルIDから、そのバンドルIDに対応するバンドル制御実装クラス２０４を検出する。
【００５４】
フレームワーク実装クラス２０１は、バンドル制御実装クラス２０４が記憶しているバンドルアクチベーターオブジェクトを取得する。フレームワーク実装クラス２０１は、取得したバンドルアクチベーターオブジェクトに対してストップ（stop）メソッドを呼び出し、バンドル１０４毎に定義されたバンドルの停止ルーチンを実行する（ステップＳ６１０）。この停止ルーチンの中で、バンドル１０４が登録したサービスの登録解除（ステップＳ６１２）や、使用していたサービスの開放（ステップＳ６１１）を行うことが一般的である。
【００５５】
バンドル１０４の停止が成功すると、該バンドル１０４が停止していることを示す状態であるRESOLVED状態にバンドル制御実装クラス２０４が設定される（ステップＳ６１３）。また、このRESOLVED状態は、バンドルリストの対応するエントリの状態フィールドにも設定されて永続的に記憶される（ステップＳ６１４）。
【００５６】
更に、バンドル起動順リストから停止したバンドル１０４のバンドルIDが記述されているエントリを削除する。こうすることによって、バンドル起動順リストは、起動されているバンドル１０４がどのような順番で起動されたのかを保持することができる。
【００５７】
≪システム停止処理≫
次に、システムを停止する際の処理について、図７を用いて説明する。
【００５８】
図７は、システムを停止する際の処理動作の流れを示すフローチャートである。
【００５９】
本実施の形態では、２つのバンドルであるバンドル１及びバンドル２が起動しており、それぞれのバンドル１，２に対するバンドルアクチベーター（Bundle Activator）を実装したクラスとして、Bundle Activator(1)、Bundle Activator(2)があるものとする。
【００６０】
図７において、システム７００のオペレータ７０１が該システム７００の停止を指示すると（ステップＳ７０１）、フレームワーク実装クラス２０１に対して停止メソッドが呼ばれる（ステップＳ７０２）。停止メソッドでは、まず、フレームワーク実装クラス２０１は、永続的記憶領域から読み込んだバンドル起動順リストを参照する（ステップＳ７０３）。バンドル起動順リストは、バンドルの起動／停止処理時に更新されている。このバンドル起動順リストを逆に参照し、最も遅く起動されたバンドル１０４から停止していく。本実施の形態では、バンドル１、バンドル２の順に停止する。
【００６１】
まず、停止するバンドルのマニフェストに定義されたタイムアウト時間３０８を取得する（ステップＳ７０４）。バンドル１に対しては、タイムアウト時間としてタイムアウト時間１を取得する。次に、オブジェクト生成を行う（ステップＳ７０５）。
【００６２】
フレームワーク１０３にインストールされるバンドル１０４には、生成したデータをハードディスクに書き込むもの、ネットワークを介して大量のデータを送受信するもの、また、そのような処理は行わない単純なもの等、様々なものがある。システムを停止する場合、それぞれのバンドルは、行っていた処理を適切に終了する必要があるが、その処理は、バンドル毎に様々であるために、停止処理を開始してから終了するまでに要する時間もバンドル１０４毎に異なる。そのため、バンドル１０４は、停止処理を安全に完了するために必要な時間をマニフェストに定義しておく。それが、タイムアウト時間である。タイムアウト時間の定義としては、少なくともそのバンドルが安全に停止するために必要となる時間である。
【００６３】
次に、フレームワーク実装クラス２０１は、停止するバンドルのバンドルアクチベーターオブジェクトを指定して、停止マネージャ７０２を別スレッドで起動した後（ステップＳ７０６）、停止マネージャ７０２から停止ルーチンが完了したことを告げる通知があるまで待機する。待機を開始した時点からタイムアウト時間の測定を開始する（ステップＳ７０７）。停止マネージャ７０２から停止ルーチンが完了したことを告げる通知を受ける前にタイムアウト時間が経過した場合は、待機状態から抜けてフレームワークの停止処理を続行する。すなわち、停止マネージャ７０２から停止ルーチンが完了したことを告げる通知を受け取った場合と同様に、バンドル起動順リストに基づいて次の停止対象となるバンドルのBundle Activator(2)に対して、先ほどと同様に停止処理を開始する。
【００６４】
停止マネージャ７０２は、上記≪バンドルの起動／停止≫で説明したバンドル１０４毎に定義されたバンドル１０４の停止ルーチンを開始させるためのクラスである。
【００６５】
但し、通常のバンドルの停止とは異なり、停止ルーチンでは、状態の保存は行わない。
【００６６】
停止ルーチンが完了すると停止マネージャ７０２は、フレームワーク実装クラス２０１に対して停止処理が完了したことを通知する（ステップＳ７０８）。
【００６７】
図７に示す例では、Bundle Activator(1)は、正常に停止ルーチンから抜けるので、タイムアウト時間が経過する前に停止マネージャ７０２は、フレームワーク実装クラス２０１に停止ルーチンの完了を通知する。この停止ルーチンの完了通知を受け取ったフレームワーク実装クラス２０１は、タイムアウト時間の測定を終了する。そして、バンドル１の停止処理が完了した判断し、バンドル起動順リストに基づいて次の停止対象となるバンドルのBundle Activator(2)に対して、先ほどと同様に停止処理を開始する（ステップＳ７１０）。
【００６８】
バンドル２についても、フレームワーク実装クラス２０１は、ステップＳ７１０でタイムアウト時間を取得し、ステップＳ７１１でオブジェクトを生成し、ステップＳ７１２で停止するバンドルのバンドルアクチベーターオブジェクトを指定して、停止マネージャ７０２を別スレッドで起動する。次に、ステップＳ７１３でタイムアウト時間を測定する。
【００６９】
そして、バンドル１と同様に停止ルーチンが正常に完了し、バンドル２に対するタイムアウト時間２が経過する前に、フレームワーク１０３が停止マネージャ７０２から停止処理が完了したことを示す通知を受ける（ステップＳ７１４）。バンドル起動順リストにある全てのバンドルに対して停止処理が完了すると（ステップＳ７１５）、フレームワーク実装クラス２０１の停止メソッドから抜けて、システム７００のシャットダウン処理が続行される。
【００７０】
次に、システム停止処理においてBundle Activator(2)の停止処理ルーチンが正常に終了せずにハングアップした場合の処理について、図８を用いて説明する。
【００７１】
図８は、システム停止処理においてBundle Activator(2)の停止処理ルーチンが正常に終了せずにハングアップした場合の処理動作の流れを示すフローチャートであり、同図において図７と同一部分には同一符号が付してある。
【００７２】
図８において、ステップＳ８０１〜Ｓ８１３（バンドル１の終了まで）は、上述した図７におけるステップＳ７０１〜Ｓ７１３と同様であるから、その説明は省略し、バンドル２の停止処理を開始するところから説明する。
【００７３】
まず、図７と同様に、バンドル２に対するマニフェストに定義されたタイムアウト時間２を取得してから、別スレッドで停止マネージャ７０２を起動する。その後、タイムアウト時間の測定を開始する。
【００７４】
停止マネージャ７０２は、指定されたBundle Activator(2)のストップ（stop）メソッドを呼び出し、停止ルーチンを実行する（ステップＳ８１４）。
【００７５】
通常、この停止処理ルーチンは、正常に終了して停止マネージャ７０２に制御が戻ってくるが、ここでは、停止処理ルーチン内でハングアップしてしまい、制御が停止マネージャ７０２に戻ってこないものとする。
【００７６】
この場合、フレームワーク１０３には、停止マネージャ７０２から停止ルーチンの完了通知が無いので、タイムアウト時間が経過するまで経過時間を計測する。そして、タイムアウト時間が経過すると、待機状態から抜けて次の処理へ移行する。
【００７７】
この場合、バンドル起動順リストの全てのバンドルについて、その停止処理を完了しているので、システム７００に制御が戻り、システムは、シャットダウン処理を続行する。このシステム７００に戻す処理は、図７のステップＳ７１４において停止マネージャ７０２から停止ルーチンが完了したことを告げる通知を受け取った場合と同様の処理である。
【００７８】
図９は、図８と同様に、バンドル２の停止ルーチンがハングアップした場合のシステム停止処理動作の流れを示すフローチャートであり、同図において、図８と同一部分には同一符号が付してある。
【００７９】
図９では、図８とは異なり、システムでタイムアウト時間が一意に決まっている場合のフローを示している。
【００８０】
システムで一意にタイムアウト時間が定義される場合、そのタイムアウト時間は、インストールされるどのバンドルの停止ルーチンでも正常に完了するための時間でなくてはならないので、長めの時間が設定されている。
【００８１】
そのため、通常、短時間で停止ルーチンが終了するバンドルにとっては、ハングアップと判断する時間が必要以上に長くなり、その分、システム全体の停止時間にも影響がでる。
【００８２】
図９は、Bundle Activator(2)がハングアップしたと判断する時間、つまり、タイムアウト時間が図８と比較して長くとられるため、汎用的な一定のタイムアウト時間のみ定められている場合には、システム全体の停止時間も長くなることを示している。  以上が、本発明の第１の実施の形態の説明である。
【００８３】
本実施の形態では、全てのバンドルのマニフェストに各々のタイムアウト時間が定義されているものとしたが、例えば、タイムアウト時間がマニフェストに定義されていないバンドルについては、システムにおいて定義しているタイムアウト時間を用いるようにしても良い。
【００８４】
また、本実施の形態では、システム停止時のバンドルの停止において、バンドルがハングアップした場合に対してタイムアウト時間を設けていたが、これと同様に≪バンドルの起動／停止≫の項において説明したバンドルの停止においても、タイムアウト時間を設けて、バンドルのハングアップから抜け出るようにしても良い。
【００８５】
また、本実施の形態では、タイムアウト時間がマニフェストと呼ばれるバンドルのJarファイルに含まれるファイルに記述されている情報であるとしたが、例えば、Bundle Activatorを実装したクラスのプログラムコード中にタイムアウト時間が記述されており、Bundle Activatorを実装したクラスに用意されたタイムアウト時間を取得するためのメソッドを呼び出すことにより、フレームワーク実装クラスがバンドルに対するタイムアウト時間を取得するようにしても良い。
【００８６】
本発明のソフトウェアモジュールシステムでは、システムで一意に決められたタイムアウト時間ではなく、ソフトウェアモジュール毎にタイムアウト時間を設定する。そのため、安全に停止処理を行う時間を確保した上で、正常に停止処理が終了しない場合でも、ソフトウェアモジュールに適したタイムアウト時間を用いて停止処理の完了を判断するので、タイムアウトが起こるまで冗長を短縮することができる。
【００８７】
また、ソフトウェアモジュール毎のタイムアウト時間は、予めソフトウェアモジュールが備える情報であるから、システムを使用するユーザがタイムアウト時間を設定する必要がないため、ユーザは、タイムアウトに関する知識を必要としない。
【００８８】
更に、システム開発者、ソフトウェアモジュール開発者が異なる場合であっても、システムに一定のタイムアウト時間が設定されているのではなく、ソフトウェアモジュールがタイムアウト時間の情報を備えているため、システムの開発後や販売後にソフトウェアモジュールを追加する場合であっても、そのソフトウェアモジュールが必要とする停止時間が確保され、ソフトウェアモジュールを安全に停止することができる。
【００８９】
（第２の実施の形態）
次に、本発明の第２の実施の形態について、図１０に基づき説明する。
【００９０】
なお、本実施の形態において、ソフトウェアの構成やインストール処理、バンドルの起動等、システムの停止時の処理以外は、上述した第１の実施の形態と同じである。
【００９１】
第１の実施の形態に係るソフトウェアシステムにおける≪システム停止処理≫においては、フレームワーク実装クラス２０１は、シリアルに１つのバンドルの停止処理が完了してから次のバンドルの停止処理を開始していた。
【００９２】
本実施の形態では、１つのバンドルの停止を待たずに、パラレルにバンドルの停止を行うようにしたものである。
【００９３】
図１０は、本実施の形態に係るソフトウェアシステムにおけるシステム停止において、起動中のバンドルをパラレルに停止する処理動作の流れを示すフローチャートであり、同図において、上述した第１の実施の形態の図８と同一部分には、同一符号が付してある。
【００９４】
第１の実施の形態と同様に、本実施の形態においても、バンドル１、バンドル２の停止を行うもので、停止マネージャクラスがバンドルアクチベーター（Bundle Activator）オブジェクトのストップ（stop）メソッドを呼び出して停止ルーチンを実行させるものである。
【００９５】
また、図１０では、図８と同様に、バンドル２の停止時にBundle Activator（2）の終了ルーチンがハングアップした場合の処理フローを表している。
【００９６】
以下、本実施の形態に係るソフトウェアシステムにおけるシステム停止処理動作を、図１０に従って説明する。
【００９７】
図１０において、システム７００のオペレータ７０１が該システム７００の停止を指示すると（ステップＳ１００１）、フレームワーク実装クラス２０１に対して停止メソッドが呼ばれる（ステップＳ１００２）。次に、システム７００から停止メソッドを呼ばれたフレームワーク実装クラス２０１は、永続的記憶領域から読み込んだバンドル起動順リストを参照し（ステップＳ１００３）、そのリストにあるバンドルを停止する。本実施の形態においても第１の実施の形態と同様に、バンドル１及びバンドル２の順に停止処理を開始させる。
【００９８】
次に、フレームワーク実装クラス２０１は、停止するバンドルのマニフェストのタイムアウト時間ヘッダ３０８に定義されたタイムアウト時間を取得する（ステップＳ１００４）。バンドル１に対しては、タイムアウト時間１を取得する。次に、タイムアウト時間を計測するためのタイマクラスであるタイマオブジェクト１０００Ａを生成して（ステップＳ１００５）、別スレッドで起動する（ステップＳ１００６）。
【００９９】
タイマ１０００Ａ内の処理については、後述する。
【０１００】
バンドル１に対するタイマオブジェクト１０００Ａの生成（ステップＳ１００５）／起動（ステップＳ１００６）を終えると、バンドル１が停止したか否かに拘らずバンドル２の停止処理に移行する。
【０１０１】
バンドル１の停止処理と同様にバンドル２に対するタイムアウト時間をマニフェストから取得し（ステップＳ１００７）、取得したタイムアウト時間２をパラメータとしてタイマクラスに渡して、タイマオブジェクト１０００Ｂの生成（ステップＳ１０１１）／起動（ステップＳ１０１２）を行う。
【０１０２】
タイマ１０００Ａ、Ｂは、タイムアウト時間の計測と、Bundle Activatorのstopメソッドを呼び出す停止マネージャオブジェクト７０２Ａ、７０２Ｂの生成／起動（を行うクラスである。
【０１０３】
タイマ１０００Ａ、Ｂは、まず、Bundle Activatorのstopメソッドを呼び出すための停止マネージャオブジェクト７０２Ａ，７０２Ｂを生成して（ステップＳ１００８、Ｓ１０１５）、別スレッドで起動する（ステップＳ１００９、Ｓ１０１６）。その後、時間の計測を開始し、タイマオブジェクト１０００Ａ、Ｂの生成時にフレームワーク実装クラス２０１から取得したタイムアウト時間が経過するまで時間計測を続ける。そして、タイムアウト時間が経過したことを検知すると、フレームワーク実装クラス２０１に対してタイムアウトした旨を通知する（ステップＳ１０１８）。
【０１０４】
但し、Bundle Activatorのストップ（stop）メソッド内の停止ルーチンが完了したことを停止マネージャ７０２Ａがタイマ１０００に通知してきた場合は（ステップＳ１０１４）、タイマ１０００Ａは、その時点で時間の計測を終了して、フレームワーク実装クラス２０１に対して停止ルーチンの完了を通知する（ステップＳ１０１３）。
【０１０５】
バンドル１を停止する場合、タイムアウト時間１内にBundle Activator(1)の停止ルーチンが終了するため、タイマ１０００Ａは、タイムアウト時間１の経過を待たずにフレームワーク実装クラス２０１に対して通知を行う。
【０１０６】
一方、バンドル２を停止する場合は、Bundle Activator(2)のストップ（stop）メソッドの処理でハングアップするため、停止マネージャクラス７０２Ｂからタイマ１０００Ｂに対して通知は行われない。そのため、タイムアウト時間が経過したタイミングで、タイマ１０００Ｂからフレームワーク実装クラス２０１に対して通知が行われる。
【０１０７】
フレームワーク実装クラス２０１は、バンドル起動順リストに記録されている全てのバンドルに対してタイマオブジェクトの生成／起動を行って、停止処理を開始させる。そして、最終的に、起動した全てのタイマ１０００から通知を受けたことを確認して、停止メソッドから抜けると、システム７００に制御が戻る。
【０１０８】
以上、フレームワーク実装クラス２０１がシステム７００の停止処理をパラレルに行う例を示した。
【０１０９】
本発明は、本実施の形態に限られるものではなく、本発明の主題に基づき、どのようなものであっても適用可能である。
【０１１０】
また、上述した各実施の形態における説明に際しては、OSGサービスプラットフォームを挙げたが、本発明は、これに限られるものではない。即ち、パーソナルコンピュータ、携帯電話をはじめとする組み込み機器等、アプリケーションを実行する機器において、OSやOSG以外のミドルウェアにて本発明を実施しても良い。
【０１１１】
また、アプリケーションの停止処理を行う手段を備え、対象のアプリケーションが停止処理を安全に行うために必要な時間に関する情報を備え、起動中のアプリケーションを停止する際に、少なくとも、その時間はアプリケーションの停止に必要な時間として確保し、その間に停止処理を妨げる処理は行わないようにすることにより、実施可能である。
【０１１２】
また、本発明の目的は、上記実施の形態の機能を実現するソフトウェアのプログラムコードを記憶した記憶媒体（または記録媒体）を、システム又は装置に供給し、そのシステム又は装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出し実行することによっても、達成されることは言うまでもない。
【０１１３】
この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施の形態の機能を実現することになり、そのプログラムコード及び該プログラムコードを記憶した記憶媒体は本発明を構成することになる。
【０１１４】
また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施の形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているオペレーティングシステム（ＯＳ）等が実際の処理の一部または全部を行い、その処理によって前述した実施の形態の機能が実現される場合も含まれることは言うまでもない。
【０１１５】
また、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボード（カード）やコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボード（カード）や機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施の形態の機能が実現される場合も含まれることは言うまでもない。
【０１１６】
また、上記プログラムは、上述した実施の形態の機能をコンピュータで実現することができれば良く、その形態は、オブジェクトコード、インタプリタにより実行されるプログラムコード、ＯＳに供給されるスクリプトデータ等の形態を有するものでも良い。
【０１１７】
また、プログラムコードを供給する記憶媒体としては、例えば、フロッピー（登録商標）ディスク、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＤＶＤ−ＲＷ、ＤＶＤ＋ＲＷ、磁気テープ、不揮発性のメモリカード、他のＲＯＭ等を用いることができる。
【０１１８】
更に、上記プログラムは、インターネット、商用ネットワーク、若しくはローカルエリアネットワーク等に接続される不図示の他のコンピュータやデータベース等からダウンロードすることにより供給される。
【図面の簡単な説明】
【０１１９】
【図１】本発明の第１の実施の形態に係るソフトウェアシステム上で稼動するソフトウェアの構成を示す図である。
【図２】本発明の第１の実施の形態に係るソフトウェアシステムにおけるフレームワークをJava（登録商標）言語のクラスの構成を記述した図である。
【図３】本発明の第１の実施の形態に係るソフトウェアシステムにおいて、バンドルをインストールする際に用いるJarファイル及びマニフェストの構成を示す図である。
【図４】本発明の第１の実施の形態に係るソフトウェアシステムにおけるバンドルのフレームワークへのインストール処理動作の流れを示すフローチャートである。
【図５】本発明の第１の実施の形態に係るソフトウェアシステムにおけるバンドル軌道順リスト及びバンドルリストの構成を示す図である。
【図６】本発明の第１の実施の形態に係るソフトウェアシステムにおけるバンドル起動／停止処理動作の流れを示すフローチャートである。
【図７】本発明の第１の実施の形態に係るソフトウェアシステムにおけるシステム停止処理動作（バンドルが正常に停止する場合）の流れを示すフローチャートである。
【図８】本発明の第１の実施の形態に係るソフトウェアシステムにおけるシステム停止処理動作（バンドルが正常に停止しない場合）の流れを示すフローチャートである。
【図９】本発明の第１の実施の形態に係るソフトウェアシステムにおけるシステム停止処理動作（タイムアウト時間一定、バンドルが正常に停止しない場合）の流れを示すフローチャートである。
【図１０】本発明の第２の実施の形態に係るソフトウェアシステムにおけるシステム停止処理動作（フレームワーク実装クラスがパラレルにバンドルを停止する場合）の流れを示すフローチャートである。
【符号の説明】
【０１２０】
２０１    フレームワーク実装クラス
７００    システム
７０２Ａ  停止マネージャクラス
７０２Ｂ  停止マネージャクラス
【図１】
2006155239.tif 000003
【図２】
2006155239.tif 000004
【図３】
2006155239.tif 000005
【図４】
2006155239.tif 000006
【図５】
2006155239.tif 000007
【図６】
2006155239.tif 000008
【図７】
2006155239.tif 000009
【図８】
2006155239.tif 000010
【図９】
2006155239.tif 000011
【図１０】
2006155239.tif 000012