(57)【特許請求の範囲】
【請求項１】
制御可能なネットワーク要素を有しているネットワークにおいて、前記ネットワークに接続可能なワークステーションから前記ネットワーク要素を管理するための方法であって、該方法は、
クライアントアプリケーションにおいてオブジェクトを管理するために１以上のクライアントアプリケーションを実行するステップであって、該オブジェクトがネットワーク要素を表している、ステップ、
ネットワーク要素についての複数の属性のうちの、選択された１以上の属性を追跡管理するためにオブジェクト・サーバで該１以上のクライアントアプリケーションが登録するステップ、
前記クライアントアプリケーションの実行中に前記ワークステーションによって定義されたメンテナンス動作を要求するためのコマンドを、オブジェクト・サーバがプログラムされているオブジェクト指向言語において対応する要求に変換するステップからなり、
該変換するステップが、
該ワークステーションからのメンテナンス動作を要求するためのコマンドに基づいて、変換された要求を定義するステップであって、該変換された要求が該オブジェクトに対するメンテナンス動作である、ステップを含み、
前記方法がさらに、
該コマンドをＳＮＭＰに変換して、該ネットワーク要素に関連するオブジェクトに送信するステップ、
該選択された属性に対するネットワーク要素を該オブジェクト・サーバによってポーリングするステップであって、ポーリングサイクル中に複数のクライアントアプリケーションが該選択された属性に登録される場合には繰り返しをしない、ステップ、及び
該オブジェクト・サーバによって、前記１以上のクライアントアプリケーションに対して、前記選択した１以上の属性における変化を非同期的にレポートするステップ
からなる方法。
【請求項２】
請求項１に記載の方法において、前記オブジェクト・サーバが前記変換された要求に応答し、その応答が、
前記ネットワーク要素から情報を収集するステップ、
該収集された情報のウェブ・ページのビジュアル・ディスプレイを発生することによって、該収集された情報を該ワークステーションに送るステップ
によってなされる方法。
【請求項３】
請求項２に記載の方法において、前記収集された情報が１以上の、
該ネットワーク要素上のアクティブ・アラーム、
該ネットワーク要素上のシステム・アラーム、及び
該ネットワーク要素の詳細ステータス
を含む方法。
【請求項４】
請求項１に記載の方法において、前記変換するステップが、
分散型のオブジェクト要求アーキテクチャを介して該クライアントアプリケーションによって前記オブジェクト・サーバと通信するステップ
を含む方法。
【請求項５】
請求項４に記載の方法において、前記分散型のオブジェクト要求アーキテクチャがＣＯＲＢＡアーキテクチャである方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ネットワーク要素を制御するための方法に関し、特にネットワークを通じての通信によってそのネットワークを遠隔制御するための方法に関する。
【０００２】
【従来の技術、及び、発明が解決しようとする課題】
管理ワークステーションとネットワークを通じて送られる被管理ネットワーク要素との間の通信によって、遠隔管理ワークステーションから、ネットワーク要素または管理エージェントが遠隔制御されるネットワーク管理システムは知られている。そのような既知のネットワーク管理システムは、管理プログラムを実行している遠隔ワークステーションと、そのワークステーションとネットワーク要素との間のインターフェースを定義する管理情報ベースを含んでいる要素管理サーバとの間の通信のために、特別の通信プロトコルを採用する。
【０００３】
既知のシステム（Ｈｅｗｌｅｔｔ  ＰａｃｋａｒｄのＨＰ‐ＯＶ  ＮＮＭまたはＤＭ、Ｓｕｎ  ＭｉｃｒｏｓｙｓｔｅｍｓのＳｏｌｓｔｉｃｅなど）はステータスが必要な時にクライアントのアプリケーションがそのネットワーク要素をポーリングしなければならない場合のインターフェースを提供する。これらのシステムにおいては、そのポーリングは調整することができず、そして各クライアントが同じ属性を必要とする場合に、各クライアントに対して複製される。また、各クライアントは各ポーリング・サイクルに対して全体の結果を受信し（前のサイクルから変化がなかった場合でも）、そのネットワーク要素における複製されたポーリングのために追加の処理オーバヘッドを生成すること以外に、クライアント・アプリケーションとネットワーク要素との間の通信に使われるバンド幅を増加させる。
【０００４】
【課題を解決するための手段】
ネットワークに接続可能な遠隔ワークステーションからネットワーク要素を制御するための方法が提供される。その方法は、追跡管理されるべき属性に対してそのネットワーク要素を登録すること、そしてクライアントがネットワーク要素の監視を要求した場合に、そのネットワーク要素に関連付けられた属性に対するポーリングを提供する。属性における変化は、クライアントが属性における変化の通知を要求した時にレポートされる。複数のクライアントに対してポーリングされる属性の場合、その属性における変化の通知を要求している複数のクライアントのうちの１つに対して、その属性における変化がレポートされる。
【０００５】
その方法は、さらに、その同じ属性に対して登録する複数のクライアントに対して一度のポーリングおよび複数のクライアントに対する属性における非同期的変化のレポートを提供する。
【０００６】
本発明のもう１つの態様によれば、制御可能なネットワーク要素に関連付けられたオブジェクトを制御するために、遠隔ワークステーションにおいてオブジェクト指向のプログラムを実行するステップと、制御されているオブジェクトに関連付けられたオブジェクト指向言語で、対応している変換されるインターフェース動作に対してオブジェクト指向プログラムの実行時に、そのワークステーションによって発生されるインターフェース動作を変換するステップと、ネットワークを通じてその対応している変換されたインターフェース動作をオブジェクト・サーバに対して接続し、その変換されたインターフェース動作に従って、そのネットワーク要素に関連付けられたオブジェクトを制御するステップとを提供する。
【０００７】
本発明のこれら、および他の特徴および利点は、以下の詳細な説明、添付図面および添付されている特許請求の範囲から明らかになるだろう。
上記の有利な特徴が詳細に説明され、本発明の他の有利な特徴が以下のいくつかの図面を参照して与えられる本発明の好適な実施形態の詳細な記述から明らかになるだろう。
【０００８】
【発明の実施の形態】
本発明は、分散型のクライアント・アプリケーションと、要素管理サーバとの間の効率的な通信を、そのネットワーク要素に対する通信プロトコルとは独立に提供するアプリケーション・プログラミング・インターフェース（ＡＰＩ）およびプロトコルを提供する。Ｅｌｅｍｅｎｔ  Ｍａｎａｇｅｍｅｎｔ  Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ（要素管理アプリケーション・プログラミング・インターフェース）（ＥＭＡＰＩ）は既知の管理システムに比べて次の利点を提供する。本発明は、遠隔通信ネットワーク要素の管理において応用される。遠隔通信ネットワーク要素のそのような管理に対するさらに詳しい情報は、１９９８年５月３１日出願のウイリアム（Ｗｉｌｌｉａｍ）  Ｅ．バーカ（Ｂａｒｋｅｒ）、リサ（Ｌｉｓａ）、Ｍ．コネリー（Ｃｏｎｎｅｌｌｙ）、マービン（Ｍａｒｖｉｎ）、Ａ．エガート（Ｅｇｇｅｒｔ）、ミカエル（Ｍｉｃｈａｅｌ）、Ｐ．フォーレイ（Ｆｏｌｅｙ）、ケネス（Ｋｅｎｎｅｔｈ）、Ｒ．マックファーレン（Ｍａｃｆａｒｌａｎｅ）、フィリップ（Ｐｈｉｌｉｐ）Ｍ．パーソンズ（Ｐａｒｓｏｎｓ）、ギリッシュ（Ｇｉｒｉｓｈ）ライ（Ｒａｉ）、ジェローム（Ｊｅｒｏｍｅ）Ｅ．ログ（Ｒｏｇ）、およびクルト（Ｋｕｒｔ）Ａ．ヴァングネス（Ｖａｎｇｓｎｅｓｓ）による”Ｍｅｔｈｏｄ  ｆｏｒ  Ｃｏｍｐｕｔｅｒ  Ｉｎｔｅｒｎｅｔ  Ｒｅｍｏｔｅ  Ｍａｎａｇｅｍｅｎｔ  ｏｆ  ａ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｎｅｔｗｏｒｋ  Ｅｌｅｍｅｎｔ“（遠隔通信ネットワーク要素のコンピュータ・インターネット・遠隔管理の方法）と題する、同一所有の米国特許出願第０９／０８８，４６３号を参照されたい。この特許出願は引用によって本明細書の記載に援用する。
【０００９】
・  低いバンド幅のコネクション上での効率的な使用。クライアントのアプリケーションは、自分が追跡したいネットワークの情報に対して登録し、データの初期設定の後、変化があった時だけインクリメンタルな更新（デルタ）を受信する。
【００１０】
・  属性の中央集中型ポーリング。属性がポーリングされるのは、その属性を監視するために登録したクライアントが存在する場合だけである。複数のクライアントがその同じ属性に対して登録する場合、ポーリングはそのクライアントに対して繰り返されず、単独のポーリング・サイクルだけが実行される。
【００１１】
本発明は図１に示されているような動作、管理およびメンテナンスのシステム２０において使われる。システム２０は、ＰＣまたはワークステーション２２と、要素管理サーバ（ＥＭＳ）２４と、ワークステーション２２と、オブジェクト・サーバ２５との間にある本発明によるインターフェース２６とを含む。アプリケーション・プロセッサ２８が要素管理サーバ２４に対して接続されている。
【００１２】
ワークステーション２２は、クライアントに対するインターフェースであり、ＪＡＶＡのアプレット３２およびハイパーテキスト・マークアップ言語であるウェブ・ブラウザＨＴＭＬ３５に対するホストであるウェブ・ブラウザ３０を含む。
【００１３】
システム２０は、クライアント・コンピューティング環境において動作し、顧客から見える追加の機能を可能にするための棚卸しの技術を目的遂行の手段とし、一方、最小限の追加コストでそれ以降のリリースおよび他のプロジェクトに対する拡張を行っている。システム２０はウェブ・ブラウザのインターフェースおよびＳＮＭＰベースの要素管理プラットフォームを通じて提供される。
【００１４】
クライアントは、ワークステーション２２にあるウェブ・ページを経由してアプリケーションを実行する。クライアントはウェブ・ブラウザ３０を通して選択することによって、ネットワークのステータスの各種のビューに対する要求を行う。ウェブ・ブラウザはウェブ・サーバ２８からページを要求し、ウェブ・ブラウザ２８は適切なＪＡＶＡアプレット３２をロードして実行するためのインストラクションを含んでいるＨＴＭＬページを送信する。そのアプレットがスタートすると、それはインターフェース２６を通じてオブジェクト・サーバ２５と通信し、初期化を実行し、そして現在の要求されたビューに対して適切である初期コンフィギュレーションおよびステータス情報を要求する。次にＪＡＶＡアプレット３２はオブジェクト・サーバ２５について自分が最新に保つ必要があるコンフィギュレーションおよびステータスに対する変化のそれ以降での通知に対して登録する。クライアントはネットワーク要素２８上での各種のメンテナンス動作を要求するためにコマンドを実行することができる。これらのコマンドはインターフェース２６を通じて適切な要求に変換され、オブジェクト・サーバ２５上で動作を実行する。次に、そのコマンドがＳＮＭＰに変換され、そしてＳＮＭＰのライブラリ３３を通じてネットワーク要素２８に対して送信される。ネットワーク要素２８からのアクノレッジメントおよびコマンドの応答がＳＮＭＰライブラリ３３を通じて送信され、オブジェクト・サーバ２５によってイベントへ変換され、そしてインターフェース２６によって定義されているコール・バックを使って元のＪＡＶＡアプレット３２へ送信される。
【００１５】
本発明の１つの実施形態においては、図３に示されているように、ＪＡＶＡアプレット３２の中のクライアント・アプリケーションは、アクティブなアラーム・リストのブラウザと、システム・アラーム・サーベイと、ネットワーク要素の詳細ステータス表示とを含む。クライアントのアプリケーションは、本発明によるインターフェース２６を経由してウェブ・ブラウザ２８と通信し、ＣＯＲＢＡなどの分散型のオブジェクト要求アーキテクチャを通じて要素マネージャに対して通信する。インターフェース２６は、ネットワーク内のすべての被管理オブジェクトに対して一定のインターフェースを提供し、そして要素管理のプラットフォームに関連付けられている実装の詳細を隠す。
【００１６】
インターフェース２６（ＥＭＡＰＩ）は、クライアント・アプリケーションと、ネットワーク要素を管理するための、サーバとの間のオブジェクト、属性および動作の定義である。ＥＭＡＰＩは業界標準のＣＯＲＢＡを使ってオブジェクトおよびそれらの動作の分配を提供し、そしてクライアントおよびサーバが異なるプログラミング言語で、そして異なるコンピュータ・アーキテクチャにおいて実装されることを可能にする。
【００１７】
サーバおよび被管理オブジェクトの属性に対するクライアント・インターフェースがインターフェース２６の中に記述されており、そして被管理オブジェクトの表記がネットワーク内のすべての被管理オブジェクトの首尾一貫したモデルを提供し、要素マネージャのプラットフォームに関連付けられた実装の詳細をクライアント・アプリケーションから隠し、したがって、クライアントがそのネットワーク要素に対する根底にあるプラットフォームを知る必要がない。被管理オブジェクトの特有のロジックは、各種のアプリケーション全体に渡って散布される代わりに、その被管理オブジェクトの内部にカプセル化されており、したがって、クライアント・アプリケーションの開発を単純化している。
【００１８】
ネットワーク内の物理的な、選択された非物理的な、そして論理コンポーネントのそれぞれが被管理オブジェクトとしてモデル化され、それをサーバがＣｏｍｍｏｎ  Ｏｂｊｅｃｔ  Ｒｅｑｕｅｓｔ  Ｂｒｏｋｅｒ  Ａｒｃｈｉｔｅｃｔｕｒｅ（共通オブジェクト要求ブローカ・アーキテクチャ）（ＣＯＲＢＡ）のファシリティを通じて、分散型クライアント・アプリケーションに対して見えるようにしている。ＥＭのクライアントは、各アプリケーションの被管理オブジェクトに対して定義されている属性および動作に関してのみ関心を持ち、そしオブジェクト・サービスをサポートするために必要なネットワーク・レベルのプロトコルおよびサーバのインフラストラクチャの詳細を知る必要はない。
【００１９】
＜ＥＭＡＰＩのオブジェクト定義＞
図３は、クライアントのアプリケーションにとって見えるインターフェースのすべてを示しており、それはプロセスまたはプロセッサの境界を描いておらず、その境界はクライアントおよびサーバのオブジェクト要求ブローカ（ＯＲＢ）によってトランスペアレントにされている。アプリケーション・サービスは、ＣＯＲＢＡの中で公式に定義されているオブジェクト・インターフェース、すなわち、Ｉｎｔｅｒｆａｃｅ  Ｄｅｆｉｎｉｔｉｏｎ  Ｌａｎｇｕａｇｅ（インターフェース定義言語）（ＩＤＬ）を通じて提供される。このドキュメントの中で記述されているインターフェースのＩＤＬ仕様が付録Ａの中で提供されている。
【００２０】
クライアント・アプリケーションが対話するサーバ上に常駐しているサービス・オブジェクトが図４に示されている。
イベント、アラームまたはコンフィギュレーションの変化のリアルタイムのステータス更新または通知に対して登録するクライアント・アプリケーションは、サーバが情報を非同期的に伝播させるために使うことになるローカルのコール・バック・オブジェクトに対する参照を定義しなければならない。インターフェース２６の中で定義されているコール・バック・インターフェースが図５に示されている。これらのインターフェースを実装するクラスがクライアントのコードで定義され、実例を挙げて示されなければならない。
【００２１】
＜データ表現＞
インターフェース２６において定義されているいくつかの基本的なデータ・タイプがあり、それらは図６に示されている２つのカテゴリーのうちの１つの中に入る。
【００２２】
＜セッション・マネジメント＞
各ＥＭクライアント・セッションは、ユニークなログイン‐ホストの組合せに対して論理的に関連付けられている。複数のクライアント・アプリケーションを同じセッションに関連付けることができる。ただし、アクティブであると考えられるセッションに対して１つだけ登録される必要がある。セッションおよびアプリケーションの識別子はクライアントによって使われるリソースを追跡管理するため、そして将来のリリースにおいては、クライアントのアクセス許可を動作要求と相関付けるために、ユーザ・セッション・マネージャによって割り当てられる。アプリケーションは、プロセスの境界を横切る場合もあり、横切らない場合もある。たとえば、同じログインおよびホストによって登録されたＥＭＳのコマンド・ライン・インターフェース（ＣＬＩ）アプリケーションの複数のインスタンスは同じセッションｉｄを共有することになるが、各プロセスは、異なるアプリケーションｉｄと関連付けられている。ＥＭＳのグラフィカル・ユーザ・インターフェースにおいて、すべてのアプリケーション・フレームは、同じプロセス空間の中で実行され（異なるスレッドの中にあるにもかかわらず）、しかも各フレームは独特のアプリケーションｉｄと関連付けられている。各クライアント・アプリケーションは、その関連付けられているリソースが依然として必要であることをサーバに対して検証するために、周期的なハートビート（ｈｅａｒｔｂｅａｔ）を独立に登録する必要があることに留意されたい。
【００２３】
ＵｓｅｒＳｅｓｓｉｏｎサービス・オブジェクトは次のインターフェースを提供する。
・  ｓｔａｒｔＡｐｐｌｉｃａｔｉｏｎ
このメソッドは各クライアント・アプリケーションの初期化のために呼び出されなければならない。
・  ｓｔｏｐＡｐｐｌｉｃａｔｉｏｎ
クライアントは、このメソッドを呼び出して、ターゲットのアプリケーションが終了しつつあり、そしてその関連付けられているリソースが解放されるべきであることをサーバに通知する。
【００２４】
・  ｓｔｏｐ
このメソッドは、同じセッション識別子に関連付けられているすべてのアプリケーションの登録を解除するために使うことができる。
・  ｈｅａｒｔｂｅａｔ
このメソッドは、タイムアウトの状態を回避するために、少なくともＵｓｅｒＳｅｓｓｉｏｎ：：ＨｅａｒｔｂｅａｔＰｅｒｉｏｄ秒ごとに呼び出されなければならない。タイムアウト状態がサーバの監査によって検出されると、１つのアプリケーションによって利用されているすべてのリソースが解放されることになる。
さらに詳しくは付録の中のインターフェースＵｓｅｒＳｅｓｓｉｏｎの記述を参照されたい。
【００２５】
＜被管理オブジェクト＞
被管理オブジェクト（ＭＯ）（Ｍａｎａｇｅｄ  Ｏｂｊｅｃｔ）は、ネットワーク要素、メンテナンス・ユニット、またはデータ・リンクなどの、ＥＭＳによって管理することができる物理的、または論理的リソースの抽象的表現である。ＥＭサーバは、管理されるべき各タイプの物理的または論理的リソースに対して、１つのアプリケーション固有のサービス・オブジェクトを実装する。これらのサービス・オブジェクトは、それぞれ指定された被管理オブジェクトのインスタンス上で実行され得る動作以外に、被管理オブジェクトの性質を識別する一組の属性を定義する。（単独の「サービス・オブジェクト」を通じてインスタンスの情報に対するアクセスを定義するための決定は、現在のＯＲＢの実装が非常に多数の遠隔参照を管理している時に不安定になるという事実から来ている。）図７は、クライアント、アプリケーション固有のサービス・オブジェクトと、被管理オブジェクトのインスタンスの内部サーバ表現との間の関係を示している。
【００２６】
各被管理オブジェクトのサービス・クラスは、ＣｌａｓｓＣｏｄｅによってユニークに定義されている。各被管理オブジェクトのインスタンスは、ＩｎｓｔＩｄによってユニークに識別される。システム内の任意のオブジェクト・インスタンスを、ＣｌａｓｓＣｏｄｅおよびＩｎｓｔＩｄの組合せである被管理オブジェクト識別子（Ｏｉｄ）によってユニークに参照することができる。
【００２７】
被管理オブジェクトのステータス情報は、属性コード‐値のペアのシーケンスとしてサービス・オブジェクトによってレポートされる。各オブジェクトの値が、図６の中に記述されているインターフェース２６の基本データ・タイプのすべてのユニオンとして定義されている。
【００２８】
コンフィギュレーション情報は、ＣｏｎｆｉｇＤａｔａの構造のシーケンスとしてレポートされる。それらは次のものを含むように定義されている。
・  ネットワーク要素のインスタンスのｉｄ
・  被管理オブジェクトのインスタンスのｉｄ
・  属性値ペアのシーケンスとしてレポートされる被管理オブジェクトのキー・リスト‐‐長さが０より大きい時、そのキー・リストは関連付けられている論理識別子（ＬｏｇｉｃａｌＩｄｓ）を規定する。
【００２９】
各被管理オブジェクトのサービス・クラスは、次のコンフィギュレーションおよびステータス・サービスを定義するＭＯインターフェースを実装しなければならない。
・  ｖｉｅｗＣｏｎｆｉｇ
クライアントは、このメソッドを使って、指定されたネットワーク要素のインスタンスに対する、被管理オブジェクトのコンフィギュレーションの現在のＥＭＳビューを得る。予約済みのインスタンス識別子ＡｎｙＩｎｓｔａｎｃｅを使って、すべてのネットワーク要素に対するコンフィギュレーション情報が得られることに留意されたい。
【００３０】
・  ｎｏｔｉｆｙＣｏｎｆｉｇ
クライアントは被管理オブジェクトのコンフィギュレーション情報の初期ビューおよびコール・バック経由でのそれ以降での変化の通知に対して登録することもできる。初期ビューは通知のタイプＣＯＮＦＩＧ＿ＩＮＩＴで戻される。それ以降での変化はタイプＣＯＮＦＩＧ＿ＣＲＥＡＴＥまたはＣＯＮＦＩＧ＿ＤＥＬＥＴＥでレポートされる。
【００３１】
・  ｃａｎｃｅｌＮｏｔｉｆｙ
クライアントはこのメソッドを使って、指定されたクライアント・アプリケーションに関連付けられている被管理オブジェクトのコンフィギュレーション通知に対する登録を取り消す。
【００３２】
・ｇｅｔＰｅｒｓｉｓｔｅｎｔ
クライアントは、このメソッドを使って、このサービス・オブジェクトによってメンテナンスされているすべての「永続的な（ｐｅｒｓｉｓｔｅｎｔ）」データを識別している属性コードの集合（ＳｅｑＡｔｔｒＣｏｄｅ）を検索する。各被管理オブジェクトのインスタンスの永続性の属性に対する値が、どのクライアントの要求とも無関係に格納されて現在の状態に保たれている。
【００３３】
・  ｇｅｔＡｔｔｒＳｐｅｃ
クライアントはこのメソッドを使って、ターゲット・サービスのクラスに対して定義されているすべての属性の名前およびコードを検索することができる（現在はデバッギングのためだけに使われている）。
【００３４】
・  ｇｅｔＫｅｙＳｐｅｃ
クライアントはこのメソッドを使って、ターゲット・クラスの任意のインスタンスの論理的識別子を表す属性を識別しているコードの集合（ＳｅｑＡｔｔｒＣｏｄｅ）を検索することができる。
【００３５】
・  ｖｉｅｗＳｔａｔｕｓ
クライアントはこのメソッドを使って、指定された被管理オブジェクトのインスタンスに対して、指定された永続性の属性の組に対する現在値のＥＭＳビューを得ることができる。
【００３６】
・  ｇｅｔＳｔａｔｕｓ
クライアントはこのメソッドを使って、現在のステータス情報のスナップショットに対して登録することができる。このインターフェースは、要求される属性のリストが永続性のあるデータに関連付けられているものだけでなく、任意の被管理オブジェクトの属性コードを規定することができ、そしてその情報がクライアントのステータス・コール・バック（ＳｔａｔｕｓＣＢ）経由で返されることにおいて、前のものと異なっている。
【００３７】
・  ｓｔａｒｔＵｐｄａｔｅ
クライアントは、指定された被管理オブジェクトのインスタンスに対する選択された属性のリストに対して、初期ビューおよび任意の更新の通知に対して登録することもできる。この場合、初期ビューは通知のタイプＳＴＡＴＵＳ＿ＩＮＩＴによるクライアント・コール・バック経由でレポートされる。それ以降の変化はタイプＳＴＡＴＵＳ＿ＣＨＡＮＧＥでレポートされる。被管理オブジェクトのインスタンスの削除は、ネットワーク要素が装備されていない時にクライアントのステータス・コール・バックの混乱の可能性を回避するために、コンフィギュレーション変化通知を通じてのみレポートされる。
【００３８】
・  ｓｔｏｐＵｐｄａｔｅ
クライアントはこのメソッドを使って、指定されたクライアント・アプリケーションに関連付けられている被管理オブジェクトのステータス更新に対する登録を取り消す。
【００３９】
・  ｇｅｔＩｎｓｔ
クライアントは、このメソッドを使って、指定されたネットワーク要素のインスタンスのｉｄおよび被管理オブジェクトのキー・リストに対する被管理オブジェクトのインスタンスの識別子を得ることができる。
【００４０】
各メソッドはユーザのアクセスを検証するためにクライアントのセッション・アプリケーション識別子（ＳｅｓｓｉｏｎＡｐｐＩｄ）を必要とすることに留意されたい。コンフィギュレーションまたはステータス変化の通信の登録の場合、この識別子は、クライアント・アプリケーションがアクティブである間に利用される追加のサーバ・リソースの追跡管理のためにも使われる。
追加の詳細については、付録の中のインターフェースＭＯ、ＣｏｎｆｉｇＣＢおよびＳｔａｔｕｓＣＢの記述を参照されたい。
【００４１】
＜ネットワーク要素レベル被管理オブジェクト＞
各ネットワーク要素レベル被管理オブジェクトは、追加のネットワーク要素レベル・コンフィギュレーション・サービスを定義するＮＥＭＯインターフェースも実装しなければならない。
【００４２】
ｖｉｅｗＮＥｃｏｎｆｉｇ
クライアントはこのメソッドを呼び出して、そのネットワーク要素のコンフィギュレーションの現在のＥＭＳビューを得ることができる。
・  ｎｏｔｉｆｙＮＥｃｏｎｆｉｇ
クライアントはネットワーク要素レベル被管理オブジェクトのコンフィギュレーション情報の初期ビューおよびコール・バック経由でのそれ以降の変化の通知に対して登録することもできる。初期ビューは通知タイプＣＯＮＦＩＧ＿ＩＮＩＴによって返される。それ以降の変化はタイプＣＯＮＦＩＧ＿ＣＲＥＡＴＥまたはＣＯＮＦＩＧ＿ＤＥＬＥＴＥによってレポートされる。
【００４３】
・  ｃａｎｃｅｌＮＥｎｏｔｉｆｙ
クライアント・アプリケーションは、ネットワーク要素被管理オブジェクトのコンフィギュレーション更新に対する登録を取り消すために、このメソッドを使わなければならない。
・  ｇｅｔＮＥｉｎｓｔ
クライアントはこのメソッドを呼び出して、指定された論理ｉｄに関連付けられているネットワーク要素のＮＥＭＯインスタンス識別子を検索することができる。
【００４４】
・  ｇｅｔＬｏｇｉｃａｌＩｄ
クライアントはこのメソッドを呼び出して、指定されたＮＥＭＯインスタンスのｉｄに関連付けられているネットワーク要素の論理識別子を検索することができる。
・  ｇｅｔＣｏｎｔａｉｎｍｅｎｔ
クライアントはこのメソッドを呼び出して、ターゲットのＮＥＭＯに対する含入情報のシーケンスを得ることができる。ここで、そのシーケンスの中の各エントリは含まれているサービス・クラスのオブジェクトに対する名前、クラス・コードおよびＣＯＲＢＡの参照を含んでいる。
【００４５】
各メソッドは、ユーザのアクセスを検証するためにクライアント・セッションのアプリケーション識別子を必要とすることに留意されたい。コンフィギュレーション変化通知登録の場合、その識別子は、そのクライアント・アプリケーションがアクティブである間に利用される追加のサーバ・リソースを追跡管理するためにも使われる。
その他の詳細については、付録の中のインターフェースＮＥＭＯおよびＮＥｃｏｎｆｉｇＣＢの記述を参照されたい。
【００４６】
＜記述的エンティティのオブジェクト＞
このタイプのアプリケーション・オブジェクトは、たとえば、被管理オブジェクトの記述（たとえば、ＳＮＭＰのトラップ定義およびコマンド・グループ）の一部ではないＥＭＳとネットワーク要素との間で通信されるデータなどの抽象エンティティに対するタイプおよび属性の情報を提供するために定義されている。記述的エンティティのオブジェクトは、実装は提供しない。それらはアプリケーション固有のＩＤＬの中に定義されており、コンパイル時にクライアント・アプリケーションによって知られている。
【００４７】
＜イベント・ディストリビュータ＞
イベントは次のものの組合せとしてレポートされる。
１．  ヘッダ（最も一般的に必要な情報を含んでいる）
・  そのイベントの時刻
・  次のうちの１つであるとして定義されるイベントのカテゴリー
＊  アラームのセット
＊  アラームのクリア
＊  コマンドのアクノレッジメント
＊  コマンドの応答
＊  コンフィギュレーションの変化
＊  情報提供のメッセージ
＊  初期化
＊  状態変化
・  ネットワーク要素オブジェクト識別子
・  ネットワーク要素のアラーム・レベル‐‐アラームのセットに対してのみ意味がある
・  メンテナンス・ユニットのオブジェクト識別子（適用される場合）
・  メンテナンス・ユニットのアラーム・レベル‐‐アラームのセットに対してのみ意味がある
・  ユーザ・セッションｉｄおよびコマンド・シーケンス番号として定義されているコマンド識別子（ＣｍｄＩｄ）‐‐コマンドのアクノレッジメントおよび応答に対してのみ意味がある
【００４８】
１．  次のものを含んでいる構造のシーケンスとして定義されているイベントのデータ
・  被管理オブジェクト、ネットワーク要素または記述的エンティティのＣｌａｓｓＣｏｄｅ
・  属性コード値ペアのシーケンス
クライアント・アプリケーションは、イベント・ディストリビュータによって処理され、イベント・ヘッダの中で指定されている情報についてフィルタされたイベント・ストリームのコピーを要求することができる。フィルタのワイルドカードは「帯域外の」値を使って実装されている。
・  任意のカテゴリー
・  任意のクラス
・  任意のインスタンス
・  任意のアラーム
・  任意のコマンド
【００４９】
図８の中の表は、各イベント・カテゴリーに対してどのフィルタ基準が有効であるかを要約している。
イベント・ディストリビュータは、指定されたカテゴリーを調べて、有効な基準とＡＮＤを取ることによってフィルタを処理する。クライアントは、複数のフィルタを登録することによって、ＯＲ演算をシミュレートすることができる。
【００５０】
ＥｖｔＤｉｓｔのサービス・オブジェクトは、次のクライアント・インターフェースを実装している。
・  ＲｅｇｉｓｔｅｒＦｉｌｔｅｒ
クライアントは、このメソッドを使ってイベント・フィルタを登録する。フィルタの識別子が返される。
・  ＣａｎｃｅｌＦｉｌｔｅｒ
クライアントは、このメソッドを呼び出して、関連付けられている登録から返されるフィルタｉｄを使って、指定されたイベント・フィルタを取り除く。
【００５１】
各メソッドは、ユーザ・アクセスを検証するためにクライアント・セッションのアプリケーション識別子を必要とすることに留意されたい。
その他の詳細については付録の中のインターフェースＥｖｔＤｉｓｔおよびＥｖｅｎｔＣＢの記述を参照されたい。
【００５２】
＜アラーム・マネージャ＞
アラーム情報は次のものを含んでいるＡｌａｒｍＤａｔａ構造のシーケンスとしてレポートされる。
・  ネットワーク要素固有のアラーム・レコードを定義する被管理オブジェクトのＣｌａｓｓＣｏｄｅ。
ＥＭＳの最初のリリースにおいては、ネットワーク要素のアクティブ・アラームの１つの表（ＡｐＡｃｔｉｖｅＡｌａｒｍｓ）に定義されていることに留意されたい。
・  アラーム・レコードのシーケンス。各レコードがアラーム・インスタンス識別子および属性コード値のシーケンスのペアを含んでいる。
【００５３】
クライアント・アプリケーションは、次のものの任意の組合せについてフィルタされたすべてのアクティブ・アラームのコピーを要求することができる。
・  ネットワーク要素
・  メンテナンス・ユニット
・  アラーム・レベル
【００５４】
イベント・ディストリビュータによって提供されるインターフェースと同様に、帯域外の値を使ってワイルドカードを表すことができる。
被管理オブジェクトのインスタンスの情報は、アラームがレポートされる時点で利用できない可能性があるので、実際のアラーム・フィルタ基準は論理識別子の項で規定される。論理ｉｄは、デバイスおよびインターフェースの論理番号（たとえば、ＡＰ４）を表す整数値である。論理ｉｄと被管理オブジェクトのインスタンスの識別子との間の相関が、各被管理オブジェクトのサービス・オブジェクトによって提供されるコンフィギュレーション情報の中に提供され、そしてユーティリティ・メソッドｇｅｔＩｎｓｔを通じて提供される。詳細については、「被管理オブジェクト」のセッションを参照されたい。
【００５５】
次のＡｌａｒｍＭａｎａｇｅｒクライアント・インターフェースはアクティブ・アラーム・リストのアプリケーションのために特別に書かれている。
・  ＲｅｑｕｅｓｔＡｌａｒｍｓ
クライアントはこのメソッドを使ってアクティブなアラームに対するフィルタを登録する。
・  ＣｈａｎｇｅＦｉｌｔｅｒ
クライアントはこのメソッドを使ってフィルタの基準を変更することができる。
・  ＲｅｆｒｅｓｈＡｌａｒａｍｓ
【００５６】
クライアントはこのメソッドを呼び出して、そのアクティブ・アラーム・リストをリフレッシュすることができる。
・  ＣａｎｃｅｌＡｌａｒｍｓ
フィルタの登録を解除するためには、クライアントはこのメソッドを呼び出す必要がある。
登録解除を除いてすべての動作は指定された基準においてフィルタされているすべてのアクティブなアラームを返す。また、これらの各メソッドはユーザのアクセスを検証するために、そして各クライアントがアクティブである間に利用される可能性のある追加のサーバ・リソースについて追跡管理するために有効なクライアント・セッションのアプリケーション識別子を必要とする。
【００５７】
次のＡｌａｒｍＭａｎａｇｅｒインターフェースは、任意のクライアント・アプリケーション（たとえば、ＣＬＩ）から使うことができる。
・  ｏｐＡｌａｒｍ
コマンドのアクノレッジメントおよび応答を処理するために使われるイベントのコール・バックのクライアント実装を通じて（同じＥｖｅｎｔＣＢ参照を両方のケースにおいて使うことができる）、このメソッドはシステム内のアクティブなすべてのアラーム、またはターゲットのネットワーク要素に関連付けられているアラームだけのリストのいずれかを返す。
詳細については付録の中のインターフェースＡｌａｒｍＭａｎａｇｅｒ、ＡｌａｒｍＣＢおよびＥｖｅｎｔＣＢの記述を参照されたい。
【００５８】
＜例外＞
例外はＥＭサーバおよびクライアントの両方において首尾一貫した、そして構造化されたエラー処理のために使われる。
ＣＯＲＢＡの仕様は、次のような多くのシステム例外を定義している。
・  ＢＡＤ＿ＰＡＲＡＭ
・  ＩＮＶ＿ＯＢＪＲＥＦ
・  ＮＯ＿ＰＥＲＭＩＳＳＩＯＮ
・  ＢＡＤ＿ＯＰＥＲＡＴＩＯＮ
・  ＯＢＪ＿ＡＤＡＰＴＥＲ
・  ・・・
【００５９】
ニーモニックおよび関連している例外の記述の網羅されたリストについては、「Ｃｏｍｍｏｎ  Ｏｂｊｅｃｔ  Ｒｅｑｕｅｓｔ  Ｂｒｏｋｅｒ（共通オブジェクト要求ブローカ）：アーキテクチャおよび仕様」を参照されたい。
ベンダ固有のオブジェクト要求ブローカの例外も次のように定義されている（ＳｙｓｔｅｍＥｘｃｅｐｔｉｏｎのＭｉｎｏｒ識別子を使って）。
・  ＮＯ＿ＩＴ＿ＤＡＥＭＯＮ＿ＰＯＲＴ
・  ＬＩＣＥＮＣＥ＿ＥＸＰＩＲＥＤ
・  ・・・
【００６０】
現在、ＥＭＳはＩｏｎａのＯｒｂｉｘ製品を使っている。ニーモニックおよび関連している例外の記述の網羅されたリストについては、「Ｏｒｂｉｘ  ２．３ｃ  リファレンス・ガイド」を参照されたい。
ほとんどの場合において、例外はクライアントのコードによって致命的なエラーとして扱われ、アプリケーションが結果として終了する。
インターフェース２６固有の例外も、図９の中に示されている次の値のうちの１つを含んでいる例外コードとして定義されている。
【００６１】
付録Ａ
0004323644.tif 000002
0004323644.tif 000003
0004323644.tif 000004
0004323644.tif 000005
0004323644.tif 000006
0004323644.tif 000007
0004323644.tif 000008
0004323644.tif 000009
0004323644.tif 000010
0004323644.tif 000011
0004323644.tif 000012
0004323644.tif 000013
0004323644.tif 000014
0004323644.tif 000015
0004323644.tif 000016
0004323644.tif 000017
0004323644.tif 000018
0004323644.tif 000019
0004323644.tif 000020
0004323644.tif 000021
【００６２】
付録Ｂ‐用語集
アラーム
警報される通知の記述
属性
被管理オブジェクトの性質（たとえば、アラーム状態）
属性コード
与えられた被管理オブジェクトの属性をユニークに定義する整数値
クラス・コード
被管理オブジェクトのクラスをユニークに定義する整数値
コンフィギュレーション情報
その内容に依存して次の２つの意味のうちの１つを有する総称的な用語
被管理オブジェクトのクラスに関して、この用語は特定のネットワーク要素に対して、あるいはそのシステム内のすべてのネットワーク要素に対してのいずれかの、クラスのすべてのインスタンスの識別に適用される。
被管理オブジェクトのインスタンスに関して、この用語はデュープレックス・コンポーネントのプライマリ／オールタネートの役割などの、データベースの値に関連付けられている１つまたはそれ以上の属性に対して適用することができる。
ＣＯＲＢＡ
Ｃｏｍｍｏｎ  Ｏｂｊｅｃｔ  Ｒｅｑｕｅｓｔ  Ｂｒｏｋｅｒ  Ａｒｃｈｉｔｅｃｔｕｒｅ（共通オブジェクト要求ブローカのアーキテクチャ）
ＥＭＡＰＩ
Ｅｌｅｍｅｎｔ  Ｍａｎａｇｅｍｅｎｔ  Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ（要素管理のアプリケーション・プログラム・インターフェース）
ＥＭＳ
Ｅｌｅｍｅｎｔ  Ｍａｎａｇｅｍｅｎｔ  Ｓｙｓｔｅｍ（要素管理システム）
イベント
アラームの通知、コマンドのアクノレッジメントまたはコンフィギュレーションの変化などの自然発生的な事象の記述
インスタンス識別子
与えられた被管理オブジェクトのインスタンスをユニークに識別する整数値
インターフェース動作
分散型のサービス要求に対する総称的な用語。ターゲットのメソッド（たとえば、ステータス登録）を要素管理のアプリケーション・プログラミング・インターフェースにおいて、あるいは被管理オブジェクトのアプリケーション固有の派生物において（たとえば、コマンドの例外）定義することができる。
論理識別子
デバイスまたはインターフェースの論理的な番号（たとえば、ＡＰ４）を表す整数値。論理ｉｄとインスタンスのｉｄとの間には直接の相関はないことに留意されたい。
被管理オブジェクト
ＥＭＳによって管理することができる物理的または論理的なリソース（たとえば、ネットワーク要素、メンテナンスユニット、データ・リンク）の抽象表現。
ＯＲＢ
Ｏｂｊｅｃｔ  Ｒｅｑｕｅｓｔ  Ｂｒｏｋｅｒ（オブジェクト要求ブローカ）
オブジェクト識別子
システムの中の任意の被管理オブジェクトのインスタンスをユニークに定義する、被管理オブジェクトのクラス・コードとインスタンス識別子との組合せ。
永続的属性
どのクライアント要求とも無関係に、格納されていてカレントに保たれている情報（たとえば、メンテナンス状態）。
サービス・オブジェクト
クライアントのアプリケーションに対してサービスを提供する任意のＥＭサーバのオブジェクト。
セッション
各クライアントは初期化（それに対して１つのユニークなセッション識別子が割り当てられている）において１つのセッションを確立しなければならない。セッションは、アクセス許可を検証するために、クライアントの要求を相関付けるために、そしてそのセッションに関連付けられている任意のアプリケーションの代わりに利用されるサーバのリソースについて追跡管理するために使われる。
ステータス情報
被管理オブジェクトのインスタンスに対する現在の属性値。
【図面の簡単な説明】
【図１】本発明の好適なネットワーク要素制御方法を使っている管理システムの好適な実施形態の機能的ブロック図である。
【図２】図１の中で単独の機能的ブロックとして示されている変換用インターフェースの好適な実施形態の機能的ブロック図である。
【図３】図１のワークステーションにおけるオブジェクト指向の管理アプリケーションである被制御ネットワーク要素とのインターフェースを示している機能的ブロック図である。
【図４】図１のワークステーションにおいて実行されるクライアント管理アプリケーションと対話する複数のサービス・オブジェクトの表を示す図である。
【図５】図２の変換用インターフェースにおける実行される複数のコール・バック機能の表を示す図である。
【図６】本発明に従って図２の変換用インターフェースによって変換することができる異なる基本データ・タイプの表を示す図である。
【図７】クライアントのアプリケーション固有のサービス・オブジェクトと、被管理オブジェクトのインスタンスを表す内部的サービスとの間の関係を示しているブロック図である。
【図８】各イベントのカテゴリーに対して有効なフィルタ基準を要約している表を示す図である。
【図９】リストされている値のうちの１つを含んでいるＥＭＡＰＩの例外コードについての特定の例外を定義している表を示す図である。
【図１】
0004323644.tif 000022
【図２】
0004323644.tif 000023
【図３】
0004323644.tif 000024
【図４】
0004323644.tif 000025
【図５】
0004323644.tif 000026
【図６】
0004323644.tif 000027
【図７】
0004323644.tif 000028
【図８】
0004323644.tif 000029
【図９】
0004323644.tif 000030