(57)【要約】【課題】  メッセージ通信において大量のトラフィックを効率良く処理し、障害時にもソフトウェアコンポーネントが障害を意識することなく処理を続行することが可能な技術を提供する。【解決手段】  ネットワーク上に分散配置されたソフトウェアコンポーネント間でメッセージキューを経由してメッセージ通信を行うメッセージ通信方法において、ソフトウェアコンポーネントからメッセージ送信要求を受信した場合に、そのサービス名と共に当該メッセージを記憶手段中の共用メッセージテーブルに格納して当該メッセージのステータスを未送信に設定するステップと、ソフトウェアコンポーネントからメッセージ受信要求を受信した場合に、そのメッセージ受信要求で指定されたサービス名でステータスが未送信のメッセージを前記記憶手段中の共用メッセージテーブルから取得して当該メッセージのステータスを送信済みに変更し、前記サーバコンポーネントに当該メッセージを送信するステップとを有するものである。【選択図】図３
2006031592.tif 000002
【特許請求の範囲】
【請求項１】
ネットワーク上に分散配置されたソフトウェアコンポーネント間でメッセージキューを経由してメッセージ通信を行うメッセージ通信方法において、
ソフトウェアコンポーネントからメッセージ送信要求を受信した場合に、そのサービス名と共に当該メッセージを記憶手段中の共用メッセージテーブルに格納して当該メッセージのステータスを未送信に設定するステップと、
ソフトウェアコンポーネントからメッセージ受信要求を受信した場合に、そのメッセージ受信要求で指定されたサービス名でステータスが未送信のメッセージを前記記憶手段中の共用メッセージテーブルから取得して当該メッセージのステータスを送信済みに変更し、前記サーバコンポーネントに当該メッセージを送信するステップとを有することを特徴とするメッセージ通信方法。
【請求項２】
前記通信プロセス上のメモリキューに共用メッセージテーブルのメッセージの一部をローディングしておき、ソフトウェアコンポーネントからの受信要求を前記メモリキュー上のメッセージにより処理することを特徴とする請求項１に記載されたメッセージ通信方法。
【請求項３】
サービス毎に異なる共用メッセージテーブルを用いてメッセージ通信処理を行うことを特徴とする請求項１または請求項２のいずれかに記載されたメッセージ通信方法。
【請求項４】
ネットワーク上に分散配置されたソフトウェアコンポーネント間でメッセージキューを経由してメッセージ通信を行うメッセージ通信装置において、
ソフトウェアコンポーネントからメッセージ送信要求を受信した場合に、そのサービス名と共に当該メッセージを記憶手段中の共用メッセージテーブルに格納して当該メッセージのステータスを未送信に設定するメッセージ受信処理部と、
ソフトウェアコンポーネントからメッセージ受信要求を受信した場合に、そのメッセージ受信要求で指定されたサービス名でステータスが未送信のメッセージを前記記憶手段中の共用メッセージテーブルから取得して当該メッセージのステータスを送信済みに変更し、前記サーバコンポーネントに当該メッセージを送信するメッセージ送信処理部とを備えることを特徴とするメッセージ通信装置。
【請求項５】
ネットワーク上に分散配置されたソフトウェアコンポーネント間でメッセージキューを経由してメッセージ通信を行うメッセージ通信方法をコンピュータに実行させる為のプログラムにおいて、
ソフトウェアコンポーネントからメッセージ送信要求を受信した場合に、そのサービス名と共に当該メッセージを記憶手段中の共用メッセージテーブルに格納して当該メッセージのステータスを未送信に設定するステップと、
ソフトウェアコンポーネントからメッセージ受信要求を受信した場合に、そのメッセージ受信要求で指定されたサービス名でステータスが未送信のメッセージを前記記憶手段中の共用メッセージテーブルから取得して当該メッセージのステータスを送信済みに変更し、前記サーバコンポーネントに当該メッセージを送信するステップとをコンピュータに実行させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はネットワーク上に分散配置されたソフトウェアコンポーネント間でメッセージキューを経由してメッセージ通信を行うメッセージ通信技術に関し、特にメッセージキューを経由したメッセージ通信において大量のトラフィックを効率良く処理し、障害時にもクライアントコンポーネント及びサーバコンポーネントが障害を意識することなく処理を続行することが出来るメッセージ通信技術に適用して有効な技術に関するものである。
【背景技術】
【０００２】
既存のメッセージキューを用いた通信方法では、メッセージキューを管理するキューマネージャは各々個別にメッセージキューを保持し、ある一つのキューマネージャが他のキューマネージャの管理するメッセージキューにアクセスすることは出来ない。このためあるキューマネージャが障害でダウンすると、そのメッセージキュー上にある仕掛り中のメッセージは全て破棄されるか、当該キューマネージャが再起動されるまでアクセス不可能な状態となり、メッセージ通信のスループットに著しい影響を与える。
【０００３】
図１０は従来のキューマネージャと共用キューの関係を示す図である。前記既存のメッセージキューを用いた通信方法に対して、図１０に示す様に個々のキューマネージャが管理する個別のメッセージキューではなく、複数のキューマネージャからアクセス可能な共用キュー４と、これにアクセス可能な第一のサーバキューマネージャ２と第二のサーバキューマネージャ３とを備えた場合には、第一のサーバキューマネージャ２が障害でダウンした場合にも、第二のサーバキューマネージャ３が即時に処理を引き継ぐため、クライアントキューマネージャ１は障害を意識することがない（例えば特許文献１参照）。
【０００４】
しかしこの方法では、常に一つのキューに対して一つのキューマネージャが動作可能な状態となることによりメッセージ通信の継続的な実行を可能としているため、同時に複数のキューマネージャが一つのキューにアクセスすることは無い。このため大量のメッセージ通信のトラフィックがある場合、キューマネージャがネックとなりスループットを向上させることが出来ないという問題があった。
【０００５】
【特許文献１】特開２００２−２０２９５３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
前記の様に既存のメッセージキューを用いた通信方法では、キューマネージャが各々個別にメッセージキューを保持管理しているため、障害でダウンしたキューマネージャのメッセージキューを他のキューマネージャが処理することができず、その仕掛り中のメッセージは全て破棄されるか、当該キューマネージャが再起動されるまでアクセス不可能な状態となり、メッセージ通信のスループットに著しい影響を与えるという問題がある。
【０００７】
また前記の様に障害時に他のキューマネージャが共用キューにより処理を引き継ぐ方法では、同時に複数のキューマネージャが一つのキューにアクセスすることは無いため、大量のメッセージ通信時にスループットを向上させることが出来ないことがあるという問題がある。
【０００８】
本発明の目的は上記問題を解決し、メッセージ通信において大量のトラフィックを効率良く処理し、障害時にもソフトウェアコンポーネントが障害を意識することなく処理を続行することが可能な技術を提供することにある。
【０００９】
本発明の他の目的は通信プロセスから共用メッセージテーブルへのアクセス回数がネックとなるのを防止し、メッセージ通信処理のスループットを向上させることが可能な技術を提供することにある。
【００１０】
本発明の他の目的は共用メッセージテーブルへのアクセス集中がネックとなるのを防止し、メッセージ通信処理のスループットを向上させることが可能な技術を提供することにある。
【課題を解決するための手段】
【００１１】
本発明は、ネットワーク上に分散配置されたソフトウェアコンポーネント間でメッセージキューを経由してメッセージ通信を行うメッセージ通信装置において、共用メッセージテーブル中にメッセージと共に格納したサービス名及びステータスの情報に応じてメッセージ通信を行うものである。
【００１２】
本発明のメッセージ通信装置（計算機や情報処理装置、またはその様な処理を実施するプログラムやオブジェクトでも良い）は、クライアントコンポーネントからのメッセージ送信要求とサーバコンポーネントからのメッセージ受信要求を処理する一つまたは複数の通信プロセス（従来技術のキューマネージャに相当）と、全ての通信プロセスからアクセス可能な共用キューである一つの共用メッセージテーブルとを備え、ネームサーバはクライアントコンポーネントまたはサーバコンポーネントからの要求に対して処理を実行すべき通信プロセスを指示する。クライアントコンポーネントから送信された全てのメッセージは通信プロセスを経由して共用メッセージテーブルに格納され、サーバコンポーネントからの受信要求に応じて通信プロセスが共用メッセージテーブルからサーバコンポーネントの属するサービス（プログラムやオブジェクトの実行により実現される機能）に適合する未送信のメッセージを検索し、サーバコンポーネントに渡すことによってメッセージ通信を行う。
【００１３】
クライアントコンポーネント及びサーバコンポーネントは全ての通信プロセスの位置情報を事前に知っている必要はなく、ネームサーバにアクセスすれば、パフォーマンスの観点から最適の通信プロセスの位置情報が通知される。各通信プロセスは、起動されるとネームサーバと管理用のコネクションを確立し、自プロセスの位置情報を通知する。ネームサーバは管理用コネクションを使用して全ての通信プロセスに定期的に応答を求めるメッセージを送信し、一定時間内に応答が無い場合はその通信プロセスが障害によってダウンしたものとみなし、管理コネクションを切断してその通信プロセスに関する情報を、通信プロセス管理テーブルから削除する。このため、クライアントコンポーネント及びサーバコンポーネントは、常に動作可能な通信プロセスにアクセスすることが出来る。
【００１４】
前記の様に本発明の通信プロセスは、共用メッセージテーブル中にメッセージと共に格納したサービス名及びステータスの情報に応じてメッセージ通信を行うので、どのメッセージであっても任意の通信プロセスによって処理することが可能である。この為、メッセージ通信において大量のトラフィックを処理する必要が生じた場合には複数の通信プロセスによって大量のメッセージ通信を効率良く処理したり、またある通信プロセスで障害が発生した場合には他の通信プロセスによってメッセージ通信を代行することにより、ソフトウェアコンポーネントが障害を意識することなく処理を続行することができる。
【００１５】
また本発明では、前記通信プロセス上のメモリキューに共用メッセージテーブルのメッセージの一部をローディングしておき、サーバコンポーネントからの受信要求を前記メモリキュー上のメッセージにより処理するものとしても良い。
【００１６】
すなわち本発明において、通信プロセスと一つまたは複数のサーバコンポーネントとの間に常設コネクションを確立しておき、クライアントコンポーネントから送信要求されたメッセージを、共用メッセージテーブルに格納すると同時に通信プロセス上のメモリキューにも追加し、常設コネクションを通した受信要求に対して、このメモリキューから検索したメッセージを渡す。これにより、実質のメッセージ送受信はメモリキューを経由して行なわれるため、共用メッセージテーブルを経由したメッセージ送受信よりも高速な処理が可能となる。
【００１７】
運用による通信プロセスの終了または何らかの障害によって常設コネクションが切断された場合、クライアントコンポーネント及びサーバコンポーネントは、再度常設コネクションの接続要求を発行する。この時、ネームサーバから代替の通信プロセスが指示される。新たに常設コネクションを接続された通信プロセスは、自プロセス上のメモリキューに共用メッセージテーブルから指定されたサービスに属する未処理のメッセージを古い順に予め定義された数分読込み、通信プロセスの交代が完了する。
【００１８】
またメモリキューにメッセージを格納する際に、その通信プロセスの通信プロセスＩＤを共用メッセージテーブルに設定しておき、当該通信プロセスＩＤに対応する通信プロセスのみによりそのメッセージの処理を行うものとするが、ネームサーバが管理コネクションを通じたキープアライブメッセージの途絶により通信プロセスの障害を検知した場合には、当該通信プロセスの通信プロセスＩＤを他の各通信プロセスに通知し、その通知を受けた各通信プロセスでは、共用メッセージテーブル上で当該通信プロセスＩＤがセットされたメッセージを、通信プロセスＩＤがセットされていないメッセージと同等に取り扱うものとする。これにより、通信プロセスが障害等でダウンした場合も、当該通信プロセスのメモリキュー上に保持されていたメッセージを、他の通信プロセスによって処理することが可能となる。
【００１９】
また本発明では、サービス毎に異なる共用メッセージテーブルを用いてメッセージ通信処理を行うものとしても良い。すなわち本発明において、共用メッセージテーブルを複数に分割し、各々の共用メッセージテーブルに格納されるメッセージをサービス毎に分け、どの共用メッセージテーブルにどのサービスの属するメッセージが格納されるかを共用メッセージテーブル管理テーブルによって示す。これにより、共用メッセージテーブルがネックとなるスループットの低下を回避することが可能となる。
【発明の効果】
【００２０】
本発明によれば、メッセージ通信において大量のトラフィックを効率良く処理し、障害時にもソフトウェアコンポーネントが障害を意識することなく処理を続行することが可能である。
【発明を実施するための最良の形態】
【００２１】
（実施形態１）
以下にネットワーク上に分散配置されたソフトウェアコンポーネント間でメッセージキューを経由してメッセージ通信を行う実施形態１のメッセージ通信装置について説明する。
【００２２】
図１は本実施形態のメッセージ通信システムのシステム構成例を示す図である。通信ネットワークを介して複数の情報処理装置が接続されており、各情報処理装置はＣＰＵとメモリとハードディスクを備えている。
【００２３】
第一の情報処理装置１０のメモリ上にメッセージ通信のクライアントとなるアプリケーションプログラムであるクライアントコンポーネント１００がロードされており、第二の情報処理装置１１のメモリ上にメッセージ通信のサーバとなるアプリケーションプログラムであるサーバコンポーネント１１０がロードされており、第三の情報処理装置２０（メッセージ通信装置）のメモリ上にメッセージ通信を中継する通信プログラムである通信プロセス２００がロードされており、第四の情報処理装置３０のメモリ上にネームサービスを実行するプログラムであるネームサーバ３００がロードされている。
【００２４】
以降、メッセージ通信のクライアントとなるアプリケーションプログラムの処理を実行する主体をクライアントコンポーネントと呼び、メッセージ通信のサーバとなるアプリケーションプログラムの処理を実行する主体をサーバコンポーネントと呼び、メッセージ通信の中継する通信プログラムの処理を実行する主体を通信プロセスと呼び、ネームサービスを行なうプログラムの処理を実行する主体をネームサーバと呼ぶ。
【００２５】
図２は本実施形態のメッセージ通信装置である情報処理装置２０の概略構成を示す図である。図２に示す様に本実施形態の情報処理装置２０は、メッセージ受信処理部２１と、メッセージ送信処理部２２とを有している。
【００２６】
メッセージ受信処理部２１は、クライアントコンポーネント１００やサーバコンポーネント１１０からメッセージ送信要求を受信した場合に、そのサービス名と共に当該メッセージをハードディスク装置中の共用メッセージテーブル４００に格納して当該メッセージのステータスを未送信に設定する処理部である。
【００２７】
メッセージ送信処理部２２は、クライアントコンポーネント１００やサーバコンポーネント１１０からメッセージ受信要求を受信した場合に、そのメッセージ受信要求で指定されたサービス名でステータスが未送信のメッセージを前記ハードディスク装置中の共用メッセージテーブル４００から取得して当該メッセージのステータスを送信済みに変更し、要求元のクライアントコンポーネント１００やサーバコンポーネント１１０に当該メッセージを送信する処理部である。
【００２８】
情報処理装置２０をメッセージ受信処理部２１及びメッセージ送信処理部２２として機能させる為のプログラムは、ＣＤ−ＲＯＭ等の記録媒体に記録され磁気ディスク等に格納された後、メモリにロードされて実行されるものとする。なお前記プログラムを記録する記録媒体はＣＤ−ＲＯＭ以外の他の記録媒体でも良い。また前記プログラムを当該記録媒体から情報処理装置にインストールして使用しても良いし、ネットワークを通じて当該記録媒体にアクセスして前記プログラムを使用するものとしても良い。
【００２９】
図３は本実施形態のメッセージ通信の処理内容を示す図である。図３に示す様に本実施形態のメッセージ通信システムでは、クライアントコンポーネント１００とサーバコンポーネント１１０があり、両者の間のメッセージ通信を中継する第一の通信プロセス２００と第二の通信プロセス２１０があり、通信メッセージを格納する共用メッセージテーブル４００があり、クライアントコンポーネント１００及びサーバコンポーネント１１０がどの通信プロセスにアクセスすべきかを指示するネームサーバ３００と、ネームサーバ３００が管理する通信プロセス管理テーブル３１０がある。
【００３０】
図４は本実施形態の共用メッセージテーブル４００の構成例を示す図である。共用メッセージテーブル４００は、一つのメッセージを一つのレコードに格納し、図４に示す項目で一レコードを構成する。
【００３１】
メッセージＩＤは、受信時刻、通信プロセスＩＤ、通信プロセス毎の処理通番で構成され、通信プロセスが個々のメッセージを一意に識別する為に使用する。引継ぎメッセージＩＤは、当該メッセージが応答の場合に対応する問合せメッセージのＩＤであり、問合せ応答型の通信で使用する。サービス名は、当該メッセージを受信して処理するサーバコンポーネント１１０が提供するサービスの名称であり、クライアントコンポーネント１００がメッセージ送信先のサーバコンポーネント１１０を指定する為に使用する。
【００３２】
メッセージ種別は、問合せ応答か一方送信かという当該メッセージの処理形態を示すもので、クライアントコンポーネント１００がメッセージ送信時に指定する。ステータスは、未送信か送信済みかの当該メッセージの処理状態を示すもので、通信プロセスがサーバコンポーネント１１０からのメッセージ受信要求に対して送信するメッセージを選択する際に使用する。メッセージ長はメッセージボディのデータ長を示し、メッセージボディはメッセージの内容を示す。
【００３３】
図５は本実施形態の通信プロセス管理テーブル３１０の構成例を示す図である。通信プロセス管理テーブル３１０は、一つの通信プロセスの情報を一つのレコードに格納し、図５に示す項目で一レコードを構成する。
【００３４】
通信プロセスＩＤは、ネームサーバ３００が個々の通信プロセスを一意に識別するＩＤであり、ＩＰ(Internet Protocol)アドレスはクライアントコンポーネント１００またサーバコンポーネント１１０が当該通信プロセスにアクセスする際に使用するアドレスであり、受信受付ポートはメッセージ受信要求を行なうコンポーネントが当該通信プロセスにアクセスする為のポート番号であり、送信受付ポートはメッセージ送信要求を行なうコンポーネントが当該通信プロセスにアクセスする為のポート番号である。
【００３５】
以下に、本実施形態のメッセージ通信システムにおいて、通信プロセス２００や通信プロセス２１０を介し、クライアントコンポーネント１００からサーバコンポーネント１１０へメッセージを送信する処理について説明する。
【００３６】
クライアントコンポーネント１００がメッセージを送信する場合、まずネームサーバ３００にどの通信プロセスにアクセスすべきかを問合せる。ネームサーバ３００は通信プロセス管理テーブル３１０を参照し、動作可能な通信プロセスのリストの中から問合せの都度ラウンドロビンで一つの通信プロセスを選択し、第一の通信プロセス２００のＩＰアドレスと送信受付ポートをクライアントコンポーネント１００に回答する。
【００３７】
クライアントコンポーネント１００は次に、ネームサーバ３００から指示された第一の通信プロセス２００にメッセージを送信する。この時、当該メッセージを受信すべきサーバコンポーネント１１０が提供するサービス名を指定する。また応答を期待する場合にはメッセージ種別を問合せとし、そうでない場合はメッセージ種別を一方送信として併せて第一の通信プロセス２００に通知する。
【００３８】
第一の通信プロセス２００のメッセージ受信処理部２１は、通信装置によりクライアントコンポーネント１００からメッセージを受信すると、受信時刻と当該通信プロセスＩＤと当該通信プロセス内の処理通番から本実施形態によるシステム内でメッセージ毎にユニークとなるメッセージＩＤを採番して、そのメッセージＩＤ、クライアントコンポーネント１００から指定されたサービス名及びメッセージ種別と共に当該メッセージをハードディスク装置内の共用メッセージテーブル４００に格納し、当該メッセージのステータスを未送信とした後、通信装置によりクライアントコンポーネント１００にメッセージＩＤを通知する。
【００３９】
サーバコンポーネント１１０がメッセージを受信する場合、まずネームサーバ３００にどの通信プロセスにアクセスすべきかを問合せる。ネームサーバ３００はクライアントコンポーネント１００からの問合せの場合と同様に通信プロセス管理テーブル３１０を参照し、第二の通信プロセス２１０のＩＰアドレスと受信受付ポートをサーバコンポーネント１１０に回答する。この時、第一の通信プロセスと第二の通信プロセスは同一である場合もある。
【００４０】
サーバコンポーネント１１０は次に、ネームサーバ３００から指示された第二の通信プロセス２１０にメッセージ受信要求を送信する。この時、受信すべきメッセージを識別する為に自身が提供するサービス名を指定する。
【００４１】
第二の通信プロセス２１０のメッセージ送信処理部２２は、通信装置によりサーバコンポーネント１１０からメッセージ受信要求を受信すると、ハードディスク装置内の共用メッセージテーブル４００から指定されたサービス名で、ステータスが未送信のメッセージを取得し、当該メッセージのステータスを送信済みに変更して、サーバコンポーネント１１０にメッセージＩＤ、サービス種別と共に当該メッセージを送信する。共用メッセージテーブル４００に指定されたサービス名で未送信のメッセージが無い場合、クライアントコンポーネント１００からメッセージが送信されるまで待つ方法と、一旦サーバコンポーネント１１０にメッセージ無しの応答をして、サーバコンポーネント１１０から再度メッセージ受信要求を出す方法の二通りが実施可能である。
【００４２】
サーバコンポーネント１１０は、受信したメッセージの処理を行い、メッセージ種別が問合せの場合、応答メッセージを作成し、メッセージ種別を応答とし、引継メッセージＩＤと共に第二の通信プロセス２１０に送信する。
【００４３】
第二の通信プロセス２１０のメッセージ受信処理部２１は、通信装置によりサーバコンポーネント１１０からの応答メッセージを受信すると、クライアントコンポーネント１００からの送信メッセージ受信時と同様にメッセージＩＤを採番し、メッセージＩＤ、サーバコンポーネント１１０から指定された引継ぎメッセージＩＤ及びメッセージ種別と共に共用メッセージテーブル４００に格納し、当該メッセージのステータスを未送信とし、サーバコンポーネント１１０にメッセージＩＤを通知する。サーバコンポーネント１１０が応答メッセージを送信する際、再度ネームサーバ３００に問合せ、他の通信プロセスを使用することも可能である。
【００４４】
クライアントコンポーネント１００が応答メッセージを受信する場合、第一の通信プロセス２００に対応する問合せメッセージのＩＤである引継メッセージＩＤを指定して、メッセージ受信要求を送信する。
【００４５】
第一の通信プロセス２００のメッセージ送信処理部２２は、通信装置によりクライアントコンポーネント１００からのメッセージ受信要求を受信すると、共用メッセージテーブル４００から、引継メッセージＩＤが一致するメッセージを取得し、当該メッセージのステータスを送信済みに変更し、サーバコンポーネント１１０にメッセージＩＤ、サービス種別と共に当該メッセージを送信する。共用メッセージテーブル４００に指定された引継メッセージＩＤのメッセージが無い場合、サーバコンポーネント１１０から応答メッセージが送信されるまで待つ方法と、一旦クライアントコンポーネント１００にメッセージ無しの応答をして、クライアントコンポーネント１００から再度応答メッセージ受信要求を出す方法の二通りが実施可能である。また、クライアントコンポーネント１００が応答メッセージ受信要求を送信する際、再度ネームサーバ３００に問合せ、他の通信プロセスを使用することも可能である。
【００４６】
前記の様に本実施形態の通信プロセスは、共用メッセージテーブル４００中にメッセージと共に格納したサービス名及びステータスの情報に応じてメッセージ通信を行うので、どのメッセージであっても任意の通信プロセスによって処理することが可能である。この為、メッセージ通信において大量のトラフィックを処理する必要が生じた場合には複数の通信プロセスによって大量のメッセージ通信を効率良く処理したり、またある通信プロセスで障害が発生した場合には他の通信プロセスによってメッセージ通信を代行することにより、ソフトウェアコンポーネントが障害を意識することなく処理を続行することができる。
【００４７】
またサーバコンポーネント１１０の障害等により受信メッセージが消失した場合には、メッセージＩＤを指定して再送要求を行なうことにより、メッセージを再度受信することが出来る。この操作を行なうのは、メッセージＩＤを引継いだ別のサーバコンポーネントであっても構わない。また、どの通信プロセスに再送要求を行っても構わない。
【００４８】
同様にクライアントコンポーネント１００の障害等により応答メッセージが消失した場合にも、引継メッセージＩＤを指定して再送要求を行なうことにより、応答メッセージを再度受信することが出来る。この操作を行なうのは、引継メッセージＩＤを引継いだ別のクライアントコンポーネントであっても構わない。また、どの通信プロセスに再送要求を行っても構わない。
【００４９】
通信プロセスを追加する場合、新たな通信プロセスは、ネームサーバ３００と管理コネクションを接続し、自プロセスのＩＰアドレス、送信受付ポート、受信受付ポートをネームサーバ３００に通知する。ネームサーバ３００は、通信プロセス管理テーブル３１０に通信プロセスを追加し、管理コネクションを接続した通信プロセスに通信プロセスＩＤを通知する。ネームサーバ３００は管理用コネクションを使用して全ての通信プロセスに定期的に応答を求めるメッセージを送信し、一定時間内に応答が無い場合はその通信プロセスが障害によってダウンしたものとみなし、管理コネクションを切断してその通信プロセスに関する情報を、通信プロセス管理テーブルから削除する。
【００５０】
前記の様に本実施形態によれば、メッセージ通信において大量のトラフィックを効率良く処理し、障害時にもクライアントコンポーネント及びサーバコンポーネントが障害を意識することなく処理を続行することが出来る。更に、必要に応じて通信プロセスの数を増減させることも自由に行なうことができ、ノンストップシステムを容易に実現することができる。
【００５１】
以上説明した様に本実施形態のメッセージ通信装置によれば、共用メッセージテーブル中にメッセージと共に格納したサービス名及びステータスの情報に応じてメッセージ通信を行うので、メッセージ通信において大量のトラフィックを効率良く処理し、障害時にもソフトウェアコンポーネントが障害を意識することなく処理を続行することが可能である。
【００５２】
（実施形態２）
以下にソフトウェアコンポーネントからの受信要求をメモリキュー上のメッセージにより処理する実施形態２のメッセージ通信装置について説明する。
【００５３】
実施形態１に拠れば、通信プロセスはサービス名に拘らず全てのメッセージを中継できる。また、通信プロセスの数を増やすことも自由であり、大量のトラフィックがある場合、リソースの許す限り通信プロセスを増やしてこれに対応することができる。しかしクライアントコンポーネント１００とサーバコンポーネント１１０の間のメッセージ通信において、共用メッセージテーブル４００へのアクセスが、一方送信の場合は２回、問合せ応答の場合は４回シーケンシャルに行われることとなり、共用メッセージテーブル４００へのアクセス回数が増加してレスポンスタイムに影響を及ぼすことが考えられる。そこで、この点について改良する方法について、図６を用いて説明する。
【００５４】
図６は本実施形態のメッセージ通信の処理内容を示す図である。実施形態１との構成の違いは次の通りである。第一のサーバコンポーネント１１０は第一の通信プロセス２００と常設コネクションを接続している。第一の通信プロセス２００上にはメモリキュー２０１があり、第二の通信プロセス２１０上にはメモリキュー２１１がある。
【００５５】
図７は本実施形態の共用メッセージテーブル４１０の構成例を示す図である。共用メッセージテーブル４１０のレコード構成は、図７に示す様に拡張され、当該メッセージがどの通信プロセス上のメモリキューにあるかを示す通信プロセスＩＤが追加されている。
【００５６】
図８は本実施形態の通信プロセス管理テーブル３２０の構成例を示す図である。また通信プロセス管理テーブル３２０のレコード構成も図８に示す様に拡張され、当該通信プロセスに常設コネクションを接続しているサーバコンポーネントの提供するサービス名リストが追加されている。
【００５７】
クライアントコンポーネント１００がメッセージを送信する場合、サービス名を指定してネームサーバ３００に問合せる。ネームサーバ３００は、通信プロセス管理テーブル３２０を参照し、サービス名リスト中に指定されたサービス名が存在する通信プロセスの中からラウンドロビンで一つの通信プロセスを選択し、そのＩＰアドレスと送信受付ポートをクライアントコンポーネント１００に回答する。本実施形態では、クライアントコンポーネント１００はネームサーバ３００からの回答に従って、第一の通信プロセス２００にメッセージを送信する。
【００５８】
第一の通信プロセス２００のメッセージ受信処理部２１は、メッセージを受信すると、それをメモリキュー２０１に追加し、当該通信プロセスＩＤと共に共用メッセージテーブル４１０に格納し、クライアントコンポーネント１００にメッセージＩＤを通知する。この時、メモリキュー２０１に追加できるメッセージ数の上限に達している場合、メモリキュー２０１へのメッセージ追加は行なわず、通信プロセスＩＤを指定せずに共用メッセージテーブル４１０に当該メッセージを格納する。
【００５９】
サーバコンポーネント１１０がメッセージを受信する場合、常設コネクションを使用して第一の通信プロセス２００に対してメッセージ受信要求を行う。第一の通信プロセス２００のメッセージ送信処理部２２は、メッセージ受信要求を受けるとメモリキュー２０１からメッセージを一つ取出してサーバコンポーネント１１０に送信し、メモリキュー２０１から当該メッセージを消去し、共用メッセージテーブル４１０にアクセスして当該メッセージのステータスを送信済みに変更し、通信プロセスＩＤを消去する。次に共用メッセージテーブル４１０に、当該通信プロセスと常設コネクションを接続しているサーバコンポーネントの提供するサービスの何れかに該当するサービス名で、通信プロセスＩＤがセットされていないメッセージを、それが無くなるかメモリキュー２０１に追加できるメッセージ数の上限に達するまで取得し、メモリキュー２０１に追加する。
【００６０】
サーバコンポーネント１１０が応答メッセージを送信する場合も常設コネクション使用し、第一の通信プロセスに対してメッセージ送信要求を行なう。クライアントコンポーネント１００も、問合せメッセージを送信したのと同じ第一の通信プロセス２００に対してメッセージ受信要求を行い、応答メッセージを受信する。
【００６１】
前記の様に本実施形態では、通信プロセス２００や２１０と一つまたは複数のサーバコンポーネント１１０や１３０との間に常設コネクションを確立しておき、クライアントコンポーネント１００や１２０から送信要求されたメッセージを、共用メッセージテーブル４１０に格納すると同時に通信プロセス２００上のメモリキュー２０１または通信プロセス２１０上のメモリキュー２１１にも追加し、常設コネクションを通した受信要求に対して、このメモリキュー２０１や２１１から検索したメッセージを渡すので、実質のメッセージ送受信はメモリキュー２０１や２１１を経由して行なわれ、共用メッセージテーブル４１０を経由したメッセージ送受信よりも高速な処理が可能となる。
【００６２】
運用による通信プロセスの終了または何らかの障害によって常設コネクションが切断された場合、クライアントコンポーネント及びサーバコンポーネントは、再度常設コネクションの接続要求を発行する。この時、ネームサーバ３００から代替の通信プロセスが指示される。新たに常設コネクションを接続された通信プロセスは、自プロセス上のメモリキューに共用メッセージテーブル４１０から指定されたサービスに属する未処理のメッセージを古い順に予め定義された数分読込み、通信プロセスの交代が完了する。
【００６３】
またメモリキューを用いるメッセージ通信では、その通信プロセスの通信プロセスＩＤを共用メッセージテーブル４１０に設定しておき、当該通信プロセスＩＤに対応する通信プロセスのみによりそのメッセージの処理を行っているが、ネームサーバ３００が管理コネクションを通じたキープアライブメッセージの途絶により通信プロセスの障害を検知した場合には、当該通信プロセスの通信プロセスＩＤを他の各通信プロセスに通知し、その通知を受けた各通信プロセスでは、共用メッセージテーブル４１０上で当該通信プロセスＩＤがセットされたメッセージを、通信プロセスＩＤがセットされていないメッセージと同等に取り扱うものとする。これにより、通信プロセスが障害等でダウンした場合も、当該通信プロセスのメモリキュー上に保持されていたメッセージを、他の通信プロセスによって処理することが可能となる。
【００６４】
以上説明した様に本実施形態のメッセージ通信装置によれば、ソフトウェアコンポーネントからの受信要求をメモリキュー上のメッセージにより処理するので、通信プロセスから共用メッセージテーブルへのアクセス回数がネックとなるのを防止し、メッセージ通信処理のスループットを向上させることが可能である。
【００６５】
（実施形態３）
以下にサービス毎に異なる共用メッセージテーブルを用いてメッセージ通信処理を行う実施形態３のメッセージ通信装置について説明する。
【００６６】
実施形態１によれば、単一の通信プロセスの処理がネックとなってスループットを向上できない場合の問題点は解消される。しかし単一の共用メッセージテーブルへのアクセス集中がネックとなってスループットに影響を及ぼすことが考えられる。そこで、この点を改良する方法を、実施形態３として図９を用いて説明する。
【００６７】
図９は本実施形態のメッセージ通信の処理内容を示す図である。実施形態２との構成の違いは次の通り。
【００６８】
サービス毎にメッセージを格納する第一の共用メッセージテーブル４１０と第二の共用メッセージテーブル４２０があり、どの共用メッセージテーブルにどのサービスの属するメッセージが格納されるかを共用メッセージテーブル管理テーブル（図示せず）によって示す。指定されたサービス名や共用メッセージテーブル管理テーブルの内容に従って、例えば第一の通信プロセス２００は第一の共用メッセージテーブル４１０にアクセスし、第二の通信プロセス２１０は第二の共用メッセージテーブル４２０にアクセスする。但し、一つの通信プロセスが複数の共用メッセージテーブルにアクセスすることも妨げないものとする。
【００６９】
以上説明した様に本実施形態のメッセージ通信装置によれば、サービス毎に異なる共用メッセージテーブルを用いてメッセージ通信処理を行うので、共用メッセージテーブルへのアクセス集中がネックとなるのを防止し、メッセージ通信処理のスループットを向上させることが可能である。
【図面の簡単な説明】
【００７０】
【図１】実施形態１のメッセージ通信システムのシステム構成例を示す図である。
【図２】実施形態１のメッセージ通信装置である情報処理装置２０の概略構成を示す図である。
【図３】実施形態１のメッセージ通信の処理内容を示す図である。
【図４】実施形態１の共用メッセージテーブル４００の構成例を示す図である。
【図５】実施形態１の通信プロセス管理テーブル３１０の構成例を示す図である。
【図６】実施形態２のメッセージ通信の処理内容を示す図である。
【図７】実施形態２の共用メッセージテーブル４１０の構成例を示す図である。
【図８】実施形態２の通信プロセス管理テーブル３２０の構成例を示す図である。
【図９】実施形態３のメッセージ通信の処理内容を示す図である。
【図１０】従来のキューマネージャと共用キューの関係を示す図である。
【符号の説明】
【００７１】
１…クライアントキューマネージャ、２…サーバキューマネージャ、３…サーバキューマネージャ、４…共用キュー、１０…情報処理装置、１１…情報処理装置、２０…情報処理装置、３０…情報処理装置、１００…クライアントコンポーネント、１１０…サーバコンポーネント、２００…通信プロセス、３００…ネームサーバ、４００…共用メッセージテーブル、２１…メッセージ受信処理部、２２…メッセージ送信処理部、２１０…通信プロセス、３１０…通信プロセス管理テーブル、１２０…クライアントコンポーネント、１３０…サーバコンポーネント、２０１…メモリキュー、２１１…メモリキュー、３２０…通信プロセス管理テーブル、４１０…共用メッセージテーブル、４２０…共用メッセージテーブル。
【図１】
2006031592.tif 000003
【図２】
2006031592.tif 000004
【図３】
2006031592.tif 000005
【図４】
2006031592.tif 000006
【図５】
2006031592.tif 000007
【図６】
2006031592.tif 000008
【図７】
2006031592.tif 000009
【図８】
2006031592.tif 000010
【図９】
2006031592.tif 000011
【図１０】
2006031592.tif 000012