JP2005522939A - 通信ネットワークにおけるマネージャオブジェクトと被管理オブジェクトとの間の通信を編成するための方法、アーキテクチャー及びそのソフトウェア - Google Patents

Abstract

通信ネットワーク（Ｒ）を介して少なくとも１つのマネージャオブジェクトにより少なくとも１つの被管理オブジェクト（Ｂ１，．．．，ＢＮ）を管理するための方法であって、- データセット（１１００）に従って前記少なくとも１つの被管理オブジェクト（Ｂ１，．．．，ＢＮ）を管理するよう構成された少なくとも１つの中間オブジェクト又は階層型エージェント（ＡＧ）を設ける操作であって、前記管理が結果セット（１１０４）に変換される前記操作、- 前記データセット（１１００）を前記少なくとも１つのマネージャオブジェクト（Ａ）から前記中間オブジェクト（ＡＧ）に与える操作、- 前記少なくとも１つの中間オブジェクト（ＡＧ）を介して前記少なくとも１つの被管理オブジェクト（Ｂ１，．．．，ＢＮ）を管理し、前記結果セット（１１０４）を生成する操作、及び、- 前記結果セット（１１０４）を前記少なくとも１つの中間オブジェクト（ＡＧ）から前記少なくとも１つのマネージャオブジェクト（Ａ）に転送する操作（１１０８）を含む前記方法。好ましくは、マネージャオブジェクト（Ａ）と中間オブジェクト（ＡＧ）との間での通信では、ＵＤＰプロトコル及び圧縮されたモードが実施される。

Description

本発明は、電気通信ネットワークの場合に少なくとも１つのマネージャオブジェクト（以下、簡単に「マネージャ」という）と少なくとも１つの被管理オブジェクト（以下、簡単に「エージェント」という）との間の通信を確立するための方法に関する。

この目的に用いられる典型的な基準アーキテクチャーは、図１に示され、この図１は、電気通信ネットワークＲにより相互接続されたマネージャモジュールＡといくつかのエージェント要素Ｂ１，Ｂ２，Ｂ３，．．．との間の接続を示す。

このアーキテクチャーは、例えばＳＮＭＰ（シンプル・ネットワーク管理プロトコル）規格に記載されている。ドキュメントＲＦＣ１１５７、１９９０年改訂版が参照できる。

一般レベルでは、インターネットプロトコルアーキテクチャーは、一般にはアプリケーション（Ａ）、トランスポート（Ｔ）、ネットワーク（Ｎ）及びリンク（Ｌ）と称する４つの論理レベルを構成する。

図２に示されるように、各レベルは、実際は下のプロトコル内に入れ子になっている。例えば、アプリケーションレベルのプロトコル、例えば上記ＳＮＭＰ及びＴＦＴＰ、すなわち、Ｔｅｌｎｅｔ又はＦＴＰプロトコルは、下のプロトコル内に入れ子になっている。

具体的には、ＳＮＭＰ及びＴＦＴＰプロトコルは、ＵＤＰ（ユーザーデータグラムプロトコル）中に入れ子になっており、このＵＤＰが、ＩＰ（インターネットプロトコル）中に入れ子になっており、よって、ソフトウェアドライバ又はハードウェア装置によって符号Ｄで示した物理的キャリア（ケーブル、ファイバー、電波）内に注入されて物理レベル上のリンクＬを実現する。

同様に、Ｔｅｌｎｅｔ及びＴＦＴＰプロトコルは、ＴＣＰ（伝送制御プロトコル）中に入れ子になっており、このＴＣＰがＩＰプロトコル中に入れ子になっており、よって、物理的キャリア装置Ｌ中に注入される。

トランスポートレベル上のＴＣＰ及びＵＤＰの主要な特徴は以下の事項に関して説明し得る。

ＴＣＰは、システム通信向きのプロトコル（システムはネットワークアドレスにより識別される）であり、それが用いるソフトウェアにリンクされる。接続、すなわち、リモートシステムとの固定通信は、このプロトコルを用いる通信を確立する前に確立されなければならない。データ転送は、制御され保証されるが、特に不連続又は小さいときに遅い。この遅延は、ＩＰプロトコルの特性、及び各リクエストの後で接続が設定され、使用されない場合に通信の終了時にて解除、すなわち遮断されるということから生じる。この通信は、プロトコルと、通信の正確性を保証すべくデータ及び接続が受けるチェックとの複雑さゆえに、使用されるシステムリソースに関してコスト高となる。

逆に、ＵＤＰプロトコルは、プロセス通信向きであり、プロセス通信は、０〜６５５３５の範囲の数により各々が特徴付けられた論理ポートによって識別される。伝送では、該プロトコルは、様々なアプリケーションプロシージャからメッセージを受け取り、それらをＩＰプロトコルに送って伝送する。この機能は、多重化という。受信では、ＵＤＰプロトコルは、宛先アプリケーションプロセスを介してＩＰ層からデータパッケージを受け取る。この機能は、逆多重化という。

ＵＤＰプロトコルは、リソースの利用に関して十分に軽量であり、実行及び管理するのが簡単である。具体的には、これは、「ソースポート」、「宛先ポート」、「長さ」及び「チェックサム」に分割された簡潔な６４ビットのヘッダー（「ＰＤＵユーザーヘッダー」という）と、「ソースアドレス」、「宛先アドレス」、「フィルター」、「プロトコル型」、「長さＰＤＵ」フィールドを含んだ９２ビットのヘッダーとを用いる。

ＩＰ伝送プロトコルは処理又はチェックを必要としないので、ＵＤＰプロトコルは速い。すなわち、これは、可能な場合に単に現在のネットワークアドレスから宛先ネットワークアドレスに伝送する。

生来のＵＤＰプロトコルは、受信肯定応答メッセージを用いず、メッセージをソートせず、フローをチェックせず、よって、完全には安全又は確実でない。というのは、メッセージが、失われたり、拒否されたり、二重になったり、誤ったシーケンス中にて受信されたりし得るか、又は到着レートが、ネットワークにおけるアプリケーション及び受信プロセスの到着レートよりも高くなり得るからである。

伝送プロトコルとしてＵＤＰを用いる一般のプロセスアーキテクチャーは、図３に概略的に示した基準に従ってポートに関連付けられることを特徴とする。

受信及び伝送ポートに数を割り当てるために、２つの基本的な基準が用いられる。

第１の基準は、それぞれの数が公式に定められ総ての関係者に認められているような普遍的な割当を定めることに存する。

第２の基準は、動的束縛を定めることに存し、この動的束縛に従って、必要なときにはいつでもプログラムがポートを要求し、該ポートがネットワークソフトウェアにより割り当てられる。受信ポートは、たとえそれらが変更され得るとしても、通常は事前に割り当てられる。伝送ポートは、これら２つの方法のどちらかを用いて定めることができる。

具体的には、図３において、符号ＰＡは、一般的に、３つのそれぞれのポートを介してＵＤＰプロトコルとインターフェースをとる様々なアプリケーションプロセス（１，２，３．．．）を示す。

図４にさらに詳しく示されるように、ＵＤＰプロトコルに基づいた管理アーキテクチャーにおいてアプリケーションプロセスに加えて、「物理オブジェクト」及び「論理オブジェクト」と称される追加の統合コンポーネントが識別できる。

アプリケーションプロセスは、その時点で実行される役割に従って、符号Ａにより一般的に示されたマネージャ機能を有するオリジネータ・アプリケーションプロセスと、１つ（又はそれより多くの）宛先アプリケーションプロセス（エージェントという）とにさらに分けることができる。

用語「物理オブジェクト」は、アプリケーション操作に必要な他の物理オブジェクトをホストするハードウェアコンテナ又は媒体（例えば、パーソナルコンピュータ）に対して用いられる。このコンテナは、図４において符号Ｐ_１及びＰ_２で示されている。追加の物理オブジェクトは、物理（例えば、ＲＡＭ）及び／又は仮想（例えば、ファイル）処理メモリと、プロセス（ソフトウェア、基本ファームウェア、プロトコル、アプリケーション）を実行するためにハードウェア媒体（単数又は複数）により用いられる中央演算処理装置（ＣＰＵ）とを含む。この種のメモリは、図４において符号Ｒ_１及びＲ_２により示される。

図４では、符号Ｗが、オペレーティングシステムレベルのシステムソフトウェアを示し、符号Ｙ及びＺが、１以上のアプリケーションソフトウェア向きのプロトコル（トランスポート）からなるソフトウェア、及びネットワークＲとインターフェースをとるためのネットワークボード又はＣＲトランスデューサ向きのソフトウェア（この場合１以上のプロトコルからなる）を示す。

以下の説明では、アプリケーションプロセス、オブジェクト及びアーキテクチャーコンポーネントの間の関係を示す図４を参照する。システムソフトウェアＷは、処理メモリＲ_１、Ｒ_２の利用可能な部分を用いてシステム又は装置において割り当てられたタスクを実行するのに使用される。

システムＰ_１にあるプロセスＡは、両装置に必ず存在するコンポーネントＷ、Ｙ及びＺ、ネットワークボード並びに物理媒体を介して、システムＰ_２にあるプロセスＢとインターフェースをとる。

ソフトウェアコンポーネントＡ、Ｂ、Ｙ、Ｚ及びＷは、それらの特徴に基づいてメモリＲ_１、Ｒ_２のうちの一定量を使用し共用する。

最大使用可能バンドは、ネットワークＲの特性とネットワークボードＣＲの特性（これらは必ず一致しなければならない）に関連している。

図１に示した型のアーキテクチャーを用いる可能性は、いくつかの要因により制約される。

まず、ネットワークＲの最大利用可能バンドは、マネージャとエージェントの数、及び生成されたトラヒックの量により制約される。この利用可能バンドは、２つの装置のみ、すなわち、１つのマネージャと１つのエージェントのみが存在する場合にのみ最大となり得る。この利用可能バンドは、１つのマネージャと複数のエージェントが存在する場合には共用されなければならない。従って、マネージャとエージェントとの間の各通信に対する最大利用可能バンドは保証され得ない。

一般に、マネージャと複数のエージェントとの間の通信は、シーケンシャル戦略又はパラレル戦略により管理され得る。

シーケンシャル戦略において、マネージャは、エージェントとの通信を確立し、次の通信を続ける前に当該通信が終了するのを待つ。

パラレル戦略は、競合動的ポート割当機構を介してプロトコル（一般には、ＵＤＰすなわちユーザーデータグラムプロトコル）により提供される多重化及び逆多重化機能を利用し、複数のエージェントとのいくつかの同時通信を確立する。

シーケンシャル方法によると、マネージャ-エージェント出力バンド（すなわち、伝送される全メッセージサイズの合計を、それらを送るのに用いられる時間で割ったもの）と、マネージャ入力バンド（すなわち、各ノードマネージャが受信した全メッセージサイズの合計を、該マネージャがそれらを受信するのに要する時間で割ったもの、ここで、受信時間はエージェント処理時間の合計にネットワーク遅延を加えたものである）は両方とも、伝送及び受信時間が長いので、小さい。

パラレル方法によると、マネージャ-エージェント出力バンドは高く、入力バンドは非常に高くし得る。というのは、伝送及び受信時間が非常に短く、また、応答が要求よりもかなり長いからである。

図１に示した公知技術によるアーキテクチャーは、多くの制限及び欠点をもつ。

エージェントの数が一定値（例えば、千）を超えると、シーケンス伝送は効率的でない。アクティビティを完了するのに要する時間がかなり増大するからである。さらに、マネージャの同時のリクエストにより生成されたトラヒックと、エージェントにより生成された戻りトラヒックとが同時に生じ得るゆえに、図１のアーキテクチャーは、これも大規模なトラヒックバーストを発生する。これは、利用可能なバンド限界を超え得、よって、ネットワーク機能性の低下とメッセージの喪失を生じ得る。

パラレル方法は、異なるＵＤＰポートに割り当てられた複数のマネージャプロセスを用い、これは、ＲＡＭやＣＰＵなどのシステムリソースをすべて使い果たし得る。

アプリケーションプロセスにより用いられるプロトコル、例えば、前記ＳＮＭＰプロトコル又はＴＦＴＰ（Tｒｉｖｉａ Fｉｌｅ Tｒａｎｓｆｅｒ Pｒｏｔｏｃｏｌ）（ドキュメントＲＦＣ１３５０を参照）は、多量の情報を運ぶために、又は多数のプロトコルでネットワークにおいて稼働するために最適化されていない。加えて、これらのプロトコルは、ポイントツーポイント型であり、よって、マルチレベルアーキテクチャーを実現又は管理し得ない。

さらに、図１のアーキテクチャーに示されるように、すべてのエージェントは、マネージャにより何らかの方法にて直接連絡可能（ｒｅａｃｈａｂｌｅ）であるべきである。例えば、マネージャから異なるネットワークに接続されているゆえに、マネージャにより直接連絡できないエージェントは、管理用の専用マネージャを設置する必要がある。

本発明の目的は、前記欠点を解消することができる解決策を提供することである。

本発明によると、この目的は、特許請求の範囲に明確に記載した特徴を有する方法により達成される。本発明はまた、対応するネットワークアーキテクチャー及び対応するソフトウェア、すなわち、ソフトウェアが少なくとも１つのデジタル処理装置により実行されるとき、本発明による方法を実施できるソフトウェアコード部分を含んでデジタル処理装置のメモリに直接アップロードすることができるソフトウェアにも関する。

本質的に、本発明による解決策は、最適化されたマルチレベル管理アーキテクチャーを実現して複数の機器に対して管理アクティビティを細分し、それにより、従来の単一レベルアーキテクチャーを利用する必要性に関係した限界を克服する。これはすべて、特に物理マネージャリソースの利用を最適化する可能性に関して、当該バンドの使用を制限する。

要するに、本発明による解決策は、中間オブジェクト、すなわち、マネージャが制御されたエージェントに直接実行する管理アクティビティを実施すべくマネージャから十分な情報を受け取ることができる新しい型のエージェント（「階層型エージェント」をいう）を実現することに存する。

よって、後にさらに説明されているように、本発明による解決策は、圧縮ＵＤＰメッセージ転送方法との組合せにて使用される場合に適しかつ特に有利である。

図面の簡単な説明
以下、添付図面に関し、単なる例として本発明を説明する。
図１〜４は、公知技術に関するものであり、上記説明した。
図５は、本発明による新しい管理アーキテクチャーを一般的な用語にて示す。
図６は、本発明による解決策の第１の実施態様を示す。
図７は、本発明による解決策の第2の実施態様を示す。
図８は、本発明によるアーキテクチャーの動作論理例を示す。
図９は、本発明によるアーキテクチャー内の可能な通信管理図を示す。
図１０は、共用されるエージェント管理方法を示す。
図１１は、本発明によるいわゆる階層型エージェントのアーキテクチャーを示す。
図１２は、本発明の範囲内での構造の可能な編成及び階層型エージェントによりサポートされた制御のネスティングを示す。
図１３〜１５は、各々が伝送（ａ部分）及び受信（ｂ部分）に関する２つの部分に別れており、本発明による解決策のいくつかの好ましい実施態様をフローチャートにて示す。
図１６は、本発明による解決策のさらに一般的な特徴を示した別のフローチャートである。
図１７及び１８は、本発明の可能な２つの変形による解決策の別の可能な実施態様を示す。

図５は、本発明による一般的なアーキテクチャーを示す。

図１と直接比較すると、追加のモジュール、すなわち、階層型エージェントＡＧと称する中間オブジェクトが、相互にインターフェースをとるマネージャＡ及び複数のエージェントＢ１、Ｂ２、Ｂ３の存在に基づく本発明によるアーキテクチャー中に統合されている。

本質的に、階層型エージェントＡＧは、マネージャＡの同じ管理アクティビティをいくつかのエージェントＢ１、Ｂ２、Ｂ３（任意の数のエージェントが可能である）に実行するのに十分な量の情報をマネージャＡから受信するように、マネージャＡとインターフェースをとる。

本発明による解決策では、マネージャＡは、図５中にて符号ＢＫ，．．．，ＢＮで示された他のエージェントを保持し直接制御し続けることができる。

明らかに、任意数のエージェントＢ１，．．．，ＢＮ、及び階層型エージェントＡＧとマネージャＡの間での管理目的のための任意数の分割が実現できる。

図５に概略的に示されたアーキテクチャーは、マネージャ機能を二重にすることなくマルチレベルのアーキテクチャーを構成するのに使用される。というのは、新しい要素（すなわち、階層型エージェントＡＧ）が、必要なアクティビティを実施して所要の結果を得るために使用できるからである。

実際、階層型エージェントＡＧと称される中間オブジェクトは、エージェント（Ｂ１，Ｂ２，Ｂ３，．．．）として与えられることにより、マネージャＡから適切な形式のメッセージ、例えば、特定のプロトコル（ＳＮＭＰ、ＴＦＴＰ、Ｔｅｌｎｅｔ、ＤＮＳなど）を用いてネットワークアドレスにより識別される特定のエージェントに対して、マネージャＡにより要求されるアクティビティを実行するのに十分な情報を含んだＳＮＭＰメッセージを受信することができる。この要求されたアクティビティの後、ＡＧモジュールは、結果をマネージャＡに送る。マネージャＡと階層型エージェントＡＧの間の相互接続は、ネットワークＲ（図６に示された実施態様のような）を用いて、又は二重接続を介した異なるネットワーク（図７に示された実施態様、ここで、符号ＲＰ及びＲＡは２つのネットワークを示す）を用いて実現できる。

図７は、本発明による解決策の極度の柔軟性を示す。

具体的には、この図は、符号ＲＰにより示された第１ネットワークが、マネージャＡとマネージャＡにより直接管理され続けているエージェントＢ１との間の通信のために使用でき、マネージャＡと、符号ＲＡにより示された第２ネットワークにおけるエージェントＢ２及びＢ３の管理においてマネージャＡに「取って代わる」階層型エージェントＡＧとの間の通信が可能になることを示す。

本発明による解決策はまた、バンドに関してネットワーク（又は一般に複数ネットワーク）の使用を最適化する。

具体的には、アルゴリズム的圧縮は、好ましくは、アプリケーションプロトコル（ＳＮＭＰのＯＩＤ、ＵＤＰのペイロードなど）に含まれるデータに適用し、マネージャＡと階層型エージェントＡＧとの間の通信によるネットワークトラヒックを削減する。

本質的にこの方法は、（少なくとも）メッセージペイロードに対し、メッセージ中に周期的に現れるシーケンスの肯定応答に好ましくは基づいた圧縮操作を行うことに存する。特に好ましい方法では、この圧縮操作は、例えばｚＬｉｂなどのｇｚｉｐ方法に従って実行される。

この方法は、図１２以降に関して詳しく説明するが、より重要なデータ内容のほうを選んで、交換されたＰＤＵデータパッケージの数を削減する。

例えば、ＴＦＴＰプロトコルにおけるデータＰＤＵは、５１６バイトを使用し、よって、５２０Ｋｂのファイルを転送するのに１０１６パッケージが必要とされる。前記基準による圧縮の後では、５２０Ｋｂが４Ｋｂに削減され、このことは単一のＵＤＰデータパッケージ又はＳＮＭＰメッセージにてそれらを送ることができることを意味する。従って、転送は、「単一メッセージ」の代わりに「等価アプリケーションメッセージ」を運ぶことに存する。このことは、転送されるデータは等しいままで、生成されるトラヒックの量を削減できることを意味する。

説明した解決策はまた、当該アクティビティを実行するのに必要なシステムリソースを最適化するのに使用できる。

というのは、説明した解決策は、例えば図１０に示される基準に従って、複数の階層型エージェントＡＧに対してマネージャのアクティビティを分配するからである。この図では、符号ＡＧ１及びＡＧ２は、マネージャＡと協働していくつかのエージェントＢ１〜Ｂ５を管理する２つの階層型エージェントを示し、１以上のエージェント（示された例ではエージェントＢ３）の管理は、２つの階層型エージェントＡＧ１及びＡＧ２により分担されている。

その時点で空いているリソース（ＣＰＵ、ＲＡＭなど）を使用するために、複数の階層型エージェント上のマネージャＡのアクティビティを共用する可能性が活用できる。階層型エージェントＡＧ１及びＡＧ２により独占的にアクティビティの終わりにのみ生成されるマネージャＡへの戻りトラヒックは、階層型エージェントＡＧ１及びＡＧ２によりマネージャＡに転送される結果に存する。好ましくは、これは、圧縮された方法に従って、よって、サイズが中小でデータ内容が重要な少しのパッケージを用いることにより行われる。これらのパッケージは、圧縮解除と管理に必要なマネージャＡのシステムリソースに影響を与えない。

このようにして、図８に示されたように、マネージャＡと階層型エージェントＡＧ（簡単のため以下の説明ではこの種の単一モジュールを参照するが、複数の階層型エージェントモジュールへの拡張も明瞭に理解されるであろう）との間の相互作用は、マクロ-アクティビティの性能及び管理に有効な信号の交換に基づいている。

具体的には、符号１１００により示されるステップでは、マネージャＡが、メッセージの形式にて例えば、標準的又は圧縮されたＳＮＭＰメッセージを用いることにより、アクティビティリクエストを階層型エージェントＡＧに送る。符号１１０２により示されるステップでは、階層型エージェントＡＧが、当該リクエストを受信して分析し、情報の処理及び収集を開始する。処理中すなわちステップ１１０４中、階層型エージェントＡＧが、統計メッセージ及び進行中のアクティビティのステータスを同期させるためのメッセージをマネージャに送る。このことは、符号１１０６により示されたステップにおいて行われる。被管理オブジェクト、すなわちエージェントの管理アクティビティが終了すると、階層型エージェントＡＧは、その結果をマネージャＡに送る。このことは、符号１１０８により示されたステップにおいて行われる。符号１１１０により示されたステップでは、マネージャＡは、ステップ１１１２において結果の受信肯定応答メッセージを階層型エージェントに送ることによって、アクティビティの結果を受信し処理する。次いで階層型エージェントＡＧは、符号１１１４により示されたステップにおいて、要求されたアクティビティを終了する。

このサイクルは、得られた結果に従って、マネージャにより複数回繰り返され得る。例えば、いくつかのデータが不十分であるとされたならば、新しいリクエストが送られ得る。

図９は、階層型エージェントＡＧの高レベルの論理要素、及びアーキテクチャーの他のコンポーネントとの関係を示す。

図９は本質的に図５のアーキテクチャーに対応しており、図５では、マネージャＡが、いくつかのエージェントＢＫ，．．．，ＢＮを直接管理し、他のエージェントＢ１、Ｂ２及びＢ３の管理を階層型エージェントＡＧに委託していることに留意されたい。ネットワークＲのインターフェースを図６に示す。

マネージャＡは、例えば、標準的又は（好ましくは）圧縮されたＳＮＭＰメッセージを用いてＵＤＰプロトコルを実施する通信を介して、その直接のエージェント及び階層型エージェントＡＧとインターフェースをとる。

この目的のため、制御及び管理ロジックＬＣＧに加えて、階層型エージェントは、本質的にあたかもマネージャＡにより直接管理される別のエージェントであるように階層型エージェントＡＧがマネージャＡにより「見られ」得るように、階層型エージェントＡＧとマネージャＡとの間の通信を管理するための２つのモジュール（それぞれ符号ＡＲＸ及びＡＴＸにより示される）を備える。

階層型エージェントＡＧは、マルチマネージャモジュールＭＭをさらに備え、このマルチマネージャモジュールＭＭは、本質的に各エージェントが階層型エージェントＡＧをまるでそれがマネージャＡであるかのように「見る」ように、階層型エージェントＡＧとエージェントＢ１、Ｂ２、Ｂ３との間の通信を監督する。

マネージャＡと階層型エージェントＡＧのマルチマネージャコンポーネントは、標準的な方法／プロトコルを用いて様々なエージェントと通信する。

よって、図１０に示されるように、エージェント（図示された例ではエージェントＢ３）が、同じマネージャにより制御される１以上の階層型エージェントＡＧ１又はＡＧ２により管理され得る。

図１１は、結果管理と制御論理を実現するための、階層型エージェントＡＧの内部アーキテクチャーを示す。

好ましい方法では、本発明による解決策は、完全なメッセージ圧縮（符号ＭＨにより示されたヘッダー及びＰＤＵ）に基づいている。

具体的には、可能な２つの異なる転送方法又は態様が用いられる。
第一のものは、ＳＮＭＰメッセージを新しい圧縮ＳＮＭＰメッセージ中に入れ子にし、標準的なＵＤＰを用いてそれを送る。
第二のものは、ドライバを介してＵＤＰを直接制御し、データオクテットとしてＳＮＭＰメッセージ圧縮の結果を与える。

本質的に、この圧縮方法は、メッセージ中に周期的に現れるシーケンスの肯定応答に基づいている。

特に好ましい実施形態では、ＬＺ７７として知られている該方法の変形が、圧縮方法として用いられる（Ｚｉｖ．Ｊ．，Ｌｅｍｐｅｌ Ａ．，“Ａ Ｕｎｉｖｅｒｓａｌ Ａｌｇｏｒｉｔｈｍ ｆｏｒ Ｓｅｑｕｅｎｔｉａｌ Ｄａｔａ Ｃｏｍｐｒｅｓｓｉｏｎ”，ＩＥＥＥ Ｔｒａｎｓａｃｔｉｏｎｓ ｏｎ Ｉｎｆｏｒｍａｔｉｏｎ Ｔｈｅｏｒｙ，Ｖｏｌ．２３，Ｎｏ．３，ｐ．３３７?３４３参照）。この方法は、ＵＮＩＸ環境において周知である。これは、ｇｚｉｐ（ｇｚｉｐ形式-ＲＦＣ１９５２）といい、よく知られたＰＫＺＩＰアプリケーションによっても用いられる。この方法の規格は、公有財産である。様々な開発環境や動作システム、例えばＨＰ-ＵＸ、Dｉｇｉｔａｌ、ＢＥＯＳ、Ｌｉｎｕｘ、ＯＳ／２、Ｊａｖａ、Ｗｉｎ３２、ＷｉｎＣＥなどにおいて、これらの解決策を実施し用いるために、ソースライブラリが利用できる。

具体的には、アルゴリズムポーティングは、「ｚＬｉｂ」ライブラリを用いてＷｉｎ３２上にて使用できる。このライブラリの主な特徴は、バイナリデータ構造とストリングの両方のランタイム及びオンメモリ圧縮を可能にすることであり、これは、システム性能における基本的な要素である。

図１１は、図９に関して述べたＡＲＸモジュール及びＡＴＸを示す。

ＡＲＸモジュールは、メッセージをネットワークＲから収集し、それらを符号Ｇにより示された待ち行列管理モジュール中に含まれる入力待ち行列Ｉに送ることを専ら担当している。

対称的に、ＡＴＸモジュールは、待ち行列マネージャＧの出力待ち行列（符号Ｕにより示す）からメッセージを送ることを専ら担当している。

待ち行列マネージャ又はモジュールＧは、各クロックパルスにて、入力待ち行列Ｉ、出力待ち行列Ｕ及び符号Ｌにより示された別の待ち行列（稼働中の待ち行列という）からのメッセージを分析することを専ら担当している。

前記クロック信号は、符号Ｔにより示されたタイマーモジュール又はタイマーにより生成される。このタイマーモジュール又はタイマーは、待ち行列マネージャGの同期クロックを生成することを専ら担当している。

入力待ち行列Ｉ中のメッセージが取り出されてＤＣモジュールに送られる。このＤＣモジュールは、タイマーＴにより生成される各クロック信号でのさらなる処理のための、メッセージの解釈モジュール（及び好ましい実施態様では圧縮解除モジュールである。前記圧縮解除／解釈モジュールは、符号ＤＣにより示される。

さらに、稼働中の待ち行列Ｌ中のメッセージが、タイマーＴにより生成される各クロック信号にて分析され、一方、出力待ち行列Ｕ中のアクティビティステータスを示すメッセージが、待ち行列中の各メッセージに対して生成される。

タイマーＴからの各クロック信号にて、出力待ち行列Ｕ中のメッセージが、ＡＴＸモジュールを介してマネージャに伝送される。

さらに詳しくは、ＤＣモジュールは、入力待ち行列Ｉにより受信された各メッセージを分析し、もし必要ならそれを圧縮解除し、優先度に従ってそれを、実行すべきアクティビティの方法及び種類を示すアクティビティ協働モジュールＣＡに送ることを専ら担当している。

本質的にＣＡモジュールは、以下の事項を担当する。
- ＣＭにより示されたマネージャ制御モジュールを介した協働アクティビティによるメッセージインタプリタのリクエストに適したコンカレントプロセスをインスタント化（ｉｎｓｔａｎｔｉａｔｉｎｇ）し、ステータスをモニターすること、
- 稼働中の待ち行列Ｌ中のリクエストのアクティビティステータスを更新すること、及び
- 出力待ち行列Uを介してマネージャＡに送るべき統計チェックメッセージを生成すること、ただし、これらのメッセージは、インスタント化コンカレントプロセスの全体の操作ステータスについての統計情報を含んでいる。

ＣＭモジュールは、受信した情報を収集し分析することにより、協働及び分離方法の両方にて可能な他のプロトコルマネージャモジュール（そのうち３つが例としてここに示されていおり、符号ＭＰ１、ＭＰ２、ＭＰ３で示す）の管理を担当する。アクティビティの終了時、マネージャＡへの次の伝送のための出力待ち行列Ｕへの後続の挿入を考慮して、その結果が、メッセージをコンパイル及び圧縮するモジュール（符号ＣＣＭにより示す）に送られる。

ＣＣＭモジュールは、コンカレントプロセスにより生成されたアクティビティの結果を管理し、メッセージを作り、リクエストが圧縮されていたならば場合によっては該メッセージを圧縮し、待ち行列マネージャの出力待ち行列にそれを入れることを専ら担当している。

プロトコルマネージャＭＰ１、ＭＰ２、ＭＰ３と称するモジュールの各々（上述したように、管理すべきプロトコルの数に従って、任意の数のマネージャが存在し得る）は、特定のそれぞれのプロトコル（例えば、Ｔｅｌｎｅｔ、ＳＮＭＰ、ＴＦＴＰなど）を介してエージェントと通信することを担当している。

システム内では、アーキテクチャーにおける迅速でエラーの無い識別のために、一義的な識別番号が各メッセージに割り当てられる。階層型エージェントＡＧのエージェントアーキテクチャーの特徴についての概略は以下の通りである。

階層型エージェントＡＧは、従来のマネージャよりも軽量モジュールとして構成される。というのは、単純なコンポーネントが、エミュレートされるネットワークプロトコル（例えば、ＳＮＭＰ、Ｔｅｌｎｅｔ、ＤＮＳ、ＴＦＴＰなど）に対して用いられるからである。例えば、ＴＦＴＰプロトコルの場合、当該プロトコルに準拠したエージェントと通信する基本的な装置のみが、サーバー全体の代わりに実現される。

階層型エージェントＡＧはまた、従来のマネージャよりも速い。というのは、例えば遅いのは周知のディスク又はデータベースにアクセスすることなく、ホストシステムのＲＡＭのみを使用し最適化するからである。加えて、階層型エージェントＡＧは、複雑なマネージャ型メッセージの処理機能を含まず、よって、マネージャＡからのリクエストの受信時にのみ始動され、アクティビティの終了時に停止されるリソース使用の観点から、従来のマネージャに対してさらに効率的である。

上述したアーキテクチャーは、複数のプロトコル類型を伴って同時に協働される複数のアクティビティを実行するのに用いられ、階層型モードのエージェントにアクセスする可能性を与え、すなわち、特定のエージェントが２つの階層型エージェントにより連絡されることを可能にし、該階層型エージェントの第１のものは、主要素として働き、第２のものは副要素としてマネージャＡに働く。

これは、第１のものが利用できない場合に副の階層型エージェントが使用できることを意味する。

よって、上述した解決策は、故障又は一般に（これも一時的に）特定の要素が利用できない場合に、さらにロバストである。

分離された双方向通信のためにＡＲＸ及びＡＴＸモジュールを利用可能なことは、伝送性能を妥協することなく、大量の入力トラヒックを管理できることを意味する。特に、ＡＴＸモジュール伝送は、それぞれの優先度によるメッセージブロックに対して「タイミング式（ｔｉｍｅｄ）」又は「ガウス式（ｇａｕｓｓｉａｎ）」と称され得る方法により管理される。このアプローチは、トラヒックの起こりうるバーストを回避する。というのは、各クロック信号にて優先度に従って所定数のメッセージ（例えば、２０の優先度「１」メッセージ、１０の優先度「２」メッセージ、８つの優先度「３」メッセージ、２つの優先度「４」メッセージ及び１つの優先度「５」メッセージ）が送られ、一方、残りのメッセージは、待ち行列に入れられて次のサイクル中に送られるからである。加えて、これにより、「ボトルネック」の形成が避けられる。というのは、各メッセージは、モジュール処理速度を分離する内部バッファを介して一方のモジュールからもう一方に流れるからである。

特に好ましい実施態様では、図１２に示された方法によりマネージャＡと階層型エージェントＡＧとの間の通信に用いられるメッセージの構造は、ヘッダーＩとそれに続くデータ本体ＣＩとを与える。

この特定の場合には、ヘッダーＩは一般に次の情報を含む。
- メッセージ形式のバージョン（例えば、１．０）、
- 最大命令処理時間（ミリ秒にて）、
- 圧縮された内容の標識（１＝符号化された、０＝符号化されてない）、
- エラーの説明（エラーが無いか又はエラーのテキストを含んでいるかを確認するメッセージにコンパイルされている）、
- バイト単位でのメッセージサイズ、
- アクティビティを実行すべきエージェントのＩＰアドレス、
- マネージャにより示されるメッセージの優先度（０＝階層型エージェントＡＧにより割り当てられる優先度、１＝最大、５＝最小）、
- 使用されるべきプロトコルのマネージャの識別、
- 要求されるアクティビティ類型（命令自身）、
- マネージャリクエストのソースＵＤＰポート、
- マネージャＡ又は階層型エージェントＡＧのバージョン、
- マネージャ内のリクエストの一義的な識別。

データ本体ＣＩは、要求されるアクティビティを実行するのに用いられるプロトコルマネージャ（ＭＰ１，ＭＰ２，ＭＰ３，．．．）についての特定の情報を含む。これらが示すものは、実行されるべきアクティビティと、使用されるプロトコルにより区別される。以下の内容は、例えば次のように表現することができる。
- ＳＮＭＰプロシージャ：要求されるべきＯＩＤ ＳＮＭＰ、実行すべき操作の類型（ＧＥＴ、ＧＥＴ ＮＥＸＴ、ＳＥＴ及びＢＵＬＫなど）を有する標準的なＳＮＭＰメッセージを含む。
- Ｔｅｌｎｅｔプロシージャ：認証パラメータ（ＵＩＤ、パスワード）、オペレータ命令、命令により生成された出力を戻すか否かの指示を含む。
- ＳＮＭＰプロシージャ：標準的なＳＮＭＰ操作類型（ＢＵＬＫ又はＧＥＴ ＮＥＸＴ）を介して収集されるべき総てのＭＩＢブランチのＯＩＤ ＳＮＭＰを含む。
- 協働プロシージャ：スクリプトの形式のマルチプロトコル協働方法を含む。
- ＴＦＴＰファイル管理プロシージャ（非標準的）：アクティビティ類型（アップロード又はダウンロード）、収集又はダウンロードされるべきファイルのリストを含む。
- エージェント連絡可能性テストプロシージャ：テスト類型／ＤＮＳルックアップ及び逆のＤＮＳルックアップ、ｐｉｎｇ、Ｔｅｌｎｅｔ及びＳＮＭＰポート連絡可能性を介して実行されるべき類型を含む。
- 階層型エージェント連絡可能性テストプロシージャ：実行すべきアクティビテ
ィを含まず、階層型エージェントＡＧの連絡可能性をテストすべくマネージャＡにより用いられる。
- 統計伝送命令：統計データを送らなければならないマネージャＡのＵＤＰポートを登録し定義するデータを含む。

次に、命令は、特にメッセージ中に周期的に現れるシーケンスの肯定応答に基づいた圧縮操作から成るアルゴリズム的圧縮方法を用いて、圧縮されかつ入れ子にされ得る。

具体的には、図１２に示されるように、メッセージのヘッダーＩ及びデータ本体ＣＩが、メッセージヘッダーＭＨ及び残りの部分ＰＤＵから成る階層型エージェントＡＧによりサポートされたメッセージ構造中に入れ子にされて、ＩＰレベル上の通過が可能なＳＮＭＰ又はＵＤＰメッセージを生成し得る。

図１３のフローチャートは、ＳＮＭＰメッセージの圧縮（図１３ａ）及び圧縮解除（図１３ｂ）のために用いられる方法を示す。

図１４のフローチャート（ここでも伝送は図１４ａ、受信は図１４ｂ）は、ＳＮＭＰネスティングを介して圧縮ＳＮＭＰメッセージを転送する第一の解決策を示す。

図１５のフローチャートは、ＵＤＰネスティングを介した転送の解決策を示す。ここでも、伝送（図１５ａ）と受信（図１５ｂ）を分けて参照する。

図１７及び１８は、図１３及び１４のａ部分（図１７）、並びに図１３及び１５のａ部分（図１８）にそれぞれ例示された全体の圧縮及び伝送操作を示す。

図１３のフローチャートでは、符号１００は、全体のＳＮＭＰメッセージ（ヘッダー＋ＰＤＵ）が読み出されるステップを示し、符号１０２により示される次のステップにて１６進形式に変換される。これは、ＢＥＲ型のエンコードを適用することにより行われる。

このように符号化されたメッセージは、反復性シーケンスの肯定応答に基づいた圧縮方法、例えば、上述したｚＬｉｂライブラリに記された方法などを用いてオンメモリにて圧縮される。

これは、符号１０４により示されたステップにおいて行われ、ステップ１０６の伝送に備えた圧縮データ単位を得る。

対称的に、図１３のｂ部分のフローチャートは、４つのステップ２０６、２０４、２０２及び２００（図示された順番にて処理される）を含み、その際、受信した圧縮データ単位（ステップ２０６）は、次の１６進復号化（ステップ２０２）及び内部ＳＮＭＰメッセージについての再構成（ステップ２００）を考慮して、圧縮解除（ステップ２０４）を受ける。

図１３の部分ｂのフローチャート中のステップの数字符号は、圧縮プロシージャの１００〜１０６のステップとの対称性を単に強調するように、処理順の逆にしている。図１４及び図１５中のフローチャートに関しても、同様のことを行っている。

図示されているように、図１４及び図１７は、転送の解決策に関するものであり、該解決策では、圧縮データ単位が、変数束縛と標準的なＵＤＰ伝送方法とを特徴とする標準的なＳＮＭＰメッセージ中に入れ子にされる。

ステップ１０６における圧縮データ単位のネスティング方法は、初期ステップ（符号１０８で示す）から成り、該初期ステップにおいて、圧縮データ単位がバイトにて読み出され、次いで（符号１１０で示される次の符号化ステップにおいて）対応するＡＳＣＩＩ文字セットに置換される。

メッセージの変数束縛は、＿ＺＩＰ＿ｘｘｘｘストリング（ここでｘｘｘｘは元のファイルのサイズである）の値を含んだ第１の番号付きＯＩＤ（例えば、１．３．６．１．４．６６６．１）からなり、符号１１２により示された次のステップにおいて（場合によっては、ＡＣＫ ＴＡＢ＋ＮＵＬＬなどの補助機能の後。図１７のブロック１１０ａを参照）生成される。ＩＡＮＡ（Ｉｎｔｅｒｎｅｔ Aｓｓｉｇｎｅｄ Nｕｍｂｅｒｓ Aｕｔｈｏｒｉｔｙ）により現在のところ登録されていない所有者コード６６６．１が、上記例では用いられた。

ＡＳＣＩＩに翻訳された圧縮データ単位を含んだ次の変数束縛要素は、ＯＩＤ／値の対からなる。この値は、最大サイズが２５５文字であるＡＳＣＩＩ形式に置換された圧縮データ単位の部分を含む。

次いで、ＳＮＭＰメッセージのヘッダーデータが再構成される。これはステップ１１２で行われ、その後、ステップ１１４において、ＢＥＲ方法による追加の符号化が実施され、データを送る（ステップ１１６）のに用いられるＰＤＵ ＵＤＰペイロードを生成する。

この場合にも、図１４のｂ部分において符号２１６、２１４、２１２、２１０及び２０８により示されたステップは、上記示した順に処理されるものであり、伝送に関するステップ１０８〜１１６の受信中に実行されるデュアル機能である。

図１４及び１７に示した解決策を採用することにより、圧縮ＳＮＭＰメッセージは、標準的なＳＮＭＰ論理形式と所有者コンテントとを有する。よって、肯定応答及び符号化／復号化を可能にするために、機能の拡大（最小限の）がエージェントのマネージャにより要求される。

出願人が行った実験では、この解決策はネットワークアーキテクチャーに悪影響を与えることなく完全に実現可能であることが示された。

別の解決策（図１５及び１８を参照）は、図１３に示した方法に従ってＳＮＭＰメッセージから開始して圧縮データ単位を準備した後、前記データ単位をＰＤＵ ＵＤＰペイロード中に直接ネスティングすることに存する。

もちろん、正しい操作を保証するために、この解決策では、例えば標準とは異なるＵＤＰポートを使用しなければならない場合に、専用の送信器及び受信器（例えば、図９及び１１のＡＲＸ及びＡＴＸモジュールなど）が利用できることが必要である。よって、この送信器は、どのＵＤＰポートが受信器により使用されるかを知らなければならず、逆もまた同様である。使用ポート上の情報は、後に詳しく説明する基準に従って、標準的なＳＮＭＰ形式の同期化メッセージによってより高いレベルにて交換され得る。

図１５及び１８に示された代わりの解決策を採用することにより、ステップ１０８中に利用可能にされ、かつメッセージ中のＢＥＲに取って代わるべき圧縮データ単位が、ＵＤＰメッセージのペイロードになる。

それぞれの操作が、図１５及び１８中の数字符号１２０により示されたステップにおいて概略示されている。このステップは、伝送ステップ１２２に進み、受信器のそれぞれの専用ポート（一般にポートＸという）に向かう。

この場合にも、相補的な操作は、符号２２２（その時点で受信しているモジュールのポートＹを介した受信）、２２０（ＰＤＵ ＵＤＰペイロード抽出）及び２１８（図１３のｂ部のフローチャート中のステップ２０６に転送されるべき圧縮データ単位の作成）に示される３つのステップから成る。

この場合にも、ステップ２２２、２２０及び２１８は、それらが示された順にて実行される。

上記説明で参照した同期メッセージは、所有者変数束縛を含んだ標準的なＳＮＭＰ形式を用いる一般的なアプリケーション-アプリケーション基準に従って、マネージャＡにより階層型エージェントＡＧに送られる。

転送されるデータの型は次の通りである。

マネージャＡは、所有者メッセージを階層型エージェントＡＧに送り、ＵＤＰ伝送に使用しようとしているポートの数（例えば、１０２４）を有する＜ＵＤＰ＿ＴＸ＿Ｐｏｒｔ＞をコンパイルし、ＵＤＰ受信に使用するポートの数（例えば、１２２４）を有する＜ＵＤＰ＿ＲＸ＿Ｐｏｒｔ＞をコンパイルする。階層型エージェントＡＧは、それ自身の情報を含んだ同様のメッセージを送ることにより、マネージャＡに応答する。この方法は、解決策の効率を改善することによって処理時間を削減する。

図１６のフローチャートは、さらに、説明した解決策がいかにして一般化され、いかにしてトランスポート用のＵＤＰ（例えば、ＳＮＭＰ、ＰＩＮＧなど）を用いる任意の種類のメッセージに適用されるかを示す。この一般化は、現在使用中のものに取って代わり得るＵＤＰドライバを作り出すのに活用できる。

この解決策は、転送されるべきペイロードのサイズを評価すること、及びもしサイズが適切ならば（例えば、２０バイトより大）、上述した方法を進めることに存する。ＵＤＰメッセージヘッダーのビット６２〜ビット６９の８ビットは、例えば、該ビットを１に設定することにより、ＵＤＰメッセージのコンパクトな性質を示すのに使用できる（これらのビットは現在使用されておらず、デフォルトで０に設定されている）。

具体的には、図１６中の符号３００は、ＵＤＰメッセージにて運ばれ得るメッセージを送る必要性が生じ、その後に、上述した方法によりペイロードを圧縮するステップ３０２が続くという任意のステップを示す。

次のステップ３０４は、上記事項に関しＵＤＰメッセージヘッダーを生成することに存する。符号３０６により示される次のステップは、ＩＰ伝送（ステップ３０８にて実施される）に備えるために、完全なＵＤＰメッセージを作ることに対応する。

もちろん、特許請求の範囲に記載のような本発明の範囲を逸脱することなく、ここで想定されている本発明の構成及び実施態様に対して、多くの変更を実施することができる。

公知技術に関する説明図である。 公知技術に関する説明図である。 公知技術に関する説明図である。 公知技術に関する説明図である。 本発明による新しい管理アーキテクチャーを一般的な用語にて示す。 本発明による解決策の第１の実施態様を示す。 本発明による解決策の第２の実施態様を示す。 本発明によるアーキテクチャーの動作論理例を示す。 本発明によるアーキテクチャー内の可能な通信管理図を示す。 共用されるエージェント管理方法を示す。 本発明によるいわゆる階層型エージェントのアーキテクチャーを示す。 本発明の範囲内での構造の可能な編成及び階層型エージェントによりサポートされた制御のネスティングを示す。 各々が伝送（ａ部分）及び受信（ｂ部分）に関する２つの部分に別れており、本発明による解決策のいくつかの好ましい実施態様をフローチャートにて示す。 各々が伝送（ａ部分）及び受信（ｂ部分）に関する２つの部分に別れており、本発明による解決策のいくつかの好ましい実施態様をフローチャートにて示す。 各々が伝送（ａ部分）及び受信（ｂ部分）に関する２つの部分に別れており、本発明による解決策のいくつかの好ましい実施態様をフローチャートにて示す。 本発明による解決策のさらに一般的な特徴を示した別のフローチャートである。 本発明の可能な変形による解決策の別の可能な実施態様を示す。 本発明の可能な変形による解決策の別の可能な実施態様を示す。

符号の説明

Ａ マネージャモジュール（マネージャオブジェクト）
ＡＧ 階層型エージェント（中間オブジェクト）
Ｂ１．．．ＢＮ エージェント（被管理オブジェクト）
Ｒ 通信ネットワーク

Claims (30)

1. 通信ネットワーク（Ｒ）を介して少なくとも１つのマネージャオブジェクトによって少なくとも１つの被管理オブジェクト（Ｂ１，．．．，ＢＮ）の管理アクティビティを行うための方法であって、
   - データセット（１１０２）に従って前記少なくとも１つの被管理オブジェクト（Ｂ１，．．．，ＢＮ）を管理するよう構成された少なくとも１つの中間オブジェクト（ＡＧ）を設けるステップであって、前記管理アクティビティが結果セット（１１１２）に変換される前記ステップ、
   - 前記データセット（１１００）を前記少なくとも１つのマネージャオブジェクト（Ａ）から前記中間オブジェクト（ＡＧ）に与えるステップ、
   - 前記少なくとも１つの中間オブジェクト（ＡＧ）を介して前記少なくとも１つの被管理オブジェクト（Ｂ１，．．．，Ｂｎ）を管理して前記結果セットを生成するステップ、
   - 前記結果セットを前記少なくとも１つの中間オブジェクト（ＡＧ）から前記少なくとも１つのマネージャオブジェクト（Ａ）に転送するステップ（１１０８）、
   を含むことを特徴とする前記方法。
2. 前記少なくとも１つのマネージャオブジェクト（Ａ）と前記少なくとも１つの中間オブジェクトとの間でＵＤＰプロトコルを介した通信を確立するステップを含むことを特徴とする請求項１に記載の方法。
3. - 前記少なくとも１つのマネージャオブジェクト（Ａ）を介して直接少なくとも１つの別の被管理オブジェクト（Ｂｋ，．．．，ＢＮ）を管理するステップ、及び
   - 前記中間オブジェクト（ＡＧ）を介して、前記少なくとも１つのマネージャオブジェクト（Ａ）により前記少なくとも１つの被管理オブジェクト（Ｂ１、Ｂ２、Ｂ３）を管理するステップ、
   を含むことを特徴とする請求項１又は請求項２に記載の方法。
4. 通信ネットワーク（Ｒ）を介した、前記少なくとも１つの別の被管理オブジェクト（Ｂｋ，．．．，Ｂｎ）及び前記少なくとも１つの被管理オブジェクト（Ｂ１、Ｂ２、Ｂ３）の管理を含むことを特徴とする請求項３に記載の方法。
5. - 前記少なくとも１つのマネージャオブジェクト（Ａ）を介して直接前記少なくとも１つの別の被管理オブジェクト（Ｂ１）を管理し、かつ前記データセット（１１００）と前記結果セット（１１１８）を前記少なくとも１つのマネージャオブジェクト（Ａ）と前記少なくとも１つの別の被管理オブジェクト（Ｂ１）との間で転送するための第１通信ネットワーク（ＲＰ）を設けるステップ、及び
   - 前記中間オブジェクト（ＡＧ）を介して前記少なくとも１つの被管理オブジェクト（Ｂ２、Ｂ３）を管理するための第２通信ネットワーク（ＲＡ）を設けるステップ、
   を含むことを特徴とする請求項３に記載の方法。
6. 複数の前記中間オブジェクト（ＡＧ１、ＡＧ２）を設け、前記複数の中間オブジェクトのうちのいくつかの中間オブジェクト（ＡＧ１、ＡＧ２）を介して、少なくとも１つの被管理オブジェクト（Ｂ３）を管理するステップを含むことを特徴とする請求項１〜５のいずれか一項に記載の方法。
7. 前記中間オブジェクト（ＡＧ）が、それぞれの受信モジュール（ＡＲＸ）及び伝送モジュール（ＡＴＸ）を備え、該受信モジュール（ＡＲＸ）及び伝送モジュール（ＡＴＸ）は、前記少なくとも１つのマネージャオブジェクト（Ａ）が前記中間オブジェクト（ＡＧ）を本質的に前記被管理オブジェクト（Ｂ１，．．．，Ｂｎ）の一つとして見るように構成されていることを特徴とする請求項１〜６のいずれか一項に記載の方法。
8. 前記少なくとも１つの中間オブジェクト（ＡＧ）が、少なくとも１つのそれぞれの管理モジュール（ＭＭ）を備え、該管理モジュール（ＭＭ）は、前記少なくとも１つの中間オブジェクト（ＡＧ）により管理される前記少なくとも１つの被管理オブジェクト（Ｂ１，．．．，ＢＮ）が、前記少なくとも１つの中間オブジェクト（ＡＧ）を本質的に前記少なくとも１つのマネージャオブジェクト（Ａ）として見るように構成されていることを特徴とする請求項１〜７のいずれか一項に記載の方法。
9. 前記少なくとも１つの中間オブジェクト（ＡＧ）が、以下の待ち行列、すなわち
   - 前記少なくとも１つの中間オブジェクト（ＡＧ）に対する入力メッセージを収集するための入力待ち行列（Ｉ）、
   - 前記少なくとも１つの中間オブジェクト（ＡＧ）からの出力メッセージを収集するための出力待ち行列（Ｕ）、及び
   - 前記少なくとも１つの被管理オブジェクト（Ｂ１，．．．，Ｂｎ）上にて前記少なくとも１つの中間オブジェクト（ＡＧ）にて実行される前記管理アクティビティに固有なメッセージを収集するための稼働中の待ち行列（Ｌ）
   のうちの一つを備えることを特徴とする請求項１〜８のいずれか一項に記載の方法。
10. 前記少なくとも１つの中間オブジェクト（ＡＧ）において、前記入力待ち行列（Ｉ）により受信された入力メッセージを分析するための専用モジュール（ＤＣ）を設けるステップを含むことを特徴とする請求項９に記載の方法。
11. 以下の機能、すなわち
    - 少なくとも１つのコンカレントプロセスをインスタント化し、
    - 前記稼働中の待ち行列Ｌにおけるリクエストのアクティビティステータスを更新し、
    - 前記出力待ち行列（Ｕ）を介して前記少なくとも１つのマネージャオブジェクト（Ａ）に送られるべき統計チェックメッセージを作る
    機能のうちの少なくとも１つを実行するためのアクティビティ協働モジュール（ＣＡ）を、前記少なくとも１つの中間オブジェクト（ＡＧ）に設けるステップを含むことを特徴とする請求項９又は請求項１０に記載の方法。
12. 前記少なくとも１つの中間オブジェクト（ＡＧ）において異なるそれぞれのプロトコルを介して前記少なくとも１つの被管理オブジェクト（Ｂ１，．．．，ＢＮ）との通信を確立するよう構成された複数のプロトコル管理モジュール（ＭＰ１、ＭＰ２、ＭＰ３）を設けるステップを含むことを特徴とする請求項１〜１１のいずれか一項に記載の方法。
13. それぞれのメッセージの少なくとも１つの部分に圧縮操作（３０２；１０４、２０４）を行うことにより、前記少なくとも１つのマネージャオブジェクト（Ａ）と前記少なくとも１つの中間オブジェクト（ＡＧ）との間での通信を確立するステップを含むことを特徴とする請求項１〜１２のいずれか一項に記載の方法。
14. 前記圧縮操作が、メッセージ中に周期的に現れるシーケンスの肯定応答に基づくことを特徴とする請求項１３に記載の方法。
15. 前記圧縮操作がｚＬｉｂといったｇｚｉｐ型方法を実施することを特徴とする請求項１４に記載の方法。
16. ＵＤＰにより転送されるメッセージの圧縮が実行されたことを示すステップを含むことを特徴とする請求項２及び請求項１３〜１５のいずれか一項に記載の方法。
17. ＵＤＰヘッダー中のビットフィールドが、圧縮操作（３０２）が行われたことを示すのに用いられることを特徴とする請求項１６に記載の方法。
18. ＵＤＰヘッダー中のビット６２〜ビット６９の範囲から構成されるビットが、圧縮操作（３０２）が行われたことを示すのに用いられることを特徴とする請求項１７に記載の方法。
19. ＵＤＰメッセージヘッダーのビット６２〜６９の少なくとも１つを１に設定するステップを含むことを特徴とする請求項１８に記載の方法。
20. 前記少なくとも１つのマネージャオブジェクト（Ａ）と前記少なくとも１つの中間オブジェクト（ＡＧ）との間の通信が、ＳＮＭＰメッセージにより実行され、また、圧縮ステップ中に、
    - 全体のＳＮＭＰメッセージを読み取るステップ（１００）、
    - 読み取ったメッセージを１６進形式に符号化するステップ（１０２）、及び
    - １６進形式に符号化されたメッセージを圧縮するステップ（１０４）
    を含むことを特徴とする請求項１３〜１９のいずれか一項に記載の方法。
21. 前記少なくとも１つのマネージャオブジェクト（Ａ）と前記少なくとも１つの中間オブジェクト（ＡＧ）との間の通信が、ＳＮＭＰメッセージにより実行され、また、受信ステップ中、
    - 前記圧縮操作と相補的な圧縮解除（２０４）を受信メッセージに行い、１６進形式にて復号化されたメッセージを得るステップ、
    - １６進形式からメッセージを復号化するステップ（２０２）、及び
    - 前記復号化されたメッセージから全体のＳＮＭＰメッセージを再構成するステップ（２００）
    を含むことを特徴とする請求項１３〜１９のいずれか一項に記載の方法。
22. 前記圧縮操作（１０４）を受けたメッセージの伝送のため、標準的なＳＮＭＰメッセージ中のネスティング操作を含むことを特徴とする請求項２０又は請求項２１に記載の方法。
23. 伝送中に、
    - 前記圧縮操作（１０４）を受けたメッセージをバイトにて読み出し（１０８）、それを対応するＡＳＣＩＩ文字メッセージに置換する（１１０）ステップ、
    - 元のファイルサイズを示す第１ＯＩＤを含んだ変数束縛セットと、前記圧縮操作（１０４）を受けてＡＳＣＩＩ文字に置換された前記メッセージの部分を運ぶ後続のＯＩＤ／値の対とを生成する（１１２）ステップ、
    - ＳＮＭＰメッセージのヘッダーデータを再構成するステップ、
    - 得られた１６進形式のＳＮＭＰメッセージを符合化して（１１４）、ＵＤＰペイロードを生成するステップ、及び
    - このようにして生成されたＵＤＰペイロードを転送する（１１６）ステップ、
    を含むことを特徴とする請求項２２に記載の方法。
24. 受信中に、
    - 前記圧縮操作を受けたメッセージをＵＤＰペイロードとして受信するステップ（２１６）、
    - このように受信したペイロードに１６進復号化操作を行うステップ（２１４）、
    - 肯定応答し、１６進復号化を受けたメッセージの変数束縛をアセンブルするステップ（２１２）、
    - 前記肯定応答及びアセンブル操作（２１２）を受けたメッセージに対し、バイナリＡＳＣＩＩ復号化を行うステップ（２１０）、及び
    - 復号化されたバイナリ形式のメッセージに前記圧縮解除操作を行うステップ（２０４）
    ことを特徴とする請求項２２又は請求項２３に記載の方法。
25. 前記圧縮操作（１０４）を受けたメッセージの伝送のために、ＵＤＰネスティングを介して前記圧縮操作（１０４）を受けたメッセージを統合するステップを含むことを特徴とする請求項２０又は請求項２１に記載の方法。
26. 伝送中、
    - 前記圧縮操作（１０４）を受けた前記メッセージをプロトコルデータ単位（ＰＤＵ）のペイロードとして構成するステップ、及び
    - このようにして作成されたペイロードを所与の受信器ポートに転送するステップ
    を含むことを特徴とする請求項２５に記載の方法。
27. 受信中、
    - 受信器ポートにて受信したＰＤＵ ＵＤＰのペイロードとして、前記メッセージを受信するステップ、及び
    - 前記ＰＤＵから前記ペイロードを抽出するステップ
    を含むことを特徴とする請求項２５又は請求項２６に記載の方法。
28. 前記少なくとも１つのマネージャオブジェクト（Ａ）と前記少なくとも１つの中間オブジェクト（ＡＧ）との間の前記伝送ポート及び／又は前記受信ポートを示すＳＮＭＰ型の同期メッセージ（１１０６）を伝送するステップを含む
    ことを特徴とする請求項２６又は請求項２７に記載の方法。
29. 少なくとも１つのマネージャオブジェクト（Ａ）と少なくとも１つの被管理オブジェクト（Ｂ１，．．．，Ｂｎ）とを含む通信ネットワークを管理するためのシステムであって、請求項１〜２８のいずれか一項に記載の方法を実行する少なくとも１つの中間オブジェクト（ＡＧ）を備えることを特徴とする前記システム。
30. 少なくともコンピュータの内部メモリに直接ロードできるソフトウェアモジュールであって、少なくとも１つのコンピュータにより該ソフトウェアモジュールが実行されるとき、請求項１〜２８のいずれか一項に記載の方法を実行するソフトウェアコードの部分を含む前記ソフトウェアモジュール。