(57)【要約】【課題】ネットワークを管理する方法、ネットワーク管理システム及びコンピュータ・プログラムを提供する。【解決手段】本システムは、監視対象システムからのシステム・イベントをインターセプトし且つイベント項目を作成するか又は前記システム・イベントに関連するイベント項目を修正するためのプローブと、イベント項目のデータベース内に、新しいイベント項目又は既存のイベントに対する修正のバッチを収集するための収集データベース・サーバと、クライアントと、新しいイベント項目又はイベント項目修正のバッチを前記クライアントに定期的に通知するための複製手段と、新しいイベント項目又は修正済みのイベント項目が優先条件を満たす場合には、前記定期的なバッチ通知とは独立に、当該新しいイベント項目又は修正済みのイベント項目を前記クライアントに直接的に通知するための加速機構とを備える。【選択図】  図３
2010539572.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを管理する方法であって、
モニタされるシステムからのシステム・イベントをインターセプトし且つイベント項目を作成するか又は前記システム・イベントに関連するイベント項目を修正するステップと、
イベント項目のデータベース内に、新しいイベント項目又は既存のイベントに対する修正のバッチを収集するステップと、
新しいイベント項目又はイベント項目修正の前記バッチをクライアントに定期的に通知するステップと、
新しいイベント項目又は修正済みのイベント項目が優先条件を満たす場合は、前記定期的なバッチ通知とは独立に、当該新しいイベント項目又は修正済みのイベント項目を前記クライアントに直接的に通知するステップとを含む、方法。
【請求項２】
前記収集するステップが、第１のデータベース・サーバ内で実行され、前記クライアントが、前記新しいイベント項目又はイベント項目修正を複製する第２のデータベース・サーバを含む、請求項１に記載の方法。
【請求項３】
前記クライアントが、前記通知を受け取り、前記第１のデータベース・サーバからイベント項目データをプルし、当該イベント項目データを前記第２のデータベース・サーバにプッシュするゲートウェイをさらに含む、請求項２に記載の方法。
【請求項４】
前記収集するステップが、２つ以上のデータベース・サーバの収集層内で実行され、当該２つ以上の収集データベース・サーバの各々がイベントをインターセプトするための１つ以上の関連するプローブを有し、前記クライアントが、当該２つ以上の収集データベース・サーバからの全ての前記新しいイベント項目又はイベント修正項目を中央の場所に複製する集約データベース・サーバを含む集約層であり、前記新しいイベント項目又は修正済みのイベント項目が優先条件を満たす場合は、前記定期的なバッチ通知とは独立に、前記集約された新しい優先イベント項目又は修正済みの優先イベント項目を第２のクライアントに直接的に通知するステップをさらに含む、請求項１に記載の方法。
【請求項５】
前記第２のクライアントが、２つ以上のデータベース・サーバの表示層であり、当該２つ以上の表示層データベース・サーバの各々が前記集約データベース・サーバからの前記集約された新しいイベント項目又はイベント修正項目のサブセットを複製し、新しいイベント項目又は修正済みのイベント項目が優先条件を満たす場合は、各表示層オブジェクト・サーバが、前記定期的なバッチ通知とは独立に、当該新しいイベント項目又は修正済みのイベント項目を少なくとも１つの表示クライアントに直接的に通知することができる、請求項４に記載の方法。
【請求項６】
ネットワーク管理システムであって、
モニタされるシステムからのシステム・イベントをインターセプトし且つイベント項目を作成するか又は前記システム・イベントに関連するイベント項目を修正するためのプローブと、
イベント項目のデータベース内に、新しいイベント項目又は既存のイベントに対する修正のバッチを収集するための収集データベース・サーバと、
クライアントと、
新しいイベント項目又はイベント項目修正の前記バッチを前記クライアントに定期的に通知するための複製手段と、
新しいイベント項目又は修正済みのイベント項目が優先条件を満たす場合は、前記定期的なバッチ通知とは独立に、当該新しいイベント項目又は当該修正済みのイベント項目を前記クライアントに直接的に通知するための加速機構とを備える、ネットワーク管理システム。
【請求項７】
前記クライアントが、前記新しいイベント項目又はイベント項目修正を複製する集約データベース・サーバを含む、請求項６に記載のネットワーク管理システム。
【請求項８】
前記クライアントが、前記通知を受け取り、前記収集データベース・サーバからイベント項目データをプルし、当該イベント項目データを前記集約データベース・サーバにプッシュするゲートウェイをさらに含む、請求項７に記載のネットワーク管理システム。
【請求項９】
２つ以上の収集データベース・サーバの収集層をさらに備え、当該２つ以上の収集データベース・サーバの各々が１つ以上の関連するプローブを有し、前記クライアントが、当該２つ以上の収集データベース・サーバからの全ての前記新しいイベント項目又はイベント修正項目を中央の場所に複製する集約データベース・サーバを含む集約層であり、前記新しいイベント項目又は修正済みのイベント項目が優先条件を満たす場合は、前記定期的なバッチ通知とは独立に、前記集約された新しい優先イベント項目又は修正済みの優先イベント項目を第２のクライアントに直接的に通知することをさらに含む、請求項６に記載のネットワーク管理システム。
【請求項１０】
前記第２のクライアントが、２つ以上のデータベース・サーバの表示層であり、当該２つ以上の表示層データベース・サーバの各々が前記集約データベース・サーバからの前記集約された新しいイベント項目又はイベント修正項目のサブセットを複製し、新しいイベント項目又は修正済みのイベント項目が優先条件を満たす場合は、各表示層オブジェクト・サーバが、前記定期的なバッチ通知とは独立に、当該新しいイベント項目又は修正済みのイベント項目を少なくとも１つの表示クライアントに直接的に通知することができる、請求項９に記載のネットワーク管理システム。
【請求項１１】
ネットワーク管理システム用のコンピュータ可読コードを格納するコンピュータ可読記録媒体を含むコンピュータ・プログラムであって、前記コンピュータ可読コードがコンピュータ・システムにロードされ且つ実行されるとき、当該コンピュータ・システムに、
モニタされるシステムからのシステム・イベントをインターセプトし且つイベント項目を作成するか又は前記システム・イベントに関連するイベント項目を修正するステップと、
イベント項目のデータベース内に、新しいイベント項目又は既存のイベントに対する修正のバッチを収集するステップと、
新しいイベント項目又はイベント項目修正の前記バッチをクライアントに定期的に通知するステップと、
新しいイベント項目又は修正済みのイベント項目が優先条件を満たす場合は、前記定期的なバッチ通知とは独立に、当該新しいイベント項目又は修正済みのイベント項目を前記クライアントに直接的に通知するステップとを実行させるためのコンピュータ・プログラム。
【請求項１２】
前記収集するステップが、第１のデータベース・サーバ内で実行され、前記クライアントが、前記新しいイベント項目又はイベント項目修正を複製する第２のデータベース・サーバを含む、請求項１１に記載のコンピュータ・プログラム。
【請求項１３】
前記クライアントが、前記通知を受け取り、前記第１のデータベース・サーバからイベント項目データをプルし、当該イベント項目データを前記第２のデータベース・サーバにプッシュするゲートウェイをさらに含む、請求項１２に記載のコンピュータ・プログラム。
【請求項１４】
前記収集するステップが、２つ以上のデータベース・サーバの収集層内で実行され、当該２つ以上の収集データベース・サーバの各々がイベントをインターセプトするための１つ以上の関連するプローブを有し、前記クライアントが、当該２つ以上の収集データベース・サーバからの全ての前記新しいイベント項目又はイベント修正項目を中央の場所に複製する集約データベース・サーバを含む集約層であり、前記新しいイベント項目又は修正済みのイベント項目が優先条件を満たす場合は、前記定期的なバッチ通知とは独立に、前記集約された新しい優先イベント項目又は修正済みの優先イベント項目を第２のクライアントに直接的に通知するステップをさらに含む、請求項１１に記載のコンピュータ・プログラム。
【請求項１５】
前記第２のクライアントが、２つ以上のデータベース・サーバの表示層であり、当該２つ以上の表示層データベース・サーバの各々が前記集約データベース・サーバからの前記集約された新しいイベント項目又はイベント修正項目のサブセットを複製し、新しいイベント項目又は修正済みのイベント項目が優先条件を満たす場合は、各表示層オブジェクト・サーバが、前記定期的なバッチ通知とは独立に、当該新しいイベント項目又は修正済みのイベント項目を少なくとも１つの表示クライアントに直接的に通知することができる、請求項１４に記載のコンピュータ・プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク管理システム（ＮＭＳ）において加速されたイベントを伝搬するための方法及び装置に係る。
【背景技術】
【０００２】
ネットワーク管理システム（ＮＭＳ）は、複数のネットワーク・データ・ソースから企業全体に渡るイベント・データを収集し、この情報の簡略化したビューをエンド・ユーザに提示する。図１を参照して説明すると、ＮＭＳがイベント・データを管理するのは、オペレータへの割り当て、関係データベース管理システム（ＲＤＢＭＳ）に基づくヘルプデスク・システムへの引き渡し、ヘルプデスク・カスタマ・リレーションシップ管理（ＣＲＭ）システムのようなデータベースへのログイン、遠隔サービス・レベルの管理システム上での複製、特定の警報に対する自動応答のトリガのためである。 また、ＮＭＳは、遠隔地における種々のドメイン限定ネットワーク管理プラットフォームからの情報を統合する。ＮＭＳは、既存の管理システム及びアプリケーションと協働することによって、配備（deployment）時間を最小化し、被雇用者が彼らの既存のネットワーク管理スキルを使用することを可能にする。
【０００３】
１つの企業ＮＭＳは、企業イベントの管理を扱うために、定期的に複製を行う複数のオブジェクト・サーバを有するスケーラブル・システムを使用する。一のオブジェクト・サーバは、他のオブジェクト・サーバと独立して又は共同して、イベントを収集し、集約（aggregate）し、表示することができる。かかる独立的な構成可能性は、高いスケーラビリティを許容する。図１に示す既知のＮＭＳは、フェイルオーバ構成を有するため、イベントを管理する１つのオブジェクト・サーバ及び追加のオブジェクト・サーバを備える。図２は、３層のオブジェクト・サーバを有する既知のＮＭＳを示す。多数のイベントがオブジェクト・サーバの処理能力に影響を与える場合には、これらのイベントを調整するために階層化（多層化とも呼ばれる）オブジェクト・サーバ・アーキテクチャを使用することが知られている。２層のＮＭＳは、１つ以上の下位オブジェクト・サーバ（収集層：collection layer）及び上位オブジェクト・サーバ（集約兼表示層：aggregationand display layer）を有する。３層のＮＭＳ（図２を参照）は、１つ以上の下位オブジェクト・サーバ（収集層）、中位オブジェクト・サーバ（集約層）及び１つ以上の上位オブジェクト・サーバ（表示層）を有する。 生イベントは、システムに入り、プローブを介して収集層内で収集される。プローブは、種々のネットワーク装置及び要素から供給されるイベント・データを読み取り、これをオブジェクト・サーバに書き込むことができる、小さなアプリケーション・プロセスである。これらのイベントは、処理及び転送のために、オブジェクト・サーバのステータス・テーブルに挿入される。異なる層におけるオブジェクト・サーバは、ゲートウェイを介して相互に接続される。イベントが下位層から、中位層を通して、上位層まで進行するのは、これらのゲートウェイを介してである。
【０００４】
企業ＮＭＳ内では、イベントは、それらが生じるときゲートウェイへ直ちにプッシュされずに、バッチ・アップされ、そして細分性ウィンドウと呼ばれる更新サイクル時に、クライアントに対し定期的にプッシュされる。ユーザは、細分性ウィンドウ又は更新サイクルの期間を変更することができる。大規模で且つビジー率の高いシステムでは、更新サイクルの期間を３０秒以上に設定することができる。
【０００５】
３層のＮＭＳを通して行われるイベント進行の概略については、図２を参照して後述する。
【０００６】
収集層では、管理対象ネットワーク要素からの生イベントは、プローブによって受信される。プローブによってインターセプトされた各生イベントは、オブジェクト・サーバのステータス・テーブル上の操作に係るオブジェクト・サーバ・イベントに変更される。オブジェクト・サーバ・イベントは、ステータス・テーブルにおけるデータの挿入、削除、更新又は取り消しのうちの１つである。クライアント（ゲートウェイ及びエンドユーザ・アプリケーションの両方）は、特定のタイプのオブジェクト・サーバ・イベントに対するインタレストを、オブジェクト・サーバに登録する。定期的に、及びステータス・テーブル上の操作に係る１つ以上のオブジェクト・サーバ・イベントの後、オブジェクト・サーバによって変更メッセージが生成され、インタレストがある全てのクライアントに送信される。例えば、集約オブジェクト・サーバ用のゲートウェイは、ステータス・テーブル上の操作に係る全てのオブジェクト・サーバ・イベントに対するインタレストを登録している。オブジェクト・サーバからの定期的な変更メッセージを受信する際、このゲートウェイは、最後の期間のためのオブジェクト・サーバ・イベントの変更参照データ・セットを要求するであろう。この変更参照データ・セットは、変更データを参照するが、変更データを構成しない。クライアントは、受信した変更参照データ・セットを使用して、変更データの全部又は一部（例えば、ステータス・テーブルからの完全な行又は選択された列）を取り出す。その後、このゲートウェイは、変更データ・セット内で定義された全ての変更を、クライアント・データベース又はオブジェクト・サーバ・データベース（例えば、集約オブジェクト・サーバ）上に複製することができる。
【０００７】
このゲートウェイからのイベントが集約オブジェクト・サーバに挿入される際、集約オブジェクト・サーバは、インタレストがある全てのパーティのためにさらなる変更イベントを生成する。このイベントは、集約層のオブジェクト・サーバから、関連するゲートウェイを介して、表示層のオブジェクト・サーバに伝搬される。
【０００８】
表示層では、この層におけるイベント変更は、ネットワーク・オペレータのようなエンド・ユーザのデスクトップに伝搬される。表示層のオブジェクト・サーバからデスクトップへの伝搬は、収集及び集約層内のゲートウェイが使用するのと同じ複製戦略を使用して達成される。
【０００９】
階層化アーキテクチャは、負荷平衡化の形式として作用する定期的な複製機構を備えることにより十分なスケーラビリティを提供するが、表示層に接続されたオペレータに対するイベント通知において追加の遅延を導入する。ＥＭＳの大規模な配備では、重要なイベントをネットワーク・オペレータに表示するために要する時間、すなわち重要なイベントのソースからオペレータの入力側に伝搬するのに要する時間は、システム内の他の任意のイベントに対するそれと同じである。システムの観点からすれば、全てのイベントは、同等のステータスを有する。ここで、３層の配備を仮定し、当該構造の各レベルにおいて３０秒の更新サイクル期間を仮定する。この仮定の下では、一旦イベントがシステムに入ると、エンド・ユーザは、ほぼ９０秒以内にこのイベントを観察することができるであろう。幾つかの環境では、イベントのサブセットをより短い時間内にオペレータに提示することが望ましい。
【００１０】
米国特許第６１３．１１１２号明細書は、ネットワーク管理プラットフォーム（ＮＭＰ）とシステム管理システム（ＳＭＰ）との間のゲートウェイと呼ばれるプロセスを開示する。このゲートウェイは、機能横断的な相関の利益のために、当該２つのシステム間でイベント／アラームの交換を可能にする。開示されたシステムは、フィルタリング又はユーザが定義したポリシの形式を介して、イベントをインタレストについて調査した後、これを第２のシステムに渡すことができる。第２のシステムを宛先とする全てのイベントは、同じプロセス及びパスを使用して宛先システムにプッシュされるために、互いに同等のものと見なされる。
【００１１】
米国特許出願公開第２００６／００１５６０８号は、保守に起因して停止中であることが分かっている資源からのイベントを抑止するという概念を開示する。資源のためのシステム保守ウィンドウが定義され、この定義されたウィンドウの間に、この資源に関係する任意の障害イベントが抑止され且つ無視される。
【先行技術文献】
【特許文献】
【００１２】
【特許文献１】米国特許第６１３．１１１２号明細書
【特許文献２】米国特許出願公開第２００６／００１５６０８号
【発明の概要】
【発明が解決しようとする課題】
【００１３】
従って、大量の生イベントを処理する場合、これらの生イベントを編成し且つそれらを効率的に処理及び分配することを保証するためには、定期的な通知及び複製が必要である。生イベントの量及び定期的な通知は、全てのイベントがほぼ同じ態様及び時間で処理されるように、これらのイベントの順序づけられた処理を必要とする。しかし、幾つかのイベントについては、これを平均時間よりも速く処理するという要請が存在する。
【課題を解決するための手段】
【００１４】
本発明の１つ以上の側面に従って、特許請求の範囲の欄に記述されるような、方法、システム及びコンピュータ・プログラムが提供される。
【００１５】
オブジェクト・サーバ内に記録され且つ重要であると識別された任意のイベントは、登録済みのクライアントにプッシュされる優先メッセージに帰着する。この優先メッセージの内容は、サマリ・フィールド・リスト及びイベント・キーを含む。サマリ・フィールド・リストは、コンテキストがクライアントによって決定されるように、当該イベントについて十分な情報を提供する。サマリ・フィールド・リストは、通知ポップアップ・クライアントのような、クライアントに対向するデスクトップを目標にする。イベント・キーは、イベントを次の層に転送するプロセスのために、全てのイベント詳細をプルするためのものである。イベント・キーは、ゲートウェイのような、複製ベースのクライアントを目標にする。優先メッセージがプッシュされる場合、ゲートウェイ又はクライアントは、イベント・キーを使用して、オブジェクト・サーバから必要とされる全てのイベント詳細をプルするであろう。その後、ゲートウェイは、重要なイベント詳細を次のオブジェクト・サーバに転送するであろう。
【００１６】
従って、本発明の解決手段は、システム内の他の全てのイベント用の通常の処理パスに干渉することなく、ユーザによって定義されたような重要なイベントを、クライアントへの優先パスを使用して、高速に追跡するための機構を提供する。
【００１７】
表示層及び集約層のオブジェクト・サーバは、イベントを高速に追跡するために、収集層のオブジェクト・サーバによって使用されるものと同じ論理を使用する。この論理は、オブジェクト・サーバ間の加速アクションのカスケードとして見ることができ、必要に応じて、各オブジェクト・サーバと独立して構成することができる。
【発明の効果】
【００１８】
本発明は、システム内の他の全てのイベント用の通常の処理パスに干渉することなく、ユーザによって定義されたような重要なイベントを、クライアントへの優先パスを使用して、高速に追跡するための機構を提供するという効果を奏する。
【図面の簡単な説明】
【００１９】
【図１】フェイルオーバ構成を有するため、イベントを管理する１つのオブジェクト・サーバ及び追加のオブジェクト・サーバを備える、既知のネットワーク管理システム（ＮＭＳ）のコンポーネントを示す図である。
【図２】３層のオブジェクト・サーバを有する既知のＮＭＳのコンポーネントを示す図である。
【図３】本実施形態のオブジェクト・サーバのコンポーネント及びこれらのコンポーネント間の処理フローを示す図である。
【図４】複数のチャネル・テーブルの内容及びこれらのチャネル・テーブルの関係を示す図である。
【発明を実施するための形態】
【００２０】
イベント管理システム
図１は、フェイルオーバ構成を有するため、イベントを管理する１つのオブジェクト・サーバ及び追加のオブジェクト・サーバを備える、既知のネットワーク管理システム（ＮＭＳ）のコンポーネントを示す図である。このＮＭＳは、第１のゲートウェイによって接続された第１及び第２のオブジェクト・サーバと、第１のオブジェクト・サーバに接続された３つのプローブと、第１のオブジェクト・サーバに接続されたエンド・ユーザ・イベント・リストと、第１のオブジェクト・サーバに接続されたエンド・ユーザ管理者と、第２のゲートウェイを介して第１のオブジェクト・サーバに接続されたエンド・ユーザヘルプデスクＣＲＭと、第３のゲートウェイを介して第１のオブジェクト・サーバに接続された関係データベース管理システム（ＲＤＢＭＳ）とを備える。
【００２１】
プローブは、イベント・データを検出し且つ獲得するために、イベント・ソースに接続する。プローブは、このイベント・データを警報としてオブジェクト・サーバに挿入する。 各プローブは、イベント要素をオブジェクト・サーバのステータス・テーブル内にイベント・レコードとして挿入するための警報レコードに変換する前に、規則ファイル内で指定された論理を使用して、これらのイベント要素を操作する。各プローブは、特定のソースからのイベント・データを獲得するように独自に設計されている。プローブは、装置、データベース及びログ・ファイルを含む、任意の安定したデータ・ソースからのデータを獲得することができる。
【００２２】
ゲートウェイは、２つのオブジェクト・サーバの間で、又は一のオブジェクト・サーバと他のアプリケーション（例えば、データベース、ヘルプデスク又はカスタマ・リレーションシップ管理（ＣＲＭ）システム）との間で、制御メッセージを交換する。また、ゲートウェイは、ステータス・テーブル内にイベント・レコードを複製するか、又はバックアップ・オブジェクト・サーバを保守するためにも使用される。さらに、ゲートウェイは、イベント・レコードをデータベースに保存するためにも使用される。一旦ゲートウェイが正しくインストールされ且つ構成されると、イベント・レコードの転送はオペレータに透明となる。
【００２３】
デスクトップ・ツールは、警報を表示及び管理し且つ警報情報の提示方法を構成するために使用される、グラフィック・ツールの統合スイートである。イベント情報の配信フォーマットは、ユーザがネットワーク上で使用可能なサービスを速やかに決定することを可能にするようなものである。イベント原因が識別された場合、デスクトップ・ツールは、ユーザが問題を速やかに解決することを可能にする。基本的なデスクトップ・ツールは、イベント・リストである。しかし、他のツールは、フィルタ・ビルダ、ビュー・ビルダ及び管理クライアントを含む。 これらのアプリケーションは、オブジェクト・サーバから情報を検索し、データベースの現状態を表示することを可能にする。これは、管理対象システムのステータスを反映する。
【００２４】
イベント・リストは、スクロール・リスト内に、色分けされてもよい警報のフィルタされたビューを表示する。複数のイベント・リスト・クライアントは、各々が異なる優先順位及びフィルタを有するように、設定することができる。イベント・リストは、複数の警報を再優先順位付けし且つ問題を他のユーザに割り当てるか又は再割り当てするために使用することができる。一の警報が一のユーザに割り当てられた場合、このユーザは、割り当てを確認するか、又はその問題が他のユーザによってピックアップされるように、割り当てを否定することができる。
【００２５】
フィルタは、イベント・リスト内に表示すべき特定の警報の選択を可能にする。フィルタ・ビルダは、簡単な又は複雑な警報フィルタの構築を可能にする。要素インスペクタは、正規表現が条件に追加されることを可能にする。
【００２６】
ビュー・ビルダは、オペレータにとってインタレストがある、列のリストを構成する（ビュー）。
【００２７】
管理クライアントは、管理者がオブジェクト・サーバを構成し且つ管理することを可能にする。図２は、複数のクライアントが表示層内の２つ以上のオブジェクト・サーバに接続される、企業ＮＭＳのより典型的な構成を示す。各オブジェクト・サーバは、ゲートウェイを通して、集約層内のオブジェクト・サーバに接続される。集約層内のオブジェクト・サーバは、ゲートウェイを通して、収集層内のそれぞれのオブジェクト・サーバに接続される。収集層内の各オブジェクト・サーバは、１つ以上のプローブに接続される。
【００２８】
オブジェクト・サーバ
図３は、１つ以上のプローブと単一のゲートウェイとの間に接続された、収集層内にある推奨実施形態のオブジェクト・サーバ３００を示す。オブジェクト・サーバ３００は、ステータス・テーブル３０１、クライアント・スレッド・プロセッサ３０２、オートメーション・システム３０４、挿入−削除−更新−制御（ＩＤＵＣ）システム３０６及びＳＱＬインタフェース３０８を備える。オブジェクト・サーバ３００は、ＮＭＳのコアにおけるインメモリ・データベース・サーバである。イベント・レコードは、プローブ、モニタ及びゲートウェイのような、外部プログラムからオブジェクト・サーバ３００に直接的に挿入され、ステータス・テーブル３０１内に格納及び管理され、最終的にクライアント・イベント・リスト内に転送及び表示される。
【００２９】
ステータス・テーブル３０１は、イベントに関するデータを格納するためのオブジェクト・サーバ３００内のデータベースである。ステータス・テーブル３０１の１つのフィールドは、優先イベント・フラグである。データをステータス・テーブル３０１に挿入したり、データをステータス・テーブル３０１から検索するには、ＳＱＬインタフェース３０８を通して与えられるＳＱＬコマンドを使用する。推奨実施形態では、データベースをテーブルとして説明するが、データベースは、このフォーマットに制限されない。従って、本発明は、他の任意のデータベース・フォーマットで表現することができる。
【００３０】
構造化照会言語（ＳＱＬ）インタフェース３０８は、テーブル及びビューのような、関係データベース・オブジェクトの定義及び操作を可能にする。対話型のＳＱＬインタフェース３０８は、オブジェクト・サーバに接続し、これと対話し且つこれを制御するために使用することができる。対話型のＳＱＬインタフェース３０８は、新しいデータベース・テーブルを作成するか、又は実行すべきオブジェクト・サーバを停止させるようなタスクを可能にする。
【００３１】
ＩＤＵＣシステム３０６による処理のために定義される３つの拡張ＳＱＬコマンドは、ＳＱＬイベント高速追跡コマンド、ＳＱＬアクション・コマンド及びＳＱＬメッセージ送信コマンドである。
【００３２】
ＳＱＬイベント高速追跡コマンドは、インタレストがあるパーティであると識別されたクライアントへの高速追跡のために、テーブル行をＩＤＵＣシステム３０６へ渡すために使用される。インタレストがあるパーティは、特定のクライアント接続ＩＤを介して、又はＩＤＵＣチャネル名を介して、定義することができる。その結果、イベント高速追跡制御メッセージが、それぞれのクライアントにプッシュされる。このイベント高速追跡制御メッセージがクライアントによって受信される場合、このクライアントは、ＳＱＬインタフェース３０８を介して与えられる"select via" ＳＱＬコマンドを使用して、必要とされる列を取り出すように進行するであろう。このことは、クライアント・ゲートウェイが、ステータス・テーブル３０１内の行に直接的にアクセスすることを可能にする。要求されたイベント行要素は、ステータス・テーブル３０１から要求元のクライアントに与えられる。
【００３３】
ＳＱＬアクション・コマンドは、クライアントが理解するコマンド・アクションを、クライアント、クライアントのセット、又は作用すべきオブジェクト・サーバに送信するために使用される。
【００３４】
ＳＱＬメッセージ送信コマンドは、クライアント情報テキスト・メッセージを送信するために使用される。このメッセージ引き数は、式として定義される。というのは、このようにすると、ＳＱＬ手続きブロック内の変数をハードコードされた定義済みの値として単に強制するのではなく、これらの変数を使用してメッセージを構築することが可能になるからである。
【００３５】
クライアント・スレッド・プロセッサ３０２は、ステータス・テーブル３０１に挿入すべきデータを決定するイベント・レコードを挿入するためのＳＱＬコマンドを解析し且つこのイベント・レコードをステータス・テーブル３０１に挿入するためのものである。
【００３６】
オートメーション・システム３０４は、挿入後（post-insert）トリガを含む。挿入後トリガは、ステータス・テーブル３０１内に実際に挿入されたイベントが当該サーバ内に永続するように、かかるイベントだけを高速に追跡することを保証する。最速の態様でイベントを高速に追跡する推奨実施形態では、挿入後トリガは、プローブによって設定された挿入済みイベント・レコード内の高速追跡フラグを探すことにより、かかる挿入済みイベント・レコード内の重要なイベントを探す。他の実施形態では、挿入後トリガは、より正確な高速追跡のために、プローブのフィルタよりも一層細かく調整されたフィルタを適用することができる。基準が真に解決される場合、挿入後トリガは、（ＳＱＬインタフェース３０８内で定義された）ＳＱＬイベント高速追跡コマンドを使用して、イベント行の全体をＩＤＵＣシステム３０６に送信するであろう。ＩＤＵＣシステム３０６による処理の後、このイベントは、ＩＤＵＣイベント高速追跡制御メッセージとして、オブジェクト・サーバ３００から高速に追跡されるであろう。イベント高速追跡制御メッセージとしてプッシュされる任意の行は、可能であれば、処理チェーン内の重複する挿入を防止するために、保留中の任意のＩＤＵＣ変更データをパージさせるであろう。
【００３７】
イベントは、ＳＱＬイベント高速追跡コマンドを使用して、挿入後トリガ内のチャネルと関連付けられる。例えば、このイベントがアクセス違反であれば、全てのイベントは、一のセキュリティ・チャネルと関連付けられるであろう。
【００３８】
疑似コード
ifevent.FastTrack == 1
begin
ifevent.type = accessViolation : IDUC EVTFT 'Security_Channel', insert , new; 
end
【００３９】
ＩＤＵＣシステム及びＩＤＵＣ制御メッセージ
ＩＤＵＣ制御メッセージは、ＩＤＵＣ接続を使用して、クライアントとオブジェクト・サーバとの間のＩＤＵＣシステム３０６から送信される。本実施形態では、３つのＩＤＵＣ制御メッセージは、イベント高速追跡制御メッセージ、アクション・コマンド制御メッセージ及びメッセージ送信制御メッセージである。
【００４０】
イベント高速追跡制御メッセージは、２つの基本特性を有する。第１に、このメッセージは、必要に応じて、完全なイベントの詳細を取り出すことができるように、クライアントが通知をオリジナルの行に関係付けることを可能にする、完全に記述的なキーを保持する。第２に、このメッセージは、サーバから追加の詳細を取り出すことなく、このメッセージの意味を感知することができるように、十分にサマリされた記述を保持する。この第２の特性は、エンド・ユーザ通知クライアント・ポップアップ・ツールにとって必要である。かかるツールの目的は、できるだけ速い時間にインタレストのある特定のイベントをユーザに通知することである。十分なサマリをこのメッセージ内にプッシュすると、これをより効率的に行うことが可能となり、従って、システムの潜在的なスループットを向上させることができる。イベントの完全な詳細を取り出すことは、ユーザがそれを見たいと決定するまで、遅延させることができる。
【００４１】
アクション・コマンド制御メッセージは、クライアントに操作すべきコマンドを送信するための構造化された手段を提供する。このコマンドは、他のクライアントから来ることがある。このコマンドの意味は、ＩＤＵＣシステム３０６内では未知であり、必要とされるアクションを実行するために、クライアント自体が解釈及び理解しなければならない。このコマンドの解釈は、クライアントの責任であるから、アクション・コマンドの本文は、バイト・データ・ブロックとして扱われる。アクション・コマンド制御ペイロードは、以下で定義される。
【００４２】
メッセージ送信制御メッセージは、当日のメッセージ、システム保守ウィンドウ及び操作問題のような、情報メッセージをクライアントに送信するための構造化された手段を提供する。クライアントがこのメッセージの受信時に実行する必要のある唯１つのアクションは、実際のメッセージのテキストを適切な方法でエンド・ユーザに表示することである。
【００４３】
ＩＤＵＣシステム３０６は、コールバック機能３０９、クライアント・コマンド・メッセージ・キュー３１２、クライアント・コマンド・スレッド・プロセッサ３１４、接続済みリアルタイム・クライアント３１６及びＩＤＵＣチャネル・キャッシュ４００を備える。
【００４４】
コールバック機能３０９は、チャネル・キャッシュ４００のデータにアクセスするために使用される。定義済みのコールバック機能は、次の通りである。解決コールバック、実行コールバック、前処理（pre-processing）コールバック、送信前（pre-send）コールバック、フォーマット・コールバック、送信後（post-send）コールバック及び後処理（post-processing）コールバック。
【００４５】
解決コールバック（３．１）は、高速追跡要求の性質を有効にし、全ての処理要素に対する一のハンドルを獲得する。
【００４６】
実行コールバック（３．２）は、イベント高速追跡制御メッセージを構築する。
【００４７】
前処理コールバック（４．４．１）は、宛先クライアント・セットの処理に必要とされる任意のデータ要素を設定するために、アプリケーションによって使用される。
【００４８】
送信前コールバック（４．４．２．１）は、現在の宛先クライアントの処理に必要とされる任意のデータ要素を設定するために、アプリケーションによって使用される。
【００４９】
フォーマット・コールバック（４．４．２．２）は、文字セット変換のような、クライアントに配信すべきメッセージ・ペイロードの任意の特定フォーマットの設定を実行するために、アプリケーションによって使用される。
【００５０】
送信後コールバック（４．４．２．４）は、送信前コールバック又はフォーマット・コールバックにおける現在のクライアント用に設定された任意のデータ要素をクリーンアップするために、アプリケーションによって使用される。
【００５１】
後処理コールバック（４．４．３）は、宛先クライアント・セットの処理用に設定された任意のデータ項目をクリーンアップするために、アプリケーションによって使用される。
【００５２】
クライアント・コマンド・メッセージ・キュー３１２は、コマンド・メッセージをクライアント・コマンド・スレッド・プロセッサ３１４に渡す前に、これらのコマンド・メッセージを保持する。
【００５３】
クライアント・コマンド・スレッド・プロセッサ３１４は、ＩＤＵＣ制御メッセージを解決し且つこの制御メッセージを必要とされる宛先クライアントに配信する責任を有する。クライアント・コマンド・スレッド・プロセッサ３１４は、コールバック機能３０９を介して、ＩＤＵＣチャネル・テーブル４００を使用することにより、どのクライアントがどの制御メッセージにインタレストがあるかを決定する。これらのテーブルの連続的なウォークを防止するために、これらのテーブル内容の内部メモリ・キャッシュが構築される。その結果、この内部メモリ・キャッシュは、データに関する追加のインデックスを使用することができる。また、これらのテーブルに挿入後−更新−削除トリガが接続され、その結果、可能な場合には、完全なリフレッシュを行うことなく、この内部メモリ・キャッシュを最新状態に維持することができる。
【００５４】
接続済みのリアルタイム・クライアント・リスト３１６は、完全に確立された各ＩＤＵＣ接続に関する詳細なエントリを提供する。一旦チャネル・テーブル４００に対する一のハンドルが獲得されると、解決コールバック（３．１）は、接続済みのリアルタイム・クライアント・リスト３１６をウォークする。リアルタイム・クライアント・エントリごとに、ユーザ、ホスト名、アプリケーション名及びアプリケーション記述コンポーネントを、１つ以上のチャネル・インタレスト・エントリと比較することにより、このクライアントが所定のＩＤＵＣクライアント・コマンドにインタレストがあるか否かを決定する。一致する各クライアントＩＤは、クライアントＩＤリストに追加され、このＩＤリストがＩＤＵＣクライアント・コマンド・スレッド３１４に戻される。
【００５５】
ＩＤＵＣチャネル・テーブル４００とも呼ばれるＩＤＵＣチャネル・キャッシュ４００は、それぞれのテーブル内にクライアント・インタレストの詳細を格納する。ＩＤＵＣチャネル・テーブル４００は、インタレスト・グループの定義と見なすことができる。というのは、ＩＤＵＣチャネル・テーブル４００は、所定のＩＤＵＣ制御メッセージにインタレストがある、リアルタイム・クライアントを定義するからである。使用可能なＩＤＵＣチャネルは、標準のオムニバス構成ＧＵＩを介して、管理ユーザによって定義される。このようにすると、この構成はオブジェクト・サーバ３００自体の中核として維持され、クライアント自体における構成を殆ど必要としない。もし、一のＩＤＵＣ制御メッセージが一のクライアントに配信されるならば、このクライアントは、そのクライアントのタイプについて予測された方法でこの制御メッセージを自動的に処理する。
【００５６】
図４を参照して説明する。使用可能なＩＤＵＣチャネルの詳細は、１セットの４つのチャネル・テーブル（すなわち、channel ４０２、channel_interest ４０４、channel_summary ４０６、channel_summary_cols ４０８）内に格納される。これらのテーブルは、各オブジェクト・サーバ内の名前空間iduc_system 内に位置する。将来は、ＩＤＵＣに関係する他の任意のサポート・テーブルが、このデータベースに追加されるであろう。以下、図４に示す４つのテーブルを参照して、各チャネルの詳細を説明する。
【００５７】
iduc_system.channel ４０２は、オブジェクト・サーバ３００内の既知のＩＤＵＣチャネルのセットを定義する。関連するテーブル内に格納されたチャネルの詳細をより効率的に参照するために、整数の外部キーであるChannelID が追加される。
【００５８】
iduc_system.channel_interest ４０４は、所定のチャネルのためのチャネル・インタレストを格納する。各エントリを合成フィルタと見なすことができるのは、所定のチャネルにインタレストがあるＩＤＵＣ対応クライアントを、そのホスト名、アプリケーション名、アプリケーション記述及び／又はそのユーザ名の組み合わせとして定義することができる場合である。各列に値を提供する必要があるとは限らない。空ストリングを保持する任意の列は、解決に対して無関係のコンポーネントと見なされる。ElementName 列を除く全ての列は、必要とされるフィルタ基準を正規表現として定義することができる。１チャネル当たり複数のインタレスト・エントリが存在し得る。インタレストがあるクライアント・パーティのセットを定義するために、ユーザがこれと同数のインタレスト記述を有するようにすることができる。
【００５９】
iduc_system.channel_summary ４０６が、イベント高速追跡制御メッセージのためにだけ使用されるのに対し、channel ４０２及び channel interest ４０４は、通常の処理中に使用される。この列は、オブジェクト・サーバ３００自体の内部にある特定テーブルのサマリ詳細を定義する。このサマリ列テーブルへの参照をより効率的にするために、整数の外部キーであるSummaryID が追加される。オブジェクト・サーバ３００内の任意のテーブルからの列を高速に追跡することができるので、このテーブルは、イベントを高速に追加されたことがある複数のテーブルに対し一のチャネルを関連付けることができる。
【００６０】
iduc_system.channel_summary_cols ４０８は、所定のテーブル用の実際のサマリを形成する、正確な列に関する詳細を格納する。この列の名前及びサマリ順序内のその位置は、channel_summary テーブル４０６内で提示される所定のサマリ定義の一部である、列ごとに指定される。
【００６１】
以下、図３に示すステップを参照して、高速に追跡されるＩＤＵＣイベントの操作上の使用事例を説明する。
【００６２】
ステップ１：プローブは、モニタ中のソース・システムから生イベントを受信する。この生イベントは、このプローブの現在の規則ファイルを通して渡される。これらの規則内の一の条件は、このイベントが顧客／システムにとって重要な問題であることを識別することができる。この生イベントは、ＳＱＬ高速追跡イベント・コマンドにパッケージ化され、オブジェクト・サーバ３００に配信される。
【００６３】
ステップ２：ＳＱＬ高速追跡イベント・コマンドは、クライアント・スレッド・プロセッサ３０２内で受信され、そこで処理される。ＳＱＬ高速追跡イベント・コマンドは、コマンド・パーザによって解析され、有効性について検査された後、このイベントがステータス・テーブル３０１内に挿入される。
【００６４】
ステップ３：挿入後トリガは、このイベントがステータス・テーブル３０１に挿入されたことを検出する。オートメーション・システム３０４内の一の条件は、高速追跡フィールドの値を調べ、ＩＤＵＣシステム３０６がこのイベントを高速に追跡することを要求する。
【００６５】
ステップ３．１：ＩＤＵＣシステム３０６は、当該高速追跡要求の性質を有効にし、全ての処理要素に対するハンドルを獲得する。
【００６６】
ステップ３．２：コールバック・プロセッサ３０９は、この要求及びこのイベントを完全に記述する、一の制御メッセージを構築する。このコマンド要求は、メッセージ内容の点から、完全に記述的である。もし、この要求がチャネル名を保持するならば、このイベントを高速に追跡するためのチャネル定義は、ＩＤＵＣチャネルのキャッシュされたデータ内で見いだされる。もし、如何なるチャネルも見つからなければ、この要求は除去される。しかし、この要求が特定のクライアントＩＤに対するものであれば、デフォルト・チャネルが使用される。ステータス・テーブル３０１及びチャネルに関連するサマリ・フィールド・リストも、チャネル・キャッシュ４００内で見いだされる。もし、このイベントを保持するステータス・テーブル３０１について如何なるサマリ・リストも定義されていなければ、このテーブル用の１次キー・リストがサマリ・フィールド・リストになる。
【００６７】
ステップ３．３：見いだされたチャネル定義、１次キー・リスト、サマリ・フィールド・リスト要素及びステータス・テーブル３０１からのイベント・データを使用し且つ列ハンドルを使用して、高速追跡メッセージが構築される。このイベント高速追跡制御メッセージは、この要求のユーザ・データ参照内に格納済みの、予め構築されたＩＤＵＣ変更セット（単一イベント用）を含む。変更セットは、ＩＤＵＣ更新サイクル中に一のイベントについて生じたことの、短縮化された記述である。例えば、このイベントが受信され、再び受信され、さらに再び受信される場合、１つ以上の属性がそれらの初期値から変更されているために、変更セットは、（対応する値を伴う）挿入−挿入−更新−更新のように見えることがある。全ての要素を共に１つのコマンドに入れると、ソース行を参照することなく処理を行うことができる。この優先コマンドは、一の優先コマンドとして、クライアント・コマンド・メッセージ・キュー３１２上にスタックされる。
【００６８】
ステップ４．０：この優先コマンドは、クライアント・コマンド・メッセージ・キュー３１２からクライアント・コマンド・スレッド・プロセッサ３１４に送信される。
【００６９】
ステップ４．１：この優先コマンドが受信され且つ処理される。この受信済みの優先コマンドは、自己記述的である。しかし、クライアント・コマンド・スレッド・プロセッサ３１４は、宛先クライアントＩＤのセットを解決する必要がある。これらのＩＤの解決及びこのコマンドの処理は、オブジェクト・サーバ３００によって定義された１セットのコールバックを介して達成される。第１に、全ての宛先クライアントのクライアントＩＤが解決される。クライアント・コマンド・スレッド・プロセッサ３１４は、コールバック・プロセッサ３０９内の解決機能を呼び出すことにより、このリストを解決する。このようにすると、クライアント・コマンド・スレッド・プロセッサ３１４は、宛先リストが何であるか又は宛先リストを解決する方法を知る必要なしに、コールバックをアプリケーションにインストールすることができる。
【００７０】
ステップ４．２：コールバック・プロセッサ３０９内の解決機能は、キャッシュされたチャネル・データ３１０内のＩＤＵＣチャネル名を調べる。その結果、この解決機能は、チャネル・インタレスト・リストに対する一のハンドルを有することになる。詳細については、ステップ３．２を参照されたい。
【００７１】
ステップ４．３：一旦このチャネル・インタレスト・リストに対するハンドルが獲得されると、この解決コールバック機能は、接続済みのリアルタイム・クライアント・リスト３１６をウォークする。このリスト内の各エントリは、一の接続とペアになる完全に確立された各ＩＤＵＣ接続に関する詳細を提供する。リアルタイム・クライアント・エントリごとに、このクライアントが所定のＩＤＵＣクライアント・コマンドにインタレストがあるか否かを決定するために、ユーザ、ホスト名、アプリケーション名及びアプリケーション記述コンポーネントが、各チャネル・インタレスト・エントリと比較される。一致するクライアントごとに、そのクライアントＩＤがクライアントＩＤリストに追加され、これがクライアント・コマンド・スレッド３１４に戻される。もし、クライアント・コマンド・スレッド３１４に戻される宛先ＩＤのリストが空であれば、高速追跡メッセージの処理が終了し、そして成功ステータスが戻される。もし、このリストが空でなければ、このスレッドは、クライアント・イベント高速追跡ＩＤＵＣコマンド・メッセージ・ペイロードを構築するように進行する。
【００７２】
ステップ４．４：このメッセージ・ペイロードを構築した後、次の処理ステップが実行される。
【００７３】
ステップ４．４．１：アプリケーションにインストールされたＩＤＵＣクライアント・コマンド前処理コールバックを呼び出す。このコールバックは、宛先クライアント・セットの処理に必要とされる任意のデータ要素を設定するために、当該アプリケーションによって使用することができる。
【００７４】
ステップ４．４．２：接続済みのリアルタイム・クライアント・リスト３１６を使用して、宛先リスト内の各クライアントＩＤが検索される。
【００７５】
ステップ４．４．２．１：アプリケーションにインストールされたクライアント・メッセージ・フォーマット前処理コールバックを呼び出す。このコールバックは、現在の宛先クライアントの処理に必要とされる任意のデータ要素を設定するために、当該アプリケーションによって使用することができる。
【００７６】
ステップ４．４．２．２：アプリケーションにインストールされたクライアント・メッセージ・フォーマット送信コールバックを呼び出す。このコールバックは、現在の宛先クライアントの処理に必要とされる任意のデータ要素を設定するために、このアプリケーションによって使用することができる。このコールバックは、クライアントに配信すべきメッセージ・ペイロードの任意の特定のフォーマット化（例えば、文字セット変換）を実行するために、このアプリケーションによって使用することができる。このようにすると、ペイロードを信頼できる形式でクライアントに配信することができる。オブジェクト・サーバ３００では、このコールバックは、既知の文字セット変換ルーチンを使用して、ペイロード・メッセージをオブジェクト・サーバ３００の文字セットからクライアントの文字セットに変換する。
【００７７】
ステップ４．４．２．３：フォーマット化されたペイロードを有する、完全なイベント高速追跡ＩＤＵＣ制御メッセージを構築し、これをそのＩＤＵＣ接続を介してクライアントに送信する。
【００７８】
ステップ４．４．２．４：アプリケーションにインストールされたクライアント・メッセージ送信後コールバックを呼び出す。このコールバックは、送信前コールバック又はフォーマット・コールバックにおける現在のクライアント用に設定された任意のデータ要素をクリーンアップするために、このアプリケーションによって使用することができる。このコールバックは、現在のクライアントＩＤをＩＤＵＣ変更セットに追加するために、オブジェクト・サーバ３００によって使用される。このＩＤＵＣ変更セットは、高速に追跡される挿入、更新又は削除のための任意の保留中ＩＤＵＣを除去するために使用されるであろう。
【００７９】
ステップ４．４．３：アプリケーションにインストールされたＩＤＵＣクライアント・コマンド後処理コールバックを呼び出す。このコールバックは、宛先クライアント・セットの処理用に設定された任意のデータ項目をクリーンアップするために、このアプリケーションによって使用することができる。オブジェクト・サーバ３００は、このコールバックを使用して現在のＩＤＵＣ変更セットを適用することにより、メッセージが成功裡に送信された任意のクライアントのための任意の保留中ＩＤＵＣを除去する。
【００８０】
ステップ５：オブジェクト・サーバ３００のゲートウェイ読み取り手段は、高速追跡イベントを受信する。このゲートウェイ読み取り手段は、複数行の１次キー列の値を抽出し、適切な"select via" ＳＱＬコマンドを構築することにより、必要とする全ての列の値を取り出す。戻される結果セットは、シミュレートされるＩＤＵＣデータ処理構造に統合され、高優先順位のメッセージとして書き込み手段に送信される。この書き込み手段は、次のメッセージとしてキューからこの高優先順位のメッセージを獲得するとすぐに、この高優先順位のメッセージを処理する。高速に追跡されたイベントは、宛先オブジェクト・サーバに挿入され、そこで配信が完了する。もし、宛先クライアントの読み取り手段が通知ツールであれば、このメッセージからのように、イベント・サマリが表示されるであろう。このイベントのさらなる詳細が必要でない限り、オブジェクト・サーバ３００への戻りトリップは存在しない。この時点で、このイベントの１次キー列の値を使用することができる。
【００８１】
例
以下に例示するように、イベント高速追跡制御メッセージ・ペイロードが定義される。サマリ列リストは、ユーザによって定義されるコンポーネントであって、このペイロードを形成するためにステータス・テーブル３０１からどのデータ要素が使用されるかを定義する。
【００８２】
“s:evtft:<channel_name><action_type><src_table>:<primary_key><summary_cols>”
【００８３】
但し、“s:evtft:” は、イベント高速追跡制御メッセージを表し且つその後に続くものがペイロード表現を保持するイベント高速追跡ストリングであることを表す、汎用コードである。
【００８４】
“<channel_name>” は、この制御メッセージに挿入されるチャネル定義の名前である。
【００８５】
“<action_type>” は、このイベント・レコードについて実行されるアクションのタイプである。これらのタイプは、挿入を表す“I”、更新を表す“U”、そして削除を表す“D” である。
【００８６】
“<src_table>” は、高速追跡イベントが生じる、ステータス・テーブル３０１を定義する。定義の形式は、“<db_name>.<tbl_name>”である。但し、 <db_name> は、データベース名であり、<tbl_name > は、テーブル名である。
【００８７】
“<primary_key>” は、高速追跡が操作するステータス・テーブル３０１内の列を定義する。<primary_key> の形式は、<col_num>.<col_list> である。
【００８８】
“<summary_cols>“ は、この制御メッセージ内で送信されるステータス・テーブル３０１内の列のサブセット（サマリ）を定義する。<primary_key> の形式は、<col_num>.<col_list> である。
【００８９】
“<col_num>” は、１次キー又はサマリ内の列の数である。
【００９０】
“<col_list>” は、“<col_name>:<col_type>:<col_value><col_value_end>”の形式を有する。
【００９１】
“<col_name>” は、テキスト名である。
【００９２】
“<col_type>” は、ストリングについては “S” であり、整数については“I” である。
【００９３】
“<col_value>” は、ストリングに変換された列の値である。
【００９４】
“<col_value_end>” 及び “<value_end>” は、区切り文字
［数１］
（制御文字シーケンス０Ｘ０８ｂ１）である。
【００９５】
他の実施形態
本発明の方法は、この方法の諸ステップを実行するための論理手段を備えた論理装置において適切に具体化することができ、かかる論理手段は、ハードウェア・コンポーネント又はファームウェア・コンポーネントから構成することができる。例えば、図３は、論理及び方法の両方の実施形態を示す。
【００９６】
また、本発明の論理配置は、本発明の方法は、その諸ステップを実行するための論理手段を備えた論理装置において適切に具体化することができ、そしてかかる論理手段は、例えば、プログラマブル論理アレイ内の論理ゲートのような諸コンポーネントから構成することができる。さらに、かかる論理配置は、例えば、固定又は伝送可能なキャリア媒体に格納することができる仮想ハードウェア記述言語を使用して、かかるアレイ内に論理的な構造を一時的又は永久的に確立するためのイネーブル手段において具体化することができる。
【００９７】
さらに、前述の方法は、１つ以上のプロセッサ（図示せず）上で稼働するソフトウェア内で完全に又は部分的に適切に実行することができ、そしてかかるソフトウェアは、磁気ディスク又は光ディスクのような任意の適切なデータ担体（図示せず）上に担持されたコンピュータ・プログラム要素として提供することができる。同様に、データ送信用のチャネルは、種々のストレージ媒体に加えて、有線式又は無線式信号媒体のような信号担持媒体を含むことができる。
【００９８】
本発明は、コンピュータ・システムに関連して使用するためのコンピュータ・プログラムとして適切に具体化することができる。かかる実装は、コンピュータ可読媒体（例えば、フレキシブル・ディスク、ＣＤ−ＲＯＭ、ＲＯＭ又はハードディスク）のような有形的媒体上に固定されるか、或いはモデム又は他のインタフェース装置を介して、（光通信回線、アナログ通信回線等を含む）有形的媒体又は（マイクロ波、赤外線等の無線伝送技術を含む）非有形的媒体上でコンピュータ・システムに伝送可能な、一連のコンピュータ可読命令から構成することができる。かかる一連のコンピュータ可読命令は、前述の機能性の全部又は一部を具体化する。
【００９９】
かかるコンピュータ可読命令は、多数のコンピュータ・アーキテクチャ又はオペレーティング・システムに関連して使用するために、多数のプログラミング言語で書くことができる。
【０１００】
さらに、かかる命令は、半導体メモリ、磁気メモリ、光メモリ等の、任意のメモリ技術を使用して格納することができ、或いは光通信、赤外線通信、マイクロ波通信等の、任意の通信技術を使用して伝送することができる。
【０１０１】
かかるコンピュータ・プログラムは、例えば、ビニールで包装したソフトウェア、コンピュータ・システムのシステムＲＯＭ又は固定ディスクにプリロードしたソフトウェア等の、印刷又は電子文書を伴う取り外し可能な媒体として配布するか、或いはインターネットやワールド・ワイド・ウェブのようなネットワークを介してサーバ又は電子掲示板から配布することができる。
【０１０２】
プロセス・ソフトウェアＸＸＸは、ＣＤ、ＤＶＤ等の記憶媒体のローディングを介して、クライアント、サーバ及びプロキシ・コンピュータ内に手動的に且つ直接的にロードすることにより、これを配備することができるが、プロセス・ソフトウェアは、これを中央サーバ又は中央サーバのグループに送信することにより、コンピュータ・システムに自動的に又は半自動的に配備することもできる。その場合、プロセス・ソフトウェアは、これを実行するクライアント・コンピュータに事後的にダウンロードされる。代替的に、プロセス・ソフトウェアは、電子メールを介して、クライアント・システムに直接的に送信される。その場合、プロセス・ソフトウェアは、これをディレクトリに切り離すプログラムを実行する電子メール上のボタンによって、ディレクトリに切り離されるか又はディレクトリにロードされる。他の代替方法は、プロセス・ソフトウェアをクライアント・コンピュータのハード・ドライブ上にあるディレクトリに直接的に送信するというものである。プロキシ・サーバが存在する場合、プロセスは、プロキシ・サーバ・コードを選択し、このプロキシ・サーバ・コードをどのコンピュータに配置すべきかを決定し、このプロキシ・サーバ・コードを送信した後、このプロキシ・サーバ・コードをプロキシ・コンピュータにインストールする。プロセス・ソフトウェアは、このプロキシ・サーバに送信され、このプロキシ・サーバ上に格納されるであろう。
【０１０３】
プロセス・ソフトウェアは、クライアント、サーバ及びネットワーク環境へ統合される。このため、アプリケーション、オペレーティング・システム及びネットワーク・オペレーティング・システムと共存するようにプロセス・ソフトウェアを準備させ、次に、プロセス・ソフトウェアが機能するであろう環境内のクライアント及びサーバ上にプロセス・ソフトウェアをインストールすることが行われる。第１のステップは、プロセス・ソフトウェアが配備されるであろうネットワーク・オペレーティング・システムを含む、クライアント及びサーバ上の任意のソフトウェアであって、プロセス・ソフトウェアによって必要とされる又はプロセス・ソフトウェアと協働するような、任意のソフトウェアを識別することである。これは、ネットワーク・オペレーティング・システム（すなわち、ネットワーキング機能を追加することにより基本オペレーティング・システムを拡張するソフトウェア）を含む。次に、ソフトウェア・アプリケーション及びバージョン番号が識別され、プロセス・ソフトウェアと協働するというテストに合格したソフトウェア・アプリケーション及びバージョン番号のリストと比較されるであろう。このリストに見当たらないか、又は正しいバージョンと一致しないソフトウェア・アプリケーションは、正しいバージョン番号でアップグレードされるであろう。プロセス・ソフトウェアからソフトウェア・アプリケーションにパラメータを渡すプログラム命令は、そのパラメータ・リストがプロセス・ソフトウェアによって必要とされるパラメータ・リストと一致することを保証するために、検査されるであろう。それとは逆に、ソフトウェア・アプリケーションからプロセス・ソフトウェアに渡されるパラメータは、これらのパラメータがプロセス・ソフトウェアによって必要とされるパラメータと一致することを保証するために、検査されるであろう。ネットワーク・オペレーティング・システムを含むクライアント及びサーバのオペレーティング・システムが識別され、プロセス・ソフトウェアと協働するというテストに合格したオペレーティング・システム、バージョン番号及びネットワーク・ソフトウェアのリストと比較されるであろう。テスト済みのオペレーティング・システム及びバージョン番号のリストと一致しないオペレーティング・システム、バージョン番号及びネットワーク・ソフトウェアは、クライアント及びサーバ上で、必要とされるレベルにアップグレードされるであろう。プロセス・ソフトウェアを配備すべきソフトウェアが、プロセス・ソフトウェアと協働するというテストに合格した正しいバージョン・レベルにあることを保証した後、プロセス・ソフトウェアをクライアント及びサーバ上にインストールすることにより、統合が完了する。
【０１０４】
プロセス・ソフトウェアは共有されて、柔軟且つ自動化された態様で複数の顧客に対し同時にサービスを提供する。それは、標準化され、カスタマイズを殆ど必要とせず、スケーラブルであり、従量制のキャパシティ・オンデマンドを提供する。プロセス・ソフトウェアは、１つ以上のサーバからアクセス可能な共有ファイル・システム上に格納することができる。プロセス・ソフトウェアは、データ及びアクセスされるサーバ上のＣＰＵユニットを使用するサーバ処理要求を保持するトランザクションを介して、実行される。ＣＰＵユニットは、サーバの中央プロセッサに関する分、秒、時間のような時間の単位である。また、評価されたサーバは、ＣＰＵユニットを必要とする他のサーバを要求することができる。ＣＰＵユニットは、使用量の測定値を表す１つの例である。使用量の他の測定値は、ネットワーク帯域幅、メモリ使用量、ストレージ使用量、パケット転送、完全トランザクション等を含む。複数の顧客が同じプロセス・ソフトウェアを使用する場合、それぞれのトランザクションは、これらのトランザクション内に含まれ且つ特定の顧客及びその顧客のためのサービスのタイプを識別する、パラメータによって差異化される。ＣＰＵユニットの全てに加えて、各顧客用のサービスのために使用される他の使用量の測定値が記録される。任意の１つのサーバに対するトランザクションの数がこのサーバの性能に影響するような数に達する場合、キャパシティを増加させ且つ作業負荷を共有するために他のサーバがアクセスされる。同様に、ネットワーク帯域幅、メモリ使用量、ストレージ使用量等の使用量の他の測定値が、性能に影響するようなキャパシティに接近する場合、作業負荷を共有するように追加のネットワーク帯域幅、メモリ使用量、ストレージ使用量等が追加される。各サービス及び顧客のために使用される使用量の測定値は、収集サーバに送信され、そしてこの収集サーバは、プロセス・ソフトウェアの共有式実行を提供するサーバのネットワーク内の任意の場所で処理された、各サービス対応及び各顧客対応の使用量の測定値を合計する。この合計済みの使用量の測定値と単位コストとが定期的に乗算され、その結果であるプロセス・ソフトウェアの総サービス・コストが顧客に送信されるか、或いは顧客によってアクセスされるウェブサイト上に指示され、これに応じて、顧客は、サービス・プロバイダに支払金を送金する。他の実施形態では、サービス・プロバイダは、銀行又は金融機関における顧客の口座からの支払いを直接的に要求する。他の実施形態では、もし、サービス・プロバイダが、プロセス・ソフトウェアを使用する当該顧客の顧客でもあれば、両当事者間の支払金の送金を最小にするために、当該顧客が支払うべき支払金は、サービス・プロバイダが支払うべき支払金と調整される。
【０１０５】
プロセス・ソフトウェアは、仮想プライベート・ネットワーク（ＶＰＮ）の使用を通して、配備し、アクセスし、実行することができる。ＶＰＮは、そうでなければ保護されていないか又は信頼できないネットワークを通して接続を安全にするために使用することができる、技術の任意の組み合わせである。ＶＰＮは、セキュリティを改良し、運用コストを減少させるために使用される。ＶＰＮは、遠隔サイト又はユーザを相互に接続するために、公衆網（通常はインターネット）を使用する。ＶＰＮは、専用回線のような専用の、実世界の接続を使用する代わりに、企業の私設網からインターネットを通して遠隔サイト又は被雇用者に経路指定される「仮想」接続を使用する。ＶＰＮを介するソフトウェアへのアクセスは、プロセス・ソフトウェア（すなわち、任意の場所に常駐するソフトウェア）の配信又は実行の目的のためにＶＰＮを特別に構成することにより、サービスとして提供することができる。この場合、ＶＰＮの存続時間は、支払金額に基づき、所定の期間又は所定数の配備に制限される。プロセス・ソフトウェアは、遠隔アクセス又はサイト間のＶＰＮの何れかを介して、展開し、アクセスし、実行することができる。遠隔アクセスＶＰＮを使用する場合、プロセス・ソフトウェアは、企業の私設網と遠隔ユーザとの間の（第３者のサービス・プロバイダが介在する）安全で、暗号化された接続を介して、配備され、アクセスされ、実行される。企業サービス・プロバイダ（ＥＳＰ）は、ネットワーク・アクセス・サーバ（ＮＡＳ）を設定し、遠隔ユーザに対しそのコンピュータ用のデスクトップ・クライアント・ソフトウェアを提供する。その後、在宅勤務者は、ＮＡＳに到達するようにフリーダイアル番号をダイヤルするか、又はケーブル若しくはＤＳＬモデムを介して直接的に接続し、それぞれのＶＰＮクライアント・ソフトウェアを使用して企業ネットワークにアクセスした後、プロセス・ソフトウェアにアクセスし、ダウンロードし、実行する。サイト間のＶＰＮを使用する場合、プロセス・ソフトウェアは、企業の複数の固定サイトをインターネットのような公衆網を介して接続するために使用される、専用装置及び大規模暗号化の使用を通して、配備され、アクセスされ、実行される。プロセス・ソフトウェアは、トンネリング（すなわち、パケット全体を他のパケット内に配置し且つこれをネットワーク上に送信するプロセス）を介して、ＶＰＮ上を移送される。外部パケットのプロトコルは、トンネル・インタフェースと呼ばれるネットワーク及び両端によって理解される。パケットは、ネットワークに出入りする。
【符号の説明】
【０１０６】
３００・・・オブジェクト・サーバ
３０１・・・ステータス・テーブル
３０２・・・クライアント・スレッド・プロセッサ
３０４・・・オートメーション・システム
３０６・・・挿入−削除−更新−制御（ＩＤＵＣ）システム
３０８・・・ＳＱＬインタフェース
３０９・・・コールバック・プロセッサ（機能）
３１２・・・クライアント・コマンド・メッセージ・キュー
３１４・・・クライアント・コマンド・スレッド・プロセッサ
３１６・・・接続済みリアルタイム・クライアント
４００・・・ＩＤＵＣチャネル・キャッシュ（テーブル）
【図１】
2010539572.tif 000003
【図２】
2010539572.tif 000004
【図３】
2010539572.tif 000005
【図４】
2010539572.tif 000006
【国際調査報告】
2010539572.tif 000007
2010539572.tif 000008