JP4356693B2 - メッセージ配信装置及びその方法並びにシステム及びプログラム - Google Patents

Description

本発明はメッセージ配信装置及びその方法並びにシステム及びプログラムに関し、特にある通信ノードから通信網を介して複数の関連する通信ノードに対してメッセージを配信するメッセージ配信方式に関するものである。

サン（Ｓｕｎ）社が仕様を定めているジャバメッセージングサービス（Ｊａｖａ（Ｒ）Ｍｅｓｓａｇｉｎｇ Ｓｅｒｖｉｃｅ：ＪＭＳ；ｈｔｔｐ：／／ｊａｖａ．ｓｕｎ．ｃｏｍ／ｐｒｏｄｕｃｔｓ／ｊｍｓ／）や、その一実装であるソフトワイアード（Ｓｏｆｔｗｉｒｅｄ）社のアイバス（ｉＢｕｓ：ｈｔｔｐ：／／ｗｗｗ．ｓｏｆｔｗｉｒｅｄ−ｉｎｃ．ｃｏｍ）／などのメッセージ指向ミドルウェアは、メッセージにトピックと呼ぶキーワードをつけるようになっている。メッセージ送信者は、メッセージルータに対して、このトピック付メッセージを送信する。
例えば、図２１を参照すると、従来のメッセージ配信システムの例が示されている。受信者の通信ノード（以下、単にノードと称す）５００，５０１がネットワーク１００を介してメッセージルータ８００に接続されており、ＤＢ（データベース）９００はメッセージルータ８００により管理される。
図２１において、受信者ノード５００は予め自分が受信したいトピックをメッセージルータ８００に登録しておく。トピック付メッセージは、メッセージ受信部２１０で受信され、スプリッタ２２０に渡される。スプリッタ２２０はメッセージをヘッダとペイロードとに分割し、前者をヘッダ解釈部２３０へ、後者を合成部２６０へ、それぞれ送信する。
ヘッダ解釈部２３０はヘッダを解釈し、このメッセージが登録要求メッセージであることを把握すると共に、トピックと受信者ノード５００のＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）を抽出する。また、ヘッダ解釈部２３０はＤＢ（データベース）書込部２９０を利用して、データベース９００にトピックをキーワードとし、受信者のＵＲＬ等の位置情報のリストを表として格納しておく。ヘッダ解釈部２３０はデータベース９００への登録に成功すると、応答メッセージメ用ヘッダを作成し、合成部２６０に渡す。
合成部２６０はヘッダ解釈部２３０から受け取ったヘッダと、スプリッタ２２０から受け取ったペイロードとを合わせて、一つの応答メッセージとする。合成部２６０はメッセージ転送部２７０を用いてノード５００に対して登録成功応答メッセージを発行する。
ノード５００のメッセージ受信部５２０がこの登録成功応答メッセージを受信して処理部５１０に渡す。これにより、処理部５１０は登録成功を確認することになる。なお、ノード５０１は送信者ノードである。
メッセージルータ８００は、メッセージ受信部２１０により、送信者ノード５０１からメッセージを受信したとき、メッセージはスプリッタ２２０に渡される。スプリッタ２２０はメッセージをヘッダとペイロードに分割し、前者をヘッダ解釈部２３０に、また後者を合成部２６０に、それぞれ送信する。ヘッダ解釈部２３０はヘッダを解釈し、このメッセージがルーティング対象メッセージであることを把握すると共に、送信対象のトピックを抽出する。ヘッダ解釈部２３０はＤＢ読出部２４０を利用して、メッセージのトピックでデータベース９００を検索し、その結果得られたノードの位置情報、例えばノード５００等のＵＲＬの集合を得る。
ヘッダ解釈部２３０はこの得られた位置情報のリストに対して、それぞれヘッダを作成し、合成部２６０に渡す。合成部２６０はヘッダ解釈部２３０から受け取ったヘッダ各々に対して、スプリッタ２２０から受け取ったペイロードをコピーしてメッセージを作成し、メッセージ転送部２７０に渡す。メッセージ転送部２７０はノード５０１などの受信者ノードにメッセージを送信する。送信されたメッセージは、例えばノード５００のメッセージ受信部５２０で受信され、処理部５１０に渡される。処理部５１０は受け取ったメッセージに応じた処理を行う。
例えば、営業部所属メンバへのメッセージをトピック”Ｓａｌｅｓ Ｄｉｖ”とする。また、営業１課のトピックを”１ｓｔ ｓｅｃ”とする。トピック”Ｓａｌｅｓ Ｄｉｖ”のメッセージは、トピック”Ｓａｌｅｓ Ｄｉｖ”を欲する受信者にも送信されるべきである。ＪＭＳのように階層的なトピック構造を有しない場合、営業１課の所属メンバは”Ｓａｌｅｓ Ｄｉｖ”と”１ｓｔ ｓｅｃ”の両トピックに受信者を登録する必要がある。
また、複数の受信者に渡るメッセージをＪＭＳでは実現することができないため、あるメッセージを受信したノードがさらに他のノードにメッセージを転送することが困難である。例えば、あるサービス提供ノードと認証ノードとが存在する場合に、認証ノードが認証したメッセージのみを、サービス提供ノードのみにに流す必要がある。しかし、サービス提供ノードが設定したトピックを使ってメッセージを流すと、認証ノードの有無にかかわらずサービス提供ノードにメッセージが流れてしまい、認証不可のメッセージのサービスも利用が可能となってしまうことになる。このように、認証サーバのような、例えば、ある処理の前に認証処理を行うフロント処理サービスを追加することが困難となる。
「エックスラング：ウェブサービシズフォービジネスプロセスデザイン（ＸＬＡＮＧ：Ｗｅｂ Ｓｅｒｖｉｃｅｓ ｆｏｒ Ｂｕｓｉｎｅｓｓ Ｐｒｏｃｅｓｓ Ｄｅｓｉｇｎ）」で定義されているＸＬＡＮＧでは、ウェブサービスで利用されるシンプルオブジェクトアクセスプロトコル（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ−Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ：ＳＯＡＰ）のヘッダにルーティング情報を導入することで、サービス間の連携を可能としている。サービス提供者はＳＯＡＰメッセージのペイロードをみてサービスを提供する。また、ヘッダをみて、メッセージの次の転送先を決定する。ＸＬＡＮＧでは、転送先一つ一つをヘッダに明示する。そのために、サービス連携ノードが多数存在する場合、ヘッダのサイズが大きくなってしまい効率的ではない。
メッセージ指向ミドルウェアで構築されたシステムやクライアント−サーバシステムでは、サービス提供者がインタネット中に存在する場合、不特定のサービス利用者からアクセスされる。そのため、悪意を持つサービス利用者が一度に多数回、サービス提供者にアクセスすることで、他のサービス利用者がサービスを利用することを妨害するサービス拒否攻撃が知られている。
イングレスフィルタリング技術は、サービス利用者が限定される場合、そのサービス利用者以外の送信者アドレスを有するパケットを、サービス提供者に届く前に、物理的・論理的にフィルタリングすることで、サービス拒否攻撃を防止するようになっている。しかしながら、サービス利用者が特定できない場合、イングレスフィルタリングを利用することはできない。
特開２００１−２７３２０９号公報に開示の発明では、サービス提供者の接続要求数に制限を設けて、それを越す接続要求は拒否をする。この場合、悪意のあるサービス利用者が制限数を超える要求をしている場合、正規のサービス利用者がサービスを利用することは困難である。
特開２００２−１５８６９９号公報に開示の発明では、送信元で安全性を保障する印をメッセージに添付し、サービス提供側は安全性に応じて優先度を付けて、サービスを提供するものであり、この発明では、送信元に安全性を保障する印を付ける機構が備わっていることが必要である。これは、サービス利用者が特定のＩＳＰ（Ｉｎｔｅｒｎｅｔ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ）を通じてアクセスする場合には、実現できるが、一般的にインターネット利用者は必ずしも安全性を示す印を付ける機構を有するＩＳＰを通してアクセスするとは限らず、実現が困難である。
分散サービス拒否攻撃とは、悪意を有するノードが直接サービス提供者を攻撃するのではなく、他の悪意のないノードを利用して、サービス提供者を攻撃することをいう。悪意を有するノードに利用されるノードを踏み台ノードと呼ぶ。特開２００２−１５８６６０号公報に開示の発明では、踏み台ノードにそれぞれ攻撃遮断機能を設置するものであり、攻撃検出機能が分散サービス拒否攻撃を検出すると、攻撃遮断機能に命じて、踏み台ノードからサービス提供者へのアクセスを拒絶する。しかし、踏み台ノードにされるノードを予め特定することは困難であるので、攻撃遮断機能を設置することは現実的でない。
よって、従来の技術には次のような問題点がある。第１の問題点は、インターネットのように、サービスや情報を提供するサービス提供者であるノードが多数存在するシステムにおいて、効率的にノードが協調するメッセージ指向ミドルウェアがないことである。例えば、既存のサービス提供ノードに手を加える必要なく、認証サービス提供ノードを設け、サービス提供ノードへのアクセスを制限する方法を実現することは困難である。
その理由は、従来のメッセージ指向ミドルウェアでは、該当する受信対象者にメッセージを同時に配信していたためである。そのため、認証サーバで認証が成功したら、サービス提供ノードでサービスを提供するように順序がある処理を実現することができなかった。
第２の問題点は、メッセージが有するトピックに対して、それを包含するトピックに興味があるノードに対してメッセージ送信をすることが困難であることである。トピック”Ｓａｌｅｓ Ｄｉｖ”を有するメッセージは、”Ｓａｌｅｓ Ｄｉｖ”をトピックとして登録したノードに送信するだけではなく、”Ｓａｌｅｓ Ｄｉｖ”に包含されるトピック”１ｓｔ ｓｅｃ”で登録したノードにも送信すべきである。
このようなことが困難である理由は、トピックが包含関係を有しないことである。そのため、”Ｓａｌｅｓ Ｄｉｖ”が”１ｓｔ ｓｅｃ”を包含するトピックであることを指定できない。
第３の問題点は、インターネットなど開かれたネットワークでは、サービス提供者がサービス拒否攻撃をうける可能性がある。その理由は、サービス提供者であるノードは、インターネットに接続されている可能性があり、その場合、あらゆるノードからもアクセス可能であるためである。そのため、悪意を有するノードがサービス提供者に対して過大な負荷をかけて、正常なサービス提供を困難にさせる。
第４の問題点は、インターネットなど開かれたネットワークでは、サービス提供者が分散サービス拒否攻撃を受ける可能性がある。その理由は、サービス利用者であるノードは、あらゆるノードからもアクセス可能であるためである。そのため、悪意を有するノードがサービス利用者を使い、サービス提供者に対して過大な負荷をかけて、正常なサービス提供を困難にさせる。

本発明の第１の目的は、メッセージ配送手順を処理可能なメッセージ指向ミドルウェアを有するメッセージ配信装置及びその方法並びにシステム及びプログラムを提供することである。
本発明の第２の目的は、包含関係を有するトピックによる配信先の指定が可能なメッセージ指向ミドルウェアを有するメッセージ配信装置及びその方法並びにシステム及びプログラムを提供することである。
本発明の第３の目的は、インターネット環境など開かれたネットワーク環境においても、サービス提供者に対するサービス拒否攻撃を防止することが可能なメッセージ配信装置及びその方法並びにシステム及びプログラムを提供することである。
本発明の第４の目的は、インターネット環境など開かれたネットワーク環境においても、サービス提供者に対する分散サービス拒否攻撃を防止するが可能なメッセージ配信装置及びその方法並びにシステム及びプログラムを提供することである。
このような目的を達成するために、本発明によるメッセージ配信装置は、メッセージをネットワークに接続されたノードへ配信するメッセージ配信装置であって、メッセージ配信先のノード情報が予め定められた関係に従ったツリーデータ構造として格納されたデータベースと、メッセージのヘッダ部に付加されたこのメッセージの受信ノード情報を基にデータベースのツリーデータ構造をアクセスして、受信ノード情報をルートとするサブツリーに含まれる全てのノード情報を検索する検索手段と、検索された全てのノード情報に対応する配信先へメッセージを転送する転送手段とを備えることを特徴とする。ここで、データベースには、ノード情報と、メッセージ配信先を決定するための方針を定めたポリシ情報との対がツリーデータ構造として格納され、検索手段は、ノード情報とポリシ情報との対を検索し、転送手段は、検索された情報に従ってメッセージを転送するようにしてもよい。
また、本発明によるメッセージ配信方法は、メッセージをネットワークに接続されたノードへ配信するメッセージ配信方法であって、メッセージ配信先のノード情報が予め定められた関係に従ったツリーデータ構造として格納されたデータベースを、メッセージのヘッダ部に付加されたこのメッセージの受信ノード情報を基にアクセスして、受信ノード情報をルートとするサブツリーに含まれる全てのノード情報を検索するステップと、検索された全てのノード情報に対応する配信先へメッセージを転送するステップとを備えることを特徴とする。
また、本発明によるメッセージ配信システムは、ネットワークに接続されかつメッセージを送信及び受信する複数のノードと、ネットワークに接続されかつノードから送信されたメッセージを別のノードに配信するメッセージ配信装置とを備え、メッセージ配信装置は、メッセージ配信先のノード情報が予め定められた関係に従ったツリーデータ構造として格納されたデータベースと、メッセージのヘッダ部に付加されたこのメッセージの受信ノード情報を基にデータベースのツリーデータ構造をアクセスして、受信ノード情報をルートとするサブツリーに含まれる全てのノード情報を検索する検索手段と、検索された全てのノード情報に対応する配信先へメッセージを転送する転送手段とを備えることを特徴とする。ここで、これらのノード、メッセージ配信装置、ノード管理装置の各々とネットワークとの間にファイヤウォールを設けてもよい。
また、本発明によるプログラムは、メッセージをネットワークに接続されたノードへ配信するメッセージ配信方法をコンピュータに実現させるためのプログラムであって、メッセージ配信先のノード情報が予め定められた関係に従ったツリーデータ構造として格納されたデータベースを、メッセージのヘッダ部に付加されたこのメッセージの受信ノード情報を基にアクセスして、受信ノード情報をルートとするサブツリーに含まれる全てのノード情報を検索するステップと、検索された全てのノード情報に対応する配信先へメッセージを転送するステップとを実現させるためのプログラムである。

図１は、本発明の第１の実施例の構成を示すブロック図である。
図２は、本発明の第１の実施例の動作を示すフローチャートである。
図３は、本発明の第１の実施例の送信メッセージに関する動作を示すフローチャートである。
図４は、本発明の第１の実施例の送信メッセージの例を示す図である。
図５は、本発明の第１の実施例のエラーメッセージの例を示す図である。
図６は、本発明の第１の実施例のノード離脱要求メッセージの例を示す図である。
図７は、本発明の第１の実施例のノード離脱要求メッセージに関する動作を示すフローチャートである。
図８は、本発明の第１の実施例のエラーメッセージに関する動作を示すフローチャートである。
図９は、本発明の第１の実施例のノード登録要求メッセージに関する動作を示すフローチャートである。
図１０は、本発明の第１の実施例のノード登録要求メッセージの例を示す図である。
図１１は、本発明の第２の実施例の構成を示すブロック図である。
図１２は、本発明の第２の実施例のポリシエンジンの構成を示すブロック図である。
図１３は、本発明の第２の実施例のポリシエンジンの動作を示すフローチャートである。
図１４は、本発明の第２の実施例のノード登録要求メッセージに関する動作を示すフローチャートである。
図１５は、本発明の第２の実施例のノード登録要求メッセージの例を示す図である。
図１６は、本発明の第２の実施例の送信メッセージに関する動作を示すフローチャートである。
図１７は、本発明の第２の実施例の具体例を示すブロック図である。
図１８は、本発明の第３の実施例の具体例を示すブロック図である。
図１９は、本発明の第３の実施例のノード登録要求メッセージに関する動作を示すフローチャートの一部である。
図２０は、本発明の第３の実施例のノード登録要求メッセージに関する動作を示すフローチャートの一部である。
図２１は、従来技術を説明するためのブロック図である。

以下に図面を参照しつつ本発明の実施例について詳細に説明する。
第１の実施例
図１を参照すると、本発明の第１の実施例のブロック図が示されている。図１において、ネットワーク１００を介して、メッセージルータ（メッセージ配信装置）２００、ノードマネージャ（ノード管理装置）４００、メッセージを送受信するための複数のノード５００〜５０２等が接続されている。ノード間はメッセージルータ２００を介して、お互いメッセージを送受信し合うものとする。ノード５００〜５０２等は、処理部５１０〜５１２が、詳細は後述する図４で示すようなメッセージを作成し、メッセージ送信部５３０〜５３２を使って、他のノードへのメッセージを送信する。尚、他のノードからのメッセージ受信はメッセージ受信部５２０〜５２２により行う。
このメッセージはＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）メッセージやＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｌ Ｐｒｏｔｏｃｏｌ）などのアプリケーションプロトコルであり、ヘッダ部分とペイロードに分かれる。ヘッダ部分は、ＨＴＴＰで規定されたヘッダ以外に、本実施例の特有のヘッダ（たとえば、ｍｅｓｓａｇｅ：ｓｅｎｄ）を有する。
ネットワーク１００に接続されたメッセージルータ２００のメッセージ受信部２１０がメッセージを受信する。メッセージ受信部２１０は受信したメッセージをスプリッタ２２０に渡す。スプリッタ（分離手段）２２０はメッセージをヘッダ部分とペイロード部分に分割し、メッセージ部分をヘッダ解釈部２３０に、ペイロード部分を合成部２６０に、それぞれ渡す。ヘッダ解釈部（解釈手段）２３０はメッセージのヘッダ部分のうち、０個以上の受信者群を示す属性（例えば，ｒｅｃｅｉｖｅｒｓ属性）の値を使って、ＤＢ読出部（検索手段）２４０を介して、データベース３００が格納するドメインツリー３１０から適切なノード情報を取り出す。
ここで、ノード情報とは、ノード５００等のＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）などの位置情報である。ドメインツリーとはノード情報や、ドメインと呼ぶノード情報の集合を節とするツリー構造である。節には名前がつけられており、ツリーのルートから「／」を区切り子として節の名前を連ねることで、ノード情報、もしくはドメインを一意に指定することができる。この名前をドメインパスと呼ぶ。ｒｅｃｅｉｖｅｒｓ属性の値はドメインパスである。上記「適切なノード情報」とは、ｒｅｃｅｉｖｅｒｓ属性値のドメインパスで指定したノード情報、もしくはドメインパスで指定したドメインを頂点とするサブツリーに含まれるノード情報の全てである。
ヘッダ解釈部２３０はそのノード情報の集合と、ヘッダ部分をヘッダ書換部２５０に渡す。ヘッダ書換部（書換手段）２５０は、メッセージからｒｅｃｅｉｖｅｒｓ属性及びその値を取り除き、その代わりに、メッセージルータの位置情報を示す属性（例えば、ｒｏｕｔｅｒＵｒｌ属性）とその値としてメッセージルータのＵＲＬなどの位置情報を付け加え、合成部２６０に送る。合成部（合成手段）２６０はヘッダ書換部２５０からのヘッダの後ろに、スプリッタ２２０から受けたペイロードをつけ足して、新しいメッセージとする。合成部２６０は、メッセージとヘッダ書換部２５０から受けたノードを表すＵＲＬなどの位置情報を、メッセージ転送部２７０に送る。メッセージ転送部（転送手段）２７０は合成部２６０から受けたＵＲＬなどの位置情報で指定されたノードにメッセージを送信する。メッセージ転送部２７０から送信されたメッセージは、例えば、ノード５０１のメッセージ受信部５２１に到着し、処理部５１１に渡されて処理がなされる。
ノード５００等のノードに関するノード情報は、予めデータベース３００に登録しておく必要がある。ノードマネージャ４００はノードの登録要求を受理する。つまり、ノードの登録要求メッセージを登録要求受付部４２０が受信し、メッセージ解釈部４１０に伝える。メッセージ解釈部４１０は、メッセージルータ表４４０に登録されているメッセージルータのＵＲＬなどの位置情報を得る。メッセージ解釈部４１０は、メッセージ送信部（転送手段）４３０を介して、メッセージルータ２００に当該メッセージを送信する。
応答受信部４５０は、メッセージルータ２００に出した登録要求の結果を受ける。応答部４６０は、応答受信部４５０から応答結果を示すメッセージを受け、それを登録要求者に応答メッセージとして送信する。
図２は、本発明の第１の実施例の動作のうち、メッセージ送信を示すフローチャートである。まず、ノード５００の処理部５１０がメッセージ送信部５３０に依頼し、ネットワーク１００にメッセージルータ２００宛てメッセージを投げる（ステップＤ１０）。
メッセージルータ２００のメッセージ受信部２１０がそのメッセージを受信する（ステップＤ２０）。スプリッタ２２０がメッセージをヘッダとペイロードに分割し、ヘッダをヘッダ解釈部２３０に、ペイロードを合成部２６０に、それぞれ渡す（ステップＤ３０）。
ヘッダ解釈部２３０はヘッダを解釈し、メッセージの種類を表す属性（例えば、ｍｅｓｓａｇｅ属性）の値を得る（ステップＤ４０）。ｍｅｓｓａｇｅ属性の値は、メッセージ送信メッセージ（例えば、ｍｅｓｓａｇｅ属性の値が「ｓｅｎｄ」）か、ノードの離脱要求メッセージ（例えば、「ｌｅａｖｅ」）か、エラーメッセージ（例えば、「ｅｒｒｏｒ」）である。その値により、処理が分岐される（ステップＤ５０）。
図３は、本発明の第１の実施例の動作のうち、ｍｅｓｓａｇｅ属性の値がメッセージ送信メッセージであることを示す値、つまり「ｓｅｎｄ」の場合の処理を示す。ヘッダ解釈部２３０はヘッダを解釈し、ヘッダの受信者を表す属性（例えば、ｒｅｃｅｉｖｅｒｓ属性）の値に応じて、ＤＢ読出部２４０に適切なノード情報の取得を依頼する。ＤＢ読出部２４０はその結果であるノード情報の集合をヘッダ解釈部２３０に返す（ステップＢ４０）。その集合が空になるまで、次の処理を繰り返す（ステップＢ６０）。
ヘッダ解釈部２３０はヘッダ情報の集合の要素の１つをヘッダ書換部２５０に渡す（ステップＢ７０）。ヘッダ書換部２５０はヘッダを書き換える。つまり、ヘッダからｒｅｃｅｉｖｅｒｓ属性を削除し、現在使用しているメッセージルータ２００のＵＲＬなどの位置情報を示す属性（例えば，ｒｏｕｔｅｒＵｒｌ属性）を追加する。ｒｏｕｔｅｒＵｒｌ属性の値は、現在使用しているメッセージルータ２００のＵＲＬなどの位置情報である。書き換えたヘッダを合成部２６０に渡す（ステップＢ８０）。
合成部２６０はヘッダ書換部２５０から受けたヘッダとスプリッタ２２０からのペイロードとを合成し、メッセージ転送部２７０に渡す（ステップＢ９０）。メッセージ転送部２７０はノード情報で示されているノードに対してメッセージを送信する（ステップＢ１００）。ノード情報から、今回、受信者となったノード情報をノード情報の集合から削除し、ステップＢ６０に戻り、ノード情報の集合が空になるまで、ステップＢ７０〜Ｂ１００の処理を繰り返す。ノード情報の集合が空のとき、処理は終了する。
図７は本発明の第１の実施例の動作のうち、図２のフローチャートの後続として、ｍｅｓｓａｇｅ属性の値がノードの離脱要求を示す値、つまり「ｌｅａｖｅ」の場合の処理を示す。ヘッダ解釈部２３０はヘッダを解釈し、ＤＢ書込部２９０にヘッダの送信ノードを示す属性（例えば、ｓｅｎｄｅｒ属性）の値が指定するノードの削除を依頼する（ステップＥ４０）。ＤＢ書込部２９０はデータベース３００から指定したノード情報を削除する（ステップＥ５０）。
図８は、本発明の第１の実施例の動作のうち、図２のフローチャートの後続として、ｍｅｓｓａｇｅ属性の値がエラーメッセージを示す値、つまり「ｅｒｒｏｒ」の場合の処理を示す。メッセージの受信者であるノードやメッセージルータがｍｅｓｓａｇｅ属性の値が「ｓｅｎｄ」である受信メッセージに関する処理でエラーが発生した場合に、ｅｒｒｏｒメッセージを発する。たとえば、受信者ノード５００でエラーを発生した場合、処理部５１０でエラーメッセージを作成する。
ｍｅｓｓａｇｅ属性は「ｅｒｒｏｒ」で、ｓｅｎｄｅｒ属性の値は、エラーが発生した元のメッセージの送信者を示すドメインパスで、メッセージ識別子を値にもつ属性（例えば，ｍｅｓｓａｇｅｉｄ属性）の値は元のメッセージのｍｅｓｓａｇｅｉｄ属性の値と同一の値で、ｒｅｃｅｉｖｅｒｓ属性はエラーを発見したノード（つまり、受信者ノード５００）のドメインパスである。元のメッセージのｒｏｕｔｅｒＵｒｌ属性の値であるメッセージルータのＵＲＬなどの位置情報に、作成したエラーメッセージを送信する。
ヘッダ解釈部２３０はヘッダを解釈し、ヘッダの送信ノードを示す属性（例えば、ｓｅｎｄｅｒ属性）の値に応じてＤＢ読出部２４０に適切なノード情報の取得を依頼する。ＤＢ読出部２４０はその結果をヘッダ解釈部２４０に返す（ステップＦ４０）。ヘッダ解釈部２３０は応答部２８０にノード情報からＵＲＬなどの位置情報を取得し、エラーメッセージをＵＲＬなどの位置情報で指定されたノードに送信する（ステップＦ５０）。
図９は、本発明の第１の実施例の動作のうち、ノード情報をデータベース３００に登録する動作を示す。ノード５００の追加依頼メッセージが、ネットワーク１００を介して、ノードマネージャ４００宛てに、図１０を例とするようなメッセージとして送出される（ステップＡ１０）。ノードマネージャ４００の要求受信部４２０がメッセージを受信し、メッセージ解釈部４１０に伝える。
メッセージ解釈部４１０がメッセージを解釈する（ステップＡ２０）。解釈する過程でメッセージにエラーがあるかを判定する（ステップＡ３０）。メッセージにエラーが発見されたら、メッセージ解釈部４１０は応答部４６０に依頼し、ノード５００の追加依頼者にエラーメッセージを返す（ステップＡ３５）。
エラーがなければ、メッセージ解釈部４１０はメッセージルータ表４４０を参照し、ｓｅｎｄｅｒ属性値に対応するメッセージルータのＵＲＬなどの位置情報を得る（ステップＡ４０）。この第１の実施例では、メッセージルータ表４４０に登録されているメッセージルータは１つと仮定しているため、常に同じＵＲＬなどの位置情報が返される。メッセージ解釈部４１０はメッセージルータにノード５００の登録要求メッセージを転送する（ステップＡ５０）。メッセージルータ２００のメッセージ受信部２１０がメッセージを受信し、スプリッタ２２０に投げる（ステップＡ６０）。
スプリッタ２２０はメッセージをヘッダとペイロードに分離し、ヘッダをヘッダ解釈部２３０に、ペイロードを合成部２６０に、それぞれ渡す（ステップＡ７０）。ヘッダ解釈部２３０はヘッダの中身を解釈し、ＤＢ書込部（登録手段）２９０を使用し、送信ノードの位置情報を示す属性（例えば、ｓｅｎｄｅｒＵＲＬ属性）でＵＲＬなどの位置情報をノード情報として、ドメインツリー３１０中のｓｅｎｄｅｒ属性で指定したドメインに追加する（ステップＡ８０）。ヘッダ解釈部２３０は応答部２８０を介して、メッセージルータ２００のＵＲＬなどの位置情報を含む追加成功メッセージを応答受信部４５０に送信する（ステップＡ９０）。
応答受信部４５０は応答部４６０に依頼し、追加成功メッセージをノード５００に転送する（ステップＡ１００）。このメッセージにはメッセージルータ２００のＵＲＬなどの位置情報を含む。以降、ノード５００はこのＵＲＬなどの位置情報が指すメッセージルータにｍｅｓｓａｇｅ属性値が「ｓｅｎｄ」のメッセージを送信する。
次に、具体的な実施例を用いて本実施例の動作を説明する。先ず、メッセージルータ２００のＵＲＬを“ｈｔｔｐ：／／ｄｉｓｔｒｉｂｕｔｏｒ．ｃｏｍｐａｎｙ．ｃｏｍ／ｓｅｒｖｌｅｔ／ｄｉｓｔｒｉｂｕｔｏｒ”とし、ノードマネージャ４００のＵＲＬを“ｈｔｔｐ：／／ｎｏｄｅｍａｎａｇｅｒ．ｃｏｍｐａｎｙ．ｃｏｍ／ｓｅｒｖｌｅｔ／ｄｉｓｔｒｉｂｕｔｏｒ”とする。また、ノード５００のＵＲＬを“ｈｔｔｐ：／／ｎｏｄｅ５００．ｐｏｒｔｉａ．ｃｏｍ／ａｐｐ”とする。
先ず、ノード５００をメッセージルータ２００にドメインパス／ｎｏｄｅｓ／ｓｅｎｄｅｒｓ／ｎｏｄｅ５００として登録すると考える。このとき、ノード登録要求者は図１０で示すようなメッセージをノードマネージャ４００に発行する。図１０（図４〜図６においても同様）の１行目から４行目がＨＴＴＰヘッダ、５行目から９行目が本実施例で定義した属性である。１０行目（空行）がヘッダとペイロードのセパレータで、１１行目以降がペイロードである。なお、本実施例では、ＨＴＴＰヘッダと属性を、ヘッダと称するものとする。
ｍｅｓｓａｇｅ属性はメッセージの種類を表し、その値として「ｊｏｉｎ」、「ｌｅａｖｅ」、「ｓｅｎｄ」、「ｅｒｒｏｒ」が定義されている。「ｊｏｉｎ」はノードの登録要求メッセージ（図１０）、「ｌｅａｖｅ」は登録済みノードを登録から取り除く作業（離脱）要求メッセージ（図６）、「ｓｅｎｄ」はデータ通信用メッセージ（図４）、「ｅｒｒｏｒ」は「ｓｅｎｄ」メッセージでエラーが発生した場合のエラー通知用メッセージ（図５）となる。
登録要求メッセージは、ノード登録要求者がノードマネージャ４００に対して要求メッセージを発行する。「ｌｅａｖｅ」メッセージは、離脱対象ノード５００がメッセージルータ２００に対して「ｌｅａｖｅ」メッセージを発行する。「ｓｅｎｄ」メッセージ、「ｌｅａｖｅ」メッセージは、登録済みノードがメッセージルータ２００に対してメッセージを発する。
登録要求メッセージでは、ｓｅｎｄｅｒ属性は、登録対象ノードの登録先をドメインパスで指定する。ｍｅｓｓａｇｅｉｄは、登録要求者が、その責任で、グローバルにメッセージを一意に保障できるようにつけた識別子である。ｓｅｎｄｅｒＵｒｌ属性はノード５００のメッセージ受信部５２０を指定するＵＲＬである。ノード５００つまり、／ｎｏｄｅｓ／ｓｅｎｄｅｒｓ／ｎｏｄｅ５００へのメッセージは、このＵＲＬに送信される。送信モードを表す属性（例えば、ｍｏｄｅ属性）は、ノード５００へのメッセージ送信モードを指定する。
受信ノードがサーバソケットを開設している場合のｍｏｄｅ属性値（例えば、「ａｃｔｉｖｅ」）の場合、ノード５００のメッセージ受信部５２０はサーバとしてサーバソケットを開いてメッセージを待っている。受信ノードがサーバソケットを開設できない場合のｍｏｄｅ属性値（例えば、「ｐａｓｓｉｖｅ」）の場合、メッセージ受信部５２０は定期的にメッセージルータ２００にポーリングし、ノード５００宛てのメッセージが届いていないかを調べる。「ｐａｓｓｉｖｅ」は、ファイヤウォール内にいるときや、グローバルＩＰアドレスを有しないため、ノード５００がサーバソケットを開設できない場合に使用する。
この登録要求メッセージは要求受付部４２０で受信され、メッセージ解釈手４１０に伝えられる。メッセージルータ表４４０からメッセージルータのＵＲＬ“ｈｔｔｐ：／／ｄｉｓｔｒｉｂｕｔｏｒ．ｃｏｍｐａｎｙ．ｃｏｍ／ｓｅｒｖｌｅｔ／ｄｉｓｔｒｉｂｕｔｏｒ”を得る。本実施例では、メッセージルータ表４４０に登録されているメッセージルータは、ルータ２００の１つだけであるとする。メッセージ送信部４３０は、ＵＲＬ“ｈｔｔｐ：／／ｄｉｓｔｒｉｂｕｔｏｒ．ｃｏｍｐａｎｙ．ｃｏｍ／ｓｅｒｖｌｅｔ／ｄｉｓｔｒｉｂｕｔｏｒ”、つまり、メッセージルータ２００に、登録要求メッセージを送信する。メッセージルータ２００のメッセージ受信部２１０が本メッセージを受理し、スプリッタ２２０がメッセージのヘッダ部分である図１０の１行目から９行目を切り出して、ヘッダ解釈部２３０に渡す。
ヘッダ解釈部２３０は、ＤＢ書込部２９０を使用し、ドメインツリーのドメイン／ｎｏｄｅｓ／ｓｅｎｄｅｒｓの要素としてノード５００のノード情報“ｈｔｔｐ：／／ｎｏｄｅ５００．ｐｏｒｔｉａ．ｃｏｍ／ａｐｐ”をデータベース３００に登録する。ヘッダ解釈部２３０は応答部２８０を使って、応答受信部４５０に成功応答を返し、応答受信部４５０は応答部４６０を介して、登録要求メッセージ送信者に応答を返す。
次に、ノード５０１、ノード５０２に対し、ノード５００がメッセージを送信する具体的な実施例を示す。ノード５０１はドメイン／ｃｏｍｐａｎｙ／ｓａｌｅｓＤｉｖ／ｎｏｄｅ５０１に登録され、そのＵＲＬは“ｈｔｔｐ：／／ｎｏｄｅ５０１．ｐｏｒｔｉａ．ｃｏｍ／ａｐｐ”とする。ノード５０２はドメイン／ｃｏｍｐａｎｙ／ｓａｌｅｓＤｉｖ／１ｓｔＳｅｃ／ｎｏｄｅ５０２に登録され、そのＵＲＬは“ｈｔｔｐ：／／ｎｏｄｅ５０２．ｐｏｒｔｉａ．ｃｏｍ／ａｐｐ”とする。
ノード５００の処理部５１０は、図４で示すメッセージを送信する。ｒｅｃｅｉｖｅｒｓ属性の値は、受信者（メッセージ配信先）の集合を表すドメインパスである。ｒｅｃｅｉｖｅｒｓ属性値が／ｃｏｍｐａｎｙ／ｓａｌｅｓＤｉｖなので、ドメイン／ｃｏｍｐａｎｙ／ｓａｌｅｓＤｉｖをルート（ｒｏｏｔ：根）とするサブツリーに含まれるノード５０１，５０２が送信対象となる。このメッセージはメッセージ送信部５３０より送信され、メッセージ受信部２１０で受信される。
スプリッタ２２０は、図４で示すメッセージのヘッダ（１行から８行）をヘッダ解釈部２３０に渡す。ヘッダ解釈部２３０はｒｅｃｅｉｖｅｒｓ属性の値／ｎｏｄｅｓ／ｒｅｃｉｅｖｅｒｓを取り出し、ＤＢ読込部２４０にドメイン／ｎｏｄｅｓ／ｒｅｃｉｅｖｅｒｓをルートするサブツリーのすべてのノードを返すよう依頼する。ヘッダ解釈部２３０には、ノード情報として、“ｈｔｔｐ：／／ｎｏｄｅ５０１．ｐｏｒｔｉａ．ｃｏｍ／ａｐｐ”と“ｈｔｔｐ：／／ｎｏｄｅ５０２．ｐｏｒｔｉａ．ｃｏｍ／ａｐｐ”を得る。ヘッダ書換部２５０は、それぞれのＵＲＬに対して、まず、ｒｏｕｔｅｒＵｒｌ属性として、属性値“ｈｔｔｐ：／／ｄｉｓｔｒｉｂｕｔｏｒ．ｃｏｍｐａｎｙ．ｃｏｍ／ｓｅｒｖｌｅｔ／ｄｉｓｔｒｉｂｕｔｏｒ”を加え、ｒｅｃｅｉｖｅｒｓ属性をそれぞれ／ｃｏｍｐａｎｙ／ｓａｌｅｓＤｉｖ／ｎｏｄｅ５０１，／ｃｏｍｐａｎｙ／ｓａｌｅｓＤｉｖ／１ｓｔＳｅｃ／ｎｏｄｅ５０２となるようヘッダを変換する。
ヘッダ書換部２５０は変換したヘッダを合成部２６０に渡し、合成部２６０はヘッダにペイロード（図４の１０行目以降）を取り付けて、メッセージ転送部２７０にノード５０１及び５０２に、それぞれのメッセージを送信するよう依頼する。
以上の説明からも分かる様に、データベース３００のドメインツリー３１０の例としては、会社組織であれば、部、課、係、班等の組織を、大組織から小組織へと順次枝が分かれて伸びるように、また予め互いに関連するようにツリー構造として組み立てたものであり、上記例の様に、受信者（メッセージ配信先）の集合を表すドメインパスであるｒｅｃｅｉｖｅｒｓ属性値により当該会社組織（ｃｏｍｐａｎｙ）の営業部（ｓａｌｅｓＤｉｖ）が指定されると、この会社組織（ｃｏｍｐａｎｙ）の営業部（ｓａｌｅｓＤｉｖ）をルート（根）とするサブツリーに含まれる全てのノード（受信者群）が送信対象となるのである。
次に、このメッセージがノード５０２においてエラーが発生した場合の例を示す。ノード５０２の処理部５１２が、たとえば、メッセージ受信部５２２で受信に失敗したことを検出したとする。そのとき、処理部５１２は図５で示すメッセージを作成する。この場合、ｍｅｓｓａｇｅ属性は「ｅｒｒｏｒ」であり、ｓｅｎｄｅｒ属性は元のメッセージの送信者であるノード５００のドメインパス／ｎｏｄｅ／ｓｅｎｄｅｒｓ／ｎｏｄｅ５００であり、ｒｅｃｅｉｖｅｒｓ属性の値はノード５０２のドメインパス／ｃｏｍｐａｎｙ／ｓａｌｅｓＤｉｖ／１ｓｔＳｅｃ／ｎｏｄｅ５０２であり、ｍｅｓｓａｇｅｉｄ属性の値は元のメッセージと同じｍｅｓｓａｇｅｉｄである。
処理部５１２はメッセージ送信部５３２を使って、元メッセージのｒｏｕｔｅｒＵｒｌ属性で示されたメッセージルータ２００にメッセージを送信する。メッセージ受信部２１０で受信されたメッセージはスプリッタ２２０を通り、ヘッダ受信部２３０がｓｅｎｄｅｒ属性のドメインパスで指定されたノード５００のノード情報ＵＲＬ“ｈｔｔｐ：／／ｎｏｄｅ５００ｐｏｒｔｉａ．ｃｏｍ／ａｐｐ”を得る。ヘッダ書換部２５０を通し、このヘッダ及びＵＲＬは合成部２６０に伝えられ、ペイロードと合成されて、メッセージ転送部２７０を介してノード５００に送信される。
次に、ノード５００がｌｅａｖｅメッセージを発信する具体例を示す。ノード５００の処理部５１０は、図６で示すｌｅａｖｅメッセージを作成する。このメッセージのｓｅｎｄｅｒ属性はノード５００のドメインパス／ｎｏｄｅ／ｓｅｎｄｅｒｓ／ｎｏｄｅ５００である。メッセージ送信部５３０を使って、メッセージルータ２００にメッセージが送信される。メッセージルータ２００では、メッセージ受信部２１０が受信したメッセージをスプリッタ２２０がヘッダを切り出し、ヘッダ解釈部２３０に渡す。ヘッダ解釈部２３０はｓｅｎｄｅｒ属性の値／ｎｏｄｅ／ｓｅｎｄｅｒｓ／ｎｏｄｅ５００を取り出し、ＤＢ書込部２９０を使って、／ｎｏｄｅ／ｓｅｎｄｅｒｓ／ｎｏｄｅ５００のノード情報を削除する。ここでは、ｌｅａｖｅメッセージがノード５００から直接メッセージルータ２００に送信される例を示したが、ノード５００からノードマネージャ４００を経由してメッセージルータ２００に送信されるようにしてもよい。
本実施例では、データベースには、ツリーデータ構造でノード情報を格納する。ツリーのノードを指定するドメインパスにより、サブツリーに含まれるノードすべてを指定することが可能になる。よって、指定したトピック間の包含関係を反映したノードを指定することが可能となる。
第２の実施例
次に、本発明の第２の実施例について説明する。図１１は本発明の第２の実施例を表すブロック図である。メッセージルータ６００は図１のメッセージルータ２００のヘッダ書換部２５０の代わりにポリシエンジン６１０を搭載している。ポリシエンジン（照合手段）６１０は、送信対象候補のノードの位置情報（例えば、ＵＲＬ）とそれに添付されたポリシ（方針）のペアの集合と、ヘッダを入力とし、送信対象の位置情報とヘッダのペアを出力とする。ポリシエンジン６１０は、送信対象候補ノードのポリシがヘッダにマッチするか検査し、マッチするならば、新たなヘッダを作成し、それが他のポリシにマッチするかを判断する。
ポリシエンジンの構造を図１２に示す。ノード情報であるノードの位置情報（例えば、ＵＲＬ）と、そのノードを登録するときに設定するポリシの組が複数あるとする（６８０）。順序付け部６５０はこれらのノード情報の集合を一定規則で取り出し、ＦＩＦＯキュー６４０に順番に入れていく。ここで、一定規則とは、例えば、乱数により無作為に取り出す方式でも良く、これに限定されない。ＦＩＦＯキュー６４０はノード情報を格納する行列で、行列に入力した順番で、ノード情報を取り出すことができる。
バッファ６７０はメッセージ送信メッセージのヘッダ６９１を高々１個格納することができる。よって、バッファ６７０からヘッダを取り出すと、格納ヘッダ数は０個となる。ポリシは照合部と書き換え部から構成される記述である。照合部はメッセージのヘッダのパターンを記述し、ヘッダが照合部に照合可能か否かが判別可能である。書き換え部は照合部の照合状況を考慮した上で、ヘッダの内容を書き換える。
例えば、照合部はヘッダ属性値を正規表現で記述し、ヘッダが有する属性値が正規表現に照合するかで、照合可能かを判別し、書き換え部は照合した属性値を指定したある特定の文字列に置き換えるというポリシが考えられる。
更に述べると、ポリシとは、ノードが受信すべきメッセージを定めた方針を意味するものであり、換言すれば、ノードが受信すべきメッセージの性質を示すものである。例えば、ノード５０１がポリシ“ｓｅｎｄｅｒ＝／ｎｏｄｅｓ／ｓｅｎｄｅｒｓ／｜＊”として「ｊｏｉｎ」メッセージにより登録されていたとする。この場合、ノード５０１はｓｅｎｄｅｒ属性を有し、その値が”／ｎｏｄｅｓ／ｓｅｎｄｅｒｓ／”で始まるあるメッセージ、例えば、図４で示す送信メッセージを受信する。ポリシは、メッセージ配信先の決定に用いられる。
更に、複数のノードが受信するメッセージパターンを記述するために、当該ポリシは照合部に加えて、書き換え部をも有している。この書き換え部は、ノードが受信可能な場合に、すなわち、そのノードのポリシに照合（合致）した場合に、他のノードが受信条件に合致することを記述するものである。
ポリシ照合検査部６３０はノード情報とヘッダを順次入力とし、ノード情報のポリシの照合部がノードに照合可能かを判定し、照合不可能ならば停止し、照合可能ならば、ノード情報、つまり、位置情報とヘッダの組と、照合情報とヘッダの組を出力する。ヘッダ書換部２５０は、図１の書換部２５０と同様であり、ヘッダと位置情報の組を入力とする。ヘッダの受信者を示す属性（例えば，ｒｅｃｅｉｖｅｒｓ属性）の値をノード情報が格納されているドメインパスとし、メッセージルータの位置情報を示す属性（例えば、ｒｏｕｔｅｒＵｒｌ属性）の値としてメッセージルータ６００の位置情報を設定し、この位置情報とヘッダとを組６９０で出力する。
書換部６６０はポリシ照合検査部６３０が行なった照合作業の情報と、ポリシと、ヘッダとを入力として、ポリシの書き換え部の内容を調べ、ヘッダを書き換えて出力する。
ポリシエンジン６１０の動作を図１３を用いて説明する。バッファ６７０がヘッダ６９１を外部から１つ取り込む（ステップＰ１０）。ノードのＵＲＬとポリシの組であるノード情報の集合６８０を順序付け部６５０がある一定の規則に従い、順番付けし、ＦＩＦＯキュー６４０に格納する（ステップＰ２０）。ここで、一定規則とは、例えば、上述したように、ランダムに順番付けする方法を使用しても良い。
ポリシ照合検査部６３０がＦＩＦＯキュー６４０からＵＲＬとポリシを、またバッファ６７０からヘッダを取り出す（ステップＰ５０）。このとき、ノード情報がＦＩＦＯキュー６４０に存在していなければ、処理を停止する（ステップＰ３０）。また、バッファ６７０にヘッダが存在しなければ、処理を停止する（ステップＰ４０）。
ポリシ照合検査部６３０はポリシの照合部が、ヘッダと照合可能か検査する（ステップＰ６０）。照合不可ならば、ヘッダをバッファ６７０に戻し、ステップＰ５０から再開する（ステップＰ８０，Ｐ８５）。
ポリシ照合検査部６３０からＵＲＬとヘッダを渡され、書換部２５０がヘッダの受信ノードを示す属性（例えば，ｒｅｃｅｉｖｅｒｓ属性）をノード情報が格納されているドメインのドメインパスに書き換え、メッセージルータの位置情報を示す属性（ｒｏｕｔｅｒＵｒｌ属性）をその値をメッセージルータの位置情報として追加し、位置情報とヘッダの組６９０を出力する（ステップＰ９０）。次に、ポリシに書き換え部があるかをチェックする。もしなければ、ポリシエンジンの動作を終了する（ステップＰ１００）。
ポリシ照合検査部６３０から、照合情報とポリシとヘッダの組を受け取り、書換部６６０がポリシの書き換え部に従い、ヘッダを書き換えてバッファ６７０に置く（ステップＰ１１０）。ステップＰ１１０の後、ステップＰ５０に戻り、処理を繰り返す。
このようなポリシエンジンを使った本発明の第２の実施例において、ノード登録要求メッセージに対する動作を図１４を使って説明する。図１５が本発明の第２の実施例におけるノード登録要求メッセージである。図１０で示した本発明の第１の実施例でのノード登録要求メッセージとの違いは、ポリシを示す属性（例えば、ｐｏｌｉｃｙ属性）が存在することである。
図９で示した本発明の第１の実施例でのノード登録要求メッセージの動作との違いは、ステップＡＰ８０において、ヘッダ解釈部２３０が送信ノードの位置情報を示す属性（例えば、ｓｅｎｄｅｒＵｒｌ属性）の値だけではなく、ポリシ３２０を示す属性の値も加えて組とし、データベース３００が格納するドメインツリーに登録していることである。図１４におけるステップＡＰ８０以外の他のステップＡＰ１０，ＡＰ２０などは、図９の各ステップＡ１０，Ａ２０などと同じである。
次に、図１６を用いて、本発明の第２の実施例において、メッセージ送信方法の動作を説明する。第２の実施例においても、図２で示すフローチャートと同様の動作を行なう。そこで、図２の継続の処理として図１６のフローチャートで示す動作を説明する。
ヘッダ解釈部２３０はヘッダを解釈し、ヘッダの受信者を示す属性（例えば、ｒｅｃｅｉｖｅｒｓ属性）の値に応じてＤＢ読出部２４０に適切なノード情報の取得を依頼する。ＤＢ読出部２４０はその結果であるノード情報の集合をヘッダ解釈部２３０に返す（ステップＣ６０）。ヘッダ解釈部２３０はノード情報の集合とヘッダをポリシエンジン６１０に渡す（ステップＣ７０）。ポリシエンジン６１０はＵＲＬとヘッダの組を出力する（ステップＣ８０）。ポリシエンジン６１０が位置情報とヘッダの組を出力することを停止したら、処理が終了である（ステップＣ８５）。
ポリシエンジン６１０はヘッダを合成部２６０に渡す（ステップＣ９０）。合成部２６０はヘッダ書換部２５０から受けたヘッダとスプリッタ２２０からのペイロードを合成し、メッセージ転送部２７０に渡す（ステップＣ９５）。メッセージ転送部２７０はノード情報で示されているノードに対してメッセージを送信する（ステップＣ１００）。ステップＣ１００からステップＣ７０に処理を繰り返す。
次に、具体的な例を用いて、本実施例の動作を説明する。ノード５０１がポリシ“ｓｅｎｄｅｒ＝／ｎｏｄｅｓ／ｓｅｎｄｅｒｓ／｜＊”で、ノード５０２が、図１５に示す様に、ポリシ“ｓｅｎｄｅｒ＝／ｎｏｄｅｓ／ｒｅｃｅｉｖｅｒｓ／｜＊”で登録されていたとする。ノード５００が「ｓｅｎｄ」メッセージを送信すると、図４で示すメッセージが送信される。これには、ｓｅｎｄｅｒ属性の値は“／ｎｏｄｅｓ／ｓｅｎｄｅｒｓ／ｎｏｄｅ５００”である。メッセージのｒｅｃｅｉｖｅｒｓ属性からノード５０１に関するノード情報と、ノード５０２に関するノード情報の集合が得られる。
ポリシエンジン６１０の順序付け部６５０はランダムにノード５０２のノード情報、ノード５０１のノード情報という順番で、ＦＩＦＯキュー６４０に入れるとする。ポリシ照合検査部６３０は、まず、ノード５０２のＵＲＬ”ｈｔｔｐ：／／ｎｏｄｅ５０２．ｐｏｒｔｉａ．ｃｏｍ／ａｐｐ”とポリシ”ｓｅｎｄｅｒ＝／ｎｏｄｅｓ／ｒｅｃｅｉｖｅｒｓ／｜＊”を得る。照合部はｓｅｎｄｅｒ属性の値が正規表現で”／ｎｏｄｅｓ／ｒｅｃｅｉｖｅｒｓ／”なので、ヘッダのｓｅｎｄｅｒ属性値とは照合しない。
そこで、次にノード５０１のＵＲＬ”ｈｔｔｐ：／／ｎｏｄｅ５０ １．ｐｏｒｔｉａ．ｃｏｍ／ａｐｐ”とポリシ”ｓｅｎｄｅｒ＝／ｎｏｄｅｓ／ｓｅｎｄｅｒｓ／｜＊”を得る。これはヘッダのｓｅｎｄｅｒ属性値と照合する。そこで、書換部２５０はｒｅｃｅｉｖｅｒｓ属性の値をノード５０１のＵＲＬ”ｈｔｔｐ：／／ｎｏｄｅ５０ １．ｐｏｒｔｉａ．ｃｏｍ／ａｐｐ”に書き換え、ｒｏｕｔｅｒＵｒｌ属性をメッセージルータ６００のＵＲＬ”ｈｔｔｐ：／／ｄｉｓｔｒｉｂｕｔｏｒ．ｃｏｍｐａｎｙ．ｃｏｍ／ｓｅｒｖｌｅｔ／ｄｉｓｔｒｉｂｕｔｏｒ”とし、ヘッダを合成部２６０に渡す。合成部２６０はヘッダとペイロードを合わせて、メッセージ転送部２７０からノード５１０へ送信する。
同時に、ポリシ照合部６３０は、書換部６６０にポリシとヘッダを渡す。ポリシの書き換え部は、”｜”より後部の”＊”で、これはヘッダをすべてコピーしてそのまま出力することを意味するので、バッファ６７０にヘッダをそのまま置く。ポリシ照合部６３０は次のノード情報をＦＩＦＯキュー６４０より取得しようとするが、すでに空なので、処理を停止する。
次に、図１７で示す他の具体例を用いて、本実施例の動作を説明する。サービス利用ノード５０５とサービス提供ノード５０７に加えて認証サーバ５０６が存在するシステムを考える。サービス提供ノード５０７はドメインパス／ｓｅｒｖｉｃｅＰｒｏｖｉｄｅｒにポリシ”ＰｏＳ−Ａｕｔｈ＝ｔｒｕｅ｜”で登録されているものとする。このポリシは、照合部のＰｏＳ−Ａｕｔｈ属性の値が”ｔｒｕｅ”の場合、メッセージを受け付ける。”｜”の右側が空なので、書き換え部は存在しない。
一方、認証サーバ５０６は、メインパス／ａｕｔｈｏｒｉｚａｔｉｏｎにポリシ”！ＰｏＳ−Ａｕｔｈ｜”で登録されているものとする。このポリシは、照合部にＰｏＳ−Ａｕｔｈ属性が存在しない場合、メッセージを受け付ける。”｜”の右側が空なので、書き換え部は存在しない。
サービス利用ノード５０５はその送信メッセージにユーザ名とパスワードを、認証方法ＢａｓｉｃでＡｕｔｈｏｒｉｚａｔｉｏｎ属性の値としているとする。サービス提供ノード５０７の送信メッセージには属性ＰｏＳ−Ａｕｔｈが存在しない。そのため、認証サーバ５０６のポリシの照合部“！Ｐｏｓ−Ａｕｔｈ”に合致し、認証サーバ５０６にメッセージが転送される。認証サーバ５０６はＡｕｔｈｏｒｉｚａｔｉｏｎ属性値に含まれるユーザ名とパスワードを取り出し、認証を行う。認証に成功したら、ヘッダに”ＰｏＳ−Ａｕｔｈ：ｔｒｕｅ”を、失敗したら”ＰｏＳ−Ａｕｔｈ：ｆａｌｓｅ”を加えて、メッセージルータ６００に転送する。転送されたメッセージは、認証に成功していれば、ＰｏＳ−Ａｕｔｈ属性の値が”ｔｒｕｅ”なので、サービス提供ノード５０７のポリシに合致し、サービス利用ノード５０５に転送され、サービスが提供される。
本実施例では、ポリシエンジン６１０を用いることで、ドメインパスのみで指定していた受信者を限定することが可能になる。これにより、メッセージヘッダ内の属性値により配信先を決定することが可能になり、属性値を変えることで、メッセージの状態を表すことになり、配信先を変更できる。つまり、メッセージの状態に応じてまず、最初に配送すべきノードが定まり、メッセージの状態変化で、順次配送先が定まり、ノード間連携が可能となる。
第３の実施例
次に、図面を使って、本発明の第３の実施例について説明する。図１８は本発明の第３の実施例を表すブロック図である。図１１に示した第２の実施例との差異は、メッセージルータ６００とネットワーク１００の間に、ファイヤウォール７００を置き、ノード５００〜５０２の各々とネットワーク１００との間に、ファイヤウォール７０１〜７０３を夫々置いたことである。他の構成は図１１のそれと同一である。また図１に示した第１の実施例にも同様に適用される。
ファイヤウォール７００にはノードマネージャ４００からどのＩＰアドレスからのアクセスを許すかを設定可能である。一方、ファイヤウォール７０１はノード５００から設定可能である。ファイヤウォール７０２，７０３も同様である。なお、ノードマネージャ４００に認証表４７０を設けている。認証表４７０はメッセージ解釈部４１０からのユーザ名やパスワードが正しいかを検査する。認証方法としては、ＨＴＴＰで定義されたＡｕｔｈｏｒｉｚａｔｉｏｎ属性によるＢａｓｉｃ認証方法等がある。
図１９及び図２０は本発明の第３の実施例の動作を示すフローチャートである。図１４のフローチャートに対して、ノード登録要求メッセージを受信したメッセージ解釈部４１０が認証表に認証情報が正しいか確認する点（ステップＡＳ３５，ＡＳ３７）、メッセージ解釈部４１０がファイヤウォール７００に送信ノードの位置情報を示す属性（例えば、ｓｅｎｄｅｒＵｒｌ属性）で指定したノードも通過可能に設定する点（ステップＡＳ４５）、そして、処理終了時に登録ノード５００がファイヤウォール７０１に処理が正しいことを確認する点（ステップＡＳ１２０）が追加されている。他の処理は図１４のそれと同一であり、同等符号により示されている。
具体的な例を用いて、本実施例の動作を説明する。ノード５００を登録する際、ＨＴＴＰのＡｕｔｈｏｒｉｚａｔｉｏｎ属性の値として、認証方法（例えば、Ｂａｓｉｃ）とユーザ情報とパスワードを取る。ノードマネージャ４００は本発明の第２の実施例と同様の処理を行ない、更に、ユーザ情報とパスワードが認証表４７０上に掲載されていることを確認する。その後メッセージ解釈部４１０はファイヤウォール７００にメッセージのｓｅｎｄｅｒ属性値”ｈｔｔｐ：／／ｎｏｄｅ５００．ｐｏｒｔｉａ．ｃｏｍ／ａｐｐのｎｏｄｅ５００．ｐｏｒｔｉａ．ｃｏｍ”からメッセージルータ６００へのアクセス許可を追加する。そして、登録成功後、ノード５００は、返されたメッセージルータのＵＲＬ”ｈｔｔｐ：／／ｄｉｓｔｒｉｂｕｔｏｒ．ｃｏｍｐａｎｙ．ｃｏｍ／ｓｅｒｖｌｅｔ／ｄｉｓｔｒｉｂｕｔｏｒ”を見て、ファイヤウォール７０１を”ｄｉｓｔｒｉｂｕｔｏｒ．ｃｏｍｐａｎｙ．ｃｏｍ”からのアクセスのみを許可するように設定する。
このようにした場合、悪意のサーバは認証されないので、登録できない。登録していないサーバはメッセージルータへアクセスしようとしてもファイヤウォール７００がアクセスを拒否する。またノード５００へのアクセスはファイヤウォール７０１が拒否する。そのため、ノード５００など登録したサーバを踏み台にした攻撃を防御できる。また、登録していないサーバを踏み台にしても登録していないサーバからのアクセスをファイヤウォールで拒否できるので、分散サービス拒否攻撃を防止できる。
以上の各実施例におけ動作フローは、予めプログラムとして記録媒体に格納しておき、これをＣＰＵ（コンピュータ）に読み取らせて、順次実行させるようにすることができることは明白である。また、上記各実施例におけるデータベース３００は、メッセージルータ２００，６００とは別に分離して設ける様に図示しているが、メッセージルータ２００，６００内に設けても良い。また、メッセージルータは一つとして示しているが、実際には複数存在するものであり、図を簡単化するためのものである。
上述した実施例の第１の効果は、メッセージ受信対象者を定めるトピックに包含関係が含意されている場合においても、包含関係に従って、適切なノードにメッセージを送信することができることである。その理由は、ノード情報をドメインと呼ぶツリーデータ構造で管理しており、ドメインで包含関係を表すことができるからである。
第２の効果は、複数のノード間での連携を実現可能な点である。例えば、あるサービスを提供するノードにメッセージを送信してから、他のサービスを提供するノードにメッセージを送信することができる点である。その理由は、ポリシによりメッセージの状態をヘッダの属性として管理し、その状態に応じて、適切な配信先を指定できるからである。例えば、あるサービスを提供するノードがヘッダの属性値を書き換えてメッセージを転送することで、ポリシはそのサービスが完了したとみなし、次のサービスを提供するノードに転送するような配信を記述できる。
第３の効果は、登録されたノードやメッセージルータに対するサービス拒否攻撃を防止できる点である。その理由は、ノードは登録することで、メッセージルータとのみ通信することに限定されることを利用し、ファイヤウォールを設け、それ以外のノードとの通信を拒否することができるからである。また、メッセージルータは登録したノードとのみ通信するので、ファイヤウォールにより、登録したノードとのみ通信するように設定することで、サービス拒否攻撃を防止できる。
第４の効果は、登録されたノードやメッセージルータに対する分散サービス拒否攻撃を防止できる点である。その理由は、ノードは、登録することによって、メッセージルータとのみ通信することに限定されることを利用し、ファイヤウォールを設け、それ以外のノードとの通信を拒否することができるからである。これにより、登録したノードを踏み台にすることができない。また、メッセージルータは登録したノードとのみ通信するので、ファイヤウォールにより、登録したノードとのみ通信するように設定することで、メッセージルータを踏み台にすることはできない。

Claims (21)

1. メッセージをネットワークに接続されたノードへ配信するメッセージ配信装置であって、
   メッセージ配信先のノード情報が予め定められた関係に従ったツリーデータ構造として格納されたデータベースと、
   前記メッセージのヘッダ部に付加されたこのメッセージの受信ノード情報を基に前記データベースのツリーデータ構造をアクセスして、前記受信ノード情報をルートとするサブツリーに含まれる全てのノード情報を検索する検索手段と、
   検索された全てのノード情報に対応する配信先へ前記メッセージを転送する転送手段と
   を備えることを特徴とするメッセージ配信装置。
2. 請求の範囲第１項に記載のメッセージ配信装置において、
   前記メッセージのヘッダ部とペイロード部とを分離する分離手段と、
   分離された前記ヘッダ部を解釈して前記検索手段に検索を指示する解釈手段と、
   前記検索手段により検索されたメッセージ配信先に応じて前記ヘッダ部を書換える書換手段と、
   書換えられたヘッダ部と前記分離手段により分離された前記ペイロード部とを合成して前記転送手段へ送出する合成手段と
   を更に備えることを特徴とするメッセージ配信装置。
3. 請求の範囲第１項に記載のメッセージ配信装置において、
   前記データベースには、前記ノード情報と、前記メッセージ配信先を決定するための方針を定めたポリシ情報との対が前記ツリーデータ構造として格納され、
   前記検索手段は、前記ノード情報とポリシ情報との対を検索し、
   前記転送手段は、検索された情報に従って前記メッセージを転送することを特徴とするメッセージ配信装置。
4. 請求の範囲第３項に記載のメッセージ配信装置において、
   前記転送手段は、検索されたポリシ情報と前記メッセージのヘッダ部情報との照合結果に応じて前記メッセージを転送することを特徴とするメッセージ配信装置。
5. 請求の範囲第４項に記載のメッセージ配信装置において、
   検索された前記ポリシ情報と前記メッセージのヘッダ部情報とを照合し、前記照合結果として配信先のノード情報とヘッダ部情報との対を出力する照合手段を更に備えることを特徴とするメッセージ配信装置。
6. メッセージをネットワークに接続されたノードへ配信するメッセージ配信方法であって、
   メッセージ配信先のノード情報が予め定められた関係に従ったツリーデータ構造として格納されたデータベースを、前記メッセージのヘッダ部に付加されたこのメッセージの受信ノード情報を基にアクセスして、前記受信ノード情報をルートとするサブツリーに含まれる全てのノード情報を検索するステップと、
   検索された全てのノード情報に対応する配信先へ前記メッセージを転送するステップと
   を備えることを特徴とするメッセージ配信方法。
7. 請求の範囲第６項に記載のメッセージ配信方法において、
   前記メッセージのヘッダ部とペイロード部とを分離するステップと、
   分離された前記ヘッダ部を解釈して検索を指示するステップと、
   検索されたメッセージ配信先に応じて前記ヘッダ部を書換えるステップと、
   書換えられたヘッダ部と分離された前記ペイロード部とを合成するステップとを更に備え、
   転送するステップは、合成された前記ヘッダ部及び前記ペイロード部に従って前記メッセージを転送するステップを備えることを特徴とするメッセージ配信方法。
8. 請求の範囲第６項に記載のメッセージ配信方法において、
   前記データベースに前記ノード情報と、前記メッセージ配信先を決定するための方針を定めたポリシ情報との対を前記ツリーデータ構造として格納するステップを更に備え、
   検索するステップは、前記ノード情報とポリシ情報との対を検索するステップを備え、
   転送するステップは、検索された情報に従って前記メッセージを転送するステップを備えることを特徴とするメッセージ配信方法。
9. 請求の範囲第８項に記載のメッセージ配信方法において、
   転送するステップは、検索されたポリシ情報と前記メッセージのヘッダ部情報との照合結果に応じて前記メッセージを転送するステップを備えることを特徴とするメッセージ配信方法。
10. 請求の範囲第９項に記載のメッセージ配信方法において、
    検索された前記ポリシ情報と前記メッセージのヘッダ部情報とを照合し、前記照合結果として配信先のノード情報とヘッダ部情報との対を出力するステップを更に備えることを特徴とするメッセージ配信方法。
11. ネットワークに接続されかつメッセージを送信及び受信する複数のノードと、
    前記ネットワークに接続されかつノードから送信されたメッセージを別のノードに配信するメッセージ配信装置とを備え、
    前記メッセージ配信装置は、
    メッセージ配信先のノード情報が予め定められた関係に従ったツリーデータ構造として格納されたデータベースと、
    前記メッセージのヘッダ部に付加されたこのメッセージの受信ノード情報を基に前記データベースのツリーデータ構造をアクセスして、前記受信ノード情報をルートとするサブツリーに含まれる全てのノード情報を検索する検索手段と、
    検索された全てのノード情報に対応する配信先へ前記メッセージを転送する転送手段とを備えることを特徴とするメッセージ配信システム。
12. 請求の範囲第１１項に記載のメッセージ配信システムにおいて、
    前記ネットワークに接続されかつ前記ノードの前記データベースへの登録要求を受付管理するノード管理装置を更に備えることを特徴とするメッセージ配信システム。
13. 請求の範囲第１２項に記載のメッセージ配信システムにおいて、
    前記ノード管理装置は、前記登録要求を前記メッセージ配信装置へ転送する転送手段を備え、
    前記メッセージ配信装置は、転送された前記登録要求に含まれる前記ノードの位置情報をノード情報として前記データベースのツリーデータ構造に追加することにより前記ノードを登録する登録手段を備えることを特徴とするメッセージ配信システム。
14. 請求の範囲第１１項に記載のメッセージ配信システムにおいて、
    前記メッセージ配信装置と前記ネットワークとの間に設けられたファイヤウォールを備えることを特徴とするメッセージ配信システム。
15. 請求の範囲第１１項に記載のメッセージ配信システムにおいて、
    前記ノードと前記ネットワークとの間に設けられたファイヤウォールを備えることを特徴とするメッセージ配信システム。
16. 請求の範囲第１１項に記載のメッセージ配信システムにおいて、
    前記ノード管理装置と前記ネットワークとの間に設けられたファイヤウォールを備えることを特徴とするメッセージ配信システム。
17. メッセージをネットワークに接続されたノードへ配信するメッセージ配信方法をコンピュータに実現させるためのプログラムであって、
    メッセージ配信先のノード情報が予め定められた関係に従ったツリーデータ構造として格納されたデータベースを、前記メッセージのヘッダ部に付加されたこのメッセージの受信ノード情報を基にアクセスして、前記受信ノード情報をルートとするサブツリーに含まれる全てのノード情報を検索するステップと、
    検索された全てのノード情報に対応する配信先へ前記メッセージを転送するステップと
    をコンピュータに実現させるためのプログラム。
18. 請求の範囲第１７項に記載のプログラムにおいて、
    前記メッセージのヘッダ部とペイロード部とを分離するステップと、
    分離された前記ヘッダ部を解釈して検索を指示するステップと、
    検索されたメッセージ配信先に応じて前記ヘッダ部を書換えるステップと、
    書換えられたヘッダ部と分離された前記ペイロード部とを合成するステップと、
    転送するステップにおいて、合成された前記ヘッダ部及び前記ペイロード部に従って前記メッセージを転送するステップと
    を更にコンピュータに実現させるためのプログラム。
19. 請求の範囲第１８項に記載のプログラムにおいて、
    前記データベースに前記ノード情報と、前記メッセージ配信先を決定するための方針を定めたポリシ情報との対を前記ツリーデータ構造として格納するステップと、
    検索するステップにおいて、前記ノード情報とポリシ情報との対を検索するステップと、
    転送するステップにおいて、検索された情報に従って前記メッセージを転送するステップと
    を更にコンピュータに実現させるためのプログラム。
20. 請求の範囲第１９項に記載のプログラムにおいて、
    転送するステップにおいて、検索されたポリシ情報と前記メッセージのヘッダ部情報との照合結果に応じて前記メッセージを転送するステップをコンピュータに実現させるためのプログラム。
21. 請求の範囲第２０項に記載のプログラムにおいて、
    検索された前記ポリシ情報と前記メッセージのヘッダ部情報とを照合し、前記照合結果として配信先のノード情報とヘッダ部情報との対を出力するステップを更にコンピュータに実現させるためのプログラム。

Images