(57)【要約】【課題】ミドルウェアを介してネットワーク上に接続された複数の通信コンポーネントを備える通信処理装置において、ネットワークの通信先のコンポーネントの物理配置が変化しても、正常な通信が行うことを可能にする。【解決手段】第１通信手段は、情報処理装置が停止した際に第２通信手段に通知する。第２通信手段は、情報処理装置上で動作しているプロセスのプロセスＩＤと、該プロセスに予め割り当てられている論理ＩＤと、の間の対応付け情報を格納する。通信先となるプロセスの論理ＩＤに対応するプロセスＩＤを取得する。取得したプロセスＩＤを有する、情報処理装置上で動作するプロセスとの通信を実行する。情報処理装置が停止したことを通知された際に、情報処理装置で動作するそれぞれのプロセスについて格納している対応付け情報を無効化する。【選択図】図１
2011227867.tif 000002
【特許請求の範囲】
【請求項１】
情報処理装置と通信する第１通信手段と、前記情報処理装置上で動作するプロセスと前記第１通信手段を介して通信する第２通信手段と、を有する通信処理装置であって、
前記第１通信手段は、
前記情報処理装置が停止した際に前記第２通信手段に通知する通知手段を備え、
前記第２通信手段は、
前記情報処理装置上で動作しているプロセスのプロセスＩＤと、該プロセスに予め割り当てられている論理ＩＤと、の間の対応付け情報を格納する格納手段と、
通信先となるプロセスの論理ＩＤに対応するプロセスＩＤを前記格納手段を参照して取得する取得手段と、
前記取得手段が取得したプロセスＩＤを有する、前記情報処理装置上で動作するプロセスとの通信を実行する実行手段と、
前記通知手段によって前記情報処理装置が停止したことを通知された際に、前記情報処理装置で動作するそれぞれのプロセスについての前記格納手段が格納している対応付け情報を無効化する無効化手段と
を備えることを特徴とする通信処理装置。
【請求項２】
前記第２通信手段は、更に、
通信先となるプロセスについての前記対応付け情報が前記格納手段に格納されていないか又は無効化されている場合、該通信先となるプロセスの前記論理ＩＤに対応するプロセスＩＤを前記第１通信手段に問合せる問合せ手段と、
前記問合せに対する応答として前記第１通信手段から前記通信先となるプロセスのプロセスＩＤを取得し、該プロセスＩＤと、前記通信先となるプロセスの前記論理ＩＤと、の間の対応付け情報を前記格納手段に格納する登録手段と、
を備えることを特徴とする請求項１に記載の通信処理装置。
【請求項３】
前記第１通信手段は、更に、
複数の情報処理装置について、それぞれの情報処理装置上で動作しているプロセスのプロセスＩＤと、該プロセスの前記論理ＩＤと、の間の対応付け情報を格納する管理手段と、
前記第２通信手段から前記問合せを受けた場合に、前記通信先となるプロセスの前記論理ＩＤに対応するプロセスＩＤを前記管理手段を参照して取得し、該取得したプロセスＩＤを前記第２通信手段へ送信する送信手段と
を備えることを特徴とする請求項２に記載の通信処理装置。
【請求項４】
情報処理装置と通信する第１通信手段と、前記情報処理装置上で動作するプロセスと前記第１通信手段を介して通信する第２通信手段と、を有する通信処理装置が行う情報処理方法であって、
前記第２通信手段は、前記情報処理装置上で動作しているプロセスのプロセスＩＤと、該プロセスに予め割り当てられている論理ＩＤと、の間の対応付け情報を格納する格納手段を有し、
前記第２通信手段の取得手段が、通信先となるプロセスの論理ＩＤに対応するプロセスＩＤを前記格納手段を参照して取得する取得工程と、
前記第２通信手段の実行手段が、前記取得工程で取得したプロセスＩＤを有する、前記情報処理装置上で動作するプロセスとの通信を実行する実行工程と、
前記第１通信手段の通信手段が、前記情報処理装置が停止した際に前記第２通信手段に通知する通知工程と、
前記通知工程において前記情報処理装置が停止したことを通知された際に、前記情報処理装置で動作するそれぞれのプロセスについての前記格納手段が格納している対応付け情報を無効化する無効化工程と
を備えることを特徴とする通信処理方法。
【請求項５】
コンピュータを、請求項１乃至３の何れか１項に記載の通信処理装置が有する各手段として機能させるためのプログラム。
【請求項６】
請求項５に記載のプログラムを格納した、コンピュータが読み取り可能な記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークのノードにミドルウェアを介して接続された通信処理装置およびその制御方法に関する。
【背景技術】
【０００２】
近年、ソフトウェアシステム開発においては、ソフトウェアのコンポーネント化が推進されている。そこではまず、ソフトウェアを相互に依存度の低いコンポーネント（部品）単位に分割し、分割したコンポーネントを様々な通信チャネルを持った複数の情報処理装置（ノード）に配置する。そして、コンポーネント同士は、相互に通信を行いながら動作するものである。さらに、コンポーネント間の通信では、通信制御を統一的に行う通信ミドルウェアを導入し、異なる通信チャネルを隠蔽して通信のインタフェースを統一する。このインタフェースの統一によって、システムの保守性を向上させたり、コンポーネントの再利用による生産性を向上させたりしている。
【０００３】
この統一されたインタフェースにおいて、通信相手となるコンポーネントを特定するためのＩＤとして、どのような情報を利用するかは、システム設計において重要な事項である。なぜなら、その利用する情報が、コンポーネント設計の柔軟性やシステムの動作速度に影響を与えるからである。
【０００４】
一般的に、通信相手を特定するＩＤとしては、抽象度の低い物理ＩＤを使ったり、抽象度の高い論理ＩＤを使ったりすることが考えられる。前者は、通信相手が配置されているノード、所属するプロセス、そして関連付けられている物理的な情報を内包した物理ＩＤを利用して通信を行う方法（以下、「物理ＩＤを使った通信方法」と呼ぶ）である。後者は、コンポーネント名称などの抽象度の高い論理ＩＤを用いて通信相手を特定するとともに、通信ミドルウェアがコンポーネント名称と通信相手の物理的な情報との関連を管理し、通信時に論理ＩＤから物理的な情報（物理ＩＤなど）への変換を行う方法である。（以下、「論理ＩＤを使った通信方法」と呼ぶ。）
【０００５】
また、「物理ＩＤを使った通信方法」では、ＩＤの中に通信経路を特定する情報が含まれているため、通信処理にかかる時間を減らすことができ、高速な通信を行うことができる。反面、コンポーネント設計に対する柔軟性が乏しくなってしまう。
【０００６】
更に、「論理ＩＤを使った通信方法」では、通信を行うたびに論理ＩＤから物理的な情報への変換処理を行う必要がある。複数ノードから成るシステムでは、コンポーネントの物理的な情報は、ノードをまたがって集中管理される必要がある。従って、「論理ＩＤを使った通信方法」では、通信元となるコンポーネントからコンポーネントの物理的な情報にアクセスし、論理ＩＤを物理的な情報に変換する処理には時間がかかるので、通信にかかる計算コストは高くなる。しかしながら、コンポーネントは、動作時に自由に複数ノードに跨って配置することができ、設計の柔軟性は高くなる。
【０００７】
物理ＩＤと論理ＩＤの長所を生かすべくこれらを併用し、初回の通信のみ論理ＩＤから物理的な情報へ変換し、２度目からは得られた物理的な情報を直接用いて通信をする方法（以下、「初回のみ論理ＩＤを使用する方法」）も考えられる。この方法では設計の柔軟性と通信速度を両立させることができるが、システム動作中にコンポーネントの物理配置が変わってしまうようなシステムにおいては、通信の宛先となる物理的な情報を何らかの方法で補正する必要が生じる。
【０００８】
特開２００９−００９６０７号公報は、データの物理的な配置情報と論理的な名前の対応をテーブルで管理し、物理配置を隠蔽するミドルウェアに関するものである。物理配置が変更になった場合に、テーブルを自動で更新することで、アクセス元のプログラムはデータの配置変更を意識せずに済むものである。
【０００９】
特開２００７−２８１８３９号公報は、バスリセットが発生すると、ネットワークの構成変更があるかどうかを走査して、物理的な配置情報と論理的な位置情報との対応表を更新することを提案している。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】特開２００９−００９６０７号公報
【特許文献２】特開２００７−２８１８３９号公報
【発明の概要】
【発明が解決しようとする課題】
【００１１】
複数ノードで構成されるシステムにおいて、システム自体は動きつづけたまま、一部のノードだけが再起動してしまうことがある。一部ノードが再起動すると、該当ノード上にあるコンポーネントの所属するプロセスＩＤなどの情報が変化してしまうことがある。
【００１２】
例えば、あるノードが停止した後に再起動すると、そのノードに配置されたコンポーネントは一度終了した後に再起動することになる。一般的なコンピュータのＯＳにおいて、プロセスＩＤは、起動した順に割り付けられるものであり、また複数のプロセスから成るシステムにおいては、プロセスが起動する順序は厳密に一意に決められるものではない。
【００１３】
つまり、あるノードが再起動した場合、そのノードに配置されたコンポーネントは、再起動の前後で同じプロセスＩＤを割り付けられるとは限らず、結果としてプロセスＩＤを内包する物理ＩＤで示される物理配置も再起動の前後で異なってしまう場合がある。その場合、「初回のみ論理ＩＤを使用する方法」では、通信先の物理的な情報が変化してしまうことから、正常な通信ができなくなってしまう。正しい通信先の物理的な情報を取得するためには、一部のノードが再起動した後に論理ＩＤから物理配置への変換処理をやり直す必要がある。しかし、システム内に多数のコンポーネントが存在する場合、全てのコンポーネントにノード再起動の検知と再変換処理を実装するのはコストが高く非効率である。
【００１４】
特開２００９−００９６０７号公報の方法では、複数ノードにまたがるシステムにおいては、コンポーネントの情報をノードをまたいで集中管理する必要があり、関連テーブルに毎回アクセスすると通信負荷が高くなることがある。
【００１５】
また特開２００７−２８１８３９号公報では、バスリセットによる情報の変更が発生するたびに全てのデバイス（通信端点）を走査して配置情報を更新している。そのため、再起動されないデバイスで動作するコンポーネントの情報などを余計に更新するのでトラフィックが大きくなってしまう。
【００１６】
本発明は係る課題に鑑み、ミドルウェアを介してネットワーク上に接続された複数の通信コンポーネントを備える通信処理装置において、ネットワークの通信先のコンポーネントの物理配置が変化しても、正常な通信が行うことを可能にする技術を提供する。
【課題を解決するための手段】
【００１７】
本発明の通信処理装置は、情報処理装置と通信する第１通信手段と、前記情報処理装置上で動作するプロセスと前記第１通信手段を介して通信する第２通信手段と、を有する通信処理装置であって、
前記第１通信手段は、
前記情報処理装置が停止した際に前記第２通信手段に通知する通知手段を備え、
前記第２通信手段は、
前記情報処理装置上で動作しているプロセスのプロセスＩＤと、該プロセスに予め割り当てられている論理ＩＤと、の間の対応付け情報を格納する格納手段と、
通信先となるプロセスの論理ＩＤに対応するプロセスＩＤを前記格納手段を参照して取得する取得手段と、
前記取得手段が取得したプロセスＩＤを有する、前記情報処理装置上で動作するプロセスとの通信を実行する実行手段と、
前記通知手段によって前記情報処理装置が停止したことを通知された際に、前記情報処理装置で動作するそれぞれのプロセスについての前記格納手段が格納している対応付け情報を無効化する無効化手段と
を備えることを特徴とする。
【発明の効果】
【００１８】
ミドルウェアを介してネットワーク上に接続された複数の通信コンポーネントを備える通信処理装置において、ネットワークの通信先のコンポーネントの物理配置が変化しても、正常な通信を行うことができる。
【図面の簡単な説明】
【００１９】
【図１】通信処理システムの全体を示す図。
【図２】物理ＩＤの例を示す図。
【図３】ＩＤ変換テーブルの具体的な例を示す図。
【図４】「物理ＩＤを使った通信方法」の構成を示す図。
【図５】「物理ＩＤを使った通信方法」のメッセージ送信のフローを示す図。
【図６】「論理ＩＤを使った通信方法」の構成を示す図。
【図７】「論理ＩＤを使った通信方法」のメッセージ送信のフローを示す図。
【図８】「初回のみ論理ＩＤを使用する通信方法」のメッセージ送信のフローを示す図。
【図９】本発明のメッセージ送信のフローを示す図。
【図１０】本発明のノード停止検出時の処理フローを示す図。
【図１１】本発明の追加の処理フローを示す図。
【図１２】通信処理装置（ノード）のハードウェア構成を詳細に示すシステム図。
【図１３】コンポーネントと通信ミドルウェアとの間の通信フローを示す図。
【発明を実施するための形態】
【００２０】
＜実施形態１＞
図１２は、実施形態１における、通信処理装置の構成例を示す図である。図１２において、ノード０１及びノード０２が、本実施形態に係る通信処理装置に相当する。図１２において、ノード０１とノード０２とは、通信路１２を経由して通信することができる。以下に、ノード０１の詳細な構成について説明する。ノード０２はノード０１と同様の構成を有する。このため、ノード０２についての詳細な説明は省略する。
【００２１】
ノード０１には、ＣＰＵ１３、ネットワークコントローラ０３およびメモリ０５が配置されており、これらはシステムバス０４によって相互に接続されている。メモリ０５は、ＣＰＵ１３の備えるメモリ保護機構によってプロセスごとに分割されている。図１２の例では、ノード０１では通信ミドルウェア（第１通信手段）、コンポーネントＡ及びコンポーネントＢが動作している。したがって、メモリ０５内には通信ミドルウェア用メモリ空間０６、コンポーネントＡ用メモリ空間０７、及びコンポーネントＢ用メモリ空間０８が存在する。
【００２２】
これらメモリ空間０６〜０８内には、論理ＩＤと物理ＩＤとの変換テーブルが独立に保持されている。すなわち、通信ミドルウェア用メモリ空間０６内には変換テーブル０９が、コンポーネントＡ用メモリ空間０７内には変換テーブル１０が、コンポーネントＢ用メモリ空間０８内には変換テーブル１１が、それぞれ存在する。上述のようにノード０１は通信路１２を経由してノード０２と接続されている。ノード０１の通信ミドルウェアは、ネットワークコントローラ０３を介してノード０２と通信を行う。
【００２３】
図１は、実施形態１における、ネットワークを介して通信コンポーネント間で通信を行う通信処理システムの概略を示す図である。この通信処理システムは、複数の通信処理装置（情報処理装置）であるノード０１、０２に接続された、通信機能を提供する通信ミドルウェア１０３と複数のコンポーネントＡ、Ｂとを含む。通信ミドルウェア１０３は、ノード間、プロセス間などの通信を抽象化する機能を持っている。図１の例においてノード０１及びノード０２上（情報処理装置上）では、通信ミドルウェア１０３を実現するプログラムが動作しており、これらのプログラムが連携することによって通信ミドルウェア１０３が実現されている。通信ミドルウェア１０３は、ＩＤ集中管理機能１０４およびノード動作状態管理機能１０５を有している。ノード動作状態管理機能１０５は、システムを構成する各ノードの状態を監視し、現在動作中であるか、あるいは停止中であるかを管理している。通信ミドルウェア１０３上には、通信端点となる複数のソフトウェアのコンポーネントＡ、Ｂが動作している（図４参照）。そして、コンポーネントＡは、ノード０１上で、またコンポーネントＢは、ノード０２上でそれぞれ動作している。通信コンポーネント（第２通信手段）であるコンポーネントＡには、ＩＤ変換テーブル１０８（格納手段）、所属ノード判別機能１０９、およびＩＤ無効化機能１１０（無効化手段）が配置されている。ここで通信ミドルウェア１０３は、通信コンポーネントの物理配置を表す物理ＩＤ、コンポーネントの配置に依存しない論理ＩＤを併用する複数のＩＤ解釈機能を備えている。
【００２４】
また、通信ミドルウェア１０３は、送信先ノード判別機能１１１を備えてもよい。送信先ノード判別機能１１１は、所属ノード判別機能１０９と連携し、メッセージの宛先である物理ＩＤから宛先コンポーネントが所属するノードを判別する機能である。
【００２５】
図２は、実施形態１における、ネットワーク上の通信コンポーネントの物理配置を示す物理ＩＤの例である。物理ＩＤ２０１は、４桁の数値から構成される。物理ＩＤ２０１は、該当コンポーネントが配置されたノードを識別する２桁のノードＩＤ２０２と該当コンポーネントが配置されたプロセスを識別する２桁のプロセスＩＤ２０３の組み合わせである。
【００２６】
図３は、通信のための各コンポーネント内に配置されるＩＤ変換テーブル１０８の具体例を示す。このＩＤ変換テーブル１０８は、コンポーネント内に其々保持されているため、「論理ＩＤを使った通信方法」のように通信を行うたびに通信ミドルウェアの提供する変換機能を用いるのに比べ、高速な処理が可能である。通信相手（通信先）のコンポーネントに対して、この図のように、識別情報として、エントリ番号３０５、論理ＩＤ３０６、そして物理ＩＤ３０７があり、物理ＩＤ３０７には、ノードとプロセスの情報が含まれている。
【００２７】
図３はコンポーネントＡの保持するＩＤ変換テーブル１０８であって、通信相手である、コンポーネントＢ、コンポーネントＣ、コンポーネントＤの３つのコンポーネントの情報が登録されている。このＩＤ変換テーブル１０８は、エントリした通信相手の各コンポーネントに対して、エントリ番号３０５と論理ＩＤと物理配置を示す物理ＩＤ２０１との関連付けを行うための情報をテーブル化している。具体的には、ＩＤ変換テーブル１０８内に配置されている宛先を識別する通し番号であるエントリ番号３０５、宛先コンポーネントを文字列で表現した論理ＩＤ３０６、宛先コンポーネントの物理的情報を表現した物理ＩＤ３０７である。図３の例では、コンポーネントＢは、物理ＩＤ＝０１０１、コンポーネントＣは、物理ＩＤ＝０２０１、コンポーネントＤは、物理ＩＤ＝０２０２となっている。これらは、それぞれのコンポーネントが、ノード０１のプロセス０１、ノード０２のプロセス０１、ノード０２のプロセス０２に配置されていることを意味している。以上のようにこのＩＤ変換テーブルには、コンポーネント（プロセス）のプロセスＩＤと、このコンポーネント（プロセス）に予め割り当てられている論理ＩＤと、の間の対応付け情報が格納されている。
【００２８】
まず、従来技術の「物理ＩＤを使った通信方法」、「論理ＩＤを使った通信方法」、「初回のみ論理ＩＤを使用する通信方法」におけるシステム構成、および通信ミドルウェアを使ったメッセージ送信時の動作について説明し、本発明の実施形態１との差異を明確にする。
【００２９】
図４および図５は、一般的な「物理ＩＤを使った通信方法」に対する説明のための図である。図４の構成からわかるように、２つのノード０１、０２を含むシステムに通信ミドルウェア４０３が配置されている。通信ミドルウェア４０３上には複数のソフトウェアコンポーネントＡ、Ｂ、Ｃ、Ｄが動作している。コンポーネントＡは、ノード０１上に配置され、所属するプロセスＩＤは０１である。同様に、コンポーネントＢはノード０１上のプロセス０２、コンポーネントＣは、ノード０２上のプロセス０１、コンポーネントＤは、ノード０２上のプロセス０２に所属している。この場合、コンポーネントＡ、Ｂ，Ｃ、Ｄを表す物理ＩＤは、それぞれ０ｘ０１０１、０ｘ０１０２、０ｘ０２０１、０ｘ０２０２となる。
【００３０】
図５のフロー図で「物理ＩＤを使った通信方法」の動作について説明する。Ｓ５０１において、送信指示を受付けることにより、あるコンポーネントがメッセージの送信処理を開始する。Ｓ５０２において、通信ミドルウェアは、宛先の物理ＩＤから宛先コンポーネントの物理ＩＤを特定する。「物理ＩＤを使った通信方法」においては、通信を行うコンポーネントは宛先を物理ＩＤで指定することになる。ここで物理ＩＤは、図２に示した通り宛先コンポーネントの物理的な情報を内包しており、この特定処理の負荷は小さい。
【００３１】
次に、Ｓ５０３において、特定された宛先の物理ＩＤを用いて通信ミドルウェアが実際のメッセージ送信処理を行う。Ｓ５０４で、宛先への通信が存在するか否かにより、送信結果が得られる。ここで、宛先への通信が成功すれば、すなわち宛先が存在すれば通信は成功であり、Ｓ５０５へ移行する。Ｓ５０４で、通信した結果宛先が存在しないなどのエラーが発生すると、通信は失敗となりＳ５０６へ移行する。
【００３２】
図６および図７は、「論理ＩＤを使った通信方法」に対する説明のための図である。図６において、２つのノード０１、０２を含むシステムに通信ミドルウェア６０３が配置されている。通信ミドルウェア６０３は、内部にＩＤ集中管理機能６０４を備えている。通信ミドルウェア６０３上には、複数のソフトウェアコンポーネントＡ、Ｂ、Ｃ、Ｄが動作しており、コンポーネントＡはノード０１上に配置され、所属するプロセスＩＤは０１である。同様に、コンポーネントＢはノード０１上のプロセス０２、コンポーネントＣはノード０２）上のプロセス０１、コンポーネントＤはノード０２上のプロセス０２に所属している。この場合、コンポーネントＡ、Ｂ、Ｃ、Ｄを表す物理ＩＤは、それぞれ０ｘ０１０１、０ｘ０１０２、０ｘ０２０１、０ｘ０２０２となる。
【００３３】
図７のフロー図で「論理ＩＤを使った通信方法」の動作について説明する。Ｓ７０１において、送信指示を受付けることにより、通信を行うコンポーネントがメッセージの送信処理を開始する。この時点で、通信を行うコンポーネントは、宛先の論理ＩＤを受付けている。Ｓ７０２で、通信を行うコンポーネントは、まず通信ミドルウェア６０３に問い合わせる。そして、通信ミドルウェア６０３が備えるＩＤ集中管理機能６０４が、論理ＩＤから物理ＩＤへの変換処理を行う。「論理ＩＤを使った通信方法」では、通信を行うコンポーネントは、宛先を論理ＩＤで指定する。論理ＩＤとして、例えばコンポーネント名称を表す文字列などを指定する。また、通信ミドルウェアによるＩＤ集中管理機能６０４は、複数のノードに渡るコンポーネントの情報を動的かつ一元的に管理しなければならない。
【００３４】
Ｓ７０３で、問い合わせを受けた通信ミドルウェア内のＩＤ集中管理機能６０４は、指定された論理ＩＤを持つコンポーネントがシステム内に存在するかどうかの判定を行う。システム内に該当のコンポーネントが存在しなかった場合、Ｓ７０４で、宛先が存在しないエラーが送信元コンポーネントに通知される。
【００３５】
システム内に該当のコンポーネントが存在し、物理ＩＤへの変換処理が行われた後の処理は、図５で説明した「物理ＩＤを使った通信方法」と同一である。つまり、Ｓ７０５で、ＩＤ集中管理機能６０４は、物理ＩＤから宛先コンポーネントを特定する。
【００３６】
Ｓ７０５で、ＩＤ集中管理機能６０４は、特定した宛先コンポーネントへ実際の送信処理を行う。そして、Ｓ７０７で、通信の成否を確認する。最終的に宛先が存在すれば、通信は成功でありＳ７０８へ移行し、存在しなければ、エラーとしてＳ７０９へ移行する。
【００３７】
図８は、従来技術「初回のみ論理ＩＤを使用する方法」に対する説明のための図である。この従来技術におけるシステム構成は、図６の「論理ＩＤを使った通信方法」と同様である。Ｓ８０１で、通信を行うコンポーネントがメッセージの送信処理を開始する。Ｓ８０２で、通信を行うコンポーネントは、該当の宛先に対する初回の送信かどうかを判定する。
【００３８】
ここで初回の送信であると判定すると、Ｓ８０３で、通信を行うコンポーネントは、通信ミドルウェア６０３に問い合わせ、ＩＤ集中管理機能６０４が、論理ＩＤから物理ＩＤへの変換処理を行う。「初回のみ論理ＩＤを使用する方法」の初回の通信では宛先を論理ＩＤで指定する。
【００３９】
Ｓ８０４で、「論理ＩＤを使った通信方法」と同様に、通信ミドルウェア６０３内のＩＤ集中管理機能６０４は、指定された論理ＩＤを持つコンポーネントがシステム内に存在するかどうかの判定を行う。これはＳ７０３の手順と同様である。システム内に該当のコンポーネントが存在しなかった場合は、Ｓ８０５で、ＩＤ集中管理機能６０４は、宛先が存在しないとしてエラーを返す。これはＳ７０４と同様である。
【００４０】
システム内に該当のコンポーネントが存在し、ＩＤ集中管理機能６０４が論理ＩＤから物理ＩＤへの変換が成功した場合は、Ｓ８０６で、ＩＤ集中管理機能６０４は、変換後の物理ＩＤをコンポーネント内のメモリ（不図示、コンポーネントが属するプロセスのメモリ空間）に格納する。物理ＩＤを格納しておくことにより、２回目の送信からはコストの高いＳ８０３を実行せずに済むことになる。
【００４１】
物理ＩＤを記憶した後、あるいはＳ８０２において２回目以降の通信であると判定された場合は、ＩＤ集中管理機能６０４は、物理ＩＤを使って通信を行う。これ以降の処理は、図７の「論理ＩＤを使った通信方法」と同様である。すなわち、Ｓ８０７からＳ８１１のステップは、それぞれ図７のＳ７０５からＳ７０９のステップに対応するので、説明を省略する。
【００４２】
次に、本発明の一実施形態について説明する。図９は、本実施形態においてメッセージを送信するコンポーネントの動作を表すフローチャートである。また図１０は、本実施形態においてノード停止検出時の通信ミドルウェアの動作を表すフローチャートである。本実施形態のシステム構成図は、図１で説明したとおりである。
【００４３】
Ｓ９０１において、通信を行うコンポーネントがメッセージの送信処理を開始する。Ｓ９０２で、通信を行うコンポーネントは、コンポーネント内のＩＤ変換テーブル１０８を参照し、送信先に相当するエントリがテーブル内に存在するかどうかを判定する（取得手段）。本実施形態においては、図３のＩＤ変換テーブル１０８の構成に示すように、宛先を論理ＩＤで指定してもＩＤ変換テーブルのエントリ番号で指定してもよい。
【００４４】
Ｓ９０３で、判定によってＩＤ変換テーブル１０８内にエントリが発見された場合は、このエントリが無効化済であるかどうか判定する。（ＩＤ変換テーブル１０８内のエントリを無効化する処理については、図１０を用いて後述する。）
【００４５】
すでに無効化済であった場合は、Ｓ９０４で、ＩＤ変換テーブル１０８からこのエントリに含まれる論理ＩＤを取得する。更に、Ｓ９０５で、通信を行うコンポーネントは、通信ミドルウェア６０３に問い合わせ、ＩＤ集中管理機能１０４は、その論理ＩＤを用いて物理ＩＤへの変換処理を行う。この処理は「論理ＩＤを使った通信方法」のＳ７０２と同じ処理であり、通信ミドルウェア１０３への問い合わせが発生する。
【００４６】
Ｓ９０２において、送信先に相当するエントリが存在しなかった場合は、通信を行うコンポーネントは、宛先として指定された論理ＩＤを用いて、同様に、通信ミドルウェア１０３へ問合せ（問合せ手段）、Ｓ９０５で、ＩＤ集中管理機能１０４が物理ＩＤへの変換処理を行う。ＩＤ集中管理機能１０４は、ネットワーク上の全てのコンポーネントに対して集中的に物理ＩＤを登録する集中ＩＤテーブルを有する。この集中ＩＤテーブルを参照することにより、宛先として指定された論理ＩＤが、対応する物理ＩＤへ変換される。すなわちこの集中ＩＤテーブルには、コンポーネント（プロセス）のプロセスＩＤと論理ＩＤとの間の対応付け情報が格納されている。
【００４７】
次にＳ９０６において、「論理ＩＤを使った通信方法」のＳ７０３と同様に、通信ミドルウェア１０３内のＩＤ集中管理機能１０４を用いて、通信ミドルウェアは指定された論理ＩＤを持つコンポーネントがシステム内に存在するかどうかの判定を行う。該当のコンポーネントが未登録で存在しなかった場合は、Ｓ９０７で、通信ミドルウェアは宛先が存在しないエラーを通信を行うコンポーネントへ返却する。これはＳ７０４と同じ処理である。
【００４８】
Ｓ９０６で、ＩＤ集中管理機能１０４が論理ＩＤから物理ＩＤへの変換に成功したら、Ｓ９０８において、通信を行うコンポーネントは、ＩＤ変換テーブル１０８に変換結果となる論理ＩＤと物理ＩＤの組み合わせを追記する（登録手段）。具体的には、Ｓ９０２において送信先エントリが存在しなかった場合には、ＩＤ変換テーブル１０８に新たなエントリを生成して追記する。あるいは、Ｓ９０３において、エントリが無効化されていた場合は、通信を行うコンポーネントは、Ｓ９０５において再取得された物理ＩＤを正しい物理ＩＤとして、該エントリを更新することになる。
【００４９】
Ｓ９０３で、送信先となるエントリが無効化されておらず有効であった場合には、Ｓ９０９において、通信を行うコンポーネント内で、エントリから物理ＩＤが取得される。この処理は、例えば図３のＩＤ変換テーブル１０８に対応する、送信元コンポーネント内に保持されているＩＤ変換テーブル１０８からＩＤを抽出する処理である。従って、Ｓ９０５のような、通信ミドルウェアに問い合わせを行うような処理が発生しない。
【００５０】
Ｓ９０９において物理ＩＤを取得した、あるいはＳ９０８にてＩＤ変換テーブル１０８への追記が完了したら、通信を行うコンポーネントは得られた物理ＩＤを使って通信を行う。これ以降の処理は、図７の「論理ＩＤを使った通信方法」と同様である。すなわち、Ｓ９１０からＳ９１４のステップは、それぞれ図７のＳ７０５からＳ７０９のステップに対応するので、説明を省略する。以上のように、変換テーブル１０８は、図９のＳ９０２−Ｓ９０６およびＳ９０８のステップにより再構築されることがわかる。
【００５１】
図１０を用いて、ノード単位の部分的な再起動により発生する、ＩＤ変換テーブル１０８内のエントリを無効化する処理について説明する。Ｓ１００１において、通信ミドルウェア１０３は、システムを構成する全体のノードの動作状態を監視する。Ｓ１００２において、通信ミドルウェア１０３は、ノードが停止したかどうかを検出する。検出した場合、Ｓ１００３において、通信ミドルウェア１０３は、停止したノードの情報を全コンポーネントに通知する。ここで、実際にノードの停止を検出して通知を行うのは通信ミドルウェア１０３内のノード動作状態管理機能１０５である。通知を受取った全てのコンポーネントにおいて、以下の処理が行われる。
【００５２】
Ｓ１００４でノード停止を受信したコンポーネントは、Ｓ１００５で、まずコンポーネントが保持するＩＤ変換テーブル１０８を走査する。具体的には、以下の処理をテーブルに含まれる全てのエントリに対して行う（Ｓ１００６）。つぎに、Ｓ１００７で、該エントリに保持されている物理ＩＤからノード番号を取得する。所属ノード判別機能１０９は、物理ＩＤがどのノードに所属するかを判別する。この判別を行うのは所属ノード判別機能１０９であり、図２で述べたように、物理ＩＤの上２桁を抽出する処理に相当する。
【００５３】
次に、Ｓ１００８において、通知を受信したコンポーネントは、Ｓ１００７で抽出した所属ノードとＳ１００２で通知された停止ノードとを比較し、一致しているかどうか判断する。もし両者が一致していたら、Ｓ１００９で、該当エントリは停止したノードに所属するものであること判断し、ＩＤ無効化機能１１０は、該エントリを無効化する。具体的には、該エントリにフラグを付加してもよいし、物理ＩＤを無効な値で更新しても良い。ここで無効化されたエントリは、Ｓ９０３で実施した、メッセージ送信時のＩＤが無効かどうかの判定に利用される。以上の処理を全エントリ、Ｓ１０１０で、全ノードに対して行い、処理を終了する。
【００５４】
図１３を参照して、ノードの再起動前後における、コンポーネントと通信ミドルウェアとの動作を説明する。図１３において、ノード０１にはコンポーネント１３０１、コンポーネント１３０２、及び通信ミドルウェア１３０３が配置されている。また、ノード０２には通信ミドルウェア１３０４及びコンポーネント１３０５が配置されている。
【００５５】
まず、ノード２の再起動前に、コンポーネント１３０１が行う通信について説明する。コンポーネント１３０１は、論理ＩＤが既知であるコンポーネント１３０５との通信を希望するものとする。また、コンポーネント１３０１が有するＩＤ変換テーブルには、コンポーネント１３０５の物理ＩＤが登録されていないものとする。
【００５６】
この場合Ｓ１３０６においてコンポーネント１３０１は、コンポーネント１３０１と同一ノードに配置されている通信ミドルウェア１３０３に対して、コンポーネント１３０５の物理ＩＤを問い合わせる。具体的にはコンポーネント１３０１は、通信ミドルウェア１３０３に対して、通信を希望するコンポーネント１３０５の論理ＩＤを送信し、コンポーネント１３０５の物理ＩＤの送信を要求する。コンポーネント１３０５の物理ＩＤを取得すると、Ｓ１３０７においてコンポーネント１３０１は、コンポーネント１３０５へとデータを送信する（実行手段）。また、上述のようにコンポーネント１３０１は、コンポーネント１３０５の論理ＩＤと物理ＩＤとを含む情報をＩＤ変換テーブルに登録する。
【００５７】
ここで、ノード０２が停止したものとする。Ｓ１３０８においてノード０１の通信ミドルウェア１３０３は、ノード０２の停止を検知する。ノード０２の停止の検知は、様々な方法によって行うことができる。例えば、ノード０１が備えるネットワークコントローラが通信路の切断を検知してもよい。また、通信ミドルウェア１３０３と通信ミドルウェア１３０４間との定期的な通信が途絶した場合に、通信ミドルウェアは通信路が切断されたものと判断してもよい。
【００５８】
１３０９において通信ミドルウェア１３０３は、ノード０１に配置されたコンポーネント１３０１及び１３０２に対して、ノード０２が停止したことを通知する。図１０を参照して上述したように、各コンポーネント１３０１，１３０２は、この通知を受けると、それぞれが有するＩＤ変換テーブルをチェックし、ノード０２に配置されているコンポーネント１３０５についてのエントリを無効化する。
【００５９】
ここで、ノード０２が再起動したものとする。Ｓ１３１０において再起動したノード０２の通信ミドルウェア１３０４は、他のノードへとノード０２が再起動したことを通知する。具体的には通信ミドルウェア１３０４は、通信ミドルウェア１３０３へとノード０２が再起動したことを通知する。
【００６０】
さらにその後、ノード０２に配置されたコンポーネント１３０５も再起動されたものとする。このときコンポーネント１３０５は、ノード０２の制御部（例えば不図示のオペレーティングシステム）からプロセスＩＤを割り振られる。本実施形態においては物理ＩＤはノードＩＤとプロセスＩＤとで構成され、通常ノードＩＤは固定されている。したがって、プロセスＩＤを割り振られた時、コンポーネント１３０５は自分の物理ＩＤを知ることとなる。もっともコンポーネント１３０５は、ノード０２の制御部から、直接物理ＩＤを通知されてもよい。
【００６１】
次にＳ１３１１においてコンポーネント１３０５は、コンポーネント１３０５が配置されているノード０２の通信ミドルウェア１３０４へと、コンポーネント１３０５の物理ＩＤを通知する。すると通信ミドルウェア１３０４は、通信ミドルウェア１３０４が有するＩＤ変換テーブルに、コンポーネント１３０５の物理ＩＤと論理ＩＤとを関連付けて格納する。
【００６２】
Ｓ１３１２において、ノード０１の通信ミドルウェア１３０３とノード０２の通信ミドルウェア１３０４とは、有しているＩＤ変換テーブルを同期する。図１３の例によれば、Ｓ１３１２において、ノード０１の通信ミドルウェア１３０３が保持するＩＤ変換テーブルに、コンポーネント１３０５の物理ＩＤと論理ＩＤとが関連付けられて格納される。このＩＤ変換テーブルの同期は、一定時間ごとに行われてもよい。また、新しいコンポーネントが起動していずれかのノード上の通信ミドルウェアにそのコンポーネントについての情報が追加されたことに応答して、行われてもよい。
【００６３】
この状態でコンポーネント１３０１がコンポーネント１３０５への通信を希望するものとする。上述のようにＳ１３０９において、コンポーネント１３０５の情報は、コンポーネントＳ１３０１が有するＩＤ変換テーブルからは削除されている。したがってＳ１３１３において、Ｓ１３０６と同様に、コンポーネント１３０５は通信ミドルウェア１３０３へと問い合わせを行う。
【００６４】
最後にＳ１３１４において、Ｓ１３０７と同様に、コンポーネント１３０１はコンポーネント１３０５へとデータを送信する。このように、Ｓ１３１３においてコンポーネント１３０１は通信ミドルウェア１３０３へとコンポーネント１３０５の物理ＩＤを問い合わせている。したがって、ノード０２が再起動されコンポーネント１３０５の物理ＩＤが変化して可能性があるにもかかわらず、コンポーネント１３０５へと正しく送信が行われる。
【００６５】
また本実施形態においては、Ｓ９１０で宛先コンポーネントの物理配置を特定してから、Ｓ９１１で実際の送信を行うまでの間に、宛先コンポーネントが所属するノードの動作状態を判定してもよい。そして、停止中であった場合には、その送信を未然に抑止してもよい。この判定を行うことによって、停止中のノードに対して送信処理を行うことによる送信エラーや送信タイムアウトの発生を防ぐことができる。
【００６６】
図１１を用いて、この追加処理フローを説明する。Ｓ１１０１において、宛先コンポーネントの物理ＩＤから宛先の物理的情報が特定される（Ｓ９１０の処理に相当する）。Ｓ１１０２において、宛先のコンポーネントが所属するノードが停止中であるかどうか判定する。Ｓ１１０１において宛先コンポーネントの物理的情報が特定されていることから、判定すべきノードを一意に決定することが可能である。
【００６７】
判定の結果、該当ノードが動作中であれば、Ｓ１１０３で、実際の送信を行う（Ｓ９１１の処理に相当する）。Ｓ１１０４で、該当ノードが停止中であれば、宛先停止中エラーを発生させ、実際の通信が行われないよう抑止する。また、ノード停止中のときに、図１０に示したエントリの無効化を実施してもよいことは言うまでもない。
【００６８】
以上のような制御を行うことにより、論理ＩＤ使用によるコンポーネント設計の柔軟性と物理ＩＤ使用による高速な通信を両立させることが可能となる。そして、システムを構成するノードの一部が停止し再起動することによる物理ＩＤの変化にも対応することも可能となる。さらに本実施形態の構成を採ることにより、コンポーネント実装の複雑化を抑止することができる。
【００６９】
＜その他の実施例＞
上述の実施形態において、各コンポーネントはノードのプロセスに配置されるものとして説明された。すなわち、ノードのコンポーネントと通信することは、ノードのプロセスと通信することを意味しうる。また上述の実施形態において論理ＩＤは、宛先コンポーネントを文字列で表現したものである。しかしながら論理ＩＤは文字列には限定されず、数値などであってもよい。各コンポーネントには、一意の論理ＩＤが予め割り当てられていてもよい。例えば、ノード０１が通信可能なノードで動作する各コンポーネントに、別々の論理ＩＤが割り当てられていてもよい。
【００７０】
上述の実施形態においてミドルウェアはＩＤ変換テーブルを有し、他のノードのミドルウェアが有するＩＤ変換テーブルとの同期を行った。しかしながら、ミドルウェアがＩＤ変換テーブルを有する必要はない。例えば不図示の管理ノードは、各コンポーネントについての論理ＩＤと物理ＩＤとを関連付けて格納しうる。この場合ミドルウェアは、論理ＩＤに対応する物理ＩＤをコンポーネントから問い合わせられた際に、この管理ノードに問い合わせを行い、物理ＩＤを取得することができる。
【００７１】
図１２に示される例においては、通信ミドルウェア及びコンポーネントは、例えばパーソナルコンピュータのようなノードが、プログラムを実行することによって実現される。しかしながら本発明に係る通信処理装置は、専用のハードウェアによって構成されていてもよいことは、当業者には明らかであろう。すなわち本発明に係る通信処理装置が、通信ミドルウェアとして動作する回路と、通信処理装置内のコンポーネントとして動作する回路と、によって構成されていてもよい。
【００７２】
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【図１】
2011227867.tif 000003
【図２】
2011227867.tif 000004
【図３】
2011227867.tif 000005
【図４】
2011227867.tif 000006
【図５】
2011227867.tif 000007
【図６】
2011227867.tif 000008
【図７】
2011227867.tif 000009
【図８】
2011227867.tif 000010
【図９】
2011227867.tif 000011
【図１０】
2011227867.tif 000012
【図１１】
2011227867.tif 000013
【図１２】
2011227867.tif 000014
【図１３】
2011227867.tif 000015