JPH11234276A - ビーンに基づく管理システム - Google Patents

Abstract

(57)【要約】 【課題】 ビーンに基づく環境を用いて、ネットワーク
管理モデルを構成し、次いでこのモデルをコンパイル
し、ビーンに基づく環境内にコンピュータ・ネットワー
ク管理システムを実装することにより、ネットワーク・
管理システムを生成する。 【解決手段】 ビーンが、１組のプロパティ、アクショ
ンを実行するための１組のメソッド、ならびにイベント
およびイントロスペクションに対するサポートを与え
る。ビーンは、モデル化対象システムのコンポーネント
の特徴を、直接モデル化することができる。また、ビー
ンを直接コンパイルし、モデルのインプリメンテーショ
ンを与えることも可能である。その結果、管理システム
を実装するために用いる環境とは別個の、当該管理シス
テムをモデル化する環境に対する必要性を回避すること
ができる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ネットワーク管理
システムに関し、特に、かかるシステムのためのネット
ワーク・モデルの生成に関するものである。

【０００２】

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

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

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

【０００５】既存のネットワーク管理システムに伴う難
問の１つに、ネットワーク・モデルの生成に関連するも
のがある。例えば、ＴＭＮ環境では、オブジェクトは、
被管理モデルの定義のための産業標準X722/ISO-10165-4
ガイドライン（ＧＤＭＯ：Guidelines for Definition
of Managed Objects）にしたがって定義される。ＧＤＭ
Ｏは、X208/ISO-8824抽象シンタクス・ノテーション１
（ＡＳＮ．１：Abstract Syntax Notation One)およ
び、データ・ノテーションのための抽象ノテーション１
に対する基本符号化規則（ＢＥＲ：Basic Encoding Rul
es)のX209/ISO-8825仕様にしたがって、データ、または
パラメータ、型（タイプ）を定義する。これら種々の産
業標準は、国際標準化機構（ＩＳＯ：International St
andards Organization）によって定義されている。

【０００６】

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

【０００７】ＣＭＩＳを呼び出すためには、アプリケー
ション・プログラミング・インターフェース（ＡＰＩ：
Application Programming Interface)というインプリメ
ンテーション（実装系）を生成する必要がある。典型的
に、ＡＰＩは、ＣまたはＣ＋＋のようなプログラミング
言語を用いて作成されてきた。種々の規格は存在する
が、この段階は、非常に費用がかかり、しかも潜在的に
危険である。プログラマの非常に重要な関与が、ＡＰＩ
の作成には必要である。費用は別として、結果的に作成
されたＡＰＩの信頼性および検証の問題もある。ＡＳ
Ｎ．１およびＧＤＭＯ規格に対するプログラム・ベース
のＡＰＩの混合の結果生ずる別の問題として、例えば、
オブジェクトの新しい型およびインスタンス（例えば、
ネットワーク・マネージャのための新しい型のワークス
テーション）を定義することによって、ネットワーク・
サービスを継承（extend）する必要がある場合に遭遇す
る困難がある。言い換えると、ＡＰＩを提供する従来の
手法は、動的なネットワーク管理環境においては、数多
くの問題を抱えている。

【０００８】本発明の全体としての目的は、より柔軟性
のあるネットワーク管理環境の開発に対して、改善され
たアプローチを提供することである。

【０００９】

【課題を解決するための手段】本発明の第１の態様によ
れば、コンピュータ・ネットワーク管理システムを生成
するコンピュータ実装（computer-implemented）方法が
提供され、この方法は、 ａ）少なくとも１つの管理ビーンを含むネットワーク管
理モデルを、ビーンに基づく環境を用いて定義するステ
ップと、 ｂ）モデルをコンパイルし、ビーンに基づく環境におい
てコンピュータ・ネットワーク管理システムを実装する
ステップと、から成る。

【００１０】ビーンに基づく環境においてモデルを定義
することにより、ビーンに基づくモデルを直接コンパイ
ルし、ビーンに基づく環境のための標準的なコンパイラ
を用いて、ビーンに基づくインプリメンテーションを形
成することが可能となる。

【００１１】本発明の好適な実施形態では、管理ビーン
は、ＪａｖａＢｅａｎｓコンポーネントである（Ｊａｖ
ａＢｅａｎｓは、サンマイクロシステムズ社(Sun Micro
systems, Inc.)の商標である）。ビーンは、再利用可能
なソフトウエア・コンポーネントであり、ビルダ・ツー
ル（例えば、エディタまたはグラフィカル・ユーザ・イ
ンターフェース・ビルダ（ＧＵＩビルダ））において視
覚的に操作することができる。ビルダ・ツールの一例
に、ＪａｖａＢｅａｎｓ開発キット(JavaBeansDevelopm
ent Kit)がある。ビーンに関する更なる詳細は、多くの
異なる書籍において見ることができ、例えば、Synbexに
よって発行されたLawrence Vanhelsuwe著のMastering J
avaBeans（ＪａｖａＢｅａｎｓの習得）と題する本(ISB
N-0-7821-2097-0)があげられる。これは、表題に「Ｊａ
ｖａＢｅａｎｓ」を有しＪａｖａＢｅａｎｓについて説
明する、広い意味で同等な市販の多くの本の一例に過ぎ
ない。Mastering JavaBeansを含むこれらの本の多く
は、上述のビーン開発キットに対応する(supply)もので
ある。ビーンはそのファンクショナリティ(functionali
ty)が様々に変化するが、典型的に、ある種の共通した
定義構造を共有しており、１組のプロパティ、アクショ
ンを実行する１組のメソッド、ならびにイベント、およ
びリフレクション(reflection)としても知られているイ
ントロスぺクション (introspection:内省) に対するサ
ポートを与える。プロパティは、ビーンのプログラム的
な操作を可能とし、ビーンのカスタム化(customizatio
n)をサポートする。メソッドはプロパティを実装する。
イベントに対するサポートは、ビーンズがイベントを発
火(fire)することを可能とし、発火することができるイ
ベントを定義する。イントロスぺクションに対するサポ
ートは、ビーンのプロパティ、イベントおよびメソッド
を、外部から検分することを可能にする。

【００１２】本発明は、ビーンが、管理すべきリソース
をモデル化するためのビヒクルを与えることができるこ
とを初めて認識した。

【００１３】例えば、ステップ（ａ）は、被管理リソー
スのプロパティ（例えば、メモリのサイズ、バッファ内
に受け入れるメッセージ数等のような、リソースの属
性）をモデル化するために、管理ビーンにおいて少なく
とも１つのプロパティを定義するステップを含むことが
できる。また、被管理リソースのアクション（例えば、
システム・リセット）をモデル化するために、管理ビー
ンのために少なくとも１つのメソッドを定義するステッ
プを含むことができる。また、被管理リソースの少なく
とも１つのイベント（例えば、ディスク・フル・イベン
ト）に対するサポートを定義するステップを含むことが
できる。この目的のために、管理ビーンは、リスナ・イ
ベント(listener event)に対するサポートを与えること
ができ、これによって、ある管理ビーンが他の管理ビー
ン上のイベントに応答することが可能となる。

【００１４】管理ビーンは、イントロスぺクションに対
するサポートを与え、ビーンの組成の外部分析、および
ビーン間の情報の交換を可能とする。

【００１５】このように、管理ビーンは、被管理リソー
ス間の関係および相互作用を表すものとして、管理ビー
ン間の関係および相互作用の定義を含むことができる。

【００１６】本発明の好適な実施形態では、ステップ
（ｂ）は、 ｉ）少なくとも１つの管理ビーンを、拡張可能なエージ
ェント・フレームワークに登録するステップと、 ｉｉ）ネットワーク通信プロトコルのための少なくとも
１つのネットワーク・アダプタを、拡張可能なエージェ
ント・フレームワークに登録するステップと、 ｉｉｉ）少なくとも１つのネットワーク・アダプタを通
じて少なくとも１つの管理ビーンに対して、ネットワー
クを通じた外部アクセスを可能にするステップとを含
む。

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

【００１８】好ましくは、拡張可能なエージェント・フ
レームワークは、関連するレポジトリ・ビーンを備え、
ステップ（ｂ）（ｉｉ）は、少なくとも１つの管理ビー
ンおよび／または少なくとも１つのネットワーク・アダ
プタを、レポジトリ・ビーンに登録するステップを含
む。

【００１９】ネットワーク・アダプタは、ネットワーク
・アダプタ・ビーンによって形成することができる。

【００２０】本発明の別の態様によれば、コンピュータ
・ネットワーク管理システムが提供され、このシステム
は、オブジェクトに基づくネットワーク管理モデリング
環境と、オブジェクトに基づく環境において、コンピュ
ータ・ネットワーク管理システムのインプリメンテーシ
ョンを生成するための、オブジェクトに基づく環境用コ
ンパイラと、から成る。

【００２１】

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

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

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

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

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

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

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

【００２８】通信ネットワークの管理は、種々のサイズ
および複雑度を有するアプリケーションを必要とする。
重要なマネージャ(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 (19)

【特許請求の範囲】
1. 【請求項１】 コンピュータ・ネットワーク管理システ
   ムを生成する、コンピュータ実装方法であって、 ａ）少なくとも１つの管理ビーンを含むネットワーク管
   理モデルを、ビーンに基づく環境を用いて定義するステ
   ップと、 ｂ）前記モデルをコンパイルし、前記ビーンに基づく環
   境において前記コンピュータ・ネットワーク管理システ
   ムを実装するステップと、 を含むことを特徴とする方法。
2. 【請求項２】 請求項１記載の方法において、ステップ
   （ａ）は、被管理リソースのプロパティをモデル化する
   少なくとも１つのプロパティを与える少なくとも１つの
   前記管理ビーンを定義するステップを含むことを特徴と
   する方法。
3. 【請求項３】 請求項２記載の方法において、ステップ
   （ａ）は、前記被管理リソースのためにアクションをモ
   デル化する方法を含む少なくとも１つの前記管理ビーン
   を定義するステップを含むことを特徴とする方法。
4. 【請求項４】 請求項２記載の方法において、ステップ
   （ａ）は、前記リソースのイベントをモデル化する少な
   くとも１つのイベントに対するサポートを与える少なく
   とも１つの前記管理ビーンを定義するステップを含むこ
   とを特徴とする方法。
5. 【請求項５】 請求項１記載の方法において、前記少な
   くとも１つの管理ビーンは、前記ビーンの組成の外部的
   な分析を可能にするイントロスペクションに対するサポ
   ートを与えることを特徴とする方法。
6. 【請求項６】 請求項５記載の方法において、ステップ
   （ａ）は、前記被管理リソース間の関係と相互作用とを
   表すものとして、管理ビーン間の関係と相互作用とを定
   義するステップを含むことを特徴とする方法。
7. 【請求項７】 請求項６記載の方法であって、少なくと
   も１つの管理ビーンに関して、少なくとも１つのリスナ
   ・イベントを定義するステップを含むことを特徴とする
   方法。
8. 【請求項８】 請求項１記載の方法において、ステップ
   （ｂ）は、 ｉ）少なくとも１つの前記管理ビーンを、拡張可能なエ
   ージェント・フレームワークに登録するステップと、 ｉｉ）ネットワーク通信プロトコルのための少なくとも
   １つのネットワーク・アダプタを、前記拡張可能なエー
   ジェント・フレームワークに登録するステップと、 ｉｉｉ）前記少なくとも１つのネットワーク・アダプタ
   を介する前記少なくとも１つの管理ビーンに対して、前
   記ネットワークを介する外部アクセスを可能にするステ
   ップと、 を含むことを特徴とする方法。
9. 【請求項９】 請求項８記載の方法において、前記拡張
   可能なエージェント・フレームワークは、関連するレポ
   ジトリ・ビーンを備えており、ステップ（ｂ）の（ｉ
   ｉ）は、前記少なくとも１つの管理ビーンおよび／また
   は前記少なくとも１つのネットワーク・アダプタを、前
   記レポジトリ・ビーンに登録するステップを含むことを
   特徴とする方法。
10. 【請求項１０】 請求項９記載の方法において、前記少
    なくとも１つのネットワーク・アダプタは、ネットワー
    ク・アダプタ・ビーンを備えていることを特徴とする方
    法。
11. 【請求項１１】 コンピュータ・ネットワーク管理シス
    テムであって、 オブジェクト・ベースのネットワーク管理モデリング環
    境と、 前記オブジェクト・ベースの環境において前記コンピュ
    ータ・ネットワーク管理システムのインプリメンテーシ
    ョンを生成する前記オブジェクト・ベースの環境のため
    のコンパイラと、 を含むことを特徴とするコンピュータ・ネットワーク管
    理システム。
12. 【請求項１２】 請求項１１記載のコンピュータ・ネッ
    トワーク管理システムにおいて、少なくとも１つの前記
    管理ビーンは、被管理リソースのプロパティをモデリン
    グする少なくとも１つのプロパティを与えることを特徴
    とするコンピュータ・ネットワーク管理システム。
13. 【請求項１３】 請求項１１記載のコンピュータ・ネッ
    トワーク管理システムにおいて、少なくとも１つの前記
    管理ビーンは、前記被管理リソースのためにアクション
    をモデル化するメソッドを含むことを特徴とするコンピ
    ュータ・ネットワーク管理システム。
14. 【請求項１４】 請求項１１記載のコンピュータ・ネッ
    トワーク管理システムにおいて、少なくとも１つの前記
    管理ビーンには、前記リソースのイベントをモデル化す
    るための少なくとも１つのイベントに対するサポートが
    提供されていることを特徴とするコンピュータ・ネット
    ワーク管理システム。
15. 【請求項１５】 請求項１１記載のコンピュータ・ネッ
    トワーク管理システムにおいて、少なくとも１つの前記
    管理ビーンは、前記ビーンの組成の外部的な分析を可能
    にするイントロスペクションに対するサポートを与える
    ことを特徴とするコンピュータ・ネットワーク管理シス
    テム。
16. 【請求項１６】 請求項１１記載のコンピュータ・ネッ
    トワーク管理システムにおいて、前記管理ビーン間の関
    係および相互作用を定義する複数の管理ビーンは、前記
    被管理リソース間の関係と相互作用とを表すことを特徴
    とするコンピュータ・ネットワーク管理システム。
17. 【請求項１７】 請求項１６記載のコンピュータ・ネッ
    トワーク管理システムにおいて、少なくとも１つの管理
    ビーンには、リスナ・イベントに対するサポートが提供
    されていることを特徴とするコンピュータ・ネットワー
    ク管理システム。
18. 【請求項１８】 請求項１１記載のコンピュータ・ネッ
    トワーク管理システムにおいて、前記コンパイルされた
    システムは、 拡張可能なフレームワーク・サービス・オブジェクト
    と、 前記フレームワーク・サービスに登録可能な少なくとも
    １つの管理ビーンと、 前記フレームワーク・サービスに登録可能であり、前記
    管理ビーンに対するアクセスを可能にするネットワーク
    通信プロトコルのための少なくとも１つのネットワーク
    ・アダプタ・ビーンと、 を含むネットワーク・エージェントを備えることを特徴
    とするコンピュータ・ネットワーク管理システム。
19. 【請求項１９】 請求項１８記載のコンピュータ・ネッ
    トワーク管理システムにおいて、前記ネットワーク・エ
    ージェントは、関連するレポジトリ・ビーンを備えてお
    り、前記少なくとも１つの管理ビーンおよび／または前
    記少なくとも１つのネットワーク・アダプタ・ビーン
    は、前記レポジトリ・ビーンに登録可能であることを特
    徴とするコンピュータ・ネットワーク管理システム。