(57)【要約】【課題】  従来の複数のノードを経由するメッセージ配信で、変換作業の必要な複数のメッセージが混在した場合は想定されていない。  本発明の目的は、複数の変換作業の必要なメッセージが混在するメッセージ配信において、ノードの状況に応じて高負荷のノードにメッセージの変換が偏らないよう柔軟に制御可能なメッセージ配信方法を実現することにある。【解決手段】  各ノードでのリソースの使用状況等のステータスを診断し、その診断結果に基づき、各ノード毎のメッセージ中継方法を定義している（メッセージの変換を行うかどうかを決定する情報を含む）メッセージ中継ポリシーを、動的に変更することで、高負荷であるノードで変換作業が行われることを避けることができる。【選択図】図１
2012156734.tif 000002
【特許請求の範囲】
【請求項１】
複数のノードを経由し、前記複数のノードいずれかで変換が必要なメッセージが存在するメッセージの配信を制御するメッセージ配信制御装置であって、
ノードの動作状況について、複数のレベルに分けた指標を示す診断ルールＩＤと対応付けて記憶する手段と、
前記診断ルールＩＤ毎に、前記複数のノードそれぞれが記憶しており、前記変換の要否を含むメッセージの中継方法を示すメッセージ中継ポリシーを更新する為の制御内容を記憶する手段と、
前記複数のノードそれぞれから当該ノードの動作状況を示す監視情報を取得する手段と、
前記取得した監視情報に対応する診断ルールＩＤを特定する手段と、
前記特定された診断ルールＩＤに対応する制御内容に基づいて、前記複数のノードのうち少なくとも一部のノードに対して、メッセージ中継ポリシーの更新要求を生成し、生成された更新要求を前記複数のノードの少なくとも一部に送信する手段と
を有するメッセージ配信制御装置。
【請求項２】
請求項１に記載のメッセージ配信制御装置において、
前記送信する手段が、前記複数のノードそれぞれに対して、当該ノードにおける診断ルールＩＤに対応する中継ポリシーを送信することで、
前記複数のノードそれぞれが記憶している中継ポリシーに対して、送信された中継ポリシーを上書きすることで前記更新を可能にすることを特徴とするメッセージ配信制御装置。
【請求項３】
請求項１または請求項２いずれかに記載のメッセージ配信制御装置であって、
前記記憶する手段はオペレータ通知要否のフラグを更に記憶し、
前記オペレータ通知要否のフラグが要の場合、前記特定された診断ルールＩＤに基づいて処理するかどうかオペレータの承認要否を判断し、必要に応じてオペレータ端末に対して、判断要求をアラート発信する手段を
有することを特徴とするメッセージ配信制御装置。
【請求項４】
複数のノードを経由し、前記複数のノードいずれかで変換が必要なメッセージが存在するメッセージの配信を制御するメッセージ配信制御方法であって、
ノードの動作状況について、複数のレベルに分けた指標を示す診断ルールＩＤと対応付けて記憶し、
前記診断ルールＩＤ毎に、前記複数のノードそれぞれが記憶しており、前記変換の要否を含むメッセージの中継方法を示すメッセージ中継ポリシーを更新する為の制御内容を記憶し、
前記複数のノードそれぞれから当該ノードの動作状況を示す監視情報を取得し、
前記取得した監視情報に対応する診断ルールＩＤを特定し、
前記特定された診断ルールＩＤに対応する制御内容に基づいて、前記複数のノードのうち少なくとも一部のノードに対して、メッセージ中継ポリシーの更新要求を生成し、生成された更新要求を前記複数のノードの少なくとも一部に送信するステップと
を有するメッセージ配信制御方法。
【請求項５】
請求項４に記載のメッセージ配信制御方法において、
前記送信するステップが、前記複数のノードそれぞれに対して、当該ノードにおける診断ルールＩＤに対応する中継ポリシーを送信することで、
前記複数のノードそれぞれが記憶している中継ポリシーに対して、送信された中継ポリシーを上書きすることで前記更新を可能にすることを特徴とするメッセージ配信制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークを介して送信されるメッセージに、その送信途中で変換処理が必要なメッセージが存在する場合の、当該メッセージに対する変換処理の制御に関する。この変換処理が必要なメッセージが存在するとは、（１）メッセージ自身に基づく理由により変換が必要な場合と、（２）受信側に、送信されたメッセージをそのまま受信できず、変換が必要な装置が存在しているために変換が必要になることを指す。この中でも特に、複数ノードを経由するメッセージ配信に関する。
【背景技術】
【０００２】
現在、メッセージ配信が一般的になされているが、送信側と受信側の仕様の違いなどにより、受信側が送信されたメッセージをそのまま受信できない、ないし受信したデータを処理できないことがある。このために、その配信経路で、メッセージを変換することがなされている。
【０００３】
例えば、特許文献１のように、異なる通信事業者に対応した通信端末間において、通信事業者独自の絵文字を電子メールに含めて送受信しても、文字化けが生ずることなく正常に送受信して表示する為、電子メールをメールサーバで変換して受信者に届ける技術について知られている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００４−２９７１２３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
特許文献１は、メールを送信途中のメールサーバにて、電子メールを変換して送信する技術について開示されている。しかしながら、特許文献１では、予めメッセージを変換する装置がメールサーバと、特定されている。このために、変換する装置での変換処理ないし変換処理が必要なメッセージの配信数が多い場合やこの変換する装置で他の情報処理を行っており負荷が掛かっている場合、その装置での変換負荷が増大ないし負荷集中してしまうとの問題が生じる。その中でも、複数の受信装置にメッセージを送信する場合、変換負荷の増加により、このような装置を経由してメッセージが送信される受信装置において、当該メッセージの受信が他の受信装置より遅くなるとの問題が生じる。さらに、以下のようなマルチキャストの場合、この問題が特に顕著になる。例えば、複数の証券市場に上場している企業が複数の証券市場に会社情報等をマルチキャストで複数のノードを経由して送信する場合、上場企業は、株価等に影響する会社情報を適時・適切に公開することが義務付けられており、複数市場に上場している場合は、市場間での不公平が生じないように、複数の上場市場に対して、同一情報をできるだけ等しいタイミングで配信する必要があるが、変換負荷の増加によりタイミングがずれることが生じる。
【０００６】
例えば株価情報を送信装置から受信装置へ中継ノードＡ、中継ノードＢを経由して送信するケースを考える。送信装置から送信されるメッセージと受信装置で受信できるメッセージが異なる場合、送信装置、中継ノードＡ、Ｂのいずれかでメッセージ変換が必要となる。仮に中継ノードＡでメッセージ変換を行う場合に、中継ノードＡの負荷が高いとメッセージの転送に遅延が発生する。特に送信装置が他の中継ノードにもメッセージを配信している場合には、中継ノードＡを経由しメッセージを受信する受信装置は、中継ノードＡを経由しない受信装置よりもメッセージを受け取る遅延が大きくなる。もし中継ノードＢでメッセージ変換が可能でありかつその負荷が低ければ、メッセージ変換を中継ノードＢに割り当てた方が、受信装置のメッセージ受信の遅延を小さく抑えることができる。
【０００７】
ここで、この配信されるメッセージについて、扱えるメッセージがそれぞれの受信装置で異なる、例えば、ある受信装置はテキスト形式は扱えるがバイナリ形式が扱えない、他の装置はいずれも扱えることがある。また、各受信装置で扱えるメッセージと扱えないメッセージ、例えば、各受信装置がテキスト形式は扱えるがバイナリ形式は扱えない場合に、送信装置がバイナリ形式とテキスト形式の両方を送信することがある。これらの場合、受信装置によって、複数のノードのいずれかでバイナリ形式からテキスト形式に変換されたメッセージを受け取る必要がある受信装置があれば、バイナリ形式のまま、受け取ることも可能な装置もある。この場合、バイナリ形式で受ける受信装置と、テキスト形式で受ける受信者で受け取る時差が大きくなってしまうという課題が顕著になる。
【０００８】
このように、特に、金融業界、例えば、証券の売買注文の判断に直結する情報などは、相手への着信が数秒遅れるだけで、多大な収益／損害に直結するケースにおいては、受信装置にできるだけ時差を少なくしてメッセージを届ける必要がある。
【０００９】
そこで、本発明の目的は、メッセージの変換処理が必要な複数のノードを経由するメッセージ送信において、各ノードの状況に応じてより高負荷のノードでの変換処理を避けるように制御可能なメッセージ配信(送信)を実現することにある。
【課題を解決するための手段】
【００１０】
本発明は、変換処理が必要なメッセージが配信対象のメッセージに含まれる場合、当該変換を実行する装置を、ネットワークに存在するノード(装置)の中から特定ないし変更するものである。例えば、マーケット情報の配信など複数のノードを経由するメッセージ配信において，変換の必要のあるメッセージを混在して送信する場合に関するものである。まず、各ノードでのリソースの使用状況等のステータスを診断し、その診断結果に基づき、各ノード毎のメッセージ中継方法を定義している（メッセージの変換を行うかどうかを決定する情報を含む）メッセージ中継ポリシーを、動的に変更することで、高負荷であるノードで変換作業が行われることを避けることができる。
【発明の効果】
【００１１】
本発明によれば、メッセージの配信において、より適切な変換装置を特定することでネットワーク全体の送信効率が落ちることを防止する効果がある。
【図面の簡単な説明】
【００１２】
【図１】マルチキャストメッセージ配信制御システム4000の全体像である
【図２】ネットワーク監視部4100の構成である
【図３】ネットワーク監視処理フローである
【図４】ネットワークプロファイル管理テーブル4140の構成である
【図５】ネットワーク監視条件管理テーブル4150の構成である
【図６】メッセージ中継ノード3100の基本構成である
【図７】ステータス管理テーブル3180の構成である
【図８】ネットワーク監視履歴管理テーブル4160の構成である
【図９】ネットワーク診断部4200の構成である
【図１０】ネットワーク診断処理フローである
【図１１】ネットワーク診断ルール管理テーブル4240の構成である
【図１２】ネットワーク診断履歴管理テーブル4250の構成である
【図１３】ネットワーク制御部4300の構成である
【図１４】ネットワーク制御処理フローである
【図１５】ネットワーク制御テーブル4340の構成である。
【図１６】メッセージ中継ポリシー管理テーブル3190の基本構成である
【図１７】ネットワーク制御履歴管理テーブル4340の構成である
【発明を実施するための形態】
【００１３】
以下、図1〜図17を用いて、マーケット情報の配信など、マルチキャストの場面において、性能特性の異なる複数のメッセージが混在する場合において、各ノードの変換性能，空きリソース，各メッセージにおけるメッセージの種類，ネットワーク負荷等を考慮して，伝送に用いるメッセージや変換ノードを動的に制御するものを一例として、実施例を説明する。ここでいう、性能特性とは、メッセージの圧縮率/変換効率が異なることを指している。一般に、圧縮率が高くサイズが小さいメッセージは伝送効率は優れるが、メッセージ変換の処理効率は低下する。これらはトレードオフの関係にあり、通信インフラの状況や各ノードのメッセージフォーマットの対応状況に応じ使い分ける。なお、本実施例はマルチキャストの場合についてのものだが、これに限定されるものではない。
【００１４】
図１は、マルチキャストメッセージ配信制御システムの全体像である。マーケット情報等の送信元となる業務システムA 1000と、マーケット情報等を受信する業務システムB,C,D 2000はマルチキャスト通信ネットワーク3000にて接続されており、マルチキャスト通信ネットワーク3000は、メッセージの伝送経路の制御やメッセージの変換を行うメッセージ中継ノード3100から構成される。
【００１５】
これらの個々の中継ノード3100の状態を監視して、通信ネットワークを制御するマルチキャストメッセージ配信制御システム4000は、個々の中継ノード3100の状態を監視するネットワーク監視部4100、監視結果から各中継ノード3100の制御要否を判断するネットワーク診断部4200、診断結果にもとづき、各中継ノード3100に対して制御指令を伝達するネットワーク制御部4300から構成され、マルチキャストメッセージ配信制御システム4000は、ネットワーク運用管理端末5000と接続される。
【００１６】
次に、マルチキャストメッセージ配信制御システム4000の中核機能である、ネットワーク監視部4100、ネットワーク診断部4200、ネットワーク制御部4300の機能概要を説明する。なお、これらの各構成要件は、コンピュータプログラムで構成することがより好適である。つまり、メッセージ配信制御システムの有するＣＰＵの如き演算装置がコンピュータプログラムに従って後述する各処理を実行する。また、他の装置での処理も同様にコンピュータプログラムに従って実行されることがより好適である。
【００１７】
ネットワーク監視部4100は、監視対象であるマルチキャスト通信ネットワーク3000を構成する各中継ノード群とそれぞれ双方向通信を行い、監視対象の中継ノード3100の状態値を監視する。
【００１８】
さらに、状態値から何らかの問題を検出した場合にはネットワーク診断部4200に対して検出した問題点の診断を要求する。
【００１９】
図2は、ネットワーク監視部4100の構成である。ネットワーク監視部4100は、マルチキャスト通信ネットワーク3000を構成する各中継ノード3100との通信を制御する対ネットワーク通信制御部4110、ネットワーク診断部4200との通信を制御する対ネットワーク診断部通信制御部4120、システム運用管理端末との通信を制御する対システム運用管理端末通信制御部4130、ネットワーク監視条件テーブル4140とネットワーク監視履歴テーブル4150、各中継ノード3100のMACアドレス、IPアドレス、性能・機能情報などの静的プロファイル情報を管理するネットワークプロファイル管理テーブル4160と連携して、個々の中継ノード3100の状態を監視・管理するネットワーク監視処理4170から構成される。なお、オペレータは、システム運用管理端末を介して、各中継ノード3100の監視条件を修正できる。
【００２０】
続いて、ネットワーク監視部4100の処理概要を説明する。
【００２１】
図3は、ネットワーク監視部4100の処理フローである。まず、ステップ100にて、ネットワーク監視部4100はネットワーク監視条件テーブル4150を参照して監視対象ノードと監視方法を決定し、ステップ110にて監視要求メッセージを監視対象の中継ノード3100に送信する。
【００２２】
図4は、ネットワークプロファイル管理テーブル4140の構成である。ネットワークプロファイル管理テーブル4140は、各メッセージ中継ノード3100の静的属性情報を管理するテーブルであり、MACアドレス、IPアドレス、ハードウェア仕様、ソフトウェア仕様、接続ノードID、稼動開始日等の情報を管理する。
【００２３】
図5は、ネットワーク監視条件管理テーブル4150の構成である。ネットワーク監視条件4150は、中継ノード3100毎に定義され、条件項目としては監視要否を設定する「監視要否フラグ」、緊急・通常など監視の重要度、すなわち、監視の厳しさ（頻度ないし優先度合い）を示す複数のレベルを定義する「監視モード」、監視モード毎の監視時隔を設定する「監視時隔」、「次回監視予定時刻」、「監視方法」、診断の要否判断の指標を設定する「判断基準」等を定義する。なお、本実施例においては、監視条件テーブルに設定された次回監視予定時刻に従って監視対象の中継ノード3100を決定しているが、全ての中継ノード3100に対して定期的に一斉監視を行う方法や、周期的に監視対象をローテーションする方法をとってもよい。
【００２４】
次に、中継ノード3100ではステップ120にて監視要求メッセージを受信する。監視要求メッセージは、ノードIDおよびノードIDを検索キーとしてネットワーク監視条件管理テーブル4150から取得可能な情報から構成される。
【００２５】
次に、メッセージ中継ノード3100では、ステップ130にて自ノード3100と自ノード3100に接続される近接ノード3100のステータス情報を取得し、ステップ140にて図８の監視ＩＤ毎に設定される情報（メッセージ変換効率など）であるステータス情報をネットワーク監視処理に送信する。
【００２６】
図6は、メッセージ中継ノード3100の基本構成である。(本実施例ではメッセージ中継ノードの他、単に中継ノード、自ノード、近接ノード、監視ノード等でも表現される。)メッセージ中継ノード3100は、ネットワーク監視部4100との通信を制御する対ネットワーク監視部通信制御部3110、ネットワーク制御部4300との通信を制御する対ネットワーク制御部通信制御部3120、自中継ノード3100と接続される他の中継ノード3100との通信を制御する対中継ノード通信制御部3130、中継ノードステータス管理テーブル3140とメッセージ中継ポリシー3190と連携し、他の中継ノード3100とのメッセージ送受信処理を行う送受信処理3160、受信したメッセージに対して、必要に応じてメッセージの変換を行う中継処理3170、受信したメッセージの中継ポリシーを管理する中継ポリシー管理処理3180、自ノードおよび自ノードに接続される周辺ノードの状態を管理するステータス管理処理3170から構成される。このメッセージ中継ノード3100はノードを意味しており、ノードの種類を特定するものではない。
【００２７】
図7は、ノードステータス管理テーブル3180の構成である。ノードステータス管理テーブル3180は、個々の中継ノード3100、および中継ノード3100に直接接続される上流ノード、下流ノードの動的な通信属性の状態値を管理するテーブルであり、送受信キューの余裕度、CPU負荷、メモリ使用量などが属性値として管理される。なお、メッセージ中継ポリシー管理テーブル3190の構成については後述する。
【００２８】
続いて、ネットワーク監視部4100では、ステップ150でステータス情報を受信し、ステップ160にてネットワーク監視履歴管理テーブル4160を更新する。
【００２９】
図8は、ネットワーク監視履歴管理テーブル4160の構成である。監視履歴は中継ノード3100毎かつ時系列に設定される監視ID毎に管理する。監視履歴としての管理情報としては、単位時間あたりのメッセージ変換量を示すメッセージ変換効率、受信して処理待ちの状態にある受信メッセージキューの状態を示す入力メッセージキュー、出力先ノードへの送信メッセージキューの状態を示す出力メッセージキュー、CPU使用率、メモリ使用等から構成される。
【００３０】
次に、ネットワーク監視部4100は、ステップ170にてネットワーク監視履歴管理テーブル4160を参照し、監視対象ノードの診断要否を判断する。診断要否の具体的な方法に関しては、あらかじめ閾値を設定しておく方法や、システム運用管理端末にアラートを出してオペレータが判断するといった方法が考えられる。ステップ170で診断不要と判断された場合は、ステップ100に戻り、診断が必要と判断した場合にはステップ180にて監視履歴をもとに診断要求を作成し、これを対ネットワーク診断部通信制御部4120を介してネットワーク診断部4200に送信する。診断要求メッセージは、ノードID、監視IDおよびノードIDと監視IDを検索キーにネットワーク監視履歴管理テーブル4160を参照することで取得可能なメッセージ変換効率、CPU使用率、メモリ使用率などの属性情報から構成される。
【００３１】
ネットワーク診断部4200は、ネットワーク監視部4100から受信した診断要求メッセージに対してあらかじめ定義されたネットワーク診断ルール（図11の説明で後述するがステータス情報をレベル分けした指標により定義されるものを言う）を適用することにより、ネットワークの制御要否と制御内容（これは後述するネットワーク制御ルールで判別される）を判断する。また、制御内容については、必要に応じてオペレータ判断を加味することも可能である。
【００３２】
図9は、ネットワーク診断部4200の構成である。ネットワーク診断部4200は、ネットワーク監視部4100との通信を制御する対ネットワーク監視部通信制御部4210、ネットワーク制御部4300との通信を制御する対ネットワーク制御部通信制御部4220、システム運用管理端末との通信を制御する対システム運用管理端末通信制御部4230、ネットワーク診断ルール4240、ネットワーク診断履歴4250と連携してメッセージ中継ノード3100の状態を診断するネットワーク診断処理4260から構成される。なお、オペレータは必要に応じて、システム運用管理端末からネットワーク診断ルール管理テーブル4240を修正することができる。
【００３３】
続いて、ネットワーク診断部4200の処理概要を説明する。
【００３４】
図10は、ネットワーク診断処理フローである。まず、ステップ200にてネットワーク監視部4100は診断要求メッセージをネットワーク診断処理に送信すると、ネットワーク診断部4200では、ステップ210にて診断要求を受信し、ステップ220にてネットワーク診断ルールを参照する。
【００３５】
図11は、ネットワーク診断ルール管理テーブル4240の構成である。ネットワーク診断ルール管理テーブル（ノットワーク診断ルール）4240は、メッセージ変換効率、ＣＰＵ使用率、メモリ使用率等からなる監視情報をレベル分けした指標の組合せに応じて定義される。ここで、このレベルの定義としては、例えば、ＣＰＵ使用率０％〜２０％までをレベル１、２０％〜４０％までをレベル２、４０％〜６０％までをレベル３、６０％〜８０％までをレベル４、８０％〜１００％までをレベル５というようにユーザが任意に設定することができる。そして、この診断ルールは、ルールＩＤ毎に、定義された各レベルについて、当該レベルに応じて中継ノード3100の中継ポリシー管理テーブル3190をどのように書き換えるかを定めるものである。また、ネットワーク診断ルール4240毎にオペレータ通知の要否を表すフラグを記憶してもよい。これにより、自動での制御のみならず、オペレータに通知してオペレータの判断を仰ぐように設定することも可能となる。ここで、メッセージ変換効率とは、例えばバイナリ形式のメッセージをテキスト形式のメッセージに変換する場合の速度等の、変換の処理能力を指すが、これは変換効率が依存するＣＰＵ等の処理速度を指標としてもよいし、データ変換のベンチマーク等の指標を使ってもよい。監視情報は各中継ノード3100の負荷を表す指標であり、ＣＰＵ、メモリ等の情報に限定されるものではない。
【００３６】
次に、ネットワーク診断部4200は、ステップ230にて、診断要求を診断ルールの監視情報が示す条件部と照合することにより、ネットワークの診断を実施する。診断要求で要求される情報は、各中継ノード3100の監視ＩＤ毎のメッセージ変換効率、ＣＰＵ使用率、メモリ使用率等の情報が具体的な例として含まれ、各中継ノード3100の処理状況ないし負荷状況を示す監視情報である。照合の結果、適合するルールが存在した場合には、その監視情報に対応付いた診断ルールＩＤを特定する。更に、ネットワーク診断部4200は、ステップ240にて診断結果をネットワーク診断履歴管理テーブル4250に格納する。
【００３７】
図12は、ネットワーク診断履歴管理テーブル4250の構成である。ネットワーク診断履歴管理テーブル4250は、診断ID毎に、監視情報と診断情報を管理する。
【００３８】
次に、ネットワーク診断部4200は、ステップ250にて診断ルール4240のオペレータ通知要否を参照し、当該ルール適用にあたってのオペレータによる承認要否を判定する。ここでオペレータによる判断が不要と判断された場合は、ステップ280に至り、オペレータによる判断が必要と判定された場合は、ネットワーク診断部4200は、ステップ260にて対ネットワーク運用管理端末通信制御部4230を介してシステム運用管理端末に診断内容をアラート提示し、診断結果のオペレータによる承認を要求する。ネットワーク運用管理端末5000では、ステップ270にてオペレータによる判断内容をネットワーク診断処理に返す。
【００３９】
次に、ネットワーク診断部4200は、ステップ280で、オペレータからの回答を受信、あるいはオペレータによる判断が不要な診断結果を受け取ると、診断結果とオペレータ判断を統合して制御要否を判定する。制御の要否については、例えば診断ルールＩＤ００１〜００４は制御否、００５〜nは制御要のように、制御ルール毎に決めてもよいし、オペレータ判断の要否を見て決めてもよいし、その両方を考慮して決めてもよい。ここで制御が必要と判断された場合には、ステップ290にて制御要求メッセージ作成し、これを対ネットワーク制御部通信制御部を介してネットワーク制御処理に送信する。なお、制御要求メッセージは、どの中継ノード3100の制御であるかを特定する為のノードID、制御ルールＩＤから構成される。
【００４０】
ネットワーク制御部4300は、ネットワーク診断部4200から受信した制御要求メッセージにもとづいて、制御対象の中継ノード3100にて管理される、つまりノードＩＤにより、中継ノード3100が特定され、特定された中継ノード3100に制御ルールＩＤで特定された制御内容で、メッセージ中継ポリシー3190が更新される。そのことにより、ネットワーク全体のマルチキャスト通信を制御する。ここで、制御ＩＤとは、診断ルールＩＤが特定され、制御が必要と判断された場合に、各診断ルールＩＤに1対1に対応した制御ルールＩＤが割当てられ特定されるものである。その為、制御ルールＩＤではなく、診断ルールＩＤと制御内容を対応付けて管理して、診断ルールＩＤにより制御内容が特定されることとしてもよい。
【００４１】
図13は、ネットワーク制御部4300の構成である。ネットワーク制御部4300は、各メッセージ中継ノード3100との通信を制御する対ネットワーク通信制御部4310、ネットワーク診断部4200との通信を制御する対ネットワーク診断部通信制御部4320、システム運用管理端末に対して制御内容を通知する対システム運用管理端末通信制御部4330、ネットワーク制御履歴4340とネットワーク制御ルール4350と連携してメッセージ中継ノード3100のメッセージ中継ポリシー3190を制御するネットワーク制御処理4360から構成される。
【００４２】
続いて、ネットワーク制御部4300の処理概要を説明する。
【００４３】
図14は、ネットワーク制御部4300の処理フローである。まず、ステップ300にてネットワーク診断部4200は制御要求メッセージをネットワーク制御部4300に送信すると、ネットワーク制御部4300では、ステップ310にて制御要求を受信し、ステップ320にて制御要求メッセージにもとづいて制御指令を生成し、ステップ330にて制御指令をメッセージ中継ノード3100に送信する。メッセージ中継ノード3100では、ステップ350にて、制御指令に応じてメッセージ中継ポリシー管理テーブル3190を修正し、修正内容を制御結果としてネットワーク制御部4300へ送信する。ここでいう制御指令とは、メッセージ中継ポリシー管理テーブル3190を書き換える為のコマンドでもよいし、後述のネットワーク制御ルールの制御ルールＩＤもしくは診断ルールＩＤで特定された、ポリシーＩＤとポリシーＩＤ毎に対応付けられた制御内容を含んだものであってもよい。また、各中継ノード3100それぞれに対して、当該ノードにおける制御ルールＩＤもしくは診断ルールＩＤに対応する中継ポリシーを送信することで、前記複数のノードそれぞれが記憶しているメッセージ中継ポリシー管理テーブル3190に対して、送信された中継ポリシーを上書きすることとしてもよい。
【００４４】
図15は、ネットワーク制御ルール4340の構成図である。特定された診断ルールＩＤに1対１に対応する制御ルールＩＤ毎にメッセージ中継ポリシー管理テーブル3190のメッセージ中継方法を制御内容で書き換えるために定義するテーブルである。例えば制御ルールＩＤ００１のポリシーＩＤ００３の制御内容がメッセージ変換要否を要に変更となっていれば、制御ルールＩＤ００１が指定された場合に、メッセージ中継ポリシー管理テーブル3190内のポリシーＩＤ００３のメッセージ変換要否を要に書き換える。ここで、制御ＩＤを介さず、診断ルールＩＤと各ポリシーＩＤ、メッセージ中継ポリシー管理テーブル3190のメッセージ中継方法を書き換える制御内容と対応づけてもよい。
【００４５】
図16は、メッセージ中継ポリシー管理テーブル3190の構成である。メッセージ中継ポリシー管理テーブル3190は、各中継ノード3100毎に定義される、条件に応じたメッセージ中継方法を規定するテーブルであり、想定されるメッセージ中継条件のパターンに対して、メッセージ変換の要否、変換要の場合の具体的な変換方法等を規定する。
【００４６】
次に、ネットワーク制御部4300では、ステップ370にて制御結果を受信し、ステップ380にて制御結果を制御履歴管理テーブル4340に格納する。
【００４７】
このテーブルでいうメッセージ中継条件とは、中継ノード3100に送られてくるメッセージのメッセージ書式（textやbinary等）や、各メッセージで指定される業務要件（遅延不可のメッセージか、遅延可能なメッセージかのフラグ）、メッセージを受けた場合の中継ノード3100のリソース状態等の、メッセージの状態や、中継ノード3100のリソース状態等を表すものである。このメッセージ中継条件に対応したメッセージ中継方法を、様々なメッセージ中継条件の場合に対応させて記憶する。それにより、そのメッセージの状態や、リソース状況に応じて、どのようにメッセージの中継方法を適用するかを管理することができる。ここでいうメッセージ中継方法とは、メッセージを変換するかどうかを決めるメッセージ変換要否やその変換方法（効率を優先するのか、時間を優先するのか等）を決めている。このメッセージ中継方法は先に述べたように各中継ノード3100の状況に応じて、自動で更新される。
【００４８】
図17は、ネットワーク制御履歴管理テーブル4340の構成である。ネットワーク制御履歴管理テーブル4340は、制御ＩＤにて管理されており、制御ＩＤ毎に、制御対象ノードＩＤ、制御対象のポリシーＩＤ、メッセージ変換方法等の、メッセージ中継ポリシー3190が更新された内容はこのネットワーク制御履歴管理テーブル4340に書き込まれ管理される。
【符号の説明】
【００４９】
１０００  送信側業務システム
３０００  マルチキャスト通信ネットワーク
３１００  メッセージ中継ノード
２０００  受信側業務システム
４０００  マルチキャストメッセージ配信制御システム
５０００  ネットワーク運用管理端末
【図１】
2012156734.tif 000003
【図２】
2012156734.tif 000004
【図３】
2012156734.tif 000005
【図４】
2012156734.tif 000006
【図５】
2012156734.tif 000007
【図６】
2012156734.tif 000008
【図７】
2012156734.tif 000009
【図８】
2012156734.tif 000010
【図９】
2012156734.tif 000011
【図１０】
2012156734.tif 000012
【図１１】
2012156734.tif 000013
【図１２】
2012156734.tif 000014
【図１３】
2012156734.tif 000015
【図１４】
2012156734.tif 000016
【図１５】
2012156734.tif 000017
【図１６】
2012156734.tif 000018
【図１７】
2012156734.tif 000019