(57)【要約】      （修正有）【課題】Pub/Subシステムにおいて、サブスクライバ登録のタイムラグをなくし、ネットワークトラフィックの低減をはかった、メッセージ配送を実現する。【解決手段】メッセージ登録時、メッセージ登録時刻をメッセージ配送情報テーブルへ格納し、メッセージの配送先のノード装置の情報をサブスクライバ登録情報テーブルから読み出してその配送先ノード装置にメッセージを配送し、メッセージ配送情報テーブルのメッセージ情報中のメッセージ登録時刻が通知されたサブスクライバ登録情報中のサブスクライバ登録時刻以後である場合にそのサブスクライバ登録情報で示される配送先ノード装置に当該メッセージ情報で示されるメッセージを配送する。【選択図】図１
2008124977.tif 000002
【特許請求の範囲】
【請求項１】
受け付けたメッセージを配送先ノード装置に配送するメッセージ配送装置におけるメッセージ配送方法において、
メッセージが登録された場合にメッセージ登録時刻を示すメッセージ情報をメッセージ配送情報テーブルへ記憶装置により格納し、当該メッセージの配送先のノード装置の情報をサブスクライバ登録情報テーブルから記憶装置により読み出してその配送先ノード装置に前記メッセージを配送し、配送先ノード装置及びサブスクライバ登録時刻を示すサブスクライバ登録情報の通知を受け取った場合に当該サブスクライバ登録情報を前記サブスクライバ登録情報テーブルへ記憶装置により格納し、前記メッセージ配送情報テーブルのメッセージ情報中のメッセージ登録時刻が前記通知されたサブスクライバ登録情報中のサブスクライバ登録時刻以後である場合にそのサブスクライバ登録情報で示される配送先ノード装置に当該メッセージ情報で示されるメッセージを配送することを特徴とするメッセージ配送方法。
【請求項２】
前記メッセージ配送情報テーブルのメッセージ情報中のメッセージ登録時刻以降における全てのノード装置との通信履歴が記憶装置により格納されており、当該メッセージの配送対象のノード装置が配送済みサブスクライバとして前記メッセージ配送情報テーブルへ記憶装置により格納されている場合に当該メッセージを記憶装置から削除することを特徴とする請求項１に記載されたメッセージ配送方法。
【請求項３】
受け付けたメッセージを配送先ノード装置に配送するメッセージ配送装置において、
メッセージが登録された場合にメッセージ登録時刻を示すメッセージ情報をメッセージ配送情報テーブルへ記憶装置により格納し、当該メッセージの配送先のノード装置の情報をサブスクライバ登録情報テーブルから記憶装置により読み出してその配送先ノード装置に前記メッセージを配送するキューマネージャ処理部と、
配送先ノード装置及びサブスクライバ登録時刻を示すサブスクライバ登録情報の通知を受け取った場合に当該サブスクライバ登録情報を前記サブスクライバ登録情報テーブルへ記憶装置により格納し、前記メッセージ配送情報テーブルのメッセージ情報中のメッセージ登録時刻が前記通知されたサブスクライバ登録情報中のサブスクライバ登録時刻以後である場合にそのサブスクライバ登録情報で示される配送先ノード装置に当該メッセージ情報で示されるメッセージを配送するメッセージ配送処理部とを備えることを特徴とするメッセージ配送装置。
【請求項４】
受け付けたメッセージを配送先ノード装置に配送するメッセージ配送装置におけるメッセージ配送方法をコンピュータに実行させる為のプログラムにおいて、
メッセージが登録された場合にメッセージ登録時刻を示すメッセージ情報をメッセージ配送情報テーブルへ記憶装置により格納し、当該メッセージの配送先のノード装置の情報をサブスクライバ登録情報テーブルから記憶装置により読み出してその配送先ノード装置に前記メッセージを配送し、配送先ノード装置及びサブスクライバ登録時刻を示すサブスクライバ登録情報の通知を受け取った場合に当該サブスクライバ登録情報を前記サブスクライバ登録情報テーブルへ記憶装置により格納し、前記メッセージ配送情報テーブルのメッセージ情報中のメッセージ登録時刻が前記通知されたサブスクライバ登録情報中のサブスクライバ登録時刻以後である場合にそのサブスクライバ登録情報で示される配送先ノード装置に当該メッセージ情報で示されるメッセージを配送するメッセージ配送方法をコンピュータに実行させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はPub/Subシステムにおけるメッセージ配送を行うメッセージ配送技術に関するものである。
【背景技術】
【０００２】
Pub/Subシステムはメッセージキューイングシステムの一種である。メッセージキューイングシステムでは、送信側と受信側の双方のノードが稼動していなくても、自ノードが稼動していれば、キューを介することによって相手側の稼働状態に依存することなく送信処理または受信処理を行うことができる。また、通信障害やシステムダウンが発生しても、送受信されるメッセージは、ディスク装置等の物理実体を有するキューに格納されているので、そのメッセージが消失することはない。従って、メッセージキューイングシステムは、信頼性が高く、かつ、拡張性と柔軟性に優れたシステムであるといえる。
【０００３】
また、Pub/Subシステムでは、複数のノード装置がネットワークを介して他ノード装置上のトピックと呼ばれるキューに対してサブスクライバと呼ばれる受信ノードを登録する。この場合、送信側に登録されたメッセージを複数の受信側ノードに対して配送することができる。また、いずれかの配送先のノード装置に障害が発生した場合にも、システム全体の稼働が停止することはない。可用性に優れたシステムである。ただし、複数のセンタ間でPub/Subシステムを実現する場合には、サブスクライバの登録情報の伝播が遅延することがある。
【０００４】
ところで、Pub/Subシステムの実現の方式には、大きく分けて２通りのタイプがある。一つは、トピックへのサブスクライバの登録時に配送元ノードに通知を行っておき、登録先にのみメッセージを配送するタイプ（例えば、特許文献１、特許文献２参照）、他の一つは、トピックへの登録先ノードを考慮せずに、メッセージを送付するタイプである。
【０００５】
【特許文献１】特開２００４−３４８６８０号公報
【特許文献２】米国特許第０２６１９２３号明細書
【発明の開示】
【発明が解決しようとする課題】
【０００６】
特許文献１に開示された技術によれば、登録されたノードにのみメッセージの配送を行う分、通信のコストの観点で優位である。しかしながら、ネットワークの遅延等によってトピックへのサブスクライバの登録が遅延した場合、メッセージが送信されないことがあるという欠点がある。一方、トピックの登録ノードを考慮せずに全てのノードに送る技術では、予め全ノードに対してメッセージを配信し、受信側ノードでサブスクライバが登録されているかどうかの判別を行うことでサブスクライバ登録のタイムラグの問題に対処する。しかしながら、この場合ネットワークトラフィックの増大という新たな問題が発生する。
【０００７】
本発明の目的は上記サブスクライバ登録のタイムラグの問題を解決し、かつ、ネットワークトラフィックの低減をはかった、Pub/Subシステムにおけるメッセージ配送を行うことが可能な技術を提供することにある。
【課題を解決するための手段】
【０００８】
本発明は、受け付けたメッセージを配送先ノード装置に配送するメッセージ配送装置において、メッセージ登録時刻がサブスクライバ登録時刻以後である場合に当該メッセージをそのサブスクライバ登録情報で示される配送先ノード装置に配送するものである。
【０００９】
本発明のメッセージ配送装置では、Pub/Subシステムにおける通常のメッセージ登録処理としてメッセージが登録されると、メッセージ登録時刻を示すメッセージ情報をメッセージ配送情報テーブルへ格納した後、当該メッセージの配送先のノード装置の情報をサブスクライバ登録情報テーブルから読み出してその配送先ノード装置に前記メッセージを配送する処理を行う。
【００１０】
また本発明のメッセージ配送装置では、サブスクライバである配送先ノード装置の情報と当該サブスクライバの登録をそのノード装置が指示した時刻を示すサブスクライバ登録時刻とを表すサブスクライバ登録情報の通知をノード装置から受け取ると、当該サブスクライバ登録情報を前記サブスクライバ登録情報テーブルへ格納した後、前記メッセージ配送情報テーブルからメッセージ情報中のメッセージ登録時刻を読み出して、前記通知されたサブスクライバ登録情報中のサブスクライバ登録時刻と比較してそのメッセージ登録時刻がサブスクライバ登録時刻以後であるかどうかを調べ、サブスクライバ登録時刻以後である場合には、そのサブスクライバ登録情報で示される配送先ノード装置に当該メッセージ情報で示されるメッセージを配送する処理を行う。
【００１１】
よって本発明においては、サブスクライバ登録情報の通知が遅延した場合に、従来は配送が行われなかったメッセージを、遅延して登録されたサブスクライバに対しても配送することができ、そのメッセージに係るユーザプログラムの処理をメッセージ配送先のノード装置に継続して実行させることができる。従って、ネットワークによるタイムラグにおいてもPub/Subシステムの可用性が確保されていることになる。また、本発明においては、サブスクライバが登録されたノード装置に対してのみ、メッセージ配送処理を行うこととなる。つまり、ネットワークトラフィックは低減されているといえる。
【発明の効果】
【００１２】
本発明によれば、サブスクライバ登録のタイムラグの問題を解決し、かつ、ネットワークトラフィックの低減をはかった、Pub/Subシステムにおけるメッセージ配送を行うことが可能である。
【発明を実施するための最良の形態】
【００１３】
以下に受け付けたメッセージを配送先ノード装置に配送する一実施形態のメッセージ配送装置について説明する。
【００１４】
図１は本実施形態のPub/Subシステムの一例を示す図である。図１に示す様に、本発明の実施形態に係るPub/Subシステムは、ノードＡのコンピュータ１と、ノードＢのコンピュータ２と、ノードＣのコンピュータ３とがネットワーク４によって接続されて構成される。
【００１５】
なお、これらのコンピュータ１〜３は、ネットワーク４におけるいわゆるノード装置であり、以下、本明細書及び図面においては、単に「ノード」と、適宜、略称する。また、「ノード＃のコンピュータ」を単に「ノード＃」と適宜、略称する。ここで、＃は、Ａ、ＢまたはＣである。
【００１６】
図１において、ノードＡのコンピュータ１は、ＣＰＵ（Central Processing Unit）１１と、メモリ１２とから構成され、メモリ１２には、監視エージェント１２１、キューマネージャ１２２、ユーザプログラム１２３、トピック１２４、サブスクライバ登録情報テーブル１２５、センタ間通信履歴１２６、メッセージ配送プログラム１２７が格納されている。なお、メモリ１２は、通常は、主メモリ部分が半導体メモリで構成され、補助メモリ部分がハードディスク記憶装置によって構成される。
【００１７】
ここで、監視エージェント１２１は、メッセージ配送先ノードであるノード２またはノード３における監視エージェントとの間で定期的に通信を行い、サブスクライバ登録情報のやり取りを行う機能等を持つ。また、キューマネージャ１２２は、使用するトピックを管理するとともに、ユーザプログラム１２３がＡＰＩ（アプリケーション・プログラム・インタフェース）を介して操作するトピック１２４に対し、メッセージの登録及び読み出し及びサブスクライバの登録を行う。
【００１８】
なお、「トピック」とは、メッセージを保存する為の論理的な待ち行列を構成する器であり、通常はハードディスク記憶装置上のファイルとして実現される。トピックは内部にメッセージ１２４１とメッセージ毎の配送状況を表すメッセージ配送情報テーブル１２４２を保持する。ユーザプログラム１２３は、メッセージ送信時に、トピックを指定してメッセージ登録ＡＰＩを発行することによって、メッセージを送信側ノードのトピックに格納する。すると、メッセージキューイングシステムの転送機能によって、トピックに格納されたメッセージは、例えば、ＦＩＦＯ（先入れ・先出し）アルゴリズムに従って取り出され、サブスクライバ登録情報テーブル１２５に登録されているサブスクライバに対応する宛先トピックへ送信される。
【００１９】
また、図１では、トピックは、トピック１２４として１つしか示されていないが、各ノードのコンピュータが少なくとも１つのトピック、通常は、複数のトピックを使用するので、ノードのコンピュータの数よりは多いトピックがあることになる。
【００２０】
また、ユーザプログラム１２３は、受信時には、トピックに対してサブスクライバを登録した後に、メッセージ読み出しＡＰＩを発行することによって、宛先トピックに格納されているメッセージを、例えば、キューに最も長く格納されている順番に取り出す。なお、この取り出しにおいては特定のメッセージを優先的に取り出すことも可能である。
【００２１】
ここで、メッセージ配送プログラム１２７は、監視エージェント１２１が受け取ったサブスクライバの登録情報をもとに、サブスクライバ登録情報テーブル１２５とセンタ間通信履歴１２６を更新した後で、トピック内のメッセージ配送情報テーブル１２４２に基づき、サブスクライバに対応するトピック内の配送メッセージを選択する。そして、配送先ノード上のトピックに対して、そのメッセージを配送し、その後メッセージ配送情報テーブル１２４２の状態を更新する。
【００２２】
次に、ノードＢのコンピュータ２は、ＣＰＵ２１とメモリ２２から構成され、メモリ２２には、監視エージェント２２１、キューマネージャ２２２、ユーザプログラム２２３、トピック２２４、サブスクライバ登録情報テーブル２２５、センタ間通信履歴２２６、メッセージ配送プログラム２２７が格納されている。監視エージェント２２１、キューマネージャ２２２、ユーザプログラム２２３、トピック２２４、サブスクライバ登録情報テーブル２２５、センタ間通信履歴２２６、メッセージ配送プログラム２２７のそれぞれの機能は、ノードＡのコンピュータ１における監視エージェント１２１、キューマネージャ１２２、ユーザプログラム１２３、トピック１２４、サブスクライバ登録情報テーブル１２５、センタ間通信履歴１２６、メッセージ配送プログラム１２７のそれぞれの機能と同じである。
更に、ノードＣのコンピュータ３は、ノードＢと同じ構成である。
【００２３】
本実施形態において、前記監視エージェント、キューマネージャ及びメッセージ配送の処理を行う処理部としてコンピュータを機能させる為のプログラムは、ＣＤ−ＲＯＭ等の記録媒体に記録され磁気ディスク等に格納された後、メモリにロードされて実行されるものとする。なお前記プログラムを記録する記録媒体はＣＤ−ＲＯＭ以外の他の記録媒体でも良い。また前記プログラムを当該記録媒体からコンピュータにインストールして使用しても良いし、ネットワークを通じて当該記録媒体にアクセスして前記プログラムを使用するものとしても良い。
【００２４】
図２は本実施形態のメッセージ配送処理で用いられるデータのデータ構造例を示す図である。ここで、図２（ａ）は、サブスクライバ登録情報テーブルのデータ構造の一例、、図２（ｂ）は、センタ間通信履歴のデータ構造の一例、図２（ｃ）は、メッセージ配送情報テーブルのデータ構造の一例を示している。
【００２５】
サブスクライバ登録情報テーブル１２５は、トピック毎にそのトピックに登録されているサブスクライバと宛先ノードとサブスクライバの登録時刻を対応づけた情報であり、図２（ａ）に示す様に、トピック名、（サブスクライバ名、宛先ノード名、サブスクライバ登録時刻）等のフィールドによって構成される。ここで、このサブスクライバ登録時刻は、サブスクライバの登録を行おうとするノードがそのサブスクライバ登録情報を送信して登録を指示した時刻を示すものとする。
【００２６】
センタ間通信履歴１２６は、ノードごとのサブスクライバ登録情報を受け取った最終時刻を対応付けた情報であり、図２（ｂ）に示す様に、ノード名、最終通信時刻等のフィールドによって構成される。また、メッセージ配送情報テーブルは、メッセージ毎に配送済みサブスクライバを対応付けた情報であり、図２（ｃ）に示す様に、メッセージ名、メッセージ登録時刻、配送済みサブスクライバ等のフィールドによって構成される。
【００２７】
図３は本実施形態のPub/Subシステムにおけるメッセージ配送処理の流れの例を示す図である。通常メッセージが登録された場合の処理手順を図３で説明する。
【００２８】
メッセージが登録されるとキューマネージャはトピックとメッセージ配送情報テーブルに対して、メッセージ情報を登録する(ステップＳ３１、Ｓ３２)。その後で、サブスクライバ登録情報テーブルから、トピックに対応付けられたサブスクライバ登録情報を取得する（ステップＳ３３）。そして、登録されているサブスクライブを選択し(ステップＳ３４)、メッセージの配送(ステップＳ３５)を行い、配送が終了するとメッセージ配送情報テーブルを更新(ステップＳ３６)することを繰り返す。なお、メッセージの配送が完了してもこの時点でメッセージの削除は行わない。
【００２９】
図４は本実施形態のPub/Subシステムにおけるサブスクライバ登録情報を受け取ったときの流れの例を示す図である。すなわち、図４は、ノードＡのコンピュータ１においてサブスクライバ登録情報を受け取ったとき、そのノードＡのコンピュータ１が使用していたトピックに格納されているメッセージを、サブスクライバ登録情報を通知してきたノードＢのコンピュータのキューマネージャに配送する処理の例を示したものである。以下、その処理の内容について説明する。なお、メッセージをキューマネージャに配送するとは、そのキューマネージャが管理するトピック、つまり、そのキューマネージャが動作しているノードが使用する対応するトピックにメッセージを配送することを意味する。(以下、本明細書において同じ)。
【００３０】
図４には、コンピュータ１のメッセージ配送プログラム１２７、監視エージェント１２１、サブスクライバ登録情報テーブル１２５、センタ間通信履歴１２６、メッセージ配送情報テーブル１２４２、キューマネージャ１２２、コンピュータ２の監視エージェント２２１、キューマネージャ２２２の動作が示されている。
【００３１】
ノード＃のコンピュータ１、２、３（ここで、＃＝Ａ、Ｂ、Ｃ）との間には、通常、サブスクライバ登録情報通知の為の専用線（図１において図示せず）が設けられており、その通信線を介してノード＃のコンピュータ１、２、３ではサブスクライバ登録情報をやりとりすることができる。この通信は定期的に行われ、例えば、ノードＡのコンピュータ１の持つトピックに対して、ノードＢがサブスクライバを登録した場合、その後の定期的なサブスクライバ情報通知には、ノードＢからノードＡに対してのサブスクライバ登録情報が含まれる。（ステップＳ４１）。
【００３２】
その通知を受けたコンピュータ１の監視エージェント１２１は、メッセージ配送プログラム１２７に通知する（ステップＳ４２）。すると、メッセージ配送プログラム１２７は、センタ間通信履歴１２６を更新(ステップＳ４３)した後で、自ノードのトピックを一つ選択する(ステップＳ４４)。そして、そのトピックに関連するサブスクライバ登録通知を元に、サブスクライバ登録情報テーブルを更新する(ステップＳ４５)。
【００３３】
次に、サブスクライバ登録情報に含まれるサブスクライバを一つ選択し(ステップＳ４６)、そのサブスクライバに配送すべきメッセージがトピック内に存在するかどうかを選別する(ステップＳ４７)。このメッセージ選別処理の具体的な処理手順については、次に、図５を用いて詳細に説明する。
【００３４】
図５は本実施形態のメッセージ選別処理の具体的な処理手順を示す図である。図５において、メッセージ配送プログラム１２７は、メッセージ配送情報テーブル１２４２と通知されたサブスクライバ登録情報を参照する。そして、メッセージ配送情報テーブルにメッセージが存在するかをチェックし(ステップＳ５１)、最初のメッセージを選択する(ステップＳ５２)。
【００３５】
次に、サブスクライバ登録時刻以降にメッセージが登録されていた場合(ステップＳ５３)、サブスクライバに対して未配送であれば配送対象として選別する(ステップＳ５４、Ｓ５５)。続いて、メッセージのポインタを進めて（ステップＳ５６）、次に位置するメッセージを選択し、ステップＳ５１〜Ｓ５６の処理を、メッセージがなくなる（ステップＳ５１でＮｏ）まで繰り返す。
【００３６】
説明を図４に戻す。メッセージ配送プログラム１２７は、以上の様にして、サブスクライバに対する配送対象メッセージを選別すると、キューマネージャに対して、それらのメッセージをサブスクライバに対応するキューマネージャに配送する様に指示し（ステップＳ４８）、キューマネージャはメッセージを配送する(ステップＳ４９)。メッセージの配送が終了すると、メッセージ配送プログラムはメッセージ情報テーブルに対して、配送したメッセージに対応する配送済みサブスクライバの値を更新する様に指示する（ステップＳ４ａ）。その後、メッセージ配送プログラムは、ステップＳ４６へ戻り未処理のサブスクライバが存在しなくなるまで、ステップＳ４７以下の処理を再度実行し、存在しなくなった場合には（ステップＳ４６でＮｏ）、メッセージの削除処理(ステップＳ４ｂ)を実行する。
【００３７】
図６は本実施形態のメッセージ削除処理の具体的な処理手順を示す図である。メッセージの削除処理の詳細な手順を図６で説明する。
【００３８】
メッセージの削除処理では、センタ間の通信履歴とメッセージ配送情報テーブルとサブスクライバ登録情報を参照する。そして、メッセージ配送情報テーブルの中にメッセージが存在した場合(ステップＳ６１)、メッセージを選択する(ステップＳ６２)。そして、そのメッセージがメッセージの登録時刻以降に全てのノードとの通信履歴があるかをチェックし(ステップＳ６３)、サブスクライバ登録情報に記載しているサブスクライバのうち、配送対象のものが配送済みサブスクライバに登録されているかをチェックする(ステップＳ６４)。これらの条件を満たす場合には、メッセージを削除する(ステップＳ６５)。続いて、メッセージのポインタを進めて（ステップＳ６６）、次に位置するメッセージを選択し、ステップＳ６１以下の処理を、削除判定が未処理のメッセージがなくなる（ステップＳ６１でＮｏ）まで繰り返す。
【００３９】
説明を再び図４に戻す。メッセージ配送プログラム１２７は、メッセージの削除処理が完了すると、ステップＳ４４へ戻り未処理のトピックが存在しなくなるまで、ステップＳ４５以下の処理を再度実行し、存在しなくなった場合には（ステップＳ４４でＮｏ）、メッセージ配送処理を終える。
【００４０】
以上の様に、本実施形態においては、サブスクライバ登録情報を受け取った時に、メッセージを対応するノードのトピックに配送をおこなう。そのため、ネットワーク等の要因でサブスクライバ登録情報の通知に遅延が起きた場合でも、メッセージを適切に配送することができ、かつ、サブスクライバ登録を行っていないノードについては、メッセージは送信しないため、ネットワークトラフィックを低減することができる。
【図面の簡単な説明】
【００４１】
【図１】本実施形態のPub/Subシステムの一例を示す図である。
【図２】本実施形態のメッセージ配送処理で用いられるデータのデータ構造例を示す図である。
【図３】本実施形態のPub/Subシステムにおけるメッセージ配送処理の流れの例を示す図である。
【図４】本実施形態のPub/Subシステムにおけるサブスクライバ登録情報を受け取ったときの流れの例を示す図である。
【図５】本実施形態のメッセージ選別処理の具体的な処理手順を示す図である。
【図６】本実施形態のメッセージ削除処理の具体的な処理手順を示す図である。
【符号の説明】
【００４２】
１〜３…コンピュータ、４…ネットワーク、１１…ＣＰＵ、１２…メモリ、１２１…監視エージェント、１２２…キューマネージャ、１２３…ユーザプログラム、１２４…トピック、１２４１…メッセージ、１２４２…メッセージ配送情報テーブル、１２５…サブスクライバ登録情報テーブル、１２６…センタ間通信履歴、１２７…メッセージ配送プログラム、２１…ＣＰＵ、２２…メモリ、２２１…監視エージェント、２２２…キューマネージャ、２２３…ユーザプログラム、２２４…トピック、２２５…サブスクライバ登録情報テーブル、２２６…センタ間通信履歴、２２７…メッセージ配送プログラム。
【図１】
2008124977.tif 000003
【図２】
2008124977.tif 000004
【図３】
2008124977.tif 000005
【図４】
2008124977.tif 000006
【図５】
2008124977.tif 000007
【図６】
2008124977.tif 000008