JPH11224196A - リモート・オブジェクト・アクセス - Google Patents

Abstract

(57)【要約】 （修正有） 【課題】 目標オブジェクトの表現を形成するクライア
ント・オブジェクトを生成することにより、目標オブジ
ェクトに対するリモート・アクセスを行なう。 【解決手段】 クライアント・オブジェクトは、遠隔的
にアクセス可能な目標オブジェクトのメソッドを識別
し、遠隔的にアクセス可能な目標オブジェクトを実装す
る。目標オブジェクトはリモート・ステーションにおい
て、またクライアント・オブジェクトはクライアント・
マシンにおいて、おのおのネットワーク・プロトコルに
対するネットワーク・アダプタと関連付けられる。こう
して、クライアント・アプリケーションは、クライアン
ト・オブジェクトを通して、遠隔の目標オブジェクトに
アクセスすることができる。目標オブジェクトを修正し
たり、特定の通信コードをそれに含ませる必要はない。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、オブジェクト、特
に、ビーン(bean)として知られているオブジェクトの制
御および／またはアクセスに関するものである。

【０００２】

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

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

【０００４】

【発明が解決しようとする課題】しかしながら、通常、
ビーンは、当該ビーンが存在する仮想マシン環境内での
み、その制御および操作が可能である。米国特許第５，
３１５，７０３号および米国特許第５，３６７，６３３
号は、変更通知機能を与える、オブジェクトに基づくシ
ステムについて記載する。しかしながら、これらの特許
は、スタンド・アロンのシステムについて記載するに過
ぎない。

【０００５】例えば、ネットワークを通じて、遠方から
ビーンにアクセスしたり、ビーンを制御することができ
れば望ましいであろう。しかしながら、これは、適切な
メソッドをビーン自体の中に実際に含ませ、その必要と
されるメソッドを露出させなければ可能ではない。しか
しながら、遠隔的なアクセスを可能とするようにビーン
を特定的に適合化させなければならないことは望ましく
ない。したがって、事前の修正なく、あらゆるビーンを
遠隔的にアクセス、制御、および修正することができれ
ば、望ましいであろう。

【０００６】したがって、本発明の目的は、この問題に
対処することである。

【０００７】

【課題を解決するための手段】本発明によれば、通信ネ
ットワークを通じて、クライアント・ステーションか
ら、リモート・ステーションにおける目標オブジェクト
にアクセスする方法が提供され、この方法は、 ａ）目標オブジェクトの表現を形成するクライアント・
オブジェクトを生成し、遠隔的にアクセス可能な目標オ
ブジェクトのメソッドを識別し、遠隔的にアクセス可能
なメソッドを実装するようにクライアント・オブジェク
トを構成するステップと、 ｂ）目標オブジェクトとネットワーク・プロトコルに対
するネットワーク・アダプタとを、リモート・ステーシ
ョンにおけるフレームワークに登録するステップと、 ｃ）クライアント・マシンにおいて、クライアント・オ
ブジェクトを、ネットワーク・プロトコルに対するネッ
トワーク・アダプタと関連付けるステップと、 ｄ）クライアント・オブジェクトをインスタンス化する
ことにより、クライアント・アプリケーションが目標タ
ーゲットにアクセスすることを可能にするステップと、
から成る。

【０００８】クライアント・ステーションおよびリモー
ト・ステーションにおいてネットワーク・プロトコル・
アダプタを用い、更に目標オブジェクトのクライアント
・オブジェクト表現を用いることによって、リモート・
ステーションにおいて、目標オブジェクトのリモート・
アクセス、制御、および修正が、必要であれば、可能と
なり、しかも目標オブジェクトを予め修正したり、目標
オブジェクトにそれ自体の内部リモート・アクセス・メ
ソッドを含むことを要求する必要はない。

【０００９】本発明の好適な実施形態では、目標オブジ
ェクトをネットワーク・エージェントのフレームワーク
のレポジトリ・サービスに登録することによって、目標
オブジェクトをネットワーク・アダプタと関連付ける。
ネットワーク・アダプタは、リモート・アクセス要求に
応答し、フレームワークに、レポジトリ・サービスを参
照することによって、目標オブジェクトに対するアクセ
スを起動させる。

【００１０】好ましくは、ステップ（ａ）は、目標オブ
ジェクトをコンパイルし、目標オブジェクトのどのメソ
ッドが遠隔的にアクセス可能であるかを識別する目標オ
ブジェクト・インターフェースと、および遠隔的にアク
セス可能なメソッドを実装する目標オブジェクト・スタ
ブとから成るクライアント・オブジェクトを生成するス
テップを含む。コンパイルするステップは、リモート・
ステーションまたはクライアント・ステーションにおい
て実行することができ、得られたコードは、例えば、ネ
ットワークを通じて転送することができる。しかしなが
ら、代替案として、コンパイルは、クライアント・ステ
ーションおよびリモート・ステーション双方において行
なうことができる。

【００１１】好ましくは、ステップ（ｄ）は、目標オブ
ジェクト・スタブを選択的に交換し、実行時においてク
ライアント・アプリケーションのビヘービャを動的に変
更するステップを含む。例えば、第１および第２のスタ
ブをそれぞれ用いて、目標オブジェクトに対するリード
・オンリ・アクセスを指定するか、あるいはリード−ラ
イト・アクセスを指定することができる。

【００１２】本発明は、ビーンの形態のオブジェクトに
対して、特に適用されるものである。ビーンは、１組の
プロパティ、アクションを実行する１組のメソッド、な
らびにイベントおよびイントロスペクションに対するサ
ポートから成る。イントロスペクションに対するサポー
トは、コンパイラがクライアント・オブジェクト（また
は複数のクライアント・オブジェクト）を生成すること
を可能とし、ユーザ・アプリケーションがクライアント
・オブジェクト（または複数のクライアント・オブジェ
クト）と相互作用を行い、目標オブジェクトの少なくと
も選択されたメソッドにアクセスし表示することを可能
にする。実際には、ステップ（ａ）は、イントロスペク
ションによって目標オブジェクトのメソッドを抽出する
ステップを含むことが好ましい。

【００１３】本発明は、目標オブジェクトが被管理オブ
ジェクトであり、クライアント・アプリケーションがネ
ットワーク管理アプリケーションであるネットワーク管
理システムに、特に適用されるものであるが、これのみ
に限定される訳ではない。

【００１４】本発明の別の態様によれば、クライアント
・ステーションにおいて、通信ネットワークを通じて、
リモート・ステーションにおける目標オブジェクトにア
クセスするための、リモート・アクセス・サポート機構
が提供され、このリモート・アクセス・サポート機構
は、目標オブジェクトの表現を形成するクライアント・
オブジェクトであって、遠隔的にアクセス可能な目標オ
ブジェクトのメソッドを識別し、遠隔的にアクセス可能
なメソッドを実装するクライアント・オブジェクトと、
クライアント・オブジェクトに応答するネットワーク・
アダプタと、から成り、クライアント・オブジェクト
が、クライアント・アプリケーションによってインスタ
ンス化され、クライアント・アプリケーションが目標タ
ーゲットにアクセスしそれを修正することを可能にする
ように構成されている。

【００１５】本発明の更に別の態様によれば、通信ネッ
トワークを通じて、第１のマシンにおける目標オブジェ
クトにクライアント・マシンからのリモート・アクセス
を可能とする、第１のマシンにおけるリモート・アクセ
ス・サポート機構が提供され、このリモート・アクセス
・サポート機構は、少なくとも１つの目標オブジェクト
と、ネットワーク・プロトコルに対応する少なくとも１
つのネットワーク・アダプタと、から成り、目標オブジ
ェクト（または複数の目標オブジェクト）とネットワー
ク・アダプタ（または複数のネットワーク・アダプタ）
が、第１のマシンにおけるフレームワークに登録可能で
あり、ネットワーク・アダプタが、プロトコルにしたが
って、クライアント・マシンからのリモート・アクセス
要求に応答し、フレームワークを通じて目標オブジェク
トにアクセスする。

【００１６】本発明の更に他の態様によれば、通信ネッ
トワークを通じて、第１のマシンにおける目標オブジェ
クトにクライアント・マシンからのリモート・アクセス
を可能とする、コンピュータ用データ担体上のリモート
・アクセス・サポート機構が提供され、このリモート・
アクセス・サポート機構は、少なくとも１つの目標オブ
ジェクトと、ネットワーク・プロトコルに対応する少な
くとも１つのネットワーク・アダプタと、から成り、目
標オブジェクト（または複数の目標オブジェクト）とネ
ットワーク・アダプタ（または複数のネットワーク・ア
ダプタ）が、第１のマシンにおけるフレームワークに登
録可能であり、ネットワーク・アダプタが、プロトコル
にしたがって、クライアント・マシンからのリモート・
アクセス要求に応答して、フレームワークを通じて目標
オブジェクトにアクセスする。

【００１７】

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

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

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

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

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

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

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

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

【特許請求の範囲】
1. 【請求項１】 通信ネットワークを通じて、クライアン
   ト・ステーションから、リモート・ステーションにおけ
   る目標オブジェクトにアクセスする方法であって、 ａ）前記目標オブジェクトの表現を形成するクライアン
   ト・オブジェクトを生成するステップであって、前記ク
   ライアント・オブジェクトは、遠隔的にアクセス可能な
   前記目標オブジェクトのメソッドを識別し、前記遠隔的
   にアクセス可能なメソッドを実装するように構成されて
   いる、ステップと、 ｂ）前記目標オブジェクトとネットワーク・プロトコル
   に対するネットワーク・アダプタとを、前記リモート・
   ステーションにおけるフレームワークに登録するステッ
   プと、 ｃ）クライアント・マシンにおいて、前記クライアント
   ・オブジェクトを、前記ネットワーク・プロトコルに対
   するネットワーク・アダプタと関連付けるステップと、 ｄ）前記クライアント・オブジェクトをインスタンス化
   することにより、クライアント・アプリケーションが前
   記目標オブジェクトにアクセスすることを可能にするス
   テップと、 を含むことを特徴とする方法。
2. 【請求項２】 請求項１記載の方法において、ステップ
   （ａ）は、目標オブジェクトをコンパイルし、前記目標
   オブジェクトのどのメソッドが遠隔的にアクセス可能で
   あるかを識別する目標オブジェクト・インターフェース
   と、遠隔的にアクセス可能なメソッドを実装する目標オ
   ブジェクト・スタブとから成るクライアント・オブジェ
   クトを生成するステップを含むことを特徴とする方法。
3. 【請求項３】 請求項２記載の方法において、ステップ
   （ｄ）は、前記目標オブジェクト・スタブを選択的に交
   換し、実行時において前記クライアント・アプリケーシ
   ョンのビヘービャを動的に修正するステップを含むこと
   を特徴とする方法。
4. 【請求項４】 請求項１記載の方法において、前記クラ
   イアント・オブジェクトおよび前記目標オブジェクト
   は、ビーンであって、それぞれが、１組のプロパティ、
   アクションを実行する１組のメソッド、ならびにイベン
   トおよびイントロスペクションに対するサポートから成
   ることを特徴とする方法。
5. 【請求項５】 請求項４記載の方法において、ステップ
   （ａ）は、イントロスペクションによって目標オブジェ
   クトのメソッドを抽出するステップを含むことを特徴と
   する方法。
6. 【請求項６】 請求項１記載の方法において、前記目標
   オブジェクトは、被管理オブジェクトであり、前記クラ
   イアント・アプリケーションは、ネットワーク管理アプ
   リケーションであることを特徴とする方法。
7. 【請求項７】 クライアント・ステーションにおいて、
   通信ネットワークを通じて、リモート・ステーションに
   おける目標オブジェクトにアクセスするための、リモー
   ト・アクセス・サポート機構であって、 前記目標オブジェクトの表現を形成するクライアント・
   オブジェクトであって、遠隔的にアクセス可能な前記目
   標オブジェクトのメソッドを識別し、前記遠隔的にアク
   セス可能なメソッドを実装するクライアント・オブジェ
   クトと、 前記クライアント・オブジェクトに応答するネットワー
   ク・アダプタと、 を備えており、前記クライアント・オブジェクトは、ク
   ライアント・アプリケーションによってインスタンス化
   され、前記クライアント・アプリケーションが前記目標
   オブジェクトにアクセスしそれを修正することを可能と
   するように構成されていることを特徴とするリモート・
   アクセス・サポート機構。
8. 【請求項８】 請求項７記載のリモート・アクセス・サ
   ポート機構において、前記クライアント・オブジェクト
   は、目標オブジェクトからコンパイルされ、前記目標オ
   ブジェクトのどのメソッドが遠隔的にアクセス可能であ
   るかを識別する目標オブジェクト・インタフェースと、
   前記遠隔的にアクセス可能なメソッドを実装する目標オ
   ブジェクト・スタブとを含むことを特徴とするリモート
   ・アクセス・サポート機構。
9. 【請求項９】 請求項８記載のリモート・アクセス・サ
   ポート機構において、前記目標オブジェクト・スタブ
   は、選択的に交換可能であり、実行時に前記クライアン
   ト・アプリケーションのビヘービャを動的に修正するこ
   とを特徴とするリモート・アクセス・サポート機構。
10. 【請求項１０】 請求項９記載のリモート・アクセス・
    サポート機構において、前記クライアント・オブジェク
    トは、１組のプロパティ、アクションを実行する１組の
    メソッド、ならびにイベントおよびイントロスペクショ
    ンに対するサポートを有するオブジェクトであることを
    特徴とするリモート・アクセス・サポート機構。
11. 【請求項１１】 請求項１０記載のリモート・アクセス
    ・サポート機構において、前記クライアント・オブジェ
    クトおよび前記目標オブジェクトは、ビーンであって、
    それぞれが、１組のプロパティ、アクションを実行する
    １組のメソッド、ならびにイベントおよびイントロスペ
    クションに対するサポートから成ることを特徴とするリ
    モート・アクセス・サポート機構。
12. 【請求項１２】 請求項１１記載のリモート・アクセス
    ・サポート機構であって、イントロスペクションによっ
    て前記目標オブジェクトのメソッドを抽出し、前記クラ
    イアント・オブジェクトを生成するコンパイラを備えて
    いることを特徴とするリモート・アクセス・サポート機
    構。
13. 【請求項１３】 請求項１１記載のリモート・アクセス
    ・サポート機構において、前記目標オブジェクトは、被
    管理オブジェクトであり、前記クライアント・アプリケ
    ーションは、ネットワーク管理アプリケーションである
    ことを特徴とするリモート・アクセス・サポート機構。
14. 【請求項１４】 請求項１３記載のリモート・アクセス
    ・サポート機構であって、ソフトウエア機構を備えてい
    ることを特徴とするリモート・アクセス・サポート機
    構。
15. 【請求項１５】 通信ネットワークを通じて第１のマシ
    ンにおける目標オブジェクトに対するクライアント・マ
    シンからのリモート・アクセスを可能とする、前記第１
    のマシンにおけるリモート・アクセス・サポート機構で
    あって、 少なくとも１つの目標オブジェクトと、 ネットワーク・プロトコルをサポートする少なくとも１
    つのネットワーク・アダプタと、 を備えており、前記少なくとも１つの目標オブジェクト
    と前記少なくとも１つのネットワーク・アダプタとは、
    前記第１のマシンにおけるフレームワークに登録可能で
    あり、前記ネットワーク・アダプタは、前記プロトコル
    にしたがって、前記クライアント・マシンからのリモー
    ト・アクセス要求に応答して、前記フレームワークを通
    じて前記目標オブジェクトにアクセスすることを特徴と
    するリモート・アクセス・サポート機構。
16. 【請求項１６】 請求項１５記載のリモート・アクセス
    ・サポート機構であって、ソフトウエア機構を備えてい
    ることを特徴とするリモート・アクセス・サポート機
    構。
17. 【請求項１７】 通信ネットワークを通じて、第１のマ
    シンにおける目標オブジェクトに対するクライアント・
    マシンからのリモート・アクセスを可能とする、コンピ
    ュータ用データ・キャリア上のリモート・アクセス・サ
    ポート機構であって、 少なくとも１つの目標オブジェクトと、 ネットワーク・プロトコルに対応する少なくとも１つの
    ネットワーク・アダプタと、 を備えており、前記少なくとも１つの目標オブジェクト
    と前記少なくとも１つのネットワーク・アダプタとは、
    前記第１のマシンにおけるフレームワークに登録可能で
    あり、前記ネットワーク・アダプタは、前記プロトコル
    にしたがって、前記クライアント・マシンからのリモー
    ト・アクセス要求に応答して、前記フレームワークを通
    じて前記目標オブジェクトにアクセスすることを特徴と
    するリモート・アクセス・サポート機構。