JP2013206040A - ＯＳＧｉ実行装置、ＯＳＧｉシステム - Google Patents

Abstract

【課題】信頼性を保証できないＯＳＧｉバンドルを実行した場合にもＯＳＧｉフレームワーク全体としての信頼性を保つ技術を提供する。
【解決手段】本発明に係るＯＳＧｉ実行装置は、第１および第２ＯＳＧｉフレームワーク部を備え、第１ＯＳＧｉフレームワーク部から第２ＯＳＧｉフレームワーク部へＯＳＧｉバンドルをエクスポートし、第２ＯＳＧｉフレームワーク部が正常稼動していない場合はこれを再起動する。
【選択図】図３

Description

本発明は、ＯＳＧｉフレームワークの信頼性を高める技術に関する。

ＯＳＧｉフレームワークとは、Ｊａｖａ（登録商標）Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ上で動作し、ＪａｖａプログラムをＰｌｕｇｉｎモジュールとして取り扱い、動的に追加・実行できるようにする、サービスプラットフォームである。ＯＳＧｉフレームワークは、ＯＳＧｉ Ａｌｌｉａｎｃｅによって開発・定義されている（非特許文献１）。Ｐｌｕｇｉｎモジュールとして扱われるＯＳＧｉフレームワーク上のＪａｖａプログラムのことをＯＳＧｉバンドルと呼ぶ。

例えば、ＯＳＧｉフレームワークを使用せず、Ｃ言語等を用いてアプリを開発する場合と比較して以下の違いがある。まず、ＯＳＧｉフレームワークはＪａｖａ上で動作するため、環境に合わせたＯＳＧｉバンドルの再開発・修正が必要ない。次に、ＯＳＧｉフレームワークは１つのＪａｖａアプリ、つまりＯＳからみた場合１つのプロセスとして実行され各ＯＳＧｉバンドルは全てこの１プロセス内で実行されるためメモリ使用量が少なく、メモリの少ない組み込み機器上での開発に適している。さらには、各ＯＳＧｉバンドル同士は動的に機能連携できるため、後から容易に機能追加できる。

下記非特許文献２に記載されているＲ−ＯＳＧｉは、複数のＯＳＧｉフレームワークを稼動させている場合において、各ＯＳＧｉフレームワーク間でＯＳＧｉバンドルをインポート／エクスポートする機能を備えている。Ｒ−ＯＳＧｉ自身もＯＳＧｉバンドルとして構成されている。

ＯＳＧｉ Ｓｅｒｖｉｃｅ Ｐｌａｔｆｏｒｍ Ｒｅｌｅａｓｅ ４、ＵＲＬ：http://www.osgi.org/Release4/HomePage（２０１２年３月１６日取得） Ｒ−ＯＳＧｉ − ｔｒａｎｓｐａｒｅｎｔ ＯＳＧｉ ｒｅｍｏｔｅ ｅｘｔｅｎｓｉｏｎ ｆｏｒ ｄｉｓｔｒｉｂｕｔｅｄ ｓｅｒｖｉｃｅｓ、ＵＲＬ：http://r-osgi.sourceforge.net/（２０１２年３月１６日取得）

ＯＳＧｉフレームワークおよびその上で動作するＯＳＧｉバンドル群は、１つのプロセスとして実行される。これにより省メモリを実現しているが、同時に、１つのＯＳＧｉバンドルがハングアップすると、ＯＳＧｉフレームワークおよび他のＯＳＧｉバンドルも一緒にハングアップしてしまうという課題がある。

これはＯＳＧｉフレームワークの開発元が全てのＯＳＧｉバンドルを開発し、各ＯＳＧｉバンドルの動作の信頼性（可用性）を保証できる場合には問題とはならないが、サードパーティが作成したＯＳＧｉバンドルを一緒に実行する場合、そのＯＳＧｉバンドルひいてはＯＳＧｉフレームワーク全体の信頼性を保証できなくなる可能性がある。

本発明は、上記のような課題を解決するためになされたものであり、信頼性を保証できないＯＳＧｉバンドルを実行した場合にもＯＳＧｉフレームワーク全体としての信頼性を保つ技術を提供することを目的とする。

本発明に係るＯＳＧｉ実行装置は、第１および第２ＯＳＧｉフレームワーク部を備え、第１ＯＳＧｉフレームワーク部から第２ＯＳＧｉフレームワーク部へＯＳＧｉバンドルをエクスポートし、第２ＯＳＧｉフレームワーク部が正常稼動していない場合はこれを再起動する。

本発明に係るＯＳＧｉ実行装置によれば、ＯＳＧｉの省メモリとＯＳＧｉバンドル間の動的な連携という特徴を保ちつつ、信頼性を保証できないＯＳＧｉバンドルが第２ＯＳＧｉフレームワーク部上でハングアップした場合でも、第１ＯＳＧｉフレームワーク部上の重要なＯＳＧｉバンドルを実行させ続けることができる。

実施形態１に係るホスト１０の構成図である。 Ｒ−ＯＳＧｉ技術の概要を示す図である。 ホスト１０の動作を概念的に表した図である。 ＵＩ・起動管理プログラム１５の機能ブロック図である。 ユーザからのコマンド入力に対する処理の流れを示す。 ホスト１０の動作フローを示す図である。 実施形態３に係るＯＳＧｉシステムの構成図である。

＜実施の形態１：システム構成＞
図１は、本発明の実施形態１に係るホスト１０の構成図である。ホスト１０は、ＯＳＧｉフレームワークを実行する装置であり、ＯＳ１１、ＪａｖａＶＭ１２１、１２２、１２３を備える。また、ＯＳ１１と各ＪａｖａＶＭを実行するプロセッサを備える。記載の便宜上、図１ではＯＳ１１とプロセッサを一体的に示した。

ＪａｖａＶＭ１２１〜１２３は、ＯＳ１１上で実行される。ＪａｖａＶＭ１２１は、ＵＩ・起動管理プログラム１５を実行する。ＪａｖａＶＭ１２２は、コアＯＳＧｉ１３を実行する。ＪａｖａＶＭ１２３は、アプリＯＳＧｉ１４を実行する。図１上でＪａｖａＶＭを３つに分けているのは、各ＪａｖａＶＭが別プロセスとして動いていることを明示するためである。ＯＳ１１から見れば、コアＯＳＧｉ１３、アプリＯＳＧｉ１４、ＵＩ・起動管理プログラム１５という３つのＪａｖａプロセスが動いていることになる。

コアＯＳＧｉ１３とアプリＯＳＧｉ１４は、ＯＳＧｉ仕様にしたがって実装されたＯＳＧｉフレームワークである。

コアＯＳＧｉ１３は、高い可用性が求められるＯＳＧｉバンドル（以下ではコアバンドルと呼ぶ）を実行するＯＳＧｉフレームワークであり、コアバンドルＡ１３１、コアバンドルＢ１３２、Ｒ−ＯＳＧｉバンドルＳ１３３を実行する。

アプリＯＳＧｉ１４は、必ずしも高い可用性を求められないＯＳＧｉバンドル（以下ではアプリバンドルと呼ぶ）を実行するＯＳＧｉフレームワークであり、Ｒ−ＯＳＧｉバンドルＣ１４１、アプリバンドルＸ１４４、アプリバンドルＹ１４５を実行する。さらに、コアＯＳＧｉ１３からコアバンドルＡ１３１とコアバンドルＢ１３２をインポートし、コアバンドルＡ１４２およびコアバンドルＢ１４３として実行する。

Ｒ−ＯＳＧｉバンドルＳ１３３とＲ−ＯＳＧｉバンドルＣ１４１は、それぞれ「エクスポート部」と「インポート部」に相当する。

＜実施の形態１：Ｒ−ＯＳＧｉ＞
図２は、Ｒ−ＯＳＧｉ技術の概要を示す図である。Ｒ−ＯＳＧｉは、ＯＳＧｉフレームワーク間でＯＳＧｉバンドルを相互にエクスポート／インポートする機能を提供する。図２では、コアＯＳＧｉ１３からコアバンドルＡ１３１をアプリＯＳＧｉ１４へエクスポートし、アプリＯＳＧｉ１４はコアバンドルＡ１３１をインポートしてコアバンドルＡ１４２として実行する。Ｒ−ＯＳＧｉ自身もＯＳＧｉバンドルとして実装されており、ＯＳＧｉフレームワーク自体には改変を加える必要はない。

コアＯＳＧｉ１３上でＲ−ＯＳＧｉバンドルＳ１３３が起動されると、Ｒ−ＯＳＧｉバンドルＳ１３３はユーザの指定したＴＣＰポートを介してＲ−ＯＳＧｉバンドルＣ１４１からの接続を待ち受ける。

アプリＯＳＧｉ１４上で起動されたＲ−ＯＳＧｉバンドルＣ１４１は、ユーザによって指定されたＩＰアドレスおよびＴＣＰポートを用いて、Ｒ−ＯＳＧｉバンドルＳ１３３との接続を確立する。

Ｒ−ＯＳＧｉバンドルＳ１３３は、コアＯＳＧｉ１３上のＯＳＧｉバンドルであるコアバンドルＡ１３１とその提供するメソッドについての情報を取得し、ＴＣＰ／ＩＰ接続を通じてＲ−ＯＳＧｉバンドルＣ１４１にエクスポートする。それらの情報を受け取ったＲ−ＯＳＧｉバンドルＣ１４１は、仮想的なＯＳＧｉバンドルであるコアバンドルＡ１４２を作成し、アプリＯＳＧｉ１４上で実行する。コアバンドルＡ１４２は、コアバンドルＡ１３１が持つのと同じメソッドのインターフェースは持つが、それらメソッドの実装は持たないＯＳＧｉバンドルである。

アプリＯＳＧｉ１４上のＯＳＧｉバンドルであるアプリバンドルＸ１４４がコアバンドルＡ１４２のメソッドを呼び出した場合、コアバンドルＡ１４２はその呼び出しをＲ−ＯＳＧｉバンドルＣ１４１にフォワードする。Ｒ−ＯＳＧｉバンドルＣ１４１はそれを更にＲ−ＯＳＧｉバンドルＳ１３３にフォワードする。

そのメソッド呼び出しを受け取ったＲ−ＯＳＧｉバンドルＳ１３３は、コアバンドルＡ１４２に対応するコアバンドルＡ１３１のメソッドを呼び出して実行し、その実行結果をＲ−ＯＳＧｉバンドルＣ１４１にフォワードする。それを受け取ったＲ−ＯＳＧｉバンドルＣ１４１それを更にコアバンドルＡ１４２にフォワードし、コアバンドルＡ１４２はそれをアプリバンドルＸ１４４に返す。

アプリバンドルＸ１４４から見ると、コアバンドルＡ１４２はアプリＯＳＧｉ１４に存在しているものであるかのように見える。これにより、アプリＯＳＧｉ１４上でコアＯＳＧｉ１３上のコアバンドルＡ１３１の機能を提供しつつ、コアバンドルＡ１３１とアプリバンドル１４４を切り分けることができる。すなわち、アプリバンドル１４４がハングアップにより正常稼動しなくなっても、その影響はコアバンドルＡ１３１に及ばない。

コアバンドルとして実装されるバンドルは、ハングアップやダウンさせたくない機能がこれに該当する。例えば、ログ機能、通信機能、セキュリティ機能などが考えられる。これらの機能はシステムの基本要素であるから、アプリバンドルがこれら機能を利用する場合が比較的多いと考えられる。したがって、単にコアＯＳＧｉ１３とアプリＯＳＧｉ１４を分離してコアＯＳＧｉ１３を安定的に実行すればよいというものではなく、両者が連携することが必要になるのである。

なお、本実施形態１ではＯＳＧｉバンドルをエクスポート／インポートしてＯＳＧｉフレームワーク同士を連携させる手段としてＲ−ＯＳＧｉを例示したが、同様の機能を実現することができれば、その他の手段を用いてもよい。

＜実施の形態１：システム動作の概略＞
図３は、ホスト１０の動作を概念的に表した図である。コアＯＳＧｉ１３とアプリＯＳＧｉ１４は、Ｒ−ＯＳＧｉバンドルＳ１３３とＲ−ＯＳＧｉバンドルＣ１４１によって連携している。より具体的には、Ｒ−ＯＳＧｉバンドルＳ１３３がコアＯＳＧｉ１３上のコアバンドルＡ１３１およびコアバンドルＢ１３２をエクスポートし、Ｒ−ＯＳＧｉバンドルＣ１４１がそれらのＯＳＧｉバンドルをアプリＯＳＧｉ１４にインポートしている。

アプリＯＳＧｉ１４上の他のＯＳＧｉバンドル、例えばアプリバンドルＸ１４４から見ると、コアバンドルＡ１４２とコアバンドルＢ１４３はアプリＯＳＧｉ１４上で実行されているように見える。

ＯＳＧｉフレームワークを利用するユーザは、ＯＳＧｉバンドルをインポートする側のアプリＯＳＧｉ１４に対して、ＯＳＧｉバンドルを呼び出すよう要求し、任意のＯＳＧｉバンドルをインストールし、または管理操作を実施する。コアＯＳＧｉ１３上のバンドルとアプリＯＳＧｉ１４上のバンドルが全て利用できるのはアプリＯＳＧｉ１４の方だからである。

仮に、ユーザがコアＯＳＧｉ１３に対して操作を実施すると仮定する。この場合、信頼性（可用性）を保証できないサードパーティ製のＯＳＧｉバンドルをコアＯＳＧｉ１３上にインストールすることができる。そうすると、信頼性の低いＯＳＧｉバンドルがコアＯＳＧｉ１３をハングアップさせてしまう可能性が高くなるので、コアバンドルＡ１３１などの信頼性もこれに引きずられて信頼性が低下する。そこで本発明では、ユーザが操作する対象はアプリＯＳＧｉ１４とした。

なお、コアバンドルの製作者とアプリバンドルの製作者は異なる可能性があるが、これら製作者と各ＯＳＧｉフレームワークの製作者は必ずしも同一でなくともよい。すなわちコアバンドルの製作者は信頼性を何らかの手段で確認することができればよく、必ずしもＯＳＧｉフレームワークの製作者と同一でなくともよい。また、コアＯＳＧｉ１３とアプリＯＳＧｉ１４を分離しているのは、アプリバンドルが必ずしも信頼性を確保できない可能性があることに鑑みたものであるが、信頼性を確保できるアプリバンドルをアプリＯＳＧｉ１４上で実行することを排除するものではない。

ＯＳＧｉバンドルの製作者が誰であるかについては、ＯＳＧｉフレームワーク上へＯＳＧｉバンドルをインストールする者がその入手先を把握していればこれに基づき判断することもできるし、ｊａｒ（Ｊａｖａアーカイブ）ファイル内に含まれているマニフェストファイルに記載されているフィールドの値に基づき製作者名を特定することもできる。ＯＳＧｉ仕様においては、「Ｂｕｎｄｌｅ−Ｖｅｎｄｏｒ」「Ｂｕｎｄｌｅ−Ｃｏｐｙｒｉｇｈｔ」などのマニフェストフィールドを用いて各バンドルの製作者名を判断することができるであろう。

ＵＩ・起動管理プログラム１５はコアＯＳＧｉ１３とアプリＯＳＧｉ１４を起動し、アプリＯＳＧｉ１４がハングアップした場合にはアプリＯＳＧｉ１４を再起動する。コアＯＳＧｉ１３上のＲ−ＯＳＧｉバンドルＳ１３３とアプリＯＳＧｉ１４上のＲ−ＯＳＧｉバンドルＣ１４１は、それぞれコアＯＳＧｉ１３とアプリＯＳＧｉ１４が起動した後、あらかじめユーザが設定した設定情報にしたがって自動的に連携を確立する。

ＵＩ・起動管理プログラム１５はＵＩ機能も提供する。ここでのＵＩとは、ユーザがＯＳＧｉフレームワークを起動した後にそのＯＳＧｉフレームワークを操作するためのＣＵＩ（Ｃｈａｒａｃｔｅｒ−ｂａｓｅｄ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）またはＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）を指すものとする。ＵＩ・起動管理プログラム１５が操作対象としてユーザに提示するＯＳＧｉフレームワークは、コアＯＳＧｉ１３上およびアプリＯＳＧｉ１４上のＯＳＧｉバンドルの違いを仮想化した仮想ＯＳＧｉ１５１である。

仮想ＯＳＧｉ１５１は、基本的にはアプリＯＳＧｉ１４のラッパである。仮想ＯＳＧｉ１５１は、ユーザからＯＳＧｉフレームワークに対するコマンドを受け取るとそれをアプリＯＳＧｉ１４にフォワードし、アプリＯＳＧｉ１４から返されたコマンド実行結果を受け取ってユーザにフォワードする。

ユーザが直接アプリＯＳＧｉ１４を操作するのではなくＵＩ・起動管理プログラムを通して操作するようにしているのは、ユーザが直接アプリＯＳＧｉ１４を起動し操作するとアプリＯＳＧｉ１４が再起動された際にユーザがそのプロセスハンドルを見失ってしまうためである。仮想ＯＳＧｉ１５１を介してアプリＯＳＧｉ１４を操作する場合、アプリＯＳＧｉ１４がダウンしても仮想ＯＳＧｉ１５１上では単にレスポンスが遅れているかのように見せることができるので、ユーザはＯＳＧｉフレームワークのプロセスハンドルを保持したまま維持することができる。

ＵＩ・起動管理プログラム１５がコアＯＳＧｉ１３と別プロセスとなっているのは、単に簡単のためである。ＵＩ・起動管理プログラムをコアＯＳＧｉ１３に組み込んだ場合、コアＯＳＧｉ１３は標準的なＯＳＧｉフレームワークではなく、特殊なＯＳＧｉフレームワークとなってしまうので、これを避けるため本実施形態１ではＵＩ・起動管理プログラムをコアＯＳＧｉ１３から切り離すこととした。これにより、コアＯＳＧｉ１３とアプリＯＳＧｉ１４は標準的なＯＳＧｉフレームワークとして構成することができる。

＜実施の形態１：ＵＩ・起動管理プログラム１５の詳細＞
図４は、ＵＩ・起動管理プログラム１５の機能ブロック図である。ＵＩ・起動管理プログラム１５は、アプリＯＳＧｉ１４の再起動を管理する起動管理部１５２、ユーザにＵＩを提供するＵＩ部１５３を有する。

起動管理部１５２は、ＵＩ・起動管理プログラム１５が起動した後にコアＯＳＧｉ１３とアプリＯＳＧｉ１４を子プロセスとして起動し、これらが起動した後はアプリＯＳＧｉ１４の実行状態を監視する。アプリＯＳＧｉ１４が不正終了した場合は、アプリＯＳＧｉ１４を起動し直す。これら子プロセスの実行と監視は、Ｊａｖａの標準ライブラリに含まれるｊａｖａ.ｌａｎｇ.Ｒｕｎｔｉｍｅクラスおよびｊａｖａ.ｌａｎｇ.Ｐｒｏｃｅｓｓクラスを使用することにより実現できる。アプリＯＳＧｉ１４については不正終了でなくフリーズ状態になってしまうことも考えられるが、それについては起動管理部１５２から定期的にアプリＯＳＧｉ１４にコマンドを送り実行結果を取得することにより監視する。このコマンド送信も上記Ｐｒｏｃｅｓｓクラスの機能よりアプリＯＳＧｉ１４に対する標準入出力を取得することによって実現できる。

ＵＩ部１５３は、アプリＯＳＧｉ１４のＵＩに対するラッパ機能を提供する。例えば、標準入力を通じてユーザからのコマンド入力を受け付け、先述のＰｒｏｃｅｓｓクラスを通じてアプリＯＳＧｉ１４の標準入力にフォワードし、その実行結果をアプリＯＳＧｉ１４の標準出力から受け取って標準出力に出力する。アプリＯＳＧｉ１４がハングアップして再起動処理中である場合は、ユーザからのコマンド入力に対し常にエラーを返す。

＜実施の形態１：システム動作の詳細＞
図５は、ユーザからのコマンド入力に対する処理の流れを示す。処理４１０はアプリＯＳＧｉ１４が正常に動作している場合の処理の流れである。処理４２０はアプリＯＳＧｉ１４が正常稼動してない場合の処理の流れである。

（図５：処理４１１）
ユーザは標準入力に対し仮想ＯＳＧｉ１５１を操作するコマンドを入力する
（図５：処理４１２）
ＵＩ・起動管理プログラム１５はアプリＯＳＧｉ１４が正常動作していることを確認し、標準入力より受け取ったコマンドをアプリＯＳＧｉ１４の標準入力にフォワードする。
（図５：処理４１３）
アプリＯＳＧｉ１４は、標準入力より受け取ったコマンドの処理を実行し、標準出力に出力する
（図５：処理４１４）
ＵＩ・起動管理プログラム１５はアプリＯＳＧｉ１４の標準出力より受け取ったコマンド実行結果を標準出力にフォワードする。
（図５：処理４１５）
ユーザは標準出力からコマンド実行結果を受け取る。
（図５：処理４２１）
ユーザは標準入力に対しＯＳＧｉフレームワークを操作するコマンドを入力する
（図５：処理４２２）
ＵＩ・起動管理プログラム１５はアプリＯＳＧｉ１４の動作を確認し、再起動処理中であればエラーを標準出力に出力する。アプリＯＳＧｉ１４が正常稼動していない場合は、アプリＯＳＧｉ１４を再起動する一方で、標準出力にエラーを出力する。
（図５：処理４２３）
ユーザは標準出力からエラーを受け取る。

図６は、ホスト１０の動作フローを示す図である。以下、図６の各ステップについて説明する。

（図６：ステップＳ６００）
ユーザがＣＵＩ（コマンドライン）よりＵＩ・起動管理プログラム１５を起動する。
（図６：ステップＳ６０１）
ＵＩ・起動管理プログラム１５はコアＯＳＧｉ１３とアプリＯＳＧｉ１４を子プロセスとして起動する。
（図６：ステップＳ６０２）
コアＯＳＧｉ１３とアプリＯＳＧｉ１４は、Ｒ−ＯＳＧｉバンドルＳ１３３およびＲ−ＯＳＧｉバンドルＣ１４１を介して、ユーザによってあらかじめ設定されたＩＰアドレスとＴＣＰポートを用いてりＲ−ＯＳＧｉ連携を確立する。これによりアプリＯＳＧｉ１４上からコアＯＳＧｉ１３上のＯＳＧｉバンドルを利用することができるようになる。
（図６：ステップＳ６０３）
ＵＩ・起動管理プログラム１５はアプリＯＳＧｉ１４の実行状態を監視する。
（図６：ステップＳ６０４）
ＵＩ・起動管理プログラム１５は、アプリＯＳＧｉ１４がフリーズした場合はステップ６０５の処理に進み、不正終了した場合にはステップＳ６０６の処理に移る。
（図６：ステップＳ６０５）
ＵＩ・起動管理プログラム１５は、アプリＯＳＧｉ１４プロセスを終了させ、ステップＳ６０６に進む。
（図６：ステップＳ６０６＞
ＵＩ・起動管理プログラム１５は、アプリＯＳＧｉ１４を再起動する。

＜実施の形態１：まとめ＞
以上のように、本実施形態１に係るホスト１０は、コアＯＳＧｉ１３とアプリＯＳＧｉ１４を備え、コアＯＳＧｉ１３からアプリＯＳＧｉ１４へバンドルをエクスポートし、アプリＯＳＧｉ１４の動作を監視する。これにより、アプリＯＳＧｉ１４がコアバンドルの機能を利用しつつ、コアバンドルを実行するＯＳＧｉフレームワークとアプリバンドルを実行するＯＳＧｉフレームワークを分離することができるので、アプリバンドルの信頼性を確保できない場合でも、コアバンドルの信頼性を維持することができる。

また、本実施形態１に係るホスト１０は、コアバンドルとアプリバンドルをそれぞれＯＳＧｉバンドルとして実行するので、これらを個別のアプリケーションプロセスとして実行する場合と比較して、メモリ消費量を抑えることができる。

＜実施の形態２＞
実施形態１で説明した構成において、ＵＩ・起動管理プログラム１５の機能は、コアＯＳＧｉ１３の一部として組み込むこともできる。この場合、コアＯＳＧｉ１３は標準的なＯＳＧｉフレームワークとは異なるものとなる。

また、アプリＯＳＧｉ１４は必ずしも１つでなくともよい。アプリＯＳＧｉ１４が複数存在する場合は、ＵＩ・起動管理プログラム１５は各アプリＯＳＧｉ１４の動作を個別に監視する。

＜実施の形態３＞
実施形態１〜２では、ＵＩ・起動管理プログラム１５、コアＯＳＧｉ１３、アプリＯＳＧｉ１４を単一のホスト上で実行する例を説明したが、これらのうちいずれかを他の装置上で実行し、ネットワークを介して各装置を接続して実施形態１〜２と同様の動作を実現することもできる。本発明の実施形態３では、これら３つのプログラムをそれぞれ別の装置上で実行する構成例を説明する。

図７は、本実施形態３に係るＯＳＧｉシステムの構成図である。本実施形態３において、ＵＩ・起動管理プログラム１５、コアＯＳＧｉ１３、アプリＯＳＧｉ１４は、それぞれ管理装置１００、コアＯＳＧｉ装置２００、アプリＯＳＧｉ装置３００に分割して配置されている。各装置はネットワークを介して接続されている。

管理装置１００は、アプリＯＳＧｉ装置３００上で動作するアプリＯＳＧｉ１４の動作を監視する。例えば、アプリＯＳＧｉ１４の動作を監視するプログラムをアプリＯＳＧｉ装置３００上にインストールしておき、管理装置１００はこれを介してアプリＯＳＧｉ１４の動作を監視すればよい。管理装置１００の機能は、実施形態２と同様にコアＯＳＧｉ装置２００のコアＯＳＧｉ１３と統合することもできる。

コアＯＳＧｉ装置２００のコアＯＳＧｉ１３とアプリＯＳＧｉ装置３００のアプリＯＳＧｉ１４は、実施形態１〜２と同様にＲ−ＯＳＧｉを介してＯＳＧｉバンドルをエクスポート／インポートする。実施形態２と同様に、アプリＯＳＧｉ装置３００は複数設けることもできる。この場合、管理装置１００は各アプリＯＳＧｉ装置３００の動作を個別に監視する。

本発明は上記した実施形態に限定されるものではなく、様々な変形例が含まれる。上記実施形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施形態の構成の一部を他の実施形態の構成に置き換えることもできる。また、ある実施形態の構成に他の実施形態の構成を加えることもできる。また、各実施形態の構成の一部について、他の構成を追加・削除・置換することもできる。

上記各構成、機能、処理部、処理手段等は、それらの一部や全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリ、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の記録装置、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に格納することができる。

１０：ホスト、１１：ＯＳ、１２１〜１２３：ＪａｖａＶＭ、１３：コアＯＳＧｉ、１３１：コアバンドルＡ、１３２：コアバンドルＢ、１３３：Ｒ−ＯＳＧｉバンドルＳ、１４：アプリＯＳＧｉ、１４１：Ｒ−ＯＳＧｉバンドルＣ、１４２：コアバンドルＡ、１４３：コアバンドルＢ、１４４：アプリバンドルＸ、１４５：アプリバンドルＹ、１５：ＵＩ・起動管理プログラム、１００：管理装置、２００：コアＯＳＧｉ装置、３００：アプリＯＳＧｉ装置。

Claims (7)

1. ＯＳＧｉフレームワークを実行する装置であって、
   ＯＳＧｉフレームワークを実行する第１および第２ＯＳＧｉフレームワーク部と、
   前記第１および第２ＯＳＧｉフレームワーク部の動作を管理する管理部と、
   を備え、
   前記第１ＯＳＧｉフレームワーク部は、
   前記第１ＯＳＧｉフレームワーク部上で実行するＯＳＧｉバンドルを、前記第１ＯＳＧｉフレームワーク部上に残したまま前記第２ＯＳＧｉフレームワーク部へエクスポートするエクスポート部を備え、
   前記第２ＯＳＧｉフレームワーク部は、
   前記第１ＯＳＧｉフレームワーク部がエクスポートしたＯＳＧｉバンドルを前記第２ＯＳＧｉフレームワーク部上で実行するＯＳＧｉバンドルとしてインポートするインポート部を備え、
   前記管理部は、
   前記第２ＯＳＧｉフレームワーク部の稼動状態を監視し、前記第２ＯＳＧｉフレームワーク部が正常動作していない場合は、前記第２ＯＳＧｉフレームワーク部を再起動する
   ことを特徴とするＯＳＧｉ実行装置。
2. 前記管理部は、
   前記第２ＯＳＧｉフレームワーク部が実行するＯＳＧｉバンドルを呼び出すよう要求するリクエストを受け取り、前記第２ＯＳＧｉフレームワーク部から前記要求されたＯＳＧｉバンドルを呼び出し、
   前記第２ＯＳＧｉフレームワーク部から前記要求されたＯＳＧｉバンドルを呼び出すことができない場合は、その旨のエラーを前記リクエストの要求元へ送信する
   ことを特徴とする請求項１記載のＯＳＧｉ実行装置。
3. 前記第１ＯＳＧｉフレームワーク部が実行するＯＳＧｉバンドルの製作者と、前記第２ＯＳＧｉフレームワーク部が実行するＯＳＧｉバンドルのうち前記第１ＯＳＧｉフレームワーク部からインポートしたものを除くＯＳＧｉバンドルの製作者は、互いに異なる
   ことを特徴とする請求項１記載のＯＳＧｉ実行装置。
4. 前記第１ＯＳＧｉフレームワーク部が実行するＯＳＧｉバンドルの製作者を示すフィールドに記載されている値と、前記第２ＯＳＧｉフレームワーク部が実行するＯＳＧｉバンドルのうち前記第１ＯＳＧｉフレームワーク部からインポートしたものを除くＯＳＧｉバンドルの製作者を示すフィールドに記載されている値は、互いに異なる
   ことを特徴とする請求項３記載のＯＳＧｉ実行装置。
5. 前記ＯＳＧ実行装置は、複数の前記第２ＯＳＧｉフレームワーク部を備え、
   前記管理部は、各前記第２ＯＳＧｉフレームワーク部の動作を管理する
   ことを特徴とする請求項１記載のＯＳＧｉ実行装置。
6. 前記管理部は、前記第１ＯＳＧｉフレームワーク部の一部として構成されている
   ことを特徴とする請求項１記載のＯＳＧｉ実行装置。
7. ＯＳＧｉフレームワークを実行する第１および第２ＯＳＧｉ実行装置と、
   前記第１および第２ＯＳＧｉ実行装置の動作を管理する管理部と、
   を備え、
   前記第１ＯＳＧｉ実行装置は、
   前記第１ＯＳＧｉ実行装置のＯＳＧｉフレームワーク上で実行するＯＳＧｉバンドルを、前記第１ＯＳＧｉ実行装置のＯＳＧｉフレームワーク上に残したまま前記第２ＯＳＧｉ実行装置へエクスポートするエクスポート部を備え、
   前記第２ＯＳＧｉ実行装置は、
   前記第１ＯＳＧｉ実行装置がエクスポートしたＯＳＧｉバンドルを前記第２ＯＳＧｉ実行装置のＯＳＧｉフレームワーク上で実行するＯＳＧｉバンドルとしてインポートするインポート部を備え、
   前記管理部は、
   前記第２ＯＳＧｉ実行装置のＯＳＧｉフレームワークの稼動状態を監視し、前記第２ＯＳＧｉ実行装置のＯＳＧｉフレームワークが正常動作していない場合は、前記第２ＯＳＧｉ実行装置のＯＳＧｉフレームワークを再起動する
   ことを特徴とするＯＳＧｉシステム。

Images