情報処理装置、情報処理方法及びプログラム
【課題】コンポーネントに特別な実装を追加する事無く、通信制御ミドルウェアで、コンポーネント間で依頼と応答との通信が正常に行われた場合でも、処理が正常に進行していない状況を検出することを目的とする。
【解決手段】複数のアプリケーションコンポーネントの通信を制御する通信制御手段と、複数のアプリケーションコンポーネントのライフサイクルを管理し、複数のアプリケーションコンポーネントの通信間隔のばらつきから故障発生を判断するライフサイクル管理手段と、を有することによって課題を解決する。
【解決手段】複数のアプリケーションコンポーネントの通信を制御する通信制御手段と、複数のアプリケーションコンポーネントのライフサイクルを管理し、複数のアプリケーションコンポーネントの通信間隔のばらつきから故障発生を判断するライフサイクル管理手段と、を有することによって課題を解決する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、情報処理方法及びプログラムに関する。
【背景技術】
【０００２】
従来、アプリケーションコンポーネント以下、コンポーネントという同士が通信する通信制御ミドルウェアとして、コンポーネントの状態をコンポーネントライフサイクルに渡って管理する方法は一般的である。このライフサイクル管理は一般に、システムを構成する各コンポーネントの状態をシステム状態に関連付けられる際に用いられる。例えば、障害発生時にアプリケーションを再起動する方法としては特許文献１が挙げられる。一方、システムにおける故障の検出手段については特許文献２が挙げられる。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００６−１５７３８６号公報
【特許文献２】特開平８−４４６８４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、従来のライフサイクル管理では、特許文献２に示されるように故障を検出した事をきっかけとして、特許文献１に示されるようにシステムを再起動する処理を実現できない。これには以下の問題があった。
通信制御ミドルウェアでは故障の発生を検出することができない。コンポーネント間のコマンド送受信が成功している場合、通信制御ミドルウェアでコマンドの実行が正常に行われたか判断できない。その為、故障検出の仕組みをコンポーネントに実装する必要があった。
【０００５】
本発明はこのような問題点に鑑みなされたもので、コンポーネントに特別な実装を追加する事無く、通信制御ミドルウェアで、コンポーネント間で依頼と応答との通信が正常に行われた場合でも、処理が正常に進行していない状況を検出することを目的とする。
【課題を解決するための手段】
【０００６】
そこで、本発明の情報処理装置は、複数のアプリケーションコンポーネントの通信を制御する通信制御手段と、前記複数のアプリケーションコンポーネントのライフサイクルを管理し、前記複数のアプリケーションコンポーネントの通信間隔のばらつきから故障発生を判断するライフサイクル管理手段とを有することを特徴とする。
【発明の効果】
【０００７】
本発明によれば、コンポーネントに特別な実装を追加する事無く、通信制御ミドルウェアで、コンポーネント間で依頼と応答との通信が正常に行われた場合でも、処理が正常に進行していない状況を検出することができる。
【図面の簡単な説明】
【０００８】
【図１】システム構成の一例を示す図である。
【図２】図１のＯＳ上位層を論理的に拡大表示した図である。
【図３】ＵＩコンポーネントとジョブ制御コンポーネントとのメッセージ送受信の一例を説明するための図である。
【図４】コンポーネント情報保存部について説明するための図である。
【図５】状態変化通知と、ジョブ処理の流れと、を説明するための図である。
【図６】一般的なシステムにおけるコンポーネント構成の一例を示す図である。
【図７】キーコンポーネントが多くの他のコンポーネントと通信するイメージの一例を示す図である。
【図８】図１や図２のシステムにおける、４つのコンポーネントの関係の一例を示す図である。
【図９】４つのコンポーネントが共有データ管理コンポーネントを介してデータを共有しながら、処理を進めていく様子の一例を示す図である。
【図１０】共有データコンポーネントと他のコンポーネントと通信制御のシーケンスの一例を示す図である。
【図１１】キーコンポーネント特定の流れを表す図である。
【図１２】キーコンポーネントを特定する概念を表す図である。
【図１３】故障のない処理の通信履歴と状態変化の関係を表す図である。
【図１４】コンポーネントＢに着目した表であり、故障コンポーネントを特定する概念を表す図である。
【図１５】故障コンポーネント特定部の処理の流れを示す図である。
【図１６】故障通知の詳細を説明するための図である。
【発明を実施するための形態】
【０００９】
以下、本発明の実施形態について図面に基づいて説明する。
【００１０】
＜実施形態１＞
図１は、システム構成の一例を示す図である。図１では、システム１６０１が複数のコンピュータを有している。ＣＰＵ１ １６０２とＯＳ１ １６０４とを有するコンピュータは、ユーザにインタフェースを提供し、ＣＰＵ２ １６０６とＯＳ２ １６０８とを有するコンピュータは、デバイスの制御を司る。各々のコンピュータシステムは通信制御物理層１６０３、１６０７によって物理的に接続されている。また、各々のコンピュータシステム上には通信制御ミドルウェア１６０５、１６０９が動作している。この通信制御ミドルウェア１６０５、１６０９は、アプリケーションコンポーネント以下、コンポーネントというに対し、通信制御層以下の物理的なシステム構成を隠蔽している。ユーザインタフェースを司るＣＰＵ１ １６０２とＯＳ１ １６０４とのコンピュータシステムの通信制御ミドルウェア１６０５の上にはＵＩコンポーネント１０２が動作している。装置の制御を司るＣＰＵ２ １６０６とＯＳ２ １６０８とのコンピュータシステムの通信制御ミドルウェア１６０９の上には３つのコンポーネントが動作している。即ち、ジョブ制御コンポーネント１０３とデバイス制御コンポーネント１０４と共有データ管理コンポーネント１０５とが動作している。システム１６０１は、ユーザ１６１０がＵＩコンポーネント１０２を操作し、システム内の４つのコンポーネントが協調動作することでユーザにサービスを提供する。４つのコンポーネントとは、ＵＩコンポーネント１０２、ジョブ制御コンポーネント１０３、デバイス制御コンポーネント１０４、共有データ管理コンポーネント１０５である。
なお、本実施形態では、コンピュータシステムは、１つの情報処理装置コンピュータに実装されているものとして説明を行う。情報処理装置は、通常のコンピュータのハードウェア構成を有する。情報処理装置のＣＰＵが、ＲＡＭ、ＲＯＭ、ＨＤＤ等の記憶装置に記憶されているプログラムに基づき処理を実行することによって、各コンピュータシステムの構成、及び後述する各コンピュータシステムにおける処理が実現される。なお、ＣＰＵが処理を実行する際に利用されるデータ等は、記憶装置に記憶されている。
【００１１】
ＯＳ上位層１６１１の点線で囲まれた領域について図２を用いて詳説する。図２は、図１のＯＳ上位層１６１１を論理的に拡大表示した図である。
通信制御ミドルウェア１６０５、１６０９は、通信制御部１０１とライフサイクル管理部１１２とを有している。４つのコンポーネントが通信制御部１０１とライフサイクル管理部１１２とに論理的に接続されている。これらの論理接続は各コンポーネントが通信ミドルウェアに対して行う初期化処理にて確立される。コンポーネント同士は通信制御部１０１を介してメッセージの送受信を行い、コンポーネント状態管理部１０８に状態変化の通知を行う。
通信制御部１０１の動作についてＵＩコンポーネント１０２とジョブ制御コンポーネント１０３とのメッセージ送受信を例に図３を用いて説明する。図３は、ＵＩコンポーネント１０２とジョブ制御コンポーネント１０３とのメッセージ送受信の一例を説明するための図である。
ここではＵＩコンポーネント１０２とジョブ制御コンポーネント１０３とがメッセージ送受信によりジョブスタートとジョブ終了の強調動作を行う事を想定している。ＵＩコンポーネント１０２がジョブ制御コンポーネント１０３に対してメッセージ送信を行う場合、まずＵＩコンポーネント１０２は、通信制御部１０１に対してメッセージ送信１１０１を行う。このメッセージ送信１１０１ではメッセージ内容として「ジョブスタート」、送信元としてＵＩコンポーネント１０２、送信先としてジョブ制御コンポーネントのメッセージ１１０５が送信される。通信制御部１０１ではこのメッセージ１１０５が一旦保存され、ジョブ制御コンポーネント１０３からのメッセージ受信１１０２により受け渡される１１０６。同様にジョブ制御コンポーネント１０３からＵＩコンポーネント１０２にメッセージ送信を行う場合、まずジョブ制御コンポーネント１０３から通信制御部１０１にメッセージ送信１１０３を行う。このメッセージ送信１１０３ではメッセージ内容として「ジョブ終了」、送信元としてジョブ制御コンポーネント１０３、送信先としてＵＩコンポーネント１０２のメッセージ１１０７が送信される。通信制御部１０１ではこのメッセージ１１０７を一旦保存し、ＵＩコンポーネント１０２からのメッセージ受信１１０４により受け渡される１１０８。通信制御部１０１から見れば１１０９、１１１０、１１１１、１１１２の時点でコンポーネントに対しメッセージの送受信が発生した事が明らかである。
図２の通信制御部１０１はコンポーネント間でメッセージの送受信が発生すると、通信履歴保存部１０６を介してメッセージの送受信履歴を１１０９、１１１０、１１１１、１１１２等の時点で保存する。通信履歴保存部１０６は、コンポーネント情報保存部１０７に対し通信履歴１５０６の保存を行う。
【００１２】
コンポーネント情報保存部１０７について図４を用いて述べる。図４は、コンポーネント情報保存部１０７について説明するための図である。コンポーネント情報保存部１０７は、コンポーネントに関する情報として、コンポーネント情報１５００を持つ。コンポーネント情報１５００は、複数のコンポーネントに関する情報を保持する１５０１。各コンポーネント１５０１の情報としては代表的な物としてコンポーネント識別子１５０２、現在の状態１５０３、状態変化履歴１５０４、通信履歴１５０６がある。その他にも各コンポーネント１５０１に対し、通信発生間隔履歴１５１１、キーコンポーネントフラグ１５１０、通信相手リスト１５１２が関連付けられる。各状態変化履歴１５０４には状態変化時刻１５０５が関連付けられる。各通信履歴１５０６には送信元コンポーネントと送信先コンポーネント１５０７及び通信時刻１５１４が関連付けられる。ここで言う送信元コンポーネントとはメッセージ中に定義される送信元コンポーネントであり、より具体的には１１０５、１１０６、１１０７、１１０８に示される送信元と等価である。通信履歴１５０６と関連付けられる送信先コンポーネント１５０７についても１１０５、１１０６、１１０７、１１０８に示される送信先と等価である。更に各通信履歴１５０６は通信制御部１０１から見た場合の送受信種別が関連付けられる。通信制御部１０１から見た送信とは例えば１１０１、１１０３の様な場合を示し、受信は１１０２、１１０４の様な場合を示す。
【００１３】
次に図２のコンポーネント状態管理部１０８について説明する。コンポーネント状態管理部１０８は、各コンポーネント１０２、１０３、１０４、１０５からの状態変化通知を論理的な接続１１３、１１４、１１５、１１６を介して受け取る。なお、１１３、１１４、１１５、１１６のコンポーネントとコンポーネント状態管理部１０８との論理的な接続は通信制御部１０１との接続の上で実現されてもよいし、別途確立される接続でもよい。
状態変化通知を受けたコンポーネント状態管理部１０８は、コンポーネント情報保存部１０７にて、コンポーネント１５０１に関連付けられた状態変化履歴１５０４と状態変化時刻１５０５とを保存する。
【００１４】
図５を用いて状態変化通知と、ジョブ処理の流れと、を解説する。図５は、状態変化通知と、ジョブ処理の流れと、を説明するための図である。ユーザ１０１６がＵＩコンポーネント１０２に対しユーザインタフェース等を介してスタート１００１を指示したとする。ＵＩコンポーネント１０２は、コンポーネント状態管理部１０８に対しＵＩコンポーネント１０２が活性化された事を示すＡＣＴＩＶＥ状態通知１００２を行う。このとき、コンポーネント状態管理部１０８は、コンポーネント情報保存部１０７に対しコンポーネントの状態変化履歴１５０４と状態変化時刻１５０５とをコンポーネント１５０１に関連付けて保存する。関連付けは、予めコンポーネント情報保存部１０７に設定されているコンポーネント識別子１５０２と状態変化通知であるＡＣＴＩＶＥ状態通知１００２等に付随して送られてくるコンポーネント識別子とを関連付けて実現される。コンポーネント状態管理部１０８は、コンポーネントからの状態変化通知を受ける毎にコンポーネントの状態変化履歴１５０４と状態変化時刻１５０５とを保存する。更に最新のコンポーネント状態を現在の状態１５０３に保存する。その後、ＵＩコンポーネント１０２は、ジョブ制御コンポーネント１０３にジョブスタート１００３を指示する。ＡＣＴＩＶＥ状態通知１００２やジョブスタート１００３は、実際には通信制御部１０１に対するメッセージ送受信により実施される。又は、ＡＣＴＩＶＥ状態通知１００２についてはコンポーネントとコンポーネント状態管理部１０８との間に別途確立されたコネクション上で実施されてもよい。ジョブスタート１００３を指示されたジョブ制御コンポーネント１０３は、活性化されたことをコンポーネント状態管理部１０８にＡＣＴＩＶＥ通知１００４する。その後、ジョブ制御コンポーネント１０３は、デバイス制御コンポーネント１０４にデバイス処理開始１００５を指示する。デバイス処理開始１００５を指示されたデバイス制御コンポーネント１０４は、活性化された事をコンポーネント状態管理部１０８にＡＣＴＩＶＥ通知１００６する。
【００１５】
その後、デバイス制御コンポーネント１０４にて一連のデバイス制御処理を実施し、処理が終了したらデバイス制御コンポーネント１０４が非活性化された事をコンポーネント状態管理部１０８に通知する。この通知は、デバイス制御コンポーネント１０４からコンポーネント状態管理部１０８に対しＩＤＬＥ１００７を通知する事で実施される。その後、デバイス制御コンポーネント１０４は、デバイス処理が終了したことをジョブ制御コンポーネント１０３に通知する１００８。デバイス処理終了１００８通知を受けたジョブ制御コンポーネント１０３は、コンポーネント状態管理部１０８に対して自身が非活性化されることをＩＤＬＥ１００９通知する。その後、ジョブ制御コンポーネント１０３は、ＵＩコンポーネント１０２に対しジョブ処理が終了１０１０したことを通知する。ジョブ処理の終了１０１０通知を受けたＵＩコンポーネント１０２は、自身が非活性化される事をＩＤＬＥ１０１１通知によりコンポーネント状態管理部１０８に伝え、ユーザに処理が終了した事を通知１０１２する。なお、共有データ管理コンポーネント１０５は、ジョブのスタート１００１や終了の通知１０１２に関わらず、システムが起動するより前に活性化されている必用がある１０１４。更にシステムが終了する前に非活性化される１０１５。
【００１６】
なお、共有データ管理コンポーネント１０５は、活性化される前にコンポーネント状態管理部１０８に対し、コンポーネント属性送信１０１３を行ってもよい。図２ではこの属性送信はキーコンポーネント特定属性１１１によって表されている。このコンポーネント属性送信１０１３は、共有データ管理コンポーネント１０５が自らをキーコンポーネントであることを宣言する意味を持つ。このコンポーネント属性送信１０１３を受けた場合は、コンポーネント状態管理部１０８は、該当コンポーネントのキーコンポーネントフラグ１５１０をＯＮにする。コンポーネント属性送信１０１３にはコンポーネント識別子が関連付けられているものとする。なお、キーコンポーネント特定属性送信は必ずしも実装される必要はなく、キーコンポーネント特定部１１０によりキーコンポーネントの特定を行うようにしてもよい。
【００１７】
ここでキーコンポーネントとは何かを解説する。図６は、一般的なシステム２０４におけるコンポーネント構成の一例を示す図である。丸印２０３は１つのコンポーネントを示している。また、２０１２０２の様な太陽印はキーコンポーネントを示している。ここでは、キーコンポーネントとしてデータを共有するコンポーネント２０２と、状態を同期するコンポーネント２０１と、を仮定している。システムが例えば２台のコンピュータシステムで構成されている場合、各々のコンピュータシステム上に複数の論理的ドメインが構成されシステムが構成される場合が多い。例えば、最上位ドメインはユーザインタフェースドメイン２０５であり、次がアプリケーションサービスを提供するＡＰＳドメイン２０６であり、次がジョブ制御を行うＪｏｂＣｔｒｌ２０７ドメインである。ここまでが一台のコンピュータシステム上に構成されるとする。更にもう一台のコンピュータシステム上には以下３つのドメインが構成されるものとする。即ち、組込機器の上位層としてジョブ制御を行うＥｍｂｅｄｅｄ Ｊｏｂ Ｃｔｒｌ２０８ドメイン。組込機器の機能制御を行うＥｍｂｅｄｅｄ Ｆｕｎｃｔｉｏｎ Ｃｔｒｌ２０９ドメイン。組込機器のデバイス制御を行うＥｍｂｅｄｅｄ Ｄｅｖｅｉｃｅ Ｃｔｒｌ２１０ドメイン、の３ドメインである。各ドメインを構成するコンポーネント同士は一般に、隣のドメインに存在するコンポーネントと協調しながらシステム全体が動作しサービスを提供する。一方、システムには、２０１２０２に示す様な、ドメインを跨って全コンポーネントに対しデータや状態を同期する、コンポーネントが幾つかは存在する場合が多い。本実施形態ではこの様にシステム上の多くのコンポーネントからアクセスされるコンポーネントをキーコンポーネントと呼ぶ。図７は、キーコンポーネント３０１が多くの他のコンポーネント３０２と通信するイメージの一例を示す図である。
【００１８】
図８は、図１や図２のシステムにおける、４つのコンポーネントの関係の一例を示す図である。ＵＩコンポーネント１０２は、ジョブ制御コンポーネント１０３に対しジョブスタート・終了４０１の関係を持つ。ジョブ制御コンポーネント１０３とデバイス制御コンポーネント１０４とはデバイス処理開始・終了の関係４０２を持つ。一方、共有データ管理コンポーネント１０５とＵＩコンポーネント１０２とはジョブデータセット・取得・結果データ取得４０３の関係を持つ。共有データ管理コンポーネント１０５とジョブ制御コンポーネント１０３とはデバイス処理データセット・結果取得４０４の関係を持つ。更に、共有データ管理コンポーネント１０５とデバイス制御コンポーネント１０４とはデバイス処理データ取得・更新４０５の関係を持つ。即ち、サービス提供を制御する系統のコンポーネントである、ＵＩコンポーネント１０２、ジョブ制御コンポーネント１０３、デバイス制御コンポーネント１０４は、互いに数珠繋ぎの関係を持つ。一方でサービス提供を制御する系統の各々のコンポーネント１０２、１０３、１０４は、処理を進める為にデータを共有する必要性から、共有データ管理コンポーネント１０５とは中央集権型の関係を持つ。つまり共有データ管理コンポーネント１０５は、本実施形態におけるキーコンポーネントであると見なす事ができる。
【００１９】
図９は、４つのコンポーネントが共有データ管理コンポーネント１０５を介してデータを共有しながら、処理を進めていく様子の一例を示す図である。ユーザ１２１５がＵＩコンポーネント１０２に対してスタート１２０１を指示する。ＵＩコンポーネント１０２は、共有データ管理コンポーネント１０５にジョブデータセット１２０２を行い、ジョブ制御コンポーネント１０３にジョブスタート１２０３を指示する。ジョブ制御コンポーネント１０３は、ジョブスタート１２０３を受けると、ジョブデータ取得１２０４とデバイス処理データセット１２０５とを共有データ管理コンポーネント１０５に対して行う。その後、ジョブ制御コンポーネント１０３は、デバイス制御コンポーネント１０４にデバイス処理開始１２０６を指示する。指示を受けたデバイス制御コンポーネント１０４は、デバイス処理データ取得１２０７とデバイス処理データ更新１２０８とを共有データ管理コンポーネント１０５に対して行う。その後、デバイス制御コンポーネント１０４がデバイス制御処理を終えるとデバイス処理終了１２０９をジョブ制御コンポーネント１０３に通知する。デバイス処理終了１２０９を受けたジョブ制御コンポーネント１０３は、デバイス処理結果データ取得１２１０を共有データ管理コンポーネント１０５から行う。その後、ジョブ制御コンポーネント１０３は、ＵＩコンポーネント１０２に対しジョブ終了１２１１を通知する。ジョブ終了１２１１を受信したＵＩコンポーネント１０２はジョブ処理結果データ取得１２１２を共有データ管理コンポーネント１０５から行う。その後、ＵＩコンポーネント１０２は、ユーザに対しジョブ処理結果データ表示１２１３と、終了通知１２１４と、を行う。ここで示したジョブスタート１２０３、ジョブ終了１２１１、デバイス処理開始１２０６、デバイス処理終了１２０９は、通信制御部１０１を介して伝達される事は図３に解説した通りである。一方でジョブデータセット１２０２、ジョブデータ取得１２０４、１２０５、１２０７、１２０８１２１０、１２１２についても通信制御部１０１を介して伝達される。その様子を、図１０を用いて説明する。
【００２０】
図１０は、共有データコンポーネントと他のコンポーネントと通信制御のシーケンスの一例を示す図である。ＵＩコンポーネント１０２が共有データ管理コンポーネント１０５に対してジョブデータセット１２０２を実施する際、ＵＩコンポーネント１０２はまず通信制御部１０１に対しメッセージ送信１３０１を行う。この際「メッセージ内容：ジョブデータセット、送信元ＵＩコンポーネント、送信先共有データ管理コンポーネント」１３０５、のメッセージが通信制御部１０１に対して送信される。共有データ管理コンポーネント１０５は通信制御部１０１からメッセージ受信１３０２を行い、１３０６、１３０５と等価のメッセージを受け取る。１３０９、１３１０のタイミングで通信制御部１０１は、通信履歴保存部１０６を介してコンポーネント情報保存部１０７に通信履歴１５０６を保存する。通信履歴１５０６に対応して通信時刻１５１４も保存される。同様にＵＩコンポーネント１０２が共有データ管理コンポーネント１０５からジョブ処理結果データ取得１２１２を行う際はまず通信制御部１０１に対しメッセージ送信１３０３を行う。このメッセージには「メッセージ内容：ジョブ処理結果データ取得、送信元：ＵＩコンポーネント、送信先：共有データ管理コンポーネント」１３０８のメッセージが通信制御部１０１に対して送信される。共有データ管理コンポーネント１０５は、通信制御部１０１からメッセージ受信１３０４を行い、１３０７、１３０８と等価のメッセージを受け取る。１３１１、１３１２のタイミングで通信制御部１０１は、通信履歴保存部１０６を介してコンポーネント情報保存部１０７に通信履歴１５０６を保存する。通信履歴１５０６に対応して通信時刻１５１４も保存される。これにより図９で示される、４つのコンポーネントが共有データ管理コンポーネント１０５を介してデータを共有しながら、処理を進めていく様子は全てコンポーネント情報保存部１０７の通信履歴１５０６に保存される。
【００２１】
次に図２におけるキーコンポーネント特定部１１０について説明する。図１１は、キーコンポーネント特定の流れを表す図である。図１１の黒丸は処理の開始状態を表し、黒丸の外に丸がある２重丸の印は処理の終了状態を示す図１５も同様。コンポーネント状態管理部１０８がキーコンポーネント特定部１１０に対し、コンポーネントが非活性化されたコンポーネントの状態がＡＣＴＩＶＥからＩＤＬＥに変化した事を伝える８０１。キーコンポーネント特定部１１０は、コンポーネント情報保存部１０７に保存された通信履歴１５０６から、コンポーネントの通信相手コンポーネントのリストを作成する。ここで、特に図示しないが、コンポーネントの通信相手コンポーネントのリストは、毎回全て作り直してもよいし、コンポーネントの１活性期間内についてのみ作成してもよい。その後、キーコンポーネント特定部１１０は、作成された通信相手コンポーネントリストをコンポーネント情報保存部１０７の通信相手リスト１５１２に保存する。更にキーコンポーネント特定部１１０は、送信先コンポーネント数と受信元コンポーネント数と送受信両方を行っているコンポーネント数とを通信相手リスト１５１２と通信履歴１５０６とから算出する８０３。次に、キーコンポーネント特定部１１０は、自コンポーネントの送受信コンポーネント数と他の全てのコンポーネントの送受信コンポーネント数とを比較する。キーコンポーネント特定部１１０は、自コンポーネントの送受信コンポーネント数が最大である場合は、自コンポーネントのキーコンポーネントフラグをＯＮにする８０４。これら一連の処理は、コンポーネントが非活性化される８０１毎に各々のコンポーネント１５０１に対して実施される。
図１２は、キーコンポーネントを特定する概念を表す図である。図１０の処理の流れの結果保存された通信履歴１５０６に対し図１１の流れを適用すると図１２の様にキーコンポーネントが特定される。共有データ管理コンポーネント１０５のみがＵＩコンポーネント１０２、ジョブ制御コンポーネント１０３、デバイス制御コンポーネント１０４の３つのコンポーネントに対し送受信の関係◎で示す。送受信コンポーネントの数は４つのコンポーネントの内最大であることがわかる５１５。このことから共有データ管理コンポーネント１０５は、キーコンポーネントであると言える。
【００２２】
次に図２における故障コンポーネント特定部１０９について説明する。故障コンポーネント特定部１０９の詳細を述べる前に、故障コンポーネントを特定する概念を図１３と図１４とで説明する。図１３は、故障のない処理の通信履歴と状態変化の関係を表す図である。図１３はコンポーネントＣに着目した表であり、図１３の初めの４つの通信履歴はコンポーネントＣが１回目に活性化していた期間に発生した通信回数と通信間隔とを示している。コンポーネントＣが１回目に活性化していた期間は約３３０ｍｓであり通信回数が４回であることから平均的な通信間隔は約８０ｍｓである。更に２回目の活性期間も約３３０ｍｓであり通信回数が４回であるから平均的な通信間隔は約８０ｍｓである。３回目の活性期間についても約３３０ｍｓであり通信回数が４回であるから平均的な通信間隔は約８０ｍｓである。この場合はコンポーネントＣには故障は発生せず、活性期間中に問題は無かったと判断される。
一方、図１４に着目する。図１４は、コンポーネントＢに着目した表であり、故障コンポーネントを特定する概念を表す図である。初めの４回の通信履歴は、活性化期間３３０ｍｓの間に４回の通信が発生し平均的な通信間隔が８０ｍｓであることを示している。２回目の活性化期間もほぼ同等である。しかし３回目の活性化期間は平均的な通信間隔が２００００ｍｓであることを示している。この場合は３回目の活性化期間の平均的な通信間隔が、他の２回の活性化期間の平均的な通信間隔にたいしておおきくばらついていることが判る。このことから最後の活性化期間にはコンポーネントＢに何らかの問題が発生していて、正常に処理が行われなかった事が推定される。本図は、説明の簡略化の為に活性化期間を３回に絞って説明しているが、実際のシステム運用時は観察する活性化期間の回数は大きく、通信間隔がばらつく回数は小さいことを想定している。
【００２３】
次に故障コンポーネント特定部１０９の処理の詳細について述べる。図１５は、故障コンポーネント特定部１０９の処理の流れを示す図である。コンポーネント状態管理部１０８が故障コンポーネント特定部１０９にコンポーネントが非活性化したＡＣＴＩＶＥ→ＩＤＬＥの状態変化事を伝える９０１か、ユーザが故障診断を指示する９０２。故障コンポーネント特定部１０９は、コンポーネントが活性化されてから非活性化されるまでのキーコンポーネントとの通信回数を通信履歴から取得する９０３。コンポーネント情報保存部１０７は、状態変化履歴１５０４と状態変化時刻１５０５と通信履歴１５０６と通信時刻１５１４とを保持しているので９０３の操作が可能になる。なお９０３の処理についてはオプションとしてキーコンポーネントとの通信回数ではなく、通信相手に関わらずコンポーネントが活性化されてから非活性化されるまでの通信回数を通信履歴から取得９１０する方法であってもよい。このオプションを用いるとはキーコンポーネント特定部１１０に依存せずに故障コンポーネント特定部１０９がキーコンポーネントを特定する処理を実行する。次に、故障コンポーネント特定部１０９は、コンポーネントが活性化されていた期間を状態変化履歴から算出する９０４。次に、故障コンポーネント特定部１０９は、活性化期間を通信回数で割り、活性期間中の平均的な通信間隔を算出する９０５。故障コンポーネント特定部１０９は、算出した活性期間中の通信発生間隔をコンポーネント１５０１に対応付けられた通信発生間隔履歴１５１１に保存する９０６。次に、故障コンポーネント特定部１０９は、予め設定された過去Ｎ回分の通信発生間隔の標準偏差σと平均とを求める９０７。次に、故障コンポーネント特定部１０９は、今回最新の通信発生間隔が平均プラスマイナス３σの範囲内に入っているか９０８判断する。この部分はオプション処理として、今回最新の通信発生間隔が平均プラスマイナスｎ＊σの範囲内に入っているか９１１の処理に置き換える事もできる。ｎは予め設定しておく。故障コンポーネント特定部１０９は、範囲に入っていない９１２場合は故障通知を行う９０９。９０８９１１では、故障コンポーネント特定部１０９は、コンポーネント活性期間中の通信間隔にばらつきが発生した事を検出し、大きくばらついていた場合には正常な処理が行われていないと判断している。
【００２４】
故障通知９０９の詳細について図１６を用いて説明する。殆どの処理は図５を用いて説明された状態変化通知とジョブ処理の流れと同様である。異なる部分としては、故障コンポーネント特定部１０９が図１５の故障コンポーネント特定部１０９の処理の流れ９０９にて故障コンポーネントの故障通知を行うと、故障コンポーネント通知１４０１が発生する。故障コンポーネント通知１４０１は、故障コンポーネント特定部１０９からコンポーネント状態管理部１０８に送られる。コンポーネント状態管理部１０８は、１４０１を受信し、故障復帰処理開始指示１４０２をジョブ制御コンポーネント１０３に、故障発生通知１４０３をＵＩコンポーネント１０２に送付する。故障コンポーネント通知１４０１には故障コンポーネントを特定するコンポーネント識別子が関連付けられており、コンポーネント状態管理部１０８は該当するコンポーネントに復帰処理開始指示を送信する。図１６の実施例では故障コンポーネントがジョブ制御コンポーネント１０３であった場合を想定している。故障復帰処理開始指示１４０２を受信したジョブ制御コンポーネント１０３は、自身に実施可能な故障復帰処理を開始する事ができる。故障発生通知１４０３を受信したＵＩコンポーネント１０２は、１４０３にコンポーネント識別子を関連付けておくことで、故障発生個所をユーザに表示できる１４０４。
【００２５】
＜その他の実施形態＞
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェアプログラムを、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ又はＣＰＵやＭＰＵ等がプログラムを読み出して実行する処理である。
【００２６】
以上、上述した各実施形態によれば、コンポーネントに特別な実装を追加する事無く、通信制御ミドルウェアで、コンポーネント間で依頼と応答との通信が正常に行われた場合でも、処理が正常に進行していない状況を検出することができる。
【００２７】
以上、本発明の好ましい実施形態について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【符号の説明】
【００２８】
１０１ 通信制御部
１１２ ライフサイクル管理部
【技術分野】
【０００１】
本発明は、情報処理装置、情報処理方法及びプログラムに関する。
【背景技術】
【０００２】
従来、アプリケーションコンポーネント以下、コンポーネントという同士が通信する通信制御ミドルウェアとして、コンポーネントの状態をコンポーネントライフサイクルに渡って管理する方法は一般的である。このライフサイクル管理は一般に、システムを構成する各コンポーネントの状態をシステム状態に関連付けられる際に用いられる。例えば、障害発生時にアプリケーションを再起動する方法としては特許文献１が挙げられる。一方、システムにおける故障の検出手段については特許文献２が挙げられる。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００６−１５７３８６号公報
【特許文献２】特開平８−４４６８４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、従来のライフサイクル管理では、特許文献２に示されるように故障を検出した事をきっかけとして、特許文献１に示されるようにシステムを再起動する処理を実現できない。これには以下の問題があった。
通信制御ミドルウェアでは故障の発生を検出することができない。コンポーネント間のコマンド送受信が成功している場合、通信制御ミドルウェアでコマンドの実行が正常に行われたか判断できない。その為、故障検出の仕組みをコンポーネントに実装する必要があった。
【０００５】
本発明はこのような問題点に鑑みなされたもので、コンポーネントに特別な実装を追加する事無く、通信制御ミドルウェアで、コンポーネント間で依頼と応答との通信が正常に行われた場合でも、処理が正常に進行していない状況を検出することを目的とする。
【課題を解決するための手段】
【０００６】
そこで、本発明の情報処理装置は、複数のアプリケーションコンポーネントの通信を制御する通信制御手段と、前記複数のアプリケーションコンポーネントのライフサイクルを管理し、前記複数のアプリケーションコンポーネントの通信間隔のばらつきから故障発生を判断するライフサイクル管理手段とを有することを特徴とする。
【発明の効果】
【０００７】
本発明によれば、コンポーネントに特別な実装を追加する事無く、通信制御ミドルウェアで、コンポーネント間で依頼と応答との通信が正常に行われた場合でも、処理が正常に進行していない状況を検出することができる。
【図面の簡単な説明】
【０００８】
【図１】システム構成の一例を示す図である。
【図２】図１のＯＳ上位層を論理的に拡大表示した図である。
【図３】ＵＩコンポーネントとジョブ制御コンポーネントとのメッセージ送受信の一例を説明するための図である。
【図４】コンポーネント情報保存部について説明するための図である。
【図５】状態変化通知と、ジョブ処理の流れと、を説明するための図である。
【図６】一般的なシステムにおけるコンポーネント構成の一例を示す図である。
【図７】キーコンポーネントが多くの他のコンポーネントと通信するイメージの一例を示す図である。
【図８】図１や図２のシステムにおける、４つのコンポーネントの関係の一例を示す図である。
【図９】４つのコンポーネントが共有データ管理コンポーネントを介してデータを共有しながら、処理を進めていく様子の一例を示す図である。
【図１０】共有データコンポーネントと他のコンポーネントと通信制御のシーケンスの一例を示す図である。
【図１１】キーコンポーネント特定の流れを表す図である。
【図１２】キーコンポーネントを特定する概念を表す図である。
【図１３】故障のない処理の通信履歴と状態変化の関係を表す図である。
【図１４】コンポーネントＢに着目した表であり、故障コンポーネントを特定する概念を表す図である。
【図１５】故障コンポーネント特定部の処理の流れを示す図である。
【図１６】故障通知の詳細を説明するための図である。
【発明を実施するための形態】
【０００９】
以下、本発明の実施形態について図面に基づいて説明する。
【００１０】
＜実施形態１＞
図１は、システム構成の一例を示す図である。図１では、システム１６０１が複数のコンピュータを有している。ＣＰＵ１ １６０２とＯＳ１ １６０４とを有するコンピュータは、ユーザにインタフェースを提供し、ＣＰＵ２ １６０６とＯＳ２ １６０８とを有するコンピュータは、デバイスの制御を司る。各々のコンピュータシステムは通信制御物理層１６０３、１６０７によって物理的に接続されている。また、各々のコンピュータシステム上には通信制御ミドルウェア１６０５、１６０９が動作している。この通信制御ミドルウェア１６０５、１６０９は、アプリケーションコンポーネント以下、コンポーネントというに対し、通信制御層以下の物理的なシステム構成を隠蔽している。ユーザインタフェースを司るＣＰＵ１ １６０２とＯＳ１ １６０４とのコンピュータシステムの通信制御ミドルウェア１６０５の上にはＵＩコンポーネント１０２が動作している。装置の制御を司るＣＰＵ２ １６０６とＯＳ２ １６０８とのコンピュータシステムの通信制御ミドルウェア１６０９の上には３つのコンポーネントが動作している。即ち、ジョブ制御コンポーネント１０３とデバイス制御コンポーネント１０４と共有データ管理コンポーネント１０５とが動作している。システム１６０１は、ユーザ１６１０がＵＩコンポーネント１０２を操作し、システム内の４つのコンポーネントが協調動作することでユーザにサービスを提供する。４つのコンポーネントとは、ＵＩコンポーネント１０２、ジョブ制御コンポーネント１０３、デバイス制御コンポーネント１０４、共有データ管理コンポーネント１０５である。
なお、本実施形態では、コンピュータシステムは、１つの情報処理装置コンピュータに実装されているものとして説明を行う。情報処理装置は、通常のコンピュータのハードウェア構成を有する。情報処理装置のＣＰＵが、ＲＡＭ、ＲＯＭ、ＨＤＤ等の記憶装置に記憶されているプログラムに基づき処理を実行することによって、各コンピュータシステムの構成、及び後述する各コンピュータシステムにおける処理が実現される。なお、ＣＰＵが処理を実行する際に利用されるデータ等は、記憶装置に記憶されている。
【００１１】
ＯＳ上位層１６１１の点線で囲まれた領域について図２を用いて詳説する。図２は、図１のＯＳ上位層１６１１を論理的に拡大表示した図である。
通信制御ミドルウェア１６０５、１６０９は、通信制御部１０１とライフサイクル管理部１１２とを有している。４つのコンポーネントが通信制御部１０１とライフサイクル管理部１１２とに論理的に接続されている。これらの論理接続は各コンポーネントが通信ミドルウェアに対して行う初期化処理にて確立される。コンポーネント同士は通信制御部１０１を介してメッセージの送受信を行い、コンポーネント状態管理部１０８に状態変化の通知を行う。
通信制御部１０１の動作についてＵＩコンポーネント１０２とジョブ制御コンポーネント１０３とのメッセージ送受信を例に図３を用いて説明する。図３は、ＵＩコンポーネント１０２とジョブ制御コンポーネント１０３とのメッセージ送受信の一例を説明するための図である。
ここではＵＩコンポーネント１０２とジョブ制御コンポーネント１０３とがメッセージ送受信によりジョブスタートとジョブ終了の強調動作を行う事を想定している。ＵＩコンポーネント１０２がジョブ制御コンポーネント１０３に対してメッセージ送信を行う場合、まずＵＩコンポーネント１０２は、通信制御部１０１に対してメッセージ送信１１０１を行う。このメッセージ送信１１０１ではメッセージ内容として「ジョブスタート」、送信元としてＵＩコンポーネント１０２、送信先としてジョブ制御コンポーネントのメッセージ１１０５が送信される。通信制御部１０１ではこのメッセージ１１０５が一旦保存され、ジョブ制御コンポーネント１０３からのメッセージ受信１１０２により受け渡される１１０６。同様にジョブ制御コンポーネント１０３からＵＩコンポーネント１０２にメッセージ送信を行う場合、まずジョブ制御コンポーネント１０３から通信制御部１０１にメッセージ送信１１０３を行う。このメッセージ送信１１０３ではメッセージ内容として「ジョブ終了」、送信元としてジョブ制御コンポーネント１０３、送信先としてＵＩコンポーネント１０２のメッセージ１１０７が送信される。通信制御部１０１ではこのメッセージ１１０７を一旦保存し、ＵＩコンポーネント１０２からのメッセージ受信１１０４により受け渡される１１０８。通信制御部１０１から見れば１１０９、１１１０、１１１１、１１１２の時点でコンポーネントに対しメッセージの送受信が発生した事が明らかである。
図２の通信制御部１０１はコンポーネント間でメッセージの送受信が発生すると、通信履歴保存部１０６を介してメッセージの送受信履歴を１１０９、１１１０、１１１１、１１１２等の時点で保存する。通信履歴保存部１０６は、コンポーネント情報保存部１０７に対し通信履歴１５０６の保存を行う。
【００１２】
コンポーネント情報保存部１０７について図４を用いて述べる。図４は、コンポーネント情報保存部１０７について説明するための図である。コンポーネント情報保存部１０７は、コンポーネントに関する情報として、コンポーネント情報１５００を持つ。コンポーネント情報１５００は、複数のコンポーネントに関する情報を保持する１５０１。各コンポーネント１５０１の情報としては代表的な物としてコンポーネント識別子１５０２、現在の状態１５０３、状態変化履歴１５０４、通信履歴１５０６がある。その他にも各コンポーネント１５０１に対し、通信発生間隔履歴１５１１、キーコンポーネントフラグ１５１０、通信相手リスト１５１２が関連付けられる。各状態変化履歴１５０４には状態変化時刻１５０５が関連付けられる。各通信履歴１５０６には送信元コンポーネントと送信先コンポーネント１５０７及び通信時刻１５１４が関連付けられる。ここで言う送信元コンポーネントとはメッセージ中に定義される送信元コンポーネントであり、より具体的には１１０５、１１０６、１１０７、１１０８に示される送信元と等価である。通信履歴１５０６と関連付けられる送信先コンポーネント１５０７についても１１０５、１１０６、１１０７、１１０８に示される送信先と等価である。更に各通信履歴１５０６は通信制御部１０１から見た場合の送受信種別が関連付けられる。通信制御部１０１から見た送信とは例えば１１０１、１１０３の様な場合を示し、受信は１１０２、１１０４の様な場合を示す。
【００１３】
次に図２のコンポーネント状態管理部１０８について説明する。コンポーネント状態管理部１０８は、各コンポーネント１０２、１０３、１０４、１０５からの状態変化通知を論理的な接続１１３、１１４、１１５、１１６を介して受け取る。なお、１１３、１１４、１１５、１１６のコンポーネントとコンポーネント状態管理部１０８との論理的な接続は通信制御部１０１との接続の上で実現されてもよいし、別途確立される接続でもよい。
状態変化通知を受けたコンポーネント状態管理部１０８は、コンポーネント情報保存部１０７にて、コンポーネント１５０１に関連付けられた状態変化履歴１５０４と状態変化時刻１５０５とを保存する。
【００１４】
図５を用いて状態変化通知と、ジョブ処理の流れと、を解説する。図５は、状態変化通知と、ジョブ処理の流れと、を説明するための図である。ユーザ１０１６がＵＩコンポーネント１０２に対しユーザインタフェース等を介してスタート１００１を指示したとする。ＵＩコンポーネント１０２は、コンポーネント状態管理部１０８に対しＵＩコンポーネント１０２が活性化された事を示すＡＣＴＩＶＥ状態通知１００２を行う。このとき、コンポーネント状態管理部１０８は、コンポーネント情報保存部１０７に対しコンポーネントの状態変化履歴１５０４と状態変化時刻１５０５とをコンポーネント１５０１に関連付けて保存する。関連付けは、予めコンポーネント情報保存部１０７に設定されているコンポーネント識別子１５０２と状態変化通知であるＡＣＴＩＶＥ状態通知１００２等に付随して送られてくるコンポーネント識別子とを関連付けて実現される。コンポーネント状態管理部１０８は、コンポーネントからの状態変化通知を受ける毎にコンポーネントの状態変化履歴１５０４と状態変化時刻１５０５とを保存する。更に最新のコンポーネント状態を現在の状態１５０３に保存する。その後、ＵＩコンポーネント１０２は、ジョブ制御コンポーネント１０３にジョブスタート１００３を指示する。ＡＣＴＩＶＥ状態通知１００２やジョブスタート１００３は、実際には通信制御部１０１に対するメッセージ送受信により実施される。又は、ＡＣＴＩＶＥ状態通知１００２についてはコンポーネントとコンポーネント状態管理部１０８との間に別途確立されたコネクション上で実施されてもよい。ジョブスタート１００３を指示されたジョブ制御コンポーネント１０３は、活性化されたことをコンポーネント状態管理部１０８にＡＣＴＩＶＥ通知１００４する。その後、ジョブ制御コンポーネント１０３は、デバイス制御コンポーネント１０４にデバイス処理開始１００５を指示する。デバイス処理開始１００５を指示されたデバイス制御コンポーネント１０４は、活性化された事をコンポーネント状態管理部１０８にＡＣＴＩＶＥ通知１００６する。
【００１５】
その後、デバイス制御コンポーネント１０４にて一連のデバイス制御処理を実施し、処理が終了したらデバイス制御コンポーネント１０４が非活性化された事をコンポーネント状態管理部１０８に通知する。この通知は、デバイス制御コンポーネント１０４からコンポーネント状態管理部１０８に対しＩＤＬＥ１００７を通知する事で実施される。その後、デバイス制御コンポーネント１０４は、デバイス処理が終了したことをジョブ制御コンポーネント１０３に通知する１００８。デバイス処理終了１００８通知を受けたジョブ制御コンポーネント１０３は、コンポーネント状態管理部１０８に対して自身が非活性化されることをＩＤＬＥ１００９通知する。その後、ジョブ制御コンポーネント１０３は、ＵＩコンポーネント１０２に対しジョブ処理が終了１０１０したことを通知する。ジョブ処理の終了１０１０通知を受けたＵＩコンポーネント１０２は、自身が非活性化される事をＩＤＬＥ１０１１通知によりコンポーネント状態管理部１０８に伝え、ユーザに処理が終了した事を通知１０１２する。なお、共有データ管理コンポーネント１０５は、ジョブのスタート１００１や終了の通知１０１２に関わらず、システムが起動するより前に活性化されている必用がある１０１４。更にシステムが終了する前に非活性化される１０１５。
【００１６】
なお、共有データ管理コンポーネント１０５は、活性化される前にコンポーネント状態管理部１０８に対し、コンポーネント属性送信１０１３を行ってもよい。図２ではこの属性送信はキーコンポーネント特定属性１１１によって表されている。このコンポーネント属性送信１０１３は、共有データ管理コンポーネント１０５が自らをキーコンポーネントであることを宣言する意味を持つ。このコンポーネント属性送信１０１３を受けた場合は、コンポーネント状態管理部１０８は、該当コンポーネントのキーコンポーネントフラグ１５１０をＯＮにする。コンポーネント属性送信１０１３にはコンポーネント識別子が関連付けられているものとする。なお、キーコンポーネント特定属性送信は必ずしも実装される必要はなく、キーコンポーネント特定部１１０によりキーコンポーネントの特定を行うようにしてもよい。
【００１７】
ここでキーコンポーネントとは何かを解説する。図６は、一般的なシステム２０４におけるコンポーネント構成の一例を示す図である。丸印２０３は１つのコンポーネントを示している。また、２０１２０２の様な太陽印はキーコンポーネントを示している。ここでは、キーコンポーネントとしてデータを共有するコンポーネント２０２と、状態を同期するコンポーネント２０１と、を仮定している。システムが例えば２台のコンピュータシステムで構成されている場合、各々のコンピュータシステム上に複数の論理的ドメインが構成されシステムが構成される場合が多い。例えば、最上位ドメインはユーザインタフェースドメイン２０５であり、次がアプリケーションサービスを提供するＡＰＳドメイン２０６であり、次がジョブ制御を行うＪｏｂＣｔｒｌ２０７ドメインである。ここまでが一台のコンピュータシステム上に構成されるとする。更にもう一台のコンピュータシステム上には以下３つのドメインが構成されるものとする。即ち、組込機器の上位層としてジョブ制御を行うＥｍｂｅｄｅｄ Ｊｏｂ Ｃｔｒｌ２０８ドメイン。組込機器の機能制御を行うＥｍｂｅｄｅｄ Ｆｕｎｃｔｉｏｎ Ｃｔｒｌ２０９ドメイン。組込機器のデバイス制御を行うＥｍｂｅｄｅｄ Ｄｅｖｅｉｃｅ Ｃｔｒｌ２１０ドメイン、の３ドメインである。各ドメインを構成するコンポーネント同士は一般に、隣のドメインに存在するコンポーネントと協調しながらシステム全体が動作しサービスを提供する。一方、システムには、２０１２０２に示す様な、ドメインを跨って全コンポーネントに対しデータや状態を同期する、コンポーネントが幾つかは存在する場合が多い。本実施形態ではこの様にシステム上の多くのコンポーネントからアクセスされるコンポーネントをキーコンポーネントと呼ぶ。図７は、キーコンポーネント３０１が多くの他のコンポーネント３０２と通信するイメージの一例を示す図である。
【００１８】
図８は、図１や図２のシステムにおける、４つのコンポーネントの関係の一例を示す図である。ＵＩコンポーネント１０２は、ジョブ制御コンポーネント１０３に対しジョブスタート・終了４０１の関係を持つ。ジョブ制御コンポーネント１０３とデバイス制御コンポーネント１０４とはデバイス処理開始・終了の関係４０２を持つ。一方、共有データ管理コンポーネント１０５とＵＩコンポーネント１０２とはジョブデータセット・取得・結果データ取得４０３の関係を持つ。共有データ管理コンポーネント１０５とジョブ制御コンポーネント１０３とはデバイス処理データセット・結果取得４０４の関係を持つ。更に、共有データ管理コンポーネント１０５とデバイス制御コンポーネント１０４とはデバイス処理データ取得・更新４０５の関係を持つ。即ち、サービス提供を制御する系統のコンポーネントである、ＵＩコンポーネント１０２、ジョブ制御コンポーネント１０３、デバイス制御コンポーネント１０４は、互いに数珠繋ぎの関係を持つ。一方でサービス提供を制御する系統の各々のコンポーネント１０２、１０３、１０４は、処理を進める為にデータを共有する必要性から、共有データ管理コンポーネント１０５とは中央集権型の関係を持つ。つまり共有データ管理コンポーネント１０５は、本実施形態におけるキーコンポーネントであると見なす事ができる。
【００１９】
図９は、４つのコンポーネントが共有データ管理コンポーネント１０５を介してデータを共有しながら、処理を進めていく様子の一例を示す図である。ユーザ１２１５がＵＩコンポーネント１０２に対してスタート１２０１を指示する。ＵＩコンポーネント１０２は、共有データ管理コンポーネント１０５にジョブデータセット１２０２を行い、ジョブ制御コンポーネント１０３にジョブスタート１２０３を指示する。ジョブ制御コンポーネント１０３は、ジョブスタート１２０３を受けると、ジョブデータ取得１２０４とデバイス処理データセット１２０５とを共有データ管理コンポーネント１０５に対して行う。その後、ジョブ制御コンポーネント１０３は、デバイス制御コンポーネント１０４にデバイス処理開始１２０６を指示する。指示を受けたデバイス制御コンポーネント１０４は、デバイス処理データ取得１２０７とデバイス処理データ更新１２０８とを共有データ管理コンポーネント１０５に対して行う。その後、デバイス制御コンポーネント１０４がデバイス制御処理を終えるとデバイス処理終了１２０９をジョブ制御コンポーネント１０３に通知する。デバイス処理終了１２０９を受けたジョブ制御コンポーネント１０３は、デバイス処理結果データ取得１２１０を共有データ管理コンポーネント１０５から行う。その後、ジョブ制御コンポーネント１０３は、ＵＩコンポーネント１０２に対しジョブ終了１２１１を通知する。ジョブ終了１２１１を受信したＵＩコンポーネント１０２はジョブ処理結果データ取得１２１２を共有データ管理コンポーネント１０５から行う。その後、ＵＩコンポーネント１０２は、ユーザに対しジョブ処理結果データ表示１２１３と、終了通知１２１４と、を行う。ここで示したジョブスタート１２０３、ジョブ終了１２１１、デバイス処理開始１２０６、デバイス処理終了１２０９は、通信制御部１０１を介して伝達される事は図３に解説した通りである。一方でジョブデータセット１２０２、ジョブデータ取得１２０４、１２０５、１２０７、１２０８１２１０、１２１２についても通信制御部１０１を介して伝達される。その様子を、図１０を用いて説明する。
【００２０】
図１０は、共有データコンポーネントと他のコンポーネントと通信制御のシーケンスの一例を示す図である。ＵＩコンポーネント１０２が共有データ管理コンポーネント１０５に対してジョブデータセット１２０２を実施する際、ＵＩコンポーネント１０２はまず通信制御部１０１に対しメッセージ送信１３０１を行う。この際「メッセージ内容：ジョブデータセット、送信元ＵＩコンポーネント、送信先共有データ管理コンポーネント」１３０５、のメッセージが通信制御部１０１に対して送信される。共有データ管理コンポーネント１０５は通信制御部１０１からメッセージ受信１３０２を行い、１３０６、１３０５と等価のメッセージを受け取る。１３０９、１３１０のタイミングで通信制御部１０１は、通信履歴保存部１０６を介してコンポーネント情報保存部１０７に通信履歴１５０６を保存する。通信履歴１５０６に対応して通信時刻１５１４も保存される。同様にＵＩコンポーネント１０２が共有データ管理コンポーネント１０５からジョブ処理結果データ取得１２１２を行う際はまず通信制御部１０１に対しメッセージ送信１３０３を行う。このメッセージには「メッセージ内容：ジョブ処理結果データ取得、送信元：ＵＩコンポーネント、送信先：共有データ管理コンポーネント」１３０８のメッセージが通信制御部１０１に対して送信される。共有データ管理コンポーネント１０５は、通信制御部１０１からメッセージ受信１３０４を行い、１３０７、１３０８と等価のメッセージを受け取る。１３１１、１３１２のタイミングで通信制御部１０１は、通信履歴保存部１０６を介してコンポーネント情報保存部１０７に通信履歴１５０６を保存する。通信履歴１５０６に対応して通信時刻１５１４も保存される。これにより図９で示される、４つのコンポーネントが共有データ管理コンポーネント１０５を介してデータを共有しながら、処理を進めていく様子は全てコンポーネント情報保存部１０７の通信履歴１５０６に保存される。
【００２１】
次に図２におけるキーコンポーネント特定部１１０について説明する。図１１は、キーコンポーネント特定の流れを表す図である。図１１の黒丸は処理の開始状態を表し、黒丸の外に丸がある２重丸の印は処理の終了状態を示す図１５も同様。コンポーネント状態管理部１０８がキーコンポーネント特定部１１０に対し、コンポーネントが非活性化されたコンポーネントの状態がＡＣＴＩＶＥからＩＤＬＥに変化した事を伝える８０１。キーコンポーネント特定部１１０は、コンポーネント情報保存部１０７に保存された通信履歴１５０６から、コンポーネントの通信相手コンポーネントのリストを作成する。ここで、特に図示しないが、コンポーネントの通信相手コンポーネントのリストは、毎回全て作り直してもよいし、コンポーネントの１活性期間内についてのみ作成してもよい。その後、キーコンポーネント特定部１１０は、作成された通信相手コンポーネントリストをコンポーネント情報保存部１０７の通信相手リスト１５１２に保存する。更にキーコンポーネント特定部１１０は、送信先コンポーネント数と受信元コンポーネント数と送受信両方を行っているコンポーネント数とを通信相手リスト１５１２と通信履歴１５０６とから算出する８０３。次に、キーコンポーネント特定部１１０は、自コンポーネントの送受信コンポーネント数と他の全てのコンポーネントの送受信コンポーネント数とを比較する。キーコンポーネント特定部１１０は、自コンポーネントの送受信コンポーネント数が最大である場合は、自コンポーネントのキーコンポーネントフラグをＯＮにする８０４。これら一連の処理は、コンポーネントが非活性化される８０１毎に各々のコンポーネント１５０１に対して実施される。
図１２は、キーコンポーネントを特定する概念を表す図である。図１０の処理の流れの結果保存された通信履歴１５０６に対し図１１の流れを適用すると図１２の様にキーコンポーネントが特定される。共有データ管理コンポーネント１０５のみがＵＩコンポーネント１０２、ジョブ制御コンポーネント１０３、デバイス制御コンポーネント１０４の３つのコンポーネントに対し送受信の関係◎で示す。送受信コンポーネントの数は４つのコンポーネントの内最大であることがわかる５１５。このことから共有データ管理コンポーネント１０５は、キーコンポーネントであると言える。
【００２２】
次に図２における故障コンポーネント特定部１０９について説明する。故障コンポーネント特定部１０９の詳細を述べる前に、故障コンポーネントを特定する概念を図１３と図１４とで説明する。図１３は、故障のない処理の通信履歴と状態変化の関係を表す図である。図１３はコンポーネントＣに着目した表であり、図１３の初めの４つの通信履歴はコンポーネントＣが１回目に活性化していた期間に発生した通信回数と通信間隔とを示している。コンポーネントＣが１回目に活性化していた期間は約３３０ｍｓであり通信回数が４回であることから平均的な通信間隔は約８０ｍｓである。更に２回目の活性期間も約３３０ｍｓであり通信回数が４回であるから平均的な通信間隔は約８０ｍｓである。３回目の活性期間についても約３３０ｍｓであり通信回数が４回であるから平均的な通信間隔は約８０ｍｓである。この場合はコンポーネントＣには故障は発生せず、活性期間中に問題は無かったと判断される。
一方、図１４に着目する。図１４は、コンポーネントＢに着目した表であり、故障コンポーネントを特定する概念を表す図である。初めの４回の通信履歴は、活性化期間３３０ｍｓの間に４回の通信が発生し平均的な通信間隔が８０ｍｓであることを示している。２回目の活性化期間もほぼ同等である。しかし３回目の活性化期間は平均的な通信間隔が２００００ｍｓであることを示している。この場合は３回目の活性化期間の平均的な通信間隔が、他の２回の活性化期間の平均的な通信間隔にたいしておおきくばらついていることが判る。このことから最後の活性化期間にはコンポーネントＢに何らかの問題が発生していて、正常に処理が行われなかった事が推定される。本図は、説明の簡略化の為に活性化期間を３回に絞って説明しているが、実際のシステム運用時は観察する活性化期間の回数は大きく、通信間隔がばらつく回数は小さいことを想定している。
【００２３】
次に故障コンポーネント特定部１０９の処理の詳細について述べる。図１５は、故障コンポーネント特定部１０９の処理の流れを示す図である。コンポーネント状態管理部１０８が故障コンポーネント特定部１０９にコンポーネントが非活性化したＡＣＴＩＶＥ→ＩＤＬＥの状態変化事を伝える９０１か、ユーザが故障診断を指示する９０２。故障コンポーネント特定部１０９は、コンポーネントが活性化されてから非活性化されるまでのキーコンポーネントとの通信回数を通信履歴から取得する９０３。コンポーネント情報保存部１０７は、状態変化履歴１５０４と状態変化時刻１５０５と通信履歴１５０６と通信時刻１５１４とを保持しているので９０３の操作が可能になる。なお９０３の処理についてはオプションとしてキーコンポーネントとの通信回数ではなく、通信相手に関わらずコンポーネントが活性化されてから非活性化されるまでの通信回数を通信履歴から取得９１０する方法であってもよい。このオプションを用いるとはキーコンポーネント特定部１１０に依存せずに故障コンポーネント特定部１０９がキーコンポーネントを特定する処理を実行する。次に、故障コンポーネント特定部１０９は、コンポーネントが活性化されていた期間を状態変化履歴から算出する９０４。次に、故障コンポーネント特定部１０９は、活性化期間を通信回数で割り、活性期間中の平均的な通信間隔を算出する９０５。故障コンポーネント特定部１０９は、算出した活性期間中の通信発生間隔をコンポーネント１５０１に対応付けられた通信発生間隔履歴１５１１に保存する９０６。次に、故障コンポーネント特定部１０９は、予め設定された過去Ｎ回分の通信発生間隔の標準偏差σと平均とを求める９０７。次に、故障コンポーネント特定部１０９は、今回最新の通信発生間隔が平均プラスマイナス３σの範囲内に入っているか９０８判断する。この部分はオプション処理として、今回最新の通信発生間隔が平均プラスマイナスｎ＊σの範囲内に入っているか９１１の処理に置き換える事もできる。ｎは予め設定しておく。故障コンポーネント特定部１０９は、範囲に入っていない９１２場合は故障通知を行う９０９。９０８９１１では、故障コンポーネント特定部１０９は、コンポーネント活性期間中の通信間隔にばらつきが発生した事を検出し、大きくばらついていた場合には正常な処理が行われていないと判断している。
【００２４】
故障通知９０９の詳細について図１６を用いて説明する。殆どの処理は図５を用いて説明された状態変化通知とジョブ処理の流れと同様である。異なる部分としては、故障コンポーネント特定部１０９が図１５の故障コンポーネント特定部１０９の処理の流れ９０９にて故障コンポーネントの故障通知を行うと、故障コンポーネント通知１４０１が発生する。故障コンポーネント通知１４０１は、故障コンポーネント特定部１０９からコンポーネント状態管理部１０８に送られる。コンポーネント状態管理部１０８は、１４０１を受信し、故障復帰処理開始指示１４０２をジョブ制御コンポーネント１０３に、故障発生通知１４０３をＵＩコンポーネント１０２に送付する。故障コンポーネント通知１４０１には故障コンポーネントを特定するコンポーネント識別子が関連付けられており、コンポーネント状態管理部１０８は該当するコンポーネントに復帰処理開始指示を送信する。図１６の実施例では故障コンポーネントがジョブ制御コンポーネント１０３であった場合を想定している。故障復帰処理開始指示１４０２を受信したジョブ制御コンポーネント１０３は、自身に実施可能な故障復帰処理を開始する事ができる。故障発生通知１４０３を受信したＵＩコンポーネント１０２は、１４０３にコンポーネント識別子を関連付けておくことで、故障発生個所をユーザに表示できる１４０４。
【００２５】
＜その他の実施形態＞
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェアプログラムを、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ又はＣＰＵやＭＰＵ等がプログラムを読み出して実行する処理である。
【００２６】
以上、上述した各実施形態によれば、コンポーネントに特別な実装を追加する事無く、通信制御ミドルウェアで、コンポーネント間で依頼と応答との通信が正常に行われた場合でも、処理が正常に進行していない状況を検出することができる。
【００２７】
以上、本発明の好ましい実施形態について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【符号の説明】
【００２８】
１０１ 通信制御部
１１２ ライフサイクル管理部
【特許請求の範囲】
【請求項１】
複数のアプリケーションコンポーネントの通信を制御する通信制御手段と、
前記複数のアプリケーションコンポーネントのライフサイクルを管理し、前記複数のアプリケーションコンポーネントの通信間隔のばらつきから故障発生を判断するライフサイクル管理手段と、
を有することを特徴とする情報処理装置。
【請求項２】
前記ライフサイクル管理手段は、前記複数のアプリケーションコンポーネントのうち、他のアプリケーションコンポーネントとのメッセージの送受信の量に基づいて、キーとなるコンポーネントを特定し、コンポーネントの活性期間における前記コンポーネントと前記特定したコンポーネントとの通信間隔のばらつきから故障発生を判断することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
通信制御手段と、ライフサイクル管理手段と、を有する通信制御ミドルウェア手段を有する情報処理装置における情報処理方法であって、
前記通信制御手段が、複数のアプリケーションコンポーネントの通信を制御する制御ステップと、
前記ライフサイクル管理手段が、前記複数のアプリケーションコンポーネントのライフサイクルを管理し、前記複数のアプリケーションコンポーネントの活性期間の通信間隔のばらつきから故障発生を判断するライフサイクル管理ステップと、
を含むことを特徴とする情報処理方法。
【請求項４】
コンピュータを、
複数のアプリケーションコンポーネントの通信を制御する通信制御手段と、
前記複数のアプリケーションコンポーネントのライフサイクルを管理し、前記複数のアプリケーションコンポーネントの活性期間の通信間隔のばらつきから故障発生を判断するライフサイクル管理手段と、
して機能させることを特徴とするプログラム。
【請求項１】
複数のアプリケーションコンポーネントの通信を制御する通信制御手段と、
前記複数のアプリケーションコンポーネントのライフサイクルを管理し、前記複数のアプリケーションコンポーネントの通信間隔のばらつきから故障発生を判断するライフサイクル管理手段と、
を有することを特徴とする情報処理装置。
【請求項２】
前記ライフサイクル管理手段は、前記複数のアプリケーションコンポーネントのうち、他のアプリケーションコンポーネントとのメッセージの送受信の量に基づいて、キーとなるコンポーネントを特定し、コンポーネントの活性期間における前記コンポーネントと前記特定したコンポーネントとの通信間隔のばらつきから故障発生を判断することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
通信制御手段と、ライフサイクル管理手段と、を有する通信制御ミドルウェア手段を有する情報処理装置における情報処理方法であって、
前記通信制御手段が、複数のアプリケーションコンポーネントの通信を制御する制御ステップと、
前記ライフサイクル管理手段が、前記複数のアプリケーションコンポーネントのライフサイクルを管理し、前記複数のアプリケーションコンポーネントの活性期間の通信間隔のばらつきから故障発生を判断するライフサイクル管理ステップと、
を含むことを特徴とする情報処理方法。
【請求項４】
コンピュータを、
複数のアプリケーションコンポーネントの通信を制御する通信制御手段と、
前記複数のアプリケーションコンポーネントのライフサイクルを管理し、前記複数のアプリケーションコンポーネントの活性期間の通信間隔のばらつきから故障発生を判断するライフサイクル管理手段と、
して機能させることを特徴とするプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【公開番号】特開２０１２−１２３７２２（Ｐ２０１２−１２３７２２Ａ）
【公開日】平成２４年６月２８日（２０１２．６．２８）
【国際特許分類】
【出願番号】特願２０１０−２７５７４１（Ｐ２０１０−２７５７４１）
【出願日】平成２２年１２月１０日（２０１０．１２．１０）
【出願人】（０００００１００７）キヤノン株式会社 (59,756)
【Ｆターム（参考）】
【公開日】平成２４年６月２８日（２０１２．６．２８）
【国際特許分類】
【出願日】平成２２年１２月１０日（２０１０．１２．１０）
【出願人】（０００００１００７）キヤノン株式会社 (59,756)
【Ｆターム（参考）】
[ Back to top ]