JPH11232239A - ネットワーク管理フレームワーク - Google Patents

Abstract

(57)【要約】 【課題】 柔軟性が高いネットワーク管理環境の開発を
可能にするネットワーク管理フレームワークを提供す
る。 【解決手段】 ネットワーク管理システムのための汎用
管理フレームワークは、必要に応じて、管理サービスお
よび管理エージェントを使用中に追加することを可能に
する。管理サービスは、フレームワークに動的にロード
することまたは差し込むことができる。その結果、スケ
ーラブルかつ動的であり、要件の変更に応じて発展可能
な管理構造を備えることが可能となる。管理情報は、管
理ビーンとしてモデル化される。ネットワーク管理アダ
プタも、必要に応じて、フレームワークに追加し、ＨＴ
ＴＰ、ＳＳＬ、ＲＭＩ，ＳＮＭＰというようなプロトコ
ルに対応することができる。これによって、遠方のアプ
リケーションが、異なるプロトコルを通じて遠方より管
理ビーンを制御することが可能となる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ネットワーク管理
システムおよびフレームワーク、ならびにかかるシステ
ムのための方法に関するものである。

【０００２】

【従来の技術】ネットワーク管理システムは、通信シス
テムを通じた遠隔的なシステム管理にその用途がある。
ネットワーク管理システムは、ＧＥＴ, ＳＥＴ，ＡＣＴ
ＩＯＮ，ＣＲＥＡＴＥおよびＤＥＬＥＴＥといった動作
を含む、１組の比較的限られたコマンドにしたがって、
ネットワーク上で多数で多様なオブジェクトの操作およ
び制御を可能にするものとして知られている。かかるネ
ットワーク管理システムの一例に、通信管理ネットワー
ク（ＴＭＮ：Telecommunications Management Networ
k）環境と呼ばれるものがある。

【０００３】ＴＭＮ環境は、業界標準の共通管理情報プ
ロトコル（ＣＭＩＰ：Common Management Information
Protocol）を提供し、そのプロトコルの下でX710/ISO 9
595共通管理情報サービス（ＣＭＩＳ：Common Manageme
nt Information Services)に対応する。これらのサービ
スは、ＧＥＴ, ＳＥＴ，ＡＣＴＩＯＮ，ＣＲＥＡＴＥお
よびＤＥＬＥＴＥといった動作を含む、１組の比較的限
られたコマンドにしたがって、ネットワーク上で多数の
多種多様なオブジェクトの操作を可能にする。

【０００４】ネットワーク管理システムを構成したネッ
トワークの物理的コンフィギュレーションは、多くの異
なる形態を取ることができ、その例として、公衆電話交
換網および／またはローカル・エリア・ネットワーク、
および／またはローカル・エリアおよび／またはより広
いエリア内の専用ネットワーク接続コンピュータおよび
その他の機器、あるいはインターネットまたはイントラ
ネットのようなオープン・ネットワークを含む。オブジ
ェクトは、典型的に、機器の一部(piece)、当該機器の
コンポーネント、機器またはそのコンポーネントの動作
等をモデル化するために用いられるパラメータおよびメ
ソッドを備えている。

【０００５】ＴＭＮ環境では、例えば、オブジェクト
は、被管理オブジェクトの定義のための業界標準X722/I
SO-10165-4ガイドライン（ＧＤＭＯ：Guidelines for D
efinition of Managed Objects）にしたがって定義され
る。ＧＤＭＯは、X208/ISO-8824抽象シンタクス・ノテ
ーション１（ＡＳＮ．１：Abstract Syntax Notation O
ne)および、データ・ノテーションのための抽象ノテー
ション１に対する基本符号化規則（ＢＥＲ：Basic Enco
ding Rules)のX209/ISO-8825仕様にしたがって、デー
タ、またはパラメータ、型を定義する。これら種々の業
界標準は、国際標準化機構（ＩＳＯ：International St
andards Organization）によって定義されている。

【０００６】

【発明が解決しようとする課題】ＧＤＭＯは、コンピュ
ータによって直接理解されない、形式的な記述言語であ
る。したがって、ＧＤＭＯをコンピュータが理解可能な
フォーマットに変換する必要がある。かかるプロセスに
対する標準がないので、これは、しばしば多数の解釈が
行われる結果となり、そのために相互動作性(inter-ope
rability)の問題を招いている。

【０００７】ＣＭＩＳを呼び出すためには、アプリケー
ション・プログラミング・インターフェース（ＡＰＩ：
Application Programming Interface)を与える必要があ
る。典型的に、ＡＰＩは、ＣまたはＣ＋＋のようなプロ
グラミング言語を用いて作成されてきた。しかしなが
ら、例えば、オブジェクトの新しい型およびインスタン
ス（例えば、ネットワーク・マネージャのための新しい
型のワークステーション）を定義することによって、ネ
ットワーク・サービスを継承extend）する必要がある場
合、ＡＳＮ．１およびＧＤＭＯ規格に対するプログラム
に基づくＡＰＩは、難問に突き当たる。既存のネットワ
ーク管理システムに伴う別の問題に、ネットワーク管理
エージェントが対応可能なプロトコルに関して、これら
が制限されていることがあげられる。言い換えると、従
来のＡＰＩを与える手法は、動的ネットワーク管理環境
においては問題がある。

【０００８】本発明の全体的な目的は、より柔軟性が高
いネットワーク管理環境の開発を可能にする構造を提供
することである。この全体的な目的の範囲内において、
本発明が対象とする問題を更に特定すれば、動的ネット
ワーク管理エージェント構造を提供することである。

【０００９】

【課題を解決するための手段】本発明の一態様によれ
ば、通信ネットワークのためのネットワーク・エージェ
ントが提供され、このネットワーク・エージェントは、
拡張可能なフレームワークと、フレームワークに登録可
能な１つ以上の被管理オブジェクトと、フレームワーク
に登録可能であり、ネットワーク通信プロトコルが被管
理オブジェクトにアクセスすることを可能とするための
１つ以上のネットワーク・アダプタとから成る。

【００１０】ネットワーク・エージェントの拡張可能な
フレームワークに、当該フレームワークと関連付けるこ
と、またはこれに登録することが可能な被管理オブジェ
クトおよびネットワーク・アダプタを備えることによっ
て、柔軟性のあるネットワーク・エージェント、例え
ば、ネットワーク管理エージェントを備えることがで
き、変化する状況に合わせて適応可能に拡張することが
できる。異なる被管理オブジェクトを必要に応じて関連
付けまたは登録することを可能にすることによって、新
たなリソースまたはリソースの変化を管理する新しいオ
ブジェクトを組み込むための構造の拡張が容易に可能と
なる。好ましくはオブジェクトとして実装する、異なる
ネットワーク・アダプタの選択的接続を可能とすること
により、被管理オブジェクトを管理するプロトコルを、
必要に応じて選択することが可能となる。

【００１１】米国特許第５，３１５，７０３号および米
国特許第５，３６７，６３３号は、変更通知機能を可能
にするためのフレームワークを含む、オブジェクトに基
づくシステムについて記載する。しかしながら、これら
の特許は、単体のシステムについて記載するに過ぎな
い。

【００１２】好ましくは、管理サービスを動的にフレー
ムワークに登録し、スケーラブルな管理環境を備えるこ
とを可能とする。管理サービスは、フレームワークに登
録可能なオブジェクトの形態で実装することが好まし
い。管理サービスの一例は、レポジトリ・サービスであ
る。

【００１３】好適な実施形態では、レポジトリ・サービ
ス・オブジェクトが、前記フレームワークに登録可能で
あり、被管理オブジェクト（または複数の被管理オブジ
ェクト）および／またはネットワーク・アダプタ（およ
び／または更に別の管理サービス）が、前記レポジトリ
・サービス・オブジェクトに登録可能であり、これによ
って、前記被管理オブジェクトおよび前記ネットワーク
・アダプタが、前記レポジトリ・サービス・オブジェク
トを通じて、前記フレームワークに間接的に登録可能と
なる。次いで、フレームワークは、レポジトリ・オブジ
ェクトを通じて、またはこれを参照することにより、被
管理オブジェクトおよびネットワーク・アダプタにアク
セスすることができる。レポジトリ・サービス・オブジ
ェクトは、実際には、フレームワークと、被管理オブジ
ェクトと、ネットワーク・アダプタとの間に接続機構を
備える。これは、エージェント構造の動的な拡張性に、
特に柔軟な構造を与える。

【００１４】本発明の好適な実施形態では、オブジェク
トは、ビーンとして、例えば、ＪａｖａＢｅａｎｓコン
ポーネントとして実装される（ＪａｖａＢｅａｎｓは、
サンマイクロシステムズ社(Sun Microsystems, Inc.)の
商標である）。ビーンは、再利用可能なソフトウエア・
コンポーネントであり、ビルダ・ツール（例えば、エデ
ィタまたはグラフィカル・ユーザ・インターフェース・
ビルダ（ＧＵＩビルダ））において視覚的に操作するこ
とができる。ビルダ・ツールの一例に、ＪａｖａＢｅａ
ｎｓ開発キット(JavaBeans Development Kit)がある。
ビーンに関する更なる詳細は、多くの異なる研究におい
て見ることができ、例えば、Synbexによって発行された
Lawrence Vanhelsuwe著のMastering JavaBeans（Ｊａｖ
ａＢｅａｎｓの習得）と題する本(ISBN-0-7821-2097-0)
があげられる。これは、表題に「ＪａｖａＢｅａｎｓ」
を有しＪａｖａＢｅａｎｓについて説明する、広い意味
で同等な市販の多くの本の一例に過ぎない。Mastering
JavaBeansを含むこれらの本の多くは、上述のビーン開
発キットに対応する(supply)ものである。

【００１５】ビーンはそのファンクショナリティ(funct
ionality)が様々に変化するが、典型的に、ある種の共
通した定義構造を共有しており、１組のプロパティ、１
組のメソッド、ならびにイベント、およびリフレクショ
ン(reflection)としても知られているイントロスぺクシ
ョン (introspection:内省) に対するサポート(suppor
t)を与える。プロパティは、ビーンのプログラム的な操
作を可能とし、ビーンのカスタム化(customization)を
サポートする。メソッドはプロパティを実装する。イベ
ントに対するサポートは、ビーンがイベントを発火(fir
e)することを可能とし、発火することができるイベント
を定義する。イントロスぺクションに対するサポート
は、ビーンのプロパティ、イベントおよびメソッドを、
外部から検分することを可能にする。

【００１６】好ましくは、フレームワークは、ゲッタ・
プロパティおよびセッタ・プロパティを備えており、オ
ブジェクトおよび／またはオブジェクト・メソッドの獲
得および／またはセットを行うために、ゲッタ・メソッ
ドおよびセッタ・メソッドを実装する。オブジェクトを
遠方から操作するために、ネットワーク・アダプタ（ま
たは複数のネットワーク・アダプタ）は、受信した外部
要求に応答し、前記フレームワークに、前記要求に対す
る被管理オブジェクト・メソッドを獲得させ、続いて応
答を返送させる。レポジトリ・サービスが備えられてい
る場合、フレームワークは、このレポジトリ・サービス
を参照して、被管理オブジェクト・メソッドをコールす
る。好ましくは、フレームワークは、オブジェクト追加
機能およびオブジェクト除去機能を実行し、管理構造の
動的なスケーリングを実施するように構成されている。
好ましくは、フレームワークは、ゲッタ・プロパティお
よびセッタ・プロパティ、これらのプロパティを実装す
るためのメソッド、ならびにオブジェクト追加イベント
およびオブジェクト除去イベントのためのサポートを含
むビーンとして実装する。

【００１７】本発明の別の態様によれば、通信ネットワ
ークに接続可能な計算機システムが提供される。この計
算機システムはネットワーク・エージェントを含み、ネ
ットワークエージェントは、拡張可能なフレームワーク
と、フレームワークに登録可能な１つ以上の被管理オブ
ジェクトと、フレームワークに登録可能であり、ネット
ワーク通信プロトコルが前記被管理オブジェクトにアク
セスすることを可能とするための１つ以上のネットワー
ク・アダプタとから成る。

【００１８】本発明の更に別の態様によれば、少なくと
も１つの記憶媒体上にある、オブジェクトに基づくネッ
トワーク・エージェントが提供され、このネットワーク
・エージェントは、拡張可能なフレームワーク・サービ
ス・オブジェクトと、フレームワーク・サービスに登録
可能な１つ以上の被管理オブジェクトと、フレームワー
ク・サービスに登録可能であり、ネットワーク通信プロ
トコルが前記被管理オブジェクトにアクセスすることを
可能とするための１つ以上のネットワーク・アダプタ・
オブジェクトとから成る。

【００１９】本発明の更に別の態様によれば、被管理シ
ステムのためのネットワーク管理エージェント備えたネ
ットワーク管理システムが提供され、このネットワーク
管理エージェントは、拡張可能なフレームワーク・サー
ビス・オブジェクトと、フレームワーク・サービスに登
録可能な１つ以上の被管理オブジェクトと、フレームワ
ーク・サービスに登録可能であり、ネットワーク通信プ
ロトコルが前記被管理オブジェクトにアクセスすること
を可能とするための１つ以上のネットワーク・アダプタ
・オブジェクトとから成る。

【００２０】本発明の更に別の態様によれば、通信ネッ
トワークを通じて、エージェント・サービスを与える方
法が提供され、この方法は、１つ以上の被管理オブジェ
クトを拡張可能なエージェント・フレームワークに動的
に登録するステップと、ネットワーク通信プロトコルの
ための１つ以上のネットワーク・アダプタをフレームワ
ークに登録するステップと、ネットワーク・アダプタ
（または複数のネットワーク・アダプタ）を通じて、被
管理オブジェクト（または複数の被管理オブジェクト）
に対するアクセスを可能にするステップとから成る。

【００２１】

【発明の実施の形態】これより本発明の代表的な実施形
態について、一例としてのみ、添付図面を参照しながら
説明する。図面において、同様の参照符号は、同様のエ
レメントに関連するものとする。

【００２２】図１は、マルチ・ステーション・ネットワ
ークを基本としたシステム１の概略図であり、３箇所の
ステーション、即ち、ノード、またはマシン３、４、５
がネットワーク２を通じて接続されている。ネットワー
ク２は、公衆電話交換網および／またはローカル・エリ
ア・ネットワーク、および／またはローカル・エリアお
よび／またはより広いエリア内の専用ネットワーク接続
コンピュータおよびその他の機器、および／またはイン
ターネットまたはイントラネットのようなオープン・ネ
ットワーク、あるいはその組み合わせ、あるいは実際に
は通信管理情報の交換に対応可能な他のあらゆる形式の
通信ネットワークを基本とすることができる。ネットワ
ークは、レベル構造、ピラミッド階層等のような、任意
の所望の構造でよい。

【００２３】ステーション３、４、５の任意の１つ又は
複数は、ネットワーク管理ステーションとして、そのコ
ンフィギュレーションを設定することができる。図１に
示す例では、ステーション３を管理ステーションとし、
ステーション４、５を被管理ステーションとする。いず
れの数の管理ステーションおよび被管理ステーションで
も設けることができ、図１においてステーションを３箇
所としたのは、例示の目的のために過ぎないことは認め
られよう。また、管理および被管理機能は相互に交換可
能であり、実際には、管理機能および被管理機能は、１
つの同じステーションにおいてサポートすることが可能
である。

【００２４】ステーションは、多くの形態を取ることが
できる。例示の目的のために、双方ともコンピュータ・
ワークステーションから成るものと仮定する。図２は、
コンピュータ・ワークステーションのコンフィギュレー
ションの概略図である。図２に示すように、これは、デ
ィスプレイ８、キーボードおよびその他の入力デバイス
９を有するシステム・ユニット１１を備えたサーバ・コ
ンピュータ１０によって実装されている。図２のＡは、
システム・ユニット１１の内容の態様を表す概略ブロッ
ク図である。図２のＡに示すように、システム・ユニッ
ト１１は、プロセッサ１７、メモリ１８、磁気および／
または光ディスク・ドライブ１３、１４、および通信ネ
ットワーク２に接続するための１又は複数の通信ライン
１５に接続するための通信アダプタ１６を含む。図２の
Ａに示すように、このシステム・ユニットのコンポーネ
ントは、バス配列１９を通じて接続されている。図２お
よび図２のＡは、ルータを形成するためのサーバ・コン
ピュータに対する、１つの可能なコンフィギュレーショ
ンの概略図である。また、代わりのコンフィギュレーシ
ョンも多数提供可能であることも認められよう。

【００２５】ワークステーションによって管理ステーシ
ョンが実装される場合には、１又は複数の管理アプリケ
ーションとインターフェース構造とは、典型的に、ソフ
トウエアで供給され、このソフトウエアはワークステー
ションのメモリに格納され、ワークステーションのプロ
セッサによって実行される。

【００２６】ワークステーションによって被管理ステー
ションが実装される場合には、エージェントが、ネット
ワークを通じた管理アプリケーションからの離れた管理
要求に応答し、被管理ステーションにおける被管理オブ
ジェクトへのインターフェースを与える。エージェント
および被管理オブジェクト構造は、典型的に、ソフトウ
エアで供給され、このソフトウエアはワークステーショ
ンのメモリに格納され、ワークステーションのプロセッ
サによって実行される。

【００２７】オブジェクトは、典型的に、１台の機器、
当該機器のコンポーネント、機器あるいはそのコンポー
ネントまたはリソースの動作等をモデル化するために用
いられるパラメータおよびメソッドを備えている。

【００２８】通信ネットワークの管理は、種々のサイズ
および複雑度を有するアプリケーションを必要とする。
重要なマネージャ(heavy manager)、中間マネージャ、
拡張可能なエージェント、スマート・エージェント(sma
rt agent)およびアプライアンス(appliance)は全て、通
信ネットワークの管理において役割を有する。本発明を
組み込むネットワーク管理システムは、拡張可能なエー
ジェント・フレームワークを提供し、これらの異なるア
プリケーション・タイプの全てを、同一アーキテクチャ
上で構築することを可能とする。この拡張可能なエージ
ェント・フレームワークは、ネットワーク管理システム
のコンポーネントによって与えられる。このコンテキス
トにおける拡張可能なエージェント・フレームワークに
対する代わりの用語として、「動的フレームワーク」ま
たは「オープン・フレームワーク」または「ランタイム
・コンポーネント」とすることも可能であるが、ここで
は「フレームワーク」または「拡張可能なエージェント
・フレームワーク」を用いることにする。

【００２９】ネットワーク管理システムには、１組のコ
ア管理サービスが供給される。この１組のサービスから
選択を行うことができ、更に特定のアプリケーションを
開発するために拡張することができる。異なるサービス
を静的にまたは動的にフレームワークにロードし、特定
のアプリケーションの要件を満たすようにする。

【００３０】本発明を組み込んだネットワーク・エージ
ェントの一例における被管理オブジェクトは、好ましく
は、ビーン（bean）として、更に好ましくは、Ｊａｖａ
Ｂｅａｎｓコンポーネントとして実装される。ビーン
（およびJavabeans コンポーネント）は、再利用可能な
ソフトウエア・コンポーネントであり、構築ツール(bui
lder tool)（例えば、エディタまたはグラフィカル・ユ
ーザ・インターフェース・ビルダ（ＧＵＩビルダ））に
おいて視覚的に操作することができる。構築ツールの一
例として、ＪａｖａＢｅａｎｓ開発キットがあげられ
る。ビーンはそのファンクショナリティが様々に変化す
るが、典型的に、ある種の共通した定義構造を共有して
おり、１組のプロパティ、アクションを実行する１組の
メソッド、ならびにイベントおよびイントロスぺクショ
ンに対するサポートを与える。プロパティは、ビーンの
プログラム的な操作を可能とし、ビーンのカスタム化(c
ustomization)をサポートする。メソッドはプロパティ
を実装する。イベントに対するサポートは、ビーンズが
イベントを発火(fire)することを可能とし、発火するこ
とができるイベントを定義する。イントロスぺクション
に対するサポートは、ビーンのプロパティ、イベントお
よびメソッドを、外部から検分することを可能にする。
ＧＥＴ、ＳＥＴ、ＡＣＴＩＯＮ、ＣＲＥＡＴＥおよびＤ
ＥＬＥＴＥというような動作をサポートすることができ
る。

【００３１】エージェントにおける被管理オブジェクト
は、それがフレームワークに登録されると直ちに管理可
能となる。この構成によって、このネットワーク管理シ
ステムにしたがって開発されたエージェントは、エージ
ェントの設計に対する影響を最少に抑えて、管理可能と
なる。

【００３２】先に示したように、ネットワーク管理シス
テムの一例は、ＪａｖａＢｅａｎｓコンポーネント・モ
デルを用いることによって、アプリケーションの開発を
容易にする。この例では、コア管理サービスの全てが、
ＪａｖａＢｅａｎｓコンポーネントとして用意されてい
る。したがって、広く知られたＪａｖａＢｅａｎｓ開発
キットのような、Ｊａｖａアプリケーション・ビルダを
用いて、それらへのアクセスが可能になる。被管理オブ
ジェクトは、ＪａｖａＢｅａｎｓコンポーネントとして
開発される。ネットワーク管理システム・エージェント
におけるＪａｖａＢｅａｎｓコンポーネントは、局所的
にまたは遠隔的にアクセスすることができる。これは、
このネットワーク管理システムを用いて被管理オブジェ
クトを開発する場合、どの通信プロトコルに被管理オブ
ジェクトがアクセスするのかについて知る必要がないこ
とを意味する。

【００３３】ネットワーク管理システムは、拡張可能エ
ージェントの開発を簡略化する。ネットワーク管理シス
テムが提供する１組のコア管理サービスを拡張し、エー
ジェントが実行されている間に、それにロードすること
ができる。コア管理サービスの殆どはオプションであ
る。これが意味するのは、ネットワーク管理システムを
用いて開発したエージェントは、それが用いるサービス
を実装するだけでよいということである。この構造は、
異なるサイズおよび複雑度のエージェントの開発を可能
にする。

【００３４】また、ネットワーク管理システムを用いて
開発したエージェントは、スマート・エージェントでも
ある。スマート・エージェントは、管理要求を処理する
ために必要とされるサービスを提供する。スマート・エ
ージェントでは、処理の多くは、エージェント自体の中
で局所的に行うことができるので、エージェントと管理
システムとの間のネットワーク接続上の負荷が減少す
る。

【００３５】図３は、ネットワーク管理システム・エー
ジェントのアーキテクチャの一態様を示し、ネットワー
ク管理システムのコンポーネント間の関係を含む。ま
た、図３は、ネットワーク管理システム・エージェント
と管理アプリケーションとの間の関係も示す。

【００３６】図３に示すように、ネットワーク管理シス
テム・エージェントは、Ｊａｖａ仮想マシン（ＶＭ：vi
rtual machine）の内側にある多数のコンポーネントか
ら成る。これらは、 − ｍ−ビーン２９、 − フレームワーク２４、 − コア管理サービス２５、２６、２７、２８、 − 被管理オブジェクト・アダプタ・サーバ３０、３
２、３４、３６、３８、 を含む。これらのコンポーネントについて、以下で更に
詳細に説明する。

【００３７】被管理オブジェクト（managed object）と
は、エージェントによって制御され監視される、リソー
スのソフトウエア抽象化(software abstraction)であ
る。被管理オブジェクト（例えば２８）のことを、管理
ビーンまたはｍ−ビーンと呼ぶ。ネットワーク管理シス
テムの一例では、全てのｍ−ビーンはＪａｖａＢｅａｎ
ｓコンポーネントとして実装される。したがって、先に
述べたＪａｖａＢｅａｎｓ開発キットのような、従来の
Javaアプリケーション・ビルダを用いて、これらにアク
セスすることができる。

【００３８】他のいずれの被管理オブジェクトに関して
も、ｍ−ビーンは１組のプロパティを有し、１組のアク
ションを実行することができ、１組の通知またはイベン
トを送出することができる。ネットワーク管理システム
は、ｍ−ビーンにおけるリード専用プロパティとリード
／ライト・プロパティとの間で区別することを可能とす
る。

【００３９】ｍ−ビーンは、フレームワーク２４によっ
て登録されると直ちに管理可能となる。ｍ−ビーンが登
録されると、オブジェクト名がそれに関連付けられる。
このオブジェクト名が、ｍ−ビーン・レポジトリ（以下
を参照のこと）内の当該ｍ−ビーンを一意的に識別す
る。それによって、管理アプリケーションが、管理処理
を実行しようとするｍ−ビーンを識別することが可能に
なる。ｍ−ビーンのオブジェクト名は、任意の名称であ
り、ｍ−ビーンがどのように実装されるかには、全く依
存しない。

【００４０】フレームワーク２４は管理サービスを制御
し、エージェント２０のｍ−ビーンはフレームワーク２
４にロードされる。フレームワーク、即ち、ランタイム
・コンポーネント２４は、ＪａｖａＢｅａｎｓコンポー
ネントであり、１組のプロパティ、アクションを実行す
るための１組のメソッド、ならびにイベントおよびイン
トロスぺクションに対するサポートを備えている。プロ
パティは、ゲッタ(getter)およびセッタ(setter)プロパ
ティを含む。メソッドは、ゲッタおよびセッタ・プロパ
ティを実装するメソッドを含む。また、フレームワーク
は、オブジェクト追加機能(add object function)およ
びオブジェクト除去機能(remove objectfunction)を実
行することも可能である。

【００４１】エージェント２０が、ネットワーク・アダ
プタを介して受信した管理処理を実行するように要求さ
れたときはいつでも、フレームワーク２４は、適切なサ
ービスをコールし、要求された処理を実行する。また、
フレームワーク２４は、ｍ−ビーン２８と被管理オブジ
ェクト・アダプタ・サーバ３０〜３８との間の通信も取
り扱う。ｍ−ビーンは、フレームワーク２４に問い合わ
せを行い、フレームワーク２４の同じインスタンスにロ
ードされている他のｍ−ビーン２８に関する情報を得る
ことができる。フレームワーク２４の１つのインスタン
スのみが、仮想マシン２２内で許される。

【００４２】ネットワーク管理システムは、多数のコア
管理サービスを提供する。このシステムの一例では、コ
ア管理サービスは、Ｊａｖａインターフェースとして定
義される。コア管理サービスはオプションである。これ
が意味するのは、ネットワーク管理システムを用いて開
発したエージェントは、それが用いるサービスのみを実
装すればよいということである。コア管理サービスは、
ｍ−ビーンとして登録することができ、これによって、
いくつかの管理処理をその上で形成し、そのビヘービャ
(behaviour)を調整(tune)することを可能にする。

【００４３】このシステムの好適な例では、コア管理サ
ービスは、ＪａｖａＢｅａｎｓコンポーネントとして与
えられる。したがって、先に述べたＪａｖａＢｅａｎｓ
開発キットのような、従来のＪａｖａアプリケーション
・ビルダを用いて、これらにアクセスすることができ
る。

【００４４】次に、多数のコア管理サービスについて説
明する。

【００４５】ｍ−ビーン・レポジトリ・サービス２７
は、ｍ−ビーンへのポインタを得る。ｍ−ビーンがフレ
ームワーク２４に登録される毎に、フレームワーク２４
は、ｍ−ビーン・レポジトリ・サービス２７をコール
し、当該ｍ−ビーンの識別子(identity)を格納する。ｍ
−ビーンには名称が関連付けられる。ｍ−ビーン・レポ
ジトリ２７に問い合わせをすると、エージェントおよび
マネージャ・アプリケーションは、ｍ−ビームをその名
称によって識別することができる。ｍ−ビーン・レポジ
トリ・サービス２７は、異なる実装方法が可能である。
あるインプリメンテーションでは、永続的なｍ−ビーン
を格納するためにリレーショナル・データベースを用
い、一方、別のインプリメンテーションでは、非永続的
なｍ−ビームを格納するために単純なメモリを用いる。

【００４６】レポジトリ・ユニットによって与えられる
構造を考慮しながら、エージェントのコンポーネント間
の関係の別の表現を図４に示す。これは、被管理オブジ
ェクト・アダプタ・サーバ、管理サービス、および非管
理オブジェクトに対するビーンのｍ−ビーン・レポジト
リ・サービス・ビーンへの登録(registration)を考慮し
たものである。

【００４７】フィルタリング・サービス(filtering ser
vice)２９は、ｍ−ビーンを管理処理の主題に選択す
る。選択は、特定の属性の存在および値を基準とする。
例えば、フィルタは、属性カラーが赤にセットされてい
る全てのｍ−ビーンを選択することができる。

【００４８】メタデータ・サービス(metadata service)
２５は、ｍ−ビーンの構造に関する情報を与える。例え
ば、フレームワーク２４は、メタデータ・サービス２５
に問い合わせを行い、ｍ−ビーン内のプロパティを得て
設定するためのメソッドにアクセスする。メタデータ・
サービス２５は、イントロスぺクションを実行するＪａ
ｖａＢｅａｎｓ開発キットによって与えられるリフレク
ションＡＰＩに基づく。

【００４９】動的クラス・ローディング・サービス(dyn
amic class loading service)は、新しいクラスをフレ
ームワーク２４にロードする。新しいクラスがロードさ
れるのは、リモート・エントリが、フレームワーク２４
にロードされていないクラスのインスタンスの作成を要
求するときである。新しいクラスは、リモート・クラス
・サーバからロードすることができる。また、動的ロー
ディング・サービスは、ネットワーク管理システム・エ
ージェントの実行中に、コア管理サービスをこれに追加
することを可能にする。例えば、フィルタリング・サー
ビスがなくとも、エージェントを開始することができ
る。そして後に、フィルタリング・サービスが必要とさ
れるときに、それをエージェントに動的に追加すること
ができる。

【００５０】アクセス制御サービス(access control s
ervice)は、ｍ−ビーンへのアクセスを制御するために
提供することができる。ｍ−ビーン上で管理処理を実行
しようとする前に、その処理が有効であることを確認す
るために、アクセス制御サービスに問い合わせするよう
に、フレームワーク２４を構成することができる。

【００５１】イベント・サービス(event service)は、
ｍ−ビーンからイベント報告を受け取り、それらを受け
取ることを要求した任意のエンティティにそれらを送出
するために提供することができる。

【００５２】関係サービス(relationship service)は、
ｍ−ビーン間の関係を、それらが要求されるときに定義
することを可能にするために提供することができる。関
係を前もって定義しておく必要はない。ｍ−ビーン間の
関係に関する情報は、ｍ−ビーン自体には格納されるの
ではなく、関係サービスから得ることができる。

【００５３】動的ネーティブ・ライブラリ・ローディン
グ・サービス(dynamic native library loading servic
e)は、ネーティブ・コードをフレームワーク２４にロー
ドするために提供することができる。ネーティブ・ライ
ブラリは、ネーティブ・コードを含む新しいクラスをロ
ードするときに、ロードすることができる。ロードされ
るライブラリは、ハードウエア・プラットフォーム、お
よびフレームワークが実行されるオペレーティング・シ
ステムに依存する。ネーティブ・ライブラリは、離れた
エンティティからロードすることができる。

【００５４】続いて、被管理オブジェクト・アダプタ・
サーバ３０〜３８の説明を行う。

【００５５】被管理オブジェクト・アダプタ・サーバと
は、通信プロトコルの抽象化を与えるプロトコル・アダ
プタである。それぞれの被管理オブジェクト・アダプタ
・サーバは、特定の通信プロトコルを通じて、ｍ−ビー
ンへのアクセスを与える。被管理オブジェクト・アダプ
タ・サーバは、管理アプリケーションが、ネットワーク
管理システム・エージェント上で管理処理を実行するこ
とを可能にする。

【００５６】ネットワーク管理システム・エージェント
を管理可能とするためには、少なくとも１つの被管理オ
ブジェクト・アダプタ・サーバを介してそれを接続す
る。しかし、ネットワーク管理システム・エージェント
は、任意の数の被管理オブジェクト・アダプタ・サーバ
に接続可能であり、異なるプロトコルを用いるリモート
管理アプリケーションがそれに問い合わせを行うことが
できる。

【００５７】ネットワーク管理システムは、被管理オブ
ジェクト・アダプタ・サーバを、標準的なプロトコルお
よびプロプライエタリ(proprietary)なプロトコルに与
える。

【００５８】例えば、被管理オブジェクト・アダプタ・
サーバを、１又は複数の標準的プロトコル、例えば、Ｈ
ＴＭＬ／ＨＴＴＰ、ＳＮＭＰ、およびＣＯＲＢＡのため
に与えることができる。

【００５９】標準的なプロトコルのための被管理オブジ
ェクト・アダプタ・サーバは、それらを用いる管理アプ
リケーションと直接通信する。

【００６０】例えば、ＨＴＭＬ／ＨＴＴＰ被管理オブジ
ェクト・アダプタ・サーバは、ユーザがウエブ・ブラウ
ザを用いて、ｍ−ビーン内に含まれる管理情報を見た
り、ネットワーク管理システム・エージェント上で管理
処理を行うことを可能にする。ＨＴＭＬ／ＨＴＴＰ被管
理オブジェクト・アダプタ・サーバは、ｍ−ビーンから
管理情報を得て、この管理情報を表すＨＴＭＬページを
生成する。

【００６１】ＳＮＭＰ被管理オブジェクト・アダプタ・
サーバは、特定的に定義されたＳＮＭＰ管理情報ベース
（ＭＩＢ：management information base）を用い、Ｓ
ＮＭＰマネージャがネットワーク管理システム・エージ
ェント上で管理処理を行うことを可能にするように構成
することができる。

【００６２】また、ネットワーク管理システムは、被管
理オブジェクト・アダプタ・サーバを、１又は複数の次
のプロプラエタリなプロトコル、ＲＭＩ、Ｊａｖａ／Ｈ
ＴＴＰ、およびセキュア・ソケット・レイヤ（ＳＳＬ：
Secure Sockets Layer）のために与えるように構成する
ことも可能である。ネットワーク管理システムの一例で
は、被管理オブジェクト・アダプタ・クライアントは、
Ｊａｖａ ＡＰＩを提供する。したがって、被管理オブ
ジェクト・アダプタ・クライアントを用いるどの管理ア
プリケーションも、Ｊａｖａ言語で書かれることにな
る。

【００６３】ネットワーク管理システムを用いて開発さ
れたエージェントは、異なる通信または管理プロトコル
を用いて管理することができる。標準的な管理プロトコ
ルを用いて管理するためには、ネットワーク管理システ
ム・エージェントを、当該プロトコルのための被管理ア
ダプタ・サーバに接続する必要がある。標準的なプロト
コルのための被管理オブジェクト・アダプタ・サービス
は、それを用いる管理アプリケーションと直接通信す
る。

【００６４】図４のエージェントの表現を用いて、この
構造の一例を図５に示す。図５では、エージェントに
は、ウエブ・ブラウザ４６によってアクセスする。ここ
では、ＨＴＭＬアダプタによって、ビーンがＨＴＭＬペ
ージにマップされることが可能になる。ＨＴＭＬのよう
なプロトコルを用いることによって、クライアント・ス
テーション９０におけるブラウザ４６が、リモート・ス
テーション２０においてビーンをブラウズし、従来のウ
エブ・ブラウザ機能を用いてそれらにアクセスし、更に
必要であれば修正することができる。図４に示す構造に
よれば、レポジトリ・サービス２７はフレームワーク２
４に登録(register)されており、ＨＴＭＬアダプタ３４
およびビーン（複数のビーン）２９はレポジトリ・サー
ビスに登録されており、これによってビーン（複数のビ
ーン）は、ＨＴＭＬアダプタ３４がサポートするＨＴＭ
Ｌページに有効に登録される。図５において、同様の参
照番号は、図４に示した構成の同様の構造(feature)に
関連する。

【００６５】図６は、リモート・マシンにおいてビーン
のプロパティの修正を可能にするステップを示すフロー
・チャートである。ステップ９２において、ＨＴＭＬア
ダプタ３４が、リモート・ステーション２０における仮
想マシン２２内で起動され、ステップ９４において、遠
方からアクセス可能であるべきその仮想マシン２２のビ
ーン（複数のビーン）２９を、フレームワーク、更に特
定すれば、上述のようなレポジトリ・サービス２７に登
録する。これは、ＨＴＭＬアダプタがフレームワーク２
４に問い合わせする場合、フレームワーク２４は、レポ
ジトリ・サービスを参照して、アクセスすべきビーン２
９を識別し、ＨＴＭＬアダプタにそのビーン２９にアク
セスさせることができるということを意味する。

【００６６】ＨＴＭＬアダプタ３４は、従来のＨＴＴＰ
交換を用いて、ネットワーク上での通信を可能にする。
これは、ＨＴＴＰサーバとして振る舞う。要求を受信し
た場合、現在レポジトリ・オブジェクト２７に登録され
ているビーン（オブジェクト）２９のリストを含むペー
ジを動的に生成する。

【００６７】ビーンは、ＨＴＭＬでは、ＨＴＭＬテーブ
ルとして表され、その中では、第１コラムがプロパティ
名を含み、第２コラムがプロパティ型を含み、第３コラ
ムがアクセス権（リード／ライト）を含み、第４コラム
がプロパティ値を含む。

【００６８】前述のように、プロパティがリード／ライ
トの場合、ＨＴＭＬフォームが生成される。

【００６９】ステップ９６では、前述のように、ＨＴＴ
Ｐ交換を用いてＨＴＭＬアダプタとの通信を行う従来の
ウエブ・ブラウザを用いてＨＴＭＬページにアクセスす
ることにより、ビーンのＨＴＭＬ表現を用いて、クライ
アント・ステーションにおいて（ディスプレイ９８によ
って表されている）ビーンを表示する。次に、ステップ
１００において、ユーザは、従来のウエブ・ブラウザ機
能を用いて、ビーンを選択することができる。次に、ウ
エブ・ブラウザは、ＨＴＴＰ ＧＥＴ要求をＨＴＭＬア
ダプタ３４に発行する。ＨＴＭＬアダプタは、イントロ
スぺクションを用いて、ビーン・プロパティを抽出し、
ＨＴＭＬポスト応答(HTML post response)をブラウザに
返し、これによって、ステップ１０２に示すように、ブ
ラウザはプロパティを表示することができ、更に、ビー
ンにサポートされるアクションおよびイベントも表示す
ることができる。従来のブラウザ機能を用いてブラウザ
を更に利用することにより、ユーザは、ビーンの態様に
対する修正、例えば、プロパティに対する変更を選択し
指定することができる。ＨＴＭＬ ＧＥＴおよび／また
はＳＥＴ要求およびＰＯＳＴ応答を更に交換することに
より、ウエブ・ブラウザおよびＨＴＭＬアダプタは、ス
テップ１０４で、リモート・ステーションにおいてビー
ンの対応するプロパティを修正し、これらの変更をクラ
イアント・ステーションにおいてユーザに表示すること
ができる。

【００７０】このように、この機構は、クライアントの
マシンから、リモート・マシンにおけるビーンのような
オブジェクトに、リモート通信ネットワークを通じてア
クセスするコンピュータによる実装方法を提供する。そ
の際、リモート・マシンにおける外部からアクセス可能
なマシン・ページに当該オブジェクトをマップし、ブラ
ウザを用いてそのマシン・ページを介してオブジェクト
をブラウズする。

【００７１】図３に示す構造の別の例を図７に示す。こ
こでは、図３の表現を用い、ネットワーク管理システム
・エージェント２０が、ＳＮＭＰマネージャ・アプリケ
ーションによって管理される。図７において、同様の参
照番号は、図３に示した構成の同様の構造に関連する。

【００７２】図８に表すネットワーク管理システムの一
例は、アダプタＡＰＩを備え、Ｊａｖａ管理アプリケー
ションが、ネットワーク管理システム・エージェントと
通信することを可能にする。アダプタＡＰＩは、特定の
通信プロトコルを通じて被管理オブジェクトにアクセス
するために、被管理オブジェクト・アダプタ・クライア
ントを与える。ネットワーク管理システムは、Ｊａｖａ
管理アプリケーションのためにｍ−ビーンの表現を定義
し、ｍ−ビーンからそのような表現を自動的に生成する
ためのコンパイル・ツールを与える。名称サービスを供
給し、Ｊａｖａ管理アプリケーションを、特定の通信プ
ロトコルとは独立させる。 被管理オブジェクト・アダ
プタ・クライアントとは、Ｊａｖａ管理アプリケーショ
ンが被管理オブジェクトにアクセスできるようにする、
抽象Ｊａｖａクラス(abstract Java class)である。Ｊ
ａｖａ管理アプリケーションに対する被管理オブジェク
トのプログラム的表現は、被管理オブジェクト・アダプ
タ・クライアントによって決定される。かかる機構は、
同一の被管理オブジェクトを異なる表現で、異なるＪａ
ｖａ管理アプリケーションに提示することを可能にす
る。ネットワーク管理システムは、１つ以上の次のプロ
トコル、ＲＭＩ、ＨＴＴＰ、およびＳＳＬを通じて被管
理オブジェクトにアクセスするために、被管理オブジェ
クト・アダプタ・クライアントを与える。

【００７３】被管理オブジェクト・アダプタ・クライア
ントは、アダプタ管理オブジェクト・インターフェース
(adaptor managed object interface)の定義を与える。
アダプタ管理オブジェクト・インターフェースは、Ｊａ
ｖａ管理アプリケーションが、ネットワーク管理システ
ム・エージェント上で、次の管理処理の１つ又は複数を
実行することを可能にする。

【００７４】− ｍ−ビーンを検索すること、 − リモートｍ−ビーンのプロパティを得るまたはセッ
トすること、 − リモートｍ−ビーンのメソッドをコールすること、 − ｍ−ビーンのインスタンスを作成すること、 − ｍ−ビーンを削除すること、および − リモートｍ−ビーンによって送出されたイベントを
受信すること。

【００７５】被管理オブジェクト・アダプタ・クライア
ントは、Ｊａｖａ管理アプリケーションに、リモート・
エージェントにおける被管理オブジェクト上の「ハンド
ル」を与える。これらのハンドルは、Ｊａｖａ管理アプ
リケーションが、被管理オブジェクトを直接操作するこ
とを可能にする。Ｊａｖａ管理アプリケーションは、被
管理オブジェクトによって用いられるプロトコルに関す
る情報を必要としない。Ｊａｖａ管理アプリケーション
が必要とするのは、被管理オブジェクトが表すオブジェ
クトのクラスだけである。例えば、アカウントを処理す
るためのＪａｖａ管理アプリケーションは、アカウント
を表すための抽象クラスを用いる。アカウントを操作す
るために、Ｊａｖａ管理アプリケーションは、被管理オ
ブジェクト・アダプタ・クライアントから、アカウント
被管理オブジェクト(account managed object)を得る。
次に、アカウント被管理オブジェクトを、当該オブジェ
クトを表す抽象クラスに組み込む(cast)。このようにし
て、アプリケーション・コードは、被管理オブジェクト
がどのように実装されるかとは無関係となる。

【００７６】図８は、クライアント・ビーン（ｃ−ビー
ン）５４とｍ−ビーン２８との間の関係の概略図であ
る。ｃ−ビーン５４は、Ｊａｖａ管理アプリケーション
に対する、ｍ−ビーンの表現である。本発明の好適実施
例では、ｃ−ビーン５４は、ｍ−ビーン２８と同様に、
ＪａｖａＢｅａｎｓコンポーネントとして実装される。
ｃ−ビーン５４は、Ｊａｖａ管理アプリケーションがど
のようにしてｍ−ビーン２８にアクセスするのかを定義
する。

【００７７】図８に見られるように、ｃ−ビーン５４
は、ｍ−ビーンのメソッドの内どれがＪａｖａ管理アプ
リケーションにアクセス可能かを定義する被管理オブジ
ェクト・インターフェース（ＭＯインターフェース）５
６と、ＭＯインターフェース５６において定義されたメ
ソッドを実装する被管理オブジェクト・スタブ（ＭＯス
タブ）５８とから成る。

【００７８】Ｊａｖａ管理アプリケーションは、アダプ
タＭＯインターフェース６０を用いることによって、ｃ
−ビーンへの参照を得る。アダプタＭＯインターフェー
スは、ｃ−ビーン５４をインスタンス化する。ｃ−ビー
ン５４の同じインプリメンテーションが、アダプタＭＯ
インターフェース６０を実装する任意の被管理オブジェ
クト・アダプタ・クライアント上で実行することができ
る。同じ被管理オブジェクトの異なるインプリメンテー
ションを、異なるＪａｖａ管理アプリケーションに提示
することができる。このようにして、単一のｍ−ビーン
を、いくつかのｃ−ビーン５４と関連付けることができ
る。

【００７９】Ｊａｖａ管理アプリケーションは、それに
関連するｃ−ビーン５４のメソッドをコールすることに
より、ｍ−ビーン上で管理処理を実行する。Ｊａｖａ管
理アプリケーションから見ると、ｃ−ビーン５４は、リ
モートＪａｖａオブジェクト（ｍ−ビーン２８）のロー
カル表現となる。

【００８０】アダプタＭＯインターフェース６０は、ｃ
−ビーン５４をインスタンス化する。ｃ−ビーンの同じ
インプリメンテーションは、アダプタＭＯインターフェ
ース６０を実装する、任意の被管理オブジェクト・アダ
プタ・クライアント６２上で実行することができる。同
じ被管理オブジェクトの異なる表現を、異なるＪａｖａ
管理アプリケーションに提示することができる。このよ
うにして、単一のｍ−ビーンをいくつかのｃ−ビーンと
関連付けることができる。

【００８１】Ｊａｖａ管理アプリケーションは、それに
関連するｃ−ビーンのメソッドをコールすることによっ
て、ｍ−ビーン上で管理処理を実行する。Ｊａｖａ管理
アプリケーションから見ると、ｃ−ビーンはリモートＪ
ａｖａオブジェクト（ｍ−ビーン）のローカル表現とな
る。

【００８２】図９は、ｍ−ビーンからのｃ−ビーン５４
の生成を表す概略図である。本発明の一実施例では、ｃ
−ビーンは、リフレクションＡＰＩを用いて、ｍ−ビー
ン２８から自動的に生成される。生成されたｃ−ビーン
は、ｍ−ビーンと同じプロパティ、メソッド、およびイ
ベントを有する(exhibit)。これは、例えば、アクセス
制御ポリシー(access control policy)が執行されない
場合である。

【００８３】ｍ−ビーン２８からｃ−ビーン５４を自動
的に生成するために、コンパイラ６０が、ｍ−ビーン２
８を入力として取り込み、ｃ−ビーン５４のＭＯインタ
ーフェースおよびＭＯスタブを出力として生成する。例
えば、accountと称するＪａｖａクラスを表すｍ−ビー
ン２８をコンパイルする場合、コンパイラ６０は、accm
ountMOと称するＭＯインターフェース５６およびaccoun
tMOSTUB５８と称するＪａｖａクラスを生成する。accou
ntMOSTUB５８は、accoutMOインターフェース５６を実装
する。

【００８４】Ｊａｖａ管理アプリケーションは、ＭＯイ
ンターフェースの定義を用いて、開発することができ
る。異なるスタブをロードすることによって、adaptorM
Oインターフェースは、実行時に、Ｊａｖａ管理アプリ
ケーションのビヘービャを修正することができる。例え
ば、リード・オンリ・スタブをロードする場合、Ｊａｖ
ａ管理アプリケーションは、ｍ−ビーン２８内のプロパ
ティを修正することはできない。

【００８５】コンパイラ６０は、リード・オンリ・スタ
ブまたはリード／ライト・スタブを生成することができ
る。生成されたスタブは、adaptorMOインターフェース
を利用する。したがって、それらのビヘービャは、被管
理オブジェクト・アダプタ・クライアントのインプリメ
ンテーションとは無関係に、adaptorMOインターフェー
スを実装する任意の被管理オブジェクト・アダプタ・ク
ライアント上においても同一である。

【００８６】図１０は、図８に示す構造を用いて、ロー
カル管理（クライアント）ステーションから、リモート
（サーバ）ステーションにおけるビーンにアクセスする
ためのステップを示すブロック図である。

【００８７】管理ステーションにおける管理アプリケー
ション（例えば、Ｊａｖａ管理アプリケーション）は、
ステップ８０において、クライアント・ステーションに
おけるadaptorMOへの獲得要求(get request)を生成す
る。ステップ８１において、adaptorMOは、クライアン
ト・ステーションにおけるＭＯスタブおよびネットワー
ク・アダプタを用いて、適切なネットワーク・プロトコ
ル（例えば、ＨＴＴＰ）にしたがって要求を生成する。

【００８８】このようにネットワークを通じて被管理シ
ステムに送られる要求は、例えば、被管理オブジェクト
の管理プロパティのためのＧＥＴ要求の形態とすること
ができる。

【００８９】適切な被管理オブジェクト・アダプタ・サ
ーバ３０〜３８が、用いられるプロトコルに従って、ス
テップ８２において、外部要求を受信する。次に、ステ
ップ８３において、フレームワーク２４にアクセスし、
適切なメソッドを得る。フレームワークは、ステップ８
３において、当該要求に対する被管理オブジェクト・メ
ソッドを獲得し、ステップ８４において、その被管理オ
ブジェクトの管理プロパティをアダプタに返す。一方、
アダプタは、ステップ８５において、同じネットワーク
・プロトコル（例えば、ＨＴＴＰ）にしたがって、リタ
ーン・メッセージをその結果と合成する。結果のメッセ
ージは、ステップ８６において、クライアント・アダプ
タおよびadaptorMOにおいて受信され、その結果を管理
アプリケーションに返す。

【００９０】管理アプリケーションを特定の通信プロト
コルから独立させる名称サービスが提供される。Ｊａｖ
ａ管理アプリケーションは、この名称サービスを用い
て、エージェントにアクセスするためにどの被管理オブ
ジェクト・アダプタ・クライアントを用いるべきかを決
定する。図１１は、名称サービスの処理を示す概略フロ
ー・チャートである。

【００９１】ステップ６２において、管理アプリケーシ
ョンは、アクセスすべきエージェントの識別子(identit
y)を主サービスに渡す。

【００９２】ステップ６４において、名称サーバは、被
管理オブジェクト・アダプタ・クライアントのクラス
名、例えば、Ｊａｖａ ＲＭＩシステムによるエージェ
ントのアクセスの場合であれば、sunw.jaw.moa.rmiを返
す。

【００９３】ステップ６６において、Ｊａｖａ管理アプ
リケーションは、そのデフォルトのクラス・ローダを用
いて、被管理オブジェクト・アダプタ・クライアントを
動的にロードし、それをインスタンス化する。Ｊａｖａ
管理アプリケーションは、次に、通信プロトコルには無
関係に、被管理オブジェクト・アダプタ・クライアント
を通じて、エージェントと相互処理を行う。

【００９４】前述のように、管理ビーン即ちｍ−ビーン
は、ネットワーク管理システム・エージェントにおける
被管理オブジェクトである。被管理オブジェクトは、当
該エージェントによって制御および監視されるリソース
のソフトウエア抽象化(software abstraction)である。
ネットワーク管理システムの例では、全てのｍ−ビーン
は、ＪａｖａＢｅａｎｓコンポーネントとして実装され
る。これらには、Ｊａｖａ Ｂｅａｎｓ開発キットのよ
うな、従来のＪａｖａアプリケーション・ビルダを用い
てアクセスすることができる。ｍ−ビーン内では、ネッ
トワーク管理システムによって提供されるサービスのコ
ールおよび使用が可能である。

【００９５】ＪａｖａＢｅａｎｓコンポーネントは、当
該ＪａｖａＢｅａｎｓコンポーネントの外観またはビヘ
ービャに影響を与え得る個別の名称付き属性(named att
ribute)を形成するプロパティを含む。例えば、イーサ
ネット・ドライバを表すｍ−ビーンは、入来するパケッ
ト数を表すIpacketsと称するプロパティを有することが
できる。プロパティは任意の値を有することができ、ビ
ルトインＪａｖａエンド型およびjava.awt.colorのよう
なクラスまたはインターフェース型の双方を含む。プロ
パティは、常に、それらを所有するオブジェクト上での
メソッド・コールを通じてアクセスされる。読み取り可
能なプロパティでは、プロパティ値を読み取るためのge
tメソッドがある。書込可能なプロパティでは、プロパ
ティ値を更新可能にするsetメソッドがある。

【００９６】プロパティを位置付けるために、次のよう
なデフォルトの設計パターンを使用することができる。

【００９７】 public PropertyType get PropertyName(); public void set PropertyName (PropertyType値); クラス定義が、セッタ(setter)のパラメータ型に対応す
るゲッタ(getter)のリターン型と一致する１対のget Pr
opertyNameおよびset PropertyNameメソッドを含む場
合、これらのメソッドは、リード／ライト・プロパティ
を定義する。クラス定義がこれらのメソッドの一方のみ
を含む場合、その名称は、PropertyNameと呼ばれるリー
ド・オンリまたはライト・オンリ・プロパティのいずれ
かを定義する。

【００９８】ブーリアン・プロパティ(Boolean propert
y)に加えて、次の設計パターンを用いてgetメソッドを
定義することが可能である。

【００９９】public boolean isPropertyName() このPropertyNameメソッドは、getPropertyNameメソッ
ドの代わりに提供することもでき、その場合、getPrope
rtyNameメソッドに加えて備えてもよい。

【０１００】インデックス・プロパティとは、以下の形
態のメソッドによってアクセスされるアレイPropertyEl
ement[]である。

【０１０１】public PropertyElement getPropertyName
(int index); public void setPropertyName (int index, PropertyEl
ementb) クラス定義がいずれかの種類のメソッドを含む場合、Pr
opertyNameはインデックス・プロパティとなる。これら
のメソッドは、プロパティ値を読み取るためおよび書き
込むために用いることができる。これらのメソッドは、
単純なプロパティのために定義されるメソッドに加えて
定義することができる。したがって、インデックス・プ
ロパティは、４つのアクセサ・メソッド(accessor meth
od)によって表すことができる。

【０１０２】デフォルトでは、次の設計パターンを用い
て、どのイベントをｍ−ビームがマルチキャスト(multi
cast)することができるのかについて判定を行なう。

【０１０３】public void addEventListenerType(Event
ListenerType a); public removeEventListenerType(EventListenerType
a); これらのメソッドは双方共、EventListenerType 型のア
ーギュメントを取り、EventlistenerType型はjava.uti
l.EventListenerインターフェースに継承し、最初のメ
ソッドはaddから開始し、２番目のメソッドはremoveか
ら開始し、EventListenerType型名は、Listenerで終わ
る。

【０１０４】この設計パターンは、Ｊａｖａビーンが、
EventListenerType インターフェースにおいて指定され
たイベントに対して、マルチキャスト・イベント・ソー
スとして動作することを想定している。

【０１０５】ＪａｖａＢｅａｎｓモデルに従うために、
ＪａｖａＢｅａｎｓコンポーネントの全てのパブリック
・メソッドは、コンポーネントによるアクセスのために
コンポーネント環境内では外部メソッドとして露出させ
なければならない。デフォルトでは、これはプロパティ
・アクセサ・メソッドを、そして最終的にリスナ・レジ
ストリ・メソッド(listener registry method)を含む。

【０１０６】設計パターン・エレメントのためのＪａｖ
ａＢｅａｎｓコンポーネント・モデルに加えて、ネット
ワーク管理システムは、アクションを、遠方からコール
する意味のあるｍ−ビーンのパブリック・メソッドとし
て定義することができる。アクションは、他のローカル
ｍ−ビーンに対して露出されるｍ−ビーンのパブリック
・メソッドの、遠方からコールすることができるパブリ
ック・メソッドからの差別化を容易にする。アクション
のための設計パターンは次の通りである。

【０１０７】 public AnyJavaType performAnAction (AnySignature); ｍ−ビーンは、ネーティブなライブラリを含むことがで
きる。これは、ｍ−ビーンの言語（例えば、Ｊａｖａ）
で書かれていないライブラリである。ネットワーク管理
システムは、ｍ−ビーンと同じリモート・クラス・サー
バからネーティブなライブラリをロードする機構を提供
することができる。ｍ−ビーンがこの機構を使用するこ
とを可能とするために、フレームワーク・クラスの静的
なloadLibraryメソッドをコールすることができ、その
際、コール元が、当該コール元のＪａｖａクラスへの参
照を含む。かかる情報は、フレームワーク２４が、クラ
スをロードするために用いるクラス・ローダを識別する
ために用いられる。

【０１０８】上述のコア管理サービスは、全てのエージ
ェントに共通である多くの管理処理のためのものであ
り、これによってエージェントの開発を簡略化する。こ
れらのコア・サービスを提供することにより、ネットワ
ーク管理システムは、特定のアプリケーションに特有の
エージェントの部品、即ち、ｍ−ビーンおよびそれらを
制御し管理するアプリケーションの開発に、努力を集中
させることができる。

【０１０９】図１２は、ネットワーク管理システム・エ
ージェント２０の初期化を示す概略フロー・チャートで
ある。この初期化プロセスは、以下のステップを含む。

【０１１０】− ステップ７０において、フレームワー
ク２４のインスタンスを作成する。

【０１１１】− ステップ７２において、ｍ−ビーン・
レポジトリ・サービス２７を追加する。

【０１１２】− ステップ７４において、メタデータ・
サービス２９を追加する。

【０１１３】− ステップ７６において、少なくとも１
つの被管理オブジェクト・アダプタ・サーバ（３０〜３
８）を追加し、管理アプリケーションがエージェントに
アクセスできるようにする。

【０１１４】ネットワーク管理システム・エージェント
２０がいったん初期化されると、エージェントを開始す
る前に、それ以上の管理サービスを追加する必要はな
い。これらは、エージェントの実行中に、動的にそれに
追加することができる。

【０１１５】フレームワーク２４は、ネットワーク管理
システムを用いて開発したエージェント２０の管理サー
ビスおよびｍ−ビーンを制御する。この好適実施例で
は、これは、Ｊａｖａクラスjava.jaw.agent.cmf.Frame
workによって実装される。エージェントは、フレームワ
ークのインスタンスを１つ含まなければならない。即
ち、好適実施例では、java.jaw.agent.cmf.Frameworkク
ラスの１つのインスタンスを含まなければならない。

【０１１６】この好適実施例では、ｍ−ビーンは、エー
ジェント２０のｍ−ビーン・レポジトリ２７にオブジェ
クト名を登録した場合にのみ管理することができる。し
たがって、エージェント２０が動作状態となる前に、ス
テップ７２においてｍ−ビーン・レポジトリ・サービス
２７を追加する。ｍ−ビーン・レポジトリ・サービス２
７は、ｍ−ビーンとそのオブジェクト名との間の関連(a
ssociation)を格納し検索するために用いられる。この
好適実施例のｍ−ビーン・レポジトリ・サービスは、Ｊ
ａｖａインターフェースjava.jaw.agent.services.MoRe
pSrvIfとして定義される。エージェントは、常に一度に
１つのｍ−ビーン・レポジトリ・サービスとのみ関連付
けることができる。しかし、エージェントが動作状態に
ある間には、当該エージェントが関連付けられているｍ
−ビーン・レポジトリ・サービスを変更することは可能
である。

【０１１７】ｍ−ビーン・レポジトリは、揮発性記憶装
置または永続的記憶装置として実現することができる。
揮発性レポジトリでは、ｍ−ビーンに関する全ての情報
をメモリに格納する。揮発性レポジトリ内の全ての情報
は、エージェントを停止したときに失われる。したがっ
て、揮発性レポジトリを用いてエージェントを開始する
場合には、情報をレポジトリに再ロードしなければなら
ない。永続的レポジトリでは、ｍ−ビーンに関する情報
の全てはデータベースに格納され、それによって、エー
ジェントを停止した場合でも、永続的レポジトリ内の情
報は失われない。また、混合レポジトリを実施すること
によって、ｍ−ビーンに関する情報をメモリまたはデー
タベースに格納することも可能である。

【０１１８】先に引用したメタデータ・サービスを用い
て、ｍ−ビーンがによってサポートされるプロパティお
よびアクションを得る。メタデータ・サービスの好適な
実施形態は、イントロスペクションを実行する公知のＪ
ａｖａ開発キットによって与えられるリフレクションＡ
ＰＩに基づく。

【０１１９】前述のように、少なくとも１つの被管理オ
ブジェクト・アダプタ・サービスが、ネットワーク管理
システム・エージェントとして、サーバの仮想マシンに
おいて実行していなければならない。ネットワーク管理
システムは、特定のインターフェース定義またはインプ
リメンテーションに従うために、被管理オブジェクト・
アダプタ・サーバを必要としない。被管理オブジェクト
・アダプタ・サーバは、フレームワーク２４にアクセス
して、エージェント内に含まれる情報を検索し変更する
ように構成されている。与えられる被管理オブジェクト
・アダプタ・サーバは、ｍ−ビーンとして実装される。
被管理オブジェクト・アダプタ・サーバの例について
は、先に述べた。本発明のこの好適実施例では、被管理
オブジェクト・アダプタ・サーバは、適切なＪａｖａク
ラスとして実装される。

【０１２０】例えば、ＲＭＩ被管理オブジェクト・アダ
プタ・サーバは、Ｊａｖａクラスsunw.jaw.agent.adapt
or.rmi.AdaptorServerImplとして実装することができ
る。これは、Ｊａｖａ管理アプリケーションが、Ｊａｖ
ａリモート・メソッド呼び出し（ＲＭＩ：remote metho
d invocation）システムを用いてエージェントにアクセ
スすることを可能にする。上述のように、Ｊａｖａ管理
アプリケーションは、Ｊａｖａクラスsunw.jaw.agent.a
daptor.rmi.AdaptorClientとして実装された被管理オブ
ジェクト・アダプタ・クライアントを通じて、このサー
バにアクセスする。

【０１２１】前述のようにエージェントがいったん初期
化されると、そのエージェントの実行中に、エージェン
トにコア管理サーバを追加することができる。次の方法
のいずれかで、コア・サービスをエージェントに追加す
ることができる。

【０１２２】− フレームワーク・クラス内のサービス
に対して直接setメソッドをコールする。

【０１２３】− ｍ−ビーンに対する方法と同じ方法
で、ｍ−ビーン・レポジトリにサービスを追加する。

【０１２４】コア管理サービスを直接追加すると、コア
管理サービスをｍ−ビーン・レポジトリに追加する場合
よりも、動作(performance)の高速化が図れる。その理
由は、フレームワークが、サービスを得るためにｍ−ビ
ーン・レポジトリに問い合わせする必要がないからであ
る。しかし、直接追加されたコア管理サービスには、次
のようないくつかの制約が適用される場合がある。

【０１２５】− サービスは、リモート・アプリケーシ
ョンには可視的でない。

【０１２６】− サービスに関する情報を、永続的記憶
装置に格納することは不可能である。

【０１２７】したがって、コア管理サービスがリモート
・アプリケーションから可視的であるのが望ましい場合
には、サービスをｍ−ビーン・レポジトリに追加する必
要がある。コア管理サービスに関する情報を永続的記憶
装置に格納することが望まれる場合も、サービスをｍ−
ビーン・レポジトリに追加する必要がある。サービスが
追加されるｍ−ビーン・レポジトリは、永続的格納をサ
ポートしていなければならない。

【０１２８】クラス・サービス名は、エージェントのた
めに実装されているサービスをフレームワーク２４が識
別する名称を含む。フレームワーク２４は、以下のよう
にして、必要なサービスを検索する。

【０１２９】１．フレームワーク２４は、サービスが直
接setメソッドを用いて定義されたのか否かについてチ
ェックを行なう。サービスがこのように定義された場
合、フレームワーク２４はこのサービスを用いる。

【０１３０】２．サービスが、直接setメソッドを用い
て定義されたのではない場合、フレームワークは、ｍ−
ビーン・レポジトリに問い合わせを行い、当該サービス
を実装するクラスのインスタンスである全てのｍ−ビー
ンを得る。例えば、メタデータ・サービスでは、フレー
ムワーク２４は、ｍ−ビーン・レポジトリに問い合わせ
を行い、ServiceName.METAと称するクラスのインスタン
ス全てを得る。

【０１３１】− レポジトリが、そのクラスのインスタ
ンスをいくつか含む場合、フレームワーク２４は、ｍ−
ビーン・レポジトリによって返された最初のインスタン
スを用いる。

【０１３２】− ｍ−ビーン・レポジトリがそのクラス
のインスタンスを全く含まない場合、フレームワーク
は、ServiceNotFound例外（Exception）を投げる。

【０１３３】ネットワーク管理サービス・エージェント
内では、種々の処理を行なうことができる。例えば、あ
るエージェント内のオブジェクトは、コア管理サービス
を用いて、 − ｍ−ビーンをインスタンス化する、 − ｍ−ビーンをｍ−ビーンに登録する、 − ｍ−ビーン・レポジトリからｍ−ビーンを検索す
る、 − ｍ−ビーン内のプロパティの値を獲得し、セットす
る、そして、 − ｍ−ビーン間の関係を定義する。

【０１３４】オブジェクト名は、ｍ−ビーンを一意的に
識別する。管理アプリケーションは、オブジェクト名を
用いて、管理処理を実行するｍ−ビーンを識別する。い
ずれの命名方式を使用することも可能である。例えば、
本発明の好適実施例では、Microsoft Corporation（マ
イクロソフト社）がハイパー・メディア管理方式（ＨＭ
ＭＳ：Hyper Media Management Scheme)のために定義し
た命名方式を用いることができる。

【０１３５】ｍ−ビーンをインスタンス化するために、
フレームワーク・クラスの以下のメソッドの１つをコー
ルすることができる。

【０１３６】ｍ−ビーンを格納するためのユーザのデフ
ォルト格納機構に対するnewObject、ｍ−ビーンが永続
的であることを指定するnewDBObject。

【０１３７】これらのメソッドのいずれかを用いる場合
には、次のものを提供することが必要である。

【０１３８】− インスタンス化するｍ−ビーンのＪａ
ｖａクラス、および − ｍ−ビーンを登録するために用いられるオブジェク
ト名。

【０１３９】デフォルトでは、フレームワーク２４は、
デフォルト・クラス・ローダを用いて、作成すべきｍ−
ビーンのＪａｖａクラスを配置する。次に、そのクラス
のインスタンスを作成する。いったんｍ−ビーンをイン
スタンス化すれば、それを初期化し、登録して、フレー
ムワーク２４にアクセス可能となるようにする。

【０１４０】− ｍ−ビーン自体に定義されているメソ
ッド、または − フレームワーク２４、を用いることによって、ｍ−
ビーンの初期化および登録を行なうことができる。

【０１４１】ｍ−ビーン自体に定義されているメソッド
を用いてｍ−ビーンのレジスタを初期化するためには、
当該ｍ−ビーンのＪａｖａクラス定義は、以下のものを
含まなければならない。

【０１４２】− 初期化メソッド、 − ｍ−ビーン自体をｍ−ビーン・レポジトリに登録す
るために必要なコード。

【０１４３】いったんｍ−ビーンがインスタンス化され
たならば、フレームワーク２４はメタデータ・サービス
２７を用いて、新たに作成されたｍ−ビーン内において
初期化メソッドを見つけ出す。かかるメソッドがｍ−ビ
ーン内に存在する場合、フレームワーク２４は、 − 第１のパラメータとして、それ自体に対する参照、 − 第２のパラメータとして、ｍ−ビーンの登録に用い
るためのオブジェクト名、を与えて、メソッドをコール
する。

【０１４４】したがって、ｍ−ビーンは、与えられたコ
ードを用いて、それ自体をｍ−ビーン・レポジトリに登
録することができる。

【０１４５】ｍ−ビーンに初期化メソッドが与えられて
いない場合、フレームワークは、この目的のために与え
られた機能を用いて、そのｍ−ビーンを初期化し、登録
する。

【０１４６】ＪａｖａＢｅａｎｓコンポーネントをｍ−
ビーン・レポジトリ２５に登録することによって、その
コンポーネントをエージェント２０によって管理するこ
とが可能となる。ＪａｖａＢｅａｎｓコンポーネントを
登録する際、当該ＪａｖａＢｅａｎｓコンポーネント自
体におけるコードの変更を必要としない。代わりに、必
要なのは、ｍ−ビーン・レポジトリ内にそれを登録する
ためのコードの追加だけである。したがって、あらゆる
既存のＪａｖａＢｅａｎｓコンポーネントを、ｍ−ビー
ン・レポジトリ内に登録することができる。いったん登
録されたならば、エージェント２０は、あらゆるｍ−ビ
ーンと同様に、ＪａｖａＢｅａｎｓコンポーネントを管
理する。ｍ−ビーンを登録する際、これにはオブジェク
ト名が割り当てられる。オブジェクト名は、明示的に特
定することができる。オブジェクト名が明示的に特定さ
れていない場合には、フレームワーク２４は、デフォル
トの名称を当該ｍ−ビーンに割り当てる。

【０１４７】ネットワーク管理システムは、ｍ−ビーン
・レポジトリからｍ−ビーンを検索するためのサービス
を与える。これらのサービスは、 − オブジェクト名に対するパターン照合（matchin
g）、または − それらが含むＪａｖａプロパティに関するクエリ
（フィルタ）を用いて、ｍ−ビーンの検索を可能とす
る。

【０１４８】ｍ−ビーンのオブジェクト名のパターン照
合を用いることによって、 − そのオブジェクト名全体を用いる特定のｍ−ビー
ン、 − 当該オブジェクト名で表されるのと同じ論理クラス
を共有する１組のｍ−ビーン、 − 同じドメイン名を共有する１組のｍ−ビーン、また
は − エージェントに含まれる全てのｍ−ビーン、を検索
することができる。

【０１４９】クエリ（queries）を用いると、Ｊａｖａ
プロパティおよびｍ−ビーン内におけるそれらの値にし
たがって、ｍ−ビーンの検索が可能となる。ｍ−ビーン
・レポジトリは、プロパティを評価することが可能な場
合、それを行なう。さもなければ、フレームワーク自体
がクエリを評価する。レポジトリがクエリにアクセス可
能か否かについて判定を行なうために、フレームワーク
は、この目的のために、クエリ・メソッドを生成する。

【０１５０】ネットワーク管理システムは、ｍ−ビーン
のプロパティを得るためおよびセットするためにサービ
スを与える。エージェントがメタデータ・サービスを与
える場合、ｍ−ビーンのgetメソッドまたはsetメソッド
に対するコールにおいて供給する必要があるのは、以下
のもので全てである。

【０１５１】− 検索するまたはセットすべきプロパテ
ィの名称、 − 当該プロパティを含むｍ−ビーンのオブジェクト
名。

【０１５２】エージェントがメタデータ・サービスを与
えない場合、ｍ−ビーンのgetメソッドまたはsetメソッ
ドの直接コールすることが依然として可能である。この
場合も、コールするメソッドの名称および署名(signatu
re)を、コール元に供給する必要がある。

【０１５３】関係サービスは、ｍ−ビーンが要求された
ときに、それらの間の関係を定義することを可能にす
る。関係は、前もって定義しておく必要はない。ｍ−ビ
ーン間の関係に関する情報は、ｍ−ビーン自体に格納す
るのではなく、関係に格納する。関係は、ｍ−ビーン・
レポジトリに格納する必要がある。関係は、 − １組の役割(role)、（例えば、所有関係では、人が
本を所有し、本は人に所有される） − 関係において、要求された役割の数に対応する度合
い（degree）、によって定義される。

【０１５４】ある関係に関与するｍ−ビーンは、それら
のオブジェクト名によって、関係内において参照され
る。起動時、またはエージェントの実行中に、特定のク
ラス・ローダをエージェントに追加することができる。
ｍ−ビーン・レポジトリに登録されているのであれば、
同一エージェント内にいくつかのクラス・ローダを有す
ることが可能である。新たなオブジェクトの作成が要求
された場合、オブジェクトをロードするために用いられ
るクラス・ローダを指定することができる。この場合、
クラス・ローダは、そのオブジェクト名によって識別さ
れる。システムは、ネットワーク・クラス・ローダのい
くつかのインプリメンテーションを与え、各インプリメ
ンテーションは、異なるプロトコルを用い、異なるクラ
ス・サーバを必要とする。

【０１５５】このシステムは、異なる通信プロトコルを
通じてイベントのフィルタリング、ロギング(loggin
g)、および送出(forwarding)を行なうために、イベント
・ハンドリング・サービスを与える。イベントを放出す
るために、センド・イベント・メソッド(send event me
thod)をコールする。このメソッドがコールされると、
フレームワーク２４は、イベント・ハンドリング・サー
ビスに対応する全てのｍ−ビーンを検索し、検索された
各イベント・ハンドラのイベント・ハンドリング・メソ
ッドをコールする。このメソッドは、イベントを扱う役
割を担う。

【０１５６】図９は、ｍ−ビーン２８からのｃ−ビーン
５４のコンパイルを表す概略図である。コンパイラ６０
は、ｃ−ビーンを生成するための１つの変換方式を実装
する。しかしながら、要件に応じて、異なる変換方式を
実装することも可能である。

【０１５７】図１３は、Ａと称する単一のｍ−ビーンを
コンパイルするコンパイラ６０の出力の一例を示す。図
１４は、コンパイルされたｍ−ビーンが、特定のイベン
トAnEventに対するaListenerを含む場合の、コンパイラ
６０の出力を示す。

【０１５８】したがって、ｍ−ビーンがリスナ(listene
r)を含む場合、コンパイラ６０は、 − ＭＯインターフェース内に含まれるリスナに対する
Ｊａｖａインターフェース、 − ｍ−ビーン・イベントを捕獲し、それらをフレーム
ワーク２４に送出するためのｍ−ビーン・リスナのイン
プリメンテーションであるリスナ・スタブ、および − EventMOと呼ばれる、リスナに関連するイベントの
Ｊａｖａ管理アプリケーションのビュー(view)、を生成
する。

【０１５９】コンパイラ６０は、適用可能な設計パラメ
ータを用いて、ｍ−ビーンを解析（パーシング）する。
パーシングの後、コンパイラ６０は、多数の規則を用い
てｃ−ビーンを生成する。

【０１６０】ｍ−ビーンの各プロパティは、同じアクセ
サ・メソッドを有するｃ−ビーン内に存在する。したが
って、あるプロパティがｍ−ビーンにおいてリード・オ
ンリである場合、そのプロパティはｃ−ビーンにおいて
もリード・オンリである。

【０１６１】図１５のＡは、図１５のＢに示すコード例
によって定義されたｍ−ビーンをコンパイルした場合に
生成される単純なｃ−ビーンの図である。加えて、コン
パイラ６０は、単純なＭＯインターフェースのインプリ
メンテーションを含むファイルを生成する。

【０１６２】プロパティ・アクセサに加えて、コンパイ
ラ６０は、リモート・アクセスを与えることが意味のあ
るパブリック・メソッドに対してのみ、コードを生成す
る。他のパブリック・メソッドは、コンパイラ６０によ
って生成されるｃ−ビーンには現れない。

【０１６３】図１６のＡは、図１６のＢにおけるように
定義されたｍ−ビーンにおいてアクション・メソッドを
コンパイルした場合にコンパイラ６０が生成する、ＭＯ
インターフェースのｃ−ビーンにおけるアクション・メ
ソッドのサブセットを示す。

【０１６４】ｍ−ビーンが、Ａと称するリスナを含む場
合、コンパイラ６０は、ｃ−ビーン内にAIfMOと称する
リスナを含む。

【０１６５】ｃ−ビーンを用いる場合、アプリケーショ
ンは、Aifmoインターフェースを実装し、ｃ−ビーン内
のリスナを追加または除去しなければならない。通常、
リスナは、所定数のメソッドを含むインターフェースで
ある。各メソッドは、１つの入力パラメータを有する。
入力パラメータは、関係するイベント・オブジェクトに
継承する。

【０１６６】一例では、リスナＡ内に定義された各メソ
ッドは、この例の目的のために、AnEventと呼ばれるイ
ベント・オブジェクトを参照する。したがって、Aifmo
インターフェースにおいては、このイベント・オブジェ
クトはAnEventMOと呼ばれる。このように、リスナＡに
対して、コンパイラ６０は、 − Aifmo.java、 − AneventMO.java、というファイルを生成する。

【０１６７】加えて、コンパイラ６０は、Astub.javaと
称するリスナＡのインプリメンテーションを生成する。

【０１６８】コンパイラ６０によって生成されたコード
は、ＪａｖａＢｅａｎｓコンポーネント・モデルによっ
て設計された設計パラメータを用いてコンパイルする。
このため、コンパイラ６０によって生成されたオブジェ
クトはこのモデルに従う開発環境に統合することができ
る。加えて、コンパイラ６０は、ＪａｖａＢｅａｎｓコ
ンポーネント・モデルによって定義された設計パターン
に従わない、いくつかのパブリック・メソッドを追加す
る。追加されたメソッドは、ｍ−ビーンとｃ−ビーンと
の間のネットワーク・トラフィックを制限するように設
計される。例えば、ｃ−ビーン上である関数をコールす
ることにより、対応するｍ−ビーンの全てのプロパティ
を読み出すことができる。

【０１６９】コンパイラ６０は、Ｊａｖａソース・コー
ドを生成する。生成したコードを編集し、それを修正し
て、ｍ−ビーンの特定のビューを定義することができ
る。インターフェースおよびスタブの双方を修正する代
わりに、インターフェースを保持し、スタブのみを修正
する方がよい。コンパイラ６０によって生成されたコー
ドは、インターフェースを用いてアプリケーションを構
築することを可能にする。一度に、adaptorMOによって
どのスタブがロードされたかに応じて、ビヘービャは変
化する。例えば、コンパイラは、同じインターフェース
に、リード・オンリ・スタブまたはリード−ライト・ス
タブを生成することができる。したがって、ｍ−ビーン
・ブラウザは、インターフェースに基づいて開発するこ
とができる。前述のように、ブラウザは、これによっ
て、リード・オンリ・スタブまたはリード−ライト・ス
タブのどちらがロードされたかに応じて、異なるビヘー
ビャを有することになる。

【０１７０】adaptorMOインターフェースは、エージェ
ント２０を管理するために定義されたＪａｖａインター
フェースである。ネットワーク管理システムは、前述の
ように、異なる通信プロトコルに基づいて、adaptorMO
インターフェースのいくつかのインプリメンテーション
を与える。しかしながら、adaptorMOインターフェース
は、プロトコルには独立している。したがって、インタ
ーフェースを用いて書かれたコードのいずれの部分で
も、ネットワーク管理システムによって与えられたイン
プリメンテーションのいずれにおいても実行することが
できる。

【０１７１】adaptorMOインターフェース内には、２つ
の異なるレベルがある。リモート・オブジェクト（ｍ−
ビーン）をそれらの名称を用いて操作する低レベル、お
よびリモート・オブジェクト（ｍ−ビーン）を当該リモ
ート・オブジェクトのローカル・ビュー（ｃ−ビーン）
を用いて操作する高レベルである。高レベルは、低レベ
ル・インターフェースの上に構築する。

【０１７２】低レベル・インターフェースを用いること
は、汎用的なアプリケーション（ＨＴＭＬオブジェクト
・ビューアまたはＭＩＢブラウザのような）を構築する
ためには実用的である。高レベルのインターフェースを
用いることは、それより低いレベルのインターフェース
を用いるよりも、かなり容易である。しかしながら、ア
プリケーションが操作するｃ−ビーンのセマンティック
(semantic)を、当該アプリケーションが知っていること
を前提とする。加えて、アプリケーション（またはadap
torMOインターフェース）が、ＭＯおよびＭＯスタブに
対するアクセスを有することを要求する。アダプタを初
期化する第１ステップは、adaptorMOインターフェース
のインプリメンテーションを初期化することから成る。

【０１７３】アダプタを初期化するために、クライアン
ト・アプリケーションは、adaptorMOインターフェース
内に定義されている、"connect"メソッドを呼び出す。
エージェントのホスト名、使用するポート番号、および
通常基本的な通信機構に依存する論理名に関連するパラ
メータを与える。使用するアダプタのインプリメンテー
ション名を与えるのと同時に、名称サーバまたはディレ
クトリ・サービスから、情報の異なる部分を得ることが
できる。adaptorMOインターフェースが用いる、基本的
な通信機構に応じて、"connect"へのコールは、クライ
アントとエージェントとの間でメッセージ交換を全く伴
わない場合もある。

【０１７４】アダプタは、 − 特定のｍ−ビーン（そのオブジェクト名によって判
明する）を表すために用いる、Ｊａｖａクラス名を得る
ための名称サーバ、 − ｃ−ビーンをロードするためのクラス・ローダ、を
利用する。

【０１７５】クライアント・アプリケーションが実行中
のマシン上に存在する場合、ｃ−ビーンに対するＪａｖ
ａクラス全てが特定のクラス・ローダを使用する必要は
ない。代わりに、ネットワークを通じてクラスを得るた
めのネットワーク・クラス・ローダを用いることができ
る。

【０１７６】ネットワーク・クラス・ローダを用いるた
めに、クライアント・アプリケーションは、ネットワー
ク・クラス・ローダをインスタンス化する必要がある。
オブジェクトをインスタンス化する場合、アプリケーシ
ョンはオブジェクト名を与える。オブジェクト名は、い
ずれかのドメインおよびいずれかのクラス名を含むこと
ができる。

【０１７７】しかしながら、オブジェクト名は、以下の
キー・プロパティを含まなければならない。

【０１７８】− ホスト（クラス・サーバが実行中のホ
ストの名称）、 − ポート（使用するポート番号）、 − サービス（呼び出すべきＲＭＩサービスの名称）。

【０１７９】アダプタがいったん初期化されると、アプ
リケーションは、リモート・エージェント上で管理処理
を実行する準備ができたことになる。アプリケーション
は、エージェントによって管理されているｍ−ビーンの
サブセットまたは全てを検索することができる。オブジ
ェクトを検索する場合、アプリケーションはクエリを指
定することができる。検索の結果は、次の２つの異なる
方式で得ることができる。

【０１８０】− オブジェクト名（ベクトルによって表
される）のリスト、 − ｃ−ビーン（検索された各オブジェクト名毎に、ア
ダプタはｃ−ビーンをインスタンス化する）のリスト。

【０１８１】リモートｍ−ビーンのプロパティを読み取
るために、低レベルadaptorMOインターフェース・レベ
ルを用いる場合、プロパティ名が必要となる。高レベル
・インターフェースを用いる場合、ｃ−ビーンを検索
し、次いでプロパティに関連するゲッタを呼び出す。

【０１８２】リモートｍ−ビーンのプロパティ、プロパ
ティ名、およびプロパティ・オブジェクト型をセットす
ることは、低レベルadaptorMOインターフェース・レベ
ルを用いる場合に必要とされる。ある値をセットする場
合、オペレータ・クラスの名称を指定することができ
る。エージェント側では、指定されたオペレータがイン
スタンス化され、プロパティ値をセットするために呼び
出される。低レベルadaptorMOインターフェース・レベ
ルを用いる場合、変更のリストを用い、１つのメソッド
・コールによって、いくつかのプロパティをセットする
ことができる。

【０１８３】高レベルadaptorMOインターフェース・レ
ベルを用いる場合、ｃ−ビーンが得られ、次いでデベロ
ッパは、プロパティに関連する前述の１組を呼び出す。

【０１８４】adaptorMOインターフェースによって、リ
モート・エージェント内においてｍ−ビーンのインスタ
ンス化を要求することが可能となる。インスタンス化を
要求する場合、新しいクラス・ローダを指定することが
でき、これを通じて、エージェントはインスタンス化す
る新しいクラスをロードすることになる。クラス・ロー
ダは、そのオブジェクト名を用いて指定することができ
る。クラス・ローダを指定しない場合、エージェントは
デフォルトのクラス・ローダを用いる。ローカルｍ−ビ
ーンをインスタンス化する場合、新しく作成したｍ−ビ
ーンを表すために、ｃ−ビーンを直接得ることができ
る。名称が与えられず、名称サーバが指定された場合、
アダプタは、エージェント側でインスタンス化するＪａ
ｖａクラスの名称を得るために、名称サーバに問い合わ
せを行なう。その他の場合、インスタンス化するクラス
のクラス名を判定するのは、エージェントの役割であ
る。エージェントにおいてｍ−ビーンをインスタンス化
する場合、オブジェクトが永続的であることを明示的に
要求することができる。

【０１８５】adaptorMOインターフェースによって、Ｊ
ａｖａオブジェクトをクライアントからエージェントに
転送することが可能となる。これを行なうために、adap
torMOインターフェースは、オブジェクトをシリアル化
し、当該オブジェクトを送り、エージェントにおいてこ
のオブジェクトをデシリアル化(deserialise)する。

【０１８６】更に、adaptorMOインターフェースによっ
て、リモート・エージェントからｍ−オブジェクトを除
去することも可能となる。ｍ−ビーンは仮想マシンから
除去されるのではなく、エージェントのオブジェクト・
レポジトリからだけ除去される。

【０１８７】図１７は、上述の管理システムを作成し動
作させるステップの概要を示すフロー・チャートであ
り、ビーンに基づく環境を用いて少なくとも１つの管理
ビーンを含むネットワーク管理モデルを定義するステッ
プと、前記モデルをコンパイルして前記コンピュータ・
ネットワーク管理システムを前記ビーンに基づく環境に
おいて実装するステップとを含む。

【０１８８】ステップ１１０において、ビーンに基づく
環境を用いてモデルを作成する。好適なビーンに基づく
環境は、ビーンをＪａｖａＢｅａｎｓとしたＪａｖａ環
境である。

【０１８９】前述のように、ビーンは、１組のプロパテ
ィ、アクションを実行する１組のメソッド、ならびにイ
ベントおよびイントロスペクションに対するサポートを
与える。従来より、プロパティは、ビーンをプログラム
的に操作すること、およびビーンのカスタム化に対応す
ることを可能にし、メソッドはプロパティを実装し、イ
ベントに対するサポートは、ビーンがイベントを発火さ
せ、発火させることができるイベントを定義することを
可能にする。イントロスペクションに対するサポート
は、ビーンのプロパティ、イベント、およびメソッド
を、外部から検査することを可能にする。

【０１９０】したがって、ステップ１１０は、被管理リ
ソースのプロパティをモデル化するための少なくとも１
つのプロパティ、および／または前記被管理リソースの
ためのアクションをモデル化するためのメソッドおよび
／または前記リソースのイベントをモデル化するための
少なくとも１つのイベントに対するサポート、および／
または前記ビーンの組成の外部分析を可能にするイント
ロスペクションに対するサポートをを与える、少なくと
も１つの前記管理ビーンを生成することを含む。また、
このステップは、被管理リソース間の関係および相互作
用を表すものとして、管理ビーン間の関係および相互作
用を定義することも含む。更に、このステップは、少な
くとも１つの管理ビーンに関して、少なくとも１つのリ
スナ・イベントを定義することを含む。

【０１９１】このネットワーク管理システムに関して、
ビーンは従来の役割を超えて使用し、管理すべきリソー
スを直接モデル化するための管理ビヒクル（管理ビー
ン）を与えることができることが、初めて認識された。
例えば、被管理リソースのプロパティ（例えば、メモリ
のサイズ、バッファに受信されているメッセージの数等
のリソースの属性）をモデル化するために、管理ビーン
内のあるプロパティを用いることができる。被管理リソ
ースのアクション（例えば、システム休止）をモデル化
するために、管理ビーンのメソッドを用いることができ
る。また、ビーンは、被管理リソースのためのイベント
（例えば、ディスク・フル・イベント）に対するサポー
トを与えるために用いることも可能である。例えば、管
理ビーンがリスナ・イベントに対するサポートを与える
ことができ、これによって、１つの管理ビーンが別の管
理ビーン上のイベントに応答することが可能となる。イ
ントロスペクションに対するサポートによって、管理ビ
ーンは、ビーンの組成の外部的な分析、およびビーン間
の情報の交換が可能となる。管理ビーンは、被管理リソ
ース間の関係および相互作用を表すものとして、管理ビ
ーン間の関係および相互作用の定義を含むことができ
る。

【０１９２】ビーンは再利用可能なソフトウエア・コン
ポーネントであり、ビルダ・ツール（例えば、エディタ
またはグラフィカル・ユーザ・インターフェース・ビル
ダ（ＧＵＩビルダ））において視覚的に操作することが
できるので、ステップ１１０において、ユーザは、Ｊａ
ｖａＢｅａｎｓ開発キットのような従来のビルダ・ツー
ルを用いて、システム・リソース、それらの関数および
システム・リソース間の関係および相互作用を定義する
ビーンを含む、管理システム・モデルを生成することが
できる。ビーン・モデルは、例えば、Ｊａｖａ仮想マシ
ン内においてＪａｖａＢｅａｎｓを用いて、ビーンに基
づく環境を形成する仮想マシン内で定義される。これに
よって、管理システム・モデルの生成が格段に容易に行
なえるようになる。モデルの確認およびデバッギング
は、イントロスペクションおよびその他の技法を用い
て、容易に行なうことができる。

【０１９３】ステップ１１２において、一旦モデルが生
成されたなら、例えば、図９に示したコンパイラ６０の
ような、ビーンに基づく環境のための従来のコンパイラ
を用いて、モデルを直接コンパイルすることができる。
ビーンに基づく環境においてモデルを定義することによ
り、ビーンに基づくモデルを直接コンパイルし、例え
ば、Ｊａｖａコンパイラを用いてＪａｖａＢｅａｎｓを
コンパイルすることによって、ビーンに基づく環境のた
めの標準的なコンパイラを用いて、ビーンに基づくイン
プリメンテーションを形成することが可能となる。した
がって、結果的に得られるビーン管理システムも、同じ
Ｊａｖａ環境内において定義される。これによって、コ
ンパイラが、モデルの信頼性高く類似したインプリメン
テーションを強制するので、この管理システムの生成段
階が大幅に簡略化される。

【０１９４】したがって、実行時において、ステップ１
１４では、本明細書の冒頭に記載した管理システムは、
従来のネットワーク管理システムの難問や欠点がなく、
ロバスト性が高く容易に修正可能な構造を与える。

【０１９５】ステップ１１４は、１つ以上の管理ビーン
を、拡張可能なエージェント・フレームワークに登録
し、ネットワーク通信プロトコルのための１つ以上のネ
ットワーク・アダプタ（例えば、ネットワーク・アダプ
タ・ビーン（複数のビーン））を拡張可能なエージェン
ト・フレームワークに登録し、ネットワーク・アダプタ
（複数のアダプタ）を通じた管理ビーン（複数のビー
ン）に対する、ネットワークを通じた外部アクセスを可
能にする、図１２に関連して説明したステップを含む。

【０１９６】図１２に関して説明したように、拡張可能
なエージェント・フレームワークは、関連するレポジト
リ・ビーンを含み、１つ以上の管理ビーンおよび／また
はネットワーク・アダプタを登録するステップは、１つ
以上の管理ビーンおよび／またはネットワーク・アダプ
タをレポジトリ・ビーンに登録するステップから成るも
のとすることができる。

【０１９７】以上のように、通信ネットワークのための
ネットワーク・エージェントについて説明した。このネ
ットワーク・エージェントは、拡張可能なフレームワー
クと、フレームワークに登録可能な１つ以上の被管理オ
ブジェクトと、フレームワークに登録可能であり、ネッ
トワーク通信プロトコルが被管理オブジェクトにアクセ
スすることを可能とするための１つ以上のネットワーク
・アダプタとから成る。ネットワーク・エージェント
は、動的なネットワーク管理環境のための柔軟性のある
機構を与える。フレームワークへの登録は、レポジトリ
・サービス・オブジェクトによって行うことができる。
被管理オブジェクトは、１組のプロパティ、１組のメソ
ッド、ならびにイベントおよびイントロスペクションに
対するサポートから成るビーンであることが好ましい。
また、サービス・エージェントを与える方法およびかか
るエージェントを用いたネットワーク管理システムにつ
いても記載した。

【０１９８】ネットワーク・エージェントは、少なくと
も１つの記憶媒体上においてソフトウエアの形態で実装
することができる。記憶媒体は、磁気ディスク、光磁気
ディスク、または光ディスクのような携帯可能な記憶媒
体、および／または固体メモリおよび／またはサーバ・
コンピュータのメモリとすることができる。ネットワー
ク・エージェントは、携帯可能な記憶媒体を接続するこ
とによって、またはサーバからダウンロードし被管理シ
ステムにおけるプロセッサによって実行することによっ
て、被管理システムのメモリにロードすることができ
る。あるいは、ネットワーク・エージェントは、少なく
とも部分的に、特殊目的のファームウエアまたはハード
ウエアによって実装することも可能である。

【０１９９】以上、本発明の特定実施形態について説明
したが、特許請求の範囲に定義される本発明の精神およ
び範囲内において、多くの変更／追加および／または交
換も可能であることは認められよう。特許請求の範囲を
参照することにより、本発明の精神および範囲内におい
て、請求項に明示的に列挙されているもの以外の従属項
の特徴を他の従属項および／または独立項の特徴と適宜
組み合わせることも可能であることを注記すべきであろ
う。

【図面の簡単な説明】

【図１】通信ネットワークを通じて接続された３箇所の
ステーションを表す図である。

【図２】図２と図２のＡとから構成される。図１のステ
ーションに対するコンピュータ・サーバの概略図を形成
する図である。

【図３】管理対象ステーションに対するエージェントの
概略図である。

【図４】図３のエージェントを示す別の図である。

【図５】エージェントのコンフィギュレーションの一例
を示す図である。

【図６】図５に示すエージェントを用いる動作を示すフ
ロー・チャートである。

【図７】管理システムのコンフィギュレーションの一例
を示す図である。

【図８】管理システムのコンフィギュレーションの別の
例を示す図である。

【図９】図８のコンフィギュレーションの作成の一態様
を示す図である。

【図１０】図８のシステムの動作を示すフロー・チャー
トである。

【図１１】命名サービスの動作を示すフロー・チャート
である。

【図１２】汎用エージェントの作成の処理を示すフロー
・チャートである。

【図１３】コンパイラの別の処理を示す図である。

【図１４】コンパイラの別の処理を示す図である。

【図１５】Ａ及びＢから構成される。管理ビーンをコン
パイルする効果を示すために用いる図である。

【図１６】Ａ及びＢから構成される。同様に管理ビーン
をコンパイルする効果を示すために用いる図である。

【図１７】管理システムを生成するステップを示すフロ
ー・チャートである。

フロントページの続き (71)出願人 597004720 2550 Ｇａｒｃｉａ Ａｖｅｎｕｅ，ＭＳ ＰＡＬ１−521，Ｍｏｕｎｔａｉｎ Ｖ ｉｅｗ，Ｃａｌｉｆｏｒｎｉａ 94043− 1100，Ｕｎｉｔｅｄ Ｓｔａｔｅｓ ｏｆ Ａｍｅｒｉｃａ (72)発明者 セルジュ・アンドレ・リゴリ フランス共和国 38120 プロヴィズオー, プランファイ

Claims (18)

【特許請求の範囲】
1. 【請求項１】 通信ネットワークのためのネットワーク
   ・エージェントであって、 拡張可能なフレームワークと、 前記フレームワークに登録可能な１又は複数の被管理オ
   ブジェクトと、 前記フレームワークに登録可能であり、ネットワーク通
   信プロトコルが前記被管理オブジェクトにアクセスする
   ことを可能とする１又は複数のネットワーク・アダプタ
   と、 を備えていることを特徴とするネットワーク・エージェ
   ント。
2. 【請求項２】 請求項１記載のネットワーク・エージェ
   ントであって、前記フレームワークに登録可能なレポジ
   トリ・サービス・オブジェクトを備え、前記被管理オブ
   ジェクトおよび／または前記ネットワーク・アダプタお
   よび／または１又は複数の更に別のサービス・オブジェ
   クトは、前記レポジトリ・サービス・オブジェクトに登
   録可能であり、これによって、前記被管理オブジェクト
   および前記ネットワーク・アダプタは、前記レポジトリ
   ・サービス・オブジェクトを通じて、前記フレームワー
   クに間接的に登録可能である特徴とするネットワーク・
   エージェント。
3. 【請求項３】 請求項２記載のネットワーク・エージェ
   ントにおいて、前記ネットワーク・アダプタは、ネット
   ワーク・アダプタ・オブジェクトを備えていることを特
   徴とするネットワーク・エージェント。
4. 【請求項４】 請求項３記載のネットワーク・エージェ
   ントにおいて、前記被管理オブジェクトは、１組のプロ
   パティ、アクションを実行する１組のメソッド、ならび
   にイベントおよびイントロスペクションに対するサポー
   トを有するビーンであることを特徴とするネットワーク
   ・エージェント。
5. 【請求項５】 請求項１記載のネットワーク・エージェ
   ントにおいて、前記フレームワークは、ゲッタ・プロパ
   ティおよびセッタ・プロパティを備えており、オブジェ
   クトおよび／またはオブジェクト・メソッドの獲得およ
   び／またはセットを行うために、ゲッタ・メソッドおよ
   びセッタ・メソッドを実装することを特徴とするネット
   ワーク・エージェント。
6. 【請求項６】 請求項７記載のネットワーク・エージェ
   ントにおいて、前記ネットワーク・アダプタの１つは、
   受信した外部要求に応答し、前記フレームワークに、前
   記要求に対する被管理オブジェクト・メソッドを獲得さ
   せ、続いて応答を返送させることを特徴とするネットワ
   ーク・エージェント。
7. 【請求項７】 請求項６記載のネットワーク・エージェ
   ントであって、前記フレームワークに登録可能なレポジ
   トリ・サービス・オブジェクトを備え、前記被管理オブ
   ジェクトおよび／または前記ネットワーク・アダプタ
   は、前記レポジトリ・サービス・オブジェクトに登録可
   能であり、これによって、前記被管理オブジェクトおよ
   び前記ネットワーク・アダプタが、前記レポジトリ・サ
   ービス・オブジェクトを通じて、前記フレームワークに
   間接的に登録可能となり、前記フレームワークが、前記
   レポジトリ・サービスを参照して、前記被管理オブジェ
   クト・メソッドをコールすることを特徴とするネットワ
   ーク・エージェント。
8. 【請求項８】 請求項５記載のネットワーク・エージェ
   ントにおいて、前記フレームワークは、オブジェクト追
   加機能およびオブジェクト除去機能を実行するように構
   成されていることを特徴とするネットワーク・エージェ
   ント。
9. 【請求項９】 請求項１記載のネットワーク・エージェ
   ントにおいて、前記フレームワークは、１組のプロパテ
   ィ、アクションを実行する１組のメソッド、ならびにイ
   ベントおよびイントロスペクションに対するサポートを
   有するビーンであることを特徴とするネットワーク・エ
   ージェント。
10. 【請求項１０】 通信ネットワークに接続可能な計算シ
    ステムであって、該計算システムはネットワーク・エー
    ジェントを含み、該ネットワークエージェントは、 拡張可能なフレームワークと、 前記フレームワークに登録可能な１又は複数の被管理オ
    ブジェクトと、 前記フレームワークに登録可能であり、ネットワーク通
    信プロトコルが前記被管理オブジェクトにアクセスする
    ことを可能とする１又は複数のネットワーク・アダプタ
    と、 を備えていることを特徴とする計算システム。
11. 【請求項１１】 少なくとも１つの記憶媒体上にある、
    オブジェクト・ベースのネットワーク・エージェントで
    あって、 拡張可能なフレームワーク・サービス・オブジェクト
    と、 前記フレームワーク・サービスに登録可能な１又は複数
    の被管理オブジェクトと、 前記フレームワーク・サービスに登録可能であり、ネッ
    トワーク通信プロトコルが前記被管理オブジェクトにア
    クセスすることを可能とする１又は複数のネットワーク
    ・アダプタ・オブジェクトと、 を備えていることを特徴とするネットワーク・エージェ
    ント。
12. 【請求項１２】 被管理システムのためのネットワーク
    ・エージェントを備えたネットワーク管理システムであ
    って、 拡張可能なフレームワーク・サービス・オブジェクト
    と、 前記フレームワーク・サービスに登録可能な１又は複数
    の被管理オブジェクトと、 前記フレームワーク・サービスに登録可能であり、ネッ
    トワーク通信プロトコルが前記被管理オブジェクトにア
    クセスすることを可能とする１又は複数のネットワーク
    ・アダプタ・オブジェクトと、 を備えていることを特徴とするネットワーク・エージェ
    ント。
13. 【請求項１３】 通信ネットワークを通じて、エージェ
    ント・サービスを与える方法であって、 １又は複数の被管理オブジェクトを拡張可能なエージェ
    ント・フレームワークに動的に登録するステップと、 ネットワーク通信プロトコルのための１つ以上のネット
    ワーク・アダプタを前記フレームワークに登録するステ
    ップと、 前記ネットワーク・アダプタを通じて、前記被管理オブ
    ジェクトに対するアクセスを可能にするステップと、 を含むことを特徴とする方法。
14. 【請求項１４】 請求項１３記載の方法において、前記
    フレームワークは、関連するレポジトリ・オブジェクト
    を備え、前記登録するステップが、前記被管理オブジェ
    クトおよび／または前記ネットワーク・アダプタを前記
    レポジトリ・オブジェクトに登録するステップを含むこ
    とを特徴とする方法。
15. 【請求項１５】 請求項１４記載の方法において、前記
    ネットワーク・アダプタは、受信した外部要求に応答
    し、前記フレームワークに、前記要求に対する被管理オ
    ブジェクト・メソッドをコールさせ、続いて応答を返送
    させることを特徴とする方法。
16. 【請求項１６】 請求項１５記載の方法において、前記
    ネットワーク・アダプタが、ネットワーク・アダプタ・
    オブジェクトを備えることを特徴とする方法。
17. 【請求項１７】 請求項１３記載の方法において、前記
    オブジェクトの１つが、１組のプロパティ、アクション
    を実行するための１組のメソッド、ならびにイベントお
    よびイントロスぺクションに対するサポートを有してい
    ることを特徴とする方法。
18. 【請求項１８】 請求項１７記載の方法において、前記
    オブジェクトはビーンであることを特徴とする方法。