(57)【特許請求の範囲】
【請求項１】
個々の通信装置を管理するエレメント管理システム、複数の前記通信装置からなるネットワーク全体を管理するネットワーク管理システム、通信プロバイダのカスタマサービス管理に使用するサービス管理システム及び通信プロバイダの経営戦略に使用するビジネス管理システムからなる多階層管理システムにおいて、
前記管理システムからのイベントメッセージを全て受信し、
受信したイベントメッセージの送信元の管理システムが前記エレメント管理システムであった場合に、該イベントメッセージを内部に蓄えるとともに、予め記憶されているイベントルートデータに基づく送信先の管理システムに対して、このイベントメッセージを転送し、
受信したイベントメッセージの送信元の管理システムが前記エレメント管理システムでない場合に、この送信元の管理システムに対して該イベントメッセージが送信済みであることを示すフラグを内部に記憶することによりイベントメッセージの送信状態を管理するとともに、前記イベントルートデータに基づいて、受信したイベントメッセージを次の管理システムに対して転送することにより前記管理システム間のイベントを送信する手段と、
前記管理システムがイベント確認メッセージを受信する前にタイムアウトを検出した場合に内部に蓄えておいたイベントメッセージを再送信する手段と、
前記管理システムのいずれかとの送受信パスの確立がされている場合に、前記イベントメッセージが送信済みであることを示すフラグに基づいて、内部にキューイングされているイベントメッセージが送信されていない管理システムに対して送信する手段と
からなるイベント管理装置を具備することを特徴とする多階層管理システム。
【請求項２】
前記イベント管理装置は、前記イベントルートデータを入力して記憶する手段をさらに備えたことを特徴とする請求項１に記載の多階層管理システム。
【請求項３】
前記イベントメッセージを送信する手段は、送信先の管理システムとの間の送信及び受信の両方の通信パスが確立されている場合に、前記イベントメッセージを送信することを特徴とする請求項１または２に記載の多階層管理システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
この発明は、階層構造を構成する複数の管理システムからなる多階層管理システムに関する。
【０００２】
【従来の技術】
通信サービスを提供するネットワークの構成、障害、性能などを管理するエレメント管理システム、ネットワーク管理システムと管理システムの多階層構造において上位レイヤに位置するサービス管理システム、ビジネス管理システムにおいてイベントの処理は重要である。理由は、イベントにはネットワークの障害発生を通知するためのアラームが含まれており、アラームが発生した場合には迅速な障害復旧と通信サービスの利用者へのケアが必要だからである。従って、イベントが管理システム内部、あるいは管理システム間でロストされる事態はクリティカルな問題となる。従来のネットワーク管理システムにおけるイベント通知方式が特開平9-247146、特開平4-345248に記載されている。これらの特開平すべてに共通する事は、通信装置とその装置を管理するネットワーク管理システム間のイベント通知方式にのみ言及されており、多階層からなる管理システム間のイベント通知には言及されていないことである。
【０００３】
【発明が解決しようとする課題】
特開平9-247146で記載されたネットワーク機器はシーケンス番号付与手段を備えており、ネットワーク機器でイベントが発生するとイベント番号がシーケンスに設定される。ネットワーク装置であるワークステーションはトラップを受信するとシーケンス番号に基づき、損失トラップ情報発生の有無の検出がなされ、損失トラップの情報を検出すると警報出力がなされることになる。
しかし、この従来技術には、次のような問題点があった。
第一の問題点は、警報出力がなされた場合にロストされたイベントをワークステーションが取得するメカニズムについて記述されていない点である。
その理由は、上述したようにイベントのロストは通信サービスにおいてクリティカルな問題となるからである。
第二の問題点は、ネットワーク機器がイベントを再送するためにはイベントを記憶装置に記憶する必要があり、そのために必要なリソースが膨大になる点である。
その理由は、ネットワーク機器に記憶装置を大量に実装することはコスト増大となるからである。
特開平4-345248に記載されたネットワーク管理システムの被管理装置において、短時間に膨大な量の障害イベントが発生した場合に、通信処理にかかる負荷の急激な上昇を押さえるために、イベント数を削除するための判定基準値を被管理装置に設定し、その基準値を超えた場合には重大でないイベントをフィルタで除外する。このことにより被管理装置とネットワーク管理システム間のトラフィックの増加を押さえるものである。
しかし、この従来技術には、次のような問題点があった。
その問題点は、被管理装置とネットワーク管理システム間のイベントのロストやネットワーク管理システムがメンテナンスなどのためにシャットダウンされている場合の再送メカニズム、ネットワーク管理システムが稼動しているか否か、イベントを送信するための通信パスがアクティブか否かを調べるためのヘルスチェックなどについて言及されていない点である。
その理由は、上述したようにイベントのロストは通信サービスにおいてクリティカルな問題となるからである。
【０００４】
この発明は、このような背景の下になされたもので、多階層管理システム群の構成要素である管理システム間のイベント通知において、個々の管理システムの処理内容を簡略化し、イベントルートの設定やイベント送信のトラッキングなどのオペレーションを容易にすることができる多階層管理システムを提供することを目的とする。
【０００５】
【課題を解決するための手段】
請求項１記載の発明は、個々の通信装置を管理するエレメント管理システム、複数の前記通信装置からなるネットワーク全体を管理するネットワーク管理システム、通信プロバイダのカスタマサービス管理に使用するサービス管理システム及び通信プロバイダの経営戦略に使用するビジネス管理システムからなる多階層管理システムにおいて、前記管理システムからのイベントメッセージを全て受信し、受信したイベントメッセージの送信元の管理システムが前記エレメント管理システムであった場合に、該イベントメッセージを内部に蓄えるとともに、予め記憶されているイベントルートデータに基づく送信先の管理システムに対して、このイベントメッセージを転送し、受信したイベントメッセージの送信元の管理システムが前記エレメント管理システムでない場合に、この送信元の管理システムに対して該イベントメッセージが送信済みであることを示すフラグを内部に記憶することによりイベントメッセージの送信状態を管理するとともに、前記イベントルートデータに基づいて、受信したイベントメッセージを次の管理システムに対して転送することにより前記管理システム間のイベントを送信する手段と、前記管理システムがイベント確認メッセージを受信する前にタイムアウトを検出した場合に内部に蓄えておいたイベントメッセージを再送信する手段と、前記管理システムのいずれかとの送受信パスの確立がされている場合に、前記イベントメッセージが送信済みであることを示すフラグに基づいて、内部にキューイングされているイベントメッセージが送信されていない管理システムに対して送信する手段とからなるイベント管理装置を具備することを特徴とする。
請求項２記載の発明は、前記イベント管理装置は、前記イベントルートデータを入力して記憶する手段をさらに備えたことを特徴とする。
請求項３記載の発明は、前記イベントメッセージを送信する手段は、送信先の管理システムとの間の送信及び受信の両方の通信パスが確立されている場合に、前記イベントメッセージを送信することを特徴とする。
【０００６】
【発明の実施の形態】
本発明は、多階層管理システム群(図1の107)の構成要素である管理システム(図1の102、103、104、105)間のイベント通知において、下記の機能をイベント管理装置(図1の101)に実装することにより、個々の管理システム(図1の102、103、104、105)の処理内容を簡略化し、イベントルートの設定やイベント送信のトラッキングなどのオペレーションを容易にするものである。
【０００７】
・ 管理システム(図1の102、103、104、105)間で送信されるイベントの受信確認
・ イベントメッセージのバッファリングと送信状態管理機能
・ イベント送信のリトライ設定
・ 管理システム(図1の102、103、104、105)のヘルスチェック
【０００８】
以下に本発明の特徴を表す動作を記述する。
イベント受信装置(図1の101)は、管理システム(図1の102、103、104、105)からイベントを受信するとイベントメッセージから送信元管理システム名を読み出す。送信元管理システム名がネットワーク管理システム(図1の104)の場合、イベント受信手段(図2の35)は、受信イベントに含まれるイベントIDをパラメータとしてイベント処理手段(図2の34)に処理を要求する。イベント処理手段(図2の34)はイベント状態管理手段(図2の38)とイベントバッファ管理手段(図2の39)に処理を要求し、両方の処理が終了するまでの状態を管理する。
【０００９】
イベント状態管理手段(図2の38)はイベントIDをパラメータとしてイベント状態記憶部(図2の42)から状態データを読み込み、状態の更新を行う。更新内容は、イベントルートにおいて送信元管理システム名（ネットワーク管理システム(図1の104)）がイベントを送受信済みである事をあらわすフラッグデータ、イベント送信時刻と受信時刻である。このことによりサービス管理システム(図1の103)がネットワーク管理システム(図1の104)に対してイベント受信確認メッセージを送信したり、ネットワーク管理システム(図1の104)がイベントメッセージをバッファリング、再送するメカニズムが不要となるので、管理システム(図1の102、103、104、105)の処理が簡素化される。次にイベント状態管理手段(図2の38)は更新した状態データの送信元管理システム名が前にポイントする管理システム名が、さらに後にポイントする管理システム名を取得する。次に、イベント状態管理手段(図2の38)は後にポイントされるすべての管理システム名において、フラッグデータが書き込まれているか否かを読み込む。ここでは、例として送信元ネットワーク管理システム(図1の104)が前にポイントするエレメント管理システム(図1の105)が、該当ネットワーク管理システム(図1の104)以外にイベントを送信しないイベントルートがイベントルート記憶部(図2の41)に設定されていたとする。この場合、イベントIDとエレメント管理システム名をキーにしてイベントバッファ管理手段(図2の39)に処理を依頼し、イベントコンテンツ記憶部(図2の43)から該当のイベントメッセージを削除する。次に、イベントバッファ管理手段(図2の39)はネットワーク管理システム(図1の104)から受信したイベントメッセージの内容に送信元管理システム名、送信先管理システム名、イベント管理システム(図1の101)がイベントを受信した時刻などを追加して、イベントコンテンツ記憶部(図2の43)に書き込む。
【００１０】
イベント処理手段(図2の34)が、イベント状態管理手段(図2の38)とイベントバッファ管理手段(図2の39)の双方から終了信号を受信すると、イベント送信手段(図2の33)へ処理を要求する。イベント送信手段(図2の33)は、イベントIDと送信元ネットワーク管理システム名をパラメータとして、イベントルート管理手段(図2の37)から次に送信する管理システム名（サービス管理システム(図1の103)）を受け取り、コネクション確率状態管理手段(図2の32)に処理を要求する。送信先管理システムとイベント管理装置(図1の101)間の送受信通信パスが確立されている場合、イベント送信手段(図2の33)は管理システムに対してイベントを送信する。この送受信通信パスが確立のチェック処理により、イベント管理装置の処理を減少させる利点が得られる。
【００１１】
図1を参照すると本実施形態は、本発明の主題であるイベント管理装置101、ネットワークに存在して被管理対象となる通信装置106、複数のコンピュータに実装される多階層管理システム群7から構成される。
【００１２】
イベント管理装置101は、多階層管理システム群107の構成要素である管理システム間のイベントの送受信を管理する装置である。詳細は以降のパラブラフで記述する。
【００１３】
通信装置は、多階層管理システム群107の構成要素であるエレメント管理システム105によって構成情報、障害情報、性能情報などを管理される。
【００１４】
多階層管理システム群107は複数レイヤに区分され、それぞれビジネス管理レイヤ、サービス管理レイヤ、ネットワーク管理レイヤ、エレメント管理レイヤに分類される。
【００１５】
ビジネス管理レイヤはビジネス管理システム102によって実現され、通信プロバイダの経営戦略に使用される。サービス管理レイヤはサービス管理システム103によって実現され、主に通信プロバイダのカスタマサービス管理に使用される。ネットワーク管理レイヤはネットワーク管理システム104によって実現され、複数の通信装置からなるネットワーク全体、またはサブネットワークを管理する。エレメント管理レイヤはエレメント管理システム105によって実現され、個々の通信装置を管理する。ビジネス管理システム102、サービス管理システム103、ネットワーク管理システム104、エレメント管理システム105はコンピュータ上に実装され、多階層における各々の上下関係は決定されている。また、通信装置106から通知されるイベントの転送順序も固定であり、エレメント管理→ネットワーク管理→サービス管理→ビジネス管理の順序となる。
【００１６】
本実施形態におけるイベント通知経路を図1の直線で示す。通信装置106→エレメント管理システム105→イベント管理装置101→ネットワーク管理システム104→イベント管理装置101→サービス管理システム103→イベント管理装置101→ビジネス管理システム102である。
【００１７】
次に、イベント管理装置(図1の101)について詳細に記述する。
図2を参照するとイベント管理装置(図1の101)はキーボードなどの入力装置1、ディスプレイ装置や印刷装置などの出力装置2、多階層管理システム群を構成する管理システムとプログラム制御により動作するデータ処理装置3、情報を記憶する記憶装置4から構成される。
【００１８】
記憶装置4はイベントID記憶部44、イベントコンテンツ記憶部43、イベント状態記憶部42、イベントルート記憶部41を備えている。
【００１９】
通信装置(図1の106)から送信されたすべてのイベントはイベント管理装置(図1の101)に送信され、多階層管理システム群(図1の107)において一意な識別子が付与される。イベントに付与された識別子はイベントIDとしてイベントID記憶部44に記録され、イベントIDは過去に処理されたイベントの検索や新規に受信したイベントIDの決定に使用される。
【００２０】
イベントコンテンツ記憶部43は、イベント管理装置が管理システムから受信したイベントメッセージを記録する。イベントメッセージには、イベントID、イベント送信元、イベント送信先、イベント送信時刻、イベント管理装置がイベントを受信した時刻、管理システムから管理システムへ送信されるメッセージの内容などが含まれる。
【００２１】
イベント状態記憶部42は、イベントが多階層管理システム群においてどの管理システムからどの管理システムまで送信されたかを管理するために使用される。ある一つのイベントの状態データには、イベントID、イベントが送信される管理システム名とその順序を表すイベントルート、各々の管理システムのイベント送信時刻と受信時刻、送受信済み、または未送受信を表すフラッグデータなどを含む。
【００２２】
イベントルート記憶部41はあるイベントをエレメント管理システム(図1の105)が通信装置(図1の106)から受信後、そのイベントがどの管理システムに対してどの順序で転送されるかのデータを記憶する。多階層管理システム群(図1の107)をグループ化した管理レイヤのイベント送信順序は固定であり、エレメント管理レイヤ、ネットワーク管理レイヤ、サービス管理レイヤ、ビジネス管理レイヤであるが、それぞれのレイヤを構成する管理システム5、6は複数であるため、管理システム5、6間の送信順序を規定するために使用される。また、一つの管理システム6が複数の管理システム6に対してイベントを送信するルートと、複数の管理システム5から一つの管理システム6がイベントを受信するルートは許される。
【００２３】
データ処理手段3はコネクション確立状態管理手段32、イベント送信手段33、イベント処理手段34、イベント受信手段35、イベント確認送信手段36、イベントルート管理手段37、イベント状態管理手段38、イベントバッファ管理手段39、イベントID管理手段3A、ユーザインタフェース処理手段31からなる。
【００２４】
コネクション確立状態管理手段32は、イベント管理装置がイベントを送信する先の管理システム5とイベント管理装置との通信パスが確立されているか否かを管理する。通信パスが確立されているときは、イベント送信手段33に送信許可信号を送り、確立されていないときは処理中断信号を送る。また、通信パスがきれたとき、あるいは確立されたときには、その事象を検出して状態を管理する。
【００２５】
イベント送信手段33は、コネクション確立状態管理手段32からの送信許可信号を受けて、管理システム5に対してイベントを送信する。
【００２６】
イベント処理手段34はイベント受信手段35からの処理リクエストを受信し、イベント状態管理手段38とイベントバッファ管理手段39に処理を要求する。要求後、イベント状態管理手段38とイベントバッファ管理手段39の両方が処理を終了するまでのトランザクションを管理して、すべての処理が終了後にイベント送信手段33に処理を要求する。
【００２７】
イベント受信手段35は管理システム6からのイベントを受信する。
【００２８】
イベント確認送信手段36は、エレメント管理システム(図1の105)に対してイベント確認メッセージを送信するために使用され、エレメント管理システム(図1の105)からイベントを受信したことを通知する。イベント確認メッセージにはエレメント管理システム(図1の105)が付与したイベントIDとイベント管理装置が付与したイベントIDなどが含まれる。エレメント管理システム(図1の105)が、イベント確認メッセージを受信する前にタイムアウトを検出した場合、そのイベントは設定回数だけ再送される。
【００２９】
イベントルート管理手段37はイベントルート管理記憶部41に対するアクセスインタフェースを提供する。ユーザインタフェース処理手段31からの要求を受けて、イベントルートの読み込みや書き込み、イベント送信手段33とイベント状態管理手段38からの要求を受けて、イベントルートの読み込みなどを行う。
【００３０】
イベント状態管理手段38はイベント状態管理記憶部42に対するアクセスインタフェースを提供する。イベント処理手段34の要求を受けて、受信したイベントの状態更新やユーザインタフェース処理手段31の要求を受けて、イベント状態の読み込みなどを行う。
【００３１】
イベントバッファ管理手段39はイベントコンテンツ記憶部43に対するアクセスインタフェースを提供する。イベント処理手段34の要求を受けて、受信したイベント内容をイベントコンテンツ記憶部43に書き込み、ユーザインタフェース処理手段31の要求を受けて、イベント内容の読み込みなどを行う。
【００３２】
イベントID管理手段3AはイベントID記憶部44に対するアクセスインタフェースを提供する。イベント受信手段35の要求を受けて、新規に受信したイベントのIDを決定するなどの機能を提供する。
【００３３】
ユーザインタフェース処理手段31は、入力装置1と出力装置2に対してイベント管理装置の操作インタフェースを提供する。イベントコンテンツ記憶部31アクセスによるイベント内容の読み込みやイベント状態記憶部42アクセスによるイベント送信のトラッキングなどを実現する。
【００３４】
次に本実施形態の動作について三点詳細に説明する。
第一に図2及び図4〜6を参照して、イベント管理装置(図1の101)がイベントを管理システム5から受信したときの動作について詳細に説明する。
【００３５】
イベント受信装置(図1の101)は、管理システム5からイベントを受信するとイベントメッセージから送信元管理システム名を読み出す(図4のステップA1、A2)。読み出された管理システム名5がエレメント管理システムか、ネットワーク管理システム、サービス管理システム、ビジネス管理システムかの判定を行う(ステップA3)。
【００３６】
エレメント管理システムと判定された場合、イベントID管理手段3AはイベントID記憶部44から記憶されているイベントIDを読み出し(ステップA11)、新規に受信したイベントに対して付与するイベントIDを決定する(A12)。なお、受信イベントにはエレメント管理システムが付与したイベントIDも含まれる。イベント受信手段35は、エレメント管理システムが付与したイベントIDとイベント管理装置が付与したイベントIDのペアをパラメータとしてイベント確認送信手段34に処理を要求し、イベント確認メッセージがエレメント管理システムに対して送信される(ステップA13)。エレメント管理システムがイベント確認メッセージを受信せずにタイムアウトを検出した場合、該当イベントが同一のイベントIDを付与されて再送される。
【００３７】
次に、イベント処理手段34へ処理が要求されて、その要求はイベント状態管理手段38とイベントバッファ管理手段39へ転送される。
【００３８】
イベント状態管理手段38は送信元エレメント管理システム名をパラメータとして、イベントルート管理手段37へ処理を依頼する。該当の送信元エレメント管理システムからイベントが転送される管理システム5とその順序を表すイベントルートがイベントルート記憶部41から読み出される(ステップA21)。イベント状態管理手段38は、イベント状態記憶部42にイベント状態データを書き込む(ステップA22)。イベント状態データにはイベントID、エレメント管理システムのイベント送信時刻と受信時刻、送受信済みを表すフラッグデータが書き込まれる(図3を参照)。処理が終了後に、終了信号がイベント処理手段34に送信される。
【００３９】
イベントバッファ管理手段39は、エレメント管理システムから受信したイベントメッセージの内容にイベントID、送信元管理システム名、送信先管理システム名、イベント管理システムがイベントを受信した時刻などを追加して、イベントコンテンツ記憶部43に書き込む(ステップA31)。処理が終了後に、終了信号がイベント処理手段34に送信される。
【００４０】
イベント処理手段34が、イベント状態管理手段38とイベントバッファ管理手段39の双方から終了信号を受信すると、イベント送信手段33へ処理を要求する。イベント送信手段33は、イベントIDと送信元エレメント管理システム名6をパラメータとして、イベントルート管理手段37から次に送信する管理システム名5を受け取り(ステップA41)、送信先管理システム名5をパラメータとしてコネクション状態管理手段32に処理を要求する。
【００４１】
送信先管理システム5とイベント管理装置間の送受信通信パスが確立されていない場合、コネクション確立状態管理手段32は処理終了をレスポンスする。
【００４２】
送受信通信パスが確立されている場合、イベント送信手段33は管理システム5に対してイベントを送信する(ステップA43)。ここで、通信パスは送信と受信の両方が確立されていなければ、イベントはイベント送信手段33から送信されない。受信パスが確立されていない場合、送信先管理システム5から再度、イベントを受信することができず、送信先管理システム54がイベント送信をリトライするために処理負荷が増加するからである。
【００４３】
ネットワーク管理システム、サービス管理システム、ビジネス管理システムと判定された場合、イベント受信手段35は、受信イベントに含まれるイベントIDをパラメータとしてイベント処理手段34に処理を要求する。イベント処理手段34はイベント状態管理手段38とイベントバッファ管理手段39に処理を要求し、両方の処理が終了するまでの状態を管理する。なお、ここで使用されるイベントIDはイベントID管理手段3Aがエレメント管理システムからのイベント受信後に付与したものである。
【００４４】
イベント状態管理手段38はイベントIDをパラメータとしてイベント状態記憶部42から状態データを読み込み、状態の更新を行う(ステップA51)。更新内容は、イベントルートにおいて送信元管理システム名6がイベントを送受信済みである事をあらわすフラッグデータ、イベント送信時刻と受信時刻である。
【００４５】
次にイベント状態管理手段38は更新した状態データの送信元管理システム名5が前にポイントする管理システム名が、さらに後にポイントする管理システム名を取得する。例えば、図3を参照し、管理システム名SMS1のフラッグデータ、イベント送信時刻と受信時刻を更新したとすると、前にポイントされる管理システム名はNMS1であり、NMS1が後にポイントする管理システム名はSMS1、SMS2である。従って、イベント状態管理手段38はSMS1、SMS2を取得する。次に、イベント状態管理手段38は後にポイントされるすべての管理システム名において、フラッグデータが書き込まれているか否かを読み込む(ステップA52、A53)。例えば、SMS1とSMS2の両方からイベントを受信済みか否かを調べる。
【００４６】
すべてフラッグデータが書き込まれている場合、イベントIDと前にポイントされている管理システム名をキーにしてイベントバッファ管理手段39に処理を依頼し、イベントコンテンツ記憶部43から該当のイベントメッセージを削除し、次の処理へ進む(ステップA54)。
【００４７】
すべてフラッグデータが書き込まれていない場合、次の処理へ進む。
【００４８】
イベントバッファ管理手段39はネットワーク、サービス、ビジネス管理システムから受信したイベントメッセージの内容に送信元管理システム名、送信先管理システム名、イベント管理システムがイベントを受信した時刻などを追加して、イベントコンテンツ記憶部43に書き込む(ステップA61)。処理が終了後に、終了信号がイベント処理手段34に送信される。
【００４９】
イベント処理手段34が、イベント状態管理手段38とイベントバッファ管理手段39の双方から終了信号を受信すると、その後の処理内容は図４，５のステップA41〜ステップA43と同じである(ステップA71)。
【００５０】
第二に図2及び図7を参照して、イベント管理装置にイベントルートデータを登録する動作について詳細に説明する。
まず、イベント管理装置のオペレータが入力装置1からユーザインタフェース処理手段31を使用してイベントルートデータを入力する(図7のステップB1)。ユーザインタフェース処理手段31はイベントルート管理手段37に処理を依頼し、イベントルート管理手段37は入力されたデータに矛盾がないか否かをチェックする(ステップB2)。
【００５１】
矛盾がない場合、イベントルート管理手段37はイベントルート記憶部41にイベントルートデータを登録する(ステップB3)。
【００５２】
矛盾がある場合、ユーザインタフェース処理手段31へ処理を依頼してエラーメッセージを出力装置2に出力する(B4)。
【００５３】
第三に図2及び図8を参照して、シャットダウンされているネットワーク管理システム、サービス管理システム、ビジネス管理システムを起動した後のイベント管理装置の動作について詳細に説明する。
まず、ネットワーク管理システム、サービス管理システム、ビジネス管理システムを起動する(図8のステップC1)とコネクション確立状態管理手段32は管理システム5、6とイベント管理装置間の送受信パスの確立を認識し(ステップC2)、起動された管理システム名5、6をパラメータとしてイベント処理手段34に処理を依頼する。
【００５４】
イベント処理手段34は起動された管理システム名5、6をパラメータとして、イベント状態管理手段38に下記の条件をみたすイベント状態データの検索を依頼する(ステップC3)。
【００５５】
・ イベント状態データにおいて起動管理システム名の属性である送受信済みフラッグがオフになっている。
・ イベント状態データにおいて起動管理システム名の前にポイントされる管理システム名の属性である送受信済みフラッグがオンになっている。
【００５６】
イベント状態管理手段38は検索されたイベント状態データから、イベントIDと起動管理システム名の前にポイントされる管理システム名を読み込む。例えば、図3においてSMS1が起動された場合、イベントIDとNMS1が読み込まれる(ステップC4)。
【００５７】
次にイベント状態管理手段38は、イベントバッファ管理手段39に処理を依頼し、イベントIDと前にポイントされる管理システム名をパラメータとしてイベントコンテンツ記憶部43からイベントメッセージを読み込む(ステップC5)。ここで読み込まれるイベントメッセージは、次に送信先の管理システムがシャットダウン状態であったためにイベント管理装置にキューイングされていたものである。
【００５８】
次にイベントバッファ管理手段はイベント処理手段に対してイベントメッセージ送信を依頼し、以後の処理は図4，5のステップ41からステップ43と同じになる(ステップC6)。
【００５９】
次に、本発明の他の実施形態について図面を参照して詳細に説明する。
図9を参照すると、本実施形態は図2と比べて記憶装置4においてイベントフィルタ記憶部45が追加され、データ処理装置3においてイベントフィルタ処理手段3Bが追加された点で異なる。
【００６０】
イベントフィルタ記憶部45はある送信元管理システム6から送信先管理システム5に送信するイベントタイプを記憶する。イベントフィルタ処理手段3Bはイベントバッファ管理手段39からの処理を受けて、イベントフィルタ記憶部45からフィルタ条件を読み込み、イベントのフィルタリングを実行する。
【００６１】
図9に示される入力装置1、出力装置2、データ処理装置3、記憶装置4を構成するイベントID記憶部44、イベントコンテンツ記憶部43、イベント状態記憶部42、イベントルート記憶部41とコネクション確立状態管理手段32、イベント送信手段33、イベント処理手段34、イベント受信手段35、イベント確認送信手段36、イベントルート管理手段37、イベント状態管理手段38、イベントバッファ管理手段39、イベントID管理手段3A、ユーザインタフェース処理手段31、管理システム5、6は、図2に示されるものと同一の動作のため説明を省略する。
【００６２】
図4〜6で示された実施形態では、イベントバッファ管理手段39が、イベントコンテンツ記憶部43から読み出したイベントメッセージを送信先管理システム5に送信していた。
【００６３】
本実施形態では、イベントを送信する前にフィルタリングする点で異なる。すなわち、イベントバッファ管理手段39が、イベント処理手段34に処理を依頼する前にイベントフィルタ処理手段3Bに処理を依頼し、イベントフィルタ記憶部45からフィルタ条件データを読み込む(ステップD2)。次に、フィルタ条件データには送信元管理システム名6、送信先管理システム名5、送信可能なイベントタイプが含まれ、イベントフィルタ処理手段3Bは送信対象のイベントの属性が送信可能イベントタイプか否かの判定を行う(ステップD3,)。送信可能イベントタイプの場合、そのイベントメッセージはイベント処理手段34にパラメータとして渡され、送信可能イベントタイプでない場合、処理を終了する。図10においてステップD1の動作は図4〜6のステップA1〜ステップA22、31とステップA51〜ステップA54、61と同一であり、ステップD4の動作は図4〜6のステップA41〜ステップ43と同一であるので説明を省略する。
【００６４】
以上、この発明の実施形態を図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計の変更等があってもこの発明に含まれる。
【００６５】
【発明の効果】
請求項１記載の発明によれば、個々の管理システムの処理内容を簡素化し、イベントの受信確認メッセージ、イベントメッセージのバッファーリング、再送、送信先管理システムのヘルスチェックを管理システム側で行う必要が無くなる。  請求項２記載の発明によれば、イベントルートのコンフィグレーションを個々の管理システムに設定する必要がなく、システム管理者の負荷を軽減できる。
請求項３記載の発明によれば、イベント管理装置の処理負荷を軽減できる。
【図面の簡単な説明】
【図１】  本発明の一実施形態による多階層管理システムの構成例を示すブロック図である。
【図２】  同実施形態によるイベント管理装置の構成例を示すブロック図である。
【図３】  同実施形態によるイベント状態データの一例を示す説明図である。
【図４】  同実施形態によるイベント管理装置の動作例を示すフローチャートである。
【図５】  同実施形態によるイベント管理装置の動作例を示すフローチャートである。
【図６】  同実施形態によるイベント管理装置の動作例を示すフローチャートである。
【図７】  同実施形態によるイベント管理装置の動作例を示すフローチャートである。
【図８】  同実施形態によるイベント管理装置の動作例を示すフローチャートである。
【図９】  本発明の他の実施形態によるイベント管理装置の構成例を示すブロック図である。
【図１０】  本発明の他の実施形態によるイベント管理装置の動作例を示すフローチャートである。
【符号の説明】
１０１……イベント管理装置、  １０２……ビジネス管理システム、
１０３……サービス管理システム、  １０４……ネットワーク管理システム、
１０５……エレメント管理システム、  １０６……通信装置、
１０７……多階層管理システム群
【図１】
0003890154.tif 000002
【図２】
0003890154.tif 000003
【図３】
0003890154.tif 000004
【図４】
0003890154.tif 000005
【図５】
0003890154.tif 000006
【図６】
0003890154.tif 000007
【図７】
0003890154.tif 000008
【図８】
0003890154.tif 000009
【図９】
0003890154.tif 000010
【図１０】
0003890154.tif 000011