今日のデータ・ネットワークには、いくつかのリモート管理されたデータ・ネットワーク・デバイスが含まれる。 次第に、このようなデバイスのリモート管理はより複雑になってきており、これは、ネットワークへのサブスクライバが異なるサービスを要求してきたからであり、ネットワークのオペレータが新しい管理ツールを必要としてきたからである。

サブスクライバ、および、オペレータの管理上の必要性によって必要とされたサービスのすべてをサポートする能力は、重要な課題である。 今日、データ・ネットワーク・デバイスがいくつかの異なるデバイスに接続されることは珍しいことではなく、これらの異なるデバイスは「クライアント」または「エージェント」と呼ばれ（集合的に以下で「エージェント」と称する）、各々は別々のサービスをサブスクライバに供給する。 残念ながら、これらの各エージェントはデータ・ネットワーク・デバイスと、異なる「管理トランザクション要求」を使用して通信する。 例えば、これらの各エージェントは、構成変更をデータ・ネットワーク・デバイスに、異なるプロトコル、フォーマットおよび／または表現における命令を使用して送信しようと試みる場合がある。

このため、ルーターなど、データ・ネットワーク・デバイスは、多数の異なる管理トランザクション要求を解釈または変換するように設計されなければならない。 これにより、このようなデバイスを設計するコストが増す。

したがって、いかなる数のエージェントによっても、構成（または、場合によっては再構成）変更をデータ・ネットワーク・デバイスに通信するために使用することができる、共通管理トランザクション要求を提供することが望ましい。

あるソフトウェア言語は、拡張マークアップ言語（ＸＭＬ）と呼ばれ、そのうちでこのような共通管理トランザクション要求を作成することができるフレームワークまたは構造を作成するために、使用することができる言語としての将来性を発揮している。
ＸＭＬは、以前はネットワーク電気通信環境において使用されてきた。 ある技術は、ＸＭＬベースのネットワーク管理エージェントのためのアーキテクチャを作成しようとする。 しかし、今まで、この技術は、可能であると信じられた潜在的な柔軟性およびパフォーマンスの利益を実現できていない。

サブシステム・インタフェースに加えて、いくつかの主要なデータ・ネットワーキング機器ベンダーは、ＸＭＬベースの表現および技術を、ネットワーク管理システムおよび管理されたエージェント／デバイス内で使用している。 しかし、これらの表現および技術はそれらの欠点を有し、これは、これらの表現および技術がなお、構成コマンドをデータ・ネットワーク・デバイスに入力、送信し、処理するために著しい量の時間を必要とするからであり、または、これらの表現および技術が再構成プロセス中にデータ・ネットワーク・デバイスの構成を「ロック」させることを必要とするからである。 後者は、個々のユーザーの再構成が上書きされ、したがって失われる場合がある可能性を回避するために、データ・ネットワーク・デバイスに強制的に、個々のユーザーからの再構成に関連した管理トランザクション要求を一度に１つずつ処理させるので、望ましくない。

したがって、管理トランザクション要求を可能な限り高速に処理し、複数のユーザーが再構成ベースの管理トランザクション要求をデータ・ネットワーク・デバイスに、データ・ネットワーク・デバイスまたはそのサブシステムの１つの現在の構成をロックすることなく、送信することを可能にする、方法およびデバイスを提供することもまた望ましい。

あるタイプのプログラムは、コマンド・ライン・インタフェース（ＣＬＩ）と呼ばれ、一般に、構成に関連した管理トランザクション要求をデータ・ネットワーク・デバイス（例えば、ＴＣＰ／ＩＰルーター、マルチプロトコル・ラベル・スイッチング（ＭＰＬＳ）スイッチなど）に通信するために使用される。 しかし、ＣＬＩの開発に関係するコストのために、既存のＣＬＩは、データ・デットワーク・デバイスを再構成する、機能的に完全または効率的な手段を提供しない。

したがって、データ・ネットワーク・デバイスまたは関連付けられたサブシステムの管理機能への全アクセスを提供する、ＣＬＩを提供することが、追加として望ましい。
構成情報をデータ・ネットワーク・デバイスに送信することができることに加えて、ユーザーはまた、データ・ネットワーク・デバイスの１つまたは複数のサブシステムの現在の構成を定期的に得る必要もある。

したがって、このような構成を、共通管理トランザクション要求を使用して得るための手段を提供することがさらに望ましい。

我々は、「ＸＰａｔｈ表現」を含むように生成されたＸＭＬ管理トランザクション要求（以下で「ＸＭＬ要求」と称する）を、データ・ネットワーク・デバイスの１つまたは複数のサブシステムを再構成するため、または、このようなサブシステムの現在の構成を得るための、共通の管理トランザクション要求を作成するための構造として使用することができると認識している。

このようなＸＭＬ要求は、複雑な管理トランザクションに関連付けられるＸＰａｔｈ表現を含むことができる。 このような要求の実行により、ＸＰａｔｈ表現がパターン・マッチング表現として、例えば、実質的に同じ時間に変更などがされるべきである、所与のサブシステム構成のいくつかの異なる要素を識別することが可能となる。 これにより、データ・ネットワーク・デバイスまたは関連付けられたサブシステムを再構成する時間およびコストが削減される。

Ｘｐａｔｈ表現を含むＸＭＬ要求の使用により、使いやすいＣＬＩまたは他の類似のエージェントの設計もまた可能となる。
本発明によって提供された各エージェントは、同じＸＭＬ要求構造を使用して要求を生成するので、これらの要求を、データ・ネットワーク・デバイス内の中央管理モジュール（ＣＭＭ）などによって、高速に処理することができる。

ＣＭＭは、１つの共通構造を使用してトランザクションを処理することのみを必要とするので、データ・ネットワーク・デバイスを設計するコストを削減することができる。
小規模データ・ネットワークがこの共通のＸＭＬ要求構造を利用することができることを確認するために、本発明は、受信されたＸＭＬ要求を、ＸＰａｔｈ表現を含まない、拡張された内部要求に変換することに備える。 これは、ＸＰａｔｈ表現を処理することができないデータ・ネットワーク・デバイスの所与のサブシステムが、それにもかかわらず、ＸＰａｔｈ表現を処理することなくＸＭＬ要求を処理することを可能とするために行われる。 これにより、このようなサブシステムのコストが低く保たれる。

代替として、このようなサブシステムのリソース使用が最大の関心事ではない、より大規模なデータ・ネットワーク・デバイスでは、本発明は追加として、ＸＭＬ要求を、その中に含まれたＸＰａｔｈ表現を含めて処理のためにサブシステム上に渡す、ＣＭＭに備える。

このとき図１を見ると、本発明の一実施形態によるデータ・ネットワーク１が図示される。 図のように、ネットワーク１は、１つまたは複数のエージェント３０ａ、３０ｂ、． ． ． ３０ｎ（ただし「ｎ」は最後のエージェント）を含み、各エージェントは、パスウェイ４０を介してＣＭＭ１０に接続されたＸＭＬインタフェース３１ａ、３１ｂ、． ． ． ３１ｎを含む。 ＣＭＭ１０は、データ・ネットワーク・デバイスの一部であり、ルーター、ＭＰＬＳスイッチなどである。 ＣＭＭ１０は、外部ＸＭＬ要求を１つまたは複数のエージェント３０ａ、３０ｂ、． ． ． ３０ｎから受信するための、入出力（Ｉ／Ｏ）ユニット１１を含むことができる。 ＸＭＬ要求を受信すると、入出力ユニット１１を、これらの要求をパーサー１２に転送するように動作可能にすることができ、パーサー１２は、格納ＸＭＬスキーマ・セクション１３を使用して、受信された各要求の構文を妥当性検査するように動作可能である。 以下でさらに説明するように、受信された各ＸＭＬ要求の構文の妥当性検査はオプショナルであることを理解されたい。 引き続き、ＣＭＭ１０はまた、ＤＯＭツリー・セクション１４を含むようにも図示され、ＤＯＭツリー・セクション１４は、サブシステム２０ａ、２０ｂ、． ． ． ２０ｎのすべての構成を表現する全体のＤＯＭツリーを格納するように動作可能である。 ＤＯＭツリー・セクション１４はまた、受信された各ＸＭＬ要求が、サブシステム２０ａ、２０ｂ、． ． ． ２０ｎのうち１つに含まれた構成要素を含むかどうかを判断することにおける工程として、受信された各ＸＭＬ要求を表現する１つまたは複数のＤＯＭツリーを生成するようにも動作可能である。 別の言い方では、ＤＯＭツリー・セクション１４を、ＸＳＬＴセクション１５と共に使用して、各要求のセマンティクスを妥当性検査することができる。 これもまたオプショナルである。

ＣＭＭ１０内にまた、比較セクション１６、変換セクション１７およびコントロール・セクション１８も図示される。 これらのセクションのオペレーションを、以下でより詳細に論じる。

本発明の一実施形態では、図１のサブシステム２０ａ、２０ｂ、． ． ． ２０ｎの各々は、ＸＭＬ要求を受信するように動作可能であり、これらのＸＭＬ要求は、それらの構成を変更すること、状態情報（例えば、カウンタの値）へのアクセスを可能にすること、またはそうでない場合はサブシステムを管理することができる。 代替として、各サブシステム２０ａ、２０ｂ、． ． ． ２０ｎは、仮想ＤＯＭツリー・インタフェース２１ａ、２１ｂ、． ． ． ２１ｎを含むことができる。 アドホック・クエリがＸＰａｔｈ表現、ＸＱｕｅｒｙ表現またはプログラミング言語スクリプトの形態でサブシステムに送信されるとき、インタフェース２１ａ、２１ｂ、． ． ． ２１ｎは必要である。 サブシステム２０ａ、２０ｂ、． ． ． ２０ｎはＣＭＭ１０に、パスウェイ５０などを使用して接続され、エージェント３０ａ、３０ｂ、． ． ． ３０ｎに、パスウェイ７０によって接続される。

別々のセクションとして図示するが、ＣＭＭ１０を構成するセクションの各々を結合してより少数のセクションを形成することができ、あるいは代替として、分解してさらに追加のセクションを形成することができることを理解されたい。 本発明の一実施形態では、エージェント、インタフェース、ＣＭＭ、ＣＭＭセクションおよびサブシステムの各々を、ソフトウェア、ファームウェア、ハードウェア、またはこれら３つのある組み合わせにおいて実施することができる。 ソフトウェアまたはファームウェアの場合、各々は、上述および後述の本発明の特徴および機能を実行することができる、１つまたは複数のプログラムまたはプログラム・コンポーネントを含むことができる。

図１に示すコンポーネントのオペレーションを論じる前に、このとき図２を参照し、図２では、本発明の一実施形態による、生成された外部ＸＭＬ要求の一実施例が示される。

前述のように、共通管理トランザクション要求構造の使用は、ルーターおよびスイッチなど、データ・ネットワーク・デバイスを設計することに関連付けられたコストを大幅に削減するようになる。 これを理解して、本発明者は、ＸＭＬ表現された管理トランザクション要求の新しい構造または形式を発見した。 すなわち、本発明者は、ＸＰａｔｈ表現を含んだＸＭＬ表現された管理トランザクション要求が、複雑な管理トランザクションが以前に可能だと考えられたよりも高速に実行されることを可能にすることを発見した。 これは、部分的には、ＸＰａｔｈ表現がパターン・マッチング表現として動作して、サブシステム内で１つまたは複数のターゲット構成要素を識別するという事実による。 複雑なトランザクションを、ＸＰａｔｈ表現を使用して実行するための能力は、複雑なトランザクション要求のほぼ同時処理を、最小のロッキング要件により可能にする。 相対的に、既存のＸＭＬスキームは、データ・ネットワーク・デバイスの構成が、延長された期間に渡ってロックされて、複雑なトランザクション要求を複数のソースから受信することが可能になることを必要とする。

図２に示す外部ＸＭＬ要求２００は、一連の異なるセグメントから構成される。 説明を容易にするため、これらのセグメントのうちいくつかのみを論じる。 図のように、要求２００は、要求名セグメント２０１、そのうちの１つがセグメント２０２である、１つまたは複数の属性名セグメント、および、ＸＰａｔｈ表現セグメント２０３を含む。

一般に、角括弧「＜＞」は、ＸＭＬ開始タグまたはＸＭＬ終了タグを描く。 ＸＭＬ要求２００は開始タグ３０１で開始し、終了タグ３０２で終了する。 開始タグ３０１内に、要素の「属性」がリストされる。

属性名セグメント２０２は、ＸＰａｔｈ表現セグメント２０３内に含まれた属性値２０４に関連付けられる。 属性値２０４および属性名セグメント２０２を使用して、ＸＭＬ要求２００のターゲットを識別することができる。

本発明の一実施形態では、要素名セグメント２０１は、サブシステムの構成の少なくとも１つのターゲット構成要素上で実行されるべきオペレーションを指示して、例えば、ＣＭＭ１０に関連付けられたサブシステム２０ａ、２０ｂ、． ． ． ２０ｎのオペレーションを再構成する。

上述のように、ＸＰａｔｈ表現が実行されるとき、ＸＰａｔｈ表現はパターン・マッチング表現としての機能を果たす。 具体的には、ＸＰａｔｈ表現は、例えば、要素のシーケンス２０４がＸＭＬ構成ツリー内でネストされる順序で、要素のシーケンス２０４によって定義されたパスに従うことによって、ターゲット構成要素を識別する。

つまり、本発明によって提供されたＸＭＬ要求を使用することによって、ユーザー６０によって最初に発信された単純または複雑な管理トランザクション要求のターゲットである、サブシステム内の構成要素を、高速に識別することができる。 実際に、以前に可能であると考えられたよりもはるかに高速である。

図２に示す要素名を「ａｄｄＲｅｑｕｅｓｔ」として示すが、いくつかの要素名を使用することができることを理解されたい。 本発明のさらなる実施形態では、要素名セグメント２０１を、２、３例を挙げると、ａｄｄＲｅｑｕｅｓｔ、ｄｅｌｅｔｅＲｅｑｕｅｓｔ、ｍｅｒｇｅＲｅｑｕｅｓｔ、ｒｅｐｌａｃｅＲｅｑｕｅｓｔ、ｇｅｔＲｅｑｕｅｓｔおよびｃｏｍｍａｎｄＲｅｑｕｅｓｔからなるグループから選択することができる。
ＸＭＬ要求は、１つまたは複数の構成要素を識別するＸＰａｔｈ表現を含むので、ＸＰａｔｈ表現は、ユーザー６０によって１つまたは複数のエージェント３０ａ、３０ｂ、． ． ． ３０ｎに入力された元の管理トランザクション要求のターゲットを含む、と言うこともできる。

やや引き返すと、図２に示すＸＭＬ要求２００を、１つまたは複数のエージェント３０ａ、３０ｂ、． ． ． ３０ｎによって生成し、次いでＣＭＭ１０に送信することができることを理解されたい。 このＸＭＬ要求を後述の他のＸＭＬ表現された管理トランザクション要求と区別するために、このタイプのトランザクションを「外部ＸＭＬ要求」と称しており、以下でもそのように称する。 また、ＸＭＬ要求２００を、エージェント３０ａ、３０ｂ、． ． ． ３０ｎから離れて、例えば、ＸＭＬ要求ジェネレータ８０（例えば、リモート管理システム、サーバーなど）によって生成し、次いで、エージェント３０ａ、３０ｂ、． ． ． ３０ｎにダウンロード、またはそうでない場合は入力することができることも理解されたい。

上述のように、本発明によって提供されたＸＭＬ要求は、複雑な管理トランザクションを表現するＸＰａｔｈ表現を含むことができる。 このような複雑なトランザクションは、複数のターゲット構成要素が同時に再構成または変更されることを必要とする場合がある。 これに関して、本発明は、複数のターゲット構成要素上で実行されるべきオペレーションを指示する要素名セグメント、複数のターゲット構成要素の各々に関連付けられた属性名を含む属性名セグメント、および、複数のターゲット構成要素の各々に関連付けられた属性値を含むＸＰａｔｈ表現セグメントを含む、ＸＭＬ要求を提供する。

上述のように、ＣＭＭ１０によってパスウェイ４０に沿って受信されるＸＭＬ要求は、１つまたは複数のエージェント３０ａ、３０ｂ、． ． ． ３０ｎで発生する。 これらのエージェントは、本発明によって提供された新規なエージェントである。

具体的には、エージェント３０ａ、３０ｂ、． ． ． ３０ｎの各々は、新規なＸＭＬインタフェース・セクション３１ａ、３１ｂ、． ． ． ３１ｎを含むことができ、これらのＸＭＬインタフェース・セクションは、１つまたは複数の従来の管理トランザクション要求をユーザー６０から受信するように動作可能である。 １つまたは複数の要求を受信すると、各ＸＭＬインタフェース・セクション３１ａ、３１ｂ、． ． ． ３１ｎは、少なくとも１つのＸＭＬ要求（ＸＰａｔｈ表現を含む）を、受信された従来の要求毎に生成するように動作可能である。 １つまたは複数の受信された従来の管理トランザクション要求は、単純または複雑な管理トランザクションを含むことができる。

生成されたＸＭＬ要求の構造は、図２に示すような類似の構造に従う。

エージェント３０ａ、３０ｂ、． ． ． ３０ｎは、いくつかのタイプのエージェントを含むことができ、これらのエージェントには、２、３例を挙げると、ＣＬＩクライアント、ＨＴＴＰ／ＳＯＡＰクライアント、ＳＮＭＰエージェントまたはスクリプト・クライアントが含まれる。 ＣＬＩは、実際には、本発明の目的のクライアント／エージェント全体の一部でしかない場合があるが、ＣＬＩエージェントという用語は、特に明記しない限り、または、以下の考察の文脈が別のように示さない限り、単にＣＬＩを指す。

ＸＭＬ要求の生成に加えて、エージェント３０ａ、３０ｂ、． ． ． ３０ｎの各々をさらに、そのように生成された各ＸＭＬ要求の構文を、ＸＭＬスキーマを使用して妥当性検査するように、動作可能にすることができる。 一般的に言えば、ＸＭＬスキーマを文法または語彙と見なすことができる。 本発明のさらなる実施形態では、エージェント３０ａ、３０ｂ、． ． ． ３０ｎの各々は、生成された各ＸＭＬ要求が、要求をＣＭＭ１０上に送信することに先立ってＣＭＭ１０によって認識可能である語彙／文法に準拠することを検証するために、この文法または語彙を使用するように動作可能である。 このように、認識可能な構文（例えば、認識可能な要素名、属性名）を含まない要求は、ＣＭＭ１０に到達することを防止される。 認識不可能な要求は、無害のエラーの結果となる場合があり、あるいは代替として、ＣＭＭ１０をハッキングまたは中断しようとする、より故意の試みの結果となる場合がある。

本発明のさらなる実施形態では、ＣＬＩエージェント３０ａをさらに、ユーザー６０との１つまたは複数のインタラクティブなセッションを生成するように動作可能にすることができる。 例えば、ＣＬＩエージェント３０ａは、ユーザー・コマンド・フィードバック、文脈依存ヘルプ、モーダル・ビヘイビア、および、ＸＭＬスキーマを使用する他のカスタマイズされた機能からなるグループから少なくとも選択された機能を含む、セッションを生成することができる。 別の言い方では、ＣＬＩエージェント３０ａはユーザー６０に、ＸＭＬスキーマに準拠する、カスタマイズされた文脈依存ＸＭＬ要求をインタラクティブに作成する機会を提供する。

ＸＭＬスキーマを各エージェント３０ａ、３０ｂ、． ． ． ３０ｎ内に格納することができるが、本発明の代替実施形態では、エージェント３０ａ、３０ｂ、． ． ． ３０ｎの各々を、ＸＭＬスキーマをＣＭＭ１０から、または、リモート・ネットワーク管理システムからなど、リモート・デバイスから受信するように、動作可能にすることができる。

ＸＭＬスキーマを受信すると、エージェント３０ａ、３０ｂ、． ． ． ３０ｎの各々を、ＸＭＬスキーマを例えばプログラムにロードするように動作可能にすることができる。 このようなプログラムを、ＸＭＬ要求の構文を妥当性検査するように動作可能にすることができる。

さらに、本発明のさらなる実施形態では、ＣＬＩエージェント３０ａ内のＸＭＬインタフェース３１ａは、増補されたＸＭＬスキーマを受信する（あるいは、増補されたＸＭＬスキーマを格納する）ことができる。 この増補されたＸＭＬスキーマは、ユーザー６０とＣＬＩエージェント３０ａの間の対話をカスタマイズする、追加の命令を含む。 図３は、本発明の一実施形態による、増補されたＸＭＬスキーマの一実施例を示す。 増補されたＸＭＬスキーマを使用して、コマンド・モードおよび関連付けられたコマンド・ライン・プロンプトを定義することができ、ＩＳＯのような「ｎｏ」プレフィックスを、例えばコマンドに適用することができるときを定義することができる。

管理されたデバイスから機能が追加または除去されるとき、エージェント３０ａ、３０ｂ、． ． ． ３０ｎによって使用されたＸＭＬスキーマを増補することができる。

ＣＬＩエージェント３０ａをさらにユーザー・フレンドリーにするために、本発明は、ユーザー６０にコマンド履歴、コマンド完了プロンプト、およびコマンド・ライン編集を提供するＣＬＩを提供する。

前述のように、各エージェントは、同じＸＭＬ要求構造を使用して、要求を生成する。 このため、ＣＭＭ１０によって受信された管理要求はすべて共通の管理トランザクション要求構造に準拠し、これは、ＣＭＭ１０および／またはＣＭＭ１０がその一部であるデータ・ネットワーク・デバイスの設計を削減する助けとなる。

新しいＸＭＬ要求構造、および、新しいＸＭＬ要求を生成するための方法を発明した後、本発明者は、このような要求を処理することができる新しいＣＭＭも提供される必要があることを理解した。

一般に、今日存在するＣＭＭは２つのタイプがあり、すなわち、限定リソースを有するもの、および、相対的に言うと、無制限のリソースを有するものである。 別の言い方では、高度な処理を実行することができるサブシステムを含むＣＭＭが存在する。 これらは相対的に無制限のリソースのＣＭＭである。 対照的に、いくつかのＣＭＭは、限定量の処理のみが可能であるサブシステムを含む。 これらは、限定リソースＣＭＭである。 ＣＭＭが、限定リソースを有するサブシステムを含むか、無制限リソースを有するサブシステムを含むかに応じて、受信されたＸＭＬ要求をＣＭＭがどのように処理することができるかが決定する。

まず、限定リソースＣＭＭを論じる。
サブシステムが限定リソースを有する場合、ほとんど確実に、サブシステムはＸＰａｔｈ表現を処理することができないようになる。 したがって、１つまたは複数のエージェント３０ａ、３０ｂ、． ． ． ３０ｎから受信された外部ＸＭＬ要求は、ＸＰａｔｈ表現を含まない要求に変換されなければならない。 本発明の一実施形態では、ＸＰａｔｈ表現を含む少なくとも１つのＸＭＬ要求を受信すると、ＣＭＭ１０は、要求内の属性名および属性値に関連付けられた少なくとも１つのサブシステム２０ａ、２０ｂ、． ． ． ２０ｎを識別するように動作可能である。 識別されたサブシステムが限定リソースを有するとき、ＣＭＭ１０はさらに、受信された要求を、ＸＰａｔｈ表現を含まない拡張された内部要求に変換するように動作可能である。 ＣＭＭ１０はさらに、次いで、拡張された内部要求を、識別されたサブシステム上に転送するように動作可能である。 このタイプのＸＭＬ要求を、エージェントから受信された外部要求と区別するために、この要求を「内部」ＸＭＬ要求と称する。 拡張された内部ＸＭＬ要求の一実施例を図４に示す。 図４に示す要求は、図２に示す外部ＸＭＬ要求の拡張バージョンである。

このサブシステムの識別を、例えば比較セクション１６と共に、コントロール・セクション１８によって実行することができる。

具体的には、サブシステムを識別するため、ＣＭＭ１０は最初に「所有権登録」を１つまたは複数のサブシステム２０ａ、２０ｂ、． ． ． ２０ｎから受信することができる。 これらの所有権登録は、どの構成要素がどのサブシステム内に含まれるかを指示する。 その後、特定のサブシステムを識別するために、ＣＭＭ１０をさらに、１つまたは複数の所有権登録を、受信されたＸＰａｔｈ表現内のターゲット構成要素と比較するように、動作可能にすることができる。 一致が生じる場合、これは、受信されたＸＭＬ表現が、最終的にＸＰａｔｈ表現に一致した所有権登録を以前に供給していた特定のサブシステム上に転送されるべきであるという指示である。

このような一致が生じるとき、ＣＭＭ１０を、変換セクション１７を使用して、例えば、受信された外部ＸＭＬ要求を、ＸＰａｔｈ表現を含まない拡張された内部要求に変換するように、動作可能にすることができる。 その後、ＣＭＭ１０を、入出力セクション１１を介して、例えば、拡張された内部要求を、識別されたサブシステム上に転送するように、動作可能にすることができる。 再度、識別されたサブシステムが限定リソースを有し、したがって、ＸＰａｔｈ表現を処理することができないと仮定される。

時として、あるサブシステムに、変更が他のサブシステムに行われていることが通知されることが望ましい。 これを理解して、本発明は、１つまたは複数の「通知登録」を１つまたは複数のサブシステム２０ａ、２０ｂ、． ． ． ２０ｎから受信することができる、ＣＭＭ１０を提供する。 これらの通知登録は、サブシステムが、特定の変更が別のサブシステムに行われるたびに通知を受信することを望むことを、ＣＭＭに知らせるための方法である。 具体的には、ＣＭＭ１０は、これらの登録のうち１つまたは複数を受信するように動作可能であり、各登録は、別のサブシステムの構成内の少なくとも１つの構成要素に関連付けられる。 ＣＭＭ１０が、通知登録に関連付けられた構成要素の１つを含むＸＰａｔｈ表現を含むＸＭＬ要求を受信するとき、ＣＭＭ１０はさらに、通知メッセージを１つまたは複数のサブシステム２０ａ、２０ｂ、． ． ． ２０ｎに転送し、それがこのようなＸＭＬ要求を受信していることをサブシステムに通知するように動作可能である。 このように、受信されたＸＭＬ要求は、通知登録を発信したサブシステム上に送信されないが、それにもかかわらず、サブシステムには、別のサブシステムに行われた変更を追跡するために、このようなＸＭＬ要求の受信が通知される。

いくつかのＣＭＭは、相対的に無制限のリソースを有するサブシステムを含む。 このような場合、受信されたＸＭＬ要求を、ＸＰａｔｈ表現を除去する内部要求に変換する必要はない。 その代わりに、本発明のさらなる実施形態では、ＣＭＭ１０が、ＸＭＬ要求内の属性名および属性値に関連付けられる少なくとも１つのサブシステム２０ａ、２０ｂ、． ． ． ２０ｎを識別した後、ＣＭＭ１０は、受信されたＸＭＬ要求を、そのように識別されたサブシステム上に転送するように動作可能である。 その後、サブシステムは、要求をＸＰａｔｈ表現と共に処理することができる。

今までは、受信されたＸＭＬ要求の構文およびセマンティクスの両方が適切であったこと、または、エージェントが両方を妥当性検査していることが仮定された。 本発明の追加の実施形態では、ＣＭＭ１０はさらに、各要求の構文およびセマンティクスを、このような要求をサブシステム上に転送する前に、妥当性検査するように動作可能である。 特に、本発明のさらなる実施形態では、ＸＰａｔｈ表現を含む少なくとも１つの外部ＸＭＬ要求を受信した後、ＣＭＭ１０は、この要求の構文を、格納されたＸＭＬスキーマを使用して妥当性検査するように動作可能である。 この妥当性検査をパーサー１２によって、１つまたは複数のＸＭＬスキーマを格納するように動作可能であるＸＭＬスキーマ・セクション１３と共に、実行することができる。 セクション１３内に格納されたＸＭＬスキーマの構成は、例えば、ＣＭＭ１０の機能に応じて変わる場合がある。 前述のように、入ってくる各要求の構文を妥当性検査することは、オプショナルであることを理解されたい。 いくつかの場合、これは、不適切な構文におけるいかなる要求、特に、ハッカーまたは他者によって有害な意図により生成されているものを除去するために、望ましい。

各外部ＸＭＬ要求の構文を妥当性検査することに加えて、ＣＭＭ１０はまた、各要求のセマンティクスを、サブシステム２０ａ、２０ｂ、． ． ． ２０ｎの全体の構成を表現する集中ＤＯＭツリーを使用して、妥当性検査することもできる。 すなわち、受信された要求が適切な構文（例えば、要素名）を有する場合があるとしても、このような要求は、サブシステム２０ａ、２０ｂ、． ． ． ２０ｎのいずれの内部にも存在しない属性値を含む場合がある。 このような場合、時間を節約するために、要求をサブセクション上に転送して、エラー・メッセージを戻させるのではなく、ＣＭＭ１０はさらに、無効なセマンティクスを有するいかなる要求をも識別し、次いでエラー・メッセージを、発信元のエージェントまたは要求のソースに戻すように動作可能である。

ＣＭＭ１０は、このセマンティック妥当性検査を、ＸＳＬＴセクション１５と共に、ＤＯＭツリー・セクション１４を使用して実行することができる。 具体的には、外部ＸＭＬ要求を受信すると、ＤＯＭツリー・セクション１４を、受信された要求に関連付けられたＤＯＭツリーを生成するように動作可能にすることができる。 その後、ＤＯＭツリー・セクション１４を、ＸＳＬＴセクション１５と共に、ＤＯＭツリー内で少なくとも１つのターゲット構成要素を識別するように動作可能にすることができる。 生成されたＤＯＭツリー内でターゲット構成要素を識別すると、ＤＯＭツリー・セクション１４を、ＸＳＬＴセクション１５と共に、セクション１４内に格納されたサブシステム２０ａ、２０ｂ、． ． ． ２０ｎの構成全体を表現する集中ＤＯＭツリーを探索するように、動作可能にすることができ、これは、集中ＤＯＭツリーが識別された要素に対する一致を含むかどうかを判断するためである。 そうである場合、ＤＯＭツリー・セクション１４はさらに、一致され識別された要素に関連付けられるサブシステムを識別するように動作可能である。 一致がない場合、ＤＯＭツリー・セクション１４は命令を、エラー・メッセージを生成するコントロール・セクション１８などに送信するように動作可能である。

引き続き、一致が発見されるとき、要求を、識別されたサブシステム上に転送することができる。 前述のように、識別されたサブシステムが、限定リソースを有するものである場合、この要求は、ＸＰａｔｈ表現を含まない拡張された内部要求に変換されなければならない。 他方では、サブシステムが相対的に無制限のリソースを有する場合、ＸＰａｔｈ表現を含む元のＸＭＬ要求を、識別されたサブシステム上に転送することができる。

これまで、本発明によって提供された新規なＸＭＬ要求、エージェントおよびＣＭＭを論じた。 残るものは、本発明によって提供された新規なサブシステムを論じることである（しかし、これらのすべては相互に関係がある）。

前述のように、各サブシステム２０ａ、２０ｂ、． ． ． ２０ｎは、所有権または通知登録を生成することができ、これらの所有権または登録通知はＣＭＭ１０に送信され、これは、各サブシステム内に格納される構成要素の指示をＣＭＭ１０に提供するため、および、所与のサブシステムが監視することを望む他のサブシステムのある種のリストをＣＭＭ１０に提供するためである。 サブシステムが無制限リソースを有するとき、サブシステムを、ＣＭＭ１０に関して上述した構文およびセマンティクス妥当性検査を実行するように動作可能にすることができる。

本発明のさらに追加の実施形態では、サブシステム２０ａ、２０ｂ、． ． ． ２０ｎの各々は、仮想ＤＯＭツリー・インタフェース２１ａ、２１ｂ、． ． ． ２１ｎを含むことができる。 これらの各インタフェースを、管理トランザクション要求を受信し、次いで要求に基づいて、（ａ）関連付けられたサブシステムの現在の構成を戻すように、または、（ｂ）関連付けられたサブシステムの構成を修正するように、動作可能にすることができる。

受信された要求のタイプは変わる場合がある。 本発明の一実施形態では、要求を、少なくとも１つのターゲット構成要素を含むＸＰａｔｈ表現を含む、ＸＭＬ要求にすることができる。 本発明のもう１つの実施形態では、要求はＸＱｕｅｒｙ表現を含むことができる。 本発明のさらにもう１つの実施形態では、要求はプログラミング言語スクリプトを含むことができる。

いずれにしても、所与の仮想ＤＯＭツリー・インタフェース２１ａ、２１ｂ、． ． ． ２１ｎが要求を受信した後、この仮想ＤＯＭツリー・インタフェースはさらに、関連付けられたサブシステム構成を探索して、その構成が、要求に含まれた少なくとも１つのターゲット構成要素の一致を含むかどうかを判断するように、動作可能である。 一致が発見されるとき、インタフェース２１ａ、２１ｂ、． ． ． ２１ｎはさらに、発見されたいかなる一致する要素をも戻すように動作可能である。

具体的には、要求を受信すると、各インタフェース２１ａ、２１ｂ、． ． ． ２１ｎは、ＸＭＬ ＤＯＭ ＡＰＩを、構成および状態情報（例えば、カウンタの値など）に適用し、サブシステムを構成するように動作可能である。 その後、各インタフェースは、ＸＰａｔｈ、ＸＱｕｅｒｙまたはプログラミング言語スクリプトを仮想ＤＯＭツリーへ、適用されたＡＰＩを使用して適用して、一致があるかどうかを判断し、あるいは、スクリプト指示処理（例えば、カウンタの値を抽出するなど）を実行するように、動作可能である。 一致が発生する場合、一致する構成または状態要素は、応答のＸＭＬメッセージにおいて戻される。 そうでない場合、エラー・メッセージが、例えば１つまたは複数のエージェント３０ａ、３０ｂ、． ． ． ３０ｎに戻される。 元のＸＭＬ要求がプログラミング言語スクリプトを含んだ場合、このスクリプトに応答して生成されたいかなる出力も、応答のＸＭＬメッセージのコンテンツ内で戻される。

スクリプトがインタフェース２１ａ、２１ｂ、． ． ． ２１ｎによって受信されるとき、インタフェースを、例えば適切な一致が発見されるとき、スクリプトのコンテンツに基づいて、関連付けられたサブシステムの構成を修正するように動作可能にすることができる。

上述の考察は本発明の実施例を示すように試みており、本発明の真の範囲は、以下に続く特許請求の範囲によって決定される。

本発明の一実施形態による、ＸＭＬ要求を利用するデータ・ネットワークを示す図である。

１つまたは複数のエージェントによって生成された、ＸＰａｔｈ表現を含む、外部ＸＭＬ要求の簡易化された実施例を示す図である。

本発明の一実施形態による、ＸＭＬ要求を妥当性検査するため、および、ＸＭＬスキーマ・ドリブンのＣＬＩのオペレーションを指示するために使用される、増補されたＸＭＬスキーマを示す図である。

本発明のもう１つの実施形態による、ＣＭＭなどによって拡張されておらず、１つまたは複数のサブシステムによる使用のためのＸＰａｔｈ表現を含まない、内部ＸＭＬ表現された管理トランザクション要求を示す図である。