JP4195452B2 - イベント・バス・システム、イベント・レポートを処理するための方法およびコンピュータ・プログラム - Google Patents

Description

本発明は、管理対象ネットワーク・コンピュータからの障害報告など、コンピューティング環境において電子的に報告されたイベントを処理するための回路、システム、および方法に関する。

今日のビジネス環境では、従業員の生産性および顧客満足度はシステム障害および遅延により負の影響を受ける可能性がある。ハイパフォーマンスを達成するために、システムの欠陥は適時に診断し解決しなければならない。高度に相互接続されたシステムでは、問題解決の複雑さのレベルは相当なものである。往々にして、複数の管理者およびサポート・スタッフが同一の問題通知を受信することになり、それが重複作業を生み、多くの場合、ワーク・フローの有効性、システム応答、および生産性を損なう。

一般に大規模アカウント（たとえば、大型小売店、政府機関などのためのコンピュータ・システム）においてシステム管理の領域で発生する状況は、複数のロケーションから複数の「ホーム」サーバへのイベントのフローであり、そのサーバにはそれぞれの定義済みタスクに基づいて様々なタスクが割り当てられている。この環境で発生する主な要件のうちの２つは、（ａ）複数のイベント・サーバにそのイベントを送信する必要性と、（ｂ）「フェイルオーバ」機能を提供することである。

現在までの標準的なソリューションは、イベントのソースまたは下位レベルにあるそのシステムのインフラストラクチャの一部のいずれかで定義された「ルール」またはロジックに基づいて、種々のサーバ宛てにイベントを送信させることであった。これは、いくつかの問題をもたらした。その第１の問題は、ネットワーク・インフラストラクチャが多くの場合、必要な負荷の４〜５倍を処理できると想定していることである。第２に、イベント所有権およびフェイルオーバ方式は、このロジックに電力を供給するために必要なハードウェアを含めて、多種多様なロケーションを伴う種々の地理を含む多数のポイントにあるインフラストラクチャの下位レベル部分間で調整することが必要であり、システム構成および配置を困難にしている。

したがって、最適構成で諸技術を統合させるために、今日のネットワーク・コンピューティング企業は、オープンでスケーラブルかつクロスプラットフォームの手法を必要としている。このようなシステム・ソリューションの１つは、ＩＢＭのＴｉｖｏｌｉ（登録商標）Ｍａｎａｇｅｍｅｎｔ Ｆｒａｍｅｗｏｒｋ（「ＴＭＦ」）であり、これは複合コンピューティング・システムおよびネットワーク管理のための管理アプリケーションのスイートの基礎である。ＴＭＦは以下の機能およびサービスを有する。
（ａ）ユーザがタスク・ライブラリを介して複数のＴｉｖｏｌｉリソースに関するタスクを作成し実行できるようにする。
（ｂ）タスク・ライブラリを実行するためのスケジューラを提供する。
（ｃ）他のＴｉｖｏｌｉ製品がアプリケーション固有情報をリレーショナル・データベースに書き込めるようにするリレーショナル・データベース管理システム（「ＲＤＢＭＳ」）インターフェース・モジュール（ＲＩＭ）を含む。
（ｄ）ユーザがリレーショナル・データベースからデータを検索し取得できるようにする照会機能を組み込む。

ＴＭＦとともに適切に機能するもう１つのツールは、ＩＢＭのＴｉｖｏｌｉ Ｅｎｔｅｒｐｒｉｓｅ Ｃｏｎｓｏｌｅ（「ＴＥＣ」）である。ＴＥＣは、システム・パフォーマンスを改善し、サポート・コストを低減するための洗練され高度に自動化された問題診断解決ツールである。ＴＥＣは、システム、データベース、ネットワーク、およびアプリケーションの管理を統合するルール・ベースのイベント管理アプリケーションである。ＴＥＣは、サーバ障害、ネットワーク接続の喪失、またはバッチ処理ジョブの正常完了などの一般的な管理イベントを収集し、処理し、それに対して自動的に応答する能力を有する。各ＴＥＣは、様々なソースからの警報およびイベントに関する中央収集ポイントとして動作し、受信したイベントの重大度のレベルに基づいてタスクに優先順位を付け、冗長または低優先順位イベントをフィルタリングする。また、ＴＥＣの調整機能は、特定のイベントを処理して問題を迅速に解決するためにレビュアを識別するのにも役に立つ。

ＩＢＭのＴｉｖｏｌｉ Ｍａｎａｇｅｍｅｎｔ Ｆｒａｍｅｗｏｒｋは、Ｔｉｖｏｌｉ Ｅｎｔｅｒｐｒｉｓｅ Ｃｏｎｓｏｌｅのための土台として機能する。このフレームワークとコンソールを一緒に使用することにより、複数のオペレーティング・システムを備えた大規模分散ネットワークを管理することができ、そのオペレーティング・システムはノードおよびユーザを絶えず変更することができる多様なシステム操作を実行する種々のネットワーク・サービスを使用することができる。

ＴＥＣの既存プロセスを理解するために、次に図３を参照する。典型的なイベント・プロセス（３０）を示すこの図では、単一障害に関連する単一イベント・ソース（３２）によってＭ個のイベント・レポート（３４ａ〜３４ｍ）が生成される。たとえば、システムのプリンタが用紙切れである場合、文書を印刷しようと試行しているアプリケーション・プログラムによって第１のイベント・レポートが生成される可能性があり、そのプリンタがオフラインになっているかまたは通信していないことを発見したときにそのシステムのオペレーティング・システムによって第２のイベント・レポートが生成される可能性があり、プリンタ管理アプリケーション・プログラムなどによって第３のイベント・レポートが生成される可能性がある。

システム（３２）の構成に基づいて、Ｍ個の関連イベント・レポートのそれぞれのコピーが電話網を備えたダイヤルアップ・モデムなどの通信ネットワーク（３１）を介して１つまたは複数の指定のＴＥＣサーバ（３３ａ、３３ｂ、３３ｎ）に送信される。少なくとも１つのＴＥＣサーバが正常に障害を受信し、それについて動作することを保証しようと努めて、このような複数のイベント・レポートの複数のコピー（たとえば、Ｍ×ｎ個）が送信される。これは応答システムの信頼性を増大するが、このような重複レポートにより冗長データや重複努力が発生する。

図４を参照すると、イベント・レポートの典型的な処理を示すより広範囲のシステム図が示されており、各ＴＥＣサーバが複数のイベント・ソースからイベント・レポートを受信する。この例（４０）では、複数のイベント・ソース（３２ａ、３２ｂ、・・・３２ｘ）からの複数のイベント・レポート（４２）が通信ネットワーク（３１）を介して送信され、複数のＴＥＣサーバ（３３ａ〜３３ｎ）によって受信（４１）されるが、図３のところで述べたような重複レポートを含んでいる。したがって、たとえば、この広範囲の例では、合計Ｍ×ｎ×ｘ個のイベント・レポートがイベント・ソースとＴＥＣサーバとの間で送信される。

各イベント・レポートが特定のＴＥＣサーバに到達すると、適切なデータがローカル・イベント・データベース（４３ａ、４３ｂ、・・・４３ｎ）に保管される。ＩＢＭのＬｏｔｕｓ Ｎｏｔｅｓ（登録商標）やＤｏｍｉｎｏ（登録商標）プログラムなどの分散リレーショナル・データベース同期化プログラムを使用して、ＴＥＣサーバのデータベースは、事前定義されたルールおよび期間に基づいて定期的に互いに同期化される（４４）。

たとえば、イベント・レポートＡ（図示せず）はイベント・ソース（３２ｘ）から生成され、コピーはＴＥＣサーバ１および２（３３ａ、３３ｂ）に送信される。ＴＥＣサーバ１（３３ａ）によって受信されると、これは直ちにＴＥＣサーバ１のローカル・データベース（４３ａ）に保管される。同様に、イベント・ソース（３２ｘ）からのイベント・レポートＡがＴＥＣサーバ２（３３ｂ）によって受信されると、これは直ちにＴＥＣサーバ２のローカル・データベース（４３ｂ）に保管される。この時点では、データベース同期化スケジュール・ルール、データベース同期化プロセス用のネットワーク・リソースの可用性、同期化すべきデータの量に応じて、数分後、数時間後、または数日後などに次のデータベース同期化（４４）が行われるまで、いずれのＴＥＣサーバも、もう一方のサーバがイベント・レポートのコピーを受信していることを承知していない。次の同期化プロセスの後で、ＴＥＣサーバ１および２には、イベント・レポートＡが他のＴＥＣサーバによって解決されるかどうかが通知される。解決されない場合、現地担当者が報告イベント・ソース・システムをサポートするためのバックアップ・リソースとして問題を解決せざるを得ない可能性がある。

データベース同期化は即時ではない（たとえば、「リアルタイム」ではない）ので、少なくとも１つの同期化期間が経過してしまうまで、イベント・レポートが他のバックアップＴＥＣサーバによって対処されない可能性がある。さらに、各イベント・ソースは、３つ、４つ、またはそれ以上のＴＥＣサーバなどの複数のＴＥＣサーバにイベントを報告するように構成することができ、それもまた、問題の解決が全サーバのうちの他のサーバではなく特定のＴＥＣサーバにかかっていることをその特定のＴＥＣサーバが承知する前に、それぞれのデータベースによる更新および同期化遅延が発生することを示している。

その結果として、応答時間の遅延の延長が発生し、それが現行プロセスの望ましくない特性になっている。さらに、同じイベント・レポートの複数のコピーが複数のＴＥＣサーバに同時に送信されるので、システムは重複データを保管し、それにより、問題を解決するために遅延を低減しようとして冗長なサポート努力を発生する可能性がある。たとえば、ＴＥＣサーバ３がＴＥＣサーバ２の第２のバックアップとして定義され、そのＴＥＣサーバ２が特定のイベント・ソースについてＴＥＣサーバ１の第１のバックアップである場合であって、しかもＴＥＣサーバ１または２のいずれも報告された問題に対処していないとシステムが判定するのに最高２時間を要する可能性があることを技術者が経験によって知っている場合、２時間の望まれていない遅延を見越して、ＴＥＣサーバ１および２が問題に対処していないという実際の通知の前に問題を解決するためにＴＥＣサーバ３に関連する技術者が派遣される可能性がある。しかし、ＴＥＣサーバ１または２が問題に対処し始めた（たとえば、技術者またはソフトウェアによる解決プロセスが開始された）場合、ＴＥＣサーバ３の努力は冗長かつ無駄なものになり、多くの場合、状況を混乱させるものになる。

このような理由で、当技術分野では、問題解決努力の重複および問題解決の責任を取り巻く混乱を回避しながら、報告されたイベントに適時に対処し、複数のバックアップ・サーバからなるシステムを維持し、重複イベント・レポートを処理するシステムおよび方法が必要になっている。

さらに、当技術分野では、直ちにイベント・レポートに応答するために、複数のイベント・サーバ間でのリアルタイム・イベント同期化を可能にするシステムおよび方法が必要になっている。さらに、当技術分野では、コスト節約のために費やす時間およびエネルギーを低減するために重複サポート努力を解消することが必要になっている。

本発明は、ＴＥＣイベント同期（「ＴＥｖＳ」）と呼ばれ、Ｔｉｖｏｌｉ（登録商標）Ｅｖｅｎｔ Ｃｏｎｓｏｌｅ（「ＴＥＣ」）などのイベント管理システム内でまたは同様のシステム、プログラム、およびツールにより、複数のイベント・ソースから生成され報告されたイベントを処理するためのユニークな方法を提供する。

ＴＥｖＳは、複数のＴＥＣサーバを一緒にリンクし、各レポートに所有権を割り当てるイベント・バスを提供する。ＴＥｖＳは、好ましくは、イベント・バスを実現するために複数のＴＥＣサーバ間に配備された１組のＴＥｖＳモジュールを提供する。ＴＥｖＳモジュールは、スロット値を追加または変更するために各着信イベントを解析する。スロット値に基づいて、イベントは構成されたイベント・サーバに転送される。加えて、拡張された一実施形態は、エラーフリーの体系的な伝送フローを維持するために所有権を動的に変更する能力を有する。

本発明のもう１つの機能強化策では、管理者またはサポート・スタッフは、イベント・フラッドを集計し、イベント統計を計算し、イベントをログ記録するかまたはキャッシュに入れる能力を有する。さらに、サーバまたはモジュールが故障した場合、そのソースは、プロセスを続行するために２次サーバまたはモジュールにロールオーバすることになるであろう。所有者が指定されていないシナリオでは、それに応じて動作するよう委任されたサーバにプロンプトで指示するために、スロット値が追加または割り当てられることになる。

好ましい一実施形態は、ＴＥＣおよびＴＭＦによる特定の実現例のためにＴＥＣのルール・ベースのフレームワークに準拠するものである。論理フローは、ＴＥＣルール・エンジンがプロセス中にどこで検査および検証を実行するかを簡潔に宣言した１組のガイドラインである。

このため、本発明は、非常に有用かつ管理しやすいものであり、有効なサポートと、どのようなシステム障害についてもより迅速な応答時間を可能にする。

以下、添付図面を参照しながら、本発明の最良の実施形態について説明する。

本発明のＴＥＣイベント同期（「ＴＥｖＳ」）は、Ｔｉｖｏｌｉ（登録商標）Ｍａｎａｇｅｍｅｎｔ Ｆｒａｍｅｗｏｒｋ（「ＴＭＦ」）とともにＴｉｖｏｌｉ（登録商標）Ｅｖｅｎｔ Ｃｏｎｓｏｌｅ（「ＴＥＣ」）などのイベント管理システム内で複数のイベント・ソースから生成され報告されたイベントを処理するためのユニークな方法を提供する。しかし、当業者であれば、本発明がＴＥＣ／ＴＭＦによる実現に制限されず、代わって多数の他の同様のシステム、プログラム、およびツールに併せて実現可能であることを認識するであろう。本明細書の開示内容は、ＴＥＣによる実現に関する本発明の例示的な諸実施形態を示すので、本発明の範囲を逸脱せずに本発明を他のプログラムおよびプラットフォームに適合させることは当業者であれば容易であろう。

ＴＥｖＳは、一実施形態ではＴＥＣから独立したＪＡＶＡ（登録商標）アプリケーション・プログラムとして実現されているが、代わって任意の適切なプログラミング言語および方法論を使用して実現することもできる。この開示内容全体を通して以下の定義を使用する。
（ａ）「リアルタイム」は、重大な遅延なしにデータを受信したのと本質的に同じ速度でその結果を生成するコンピュータ・システム、プロセス、およびロジックを意味するかまたはそれらに関連するものとする。
（ｂ）「耐障害システム」は、（潜在的に自ら招いた）損害に耐え、予期しないかまたは不正な入力を処理し、間違ったアクションを実行するが、それにもかかわらず生産的に実行し続けることができるシステムを意味するものとする。
（ｃ）「ロールオーバ」は、あるモジュールが誤動作するかまたは異常終了したときに、終了したモジュールによって受信されたデータが継続処理および取扱いのために次に使用可能なモジュールに送信されることを意味するものとする。
（ｄ）「ロードバランシング」は、あるサーバがその最適処理状態にあるときに、任意の新しいシステム・ジョブが、トラフィックを管理し、最大サービス品質で動作するために次に使用可能なサーバにリダイレクトされることを意味するものとする。
（ｅ）「ボトルネック」は、システム上の制限因子を有する１つまたは複数のコンポーネントを指すものとする。
（ｆ）「スロット」は、定義された文字制限を備えたパラメータを指すものとする。

ＴＥｖＳ用のコンピューティング・プラットフォーム
本発明は、回路として、ソフトウェア実現プロセスとして、または両方の組合せとして実現することができる。一実施形態では、本発明は、パーソナル・コンピュータ、ウェブ・サーバ、およびウェブ・ブラウザなどの周知のコンピューティング・プラットフォーム上に存在することがすでに判明しているソフトウェアに対する機能または追加として実現される。このような一般的なコンピューティング・プラットフォームとしては、パーソナル・コンピュータ、ならびに、携帯情報端末（「ＰＤＡ」）、ウェブ対応携帯電話、およびその他のタイプの個人情報管理（「ＰＩＭ」）装置などのポータブル・コンピューティング・プラットフォームを含むことができる。

したがって、ハイエンド・ウェブまたはエンタープライズ・サーバ・プラットフォームから、パーソナル・コンピュータ、ポータブルＰＤＡまたはウェブ対応携帯電話にまで及び得るコンピューティング・プラットフォームの汎用アーキテクチャを検討することは有用である。

図１を参照すると、概してランダム・アクセス・メモリ（「ＲＡＭ」）（４）および読取り専用メモリ（「ＲＯＭ」）（５）に関連付けられているマイクロプロセッサ（２）を含む中央演算処理装置（１）（「ＣＰＵ」）を含む汎用アーキテクチャが提示されている。多くの場合、ＣＰＵ（１）には、キャッシュ・メモリ（３）およびプログラマブル・フラッシュＲＯＭ（６）も設けられている。マイクロプロセッサ（２）と様々なタイプのＣＰＵメモリとのインターフェース（７）は、多くの場合、「ローカル・バス」と呼ばれるが、より汎用的なバスまたは業界標準のバスにすることもできる。

多くのコンピューティング・プラットフォームには、ハードディスク・ドライブ（「ＨＤＤ」）、フレキシブル・ディスク・ドライブ、コンパクト・ディスク・ドライブ（ＣＤ、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ、ＤＶＤ−Ｒなど）、およびメーカ独自のディスクおよびテープ・ドライブ（たとえば、Ｉｏｍｅｇａ Ｚｉｐ（登録商標）およびＪａｚ（登録商標）、Ａｄｄｏｎｉｃｓ ＳｕｐｅｒＤｉｓｋ（登録商標）など）などの１つまたは複数のストレージ・ドライブ（９）も設けられている。さらに、いくつかのストレージ・ドライブがコンピュータ・ネットワークによりアクセス可能である可能性がある。

多くのコンピューティング・プラットフォームには、そのコンピューティング・プラットフォームについて意図された機能に応じて、１つまたは複数の通信インターフェース（１０）が設けられている。たとえば、パーソナル・コンピュータには、多くの場合、高速シリアル・ポート（ＲＳ−２３２、ＲＳ−４２２など）、拡張パラレル・ポート（「ＥＰＰ」）、および１つまたは複数のユニバーサル・シリアル・バス（「ＵＳＢ」）ポートが設けられている。また、このコンピューティング・プラットフォームには、イーサネット（登録商標）・カードなどのローカル・エリア・ネットワーク（「ＬＡＮ」）インターフェースや、ハイパフォーマンス・シリアル・バスＩＥＥＥ−１３９４などのその他の高速インターフェースを設けることもできる。

また、携帯電話および無線ネットワーク化ＰＤＡなどのコンピューティング・プラットフォームには、アンテナを備えた無線周波（「ＲＦ」）インターフェースも設けることができる。場合によっては、このコンピューティング・プラットフォームには、赤外線データ通信のためのＩｒＤＡインターフェースも設けることができる。

コンピューティング・プラットフォームは、多くの場合、サウンド・カード、メモリ・ボード、グラフィックス・アクセラレータなどのその他のハードウェアの追加のために、ＩＳＡ、ＥＩＳＡ、ＰＣＩ、またはメーカ独自のインターフェース・スロットなどの１つまたは複数の内部拡張スロット（１１）を備えている。

さらに、ラップトップ・コンピュータおよびＰＤＡなどの多くのユニットには、ＰＣＭＣＩＡカード、スマートメディア・カード、およびリムーバブル・ハードディスク・ドライブ、ＣＤドライブ、およびフレキシブル・ディスク・ドライブなどの様々なメーカ独自のモジュールなどのハードウェア拡張デバイスを容易にインストールし取り外す能力をユーザに与える１つまたは複数の外部拡張スロット（１２）が設けられている。

多くの場合、ストレージ・ドライブ（９）、通信インターフェース（１０）、内部拡張スロット（１１）、および外部拡張スロット（１２）は、ＩＳＡ、ＥＩＳＡ、またはＰＣＩなどの標準のまたは業界公開のバス・アーキテクチャ（８）を介してＣＰＵ（１）と相互接続されている。多くの場合、バス（８）はメーカ独自の設計のものにすることができる。

コンピューティング・プラットフォームには、通常、キーボード／キーパッド（１６）、マウス／ポインタ・デバイス（１７）、タッチスクリーン・ディスプレイ（１８）といった１つまたは複数のユーザ入力装置が設けられている。パーソナル・コンピュータの場合には、多くの場合、トラック・ボールまたはトラックポイント（登録商標）などのマウス／ポインタ・デバイスとともに、フルサイズのキーボードが設けられている。ウェブ対応携帯電話の場合には、単純なキーパッドに１つまたは複数の機能固有キーを設けることができる。ＰＤＡの場合には、通常、タッチスクリーン（１８）が設けられ、多くの場合、手書き文字認識機能を備えている。

さらに、このコンピューティング・プラットフォームには、ウェブ対応携帯電話のマイクロホンまたはパーソナル・コンピュータのマイクロホンなどのマイクロホン（１９）が供給される。このマイクロホンは、単純にオーディオおよび音声信号を報告するために使用することができ、また、音声認識機能を使用して、ウェブ・サイトの音声ナビゲーションまたは電話番号の自動ダイヤルなど、ユーザ選択を入力するために使用することもできる。

また、多くのコンピューティング・プラットフォームは、スチル・ディジタル・カメラまたはフルモーション・ビデオ・ディジタル・カメラなどのカメラ装置（１００）も備えている。

ほとんどのコンピューティング・プラットフォームには、ディスプレイ（１３）などの１つまたは複数のユーザ出力装置が設けられている。ディスプレイ（１３）は、陰極線管（「ＣＲＴ」）、薄膜トランジスタ（「ＴＦＴ」）アレイ、または単純な１組の発光ダイオード（「ＬＥＤ」）もしくは液晶表示（「ＬＣＤ」）インジケータを含む、多くの形を取ることができる。

多くの場合、１つまたは複数のスピーカ（１４）または報知器（１５）あるいはその両方もコンピューティング・プラットフォームに関連付けられている。スピーカ（１４）は、携帯電話のスピーカまたはパーソナル・コンピュータのスピーカなど、音声および音楽を再生するために使用することができる。報知器（１５）は、一般にＰＤＡおよびＰＩＭなどの特定の装置上に見られる単純なビープ音エミッタまたはブザーの形を取ることができる。

このようなユーザ入出力装置は、メーカ独自のバス構造またはインターフェースあるいはその両方を介してＣＰＵ（１）に直接相互接続（８’、８”）するか、あるいはＩＳＡ、ＥＩＳＡ、ＰＣＩなどの１つまたは複数の業界公開バスにより相互接続することができる。また、このコンピューティング・プラットフォームには、そのコンピューティング・プラットフォームの所望の機能を実現するための１つまたは複数のソフトウェアおよびファームウェア（１０１）プログラムも設けられている。

次に図２を参照すると、この範囲のコンピューティング・プラットフォーム上にあるソフトウェアおよびファームウェア（１０１）の汎用編成の詳細が示されている。このコンピューティング・プラットフォーム上には、ワード・プロセッサ、スプレッドシート、連絡先管理ユーティリティ、アドレス帳、カレンダ、Ｅメール・クライアント、プレゼンテーション、財務および記帳プログラムなどの１つまたは複数のオペレーティング・システム（「ＯＳ」）ネイティブ・アプリケーション・プログラム（２３）を設けることができる。

さらに、１つまたは複数の「移植可能」または装置独立プログラム（２４）を設けることができ、これは、ＪＡＶＡ（登録商標）スクリプトおよびプログラムなどのＯＳネイティブ・プラットフォーム固有インタープリタ（２５）によって解釈しなければならない。

多くの場合、コンピューティング・プラットフォームには、ある形式のウェブ・ブラウザまたはマイクロブラウザ（２６）も設けられており、これは、ブラウザ・プラグイン（２７）などの、ブラウザに対する１つまたは複数の拡張機能も含むことができる。

コンピューティング・デバイスは、多くの場合、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）、ＵＮＩＸ（登録商標）、ＩＢＭ ＯＳ／２（登録商標）、ＬＩＮＵＸ、ＭＡＣ ＯＳ（登録商標）、またはその他のプラットフォーム固有オペレーティング・システムなどのオペレーティング・システム（２０）が設けられている。ＰＤＡおよび携帯電話などのより小さいデバイスは、リアルタイム・オペレーティング・システム（「ＲＴＯＳ」）またはＰａｌｍ ＣｏｍｐｕｔｉｎｇのＰａｌｍＯＳ（登録商標）などのその他の形式のオペレーティング・システムを備えることもできる。

多くの場合、オペレーティング・システム（２０）およびプログラムがコンピューティング・プラットフォームに設けられた特定のハードウェア機能とのインターフェースを取り、それを制御できるようにするために、１組の基本入出力機能（「ＢＩＯＳ」）およびハードウェア・デバイス・ドライバ（２１）が設けられている。

さらに、多くのコンピューティング・プラットフォームには、一般に１つまたは複数の埋込みファームウェア・プログラム（２２）が設けられ、これらは、マイクロ・コントローラまたはハードディスク・ドライブ、通信プロセッサ、ネットワーク・インターフェース・カード、あるいはサウンドまたはグラフィックス・カードなどの周辺装置の一部としてオンボードまたは「埋込み」マイクロプロセッサによって実行される。

このため、図１および図２は、一般的な意味で、パーソナル・コンピュータ、ＰＤＡ、ＰＩＭ、ウェブ対応電話、およびＷｅｂＴＶ（登録商標）ユニットなどのその他の電気製品を含むがこれらに限定されない広範囲のコンピューティング・プラットフォームの様々なハードウェア・コンポーネント、ソフトウェア、およびファームウェア・プログラムを記述している。このため、次に、好ましくはこのようなコンピューティング・プラットフォーム上のソフトウェアおよびファームウェアとして実現されるプロセスおよび方法に関する本発明の開示内容に注意を向ける。当業者であれば、代わって以下の方法およびプロセスが、本発明の精神および範囲を逸脱せずに、一部または全部をハードウェア機能（たとえば、回路）として実現可能であることを容易に認識するであろう。

ＴＥｖＳのロジック
次に図５を参照すると、本発明の機能図（５０）が示されている。イベント・バス（６１）は、１つまたは複数のＴＥｖＳモジュールを含み、複数のイベント・ソース（３２ａ〜３２ｘ）からのイベント・レポート（６３ａ〜６３ｘ）をインターセプトする。ＴＥｖＳモジュールでは、イベント・レポート（６３ａ〜６３ｘ）は、各イベントの１次または２次所有権に基づいて、リアルタイムでソートされ、処理され、フラグを立てられ、適切なＴＥＣサーバ（３３ａ〜３３ｎ）に転送される。

図６は、イベント・レポートがＴＥｖＳによって処理される方法の詳細（６０）を示している。この例では、ＴＥＣサーバ１（３３ａ）との関連（６５）におけるＴＥｖＳ処理の詳細が示されている。あるイベントが発生すると、ダイヤルアップ・モデム接続などの通信ネットワーク（３１）を介してイベント・ソースからＴＥＣサーバ１によってイベント・レポート（６２ａ）が受信される。通信アダプタとしては、有線ダイヤルアップ接続用のモデム、ローカル・エリア・ネットワーク（ＬＡＮ）技術用のイーサネット（登録商標）（ＩＥＥＥ８０２．３）アダプタ、およびＩＥＥＥ８０２．１１などの無線イーサネット（登録商標）仕様を含むことができる。しかし、報告された各イベントがＴＥＣサーバに直接移行できるようにするのではなく、ＴＥｖＳモジュール（６７ａ）は通信ネットワーク（３１）からのすべてのイベント・レポートをインターセプトする。次にイベント・レポート（６２ａ）はＴＥｖＳモジュール（６７ａ）によって所有権プロパティのフラグを立てられ、変更済みイベント・データは管理者が適切に続行するために適切なＴＥＣサーバ（ＴＥＣサーバ１を含む）に送信される。

伝搬された各イベント・レポートに１次所有権または２次所有権の指定を追加し、（データベース同期化が行われるのを待つのではなく）変更済み各イベント・レポートをイベント・バス上でリアルタイムに伝搬することにより、各ＴＥＣサーバは、直ちに新しいイベントが通知され、直ちに反応することが必要であるかどうかを知らされる。

たとえば、受信したイベント・レポートＢが１次所有者としてＴＥＣサーバ１（３３ａ）のフラグを立てられている場合、その後直ちに、変更済みイベント・レポートＢ’がＴＥＣサーバ１（３３ａ）に渡され（６８ａ）、ほぼ同時に、変更済みイベント・レポートＢ’のコピーが好ましくは１つまたは複数のセキュアまたは高可用性ネットワーク（６４）を介して１つまたは複数のバックアップ・サーバに伝搬される（６６）。「同期化されたイベント・レポート」と呼ばれる変更済みイベント・レポートの伝搬のために使用するセキュア・ネットワーク（６４）は、仮想プライベート・ネットワーク（「ＶＰＮ」）、マイクロ波中継装置、セキュリティおよび信頼性を提供するインターネット・バックボーンを含むがこれらに限定されないものにすることができる。代替一実施形態では、通信ネットワーク（３１）は階層的に編成されたネットワークの下位レベルであり、セキュア・ネットワーク（６４）は階層的に編成されたネットワークの上位または最上位レベルであり、ＴＥＣサーバは、高可用性法人ネットワーク上で実行されるサーバなどの最上位レベル・サーバである。

好ましい一実施形態によれば、ＴＥｖＳモジュール（６７ａ）は、それが１次所有権（たとえば、「ローカル」処理）のフラグを立てるＴＥＣサーバ（３３ａ）と同じコンピューティング・プラットフォームによってまたは同じコンピューティング・プラットフォーム上で実行される。代わって、ＴＥｖＳモジュールがリモート・コンピューティング・プラットフォーム上で実行される場合もあれば、そのロジックがプログラマブルまたはハード・ロジックまたは回路あるいはそれらの組合せで実現される場合もある。

ＴＥｖＳモジュール（６７ａ、６７ｂ、・・・６７ｎ）は、図７に示す通り、生成されたイベント・レポートを処理するために、互いに独立して動作する。これらのモジュールは、前述のセキュア・ネットワークを介して自動的に互いに通信する（６６）能力を有する。１つのＴＥＣサーバは、処理すべきイベント・レポートを受信する複数のＴＥｖＳモジュールを有することができる。したがって、あるモジュールが故障するかまたは過負荷状態になり、ボトルネックになった場合、それは他のモジュールの機能に悪影響を及ぼさず、イベント・レポートは送信され続けることになる。この１組（６１）のＴＥｖＳモジュール（６７ａ、６７ｂ、・・・６７ｎ）は、前述のイベント・バスを定義し実現するものであり、複数のＴＥＣサーバ間に広く分散するか、またはより少数の実際の論理実現例に部分的にまたは全体的に統合することができる。

図８は、本発明によりイベント・レポートが処理される方法の代替図（８０）を示している。イベント・ソース（３２’、３２”）から生成されたイベント・レポートは、イベント・ソース（３２’、３２”）の組からそのイベント・バスのＴＥｖＳモジュール（６７ａ〜６７ｂ）へのイベント・フロー（６２’、６２”）を構成する。ＴＥｖＳモジュール（６７ａ〜６７ｂ）がイベント・フロー（６２’、６２”）を処理して各イベントに１次所有者のフラグを適切に立てた後、同期化されたイベント（６６）はイベント・バス上で（たとえば、ＴＥｖＳモジュール間で）交換され、１次所有者ＴＥＣサーバにも渡される（６８ａ、６８ｂなど）。変更済みイベント・レポートがＴＥＣサーバに到達すると、そのデータは個別のローカル・データベース（４３ａ、４３ｂ）に保管される。しかし、本発明の使用により、イベント・レポートが適切な管理者によって処理されるかどうかを検証するためにデータベースを定期的に同期化する必要はない。というのは、データベースはリアルタイム・イベント・バス・アクションによって必ず最新状態に保持されており、それにより、前のＴＥＣイベント処理プロセスの応答時間の遅延を回避し、ＴＥＣ管理スタッフによる重複努力の冗長性を解消するからである。

図９を参照すると、ＴＥｖＳモジュールの論理プロセスが示されている。イベント・レポートがイベント・バスによってインターセプトされる（９１）と、ＴＥｖＳロジックは、イベント・レポート内に既存の所有権割当てがあるかどうか（たとえば、イベント・レポートが他のＴＥｖＳモジュールによって本発明により前に変更されているか）をチェックする（９２）。所有者指定がすでにイベント・レポート内に存在する場合（９２）、イベント・レポート・データはローカル・イベント・データベースに（またはモジュールがイベント・レポートを処理しているＴＥＣサーバに関連するイベント・データベースに）保管される（９６）。

いかなる所有者指定もイベント・レポート内に存在しない（たとえば、これが未変更のイベント・レポートである）場合（９２）、１次所有者を決定するためにＴＥｖＳモジュールによってルール・ベースが調べられ、イベント・レポートに所有者フィールドが追加される（９３）。好ましい実施形態によれば、レポート内に「スロット」を追加し、そのスロットの値をどのＴＥＣサーバが１次所有者であるかを示す値に設定することにより、ＴＥＣイベント・レポートを追加することができる。他の管理システムに関連する代替諸実施形態では、拡張マークアップ言語（「ＸＭＬ」）フィールドなどの特定の言語構造体、バイナリ・データ値、または関連の管理システムに適したその他の任意のデータ構造体を使用することにより、イベント・レポートを追加することができる。イベント・レポートはローカル・イベント・データベースに保管される（９４）。最後に、変更済みイベント・レポートがイベント・バス上を伝搬される（９５）。

図１０は本発明のシステム実現例を示しており、これは、プログラマブル・ロジックを使用するかまたはカスタム集積回路によるなど、回路および電子機器によって全部または一部を実施することができる。バイナリ、テキスト、または文字パラメータを表す一連のディジタル値などのイベント・レポート（６３）は、イベント・バス・イネーブル信号（１０１）によって制御される入力セレクタ・スイッチ（１０２）でシステム（１００）によって受信される。この信号が偽である（たとえば、イベント・バスが使用不可である）場合、入力セレクタ・スイッチ（１０２）は、データが未変更状態で伝搬されるように、ローカルＴＥＣサーバへの経路（１０３）に沿ってイベント・レポート（６３）データを送信する。

しかし、イベント・バス・イネーブル信号（１０１）が真である場合、入力セレクタ・スイッチ（１０２）は、比較器（１０５）への経路（１０４）に沿ってイベント・レポート（６３）データを送信し、その比較器は１次所有者指定パラメータがイベント・レポート・データ（６３）内に含まれているかどうかを判定する。比較器が１次所有者指定パラメータの存在を検出した場合、未変更のイベント・レポート・データをローカルＴＥＣサーバに出力するためにそのデータが経路（１１０）に沿って送信されるように、出力セレクタ・スイッチ（１０６）の制御信号が活動化される。

比較器がイベント・レポート・データ内の１次所有者指定パラメータの存在を検出しない場合、イベント・レポート・データがデータ・セレクタ（１０７）に提示されるように、出力セレクタ・スイッチ（１０６）の制御信号が活動化される。データ・セレクタ（１０７）は論理的所有者選択ルールを実現し、合計回路（１０８）に所有者指示値（１１１）を提供する。また、合計回路（１０８）は、出力セレクタ・スイッチ（１０６）からのイベント・レポート・データも受信し、所有者指示値（１１１）とそのイベント・レポート・データを組み合わせて、所有者指定パラメータを含む変更済みイベント・レポート・データを生成する。次に、合計回路（１０８）からのこの変更済みイベント・レポート・データは、好ましくはバッファリングまたは片方向データ伝送装置により、ローカルＴＥＣサーバと、１つまたは複数の代替ＴＥＣサーバに送信される。

結論
一般的にしかも例示的な実施形態例の使用により本発明を説明してきた。代替管理システムとともに使用するために本発明の代替一実施形態を実現するために、プログラミング言語、コンピューティング・プラットフォーム、または実施方法などの特定の変更および修正を行うことは、当業者の技能の範囲内である。したがって、本発明の範囲は特許請求の範囲によって決定されるべきものである。

パーソナル・コンピュータ、サーバ・コンピュータ、携帯情報端末、ウェブ対応携帯電話、またはその他のプロセッサベースの装置などの汎用コンピューティング・プラットフォーム・アーキテクチャを示す図である。 図１の汎用アーキテクチャに関連するソフトウェアおよびファームウェアの汎用編成を示す図である。 ＴＥＣ環境内のイベント・レポートに関する現行プロセス方法を示す図である。 現行インフラストラクチャ環境においてデータがどのように保管されるかを示す図である。 本発明の機能配置を示す図である。 イベント・レポートが処理される方法の詳細図である。 ＴＥｖＳモジュール間の自律性を示す図である。 本発明によるシステム操作を示すより広範囲の図である。 新しいＴＥｖＳモジュールの論理プロセスを示す図である。 本発明の回路実施形態図である。

Claims (9)

1. イベントに関するバイナリ、テキスト、または文字パラメータを表す一連のディジタル値を有するイベント・レポートを生成するための複数のイベント・ソースと、前記複数のイベント・ソースからのイベント・レポートを処理するための複数の問題管理サーバと、前記複数のイベント・ソースから第１の通信ネットワークを介して送信される各イベント・レポートを受信し且つ当該受信した各イベント・レポートを前記複数の問題管理サーバのうち適切な問題管理サーバに転送するためのイベント・バスとを備え、前記イベント・バスが、前記複数の問題管理サーバを互いにリンクするように当該複数の問題管理サーバの各々に対応して１つずつ設けられた複数のイベント同期モジュールから構成されるイベント・バス・システムであって、
   前記イベント同期モジュールの各々が、
   前記複数のイベント・ソースのうち一のイベント・ソースから前記第１の通信ネットワークを介して送信され且つ前記複数の問題管理サーバのうち一の問題管理サーバに経路指定される一のイベント・レポートを受信するための入力手段と、
   前記入力手段から前記一のイベント・レポートを受信し、イベント・バス・イネーブル信号が偽であるときに前記一のイベント・レポートが未変更状態で前記複数の問題管理サーバのうち当該イベント同期モジュールに対応する１つの問題管理サーバに送信され、さもなければ前記一のイベント・レポートが比較器と出力セレクタ・スイッチとに送信されるように前記イベント・バス・イネーブル信号によって制御される入力セレクタ・スイッチと、
   前記入力セレクタ・スイッチから前記一のイベント・レポートを受信し、当該イベント・レポート内に前記複数の問題管理サーバのうち当該イベント・レポートを処理すべき一の問題管理サーバを指定するための一の所有者値が含まれているか否かを検出し、前記一のイベント・レポート内に前記一の所有者値が含まれていることを検出したときに真の制御信号を生成する比較器と、
   前記入力セレクタ・スイッチから前記一のイベント・レポートを受信し、前記制御信号が真であるときに前記一のイベント・レポートが未変更状態で当該イベント同期モジュールに対応する前記１つの問題管理サーバに送信され、さもなければ前記一のイベント・レポートがデータ・セレクタ回路の制御入力と合計回路の第１の入力とに送信されるように前記比較器からの前記制御信号によって制御される出力セレクタ・スイッチと、
   前記出力セレクタ・スイッチから前記一のイベント・レポートを受信し、合計回路の第２の入力に提示するために複数の所有者値のうち当該イベント・レポートを処理すべき一の問題管理サーバを指定するための一の所有者値を生成するデータ・セレクタ回路と、
   前記出力セレクタ・スイッチから前記一のイベント・レポートを受信するための前記第１の入力と、前記データ・セレクタ回路から前記生成された一の所有者値を受信するための前記第２の入力とを有し、前記生成された一の所有者値を含むように前記一のイベント・レポートを変更し、当該変更済みイベント・レポートを当該イベント同期モジュールに対応する前記１つの問題管理サーバと他の問題管理サーバとに送信する合計回路とを有する、イベント・バス・システム。
2. 前記データ・セレクタ回路が、自動問題診断解決ツールによって定義されたルール・ベースに応じて前記一の所有者値を生成するように構成される、請求項１に記載のイベント・バス・システム。
3. 前記合計回路が、前記変更済みイベント・レポートを第２の通信ネットワークを介して前記他の問題管理サーバに送信するように構成される、請求項１に記載のイベント・バス・システム。
4. 前記第２の通信ネットワークが、セキュア通信ネットワークである、請求項３に記載のイベント・バス・システム。
5. イベントに関するバイナリ、テキスト、または文字パラメータを表す一連のディジタル値を有するイベント・レポートを生成するための複数のイベント・ソースと、前記複数のイベント・ソースからのイベント・レポートを処理するための複数の問題管理サーバと、前記複数のイベント・ソースから第１の通信ネットワークを介して送信される各イベント・レポートを受信し且つ当該受信した各イベント・レポートを前記複数の問題管理サーバのうち適切な問題管理サーバに転送するためのイベント・バスとを備え、前記イベント・バスが、前記複数の問題管理サーバを互いにリンクするように当該複数の問題管理サーバの各々に対応して１つずつ設けられた複数のイベント同期モジュールから構成されるイベント・バス・システムにおいて、
   前記イベント同期モジュールの各々が、
   （ａ）前記複数のイベント・ソースのうち一のイベント・ソースから前記第１の通信ネットワークを介して送信され且つ前記複数の問題管理サーバのうち一の問題管理サーバに経路指定される一のイベント・レポートを受信するステップと、
   （ｂ）前記一のイベント・レポートが前記複数の問題管理サーバのうち当該イベント・レポートを処理すべき一の問題管理サーバを指定するための一の所有者値を含むかどうかを判定するステップと、
   （ｃ）前記一のイベント・レポートが前記一の所有者値を含むと判定したことに応答して、前記一のイベント・レポートを変更なしに前記複数の問題管理サーバのうち当該イベント同期モジュールに対応する１つの問題管理サーバに送信するステップと、
   （ｄ）前記一のイベント・レポートが前記一の所有者値を含まないと判定したことに応答して、ルール・ベースに応じて複数の所有者値のうち当該イベント・レポートを処理すべき一の問題管理サーバを指定するための一の所有者値を生成し、当該生成された所有者値を含むように前記一のイベント・レポートを変更するステップと、
   （ｅ）前記変更済みイベント・レポートを当該イベント同期モジュールに対応する前記１つの問題管理サーバと他の問題管理サーバとに送信するステップと、
   を実行する、イベント・レポートを処理するための方法。
6. 前記ステップ（ｄ）が、自動問題診断ツールによって定義されたルール・ベースに応じて前記一の所有者値を生成するステップを有する、請求項５に記載の方法。
7. 前記ステップ（ｅ）が、前記変更済みイベント・レポートを第２の通信ネットワークを介して前記他の問題管理サーバに送信するステップを有する、請求項５に記載の方法。
8. 前記第２の通信ネットワークがセキュア通信ネットワークである、請求項７に記載の方法。
9. コンピュータ上で実行されるときに請求項５ないし８のいずれかに記載の方法を実行させるためのコンピュータ・プログラム。

Images