(57)【要約】【課題】ネットワーク発見用の拡張可能システムを提供する。【解決手段】ネットワークシステム（１００）は、情報を識別し、情報の消費を可能にし、且つ、情報を消費する発見サブシステム（１０２）を備える。当該発見サブシステム（１０２）は、モジュール形式のドメイン固有コンテンツ（１０８）と、ドメイン固有コンテンツ（１０８）を規格化すると共に、デバイス（１２２）から独立してドメインコンテンツを一意に定義する属性（１１２）及び値タイプ（１１４）を記述するためのデータ定義（１１０）とを使用して、ビジネスコンテンツ（１０４）及びデバイス固有ロジック（１０６）を分離する。【選択図】図１Ａ
2008287699.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークシステム（１００）であって、
情報を識別し、情報の消費を可能にし、情報を消費する発見サブシステム（１０２）
を備え、
前記発見サブシステムは、モジュール形式のドメイン固有コンテンツ（１０８）と、前記ドメイン固有コンテンツ（１０８）を規格化すると共に、デバイス（１２２）から独立してドメインコンテンツを一意に定義する属性（１１２）とタイプ（１１４）を記述するためのデータ定義（１１０）とを使用して、ビジネスコンテンツ（１０４）とデバイス固有ロジック（１０６）を分離するように構成されている
ネットワークシステム。
【請求項２】
ネットワークシステム（１００）であって、
ドメイン固有コンテンツ（１０８）を規格化すると共に、データが収集される特定のデバイスから独立して一般的に抽象化されるビジネスロジック（１１８）に専用化されているコンテンツジェネリックプロセッサ（１１６）の作成を可能にする前記発見サブシステム（１０２）
をさらに備える請求項１に記載のネットワークシステム。
【請求項３】
ネットワークシステム（１００）であって、
前記発見サブシステム（１０２）であって、
少なくとも１つのデータ定義（１１０）によって指定される通りにデバイス（１１８）からデータを収集するように構成されているデータコレクタ（１２０）と、
要求されたデータの要請を前記データコレクタ（１２０）に発行するように構成されているコンテンツマネージャ（１２４）と
を備える前記発見サブシステム
をさらに備える請求項１に記載のネットワークシステム。
【請求項４】
ネットワークシステム（１００）であって、
コレクタマッピングルール（１２８）に従ってデータをハンドリングする前記データコレクタ（１２０）をさらに備え、
前記コレクタマッピングルール（１２８）は、
指定されたデータ定義（１１０）のデバイス固有ルール（１３２）を選択するようになっている少なくとも１つのフィルタ（１３０）と、
複数のプロトコルでデータを通信するようになっている少なくとも１つの通信インターフェース（１３４）と、
選択された属性（１１２）及び優先順位に従ってデータを収集するようになっているオプションハンドラ（１３６）と、
デバイスの管理情報ベースの異なるテーブル（１４０）から収集されたデータを単一のデータ定義にマージするようになっているマージハンドラ（１３８）と、
選択されたフォーマットでマッピングルール（１２８）を定義する少なくとも１つの構成ファイル（１４２）と
を含む請求項３に記載のネットワークシステム。
【請求項５】
ネットワークシステム（１００）であって、
コンバータ（１４４）に従ってデータをハンドリングする前記データコレクタ（１２０）であって、
収集されたフォーマットから、規格化されたデータ定義フォーマットへデータを変換するようになっているデータコンバータ（１４６）と、
収集されたデータ属性を解析して複数のデータ構成要素を推定するようになっているパーサ（１４８）と、
少なくとも１つの収集されたデータ値を結合して単一の推論されたデータ値を推定するようになっているアキュムレータ（１５０）と
を備える前記データコレクタ
をさらに備える請求項３に記載のネットワークシステム。
【請求項６】
ネットワークシステム（１００）であって、
コレクタマッピングルール（１２８）及びコンバータ（１４４）に従ってデータをハンドリングして、生のデバイスデータを収集し、規格化されたデータ定義を前記コンテンツマネージャに返すように構成されている前記データコレクタ（１２０）
をさらに備える請求項３に記載のネットワークシステム。
【請求項７】
ネットワークシステム（１００）であって、
データ定義に基づくデータ収集と前記データが収集された時のコールバックを可能にする非同期アプリケーションプログラムインターフェース（ＡＰＩ）を作成するように構成されている前記データコレクタ（１２０）
をさらに備える請求項３に記載のネットワークシステム。
【請求項８】
ネットワークシステム（１００）であって、
前記発見サブシステム（１０２）であって、
データ定義（１１０）をロードすることと、
特定のデータ収集要求のデータ定義を突き止めることと、
ｓｅｔオペレーション及びｇｅｔオペレーションを使用してデータ定義テーブルを操作することと、
データタイプを変換することと
を含む
データ定義を管理するように構成されているデータ定義マネージャ（１５２）  をさらに備える前記発見サブシステム
をさらに備える請求項３に記載のネットワークシステム。
【請求項９】
ネットワークシステム（１００）であって、
複数のデータ定義を同時に要求するようになっているコンテンツプロセッサ（１１６）の作成を可能にするように構成され、
前記コンテンツプロセッサへの規格化されたデータ及びフィードバックを集めて、データ収集性能を改善するように構成されているデータコレクタ（１２０）
を備える前記発見サブシステム（１０２）
をさらに備える請求項１に記載のネットワークシステム。
【請求項１０】
製品であって、
ネットワーク発見を自動的に行うための計算可能な可読プログラムコードが具現されるコントローラ使用可能媒体であって、
前記計算可能な可読プログラムコードは、
前記コントローラに、ネットワークデバイスから発見されるデータをドメイン固有コンテンツにモジュール化させるようになっているコードと、
前記コントローラに、規格化されたデータ定義によって前記ドメイン固有コンテンツを定義させるようになっているコードと、
前記コントローラに、前記モジュール化されたドメイン固有コンテンツ及び前記データ定義に従ってビジネスコンテンツ及びデバイス固有ロジックを分離させるようになっているコードと
をさらに備えるコントローラ使用可能媒体
を備える製品。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施の形態は、ネットワーク発見用の拡張可能システムに関する。
【背景技術】
【０００２】
ネットワーク管理市場は、多くのさまざまなベンダによって供給される多数のデバイスによって支えられ、市場におけるベンダの広がり及びデバイスの奥行きをサポートするネットワーク発見システムの課題を生み出している。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
本発明は、ネットワーク発見のための拡張可能システムを提供する。
【課題を解決するための手段】
【０００４】
ネットワークシステムの一実施の形態によれば、発見サブシステムは、情報を識別し、情報の消費を可能にし、且つ、情報を消費する。当該発見サブシステムは、モジュール形式のドメイン固有コンテンツと、ドメイン固有コンテンツを規格化すると共に、デバイスから独立してドメインコンテンツを一意に定義する属性及び値タイプを記述するためのデータ定義とを使用して、ビジネスコンテンツ及びデバイス固有ロジックを分離する。
【０００５】
オペレーションの構造及び方法の双方に関するこの発明の実施形態は、以下の説明及び添付図面を参照することによって最も良く理解することができる。
【発明を実施するための最良の形態】
【０００６】
ネットワーク発見のためにコンテンツ及び／又はデバイスの拡張性をサポートするロバストなフレームワークを形成するネットワークシステムが開示される。
【０００７】
例示したネットワーク発見システムは、リードタイムが削減又は最小化されることに関しては効率的に新興のベンダ及び／又はデバイスをサポートするように拡張可能である。このネットワーク発見システムは、ビジネスコンテンツとデバイス固有ロジックとの間の従来の依存関係を断つロバストなフレームワークを可能にし、ビジネスコンテンツ及びデバイス固有ロジックをプラグインするテンプレート及びデフォルトの振る舞いを形成する。作成されたフレームワークによって、新しいデバイスのサポートが可能になり、既存のネットワーク発見システムの機能が、迅速、単純、且つ容易に拡張される。この拡張可能なフレームワークによって、発見システムの品質及び保守性の改善が可能になる。
【０００８】
例示したネットワーク発見システム及び方法は、ネットワークに接続された既存のデバイスのコンテンツのハンドリングを可能にするだけでなく、ネットワークに追加される新しいデバイスのコンテンツのハンドリングも可能にして、さまざまなデバイスをサポートする。例示したネットワーク発見システム及び方法は、可能な限り効率的にコンテンツの処理を駆動する。
【０００９】
ネットワークドメインの問題は、ネットワークに接続できるデバイスのタイプ及びモデルが多いということである。デバイスのプロトコルは厳密に定義されている。新しいタイプのコンテンツが発見されると、従来のシステムでは、その新しいコンテンツのハンドリングを可能にするために、大幅な変更が当然のごとく行われる。多くの場合、新しいコンテンツについて、データ収集のタイプは異なる可能性がある。新しいコンテンツは、デバイス固有の細部のために、抽象化したものを個々のビジネスデータに導入する可能性がある。新しいデバイスの発見についての新しいプロトコルを追加することによって、信頼性及び品質の問題が引き起こされる可能性がある。
【００１０】
例示したネットワーク発見システム及び方法は、ビジネスロジックを、モジュール形式であり且つデバイスではなくコンテンツに固有の独立した部分に抽象化することによって新しいデバイスのネットワークへの接続に対する高速な応答を可能にする。したがって、新しいデバイスのサポートを動的に実施することができる。
【００１１】
たとえばネットワークノード管理システムに、例示したネットワーク発見機能がない場合、一部の理由として、ビジネスコンテンツ及びデバイス固有ロジックが、エンドツーエンド発見処理を通じて密に且つ広範囲に結合されるという理由から、新しいコンテンツ及び／又は新しいデバイスのサポートは大掛かりなものとなる。新しいデバイスサポートが追加されると、多くのコンポーネントは、さまざまな場所で影響を受け、デバイスの拡張が困難になり、製品品質のリスクがもたらされ、保守コストが増加する。例示したネットワーク発見システム及び動作方法は、ビジネスコンテンツと対応するデバイス固有ロジックとの間の密結合を断つ新しいフレームワークを作成する。ビジネスコンテンツ又はデバイス固有ロジックに対する変更は分離されている。上述したフレームワークでは、新しいコンテンツ又はデバイスは、独立して拡張することができる。開発者は、容易にサンプルテンプレートに従って、コンテンツ又はデバイス固有ロジックを拡張することができる。フレームワークは、拡張されたビジネスコンテンツ及びデバイスをランタイムで動的に組み合わせ、新しいデバイスを拡張する能力を改善するだけでなく製品品質も改善する。
【００１２】
例示したネットワーク発見機能がない場合、ビジネスコンテンツとデバイス固有ロジックとの間の明確な区別が存在しないことから、新しいデバイスをサポートするために、開発者は、多くの異なるロケーションで変更を行う。このような変更によって、開発者には、後方非互換性を回避するために、広範囲の試験と共に製品全体の広範囲な知識を有することが必要とされる。開発者によって実装された新しいコードの小さなバグは、製品全体を崩壊させる可能性がある。
【００１３】
例示したネットワーク発見システム及び方法は、ビジネスコンテンツ(Business Content)とデバイス固有(Device Specific)ロジックとの間の依存関係を断ち、新興のネットワーク(Network)デバイス及びコンテンツを発見するためのサポートを促進するロバストなフレームワークを作成する能力を導入する。このフレームワークは、新しいコンテンツの追加が他の既存のコンテンツに影響を与えないのでロバストである。
【００１４】
例示したネットワーク発見システム及び方法は、ビジネス固有であるコンテンツ(Content)プロセッサ及びよりデバイス固有であるデータコレクタ(Data Collector)を導入して、ユーザが、コンテンツ及びデバイスを個別に拡張することを可能にする。ほとんど場合、コンテンツは、比較的安定しており、通例、更新されるのは稀である。ユーザは、何らコーディングすることなく、たとえば新しいコレクトマッピングルール(Collect Mapping Rule)を追加することによって、より多くのデバイスをサポートするようにデータコレクタを簡単に拡張することができる。また、ユーザは、特定のデータ収集状態を満たすようにコンバータ(Converter)及びコレクトマッピングルールをカスタマイズすることもできる。その結果、例示したネットワーク発見システム及び方法は、新しいコンテンツ及び／又はデバイスの状態を拡張する能力を大幅に改善することができる。あらゆる拡張サポートが骨の折れる試みであるこれまでのシステムに対して改善されている。
【００１５】
例示したネットワーク発見システム及び方法は、すべてのコンテンツ及び／又はデバイスのソリューションを自動的に統合することができ、或るアーティファクト又はソリューションにおける障害がシステム全体を崩壊しないようにソリューションのアーティファクトから障害を分離することもできる。したがって、例示した発見システムは、よりロバストで且つスケーラブルであり、保守性を高め、したがって、製品サポートコストを大幅に削減する可能性を生み出す。デバイスサポートは、たとえば、新しいデバイスの追加に対する迅速な応答を可能にする抽象化定義及びデバイスサポート行列の実施によって改善され、これによって、追加されたデバイスの市場化の時間が削減される。
【００１６】
図１Ａ、図１Ｂ、及び図１Ｃを参照して、それぞれの基本的且つより詳細な概略ブロック図が、ネットワーク発見を実施するネットワークシステム１００の実施形態を示している。ネットワークシステム１００は、発見サブシステム１０２を備える。この発見サブシステム１０２は、情報を識別し、情報の消費を可能にし、情報を消費する。発見サブシステム１０２は、モジュール形式のドメイン固有コンテンツ１０８及びデータ定義１１０を使用して、ビジネスコンテンツ１０４とデバイス固有ロジック１０６とを分離するように構成されている。データ定義１１０は、ドメイン固有コンテンツ１０８を規格化し、デバイス１２２とは独立にドメインコンテンツを一意に定義する属性１１２及び値タイプ１１４を記述するためのものである。
【００１７】
１つの例示的な実施形態では、ネットワークシステム１００は、４つのコンポーネント、具体的には、コアインフラストラクチャ(Core Infrastructure)１５４、コンテンツプロセッサ(Content Processor)１１６、データ定義(Data Definition)１１０、及びデータコレクタ１２０を含むように実施することができる。これらのコンポーネントは、疎結合されており、分離することができ、それによって、プラグアンドプレイの機能等の柔軟な機能が可能にされ、ロバスト性が増加される。
【００１８】
例示したネットワーク発見システム１００は、３つの基本コンポーネント：コンテンツ(Content)１０４、データ定義１１０、及びデータコレクタ１２０で構成することができる。これらのコンポーネントのそれぞれは、拡張可能とすることができ、コアコンポーネントからの対応するマネージャによって動的に管理することができる。トーカコンポーネント１５８は、オプションであるシステム１００の別の拡張可能な部分とすることができる。実際には、コンテンツ１０４は、０個から多数に至るデータ定義１１０をハンドリングすることができる。各データ定義は、適したトーカの個数に基づいて複数のコレクトマッピングルールを有することができる。
【００１９】
トーカ１５８は、特定の１つ又は複数のデバイスからデータを収集するデバイス又はシステムを抽象化したものである。ルールは、選択されたトーカが、指定された１つ又は複数のデバイスから情報を取得することを可能にするように指定することができる。たとえば、Smart Messaging Platform（ＳＭＰ）等のアプリケーションに準拠した特定のルールは、１つ又は複数のデバイスから情報を取得するように、指定されたトーカに指示する。また、ルールは、１つ又は複数のデバイスから収集されたコンテンツのデータ及びデータフォーマットを識別することもできる。このコンテンツは、製品固有性が高いものである。さらに、ルールは、アクセスされたコンテンツの変換を指定することもできる。
【００２０】
トーカ１５８は、ネットワーク上で情報を転送又は伝達するのに使用されるシステム又は方法とすることができる。「http://en.wikipedia.org/wiki/World_Wide_Web」トーカの例には、Hypertext Transfer Protocol（ＨＴＴＰ）、File Transfer Protocol（ＦＴＰ）、Simple Network Management Protocol（ＳＮＭＰ）等のベンダサポートプロトコル、Teletype Network（ＴＥＬＮＥＴ）、及び他の多くのものが含まれる。トーカ１５８を単独で使用することもできるし、複数のトーカを組み合わせて使用することもできる。トーカの機能は、特定のプロトコルデータコレクタが通信用の特定のプロトコルをどのように使用するかを指定するマッピングルールによって制御される。トーカは、プロトコルに準拠して動作し、例示したネットワーク発見システム及び方法は、マッピングルールに対する動的な変更を可能にして、柔軟性及びトラブルシューティングを容易にする。
【００２１】
コアインフラストラクチャ１５４は、システムにデプロイされ得る複数のコンテンツを扱い、システムの複数の部分が協力して動作できる同期方法論を可能にする。コアインフラストラクチャ１５４は、コンテンツプロセッサ１１６及びデータコレクタ１２０をリンクして、コンテンツプロセッサ１１６とデータコレクタ１２０との間におけるデータ定義１１０の通信を可能にする。ドメイン固有(Domain-specific)コンテンツ１０８ごとに個別のコンテンツプロセッサ１１６が存在し、デバイス固有(Device-specific)コンテンツ１５６ごとに個別のデータコレクタ１２０が存在するので、コンテンツプロセッサ１１６は、デバイスの障害又は異常な振る舞いを容易に分離することができる。或るコンテンツモジュール上の障害は、他のものに影響を与えないので、例示したアーキテクチャは、発見システム全体のロバスト性を大幅に改善する。
【００２２】
コンテンツプロセッサ１１６は、複数の要求が応答を待つことなく行われ、さらなるデータが処理される非同期通信をサポートすることができる。非同期通信パターンは、あらゆる新しいコンテンツプロセッサが、適した性能レベルを一貫して達成できることを確実にする。
【００２３】
ネットワークデバイス(Network Device)１２２から発見されるデータは、ドメイン固有コンテンツ１０８でモジュール化することができる。個々のドメイン固有コンテンツ１０８が、データ定義１１０と呼ばれる規格化構造によって定義される。データ定義１１０は、デバイスベンダ又はデバイスモデルから独立したドメインコンテンツ１０４を一意に定義する属性１１２及び値タイプ１１４のリストを含む。
【００２４】
発見サブシステム１０２によって、ドメイン固有コンテンツ１０８を規格化して、データが収集される特定のデバイスから独立して一般的に抽象化されるビジネスロジック１１８に専用化されたコンテンツジェネリックプロセッサ（content-generic processor）１１６の作成が可能になる。
【００２５】
コンテンツプロセッサ１１６は、データ定義１１０によって指定される通りに任意のデバイスからデータを収集することをデータコレクタ１２０に要求する。したがって、いくつかの実施形態では、発見サブシステム１０２は、１つ又は２つ以上のデータ定義１１０によって指定される通りにデバイスからデータを収集することができるデータコレクタ１２０を備える。ネットワークシステム１００は、要求されたデータ１２６を求める要請をデータコレクタ１２０に発行するように構成されたコンテンツマネージャ１２４をさらに備えることができる。コンテンツマネージャ１２４は、より一般的なデバイス基盤からデータベースオペレーションに機能をシフトする。したがって、コンテンツマネージャ１２４の機能は、特定のデバイスに依存しない。コンテンツマネージャ１２４は、データ定義１１０によって指定されたデータを収集することをデータコレクタ１２０に要求する。
【００２６】
データコレクタ１２０は、コレクタマッピングルール１２８に従ってデータ１２６をハンドリングすることができる。例示したネットワーク発見システム１００及び関連付けられた方法では、ルールは、デバイス基盤を有するのではなく、データに基づいている。コレクタマッピングルール１２８によって記述されたデータ１２６の例には、指定されたデータ定義１１０のデバイス固有ルール１３２を選択するようになっている１つ又は２つ以上のフィルタ１３０、複数のプロトコルでデータを通信するようになっている１つ又は２つ以上の通信インターフェース１３４、選択された属性１１２及び優先順位に従ってデータを収集できるオプションハンドラ１３６が含まれ得る。コレクタマッピングルール１２８によって扱われる追加データ１２６の例には、デバイス１２２の管理情報ベースの異なるテーブル１４０から収集されたデータを単一のデータ定義１１０にマージするようになっているマージハンドラ１３８、及び、選択されたフォーマットでマッピングルール１２８を定義する１つ又は２つ以上の構成ファイル１４２が含まれ得る。
【００２７】
フィルタ１３０は、マッピング法則を実施するのに使用することができ、どのマッピングルールを特定の問い合わせで実施するのかを選択する方法を定義する。コンテンツは、特定のフォーマットを有する。各デバイスモデルは、ネットワークに接続された他のデバイスによって直接アクセス可能である一意の識別情報を有する。コンテンツプロセッサは、通常はデバイスへの問い合わせにおいて物理識別子（ＩＤ）を指定することにより、データにアクセスする。試行されたコンテンツアクセスにおいて、フィルタが、システム識別子（ＳＹＳＩＤ）をマッピングルールに照合することができ、これによって、コンテンツへのアクセスを許可又は不許可にすることができる。
【００２８】
いくつかの実施形態では、データコレクタ１２０は、コンバータ１４４に従ってデータ１２６をハンドリングすることができる。コンバータ１４４は、たとえば、収集されたフォーマットから規格化されたデータ定義フォーマットへデータを変換するようになっているデータコンバータ１４６、収集されたデータ属性を解析して複数のデータ構成要素を推定するようになっているパーサ１４８、少なくとも１つの収集されたデータ値を結合して単一の推論されたデータ値を推定するようになっているアキュムレータ１５０、及び他のコンバータ等である。コンバータ１４４は、データ定義１１０に従ってデータを規格化する。
【００２９】
いくつかの実施態様又は実施形態では、データコレクタ１２０は、コレクタマッピングルール１２８及びコンバータ１４４に従ってデータをハンドリングして、生のデバイスデータを収集し、規格化されたデータ定義をコンテンツマネージャ１２４に返すように構成することができる。
【００３０】
データコレクタ１２０は、データ定義に基づくデータ収集及びデータが収集された時のコールバックを可能にする非同期アプリケーションプログラムインターフェース（ＡＰＩ）を作成するように構成することができる。
【００３１】
コンテンツマネージャ１２４は、特定の情報コンテンツを要求し、１つ又は２つ以上のデバイス又はポートからのコンテンツを動的に監視する。コンテンツマネージャ１２４は、集約ポート又は集約リンクからコンテンツにアクセスすることができる。コンテンツマネージャは、既存のコンタクトを動的に検索することができ、スパイ機能を有することができる。
【００３２】
ネットワークは、通常、非常に多くのデバイスを接続している。コンテンツマネージャ１２４は、ネットワークデバイスでサポートされるコンテンツのすべてのタイプを判断して、ネットワークに接続された個々のデバイスのコンテンツを発見して識別することができる。コンテンツマネージャ１２４は、分類に従ってデータにアクセスすることができ、デバイス属性、データ属性、デバイス、スケジュール番号、デバイス上のインターネットプロトコル（ＩＰ）アドレス、及びデバイスが属するサブネット等のさまざまな特徴に従ってデータを分類することができる。コンテンツマネージャ１２４は、さらに、レイヤ２コンテンツ、デバイス上のポート、コントローラ、プロセッサ、又は中央処理装置（ＣＰＵ）等の物理デバイス、及びそれ以外のものに従ってデータにアクセスしてデータを分類することができる。コンテンツマネージャ１２４は、特定のデバイスを、コンテンツ供給用にアクティブとして選択できる一方、他のデバイスをスタンバイモードに維持することができる。また、コンテンツマネージャ１２４は、或るデバイスのプロトコルと別のデバイスのプロトコルとの相違を求めることもでき、異なるフォーマットによるコンテンツの集約を可能にする。
【００３３】
いくつかの実施形態では、発見サブシステム１０２は、さらに、データ定義マネージャ１５２も備えることができる。データ定義マネージャ１５２は、オペレーションを通じてデータ定義１１０を管理するように構成されている。このオペレーションは、たとえば、データ定義をロードすること、特定のデータ収集要求のデータ定義を突き止めること、ｓｅｔオペレーション及びｇｅｔオペレーションを使用してデータ定義テーブルを操作すること、データタイプを変換すること等を含む。
【００３４】
データ定義マネージャ１５２は、たとえばデータを規格化することによって、データの抽象化を制御する。データ定義マネージャ１５２は、たとえば、データ定義の追加、変更、又は削除によってデータ定義を管理する。いくつかの実施形態では、eXtensible Markup Language（ＸＭＬ）を使用して、データ定義を指定することができる。ただし、他の構造を使用することもできる。データ定義は、コンテンツを抽象化したものである。個々のコンテンツは、コンテンツが収集されるデバイスから独立している１つ又は２つ以上のデータ定義を有することができる。データ定義は、１つ又は多数のコンテンツに関連付けられることができ、複数のタイプのコンテンツを可能にする。
【００３５】
データ収集マネージャ１２０は、マッピングルールを使用してコンテンツをデバイスにマッピングする詳細なロジックとして実施することができる。データ収集マネージャ１２０によって、データをどのように収集するのかを指定する複数の選択可能なオプションの使用が可能になり、また、それらのオプションを優先順位付けすることも可能になる。これらのオプションによって、複数のデバイスからデータを収集することが可能になる。データ収集マネージャ１２０によって、データ収集用の複数のオプションの指定が可能になり、問い合わせは、指定されたオプションに従って特定のデバイスへ送られる。デバイスについてのデータ収集が失敗した場合、データ収集マネージャは、その問い合わせを別のデバイスへ再び送ることができる。オプションは、コンテンツマネージャが問い合わせ及びデータを適切にハンドリングできるように、たとえば、要求のフォーマットを指定するか又はデータの規格化を指示することによって、問い合わせをデバイスにどのように送るのかを指定する。オプションは、データ変換が、特定の問い合わせについて必須であるのか又はオプションであるのかを指定することができる。データは、デバイス及び指定されたデータ定義に固有の方法で変換することができる。
【００３６】
個々のネットワークユーザ、デバイス、及びコンテンツは、通常、異なっている。データ収集マネージャ１２０は、それらの相違をハンドリングするようにコンテンツのアクティブ化及び非アクティブ化を円滑にする。
【００３７】
データ定義１１０は、コレクタマッピングルールを指定することができ、これによって、問い合わせで収集されるデータを定義することができる。コレクタマッピングルールは、１つ又は複数のデバイスのデータルールを指定するテーブルの行及び／若しくは列の名前又は他の指定と共に、テーブル名に従って実施することができる。マッピングは、デバイスごとに、データを獲得する選択された方法を定義することができる。Ciscoデバイスの例では、データ収集マネージャは、特定のデータに割り当てられたテーブル名及び列を指定することができる。例示したシステムでは、マッピングルールの変更、追加、及び削除が可能である。
【００３８】
いくつかのデバイスは、複数のタイプのデータをサポートすることができる。マッピング定義は、異なるデータタイプをどのようにハンドリングするのかを決定する。
【００３９】
或る形式から別の形式へのコンテンツの変換を可能にするようにコンバータ１４４を含めることができる。たとえば、或るデバイスについて、テーブルは、文字列フォーマットでデータを返す場合がある一方、要求は、異なるフォーマットでのそのデータの返還を指定する場合がある。コンバータは、コンテンツフォーマットの変換、データの分析、又は他のデータ表現への変更を行うことができる。コンバータ１４４は、さまざまな実施態様又はいくつかの状況ではオプションとすることができる。たとえば、特定の属性について、デバイスは、変換なしで一貫して機能することができる。コンバータ１４４は、通常、コンテンツが、要求側デバイスが受信すると予測したものとは異なるときに使用される。１つの例示的な実施形態では、コンバータは、通常、自動的に起動される。
【００４０】
データ収集マネージャ１２０のオペレーションの一例では、デバイスのコンテンツは特定のプロトコルに準拠することができ、異なるプロトコルを処理する別のデバイスによる使用のためにデバイスのコンテンツを要求することができる。たとえば、テーブル及びそのテーブルの列を指定して、異なるデバイスのデータを収集する方法を指定するコレクタマッピングルールを作成することができる。アクセスされるデータと所望のデータとは、フォーマットが異なる場合があり、そこで、コンバータを使用して適切なフォーマットでデータを返すことができる。
【００４１】
新しいデバイス及びコンテンツ構成が利用可能になると、データ収集マネージャ１２０によって、新しいコレクタマッピングルール及び変換の作成が可能になる。したがって、コレクタマッピングルールの使用によって、柔軟性が生み出され、システムの構造的態様を変更することなく、新しい機能が可能になる。
【００４２】
一例の発見方法論では、コンテンツ発見が指示されたデバイスは、デプロイされたコンテンツのリストを有する。要求側デバイスは、デバイスごとにコンテンツリストにアクセスすることができ、コンテンツリストを調べて、データ収集をトリガすることができ、システム識別子（ＳＹＳＩＤ）等の情報が返される。基本的な情報は、アクセスされると、デバイスのコンテンツごとに渡され、コンテンツマネージャ１２４に渡される。デバイスが或るタイプのコンテンツをサポートしていない場合、そのコンテンツを無視するマッピングルールが実施される。すべてのコンポーネントについて、コンポーネントの振る舞いを指定するテンプレートが供給される。テンプレートは、コンテンツマッピングルールの構造を定義し、データのデータ定義への規格化をサポートする。
【００４３】
発見サブシステム１０２によって、複数のデータ定義を同時に要求できるコンテンツプロセッサ１１６の作成が可能になる。データコレクタ１２０は、規格化されたデータ及びコンテンツプロセッサ１１６へのフィードバックを集めて、データ収集性能を改善する。
【００４４】
図２Ａ〜図２Ｊを参照すると、いくつかのフローチャートが、ネットワーク発見用の自動化された方法の実施形態を示している。例示したネットワーク発見方法２００は、図２Ａに示され、ネットワークデバイスから発見されるデータをドメイン固有コンテンツにモジュール化すること（２０２）、及び、規格化されたデータ定義によってドメイン固有コンテンツを定義すること（２０４）を含む。ビジネスコンテンツ及びデバイス固有ロジックは、モジュール化されたドメイン固有コンテンツ及びデータ定義に従って分離することができる（２０６）。
【００４５】
図２Ｂは、ネットワーク発見方法の一実施形態２１０を示している。ネットワーク発見方法２１０は、１つ又は２つ以上のネットワークデバイス上でデータを識別すること（２１２）、それによって、識別されたデータの消費を可能にすること（２１４）、次に、そのデータを消費すること（２１６）をさらに含むことができる。
【００４６】
図２Ｃは、ネットワーク発見方法の一実施形態２２０を示している。ネットワーク発見方法２２０は、ドメイン固有コンテンツを規格化すること（２２２）、及び、デバイスから独立してドメインコンテンツを一意に定義する属性及び値タイプを記述すること（２２４）をさらに含むことができる。
【００４７】
図２Ｄは、ネットワーク発見方法の一実施形態２３０を示している。ネットワーク発見方法２３０は、データが収集される特定のデバイスから独立して一般的に抽象化されるビジネスロジックに専用化されたコンテンツジェネリックプロセッサの作成を可能にすること（２３２）をさらに含むことができる。
【００４８】
図２Ｅを参照すると、ネットワーク発見方法の別の実施形態２４０は、１つ又は２つ以上のデータ定義によって指定されたデバイスからデータを収集すること（２４２）、及び、要求されたデータを求める要請をデータコレクタへ発行すること（２４４）をさらに含むことができる。
【００４９】
図２Ｆは、ネットワーク発見方法の一実施形態２５０を示している。ネットワーク発見方法２５０は、コレクタマッピングルールに従ってデータをハンドリングすること（２５１）、指定されたデータ定義のデバイス固有ルールを選択するようにデータをフィルタリングすること（２５２）、及び複数のプロトコルでデータを通信すること（２５３）をさらに含むことができる。データは、選択された属性及び優先順位に従って収集することができる（２５４）。デバイスの管理情報ベース（ＭＩＢ）の異なるテーブルから収集されたデータは、単一のデータ定義にマージすることができる（２５５）。マッピングルールは、選択されたフォーマットで定義される（２５６）。
【００５０】
データコレクタは、データ定義ごとのコレクタマッピングルール(Collector Mapping Rule)の拡張可能な概念及び要求側デバイスが期待するフォーマットにコンテンツを一致させる自動起動コンバータ１４４を用いる。
【００５１】
コレクタマッピングルールによって、いくつかの役立つ機能が可能になる。たとえば、特定のデータ定義用のデバイス固有ルールを選択するフィルタを構築することができる。コレクタマッピングルールによって、トーカは、Simple Network Management Protocol（ＳＮＭＰ）、Teletype Network（ＴＥＬＮＥＴ）、Hypertext Transfer Protocol（ＨＴＴＰ）、及びそれ以外のもの等の代替的なプロトコルを使用して、デバイスと通信することが可能になる。また、コレクタマッピングルールは、同じ属性を収集するためのデバイスの可能なオプション、及び、或るオプションを別のオプションよりも優先して考慮する優先順位をサポートすることもできる。さらに、マッピングルールによって、デバイスの管理情報ベースの異なるテーブルから収集されたデータを単一のデータ定義にマージすることを可能にすることもできる。他のルールは、eXtensible Markup Language（ＸＭＬ）フォーマットでマッピングルールを定義する構成ファイルをサポートする。
【００５２】
新しいデバイス及びコンテンツの発見の拡張可能なサポートを可能にするために、コンテンツプロセッサ、データコレクタ、及びデータ定義を実施する設計パターンが供給される。これらのパターンによって、サポート配信プロセスを促進できる標準インターフェース、抽象クラス、及びユーティリティの作成が可能になる。コア(Core)フレームワークは、新しいコンテンツサポートのアーティファクトを発見システムに自動的にスティッチする。
【００５３】
データコレクタに対しては限られた更新しか使用されないので、例示したネットワーク発見方法によって、非常に簡単化された方法で既存のコンテンツの新しいデバイスサポートが可能になる。このような更新は、構成ファイルにマッピングルールを追加すること、又は、デフォルトのコンバータがデータ変換の必要性を満たすことができない場合に、新しいコンバータをインストール又はプラグインすることと同じ最小限の動作によって行うことができる。
【００５４】
図２Ｇは、コンバータのオペレーションを含むネットワーク発見方法の一実施形態２６０を示している。コンバータは、収集されたフォーマットから規格化されたデータ定義フォーマットへのデータの変換、及び、単一の収集されたデータ属性を解析して複数のデータ構成要素を推定することを可能にする。１つまたは２つ以上の収集されたデータ値を処理して、単一の推論されたデータ値を推定することができる。また、コンバータは、コアインフラストラクチャとのより高度な相互作用も可能にする。したがって、ネットワーク発見方法２６０は、収集されたフォーマットから規格化されたデータ定義フォーマットへデータを変換すること（２６２）、収集されたデータ属性を解析して複数のデータ構成要素を推定すること（２６４）、及び１つ又は２つ以上の収集されたデータ値を結合して単一の推論されたデータ値を推定すること（２６６）をさらに含むことができる。
【００５５】
したがって、データコレクタは、マッピングルール(Mapping Rule)及びコンバータを用いて、生のデバイスデータを収集し、規格化されたデータ定義をコンテンツプロセッサに返す。
【００５６】
図２Ｈを参照すると、ネットワーク発見方法の別の実施形態２７０は、コレクタマッピングルール及びデータ変換に従ってデータをハンドリングすること（２７２）、生のデバイスデータを収集すること（２７４）、及び規格化されたデータ定義を返すこと（２７６）をさらに含むことができる。
【００５７】
図２Ｉは、データ定義に基づくデータ収集及びデータが収集された時のコールバックを可能にする非同期アプリケーションプログラムインターフェース（ＡＰＩ）を作成すること（２８２）をさらに含むことができるネットワーク発見方法の一実施形態２８０を示している。
【００５８】
図２Ｊを参照すると、ネットワーク発見方法の別の実施形態２９０は、データ定義を管理すること（２９２）をさらに含むことができる。データ定義管理オペレーションの例は、データ定義をロードすること（２９４）、特定のデータ収集要求のデータ定義を突き止めること（２９６）、ｓｅｔオペレーション及びｇｅｔオペレーションを使用してデータ定義テーブルを操作すること（２９８）、データタイプを変換すること（２９９）等を含むことができる。
【００５９】
図３を参照すると、概略ブロック図が、全体的な発見アーキテクチャ３０２におけるアナライザインフラストラクチャ３００の一実施形態のスナップショットを示している。発見サブシステムの他のコンポーネントは、アナライザインフラストラクチャの他の実施形態のさまざまな実施形態において追加することができる。
【００６０】
例示したアナライザインフラストラクチャ３００は、アナライザマネージャ(Analyzer Manager)３０４、アナライザ(Analyzer)３０６、コレクトマネージャ(Collect Manager)３０８、及びデータ定義マネージャ(DataDefinition Manager)３１０を含む４つのコンポーネントを備える。アナライザマネージャ３０４は、図１Ｂに示すコンテンツマネージャ１２４に対応し、アナライザ３０６は、図１Ｂに示すコンテンツプロセッサ１１６に対応する。ネットワーク管理システムで実施できるアナライザインフラストラクチャ３００の別のコンポーネントには、トーカ３１２が含まれる。通信プロファイラ３１４は、発見ターゲットの通信能力を表現するように動作し、ノードクラシファイヤ(Node Classifier)３１６とコレクトマネージャ３０８との間での共有コンポーネントとして構成することができる。
【００６１】
例示したアナライザマネージャ３０４は、アナライザ依存関係を指定する解析(Analysis)ブロック３１８、段階的アナライザ用のスレッドプール(ThreadPool)３２０、並びに計装（instrumentation）及びサポート性のためのMBean３２２を含む３つの主な機能を有する。１つの機能である高可用性は、アナライザマネージャ３０４又はコントローラ(Controller)３２４において実施することができる。インフラストラクチャ３００は、ドメインサービスをサポートするように実施することができる。
【００６２】
図４Ａを参照すると、クラス図が、解析３１８の一実施形態を示し、依存関係及び能率化された発見を管理するアナライザ３０６との相互作用を記述している。図４Ｂは、ノードを解析するための一例の技法を記述する解析３１８の簡単なシーケンス図を示している。
【００６３】
アナライザマネージャ３０４の起動時に、解析マネージャ(Analysis Manager)３０４は、解析３１８を構築する初期化（ｉｎｉｔ）方法をコールする。この初期化方法は、次に、解析構成ＸＭＬファイルを読み込み、各アナライザ３０６のインスタンスを作成し、構成された依存関係に従ってIBasicAnalyzerにおける親／子関係を設定する。アナライザマネージャ３０４は、スタートポイントアナライザ（start point analyzer）を有するパイプラインエントリ(PipelineEntry)のインスタンスも作成する。スタートポイントアナライザは、他のアナライザと依存関係を有しない。
【００６４】
ノードがアナライザマネージャ３０４内をフローする時、アナライザマネージャ３０４は、解析３１８をコールして、ノードを解析するエントリーポイントを取得する。反復的に、アナライザマネージャ３０４は、すべてのスタートポイントアナライザをコールしてノードを解析する。アナライザ３０６が解析を完了すると、アナライザマネージャ３０４は、解析トラッカ(AnalysisTracker)４０４をコールして、ノードに関連付けられた解析のステータスを記録する。
【００６５】
可能なステータスは、SUCCEED、NODATA、EXCEPTION、及びIGNOREである。SUCCEEDステータスは、解析が成功して完了したことを示す。解析は、この解析に依存するパイプラインの下流側のアナライザに渡される。NODATAステータスは、たとえば、ノードがトーク応答に反応しないことから、必要なデータを取得できないことにより、解析が成功して完了していないことを示す。解析は、そのノードについて、その解析に依存するパイプラインの下流側のアナライザには継続しない。EXCEPTIONステータスは、解析中に捕らえられたすべての種類の例外を示す。解析は、そのノードについて、EXCEPTIONステータスの解析に依存するパイプラインの下流側のアナライザに継続しない。IGNOREステータスは、アナライザが、ノードをハンドリングせず、解析の開始時にフィルタリング除去されることを示す。各アナライザは、実際にデータを収集する前に、１つ又は複数のフィルタに対して動作能力を評価すべきである。
【００６６】
解析ステータスは、ノードが下流側アナライザの次のセットに渡されるべきか否かを判断するために、トラッカによって使用される。現在の解析が成功であり、子の依存関係にあるもの（the dependencies of a child）も成功して完了している状況では、解析は、パイプラインフローエンジン(PipelineFlowEngine)クラスへの呼び出しｎｅｘｔ（）内で子によってアクティブ化され得る。子が利用可能でない場合、解析は、そのノードに対して単に停止するだけである。
【００６７】
各アナライザについて、スレッドプールは、データ定義（複数可）に関係付けられたデータ収集動作を整列することによって、複数のステージに分割することができる。アナライザをどのように結合解除するのかに関する詳細な情報は、以下の階層的アナライザ(Staged Analyzer)の節でさらに説明される。各ステージは、アナライザインフラストラクチャの共有スレッドプールと並行して実行できるスタンドアロンのRunnableプロシージャとすることができる。スレッドプールユーティリティ(util)は、構成可能な初期最大プールサイズを有するスレッドプールのインスタンスを作成するのに使用することができる。スレッドプールには、無限キューを推奨することができる。
【００６８】
図５Ａを参照すると、概略ブロック図が、段階的アナライザ５００の一実施形態を示している。発見階層的アナライザ５００は、各アナライザをシーケンシャルなステージに分割することによるイベント駆動型設計パターンを使用する。各ステージは、図５Ａに示すように、データ要求又は／及びデータ処理イベントによって駆動される。データ定義（ＤＤ）及びノード解析情報は、解析全体が完全に完了するまで、解析フローを或るステージから別のステージへ駆動するイベントである。
【００６９】
図５Ｂは、段階的アナライザ５００のクラスの一実施形態を示している。新しいアナライザを実施するために、開発者は、インフラストラクチャクラスによって供給された共通の機能により容易にされたクラスエントリステージ(EntryStage)５０２、アナライザ、及びさまざまなプロセスステージ(ProcessStage)５０４（ｎ）にビジネスコンテンツを単に満たすだけである。インフラストラクチャは、ビジネスコンテンツを互いにシームレスにスティッチする。
【００７０】
図５Ｃを参照すると、ノード解析を処理するアナライザの簡単なシーケンス図が示されている。解析は、どのステージにおいても、成功又は失敗のいずれかで完了することができる。たとえば、アナライザは、ノードのタイプをハンドリングする資格を有し得ない場合、コレクトマネージャからデータを取得しなかった場合、又は他の予期せぬ例外の場合がある。これらの状況でも、アナライザは、依然として、解析が通常の解析よりも早く完了したことをトラッカに通知する。解析が、完了ステータスを発行すると、解析全体は直ちに停止すべきである。
【００７１】
アナライザの観点からのステージの個数は制御されず、その結果、ステージが多いほど、アナライザは低速になる。データ定義が内部依存関係もシーケンシャルな依存も有しない場合に、開発者は、たとえば、複数のデータ定義を１つの収集要求に結合することによって、可能な限り多くのステージを削減するように管理することができる。たとえば、ノードクラシファイヤは、IfTable及びIfxTableを１つのステージに結合することができる。その理由は、それらのテーブルが分析されて、ステージが到着シーケンスにかかわらずデータの双方を処理できるからである。
【００７２】
図６を参照すると、簡単なクラス図が、コレクトマネージャ３０８の一実施形態を示している。トーカコンポーネントがＮＭＳサブシステム間で共有される構成では、データフォーマットを変換する特定のコンテンツ／トーカ対に関連付けられた個々のコレクタは必要ではない。コレクトマネージャ３０８は、所定のデータ定義に基づいてデータを収集する消費者用の非同期Application Programming Interface（ＡＰＩ）を供給することができ、すべてのデータがトーカから収集されると消費者にコールバックを供給することができる。また、コレクトマネージャ３０８は、バルクモードでデータ定義を収集する要求も形成することができ、アナライザに返される結果が所定のモードになるように、前の要求の順序に基づいて結果をソートすることができる。コレクトマネージャ３０８は、基本的な計装をMBeanによるＤＤ要求及びＤＤ応答に供給でき、通信プロファイルによって容易にされたように、適切なトーカへ透過的に要求を送ることができる。コレクトマネージャ３０８は、或るトーカが失敗した場合に別のトーカを試みる必要はなく、マネージャが再試行する構成可能な順序を必要としない。
【００７３】
図７Ａを参照すると、クラス図が、データ定義マネージャの一実施形態のデータ定義を示している。データ定義マネージャは、発見(Discovery)サブシステム内で配信されるすべてのデータ定義の管理を担当する。管理動作は、配信されたデータ定義をシステムからロードすることを含む。データ定義の元のフォーマットは、コンポーネント又はアウトオブボックスコンテンツ（out-of-box content）のサポートでパッケージされたＸＭＬフォーマットにすることができる。他の管理動作は、特定のデータ収集要求のデータ定義を突き止めること、Ｓｅｔ／Ｇｅｔオペレーション等でデータ定義テーブル(DataDefinition Table)（DDTable）を操作すること、及び特定の列の値のデータタイプ変換を容易にすることを含むことができる。
【００７４】
さまざまな実施形態では、新しいデバイスのポリシーの管理を個々のトーカに担当させることができる。個々のトーカは、固有の特徴を有することができる。たとえば、ＳＮＭＰトーカは、ポリシーからオブジェクト識別子（ＯＩＤ）が与えられるものと予想し、ＴＥＬＮＥＴトーカは、ポリシーからテルネットスクリプトが与えられるものと予想し、Internet Control Message Protocol（ＩＣＭＰ）トーカは、ポリシーから何も与えられないと予想する。
【００７５】
図７Ａは、行セット(RowSet)及びデータ定義を実装するためのクラスを示している。他のクラスは、共通のトーカコンポーネントとのインターフェースの特徴に従って実装することができる。
【００７６】
アナライザについて、データ定義を使用してSNMP トーカ(Talker)からデータを収集し処理する簡単なシーケンス図の一例が図７Ｂに示されている。
【００７７】
アナライザは、最初にコレクトリクエスト(CollectRequest)を構築する。コレクトリクエストは、トーカ及びコレクトマネージャが使用できるターゲット、次のステージ、コンテキスト、又はインデックス情報を含む。次に、アナライザは、要求及び関連付けられたデータ定義名をコレクトマネージャへ送信する。コレクトマネージャは、データ定義をルックアップし、DDテーブルを返す。要求は、コレクトハンドラ(CollectHandler)に転送され、さらに、通信プロファイラ(Communication Profiler)のプロファイル情報に基づいて特定のトーカに中継される。例示的なケースでは、SNMPトーカは、ターゲットと非同期にトークし、ＭＩＢ値を取得し、そして、それらの値をコレクトハンドラにコールバックされたコンテンツとしてDDテーブルに追加する。最後に、コレクトハンドラは、データの処理準備ができた時にアナライザにそのことを通知する。
【００７８】
図７Ｃは、ＸＳＲＰのサンプルのアウトオブボックスデータ定義のコードの一実施形態を示している。
【００７９】
ＳＮＭＰトーカの場合、価値のある情報は、返されたインスタンスサフィックスにインデックスとして組み込むことができる。たとえば、ｉｆｉｎｄｅｘ及びＨＳＲＰグループ番号は、ＨＳＲＰメンバークエリーのＯＩＤサフィックスでのみ返され、どのＭＩＢ値からも直接読み出すことができない。ＳＮＭＰトーカは、ＯＩＤサフィックスをＤＤ行ＩＤ(DDRowID)に配置し、アナライザは、ＤＤ行ＩＤコンテンツが利用可能な場合にこれを解釈する。さまざまなトーカが、ＤＤ行ＩＤを使用することができ、多くのトーカによって使用される場合には、ＤＤ行ＩＤをハンドリングするようにコレクタを実施することができる。
【００８０】
図８Ａを参照すると、初期ドラフトクラス図が、データ定義マッピングルール（ＤＤマッピングルール）の一例を示している。ＤＤマッピングルールは、定義を供給するデータ定義と共に使用されて、トーカがデータ定義の用語でベンダ／デバイス固有データを取り出すことを可能にする。また、ＤＤマッピングルール及びデータ定義によって、新しいデバイスサポートを追加するオフサイクル拡張性（off-cycle extensibility）、期待するデータが見つかるまで優先順位に基づいて複数のＳＮＭＰ  ＭＩＢに問い合わせる（interrogate）能力、及び、拡張モードにおいて複数のＳＮＭＰ  ＭＩＢに問い合わせてデータを一元化する能力も可能になる。さらに、ＤＤマッピングルール及びデータ定義によって、アナライザが、収集されたデータを非ベンダデバイス固有フォーマットでハンドリングできるように、属性コンバータを指定することにより動的なデータ変換も可能になる。
【００８１】
特定のデータ定義について、１つのトーカには、適合したマッピングルールは１つしか存在しない。しかしながら、他の適合したマッピングルールが他のトーカに存在するように構成されている場合には、他の適合したマッピングルールは、他のトーカに存在し得る。他の実施態様は、マッピングルールとトーカとの間の他の対応を有することができる。
【００８２】
各マッピングルールのサブクラスでは、「デフォルト(DEFAULT)」と名付けられた１つの予約されたマッピングルールを構成することができる。このルールは、デフォルトですべてのターゲットに適用されるように、空値フィルタ（null filter）を指定することができる。このルールは、他のルールの前後のいずれかで実行されるように構成することができる。
【００８３】
１つの適合したSNMPマッピングルールは、マッピングオプション(MappingOption)と名付けられたいくつかの代替的なマッピングを有することができる。このマッピングオプションは、相対的な優先順位の値に基づく順序でデータを収集するように実行することができる。マッピングオプションのリスト内の関係がＯＲモードとなるように、或るマッピングオプションが失敗した場合、期待するデータが受信されるまで、又は、別のマッピングオプションの残りがなくなるまで、別のマッピングオプションを試みることができる。すべてのマッピングが、データを収集するために実行され、受信されたデータがマージされるように、各マッピングオプションは、ＡＮＤモードであるマッピングのリストを有することができる。
【００８４】
図８Ｂは、各マッピングのコンテンツをXML文字列として示すテーブルである。図８Ｂに示すコンテンツを有するマッピングルールは、データ定義とは別に記憶することができる。最終的な永続ターゲットは、ObjSに記憶することができるが、短期間には、ＸＭＬファイルに保存することができる。消費者は、グローバルに一意であるデータ定義の名称を参照することによって、特定のデータ定義のマッピングルールを構成することができる。
【００８５】
マッピングルールが発見プロセスにどのように含まれるのかを記述するシーケンス図が図８Ｃに示されている。
【００８６】
ターゲットがＳＮＭＰトーカ及びＴＥＬＮＥＴトーカの双方を使用できる場合、ルールはＯＲモードとすることができ、試行する順序は、トーカオーダー(TalkerOrder)クラス内で構成された値に基づく。
【００８７】
コレクタ及びＳＮＭＰトーカの規約は、相互作用を定義することができる。データ定義で定義された属性は、マッピングされた時に異なるＳＮＭＰ値タイプを有することができ、コンバータクラスの使用を通じて扱うことができる状態を有することができる。データ定義内のすべての属性がすべてのマッピングにおいてマッピングされるという厳格な要件は課されない。データ定義は、サポートされるベンダ／デバイスからのスーパセットデータを含むことができ、その結果、ＳＮＭＰトーカが、ＳＮＭＰ要求で問い合わせる列及び列の値タイプの正確なリストを知るように、コレクタは、マッピング内のＸＭＬコンテンツをＳＮＭＰトーカに渡す。
【００８８】
SNMPトーカは、ＸＭＬコンテンツを受信すると、ＸＭＬ文字列を、SNMPスタック(Stack)によって直接使用できるSNMPColumnDefデータ構造に変換する。列エントリ(ColumnEntry)は、ロング列(LongColumn)、文字列列(StringColumn)、OID列(OIDColumn)、IPアドレス列(IPAddressColumn)、バイトアレイ列(ByteArrayColumn)とすることができる。これらのすべては、SNMPスタックに定義されている。SNMPColumndefは、
-name: String
- column: ColumnEntry
という形を有することができる。
【００８９】
SNMPトーカは、ＳＮＭＰ結果を受信すると、IConverterインターフェースを起動することによって、データ定義に定義されたタイプに列値を変換する。すべてのデータがDDテーブルに一旦書き込まれると、SNMPトーカは、コレクタをコールバックする。ISNMPConveterは、
+convert(in from: ColumnEntry, in mapping:Mapping): DDRowEntry
という形を有することができる。
【００９０】
コレクタ(Collector)からSNMPトーカへの提案されたコールは、
Void talk(Collector collector, Target target, String dd_name, String content)
Void talk(Collector collector, Target target, SNMPContext context, String dd_name, String content)
とすることができる
【００９１】
SNMPトーカからコレクタへの提案されたコールは、
Void talkDone(DDTable table, TalkerStatus status)
とすることができる。
【００９２】
トーカステータス(TalkerStatus)クラスは、要求のステータスを保持することができる。このステータスは、UnResponsive、NoTarget、IOException等とすることができる。
【００９３】
ルールフィルタ(RuleFilter)は、ターゲットを評価し、トーカがトークするのに有効なマッピングルールを返すマッピングルール方法論の一部として使用することができる。フィルタ文字列のシンタックスは、
Filter ::= Expression { LogicOper Filter}
Expression ::= Name Operator value
LogicOper ::= 'and' | 'or'
Name ::= 'OID'
Operator ::= '=' | '!=' | '>' | '>=' | '<' | '<=' | '>>' | '<<' | '<>'
とすることができる。
【００９４】
一例のフィルタ文字列は、たとえばHewlett-Packardデバイス用の「OID >> .1.3.6.1.4.1.11」とすることができる。演算子'>>'は、「〜から始まる」を意味する。演算子'<<'は、「〜で終了する」を意味する。演算子'<>'は、「含む」を意味する。
【００９５】
図９を参照すると、図が、ノードのデータを収集するデータフロー(Data Flow)の一例を示している。多くのデータマッピングルールをコレクタコンポーネント内で実施することができる。各データ定義について、そのデータ定義にどのトーカを最初に試みることができるかを定義するオプションのトーカオーダークラスが存在する。ＳＮＭＰの場合、このトーカは、ノードがＳＮＭＰをサポートするか否かをチェックし続ける。ＳＮＭＰでない場合、次のトーカが試みられる。
【００９６】
ＳＮＭＰがターゲットノードによってサポートされている場合、ノード(Node)プロパティを満たすルールがフィルタリングされる。デフォルトルールが構成される場合、そのデフォルトルールがオプションのルールリストに追加され、beforeDefaultフラグの値に基づく順序でソートされる。一方がデフォルトである最大で２つの適合したルールを実施することができる。
【００９７】
各ルールについて、データフローは、マッピングオプションから開始することができる。マッピングオプションは、優先順位に基づいてソートされる。各マッピングオプションについて、コレクタは、利用可能なマッピングが構成されるのと同時に、SNMPトーカとトークする。すべての要求がトーカから返され、少なくとも１つのトークが成功すると、構成は終了する。そうでない場合、コレクタは、残っているものがなくなるまで、次の利用可能なマッピングオプションを試みる。その後、コレクタは、残っているものがなくなるまで、次の利用可能なマッピングオプションを試みる。
【００９８】
図１０Ａ及び図１０Ｂを参照すると、テーブルが、物理コンポーネントのデータ定義の例を示し、新しいコンテンツを追加するか又は新しいデバイスを拡張する時にデータ定義及びマッピングルールをどのように開発することができるのかの例を明示している。図１０Ｃは、全体的なマッピングルールの構造の一例を示す概略ブロック図である。マッピングルールは、ＸＳＲＰ等のプロトコルごとのユースケースによって、ベンダごとに分離することもできるし、ベンダプロトコルを混合することもできる。たとえば、Ciscoデバイスでは、期待するデータが受信されるまで、さまざまなマッピングオプションを試みることができる。いくつかの極端なデバイスでは、エンティティデータを２つの異なるマッピングから収集することができ、最終データは双方の収束したものとすることができる。図１０Ｄは、Nortelマッピングルール及びＲＦＣ２７３７マッピングルールのマッピングコンテンツの定義のみを示す一例を示したテーブルである。
【００９９】
システムによって遂行又は実行されるこれらのさまざまな機能、プロセス、方法、及びオペレーションは、さまざまなタイプのプロセッサ、コントローラ、中央処理装置、マイクロプロセッサ、デジタル信号プロセッサ、状態マシン、プログラマブルロジックアレイ等で実行可能なプログラムとして実施することができる。プログラムは、任意のコンピュータ関連システム若しくはコンピュータ関連方法により使用されるか又はそれらのコンピュータ関連システム等と共に使用される任意のコンピュータ可読媒体に記憶することができる。コンピュータ可読媒体は、コンピュータ関連システム、コンピュータ関連方法、コンピュータ関連プロセス、若しくはコンピュータ関連プロシージャにより使用されるか又はそれらのコンピュータ関連システム等と共に使用されるコンピュータプログラムを収容又は記憶できる電子的、磁気的、光学的、又は他の物理的なデバイス又は手段である。プログラムは、コンピュータ若しくはプロセッサに基づくシステム又は任意の適切なタイプの命令メモリ若しくは命令ストレージから命令をフェッチできる他のシステム等の、命令実行システム、命令実行デバイス、命令実行コンポーネント、命令実行エレメント、若しくは命令実行装置により使用されるか又はそれらの命令実行システム等と共に使用されるコンピュータ可読媒体に具現することができる。コンピュータ可読媒体は、命令実行システム、命令実行装置、若しくは命令実行デバイスにより使用されるか又はそれらの命令実行システム等と共に使用されるプログラムを記憶、通信、伝播、又はトランスポートできる任意の構造、デバイス、コンポーネント、製品、又は他の手段とすることができる。
【０１００】
例示的なブロック図及びフローチャートは、プロセスの特定の論理機能又はステップを実施するための１つまたは２つ以上の実行可能な命令を含むモジュール、セグメント、又はコード片を表すことができるプロセスステップ又はプロセスブロックを示している。特定の例は、特定のプロセスステップ又は動作を示しているが、多くの代替的な実施態様が可能であり、一般に、単なる設計上の選択によって行われる。動作及びステップは、機能、目的、標準規格への準拠、レガシー構造等の考慮に基づいて、本明細書の特定の記述とは異なる順序で実行することができる。
【０１０１】
本開示は、さまざまな実施形態を説明しているが、これらの実施形態は、例示として理解されるべきであり、特許請求の範囲を限定するものではない。説明した実施形態の多くの変形、変更、追加、及び改良が可能である。たとえば、当業者は、本明細書で開示した構造及び方法を提供するのに必要なステップを容易に実施し、プロセスパラメータ、材料、及び寸法が例として与えられているに過ぎないことを理解する。これらのパラメータ、材料、及び寸法は、所望の構造及び変更を達成するように変更することができ、これらの所望の構造及び変更も、特許請求の範囲の範囲内にある。本明細書に開示した実施形態の変形及び変更も、添付の特許請求の範囲の範囲内にあることを維持しながら行うことができる。たとえば、ネットワークシステム及び方法のいくつかの特定の例が説明される。コンテンツ及びデバイスの拡張性についての例示したシステムは、任意の適したネットワーク構造、デバイス、コンテンツ、及びプロトコルと共に使用することができる。例示した技法は、任意の適したデバイス処理構成、並びに、任意の適したサーバ、コンピュータ、及びデバイスと共に使用することができる。
【図面の簡単な説明】
【０１０２】
【図１Ａ】ネットワーク発見を実施するネットワークシステムの実施形態を示す概略ブロック図である。
【図１Ｂ】ネットワーク発見を実施するネットワークシステムの実施形態を示す概略ブロック図である。
【図１Ｃ】ネットワーク発見を実施するネットワークシステムの実施形態を示す概略ブロック図である。
【図２Ａ】ネットワーク発見用の自動化された方法の実施形態を示すフローチャートである。
【図２Ｂ】ネットワーク発見用の自動化された方法の実施形態を示すフローチャートである。
【図２Ｃ】ネットワーク発見用の自動化された方法の実施形態を示すフローチャートである。
【図２Ｄ】ネットワーク発見用の自動化された方法の実施形態を示すフローチャートである。
【図２Ｅ】ネットワーク発見用の自動化された方法の実施形態を示すフローチャートである。
【図２Ｆ】ネットワーク発見用の自動化された方法の実施形態を示すフローチャートである。
【図２Ｇ】ネットワーク発見用の自動化された方法の実施形態を示すフローチャートである。
【図２Ｈ】ネットワーク発見用の自動化された方法の実施形態を示すフローチャートである。
【図２Ｉ】ネットワーク発見用の自動化された方法の実施形態を示すフローチャートである。
【図２Ｊ】ネットワーク発見用の自動化された方法の実施形態を示すフローチャートである。
【図３】全体的な発見アーキテクチャにおけるアナライザインフラストラクチャの一実施形態のスナップショットを示す概略ブロック図である。
【図４Ａ】解析の一実施形態を示し、依存関係及び能率化された発見を管理するアナライザとの相互作用を記述するクラス図である。
【図４Ｂ】ノードを解析するための一例の技法を記述する解析の簡単なシーケンス図である。
【図５Ａ】段階的アナライザの一実施形態の概略ブロック図である。
【図５Ｂ】段階的アナライザのクラスの一実施形態を示す図である。
【図５Ｃ】ノード解析を処理するアナライザの簡単なシーケンス図である。
【図６】コレクトマネージャの一実施形態を示す簡単なクラス図である。
【図７Ａ】データ定義マネージャの一実施形態のデータ定義のクラス図である。
【図７Ｂ】データ定義を使用してSNMP トーカからデータを収集し処理する簡単なシーケンス図である。
【図７Ｃ】ＸＳＲＰのサンプルのアウトオブボックスデータ定義のコードの一実施形態を示す図である。
【図８Ａ】データ定義（ＤＤ） マッピングルールの一例を示す初期ドラフトクラス図である。
【図８Ｂ】各マッピングのコンテンツをXML文字列として示すテーブルである。
【図８Ｃ】マッピングルールが発見プロセスにどのように含まれるのかを記述するシーケンス図である。
【図９】ノードのデータを収集するデータフローの一例を示す図である。
【図１０Ａ】物理コンポーネントのデータ定義の例を示し、新しいコンテンツを追加するか又は新しいデバイスを拡張する時にデータ定義及びマッピングルールをどのように開発することができるのかの一例を明示するテーブルである。
【図１０Ｂ】物理コンポーネントのデータ定義の例を示し、新しいコンテンツを追加するか又は新しいデバイスを拡張する時にデータ定義及びマッピングルールをどのように開発することができるのかの一例を明示するテーブルである。
【図１０Ｃ】全体的なマッピングルールの構造の一例を示す概略ブロック図である。
【図１０Ｄ】物理コンポーネントのデータ定義の例を示し、新しいコンテンツを追加するか又は新しいデバイスを拡張する時にデータ定義及びマッピングルールをどのように開発することができるのかの一例を明示するテーブルである。
【符号の説明】
【０１０３】
１００・・・ネットワークシステム
１０２・・・発見サブシステム
１０４・・・コンテンツ
１０６・・・デバイスロジック
１０８・・・ドメインコンテンツ
１１０・・・データ定義
１１２・・・属性
１１４・・・値タイプ
１１６・・・コンテンツプロセッサ
１１８・・・ビジネスロジック
１２０・・・データ収集マネージャ
１２２・・・ネットワークデバイス
１２４・・・コンテンツマネージャ
１２６・・・データ
１２８・・・コレクトマッピングルール
１３０・・・フィルタ
１３２・・・デバイスルール
１３４・・・通信Ｉ／Ｆ
１３６・・・オプションハンドラ
１３８・・・マージハンドラ
１４０・・・テーブル
１４２・・・通信Ｉ／Ｆ
１４４・・・コンバータ
１４６・・・データコンバータ
１４８・・・パーサ
１５０・・・アキュムレータ
１５２・・・データ定義マネージャ
１５４・・・コアインフラストラクチャ
１５８・・・トーカ
３００・・・アナライザインフラストラクチャ
３０２・・・全体的な発見アーキテクチャ
３０４・・・アナライザマネージャ
３０６・・・アナライザ
３０８・・・コレクトマネージャ
３１０・・・データ定義マネージャ
３１２・・・トーカ
３１４・・・通信プロファイラ
３１６・・・ノードクラシファイヤ
３１８・・・解析
３２０・・・スレッドプール
３２２・・・ＭＢＥＡＮ
３２４・・・コントローラ
４０４・・・トラッカ
５００・・・段階的アナライザ
５０２・・・エントリステージ
５０４・・・プロセスステージ
【図１Ａ】
2008287699.tif 000003
【図１Ｂ】
2008287699.tif 000004
【図１Ｃ】
2008287699.tif 000005
【図２Ａ】
2008287699.tif 000006
【図２Ｂ】
2008287699.tif 000007
【図２Ｃ】
2008287699.tif 000008
【図２Ｄ】
2008287699.tif 000009
【図２Ｅ】
2008287699.tif 000010
【図２Ｆ】
2008287699.tif 000011
【図２Ｇ】
2008287699.tif 000012
【図２Ｈ】
2008287699.tif 000013
【図２Ｉ】
2008287699.tif 000014
【図２Ｊ】
2008287699.tif 000015
【図３】
2008287699.tif 000016
【図４Ａ】
2008287699.tif 000017
【図４Ｂ】
2008287699.tif 000018
【図５Ａ】
2008287699.tif 000019
【図５Ｂ】
2008287699.tif 000020
【図５Ｃ】
2008287699.tif 000021
【図６】
2008287699.tif 000022
【図７Ａ】
2008287699.tif 000023
【図７Ｂ】
2008287699.tif 000024
【図７Ｃ】
2008287699.tif 000025
【図８Ａ】
2008287699.tif 000026
【図８Ｂ】
2008287699.tif 000027
【図８Ｃ】
2008287699.tif 000028
【図９】
2008287699.tif 000029
【図１０Ａ】
2008287699.tif 000030
【図１０Ｂ】
2008287699.tif 000031
【図１０Ｃ】
2008287699.tif 000032
【図１０Ｄ】
2008287699.tif 000033
【外国語明細書】
BACKGROUND OF THE INVENTION
[0001] The network management market is supported by numerous devices, supplied by many various vendors, creating a challenge for a network discovery system to support the breadth of vendors and depth of devices on the market.
SUMMARY
[0002] In accordance with an embodiment of a network system, a discovery subsystem identifies, enables for consumption, and consumes information.  The discovery subsystem isolates business contents and device-specific logic using modular domain-specific contents and data definitions for normalizing the domain-specific contents and describing attributes and value types that uniquely define domain content independently of a device.
BRIEF DESCRIPTION OF THE DRAWINGS
[0003] Embodiments of the invention relating to both structure and method of operation may best be understood by referring to the following description and accompanying drawings:
FIGUREs 1A, 1B, and 1C are schematic block diagrams showing embodiments of a network system that implements network discovery;
FIGUREs 2A through 2J are flow charts depict embodiments of automated methods for network discovery;
FIGURE 3 is a schematic block diagram illustrating a snapshot of an embodiment of an analyzer infrastructure in an overall discovery architecture;
FIGURE 4A is a class diagram showing an embodiment of Analysis and describing interactions with Analyzers to manage dependency and streamlined discovery;
FIGURE 4B is a simple sequence diagram for Analysis describing an example technique for analyzing a node;
FIGUREs 5A, 5B, and 5C respectively illustrate a schematic block diagram for an embodiment of a Staged Analyzer, an embodiment of a class for the Staged Analyzer, and a simple sequence diagram for an analyzer that processes the node analysis;
FIGURE 6 is a simple class diagram showing an embodiment of a CollectManager;
FIGUREs 7A, 7B, and 7C respectively depict a class diagram for a DataDefinition in an embodiment of a DataDefinition Manager, a simple sequence diagram to use DataDefinition to collect and process data from SNMP Talker, and an embodiment of code for a sample out-of-box DataDefinition for XSRP;
FIGUREs 8A, 8B, and 8C respectively depict an initial draft class diagram depicts an example of a DataDefinition(DD) Mapping Rule, a table that depicts content in each Mapping as an XML String, and a sequence diagram describing how mapping rules are involved in the discovery process;
FIGURE 9 is a diagram showing an example of a Data Flow to collect data for a node;
FIGUREs 10A, 10B, and 10D are tables showing examples of a DataDefinition for a physical component, demonstrating an example of how the DataDefinition and Mapping Rules can be developed when adding a new content or extending a new device; and
FIGURE 10C is a schematic block diagram illustrating an example of the structure of overall mapping rules.
DETAILED DESCRIPTION
[0004] A network system is disclosed that forms a robust framework to support content and/or device extensibility for network discovery.
[0005] An illustrative network discovery system is extensible to support emerging vendors and/or devices, efficiently with respect to reduced or minimum lead times.  The network discovery system enables the robust framework that breaks traditional dependencies between business contents and device specific logics, and forms templates and default behaviors to plug in the business contents and device specific logics.  The created framework enables support of new devices, expanding functionality of an existing network discovery system quickly, simply and easily.  The extensible framework enables improvement in quality and maintainability of the discovery system.
[0006] The illustrative network discovery system and method supports a variety of devices, enabling handling of content for existing devices connected to a network as well as new devices that are added to the network.  The illustrative network discovery system and method drives processing of content as efficiently as possible.  
[0007] A problem in the network domain is the many device types and models that can be connected to the network.  Protocols in the devices are defined rigidly.  When a new type of content is discovered, substantial changes are warranted in a conventional system to allow handling of the new content.  Often the type of data collection can differ for the new content.  The new content can introduce abstractions to separate business data due to device-specific details.  To add new protocols on the discovery of new devices can cause reliability and quality difficulties.
[0008] The illustrative network discovery system and method enables rapid response to connection of new devices to the network by abstracting business logic into independent pieces that are modular and specific to content rather than to devices.  Support for new devices can thus be implemented dynamically.  
[0009] In absence of the illustrative network discovery functionality, for example in a network node management system, support for new content and/or a new device is not trivial, partly because business contents and device specific logics are coupled tightly and pervasively through end-to-end discovery processing.  When a new device support is added, many components are impacted at various places, making device extension difficult and introducing product quality risk and increasing maintenance costs. The illustrative network discovery system and operating method create a new framework to break the tight coupling between business contents and corresponding device specific logics.  Changes to the business contents or device specific logics are isolated.  With the depicted framework, new content or device can be extended independently.  Developers can easily follow the sample templates to extend the content or device specific logic. The framework dynamically combines the extended business contents and devices at runtime, improving the ability to extend new device as well as product quality.
[0010] In absence of the illustrative network discovery functionality, to support a new device developers make changes at many different locations because no clear cut distinction exists between business content and device specific logics.  Such changes call for a developer to have extensive knowledge of the whole product, along with extensive testing to avoid backward incompatibility.  A small bug in new code implemented by the developer can cause the whole product to collapse.
[0011] The illustrative network discovery system and method introduce a capability to create a robust framework that breaks the dependencies between Business Contents and Device Specific logics and accelerates support for discovering the emerging Network device and content.  The framework is robust because the addition of new content does not impact other existing content.
[0012] The illustrative network discovery system and method enables users to extend content and device separately, introducing a Content processor that is business-specific and a Data Collector that is more device-specific. In most cases, the content is relatively stable and is usually updated infrequently. Users can simply extend the Data Collector to support more devices, for example by adding new Collect Mapping Rules without any coding.  Users can also customize Converter and Collect Mapping Rules to meet specific data collection conditions.  Consequently, the illustrative network discovery system and method can greatly improve the ability to extend new content and/or device conditions. Improving over previous systems wherein any extension support is a laborious endeavor.
[0013] The illustrative network discovery system and method can automatically integrate all content and/or device solutions, and can also isolate failures from the artifacts of the solution so that a failure in one artifact or a solution does not collapse the whole system.  Accordingly, the illustrative discovery system is more robust and scalable and enhances maintainability and hence creates potential to greatly reduce the product support costs.  Device support is improved, for example by implementation of abstraction definitions and device support matrices that enable prompt response to addition of a new device, reducing time to market of the added device.
[0014] Referring to FIGUREs 1A, 1B, and 1C, respective basic and more detailed schematic block diagrams show embodiments of a network system 100 that implements network discovery.  The network system 100 comprises a discovery subsystem 102 that identifies, enables for consumption, and consumes information.  The discovery subsystem 102 is configured to isolate business contents 104 and device-specific logic 106 using modular domain-specific contents 108 and data definitions 110 for normalizing the domain-specific contents 108 and describing attributes 112 and value types 114 that uniquely define domain content independently of a device 122.
[0015] In an illustrative embodiment, the network system 100 can be implemented to include four components, specifically a Core Infrastructure 154, a Content Processors 116, Data Definitions 110, and a Data Collector 120.  The components are loosely coupled and can be isolated, enabling flexible functionality such as that of plug and play and increasing robustness. 
[0016] The illustrative network discovery system 100 can be implemented with three basic components: Content 104, DataDefinition 110, and a Data Collector 120, each of which can be extensible and dynamically managed by a corresponding manager from a core component.  A talker component 158 can be another extensible part of the system 100 that is optional.  In practice, a content 104 can handle zero to many data definitions 110.  Each Data Definition can have multiple Collect Mapping Rules based on the number of talkers in place.
[0017] A talker 158 is an abstraction of a device or system that gathers data from a particular device or devices.  Rules can be specified to enable a selected talker to obtain information from a designated device or devices.  Specific rules, for example compliant with an application such as a Smart Messaging Platform (SMP), direct a designated talker to obtain information from a device or devices.  The rules can also identify data and data formats of content gathered from the device or devices, which is highly product-specific.  Rules can also specify conversion of accessed content.  
[0018] A talker 158 can be a system or method used to transfer or convey information on a network. "http://en.wikipedia.org/wiki/World_Wide_Web" Examples of talkers include Hypertext Transfer Protocol (HTTP), File Transfer Protocol (FTP), vendor support protocols such as Simple Network Management Protocol (SNMP), Teletype Network (TELNET), and many others.  A talker 158 can be used individually or multiple talkers may be used in combination.   Talker functionality is controlled by mapping rules that designate how a particular protocol data collector uses a specific protocol for communicating.  A talker operates in compliance with a protocol, the illustrative network discovery system and method enable dynamic changes to mapping rules, facilitating flexibility and trouble-shooting.
[0019] The Core Infrastructure 154 addresses the multiple contents that can be deployed in a system and enables a synchronous methodology wherein multiple pieces of the system can operate in concert.  The Core Infrastructure 154 links the Content Processors 116 and Data Collectors 120, enabling communication of Data Definitions 110 between the Content Processors 116 and Data Collectors 120.  Since separate Content Processors 116 exist for each Domain-specific contents 108 and separate Data Collectors 120 exist for each Device-specific contents 156, the Content Processors 116 can also isolate failures or erratic behaviors of devices easily. Since failure on one content module does not impact others, the illustrative architecture greatly improves the robustness of the entire discovery system.
[0020] The Content Processor 116 can support asynchronous communication whereby multiple requests are made without waiting for a response to process additional data.  The asynchronous communication pattern ensures every new content processor can consistently attain a suitable level of performance.  
[0021] The data to be discovered from a Network Device 122 can be modularized into domain-specific contents 108.  Individual domain-specific content 108 is defined by normalized structures called Data Definitions 110.  A data definition 110 contains a list of attributes 112 and value types 114 that uniquely define the domain content 104 independent of the device vendor or model.
[0022] The discovery subsystem 102 normalizes domain-specific content 108, enabling creation of content-generic processors 116 that are dedicated to business logics 118 which are generically abstracted independent of specific devices from which data is collected.  
[0023] A Content Processor 116 calls on the Data Collector 120 to collect from any device the data as specified by a Data Definition 110.  Accordingly, in some embodiments, the discovery subsystem 102 comprises a data collector 120 that can collect data from devices as specified by one or more of the data definitions 110.  The network system 100 can further comprise a content manager 124 configured to issue calls to the data collector 120 for requested data 126.  The content manager 124 shifts functionality from a more typical device basis to data-based operations.  Accordingly, the content manager 124 functionality does not depend on specific devices.  The content manager 124 calls on the data collector 120 to collect data specified by the data definitions 110.  
[0024] The data collector 120 can handle data 126 according to collector mapping rules 128.  In the illustrative network discovery system 100 and associated method, rules are based on data rather than having a device-basis.  Examples of data 126 described by collector mapping rules 128 can include one or more filters 130 adapted to select device-specific rules 132 for a designated data definitions 110, one or more communication interfaces 134 adapted to communicate data over a plurality of protocols, an option handler 136 that can collect data according to selected attributes 112 and priority.  Additional data 126 examples addressed by collector mapping rules 128 can include a merge handler 138 that is adapted to merge data collected from different tables 140 of a management information base of a device 122 into a single data definition 110, and one or more configuration files 142 that defines mapping rules 128 in a selected format.
[0025] The filters 130 can be used for implementing mapping laws and defines how to choose which mapping rule to implement in a particular inquiry.  Content has a particular format.  Each device model has a unique identification that is directly accessible by other devices connected to the network.  A content processor accesses data, typically by specifying a physical identifier (ID) in an inquiry to a device.  In an attempted content access, a filter can match a system identifier (SYSID) to a mapping rule, thereby allowing or disallowing access to the content.  
[0026] In some embodiments, the data collector 120 can handle data 126 according to a converter 144 such as, for example, a data converter 146 adapted to transform data from a collected format to a normalized data definition format, a parser 148 adapted to parse a collected data attribute to deduce multiple data constituents, an accumulator 150 adapted to combine at least one collected data value to deduce a single inferred data value, and other converters.  The converters 144 normalize data according to the data definitions 110.
[0027] In some implementations or embodiments, the data collector 120 can be configured to handle data according to collector mapping rules 128 and a converter 144 to collect raw device data and return a normalized data definition to a content manager 124.
[0028] The data collector 120 can be configured to create asynchronized application program interfaces (APIs) that enable data collection based on a data definition and callback when the data is collected.
[0029] The content manager 124 requests particular information content and dynamically monitors for content from one or more devices or ports.  The content manager 124 can access content from aggregated ports or aggregated links.  The content manager can dynamically search for existing contact and can have spy functionality.  
[0030] A network typically connects a very large number of devices.  The content manager 124 can discover and identify content for individual devices connected to the network, determining all types of content supported in a network device.  The content manager 124 can access data according to classification and classify the data according to various characteristics such as device attributes, data attributes, device, schedule number, internet protocol (IP) address on a device, and subnet to which a device belongs.  The content manager 124 can further access and classify data according to layer 2 content, ports on a device, physical device such as controller, processor, or central processing unit (CPU), and others.  The content manager 124 can select a particular device as active for supplying content while maintaining other devices in a stand-by mode.  The content manager 124 can also determine differences between protocol of one device and another, enabling aggregation of content in different formats.
[0031] In some embodiments, the discovery subsystem 102 can further comprise a data definition manager 152 that is configured to manage data definitions 110 through operations including, for example, loading data definitions, locating data definitions for a specific data collection request, manipulating a data definition table using set and get operations, converting data types, and the like.
[0032] A data definition manager 152 controls abstraction of data, for example by normalizing the data.  The data definition manager 152 manages data definitions, for example by adding, modifying, or deleting data definitions.  In some embodiments, eXtensible Markup Language (XML) can be used to specify data definitions, although other structures can be used.  A data definition is an abstraction of content.  An individual content can have one or more data definitions that are independent of a device from which the content is collected.  A data definition can be associated with one content or many and enables multiple types of content.  
[0033] A data collection manager 120 can be implemented as a detailed logic that uses mapping rules to map content to a device.  The data collection manager 120 enables usage of multiple selectable options that specify how to collect data and also enables the options to be prioritized.  The options enable data to be collected from multiple devices.  The data collection manager 120 enables specification of multiple options for data collection, directing an inquiry to a particular device according to the specified options.  If data collection fails for the device, the data collection manager can redirect the inquiry to another device.  The options specify how the inquiry is directed to a device, for example by specifying the format of a request or directing normalization of the data so that a content manager can appropriately handle the inquiry and data.  An option can specify that data conversion is mandatory or optional for a particular inquiry.  Data can be converted in a manner specific to a device and to the specified data definition.  
[0034] Individual network users, devices, and content are typically different.  The data collection manager 120 facilitates activation and inactivation of content in a manner that handles the differences.
[0035] A data definitions 110 can specify collector mapping rules, thereby defining data to be collected in an inquiry.  The collector mapping rules can be implemented according to a table name, along with names or other designation of rows and/or columns in the table, specifying data rules for a device or devices.  The mapping can define for each device the selected way to acquire data.  For the example of a Cisco device, the data collection manager can specify a table name and column allocated to particular data.  The illustrative system enables modification, addition, or deletion of mapping rules.  
[0036] Some devices can support multiple types of data. A mapping definition determines how to handle the different data types.  
[0037] A converter 144 can be included to enable conversion of content from one form to another.  For example, for a device a table may return data in a string format while a request may specify return of the data in a different format.  The converter can convert the content format, collate data, or make other changes in data presentation.  The converter 144 can be optional in various implementations or in some conditions.  For example, for a particular attribute a device can function consistently without conversion.  The converter 144 is typically used when content is different from what a requesting devices expects to receive.  In an illustrative embodiment, the converter is typically invoked automatically.
[0038] In an example of operation of the data collection manager 120, content for a device can be compliant with a specific protocol and can be requested for usage by another device that processes a different protocol.  A collector mapping rule can be created that specifies ways to collect data for different devices, for example designating a table and column in the table.  Format may be different for data as accessed and as desired so that the converter can be used to return data in the appropriate format.  
[0039] The data collection manager 120 enables the creation of new collector mapping rules and conversions as new devices and content formations become available.  Accordingly, the usage of collector mapping rules creates flexibility, enabling new functionality without change to structural aspects of the system.  
[0040] In an example discovery methodology, a device upon which content discovery is directed has a list of deployed content.  A requesting device can access the content lists in a device-by-device manner and examine the content lists to trigger data collection, returning information such as a system identifier (SYSID).  Basic information, once accessed, is passed for each content in a device and passed to the content manager 124.  If the device does not support a type of content, the mapping rule is implemented to ignore the content.  For all components, templates are supplied, specifying behavior of the component.  The template defines the structure of a content mapping rule and supports normalization of data to a data definition.
[0041] The discovery subsystem 102 enables creation of a content processor 116 that can request multiple data definitions concurrently.  The data collector 120 assembles normalized data and feedback to the content processor 116 to improve data gathering performance.  
[0042] Referring to FIGUREs 2A through 2J, several flow charts depict embodiments of automated methods for network discovery.  An illustrative network discovery method 200 is shown in FIGURE 2A and comprises modularizing 202 data to be discovered from a network device into domain-specific content and defining 204 the domain specific content by normalized data definitions.  Business content and device-specific logic can be isolated 206 according to the modularized domain-specific content and the data definitions.
[0043] FIGURE 2B illustrates an embodiment of a network discovery method 210 that can further comprise identifying 212 data on one or more network devices, thereby enabling 214 the identified data for consumption, then consuming 216 the data.
[0044] FIGURE 2C shows an embodiment of a network discovery method 220 that can further comprise normalizing 222 the domain-specific contents, and describing 224 attributes and value types that uniquely define domain content independently of a device.
[0045] FIGURE 2D shows an embodiment of a network discovery method 230 that can further comprise enabling 232 creation of content-generic processors that are dedicated to business logics which are generically abstracted independent of specific devices from which data is collected.
[0046] Referring to FIGURE 2E, another embodiment of a network discovery method 240 can further comprise collecting 242 data from devices specified by one or more data definitions and issuing 244 calls to the data collector for requested data.
[0047] FIGURE 2F depicts an embodiment of a network discovery method 250 that can further comprise handling 251 data according to collector mapping rules, filtering 252 data to select device-specific rules for a designated data definition, and communicating 253 data over multiple of protocols.  Data  can be collected 254 according to selected attributes and priority.  Data collected from different tables of a management information base (MIB) of a device can be merged 255 into a single data definition.  Mapping rules are defined 256 in a selected format.
[0048] The Data Collector employs the extensible concept of Collector Mapping Rules for each Data Definition and an automatically-invoked converter 144 that conforms content to a format expected by a requesting device.
[0049] The Collector Mapping Rules enable several useful features.  For example, filters can be constructed that select device specific rules for a particular Data Definition. The Collector Mapping Rules enable talkers to use alternate protocols such as Simple Network Management Protocol (SNMP), Teletype Network (TELNET), Hypertext Transfer Protocol (HTTP), and others to communicate with the device.  Collector Mapping Rules also can support potential options on the device for collecting the same attribute and the priority for considering one option over another.  The mapping rules also can enable merging of data collected from different tables of the management information base in the device into a single data definition.  Other rules support configuration files to define the mapping rules in eXtensible Markup Language (XML) format.
[0050] To enable extensible support for new device and content discovery, design patterns are supplied to implement Content Processors, Data Collectors and Data Definitions. The patterns enable creation of the standard interfaces, abstract classes, and utilities that can expedite the support delivery process. The Core framework automatically stitches the artifacts for the new content support into the discovery system.
[0051] The illustrative network discovery methods enable new device support for an existing content in a highly simplified manner since only a limited update to the Data Collector is used.  Such an update can be performed by actions as minimal as adding a mapping rule in the configuration file or installing or plugging in a new converter if the default Converter cannot meet the needs of data transformation.
[0052] FIGURE 2G shows an embodiment of a network discovery method 260 that includes operation of a Converter.  The Converter enables transformation of the data from the collected format to the normalized Data Definition format and parsing of a single collected data attribute to deduce multiple data constituents.  One or more collected data values can be processed to deduce a single inferred data value. The Converter also enables more sophisticated interaction with the core infrastructure.  Accordingly, the network discovery method 260 can further comprise converting 262 data from a collected format to a normalized data definition format, parsing 264 a collected data attribute to deduce multiple data constituents, and combining 266 one or more collected data values to deduce a single inferred data value.
[0053] Thus the Data collector employs the Mapping Rules and Converters to collect raw device data and return the normalized Data Definitions to the Content Processors.
[0054] Referring to FIGURE 2H, another embodiment of a network discovery method 270 can further comprise handling 272 data according to collector mapping rules and data  conversion, collecting 274 raw device data, and returning 276 a normalized data definition.
[0055] FIGURE 2I shows an embodiment of a network discovery method 280 that can further comprise creating 282 asynchronized application program interfaces (APIs) that enable data collection based on a data definition and callback when the data is collected.
[0056] Referring to FIGURE 2J, another embodiment of a network discovery method 290 can further comprise managing 292 data definitions.  Examples of data definition management operations can include loading 294 data definitions, locating 296 data definitions for a specific data collection request, manipulating 298 a data definition table using set and get operations, converting 299 data types, and the like.
[0057] Referring to FIGURE 3, a schematic block diagram illustrates a snapshot of an embodiment of an analyzer infrastructure 300 in an overall discovery architecture 302.  Other components in a discovery subsystem can be added in various embodiments of other embodiments of an analyzer infrastructure.
[0058] The illustrative analyzer infrastructure 300 comprises four components including an Analyzer Manager 304, Analyzers 306, Collect Manager 308, and DataDefinition Manager 310. The Analyzer Manager 304 corresponds to the Content Manager 124 and the Analyzers 306 correspond to content processors 116 shown in FIGURE 1B.  Another component of the analyzer infrastructure 300 that can be implemented in a network management system comprises talkers 312.  A communication profiler 314 operates to portray a communication capability for discovery targets and can be configured as a shared component between a Node Classifier 316 and Collect Manager 308.  
[0059] The illustrative Analyzer Manager 304 has three predominant features including an Analysis block 318 to specify the analyzer dependency, a ThreadPool 320 for staged analyzers, and MBean 322 for instrumentation and supportability. One feature, high availability, can be implemented in the Analyzer Manager 304 or in a Controller 324.  The infrastructure 300 can be implemented to support domain services.
[0060] Referring to FIGURE 4A, a class diagram illustrates an embodiment of Analysis 318 and describes interactions with Analyzers 306 to manage dependency and streamlined discovery.  FIGURE 4B shows a simple sequence diagram for Analysis 318 that describes an example technique for analyzing a node.  
[0061] At Analyzer Manager 304 start up time, the Analysis Manager 304 calls an initialization (init) method to construct the Analysis 318, which in turn reads in an Analysis configuration XML file, instantiate each Analyzer 306, set the parents/children relationship in IBasicAnalyzer according to the configured dependency. The Analyzer Manager 304 also instantiates a PipelineEntry with the start point analyzers, which do not have dependency on other analyzers.
[0062] As the nodes flow in the Analyzer Manager 304, the Analyzer Manager 304 calls Analysis 318 to obtain the entry point to analyze the node. Iteratively, the Analyzer Manager 304 calls all start point analyzers to analyze the node.  Once Analyzer 306 completes analysis, Analyzer Manager 304 calls AnalysisTracker 404 to log status of the analysis associated with the node.
[0063] Possible status can be SUCCEED, NODATA, EXCEPTION, and IGNORE.  SUCCEED status indicate the analysis completes successfully. The analysis is passed over to those analyzers downstream of the pipeline that depend on the analysis.  NODATA status indicates the analysis does not complete successfully due to inability to obtain necessary data, for example because the node is not responsive to the talk response.  Analysis does not continue for the node to analyzers downstream of the pipeline that depend on the analysis.  EXCEPTION status indicates all kinds of exceptions caught during the analysis. The analysis does not continue for the node to analyzers downstream of the pipeline that depend on the analysis for the EXCEPTION status.  IGNORE status indicates the analyzer did not handle the node and is filtered out at the beginning of analysis. Each analyzer should evaluate operational capability against a filter or filters before actually collecting data.
[0064] Analysis status is used by a tracker to determine whether the node should be passed on to the next set of downstream analyzers.  In the condition that current analysis is a success and the dependencies of a child are also completed successfully, the analysis can be activated on the child in the calling next() to PipelineFlowEngine class.  If no children are available, the analysis simply stops against the node.
[0065] For each analyzer, ThreadPool can be split into multiple stages by aligning the collect data actions pertained to DataDefinition(s).  Detail information regarding how to decouple the analyzer is further described in the Staged Analyzer section hereinafter.  Each stage can be a standalone Runnable procedure that can be executed concurrently with a shared threadpool in the analyzer infrastructure.  A threadpool util can be used to instantiate a ThreadPool with a configurable initial and maximum pool size. An unlimited queue can be recommended for the threadpool.
[0066] Referring to FIGURE 5A, a schematic block diagram illustrates an embodiment of a Staged Analyzer 500.  The discovery Staged Analyzer 500 uses event-driven design pattern by splitting each analyzer into sequential stages.  Each stage is driven by data request or/and data processing events as depicted in FIGURE 5A.  The DataDefinition (DD) and node analysis information are the events that drive the analysis flow from one stage to another until the whole analysis is fully completed.
[0067] FIGURE 5B depicts an embodiment of a class for the Staged Analyzer 500.  To implement a new analyzer, the developers simply fill in the business content in classes EntryStage 502, Analyzer, and various ProcessStages 504(n) facilitated by the common functionalities supplied by the infrastructure classes.  The infrastructure seamlessly stitches the business content together.
[0068] Referring to FIGURE 5C, a simple sequence diagram is shown for an analyzer that processes the node analysis.  The analysis can complete at any stage, either succeed or failed. For instance, the analyzer may not qualify to handle the type of node, did not get data back from collect manager, or other unexpected exceptions.  For these circumstances, the analyzer still notifies the tracker the analysis has completed earlier than normal analysis. Once an analysis has issued the complete status, the whole analysis should stop immediately.
[0069] The number of stages from analyzer perspective is not controlled so that, the more stages, the slower the analyzer. A developer can manage to reduce as many stages as possible, for example by combining multiple DataDefinitions in one collect request if the DataDefinitions have no internal dependencies or sequential reliance.  For example, NodeClassifier can combine IfTable and IfxTable in one stage because the tables are collated and a stage can process both of data without regard for arrival sequence.
[0070] Referring to FIGURE 6, a simple class diagram illustrates an embodiment of the CollectManager 308.  In a configuration wherein a talker component is shared across NMS subsystems, an individual collector associated with specific contents/talker pair to transform the data format is not necessary. CollectManager 308 can supply asynchronized Application Programming Interfaces (APIs) for a consumer to collect data based on the predefined DataDefinition, and callback to the consumer once all data have been collected from talkers.  CollectManager 308 can also form a request to collect DataDefinition in bulk mode and can sort the results based on the order in the previous request so that the results returned back to the analyzer is in predetermined mode.  CollectManager 308 can supply basic instrumentation to the DD request and response by MBean and direct the request to the appropriate talker transparently as facilitated by the communication profiler.  The CollectManager 308 need not attempt another talker if one talker has failed and does not need a configurable order for a manager to retry.  
[0071] Referring to FIGURE 7A, a class diagram depicts a DataDefinition for an embodiment of a DataDefinition Manager.  The DataDefinition Manager is responsible to manage all DataDefinitions delivered in the Discovery subsystem. Management actions include loading delivered DataDefinitions from the system. The original format of DataDefinition can be in XML format packaged with component or out-of-box contents support.  Other management actions can include locating the DataDefinition for a specific data collection request, manipulating the DataDefinitionTable (DDTable) such as with Set/Get operations, and facilitating the data type conversion for specific column value.
[0072] In various embodiments, individual talkers can be made responsible for managing policy for new devices.  Individual talkers can have unique characteristics, for example a SNMP talker expects object identifiers (OIDs) from the policy, a TELNET talker expects telnet script from the policy, and an Internet Control Message Protocol (ICMP) talker expects nothing from the policy.
[0073] FIGURE 7A depicts the classes for implementing the RowSet and DataDefinition. Other classes can be implemented according to characteristics of the interface with the common talker component.
[0074] For an analyzer, an example of a simple sequence diagram to use DataDefinition to collect and process data from SNMP Talker is shown in FIGURE 7B.  
[0075] An analyzer first constructs a CollectRequest, which contains target, next stage, context, or index information that can be used by the talker and collect manager.  Then the analyzer sends the request and associated DataDefinition names to the CollectManager, that looks up the DataDefinition and returns back the DDTable.  The request is forwarded to CollectHandler and further relayed to the specific talker based on the profile information in the Communication Profiler.  In the illustrative case, SNMPTalker asynchronously talks to the target, gets the MIB values, and adds the values into the DDTable as contents callbacked to the CollectHandler.  Finally CollectHandler notifies analyzer when the data is ready for processing.
[0076] FIGURE 7C illustrates an embodiment of code for a sample out-of-box DataDefinition for XSRP.
[0077] For an SNMP talker, valuable information can be embedded in the returned instance suffix as index. For example, the ifindex and HSRP group number are returned only in the OID suffix in HSRP member query and are not directly readable from any MIB value.  SNMP Talker places the OID suffix in DDRowID, and the analyzer interprets the DDRowID content if available.  Various talkers may use the DDRowID and, if used by many talkers, a collector can be implemented to handle DDRowID.
[0078] Referring to FIGURE 8A, an initial draft class diagram depicts an example of a DataDefinition (DD) Mapping Rule.  The DD mapping rule is used together with the DataDefinition to supply a definition to enable a talker to retrieve vendor/device specific data in a term of a DataDefinition.  The DD mapping rule and DataDefinition also enable off-cycle extensibility to add new device support, a capability to interrogate with multiple SNMP MIBs based on the priority until finding the expected data, and a capability to interrogate with multiple SNMP MIBs in augmented mode and consolidate the data.  THe DD mapping rule and DataDefinition also enable dynamic data transformation by specifying an attribute converter so that the analyzer can handle the collected data in non-vendor-device specific format.
[0079] For a particular DataDefinition, only one satisfied mapping rule is in one talker.  However, other satisfied mapping rules can be in other talkers if so configured. Other implementations may have other correspondence between mapping rules and talkers.  
[0080] In each MappingRule subclass one reserved mapping rule, named as 'DEFAULT', can be configured. The rule can specify the null filter so that the rule applies to all targets by default. The rule can be configured to run either before or after other rules.
[0081] One satisfied SNMPMappingRule can have a few alternative mappings, named MappingOption, which can be exercised to collect data in the order based on relative priority value. If one MappingOption fails, another can be attempted until the expected data is received or no additional MappingOption remains so the relation among list of MappingOption is in OR mode.  Each MappingOption can have a list of Mappings that are in AND mode so all mappings are exercised to collect data and the received data is merged.
[0082] FIGURE 8B is a table that depicts content in each Mapping as an XML String.  The mapping rules, with the contents shown in FIGURE 8A, can be stored separately from the DataDefinition. A final persistence target can be stored in ObjS, but in short term may be saved in an XML file. Consumers can configure the mapping rule for a specific DataDefinition by referencing the name of DataDefintion which is globally unique.   
[0083] A sequence diagram is shown in FIGURE 8C that describes how mapping rules are involved in the discovery process.
[0084] If a target can use both SNMP and TELNET talkers, the rules can be in OR mode and an order to try is based on the value configured in TalkerOrder class.
[0085] Collector and SNMP talker contracts can define interactions.  An attribute defined in the DataDefinition can have a different SNMP value type when mapped, a condition that can be addressed through usage of a converter class.  No strict requirement is imposed that all attributes in the DataDefinition are mapped in all mappings.  The DataDefinition can contain superset data from supported vendor/device so the collector passes the XML content in the mapping down to the SNMP talker so that SNMP talker knows the exact list of columns and column value types to query in the SNMP request.  
[0086] SNMPTalker, upon receiving the XML content, converts the XML string into the SNMPColumnDef data structure which can be used directly by SNMPStack.  The ColumnEntry can be LongColumn, StringColumn, OIDColumn, IPAddressColumn, ByteArrayColumn, all of which are defined in SNMPStack.  SNMPColumdef can have the form:
-name: String
- column: ColumnEntry
[0087] SNMPTalker, upon receiving the SNMP result, transforms the column value into the type defined in the DataDefinition by invoking the IConverter interface.  Once all data are filled in the DDTable, SNMPTalker calls back the collector.  ISNMPConverter can have the form: 
+convert(in from: ColumnEntry, in mapping:Mapping): DDRowEntry.
[0088] A suggested call from Collector to SNMPTalker can be:
Void talk(Collector collector, Target target, String dd_name, String content)
Void talk(Collector collector, Target target, SNMPContext context, String dd_name, String content)
[0089] A suggested call from SNMPTalker to Collector can be:
Void talkDone(DDTable table, TalkerStatus status)
[0090] TalkerStatus class can hold the status of the request, which could be UnResponsive, NoTarget, IOException, or the like.
[0091] A RuleFilter can be used as part of a mapping rule methodology which evaluates a target and returns a valid MappingRule for talker to talk.  Syntax of a filter string can be:
Filter ::= Expression { LogicOper Filter}
Expression ::= Name Operator value
LogicOper ::= 'and' | 'or' 
Name ::= 'OID'
Operator ::= '=' | '!=' | '>' | '>=' | '<' | '<='| '>>' | '<<' | '<>'
[0092] An example filter string can be: "OID >> .1.3.6.1.4.1.11" for example for a Hewlett-Packard device.  Operator '>>' means "starts with".  Operator '<<' means "ends with".  Operator '<>' means "contains".
[0093] Referring to FIGURE 9, a diagram shows an example of a Data Flow to collect data for a node.  Many data mapping rules can be implemented in the collector component.  For each DataDefinition, an optional TalkerOrder class exists that defines for the DataDefinition which talker can be tried first.  If SNMP, the talker continues to check whether the node supports SNMP.  If not, a next talker is attempted.
[0094] If SNMP is supported by the target node, a rule is filtered that satisfies the Node properties.  If a DEFAULT rule is configured, the default rule is added into the optional rule list and sorted in the order based on the value of beforeDefault flag.  A maximally of two satisfied rules can be implemented in which one is the DEFAULT.
[0095] For each rule, data flow can start with MappingOption, which sorts based on priority.  For each MappingOption, the collector concurrently talks with SNMPTalker with the available Mappings configured. Once all requests are returned from the Talker and at least one talk succeeds, configuration ends.  Otherwise, the collector attempts the next available MappingOption until no more remain.  Then the collector attempts the next available rule until no more remain.
[0096] Referring to FIGUREs 10A and 10B, tables show examples of a DataDefinition for a physical component, demonstrating an example of how the DataDefinition and Mapping Rules can be developed when adding a new content or extending a new device.  FIGURE 10C is a schematic block diagram that shows an example of the structure of overall mapping rules.  Mapping rules can be isolated per vendor, by use case per protocol such as XSRP; or even mixing the vendor protocol. For example for Cisco devices, various MappingOptions may be attempted until expected data is received.  For some extreme devices, entity data can be collected from two different mappings and the final data can be a convergence of both.  FIGURE 10D is a table showing an example that illustrates only definition of mapping contents for Nortel and RFC2737 mapping rules.
[0100] The various functions, processes, methods, and operations performed or executed by the system can be implemented as programs that are executable on various types of processors, controllers, central processing units, microprocessors, digital signal processors, state machines, programmable logic arrays, and the like.  The programs can be stored on any computer-readable medium for use by or in connection with any computer-related system or method.  A computer-readable medium is an electronic, magnetic, optical, or other physical device or means that can contain or store a computer program for use by or in connection with a computer-related system, method, process, or procedure.  Programs can be embodied in a computer-readable medium for use by or in connection with an instruction execution system, device, component, element, or apparatus, such as a system based on a computer or processor, or other system that can fetch instructions from an instruction memory or storage of any appropriate type.  A computer-readable medium can be any structure, device, component, product, or other means that can store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.
[0101] The illustrative block diagrams and flow charts depict process steps or blocks that may represent modules, segments, or portions of code that include one or more executable instructions for implementing specific logical functions or steps in the process.  Although the particular examples illustrate specific process steps or acts, many alternative implementations are possible and commonly made by simple design choice.  Acts and steps may be executed in different order from the specific description herein, based on considerations of function, purpose, conformance to standard, legacy structure, and the like.
[0102] While the present disclosure describes various embodiments, these embodiments are to be understood as illustrative and do not limit the claim scope.  Many variations, modifications, additions and improvements of the described embodiments are possible.  For example, those having ordinary skill in the art will readily implement the steps necessary to provide the structures and methods disclosed herein, and will understand that the process parameters, materials, and dimensions are given by way of example only.  The parameters, materials, and dimensions can be varied to achieve the desired structure as well as modifications, which are within the scope of the claims.  Variations and modifications of the embodiments disclosed herein may also be made while remaining within the scope of the following claims.  For example, a few specific examples of network systems and methods are described.  The illustrative system for content and device extensibility can be used with any suitable network structures, devices, content, and protocols.  The illustrative techniques may be used with any suitable data processing configuration and with any suitable servers, computers, and devices.
WHAT IS CLAIMED IS:
1.    A network system (100) comprising:
a discovery subsystem (102) that identifies, enables for consumption, and consumes information, the discovery subsystem configured to isolate business contents (104) and device-specific logic (106) using modular domain-specific contents (108) and data definitions (110) for normalizing the domain-specific contents (108) and describing attributes (112) and value types (114) that uniquely define domain content independently of a device (122). 
2.    The system (100) according to Claim 1 further comprising:
the discovery subsystem (102) that normalizes domain-specific content (108) and enables creation of content-generic processors (116) that are dedicated to business logics (118) which are generically abstracted independent of specific devices from which data is collected.
3.    The system (100) according to Claim 1 further comprising:
the discovery subsystem (102) comprising:
a data collector (120) configured to collect data from devices (118) as specified by at least one data definition (110); and
a content manager (124) configured to issue calls to the data collector (120) for requested data.
4.    The system (100) according to Claim 3 further comprising:
the data collector (120) that handles data according to collector mapping rules (128), the collector mapping rules (128) comprising:
at least one filter (130) adapted to select device-specific rules (132) for a designated data definition (110);
at least one communication interface (134) adapted to communicate data over a plurality of protocols; 
an option handler (136) adapted to collect data according to selected attributes (112) and priority;
a merge handler (138) adapted to merge data collected from different tables (140) of a management information base of a device into a single data definition; and
at least one configuration file (142) that defines mapping rules (128) in a selected format.
5.    The system (100) according to Claim 3 further comprising:
the data collector (120) that handles data according to a converter (144) comprising:
a data converter (146) adapted to transform data from a collected format to a normalized data definition format;
a parser (148) adapted to parse a collected data attribute to deduce multiple data constituents; and
an accumulator (150) adapted to combine at least one collected data value to deduce a single inferred data value. 
6.    The system (100) according to Claim 3 further comprising:
the data collector (120) configured to handle data according to collector mapping rules (128) and a converter (144) to collect raw device data and return a normalized data definition to content managers.
7.    The system (100) according to Claim 3 further comprising:
the data collector (120) configured to create asynchronized application program interfaces (APIs) enabling data collection based on a data definition and callback when the data is collected. 
8.    The system (100) according to Claim 3 further comprising:
the discovery subsystem (102) further comprising:
a data definition manager (152) configured to manage data definitions including loading data definitions (110), locating data definitions for a specific data collection request, manipulating a data definition table using set and get operations, and converting data types.
9.    The system (100) according to Claim 1 further comprising:
the discovery subsystem (102) configured to enable creation of a content processor (116) adapted to request multiple data definitions concurrently; and
the discovery subsystem (102) comprising a data collector (120) configured to assemble normalized data and feedback to the content processor to improve data gathering performance.
10.    An article of manufacture comprising:
a controller usable medium having a computable readable program code embodied therein for automatically performing network discovery, the computable readable program code further comprising:
a code adapted to cause the controller to modularize data to be discovered from a network device into domain-specific content;
a code adapted to cause the controller to define the domain specific content by normalized data definitions; and
a code adapted to cause the controller to isolate business content and device-specific logic according to the modularized domain-specific content and the data definitions.
EXTENSIBLE SYSTEM FOR NETWORK DISCOVERY
ABSTRACT
A network system (100) comprises a discovery subsystem (102) that identifies, enables for consumption, and consumes information.  The discovery subsystem (102) isolates business contents (104) and device-specific logic (106) using modular domain-specific contents (108) and data definitions (110) for normalizing the domain-specific contents (108) and describing attributes (112) and value types (114) that uniquely define domain content independently of a device (122).
2008287699.tif 000034
2008287699.tif 000035
2008287699.tif 000036
2008287699.tif 000037
2008287699.tif 000038
2008287699.tif 000039
2008287699.tif 000040
2008287699.tif 000041
2008287699.tif 000042
2008287699.tif 000043
2008287699.tif 000044
2008287699.tif 000045
2008287699.tif 000046
2008287699.tif 000047
2008287699.tif 000048
2008287699.tif 000049
2008287699.tif 000050
2008287699.tif 000051
2008287699.tif 000052
2008287699.tif 000053
2008287699.tif 000054
2008287699.tif 000055
2008287699.tif 000056
2008287699.tif 000057
2008287699.tif 000058
2008287699.tif 000059
2008287699.tif 000060
2008287699.tif 000061
2008287699.tif 000062
2008287699.tif 000063
2008287699.tif 000064