(57)【要約】【課題】  ＥＭＳサーバー間でのネットワーク・ステータス・データの共有を比較的簡素で信頼性のある手法で可能にする分散型メッセージング・システム及び方法を提供する。【解決手段】  分散型メッセージング・システム及び方法によってネットワーク内のサーバーが、ネットワーク内の全てのサーバーに関連するネットワーク・ステータス・データのようなデータを共有することができる。一実施形態において、分散型メッセージング・システム及び方法は分散型ネットワーク管理システム（ＮＭＳ）内の要素管理システム（ＥＭＳ）サーバーにおいて使用される。ネットワーク内のサーバーは、ネットワーク・ステータス・データを含むメッセージを送信することによって、例えば、スター型ブロードキャスト方式又は環状メッセージキュー（ＣＭＱ）方式を用いる等、分散された手法でデータを共有する。【選択図】  図３
2006042343.tif 000002
【特許請求の範囲】
【請求項１】
ネットワーク・ステータス・データをネットワーク内の要素管理システム（ＥＭＳ）サーバーと複数の他のＥＭＳサーバーのうちの少なくとも１つとの間で共有する方法であって、
前記ＥＭＳサーバー内にデータ構造を提供するステップであって、該データ構造は前記ネットワーク内の複数の前記ＥＭＳサーバーに関連するネットワーク・ステータス・データであるステップ、
前記ＥＭＳサーバーにおいて少なくとも１つのメッセージを受信するステップであって、受信されたメッセージは前記他のＥＭＳサーバーの少なくとも１つによって送信され、前記受信されたメッセージは前記ネットワーク内の複数の前記ＥＭＳサーバーに関連するネットワーク・ステータス・データを含んでいるステップ、
前記受信されたメッセージからの更新されたネットワーク・ステータス・データを用いて前記ＥＭＳサーバーにおける前記データ構造を更新するステップ、
ＥＭＳ機能実行時に、前記ＥＭＳサーバーによって取得された更新されたネットワーク・ステータス・データによって前記ＥＭＳサーバーにおける前記データ構造を更新するステップ、及び
少なくとも１つのメッセージを前記他のＥＭＳサーバーのうちの少なくとも１つに所定の時間に送信するステップであって、少なくとも１つの送信されたメッセージは前記更新されたデータ構造を含むステップ
からなる方法。
【請求項２】
請求項１記載の方法であって、さらに、更新されたネットワーク・ステータス・データによってユーザーインターフェイスを更新するステップからなる方法。
【請求項３】
請求項１記載の方法において、前記ネットワーク・ステータス・データがネットワーク・アラーム・ステータス・データ及びＥＭＳステータス・データを含むことを特徴とする方法。
【請求項４】
請求項１記載の方法において、前記データ構造がメッセージバッファ内に提供されることを特徴とする方法。
【請求項５】
請求項１記載の方法において、前記データ構造が前記ＥＭＳサーバーの各々に対応するデータブロックを含むことを特徴とする方法。
【請求項６】
請求項５記載の方法において、前記データブロックが前記データブロックに対する最後の更新の日付／時刻スタンプを含むことを特徴とする方法。
【請求項７】
請求項６記載の方法において、前記データブロックの各々がＥＭＳサーバー利用可能性データを含むことを特徴とする方法。
【請求項８】
請求項１記載の方法において、前記少なくとも１つのメッセージを送信するステップが、前記少なくとも１つのメッセージを前記ネットワーク内の他の前記ＥＭＳサーバーにブロードキャストするステップを含むことを特徴とする方法。
【請求項９】
請求項８記載の方法において、前記送信のための所定の時間が、ブロードキャストの送信時間であることを特徴とする方法。
【請求項１０】
請求項８記載の方法であって、さらに、前記データ構造を最後に送信されたメッセージと比較するステップからなり、前記データ構造が前記最後に送信されたメッセージから変化していた場合、前記少なくとも１つのメッセージが送信されることを特徴とする方法。
【請求項１１】
請求項１０記載の方法であって、さらに、前記データ構造が前記最後に送信されたメッセージから変化していなくても、所定の時間後に前記少なくとも１つの送信されたメッセージをブロードキャストするステップからなる方法。
【請求項１２】
請求項１０記載の方法であって、さらに、受信時間終了後に、メッセージが前記他のＥＭＳサーバーの少なくとも１つから受信されていないことを判別するステップからなる方法。
【請求項１３】
請求項８記載の方法において、前記データ構造が前記ネットワーク内の前記ＥＭＳサーバーに対応するデータブロックを含み、前記データブロックの各々が前記データブロックに対する最後の更新の日付／時刻スタンプ、ＥＭＳステータス・データ、ＥＭＳアラーム・ステータス・データ及びＥＭＳサーバー利用可能性データを含むことを特徴とする方法。
【請求項１４】
請求項１記載の方法であって、さらに、前記ＥＭＳサーバー内のＥＭＳサーバーのリストを提供するステップからなり、前記少なくとも１つのメッセージを送信するステップが、前記メッセージを前記ＥＭＳサーバーのリストによって規定されたように、隣接するＥＭＳサーバーに送信するステップを含むことを特徴とする方法。
【請求項１５】
請求項１４記載の方法において、送信のための前記所定の時間は、前記メッセージを隣接するＥＭＳサーバーから受信した後の所定の遅延時間であることを特徴とする方法。
【請求項１６】
請求項１４記載の方法において、前記少なくとも１つのメッセージが、前記隣接するＥＭＳサーバーが利用可能な場合のみ前記隣接するＥＭＳサーバーに送信されることを特徴とする方法。
【請求項１７】
請求項１４記載の方法であって、さらに、前記メッセージを隣接するサーバーから受信するための所定の時間が経過したかを判定するステップからなる方法。
【請求項１８】
請求項１７記載の方法であって、さらに、前記メッセージを受信するための前記所定の時間が経過した場合、利用可能性ステータス・リクエスト・メッセージを前記他のＥＭＳサーバーにブロードキャストするステップからなる方法。
【請求項１９】
請求項１４記載の方法において、前記データ構造は、前記ＥＭＳサーバーの各々に対して、利用可能性データ、遅延時間、最後のメッセージ送信の時間スタンプ及びアラーム・ステータス・データを含むことを特徴とする方法。
【請求項２０】
請求項１記載の方法であって、さらに、前記ＥＭＳサーバー内の時間クロックを前記他のＥＭＳサーバー内の時間クロックに同期させるステップからなる方法。
【請求項２１】
機械可読媒体であって、そのコンテンツによってコンピュータシステムがネットワーク内の要素管理システム（ＥＭＳ）サーバーと複数の他のＥＭＳサーバーのうちの少なくとも１つとの間でネットワーク・ステータス・データを共有するための方法を実行させる機械可読媒体において、前記方法は、
前記ＥＭＳサーバー内にデータ構造を提供するステップであって、該データ構造は前記ネットワーク内の複数の前記ＥＭＳサーバーに関連するネットワーク・ステータス・データであるステップ、
前記ＥＭＳサーバーにおいて少なくとも１つのメッセージを受信するステップであって、受信されたメッセージは前記他のＥＭＳサーバーの少なくとも１つによって送信され、前記受信されたメッセージは前記ネットワーク内の複数の前記ＥＭＳサーバーに関連するネットワーク・ステータス・データを含んでいるステップ、
前記受信されたメッセージからの更新されたネットワーク・ステータス・データによって前記ＥＭＳサーバーにおける前記データ構造を更新するステップ、
ＥＭＳ機能実行時に、前記ＥＭＳサーバーによって取得された更新されたネットワーク・ステータス・データによって前記ＥＭＳサーバーにおける前記データ構造を更新するステップ、及び
少なくとも１つのメッセージを前記他のＥＭＳサーバーのうちの少なくとも１つに所定の時間に送信するステップであって、少なくとも１つの送信されたメッセージは前記更新されたデータ構造を含むステップ
からなる方法であることを特徴とする機械可読媒体。
【請求項２２】
請求項２１記載の機械可読媒体において、前記少なくとも１つのメッセージを送信するステップは前記少なくとも１つのメッセージを該ネットワーク内の他の前記ＥＭＳサーバーに所定の送信時間にブロードキャストするステップを含むことを特徴とする機械可読媒体。
【請求項２３】
請求項２２記載の機械可読媒体において、前記データ構造が前記ＥＭＳサーバーの各々に対応するデータブロックを含み、該データブロックが前記データブロックに対する最後の更新の日付／時刻スタンプ、ＥＭＳステータス・データ、ＥＭＳアラーム・ステータス・データ及びＥＭＳサーバー利用可能性データを含むことを特徴とする機械可読媒体。
【請求項２４】
請求項２２記載の機械可読媒体において、前記方法が、さらに、前記データ構造を最後に送信されたメッセージと比較するステップからなり、前記データ構造が前記最後に送信されたメッセージから変化していた場合、又は前記データ構造が前記最後に送信されたメッセージから変化していなくても、所定の時間後に前記少なくとも１つのメッセージが送信される方法であることを特徴とする機械可読媒体。
【請求項２５】
請求項２１記載の機械可読媒体において、前記少なくとも１つのメッセージを送信するステップが、前記メッセージが受信されてから所定の遅延後に、前記メッセージを、ＥＭＳサーバーのリストによって規定されたように隣接するＥＭＳサーバーに送信することを含むことを特徴とする機械可読媒体。
【請求項２６】
請求項２５記載の機械可読媒体において、前記データ構造は、前記ＥＭＳサーバーに対して、利用可能性データ、遅延時間、最後のメッセージ送信の時間スタンプ及びアラーム・ステータス・データを含むことを特徴とする機械可読媒体
【請求項２７】
請求項２６記載の機械可読媒体において、前記方法が、さらに、隣接するサーバーからの前記メッセージを受信するための所定の時間が経過したかを判定するステップからなる方法であることを特徴とする機械可読媒体。
【請求項２８】
請求項２７記載の機械可読媒体において、前記方法が、さらに、前記メッセージを受信するための前記所定の時間が経過した場合、利用可能性ステータス・リクエスト・メッセージを前記他のＥＭＳサーバーにブロードキャストするステップからなる方法であることを特徴とする機械可読媒体。
【請求項２９】
請求項２１記載の機械可読媒体において、前記方法が、さらに、前記ＥＭＳサーバーの時間クロックを他の前記ＥＭＳサーバー内の時間クロックに同期させるステップからなる方法であることを特徴とする機械可読媒体。
【請求項３０】
ネットワーク内のサーバー間で分散型メッセージングを行う方法であって、
前記サーバー各々にメッセージバッファを提供するステップであって、前記メッセージバッファは前記ネットワーク内の前記サーバーに関連するネットワーク・ステータス・データを有するデータブロックを含んでいるステップ、
前記サーバーの各々における前記メッセージバッファを前記サーバーの各々によって取得された更新されたネットワーク・ステータス・データによって更新するステップ、
メッセージを前記サーバーの各々から異なる送信時間でブロードキャストするステップであって、前記メッセージの各々は前記サーバーのそれぞれ１つからの前記メッセージのコピーを含むステップ、
前記メッセージを前記サーバー内に受信するステップ、及び
前記サーバーの各々における前記メッセージバッファを前記サーバーによって受信された前記メッセージ内の前記ネットワーク・ステータス・データに基づいて更新するステップ
からなる方法。
【請求項３１】
請求項３０記載の方法において、前記サーバーは要素管理システム（ＥＭＳ）サーバーであることを特徴とする方法。
【請求項３２】
請求項３１記載の方法において、前記ブロック各々における前記ネットワーク・ステータス・データはＥＭＳアラーム・ステータス・データ及びＥＭＳステータス・データを含むことを特徴とする方法。
【請求項３３】
請求項３０記載の方法において、前記ブロックの各々は前記ブロックの最後の更新の日付／時刻スタンプ及びサーバー利用可能性データを含むことを特徴とする方法。
【請求項３４】
請求項３０記載の方法であって、さらに、前記メッセージバッファ内の前記データブロックを最後に送信されたメッセージ内の前記データブロックと比較するステップからなり、前記データが最後に送信されたメッセージから変化していた場合に、前記サーバーの各々が前記メッセージをブロードキャストすることを特徴とする方法。
【請求項３５】
請求項３４記載の方法であって、さらに、たとえ前記データが前記最後の送信メッセージから変化していなくても、前記最後の送信メッセージから所定の期間が経過した場合に前記メッセージをブロードキャストするステップからなる方法。
【請求項３６】
請求項３０記載の方法であって、さらに、受信時間終了後にメッセージが前記他のサーバーから受信されていないかを判定するステップからなる方法。
【請求項３７】
請求項３０記載の方法であって、さらに、前記サーバーによって管理されるユーザーインターフェイスを更新されたネットワーク・ステータス・データによって更新するステップからなる方法。
【請求項３８】
請求項３０記載の方法であって、さらに、前記サーバー間の時間クロックを同期させるステップからなる方法。
【請求項３９】
ネットワーク内のサーバー間で分散型メッセージングを行う方法であって、
前記サーバー各々にサーバーリストを提供するステップであって、前記サーバーリストが前記ネットワーク内の前記サーバーを識別するステップ、
少なくとも１つのメッセージを前記ネットワーク内の隣接するサーバーと送受信するステップであって、各前記メッセージは前記サーバーに関連するネットワーク・ステータス・データを含むステップ、及び
前記サーバーの各々によって受信された前記メッセージを、前記サーバーの各々によって取得された更新されたネットワーク・ステータス・データによって更新するステップ
からなる方法。
【請求項４０】
請求項４０記載の方法において、前記サーバーは要素管理システム（ＥＭＳ）サーバーを含むことを特徴とする方法。
【請求項４１】
請求項４０記載の方法において、前記サーバー各々に対する前記ネットワーク・ステータス・データは、現在アクティブになっている重大及び軽微アラームの数及び最後の更新からの重大及び軽微アラームの数を含むことを特徴とする方法。
【請求項４２】
請求項３９記載の方法において、前記メッセージは、各サーバーについて、サーバー利用可能性データ及び遅延時間を含むことを特徴とする方法。
【請求項４３】
請求項３９記載の方法において、前記メッセージは、前記メッセージが受信されてから所定の遅延後に前記サーバーの各々によって送信されることを特徴とする方法。
【請求項４４】
請求項３９記載の方法において、前記メッセージは前記ネットワーク内の利用可能なサーバーのみに送信されることを特徴とする方法。
【請求項４５】
請求項３９記載の方法であって、さらに、前記メッセージを受信するための所定の時間が経過したかを判定するステップからなる方法。
【請求項４６】
請求項４５記載の方法であって、さらに、前記メッセージを受信するための所定の時間が経過した場合、利用可能性ステータス・リクエスト・メッセージを前記他のＥＭＳサーバーにブロードキャストするステップからなる方法。
【請求項４７】
請求項３９記載の方法において、前記データ構造は、前記ＥＭＳサーバーの各々について、利用可能性データ、遅延時間、最後のメッセージ送信の時間スタンプ、及びアラーム・ステータス・データを含むことを特徴とする方法。
【請求項４８】
請求項３９記載の方法であって、さらに、前記サーバー間の時間クロックを同期させるステップからなる方法。
【請求項４９】
分散型ネットワーク管理システム（ＮＭＳ）であって、
ネットワーク要素を管理するための複数の要素管理システム（ＥＭＳ）であって、前記ＥＭＳの各々は前記ＥＭＳの各々に関連するネットワーク・ステータス・データを含んでいるＥＭＳからなり、
前記ＥＭＳの各々が、管理されている前記ネットワーク要素についてのネットワーク・ステータス・データを取得するように構成され、
前記ＥＭＳの各々が、他の前記ＥＭＳとメッセージを送受信するように構成され、前記メッセージはそれぞれの前記ＥＭＳからの前記データ構造を含み、
前記ＥＭＳの各々が、前記データ構造を、前記管理されているネットワーク要素から取得された前記ネットワーク・ステータス・データによって、及び他の前記ＥＭＳから受信された前記メッセージ内の前記ネットワーク・ステータス・データによって更新するように構成されたことを特徴とする分散型ネットワーク管理システム。
【請求項５０】
請求項４９記載の分散型ネットワーク管理システムにおいて、前記ＥＭＳの各々が、メッセージを前記ネットワーク内の前記他のＥＭＳに所定の送信時間にブロードキャストすることによって該メッセージを送信するよう構成されたことを特徴とする分散型ネットワーク管理システム。
【請求項５１】
請求項４９記載の分散型ネットワーク管理システムにおいて、前記ＥＭＳの各々が、メッセージが受信されてから所定の遅延後に、該メッセージを前記ＥＭＳのリストで規定されたように隣接するＥＭＳに送信することによって該メッセージを送信するよう構成されたことを特徴とする分散型ネットワーク管理システム。
【請求項５２】
請求項４９記載の分散型ネットワーク管理システムにおいて、前記ＥＭＳの各々が他の前記ＥＭＳと時間同期されることを特徴とする分散型ネットワーク管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はデータ共有化に関し、より具体的には要素管理システム（ＥＭＳ）が分散型ネットワーク管理システム（ＮＭＳ）におけるネットワーク・ステータス・データを共有可能とする分散型メッセージング・システム及び方法に関する。
【背景技術】
【０００２】
ネットワーク管理は、ネットワークの故障を回避するとともにネットワークの性能を確保するために、異なるレベルで様々な種類のネットワークにおいて行われる。通信ネットワークにおいて、要素管理システム（ＥＭＳ）がネットワーク内のネットワーク要素を監視し管理するために用いられる。また、通信ネットワークは、ネットワークの小さい領域を管理するいくつかのＥＭＳと通信することによってネットワーク全体を管理するためのネットワーク管理システム（ＮＭＳ）を含む。
【０００３】
光通信システムにおいては、例えば、終端やケーブル局がケーブルセグメントによって相互接続されてネットワークを形成する。光通信システムのネットワーク要素は、ケーブル局に接続された設備（例えば、中継器及び等価器）と同様にケーブル局に配置される設備（例えば、終端設備及び電力供給設備）も含む。そのようなシステムでは、ＥＭＳはケーブル局に（又は離れた場所に）配置され、このケーブル局に関連するネットワーク要素を管理するために用いられる。ＥＭＳは管理機能を実行するための１以上のサーバー及びユーザーインターフェイスを提供するための１以上のワークステーションを含む（例えば、ＥＭＳによって管理されるネットワークエレメントに関連する情報を表示する）。ＮＭＳは光通信システム全体、即ちネットワークを管理するためにケーブル局又は離れた場所のいずれかに配置される。
【０００４】
ネットワークの管理とは、構成管理、故障管理及び性能管理等である。ＥＭＳは、ＥＭＳによって管理されるネットワーク要素から転送されるアラーム、イベント及びシステムメッセージを取得、記憶及び／又は表示することによって故障管理を行うことができる。ＥＭＳは、伝送品質データを取得、記憶及び／又は測定することによって性能管理を行うことができる。ＮＭＳは、各ＥＭＳから転送される全てのアラーム、イベント及びシステムメッセージ並びに伝送品質データを管理することによってネットワーク全体に対する故障管理及び性能管理を提供できる。ＮＭＳは各ＥＭＳから受信された故障及び性能情報をネットワークの構成配置マップ上に表示する。
【０００５】
図１に示すように、ＮＭＳによって表示される情報の１つは、内在するＥＭＳによって管理されるネットワーク・アラーム・ステータスである。ユーザー（例えば、ネットワーク管理者又はオペレーター）は表示された情報を監視し、ネットワーク・アラームが停電の原因となるネットワーク内の故障を示しているか判別する。アラーム概要情報はアラームのレベル（例えば、重大、軽微、なし、使用不可／報告なし）、並びに重大及び軽微なアラームのアラーム数を表示する。
【０００６】
図２に示すように、アラーム・ステータス情報は各ＥＭＳサーバー１０とＮＭＳ１２との間で階層的手法を用いて通信される。一例によると、ＮＭＳにある１以上のコンピュータがＥＭＳサーバー１０から情報を受信する１以上のサーバー（例えば、単一のサーバー又は余剰のサーバー）として構成される。そして、（例えば、図１に示すように）ＮＭＳはアラーム概要情報をネットワーク内のＥＭＳごとに表示する。
【０００７】
他の可能な例によると、ＮＭＳ機能をＥＭＳサーバーに分散すること（即ち、各ＥＭＳに設置されたミニＮＭＳ機能）によって、ＮＭＳは物理的ＮＭＳサーバーで、又は層なくして形成できる。しかし、ＮＭＳ層を持たない分散されたＮＭＳを用いて、完全なネットワークのステータスの概要画面を提供することがなお望ましい。これを実現するため、各ＥＭＳは、最も高いレベルのアラーム・ステータスを「マスター」サーバーに提示することによって単一の「マスター」サーバーと通信する。それに対して、「マスター」サーバーは各ＥＭＳサーバーに、ネットワーク中の全ＥＭＳサーバーに対するアラーム・ステータスの統合された画面を提供する。そして、（例えば、図１に示すように）ネットワーク内のＥＭＳ毎のアラーム概要情報はＥＭＳのワークステーション上に表示されることになる。従って、この分散されたＮＭＳ手法もまた、階層的手法を用いる、即ち、ＮＭＳサーバーの代わりにマスターＥＭＳサーバーを用いる。
【０００８】
アラーム・ステータス・データを通信するための階層的手法は単純なデータ通信ネットワークを持つ小規模のシステム（即ち、少ない数のＥＭＳサーバー）では能力を発揮するが、大規模なシステムでは、例えば、ＥＭＳサーバーの数が、海底光通信システムに見られるような数に近づく場合、性能及び信頼性は低下する。分散されたＮＭＳシステムで利用可能な単純なＴＣＰ／ＩＰクライアントサーバーに基づく通信モデルでは不十分であり、処理及び送信のリソースを必要とする。システム動作もＮＭＳサーバー又はマスターサーバーに依存して負荷が重くなり、処理の負荷集中を招き、故障ポイントとなる。ＮＭＳサーバー又はマスターサーバーが故障すると、アラーム及びステータス共有機能も故障する。
【０００９】
従って、ＥＭＳサーバーのようなサーバー間のネットワーク・ステータス・データの共有を比較的簡単で信頼性のある手法で可能にする分散型メッセージング・システム及び方法に対する要望がある。
【発明の開示】
【課題を解決するための手段】
【００１０】
一般に、本発明による分散型メッセージング・システム及び方法によって、変化していく情報やデータがネットワークに亘って共有化されることができる。分散型メッセージング・システムにおいて、ネットワーク内のサーバーはネットワーク内の全てのサーバーのデータを含むメッセージを交換する。各サーバーがメッセージを交換する前にその特定のサーバーに関連するメッセージデータを更新するので、分散型メッセージングによって各サーバーがネットワーク内の全てのサーバーの現在のデータを保持することができる。サーバーはまた、ネットワークに亘って分散型メッセージを同調するために、時間的に同期されている。
【発明を実施するための最良の形態】
【００１１】
ここに説明される実施例によると、サーバーは、分散型メッセージングを用いて、ネットワーク・ステータス・データをネットワーク管理システム（ＮＭＳ）データ通信ネットワーク（ＤＣＮ）を用いて共有する要素管理システム（ＥＭＳ）サーバーを含む。ここで用いられるように、サーバーという用語は、ネットワークリソースを管理するソフトウェア及び／又はハードウェアのことをいい、単一のコンピュータ装置に限定されるものではない。１つのタイプのＥＭＳにおいては、ネットワーク・ステータス・データは、ＥＭＳによって管理されているネットワーク要素によってＥＭＳに転送されたアラームを表すＥＭＳアラーム・ステータス・データを含む。アラーム・ステータスに加えて、ネットワーク・ステータス・データが、ライン監視設備の状態又は他のＥＭＳステータス・データのようなＥＭＳ間で供給される他のタイプの情報を含んでもよい。しかし、本発明ではアラーム・ステータス・データ又はＥＭＳステータス・データに限定されるものではない。ここで用いられるように、ネットワーク・ステータス・データは、一般的なネットワーク及び／又はネットワーク内の１以上の特定のネットワーク要素のステータスに関係するいずれのタイプのデータを含んでいてもよい。
【００１２】
分散型メッセージング・システム及び方法は分散されたＮＭＳにおいて使用され、例えば、「ミニＮＭＳ」機能を、ＥＭＳの段階でミニＮＭＳデータ（ＭＮＤ）を分散型ＮＭＳ内のＥＭＳサーバー間で共有することによってサポートする。共有化されたネットワーク・ステータス・データのいくつか（例えば、アラーム概要情報）が、ユーザーインターフェイスを用いて、例えば、ＥＭＳサーバーにログインしたクライアントのワークステーション上のグラフィカル・ユーザー・インターフェイス（ＧＵＩ）を用いて表示されるようにしてもよい。他の共有化されたネットワーク・ステータス・データ（例えば、ＥＭＳステータス・データ）が、ＥＭＳ機能を実行するようにＥＭＳアプリケーションによって使用されるようにしてもよい。分散型ＮＭＳの一実施例として、Ｔｙｃｏ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｉｎｃ（米国）から入手できるＴｙｃｏ  Ｅｌｅｍｅｎｔ  Ｍａｎａｇｅｍｅｎｔ  Ｓｙｓｔｅｍ（ＴＥＭＳ）がある。また、分散型メッセージング・システム及び方法は、当業者には周知の他の分散型又は非分散型ＥＭＳ／ＮＭＳ構成で使用することもできる。
【００１３】
図３を参照すると、ＥＭＳサーバー２０−１・・・２０−ｎがネットワーク・ステータス・データ（例えば、アラーム・ステータス・データ及びＥＭＳステータス・データ）をＥＭＳサーバー２０−１・・・２０−ｎ間で共有する。分散型メッセージングを用いて、ネットワーク内のＥＭＳサーバー２０−１・・・２０−ｎの各々はＥＭＳサーバーの全てに関連するネットワーク・ステータス・データを含むメッセージを送信及び受信する。ＥＭＳサーバーはメッセージを他の登録されたＥＭＳサーバーに、例えば、下記にさらに詳細に説明するようなＥＭＳサーバーが、メッセージを他のサーバーにブロードキャストするスター型ブロードキャスト方式を用いて、又は  ＥＭＳサーバー２０−１・・・２０−ｎがメッセージを隣接するサーバーに送信する環状メッセージキュー（ＣＭＱ）方式を用いて送信する。追加的なメッセージが送信され、ＥＭＳサーバー２０−１・・・２０−ｎの１つ以上が、例えば、サーバーが故障しているか或いはＤＣＮリンクが故障しているために報告なし或いは利用不可であるかを判定する。
【００１４】
図４は、ネットワーク・ステータス・データを共有するためのサーバー３０ａ−３０ｃによって用いられる分散型メッセージング・システム及び方法の一実施例を示すものである。３つのサーバー３０ａ−３０ｃだけが説明の明確化と簡単のために図示されているが、当業者であれば、システム及び方法はどのような数のサーバー間の分散型メッセージングでも実施できることは認識できるであろう。
【００１５】
サーバー３０ａ−３０ｃの各々がネットワーク・ステータス・データを提供され、それはネットワーク内のサーバー３０ａ−３０ｃの全てのネットワーク・ステータス・データを含んでいる。サーバー３０ａ−３０ｃの各々はネットワーク・ステータス・データ構造３２を特定のサーバーに固有のローカル・ネットワーク・ステータス・データ３４を用いて更新する。データ構造３２は、例えば秒毎に、いつでも更新できる値を有する。ＥＭＳサーバーにおいて、例えば、ローカル・ネットワーク・ステータス・データ３４はその特定のＥＭＳサーバーによって、例えば、そのＥＭＳサーバーによって管理されているネットワーク要素から取得されたアラーム・ステータス・データ及びＥＭＳステータス・データを含む。ＥＭＳサーバー内のネットワーク・ステータス・データ構造３２は、ネットワーク内のＥＭＳサーバーの全てに対するアラーム・ステータス・データ及びＥＭＳステータス・データを含む。
【００１６】
サーバー３０ａ−３０ｃの各々は、データ構造３２を含むメッセージ３６を１以上の他のサーバー３０ａ−３０ｃに対して送信及び受信し、それにより現在のネットワーク・ステータス・データを交換し、即ち、共有する。メッセージ３６はユーザーによって設定可能な速度で及び所定の回数送信されるようにしてもよい。メッセージ通信には、既存のＤＣＮによって使用されるプロトコルのように当業者に一般に知られているようなプロトコルを用いる。サーバー３０ａ−３０ｃは、以下に説明するような、分散型メッセージングを同調するために（例えば、１秒以内に）同期を保たれたイベント・タイム・スタンピング・クロック３８を含んでもよい。時間同期は、通常の知識を有する当業者には一般に知られているネットワーク・タイム・プロトコル（ＮＴＰ）のような工業規格技術を用いて実現される。
【００１７】
サーバー３０ａがメッセージ３６を他のサーバー３０ａ−３０ｃのうちの１つから受信するとき、メッセージ３６内のネットワーク・ステータス・データはサーバー３０ａ内のネットワーク・ステータス・データ構造３２を更新するために使用される。それによってサーバー３０ａ−３０ｃの各々はネットワーク内のサーバー３０ａ−３０ｃの全てについて現在のネットワーク・ステータス・データを保持する。また、サーバー３０ａ−３０ｃの各々はデータ更新及びメッセージング・システム４０を含み、それはデータ構造３２の更新及びメッセージング機能を扱う。データ更新及びメッセージング・システム４０は、例えば、以下に説明するスター型ブロードキャスト方式又はＣＭＱ方式に従って、データ更新及びメッセージングを扱うようにしてもよい。
【００１８】
サーバー３０ａ−３０ｃの各々は、あるタイプの共有化されたネットワーク・ステータス・データを表示するために、グラフィカル・ユーザー・インターフェイス（ＧＵＩ）のようなユーザーインターフェイス４２をサポートするようにしてもよい。ＥＭＳにおいて、例えば、ユーザーインターフェイス４２はＥＭＳサーバーにログインしたクライアントのワークステーションに導入し、アラーム・ステータス情報を表示するために使用してもよい。サーバー３０ａにおいてネットワーク・ステータス・データが更新されると（例えば、ネットワーク・ステータス・データのメッセージを受信した後に）、サーバー３０ａがユーザーインターフェイス４２を適宜更新するようにしてもよい。
【００１９】
図５に示すように一実施形態によると、分散型メッセージングが、ＥＭＳサーバー５０−１・・・５０−ｎ間でネットワーク・ステータス・データを共有するためにスター型ブロードキャスト方式を用いて提供されるようにしてもよい。ＥＭＳサーバー５０−１・・・５０−ｎの各々はメッセージをネットワーク内の他の全ての利用可能なＥＭＳサーバーに対してブロードキャスト又は送信する。説明の簡単のため、１つのＥＭＳサーバー５０−１がそのデータを他のＥＭＳサーバー５０−２・・・５０−ｎにブロードキャスト又は送信するものを示す。当業者であれば他のサーバー５０−２・・・５０−ｎが同様にメッセージをブロードキャストすることは認識できるであろう。
【００２０】
スター型ブロードキャスト方式で用いられるデータ又はメッセージ構造の一実施例が図６に示される。ＥＭＳサーバー５０−１・・・５０−ｎの各々が、メッセージバッファ（ＭＢ）５２と称するバッファをメモリ内に保持し、サーバーからみたネットワーク・ステータス・データを保持する。各ＭＢ５２は、ネットワーク内のそれぞれｎ番目のサーバー５０−１・・・５０−ｎの各々に対するｎ個のデータブロック５４−１・・・５４−ｎ（ＤＢ１−ＤＢｎ）を含む。データブロック５４−１・・・５４−ｎの各々は、それぞれのＥＭＳサーバー５０−１・・・５０−ｎに対して、データブロックの最後の更新の日時スタンプ５６、ＥＭＳステータス・データ５８、ＥＭＳアラーム・ステータス・データ６０及びＥＭＳサーバー利用可能性データ６２を含む。
【００２１】
例示的スター型ブロードキャスト方式によると、ＥＭＳサーバー５０−１内のデータが更新されたとき、ＥＭＳサーバー５０−１はメッセージ（即ち、そのＭＢ５２のコピー）を他のＥＭＳサーバー５０−２・・・５０−ｎにブロードキャスト又は送信する。また、ＥＭＳサーバー５０−１は、たとえデータが更新されていなくても所定の期間後にメッセージをブロードキャストするようにしてもよい。このメッセージ（以下、「維持（keep alive）」メッセージと呼ぶ）は、他のサーバー５０−２・・・５０−ｎがサーバー５０−１は報告なしであるとみなしてしまうことを防止する。一実施例では、ＥＭＳサーバー５０−１・・・５０−ｎの各々が、維持メッセージを送る前の期間を記録する維持タイマー（ＫＡＴ）を含むようにしてもよい。
【００２２】
ＥＭＳサーバー５０−１・・・５０−ｎ内のクロック各々は時間同期され、メッセージが異なる時間に送信されることを可能とし、及び報告されたタイムスタンプ値が正確であることを確かなものとする。一実施例において、ＥＭＳサーバー５０−１・・・５０−ｎの各々は、それぞれのＭＢ５２のコピーを他のＥＭＳサーバーにブロードキャストするための送信時間（ＴＴ）を割り当てられる。サーバーｍの送信時間は、例えば、アルゴリズム：ＴＴｍ＝ｏ＋ｍ＊ｘ／ｎに従って計算される。ここで、ｏは時間オフセット（例えば、分）、ｘはシステム全体の設定パラメータ、ｎはサーバーの合計数である。この例示的アルゴリズムは、サーバーｍがそのＭＢのコピーを他のｎ−１個のサーバーのいずれかとは異なる時間にブロードキャストすることを確実にするので、従ってネットワーク内の衝突や受信機の過負荷を防止できる。
【００２３】
また、ＥＭＳサーバー５０−１・・・５０−ｎの各々は、他のＥＭＳサーバーの報告あり／なしを監視する。一実施例として、ＥＭＳサーバー５０−１・・・５０−ｎの各々はネットワーク内の他のサーバーの各々に対する受信タイマー（ＲＴ）又はカウンター（即ち、ｎ−１個の他のサーバーについてのｎ−１個のＲＴカウンター）を保持する。サーバーｎに対する受信タイマー（ＲＴｎ）は、サーバーｎが報告なしとされる前に、サーバーｎからの更新されたデータ又は維持メッセージを付帯するメッセージがそのサーバーに来るまでにかかる時間を示す。この実施例では、サーバーが他のサーバーｎのために保持する受信タイマー（ＲＴｎ）の値は、サーバーｎによって保持される維持タイマー（ＫＡＴ）の値よりも大きく、例えば、Ｘ＞０として、ＲＴｎ＝ＫＡＴ＋Ｘと表される。これによって、他のサーバーが報告なしステータスが発生したと判断する前に、サーバーが維持メッセージを送ることができる。
【００２４】
データを更新してそれをスター型ブロードキャスト方式を用いてサーバーにメッセージングするための例示的処理が図７に示される。各サーバーが起動すると初期化が行われる（１１０）。初期化の間、例えば、サーバーは、報告なしアラーム・ステータス表示をメッセージバッファ内のｎ−１個のデータブロック各々に対する各現在アラーム・ステータスに割り当て、メッセージバッファ内のｎ−１個のデータブロック各々の日時スタンプを現時刻に設定し、そのメッセージバッファ内のｎ−１個のデータブロック各々のネットワーク・ステータスを消去する。
【００２５】
初期化の後、サーバーは、サーバーの維持タイマー（ＫＡＴ）が終了したか（１２０）、メッセージが他のサーバーの１つから受信されたか（１３０）、サーバーの送信時間（ＴＴ）が来たか（１４０）、及び／又は他のサーバーのいずれか１つに対する受信時間（ＲＴ）が終了したか（１５０）を判定する。サーバーの維持タイマーが終了すると（１２０）、たとえステータスが変化していなくてもステータス・メッセージ（即ち、維持メッセージ）をブロードキャストし、その維持タイマーをリセットする（１２２）。
【００２６】
サーバーが他のサーバーの１つからメッセージを受信した場合（１３０）、受信サーバーは送信サーバーｎについての受信タイマー（ＲＴｎ）をリセットする（１３２）。そして、受信サーバーは、受信されたメッセージからのネットワーク・ステータス・データによってそのメッセージ内のデータブロックを更新する（１３４）。受信サーバーに関連するデータブロック以外の、受信されたメッセージの各データブロックに対して、受信サーバーはそのブロックの日時スタンプをそのメッセージバッファ内の対応するデータブロックに記憶された日時スタンプと比較する。日時スタンプが受信メッセージのデータブロック内のものよりも最近であることを値が示している場合、そのデータブロックに対して、受信サーバーは日時スタンプ、アラーム・ステータス・データ及びＥＭＳステータス・データの値を受信サーバーのメッセージバッファ内の対応するデータブロックにコピーする。
【００２７】
受信サーバーによってサポートされているユーザーインターフェイス上に表示されたデータのいずれかの値が変化した場合（１３６）、サーバーはそれに従ってユーザーインターフェイスを更新する（１３８）。例えば、ＥＭＳサーバーにログインしたクライアントのワークステーションのＧＵＩ上のアラーム・ステータスの値が更新されるようにしてもよい。
【００２８】
サーバーｍで送信時間が来たとき（１４０）、サーバーｍはそのデータ構造又はメッセージバッファ内のデータブロック（ＤＢｍ）を更新する（１４２）。例えば、サーバーｍは自身のデータブロック（ＤＢｍ）内の日時スタンプを現在の日付／時刻に設定し、自身のデータブロック（ＤＢｍ）を自身の現在のアラーム・ステータスを用いて更新し、自身のＥＭＳステータスを用いて自身のデータブロック（ＤＢｍ）を更新する。そして、サーバーｍは、そのデータブロック（ＤＢｍ）内の値を、サーバーｍによって送信された最後のメッセージ内の自身のデータブロック（ＤＢｍ）内の値と比較する（１４４）。それらの値に差（即ち、最後のブロードキャストからのステータスの変化）がある場合、サーバーｍはメッセージを他のサーバーにブロードキャストし、その維持タイマーをリセットする（１４６）。サーバーｍによってサポートされるユーザーインターフェイス上に表示されたデータのいずれかの値が変化したことをサーバーｍが検出した場合（１３６）、サーバーｍがそれに従ってユーザーインターフェイスを更新する（１３８）。例えば、ＥＭＳサーバーにログインしたクライアントのワークステーションのＧＵＩが、アラーム・ステータスに関連する日付／時刻スタンプだけでなくｎ個のサーバーの各々に対する更新されたアラーム・ステータスを表示するようにしてもよい。
【００２９】
期待される送信サーバーからのメッセージをサーバーが受信する前に、サーバー内の受信タイマー（ＲＴｎ−１）のどれかが終了した場合（１５０）、サーバーは、期待される送信サーバーに対して報告なしアラーム・ステータス表示を割り当てる（１５２）。報告なしアラーム・ステータス表示が、期待される受信サーバーに対するメッセージバッファにおいて、期待される送信サーバーｎに対応するデータブロック（ＤＢｎ）に対する現在のアラーム・ステータスに割り当てられる。また、期待される受信サーバーはそのメッセージバッファを、対応するデータブロック（ＤＢｎ）内の日時スタンプを現在の時刻に設定することによって更新し、対応するデータブロック（ＤＢｎ）のステータスを消去し、それによりサーバーｎを報告なしとみなす。
【００３０】
他の実施形態によると、図８に示すように、分散型メッセージはＣＭＱ方式を用いて提供され、ＥＭＳサーバー７０−１・・・７０−ｎ間でネットワーク・ステータス・データを共有する。ＥＭＳサーバー７０−１・・・７０−ｎの各々はメッセージを隣接するＥＭＳサーバーに所定の順序で配信する。この環状メッセージフローを提供することによって、システムを流れるメッセージ数及び各サーバー７０−１・・・７０−ｎのオーバーヘッド処理が軽減される。この方法によると、ＥＭＳサーバー７０−１・・・７０−ｎの各々は、ネットワーク内の全てのＥＭＳサーバーを収容してメッセージがネットワークを横切る順序を規定するリストを含む。例えば、各ＥＭＳサーバー７０−１・・・７０−ｎは、全てのサーバーの遅延時間及びＤＣＮアドレス（例えば、ＩＰアドレス）に対するデフォルトの値を含むフィールド可変構成ファイル（ＦＭＣＦ）で構成される。ＦＭＣＦ内にリストアップされたサーバー７０−１・・・７０−ｎの順序がＣＭＱのフローを規定する。
【００３１】
通常動作中（即ち、リスト内の全てのＥＭＳサーバーが正しく通信しているとき）は、ネットワーク・ステータス・メッセージ受信時に、各ＥＭＳサーバー７０−１・・・７０−ｎは自身のネットワーク・ステータス・データ（例えば、アラーム・ステータス・データ及びＥＭＳステータス・データ）をネットワーク・ステータス・メッセージに追加する。そして、ＥＭＳサーバー７０−１・・・７０−ｎは更新されたメッセージを、遅延時間の後、リストで規定された隣接するＥＭＳサーバーに転送する。
【００３２】
ＣＭＱ方式で用いられるデータ又はメッセージ構造の一実施形態が図９に示される。データ構造７２は、ネットワーク内の各ＥＭＳに対して、サーバー利用可能性属性７４、遅延時間属性７６、日付／時刻スタンプ７８、アラーム属性８０−８６、及びＥＭＳステータス属性８８を含む。サーバー利用可能性属性７４は、ネットワーク内で関連するＥＭＳサーバーが「利用可能」か「利用不可」か、を示す。遅延時間属性７６はメッセージを転送する前に関連するＥＭＳサーバーが遅延している期間（例えば、秒単位）を示す。タイムスタンプ７８は関連するＥＭＳサーバーに対する最後の更新（即ち、関連するＥＭＳサーバーによる最後のメッセージ送信の時）の日付／時刻（例えば、月／日及び時間、分並びに秒）を示す。アラーム属性８０−８６は、更新時にその時にアクティブとなっているアラーム数（重大及び軽微）についての現在のアラーム属性８０、８４、及び最後のメッセージ送信から記録されたアラーム（重大及び軽微）の合計数についての合計アラーム属性８２、８６を含む。最後に更新されてから記録された重大及び軽微アラームの合計数によって、更新と更新の間の時間内に非アクティブからアクティブに、そして非アクティブに切り換わるアラーム数が分かる。ＥＭＳサーバー属性８８はＥＭＳステータス・データを示し、又は記述する。
【００３３】
また、ＣＮＱ分散型メッセージング方式の一実施形態は、１以上のＥＭＳサーバー７０−１・・・７０−ｎが音信不通又は利用不可になったときの回復方法も含む。１つの例示的回復方法によると、各サーバー７０−１・・・７０−ｎが、メッセージがネットワークに行き渡りサーバーに戻ってくるのにかかる推定時間を判定する。各サーバー７０−１・・・７０−ｎは時間切れ時間を、例えば、ネットワーク・ステータス・メッセージ内の遅延時間を用いて、利用可能とみなされたＥＭＳサーバーの全てに対する遅延時間を合計することによって求める。期待される時間内にサーバーがその近隣からネットワーク・ステータス・メッセージを受信しない場合、サーバーはネットワーク・ステータス・メッセージを待つことを中止する。これは、ネットワーク内で、ＣＭＱ使用時のネットワーク内の全サーバー間での通信を防ぐ「切れ目」が発生したことを示す。このような切れ目はサーバーの故障、ＤＣＮの故障、システムの保守又は他の状況によって起こり得る。
【００３４】
下記により詳しく説明されるように、サーバーがメッセージを待つことを中止したとき、サーバーは利用可能なサーバーを特定してメッセージを利用可能なサーバーに送信し続ける。各サーバー７０−１・・・７０−ｎは（例えばＦＭＣＦ内の）サーバーのリストにおける自身の場所を用いて、時間切れの値に対するオフセットを規定する。これによって、ネットワーク内の全サーバー７０−１・・・７０−ｎが変動する時間切れによって構成され、回復が１つのサーバーによって瞬時に行われる。
【００３５】
サーバーがメッセージを利用可能なサーバーに送り続けた結果として、例えば、図１０に示すような、９０−１・・・９０−ｘ及び９０−(ｘ＋１)・・・９０−ｎのように、ネットワークは２以上の通信可能なＥＭＳサーバーのグループに分断される。これによって、分散メッセージングが切れ目、即ち、ネットワーク故障９４にもかかわらず存続できる複数のＣＭＱフロー９２ａ、９２ｂが形成される。従って、回復方法は自己治癒メカニズムを備える。
【００３６】
ＣＭＱ方式を用いてサーバー内でデータを更新しメッセージングするための代表的処理が図１１に示される。サーバーがネットワーク・ステータス・データ・メッセージを受信した場合（２１０）、サーバーはメッセージの自身の部分を（例えば、タイムスタンプやネットワーク・ステータス・データによって）更新し、遅延タイマーをセットする（２１２）。サーバーは更新されたメッセージの値を、サーバーで受信された最後のネットワーク・ステータス・データ・メッセージのコピーと比較する（２１４）。値の差はネットワーク・ステータスが変化したことを示し（２１４）、メッセージが処理され、そのサーバーによってサポートされ管理されるいずれかのユーザーインターフェイスが更新される（２１６）。変化がない場合（２１４）、サーバーは他のメッセージを待つ（２１０）。
【００３７】
また、サーバーは、例えば、隣接サーバーに対応するメッセージの部分において示された利用可能性ステータスに基づいて隣接するサーバーが利用可能かを判定する（２１８）。すぐ隣のサーバーが利用できない場合、サーバーは次の隣のサーバーの利用可能性をチェックする（２１９、２１８）。隣接サーバーが利用可能で遅延タイマーが終了した場合（２２０）、メッセージは隣接サーバーに転送される（２２２）。そして、遅延タイマー及び時間切れタイマーがリセットされ（２２４）、サーバーは他のメッセージを待つ（２１０）。
【００３８】
ＥＭＳサーバーはネットワーク・ステータス・データ・メッセージにおけるＥＭＳ遅延時間の全てを、ネットワーク・ステータス・メッセージを隣接サーバーに送信する前にゼロにセットする。ネットワーク・ステータス・メッセージを遅延なしでネットワーク中に伝達することによって、ＥＭＳが情報をネットワーク中により速く行き渡らせることができる。そして、例えばメッセージがＥＭＳサーバーに戻る時に、遅延時間を変化させるＥＭＳサーバーは遅延時間を当初の設定にリセットする。
【００３９】
サーバーがメッセージを待つ間に時間切れタイマーが終了した場合（２４０）、サーバーは利用可能性ステータス・リクエスト・メッセージ・ブロードキャストをネットワーク内の他の全てのサーバーに発信し、タイマーをセットする（２４２）。利用可能性ステータス・リクエスト・メッセージを発信するサーバーを発信元と称す。他のサーバーが利用可能性ステータス・リクエスト・メッセージを受信すると、サーバーは発信元に応答し、自身の時間切れタイマーをリセットする。応答が受信されると（２４４）、発信元はサーバー利用可能性属性をネットワーク・ステータス・メッセージ内の各サーバーについて更新する（２４６）。全サーバーが応答した時又はタイマーが終了した時（２４８）、ネットワーク・ステータス・メッセージはネットワーク・ステータス・データ及び利用可能性ステータス・データによって更新される（２５０）。そして、更新されたネットワーク・ステータス・メッセージは、サーバー利用可能性属性によって示されるように次の利用可能な隣接するサーバー２１８に転送される。ネットワーク内の各サーバーがネットワーク・ステータス・メッセージを自身のステータス情報を用いて更新することを続け、それを次の利用可能な隣接サーバーに転送する。
【００４０】
図１０に示されるように、例えば、発信元ＥＭＳサーバー９０−１、９０−(ｘ＋１)がステータス・リクエスト・メッセージを他のＥＭＳサーバーにブロードキャストする。発信元ＥＭＳサーバー９０−１はＥＭＳサーバー９０−(ｘ＋１)・・・９０−ｎが利用不可であると判断し、発信元ＥＭＳサーバー９０−(ｘ＋１)はＥＭＳサーバー９０−１・・・９０−ｘが利用不可であると判断する。利用可能なＥＭＳサーバー間でメッセージ送信が継続すると、ＥＭＳネットワークが分断されて１以上のＣＭＱフロー９２ａ、９２ｂが形成される。ＥＭＳネットワークが分断されると、発信元ＥＭＳサーバー９０−１、９０−(ｘ＋１)はメッセージを受信し、利用可能性ステータス・メッセージを利用不可ＥＭＳサーバーの全てに送り、利用可能／利用不可ステータス表示を適切に更新することを継続する。各発信元ＥＭＳサーバー９０−１、９０−(ｘ＋１)は利用可能性ステータス・リクエストを、全てが応答するまで又は１つの発信元が利用可能性リクエスト・メッセージを他の発信元から受信するまで、ネットワーク内の利用不可ＥＭＳサーバーの全てに送り続ける。問題が解決されるとき、発信元サーバーによる利用可能性ステータス・リクエスト・メッセージの受信があるということは、ネットワーク内に少なくとも１つの他の発信元サーバーがあることを示している。そのような利用可能性・リクエスト・メッセージを他の発信元から受信する発信元サーバーは、メッセージを隣接するサーバーに転送する前に自身の時間切れタイマーをリセットし新しいメッセージを待つ。
【００４１】
分散型メッセージング・システム及び方法の実施形態はコンピュータシステムで用いるためのコンピュータプログラム製品として実施できる。そのような実施は、システム及び方法の観点で個々に説明された機能の全部又は一部を具現化する一連のコンピュータ命令を制限なく含む。一連のコンピュータ命令は、半導体、磁気、光学又は他のメモリ装置等のどのような機械可読媒体に記憶されていてもよく、光学、赤外、マイクロ波又は他の伝送技術等のどのような通信技術を用いて伝送されてもよい。そのようなコンピュータプログラム製品は、取り外し可能機械可読媒体（例えば、ディスケット、ＣＤ−ＲＯＭ等）に分散されていてもよいし、コンピュータシステム（例えば、システムＲＯＭ又は固定ディスク）に予め読み込まれていてもよいし、又はネットワーク上でサーバー若しくは電子掲示板（例えば、インターネット又はワールド・ワイド・ウェブ）から分配されるようにしてもよいことは当然に予想される。
【００４２】
当業者であれば、そのようなコンピュータ命令は、多くのコンピュータアーキテクチャ又はオペレーティングシステムで使用される多数のプログラム言語で書かれ得ることを理解するはずである。例えば、好適な実施形態は手続きプログラム言語（例えば、「Ｃ」）又はオブジェクト指向プログラム言語（例えば、「Ｃ＋＋」又はＪａｖａ（登録商標））において実施してもよい。発明の代替の実施形態は、予めプログラムされたハードウェア要素若しくはファームウェアとして、又はハードウェア、ソフトウェア若しくはファームウェアの組み合わせとして実施してもよい。
【００４３】
従って、分散型メッセージング・システム及び方法を用いることによって、１つのサーバーへの依存を最小にしてデータがネットワーク内のサーバー間で共有されることができる。また、分散型メッセージングはトラフィックフローを軽減し、システムのボトルネックをなくすことができる。
【００４４】
発明の原理がここに説明されてきたが、当業者には分かるように、この説明はあくまでも例示としてなされたものであり、発明の範囲についての制限としてなされたものではない。ここに示され説明された代表的実施形態に加えて他の実施形態も発明の範疇において考えられる。通常の当業者による変更及び置換は本発明の範疇のものとしてみなされ、その本発明の範疇は特許請求の範囲以外のものによって制限されるものではない。
【図面の簡単な説明】
【００４５】
【図１】図１はネットワーク管理システム（ＮＭＳ）のグラフィカルユーザーインターフェイス（ＧＵＩ）を示す図である。
【図２】図２は要素管理システム（ＥＭＳ）とＮＭＳ間のデータ共有化のための階層的手法を示す概略図である。
【図３】図３は本発明の一実形態による、ＥＭＳ間データ共有化の分散型メッセージング手法を示す概略図である。
【図４】図４は本発明の一実形態による分散型メッセージング・システムを示す概略の機能ブロック図である。
【図５】図５はブロードキャスト方式を用いた分散型メッセージングの一実施形態を示す概略図である。
【図６】図６はブロードキャスト分散型メッセージング方式で用いられるデータ構造の一実施形態を示す概略のブロック図である。
【図７】図７はブロードキャスト方式を用いたデータ及びメッセージング更新のための処理の一実施例を示すフローチャートである。
【図８】図８は他の実施形態である環状メッセージキュー（ＣＭＱ）方式を用いた分散型メッセージングを示す概略図である。
【図９】図９はＣＭＱ方式で用いられるデータ構造の一実施形態を示す概略のブロック図である。
【図１０】図１０はネットワーク故障の場合におけるＣＭＱ方式を用いた分散型メッセージングのさらなる実施形態を示す概略図である。
【図１１】図１１はＣＭＱ方式を用いたデータ及びメッセージングの更新のための処理の一実施例を示すフローチャートである。
【符号の説明】
【００４６】
２０−１〜２０−ｎ．ＥＭＳサーバー
３０ａ〜３０ｃ．サーバー
３２．データ構造
３４．ローカル・ネットワーク・ステータス・データ
３６．メッセージ
３８．イベント・タイミング・スタンピング・クロック
４０．メッセージング・システム
４２．ユーザーインターフェイス
５０−１〜５０−ｎ．ＥＭＳサーバー
５２．メッセージバッファ
５４−１〜５４−ｎ．データブロック
５６．日時スタンプ
５８．ＥＭＳステータス・データ
６０．ＥＭＳアラーム・ステータス・データ
６２．ＥＭＳサーバー利用可能性データ
７０−１〜７０−ｎ．ＥＭＳサーバー
７２．データ構造遅延時間属性
７４．サーバー利用可能性属性
７６．遅延時間属性
７８．日付／時刻スタンプ
８０、８２、８４、８６．アラーム属性
８８．ＥＭＳステータス属性
９０−１〜９０−ｎ．ＥＭＳサーバー
９２ａ、９２ｂ．ＣＭＱフロー
９４．ネットワーク故障
【図１】
2006042343.tif 000003
【図２】
2006042343.tif 000004
【図３】
2006042343.tif 000005
【図４】
2006042343.tif 000006
【図５】
2006042343.tif 000007
【図６】
2006042343.tif 000008
【図７】
2006042343.tif 000009
【図８】
2006042343.tif 000010
【図９】
2006042343.tif 000011
【図１０】
2006042343.tif 000012
【図１１】
2006042343.tif 000013