モジュール化されたソフトウェアシステム内でコマンドをルーティングするシステム及び方法
管理される全ネットワーク（管理されるネットワーク内の個々の装置を含む）を集合的に、又はそれらの１つを個々に、見及び／又は管理できるサービスとしてマネージメントプラットホームをセキュアに且つ効率的に配送し、管理されるネットワーク及びシステムにおいて連続的に利用可能なインテリジェンスをリアルタイムで与えると共に、アドレススキーマの衝突、不要なインフラストラクチャーを回避する必要性、並びに適用可能なメモリ及び帯域幅制約内で全ての必要情報をリアルタイムで取得する必要性を克服する収斂型のネットワークマネージメントアプリケーション及びシステムが提供される。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークマネージメント及びサポートの分野に係る。より詳細には、本発明は、複数の異種ネットワーク及びシステムをリモート位置から安全に監視及び管理するためのシステムであって、他の能力の中でも、管理される全てのネットワークを通してイベントをリアルタイムで選択的に又は全体的に監視できると共に、ネットワークへの特殊なアクセスを必要とせず、且つ管理されるネットワークの又はその中のアーキテクチャー、ビジネス目的又はアドレススキーマに関わりなく、管理される各ネットワーク内で任意の内部深さまで個々のネットワーク要素にアクセスし管理することのできるシステムを提供する。
【０００２】
（関連出願の相互参照）
本出願は、２００８年７月３１日に出願された米国プロビジョナル特許出願第６１／０８５，４０７号の出願日の利益を主張するもので、その開示全体を参考としてここに援用する。又、本出願は、本出願と同日に出願された他の同時係争中の米国特許出願の開示全体も参考としてここに援用する。
【背景技術】
【０００３】
近代的なデータ及び通信ネットワークは、非常に複雑であり、それらネットワーク及びそれにより提供されるサービスを維持し且つ円滑に実行するには実質的なマネージメントを必要とする。「ネットワークマネージメント」の範囲内の活動の中には、ネットワーク、並びにそのシステム及びコンポーネントの健全さを監視して、問題をできるだけ早く、好ましくは、ユーザ又はビジネスプロセスに影響が及ぶ前に、見分けることがある。このようなマネージメントの範囲内の他の活動には、オペレーション、アドミニストレーション、メンテナンス、及びプロビジョニングも含まれる。
【０００４】
上述した形式のマネージメント及びサポートをネットワークごとに提供するために多数のシステムが存在する。
【０００５】
多くの組織は、複雑なネットワークを必要としているが、それらを管理するためのリソースが不足であるか、個々のネットワーク用の完全にそろったマネージメントシステムを取得するための予算が不足であるか、或いはこのような活動を外部調達できればより経済的であると考えている。しかしながら、複数の異なる顧客に対してネットワークの管理を仕事としている組織は、顧客ごとに個別のマネージメントインフラストラクチャーを提供しなければならない場合には、何倍もの経費に直面することになる。それ故、異なる所有者又は管理者のもとにあるか、さもなければ、異なるアーキテクチャー、異なるマネージメントポリシー、異なるビジネス目的、及び／又は異なる全体的設計を特徴とするネットワークを意味する複数の異種ネットワークを、リモート位置からではあるが、集中的及び安全に管理することのできるシステムが要望される。
【０００６】
所与のネットワーク内の又は所与のネットワークに向けられたネットワーク及びネットワーク装置のマネージメントをサポートするために多数のアクセス方法が存在する。これらアクセス方法は、シンプルネットワークマネージメントプロトコル（ＳＮＭＰ）、コマンドラインインターフェイス（ＣＬＩ）、カスタムＸＭＬ、ＣＭＩＰ、ウインドウズマネージメントインスツルメンテーション（ＷＭＩ）、トランザクションランゲッジ１、ＣＯＲＢＡ、ｎｅｔｃｏｎｆ、Ｊａｖａ（登録商標）マネージメントエクステンション（ＪＭＸ）、Ｊａｖａメッセージングサービス（ＪＭＳ）、ＳＯＡＰ、及びＸＭＬ−ＲＰＣを含む。これらは、主として、マネージメントジョブを行う上で助けとなる低レベルプロトコルであるが、複数の異種ネットワークを管理することに含まれる問題に対処するものではない。
【０００７】
上述したように、現在、企業レベルのネットワークを全体的に管理するためのシステムは存在する。普及型システムは、ヒューレットパッカード社からのＯｐｅｎＶｉｅｗ（登録商標）、コンピュータアソシエイツ社からのＵｎｉｃｅｎｔｅｒ（登録商標）及びＩＢＭ Ｔｉｖｏｌｉ（登録商標）フレームワークを含む。しかしながら、これらのシステムは、主として、企業レベルネットワークを個々に管理するために開発されたものである。それらは、異種ネットワークを完全に管理するための限定された能力しか有していない。このようなシステムの別の例は、Ｓｏｌａｒｗｉｎｄｓ（登録商標）Ｏｒｉｏｎ（登録商標）ネットワークパーフォーマンスモニタである。しかしながら、このＳｏｌａｒｗｉｎｄｓシステムは、ステートレス通信方法を使用するもので、監視されるネットワーク内の個々の装置のリモートマネージメント以外を監視することに向けられる。若干異なる解決策は、米国特許公告第２００６／０２１８２６７ Ａ１号に示されたＪｕｍｐｎｏｄｅシステムであり、これは、ローカルネットワークイベントを監視して、収集した情報をリモートマネージメントセンターへ通信するためにローカルネットワークにインストールできるハードウェア機器を提供する。しかしながら、このＪｕｍｐｎｏｄｅ（登録商標）機器は、ネットワークイベントをローカルで追跡し、それ故、接続のロス、ひいては、データロス及びセキュリティリスクの影響を受け易い。更に、各々のハードウェア機器は、リモートマネージメントファシリティへの必要な接続をなすためにそれ自身の「インターネットドロップ」（又はローカルネットワークの外部から直接アクセスできる他のアクセスポイント（モデムポートのような））を有していなければならず、そして機器は、ステートレス通信及びポーリングに依存するが、これは、リアルタイムデータ取得を与えるものではない。
【０００８】
又、ネットワーク間通信のためのツール、例えば、プロキシーサーバーや、リモートコントロールソフトウェアシステム、例えば、ＧｏＴｏＭｙＰＣ（登録商標）（現在サイトリックスシステムズにより所有された）及びＡｌａｒｍｎｅｔTM（ハニウェルセキュリティシステムズによる）も存在する。しかしながら、これらツールは、特殊な証明書、ＶＰＮアクセス、ファイアウォールにおける特殊な開口、等の特殊な構成、或いはより深いアクセスを許すソケット及びトンネルの手動構造をもたずに、管理されるネットワークの第１レベルを越えて通信する仕方を提供するものではない。又、それらは、一度に１つのデータソースしか見ないことを選択する以外、複数の管理されるネットワーク及びシステムにわたり全てのイベントを無差別に監視することから生じる膨大な量のデータを減少するためのメカニズムを提供するものでもない。加えて、集中型ポーリングは、エンドユーザコミュニティネットワークとは個別のマネージメントネットワークからしばしば遂行され、その結果、ポーリングされるリソースの利用性についてエンドユーザのローカルな視点の忠実度に欠けることになる。更に、距離からの測定は、待ち時間のように、実際に行われる測定に人為的な統計値を導入する。
【０００９】
同様に、ネットワークの内部ワーキング及びリソースを外部のビュー及びアクセスから分離するために、ネットワークアドレストランスレーション（ＮＡＴ）のようなツールも存在し、ＮＡＴシステムは、特定された内部ネットワーク行先及びリソースへメッセージを転送するように構成することができる。この解決策の例が、米国特許第６，５８１，１０８号（ルーセントテクノロジー社に譲渡された）、並びに米国特許公告第２００５／０２７１０４７ Ａ１号及び第２００６／００２９０８３ Ａ１号に示されている。しかしながら、このようなファシリティは、リモートマネージメントに対する限定された有用性に過ぎない。ＮＡＴドメインの内部から開始されるＮＡＴ接続は、セッションに基づくものである。外部から開始された接続を転送するために特殊な構成にすることができる。しかしながら、ＮＡＴファイアウォールを通してネットワークを外部で管理するのは、不可能である。というのは、ＮＡＴ内の各ネットワーク要素を外部からアクセスできるようにＮＡＴを構成しなければならないからである。
【００１０】
複数のネットワークを管理するように試みたシステムは、次のことを含めて、多数の問題を満足に処理できない。
【００１１】
管理されるネットワーク間でのプライベートアドレススペースの重畳。異種ネットワークは、同じプライベートアドレス割り当てを良く利用して、衝突を招くことがある。既存の問題回避法は、異なるネットワークスキーマを指定することを含むが、これは、特に、全スキーマを一度に変更する必要があるために非常に不便で且つ高価であり；又、ＶＰＮ或いはスタティックルーティングを通して一度に１つのネットワークにアタッチすることも含み、従って、多大な複写及び費用で複数のマネージメントインフラストラクチャーを監視し又は設ける際に時間的ギャップを生じる。リコー社に譲渡された米国特許第７，３０２，４６９号に示された別の解決策は、全体的に固有であると推定されるスキーマ、例えば、ＭＡＣアドレスをベースとするものを使用する。しかしながら、このようなシステムは、監視能力は与えるが、装置のローカルネットワークの外部のリモートファシリティが装置を個々にアドレスしてそれらを管理するための手段は与えない。
【００１２】
特殊な構成体が各ネットワーク内のプロセス及びリソースにアクセスしてそれらを管理する必要性。ＶＰＮ、ファイアウォールのホール、等の「特殊な」アクセス手段を与えることなく、ネットワークプロセス及びリソースをリモート管理するための一般的な方法は存在しない。従来の解決策は、全て、高価で、不便で又はセキュリティの妥協を伴い、ネットワークマネージメントサービスに対する多くの潜在的な顧客にとって受け容れられない。
【００１３】
圧倒的な量のネットワークイベント情報。各ネットワークは、監視の目的で、かなり多量のイベント情報を発生することができる。この情報の量は、マネージメントのために複数のネットワークが集計されるときに増倍される。既存のシステムは、当該情報を監視する連続的能力を妥協することなく、イベント情報を関連するものにどのように限定するかの問題を充分に取り扱っていない。
【発明の概要】
【発明が解決しようとする課題】
【００１４】
従って、特殊なアクセスのための広範囲な又は非一貫性の構成を伴わずに顧客のファイアウォール及びセキュリティ習慣を広めることによりサポートされる仕方で単一の共通のインフラストラクチャーから複数の異種ネットワークを管理し及びサービスするための実際的且つ効果的な方法と、これらの技術の効果を取り入れ、管理される全てのネットワークを集合的に又はそれらの１つを個々に見及び／又は管理できるサービスとしてマネージメントプラットホームを配送する収斂型のネットワークマネージメントアプリケーションと、が要望される。
【課題を解決するための手段】
【００１５】
本発明の目的は、管理されているネットワーク又はシステムの所有者がトポロジー特徴又は要素を変更する必要なく、単一の共通のインフラストラクチャーから複数の異種ネットワークを管理しサービスするための方法を提供することである。
【００１６】
本発明の更に別の目的は、管理されるネットワークとシステムとの間に生じ得るアドレススペース衝突を克服する方法を提供することにより、複数の異種ネットワークのためのマネージメント及びサービス方法を容易にすることである。
【００１７】
本発明の別の目的は、基本的マネージメント要素の管理可能な選択に基づきマネージメントインフラストラクチャーを拡張可能に構築できるように、マネージメント要素間で通信をルーティングするための均一で且つ包括的な方法を提供することである。
【００１８】
又、本発明の目的は、異種ネットワーク及びシステムを管理しサポートするためのシステムにおいて、圧倒的な量の非関連データを受け容れることなく、又、関連データを除外するようにデータ視野を限定することなく、複数のネットワークマネージメントプロセスに関するリアルタイム情報をリモート位置から見るための方法を提供することである。
【００１９】
本発明の付加的な目的は、前記個々の目的を満足するように前記技術の効果を取り入れて、管理される全てのネットワークを集合的に又はそれらの１つを個々に見及び／又は管理できるサービスとしてマネージメントプラットホームを配送する収斂型ネットワークマネージメントアプリケーションを提供することである。
【００２０】
これらの目的を達成するために、本発明は、１つの実施形態において、管理されるネットワーク又はシステムの位置から離れた中心の物理的位置から複数の異種ネットワーク及びシステムを監視し及び管理するためのシステムであって、管理されているネットワーク又はシステムの所有者がトポロジー特徴又は要素を変更する必要なく、且つ管理されるネットワークへの専用接続を必要とせずに、オペレーションが行われるシステムを提供することである。このシステムは、ユーザが管理される全てのネットワークを集合的に又はそれらの１つを個々に見及び／又は管理できるようにするサービスとして提供することができる。
【００２１】
複数の異種ネットワーク及びシステムを管理する能力を容易にするために、本発明は、更に、前記実施形態において、各要素のローカルドメイン内で固有の識別子を要素のアドレスに結合し、そしてその結合された固有の識別子をマネージメントシステムの他の要素に利用できるようにすることにより、ネットワークトポロジーを各要素に対する重畳するＩＰアドレススキーマで管理する能力を提供する。
【００２２】
前記能力を容易にするために、本発明は、更に、そのような能力がモジュラーソフトウェアコンポーネントを通して提供される実施形態において、ルートを明確に又は暗示的に特定し；コマンドを特定し；前記ルート及びコマンドをパラメータとしてソケットを呼び出し；前記ルートに基づいてコマンド及びパラメータをルーティングし；ルートターゲットにおいてコマンドをそのパラメータで実行し；前記ルートを通して前記実行の結果を返送し；そして前記実行が完了したときに前記ルートを閉止することにより、そのようなコンポーネントの間でコマンドをルーティングするための方法を提供する。
【００２３】
前記実施形態において、本発明は、複数のネットワークファシリティに対し、そのファシリティにおけるネットワークマネージメントプロセスに署名するための要求をそのネットワークファシリティの選択された１つに行い、そして前記ファシリティが前記情報のそれ自身の内部表現を更新するのとほぼ同時に、その署名したネットワークマネージメントプロセスに関する変更情報を前記マネージメントシステムへ中継することにより、マネージメントシステムが複数のネットワークマネージメントプロセスにアクセスする方法を提供する。ここで「発行・署名(publish and subscribe)」と称されるこのメカニズムは、マネージメントの目的で、集合的に及び個々に管理される両ネットワークに対して、豊富な種々の情報出力及び表示をサポートするのに使用される。
【００２４】
本発明の他の態様及び効果は、添付図面及び以下の詳細な説明から明らかとなろう。
【００２５】
本発明及びその効果をより完全に理解するために、同じ部分が同じ参照番号で示された添付図面を参照して以下に詳細に説明する。
【図面の簡単な説明】
【００２６】
【図１】本発明の一実施形態の例示的配備における種々のコンポーネント、及びそれらコンポーネントの相互接続を示すブロック図である。
【図２】本発明の一実施形態に使用されるルーティング方法及びプロトコルのためのソケット及びチャンネル接続を示すブロック図である。
【図３】本発明による発行・署名メカニズムの一実施形態を使用してクライアントにデータを表示するサーバーコンポーネント及びクライアントアプリケーションの例示的セットを示すブロック図である。
【図４】例示的ネットワークマネージメントアプリケーションのトップレベルスクリーン表示であって、マネージメント中の複数の異種ネットワークを示す図である。
【図５】管理されるネットワークの選択された１つのネットワークのモニタリング及びマネージメントに向けられた例示的ネットワークマネージメントアプリケーションのスクリーン表示である。
【図６】本発明の一実施形態により監視されている選択されたマネージされるネットワークに対するイベントリストを示す例示的なスクリーン表示である。
【図７】本発明の一実施形態により時間に伴う選択されたネットワークのポート使用の監視を示す例示的なスクリーン表示である。
【図８】ネットワークマップ及び要素の表示を含む管理されるネットワークの「ダッシュボード」ビューを示す例示的スクリーン表示である。
【図９】中央のコミュニケーションマネージャー（ＣＭ）プロセッサのための健全なメトリックを示す例示的スクリーン表示である。
【図１０】ＱＯＳ表示で電話のトレースルートを示す例示的なスクリーン表示である。
【図１１】１つの電話トレースルートに対するＱＯＳを詳細に示す例示的スクリーン表示である。
【図１２】ポリシー設定モジュールを示す例示的スクリーン表示である。
【図１３】時間に伴う現在サービスレベルと、移動平均表示とを示す例示的スクリーン表示である。
【発明を実施するための形態】
【００２７】
本発明をどのようにして好ましく実施するか例示するために選択された本発明の幾つかの実施形態を以下に詳細に述べる。本発明の範囲は、ここに述べる特定の実施形態に限定されず、又、添付図面に示され、或いは発明の概要又は要約書に述べられた特定の具現化、構成、実施形態又は特徴によって限定されることもない。加えて、この開示は、複数のステップを各々含む多数の方法を記述することに注意されたい。特許請求の範囲に規定されるもの以外、このような方法におけるステップの必要な順序を暗示するものは、この説明には含まれていないことを理解されたい。
【００２８】
本明細書を理解しそして添付図面を解釈する目的で、幾つかの用語を特定の定義された仕方で理解しなければならない。
【００２９】
「異種ネットワーク」とは、異なる所有又は管理のもとにあるか、さもなければ、異なるアーキテクチャー、異なるマネージメントポリシー、及びおそらく相互に衝突するアドレススキーマを有することにより特徴付けられるネットワークを意味する。
【００３０】
「ソケット」とは、両方向通信リンクにおけるエンドポイントを意味する。ＴＣＰ／ＩＰソケットは、ソケットであるが、ＴＣＰ／ＩＰソケットではないか、又はＴＣＰ／ＩＰソケットと同じ抽象的ベースクラスからインスタンス生成されるがＴＣＰ／ＩＰソケットの全機能をもたない他のソケットも存在する（そして本発明に関して使用される）。
【００３１】
（例示的システムアーキテクチャー）
図１は、本発明の一実施形態の例示的配備における種々のコンポーネントの概略と、それらコンポーネントの相互接続とを示す高レベルブロック図である。この図は、顧客ビジネスユニット１、２、等から顧客ビジネスユニットｘまでに属するネットワーク１０１、１０２、等から１０ｘまでを示している。顧客ビジネスユニットは、同じサービスプロバイダーを使用してそれらの各ネットワークを管理することだけが共通である完全に無関係なビジネス組織である。顧客ビジネスユニット１のネットワーク１０１は、他のものより詳細に示されているが、他のものも、同等の複雑さ、より高い複雑さ又はより低い複雑さのネットワーク（図１には示されていない）を有することを理解されたい。顧客ビジネスユニット１は、３つの位置１１１（メイン位置）、１１２及び１１３を有するものとして示されている。ネットワークインフラストラクチャー内で、各位置には、リモートインテリジェンスゲートウェイ（ＲＩＧ）がある。ＲＩＧ ＣＬ１−ＲＩＧ1は、位置１１１にあり、ＲＩＧ ＢＵ１−ＲＩＧ2は、位置１１２にあり、そしてＲＩＧ ＢＵ１−ＲＩＧ3は、位置１１３にある。中央インテリジェンスプラットホーム（ＣＩＰ）は、データセンター１２０内に設けられる。データセンター１２０は、この実施形態では、ＳＲＳＴＰ（以下に詳細に述べるセキュアなリモートセッショントランスポートプロトコル）を経て顧客ビジネスユニット１−ｘの各々と、そしてより詳細には（１２１、１２２及び１２ｘについて顧客側で破線を続けることにより示すように）、ネットワークマネージメントの目的で顧客ビジネスユニットの主たるファシリティとみなされるＲＩＧと接続１２１、１２２及び１２ｘを維持する単一ファシリティである。これらＲＩＧの各々は、破線１３１、１３２で示すように、ＳＲＳＴＰを経て、中間の下流顧客位置におけるＲＩＧに同様に接続される。ＣＩＰ１２０は、ＲＩＧの基礎となるクラスを拡張するソフトウェア構造に基づいて動作し、従って、著しい追加機能に加えて、ＣＩＰ１２０は、ＲＩＧの全ての機能及び属性を含む。
【００３２】
（異種システム間のアドレススペース衝突の克服）
企業のネットワークは、グローバルな又はプライベートなＩＰアドレッシングを使用することができる。グローバルに固有のＩＰアドレスは不足しているので、多くの企業は、ＲＦＣ１９１８により又は他の広く受け容れられた慣習に基づいて定義されたプライベートアドレススペースの１つを選択する。これらは、組織内ではプライベートに使用できるが、パブリックネットワークを通してルーティングされず、それ故、必ずしもグローバルに固有でなくてもよいアドレスの範囲を与える。従って、顧客ビジネスユニット１０１−１０ｘの２つ以上が、重畳するプライベートアドレススキーマを採用することがあって、互いに直接接続された場合に、衝突することが全体的に考えられる。例えば、顧客ビジネスユニット１（ネットワーク１０１）及び顧客ビジネスユニット２（ネットワーク１０２）の各々が、独自に、１７２．１６．０．０／１２プライベートアドレッシングスキーマを採用することがある。又、同じアドレス、例えば、１７２．１６．７．３３を有する各ネットワーク内に装置が存在することがある。両方のシステムを集中的に管理できるためには、同じアドレスが固有に指定された管理下の異種ネットワーク内の２つのノードを区別するための手段が必要となる。
【００３３】
プライベートにアドレスされたノードとそれ自身のアドレッシングドメインの外部から通信するために最も広く使用されている方法は、「ネットワークアドレストランスレーション」（ＮＡＴ）である。しかしながら、ＮＡＴは、セッションが一般的に内側から開始されるセッションベースのプロトコルである。これは、管理されるネットワークの外側から連絡をしばしば開始しなければならない場合には、マネージメントにとって充分ではない。別の解決策は、ＮＡＴルータ又はプロキシーサーバーの場合に、特殊なデータエントリーに基づいて通信を転送することであるが、これは、実際上、企業のファイアウォールに「穴」を残し、従って、運営上の負担及びセキュリティのリスクを引き起こす。別の回避法は、影響のある全てのネットワークを、５．０．０．０／８のような大きなアドレススペースに再指定することである。しかしながら、このような変更は、ネットワーク上の全てのものを、一度に全部、新たなアドレススキーマへ移行させることを必要とし、これは、甚だしくリソース集中であり且つ高価である。
【００３４】
本発明の一実施形態は、この問題を、次の技術によって解消する。
・システム（例えば、ＲＩＧ）を、管理されているトポロジーに対してローカルに配備する。
・ＲＩＧ上で、ＲＩＧに対してローカルなインフラストラクチャーにおいて、名前及び属性を抽象化しそしてタグ付けする。
・固有なＩＤ（例えば、ＣＬ１−ＲＩＧ１）及びタイムスタンプ（例えば、２００８−０６０１−２１：３３：１７．０４）でＲＩＧに名前を付ける。
・前記名前を各インフラストラクチャー要素のプライベートアドレスと合成して、ネットワークを共通に管理する目的で新たな「アドレス」を形成する。
・上流のレジスタにアクセスできる仕方でＲＩＧの要素リストにおいてマネージメントアドレスを発行する。
【００３５】
このようにして、上流の親（別のＲＩＧ又はＣＩＰ）は、ディレクトリ情報について（認証及び適用可能なポリシーに基づき）下流のＲＩＧに問合せをする。次いで、上流の親は、これらのアドレスを使用して、ＲＩＧのローカルネットワークに対して内部の要素にコマンドを向けることができる。このようなコマンドは、全て、この点でプロキシーとして働くローカルＲＩＧを通して進む。又、同じアドレッシングスキームで、上流の親が、第１のＲＩＧの下流の付加的なＲＩＧと通信を行えるようにする。例えば、ＣＩＰ１２０は、ＲＩＧ１３０のローカルネットワークインフラストラクチャーにおける装置を行先とするコマンドを送信することができる。ＣＩＰ１２０は、行先装置のアドレスを「知っている」。というのは、ＲＩＧ１３０のディレクトリがＲＩＧ１１０に発行され、次いで、ＣＩＰ１２０に発行され、従って、ＲＩＧ１１０を通してコマンドを送信することによりＲＩＧ１３０に対してローカルな装置へそのコマンドをアドレスできるからである（しかしながら、そのコマンドをどのようにルーティングするかは、（以下に述べる）ＳＲＳＴＰプロトコルに基づくもので、アドレッシングそれ自体に基づくものではない）。
【００３６】
（ルーティング方法及びプロトコル）
図１のアーキテクチャーにより生じる別の問題は、アドレッシングについての前記説明で既に示唆されたルーティングである。この問題は、複数のソフトウェアモジュール、例えば、ローカルネットワークマネージメントのためのモジュールが配備されたシステムにおいて、モジュール（及び関連要素）の全体的な収集を集中的に管理する有効な能力を得るという目的で、コマンド及びコマンド実行結果をどのようにルーティングするかである。これは、モジュラーソフトウェアシステムにおいてコマンドをルーティングするための柔軟なネットワークイネーブルメカニズムを必要とする。より一般的には、図１に示されたネットワークを管理するに必要な機能を完全に実現するために、通信及び管理のための同等に複雑な前構成を伴わずに複雑なトポロジーを任意にナビゲートできるモジュール間通信及び管理の方法が必要とされる。
【００３７】
例えば、図１を参照すれば、ネットワーク１０１、１０２、等を管理するために、ネットワークの全てのエリアに種々のマネージメントコマンドをルーティングできることが必要あり、そしてネットワークは、ＲＩＧに深さを通して「積層」されることが明らかである。これは、図１では、ＲＩＧ１１０及び１３０のチェーンとして最も簡単な形態で示されているが、もちろん、この構造は、任意の深さまで拡張することができ、そして全インフラストラクチャーがマネージメントを受けねばならない。
【００３８】
最も典型的には、コマンドは、ネットワーク環境において、ＲＰＣ、ＲＭＩ、Ｃｏｒｂａ、ＪＭＳ（Ｊａｖａメッセージングサービス）、ＳＯＡＰ、ＸＭＬ−ＲＰＣ（及び他の同様のプロトコル）のようなプロトコルで実行される。しかしながら、これらは、ポイント対ポイントプロトコルであり、コマンドが呼び出される環境において与えられるルーティング以外のルーティングを有していない。ここに示すケースでは、このようなルーティングは、必ずしも存在しない。一般的に上述した理由で、このような一般的なルーティングを、それが必要とされない場合に、単にマネージメント機能を行えるようにするだけのために、確立することは望ましくない。加えて、集中的に管理するときには、セキュリティの目的で、異なる顧客ネットワークの分離を維持することが必要になる。
【００３９】
複雑なシステムでは、テルネット又はＳＳＨのような一連の双方向プロトコルをチェーン化し、そして行先装置へ「ホップ」することにより、コマンドをルーティングすることができる。同様に、必要なソケット及びトンネルを手動で構成することもできる。しかしながら、このような通信のための構成にすることは、以上に述べた運営及びセキュリティ上の欠点を招く。
【００４０】
ここに意図されたものとある程度同様の形式の配布は、メールルーティングに対して、ユニックス対ユニックスコピー（ＵＵＣＰ）メール配送プロトコルで歴史的に行われている。ローカルではなく、マシンｂｏｘ２を通して接続されたマシンｂｏｘ３においてユーザを行先とするメールメッセージは、ｂｏｘ２！ｂｏｘ３！ユーザ（“ｂａｎｇ”プロトコルと称される）へアドレスされる。しかしながら、ＵＵＣＰプロトコルは、単一方向性である。コマンドをアドレスするのに使用される場合には、コマンドの実行結果を返送することができず、従って、ネットワークマネージメントに対して不充分となる。
【００４１】
図２は、本発明の一実施形態に使用されるルーティング方法及びプロトコルのためのソケット及びチャンネル接続を示すブロック図である。チャンネルマスターインスタンス２０１、２０２及び２０３は、ＲＩＧを表している。チャンネルマスターインスタンス２０３は、制御コンソール及びＧＵＩインターフェイスを与えるように主として機能する特殊なＲＩＧである。チャンネルマスターインスタンス２０１は、普通のＲＩＧ又はＣＩＰである（付加的な機能的要素は示されていない）。更に、チャンネルマスターインスタンスは、チャンネルマスターインスタンスを追加して、それらを上流のチャンネルマスターインスタンスの付加的なチャンネル接続、例えば、チャンネル接続２２１、２２２と同様の付加的なチャンネル接続（図示せず）に接続することにより、図２に示す以上の深さへとチェーン化することができる。
【００４２】
チャンネルマスターインスタンス２０１及び２０２の各々に示されたモジュール１、２及び３は、それらの各チャンネルマスターインスタンスに対してローカルの装置を表す。ＣｏｍＳｔｒｕｃインターフェイス２３１、２３２は、チャンネルマスターインスタンス２０１、２０２とその関連モジュールとの間の各インターフェイスである。
【００４３】
各チャンネルマスターインスタンスは、他のチャンネルマスターインスタンスへの１つ以上のチャンネル接続、例えば、チャンネル接続２２１、２２２、２２５及び２２６を有する。好ましくは、これら要素間の実際の接続は、ＳＳＬトンネルによるものであるが、暗号化が厳密に必要とされるのではない。完全なＧＵＩファシリティを有するもの以外の各チャンネルマスターインスタンスは、通常、関連コマンドラインインターフェイス、例えば、２４１、２４２を有し、これは、図２では、歴史的な理由だけで、「マリタイムターミナル(Maritime Terminal)」と称される。
【００４４】
又、各チャンネルマスターインスタンスは、ＣＳｏｃｋｅｔ（２５１、２５２、等）と称される通信インターフェイスも有し、これを通して、外部装置及びインターフェイスと通信する。あるＣＳｏｃｋｅｔ、例えば、２５２、２５３は、複数のＣＳｏｃｋｅｔのセットでそれに対応するチャンネル接続に接続され、これは、同じチャンネル接続を通して多数の異なるマネージメントプロセスをルーティングできることを反映する。
【００４５】
図２の基礎となるルーティングシステムは、コマンドベースである。最終的に、ルーティングされる各メッセージは、ルーティングチェーンの各端で実行されるべきコマンドを配送する。これらのコマンドは、ＣＳｏｃｋｅｔを通して転送される。その結果、コマンドと両方向性ソケットとのハイブリッド化が生じる。
【００４６】
この例示的システムに使用されるコマンドは、多数のトータルコマンドを含み、そしてより多くのオプションを伴うが幾つかの観点でＭｉｃｒｏｓｏｆｔ（登録商標）ＮＴTM ＮＥＴコマンドに類似したツリー構造で構成される。それらは、“ＣｏｍＳｔｒｕｃ”コマンドと称される。このコマンドハイアラーキーの機能及び文法を例示する多数の例示的ＣｏｍＳｔｒｕｃコマンドのリストが、本書に添付されたアペンディックスに記載されている。
【００４７】
アペンディックスのテーブル１に見られるように、好ましい実施形態では、ＣｏｍＳｔｒｕｃコマンドがツリー構造を形成し、ツリーの「葉」は、実際のコマンドであり、そして「枝」は、コマンドのコンテナ（又はカテゴリー）である。コマンドは、根から希望の葉までストリングを連結し、そして必要なパラメータを追加することにより、完全に特定される。このようなコマンド（ルーティング経路要素なし）の一例は、“tools restart”（ツール再スタート）である。この例では、“tools”はコンテナであり、“restart”は、ターゲット（及びＣｏｍＳｔｒｕｃコマンド）である。アドレスは、パラメータとして与えられる。コマンドの作用は、特定されたアドレスにおいてサービスを再スタートすることである。明らかなように、多数の他のコマンドが与えられる。パラメータの例は、ＩＰアドレス、装置の名前、ユーザの名前、ポート呼称、等である。
【００４８】
その目的は、コマンドを希望のターゲットモジュールへ繰り返し通過させることである。ルーティングは、ＳＲＳＴＰプロトコルにおいて、希望のコマンドと共に特定される。ルーティング経路は、“ｂａｎｇ”(“！”)で境界定めされた一連のサーバー（ＲＩＧ）名である。
【００４９】
ＳＲＳＴＰプロトコルは、次の一般的構造を有する（次の記述のフォーマットは、ＢＮＦ及び／又は“man pages”に精通した者であれば、容易に明らかであろう）。
ＳＲＳＴＰパケット：［!SERVER1NAME］［!SERVER2NAME...］ComStruc
Command［PARAMS］
ＣｏｍＳｔｒｕｃコマンド：container＋ComStruc Command ｜｜ target
ＰＡＲＡＭＤ：String*
ｓｔｒｉｎｇ：nonspacestring ｜｜ nonspacestring＋
【００５０】
ＣＳｏｃｋｅｔは、Ｊａｖａ Ｓｏｃｋｅｔ（ソケット）クラスを拡張するが、これは、通信機能ではなく互換性の目的で行われる。ＣＳｏｃｋｅｔは、種々のＳｏｃｋｅｔを呼び出す最も単純な非具現化をベースとする。Ｓｏｃｋｅｔと同様の通信機能が、継承によるのではなく、独立して与えられる。
【００５１】
ＣＳｏｃｋｅｔのコンストラクタは、ＣｏｍＳｔｒｕｃコマンドをパラメータとして受け容れる。コマンドは、それが明確に特定されたルーティングをもたない場合、ローカルチャンネルマスターインスタンスへ通され、これは、コマンドをローカルＣｏｍＳｔｒｕｃツリーへ通し、ターゲットを見つけて、可能であれば、それを実行する（ローカルで）。ルーティングが特定された場合にも、コマンドは、チャンネルマスターインスタンス（例えば、２０１）へ通されるが、次いで、その名前が第１のルーティングコマンドに一致するチャンネル接続（例えば、２２２）へ通される。これは、それ自身の名前（受け取ったルーティングストリングにおける第１の名前）を剥離し、ＳＳＬ接続を横切ってピアチャンネル接続（例えば、２２５）へそれを通す。このチャンネル接続は、次いで、コマンドをそのローカルのチャンネルマスターインスタンス（この例では、２０２）へ通す。この同じプロセスを、次いで、このチャンネルマスターインスタンスにおいて繰り返して、必要に応じてパケットを再び転送するか、さもなければ、それをローカルで実行する。各チャンネルマスターインスタンスは、同じコア機能を有するので、このプロセスは、チャンネルマスターインスタンスが配備された程度まで、全ネットワークを横断するように、反復的に不定に続けられる。
【００５２】
コマンド実行の結果は、普通のＳｏｃｋｅｔと同様に返送される（が、Ｓｏｃｋｅｔの具現化を使用するのではなく、ＣＳｏｃｋｅｔ自身の具現化を使用して）。又、完了メッセージがターゲットから送信されて、ＣＳｏｃｋｅｔ接続を閉止する。
【００５３】
より一般的に述べると、上述した好ましい実施形態は、モジュラー化されたソフトウェアシステムにおいてコマンドをルーティングするための方法であって、
・ルートを明確に又は暗示的に特定し、
・コマンドを特定し、
・前記ルート及びコマンドをパラメータとしてソケットを呼び出し、
・前記ルートに基づいてコマンド及びパラメータをルーティングし、
・ルートターゲットにおいてコマンドをそのパラメータで実行し、
・前記ルートを通して前記実行の結果を返送し、
・前記実行が完了したときに前記ルートを閉止する、
ことを含む方法を提供する。
【００５４】
前記方法におけるコマンドは、コンテナ及びコマンドのハイアラーキーにおいて与えられてもよい。ルートのリンクは、好ましくは、ＳＳＬを経て、トンネル接続される。
【００５５】
又、以上の説明に鑑み、上述したＳＲＳＴＰプロトコルを具現化するシステムは、一般的に、次のものを与えることが明らかである。
・ルート及びコマンドを暗示的に又は明確に特定し、そしてルート及びコマンドをパラメータとしてソケットを呼び出すアプリケーション
・各々次のものを含む１つ以上のローカルファシリティ
・特定のルーティングをオープンチャンネル接続とマッチングさせることによりルーティングを設定するチャンネルマスター
・ルート及びコマンドの残りを別のチャンネル接続に通信するチャンネル接続
・コマンドを実行する前記インスタンスの最後の１つの中のターゲット
【００５６】
更に、次の説明へ進む前に、好ましい実施形態において与えられてアペンディックスのテーブル１に示されたＣｏｍＳｔｒｕｃコマンドの１つがｌｏｃａｌＣｏｎｎｅｃｔコマンドであることに注意されたい。ＳＲＳＴＰを経て確立されたＣＳｏｃｋｅｔチェーンの各端にｌｏｃａｌＣｏｎｎｅｃｔを使用することで、ＶＰＮを必要とせずに、ソケット間で設定されたＳＳＬ接続を通してサービス又はネットワークオペレーション（例えば、メンテナンス）を実質上トンネル接続させることができる。例えば、このメカニズムは、ＣＩＰコンソールと管理されるネットワーク内のリソース深さとの間のテルネット又はＳＳＨ双方向セッション、或いはそのネットワークにおいてコンピュータをリモート制御するためのリモートデスクトッププロトコル（ＲＤＰ）セッション（そのコンピュータを通してローカルネットワークマネージメントオペレーションを行うことを含むが、これに限定されない）、等を確立するために容易に使用することができる。
【００５７】
更に、同様に、図２に示す全体的通信構造を、オペレーションサポートシステム（ＯＳＳ）とタンデムに配備して、サービスされるネットワークにＯＳＳがアクセスするための手段をなすプロキシーサーバーとして働かせることができる。
【００５８】
以上のことから、ＳＲＳＴＰは、ネットワークマネージメントアプリケーションのための、より詳細には、異種ネットワークをリモート及び中央位置で管理しサポートするための、柔軟な基礎をなすものであることが明らかであろう。
【００５９】
更に、本発明によりなされる分散情報の収集で、ネットワークマネージャーは、所与のネットワークにわたって地理的に分散した管理される要素のオペレーション状態を、観察された要素のローカルな観点から理解できるようにされる。更に、このような分散情報の収集は、人為的待ち時間のような測定アーティファクトが導入されるのを回避する。
【００６０】
（「発行・署名」メカニズム）
複数の異種ネットワークのためのマネージメントシステムが複数のネットワークマネージメントプロセスに関するリアルタイム情報をリモート位置から見ることができるようにする方法について説明する。この能力は、ある範囲のアプリケーションにとって重要であり、最も基本的には、サービスされるネットワークにおけるイベントを有効に監視できるようにするために重要である。
【００６１】
この問題に対する従来の解決策は、試みられた限りでは、全てのネットワークイベントのグローバルな表示又はデータベースを常時リフレッシュするか、又はイベントデータの取得を、一度に１つのソースのリフレッシュに限定することであった。いずれの解決策も、完全に満足なものではない。前者の解決策は、選択的でもないし、拡張性もない。後者の解決策は、リアルタイム監視の能力を固有に認めるものである。
【００６２】
本発明は、一実施形態において、複数の異種ネットワークにおけるイベントをリモート監視するための「発行・署名」（或いは又「署名・プッシュ」）メカニズムと称されるものを使用する。
【００６３】
図３は、発行・署名メカニズムを具現化して、リモートネットワークからイベントデータをリアルタイムで取得すると共に、マネージメントアプリケーションにおいてデータを表示するサーバーコンポーネント及びクライアントアプリケーションの例示的セットを示すブロック図である。ＧＸＬｉｓｔＣｌｉｅｎｔ３０１は、クライアントアプリケーション、例えば、ＣＩＰ１２０（図１）上のマネージメントコンソールアプリケーション、或いは上流ＲＩＧである。ＧＸＬｉｓｔＳｅｒｖｅｒシステム３１０、ＧＸＤａｔａＳｏｕｒｃｅ３１１、ＣｏｍＳｔｒｕｃＴａｒｇｅｔ３１２及びＬｉｓｔＳｅｓｓｉｏｎ３１３、等は、全て、管理されるネットワーク３２０に存在する。ＧＸＬｉｓｔＣｌｉｅｎｔ３０１は、図２を参照して上述したように、ＣｏｍＳｔｒｕｃトンネル３０３を経て、管理されるネットワーク３２０と通信する。ルーティングは、図２を参照して説明したのと同じであるが、簡単化のために、図３は、図２を参照して述べたコマンドツリーである（そして図２にはＣｏｍＳｔｒｕｃインターフェイス２３２として示された）ＣｏｍＳｔｒｕｃターゲット３１２で終了するＣｏｍＳｔｒｕｃトンネルを示す。管理されるネットワーク３２０における各監視されるプロセスの状態情報を保持するためにＧＸＤａｔａＳｏｕｒｃｅ３１１にテーブルが維持される。このようなテーブルごとにＧＸＬｉｓｔＳｅｒｖｅｒシステム、例えば、３１３が存在する。
【００６４】
「発行・署名」手順を開始するために、ＧＸＬｉｓｔＣｌｉｅｎｔ、例えば、３０１は、ＣｏｍＳｔｒｕｃトンネル３０３を経てＣｏｍＳｔｒｕｃターゲット３１２へＣｏｍＳｔｒｕｃ ＤＡＴＡ ＧＸＳＴＲＥＡＭ ＣＯＮＮＥＣＴメッセージを送信する。このコマンドは、ＧＸＬｉｓｔＳｅｒｖｅｒシステム３１０へ進む。ＧＸＬｉｓｔＳｅｒｖｅｒシステム３１０は、リストセッション、例えば、ＬｉｓｔＳｅｓｓｉｏｎ３１３をインスタンス生成する。
【００６５】
（フェーズ１）インスタンス生成の際に、ＬｉｓｔＳｅｓｓｉｏｎ３１３は、トラックを変更する（トラック変更）要求、即ちあるフィルタを使用するある列のための要求を聴取するループへと進む。このケースでは、ＧＸＬｉｓｔＣｌｉｅｎｔ３０１である要求者は、次いで、トラック変更要求（ＧＸＱＵＥＲＹ）を送信する。ＧＸＬｉｓｔＣｌｉｅｎｔは、ＣＳｏｃｋｅｔ（図２のような）を使用して、トラック変更要求を発信する。
【００６６】
ＬｉｓｔＳｅｓｓｉｏｎ３１３は、ＧＸＱＵＥＲＹ問合せコマンドを受け取り、そして「ダンピングモード」に入り、従って、それに署名した要素に対する全ての応答情報を収集して、それを、ＣｏｍＳｔｒｕｃトンネル３０３を通して要求者（３０１）へ返送し、そしてその進行も要求者へ報告する。又、ＬｉｓｔＳｅｓｓｉｏｎ３１３は、現在問合せのレコードも維持する。この点において、特定のネットワークプロセスにおける特定の更新に対する「署名」が確立される。
【００６７】
（フェーズ２）ＧＸＬｉｓｔＳｅｒｖｅｒ３１０は、関連テーブルを維持する役割を果たす。ＧＸＤａｔａＳｏｕｒｃｅ３１１を行先とするデータベース更新は、ＧＸＬｉｓｔＳｅｒｖｅｒ３１０を通して進む。各データベース更新要求も、各ＬｉｓｔＳｅｓｓｉｏｎオブジェクト３１３、等へ進む。ＬｉｓｔＳｅｓｓｉｏｎオブジェクト３１３、等内では、更新要求が、フィルタ及び要求された列名に対してマッチングされる。一致が生じた場合は（即ち、データベースサーバーが、署名されたデータを更新する場合は）、実際のデータベース更新がなされるのとほぼ同時に、更新情報（追加、除去又は変更できる）がＧＸＬｉｓｔＣｌｉｅｎｔ（例えば、３０１）へ送信される。換言すれば、情報が署名された後に、ローカルテーブル（即ち、ＧＸＬｉｓｔＳｅｒｖｅｒ３１０）を更新する「ミドルウェア」プロセスが、新たなデータを、加入者に向けられるソケット（即ち、ＣｏｍＳｔｒｕｃメッセージにより確立されるＣＳｏｃｋｅｔ）にコピーする。オーバーフローを回避するために、更新送信がキューを経て進む。このように、要求された情報が要求者へ「発行」（又は「プッシュ」）される。
【００６８】
ソケットがオープンしている間にいつでも、ＧＸＬｉｓｔＣｌｉｅｎｔ３０１は、新たなフィルタ及び新たな列を要求することができ、このケースでは、新たなダンプがあり、次いで、更新となる（フェーズ２）。
【００６９】
図４から１３は、上述した「発行・署名」メカニズム、並びにここに述べるアドレッシング及びルーティング技術の効果を取り入れて、ＣＩＰ１２０から実行することのできる例示的な「マネージメントコンソール」アプリケーションの選択されたスクリーン表示である。図示された例では、当該ネットワークは、ボイス・オーバー・ＩＰ（ＶＯＩＰ）電話及びデータ通信を取り扱う。
【００７０】
図４は、マネージメントコンソールの典型的なＧＵＩスクリーン４００を示す。スクリーンの左上のパネル４０１は、異なる会社に属するマネージメント中の異種ネットワークのリスト４１１、４１２、等を示す。その下のエリア４０７には、複数の状態レベルの各々におけるサーバーの数及びそれに関連したアイコンを示す状態の概要がある。明らかなように、この例では、サービスされている５つのサーバーが全て「良好」な状態にあり、それに対応する「グリーンライト」アイコン４０８が、左上のパネル４０１の対応エントリー４１１、４１２、等に隣接して示されている。右側のパネル４０２（上下の区分４０３及び４０４に分割された）は、全ての顧客に対してオペレータの応答を必要とする「アラーム」の概要を示す。又、表示されるアラームは、フィルタボックス４０５を通してフィルタすることもできる。各アラームに対して、アラームが生じたサーバー（４２１）、サーバーに依存するリソースのチェーン（依存性ツリー）のトップノード（４２２）、アラートレベル（例えば、０−５）（４２３）、状態（例えば、新規、応答、閉止）（４２４）、誰がアラームに応答するか指示する応答フィールド（４２５）、より詳細な記述及び他の情報を伴うテーブルへのリンクであるｄｉａｒｙＥｎｔｒｙフィールド（４２６）を含めて、データのセットがテーブル形態で示されている。右上のパネル（４０３）は、応答しなかった全ての現在アラームの概要を示し、右下のパネル（４０４）は、応答したアラームを示す。アラームが解決されると、その表示がこのディスプレイから消える。左上のパネル４０１においてネットワークエントリー４１１、４１２、等の１つをマウスでクリックすることにより、マネージメントコンソールのユーザは、管理されるネットワークの１つを選択することができる。
【００７１】
図５は、図４を参照して上述したようにマネージメントコンソールのユーザがネットワークの１つを選択した後に表示されるスクリーンを示す。このスクリーンから、ユーザは、種々のツールを使用してネットワークの状態を見るか、又はクライアントコンピュータをリモートネットワークと一時的にブリッジするＲＩＧの能力を使用して、デスクトップ共有アプリケーションを使用し又はマネージメントアプリケーションを実行する。デフォールトにより、このビューは、ここに示す実施形態では、選択されたネットワークに対するイベントの概要、このケースでは、ＨＨＲ（５１１）を表示する。この表示のコンテンツは、上述した「発行・署名」メカニズムを通して与えられる。コンテンツは、ダイナミックであり、リアルタイムで連続的にリフレッシュする。右上パネル５０３のメインメニュー５３０においてアイコン５３１、等をクリックすることにより、パネル５０２とで複数の他の表示をスワップすることができる。又、ビュー(View)ボタン５３２をクリックし、次いで、「概要(Summary)」（５４１）をクリックすることにより、図示されたイベント概要表示に到達することもできる。リストされたイベントライン５６１、等は、当該装置の「最大アラート(Max Alert)」レベルに対応して、各々カラーコード化される。この最大アラートは、装置の依存性レベルにおける最高アラートレベルを意味する。各イベントに対して、時間表示５７１、レポートされている装置に対してローカルと特定される“ｔｅｘｔ＿ｔｉｍｅ”表示５７２、イベント形式を特定するｅｖｅｎｔＩｄ５７３、この図ではｓｕｂＤｅｖｉｃｅＮａｍｅ５７４と称されるローカル装置名、この図ではｄｅｖｉｃｅＮａｍｅ５７５と称されるネットワーク（ネットワークが上流ＲＩＧ又はＣＰＩへの「装置」であるために）、及び他の情報が存在する。この実施形態では、イベントは、もし可能であれば「合併」される。これは、連続する良好なピン(ping)のような「合併可能」と考えられるイベントが、表示を新たなイベントでクラッター化するのではなく、それらの更新された時間及び図示された以前のイベント時間だけを有することを意味する。このようなケースでは、先行する合併イベントの時間に対してｌａｓｔ＿ｔｅｘｔ＿ｔｉｍｅ５７７にエントリーが存在する。概要５４１で始まるパネル５０３におけるアイテムの行は、以下に述べる多数の表示を含む他の表示へのリンクである。
【００７２】
図６は、同時に監視されている複数の異種ネットワークの１つにおいてイベントを監視するためのマネージメントコンソールスクリーンを示す。特定の顧客ネットワークが選択されると、図５の右側パネル５０４は、トップコントロールバー５０３と、このコントロールバーからユーザにより選択されたコンポーネントビューを含むスペース５０４の下部スクリーンとを表示する。ユーザは、（例えば）メインメニュー５３０から「ビュー(View)」５３２を選択し、次いで、サブメニュー５４０から「イベント(Event)」５４２を選択し、そしてイベントビューア(Event Viewer)コンポーネントは、パネル５０４のコンポーネントビュー区分において「概要ビュー(summary view)」に置き換わる。マネージメントシステムは、多数の管理されるネットワークにおけるイベントに署名するが、図６は、１つの特定の顧客ネットワーク（“ＨＨＲ”５１１）に限定された表示を示している。図６に示すイベントリストは、ダイナミックであり、図２に示す方法により、リアルタイムで自動的に更新する。「フィルタ」要素６０５は、いずれかの列に現れるキーに基づいて迅速なフィルタを可能にする全列フィルタである。上部の表示パネル６０３は、まだ確認されていないイベントのリストを含み、各々、時間６６１、ｅｖｅｎｔＩｄ６７３、ローカル装置名（ｄｅｖｉｃｅＮａｍｅ）６７４、もし影響があれば、サービス６７８、もしあれば、関連エージェントＩＰアドレス（ａｇｅｎｔＩｐ）６７９、及び他の情報を含む。下部区画６０４は、ここでは６時間として示されたドロップダウンコントロール６９１により調整可能な時間範囲において全てのイベントのリストを示す。パネル６０３及び６０４（並びに同様の他の表示）における列は、ＧＵＩコントロールにより左右に移動することができる。最も左の列は、リストのためのソートキーとして働く。デフォールトにより、ソートキーは、時間列である。
【００７３】
図７は、管理されるシステムにおけるポート使用量の表示を時間の関数として示す「システムモニタ」型グラフ表示である。図５に示すモニタリンク５４３からこのスクリーンに到達することもできる。表示は、この場合も、図２に示す方法により、リアルタイムで右から更新されて、右から左へとスクロールする移動グラフとして現れる。この特定の表示は、１２時間という選択された時間範囲（ドロップダウンコントロール７９１当たり）にわたり装置のスロット１におけるポート８の使用を示す。Ｙ軸７５１は、ビット／秒である。下部パネル７０５及び７０６は、現在ビュー（７０３、７０５）が長い時間線に適合する場合を示している。又、ビュー時間フレームは、パネル７０５及び７０６におけるクリック・ドラグアクションにより調整することもできる。或いは又、この例示において半透明のウインドウに表示されるレポートされるビット／秒の数字７０９、等は、曲線に重畳しないように、ダイナミック表示曲線が開始する場所の右に表示されてもよい。
【００７４】
図８は、ネットワークマップ及び要素の表示を含めて、管理されるネットワークの「ダッシュボード」ビューを示す例示的スクリーン表示である。左側パネル８０１は、ネットワークマップを示すもので、線８２１、８２２、等は、通信及びコントロールの線を示す。このケースでは、ＣＭ８３１は、ローカルサバイバブルプロセッサ（ＬＳＰ）８４１、８４２、等に接続されて示されている。このＬＳＰ８４１、８４２、等は、ＣＭ８３１がディスエイブルされるか又は接続を失った場合にそれら自体の制御を想定するようにプログラムされる。このようなイベントにおいて、ＣＭ８３１に通常接続される上流ＲＩＧ（図示せず）は、ＬＳＰ８４１、８４２、等へ直接取り付けられ、ＣＭ８３１からの以前のコントロールライン８２２、等は、消える。図８の右側パネル８０２は、トップレベルネットワーク要素（各々が依存性ツリーである）を、その状態のためのアイコンと共に示している。右側の表示パネル８０２の底部に沿ったリンク８５１、８５２、等は、パネル８０２のための他の「ダッシュボード」表示へのリンクであるか、それら自身のウインドウに表示されるリンクで、その各々は、監視されるネットワーク（１つ又は複数）に関する集中した高レベルのリアルタイム情報のパネルを与える。
【００７５】
図９は、中央通信マネージャー（ＣＭ）プロセッサに対する健全性メトリックを示す例示的スクリーン表示である。これは、図８のプロセッサリンク８５４から選択することができる。これは、パーセントプロセッサアイドル（９６１）、パーセントプロセッササービスメンテナンス（９６２）、電話コールに対するパーセントプロセッサ使用（９６３）及び他の情報を示す。
【００７６】
図１０は、電話トレースルートをＱＯＳ表示と共に示す例示的スクリーン表示である。図５における電話ＱＯＳ５４５をクリックし、次いで、電話をリストする中間スクリーン（図示せず）上の「トレース」をクリックすることで、このスクリーンに到達することができる。この電話リストのエントリーをダブルクリックすると、図１１に示す表示が現れる。図１０は、全ての電話に対するグラフィックトレースルート図である。電話は、フィルタコントロール１００５を通してフィルタリングすることができる。各トレースルート１０４１、１０４２、等の線は、パケットロス、ラウンドトリップ遅延及び到着間ジッタの関数である（この技術でよく知られた方法により計算された）現在のサービスクオリティ（ＱＯＳ）に基づいて色が変化する。
【００７７】
図１１は、ラウンドトリップ遅延１１５１、パケットロス１１５２ａ及び１１５２ｂ、並びにジッタ１１５３ａ及び１１５３ｂを含む１つの電話トレースルートのＱＯＳを詳細に示す例示的スクリーン表示である。ジッタ及びパケットロスの上部及び下部表示１１０３及び１１０４は、トレースされるルートの各端（例えば、メディアプロセッサ及び電話）における対応メトリックを表す。
【００７８】
図１２は、ポリシー設定モジュールを示す例示的スクリーン表示である。「ポリシー」は、イベントに基づく標準的アクション、例えば、レポート、イベントハンドリング、等をトリガーするために導入することができる。ポリシーは、フローチャートとしてプログラムされ、スクリプトの性質で機能する。ポリシーは、表示パネル１２０３においてマウスにより（図示された例では、右クリックアクセス可能メニューにより）アクセスできるＧＵＩコントロールを通して構築される。生成された各ポリシーは、パネル１２０２にリストされる。このスクリーンは、図４における設定タブ４１９から到達する（Ｓｅｔｕｐ→Ｐｏｌｉｃｙ）。表示されたフローチャート１２１０に示すポリシーは、「仮想」拡張への電話記録のためのものである（メッセージの記録のために物理的な電話が必要とされないので）。このポリシーは、“ＩＦ”条件１２１１、１２１２ごとに、イン・サービス／オン・フック又はイン・サービス／オフ・フックの状態が観察されない限りある範囲の仮想拡張に対する欠陥を表すイベントをキャンセルするために新たなイベントを発生し、そのようなケースでは、イベントがキャンセルされる。このポリシーは、ソフトホン欠陥に対してアクティブなイベントのリストをスキャンさせ、そしてソフトホンがフェイルしたかどうか調べるためにチェックを行う。もしそうでなければ、「フェイルした」イベントをキャンセルするために新たなイベントを送信する。従って、各ポリシーは、それが確立されると、図２を参照して説明したプロトコルにより、リアルタイムで監視されるイベントに基づいて、その特定の条件を連続的に強いる。
【００７９】
図１３は、サービスレベルモニタを示す例示的なスクリーン表示である。図５におけるビューリンク５３２でスタートするＶｉｅｗ→Ｓｅｒｖｉｃｅレベルをクリックすることによりこの表示に到達することができる。図１３の表示は、個別のウインドウ又は図５のパネル５０４に現れる。図１３は、コントロール１３９１により選択可能な時間フレームにわたる現在サービスレベル（１３１１）、（コントロール１３９２ごとの）時間範囲にわたる監視サービスレベルのローリング平均表示１３１２、及び他の情報を示している。この場合も、この表示は、監視されるネットワーク（１つ又は複数）及びリソース（１つ又は複数）のためのサービスレベルをリアルタイムでダイナミックに示す。
【００８０】
図１ないし３を参照して上述した技術を組み入れた図４ないし１３に示すオペレーション例は、そのようなシステムが過去に提供されるのを妨げていた障害、例えば、アドレスの衝突、実質的なネットワーク変更又は望ましからぬ付加的なインフラストラクチャーなしに構成ネットワーク内でルーティングできないこと、リモートネットワーク測定及び観察から生じるアーティファクト、及び管理される各ネットワークへの連続接続の欠如から生じる知識のギャップ、を克服するように、イベントを見、及び／又は複数の異種ネットワークを集合的に又はそれらの１つを個々に管理できるサービスの形態で提供される本発明の目的による収斂型モニタリング及びマネージメントプラットホームを完全に実現することが明らかであろう。
【００８１】
以上、本発明を詳細に説明したが、当業者であれば、種々の変化、置き換え、及び変更が容易に明らかであり、且つ特許請求の範囲に規定された本発明の精神及び範囲から逸脱せずにそれらがなされることを理解されたい。
【符号の説明】
【００８２】
１０１、１０２、・・・１０ｘ：ネットワーク
１１０、１３０：ＲＩＧ
１１１、１１２、１１３：位置
１２０：データセンター
１２１、１２２、１２ｘ：接続
２０１、２０２、２０３：チャンネルマスターインスタンス
２２１：チャンネル接続
２２２、２２５、２２６：チャンネル接続
２３１、２３２：ＣｏｍＳｔｒｕｃインターフェイス
２４１、２４２：コマンドラインインターフェイス
２５１、２５２：ＣＳｏｋｅｔ
【技術分野】
【０００１】
本発明は、ネットワークマネージメント及びサポートの分野に係る。より詳細には、本発明は、複数の異種ネットワーク及びシステムをリモート位置から安全に監視及び管理するためのシステムであって、他の能力の中でも、管理される全てのネットワークを通してイベントをリアルタイムで選択的に又は全体的に監視できると共に、ネットワークへの特殊なアクセスを必要とせず、且つ管理されるネットワークの又はその中のアーキテクチャー、ビジネス目的又はアドレススキーマに関わりなく、管理される各ネットワーク内で任意の内部深さまで個々のネットワーク要素にアクセスし管理することのできるシステムを提供する。
【０００２】
（関連出願の相互参照）
本出願は、２００８年７月３１日に出願された米国プロビジョナル特許出願第６１／０８５，４０７号の出願日の利益を主張するもので、その開示全体を参考としてここに援用する。又、本出願は、本出願と同日に出願された他の同時係争中の米国特許出願の開示全体も参考としてここに援用する。
【背景技術】
【０００３】
近代的なデータ及び通信ネットワークは、非常に複雑であり、それらネットワーク及びそれにより提供されるサービスを維持し且つ円滑に実行するには実質的なマネージメントを必要とする。「ネットワークマネージメント」の範囲内の活動の中には、ネットワーク、並びにそのシステム及びコンポーネントの健全さを監視して、問題をできるだけ早く、好ましくは、ユーザ又はビジネスプロセスに影響が及ぶ前に、見分けることがある。このようなマネージメントの範囲内の他の活動には、オペレーション、アドミニストレーション、メンテナンス、及びプロビジョニングも含まれる。
【０００４】
上述した形式のマネージメント及びサポートをネットワークごとに提供するために多数のシステムが存在する。
【０００５】
多くの組織は、複雑なネットワークを必要としているが、それらを管理するためのリソースが不足であるか、個々のネットワーク用の完全にそろったマネージメントシステムを取得するための予算が不足であるか、或いはこのような活動を外部調達できればより経済的であると考えている。しかしながら、複数の異なる顧客に対してネットワークの管理を仕事としている組織は、顧客ごとに個別のマネージメントインフラストラクチャーを提供しなければならない場合には、何倍もの経費に直面することになる。それ故、異なる所有者又は管理者のもとにあるか、さもなければ、異なるアーキテクチャー、異なるマネージメントポリシー、異なるビジネス目的、及び／又は異なる全体的設計を特徴とするネットワークを意味する複数の異種ネットワークを、リモート位置からではあるが、集中的及び安全に管理することのできるシステムが要望される。
【０００６】
所与のネットワーク内の又は所与のネットワークに向けられたネットワーク及びネットワーク装置のマネージメントをサポートするために多数のアクセス方法が存在する。これらアクセス方法は、シンプルネットワークマネージメントプロトコル（ＳＮＭＰ）、コマンドラインインターフェイス（ＣＬＩ）、カスタムＸＭＬ、ＣＭＩＰ、ウインドウズマネージメントインスツルメンテーション（ＷＭＩ）、トランザクションランゲッジ１、ＣＯＲＢＡ、ｎｅｔｃｏｎｆ、Ｊａｖａ（登録商標）マネージメントエクステンション（ＪＭＸ）、Ｊａｖａメッセージングサービス（ＪＭＳ）、ＳＯＡＰ、及びＸＭＬ−ＲＰＣを含む。これらは、主として、マネージメントジョブを行う上で助けとなる低レベルプロトコルであるが、複数の異種ネットワークを管理することに含まれる問題に対処するものではない。
【０００７】
上述したように、現在、企業レベルのネットワークを全体的に管理するためのシステムは存在する。普及型システムは、ヒューレットパッカード社からのＯｐｅｎＶｉｅｗ（登録商標）、コンピュータアソシエイツ社からのＵｎｉｃｅｎｔｅｒ（登録商標）及びＩＢＭ Ｔｉｖｏｌｉ（登録商標）フレームワークを含む。しかしながら、これらのシステムは、主として、企業レベルネットワークを個々に管理するために開発されたものである。それらは、異種ネットワークを完全に管理するための限定された能力しか有していない。このようなシステムの別の例は、Ｓｏｌａｒｗｉｎｄｓ（登録商標）Ｏｒｉｏｎ（登録商標）ネットワークパーフォーマンスモニタである。しかしながら、このＳｏｌａｒｗｉｎｄｓシステムは、ステートレス通信方法を使用するもので、監視されるネットワーク内の個々の装置のリモートマネージメント以外を監視することに向けられる。若干異なる解決策は、米国特許公告第２００６／０２１８２６７ Ａ１号に示されたＪｕｍｐｎｏｄｅシステムであり、これは、ローカルネットワークイベントを監視して、収集した情報をリモートマネージメントセンターへ通信するためにローカルネットワークにインストールできるハードウェア機器を提供する。しかしながら、このＪｕｍｐｎｏｄｅ（登録商標）機器は、ネットワークイベントをローカルで追跡し、それ故、接続のロス、ひいては、データロス及びセキュリティリスクの影響を受け易い。更に、各々のハードウェア機器は、リモートマネージメントファシリティへの必要な接続をなすためにそれ自身の「インターネットドロップ」（又はローカルネットワークの外部から直接アクセスできる他のアクセスポイント（モデムポートのような））を有していなければならず、そして機器は、ステートレス通信及びポーリングに依存するが、これは、リアルタイムデータ取得を与えるものではない。
【０００８】
又、ネットワーク間通信のためのツール、例えば、プロキシーサーバーや、リモートコントロールソフトウェアシステム、例えば、ＧｏＴｏＭｙＰＣ（登録商標）（現在サイトリックスシステムズにより所有された）及びＡｌａｒｍｎｅｔTM（ハニウェルセキュリティシステムズによる）も存在する。しかしながら、これらツールは、特殊な証明書、ＶＰＮアクセス、ファイアウォールにおける特殊な開口、等の特殊な構成、或いはより深いアクセスを許すソケット及びトンネルの手動構造をもたずに、管理されるネットワークの第１レベルを越えて通信する仕方を提供するものではない。又、それらは、一度に１つのデータソースしか見ないことを選択する以外、複数の管理されるネットワーク及びシステムにわたり全てのイベントを無差別に監視することから生じる膨大な量のデータを減少するためのメカニズムを提供するものでもない。加えて、集中型ポーリングは、エンドユーザコミュニティネットワークとは個別のマネージメントネットワークからしばしば遂行され、その結果、ポーリングされるリソースの利用性についてエンドユーザのローカルな視点の忠実度に欠けることになる。更に、距離からの測定は、待ち時間のように、実際に行われる測定に人為的な統計値を導入する。
【０００９】
同様に、ネットワークの内部ワーキング及びリソースを外部のビュー及びアクセスから分離するために、ネットワークアドレストランスレーション（ＮＡＴ）のようなツールも存在し、ＮＡＴシステムは、特定された内部ネットワーク行先及びリソースへメッセージを転送するように構成することができる。この解決策の例が、米国特許第６，５８１，１０８号（ルーセントテクノロジー社に譲渡された）、並びに米国特許公告第２００５／０２７１０４７ Ａ１号及び第２００６／００２９０８３ Ａ１号に示されている。しかしながら、このようなファシリティは、リモートマネージメントに対する限定された有用性に過ぎない。ＮＡＴドメインの内部から開始されるＮＡＴ接続は、セッションに基づくものである。外部から開始された接続を転送するために特殊な構成にすることができる。しかしながら、ＮＡＴファイアウォールを通してネットワークを外部で管理するのは、不可能である。というのは、ＮＡＴ内の各ネットワーク要素を外部からアクセスできるようにＮＡＴを構成しなければならないからである。
【００１０】
複数のネットワークを管理するように試みたシステムは、次のことを含めて、多数の問題を満足に処理できない。
【００１１】
管理されるネットワーク間でのプライベートアドレススペースの重畳。異種ネットワークは、同じプライベートアドレス割り当てを良く利用して、衝突を招くことがある。既存の問題回避法は、異なるネットワークスキーマを指定することを含むが、これは、特に、全スキーマを一度に変更する必要があるために非常に不便で且つ高価であり；又、ＶＰＮ或いはスタティックルーティングを通して一度に１つのネットワークにアタッチすることも含み、従って、多大な複写及び費用で複数のマネージメントインフラストラクチャーを監視し又は設ける際に時間的ギャップを生じる。リコー社に譲渡された米国特許第７，３０２，４６９号に示された別の解決策は、全体的に固有であると推定されるスキーマ、例えば、ＭＡＣアドレスをベースとするものを使用する。しかしながら、このようなシステムは、監視能力は与えるが、装置のローカルネットワークの外部のリモートファシリティが装置を個々にアドレスしてそれらを管理するための手段は与えない。
【００１２】
特殊な構成体が各ネットワーク内のプロセス及びリソースにアクセスしてそれらを管理する必要性。ＶＰＮ、ファイアウォールのホール、等の「特殊な」アクセス手段を与えることなく、ネットワークプロセス及びリソースをリモート管理するための一般的な方法は存在しない。従来の解決策は、全て、高価で、不便で又はセキュリティの妥協を伴い、ネットワークマネージメントサービスに対する多くの潜在的な顧客にとって受け容れられない。
【００１３】
圧倒的な量のネットワークイベント情報。各ネットワークは、監視の目的で、かなり多量のイベント情報を発生することができる。この情報の量は、マネージメントのために複数のネットワークが集計されるときに増倍される。既存のシステムは、当該情報を監視する連続的能力を妥協することなく、イベント情報を関連するものにどのように限定するかの問題を充分に取り扱っていない。
【発明の概要】
【発明が解決しようとする課題】
【００１４】
従って、特殊なアクセスのための広範囲な又は非一貫性の構成を伴わずに顧客のファイアウォール及びセキュリティ習慣を広めることによりサポートされる仕方で単一の共通のインフラストラクチャーから複数の異種ネットワークを管理し及びサービスするための実際的且つ効果的な方法と、これらの技術の効果を取り入れ、管理される全てのネットワークを集合的に又はそれらの１つを個々に見及び／又は管理できるサービスとしてマネージメントプラットホームを配送する収斂型のネットワークマネージメントアプリケーションと、が要望される。
【課題を解決するための手段】
【００１５】
本発明の目的は、管理されているネットワーク又はシステムの所有者がトポロジー特徴又は要素を変更する必要なく、単一の共通のインフラストラクチャーから複数の異種ネットワークを管理しサービスするための方法を提供することである。
【００１６】
本発明の更に別の目的は、管理されるネットワークとシステムとの間に生じ得るアドレススペース衝突を克服する方法を提供することにより、複数の異種ネットワークのためのマネージメント及びサービス方法を容易にすることである。
【００１７】
本発明の別の目的は、基本的マネージメント要素の管理可能な選択に基づきマネージメントインフラストラクチャーを拡張可能に構築できるように、マネージメント要素間で通信をルーティングするための均一で且つ包括的な方法を提供することである。
【００１８】
又、本発明の目的は、異種ネットワーク及びシステムを管理しサポートするためのシステムにおいて、圧倒的な量の非関連データを受け容れることなく、又、関連データを除外するようにデータ視野を限定することなく、複数のネットワークマネージメントプロセスに関するリアルタイム情報をリモート位置から見るための方法を提供することである。
【００１９】
本発明の付加的な目的は、前記個々の目的を満足するように前記技術の効果を取り入れて、管理される全てのネットワークを集合的に又はそれらの１つを個々に見及び／又は管理できるサービスとしてマネージメントプラットホームを配送する収斂型ネットワークマネージメントアプリケーションを提供することである。
【００２０】
これらの目的を達成するために、本発明は、１つの実施形態において、管理されるネットワーク又はシステムの位置から離れた中心の物理的位置から複数の異種ネットワーク及びシステムを監視し及び管理するためのシステムであって、管理されているネットワーク又はシステムの所有者がトポロジー特徴又は要素を変更する必要なく、且つ管理されるネットワークへの専用接続を必要とせずに、オペレーションが行われるシステムを提供することである。このシステムは、ユーザが管理される全てのネットワークを集合的に又はそれらの１つを個々に見及び／又は管理できるようにするサービスとして提供することができる。
【００２１】
複数の異種ネットワーク及びシステムを管理する能力を容易にするために、本発明は、更に、前記実施形態において、各要素のローカルドメイン内で固有の識別子を要素のアドレスに結合し、そしてその結合された固有の識別子をマネージメントシステムの他の要素に利用できるようにすることにより、ネットワークトポロジーを各要素に対する重畳するＩＰアドレススキーマで管理する能力を提供する。
【００２２】
前記能力を容易にするために、本発明は、更に、そのような能力がモジュラーソフトウェアコンポーネントを通して提供される実施形態において、ルートを明確に又は暗示的に特定し；コマンドを特定し；前記ルート及びコマンドをパラメータとしてソケットを呼び出し；前記ルートに基づいてコマンド及びパラメータをルーティングし；ルートターゲットにおいてコマンドをそのパラメータで実行し；前記ルートを通して前記実行の結果を返送し；そして前記実行が完了したときに前記ルートを閉止することにより、そのようなコンポーネントの間でコマンドをルーティングするための方法を提供する。
【００２３】
前記実施形態において、本発明は、複数のネットワークファシリティに対し、そのファシリティにおけるネットワークマネージメントプロセスに署名するための要求をそのネットワークファシリティの選択された１つに行い、そして前記ファシリティが前記情報のそれ自身の内部表現を更新するのとほぼ同時に、その署名したネットワークマネージメントプロセスに関する変更情報を前記マネージメントシステムへ中継することにより、マネージメントシステムが複数のネットワークマネージメントプロセスにアクセスする方法を提供する。ここで「発行・署名(publish and subscribe)」と称されるこのメカニズムは、マネージメントの目的で、集合的に及び個々に管理される両ネットワークに対して、豊富な種々の情報出力及び表示をサポートするのに使用される。
【００２４】
本発明の他の態様及び効果は、添付図面及び以下の詳細な説明から明らかとなろう。
【００２５】
本発明及びその効果をより完全に理解するために、同じ部分が同じ参照番号で示された添付図面を参照して以下に詳細に説明する。
【図面の簡単な説明】
【００２６】
【図１】本発明の一実施形態の例示的配備における種々のコンポーネント、及びそれらコンポーネントの相互接続を示すブロック図である。
【図２】本発明の一実施形態に使用されるルーティング方法及びプロトコルのためのソケット及びチャンネル接続を示すブロック図である。
【図３】本発明による発行・署名メカニズムの一実施形態を使用してクライアントにデータを表示するサーバーコンポーネント及びクライアントアプリケーションの例示的セットを示すブロック図である。
【図４】例示的ネットワークマネージメントアプリケーションのトップレベルスクリーン表示であって、マネージメント中の複数の異種ネットワークを示す図である。
【図５】管理されるネットワークの選択された１つのネットワークのモニタリング及びマネージメントに向けられた例示的ネットワークマネージメントアプリケーションのスクリーン表示である。
【図６】本発明の一実施形態により監視されている選択されたマネージされるネットワークに対するイベントリストを示す例示的なスクリーン表示である。
【図７】本発明の一実施形態により時間に伴う選択されたネットワークのポート使用の監視を示す例示的なスクリーン表示である。
【図８】ネットワークマップ及び要素の表示を含む管理されるネットワークの「ダッシュボード」ビューを示す例示的スクリーン表示である。
【図９】中央のコミュニケーションマネージャー（ＣＭ）プロセッサのための健全なメトリックを示す例示的スクリーン表示である。
【図１０】ＱＯＳ表示で電話のトレースルートを示す例示的なスクリーン表示である。
【図１１】１つの電話トレースルートに対するＱＯＳを詳細に示す例示的スクリーン表示である。
【図１２】ポリシー設定モジュールを示す例示的スクリーン表示である。
【図１３】時間に伴う現在サービスレベルと、移動平均表示とを示す例示的スクリーン表示である。
【発明を実施するための形態】
【００２７】
本発明をどのようにして好ましく実施するか例示するために選択された本発明の幾つかの実施形態を以下に詳細に述べる。本発明の範囲は、ここに述べる特定の実施形態に限定されず、又、添付図面に示され、或いは発明の概要又は要約書に述べられた特定の具現化、構成、実施形態又は特徴によって限定されることもない。加えて、この開示は、複数のステップを各々含む多数の方法を記述することに注意されたい。特許請求の範囲に規定されるもの以外、このような方法におけるステップの必要な順序を暗示するものは、この説明には含まれていないことを理解されたい。
【００２８】
本明細書を理解しそして添付図面を解釈する目的で、幾つかの用語を特定の定義された仕方で理解しなければならない。
【００２９】
「異種ネットワーク」とは、異なる所有又は管理のもとにあるか、さもなければ、異なるアーキテクチャー、異なるマネージメントポリシー、及びおそらく相互に衝突するアドレススキーマを有することにより特徴付けられるネットワークを意味する。
【００３０】
「ソケット」とは、両方向通信リンクにおけるエンドポイントを意味する。ＴＣＰ／ＩＰソケットは、ソケットであるが、ＴＣＰ／ＩＰソケットではないか、又はＴＣＰ／ＩＰソケットと同じ抽象的ベースクラスからインスタンス生成されるがＴＣＰ／ＩＰソケットの全機能をもたない他のソケットも存在する（そして本発明に関して使用される）。
【００３１】
（例示的システムアーキテクチャー）
図１は、本発明の一実施形態の例示的配備における種々のコンポーネントの概略と、それらコンポーネントの相互接続とを示す高レベルブロック図である。この図は、顧客ビジネスユニット１、２、等から顧客ビジネスユニットｘまでに属するネットワーク１０１、１０２、等から１０ｘまでを示している。顧客ビジネスユニットは、同じサービスプロバイダーを使用してそれらの各ネットワークを管理することだけが共通である完全に無関係なビジネス組織である。顧客ビジネスユニット１のネットワーク１０１は、他のものより詳細に示されているが、他のものも、同等の複雑さ、より高い複雑さ又はより低い複雑さのネットワーク（図１には示されていない）を有することを理解されたい。顧客ビジネスユニット１は、３つの位置１１１（メイン位置）、１１２及び１１３を有するものとして示されている。ネットワークインフラストラクチャー内で、各位置には、リモートインテリジェンスゲートウェイ（ＲＩＧ）がある。ＲＩＧ ＣＬ１−ＲＩＧ1は、位置１１１にあり、ＲＩＧ ＢＵ１−ＲＩＧ2は、位置１１２にあり、そしてＲＩＧ ＢＵ１−ＲＩＧ3は、位置１１３にある。中央インテリジェンスプラットホーム（ＣＩＰ）は、データセンター１２０内に設けられる。データセンター１２０は、この実施形態では、ＳＲＳＴＰ（以下に詳細に述べるセキュアなリモートセッショントランスポートプロトコル）を経て顧客ビジネスユニット１−ｘの各々と、そしてより詳細には（１２１、１２２及び１２ｘについて顧客側で破線を続けることにより示すように）、ネットワークマネージメントの目的で顧客ビジネスユニットの主たるファシリティとみなされるＲＩＧと接続１２１、１２２及び１２ｘを維持する単一ファシリティである。これらＲＩＧの各々は、破線１３１、１３２で示すように、ＳＲＳＴＰを経て、中間の下流顧客位置におけるＲＩＧに同様に接続される。ＣＩＰ１２０は、ＲＩＧの基礎となるクラスを拡張するソフトウェア構造に基づいて動作し、従って、著しい追加機能に加えて、ＣＩＰ１２０は、ＲＩＧの全ての機能及び属性を含む。
【００３２】
（異種システム間のアドレススペース衝突の克服）
企業のネットワークは、グローバルな又はプライベートなＩＰアドレッシングを使用することができる。グローバルに固有のＩＰアドレスは不足しているので、多くの企業は、ＲＦＣ１９１８により又は他の広く受け容れられた慣習に基づいて定義されたプライベートアドレススペースの１つを選択する。これらは、組織内ではプライベートに使用できるが、パブリックネットワークを通してルーティングされず、それ故、必ずしもグローバルに固有でなくてもよいアドレスの範囲を与える。従って、顧客ビジネスユニット１０１−１０ｘの２つ以上が、重畳するプライベートアドレススキーマを採用することがあって、互いに直接接続された場合に、衝突することが全体的に考えられる。例えば、顧客ビジネスユニット１（ネットワーク１０１）及び顧客ビジネスユニット２（ネットワーク１０２）の各々が、独自に、１７２．１６．０．０／１２プライベートアドレッシングスキーマを採用することがある。又、同じアドレス、例えば、１７２．１６．７．３３を有する各ネットワーク内に装置が存在することがある。両方のシステムを集中的に管理できるためには、同じアドレスが固有に指定された管理下の異種ネットワーク内の２つのノードを区別するための手段が必要となる。
【００３３】
プライベートにアドレスされたノードとそれ自身のアドレッシングドメインの外部から通信するために最も広く使用されている方法は、「ネットワークアドレストランスレーション」（ＮＡＴ）である。しかしながら、ＮＡＴは、セッションが一般的に内側から開始されるセッションベースのプロトコルである。これは、管理されるネットワークの外側から連絡をしばしば開始しなければならない場合には、マネージメントにとって充分ではない。別の解決策は、ＮＡＴルータ又はプロキシーサーバーの場合に、特殊なデータエントリーに基づいて通信を転送することであるが、これは、実際上、企業のファイアウォールに「穴」を残し、従って、運営上の負担及びセキュリティのリスクを引き起こす。別の回避法は、影響のある全てのネットワークを、５．０．０．０／８のような大きなアドレススペースに再指定することである。しかしながら、このような変更は、ネットワーク上の全てのものを、一度に全部、新たなアドレススキーマへ移行させることを必要とし、これは、甚だしくリソース集中であり且つ高価である。
【００３４】
本発明の一実施形態は、この問題を、次の技術によって解消する。
・システム（例えば、ＲＩＧ）を、管理されているトポロジーに対してローカルに配備する。
・ＲＩＧ上で、ＲＩＧに対してローカルなインフラストラクチャーにおいて、名前及び属性を抽象化しそしてタグ付けする。
・固有なＩＤ（例えば、ＣＬ１−ＲＩＧ１）及びタイムスタンプ（例えば、２００８−０６０１−２１：３３：１７．０４）でＲＩＧに名前を付ける。
・前記名前を各インフラストラクチャー要素のプライベートアドレスと合成して、ネットワークを共通に管理する目的で新たな「アドレス」を形成する。
・上流のレジスタにアクセスできる仕方でＲＩＧの要素リストにおいてマネージメントアドレスを発行する。
【００３５】
このようにして、上流の親（別のＲＩＧ又はＣＩＰ）は、ディレクトリ情報について（認証及び適用可能なポリシーに基づき）下流のＲＩＧに問合せをする。次いで、上流の親は、これらのアドレスを使用して、ＲＩＧのローカルネットワークに対して内部の要素にコマンドを向けることができる。このようなコマンドは、全て、この点でプロキシーとして働くローカルＲＩＧを通して進む。又、同じアドレッシングスキームで、上流の親が、第１のＲＩＧの下流の付加的なＲＩＧと通信を行えるようにする。例えば、ＣＩＰ１２０は、ＲＩＧ１３０のローカルネットワークインフラストラクチャーにおける装置を行先とするコマンドを送信することができる。ＣＩＰ１２０は、行先装置のアドレスを「知っている」。というのは、ＲＩＧ１３０のディレクトリがＲＩＧ１１０に発行され、次いで、ＣＩＰ１２０に発行され、従って、ＲＩＧ１１０を通してコマンドを送信することによりＲＩＧ１３０に対してローカルな装置へそのコマンドをアドレスできるからである（しかしながら、そのコマンドをどのようにルーティングするかは、（以下に述べる）ＳＲＳＴＰプロトコルに基づくもので、アドレッシングそれ自体に基づくものではない）。
【００３６】
（ルーティング方法及びプロトコル）
図１のアーキテクチャーにより生じる別の問題は、アドレッシングについての前記説明で既に示唆されたルーティングである。この問題は、複数のソフトウェアモジュール、例えば、ローカルネットワークマネージメントのためのモジュールが配備されたシステムにおいて、モジュール（及び関連要素）の全体的な収集を集中的に管理する有効な能力を得るという目的で、コマンド及びコマンド実行結果をどのようにルーティングするかである。これは、モジュラーソフトウェアシステムにおいてコマンドをルーティングするための柔軟なネットワークイネーブルメカニズムを必要とする。より一般的には、図１に示されたネットワークを管理するに必要な機能を完全に実現するために、通信及び管理のための同等に複雑な前構成を伴わずに複雑なトポロジーを任意にナビゲートできるモジュール間通信及び管理の方法が必要とされる。
【００３７】
例えば、図１を参照すれば、ネットワーク１０１、１０２、等を管理するために、ネットワークの全てのエリアに種々のマネージメントコマンドをルーティングできることが必要あり、そしてネットワークは、ＲＩＧに深さを通して「積層」されることが明らかである。これは、図１では、ＲＩＧ１１０及び１３０のチェーンとして最も簡単な形態で示されているが、もちろん、この構造は、任意の深さまで拡張することができ、そして全インフラストラクチャーがマネージメントを受けねばならない。
【００３８】
最も典型的には、コマンドは、ネットワーク環境において、ＲＰＣ、ＲＭＩ、Ｃｏｒｂａ、ＪＭＳ（Ｊａｖａメッセージングサービス）、ＳＯＡＰ、ＸＭＬ−ＲＰＣ（及び他の同様のプロトコル）のようなプロトコルで実行される。しかしながら、これらは、ポイント対ポイントプロトコルであり、コマンドが呼び出される環境において与えられるルーティング以外のルーティングを有していない。ここに示すケースでは、このようなルーティングは、必ずしも存在しない。一般的に上述した理由で、このような一般的なルーティングを、それが必要とされない場合に、単にマネージメント機能を行えるようにするだけのために、確立することは望ましくない。加えて、集中的に管理するときには、セキュリティの目的で、異なる顧客ネットワークの分離を維持することが必要になる。
【００３９】
複雑なシステムでは、テルネット又はＳＳＨのような一連の双方向プロトコルをチェーン化し、そして行先装置へ「ホップ」することにより、コマンドをルーティングすることができる。同様に、必要なソケット及びトンネルを手動で構成することもできる。しかしながら、このような通信のための構成にすることは、以上に述べた運営及びセキュリティ上の欠点を招く。
【００４０】
ここに意図されたものとある程度同様の形式の配布は、メールルーティングに対して、ユニックス対ユニックスコピー（ＵＵＣＰ）メール配送プロトコルで歴史的に行われている。ローカルではなく、マシンｂｏｘ２を通して接続されたマシンｂｏｘ３においてユーザを行先とするメールメッセージは、ｂｏｘ２！ｂｏｘ３！ユーザ（“ｂａｎｇ”プロトコルと称される）へアドレスされる。しかしながら、ＵＵＣＰプロトコルは、単一方向性である。コマンドをアドレスするのに使用される場合には、コマンドの実行結果を返送することができず、従って、ネットワークマネージメントに対して不充分となる。
【００４１】
図２は、本発明の一実施形態に使用されるルーティング方法及びプロトコルのためのソケット及びチャンネル接続を示すブロック図である。チャンネルマスターインスタンス２０１、２０２及び２０３は、ＲＩＧを表している。チャンネルマスターインスタンス２０３は、制御コンソール及びＧＵＩインターフェイスを与えるように主として機能する特殊なＲＩＧである。チャンネルマスターインスタンス２０１は、普通のＲＩＧ又はＣＩＰである（付加的な機能的要素は示されていない）。更に、チャンネルマスターインスタンスは、チャンネルマスターインスタンスを追加して、それらを上流のチャンネルマスターインスタンスの付加的なチャンネル接続、例えば、チャンネル接続２２１、２２２と同様の付加的なチャンネル接続（図示せず）に接続することにより、図２に示す以上の深さへとチェーン化することができる。
【００４２】
チャンネルマスターインスタンス２０１及び２０２の各々に示されたモジュール１、２及び３は、それらの各チャンネルマスターインスタンスに対してローカルの装置を表す。ＣｏｍＳｔｒｕｃインターフェイス２３１、２３２は、チャンネルマスターインスタンス２０１、２０２とその関連モジュールとの間の各インターフェイスである。
【００４３】
各チャンネルマスターインスタンスは、他のチャンネルマスターインスタンスへの１つ以上のチャンネル接続、例えば、チャンネル接続２２１、２２２、２２５及び２２６を有する。好ましくは、これら要素間の実際の接続は、ＳＳＬトンネルによるものであるが、暗号化が厳密に必要とされるのではない。完全なＧＵＩファシリティを有するもの以外の各チャンネルマスターインスタンスは、通常、関連コマンドラインインターフェイス、例えば、２４１、２４２を有し、これは、図２では、歴史的な理由だけで、「マリタイムターミナル(Maritime Terminal)」と称される。
【００４４】
又、各チャンネルマスターインスタンスは、ＣＳｏｃｋｅｔ（２５１、２５２、等）と称される通信インターフェイスも有し、これを通して、外部装置及びインターフェイスと通信する。あるＣＳｏｃｋｅｔ、例えば、２５２、２５３は、複数のＣＳｏｃｋｅｔのセットでそれに対応するチャンネル接続に接続され、これは、同じチャンネル接続を通して多数の異なるマネージメントプロセスをルーティングできることを反映する。
【００４５】
図２の基礎となるルーティングシステムは、コマンドベースである。最終的に、ルーティングされる各メッセージは、ルーティングチェーンの各端で実行されるべきコマンドを配送する。これらのコマンドは、ＣＳｏｃｋｅｔを通して転送される。その結果、コマンドと両方向性ソケットとのハイブリッド化が生じる。
【００４６】
この例示的システムに使用されるコマンドは、多数のトータルコマンドを含み、そしてより多くのオプションを伴うが幾つかの観点でＭｉｃｒｏｓｏｆｔ（登録商標）ＮＴTM ＮＥＴコマンドに類似したツリー構造で構成される。それらは、“ＣｏｍＳｔｒｕｃ”コマンドと称される。このコマンドハイアラーキーの機能及び文法を例示する多数の例示的ＣｏｍＳｔｒｕｃコマンドのリストが、本書に添付されたアペンディックスに記載されている。
【００４７】
アペンディックスのテーブル１に見られるように、好ましい実施形態では、ＣｏｍＳｔｒｕｃコマンドがツリー構造を形成し、ツリーの「葉」は、実際のコマンドであり、そして「枝」は、コマンドのコンテナ（又はカテゴリー）である。コマンドは、根から希望の葉までストリングを連結し、そして必要なパラメータを追加することにより、完全に特定される。このようなコマンド（ルーティング経路要素なし）の一例は、“tools restart”（ツール再スタート）である。この例では、“tools”はコンテナであり、“restart”は、ターゲット（及びＣｏｍＳｔｒｕｃコマンド）である。アドレスは、パラメータとして与えられる。コマンドの作用は、特定されたアドレスにおいてサービスを再スタートすることである。明らかなように、多数の他のコマンドが与えられる。パラメータの例は、ＩＰアドレス、装置の名前、ユーザの名前、ポート呼称、等である。
【００４８】
その目的は、コマンドを希望のターゲットモジュールへ繰り返し通過させることである。ルーティングは、ＳＲＳＴＰプロトコルにおいて、希望のコマンドと共に特定される。ルーティング経路は、“ｂａｎｇ”(“！”)で境界定めされた一連のサーバー（ＲＩＧ）名である。
【００４９】
ＳＲＳＴＰプロトコルは、次の一般的構造を有する（次の記述のフォーマットは、ＢＮＦ及び／又は“man pages”に精通した者であれば、容易に明らかであろう）。
ＳＲＳＴＰパケット：［!SERVER1NAME］［!SERVER2NAME...］ComStruc
Command［PARAMS］
ＣｏｍＳｔｒｕｃコマンド：container＋ComStruc Command ｜｜ target
ＰＡＲＡＭＤ：String*
ｓｔｒｉｎｇ：nonspacestring ｜｜ nonspacestring＋
【００５０】
ＣＳｏｃｋｅｔは、Ｊａｖａ Ｓｏｃｋｅｔ（ソケット）クラスを拡張するが、これは、通信機能ではなく互換性の目的で行われる。ＣＳｏｃｋｅｔは、種々のＳｏｃｋｅｔを呼び出す最も単純な非具現化をベースとする。Ｓｏｃｋｅｔと同様の通信機能が、継承によるのではなく、独立して与えられる。
【００５１】
ＣＳｏｃｋｅｔのコンストラクタは、ＣｏｍＳｔｒｕｃコマンドをパラメータとして受け容れる。コマンドは、それが明確に特定されたルーティングをもたない場合、ローカルチャンネルマスターインスタンスへ通され、これは、コマンドをローカルＣｏｍＳｔｒｕｃツリーへ通し、ターゲットを見つけて、可能であれば、それを実行する（ローカルで）。ルーティングが特定された場合にも、コマンドは、チャンネルマスターインスタンス（例えば、２０１）へ通されるが、次いで、その名前が第１のルーティングコマンドに一致するチャンネル接続（例えば、２２２）へ通される。これは、それ自身の名前（受け取ったルーティングストリングにおける第１の名前）を剥離し、ＳＳＬ接続を横切ってピアチャンネル接続（例えば、２２５）へそれを通す。このチャンネル接続は、次いで、コマンドをそのローカルのチャンネルマスターインスタンス（この例では、２０２）へ通す。この同じプロセスを、次いで、このチャンネルマスターインスタンスにおいて繰り返して、必要に応じてパケットを再び転送するか、さもなければ、それをローカルで実行する。各チャンネルマスターインスタンスは、同じコア機能を有するので、このプロセスは、チャンネルマスターインスタンスが配備された程度まで、全ネットワークを横断するように、反復的に不定に続けられる。
【００５２】
コマンド実行の結果は、普通のＳｏｃｋｅｔと同様に返送される（が、Ｓｏｃｋｅｔの具現化を使用するのではなく、ＣＳｏｃｋｅｔ自身の具現化を使用して）。又、完了メッセージがターゲットから送信されて、ＣＳｏｃｋｅｔ接続を閉止する。
【００５３】
より一般的に述べると、上述した好ましい実施形態は、モジュラー化されたソフトウェアシステムにおいてコマンドをルーティングするための方法であって、
・ルートを明確に又は暗示的に特定し、
・コマンドを特定し、
・前記ルート及びコマンドをパラメータとしてソケットを呼び出し、
・前記ルートに基づいてコマンド及びパラメータをルーティングし、
・ルートターゲットにおいてコマンドをそのパラメータで実行し、
・前記ルートを通して前記実行の結果を返送し、
・前記実行が完了したときに前記ルートを閉止する、
ことを含む方法を提供する。
【００５４】
前記方法におけるコマンドは、コンテナ及びコマンドのハイアラーキーにおいて与えられてもよい。ルートのリンクは、好ましくは、ＳＳＬを経て、トンネル接続される。
【００５５】
又、以上の説明に鑑み、上述したＳＲＳＴＰプロトコルを具現化するシステムは、一般的に、次のものを与えることが明らかである。
・ルート及びコマンドを暗示的に又は明確に特定し、そしてルート及びコマンドをパラメータとしてソケットを呼び出すアプリケーション
・各々次のものを含む１つ以上のローカルファシリティ
・特定のルーティングをオープンチャンネル接続とマッチングさせることによりルーティングを設定するチャンネルマスター
・ルート及びコマンドの残りを別のチャンネル接続に通信するチャンネル接続
・コマンドを実行する前記インスタンスの最後の１つの中のターゲット
【００５６】
更に、次の説明へ進む前に、好ましい実施形態において与えられてアペンディックスのテーブル１に示されたＣｏｍＳｔｒｕｃコマンドの１つがｌｏｃａｌＣｏｎｎｅｃｔコマンドであることに注意されたい。ＳＲＳＴＰを経て確立されたＣＳｏｃｋｅｔチェーンの各端にｌｏｃａｌＣｏｎｎｅｃｔを使用することで、ＶＰＮを必要とせずに、ソケット間で設定されたＳＳＬ接続を通してサービス又はネットワークオペレーション（例えば、メンテナンス）を実質上トンネル接続させることができる。例えば、このメカニズムは、ＣＩＰコンソールと管理されるネットワーク内のリソース深さとの間のテルネット又はＳＳＨ双方向セッション、或いはそのネットワークにおいてコンピュータをリモート制御するためのリモートデスクトッププロトコル（ＲＤＰ）セッション（そのコンピュータを通してローカルネットワークマネージメントオペレーションを行うことを含むが、これに限定されない）、等を確立するために容易に使用することができる。
【００５７】
更に、同様に、図２に示す全体的通信構造を、オペレーションサポートシステム（ＯＳＳ）とタンデムに配備して、サービスされるネットワークにＯＳＳがアクセスするための手段をなすプロキシーサーバーとして働かせることができる。
【００５８】
以上のことから、ＳＲＳＴＰは、ネットワークマネージメントアプリケーションのための、より詳細には、異種ネットワークをリモート及び中央位置で管理しサポートするための、柔軟な基礎をなすものであることが明らかであろう。
【００５９】
更に、本発明によりなされる分散情報の収集で、ネットワークマネージャーは、所与のネットワークにわたって地理的に分散した管理される要素のオペレーション状態を、観察された要素のローカルな観点から理解できるようにされる。更に、このような分散情報の収集は、人為的待ち時間のような測定アーティファクトが導入されるのを回避する。
【００６０】
（「発行・署名」メカニズム）
複数の異種ネットワークのためのマネージメントシステムが複数のネットワークマネージメントプロセスに関するリアルタイム情報をリモート位置から見ることができるようにする方法について説明する。この能力は、ある範囲のアプリケーションにとって重要であり、最も基本的には、サービスされるネットワークにおけるイベントを有効に監視できるようにするために重要である。
【００６１】
この問題に対する従来の解決策は、試みられた限りでは、全てのネットワークイベントのグローバルな表示又はデータベースを常時リフレッシュするか、又はイベントデータの取得を、一度に１つのソースのリフレッシュに限定することであった。いずれの解決策も、完全に満足なものではない。前者の解決策は、選択的でもないし、拡張性もない。後者の解決策は、リアルタイム監視の能力を固有に認めるものである。
【００６２】
本発明は、一実施形態において、複数の異種ネットワークにおけるイベントをリモート監視するための「発行・署名」（或いは又「署名・プッシュ」）メカニズムと称されるものを使用する。
【００６３】
図３は、発行・署名メカニズムを具現化して、リモートネットワークからイベントデータをリアルタイムで取得すると共に、マネージメントアプリケーションにおいてデータを表示するサーバーコンポーネント及びクライアントアプリケーションの例示的セットを示すブロック図である。ＧＸＬｉｓｔＣｌｉｅｎｔ３０１は、クライアントアプリケーション、例えば、ＣＩＰ１２０（図１）上のマネージメントコンソールアプリケーション、或いは上流ＲＩＧである。ＧＸＬｉｓｔＳｅｒｖｅｒシステム３１０、ＧＸＤａｔａＳｏｕｒｃｅ３１１、ＣｏｍＳｔｒｕｃＴａｒｇｅｔ３１２及びＬｉｓｔＳｅｓｓｉｏｎ３１３、等は、全て、管理されるネットワーク３２０に存在する。ＧＸＬｉｓｔＣｌｉｅｎｔ３０１は、図２を参照して上述したように、ＣｏｍＳｔｒｕｃトンネル３０３を経て、管理されるネットワーク３２０と通信する。ルーティングは、図２を参照して説明したのと同じであるが、簡単化のために、図３は、図２を参照して述べたコマンドツリーである（そして図２にはＣｏｍＳｔｒｕｃインターフェイス２３２として示された）ＣｏｍＳｔｒｕｃターゲット３１２で終了するＣｏｍＳｔｒｕｃトンネルを示す。管理されるネットワーク３２０における各監視されるプロセスの状態情報を保持するためにＧＸＤａｔａＳｏｕｒｃｅ３１１にテーブルが維持される。このようなテーブルごとにＧＸＬｉｓｔＳｅｒｖｅｒシステム、例えば、３１３が存在する。
【００６４】
「発行・署名」手順を開始するために、ＧＸＬｉｓｔＣｌｉｅｎｔ、例えば、３０１は、ＣｏｍＳｔｒｕｃトンネル３０３を経てＣｏｍＳｔｒｕｃターゲット３１２へＣｏｍＳｔｒｕｃ ＤＡＴＡ ＧＸＳＴＲＥＡＭ ＣＯＮＮＥＣＴメッセージを送信する。このコマンドは、ＧＸＬｉｓｔＳｅｒｖｅｒシステム３１０へ進む。ＧＸＬｉｓｔＳｅｒｖｅｒシステム３１０は、リストセッション、例えば、ＬｉｓｔＳｅｓｓｉｏｎ３１３をインスタンス生成する。
【００６５】
（フェーズ１）インスタンス生成の際に、ＬｉｓｔＳｅｓｓｉｏｎ３１３は、トラックを変更する（トラック変更）要求、即ちあるフィルタを使用するある列のための要求を聴取するループへと進む。このケースでは、ＧＸＬｉｓｔＣｌｉｅｎｔ３０１である要求者は、次いで、トラック変更要求（ＧＸＱＵＥＲＹ）を送信する。ＧＸＬｉｓｔＣｌｉｅｎｔは、ＣＳｏｃｋｅｔ（図２のような）を使用して、トラック変更要求を発信する。
【００６６】
ＬｉｓｔＳｅｓｓｉｏｎ３１３は、ＧＸＱＵＥＲＹ問合せコマンドを受け取り、そして「ダンピングモード」に入り、従って、それに署名した要素に対する全ての応答情報を収集して、それを、ＣｏｍＳｔｒｕｃトンネル３０３を通して要求者（３０１）へ返送し、そしてその進行も要求者へ報告する。又、ＬｉｓｔＳｅｓｓｉｏｎ３１３は、現在問合せのレコードも維持する。この点において、特定のネットワークプロセスにおける特定の更新に対する「署名」が確立される。
【００６７】
（フェーズ２）ＧＸＬｉｓｔＳｅｒｖｅｒ３１０は、関連テーブルを維持する役割を果たす。ＧＸＤａｔａＳｏｕｒｃｅ３１１を行先とするデータベース更新は、ＧＸＬｉｓｔＳｅｒｖｅｒ３１０を通して進む。各データベース更新要求も、各ＬｉｓｔＳｅｓｓｉｏｎオブジェクト３１３、等へ進む。ＬｉｓｔＳｅｓｓｉｏｎオブジェクト３１３、等内では、更新要求が、フィルタ及び要求された列名に対してマッチングされる。一致が生じた場合は（即ち、データベースサーバーが、署名されたデータを更新する場合は）、実際のデータベース更新がなされるのとほぼ同時に、更新情報（追加、除去又は変更できる）がＧＸＬｉｓｔＣｌｉｅｎｔ（例えば、３０１）へ送信される。換言すれば、情報が署名された後に、ローカルテーブル（即ち、ＧＸＬｉｓｔＳｅｒｖｅｒ３１０）を更新する「ミドルウェア」プロセスが、新たなデータを、加入者に向けられるソケット（即ち、ＣｏｍＳｔｒｕｃメッセージにより確立されるＣＳｏｃｋｅｔ）にコピーする。オーバーフローを回避するために、更新送信がキューを経て進む。このように、要求された情報が要求者へ「発行」（又は「プッシュ」）される。
【００６８】
ソケットがオープンしている間にいつでも、ＧＸＬｉｓｔＣｌｉｅｎｔ３０１は、新たなフィルタ及び新たな列を要求することができ、このケースでは、新たなダンプがあり、次いで、更新となる（フェーズ２）。
【００６９】
図４から１３は、上述した「発行・署名」メカニズム、並びにここに述べるアドレッシング及びルーティング技術の効果を取り入れて、ＣＩＰ１２０から実行することのできる例示的な「マネージメントコンソール」アプリケーションの選択されたスクリーン表示である。図示された例では、当該ネットワークは、ボイス・オーバー・ＩＰ（ＶＯＩＰ）電話及びデータ通信を取り扱う。
【００７０】
図４は、マネージメントコンソールの典型的なＧＵＩスクリーン４００を示す。スクリーンの左上のパネル４０１は、異なる会社に属するマネージメント中の異種ネットワークのリスト４１１、４１２、等を示す。その下のエリア４０７には、複数の状態レベルの各々におけるサーバーの数及びそれに関連したアイコンを示す状態の概要がある。明らかなように、この例では、サービスされている５つのサーバーが全て「良好」な状態にあり、それに対応する「グリーンライト」アイコン４０８が、左上のパネル４０１の対応エントリー４１１、４１２、等に隣接して示されている。右側のパネル４０２（上下の区分４０３及び４０４に分割された）は、全ての顧客に対してオペレータの応答を必要とする「アラーム」の概要を示す。又、表示されるアラームは、フィルタボックス４０５を通してフィルタすることもできる。各アラームに対して、アラームが生じたサーバー（４２１）、サーバーに依存するリソースのチェーン（依存性ツリー）のトップノード（４２２）、アラートレベル（例えば、０−５）（４２３）、状態（例えば、新規、応答、閉止）（４２４）、誰がアラームに応答するか指示する応答フィールド（４２５）、より詳細な記述及び他の情報を伴うテーブルへのリンクであるｄｉａｒｙＥｎｔｒｙフィールド（４２６）を含めて、データのセットがテーブル形態で示されている。右上のパネル（４０３）は、応答しなかった全ての現在アラームの概要を示し、右下のパネル（４０４）は、応答したアラームを示す。アラームが解決されると、その表示がこのディスプレイから消える。左上のパネル４０１においてネットワークエントリー４１１、４１２、等の１つをマウスでクリックすることにより、マネージメントコンソールのユーザは、管理されるネットワークの１つを選択することができる。
【００７１】
図５は、図４を参照して上述したようにマネージメントコンソールのユーザがネットワークの１つを選択した後に表示されるスクリーンを示す。このスクリーンから、ユーザは、種々のツールを使用してネットワークの状態を見るか、又はクライアントコンピュータをリモートネットワークと一時的にブリッジするＲＩＧの能力を使用して、デスクトップ共有アプリケーションを使用し又はマネージメントアプリケーションを実行する。デフォールトにより、このビューは、ここに示す実施形態では、選択されたネットワークに対するイベントの概要、このケースでは、ＨＨＲ（５１１）を表示する。この表示のコンテンツは、上述した「発行・署名」メカニズムを通して与えられる。コンテンツは、ダイナミックであり、リアルタイムで連続的にリフレッシュする。右上パネル５０３のメインメニュー５３０においてアイコン５３１、等をクリックすることにより、パネル５０２とで複数の他の表示をスワップすることができる。又、ビュー(View)ボタン５３２をクリックし、次いで、「概要(Summary)」（５４１）をクリックすることにより、図示されたイベント概要表示に到達することもできる。リストされたイベントライン５６１、等は、当該装置の「最大アラート(Max Alert)」レベルに対応して、各々カラーコード化される。この最大アラートは、装置の依存性レベルにおける最高アラートレベルを意味する。各イベントに対して、時間表示５７１、レポートされている装置に対してローカルと特定される“ｔｅｘｔ＿ｔｉｍｅ”表示５７２、イベント形式を特定するｅｖｅｎｔＩｄ５７３、この図ではｓｕｂＤｅｖｉｃｅＮａｍｅ５７４と称されるローカル装置名、この図ではｄｅｖｉｃｅＮａｍｅ５７５と称されるネットワーク（ネットワークが上流ＲＩＧ又はＣＰＩへの「装置」であるために）、及び他の情報が存在する。この実施形態では、イベントは、もし可能であれば「合併」される。これは、連続する良好なピン(ping)のような「合併可能」と考えられるイベントが、表示を新たなイベントでクラッター化するのではなく、それらの更新された時間及び図示された以前のイベント時間だけを有することを意味する。このようなケースでは、先行する合併イベントの時間に対してｌａｓｔ＿ｔｅｘｔ＿ｔｉｍｅ５７７にエントリーが存在する。概要５４１で始まるパネル５０３におけるアイテムの行は、以下に述べる多数の表示を含む他の表示へのリンクである。
【００７２】
図６は、同時に監視されている複数の異種ネットワークの１つにおいてイベントを監視するためのマネージメントコンソールスクリーンを示す。特定の顧客ネットワークが選択されると、図５の右側パネル５０４は、トップコントロールバー５０３と、このコントロールバーからユーザにより選択されたコンポーネントビューを含むスペース５０４の下部スクリーンとを表示する。ユーザは、（例えば）メインメニュー５３０から「ビュー(View)」５３２を選択し、次いで、サブメニュー５４０から「イベント(Event)」５４２を選択し、そしてイベントビューア(Event Viewer)コンポーネントは、パネル５０４のコンポーネントビュー区分において「概要ビュー(summary view)」に置き換わる。マネージメントシステムは、多数の管理されるネットワークにおけるイベントに署名するが、図６は、１つの特定の顧客ネットワーク（“ＨＨＲ”５１１）に限定された表示を示している。図６に示すイベントリストは、ダイナミックであり、図２に示す方法により、リアルタイムで自動的に更新する。「フィルタ」要素６０５は、いずれかの列に現れるキーに基づいて迅速なフィルタを可能にする全列フィルタである。上部の表示パネル６０３は、まだ確認されていないイベントのリストを含み、各々、時間６６１、ｅｖｅｎｔＩｄ６７３、ローカル装置名（ｄｅｖｉｃｅＮａｍｅ）６７４、もし影響があれば、サービス６７８、もしあれば、関連エージェントＩＰアドレス（ａｇｅｎｔＩｐ）６７９、及び他の情報を含む。下部区画６０４は、ここでは６時間として示されたドロップダウンコントロール６９１により調整可能な時間範囲において全てのイベントのリストを示す。パネル６０３及び６０４（並びに同様の他の表示）における列は、ＧＵＩコントロールにより左右に移動することができる。最も左の列は、リストのためのソートキーとして働く。デフォールトにより、ソートキーは、時間列である。
【００７３】
図７は、管理されるシステムにおけるポート使用量の表示を時間の関数として示す「システムモニタ」型グラフ表示である。図５に示すモニタリンク５４３からこのスクリーンに到達することもできる。表示は、この場合も、図２に示す方法により、リアルタイムで右から更新されて、右から左へとスクロールする移動グラフとして現れる。この特定の表示は、１２時間という選択された時間範囲（ドロップダウンコントロール７９１当たり）にわたり装置のスロット１におけるポート８の使用を示す。Ｙ軸７５１は、ビット／秒である。下部パネル７０５及び７０６は、現在ビュー（７０３、７０５）が長い時間線に適合する場合を示している。又、ビュー時間フレームは、パネル７０５及び７０６におけるクリック・ドラグアクションにより調整することもできる。或いは又、この例示において半透明のウインドウに表示されるレポートされるビット／秒の数字７０９、等は、曲線に重畳しないように、ダイナミック表示曲線が開始する場所の右に表示されてもよい。
【００７４】
図８は、ネットワークマップ及び要素の表示を含めて、管理されるネットワークの「ダッシュボード」ビューを示す例示的スクリーン表示である。左側パネル８０１は、ネットワークマップを示すもので、線８２１、８２２、等は、通信及びコントロールの線を示す。このケースでは、ＣＭ８３１は、ローカルサバイバブルプロセッサ（ＬＳＰ）８４１、８４２、等に接続されて示されている。このＬＳＰ８４１、８４２、等は、ＣＭ８３１がディスエイブルされるか又は接続を失った場合にそれら自体の制御を想定するようにプログラムされる。このようなイベントにおいて、ＣＭ８３１に通常接続される上流ＲＩＧ（図示せず）は、ＬＳＰ８４１、８４２、等へ直接取り付けられ、ＣＭ８３１からの以前のコントロールライン８２２、等は、消える。図８の右側パネル８０２は、トップレベルネットワーク要素（各々が依存性ツリーである）を、その状態のためのアイコンと共に示している。右側の表示パネル８０２の底部に沿ったリンク８５１、８５２、等は、パネル８０２のための他の「ダッシュボード」表示へのリンクであるか、それら自身のウインドウに表示されるリンクで、その各々は、監視されるネットワーク（１つ又は複数）に関する集中した高レベルのリアルタイム情報のパネルを与える。
【００７５】
図９は、中央通信マネージャー（ＣＭ）プロセッサに対する健全性メトリックを示す例示的スクリーン表示である。これは、図８のプロセッサリンク８５４から選択することができる。これは、パーセントプロセッサアイドル（９６１）、パーセントプロセッササービスメンテナンス（９６２）、電話コールに対するパーセントプロセッサ使用（９６３）及び他の情報を示す。
【００７６】
図１０は、電話トレースルートをＱＯＳ表示と共に示す例示的スクリーン表示である。図５における電話ＱＯＳ５４５をクリックし、次いで、電話をリストする中間スクリーン（図示せず）上の「トレース」をクリックすることで、このスクリーンに到達することができる。この電話リストのエントリーをダブルクリックすると、図１１に示す表示が現れる。図１０は、全ての電話に対するグラフィックトレースルート図である。電話は、フィルタコントロール１００５を通してフィルタリングすることができる。各トレースルート１０４１、１０４２、等の線は、パケットロス、ラウンドトリップ遅延及び到着間ジッタの関数である（この技術でよく知られた方法により計算された）現在のサービスクオリティ（ＱＯＳ）に基づいて色が変化する。
【００７７】
図１１は、ラウンドトリップ遅延１１５１、パケットロス１１５２ａ及び１１５２ｂ、並びにジッタ１１５３ａ及び１１５３ｂを含む１つの電話トレースルートのＱＯＳを詳細に示す例示的スクリーン表示である。ジッタ及びパケットロスの上部及び下部表示１１０３及び１１０４は、トレースされるルートの各端（例えば、メディアプロセッサ及び電話）における対応メトリックを表す。
【００７８】
図１２は、ポリシー設定モジュールを示す例示的スクリーン表示である。「ポリシー」は、イベントに基づく標準的アクション、例えば、レポート、イベントハンドリング、等をトリガーするために導入することができる。ポリシーは、フローチャートとしてプログラムされ、スクリプトの性質で機能する。ポリシーは、表示パネル１２０３においてマウスにより（図示された例では、右クリックアクセス可能メニューにより）アクセスできるＧＵＩコントロールを通して構築される。生成された各ポリシーは、パネル１２０２にリストされる。このスクリーンは、図４における設定タブ４１９から到達する（Ｓｅｔｕｐ→Ｐｏｌｉｃｙ）。表示されたフローチャート１２１０に示すポリシーは、「仮想」拡張への電話記録のためのものである（メッセージの記録のために物理的な電話が必要とされないので）。このポリシーは、“ＩＦ”条件１２１１、１２１２ごとに、イン・サービス／オン・フック又はイン・サービス／オフ・フックの状態が観察されない限りある範囲の仮想拡張に対する欠陥を表すイベントをキャンセルするために新たなイベントを発生し、そのようなケースでは、イベントがキャンセルされる。このポリシーは、ソフトホン欠陥に対してアクティブなイベントのリストをスキャンさせ、そしてソフトホンがフェイルしたかどうか調べるためにチェックを行う。もしそうでなければ、「フェイルした」イベントをキャンセルするために新たなイベントを送信する。従って、各ポリシーは、それが確立されると、図２を参照して説明したプロトコルにより、リアルタイムで監視されるイベントに基づいて、その特定の条件を連続的に強いる。
【００７９】
図１３は、サービスレベルモニタを示す例示的なスクリーン表示である。図５におけるビューリンク５３２でスタートするＶｉｅｗ→Ｓｅｒｖｉｃｅレベルをクリックすることによりこの表示に到達することができる。図１３の表示は、個別のウインドウ又は図５のパネル５０４に現れる。図１３は、コントロール１３９１により選択可能な時間フレームにわたる現在サービスレベル（１３１１）、（コントロール１３９２ごとの）時間範囲にわたる監視サービスレベルのローリング平均表示１３１２、及び他の情報を示している。この場合も、この表示は、監視されるネットワーク（１つ又は複数）及びリソース（１つ又は複数）のためのサービスレベルをリアルタイムでダイナミックに示す。
【００８０】
図１ないし３を参照して上述した技術を組み入れた図４ないし１３に示すオペレーション例は、そのようなシステムが過去に提供されるのを妨げていた障害、例えば、アドレスの衝突、実質的なネットワーク変更又は望ましからぬ付加的なインフラストラクチャーなしに構成ネットワーク内でルーティングできないこと、リモートネットワーク測定及び観察から生じるアーティファクト、及び管理される各ネットワークへの連続接続の欠如から生じる知識のギャップ、を克服するように、イベントを見、及び／又は複数の異種ネットワークを集合的に又はそれらの１つを個々に管理できるサービスの形態で提供される本発明の目的による収斂型モニタリング及びマネージメントプラットホームを完全に実現することが明らかであろう。
【００８１】
以上、本発明を詳細に説明したが、当業者であれば、種々の変化、置き換え、及び変更が容易に明らかであり、且つ特許請求の範囲に規定された本発明の精神及び範囲から逸脱せずにそれらがなされることを理解されたい。
【符号の説明】
【００８２】
１０１、１０２、・・・１０ｘ：ネットワーク
１１０、１３０：ＲＩＧ
１１１、１１２、１１３：位置
１２０：データセンター
１２１、１２２、１２ｘ：接続
２０１、２０２、２０３：チャンネルマスターインスタンス
２２１：チャンネル接続
２２２、２２５、２２６：チャンネル接続
２３１、２３２：ＣｏｍＳｔｒｕｃインターフェイス
２４１、２４２：コマンドラインインターフェイス
２５１、２５２：ＣＳｏｋｅｔ
【特許請求の範囲】
【請求項１】
モジュール化されたソフトウェアシステム内でコマンドをルーティングする方法において、
（ａ）起点ノードからターゲットノードまでのルートを、前記ターゲットノードに到達するために前記ルートにおける次々のアドレスを通る複数のリンクを特定することをサポートするプロトコルを使用して、明確に又は暗示的に特定するステップと、
（ｂ）前記ターゲットノードにおいて実行されるべきコマンドを特定するステップと、
（ｃ）前記ルート及びコマンドをパラメータとしてソケットを呼び出すステップと、
（ｄ）前記ルートに基づいて前記コマンド及びパラメータをルーティングするステップと、
（ｅ）前記ターゲットノードにおいて前記コマンドをそのパラメータと共に実行するステップと、
（ｆ）前記実行の結果を、前記ルートを通して前記起点ノードへ返送するステップと、
（ｇ）前記実行が完了したときに前記ルートを閉止するステップと、
を備えた方法。
【請求項２】
前記ルートは、前記ターゲットノードのアドレスを含む一連のアドレスを備え、前記コマンドは、前記ターゲットノードにおいて実行するために前記アドレスにおいて各ネットワークファシリティを繰り返し通過する、請求項１に記載の方法。
【請求項３】
前記コマンドは、コンテナ及びコマンドのハイアラーキーの一部分である、請求項１に記載の方法。
【請求項４】
前記ルートのリンクは、別のプロトコルを経てトンネル接続される、請求項１に記載の方法。
【請求項５】
前記別のプロトコルは、ＳＳＬである、請求項１に記載の方法。
【請求項６】
モジュール化されたソフトウェアシステム内でコマンドをルーティングするシステムにおいて、
（ａ）起点ノードからターゲットノードまでのルートを、前記ターゲットノードに到達するために前記ルートにおける次々のアドレスを通る複数のリンクを特定することをサポートするプロトコル、及びコマンドを使用して、暗示的に又は明確に特定し、そして前記ルート及びコマンドをパラメータとしてソケットを呼び出すアプリケーションと、
（ｂ）特定されたルートをオープンチャンネル接続とマッチングすることによりルートを設定するチャンネルマスター、及び
チャンネル接続であって、ルートの残部（そのチェンネル接続に到達するために使用されるルートの部分より少ない）及びコマンドを別のチャンネル接続に通信するようなチャンネル接続、
を各々含む１つ以上のランタイムインスタンスと、
（ｃ）コマンドを実行する前記インスタンスの最後の１つの中のターゲットノードであって、前記インスタンスの前記最後の１つは、前記コマンドパラメータに先行するルートパラメータがないときに到達されるとみなされるようなターゲットノードと、
を備えたシステム。
【請求項７】
監視及び管理の動作サポートを実行するために段落１１の前記システムによって与えられるルーティング機能を使用する動作サポートシステムを更に備えた、請求項６に記載のシステム。
【請求項１】
モジュール化されたソフトウェアシステム内でコマンドをルーティングする方法において、
（ａ）起点ノードからターゲットノードまでのルートを、前記ターゲットノードに到達するために前記ルートにおける次々のアドレスを通る複数のリンクを特定することをサポートするプロトコルを使用して、明確に又は暗示的に特定するステップと、
（ｂ）前記ターゲットノードにおいて実行されるべきコマンドを特定するステップと、
（ｃ）前記ルート及びコマンドをパラメータとしてソケットを呼び出すステップと、
（ｄ）前記ルートに基づいて前記コマンド及びパラメータをルーティングするステップと、
（ｅ）前記ターゲットノードにおいて前記コマンドをそのパラメータと共に実行するステップと、
（ｆ）前記実行の結果を、前記ルートを通して前記起点ノードへ返送するステップと、
（ｇ）前記実行が完了したときに前記ルートを閉止するステップと、
を備えた方法。
【請求項２】
前記ルートは、前記ターゲットノードのアドレスを含む一連のアドレスを備え、前記コマンドは、前記ターゲットノードにおいて実行するために前記アドレスにおいて各ネットワークファシリティを繰り返し通過する、請求項１に記載の方法。
【請求項３】
前記コマンドは、コンテナ及びコマンドのハイアラーキーの一部分である、請求項１に記載の方法。
【請求項４】
前記ルートのリンクは、別のプロトコルを経てトンネル接続される、請求項１に記載の方法。
【請求項５】
前記別のプロトコルは、ＳＳＬである、請求項１に記載の方法。
【請求項６】
モジュール化されたソフトウェアシステム内でコマンドをルーティングするシステムにおいて、
（ａ）起点ノードからターゲットノードまでのルートを、前記ターゲットノードに到達するために前記ルートにおける次々のアドレスを通る複数のリンクを特定することをサポートするプロトコル、及びコマンドを使用して、暗示的に又は明確に特定し、そして前記ルート及びコマンドをパラメータとしてソケットを呼び出すアプリケーションと、
（ｂ）特定されたルートをオープンチャンネル接続とマッチングすることによりルートを設定するチャンネルマスター、及び
チャンネル接続であって、ルートの残部（そのチェンネル接続に到達するために使用されるルートの部分より少ない）及びコマンドを別のチャンネル接続に通信するようなチャンネル接続、
を各々含む１つ以上のランタイムインスタンスと、
（ｃ）コマンドを実行する前記インスタンスの最後の１つの中のターゲットノードであって、前記インスタンスの前記最後の１つは、前記コマンドパラメータに先行するルートパラメータがないときに到達されるとみなされるようなターゲットノードと、
を備えたシステム。
【請求項７】
監視及び管理の動作サポートを実行するために段落１１の前記システムによって与えられるルーティング機能を使用する動作サポートシステムを更に備えた、請求項６に記載のシステム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【公表番号】特表２０１１−５３０１１５（Ｐ２０１１−５３０１１５Ａ）
【公表日】平成２３年１２月１５日（２０１１．１２．１５）
【国際特許分類】
【出願番号】特願２０１１−５２１３０８（Ｐ２０１１−５２１３０８）
【出願日】平成２１年７月３０日（２００９．７．３０）
【国際出願番号】ＰＣＴ／ＵＳ２００９／０５２２０４
【国際公開番号】ＷＯ２０１０／０１４７８０
【国際公開日】平成２２年２月４日（２０１０．２．４）
【出願人】（５１１０２６８６５）ジュマ テクノロジー コーポレイション (4)
【Ｆターム（参考）】
【公表日】平成２３年１２月１５日（２０１１．１２．１５）
【国際特許分類】
【出願日】平成２１年７月３０日（２００９．７．３０）
【国際出願番号】ＰＣＴ／ＵＳ２００９／０５２２０４
【国際公開番号】ＷＯ２０１０／０１４７８０
【国際公開日】平成２２年２月４日（２０１０．２．４）
【出願人】（５１１０２６８６５）ジュマ テクノロジー コーポレイション (4)
【Ｆターム（参考）】
[ Back to top ]