(57)【要約】  ブローカノードは、分散型イベント配信システムにおいてイベントの転送処理を行うブローカノードであって、イベント転送負荷の変動に柔軟に対応するために、イベントルール毎に自ノードにかかるイベントの転送負荷の変動を監視する監視手段と、転送負荷の変動に応じて当該イベントを転送するためのイベントトピックを動的に変更し、この変更に伴う指示を制御メッセージ（イベントＴｏｐｉｃ制御メッセージ）により他のノードへ通知する制御手段とを備えている。
2010090027.tif 000002
【特許請求の範囲】
【請求項１】
分散型イベント配信システムにおいてイベントの転送処理を行うブローカノードであって、
イベントルール毎に自ノードにかかるイベントの転送負荷の変動を監視する監視手段と、
前記転送負荷の変動に応じて当該イベントを転送するためのイベントトピックを動的に変更し、この変更に伴う指示を制御メッセージにより他のノードへ通知する制御手段とを備えた
ことを特徴とするブローカノード。
【請求項２】
前記制御手段は、イベントトピックの新規作成、削除または移動を行う請求項１に記載のブローカノード。
【請求項３】
前記制御手段は、前記制御メッセージの到達範囲を制御するための到達範囲制御手段を有する請求項１または請求項２に記載のブローカノード。
【請求項４】
前記到達範囲制御手段は、前記転送負荷の変動に応じて前記制御メッセージのＴＴＬ（Ｔｉｍｅ  Ｔｏ  Ｌｉｖｅ）値を設定する請求項３に記載のブローカノード。
【請求項５】
前記到達範囲制御手段は、他のブローカノードから到達した制御メッセージを転送する際に、ＴＴＬ値を前記転送負荷の変動に応じて変更する請求項４に記載のブローカノード。
【請求項６】
前記制御手段は、他のブローカノードから到達した制御メッセージのＴＴＬ値が０になると、当該制御メッセージを転送せずに受信する請求項５に記載のブローカノード。
【請求項７】
前記制御手段は、イベントトピックを新規に作成する場合、当該新規イベントトピックを担当するランデブーノードを他のブローカノードから新規に選択し、前記イベントの転送のための前記新規イベントトピックと前記ランデブーノードとを前記制御メッセージにより他のノードへ通知する請求項１から請求項６のうちのいずれか１項に記載のブローカノード。
【請求項８】
前記制御手段は、特定イベントルールにマッチするイベントの転送負荷が所定の増加パターンにマッチする場合、当該特定イベントルールに対応するイベントトピックを新規に作成し、当該新規イベントトピックを担当するランデブーノードを他のブローカノードから新規に選択し、前記特定のイベントルールにマッチするイベントの転送に前記新規イベントトピックと前記ランデブーノードを通るイベント配信パスとを用いるように前記制御メッセージにより他のノードへ指示する請求項７に記載のブローカノード。
【請求項９】
前記制御手段は、イベントトピックを削除する場合、当該イベントトピックを削除した後に前記イベントの転送に利用するマージ先イベントトピックを既存のイベントトピックから選択し、前記イベントの転送のための前記マージ先イベントトピックを前記制御メッセージにより他のノードへ通知する請求項１から請求項６のうちのいずれか１項に記載のブローカノード。
【請求項１０】
前記制御手段は、特定イベントルールにマッチするイベントの転送負荷が所定の減少パターンにマッチする場合、当該特定イベントルールに対応するイベントトピックを削除し、当該イベントトピックを削除した後に前記特定イベントルールにマッチするイベントの転送に利用するマージ先イベントトピックを既存のイベントトピックから選択し、前記特定のイベントルールにマッチするイベントの転送に前記マージ先イベントトピックを用いるように前記制御メッセージにより他のノードへ指示する請求項９に記載のブローカノード。
【請求項１１】
前記制御手段は、イベントトピックを移動する場合、当該イベントトピックを削除した後に前記イベントの転送に利用するマージ先イベントトピックを新規に作成し、当該マージ先イベントトピックを担当するランデブーノードを他のブローカノードから新規に選択し、前記イベントの転送のための前記マージ先イベントトピックおよび前記ランデブーノードを前記制御メッセージにより他のノードへ通知する請求項１から請求項６のうちのいずれか１項に記載のブローカノード。
【請求項１２】
前記制御手段は、特定イベントルールにマッチするイベントの転送負荷が所定の変動パターンにマッチする場合、当該特定イベントルールに対応するイベントトピックを削除し、当該イベントトピックを削除した後に前記特定イベントルールにマッチするイベントの転送に利用するマージ先イベントトピックを新規に作成し、当該マージ先イベントトピックを担当するランデブーノードを他のブローカノードから新規に選択し、前記特定のイベントルールにマッチするイベントの転送に前記マージ先イベントトピックと前記ランデブーノードを通るイベント配信パスとを用いるように前記制御メッセージにより他のノードへ指示する請求項１１に記載のブローカノード。
【請求項１３】
アドバタイズメント（Ａｄｖｅｒｔｉｓｅｍｅｎｔ）テーブルおよびサブスクリプション（Ｓｕｂｓｃｒｉｐｔｉｏｎ）テーブルを更に有し、
前記制御手段は、前記制御メッセージを送信する際、前記Ａｄｖｅｒｔｉｓｅｍｅｎｔテーブルまたは前記Ｓｕｂｓｃｒｉｐｔｉｏｎテーブルのエントリから前記特定イベントルールにマッチするエントリを検索し、当該エントリに登録されているネクストホップへ前記制御メッセージを送信し、
他のブローカノードから受信した制御メッセージを転送する際、当該受信した制御メッセージで指示された前記特定イベントルールにマッチするエントリを前記Ａｄｖｅｒｔｉｓｅｍｅｎｔテーブルまたは前記Ｓｕｂｓｃｒｉｐｔｉｏｎテーブルのエントリから検索し、当該エントリに登録されているネクストホップへ前記受信した制御メッセージを転送する
請求項１から請求項１２のうちのいずれか１項に記載のブローカノード。
【請求項１４】
前記制御手段は、自ノードからの前記制御メッセージの送信または前記他のブローカノードから受信した制御メッセージの転送をトリガとして、前記Ａｄｖｅｒｔｉｓｅｍｅｎｔテーブルまたは前記Ｓｕｂｓｃｒｉｐｔｉｏｎテーブルから、前記制御メッセージで指示された前記特定イベントルールにマッチするエントリを削除する請求項１３記載のブローカノード。
【請求項１５】
分散型イベント配信システムにおいてイベントの転送処理を行うブローカノードにおけるイベントトピック制御方法であって、
イベントルール毎に自ノードにかかるイベントの転送負荷の変動を監視し、
前記転送負荷の変動に応じて当該イベントを転送するためのイベントトピックを動的に変更し、
前記変更に伴う指示を制御メッセージにより他のノードへ通知する
ことを特徴とするイベントトピック制御方法。
【請求項１６】
前記変更は、イベントトピックの新規作成、削除または移動である請求項１５に記載のイベントトピック制御方法。
【請求項１７】
さらに、前記制御メッセージの到達範囲を制御する請求項１５または請求項１６に記載のイベントトピック制御方法。
【請求項１８】
前記転送負荷の変動に応じて前記制御メッセージのＴＴＬ（Ｔｉｍｅ  Ｔｏ  Ｌｉｖｅ）値を設定することにより前記到達簡易を制御する請求項１７に記載のイベントトピック制御方法。
【請求項１９】
他のブローカノードから到達した制御メッセージを転送する際に、ＴＴＬ値を前記転送負荷の変動に応じて変更することにより前記到達範囲を制御する請求項１８に記載のイベントトピック制御方法。
【請求項２０】
他のブローカノードから到達した制御メッセージのＴＴＬ値が０になると、当該制御メッセージを転送せずに受信する請求項１９に記載のイベントトピック制御方法。
【請求項２１】
イベントトピックを新規に作成する場合、当該新規イベントトピックを担当するランデブーノードを他のブローカノードから新規に選択し、
前記イベントの転送のための前記新規イベントトピックと前記ランデブーノードとを前記制御メッセージにより他のノードへ通知する
請求項１５から請求項２０のうちのいずれか１項に記載のイベントトピック制御方法。
【請求項２２】
イベントトピックを削除する場合、当該イベントトピックを削除した後に前記イベントの転送に利用するマージ先イベントトピックを既存のイベントトピックから選択し、
前記イベントの転送のための前記マージ先イベントトピックを前記制御メッセージにより他のノードへ通知する
請求項１５から請求項２０のうちのいずれか１項に記載のイベントトピック制御方法。
【請求項２３】
イベントトピックを移動する場合、当該イベントトピックを削除した後に前記イベントの転送に利用するマージ先イベントトピックを新規に作成し、
当該マージ先イベントトピックを担当するランデブーノードを他のブローカノードから新規に選択し、
前記イベントの転送のための前記マージ先イベントトピックおよび前記ランデブーノードを前記制御メッセージにより他のノードへ通知する
請求項１５から請求項２０のうちのいずれか１項に記載のイベントトピック制御方法。
【請求項２４】
複数のブローカノードを有する分散型イベント配信システムにおけるパブリッシャ（Ｐｕｂｌｉｓｈｅｒ）ノードであって、
アドバタイズ（Ａｄｖｅｒｔｉｓｅ）メッセージを送信するアドバタイズ送信手段と、
パブリッシュ（Ｐｕｂｌｉｓｈ）メッセージを送信するパブリッシュ送信手段と、
ブローカノードからイベントトピックの変更を指示する制御メッセージを受信すると、前記制御メッセージで指示された新規イベントトピックまたはマージ先イベントトピックを記載したアドバタイズ（Ａｄｖｅｒｔｉｓｅ）メッセージを前記制御メッセージで指示されたランデブーノードを最終宛先として送信し、前記制御メッセージで前記新規イベントトピックまたは前記マージ先イベントトピックをイベントの転送に用いるよう指示された特定のイベントトピックを前記新規イベントトピックまたは前記マージ先イベントトピックに書き換えたパブリッシュメッセージを送信するように制御する制御手段と
を備えたことを特徴とするパブリッシャノード。
【請求項２５】
複数のブローカノードを有する分散型イベント配信システムにおけるサブスクライバ（Ｓｕｂｓｃｒｉｂｅｒ）ノードであって、
サブスクライブ（Ｓｕｂｓｃｒｉｂｅ）メッセージを送信するサブスクライブ送信手段と、
パブリッシュ（Ｐｕｂｌｉｓｈ）メッセージを受信するパブリッシュ受信手段と、
ブローカノードからイベントトピックの変更を指示する制御メッセージを受信すると、前記制御メッセージで指示された新規イベントトピックまたはマージ先イベントトピックを記載したＳｕｂｓｃｒｉｂｅメッセージを前記制御メッセージで指示されたランデブーノードを最終宛先として送信するように指示する制御手段と
を備えたことを特徴とするサブスクライバノード。
【請求項２６】
分散型イベント配信システムにおいて、
アドバタイズ（Ａｄｖｅｒｔｉｓｅ）メッセージおよびパブリッシュ（Ｐｕｂｌｉｓｈ）メッセージを送信するパブリッシャ（Ｐｕｂｌｉｓｈｅｒ）ノードと、
サブスクライブ（Ｓｕｂｓｃｒｉｂｅ）メッセージを送信し、前記パブリッシュメッセージを受信するサブスクライバノードと、
パブリッシャノードからサブスクライバノードへのイベントの転送処理を行う複数のブローカノードとを備え、
各ブローカノードは、
イベントルール毎に自ノードにかかるイベントの転送負荷の変動を監視する監視手段と、
前記転送負荷の変動に応じて当該イベントを転送するためのイベントトピックを動的に変更し、この変更に伴う指示を制御メッセージにより他のノードへ通知する制御手段とを有する
こと特徴とする分散型イベント配信システム。
【請求項２７】
前記ブローカノードの前記制御手段は、イベントトピックの新規作成、削除または移動を行う請求項２６に記載の分散型イベント配信システム。
【請求項２８】
前記ブローカノードの前記制御手段は、前記制御メッセージの到達範囲を制御するための到達範囲制御手段を有する請求項２６または請求項２７に記載の分散型イベント配信システム。
【請求項２９】
前記到達範囲制御手段は、前記転送負荷の変動に応じて前記制御メッセージのＴＴＬ（Ｔｉｍｅ  Ｔｏ  Ｌｉｖｅ）値を設定する請求項２８に記載の分散型イベント配信システム。
【請求項３０】
前記到達範囲制御手段は、他のブローカノードから到達した制御メッセージを転送する際に、ＴＴＬ値を前記転送負荷の変動に応じて変更する請求項２９に記載の分散型イベント配信システム。
【請求項３１】
前記到達範囲制御手段は、他のブローカノードから到達した制御メッセージのＴＴＬ値が０になると、当該制御メッセージを転送せずに受信する請求項３０に記載の分散型イベント配信システム。
【請求項３２】
分散型イベント配信システムにおいてイベントの転送処理を行うブローカノードにおけるプログラム制御プロセッサをイベントトピック制御装置として機能させるプログラムであって、
イベントルール毎に自ノードにかかるイベントの転送負荷の変動を監視し、
前記転送負荷の変動に応じて当該イベントを転送するためのイベントトピックを動的に変更し、
前記変更に伴う指示を制御メッセージにより他のノードへ通知する
ように前記プログラム制御プロセッサを機能させることを特徴とするプログラム。
【請求項３３】
前記変更は、イベントトピックの新規作成、削除または移動である請求項３２に記載のプログラム。
【請求項３４】
さらに、前記制御メッセージの到達範囲を制御する請求項３２または請求項３３に記載のプログラム。
【請求項３５】
前記転送負荷の変動に応じて前記制御メッセージのＴＴＬ（Ｔｉｍｅ  Ｔｏ  Ｌｉｖｅ）値を設定することにより前記到達簡易を制御する請求項３４に記載のプログラム。
【請求項３６】
他のブローカノードから到達した制御メッセージを転送する際に、ＴＴＬ値を前記転送負荷の変動に応じて変更することにより前記到達範囲を制御する請求項３５に記載のプログラム。
【請求項３７】
他のブローカノードから到達した制御メッセージのＴＴＬ値が０になると、当該制御メッセージを転送せずに受信する請求項３６に記載のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は分散型イベント配信システムに係り、特に分散型イベント配信システムにおけるブローカノードおよびイベントトピック制御方法に関する。
【背景技術】
【０００２】
イベント配信システムが広く利用されている。イベント配信システムは、野球の試合のスコア変化、株価の変化、天候の変化など、何らかの状態の変化(すなわちイベント)をリアルタイムかつプッシュでイベントサーバ（パブリッシャ：Ｐｕｂｌｉｓｈｅｒ）からイベントクライアント（サブスクライバ：Ｓｕｂｓｃｒｉｂｅｒ）へ配信するシステムである。イベント配信システムにおいて、ＰｕｂｌｉｓｈｅｒからＳｕｂｓｃｒｉｂｅｒへのイベントの配信手順は次の通りである。
１）アドバタイズ（Ａｄｖｅｒｔｉｓｅ）メッセージの送信
２）サブスクライブ（Ｓｕｂｓｃｒｉｂｅ）メッセージの送信
３）ルーティングテーブルの作成
４）Ｐｕｂｌｉｓｈメッセージの送信；および５）Ｐｕｂｌｉｓｈメッセージの転送【０００３】
イベント配信システムは単一のサーバノードによりイベント配信システムを運用する集中型イベント配信システムと複数のブローカノードによりイベント配信システムを運用する分散型イベント配信システムに分けられる。以下、非特許文献１に基づき、分散型イベント配信システムについて図１〜図４を参照しながら簡単に説明する。【０００４】
図１はイベント配信システムを一般的に説明するためのネットワーク構成例を示す図である。ここでは、複数のパブリッシャ（以下、Ｐｕｂｌｉｓｈｅｒと記す。）ＰＵＢから複数のサブスクライバ（以下、Ｓｕｂｓｃｒｉｂｅｒと記す。）ＳＵＢへ複数のブローカノードＥＢのネットワークを通してイベントが配信される。ただし、以下の説明では、簡略化するために、２つのＰｕｂｌｉｓｈｅｒ（ＰＵＢＸ、ＰＵＢＹ）と、２つのＳｕｂｓｃｒｉｂｅｒ（ＳＵＢＺ、ＳＵＢＷ）と、６つのブローカノードＥＢＡ−ＥＢＥとを有するネットワークを例示する。【０００５】
１）Ａｄｖｅｒｔｉｓｅメッセージの送信
図２はＡｄｖｅｒｔｉｓｅメッセージの送信を説明するためのネットワーク構成図である。Ｐｕｂｌｉｓｈｅｒは、どのようなイベントを配信するかをＡｄｖｅｒｔｉｓｅメッセージによりイベント配信システムへ通知する。まず、ＰｕｂｌｉｓｈｅｒＰＵＢは自身が配信するイベントトピック（以下、イベントＴｏｐｉｃと記す。ここでは「関東の天気」）を決め、Ａｄｖｅｒｔｉｓｅメッセージ（Ａｄｖ）に記載して送信する。なお、イベントＴｏｐｉｃは、当該イベントＴｏｐｉｃを用いて発信される情報のトピックを表す。ＰｕｂｌｉｓｈｅｒやＳｕｂｓｃｒｉｂｅｒが同一のイベントＴｏｐｉｃを用いることで同一トピックのイベントの発信、受信を行うことが可能になる。イベントＴｏｐｉｃは他のイベントＴｏｐｉｃとの階層関係を持っていてもよい。ここでは、「日本の天気」の下位に「関東の天気」、「東海の天気」・・・があり、「関東の天気」の下位に「東京の天気」、「横浜の天気」・・・がある、という階層関係を例示する。【０００６】
Ｐｕｂｌｉｓｈｅｒは自身が配信するイベントがイベントＴｏｐｉｃ内のさらに狭い範囲の内容に限定される場合、イベントＴｏｐｉｃに加えて、フィルタリング（Ｆｉｌｔｅｒｉｎｇ）ルールをＡｄｖｅｒｔｉｓｅメッセージに記載することができる。Ｆｉｌｔｅｒｉｎｇルールはイベントの内容に関する任意の条件を記述することができる。イベントに含まれるキーワードや発信された時間帯などが例として挙げられる。また、イベントの内容がＸＭＬで記述される場合はＸｐａｔｈを用いて記述することが考えられる。図２に示す例では、ＰＵＢＸが「神奈川の天気」、ＰＵＢＹが「東京の天気」をＦｉｌｔｅｒｉｎｇルールとして指定している。【０００７】
Ａｄｖｅｒｔｉｓｅメッセージは最初にＰｕｂｌｉｓｈｅｒが直接接続しているブローカノードに対して送信され、その後ブローカノードにより転送処理が繰り返されてランデブーノードと呼ばれるブローカノードへ届けられる。ランデブーノードは、後述するように、イベントＴｏｐｉｃ毎に複数のブローカノードから選択される。Ａｄｖｅｒｔｉｓｅメッセージ送信時にイベントＴｏｐｉｃに対応するブローカノードが存在しない場合には新規に選択される。図２によれば、ＰＵＢＸがＡｄｖｅｒｔｉｓｅメッセージＡｄｖ１をブローカノードＥＢＡへ送信し、ＥＢＡからランデブーノードＥＢＦへ転送される。同様に、ＰＵＢＹがＡｄｖｅｒｔｉｓｅメッセージＡｄｖ２をブローカノードＥＢＢへ送信し、ＥＢＢからランデブーノードＥＢＦへ転送される。【０００８】
Ａｄｖｅｒｔｉｓｅメッセージを転送するブローカノードは、転送する際にＡｄｖｅｒｔｉｓｅｍｅｎｔテーブルＡＴを作成する。ＡｄｖｅｒｔｉｓｅｍｅｎｔテーブルＡＴには、受信したＡｄｖｅｒｔｉｓｅメッセージＡｄｖに記載されたイベントＴｏｐｉｃ、Ｆｉｌｔｅｒｉｎｇルールが登録されるほか、直前ホップのノードを識別する情報が登録される。ここでは、ブローカノードＥＢＡに、イベントＴｏｐｉｃ「関東の天気」、Ｆｉｌｔｅｒｉｎｇルール「神奈川」、直前ホップのノードを識別する「ＰＵＢＸ」などの情報を含むアドバタイズメント（Ａｄｖｅｒｔｉｓｅｍｅｎｔ）テーブルＡＴＡが生成される。ブローカノードＥＢＢおよびランデブーノードＥＢＦでも、同様にしてＡｄｖｅｒｔｉｓｅｍｅｎｔテーブルＡＴＢおよびＡＴＦがそれぞれ作成される。【０００９】
２）Ｓｕｂｓｃｒｉｂｅメッセージの送信
図３はＳｕｂｓｃｒｉｂｅメッセージの送信を説明するためのネットワーク構成図である。Ｓｕｂｓｃｒｉｂｅｒは、どのようなイベントを受信したいかをＳｕｂｓｃｒｉｂｅメッセージによりイベント配信システムへ通知する。Ｓｕｂｓｃｒｉｂｅｒは、受信したいイベントＴｏｐｉｃを決め、Ｓｕｂｓｃｒｉｂｅメッセージに記載して送信する。受信したいイベントがイベントＴｏｐｉｃ内のさらに狭い範囲の内容に限定される場合には、イベントＴｏｐｉｃに加えて、ＦｉｌｔｅｒｉｎｇルールをＳｕｂｓｃｒｉｂｅメッセージに記載することができる。ここでは、ＳＵＢＺがＳｕｂｓｃｒｉｂｅメッセージＳｕｂ１にＦｉｌｔｅｒｉｎｇルールとして「横浜の天気」を、ＳＵＢＷがＳｕｂｓｃｒｉｂｅメッセージＳｕｂ２にＦｉｌｔｅｒｉｎｇルールとして「川崎の天気」を、それぞれ指定している。【００１０】
ＳｕｂｓｃｒｉｂｅメッセージＳｕｂ１およびＳｕｂ２は、Ａｄｖｅｒｔｉｓｅメッセージと同様に、イベントＴｏｐｉｃに対応したランデブーノードＥＢＦへ向けてブローカノードにより転送処理が繰り返し行われる。この転送処理を行う際に、次に述べるようにブローカノードでルーティングテーブルが生成される。【００１１】
３）ルーティングテーブルの作成
イベント配信システムは、ＡｄｖｅｒｔｉｓｅメッセージおよびＳｕｂｓｃｒｉｂｅメッセージに基づいて、イベント配信のためのイベントルーティングテーブルを作成する。図２に示すように、Ａｄｖｅｒｔｉｓｅメッセージを転送するブローカノードは、転送する際にＡｄｖｅｒｔｉｓｅｍｅｎｔテーブルＡＴを作成する。図３に示すように、ブローカノードはＳｕｂｓｃｒｉｂｅメッセージを転送する際、サブスクリプション（Ｓｕｂｓｃｒｉｐｔｉｏｎ）テーブルＳＴを作成する。【００１２】
ＳｕｂｓｃｒｉｐｔｉｏｎテーブルＳＴには、受信したＳｕｂｓｃｒｉｂｅメッセージＳｕｂに記載されたイベントＴｏｐｉｃ、Ｆｉｌｔｅｒｉｎｇルールが登録されるほか、直前ホップのノードを識別する情報が登録される。ただし、複数のＳｕｂｓｃｒｉｂｅメッセージＳｕｂにおいてＦｉｌｔｅｒｉｎｇルールの地域範囲が重複する場合には、当該ブローカノードはＦｉｌｔｅｒｉｎｇルールをマージして、テーブルサイズの抑制を図ったり、Ｓｕｂｓｃｒｉｂｅメッセージの転送回数を減らしたりする。【００１３】
たとえば、ブローカノードＥＢＣは、ＳｕｂｓｃｒｉｂｅメッセージＳｕｂ１のＦｉｌｔｅｒｉｎｇルールが「神奈川／横浜」であり、ＳｕｂｓｃｒｉｂｅメッセージＳｕｂ２のＦｉｌｔｅｒｉｎｇルールが「神奈川／川崎」であるから、これらのＦｉｌｔｅｒｉｎｇルール「横浜」および「川崎」を「神奈川」にマージする。これによって、ランデブーノードＥＢＦへ転送するＳｕｂｓｃｒｉｂｅメッセージ数を１つ（Ｓｕｂ３）に減らし、ランデブーノードＥＢＦで作成されるテーブルエントリの数も１つに抑制することができる（ＳｕｂｓｃｒｉｐｔｉｏｎテーブルＳＴＦ）。【００１４】
また、ＳｕｂｓｃｒｉｂｅメッセージＳｕｂ３を受信したランデブーノードＥＢＦは、既に作成されたＡｄｖｅｒｔｉｓｅｍｅｎｔテーブルＡＴＦを参照することで、更に先のブローカノードＥＢＡへＳｕｂｓｃｒｉｂｅメッセージＳｕｂ３を転送することができる。これにより、ＳｕｂｓｃｒｉｂｅメッセージＳｕｂ３がＡｄｖｅｒｔｉｓｅメッセージのリバースパスを転送されることになり、経路上のブローカノードにＳｕｂｓｃｒｉｂｅｒの指定したＦｉｌｔｅｒｉｎｇルールが登録されていく。これによって、以下で述べるように、Ｐｕｂｌｉｓｈｅｒの近くでＰｕｂｌｉｓｈメッセージのフィルタリングを行うことが可能になり、不要なイベントの配信が防止される。【００１５】
以上の動作によりＰｕｂｌｉｓｈｅｒからランデブーノードを経由し、Ｓｕｂｓｃｒｉｂｅｒへ至るイベント配信ツリーが作成されることになる。【００１６】
４）Ｐｕｂｌｉｓｈメッセージの送信
イベントが発生すると、Ｐｕｂｌｉｓｈｅｒは、イベントＴｏｐｉｃおよびイベントを記載したＰｕｂｌｉｓｈメッセージをイベント配信システムへ送信する。【００１７】
５）Ｐｕｂｌｉｓｈメッセージの転送
図４はＰｕｂｌｉｓｈメッセージの転送を説明するためのネットワーク構成図である。Ｐｕｂｌｉｓｈメッセージは、ブローカノードＥＢＡ、ＥＢＦ、ＥＢＣの各々がＳｕｂｓｃｒｉｐｔｉｏｎテーブルを参照することで順次転送される。Ｐｕｂｌｉｓｈメッセージは基本的に全てランデブーノードを経由してＳｕｂｓｃｒｉｂｅｒへ配信されることになる。【００１８】
ブローカノードは、Ｓｕｂｓｃｒｉｐｔｉｏｎテーブルに記載されたＦｉｌｔｅｒｉｎｇルールの範囲内にＰｕｂｌｉｓｈメッセージのイベントの内容が含まれる場合にのみ転送を行う。例えば、図４において、ブローカノードＥＢＣは、ブローカノードＥＢＥから通知されたＦｉｌｔｅｒｉｎｇルール「神奈川／川崎」にＰｕｂｌｉｓｈメッセージのイベントの内容が含まれないため、ブローカノードＥＢＥに対しては当該Ｐｕｂｌｉｓｈメッセージの転送は行わない。
【先行技術文献】
【非特許文献】
【００１９】
【非特許文献１】Peter Pietzuch and Jean Bacon Hermes: A Distributed Event-Based Middleware Architecture 1st International Workshop on Distributed Event-Based Systems (DEBS'02), http://www.doc.ic.ac.uk/~peter/manager/doc/prp-debs 2002-hermes.pdf
【発明の概要】
【発明が解決しようとする課題】
【００２０】
上述した非特許文献１に記載されたような分散型イベント配信システムでは、イベントＴｏｐｉｃの決め方が重要となる。例えば、日本の天気に関するイベントを配信する場合、イベントＴｏｐｉｃを「日本の天気」といったように広い範囲でとるとランデブーノードには「日本の天気」に含まれるイベントが全て配信されることとなる。このために、台風が接近した場合などイベントの発生頻度が高くなった場合、ランデブーノードのＰｕｂｌｉｓｈメッセージ転送負荷は非常に高くなってしまう。【００２１】
一方でイベントＴｏｐｉｃを「横浜の天気」といったように狭い範囲でとった場合、地域毎にランデブーノードが選択されることでランデブーノードの負荷は分散されるが、多数のイベントＴｏｐｉｃが並立することになる。このために、上述したようなＦｉｌｔｅｒｉｎｇルールのマージが行われず、Ｓｕｂｓｃｒｉｂｅメッセージ数やルーティングテーブル数が増加してしまう。【００２２】
このように上述した分散型イベント配信システムでは、事前にイベントの発生頻度を推定してイベントＴｏｐｉｃを決めていた。すなわち、発生頻度が高いと見積もられる場合にはイベントＴｏｐｉｃを狭くとることでランデブーノードの負荷分散を実現し、発生頻度が低いと見積もられる場合にはイベントＴｏｐｉｃを広くとりＳｕｂｓｃｒｉｂｅメッセージ数やルーティングテーブルサイズの抑制を実現していた。【００２３】
しかしながら、当初の見積もりと比較してイベントの発生頻度が高くなれば、ランデブーノードへ負荷が集中することになり、低くなれば負荷分散の効果に比べＳｕｂｓｃｒｉｂｅメッセージ数やルーティングテーブルサイズ等のコストの方が大きくなる。このように事前にイベントの発生頻度を推定してイベントＴｏｐｉｃを決めておく方式では、負荷の状況変化に柔軟に対応することができない。【００２４】
そこで、本発明の目的は、分散型イベント配信システムにおいてイベント転送負荷の変動に柔軟に対応することができるブローカノードおよびイベントトピック制御方法を提供することにある。
【課題を解決するための手段】
【００２５】
本発明によるブローカノードは、イベントルール毎に自ノードにかかるイベントの転送負荷の変動を監視する監視手段と、転送負荷の変動に応じて当該イベントを転送するためのイベントトピックを動的に変更し、この変更に伴う指示を制御メッセージにより他のノードへ通知する制御手段とを備えたことを特徴とする。【００２６】
本発明によるイベントトピック制御方法は、イベントルール毎に自ノードにかかるイベントの転送負荷の変動を監視し、転送負荷の変動に応じて当該イベントを転送するためのイベントトピックを動的に変更し、変更に伴う指示を制御メッセージにより他のノードへ通知することを特徴とする。【００２７】
本発明によるパブリッシャ（Ｐｕｂｌｉｓｈｅｒ）ノードは、複数のブローカノードを有する分散型イベント配信システムにおけるパブリッシャノードであって、アドバタイズ（Ａｄｖｅｒｔｉｓｅ）メッセージを送信するアドバタイズ送信手段と、パブリッシュ（Ｐｕｂｌｉｓｈ）メッセージを送信するパブリッシュ送信手段と、ブローカノードからイベントトピックの変更を指示する制御メッセージを受信すると、前記制御メッセージで指示された新規イベントトピックまたはマージ先イベントトピックを記載したアドバタイズ（Ａｄｖｅｒｔｉｓｅ）メッセージを前記制御メッセージで指示されたランデブーノードを最終宛先として送信し、前記制御メッセージで前記新規イベントトピックまたは前記マージ先イベントトピックをイベントの転送に用いるよう指示された特定のイベントトピックを前記新規イベントトピックまたは前記マージ先イベントトピックに書き換えたパブリッシュメッセージを送信するように制御する制御手段とを備えたことを特徴とする。【００２８】
本発明によるサブスクライバ（Ｓｕｂｓｃｒｉｂｅｒ）ノードは、複数のブローカノードを有する分散型イベント配信システムにおけるサブスクライバノードであって、サブスクライブ（Ｓｕｂｓｃｒｉｂｅ）メッセージを送信するサブスクライブ送信手段と、パブリッシュ（Ｐｕｂｌｉｓｈ）メッセージを受信するパブリッシュ受信手段と、ブローカノードからイベントトピックの変更を指示する制御メッセージを受信すると、前記制御メッセージで指示された新規イベントトピックまたはマージ先イベントトピックを記載したＳｕｂｓｃｒｉｂｅメッセージを前記制御メッセージで指示されたランデブーノードを最終宛先として送信するように指示する制御手段とを備えたことを特徴とする。【００２９】
本発明による分散型イベント配信システムは、アドバタイズ（Ａｄｖｅｒｔｉｓｅ）メッセージおよびパブリッシュ（Ｐｕｂｌｉｓｈ）メッセージを送信するパブリッシャ（Ｐｕｂｌｉｓｈｅｒ）ノードと、サブスクライブ（Ｓｕｂｓｃｒｉｂｅ）メッセージを送信し、前記パブリッシュメッセージを受信するサブスクライバノードと、パブリッシャノードからサブスクライバノードへのイベントの転送処理を行う複数のブローカノードとを備え、各ブローカノードは、イベントルール毎に自ノードにかかるイベントの転送負荷の変動を監視する監視手段と、前記転送負荷の変動に応じて当該イベントを転送するためのイベントトピックを動的に変更し、この変更に伴う指示を制御メッセージにより他のノードへ通知する制御手段とを有すること特徴とする。
【発明の効果】
【００３０】
本発明によれば、分散型イベント配信システムにおいてイベント転送負荷の変動に柔軟に対応することができる。
【図面の簡単な説明】
【００３１】
【図１】イベント配信システムを一般的に説明するためのネットワーク構成例を示す図である。
【図２】Ａｄｖｅｒｔｉｓｅメッセージの送信を説明するためのネットワーク構成図である。
【図３】Ｓｕｂｓｃｒｉｂｅメッセージの送信を説明するためのネットワーク構成図である。
【図４】Ｐｕｂｌｉｓｈメッセージの転送を説明するためのネットワーク構成図である。
【図５】本発明の第１実施形態によるイベントＴｏｐｉｃ制御装置を含むブローカノードの機能的構成を示すブロック図である。
【図６】（Ａ）はＳｕｂｓｃｒｉｐｔｉｏｎテーブルの一例を示す図、（Ｂ）はＡｄｖｅｒｔｉｓｅｍｅｎｔテーブルの一例を示す図である。
【図７】転送負荷変動通知ポリシ管理テーブルに設定されている通知ポリシの一例を示す図である。
【図８】イベントＴｏｐｉｃ制御ポリシ管理テーブルに設定されている制御ポリシの一例を示す図である。
【図９】本実施形態におけるＰｕｂｌｉｓｈｅｒの機能的構成を概略的に示すブロック図である。
【図１０】本実施形態におけるＳｕｂｓｃｒｉｂｅｒの機能的構成を概略的に示すブロック図である。
【図１１】本実施形態による分散型イベント配信システムにおける新規イベントＴｏｐｉｃの作成手順を説明するためのネットワーク図である。
【図１２】本実施形態による分散型イベント配信システムにおけるイベントＴｏｐｉｃ制御メッセージの送信手順を説明するためのネットワーク図である。
【図１３】本実施形態による分散型イベント配信システムにおけるイベント配信パスの構築手順を説明するためのネットワーク図である。
【図１４】本実施形態による分散型イベント配信システムにおけるイベント転送手順を説明するためのネットワーク図である。
【図１５】本実施形態による分散型イベント配信システムにおけるイベントＴｏｐｉｃの削除手順を説明するためのネットワーク図である。
【図１６】イベントＴｏｐｉｃ「関東の天気」のイベント配信パスを示すネットワーク図である。
【図１７】本発明の第１実施形態におけるイベントＴｏｐｉｃ「横浜の天気」のイベント配信パスを示すネットワーク図である。
【図１８】本発明の第２実施形態におけるイベントＴｏｐｉｃ「横浜の天気」のイベント配信パスを示すネットワーク図である。
【図１９】本発明の第２実施形態によるイベントＴｏｐｉｃ制御装置を含むブローカノードの機能的構成を示すブロック図である。
【図２０】イベントＴｏｐｉｃ制御ポリシ管理テーブルに設定されている制御ポリシの一例を示す図である。
【発明を実施するための形態】
【００３２】
１．第１実施形態
図１に示すようなネットワークにおいて、本実施形態によるブローカノードＥＢには、後述するイベント監視部とイベントＴｏｐｉｃ制御部とが設けられている。なお、既に述べたように、イベントＴｏｐｉｃは、当該イベントＴｏｐｉｃを用いて発信される情報のトピックを表す。ＰｕｂｌｉｓｈｅｒやＳｕｂｓｃｒｉｂｅｒが同一のイベントＴｏｐｉｃを用いることで同一トピックのイベントの発信、受信を行うことが可能になる。イベントＴｏｐｉｃは他のイベントＴｏｐｉｃとの階層関係を持っていてもよい。
【００３３】
イベント監視部は、特定のルール(以下、イベントルール)に合致するイベントを転送する際、自ノードにかかる負荷を測定し、当該イベントルールについて転送負荷の変動が特定のパターン（以下、転送負荷変動パターン）にマッチする場合に、当該イベントルールと転送負荷変動パターンとをイベントＴｏｐｉｃ制御部へ通知する。イベント監視部は、特定のポリシ（転送負荷変動推定ポリシ）に基づいて特定のイベントルールに合致するイベントの転送負荷が特定の転送負荷変動パターンにマッチすることを推定し、当該イベントルールと転送負荷変動パターンをイベントＴｏｐｉｃ制御部へ通知してもよい。
【００３４】
イベントＴｏｐｉｃ制御部はイベント監視部からの通知を受け、イベントＴｏｐｉｃの新規作成または削除を行うと共に、イベントＴｏｐｉｃ制御メッセージを送信することで当該イベントＴｏｐｉｃに関係するブローカノードおよびＰｕｂｌｉｓｈｅｒ、ＳｕｂｓｃｒｉｂｅｒへイベントＴｏｐｉｃの新規作成または削除を通知する。また、他のブローカノードからイベントＴｏｐｉｃ制御メッセージを受信した場合には、当該メッセージを他のブローカノードまたはＰｕｂｌｉｓｈｅｒ、Ｓｕｂｓｃｒｉｂｅｒへ転送する。
【００３５】
このように、本実施形態によるブローカノードＥＢは、イベント転送の負荷の変動に応じてイベントトピックを動的に変更し、この変更に伴う指示を制御メッセージにより他のノードへ通知するので、イベント転送の負荷の変動に柔軟に対応できる。以下、ブローカノードの構成および動作をより詳細に説明する。
【００３６】
１．１）ブローカノードの構成
図５は本発明の第１実施形態によるイベントＴｏｐｉｃ制御装置を含むブローカノードの機能的構成を示すブロック図、図６（Ａ）はＳｕｂｓｃｒｉｐｔｉｏｎテーブルの一例を示す図、図６（Ｂ）はＡｄｖｅｒｔｉｓｅｍｅｎｔテーブルの一例を示す図である。
【００３７】
図５において、ブローカノードＥＢは、機能的に、Ｓｕｂｓｃｒｉｐｔｉｏｎテーブル１０１、Ａｄｖｅｒｔｉｓｅｍｅｎｔテーブル１０２、ルーティングテーブル管理部１０３およびイベント転送部１０４を有し、さらに、イベント監視部１０５および転送負荷変動通知ポリシ管理テーブル１０６と、イベントＴｏｐｉｃ制御部１０７およびイベントＴｏｐｉｃ制御ポリシ管理テーブル１０８とを有する。Ｓｕｂｓｃｒｉｐｔｉｏｎテーブル１０１およびＡｄｖｅｒｔｉｓｅｍｅｎｔテーブル１０２には、図６に例示するように、エントリＩＤ毎に、イベントＴｏｐｉｃ、Ｆｉｌｔｅｒｉｎｇルールおよびネクストホップに関する情報がそれぞれ登録される。
【００３８】
ルーティングテーブル管理部１０３は、隣接するブローカノードＥＢ、ＳｕｂｓｃｒｉｂｅｒまたはＰｕｂｌｉｓｈｅｒから受信したＡｄｖｅｒｔｉｓｅｍｅｎｔメッセージおよびＳｕｂｓｃｒｉｂｅメッセージを転送するとともに、受信したメッセージに含まれる情報を元にしてＳｕｂｓｃｒｉｐｔｉｏｎテーブル１０１またはＡｄｖｅｒｔｉｓｅｍｅｎｔテーブル１０２を更新する。
【００３９】
Ａｄｖｅｒｔｉｓｅメッセージを受信した場合、ルーティングテーブル管理部１０３は、Ａｄｖｅｒｔｉｓｅメッセージに含まれるイベントＴｏｐｉｃ、Ｆｉｌｔｅｒｉｎｇルールと共に、当該メッセージを自ノードへ転送した隣接ノードをＮｅｘｔホップとしてＡｄｖｅｒｔｉｓｅｍｅｎｔテーブル１０２に登録する。
【００４０】
Ｓｕｂｓｃｒｉｂｅメッセージを受信した場合、ルーティングテーブル管理部１０３は、Ｓｕｂｓｃｒｉｂｅメッセージに含まれるイベントＴｏｐｉｃ、Ｆｉｌｔｅｒｉｎｇルールと共に、当該メッセージを自ノードへ転送した隣接ノードをＮｅｘｔホップとしてＳｕｂｓｃｒｉｐｔｉｏｎテーブル１０１に登録する。
【００４１】
なお、すでにＳｕｂｓｃｒｉｐｔｉｏｎテーブル１０１に登録されているエントリのイベントＴｏｐｉｃおよびＮｅｘｔホップと、受信したＳｕｂｓｃｒｉｂｅメッセージのそれらとが同一の場合、当該エントリのＦｉｌｔｅｒｉｎｇルールと受信したＳｕｂｓｃｒｉｂｅメッセージに含まれるＦｉｌｔｅｒｉｎｇルールとをマージすることができる。例えば、Ｓｕｂｓｃｒｉｐｔｉｏｎテーブル１０１に既にイベントＴｏｐｉｃ「関東の天気」、Ｆｉｌｔｅｒｉｎｇルール「/神奈川/横浜」を持つエントリが登録されているとする。そして、イベントＴｏｐｉｃ「関東の天気」、Ｆｉｌｔｅｒｉｎｇルール「/神奈川/川崎」を持つＳｕｂｓｃｒｉｂｅメッセージを受信した場合、Ｆｉｌｔｅｒｉｎｇルールを「/神奈川/」にマージしたエントリを作成し、既存エントリを削除することができる。これによりＳｕｂｓｃｒｉｐｔｉｏｎテーブル１０１のサイズ増加が抑制され、テーブル検索にかかる時間を節約できる。
【００４２】
受信したＳｕｂｓｃｒｉｂｅメッセージは自ノードからランデブーノードへの経路上にある隣接ブローカノードへ転送する。なお、ＳｕｂｓｃｒｉｂｅメッセージのイベントＴｏｐｉｃが既にＳｕｂｓｃｒｉｐｔｉｏｎテーブルに登録されているエントリと同一であり、かつ当該エントリのＦｉｌｔｅｒｉｎｇルールＦ＿ｓｘとＳｕｂｓｃｒｉｂｅメッセージのＦｉｌｔｅｒｉｎｇルールＦ＿ｓｙとの関係が「Ｆ＿ｓｙがＦ＿ｓｘに含まれる（Ｆ＿ｓｙ⊆Ｆ＿ｓｘ）」場合、Ｓｕｂｓｃｒｉｂｅメッセージの転送を行わない。例えばＦ＿ｓｙが/横浜/、Ｆ＿ｓｘが/神奈川/であれば、Ｓｕｂｓｃｒｉｂｅメッセージの転送を行わない。
【００４３】
一度ランデブーノードへ到達した後のＳｕｂｓｃｒｉｂｅメッセージを受信した場合には、Ａｄｖｅｒｔｉｓｅｍｅｎｔテーブル１０２を参照し、同一イベントＴｏｐｉｃのエントリに登録されたＮｅｘｔホップへ転送することができる。ただし、ＳｕｂｓｃｒｉｂｅメッセージのＦｉｌｔｅｒｉｎｇルールＦ＿ｓｙと当該エントリのＦｉｌｔｅｒｉｎｇルールＦ＿ｓｚとの重なりが空集合の場合（Ｆ＿ｓｙ∩Ｆ＿ｓｚ＝φ）、Ｓｕｂｓｃｒｉｂｅメッセージの転送を行わない。
【００４４】
イベント転送部１０４は、隣接ブローカノードＥＢまたはＰｕｂｌｉｓｈｅｒからＰｕｂｌｉｓｈメッセージを受信すると、Ｓｕｂｓｃｒｉｐｔｉｏｎテーブル１０１を参照し、受信したＰｕｂｌｉｓｈメッセージとイベントＴｏｐｉｃが同じでイベント内容がＦｉｌｔｅｒｉｎｇルールに合致するエントリを検索する。そして、検索されたエントリに登録されているＮｅｘｔホップへ当該Ｐｕｂｌｉｓｈメッセージを転送する。
【００４５】
次に、本実施形態によるイベントＴｏｐｉｃ制御装置におけるイベント監視部１０５および負荷変動通知ポリシ管理テーブル１０６と、イベントＴｏｐｉｃ制御部１０７およびイベントＴｏｐｉｃ制御ポリシ管理テーブル１０８と、について詳細に説明する。
【００４６】
１．２）ブローカノードのイベント監視部
イベント監視部１０５は、特定のルール(以下、イベントルール)に合致するイベントを転送する際、自ノードにかかる負荷を測定する。そして、当該イベントルールに関する転送負荷の変動が転送負荷変動通知ポリシ管理テーブル１０６に登録されている特定のパターン（以下、転送負荷変動パターン）とマッチするかどうかを判定する。この転送負荷変動パターンにマッチする場合には、当該イベントルールと当該転送負荷変動パターンとをイベントＴｏｐｉｃ制御部１０７へ通知する。
【００４７】
また、転送負荷変動通知ポリシ管理テーブル１０６に転送負荷変動推定ポリシを登録しておき、イベント監視部１０５は特定イベントルールに関する転送負荷の変動が転送負荷変動推定ポリシに基づいて特定の転送負荷変動パターンにマッチすることを推定してもよい。この場合には、当該イベントルールと推定された転送負荷変動パターンとをイベントＴｏｐｉｃ制御部１０７へ通知する。
【００４８】
＜イベントルール＞
まずイベントルールについて説明する。イベントルールの例としては以下のようなものが考えられる。
【００４９】
（１）イベントＴｏｐｉｃ
イベントＴｏｐｉｃそのもの。必ず設定される。
【００５０】
（２）Ｆｉｌｔｅｒｉｎｇルール：
（ａ）ＳｕｂｓｃｒｉｐｔｉｏｎテーブルやＡｄｖｅｒｔｉｓｅｍｅｎｔテーブルに登録されているＦｉｌｔｅｒｉｎｇルール；Ｐｕｂｌｉｓｈメッセージにより通知されるイベントが満たすべき任意の条件；イベントに含まれるキーワードや発信された時間帯など。また、イベントの内容がＸＭＬで記述される場合はＸｐａｔｈを用いて記述されたルールが考えられる；
（ｂ）事前に設定したＦｉｌｔｅｒｉｎｇルール：上記（２．ａ）と同じ。
【００５１】
（３）Ｐｕｂｌｉｓｈメッセージの属性に基づくルール
イベントの内容そのものではなく、イベントを伝送するＰｕｂｌｉｓｈメッセージの属性情報、たとえばＨＴＴＰやＳＩＰの他ＴＣＰ、ＵＤＰ、ＩＰのヘッダー情報に関するルール：
（ａ）Ｐｕｂｌｉｓｈメッセージのサイズ；
（ｂ）Ｐｕｂｌｉｓｈメッセージの送信元Ｓｕｂｓｃｒｉｂｅｒ；
（ｃ）Ｐｕｂｌｉｓｈメッセージに添付されたファイルの種類（静止画、動画、音声）。
【００５２】
この他にも様々なルールが考えられる。イベントルールは、上記（１）のイベントＴｏｐｉｃとその他のルールとの組み合わせによって表現されうる。すなわち、各イベントルールには必ずイベントＴｏｐｉｃが記載される。単一のイベントルールに複数のイベントＴｏｐｉｃが指定されていてもよい。以下、イベントルールに指定されたイベントＴｏｐｉｃを「ターゲットイベントＴｏｐｉｃ」と呼ぶ。
【００５３】
＜転送負荷変動パターン＞
イベント監視部１０５が測定する負荷としては以下のようなパラメータが挙げられる。
【００５４】
・頻度：上記イベントルールに合致するイベントを単位時間当たりに転送する回数。
【００５５】
・ネットワーク帯域：上記イベントルールに合致するイベントを転送するために占有されるネットワーク帯域。
【００５６】
・ＣＰＵ時間：上記イベントルールに合致するイベントの転送に必要なＣＰＵ時間。例えば当該イベントに適用するＦｉｌｔｅｒｉｎｇルールが複雑なほど必要なＣＰＵ時間は増加する。
【００５７】
この他にも測定する負荷として様々なパラメータが考えられる。これらパラメータは単独で用いられてもよいし、複数のパラメータを組み合わせて測定してもよい。
【００５８】
転送負荷変動パターンとしては、つぎのようなものが挙げられる。
【００５９】
（１）転送負荷が事前に設定した閾値を上回る、または下回る。
【００６０】
（２）一定時間内の転送負荷の最小値と最大値の差、すなわち転送負荷の変動幅が事前に設定した閾値を上回る、または下回る。
【００６１】
この他にも転送負荷変動パターンとして様々なパターンが考えられる。これらのパターンは単独で用いることもできるし、複数のパターンを組み合わせて一つの転送負荷変動パターンとして用いることもできる。
【００６２】
転送負荷変動通知ポリシ管理テーブル１０６には、各イベントルールについてどのような転送負荷変動パターンを検出した場合にイベントＴｏｐｉｃ制御部１０７へ通知するかが通知ポリシとして登録されている。
【００６３】
図７は転送負荷変動通知ポリシ管理テーブルに設定されている通知ポリシの一例を示す図である。例えばＩＤ＝１のエントリでは、イベントＴｏｐｉｃ「関東の天気」、Ｆｉｌｔｅｒｉｎｇルール「/神奈川/横浜」にマッチするイベントの転送負荷がＡ、Ｂ、（ＣΛＥ）、（ＤΛＦ）のいずれかのパターンにマッチした場合に、イベントＴｏｐｉｃ制御部１０７への通知が発生する。また、ＩＤ＝４やＩＤ＝５のエントリでは、イベントルールとしてイベントＴｏｐｉｃのみが記載されている。
【００６４】
一例として（ＣΛＥ）は、ＣとＥとの論理積であり、次のようなパターンを意味する。すなわち、イベント監視部１０５は、イベント転送に利用するネットワーク帯域およびＣＰＵ使用率を測定し、転送負荷変動通知ポリシ管理テーブル１０６を参照することで、当該イベントルールでのネットワーク帯域が１Ｍｂｐｓを超えているか（パターンＣ）、ＣＰＵ使用率が５０％を超えているか（パターンＥ）を判定する。パターンＣおよびＥの両方を満たしたとき（ＣΛＥ）に、イベント監視部１０５は、当該イベントルールと当該（ＣΛＥ）の転送負荷変動パターンとをイベントＴｏｐｉｃ制御部１０７へ通知する。
【００６５】
＜推定ポリシ＞
推定ポリシは観測事象と推定事象で構成される。イベント監視部１０５は観測事象として記述された事象が観測された場合、推定事象として記述された事象が起きたこと、または将来起きることを推定する。
【００６６】
観測事象としては以下の事象が挙げられる。
【００６７】
・イベントルールに合致するイベントを転送
・イベントルールに合致するイベントの転送負荷が転送負荷変動パターンにマッチ
この他にも観測事象として様々な事象が考えられる。これらの事象は単独で用いることもできるし、複数の事象を組み合わせて一つの観測事象として用いることもできる。
【００６８】
推定事象は、特定のイベントルールについての転送負荷の変動である。
【００６９】
観測事象と推定事象の組み合わせは様々な組み合わせを用いることができる。例えば、複数の観測事象から単一の推定事象を推定したり、単一の観測事象から複数の推定事象を推定したりしてもよい。また、複数の観測事象をＡＮＤやＯＲ等の論理記号で組み合わせた論理式から単一の推定事象を推定してもよい。たとえば、ＩＦ(観測事象Ａ  ＡＮＤ  観測事象Ｂ)、ＴＨＥＮ（推定事象Ｃ）；すなわち観測事象Ａおよび観測事象Ｂを観測したならば推定事象Ｃの発生を推定する。複数の観測事象の時系列的条件から推定事象を推定してもよい。たとえば、事象Ａを観測後１０分以内に事象Ｂを観測した場合には推定事象Ｃの１時間後の発生を推定する。
【００７０】
１．３）ブローカノードのイベントＴｏｐｉｃ制御部
イベントＴｏｐｉｃ制御部１０７は、イベント監視部１０５からの負荷変動通知を受けると、後述するように、イベントＴｏｐｉｃ制御ポリシ管理テーブル１０８を参照してイベントＴｏｐｉｃの新規作成または削除を行うと共に、イベントＴｏｐｉｃ制御メッセージを送信する。イベントＴｏｐｉｃ制御メッセージにより、当該イベントＴｏｐｉｃに関係するブローカノードＥＢまたはＰｕｂｌｉｓｈｅｒやＳｕｂｓｃｒｉｂｅｒへイベントＴｏｐｉｃの新規作成または削除を通知する。
【００７１】
また、他のブローカノードＥＢからイベントＴｏｐｉｃ制御メッセージを受信した場合には、当該メッセージを他のブローカノードＥＢまたはＰｕｂｌｉｓｈｅｒ、Ｓｕｂｓｃｒｉｂｅｒへ転送する。
【００７２】
イベントＴｏｐｉｃ制御ポリシ管理テーブル１０８には、イベント監視部１０５からの通知内容とイベントＴｏｐｉｃ制御部１０７の動作内容とが記述された制御ポリシが設定されており、イベントＴｏｐｉｃ制御部１０７は、この制御ポリシに従ってイベントＴｏｐｉｃの作成・削除を行う。
【００７３】
＜制御ポリシ＞
図８はイベントＴｏｐｉｃ制御ポリシ管理テーブルに設定されている制御ポリシの一例を示す図である。
【００７４】
制御ポリシでは、以下２つの動作内容とイベント監視部１０５からの通知内容との関係が記述される。
【００７５】
（１）作成または削除するイベントＴｏｐｉｃ
（２）イベント監視部１０５から通知される転送負荷変動パターン。
【００７６】
転送負荷変動パターンとして、転送負荷が閾値を上回った(または将来上回ると推定される)と通知された場合、または、転送負荷が閾値として設定された変動幅以上に増加した（または将来増加すると推定される）と通知された場合は、当該転送負荷変動パターンが測定または推定されたイベントルールに対応するイベントＴｏｐｉｃを新規に作成する。例えば、イベントＴｏｐｉｃ：「関東の天気」、Ｆｉｌｔｅｒｉｎｇルール：「神奈川/横浜/」のイベントルールにマッチするイベントについて転送負荷が閾値を上回ったと通知された場合は、当該イベントに対応するイベントＴｏｐｉｃ、「横浜の天気」を新規に作成する。
【００７７】
また、転送負荷変動パターンとして転送負荷が閾値を下回った（または将来下回ると推定される）と通知された場合、または転送負荷が閾値として設定された変動幅以上に低下した(または将来低下すると推定される)と通知された場合は、当該転送負荷変動パターンが測定または推定されたイベントルールに対応するイベントＴｏｐｉｃを削除する。例えば、イベントＴｏｐｉｃ：「横浜の天気」のイベントルールにマッチするイベントについて転送負荷が閾値を下回ったと通知された場合は、イベントＴｏｐｉｃ「横浜の天気」を削除する。
【００７８】
＜イベントＴｏｐｉｃの作成または削除＞
イベント監視部１０５からの通知内容が実際に測定したもの（または、現時点で起きている事象として推定したもの）であれば、イベントＴｏｐｉｃ制御部１０７は即時にイベントＴｏｐｉｃの作成または削除を行う。通知内容が将来起きると推定したものであれば、通知内容に記載されたタイミングでイベントＴｏｐｉｃの作成または削除を行う。例えば１０分後に推定事象Ａが起きると通知された場合は、１０分後にイベントＴｏｐｉｃの作成または削除を行う。
【００７９】
＜イベントＴｏｐｉｃ制御メッセージの作成・削除＞
新規にイベントＴｏｐｉｃを作成する場合、新規イベントＴｏｐｉｃを担当するランデブーノード（新規ランデブーノード）を他のブローカノードＥＢから選択する。そして、イベントＴｏｐｉｃ制御メッセージに、作成した新規イベントＴｏｐｉｃと新規ランデブーノード、さらにイベント監視部１０５から通知されたイベントルール（ターゲットイベントＴｏｐｉｃが含まれる）を記載して送信し、新規イベントＴｏｐｉｃの作成を他のノードへ通知する。
【００８０】
イベントＴｏｐｉｃの削除を行う場合、削除対象のイベントＴｏｐｉｃにマッチするイベントＴｏｐｉｃ（以下、マージ先イベントＴｏｐｉｃ）を既存のイベントＴｏｐｉｃの中から決める。例えば「横浜の天気」というイベントＴｏｐｉｃを削除する場合、マージ先イベントＴｏｐｉｃとして「関東の天気」を既存のイベントＴｏｐｉｃの中から選択する。したがって、イベントＴｏｐｉｃ「横浜の天気」を利用して転送していたイベントは削除された後、「関東の天気」を利用して転送される。続いて、イベントＴｏｐｉｃ制御部１０７は、マージ先イベントＴｏｐｉｃと、イベント監視部１０５から通知されたイベントルール（ターゲットイベントＴｏｐｉｃが含まれる場合はターゲットイベントＴｏｐｉｃが削除対象イベントＴｏｐｉｃとなる。）とを記載したイベントＴｏｐｉｃ制御メッセージを送信し、既存イベントＴｏｐｉｃの削除を他のノードへ通知する。
【００８１】
なお、イベントＴｏｐｉｃの作成と削除は同時に行ってもよい。たとえば、一つのイベントＴｏｐｉｃ制御メッセージによって、イベントＴｏｐｉｃの削除およびイベントＴｏｐｉｃの作成の両方を通知し、削除対象イベントＴｏｐｉｃのマージ先イベントＴｏｐｉｃとして新規に作成したイベントＴｏｐｉｃを通知すれば、イベントＴｏｐｉｃの移動を実現することができる。
【００８２】
また、複数のイベントＴｏｐｉｃについて作成と削除を同時に通知してもよく、既存のイベントＴｏｐｉｃを削除し、複数のイベントＴｏｐｉｃを新規作成するとともに、新規に作成した複数のイベントＴｏｐｉｃをマージ先イベントＴｏｐｉｃとして通知すれば、既存のイベントＴｏｐｉｃの複数のイベントＴｏｐｉｃへの分割を実現することもできる。
【００８３】
図８に例示するように、イベントルールおよび転送負荷変動パターン毎にイベントＴｏｐｉｃ制御部１０７の動作内容が記述されている。たとえばＩＤ＝１のエントリでは、図７に示したイベントルールＩＤ＝１−３に合致するイベントの転送負荷の変動パターンが転送負荷変動パターンＡにマッチした場合に、イベントＴｏｐｉｃを新規作成する、というポリシが記載されている。また、ＩＤ＝２、ＩＤ＝７のエントリのようにワイルドカード（＊印）などを用い、任意のイベントルールについて特定の転送負荷変動パターンに転送負荷の変動がマッチした場合の動作内容を記載することもできる。
【００８４】
＜イベントＴｏｐｉｃ制御メッセージの転送＞
イベントＴｏｐｉｃ制御部１０７は、Ｓｕｂｓｃｒｉｐｔｉｏｎテーブル１０１およびＡｄｖｅｒｔｉｓｅｍｅｎｔテーブル１０２を参照してイベントＴｏｐｉｃ制御メッセージを転送する。新規イベントＴｏｐｉｃ作成時であれば、イベントＴｏｐｉｃ制御メッセージに記載されたターゲットイベントＴｏｐｉｃと合致するエントリをＳｕｂｓｃｒｉｐｔｉｏｎテーブル１０１および／またはＡｄｖｅｒｔｉｓｅｍｅｎｔテーブル１０２から検索し、当該エントリに記載されたＮｅｘｔホップへとイベントＴｏｐｉｃ制御メッセージを転送する。
【００８５】
検索したエントリに記載されたＦｉｌｔｅｒｉｎｇルール（Ｆ＿ｐ）とイベントＴｏｐｉｃ制御メッセージに記載されたルール（Ｆ＿ｑ）とに重複範囲がない場合、すなわちＦ＿ｐ∩Ｆ＿ｑ＝φ（空集合）の場合は、当該エントリに記載されたＮｅｘｔホップへとイベントＴｏｐｉｃ制御メッセージを転送しなくてもよい。その理由はＮｅｘｔホップが新規イベントＴｏｐｉｃを利用したイベントの転送（より詳しく言えばイベントＴｏｐｉｃ制御メッセージに記載されたルールに合致するイベントの転送）を行うことがないためである。こうすることで、イベントＴｏｐｉｃ制御メッセージの転送回数を抑制するこができる。
【００８６】
既存のイベントＴｏｐｉｃを削除する場合であれば、イベントＴｏｐｉｃ制御メッセージに記載されたターゲットイベントＴｏｐｉｃと合致するエントリをＳｕｂｓｃｒｉｐｔｉｏｎテーブル１０１および／またはＡｄｖｅｒｔｉｓｅｍｅｎｔテーブル１０２から検索し、当該エントリに記載されたＮｅｘｔホップへとイベントＴｏｐｉｃ制御メッセージを転送する。イベントＴｏｐｉｃ制御メッセージの転送を契機としてイベントＴｏｐｉｃ制御メッセージの転送直後または一定時間経過後に削除対象イベントＴｏｐｉｃと合致するエントリをＳｕｂｓｃｒｉｐｔｉｏｎテーブル１０１、Ａｄｖｅｒｔｉｓｅｍｅｎｔテーブル１０２から削除してもよい。こうすることで、不要なエントリの削除を迅速に行える他、不要エントリ削除のためにＰｕｂｌｉｓｈｅｒおよびＳｕｂｓｃｒｉｂｅｒがＡｄｖｅｒｔｉｓｅメッセージおよびＳｕｂｓｃｒｉｂｅメッセージ（すなわち削除対象イベントＴｏｐｉｃのイベントの送受信を今後行わない旨記載されたＡｄｖｅｒｔｉｓｅメッセージおよびＳｕｂｓｃｒｉｂｅメッセージ）を送信する必要がなくなるため、当該メッセージの転送により発生するトラヒックを抑制することができる。なお、イベントＴｏｐｉｃ制御メッセージの転送を契機に削除しない場合は、削除対象イベントＴｏｐｉｃのイベントの送受信を今後行わない旨記載されたＡｄｖｅｒｔｉｓｅメッセージおよびＳｕｂｓｃｒｉｂｅメッセージを転送したタイミングで削除すればよい。
【００８７】
なお、上述したルーティングテーブル管理部１０３、イベント転送部１０４、イベント監視部１０５およびイベントＴｏｐｉｃ制御部１０７の機能は、それぞれプログラムをＣＰＵ等のプログラム制御プロセッサ上で実行することにより実現されうる。
【００８８】
２．Ｐｕｂｌｉｓｈｅｒの構成
図９は本実施形態におけるＰｕｂｌｉｓｈｅｒの機能的構成を概略的に示すブロック図である。ＰｕｂｌｉｓｈｅｒＰＵＢは、Ａｄｖｅｒｔｉｓｅ送信部２０１、イベント発生部２０２、Ｐｕｂｌｉｓｈ送信部２０３、および、イベントＴｏｐｉｃ制御メッセージ受信部２０４からなる。
【００８９】
Ａｄｖｅｒｔｉｓｅ送信部２０１は、イベントＴｏｐｉｃをＡｄｖｅｒｔｉｓｅメッセージに記載し、当該イベントＴｏｐｉｃを担当するランデブーノードを最終宛先として自ノードと直接接続するブローカノードへ送信する。
【００９０】
イベント発生部２０２は何らかの状態の変化、すなわちイベントを検出しＰｕｂｌｉｓｈ送信部２０３に通知する。イベント発生部２０２の例としては天候の変化を検出するセンサデバイスや、ユーザのプレゼンスを検出するアプリケーションなどが挙げられる。
【００９１】
Ｐｕｂｌｉｓｈ送信部２０３はイベント発生部２０２から通知されたイベントとともにイベントに対応するイベントＴｏｐｉｃをＰｕｂｌｉｓｈメッセージに記載し、自ノードと直接接続するブローカノードへ送信する。イベントＴｏｐｉｃは事前に単一の値を設定しておいてもよいし、イベント内容に基づいてイベントＴｏｐｉｃを決めるためのルールを設定しておいてもよい。
【００９２】
イベントＴｏｐｉｃ制御メッセージ受信部２０４は、ブローカノードからのイベントＴｏｐｉｃ制御メッセージの受信、Ｐｕｂｌｉｓｈ送信部２０３が送信したＰｕｂｌｉｓｈメッセージのイベントＴｏｐｉｃの書き換えおよび転送、Ａｄｖｅｒｔｉｓｅ送信部２０１へのＡｄｖｅｒｔｉｓｅメッセージ送信の指示などを実行する。
【００９３】
＜イベントＴｏｐｉｃの書き換え＞
イベントＴｏｐｉｃ制御メッセージを受信した場合、新規イベントＴｏｐｉｃの作成の通知であれば当該メッセージ受信以降、メッセージに記載されたイベントＴｏｐｉｃおよびルールに合致するイベントを含むＰｕｂｌｉｓｈメッセージをインターセプトし、当該イベントのイベントＴｏｐｉｃを新規イベントＴｏｐｉｃに書き換える。
【００９４】
また、Ｐｕｂｌｉｓｈメッセージの最終宛先は新規イベントＴｏｐｉｃを担当するランデブーノードに書き換え、自ノードと直接接続するブローカノードへ転送する。また、Ａｄｖｅｒｔｉｓｅ送信部２０１に対して、新規イベントＴｏｐｉｃが記載されたＡｄｖｅｒｔｉｓｅメッセージを、新規イベントＴｏｐｉｃを担当するランデブーノードを最終宛先として送信するよう指示する。
【００９５】
また、既存イベントＴｏｐｉｃの削除の通知であれば、以下のように処理する。削除対象イベントＴｏｐｉｃが過去にイベントＴｏｐｉｃ制御メッセージによって追加されたイベントＴｏｐｉｃの場合、すなわち削除対象イベントの新規作成を通知するイベントＴｏｐｉｃ制御メッセージを受信済みの場合は、削除対象イベントＴｏｐｉｃへのイベントＴｏｐｉｃの書き換えを中止する。
【００９６】
また、受信したイベントＴｏｐｉｃ制御メッセージにマージ先のイベントＴｏｐｉｃが指定されている場合は、削除対象イベントＴｏｐｉｃへ書き換えられていたイベントをマージ先イベントＴｏｐｉｃに書き換えるようにする。なお、マージ先イベントＴｏｐｉｃが指定されていない場合、イベントはもともと自ノードに設定されていたイベントＴｏｐｉｃで送信される。削除対象イベントＴｏｐｉｃが過去にイベントＴｏｐｉｃ制御メッセージによって追加されたイベントＴｏｐｉｃでない場合（すなわち元々自ノードに設定されていたイベントＴｏｐｉｃの場合）は、削除対象イベントＴｏｐｉｃに合致するイベントをマージ先イベントＴｏｐｉｃに書き換えるようにする。
【００９７】
なお、上述したＰｕｂｌｉｓｈｅｒの機能は、プログラムをＣＰＵ等のプログラム制御プロセッサ上で実行することにより実現されうる。
【００９８】
３．Ｓｕｂｓｃｒｉｂｅｒの構成
図１０は本実施形態におけるＳｕｂｓｃｒｉｂｅｒの機能的構成を概略的に示すブロック図である。ＳｕｂｓｃｒｉｂｅｒＳＵＢはＳｕｂｓｃｒｉｂｅ送信部３０１、イベントＴｏｐｉｃ制御メッセージ受信部３０２およびＰｕｂｌｉｓｈ受信部３０３からなる。
【００９９】
Ｓｕｂｓｃｒｉｂｅ送信部３０１はイベントＴｏｐｉｃをＳｕｂｓｃｒｉｂｅメッセージに記載し、当該イベントＴｏｐｉｃを担当するランデブーノードを最終宛先として自ノードと直接接続するブローカノードへ送信する。
【０１００】
イベントＴｏｐｉｃ制御メッセージ受信部３０２はブローカノードからのイベントＴｏｐｉｃ制御メッセージの受信、Ｐｕｂｌｉｓｈ受信部３０３が受信するＰｕｂｌｉｓｈメッセージのイベントＴｏｐｉｃの書き換えおよび転送、Ｓｕｂｓｃｒｉｂｅ送信部３０１へのＳｕｂｓｃｒｉｂｅメッセージ送信の指示を行う。
【０１０１】
Ｐｕｂｌｉｓｈ受信部３０３はＰｕｂｌｉｓｈメッセージを受信し、受信メッセージからイベントを取り出してアプリケーション（図示せず）に渡す。
【０１０２】
＜イベントＴｏｐｉｃの書き換え＞
イベントＴｏｐｉｃ制御メッセージ受信部３０２は、受信したイベントＴｏｐｉｃ制御メッセージが新規イベントＴｏｐｉｃの作成の通知であれば、当該メッセージ受信以降、メッセージに記載されたイベントルールに合致するイベントを含むＰｕｂｌｉｓｈメッセージをインターセプトし、当該イベントのイベントＴｏｐｉｃを新規イベントＴｏｐｉｃに書き換える。また、Ｓｕｂｓｃｒｉｂｅ送信部３０１に対して、新規イベントＴｏｐｉｃが記載されたＳｕｂｓｃｒｉｂｅメッセージを、新規イベントＴｏｐｉｃを担当するランデブーノードを最終宛先として送信するよう指示する。
【０１０３】
また、既存イベントＴｏｐｉｃの削除の通知であれば、以下のように処理する。削除対象イベントＴｏｐｉｃが過去にイベントＴｏｐｉｃ制御メッセージによって追加されたイベントＴｏｐｉｃの場合、すなわち削除対象イベントの新規作成を通知するイベントＴｏｐｉｃ制御メッセージを受信済みの場合は、削除対象イベントＴｏｐｉｃへのイベントＴｏｐｉｃの書き換えを中止する。
【０１０４】
また、受信したイベントＴｏｐｉｃ制御メッセージにマージ先のイベントＴｏｐｉｃが指定されている場合は、削除対象イベントＴｏｐｉｃへ書き換えられていたイベントをマージ先イベントＴｏｐｉｃに書き換えるようにする。なお、マージ先イベントＴｏｐｉｃが指定されていない場合、イベントはもともと自ノードに設定されていたイベントＴｏｐｉｃで送信される。削除対象イベントＴｏｐｉｃが過去にイベントＴｏｐｉｃ制御メッセージによって追加されたイベントＴｏｐｉｃでない場合（すなわち元々自ノードに設定されていたイベントＴｏｐｉｃの場合）は、削除対象イベントＴｏｐｉｃに合致するイベントをマージ先イベントＴｏｐｉｃに書き換えるようにする。
【０１０５】
なお、上述したＳｕｂｓｃｒｉｂｅｒの機能は、プログラムをＣＰＵ等のプログラム制御プロセッサ上で実行することにより実現されうる。
【０１０６】
４．イベントＴｏｐｉｃ制御動作
次に、本実施形態による分散型イベント配信システムの動作について説明する。まず新規にイベントＴｏｐｉｃを作成する際の動作について図１１〜図１４に示した例を参照しながら説明する。
【０１０７】
４．１）新規イベントＴｏｐｉｃの作成
＜転送負荷変動パターンの検出＞
上述したように、ブローカノードＥＢには転送負荷変動通知ポリシ管理テーブル１０６が設けられ、予めイベントルールと転送負荷変動パターン（すなわち通知ポリシ）が設定されている。イベント監視部１０５は、転送負荷変動通知ポリシ管理テーブル１０６を参照することで特定のイベントルールのイベントの転送負荷が転送負荷変動パターンにマッチしたことを検出すると（または、マッチすると推定すると）、当該イベントルールと転送負荷変動パターンとをイベントＴｏｐｉｃ制御部１０７へ通知する。
【０１０８】
＜ランデブーノードの選択＞
イベントＴｏｐｉｃ制御部１０７は、イベント監視部１０５から負荷変動通知を受けると、通知されたイベントルールに対応するイベントＴｏｐｉｃを新規に作成するとともにブローカノードの中からランデブーノードを選択する。以下、図１１に示した分散型イベント配信システムを例にとって説明する。
【０１０９】
図１１は本実施形態による分散型イベント配信システムにおける新規イベントＴｏｐｉｃの作成手順を説明するためのネットワーク図である。ここでは、イベントＴｏｐｉｃ「関東の天気」を担当するランデブーノードとしてブローカノードＥＢＦが選択されているものとする。さらに、ブローカノードＥＢＦの転送負荷変動通知ポリシ管理テーブル１０６には通知ポリシとして図７に示す内容が設定されているものとする。
【０１１０】
例えばブローカノードＥＢＦは、イベントＴｏｐｉｃ「関東の天気」、Ｆｉｌｔｅｒｉｎｇルール「/神奈川/横浜」にマッチするイベントの転送頻度が６０００イベント/secであると測定すると、図７におけるＩＤ＝１のエントリにヒットし、ＩＤ＝１に記載された内容がイベントＴｏｐｉｃ制御部１０７に通知される。イベントＴｏｐｉｃ制御部１０７は、通知された内容を用いてイベントＴｏｐｉｃ制御ポリシ管理テーブル１０８を検索する。図８に示す制御ポリシがイベントＴｏｐｉｃ制御ポリシ管理テーブル１０８に登録されている場合、今回の例における通知内容はＩＤ＝１のエントリとマッチするので、イベントＴｏｐｉｃ制御部１０７はイベントＴｏｐｉｃを新規に作成し、ランデブーノードを選択する。図１１に示した例では、新規イベントＴｏｐｉｃとして「横浜の天気」が作成され、当該イベントＴｏｐｉｃを担当するランデブーノードとしてブローカノードＥＢ３が選択されている。
【０１１１】
＜イベントＴｏｐｉｃ制御メッセージの送信＞
次に、ブローカノードＥＢＦのイベントＴｏｐｉｃ制御部１０７はイベントＴｏｐｉｃ制御メッセージを作成し、ＡｄｖｅｒｔｉｓｅｍｅｎｔテーブルおよびＳｕｂｓｃｒｉｐｔｉｏｎテーブルを参照してイベント監視部１０５から通知されたイベントルールに合致するＮｅｘｔホップへ当該イベントＴｏｐｉｃ制御メッセージを送信する。
【０１１２】
図１２は、本実施形態による分散型イベント配信システムにおけるイベントＴｏｐｉｃ制御メッセージの送信手順を説明するためのネットワーク図である。ただし、図１２は、図１１に示した分散型イベント配信システムの動作が完了した後の動作を示している。
【０１１３】
まず、ブローカノードＥＢＦは、図１２に「ＥＴＣ」として示されるイベントＴｏｐｉｃ制御メッセージを作成し、自身のＡｄｖｅｒｔｉｓｅｍｅｎｔテーブルＡＴＦおよびＳｕｂｓｃｒｉｐｔｉｏｎテーブルＳＴＦを参照して当該イベントＴｏｐｉｃ制御メッセージＥＴＣを送信する。ここでは、ＡｄｖｅｒｔｉｓｅｍｅｎｔテーブルＡＴＦのＩＤ＝１のエントリをヒットするので、そのＮｅｘｔホップのブローカノードＥＢＡへ転送される。ＩＤ＝２のエントリについては、イベントＴｏｐｉｃ制御メッセージに記載されたＦｉｌｔｅｒｉｎｇルールと当該エントリに登録されているＦｉｌｔｅｒｉｎｇルールとの間に重複範囲がないため、ブローカノードＥＢＢへの転送は行われない。ＳｕｂｓｃｒｉｐｔｉｏｎテーブルＳＴＦについては、ブローカノードＥＢＣへイベントＴｏｐｉｃ制御メッセージＥＴＣが転送される。
【０１１４】
ブローカノードＥＢＡおよびＥＢＣは、受信したイベントＴｏｐｉｃ制御メッセージＥＴＣをＡｄｖｅｒｔｉｓｅｍｅｎｔテーブルおよびＳｕｂｓｃｒｉｐｔｉｏｎテーブルを参照して転送する。なお、ＮｅｘｔホップがイベントＴｏｐｉｃ制御メッセージの直前の転送元と同じ場合は転送を行わない（たとえばブローカノードＥＢＣやＥＢＡからＥＢＦへのイベントＴｏｐｉｃ制御メッセージの転送は行わない）。以下同様にして、各ブローカノードのＡｄｖｅｒｔｉｓｅｍｅｎｔテーブルおよびＳｕｂｓｃｒｉｐｔｉｏｎテーブルを参照したイベントＴｏｐｉｃ制御メッセージＥＴＣの転送が繰り返され、最終的にイベントＴｏｐｉｃ制御メッセージＥＴＣは、新規に作成したイベントＴｏｐｉｃを利用したイベントの送信および受信を行う全てのＰｕｂｌｉｓｈｅｒおよびＳｕｂｓｃｒｉｂｅｒ（ここでは、ＰＵＢＸとＳＵＢＺ）へ届けられる。
【０１１５】
＜イベント配信パスの構築＞
図１３は、本実施形態による分散型イベント配信システムにおけるイベント配信パスの構築手順を説明するためのネットワーク図である。ただし、図１３は図１２に示した分散型イベント配信システムの動作が完了した後の動作を示している。
【０１１６】
イベントＴｏｐｉｃ制御メッセージＥＴＣを受信したＰｕｂｌｉｓｈｅｒＰＵＢＸ、ＳｕｂｓｃｒｉｂｅｒＳＵＢＺは、イベントＴｏｐｉｃ制御メッセージＥＴＣで通知されたランデブーノードＥＢ３を最終宛先として、新規イベントＴｏｐｉｃを記載したＡｄｖｅｒｔｉｓｅメッセージおよびＳｕｂｓｃｒｉｂｅメッセージを直接接続するブローカノードへ送信する。これにより新規イベントＴｏｐｉｃに対応するイベント配信パスが構築される。
【０１１７】
ＰｕｂｌｉｓｈｅｒＰＵＢＸは、イベントＴｏｐｉｃ制御メッセージＥＴＣを受信すると、イベントＴｏｐｉｃ制御メッセージＥＴＣに記載された新規ランデブーノードＥＢ３を最終宛先として、新規イベントＴｏｐｉｃ「横浜の天気」を記載したＡｄｖｅｒｔｉｓｅメッセージを送信する。本メッセージはブローカノードＥＢ１、ＥＢ２において転送処理が行われ（通常のＡｄｖｅｒｔｉｓｅメッセージの転送時と同様、Ａｄｖｅｒｔｉｓｅｍｅｎｔテーブルのエントリが作成される）、新規ランデブーノードＥＢ３へと到達する。  また、ＳｕｂｓｃｒｉｂｅｒＳＵＢＺも同様に、イベントＴｏｐｉｃ制御メッセージＥＴＣを受信すると、イベントＴｏｐｉｃ制御メッセージＥＴＣに記載された新規ランデブーノードＥＢ３を最終宛先として、新規イベントＴｏｐｉｃ「横浜の天気」を記載したＳｕｂｓｃｒｉｂｅメッセージを送信する。既に説明した通常のＳｕｂｓｃｒｉｂｅメッセージの転送処理と同様に、ブローカノードＥＢ４、ＥＢ３、ＥＢ２、ＥＢ１のＳｕｂｓｃｒｉｐｔｉｏｎテーブル上に新規にエントリが作成される。
【０１１８】
こうして、新規イベントＴｏｐｉｃを利用したイベントの送受信を行うＰｕｂｌｉｓｈｅｒＰＵＢＸとＳｕｂｓｃｒｉｂｅｒＳＵＢＺとを結ぶイベント配信パスが構築される。
【０１１９】
＜新規イベントＴｏｐｉｃを利用したイベントの転送＞
図１４は、本実施形態による分散型イベント配信システムにおけるイベント転送手順を説明するためのネットワーク図である。ただし、図１４は、図１３に示した分散型イベント配信システムの動作が完了した後の動作を示している。
【０１２０】
イベント配信パスの構築完了後、新規に作成したイベントＴｏｐｉｃを利用したイベントの転送が可能になる。ＰｕｂｌｉｓｈｅｒＰＵＢＸのイベントＴｏｐｉｃ制御メッセージ受信部２０４は、イベントＴｏｐｉｃ制御メッセージにより通知されたイベントルールに合致したイベントを含むＰｕｂｌｉｓｈメッセージがＰｕｂｌｉｓｈ送信部２０３から送信されると、それをインターセプトし、当該イベントのイベントＴｏｐｉｃを新規イベントＴｏｐｉｃへ書き換える。これによって、Ｐｕｂｌｉｓｈメッセージは新規イベントＴｏｐｉｃを利用してＳｕｂｓｃｒｉｂｅｒＳＵＢＺへと転送される。つまり、上述したステップにより作成された新規イベントＴｏｐｉｃに対応するイベント配信パスを利用して転送される。新規イベントＴｏｐｉｃを利用したイベントの転送は新規イベントＴｏｐｉｃを担当するランデブーノードＥＢ３を経由して転送されるため、ランデブーノード間で負荷が分散されることになる。ＳｕｂｓｃｒｉｂｅｒＳＵＢＺのイベントＴｏｐｉｃ制御メッセージ受信部３０２は、新規イベントＴｏｐｉｃを利用して受信したイベントのイベントＴｏｐｉｃを書き換え、Ｐｕｂｌｉｓｈ受信部３０３に渡す。
【０１２１】
ＰｕｂｌｉｓｈｅｒＰＵＢＸは/神奈川/横浜にマッチするイベントのイベントＴｏｐｉｃを「横浜の天気」に書き換えて送信する。当該イベントは図１３に示した動作で構築されたイベント配信パスにより新規のランデブーノードＥＢ３を経由してＳｕｂｓｃｒｉｂｅｒＳＵＢＺへと転送される。
【０１２２】
４．２）イベントＴｏｐｉｃの削除
図１５は、本実施形態による分散型イベント配信システムにおけるイベントＴｏｐｉｃの削除手順を説明するためのネットワーク図である。ただし、図１５は図１４に示した分散型イベント配信システムの動作が完了した後の動作を示している。
【０１２３】
イベントＴｏｐｉｃの削除時には、イベントＴｏｐｉｃ作成時と同様に、イベント監視部１０５は、特定のイベントルールのイベントの転送負荷が転送負荷変動パターンにマッチしたことを検出した場合またはマッチすると推定した場合に、当該イベントルールと転送負荷変動パターンをイベントＴｏｐｉｃ制御部１０７へ通知する。イベントＴｏｐｉｃ制御部１０７は、イベント監視部１０５から通知を受けると、通知されたイベントルールのターゲットイベントＴｏｐｉｃを削除対象イベントＴｏｐｉｃとして選択し、マージ先イベントＴｏｐｉｃおよびランデブーノードを選択する。
【０１２４】
次に、イベントＴｏｐｉｃ制御部１０７は、イベントＴｏｐｉｃ制御メッセージＥＴＣを作成し、ＡｄｖｅｒｔｉｓｅｍｅｎｔテーブルおよびＳｕｂｓｃｒｉｐｔｉｏｎテーブルを参照してイベント監視部１０５から通知されたイベントルールに合致するＮｅｘｔホップへイベントＴｏｐｉｃ制御メッセージＥＴＣを送信する。イベントＴｏｐｉｃ制御メッセージＥＴＣの転送を行うブローカノードは、イベントＴｏｐｉｃ制御メッセージに記載された削除対象イベントＴｏｐｉｃに合致するエントリを削除する。これにより削除対象イベントＴｏｐｉｃのイベント転送に用いられていたイベント配信パスが削除されることになる。
【０１２５】
図１５において、ブローカノードＥＢ３は、イベントＴｏｐｉｃ「横浜の天気」のイベントの転送負荷の変動がイベントＴｏｐｉｃの削除と対応付けられた転送負荷変動パターンと一致したことを検出または推定すると、図１５に示したイベントＴｏｐｉｃ制御メッセージＥＴＣを作成し、Ａｄｖｅｒｔｉｓｅｍｅｎｔテーブル、Ｓｕｂｓｃｒｉｐｔｉｏｎテーブルに登録されたイベントＴｏｐｉｃ「横浜の天気」を持つエントリのＮｅｘｔホップへ当該メッセージを送信する。
【０１２６】
イベントＴｏｐｉｃ制御メッセージＥＴＣは、それを受信したブローカノードによってＡｄｖｅｒｔｉｓｅｍｅｎｔテーブル、Ｓｕｂｓｃｒｉｐｔｉｏｎテーブルに登録されたイベントＴｏｐｉｃ「横浜の天気」を持つエントリのＮｅｘｔホップへと順次転送され、最終的にイベントＴｏｐｉｃ「横浜の天気」を用いたイベントの送受信を行うＰｕｂｌｉｓｈｅｒＰＵＢＸ、ＳｕｂｓｃｒｉｂｅｒＳＵＢＺへと届けられる。イベントＴｏｐｉｃ制御メッセージＥＴＣの転送を行った各ブローカノードＥＢ１〜ＥＢ４は転送後、イベントＴｏｐｉｃ「横浜の天気」を持つエントリをＡｄｖｅｒｔｉｓｅｍｅｎｔテーブル、Ｓｕｂｓｃｒｉｐｔｉｏｎテーブルから削除する。これにより、イベントＴｏｐｉｃ「横浜の天気」のイベントの転送に利用されていたイベント配信パスが削除される。
【０１２７】
４．３）効果
本発明の第１実施形態によれば、次のような効果を得ることができる。
【０１２８】
ａ）イベント転送の負荷の変動に柔軟に対応できる。その理由は、本実施形態による分散型イベントシステムでは、イベント転送の負荷の変動に応じてイベント配信パスの新規作成や削除が動的に行われるためである。
【０１２９】
イベント転送の負荷が増加した、または増加すると見込まれる場合、本実施形態によるブローカノードは新規にイベントＴｏｐｉｃを作成するとともに当該新規イベントＴｏｐｉｃを担当するランデブーノードを新規に選択して、ＰｕｂｌｉｓｈｅｒやＳｕｂｓｃｒｉｂｅｒへ新規にイベント配信パスを作成するよう指示する。指示を受けたＰｕｂｌｉｓｈｅｒやＳｕｂｓｃｒｉｂｅｒが新規に選択されたランデブーノードへＡｄｖｅｒｔｉｓｅメッセージやＳｕｂｓｃｒｉｂｅメッセージを送信することで新規にイベント配信パスが作成される。
【０１３０】
さらにＰｕｂｌｉｓｈｅｒやＳｕｂｓｃｒｉｂｅｒは、一部またはすべてのイベントを新規イベント配信パスを利用してイベントの送受信を行う。以上の動作により本発明の分散型イベント配信システムではイベント転送の負荷が増加した、また増加すると見込まれる場合、既存のイベント配信パスの負荷を新規に作成されたイベント配信パスへ分散することができる。
【０１３１】
また、イベントイベント転送の負荷が減少した、または減少すると見込まれる場合、本実施形態によるブローカノードは、既存のイベントＴｏｐｉｃを削除するとともに、削除後にイベントの送受信に利用すべきマージ先イベントＴｏｐｉｃを既存のイベントＴｏｐｉｃから選択して、ＰｕｂｌｉｓｈｅｒやＳｕｂｓｃｒｉｂｅｒへ削除したイベントＴｏｐｉｃに対応するイベント配信パスを削除するよう指示する。指示を受けたＰｕｂｌｉｓｈｅｒやＳｕｂｓｃｒｉｂｅｒは、ＡｄｖｅｒｔｉｓｅメッセージやＳｕｂｓｃｒｉｂｅメッセージを送信することでイベント配信パスが削除される。これにより本実施形態による分散型イベント配信システムでは、イベント転送の負荷が減少した、または減少すると見込まれる場合、既存のイベント配信パスを削除してイベント配信パス維持に伴うオーバヘッドを削減することができる。
【０１３２】
また、ＰｕｂｌｉｓｈｅｒやＳｕｂｓｃｒｉｂｅｒはイベント配信パス削除後、削除したイベントＴｏｐｉｃを利用して送受信していたイベントをマージ先イベントＴｏｐｉｃを利用して送受信する。これによりイベント配信パス削除後もイベントの送受信を行うことができる。
【０１３３】
ｂ）同一のイベントＴｏｐｉｃにより送受信されているイベントの中から転送負荷が増加した、または増加すると見込まれるイベントのみを別のイベント配信パスを利用して送受信できる。その理由は、本実施形態によるブローカノードにはイベントＴｏｐｉｃに加えＦｉｌｔｅｒｉｎｇルールやＰｕｂｌｉｓｈメッセージの属性なども条件として追加可能なイベントルールが設定されており、ブローカノード内のイベント監視部がイベントルール毎に転送負荷の監視を行うためである。
【０１３４】
ブローカノードは転送負荷が増加した、または増加すると見込まれるイベントルールに対応する新規イベントＴｏｐｉｃを作成すると共に新規ランデブーノードを選択して、これら新規イベントＴｏｐｉｃと新規ランデブーノードと共にイベントルールをＰｕｂｌｉｓｈｅｒ、Ｓｕｂｓｃｒｉｂｅｒへ通知して新規イベント配信パスを作成するよう指示する。指示を受けたＰｕｂｌｉｓｈｅｒ、Ｓｕｂｓｃｒｉｂｅｒは新規イベント配信パス作成後、通知されたイベントルールにマッチするイベントを新規イベント配信パスを利用して送受信する。これにより同一のイベントＴｏｐｉｃにより送受信されているイベントの中から転送負荷が増加した、または増加すると見込まれるイベントのみを別のイベント配信パスを利用して送受信できる。
【０１３５】
本実施形態による方式は、単純負荷分散方式、すなわち同一イベントＴｏｐｉｃのイベント送受信に利用するイベント配信パスを複数用意し、ラウンドロビン等の方法でイベント配信パスを使い分けて負荷分散を行う方式と比べて、効率がよい。
【０１３６】
例えば、イベントＴｏｐｉｃ「Ａ」のイベントの送受信に利用するイベント配信パスを考える。単純負荷分散方式では「Ａ」のイベントの送受信を行う全てのＳｕｂｓｃｒｉｂｅｒ、Ｐｕｂｌｉｓｈｅｒが複数のイベント配信パス全てに接続する必要がある。つまり、「Ａ」の送受信を行う全てのＳｕｂｓｃｒｉｂｅｒ、Ｐｕｂｌｉｓｈｅｒが複数のランデブーノードに対してＳｕｂｓｃｒｉｂｅメッセージ、Ａｄｖｅｒｔｉｓｅメッセージを送信する必要がある。
【０１３７】
これに対して、本実施形態によれば、「Ａ」のイベントの送受信を行うＳｕｂｓｃｒｉｂｅｒ、Ｐｕｂｌｉｓｈｅｒのうち、特に転送負荷が増加した、または増加すると見込まれるイベントルールに対応するイベントを送受信するＳｕｂｓｃｒｉｂｅｒ、Ｐｕｂｌｉｓｈｅｒのみが新規に作成されたイベント配信パスに接続する。このため、イベント配信パスを複数用意して負荷分散を行う場合、本実施形態では単純負荷分散方式と比較してＳｕｂｓｃｒｉｂｅ、Ａｄｖｅｒｔｉｓｅメッセージの転送に伴うオーバヘッドを低くすることができる。
【０１３８】
ｃ）ブローカノードが個々のＰｕｂｌｉｓｈｅｒやＳｕｂｓｃｒｉｂｅｒを把握することなくイベント配信パスの新規作成や削除を行うことができる。その理由は、ブローカノードにおいてイベントＴｏｐｉｃ制御メッセージの送信、転送がＡｄｖｅｒｔｉｓｅｍｅｎｔテーブル、Ｓｕｂｓｃｒｉｐｔｉｏｎテーブルを参照して行われるためである。Ａｄｖｅｒｔｉｓｅｍｅｎｔテーブル、Ｓｕｂｓｃｒｉｐｔｉｏｎテーブルには、イベントＴｏｐｉｃ、Ｆｉｌｔｅｒｉｎｇルール毎に当該イベントＴｏｐｉｃおよびＦｉｌｔｅｒｉｎｇルールにマッチするイベントの送受信を行うＰｕｂｌｉｓｈｅｒ、Ｓｕｂｓｃｒｉｂｅｒへの経路のＮｅｘｔホップが登録されている。このため、ブローカノードがイベントＴｏｐｉｃ制御メッセージを、イベントＴｏｐｉｃ制御メッセージのイベントルールにマッチするＡｄｖｅｒｔｉｓｅｍｅｎｔテーブル、ＳｕｂｓｃｒｉｐｔｉｏｎテーブルのＮｅｘｔホップへ転送することにより、各ブローカノードが個々のＰｕｂｌｉｓｈｅｒやＳｕｂｓｃｒｉｂｅｒを把握することなく、イベントＴｏｐｉｃ制御メッセージをＰｕｂｌｉｓｈｅｒ、Ｓｕｂｓｃｒｉｂｅｒへ届けることが可能になる。
【０１３９】
極めて多数の（例えば１０００万台の）ＰｕｂｌｉｓｈｅｒやＳｕｂｓｃｒｉｂｅｒが存在する場合やＰｕｂｌｉｓｈｅｒやＳｕｂｓｃｒｉｂｅｒのイベント配信パスへの接続や切断が頻繁に行われる場合において、ブローカノードが個々のＰｕｂｌｉｓｈｅｒやＳｕｂｓｃｒｉｂｅｒのＩＰアドレスやイベント配信パスへの参加状態を常時把握することは非現実的であるが、本実施形態によるブローカノードはこうしたケースにも対応できる。
【０１４０】
ｄ）イベント配信パス削除時のＡｄｖｅｒｔｉｓｅｍｅｎｔ、Ｓｕｂｓｃｒｉｐｔｉｏｎテーブルのエントリ削除を迅速に行うことができる。その理由はブローカノードが削除対象イベントＴｏｐｉｃのイベントの送受信を今後行わない旨記載されたＡｄｖｅｒｔｉｓｅメッセージおよびＳｕｂｓｃｒｉｂｅメッセージがＰｕｂｌｉｓｈｅｒやＳｕｂｓｃｒｉｂｅｒから送信されることを待つことなく、イベントＴｏｐｉｃの削除を通知するイベントＴｏｐｉｃ制御メッセージの受信をトリガとして、削除対象イベントＴｏｐｉｃを含むエントリをＡｄｖｅｒｔｉｓｅｍｅｎｔテーブル、Ｓｕｂｓｃｒｉｐｔｉｏｎテーブルから削除することができるためである。
【０１４１】
５．第２実施形態
本発明の第２実施形態は、その基本的構成は上記第１実施形態と同様であるが、イベントＴｏｐｉｃ制御メッセージの到達範囲を、新規イベントＴｏｐｉｃ作成を行ったブローカノードの近傍に制限できる点が第１実施形態と異なっている。まず、この点について、図１６〜図１８を用いて説明する。
【０１４２】
図１６はイベントＴｏｐｉｃ「関東の天気」のイベント配信パスを示すネットワーク図である。上述したように、「関東の天気」を担当するランデブーノードから複数のＰｕｂｌｉｓｈｅｒおよびＳｕｂｓｃｒｉｂｅｒへのイベント配信パス４０１が設定されている。
【０１４３】
図１７は、本発明の第１実施形態におけるイベントＴｏｐｉｃ「横浜の天気」のイベント配信パスを示すネットワーク図である。第１実施形態によれば、イベントＴｏｐｉｃ「関東の天気」を担当するランデブーノードがイベントＴｏｐｉｃ「横浜の天気」の新規作成を行った場合、イベントＴｏｐｉｃ制御メッセージ到達範囲４０３は、イベント配信パスの末端、すなわち全てのＰｕｂｌｉｓｈｅｒやＳｕｂｓｃｒｉｂｅｒまで至る。言い換えれば、末端から新たに新規イベントＴｏｐｉｃ「横浜の天気」のイベント配信パスが構築される。
【０１４４】
図１８は、本発明の第２実施形態におけるイベントＴｏｐｉｃ「横浜の天気」のイベント配信パスを示すネットワーク図である。上述した第１実施形態の場合とは異なり、第２実施形態では、イベントＴｏｐｉｃ制御メッセージの到達範囲５０１がイベントＴｏｐｉｃ「関東の天気」を担当するランデブーノードの近傍に限定される。すなわち、新規イベントＴｏｐｉｃ「横浜の天気」のイベント配信パスは、ＰｕｂｌｉｓｈｅｒやＳｕｂｓｃｒｉｂｅｒの末端付近ではイベントＴｏｐｉｃ「関東の天気」と共通の経路が利用され、異なる経路が利用されるのはイベントＴｏｐｉｃ「関東の天気」を担当するランデブーノードの近傍のみである。
【０１４５】
このように第２実施形態では、イベントＴｏｐｉｃ制御メッセージの到達範囲を、新規イベントＴｏｐｉｃ作成を行ったブローカノードの近傍に制限する。これにより以下の効果を期待できる。
【０１４６】
（１）末端までイベントＴｏｐｉｃ制御メッセージが届くのを待つ必要がないため、新規イベントＴｏｐｉｃ作成時に迅速にイベント配信パスを構築することが可能になる。
（２）イベントＴｏｐｉｃ制御メッセージ転送に伴うオーバヘッドを抑制することができる。末端付近ではイベントＴｏｐｉｃ制御メッセージの転送が行われないため、末端付近でのイベントＴｏｐｉｃ制御メッセージの転送に伴うネットワーク帯域の消費やブローカノードの計算資源消費が抑制される。
【０１４７】
（３）ブローカノードにおけるＡｄｖｅｒｔｉｓｅｍｅｎｔテーブルおよびＳｕｂｓｃｒｉｐｔｉｏｎテーブルのサイズを抑制できる。末端付近でのブローカノードでは新規イベントＴｏｐｉｃ作成に伴うＡｄｖｅｒｔｉｓｅｍｅｎｔテーブルおよびＳｕｂｓｃｒｉｐｔｉｏｎテーブルへのエントリ追加が行われないため、テーブルサイズを抑制することができ、これによりテーブル検索時間の短縮が期待できる。
【０１４８】
以下、本発明の第２実施形態によるイベントＴｏｐｉｃ制御システムについて詳細に説明する。
【０１４９】
５．１）ブローカノードの構成および動作
図１９は本発明の第２実施形態によるイベントＴｏｐｉｃ制御装置を含むブローカノードの機能的構成を示すブロック図、図２０はイベントＴｏｐｉｃ制御ポリシ管理テーブルに設定されている制御ポリシの一例を示す図である。なお、図５に示す第１実施形態におけるブローカノードと同じ機能を有するブロックには同一の参照番号を付して説明は省略する。
【０１５０】
図１９において、ブローカノードＥＢは、機能的に、Ｓｕｂｓｃｒｉｐｔｉｏｎテーブル１０１、Ａｄｖｅｒｔｉｓｅｍｅｎｔテーブル１０２、ルーティングテーブル管理部１０３およびイベント転送部１０４を有し、さらに、イベント監視部１０５および転送負荷変動通知ポリシ管理テーブル１０６と、イベントＴｏｐｉｃ制御部６０１およびイベントＴｏｐｉｃ制御ポリシ管理テーブル６０２と、イベントＴｏｐｉｃ制御メッセージ受信部６０３、Ｓｕｂｓｃｒｉｂｅ送信部６０４およびＡｄｖｅｒｔｉｓｅ送信部６０５とを有する。イベントＴｏｐｉｃ制御部６０１は、後述するように、イベントＴｏｐｉｃ制御メッセージの到達範囲を設定／変更するためのＴＴＬ制御部６０１ａを機能的に含む。
【０１５１】
本実施形態におけるブローカノードＥＢと図５に示す第１実施形態におけるブローカノードＥＢとは、イベントＴｏｐｉｃ制御部６０１およびイベントＴｏｐｉｃ制御ポリシ管理テーブル６０２の機能が異なっており、さらにイベントＴｏｐｉｃ制御メッセージ受信部６０３、Ｓｕｂｓｃｒｉｂｅ送信部６０４およびＡｄｖｅｒｔｉｓｅ送信部６０５を有する点が異なっている。以下、この異なる点について詳細に説明する。
【０１５２】
＜イベントＴｏｐｉｃ制御部＞
図１９におけるイベントＴｏｐｉｃ制御部６０１は、イベントＴｏｐｉｃ制御メッセージに対して、その到達範囲を任意に制御する到達範囲制御機能としてＴＴＬ制御部６０１ａを有する。イベントＴｏｐｉｃ制御メッセージの到達範囲は次のようにして任意に制御されうる。たとえば、イベントＴｏｐｉｃ制御メッセージを作成するノードでＴＴＬ（Ｔｉｍｅ  Ｔｏ  Ｌｉｖｅ）値を設定し、他のブローカノードから受信したイベントＴｏｐｉｃ制御メッセージを転送する際にそのＴＴＬ値を１だけ減じ、ＴＴＬ値がゼロでなければ転送し、ＴＴＬ値がゼロになれば当該イベントＴｏｐｉｃ制御メッセージを受信して転送しない、というシーケンスを実行する。
【０１５３】
図２０に示すように、イベントＴｏｐｉｃ制御部６０１に設定される制御ポリシは、図８に示す第１実施形態の制御ポリシを拡張したものである。すなわち、イベントルールと転送負荷変動パターンに対応する動作内容の一部として、イベントＴｏｐｉｃ制御メッセージへ設定するＴＴＬ値が設定される。自ノードの負荷が大きい場合にはより広い範囲で新規イベント配信パスの構築を実施する、といったポリシで到達範囲を制御する。例えば、同一のイベントルールについて、転送頻度が５０００イベント/sec以上の場合はＴＴＬ＝５に設定し、１００００イベント/sec以上の場合はＴＴＬ＝７に設定するなどである。
【０１５４】
また、他のブローカノードから受信したイベントＴｏｐｉｃ制御メッセージを転送する際のＴＴＬの計算も自身の負荷に応じて柔軟に変更することができる。基本的には、転送の際に１減じる処理を行うが、たとえば自身の負荷がきわめて低い場合には転送の際に５減じるなどしてイベントＴｏｐｉｃ制御メッセージ転送範囲（すなわち新規イベント配信パスの構築範囲）を自身の近傍に制限することができる。逆に、自身の負荷が大きい場合には、ＴＴＬを逆に１増やすなどして転送範囲を拡大することも可能である。このようにイベントＴｏｐｉｃ制御メッセージ転送時のＴＴＬ計算方法を転送するブローカノードの負荷に応じて変更することにより、新規イベントＴｏｐｉｃの作成を行ったブローカノードから離れた場所の負荷状況をも反映してイベント配信パスの構築の範囲を制御することできる。
【０１５５】
本実施形態におけるイベントＴｏｐｉｃ制御部６０１は、他のブローカノードから受信したイベントＴｏｐｉｃ制御メッセージを転送する際にＴＴＬを１だけデクリメントするが、そのＴＴＬ値がゼロになると、イベントＴｏｐｉｃ制御メッセージ受信部６０３へイベントＴｏｐｉｃ制御メッセージの受信処理を行うよう指示する。
【０１５６】
＜イベントＴｏｐｉｃ制御メッセージ受信部＞
イベントＴｏｐｉｃ制御メッセージ受信部６０３は、イベントＴｏｐｉｃ制御部６０１からの指示を受けて、図９および図１０に示す第１実施形態におけるＰｕｂｌｉｓｈｅｒやＳｕｂｓｃｒｉｂｅｒのイベントＴｏｐｉｃ制御メッセージ受信部（２０４、３０２）と同様の受信処理を行う。具体的には、次の通りである。
【０１５７】
１）隣接するブローカノードがＡｄｖｅｒｔｉｓｅｍｅｎｔテーブルを参照して自ノードへイベントＴｏｐｉｃ制御メッセージを転送した場合には、イベントＴｏｐｉｃ制御メッセージ受信部６０３は第１実施形態におけるＰｕｂｌｉｓｈｅｒのイベントＴｏｐｉｃ制御メッセージ受信部２０４と同様の処理を行う。すなわち、イベントＴｏｐｉｃ制御メッセージ受信部６０３は、Ａｄｖｅｒｔｉｓｅ送信部６０５に対して、イベントＴｏｐｉｃ制御メッセージで通知された新規イベントＴｏｐｉｃを記載したＡｄｖｅｒｔｉｓｅメッセージを、同じくイベントＴｏｐｉｃ制御メッセージで通知された新規ランデブーノードを最終宛先として送信するよう指示する。
【０１５８】
また、自ノードがＰｕｂｌｉｓｈメッセージを転送する際に、イベントＴｏｐｉｃ制御メッセージに記載されたイベントルールを参照し、当該イベントルールに合致するイベントを含んだＰｕｂｌｉｓｈメッセージをインターセプトする。そして、当該ＰｕｂｌｉｓｈメッセージのイベントＴｏｐｉｃをイベントＴｏｐｉｃ制御メッセージで通知された新規イベントＴｏｐｉｃに書き換える。こうして、当該イベントは新規イベントＴｏｐｉｃを利用して配信される。すなわち新規イベントＴｏｐｉｃ作成時に作成された新規のイベント配信パスを利用して配信される。
【０１５９】
２）隣接するブローカノードがＳｕｂｓｃｒｉｐｔｉｏｎテーブルを参照して自ノードへイベントＴｏｐｉｃ制御メッセージを転送した場合には、イベントＴｏｐｉｃ制御メッセージ受信部６０３は第１実施形態におけるＳｕｂｓｃｒｉｂｅｒのイベントＴｏｐｉｃ制御メッセージ受信部３０２と同様の処理を行う。すなわち、イベントＴｏｐｉｃ制御メッセージ受信部６０３は、Ｓｕｂｓｃｒｉｂｅ送信部６０４に対して、イベントＴｏｐｉｃ制御メッセージで通知された新規イベントＴｏｐｉｃを記載したＳｕｂｓｃｒｉｂｅメッセージを、同じくイベントＴｏｐｉｃ制御メッセージで通知された新規ランデブーノードを最終宛先として送信するよう指示する。
【０１６０】
また、受信したイベントＴｏｐｉｃ制御メッセージに記載された新規イベントＴｏｐｉｃを参照し、新規イベントＴｏｐｉｃのイベントを含むＰｕｂｌｉｓｈメッセージをインターセプトする。そして、当該ＰｕｂｌｉｓｈメッセージのイベントＴｏｐｉｃをイベントルールに記載されたターゲットイベントＴｏｐｉｃに書き換える。書き換え後、当該イベントはターゲットイベントＴｏｐｉｃを利用して配信される。すなわち、新規イベントＴｏｐｉｃ作成以前から存在したターゲットイベントＴｏｐｉｃのイベントを配信するためのイベント配信パスを利用して配信される。
【０１６１】
＜Ｓｕｂｓｃｒｉｂｅ送信部＞
Ｓｕｂｓｃｒｉｂｅ送信部６０４は、イベントＴｏｐｉｃ制御メッセージ受信部６０３からの指示を受けてイベントＴｏｐｉｃ制御メッセージで通知された新規イベントＴｏｐｉｃを記載したＳｕｂｓｃｒｉｂｅメッセージを、同じくイベントＴｏｐｉｃ制御メッセージで通知された新規ランデブーノードを最終宛先として送信する。
【０１６２】
＜Ａｄｖｅｒｔｉｓｅ送信部＞
Ａｄｖｅｒｔｉｓｅ送信部６０５は、イベントＴｏｐｉｃ制御メッセージ受信部６０３からの指示を受けてイベントＴｏｐｉｃ制御メッセージで通知された新規イベントＴｏｐｉｃを記載したＡｄｖｅｒｔｉｓｅメッセージを、同じくイベントＴｏｐｉｃ制御メッセージで通知された新規ランデブーノードを最終宛先として送信する。
【０１６３】
なお、ルーティングテーブル管理部１０３、イベント転送部１０４、イベント監視部１０５、イベントＴｏｐｉｃ制御部６０１、イベントＴｏｐｉｃ制御メッセージ受信部６０３、Ｓｕｂｓｃｒｉｂｅ送信部６０４およびＡｄｖｅｒｔｉｓｅ送信部６０５の上述した機能は、ＣＰＵ等のプログラム制御プロセッサ上でプログラムを実行することにより実現することもできる。
【０１６４】
５．２）効果
本発明の第２実施形態によれば、既に述べた第１実施形態による効果に加えて、次のような効果を得ることができる。
【０１６５】
ａ）イベント配信パスの新規作成、削除に伴うオーバヘッドを抑制できる。具体的には次の通りである。イベントＴｏｐｉｃ制御メッセージを送信するブローカノードは、イベントＴｏｐｉｃ制御メッセージのＴＴＬを設定することにより、その到達範囲を任意に制御することができる。さらに、転送時にイベントＴｏｐｉｃ制御メッセージのＴＴＬが０となったブローカノードは、Ｐｕｂｌｉｓｈｅｒ、Ｓｕｂｓｃｒｉｂｅｒの代わりにＡｄｖｅｒｔｉｓｅメッセージ、Ｓｕｂｓｃｒｉｂｅメッセージの送信を行うことができる。これにより、イベントＴｏｐｉｃ制御メッセージをイベント配信パスの末端（すなわちＰｕｂｌｉｓｈｅｒ、Ｓｕｂｓｃｒｉｅｂｒ）まで転送する必要がなくなり、イベント配信パスの新規作成、削除に伴うオーバヘッドを抑制することが可能になる。
【０１６６】
ｂ）イベント転送の負荷の変動に応じてイベント配信パスを新規作成する範囲を制御できる。なぜならば、イベントＴｏｐｉｃ制御メッセージを送信または転送するブローカノードがイベントＴｏｐｉｃ制御メッセージのＴＴＬの値をイベントの転送負荷の変動に応じて変更することができるからである。例えば検出した負荷の増加幅が大きいほど、ＴＴＬに大きな値を設定することでイベントＴｏｐｉｃ制御メッセージを広範囲に到達させ、より広い範囲でイベント配信パスが新規に作成されるようにするといったことが可能になる。
【０１６７】
以上、実施形態および実施例を参照して本願発明を説明したが、本願発明は上記実施形態および実施例に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。
【０１６８】
この出願は、２００９年２月５日に出願された日本特許出願２００９−２４５９０を基礎とする優先権を主張し、その開示の全てをここに取り込む。
【産業上の利用可能性】
【０１６９】
本発明はブローカノード・ベースの分散型イベント配信システム一般に適用可能である。
【符号の説明】
【０１７０】
１０１  Ｓｕｂｓｃｒｉｐｔｉｏｎテーブル
１０２  Ａｄｖｅｒｔｉｓｅｍｅｎｔテーブル
１０３  ルーティングテーブル管理部
１０４  イベント転送部
１０５  イベント監視部
１０６  転送負荷変動通知ポリシ管理テーブル
１０７  イベントＴｏｐｉｃ制御部
１０８  イベントＴｏｐｉｃ制御ポリシ管理テーブル
２０１  Ａｄｖｅｒｔｉｓｅ送信部
２０２  イベント発生部
２０３  Ｐｕｂｌｉｓｈ送信部
２０４  イベントＴｏｐｉｃ制御メッセージ受信部
３０１  Ｓｕｂｓｃｒｉｂｅ送信部
３０２  イベントＴｏｐｉｃ制御メッセージ受信部
３０３  Ｐｕｂｌｉｓｈ受信部
４０１  イベント配信パス
４０２  イベントＴｏｐｉｃ制御メッセージ
４０３  イベントＴｏｐｉｃ制御メッセージ到達範囲
５０１  イベントＴｏｐｉｃ制御メッセージ到達範囲
６０１  イベントＴｏｐｉｃ制御部
６０２  イベントＴｏｐｉｃ制御ポリシ管理テーブル
６０３  イベントＴｏｐｉｃ制御メッセージ受信部
６０４  Ｓｕｂｓｃｒｉｂｅ送信部
６０５  Ａｄｖｅｒｔｉｓｅ送信部
ＰＵＢ  パブリッシャ（Ｐｕｂｌｉｓｈｅｒ）
ＳＵＢ  サブスクライバ（Ｓｕｂｓｃｒｉｂｅｒ）
ＥＢ  ブローカノード（Ｅｖｅｎｔ  Ｂｒｏｋｅｒ）
【図１】
2010090027.tif 000003
【図２】
2010090027.tif 000004
【図３】
2010090027.tif 000005
【図４】
2010090027.tif 000006
【図５】
2010090027.tif 000007
【図６】
2010090027.tif 000008
【図７】
2010090027.tif 000009
【図８】
2010090027.tif 000010
【図９】
2010090027.tif 000011
【図１０】
2010090027.tif 000012
【図１１】
2010090027.tif 000013
【図１２】
2010090027.tif 000014
【図１３】
2010090027.tif 000015
【図１４】
2010090027.tif 000016
【図１５】
2010090027.tif 000017
【図１６】
2010090027.tif 000018
【図１７】
2010090027.tif 000019
【図１８】
2010090027.tif 000020
【図１９】
2010090027.tif 000021
【図２０】
2010090027.tif 000022
【国際調査報告】
2010090027.tif 000023
2010090027.tif 000024