(57)【要約】【課題】複数のサービスアプリケーションを動作可能なゲートウェイ装置において、アプリケーションサービスを安定的に動作させ、可用性を向上する。【解決手段】ゲートウェイ管理装置１０１からゲートウェイ装置１０９に新規にソフトウェアを配布する際に、ゲートウェイ管理装置１０１のアプリケーション配布管理部１０２が、ゲートウェイ装置１０９から、ゲートウェイ装置１０９のリソース量の情報を受信し、新規導入ソフトウェアの利用可能リソース量が該ゲートウェイ装置１０９で確保可能か否かをチェックし、確保可能な場合に限り、新規ソフトウェアを配布することで、ゲートウェイ装置１０９の可用性を向上する。【選択図】図1
2012064025.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーションサービス実行基盤を備えたゲートウェイ装置に対し、アプリケーションサービス実行ソフトウェアを配布するゲートウェイ管理装置であって、
前記アプリケーションサービス実行ソフトウェア各々が利用可能な前記ゲートウェイ装置のリソース量を管理するテーブルを備え、
前記ゲートウェイ装置に新規のソフトウェアを配布する際に、
前記ゲートウェイ装置の、前記アプリケーションサービス実行ソフトウェアが利用可能なリソース量の合計と、既に前記ゲートウェイ装置に導入済みのソフトウェアの利用可能なリソース量の合計とを取得し、
前記導入済みのソフトウェアの利用可能なリソース量の合計と前記新規ソフトウェアの利用可能なリソース量との合計と、前記アプリケーションサービス実行ソフトウェアが利用可能なリソース量の合計を比較し、
前記導入済みのソフトウェアの利用可能なリソース量の合計と前記新規ソフトウェアの利用可能なリソース量との合計が、前記アプリケーションサービス実行ソフトウェアが利用可能なリソース量を超えない場合に、前記新規ソフトウェアの配布を許可する、
ことを特徴とするゲートウェイ管理装置。
【請求項２】
請求項１に記載のゲートウェイ管理装置であって、
前記リソース量とは前記ゲートウェイ装置の中央処理部(以下、CPU)の使用率、または前記ゲートウェイ装置の記憶部（以下、メモリ）の使用量、またはその両方である、
ことを特徴とするゲートウェイ管理装置。
【請求項３】
請求項２に記載のゲートウェイ管理装置であって、
前記CPU使用率とは、最大利用可能CPU使用率である、
ことを特徴とするゲートウェイ管理装置。
【請求項４】
請求項２に記載のゲートウェイ管理装置であって、
前記メモリ使用量とは、ヒープメモリサイズ、または前記アプリケーションサービス実行ソフトウェアのソフトウェアプロセスのメモリ使用量、またはその両方である、
ことを特徴とするゲートウェイ管理装置。
【請求項５】
ゲートウェイ管理装置が配布するアプリケーションサービス実行ソフトウェアを実行するゲートウェイ装置であって、
中央処理部（以下、CPU）を含む処理部と、メモリを含む記憶部とを備え、
前記記憶部は、
前記アプリケーションサービス実行ソフトウェアを利用可能なリソース量の合計と、既に導入済みのソフトウェアを利用可能なリソース量の合計を保持し、
前記ゲートウェイ管理装置に新規のソフトウェアを要求する際、
前記処理部は、
前記記憶部に保持する、前記アプリケーションサービス実行ソフトウェアが利用可能なリソース量の合計と、前記既に導入済みのソフトウェアの利用可能リソース量の合計を前記ゲートウェイ管理装置に送信する、
ことを特徴とするゲートウェイ装置。
【請求項６】
請求項５に記載のゲートウェイ装置であって、
前記リソース量とは前記CPUの使用率、または前記メモリの使用量、またはその両方である、
ことを特徴とするゲートウェイ装置。
【請求項７】
請求項６に記載のゲートウェイ装置であって、
前記CPUの使用率とは、最大利用可能CPU使用率である、
ことを特徴とするゲートウェイ装置。
【請求項８】
請求項６に記載のゲートウェイ装置であって、
前記メモリの使用量とは、ヒープメモリのサイズまたは前記アプリケーションサービス実行ソフトウェアのソフトウェアプロセスのメモリ使用量、またはその両方である、
ことを特徴とするゲートウェイ装置。
【請求項９】
請求項５に記載のゲートウェイ装置であって、
前記処理部は、前記アプリケーションサービス実行ソフトウェアを導入、実行する複数のアプリケーション実行部と、前記アプリケーション実行部を管理するアプリケーション管理部とから構成される、
ことを特徴とするゲートウェイ装置。
【請求項１０】
請求項９に記載のゲートウェイ装置であって、
前記アプリケーション管理部は、
前記アプリケーション実行部各々が導入、実行するソフトウェアを利用可能なリソース量の合計を、前記既に導入済みのソフトウェアの利用可能リソース量の合計として管理する、
ことを特徴とするゲートウェイ装置。
【請求項１１】
アプリケーションサービス実行基盤を有するゲートウェイ装置に対しアプリケーションサービス実行ソフトウェアを配布するゲートウェイ管理装置を備えたシステムであって、
前記アプリケーションサービス実行ソフトウェア各々が利用可能な前記ゲートウェイ装置のリソース量を管理し、
前記ゲートウェイ管理装置は、前記ゲートウェイ装置に新規のソフトウェアを配布する際に、
前記ゲートウェイ装置から、前記アプリケーションサービス実行ソフトウェアが利用可能なリソース量の合計と、前記ゲートウェイ装置に既に導入済みのソフトウェアの利用可能リソース量の合計を取得し、
前記既に導入済みのソフトウェアの利用可能リソース量との合計と前記新規ソフトウェアの利用可能リソース量との合計と、前記アプリケーションサービス実行ソフトウェアが利用可能なリソース量の合計とを比較し、
前記既に導入済みのソフトウェアの利用可能リソース量と前記新規ソフトウェアの利用可能リソース量との合計が、前記アプリケーションサービス実行ソフトウェアが利用可能なリソース量の合計を超えない場合に、前記新規ソフトウェアの前記ゲートウェイ装置への配布を許可する、
ことを特徴とするシステム。
【請求項１２】
請求項１１に記載のシステムであって、
前記ゲートウェイ装置の前記アプリケーション実行基盤は、
前記アプリケーションサービス実行ソフトウェアを導入、実行する複数のアプリケーション実行部と、前記アプリケーション実行部を管理するアプリケーション管理部とから構成される、
ことを特徴とするシステム。
【請求項１３】
請求項１２に記載のシステムであって、
前記アプリケーション管理部は、
前記アプリケーション実行部が導入、実行する前記アプリケーションサービス実行ソフトウェアが利用可能なリソース量を管理する、
ことを特徴とするシステム。
【請求項１４】
請求項１３に記載のシステムであって、
前記アプリケーション管理部は、
前記アプリケーション実行部が実行する前記アプリケーションサービス実行ソフトウェアが利用可能リソース量を超過した場合には、前記ゲートウェイ管理装置に当該超過を通知する、
ことを特徴とするシステム。
【請求項１５】
請求項１１に記載のシステムであって、
前記ゲートウェイ装置の前記アプリケーション実行基盤は、
アプリケーションサービス間における機能の公開（Ｅｘｐｏｒｔ）および呼び出し（Ｉｍｐｏｒｔ）に関するテーブルを保持し、
前記アプリケーションサービス実行ソフトウェアが利用可能リソース量を超過した場合に前記テーブルを参照し、前記超過した原因が、前記アプリケーションサービス実行ソフトウェア自身にあるか、前記アプリケーションサービス実行ソフトウェアが公開する機能を呼び出す他のアプリケーションサービス実行ソフトウェアにあるかを調査する、
ことを特徴とするシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ゲートウェイ管理装置、ゲートウェイ装置、およびシステムに関し、特に、ゲートウェイ装置の利用者が新規にアプリケーションサービスを導入する際に、ゲートウェイ装置が安定的に動作可能とするゲートウェイ管理技術に関する。
【背景技術】
【０００２】
従来、ホームネットワークに接続した機器を制御するホームネットワークシステムは、ホームネットワークを介して接続され、ＵＰｎＰ(Universal Plug and Play)やエコーネット（ＥＣＨＯＮＥＴ）といった標準プロトコルを実装した２つ以上の機器間で互いに制御を行うものが提案または実現されている。
【０００３】
しかし、従来のホームネットワークシステムでは、異なるプロトコルに対応した機器間では通信ができず、また、システム導入以降にシステムを拡張したくても、あらかじめ機器に搭載されていたアプリケーションが持つ機能以外については拡張ができないという問題がある。
【０００４】
そのため、近年、ＨＡＶｉ(Home Audio/Video Interoperability)，ＵＰｎＰ，Ｊｉｎｉ，ＨＷＷ（Home Wide Web）といったホームネットワークミドルウェアを統合支援するフレームワークを介して宅内の被制御機器へのアプリケーションのインストールおよび管理を行うことにより、ホームネットワークミドルウェアに制約されることなく、ホームネットワーク環境で家電機器の機能を動的に拡張できる手段が提案されている。例えば、特許文献１、特許文献２、特許文献３を参照されたい。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００４−２１３６１２号公報
【特許文献２】特開２００７−３１６９４７号公報
【特許文献３】特開２００８−０１５９５４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
特許文献１におけるホームネットワークシステムは、各種ホームネットワークミドルウェアを統合支援するOSGi（OSGiは登録商標）フレームワークを搭載したゲートウェイ装置などのアプリケーションサーバを導入し、種々のデバイスへアクセスするためのミドルウェアサービスをバンドル機能として提供することにより、ミドルウェアに制約されないホームネットワークシステムを実現する。
【０００７】
しかしながら、特許文献１に記載のOSGiフレームワークには様々なソフトウェア部品（OSGiバンドルと呼ぶ）を単一のソフトウェアプロセス上で動作するフレームワーク上で動作させることから、個別のOSGiバンドルがどの程度の中央処理部（Central Processing Unit：CPU）、メモリ等のリソースを消費するかを詳細に知ることができないという問題がある。
【０００８】
この問題に対し、特許文献２には、複数のゲートウェイがもつリソースの消費量についての解析結果を得る管理システムの動作方法であって、前記ゲートウェイのそれぞれから、該ゲートウェイで検出された消費量を示す消費量情報と、検出のときに当該ゲートウェイで実行されていたプログラムを示す実行プログラムリストとを取得し、平均消費量を含むレコードを作成する管理システムの動作方法が開示されている。
【０００９】
また、特許文献３には、サービス事業者ごとに利用可能なメモリの上限を管理し、アプリケーション起動時にJava（Javaは登録商標）の起動オプションにてヒープの上限値に設定することで設定値以上のメモリを該アプリケーションが利用できないようにする方法が開示されている。
【００１０】
しかしながら、特許文献２に示される方法では、複数のプログラムが消費するリソースと実行プログラムリストを複数のゲートウェイ装置から収集することで各々のプログラムが消費するリソースの平均消費量を求める方法が開示されているが、その情報を元に安定的にゲートウェイ装置を動作させる方法は着目する範囲外であり言及がない。また、複数のプログラムを単一のソフトウェアプロセスで動作させるアプリケーション実行基盤を用いる場合には、該アプリケーション実行基盤上で動作する複数のプログラムのうち、障害の原因となったものがどれであるかについて解析することが難しく、その方法は開示されていない。
【００１１】
また、特許文献３に示される方法では、複数のサービス事業者が提供するソフトウェア間において、互いにその動作を妨げないことが主な観点となっているため、リソース管理の観点において、メモリ使用量についてしか言及がなく、ゲートウェイ装置の安定動作という点においては着目範囲が狭い。また、Javaプログラムについては、ヒープサイズの上限しか着目していないため、例えばJavaの仮想マシーン（Virtual Machine：VM）が利用するメモリ量については言及がない。
【００１２】
本発明の目的は、ゲートウェイ装置において、ゲートウェイ管理装置から新規にソフトウェアを配布する際に、ゲートウェイ装置の可用性を向上するゲートウェイ管理装置およびゲートウェイ装置およびシステムを提供することにある。
【課題を解決するための手段】
【００１３】
上記目的を達成するため、本発明においては、アプリケーションサービス実行基盤を備えたゲートウェイ装置に対し、アプリケーションサービス実行ソフトウェアを配布するゲートウェイ管理装置であって、アプリケーションサービス実行ソフトウェア各々が利用可能なゲートウェイ装置のリソース量を管理するテーブルを備え、ゲートウェイ装置に新規のソフトウェアを配布する際に、ゲートウェイ装置の、アプリケーションサービス実行ソフトウェアが利用可能なリソース量の合計と、既にゲートウェイ装置に導入済みのソフトウェアの利用可能なリソース量の合計を取得し、導入済みのソフトウェアの利用可能なリソース量の合計と新規ソフトウェアの利用可能なリソース量との合計と、アプリケーションサービス実行ソフトウェアが利用可能なリソース量の合計を比較し、導入済みのソフトウェアの利用可能なリソース量の合計と新規ソフトウェアの利用可能なリソース量との合計が、アプリケーションサービス実行ソフトウェアが利用可能なリソース量の合計を超えない場合に、新規ソフトウェアの配布を許可する構成のゲートウェイ管理装置を提供する。
【００１４】
また、上記目的を達成するため、本発明においては、アプリケーションサービス実ゲートウェイ管理装置が配布するアプリケーションサービス実行ソフトウェアを実行するゲートウェイ装置であって、中央処理部（以下、CPU）を含む処理部と、メモリを含む記憶部とを備え、記憶部は、アプリケーションサービス実行ソフトウェアを利用可能なリソース量の合計と、既に導入済みのソフトウェアを利用可能なリソース量の合計を保持し、ゲートウェイ管理装置に新規のソフトウェアを要求する際、処理部は、保持するアプリケーションサービス実行ソフトウェアが利用可能なリソース量の合計と、既に導入済みのソフトウェアの利用可能リソース量の合計をゲートウェイ管理装置に送信する構成のゲートウェイ装置を提供する。
【００１５】
更に、上記の目的を達成するため、本発明においては、アプリケーションサービス実行基盤を有するゲートウェイ装置に対しアプリケーションサービス実行ソフトウェアを配布するゲートウェイ管理装置を備えたシステムであって、アプリケーションサービス実行ソフトウェア各々が利用可能なゲートウェイ装置のリソース量を管理し、ゲートウェイ管理装置は、ゲートウェイ装置に新規のソフトウェアを配布する際に、ゲートウェイ装置から、アプリケーションサービス実行ソフトウェアが利用可能なリソース量の合計と、ゲートウェイ装置に既に導入済みのソフトウェアの利用可能リソース量の合計を取得し、既に導入済みのソフトウェアの利用可能リソース量の合計と新規ソフトウェアの利用可能リソース量との合計と、アプリケーションサービス実行ソフトウェアが利用可能なリソース量の合計とを比較し、既に導入済みのソフトウェアの利用可能リソース量の合計と新規ソフトウェアの利用可能リソース量との合計が、アプリケーションサービス実行ソフトウェアが利用可能なリソース量の合計を超えない場合に、新規ソフトウェアの配布を許可する構成のシステムを提供する。
【発明の効果】
【００１６】
本発明によれば、ゲートウェイ装置に新規にアプリケーションサービス実行ソフトウェアを配布する際に、アプリケーションサービスを安定的に動作させ、ゲートウェイ装置の可用性を向上するゲートウェイ管理装置を実現することができる。
【図面の簡単な説明】
【００１７】
【図１】第１の実施例における機能構成およびネットワーク構成の一例を表す図である
【図２】第１の実施例におけるゲートウェイ管理装置およびゲートウェイ装置のハードウェア構成の一例を示す図である
【図３】第１の実施例に係る、アプリケーションサービス全体が利用可能なリソース量を示すテーブルの一例を示す図である
【図４】第１の実施例に係る、個別のアプリケーションサービスが利用可能なリソースを管理するテーブルの一例を示す図である。
【図５】第１の実施例に係る、個別のアプリケーションサービスが利用可能なリソースを管理するテーブルの一例を示す図である。
【図６Ａ】第１の実施例に係る、サービスがゲートウェイ装置に導入されるまでの手順を示したフローチャート（その１）を示す図である。
【図６Ｂ】第１の実施例に係る、サービスがゲートウェイ装置に導入されるまでの手順を示したフローチャート（その２）を示す図である。
【図７】第１の実施例に係る、サービスアプリケーションの起動処理の手順を示すフローチャート図である。
【図８】第１の実施例に係る、サービスアプリケーション間の依存関係を管理するテーブルの一例を示す図である。
【図９】第１の実施例に係る、ゲートウェイ装置に導入したサービスアプリケーション間の依存関係を管理するテーブルの一例を示す図である。
【図１０】第１の実施例に係る、サービスアプリケーションに対応するプロセスIDを管理するテーブルの一例を示す図である。
【図１１】第１の実施例に係る、画面表示の一例を示す図である。
【図１２】第１の実施例に係る、画面表示の他の例を示す図である。
【図１３】第１の実施例における機能構成の一例を示す図である。
【図１４】第１の実施例に係る、サービスアプリケーションの起動処理の手順を示すフローチャート図である。
【図１５】第１の実施例に係る、サービスアプリケーションのメモリ使用量を監視する手順を示すフローチャート図である。
【図１６】第１の実施例に係る、サービスアプリケーションのCPU使用率を監視する手順を示すフローチャート図である。
【図１７】第１の実施例に係る、図６に示した新規サービス導入処理を示すフローチャートに対応するシーケンス図である。
【図１８】第１の実施例に係る、サービスアプリケーションが利用可能リソース量を超過した際に、ゲートウェイ管理装置に異常を通知する手順の一例を示すフローチャート図である。
【図１９】サービスアプリケーションが利用可能リソース量を超過した際に、ゲートウェイ管理装置に異常を通知する手順の他の例を示すフローチャート図である。
【発明を実施するための形態】
【００１８】
以下、本発明の実施形態について図面を参照して説明する。
【実施例１】
【００１９】
第１の実施例は、ゲートウェイ管理装置とサービス事業者サーバとゲートウェイ装置とが外部ネットワークを介して接続されたゲートウェイ管理システムである。図１に第１の実施例における機能構成およびネットワーク構成の一例を示す図である。
【００２０】
図１において、符号101はゲートウェイ管理装置、符号102はアプリケーション配布管理部、符号103はDB管理部、符号104はサービス管理DB、符号105は必要リソーステーブル、符号106は外部ネットワーク、符号107はサービス事業者サーバ、符号108は利用者宅、符号109はゲートウェイ装置、符号110はアプリケーション実行部、符号111はサービスアプリケーション、符号112はアプリケーション管理部、符号113は全体利用可能リソーステーブル、符号114は利用可能リソーステーブル、符号115は利用者宅内ネットワーク、符号116は宅内機器、符号117は依存関係テーブル、符号118は導入サービスアプリケーション依存関係管理テーブル、符号119はプロセスID管理テーブルである。
【００２１】
ゲートウェイ管理装置101とサービス事業者サーバ107とゲートウェイ装置109は光通信などを利用した閉域網、またはインターネットからなる外部ネットワーク106と接続しており、所定の手順に従って情報のやり取りを行うことができる。
【００２２】
ゲートウェイ装置109と宅内機器116は利用者宅108内に設置され、有線または無線から構成される利用者宅内ネットワーク115と接続しており、所定の手順に従って情報のやり取りを行うことができる。
【００２３】
ゲートウェイ装置109は外部ネットワーク106と利用者宅内ネットワーク115の両方と接続しているおり、利用者宅108に設置された機器にとって、外部ネットワーク106に接続された機器と情報のやり取りをするためのゲートウェイとしての機能を有する。
【００２４】
図２はゲートウェイ管理装置101およびゲートウェイ装置109のハードウェア構成の一例を示す図である。
【００２５】
この図において、符号202はイーピーロム（Erasable Programmable ROM：EPROM）、符号203は中央処理部(Central Processing Unit：CPU)、符号204はメインメモリ、符号205はバス、符号206は周辺制御装置、符号207は不揮発性記憶装置、符号208はネットワークI/Fである。また、符号211はEPROM、符号212はCPU、符号213はメインメモリ、符号214はバス、符号215はネットワークI/F、符号216は周辺制御装置、符号217はネットワークI/F、符号218は不揮発性記憶装置である。メインメモリ204、213、不揮発性記憶装置207、218はそれぞれの装置の記憶部を構成する。
【００２６】
EPROM202、CPU203、メインメモリ204、周辺制御装置206はバス205と接続し、不揮発性記憶装置207、ネットワークI/F208は周辺制御装置206を介してバス205と接続しており、所定の手順に従って情報のやり取りを行うことができる。EPROM211、CPU212、メインメモリ213、周辺制御装置216はバス214と接続し、ネットワークI/F215、ネットワークI/F217、不揮発性記憶装置218は周辺制御装置216を介してバス214と接続しており、所定の手順に従って情報のやり取りを行うことができる。
【００２７】
EPROM202にはブートプログラムが格納されている。また、不揮発性記憶装置207には各種プログラムが記憶されている。ゲートウェイ管理装置101が起動するとEPROM202に格納されたブートプログラムによって不揮発性記憶装置207から各種プログラムがメインメモリ204へと読み出される。CPU203はメインメモリ204に読み出された各種プログラムを実行することにより、ネットワークI/F208への信号の送受信を行う。
【００２８】
EPROM211にはブートプログラムが格納されている。また、不揮発性記憶装置218には各種プログラムが記憶されている。ゲートウェイ装置109が起動するとEPROM211に格納されたブートプログラムによって不揮発性記憶装置218から各種プログラムがメインメモリ213へと読み出される。CPU212はメインメモリ213に読み出されたサービスアプリケーション等の各種プログラムを実行することにより、ネットワークI/F215やネットワークI/F217への信号の送受信を行う。
【００２９】
ネットワークI/F208は外部ネットワーク106と接続しており、外部ネットワーク106に接続する機器との間で情報のやり取りを行うことができる。ネットワークインターフェース(I/F)208はネットワークカード等により実現することができる。
【００３０】
不揮発性記憶装置207には、上述のようにCPU203 がメインメモリ204に読み出して実行するための各種プログラムが記憶されており、フラッシュメモリやハードディスクドライブ(Hard Disk Drive：HDD）により実現することができる。
【００３１】
ネットワークI/F215は外部ネットワーク106と接続しており、外部ネットワーク106に接続する機器との間で情報のやり取りを行うことができる。ネットワークI/F215はネットワークカード等により実現することができる。
【００３２】
ネットワークI/F217は利用者宅内ネットワーク115と接続しており、利用者宅内ネットワーク115に接続する機器との間で情報のやり取りを行うことができる。ネットワークI/F217はネットワークカード等により実現することができる。
【００３３】
不揮発性記憶装置218には、上述のようにCPU212 がメインメモリ213に読み出して実行するための各種プログラムが記憶されており、フラッシュメモリやHDD（ハードディスクドライブ）により実現することができる。
【００３４】
次に、本実施例において、ゲートウェイ管理装置101、ゲートウェイ装置109が扱うテーブル情報について説明する。
【００３５】
図３は全体利用可能リソーステーブル300の一例を示す図である。全体利用可能リソーステーブル300には全体利用可能CPU使用率301、全体利用可能メモリ量302といった項目がある。
【００３６】
図４は利用可能リソーステーブル400の一例を示す図である。利用可能リソーステーブル400には識別子(ID)401、利用可能ヒープメモリ量402、利用可能メモリ量403、利用可能CPU使用率404といった項目がある。ここでヒープメモリとは、Javaのヒープメモリのように、OSやアプリケーションソフトが使用するために、動的に確保可能なメモリ領域を示す。
【００３７】
図５は必要リソーステーブル500の一例を示す図である。必要リソーステーブル500にはID501、必要ヒープメモリ量502、必要メモリ量503、必要CPU使用率504といった項目がある。
【００３８】
図８は依存関係テーブル800の一例を示す図である。依存関係テーブル800にはID801、Import-Package802、Export-Package803といった項目がある。804〜809はそれらの例示である。
【００３９】
図９は導入サービスアプリケーション依存関係管理テーブルを示す図である。導入サービスアプリケーション依存関係管理テーブルには、ID901、Import-Package902、Export-Package903といった項目がある。904〜906はそれらの例示である。
【００４０】
図１０はプロセスID管理テーブルの一例を示す図である。プロセスID管理テーブルにはID1001、プロセスID1002といった項目がある。1003〜1005はそれらの例示である。
【００４１】
次に本実施例のゲートウェイ管理システムの動作について説明する。
【００４２】
本実施例におけるゲートウェイ装置109は、様々なサービスアプリケーション111を実行するアプリケーション実行部110を備える。このアプリケーション実行部110は、先に説明したように図２のCPU212が各種のサービスアプリケーションを実行することによって実現されることは言うまでもない。
【００４３】
アプリケーション実行部110は、例えば、上述したOSGiフレームワークのようなアプリケーション実行基盤を用いて実現することができ、ゲートウェイ管理装置101が配布するサービスアプリケーション111を実行することにより、様々な宅内機器116を利用者宅内ネットワーク115を介して制御可能とするなど、ゲートウェイ装置109の機能を柔軟に拡張することを可能とする。
【００４４】
ゲートウェイ管理装置101は様々なサービス事業者サーバ107を保持するサービス事業者が提供するサービスアプリケーションを、ゲートウェイ装置109へ外部ネットワーク106を介して配布するサービスサービスアプリケーション配布基盤としての機能を有している。これにより、様々なサービス事業者サーバ107を保持するサービス事業者は作成したサービスアプリケーション111の配布をゲートウェイ管理装置101へ委託することにより、サービスアプリケーション配布サーバ等を自身で設置したり、アプリケーション実行部110を備えたゲートウェイ装置等を自ら利用者へ配布することが必要がなくなり、コストを抑えてサービス提供を行うことが可能となる。
【００４５】
アプリケーション実行部110としてOSGiフレームワークを用いる場合、通常OSGiフレームワークは、単一のフレームワーク上で複数のサービスアプリケーションを実行することが可能であるが、本実施例では、サービスアプリケーションそれぞれが利用するゲートウェイ装置のCPU処理時間（CPU使用率）や利用メモリ量といったリソースを詳細に制御するために、サービスアプリケーションごとに別個にアプリケーション実行部110を起動することを想定する。
【００４６】
OSGiフレームワークのようなアプリケーション実行基盤は、様々なサービスアプリケーション間でお互いの機能を適切に呼び合うことを可能とする。例えば、OSGiサービスプラットフォーム仕様が標準で規定するＨＴＴＰサービスはＷＥＢサーバおよびサーブレットコンテナの機能を有し、サーブレットとして実装された他のサービスアプリケーションは、ＨＴＴＰサービスが提供するサーブレットコンテナ機能に自身を登録することにより、サービスアプリケーションを提供するサービス事業者は簡単にＷＥＢサーバおよびサーブレットコンテナの機能を利用することができる。
【００４７】
アプリケーション実行部110をサービスアプリケーションごとに起動した場合、通常上記のようなサービスアプリケーション間の連携機能は使用できなくなってしまうが、OSGiサービスプラットフォーム仕様Ｒ４．２にはＨＴＴＰサービスと同様の標準サービスとしてリモートサービスの仕様が追加されている。リモートサービスはOSGiの核となるサービスのＩｍｐｏｒｔ／Ｅｘｐｏｒｔ機能を異なるJavaVM上で動作するOSGiフレームワークと共有することを可能とする。
【００４８】
本実施例においては、特にことわりのない限り、アプリケーション実行部110はOSGiフレームワークを用いて実現され、アプリケーション実行部110は、様々なサービスアプリケーション111ごとにアプリケーション管理部112によって異なるJavaVMなどの異なるソフトウェアプロセス上で実行され、起動した複数のアプリケーション実行部110間はOSGiサービスプラットフォームの標準サービスである、リモートサービスを用いて互いに連携可能であることを想定する。
【００４９】
また、本実施例においては、サービスアプリケーションは1つまたは複数のプログラム(ソフトウェア部品、OSGiバンドルと言う)からなる。本実施例においては、1つのアプリケーション実行部では1つのサービスアプリケーションが動作することを想定する。ただし、1つのアプリケーション実行部で複数のサービスアプリケーションを実行することも可能である。例えば、サービスアプリケーションの提供事業者ごとに同一のアプリケーション実行部を利用するということも可能である。
【００５０】
本実施例において、CPU使用率、メモリ使用量といったリソースの管理を行うことができるのはアプリケーション実行部ごとである。例えば上記のように、サービスアプリケーションの提供事業者ごとに同一のアプリケーション実行部を利用する場合、利用可能なリソース量を超過した場合には該サービスアプリケーション提供事業者の提供するサービスアプリケーションのいずれかに問題があるであろう、ということまで分かる。
【００５１】
1つのアプリケーション実行部で複数のサービスアプリケーションを実行すると、ゲートウェイ装置全体におけるアプリケーション実行部を実現するプログラムであるＪａｖａＶＭやOSGiフレームワーク等の実行数が減少し、その分機器全体でのメモリ使用量等を節約することができるという効果があるが、本実施例では説明を簡便にするために1つのアプリケーション実行部では1つのサービスアプリが動作することを想定する。
【００５２】
また、本実施例におけるゲートウェイ装置109は、アプリケーション実行部110の実行されるソフトウェアプロセスそれぞれのCPU使用率、メモリ使用量、Ｊａｖａのヒープメモリ使用量の上限値を適切に制御可能な構成を想定する。
【００５３】
例えば、ゲートウェイ装置109のOS（Operation System）がＬｉｎｕｘ(Ｌｉｎｕｘは登録商標)である場合、ソフトウェアプロセスのCPU使用率はCABI（CPU Accounting and Blocking Interface）のようなCPUリソースマネジメントシステムを用いて制御が可能である。CABIはある周期におけるCPU使用時間の上限値を設定することが可能で、例えば、あるソフトウェアプロセスに対し、周期が100ms、CPU使用時間の上限値が30msといったCABIのアカウンティングオブジェクト(Accounting Object：AO）を設定した場合、100msの間に30msCPUを利用するとCPUの利用をブロックされ、CPUリソースが他のプロセスへと開放される。本実施例においては、特にことわりのない限り、ゲートウェイ装置のOSはLinuxであり、CPUリソースマネジメントにはCABIを用いることを想定するが、例えばその他のリアルタイムOS等においても同様の仕組みを用いて実現が可能な場合がある。
【００５４】
また、例えば、ゲートウェイ装置109のOSがＬｉｎｕｘである場合、ソフトウェアプロセスのメモリ使用量はCABI-DMEL（Common resource management Accounting and Blocking Interfaces - Dependable Memory management system for Embedded Linux）のようなメモリリソースマネジメントシステムを用いて制御が可能である。CABI-DMELはあるソフトウェアプロセスに対する物理メモリの割り当ての上限制限する事が可能であり、上限値以上のメモリを確保しようとした場合にメモリ割り当てをブロックすることができる。本実施例においては、特にことわりのない限り、ゲートウェイ装置のOSはLinuxであり、メモリリソースマネジメントにはCABI-DMELを用いることを想定するが、例えばその他のOS等においても同様の仕組みを用いて実現が可能な場合がある。
【００５５】
また、本実施例ではアプリケーション実行部110はOSGiフレームワークを用いて実現されることを想定するが、OSGiフレームワークはJavaVMを用いて起動される。JavaVMは実行するプログラムの利用可能なヒープメモリの上限を指定することが可能であり、設定した上限値以上のヒープメモリの利用をブロックすることができる。
【００５６】
図１３は、第１の実施例に係るアプリケーション実行部110を実現するプログラムとしてJavaVM、OSGiフレームワーク、OSGiの標準サービスであるリモートサービスバンドルを用いた場合のゲートウェイ装置の機能構成図である。同図において、図１他に示された数番と同じ数番を有するものは同一のものを示す。同図中、ゲートウェイ装置109は、その機能構成として、基本機能130、アプリケーション実行基盤としてのアプリケーション機能131、テーブル類135を備え、基本機能130は、通常の家庭用のゲートウェイ装置としての機能である電話部、インターネット接続部、映像受信部を備える。これらの基本機能130は本実施例の動作に直接関係しないので、説明を省略する。
【００５７】
アプリケーション実行基盤であるアプリケーション機能131は、アプリケーション管理部112に加え、上述した複数のアプリケーション実行部110を備え、各アプリケーション実行部110は、サービスアプリケーション111と、リモートサービスバンドル132、OSGi Framework133、JavaVM134を備える。アプリケーション実行基盤であるアプリケーション機能131内のテーブル類135は、図１で説明した各種のテーブル113、114、118、119が存在する。
【００５８】
本実施例においては、上述の通り、サービスアプリケーション111を実行するごとにJavaVM134とOSGiフレームワーク133が起動しており、各OSGiフレームワーク133上でリモートサービスバンドル132が動作し、それぞれのアプリケーション実行部110のOSGiフレームワーク133上において各サービスアプリケーション111が動作している。
【００５９】
図１３に模式的に示したように、OSGiは通常、同一のJavaVM上で動作するOSGiフレームワーク133上で動作するプログラムであるリモートサービスバンドル132間においてお互いの機能、サービスを呼び合う事ができるが、リモートサービス（フレームワーク間連携機能）を用いると、異なるJavaVM上で動作するOSGiフレームワーク間で機能、サービスの情報をやり取りすることができ、リモートサービスバンドル132が導入されたOSGiフレームワーク133上で実行されるサービスアプリケーション111は、異なるアプリケーション実行部110で動作するサービスアプリケーションの機能、サービスを相互に利用することが可能となる。
【００６０】
なお、各アプリケーション実行部110の起動処理等の管理はアプリケーション管理部112が行う。
【００６１】
図６Ａ、図６Ｂは第１の実施例のシステムにおける新規サービス導入処理の一例を示す図である。これは、ユーザが選択したサービスがゲートウェイ管理装置101を介して、ゲートウェイ装置109に導入されるまでの手順を示したフローチャートである。本実施例のシステムおいては、新規サービス導入処理の可否判断は、ゲートウェイ管理装置101が実行するが、これに限定されるものでなく、ゲートウェイ装置109が実行することも可能である。なお、図示の都合上、図６Ａと図６Ｂとは分割したが、丸１において連続する一連のフローチャートである。
【００６２】
図６Ａのステップ601はサービス利用者がゲートウェイ装置109を介してゲートウェイ管理装置101に接続し、新規導入を希望するサービスアプリケーション111を選択し、ゲートウェイ管理装置101が該アプリケーションのID(A)を得る処理である。
【００６３】
ステップ602はゲートウェイ管理装置101の指示により、ゲートウェイ装置109がゲートウェイ管理装置101へ、図３の全体利用可能リソーステーブル300に記載の情報(B)、および図４の利用可能リソーステーブル400に記載のIDの一覧(C)を送信する処理である。
【００６４】
ステップ603はゲートウェイ管理装置101が、AのIDとCのID一覧と、図８の依存関係管理テーブル800に記載の情報(D)を用いて、ゲートウェイ装置109に導入するサービスアプリケーション111のIDの一覧(E)を抽出する処理である。
【００６５】
ステップ604はゲートウェイ管理装置101が、図５の必要リソーステーブル500に記載の必要メモリ量、必要CPU使用率のそれぞれについて、CのID一覧に対応する必要メモリ量、必要CPU使用率それぞれの合計(F)と、EのID一覧に対応する必要メモリ量、必要CPU使用率それぞれの合計(G)を抽出する処理である。
【００６６】
ステップ605はゲートウェイ管理装置101が、新規サービス導入した場合にゲートウェイ装置のメモリ量、CPU使用率それぞれについて全体利用可能リソース量を超えないことを確認、すなわち、必要メモリ量、必要CPU使用率それぞれについて、Fの値とGの値の和がBにおける全体利用可能メモリ量、全体利用可能CPU使用率の値を超えないかどうかを確認する処理である。
【００６７】
図６Ｂのステップ606はメモリ量、CPU使用率それぞれについてF+G<Bが成立かどうか調べる処理である。もしメモリ量、CPU使用率それぞれについてF+G<Bが成立であれば、ステップ607へ進む。もしメモリ量、CPU使用率それぞれについてF+G<Bが成立でなければ、ステップ611へ進む。
【００６８】
ステップ607はゲートウェイ管理装置101が、ゲートウェイ装置109を介してサービス利用者に、新規導入を希望したサービスアプリケーション111を導入可能である事を提示する処理である。
【００６９】
ステップ608はゲートウェイ管理装置101が、ゲートウェイ装置109へ、該新規導入サービスアプリケーション111および必要リソーステーブル500の情報のうち該サービスアプリケーション111のIDに対応する情報(H)、および依存関係管理テーブル800の情報のうち該サービスアプリケーション111のIDに対応する情報(I)を送信する処理である。
【００７０】
ステップ609はゲートウェイ装置109が、Hの情報を、図４の利用可能リソーステーブル400に、Iの情報を、図９の導入サービスアプリケーション依存関係テーブル900に追記する処理である。
【００７１】
ステップ610はゲートウェイ装置109が、該サービスアプリケーション111を起動する処理である。
【００７２】
ステップ611はゲートウェイ管理装置101が、ゲートウェイ装置109を介してサービス利用者に、新規導入を希望したサービスアプリケーション111の導入が不可である事を提示する処理である。
【００７３】
以上説明した図６Ａ、図６Ｂにおけるステップ604において、メモリ使用量として必要メモリ量を用いたが、必要リソーステーブル500に必要メモリ量の記載がなく、必要ヒープメモリ量のみが記載されている場合などはメモリ使用量として必要ヒープメモリ量を用いてもよい。また、必要ヒープメモリ量はJavaVM自身が利用するメモリ量等を含まないが、JavaVMが利用するであろうメモリ量をある程度見込んで、それをメモリ使用量として利用してもよい。例えば、必要ヒープメモリ量と同量のメモリをJavaVMが利用するとして、必要ヒープメモリ量の2倍を必要メモリ量とする、などしてもよい。
【００７４】
続いて、図７は本実施例のシステムにおけるゲートウェイ装置109のサービスアプリケーション起動処理を示す図である。これは、サービスアプリケーションの起動処理の手順を示すフローチャートである。
【００７５】
同図において、ステップ701はアプリケーション管理部112が、図４の利用可能リソーステーブル400から、起動するサービスアプリケーション111のIDに対応する利用可能ヒープメモリ量、利用可能メモリ量、利用可能CPU使用率を取得する処理である。
【００７６】
ステップ702はアプリケーション管理部112が、CABIのAPIを用いて、該利用可能CPU使用率の値に関するアカウンティングオブジェクト(AO)を生成する処理である。
【００７７】
ステップ703はアプリケーション管理部112が、CABI-DMELのAPIを用いて、該利用可能メモリ量の値に関するアカウンティングオブジェクト(AO)を生成する処理である。
【００７８】
ステップ704はアプリケーション管理部112が、JavaVMの起動オプションの最大ヒープ量に該利用可能ヒープメモリ量を設定してOSGiフレームワークであるアプリケーション実行部110を起動し、該OSGiフレームワークに該サービスアプリケーションをインストールおよび実行する処理である。
【００７９】
ステップ705はアプリケーション管理部112が、該サービスアプリケーションを実行したソフトウェアプロセスのプロセスIDを調査、取得する。アプリケーション管理部112が、該プロセスIDをCABIおよびCABI-DMELのアカウンティングオブジェクト(AO)にバインドする処理である。
【００８０】
ステップ706は該サービスアプリケーション111のIDおよび該プロセスIDをプロセスID管理テーブル1000に記憶する処理である。
【００８１】
ここで、CABI、CABI-DMELの動作について簡単に説明する。CABIは周期とCPU使用時間をパラメータにアカウンティングオブジェクトを作成し、そのアカウンティングオブジェクトに制御したいプロセスをバインドする。例えば、利用可能CPU使用率が20％の場合、周期100ms、CPU使用時間20msなどと記述する。
【００８２】
通常Linuxのような非リアルタイムOSにおいては、CPUに余力がある場合、優先度の低いプロセスであっても多くのCPU資源(利用時間)を割り当てる。CABIを用いると、CPUに余力があった場合でもアカウンティングオブジェクトに設定した時間分のCPU資源を消費したら該プロセスはタスクを開放し、それ以上CPU資源を利用しない。CABIを用いた場合において、設定する周期とCPU使用時間は利用可能な最大値である。設定した時間分のCPUを使用していなくとも、より優先度の高いプロセスから割り込みが発生した場合等は利用時間に達しなくともCPU資源を解放する。
【００８３】
CABI-DMELはアカウンティングオブジェクト(AO)に利用可能なメモリ量を設定する。制御したいプロセスをアカウンティングオブジェクトにバインドすると、CABI-DMELは該プロセスのメモリの確保／開放を監視し、設定したメモリ量を超えるメモリの確保を行おうとするとそれを拒否する。その場合、制御対象のプロセスではメモリ確保に失敗したことになり、場合によってはプロセスそのものが異常終了するような場合もある。
【００８４】
CABIやCABI-DMELを用いた場合のログ等はシステムログ等に記録可能であり、アプリケーション管理部111から参照可能である。
【００８５】
図６Ａ、６Ｂ、図７のように新規サービス導入処理、サービス起動処理を行うことで、ゲートウェイ装置109上で動作するサービスアプリケーション111の使用リソースを適切に制御し、ゲートウェイ装置の安定動作、可用性の向上を実現することができる。
【００８６】
図６Ａ、６Ｂの処理において、サービスアプリケーション111の配布可否はゲートウェイ管理装置101にて判断しているが、上述した通り、これはゲートウェイ装置109で行ってもよい。
【００８７】
更に、図７の処理において起動されたサービスアプリケーション111の動作ログ等をゲートウェイ管理装置101またはサービス提供事業者サーバ107へ送信することにより、保守管理に役立てることが可能である。例えば、設定した上限値を超えてリソースを利用しようとしたサービスアプリケーションが存在した場合、そのログを送信することによりソフトウェアの品質改良等に役立てる事が可能である。
【００８８】
図１１において、1100は、図６Ｂにおけるステップ611においてゲートウェイ管理装置101がサービス利用者に提示する情報の画面イメージの一例である。
【００８９】
図１２において、1200は図６Ｂにおけるステップ607においてゲートウェイ管理装置101がサービス利用者に提示する情報の画面イメージの一例である。
【００９０】
図１４、図１５、図１６はそれぞれ、本実施例において、CABIおよびCABI-DMELが利用できない環境におけるサービスアプリケーションの起動処理およびメモリ使用量監視処理およびCPU使用率監視処理を示す図である。
【００９１】
図１４はサービスアプリケーション起動処理を示す図であり、サービスアプリケーション111の起動処理の手順を示すフローチャートである。
【００９２】
ステップ1401はアプリケーション管理部112が、利用可能リソーステーブル400から、起動するサービスアプリケーションのIDに対応する利用可能ヒープメモリ量を取得する処理である。
【００９３】
ステップ1402はアプリケーション管理部112が、JavaVMの起動オプションの最大ヒープ量に該利用可能ヒープメモリ量を設定して、アプリケーション実行部110のOSGiフレームワーク133を起動し、該OSGiフレームワーク133に該サービスアプリケーション111をインストールおよび実行する処理である。
【００９４】
ステップ1403はアプリケーション管理部112が、該サービスアプリケーション111を実行したソフトウェアプロセスのプロセスIDを調査、取得する。該サービスアプリケーション111のIDおよび該プロセスIDをプロセスID管理テーブル1000に記憶する処理である。
【００９５】
図１５はメモリ使用量監視処理を示す図である。これは、サービスアプリケーションのメモリ使用量を監視する手順を示すフローチャートである。
【００９６】
ステップ1501はプロセスID管理テーブル119に定期監視を終えていないサービスアプリケーションIDが存在かどうか調べる処理である。もしプロセスID管理テーブル119に定期監視を終えていないサービスアプリケーションIDが存在であれば、ステップ1502へ進む。あるいはプロセスID管理テーブルに定期監視を終えていないサービスアプリケーションIDが存在でなければ、ステップ1508へ進む。
【００９７】
ステップ1502はアプリケーション管理部112が、プロセスID管理テーブル119から定期監視を終えていないサービスアプリケーションのID、および該サービスアプリケーションIDに対応するプロセスIDを取得する処理である。
【００９８】
ステップ1503はアプリケーション管理部112が、該プロセスIDに対応するプロセスのメモリ使用量を取得する処理である。
【００９９】
ステップ1504はメモリ使用量が該サービスアプリケーションIDに対応する利用可能メモリ量を超過しているかどうか調べる処理である。もしメモリ使用量が該サービスアプリケーションIDに対応する利用可能メモリ量を超過している場合は、ステップ1505へ進む。もしメモリ使用量が該サービスアプリケーションIDに対応する利用可能メモリ量を超過していない場合は、ステップ1501へ戻る。
【０１００】
ステップ1505はアプリケーション管理部112が、該サービスアプリケーションIDに対応するサービスアプリケーションを強制終了する処理である。
【０１０１】
ステップ1506はアプリケーション管理部112が、利用可能リソーステーブル114、導入サービスアプリケーション依存関係管理テーブル118、プロセスID管理テーブル119から該サービスアプリケーションIDに対応する項目を削除する処理である。
【０１０２】
ステップ1507はアプリケーション管理部112が、該サービスアプリケーションを利用可能メモリ使用量超過で強制終了した事をシステムログ等に記録する処理である。
【０１０３】
ステップ1508は一定時間停止する処理である。この後、丸１に示すように、ステップ1501に戻る。
【０１０４】
図１６はCPU使用率監視処理を示す図である。これは、サービスアプリケーションのCPU使用率を監視する手順を示すフローチャートである。
【０１０５】
ステップ1601はアプリケーション管理部112が、ゲートウェイ装置109のCPUのロードアベレージを取得する処理である。
【０１０６】
ステップ1602はロードアベレージ>1かどうか調べる処理である。もしロードアベレージ>1であれば、ステップ1603へ進む。もしロードアベレージ>1でなければ、ステップ1609へ進む。
【０１０７】
ステップ1603はプロセスID管理テーブルに定期監視を終えていないサービスアプリケーションIDが存在かどうか調べる処理である。もしプロセスID管理テーブルに定期監視を終えていないサービスアプリケーションIDが存在であれば、ステップ1604へ進む。あるいはプロセスID管理テーブルに定期監視を終えていないサービスアプリケーションIDが存在でなければ、ステップ1609へ進む。
【０１０８】
ステップ1604はアプリケーション管理部112が、プロセスID管理テーブルから定期監視を終えていないサービスアプリケーションのID、および該サービスアプリケーションIDに対応するプロセスIDを取得する処理である。
【０１０９】
ステップ1605はアプリケーション管理部112が、該プロセスIDに対応するプロセスのCPU使用率を取得する処理である。
【０１１０】
ステップ1606はCPU使用率が該サービスアプリケーションIDに対応する利用可能CPU使用率を超過しているかどうか調べる処理である。もしCPU使用率が該サービスアプリケーションIDに対応する利用可能CPU使用率を超過している場合は、ステップ1607へ進む。もしCPU使用率が該サービスアプリケーションIDに対応する利用可能CPU使用率を超過していない場合は、ステップ1603へ戻る。
【０１１１】
ステップ1607はアプリケーション管理部112が、該プロセスIDに対応するプロセスのスレッド優先度を下げる処理である。
【０１１２】
ステップ1608はアプリケーション管理部112が、該サービスアプリケーションが利用可能CPU使用率を超過した事をシステムログ等に記録する処理である。
【０１１３】
ステップ1609は一定時間停止する処理である。この後、丸１に示すように、ステップ1501に戻る。
【０１１４】
図１７は、図６に示した新規サービス導入処理を示すフローチャートに対応するシーケンス図である。
【０１１５】
ステップ1701は、サービス利用者がゲートウェイ装置109を介してゲートウェイ管理装置101に接続し、新規導入を希望するサービスアプリケーション111を選択する処理である。
【０１１６】
ステップ1702は、ゲートウェイ管理装置101が該サービスアプリケーションのID(A)を得る処理である。
【０１１７】
ステップ1703は、ゲートウェイ管理装置101が、ゲートウェイ装置109に、全体利用可能リソース情報テーブル113に記載の情報（B）および利用可能リソーステーブル114に記載のIDの一覧（C）の送信を要求する処理である。
【０１１８】
ステップ1704は、ゲートウェイ装置109が、ゲートウェイ管理装置101に、全体利用可能リソース情報テーブル113に記載の情報（B）および利用可能リソーステーブル114に記載のIDの一覧（C）を送信する処理である。
【０１１９】
ステップ1705は、ゲートウェイ管理装置101が、AのIDとCのIDの一覧と依存関係テーブルに記載の情報（D）を用いてゲートウェイ装置109に導入するサービスアプリケーションのIDの一覧（E）を抽出する処理である。
【０１２０】
ステップ1706は、ゲートウェイ管理装置101が、必要リソーステーブルに記載の必要メモリ量、必要CPU使用率のそれぞれについて、CのID一覧に対応する必要メモリ量、必要CPU使用率それぞれの合計(F)と、EのID一覧に対応する必要メモリ量、必要CPU使用率それぞれの合計(G)を抽出する処理である。
【０１２１】
ステップ1707は、ゲートウェイ管理装置101が、新規サービス導入した場合にゲートウェイ装置109のメモリ量、CPU使用率それぞれについて全体利用可能リソース量を超えないことを確認、すなわち、必要メモリ量、必要CPU使用率それぞれについて、Fの値とGの値の和がBにおける全体利用可能メモリ量、全体利用可能CPU使用率の値を超えないかどうかを確認する処理である。
【０１２２】
ステップ1708は、ゲートウェイ管理装置101が、ゲートウェイ装置109を介してサービス利用者に、新規導入を希望したサービスアプリケーションを導入可能である事を提示する処理である。
【０１２３】
ステップ1709は、ゲートウェイ管理装置101が、ゲートウェイ装置109へ、該新規導入サービスアプリケーションおよび必要リソーステーブル500の情報のうち該サービスアプリケーションのIDに対応する情報(H)、および依存関係管理テーブル800の情報のうち該サービスアプリケーションのIDに対応する情報(I)を送信する処理である。
【０１２４】
ステップ1710は、ゲートウェイ装置109が、Hの情報を利用可能リソーステーブル114に、Iの情報を導入サービスアプリケーション依存関係テーブル118に追記する処理である。
【０１２５】
ステップ1711は、ゲートウェイ装置109が、該サービスアプリケーションを起動する処理である。
【０１２６】
図１８は異常通知を示すフローチャートの一例を示す図である。これは、サービスアプリケーションが利用可能リソース量を超過した際に、ゲートウェイ管理装置101に異常を通知する手順を示すフローチャートである。
【０１２７】
ステップ1801はアプリケーション管理部112が、システムログ等から、サービスアプリケーションが利用可能リソース量を超過したかどうかに関する情報を取得する処理である。
【０１２８】
ステップ1802は利用可能リソース量を超過したサービスアプリケーション有かどうか調べる処理である。もし利用可能リソース量を超過したサービスアプリケーション有であれば、ステップ1803へ進む。もし利用可能リソース量を超過したサービスアプリケーション有でなければ、ステップ1804へ進む。
【０１２９】
ステップ1803はアプリケーション管理部112が、該サービスアプリケーションのIDと利用可能リソース量を超過したかどうかに関する情報をゲートウェイ管理装置に送信する処理である。
【０１３０】
ステップ1804は一定時間停止する処理である。
【０１３１】
図19は異常通知を示すフローチャートの他の例を示す図である。これは、サービスアプリケーションが利用可能リソース量を超過した際に、ゲートウェイ管理装置101に異常を通知する手順を示すフローチャートである。
【０１３２】
ステップ1901はアプリケーション管理部112が、システムログ等から、サービスアプリケーションが利用可能リソース量を超過したかどうかに関する情報を取得する処理である。
【０１３３】
ステップ1902は利用可能リソース量を超過したサービスアプリケーション有かどうか調べる処理である。もし利用可能リソース量を超過したサービスアプリケーション有であれば、ステップ1903へ進む。もし利用可能リソース量を超過したサービスアプリケーション有でなければ、ステップ1905へ進む。
ステップ1903はアプリケーション管理部112が、導入サービスアプリケーション依存関係管理テーブルを参照し、該サービスアプリケーションのIDに対応するImport-Packageに記載の情報をExport-Packageに記載しているサービスアプリケーションのIDの一覧(J)を取得する処理である。
【０１３４】
ステップ1904はアプリケーション管理部112が、該サービスアプリケーションのIDと、利用可能リソース量を超過したかどうかに関する情報と、Jの情報をゲートウェイ管理装置に送信する処理である。
【０１３５】
ステップ1905は一定時間停止する処理である。
【０１３６】
以上詳述した第１の実施例によれば、ゲートウェイ装置に新規にアプリケーションサービス実行ソフトウェアを配布する際に、該ソフトウェアの利用可能リソース量と、既にゲートウェイ装置に導入済みのソフトウェアの利用可能リソース量の合計と、ゲートウェイ装置全体のリソース量のうちアプリケーションサービス実行ソフトウェアが利用可能なリソース量の合計とを比較し、既にゲートウェイ装置に導入済みのソフトウェアの利用可能リソース量の合計と新規に配布するソフトウェアが利用可能なリソース量の合計がゲートウェイ装置全体のリソース量のうちアプリケーションサービス実行ソフトウェアが利用可能なリソース量を超えない場合にのみ該ソフトウェアの配布を許可することにより、アプリケーションサービスを安定的に動作させ、ゲートウェイ装置の可用性を向上するゲートウェイ管理システムを実現することができる。
【０１３７】
なお、本発明は、以上詳述した第１の実施例に限定されるものでなく、本発明の技術思想を具現化可能できる、種々の変形実施態様にも及ぶことは言うまでもない。例えば、サービス利用者がゲートウェイ装置を介してゲートウェイ管理装置に接続し、新規なサービスアプリケーションを選択した場合、この新規なサービスアプリケーションの配布の可否判断を、ゲートウェイ管理装置でなくゲートウェイ装置で判断しても良く、これにより、ゲートウェイ装置のアプリケーションサービス実行ソフトウェアが利用可能なリソース量の合計と、既に導入済みのソフトウェアの利用可能リソース量の合計をゲートウェイ管理装置に送信するステップを省略できる。
【産業上の利用可能性】
【０１３８】
本発明は、ゲートウェイ装置の利用者が新規にアプリケーションサービスを導入する際に、安定的に動作可能とするゲートウェイ管理技術として有用である。
【符号の説明】
【０１３９】
101  ゲートウェイ管理装置
102  アプリケーション配布管理部
103  DB管理部
104  サービス管理DB
105  必要リソーステーブル
106  外部ネットワーク
107  サービス事業者サーバ
108  利用者宅
109  ゲートウェイ装置
110  アプリケーション実行部
111  サービスアプリケーション
112  アプリケーション管理部
113  全体利用可能リソーステーブル
114  利用可能リソーステーブル
115  利用者宅内ネットワーク
116  宅内機器
117  依存関係テーブル
118  導入サービスアプリケーション依存関係管理テーブル
119  プロセスID管理テーブル
202  EPROM
203  CPU
204  メインメモリ
205  バス
206  周辺制御装置
207  不揮発性記憶装置
208  ネットワークI/F
211  EPROM
212  CPU
213  メインメモリ
214  バス
215  ネットワークI/F
216  周辺制御装置
217  ネットワークI/F
218  不揮発性記憶装置
301  全体利用可能CPU使用率
302  全体利用可能メモリ量
401,501,801,901,1001  ID
402  利用可能ヒープメモリ量
403  利用可能メモリ量
404  利用可能CPU使用率
502  必要ヒープメモリ量
503  必要メモリ量
504  必要CPU使用率
802  Import-Package
803  Export-Package
902  Import-Package
903  Export-Package
1002  プロセスID。
【図１】
2012064025.tif 000003
【図２】
2012064025.tif 000004
【図３】
2012064025.tif 000005
【図４】
2012064025.tif 000006
【図５】
2012064025.tif 000007
【図６Ａ】
2012064025.tif 000008
【図６Ｂ】
2012064025.tif 000009
【図７】
2012064025.tif 000010
【図８】
2012064025.tif 000011
【図９】
2012064025.tif 000012
【図１０】
2012064025.tif 000013
【図１１】
2012064025.tif 000014
【図１２】
2012064025.tif 000015
【図１３】
2012064025.tif 000016
【図１４】
2012064025.tif 000017
【図１５】
2012064025.tif 000018
【図１６】
2012064025.tif 000019
【図１７】
2012064025.tif 000020
【図１８】
2012064025.tif 000021
【図１９】
2012064025.tif 000022