(57)【要約】【課題】ＳＮＭＰ基盤のネットワーク管理装置および方法を提供する。【解決手段】コンパイル時に開発者がアプリケーションプログラムを介してＳＮＭＰインタフェースヘッダファイルを作成すると、抽出部が上記インタフェースヘッダファイルを基にＭＩＢファイルとＯＩＤＩｎｆｏを生成する。ランタイム時には、マネージャがＳＮＭＰを要請すると、エージェントが上記ＳＮＭＰ要請メッセージに含まれているＯＩＤＩｎｆｏをＯＩＤＩｎｆｏ処理部に転送し、上記ＯＩＤＩｎｆｏ処理部は、ＯＩＤＩｎｆｏ記憶部を参照してＧＭＳ情報を上記エージェントに渡す。上記エージェントは、上記ＧＭＳ情報を基にアプリケーションプログラムとＧＭＳの要請／応答過程を行う。【選択図】図５
2006146927.tif 000002
【特許請求の範囲】
【請求項１】
ＳＮＭＰを用いて通信装置を管理するために、コンパイル時に前記通信装置を管理するための管理情報ベース（ＭＩＢ）ファイルと、前記ＳＮＭＰエージェントとアプリケーションプログラム間での通信のためのオブジェクト識別子情報ファイルとを生成するための装置であって、
前記ＳＮＭＰ装置の管理のためにアプリケーションプログラムが作成したヘッダファイルを格納するヘッダファイル記憶部と、
前記ヘッダファイル記憶部から前記ヘッダファイルを読み込み、前記管理情報ベースファイルと、前記ＳＮＭＰエージェントと前記アプリケーションプログラムとのメッセージのやり取りのための前記オブジェクト識別子情報ファイルとを作成する抽出部と、
前記抽出部において作成した前記管理情報ベースファイルを格納する管理情報ベースファイル記憶部と、
前記抽出部において作成した前記オブジェクト識別子情報ファイルを格納するオブジェクト識別子情報記憶部と、
を備えることを特徴とするＳＮＭＰ管理装置。
【請求項２】
前記メッセージは、前記ＳＮＭＰエージェントと前記アプリケーションプログラム間での通信のためのＧＭＳメッセージであることを特徴とする請求項１に記載のＳＮＭＰ管理装置。
【請求項３】
ＳＮＭＰを用いて通信装置を管理するために、コンパイル時に前記通信装置を管理するための管理情報ベース（ＭＩＢ）ファイルと、前記ＳＮＭＰエージェントとアプリケーションプログラム間での通信のためのオブジェクト識別子情報ファイルとを生成するための方法であって、
変更された管理項目を取り込まれたアプリケーションプログラムがＳＮＭＰインタフェースヘッダファイルを作成するステップと、
前記作成されたＳＮＭＰインタフェースヘッダファイルを読み込み、管理情報ベースファイルとオブジェクト識別子情報ファイルを生成するステップと、
前記生成された管理情報ベースファイルと前記オブジェクト識別子情報ファイルを格納するステップと、
を含むことを特徴とするＳＮＭＰ管理方法。
【請求項４】
ＳＮＭＰを用いて通信装置を管理するマネージャから管理項目が含まれているＳＮＭＰ要請メッセージを受け取り、前記管理項目についての処理結果を応答するランタイム動作を行うための方法であって、
前記マネージャから、エージェントが、前記管理項目に関するデータを要請するＳＮＭＰ要請メッセージを受け取るステップと、
前記エージェントが、前記ＳＮＭＰ要請メッセージに含まれているオブジェクト識別子情報をオブジェクト識別子情報処理部に転送するステップと、
前記オブジェクト識別子情報処理部が、前記オブジェクト識別子情報を基に、前記エージェントと前記マネージャが要請した管理項目のデータが格納されているアプリケーションプログラム間での通信のための情報を前記エージェントに転送するステップと、
前記エージェントが、前記オブジェクト情報処理部から受け取った前記通信のための情報を基に前記アプリケーションプログラムとの通信を行い、前記アプリケーションプログラムから前記マネージャが要求した管理項目についての処理結果を受け取るステップと、
前記エージェントが、前記受け取った管理項目についての処理結果を前記マネージャに転送するステップと、
を含むことを特徴とするＳＮＭＰ管理方法。
【請求項５】
前記オブジェクト識別子情報処理部が前記通信のための情報を前記エージェントに転送するステップは、
前記オブジェクト識別子情報処理部が、オブジェクト識別子情報記憶部からの前記オブジェクト識別子情報に対応するオブジェクト識別子情報データファイルからＧＭＳ情報を検索するステップと、
前記オブジェクト識別子情報処理部が前記ＧＭＳ情報を前記エージェントに転送するステップと、を含むことを特徴とする請求項４に記載のＳＮＭＰ管理方法。
【請求項６】
前記ＧＭＳ情報は、前記エージェントが前記アプリケーションプログラムと通信を行うための前記アプリケーションプログラムのポート番号および通信形式、ペイロードのデータ構造のうち少なくともいずれかを含むことを特徴とする請求項５に記載のＳＮＭＰ管理方法。
【請求項７】
ＳＮＭＰを用いて通信装置を管理するマネージャから管理項目が含まれているＳＮＭＰ要請メッセージを受け取り、前記管理項目についての処理結果を応答するランタイム動作を行う前記通信装置のＳＮＭＰ管理装置であって、
前記管理項目が要求する動作を行うアプリケーションプログラムと、
前記管理項目に対応する所定のオブジェクト識別子情報を受け取った場合は、前記アプリケーションプログラムとの通信のための情報を提供するオブジェクト識別子情報処理手段と、
前記マネージャから前記ＳＮＭＰ要請メッセージを受け取った場合は、前記オブジェクト識別子情報処理手段に該管理項目に対応する前記オブジェクト識別子情報を渡して前記アプリケーションプログラムとの通信のための情報を取得し、前記アプリケーションプログラムから該管理項目についての処理結果を受け取って前記マネージャに転送するエージェントと、
を備えることを特徴とするＳＮＭＰ管理装置。
【請求項８】
前記オブジェクト識別子情報処理手段は、前記エージェントと前記アプリケーションプログラム間での通信のための情報を有するオブジェクト識別子データファイルが格納されているオブジェクト識別子記憶部と、
前記オブジェクト識別子情報記憶部の前記オブジェクト識別子データファイルから前記エージェントと前記アプリケーションプログラム間での通信のための情報を検索し、前記通信のための情報を前記エージェントに転送するオブジェクト識別子情報処理部と、を備えることを特徴とする請求項７に記載のＳＮＭＰ管理装置。
【請求項９】
前記エージェントと前記アプリケーションプログラム間での通信のための情報は、ＧＭＳ情報であることを特徴とする請求項７に記載のＳＮＭＰ管理装置。
【請求項１０】
前記ＧＭＳ情報は、前記エージェントが前記アプリケーションプログラムと通信を行うための前記アプリケーションプログラムのポート番号および通信形式、ペイロードデータ構造のうち少なくともいずれかを含むことを特徴とする請求項９に記載のＳＮＭＰ管理装置。
【請求項１１】
前記オブジェクト識別子情報記憶部は、オブジェクト識別子情報ライブラリーアプリケーションプログラムプログラミングインタフェースとオブジェクト識別子情報データファイルを格納することを特徴とする請求項８に記載のＳＮＭＰ管理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク装置を管理する装置および方法に係り、特に、シンプル・ネットワーク管理プロトコル（Simple Network Management Protocol；以下、ＳＮＭＰと称する。）を用いて通信装置を管理するためのネットワーク管理装置および方法に関する。
【背景技術】
【０００２】
ここ数年間、ネットワークの急速な成長と種々の異質なシステムの登場に伴い、ネットワークの統合的管理が難しくなってきている。加えて、ネットワークが大規模化するに伴い、多くの分野におけるネットワーク装置の管理が不可欠な要素となっている。
【０００３】
このため、ネットワーク管理者らは、種々なるネットワーク環境下において包括的な管理を行うことが可能なネットワークフレームワークを求めるに至っている。かかる要求に応え、世界最大のインターネット標準団体であるインターネット工学推進チーム（Internet Engineering Task Force；以下、ＩＥＴＦと称する。）においては、インターネット基盤のネットワーク装置を管理するための標準として、比較的単純なプロトコルであるＳＮＭＰを採択することになった。
【０００４】
通常、ＳＮＭＰを採用するシステムにおいては、管理システムをマネージャと呼び、管理の対象をエージェントと呼んでいる。上記マネージャとエージェントを結ぶ管理情報の伝送網は、ＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）方式に準拠するものであり、ＳＮＭＰを用いたマネージャとエージェントとの間における通信は、管理情報ベース（Management Information Base；以下、ＭＩＢと称する。）を基に、管理情報の検索、管理情報の連続検索、管理情報の書き換え、例外動作の通知などの命令を用いて行われる。
【０００５】
上記ＳＮＭＰエージェントは、管理の対象となる装置に存在するソフトウェアモジュールであって、ＭＩＢに関する情報を有しており、該情報をＳＮＭＰプロトコルを用いて上記ＳＮＭＰマネージャに渡す。
【０００６】
ＳＮＭＰを用いて管理する必要がある特定の情報、資源などをオブジェクトと呼び、これらのオブジェクトをまとめた集合体をＭＩＢと呼ぶ。このＭＩＢ形式は、ＳＮＭＰの一部として定義されており、各オブジェクトは、ＡＳＮ．１（Abstract Syntax Notation One）を用いて定義される。
【０００７】
上記ＳＮＭＰエージェントは、ネットワーク装置の機能に関するパラメータよりなるＭＩＢを管理する。上記ＳＮＭＰマネージャは、上記ＳＮＭＰエージェントが与えるＭＩＢから特定の値を取り込んで、当該装置の状態を把握するか、または該値を変更する。
【０００８】
上述した如く、通常、ＳＮＭＰを用いてのネットワークの管理とは、管理の対象となる装置が与えるＭＩＢから特定の値を取り込んで、当該装置の状態を把握するか、あるいは該値を変更することを意味する。
【０００９】
ＳＮＭＰによれば、管理方法が容易に実現でき、ＴＣＰ／ＩＰを用いる各種の装置が開発可能である。さらには、様々なＲＦＣ（Request For Comment）により管理範囲を容易に指定あるいは拡張でき、しかも、プロトコルの構成が簡単である。なお、現在、その実現の容易さから、数多くの管理プロトコルのうちＳＮＭＰが最も汎用されている。
【００１０】
図１は、通常の構成を有するＳＮＭＰにおけるマネージャ１００とＳＮＭＰエージェント１０２間での制御動作を説明するための図である。
【００１１】
先ず、同図に示すように、マネージャ１００とＳＮＭＰエージェント１０２との間でやり取りされるコマンドについて説明する。
【００１２】
−ＧｅｔＲｅｑｕｅｓｔ：オブジェクト値を読み込むための要請信号
−ＧｅｔＮｅｘｔＲｅｑｕｅｓｔ：現オブジェクトの次のオブジェクト値を読み込むための要請信号
−ＧｅｔＲｅｓｐｏｎｓｅ：要請に対する応答信号
−ＳｅｔＲｅｑｕｅｓｔ：オブジェクト値を書き込むための信号
−Ｔｒａｐ：例外状況の通知
【００１３】
図１におけるマネージャ１００とＳＮＭＰエージェント１０２は、上述したメッセージを用いて互いに通信を行う。
【００１４】
以下、図２および図３に基づき、従来の技術によるエージェントの作成方法およびアプリケーションプログラムとのインタフェース方法について説明する。
【００１５】
図２は、従来の技術によるＳＮＭＰエージェント１０２の作成方法を示すフローチャートである。
【００１６】
ステップ２００において、ネットワークマネージャは、ＳＮＭＰエージェント１０２を作成するためにＭＩＢを定義し、これに該当するアプリケーションプログラムとインタフェースに用いられる構造を定義する。
【００１７】
ステップ２００において定義されたＭＩＢを基に、ステップ２０２においてＭＩＢファイルを生成する。ステップ２０４において、ネットワークマネージャは、生成されたＭＩＢファイルをコード化およびコンパイルしてＳＮＭＰエージェント１０２を生成する。
【００１８】
ステップ２０６において、ネットワークマネージャは、ＭＩＢあるいはインタフェースに対する修正事項の有無をチェックし、修正事項がある場合は、ステップ２０８に進んで管理項目を定義する。
【００１９】
ステップ２０８において定義された管理項目を基に、ステップ２１０において、ネットワークマネージャがＭＩＢファイルを生成し、ステップ２１２において、生成されたＭＩＢファイルを基にＳＮＭＰエージェント１０２を再コード化および再コンパイルする。
【００２０】
図３は、従来の技術によるマネージャ１００とアプリケーションプログラム３０４との間のインタフェース方法を示す図である。
【００２１】
マネージャ１００のアプリケーションプログラム３０４とのインタフェースのためには、それぞれの構造に関する情報と目的地に関する情報をＳＮＭＰエージェント１０２が知っている必要がある。そして、通常のＳＮＭＰエージェント１０２の作成ツールを用いた場合、管理項目に該当するオブジェクト３０２が、各アプリケーションプログラム３０４において用いられる構造を用いてそれぞれ実現しなければならない。
【００２２】
また、通常のＳＮＭＰエージェント１０２の作成方法においては、装備の特性が反映できるようにＭＩＢについての設計が行われ、ＭＩＢに設計された内容に基づいてＳＮＭＰエージェント１０２の作成範囲、装置内において管理機能を行うアプリケーションプログラム３０４の役割、ＳＮＭＰエージェント１０２とアプリケーションプログラム３０４との間のインタフェース方法などが決められる。
【００２３】
現在、ＳＮＭＰプロトコルを効率よく開発するために一般のツールを用いているが、このようなツールを用いてのＳＮＭＰエージェント１０２の作成は、ＳＮＭＰエージェント１０２がデータを有している場合は容易に行い得るものの、アプリケーションプログラム３０４とのインタフェースによりＭＩＢオブジェクト値を取得する場合、各ＭＩＢオブジェクトごとに異なる構造を用いるため、ＳＮＭＰエージェント１０２の作成が困難であり、且つ、複雑になる。
【００２４】
また、マネージャ１００は、ＳＮＭＰエージェント１０２を介して装置内の他のアプリケーションプログラム３０４が管理する管理項目にアクセスする。この管理項目はＭＩＢで表され、各装置の特性によって異なる。このようなＭＩＢを作成の当初に完璧に定義することは、事実上不可能に近い。
【００２５】
従来の技術は、このようなＭＩＢを基にＳＮＭＰエージェント１０２が開発されるため、各装置ごとに相異なるＳＮＭＰエージェント１０２を作成する必要がある。また、同じ装置内においても管理すべき項目の変更、追加、削除が随時行われる可能性があり、この際、ＳＮＭＰエージェント１０２の修正が不可避になる。
【００２６】
上記の如き環境下において、ＭＩＢが変更、追加、削除される都度、ＳＮＭＰエージェント１０２をさらに修正して再コンパイルすることは、開発を行う上で多くの手間を取っていた。
【発明の開示】
【発明が解決しようとする課題】
【００２７】
そこで、本発明は、上記の問題点を解決するためになされたものであって、その目的は、ネットワーク管理システムにおいて、ＭＩＢファイルとオブジェクト識別子情報ファイルをリアルタイムにて生成するＳＮＭＰ基盤のネットワーク管理装置および方法を提供することにある。
【００２８】
本発明の他の目的は、ネットワーク管理システムを構成するネットワークにおける変動事項に合わせて上記装置の動作を制御するためのＳＮＭＰ基盤のネットワーク管理装置および方法を提供することにある。
【００２９】
本発明のまた他の目的は、ネットワーク管理システムを構成する装置を標準方式に準拠して動作させるためのＳＮＭＰ基盤のネットワーク管理装置および方法を提供することにある。
【課題を解決するための手段】
【００３０】
本発明に係る、ＳＮＭＰを用いて通信装置を管理するために、コンパイル時に上記通信装置を管理するためのＭＩＢファイルと、上記ＳＮＭＰエージェントとアプリケーションプログラム間での通信のためのオブジェクト識別子情報ファイルとを生成するための装置は、上記ＳＮＭＰ装置の管理のためにアプリケーションプログラムが作成したヘッダファイルを格納するヘッダファイル記憶部と、上記ヘッダファイル記憶部から上記ヘッダファイルを読み込み、上記ＭＩＢファイルと、上記ＳＮＭＰエージェントと上記アプリケーションプログラム間でのメッセージのやり取りのための上記オブジェクト識別子情報ファイルとを作成する抽出部と、上記抽出部において作成した上記ＭＩＢファイルを格納するＭＩＢファイル記憶部と、上記抽出部において作成した上記オブジェクト識別子情報ファイルを格納するオブジェクト識別子情報記憶部と、を備える。
【００３１】
本発明に係る、ＳＮＭＰを用いて通信装置を管理するために、コンパイル時に上記通信装置を管理するためのＭＩＢファイルと、上記ＳＮＭＰエージェントとアプリケーションプログラム間での通信のためのオブジェクト識別子情報ファイルとを生成するための方法は、変更された管理項目を受け取ったアプリケーションプログラムがＳＮＭＰインタフェースヘッダファイルを作成するステップと、上記作成されたＳＮＭＰインタフェースヘッダファイルを読み込んで、ＭＩＢファイルとオブジェクト識別子情報ファイルを生成するステップと、上記生成されたＭＩＢファイルと上記オブジェクト識別子情報ファイルを格納するステップと、を含む。
【００３２】
本発明に係る、ＳＮＭＰを用いて通信装置を管理するマネージャから管理項目が含まれているＳＮＭＰ要請メッセージを受け取り、上記管理項目についての処理結果を応答するランタイム動作を行うための方法は、上記マネージャから、エージェントが、上記管理項目に関するデータを要請するＳＮＭＰ要請メッセージを受け取るステップと、上記エージェントが、上記ＳＮＭＰ要請メッセージに含まれているオブジェクト識別子情報をオブジェクト識別子情報処理部に転送するステップと、上記オブジェクト識別子情報処理部が、上記オブジェクト識別子情報を基に、上記エージェントと上記マネージャが要請した管理項目のデータが格納されているアプリケーションプログラム間での通信のための情報を上記エージェントに転送するステップと、上記エージェントが、上記オブジェクト情報処理部から受け取った上記通信のための情報を基に上記アプリケーションプログラムとの通信を行い、上記アプリケーションプログラムから上記マネージャが要求した管理項目についての処理結果を受け取るステップと、上記エージェントが、上記受け取った管理項目についての処理結果を上記マネージャに転送するステップと、を含む。
【００３３】
本発明に係る、ＳＮＭＰを用いて通信装置を管理するマネージャから管理項目が含まれている ＳＮＭＰ要請メッセージを受け取り、上記管理項目についての処理結果を応答するランタイム動作を行う上記通信装置のＳＮＭＰ管理装置は、上記管理項目が要求する動作を行うアプリケーションプログラムと、上記管理項目に対応する所定のオブジェクト識別子情報を受け取った場合は、上記アプリケーションプログラムとの通信のための情報を提供するオブジェクト識別子情報処理手段と、上記マネージャから上記ＳＮＭＰ要請メッセージを受け取った場合は、上記オブジェクト識別子情報処理手段に該管理項目に対応する上記オブジェクト識別子情報を渡して上記アプリケーションプログラムとの通信のための情報を取得し、上記アプリケーションプログラムから該管理項目についての処理結果を受け取って上記マネージャに転送するエージェントと、を備える。
【発明の効果】
【００３４】
本発明によれば、管理の対象が変わったり、管理項目が追加、変更、削除された場合であっても、抽出部において新たなオブジェクト識別子情報ファイルを生成するだけで、ＳＮＭＰエージェントは、機能の追加や新たなコード化、再コンパイルの必要がない。また、ＳＮＭＰエージェントとアプリケーションプログラムに用いられるストラクチャが追加、変更、削除されても、管理項目となるＭＩＢの変更とオブジェクト識別子情報ファイルの変更が自動的に行われる。この結果、ＳＮＭＰエージェントの開発が容易になり、且つ種々なる装置や管理の対象にＳＮＭＰエージェントをそのまま用いることができる。
【発明を実施するための最良の形態】
【００３５】
以下、添付図面に基づき、本発明の実施の形態について詳述する。なお、下記の説明および添付図面において、本発明の要旨を不明確にする公知の技術および構成についての詳細な説明は省略する。
【００３６】
本発明において、ＳＮＭＰエージェントは、図４に示すように大きく４要素から構成される。
【００３７】
図４は、本発明に係るＳＮＭＰエージェント１０２のブロック構成図である。ＳＮＭＰエージェント１０２は、ネットワークエレメントにおいてＳＮＭＰを支援する機能を果たす。
【００３８】
ＳＮＭＰエージェント１０２は、ＳＮＭＰメッセージを処理しアプリケーションプログラムとのインタフェースを司るエージェント４００と、アプリケーションプログラムとエージェント４００間での通信を行うのに要されるＧＭＳ（General Message Service）メッセージを作成するための情報を有しているライブラリーに対応するオブジェクト識別子情報（Object Identifier Information；以下、ＯＩＤＩｎｆｏと称する。）を処理するＯＩＤＩｎｆｏ処理部４０２とを備える。
【００３９】
ＳＮＭＰエージェント１０２は、さらに、ＧＭＳメッセージとＭＩＢを作成するための情報をＯＩＤＩｎｆｏ記憶部（図示せず）に渡す抽出部４０４と、アプリケーションプログラムとの通信のために用いられるＳＮＭＰインタフェースヘッダファイルとアプリケーションプログラム５０４が管理すべき情報およびＧＭＳ情報を格納するヘッダファイル記憶部４０６とを備える。
【００４０】
ＯＩＤＩｎｆｏ処理部では、大きく２種類の機能を果たす。その一つは、エージェント４００から管理項目に関するＯＩＤＩｎｆｏが入力されると、それに対する応答として、エージェント４００とアプリケーションプログラム５０４との間での通信のための情報に対応するＧＭＳ情報をＯＩＤＩｎｆｏデータファイルが格納されているＯＩＤＩｎｆｏ記憶部５００から検索し、該情報をエージェント４００に与える。ここで、上記通信のための情報としては、エージェント４００がアプリケーションプログラム５０４と通信するためのポート番号およびメッセージフォーマット、通信形式、ペイロード構造などが挙げられる。ここで、本発明の実施の形態においては、エージェント４００とアプリケーションプログラム５０４とのインタフェースをＧＭＳであると想定しているが、これに限定されることなく、他のインタフェースであっても良い。
【００４１】
図５は、図４に示すＳＮＭＰエージェントのブロック構成図および本発明のコンパイル時間とランタイム時間を含む全体の動作フローを示す図である。
【００４２】
図５を参照すると、先ず、エージェント４００は、マネージャ１００と共にＳＮＭＰプロトコルの処理を司り、また実際に管理項目を維持・管理するアプリケーションプログラムとの通信の際にＧＭＳメッセージをやり取りする。そして、ネットワークマネージャが、マネージャ１００を介してＳＮＭＰエージェント１０２が動作しているネットワーク装置の管理項目を要請するために所定の各種のフォーマットのＰＤＵ（Protocol Data Unit）が含まれているＳＮＭＰ要請メッセージをエージェント４００に送ると、このエージェント４００は、受け取ったＳＮＭＰ要請メッセージに含まれている管理項目に対応するＯＩＤＩｎｆｏをＯＩＤＩｎｆｏ処理部４０２に転送する。すると、ＯＩＤＩｎｆｏ処理部４０２は、アプリケーションプログラム５０４との通信を行うためのポート番号およびフォーマット情報、ペイロード構造が含まれている情報に対応するＧＭＳ情報を送り返す。エージェント４００は、上記ＧＭＳ情報を用いてアプリケーションプログラム５０４と通信を行い、アプリケーションプログラム５０４から上記管理項目についての処理結果を受け取り、該処理結果をＳＮＭＰ応答メッセージとしてマネージャ１００に転送する。
【００４３】
２番目に、エージェント４００がアプリケーションプログラム５０４から案内（Notification）（トラップ）メッセージを受け取ると、ＯＩＤＩｎｆｏ処理部４０２からＯＩＤＩｎｆｏを取得してマネージャ１００にトラップＰＤＵを送る役割を果たす。
【００４４】
ＯＩＤＩｎｆｏ処理部４０２は、管理項目にアクセスするために、アプリケーションプログラム５０４とのメッセージのやり取りに必要な情報を格納しているＯＩＤＩｎｆｏファイルをＯＩＤＩｎｆｏ記憶部５００から読み込み、該ＯＩＤＩｎｆｏファイルを検索してＧＭＳ情報を取り出し、該ＧＭＳ情報をエージェント４００に渡す。ＯＩＤＩｎｆｏ記憶部５００は、ＯＩＤＩｎｆｏライブラリーアプリケーションプログラムプログラミングインタフェース（Application Programming Interfaces；以下、ＡＰＩと称する。）とＯＩＤＩｎｆｏデータファイルを格納している。また、これらのＯＩＤＩｎｆｏライブラリーＡＰＩとＯＩＤＩｎｆｏデータファイルは、抽出部４０４から与えられる。
【００４５】
抽出部４０４は、アプリケーションプログラム５０４が管理項目として定義したＳＮＭＰインタフェースヘッダファイル５０６からＭＩＢファイルを生成し、ＯＩＤＩｎｆｏ処理部４０２において必要とするＯＩＤＩｎｆｏファイルを生成して、ＯＩＤＩｎｆｏ記憶部５００に格納する役割を果たす。
【００４６】
ＳＮＭＰインタフェースヘッダファイル５０６は、エージェント４００がアプリケーションプログラム５０４において管理している情報を取得するのに必要な情報、例えば、メッセージＩＤ、ポート番号、メッセージ構造などが定義されているファイルであり、各アプリケーションプログラム５０４において定義されヘッダファイル記憶部４０６に格納される。
【００４７】
以下、図６および図７を用いてＳＮＭＰエージェント１０２におけるコンパイル時に行われる動作について説明する。
【００４８】
また、抽出部４０４において、アプリケーションプログラム５０４に渡されるＧＭＳメッセージに関する情報を有しているＯＩＤＩｎｆｏデータファイルを作成するための基本構造と、この構造を用いたＯＩＤＩｎｆｏデータの生成プロセスについて説明する。
【００４９】
上述した如き方法を用いて、抽出部４０４は、ヘッダファイル記憶部４０６からデータを生成し、エージェント４００は、ＯＩＤＩｎｆｏファイルをＯＩＤＩｎｆｏ処理部４０２に転送し、このＯＩＤＩｎｆｏ処理部４０２は、ＯＩＤＩｎｆｏファイルに関するＧＭＳ情報をエージェント４００に送る。ＧＭＳ情報を受け取ったエージェント４００は、ＧＭＳ情報を用いて応用プログラムと通信を行う。
【００５０】
以下、図６を参照してＳＮＭＰエージェント１０２におけるコンパイル動作について詳述する。図６は、コンパイルに際し、ＳＮＭＰエージェント１０２の抽出部４０４がデータファイルを生成するプロセスを示す図である。
【００５１】
先ず、ＳＮＭＰエージェント１０２の開発者は、アプリケーションプログラム５０４を介して管理すべき情報などを定義したＳＮＭＰインタフェースヘッダファイル５０６をヘッダファイル記憶部４０６に定義する。そして、抽出部４０４は、上記管理すべき情報を有しているヘッダファイル記憶部４０６からＳＮＭＰインタフェースヘッダファイル５０６を読み込み、管理項目が定義されているＭＩＢファイルを作成してＭＩＢファイル記憶部５０２に格納する。さらに、抽出部４０４は、ヘッダファイル記憶部４０６からＳＮＭＰインタフェースヘッダファイル５０６を読み込み、ＧＭＳメッセージを生成するためのＯＩＤＩｎｆｏデータファイルを作成してＯＩＤＩｎｆｏ記憶部４０２に格納する。
【００５２】
図７は、本発明の実施の形態による、コンパイル時におけるＳＮＭＰエージェント１０２内の動作を示すフローチャートである。
【００５３】
図７を参照すると、ステップ７００において、開発者からＳＮＭＰエージェント１０２における管理項目の変更が求められた場合、ステップ７０２に進み、開発者からの入力情報を基に、アプリケーションプログラム５０４は、変更された管理項目に基づいてＳＮＭＰインタフェースヘッダファイル５０６を作成し、該ファイル５０６をヘッダファイル記憶部４０６に格納する。
【００５４】
ステップ７０４において、抽出部４０４は、ＳＮＭＰインタフェースヘッダファイルを読み込んでＭＩＢとＯＩＤＩｎｆｏデータファイルを作成する。このステップ７０４において作成されたＭＩＢとＯＩＤＩｎｆｏファイルは、ステップ７０６においてそれぞれＭＩＢファイル記憶部５０２とＯＩＤＩｎｆｏ記憶部５００に格納される。
【００５５】
図８は、ランタイム時におけるＳＮＭＰエージェントが図６中のコンパイル時に生成されたＯＩＤＩｎｆｏデータファイルを用いて行う所定のプロセスを示す。
【００５６】
図８におけるエージェント４００とアプリケーションプログラム５０４間での通信は、ＧＭＳ（あるいは、オブジェクト指向メッセージサービス）インタフェースを用いて行われる。また、ＧＭＳメッセージのペイロード１００９には、エージェント４００とアプリケーションプログラム５０４間でのＳＮＭＰ通信を支援するためのメッセージの形式とメッセージのペイロードにおいて繰り返されるストラクチャの数を示すＥＭインタフェースヘッダ１００２が存在し、以下、これについて詳述する。
【００５７】
先ず、マネージャ１００がエージェント４００に対してＳＮＭＰ要請メッセージを転送すると、エージェント４００は、該ＳＮＭＰ要請メッセージ内のＯＩＤＩｎｆｏをＯＩＤＩｎｆｏ処理部４０２に転送する。これは、エージェント４００がアプリケーションプログラム５０４と通信を行うためには、ＧＭＳ情報が必要になるためである。
【００５８】
ＯＩＤＩｎｆｏ処理部４０２は、受け取ったＯＩＤＩｎｆｏを基にＯＩＤＩｎｆｏ処理部５００からＧＭＳ情報を読み込んでエージェント４００に転送する。すると、エージェント４００は、ＧＭＳ情報を基にアプリケーションプログラム５０４と通信を行い、アプリケーションプログラム５０４からの応答結果を基に、マネージャ１００にＳＮＭＰの要請に対する応答を行う。
【００５９】
以下、図９を参照し、ＳＮＭＰエージェント１０２の内部ブロックのランタイム時における動作について説明する。
【００６０】
図９は、本発明の実施の形態によるランタイム時におけるＳＮＭＰエージェント１０２内の動作を示すフローチャートである。
【００６１】
ステップ９００において、エージェント４００は、マネージャ１００からＳＮＭＰ要請があったかどうかをチェックする。この結果、マネージャ１００からのＳＮＭＰ要請があった場合、ステップ９０２に進み、エージェント４００は、マネージャ１００から受け取ったＳＮＭＰ要請メッセージに含まれているＯＩＤＩｎｆｏをＯＩＤＩｎｆｏ処理部４０２に渡す。
【００６２】
ステップ９０４において、ＯＩＤＩｎｆｏ処理部４０２は、受け取ったＯＩＤＩｎｆｏを基に、該当するＧＭＳ情報をＯＩＤＩｎｆｏ記憶部５００から読み込んでエージェント４００に渡す。ここで、ＧＭＳ情報には、エージェント４００がアプリケーションプログラム５０４と通信を行うのに必要なアプリケーションプログラム５０４のポート番号、通信形式、データ構造などが含まれる。
【００６３】
ステップ９０６において、ＧＭＳ情報を受け取ったエージェント４００は、ＧＭＳ情報を基に、アプリケーションプログラム５０４に対してマネージャ１００から要求のあった管理項目に関するデータを要求する。ステップ９０８において、アプリケーションプログラム５０４は、エージェント４００に管理項目に関するデータをＧＭＳ応答メッセージとして転送する。
【００６４】
ステップ９１０において、エージェント４００は、アプリケーションプログラム５０４が応答した管理項目に関するデータを基に、マネージャ１００にＳＮＭＰ応答メッセージを転送する。
【００６５】
図１０は、エージェント４００とアプリケーションプログラム５０４間での通信のためのＧＭＳ ＰＤＵの構成を示す図である。ＧＭＳヘッダ１０００は、ＳＮＭＰを用いる全てのソフトウェアと通信を行うのに必要なフィールドである。ＧＭＳペイロード１００９には、エージェント４００とアプリケーションプログラム５０４間でのＳＮＭＰ通信を支援するための特別なヘッダファイルであるＥＭインタフェースヘッダ１００２が含まれている。このＥＭインタフェースヘッダ１００２は、４つのフィールド（図１１に基づいて後述する）からなり、エージェント４００とアプリケーションプログラム４０４間でのＳＮＭＰ通信を支援するために用いられる。ペイロード構造１００４は、ＳＮＭＰ通信時に必要なペイロードのフィールド値である。
【００６６】
図１１ないし図１４は、エージェント４００とアプリケーションプログラム５０４間でのメッセージの形式によるＰＤＵメッセージの構成および構成フィールドを説明するための図であって、以下、これらについて詳述する。
【００６７】
先ず、説明に先立ち、各フィールドの構成および役割について簡略に触れておく。
【００６８】
ＧＭＳヘッダ１０００と、ＥＭインタフェースヘッダ１００２、およびストラクチャ１００４を１つの列１０１４とする。
【００６９】
ＥＭインタフェースヘッダ１００２は、上述した通り、４フィールドからなり、この詳細については後述する。先ず、ｍｓｇＴｙｐｅ１００９は、エージェント１０２とアプリケーションプログラム５０４間でのメッセージの形式を示し、ｒｏｗＣｏｕｎｔ１００８は、マルチ・ロウ・テーブルを支援するテーブルに対してＧｅｔ、Ｓｅｔ、Ｇｅｔ−Ｎｅｘｔを行うときにペイロードにおいて繰り返されるストラクチャ１００４の数を示す。また、全てのテーブルに対してＧｅｔ−Ｂｕｌｋを行うとき、ＳＮＭＰ Ｇｅｔ−Ｂｕｌｋの最大の繰り返し値と同じ用途にて用いられる。ｒｅｓｐｏｎｓｅ（０）１０１０は、発生可能なエラーを渡すのに用いられ、ｓｔｒｕｃｔＩｄ１０１２は、アプリケーションプログラム５０４の内部においてさらに用いるメッセージのＩＤを示す。また、ＰＬＤ（Programable Loading Data）のためには、Ｒｅｌａｔｉｏｎ ＩＤとして用いる。
【００７０】
さらに、エージェント４００がアプリケーションプログラム５０４から受け取ったｒｅｓｐｏｎｓｅ（０）１０１０を正常に動作させるために、アプリケーションプログラム５０４は、エージェント４００から受け取ったＧＭＳメッセージのヘッダからｔｒａｎｓａｃｔｉｏｎＩｄ１０１６とｎｅｌｄ（ｂｓｍＩｄ）１０１８をコピーして応答メッセージを作成した後、該応答メッセージをエージェント４００に渡す。
【００７１】
図１１は、エージェント４００がＧｅｔ／ＧｅｔＮｅｘｔ／ＧｅｔＦｉｒｓｔ Ｒｅｑｕｅｓｔのメッセージをアプリケーションプログラム５０４に転送する場合における、その手続きとその応答に関する動作を示す図である。
【００７２】
エージェント４００が一つの列に該当するメモリを割り当て、マネージャ１００から受け取ったインデックス値をＧＭＳペイロード１００９に入れた後、アプリケーションプログラム５０４に渡す。
【００７３】
アプリケーションプログラム５０４は、該当するテーブルにおいてエージェント４００から受け取ったインデックスに該当する列をメモリにコピーし、エージェント４００に応答を送る。このとき、ＭｓｇＩｄは、予めストラクチャを定義したときのＲｅｓｐｏｎｓｅＩｄとして設定する。もし、失敗したときは、ＥＭインタフェースヘッダ１００２のｒｅｓｐｏｎｓｅ（０）１０１０に該当するエラー値を入れて渡す。このとき、ＧＭＳペイロード１００９をそのまま送り返す。
【００７４】
ＧｅｔＮｅｘｔＲｅｑｕｅｓｔである場合は、該当する列の次の列を検索して渡せば良い。
【００７５】
図１２は、エージェント４００がＰｒｅＳｅｔ／ＳｅｔＲｅｑｕｅｓｔのメッセージをアプリケーションプログラム５０４に転送する場合における、その手続きとその応答に関する動作を示す図である。
【００７６】
先ず、ＳｅｔＲｅｑｕｓｅｔメッセージは、エージェント４００がアプリケーションプログラム５０４にＰｒｅＳｅｔＲｅｑｕｓｅｔメッセージを送るが、ＰｒｅＳｅｔＲｅｑｕｅｓｔは、ＧｅｔＲｅｑｕｓｅｔと同じ動作を行い、ＰｒｅｓｅｔＲｅｑｕｅｓｔを受け取ったアプリケーションプログラム５０４は該当列を固定させる。アプリケーションプログラム５０４からＰｒｅＳｅｔＲｅｑｕｅｓｔの応答を受け取ったエージェント４００は、ＳｅｔＲｅｑｕｅｓｔを行うアトリビュートの値を入れ替えてから、アプケーション５０４にＳｅｔＲｅｑｕｅｓｔを送り返す。
【００７７】
アプリケーションプログラム５０４から正常的な応答を受け取ると、エージェント４００は、マネージャ１００にＳｅｔメッセージに対する応答を送る。もし、アプリケーションプログラム５０４から失敗した旨（Ｆａｉｌ）を受け取った場合、エージェント４００もマネージャ１００に失敗した旨を通知し、所定の応答時間を超えれば、エージェント４００がこのＳｅｔパケットを廃棄する。
【００７８】
ＳｅｔＲｅｑｕｅｓｔである場合は、エージェント４００が要請するＧＭＳペイロード１００９には、列に該当するメモリが割り当てられて渡されるが、アプリケーションプログラムが応答を送るときは、ＥＭインタフェースヘッダ１００２のみを送る。
【００７９】
図１３は、エージェント４００が多数のオブジェクト値を読み込むためのＧｅｔＢｕｌｋＲｅｑｕｅｓｔメッセージをアプリケーションプログラム５０４に転送する場合における、その手続きとその応答に関する動作を示す図である。
【００８０】
ＧｅｔＢｕｌｋＲｅｑｕｅｓｔである場合、該当列からＥＭインタフェースヘッダ１００２のｒｏｗＣｏｕｎｔＭａｘｒｅｐｅａｔ１００８の数字分をメモリに生成して渡し、もし、ｒｏｗＣｏｕｎｔが“０”であれば、テーブル全体を渡す。
【００８１】
また、ｒｏｗＣｏｕｎｔ１００８が“３”で、エージェント４００からアプリケーションプログラム５０４に要請があった場合は、要請するＧＭＳのペイロード１００９は、開始を示すインデックスを送るために一つの列に該当するメモリだけが割り当てられる。アプリケーションプログラム５０４は、このメモリを削除し該当するｒｏｗＣｏｕｎｔ１００８の数字分のメモリを割り当て、情報をコピーしてエージェント４００に送る。このメモリについては、エージェント４００が削除する。
【００８２】
図１４は、エージェント４００がＮｏｔｉｆｉｃａｔｉｏｎＴｒａｐメッセージをアプリケーションプログラム５０４に転送する場合における、その手続きとその応答に関する動作を示す図である。
【００８３】
ノティフィケーションを処理するためには、所定のストラクチャが定義されている必要があり、固有なＭｅｓｓａｇｅＩｄを有する。アプリケーションプログラム５０４は、ＥＭインタフェースヘッダ１００２のｍｓｇＴｙｐｅをＥＭ＿ＮＯＴＩＦＩＣＡＴＩＯＮに設定し、所定のＭｓｇＩｄ１４００の値を埋めた後、ペイロードにストラクチャを埋めてエージェント４００に渡す。
【００８４】
以下、ＯＩＤＩｎｆｏ記憶部５００に格納されるＯＩＤＩｎｆｏデータファイルについて説明する。
【００８５】
図１５ａと図１５ｂは、ＯＩＤＩｎｆｏデータファイルをオブジェクト識別子記憶部５００の図示しないメモリにマッピングした様子を概略的に示す図である。
【００８６】
図１５ａは、ＯＩＤＩｎｆｏファイルを構成する項目を概略的に示す図であり、各項目について、図１５ｂに基づいて説明する。
【００８７】
図１５ｂは、図１５ａ中の各項目を構成する情報を示すテーブルである。
【００８８】
先ず、ＯＩＤＩｎｆｏヘッダ１５００は、ＯＩＤＩｎｆｏの最も基礎的な情報を格納するペイロードのデータ構造である。このストラクチャは、ＯＩＤＩｎｆｏのバージョンと生成日付、デフォルトで処理するオブジェクト識別子、そしてオブジェクト識別子ツリーの各ノードを示すストラクチャであるオブジェクト識別子ツリー情報１５０２の最上位ノードを示すオフセット値と、メッセージＩＤを用いてノティフィケーションの情報を検索するのに用いられるＮｏｔｉＩｎｆｏＨｄｒ１５０８を示すオフセット値を含んでいる。
【００８９】
ＯＩＤＩｎｆｏＨｄｒ１５００を構成する各フィールドについての詳細は、下記表１の通りである
【００９０】
【表１】
2006146927.tif 000003
【００９１】
次いで、オブジェクト識別子ツリー情報１５０２は、ツリーのノード情報を有しており、ツリーの検索のために用いられる。オブジェクト識別子ツリー情報１５０２は、グループについての表現はもとより、スカラーオブジェクトからテーブルオブジェクトまでがオブジェクト識別子ツリー情報１５０２の一つのノードにて表される。このストラクチャは、ＭＩＢのオブジェクト識別子を示すＯｂｊｅｃｔＩＤと、ノードの形式、および４つのオフセットとからなる。
【００９２】
ＯｂｊｅｃｔＩＤは、オブジェクト識別子全体を示すのではなく、ＭＩＢにおける現在ノードのオブジェクト識別子を示す。ノードの形式は、現在のノードがグループオブジェクトを示すか、スカラーオブジェクトを示すか、それともテーブルオブジェクトを示すかを区別するのに用いられる。そして、オブジェクト識別子ツリー情報に含まれているオフセットは、上位オブジェクト識別子ツリー情報を示すオフセットと、ＧＭＳ情報とストラクチャに関する情報を有しているＧＭＳＩｎｆｏを示すオフセットとからなる。
【００９３】
オブジェクト識別子ツリー情報１５０２を構成している各フィールドについての説明は、下記表２の通りである。
【００９４】
【表２】
2006146927.tif 000004
【００９５】
ＧＭＳ情報１５０４は、アプリケーションプログラム５０４にメッセージを渡すためのＧＭＳヘッダ情報とペイロード情報を含んでいる。このストラクチャは、ストラクチャの形式に応じてその意味が異なるフィールドと、共通的に用いられるフィールドとに分けられる。簡単に述べると、オブジェクト識別子は、このストラクチャを用いて生成されたＭＩＢテーブルあるいはスカラーを含むグループに該当するオブジェクト識別子を示し、共通するｄｅｆａｕｌｔ  ＯＩＤ（ｅｎｔｅｒｐｒｉｓｅ ＯＩＤ）を含んでいる。ｓｔｒｕｃｔｎａｍｅは、ストラクチャを定義するときに作成した名前を示す。ストラクチャの形式は、６種の相異なるストラクチャの形式を示すのに用いられ、ｐａｙｌｏａｄＴｙｐｅは、このストラクチャを用いて多数の列をＳｅｔ、Ｇｅｔ、Ｇｅｔ−Ｎｅｘｔできるかどうかを示すフィールドである。
【００９６】
ｒｅｑｕｅｓｔＭｓｇＩｄ、ｒｅｓｐｏｎｓｅＭｓｇＩｄ、ｐｏｒｔＮｕｍｂｅｒは、ＧＭＳヘッダ情報を示し、ｎｕｍｂｅｒＯｆＩｎｄｅｘは、ストラクチャのインデックスの数を示す。ｎｕｍｂｅｒＯｆＦｉｅｌｄは、ＭＩＢのテーブルのアトリビュートの数ではなく、ストラクチャのフィールドの総数を示し、ｐａｙｌｏａｄＳｉｚｅは、ＧＭＳペイロードのサイズを計算するためのストラクチャの全サイズを示す。ｐｌｄＲｅｌａｔｉｏｎＩｄは、ＰＬＤのリレーションＩＤを示し、ｍａｓｔｅｒＴａｂｌｅＯｆｆｓｅｔは、ｓｔｒｕｃＴｙｐｅがサブテーブルである場合におけるマスタテーブルを示すオフセットである。ｎｅｘｔＧＭＳＩｎｆｏＯｆｆｓｅｔは、以降の使用に備えて残しておいたフィールドであり、今は、特に用途が定められていない。最後に、ｆｉｒｓｔＧＭＳＡｔｔＩｎｆｏＯｆｆｓｅｔは、ストラクチャの各フィールドの情報を示すＧＭＳアトリビュート情報の第一番目を示すオフセットである。
【００９７】
ＧＭＳ情報１５０４の各フィールドは、ストラクチャの形式によって異なる用途として用いられ、ｒｅｑｕｅｓｔＭｓｇＩＤ、ｒｅｓｐｏｎｓｅＭｓｇＩｄ、ｐｏｒｔＮｕｍｂｅｒは、ＧＭＳヘッダ情報として共通して用いられ、ｎｅｘｔＧＭＳＩｎｆｏＯｆｆｓｅｔとｆｉｒｓｔＧＭＳＡｔｔＩｎｆｏＯｆｆｓｅｔも全てのストラクチャの形式において同用途にて用いられる。次いで、下記表３において、ストラクチャの形式についての説明とストラクチャの形式によって異なる各フィールドの用途を説明する。
【００９８】
【表３】
2006146927.tif 000005
【００９９】
以下、ストラクチャの形式によるＧＭＳ情報１５０４の各フィールドの用途について説明する。
【０１００】
先ず、ストラクチャの形式がスカラーである場合における、ＧＭＳ情報１５０４の各フィールドの用途を下記表４に基づいて説明する。
【０１０１】
【表４】
2006146927.tif 000006
2006146927.tif 000007
【０１０２】
次いで、ストラクチャの形式が静的テーブルである場合における、ＧＭＳ情報１５０４の各フィールドの用途を下記表５に基づいて説明する。
【０１０３】
【表５】
2006146927.tif 000008
2006146927.tif 000009
【０１０４】
次いで、ストラクチャの形式がエージェント動的テーブルである場合における、ＧＭＳ情報１５０４の各フィールドの用途を下記表６に基づいて説明する。
【０１０５】
【表６】
2006146927.tif 000010
2006146927.tif 000011
【０１０６】
次いで、ストラクチャの形式がアプリケーションプログラム動的テーブルである場合における、ＧＭＳ情報１５０４の各フィールドの用途を下記表７に基づいて説明する。
【０１０７】
【表７】
2006146927.tif 000012
2006146927.tif 000013
【０１０８】
次いで、ストラクチャの形式がＰＬＤである場合における、ＧＭＳ情報１５０４の各フィールドの用途を下記表８に基づいて説明する。
【０１０９】
【表８】
2006146927.tif 000014
2006146927.tif 000015
【０１１０】
次いで、ストラクチャの形式がサブテーブルである場合、ＧＭＳ情報１５０４の各フィールドの用途を下記表９に基づいて説明する。
【０１１１】
【表９】
2006146927.tif 000016
2006146927.tif 000017
【０１１２】
ペイロードに入る各フィールドに関する情報は、ｆｉｒｓｔＧＭＳＡｔｔＩｎｆｏＯｆｆｓｅｔが示すＧＭＳアトリビュート情報を順番に検索していけば取得可能である。
【０１１３】
以上、ＧＭＳ情報１５０４に関する各フィールドとストラクチャの構造について説明したが、以下では、ＧＭＳアトリビュート情報１５０６のストラクチャについて説明する。ＧＭＳアトリビュート情報１５０６は、ＧＭＳのペイロードに入るストラクチャの各フィールドの情報を示すストラクチャである。ストラクチャの各フィールドを示すＧＭＳアトリビュート情報１５０６は、オフセットにより互いに接続されており、最後のＧＭＳアトリビュート情報のオフセット値は“０”である。
【０１１４】
ＧＭＳアトリビュート情報１５０６の順番において、インデックスを示すＧＭＳアトリビュート情報が最初に現れ、もし、このストラクチャが配列を含んでいる場合は、配列を示すＧＭＳアトリビュート情報が最後に現れる。
【０１１５】
インデックスは、オブジェクト識別子の順に整列されており、値もオブジェクト識別子の順に整列されている。ＧＭＳアトリビュート情報は、ＧＭＳ情報のストラクチャの形式とＧＭＳアトリビュート情報のフィールドの形式によって各フィールドの意味が異なる。先ず、ＧＭＳアトリビュート情報の形式を決めるフィールドの形式について説明したあと、フィールドの形式によって異なる各フィールドの用途を下記表１０に基づいて説明する。
【０１１６】
【表１０】
2006146927.tif 000018
【０１１７】
ストラクチャの形式がサブテーブルではなく、フィールドの形式がスカラー値、テーブル値、テーブルとインデックスである場合における、ＧＭＳアトリビュート情報１５０６の各フィールドを下記表１１に示す。
【０１１８】
【表１１】
2006146927.tif 000019
【０１１９】
ストラクチャの形式がサブテーブルではなく、フィールドの形式がテーブルとアレイである場合における、ＧＭＳアトリビュート情報１５０６の各フィールドを下記表１２に示す。
【０１２０】
【表１２】
2006146927.tif 000020
【０１２１】
ストラクチャの形式がサブテーブルではなく、フィールドの形式がアレイとインデックスである場合における、ＧＭＳアトリビュート情報１５０６のそれぞれのフィールドを下記表１３に示す。
【０１２２】
【表１３】
2006146927.tif 000021
【０１２３】
ストラクチャの形式がサブテーブルではなく、フィールドの形式がｔａｂｌｅｖａｌｕｅである場合における、ＧＭＳアトリビュート情報１５０６の各フィールドを下記表１４に示す。
【０１２４】
【表１４】
2006146927.tif 000022
【０１２５】
図１５Ａおよび図１５Ｂに示すノティフィケーションヘッダ１５０８は、メッセージＩＤを用いてノティフィケーション情報を取得するために、ＯＩＤＩｎｆｏ処理部４０２の内部において用いるストラクチャである。ノティフィケーション情報を検索する方法としては、２つのメッセージＩＤを用いて検索する方法と、一つのメッセージＩＤを用いて検索する方法の２通りがある。
【０１２６】
ノティフィケーションヘッダ１５０８は、ノティフィケーションノード情報１５１０の数を示すフィールドと、ノティフィケーションノード情報１５１０の第１番目を示すオフセットとからなる。各フィールドについての説明を、下記表１５に示す。
【０１２７】
【表１５】
2006146927.tif 000023
【０１２８】
図１５に示すノティフィケーションノード情報１５１０は、メッセージＩＤを格納するフィールドと、ノティフィケーションノード情報の形式を区分するｎｏｔｉＮｏｄｅＴｙｐｅと、サブノティフィケーション情報ヘッダを示すＳｕｂＮｏｔｉＩｎｆｏＨｄｒＯｆｆｓｅｔと、ノティフィケーション情報を有しているノティフィケーション情報１５１２を示すｎｏｔｉＩｎｆｏＯｆｆｓｅｔとからなる。
【０１２９】
ノティフィケーションノード情報１５１０は、メッセージＩＤを用いて該当するノティフィケーション情報を検索するのに用いるストラクチャである。ノティフィケーションノード情報１５１０は、ＯＩＤＩｎｆｏデータファイル記憶部５００にメッセージＩＤの順に整列されている。ＯＩＤＩｎｆｏ処理部４０２は、ノティフィケーションノード情報１５１０とノティフィケーション情報ヘッダ１５０８を用いて該当するノティフィケーション情報を検索することができる。
【０１３０】
最初に、一つのメッセージＩＤが一つのノティフィケーション情報とマッピングされている場合、ノティフィケーション情報ヘッダのｎｕｍｂｅｒＯｆＮｏｔｉＮｏｄｅＩｎｆｏとｆｉｒｓｔＮｏｔｉＩｎｆｏＯｆｆｓｅｔを用いてバイナリ検索アルゴリズムを行う。これにより、該当するノティフィケーションノード情報１５１０を検索する。これは、ノティフィケーションノード情報１５１０１がメッセージＩＤの順に整列されているために可能である。
【０１３１】
ノティフィケーションノード情報１５１０のｎｏｔｉＩｎｆｏＯｆｆｓｅｔが示すノティフィケーション情報１５１２情報を用いてＳＮＭＰノティフィケーションメッセージを作成する。
【０１３２】
第二に、２つのメッセージＩＤが一つのノティフィケーション情報とマッピングされている場合、同場合と同じ方法にてノティフィケーションノード情報１５１０を検索する。このノティフィケーションノード情報１５１０のｎｏｔｉＮｏｄｅＴｙｐｅは、マルチノティフィケーションノードであり、ＳｕｂＮｏｔｉＩｎｆｏＨｄｒＯｆｆｓｅｔは、サブノティフィケーション情報ヘッダ１５０８を示す。
【０１３３】
次いで、第２のメッセージＩＤを用いて同じアルゴリズムを繰り返し行う。これにより、該当するノティフィケーションノード情報１５１０を検索する。ノティフィケーションノード情報１５１０のｎｏｔｉｉｎｆｏＯｆｆｓｅｔが示すノティフィケーション情報を用いてＳＮＭＰノティフィケーションメッセージを作成する。
【０１３４】
上述した各フィールドについての説明を、下記表１６に示す。
【０１３５】
【表１６】
2006146927.tif 000024
【０１３６】
次いで、ノティフィケーション情報１５１２について説明する。ノティフィケーション情報１５１２は、ノティフィケーションの形式を区分するｎｏｔｉＩｎｆｏＴｙｐｅと、ＳＮＭＰインタフェースヘッダファイルに定義されたノティフィケーションストラクチャのフィールド数を示すｎｕｍｂｅｒＯｆＮｏｔｉＦｉｅｌｄと、メッセージフィールド情報の第１番目のオフセットとからなる。
【０１３７】
先ず、ｎｏｔｉＩｎｆｏＴｙｐｅについての説明を、下記表１７に示す。
【０１３８】
【表１７】
2006146927.tif 000025
【０１３９】
ノティフィケーション情報１５１２を構成する各フィールドについての説明を、下記表１８に示す。
【０１４０】
【表１８】
2006146927.tif 000026
【０１４１】
次いで、最後のストラクチャとしてのノティフィケーションアトリビュート情報１５１４について説明する。ノティフィケーションアトリビュート情報１５１４は、ノティフィケーションメッセージの各フィールドに関する情報を示す。先ず、ｎｏｔｉＡｔｔＯＩＤは、各ノティフィケーションを送るフィールドのオブジェクト識別子を示す文字列であって、スカラーはｆｕｌｌ  ＯＩＤを示し、テーブルに対してはインデックスが除かれた値を示す。ｎｏｔｉＡｔｔＮａｍｅは、ＳＮＭＰインタフェースヘッダファイルに定義されたフィールドの名前を文字列で示し、ｎｏｔｉＡＳＮＴｙｐｅは、このアトリビュートがＭＩＢにおいて表現されるシンタックスの形式を示す。ｎｏｔｉＦｉｅｌｄＴｙｐｅは、このアトリビュートがどの形式であるかを決め、この形式によって他のフィールドの使用用途もやや変わる。ｎｏｔｉＡｔｔＴｙｐｅは、このフィールドのＣデータ形式を示し、ｎｏｔｉＡｔｔＳｉｚｅは、このフィールドのサイズを示す。ｎｏｔｉＳｔａｒｔＯｆｆＳｅｔは、アプリケーションプログラムから受け取ったストラクチャにおいてこのフィールドが位置するオフセット値であり、ｓｕｂＮｏｔｉＡｔｔＩｎｆｏＯｆｆｓｅｔは、もし現在のフィールドが配列を示す場合、配列を表すノティフィケーション情報を示すオフセット値である。ｎｏｔｉＭａｘＤｉｍｅｎｓｉｏｎＶａｌｕｅは、配列の使用によって拡張されたＮｏｔｉＡｔｔＩｎｆｏにおける形式がアレイとインデックスである場合における、このインデックスの最大値を示し、これは、配列の最大値を意味する。最後に、ｎｅｘｔＮｏｔｉＡｔｔＩｎｆｏＯｆｆｓｅｔは、次のノティフィケーション情報１５１４を示すオフセット値である。ノティフィケーション情報１５１４が入っている順番は、インデックスが前方に位置する。もし、多数のテーブルからなるノティフィケーションであれば、テーブル単位でインデックスの次に値が位置し、次のインデックス、値が位置する。
【０１４２】
ノティフィケーション情報１５１４のｎｏｔｉＦｉｅｌｄＴｙｐｅによって各フィールドが意味する内容が異なるが、これについては、下記表を参照する。先ず、ノティフィケーションフィールドの形式がスカラー値である場合は、下記表１９の通りである。
【０１４３】
【表１９】
2006146927.tif 000027
次いで、ノティフィケーションフィールドの形式がテーブルとインデックスである場合は、下記表２０を参照する。
【０１４４】
【表２０】
2006146927.tif 000028
【０１４５】
ノティフィケーションフィールドの形式がテーブル値である場合は、下記表２１を参照する。
【０１４６】
【表２１】
2006146927.tif 000029
【０１４７】
ノティフィケーションフィールドの形式がテーブルとアレイである場合は、下記表２２を参照する。
【０１４８】
【表２２】
2006146927.tif 000030
【０１４９】
次いで、ノティフィケーションアトリビュート情報１５１４のｓｕｂＮｏｔｉＡｔｔＩｎｆｏＯｆｆｓｅｔが示すノティフィケーションアトリビュート情報のノティフィケーションフィールドの形式がアレイとインデックスである場合は、下記表２３を参照する。
【０１５０】
【表２３】
2006146927.tif 000031
【０１５１】
ノティフィケーション情報１５１４のｓｕｂＮｏｔｉＡｔｔＩｎｆｏＯｆｆｓｅｔが示すのティフィケーション情報のティフィケーションフィールドの形式がテーブル値である場合は、下記表２４を参照する。
【０１５２】
【表２４】
2006146927.tif 000032
【０１５３】
図１６は、ＯＩＤＩｎｆｏ記憶部５００の構造を概略的に示す図であり、オブジェクト識別子を用いてツリーを検索するための部分と、メッセージＩＤを用いてノティフィケーション情報を取得するための部分とに大別できる。ＭＩＢにおいて表される一つのテーブルは、一つのＧＭＳ情報とマッピングされる。スカラーの場合は、同じグループの下にあるものを束ねて一つのＧＭＳ情報とマッピングする。スカラーの場合、グループの下にあるものは、一つのストラクチャとして定義され、インデックスが存在しないストラクチャであるということを意味する。
【０１５４】
以下、本発明の実施の形態に係る、エージェント４００とアプリケーションプログラム５０４間での通信を行うためにＧＭＳ情報を検索する方法について、図１７を参照して説明する。
【０１５５】
図１７は、本発明の実施の形態に係るＧＭＳ情報を検索する方法を示す図である。マネージャ１００からＳＮＭＰのＧｅｔ、Ｇｅｔ−Ｎｅｘｔ、Ｇｅｔ−Ｂｕｌｋ、Ｓｅｔなどの要請を受けた場合、Ｇｅｔ、Ｇｅｔ−Ｎｅｘｔ、Ｇｅｔ−Ｂｕｌｋ、Ｓｅｔメッセージに含まれているオブジェクト識別子を用いて該当するＧＭＳ情報を検索するために、ＯＩＤＩｎｆｏ処理部４０２は、次の手続きを行う。
【０１５６】
先ず、エージェント４００から受け取ったオブジェクト識別子文字列を整数型のオブジェクトＩＤに分離し、変更する。その後、オブジェクトＩＤを基に、ツリー検索アルゴリズムを用いて順次にオブジェクト識別子ツリー情報１５０２を検索していく。
【０１５７】
すると、ＯＩＤＩｎｆｏ記憶部５００は、オブジェクト識別子と一致するオブジェクト識別子ツリー情報１５０２を送り返したり、オブジェクト識別子と一致するオブジェクト識別子ツリー情報１５０２の次のオブジェクト識別子ツリー情報を送り返す。もし、該当するオブジェクト識別子ツリー情報を検索すると、ＯＩＤＩｎｆｏ処理部４０２は、このオブジェクト識別子ツリー情報が示すＧＭＳ情報１５０４をエージェント４００に送り返す。そして、エージェント４００は、ＧＭＳ情報１５０４にある情報を用いてＧＭＳヘッダとペイロードを生成する。ＧＭＳペイロード１００９を生成するとき、ペイロードの前にはＯＡＭヘッダが入り、その次にエージェント４００とアプリケーションプログラム５０４間でのＳＮＭＰを支援するためのＥＭヘッダ１００２が入り、その次にストラクチャの値が入る。また、ストラクチャのフィールドに関する情報は、ＧＭＳアトリビュート情報１５０６を用いてＧＭＳ ＰＤＵを完成してから、アプリケーションプログラム５０４にメッセージを渡す。
【０１５８】
本発明の実施の形態に係る、エージェント４００がノティフィケーション情報を検索する方法について、図１８を参照して説明する。
【０１５９】
図１８は、本発明の実施の形態に係るエージェント４００がアプリケーションプログラムからトラップメッセージを受け取るときにおける、ノティフィケーション情報を検索する方法を示す図である。
【０１６０】
エージェント４００がアプリケーションプログラム５０４から所定のメッセージＩＤとしてトラップメッセージを受け取ると、ＯＩＤＩｎｆｏ処理部４０２がメッセージＩＤを用いてＳＮＭＰノティフィケーション情報を検索する過程である。
【０１６１】
先ず、エージェント４００は、受け取ったメッセージＩＤの数が一つであるか、それとも２つであるかをチェックする。エージェント４００は、ＥＭヘッダ１００２のｓｕｂＭｓｇＩｄフィールドをチェックし、この値が０でなければ、ＧＭＳヘッダ１０００にあるメッセージＩＤを最初のメッセージＩＤとして、ｓｕｂＭｓｇＩｄを２番目のメッセージＩＤとして用いる。
【０１６２】
その後、最初のメッセージＩＤを用いてノティフィケーションノード情報１５１０を検索する。検索方法は、ノティフィケーション情報ヘッダ１５０８のノティフィケーションノード情報１５１０の数とバイナリ検索アルゴリズムを用いてノティフィケーションノード情報１５１０を検索し、もし、上記２番目のメッセージを有する場合、ノティフィケーションノード情報１５１０のＳｕｂＮｏｔｉＩｎｆｏＨｄｒＯｆｆｓｅｔが示すノティフィケーション情報ヘッダ１５０８のサブノティフィケーションノード情報の数とバイナリ検索アルゴリズムを用いてノティフィケーションノード情報１５１０を検索する。
【０１６３】
ノティフィケーションノード情報１５１０のｎｏｔｉＩｎｆｏＯｆｆｓｅｔは、ノティフィケーション情報を格納しているノティフィケーション情報１５１２を示しており、ノティフィケーション情報１５１２とノティフィケーションアトリビュート情報１５１４を用いてＳＮＭＰノティフィケーションメッセージを作成し、マネージャ１００に送る。
【図面の簡単な説明】
【０１６４】
【図１】通常の構成を有するＳＮＭＰマネージャとＳＮＭＰエージェント間での制御動作を説明するための図。
【図２】従来の技術によるＳＮＭＰエージェントの開発方法のフローチャート。
【図３】従来の技術による上記マネージャとアプリケーションプログラムとのインタフェース方法を示す図。
【図４】本発明によるＳＮＭＰエージェントのブロック構成図。
【図５】図４におけるＳＮＭＰエージェントのブロック構成図および本発明のコンパイル時間とラン時間を含む全体の動作フローを示す図。
【図６】同ＳＮＭＰエージェントのコンパイル動作の遂行方式を示す図。
【図７】本発明の実施の形態によるコンパイル時におけるＳＮＭＰエージェント内の動作を示すフローチャート。
【図８】同ＳＮＭＰエージェントがランタイム時に図６のコンパイル時に生成されたＯＩＤＩｎｆｏを用いてＳＮＭＰ応答を行う過程を示す図。
【図９】本発明の実施の形態によるランタイム時におけるＳＮＭＰエージェント内の動作フローチャート。
【図１０】エージェントとアプリケーションプログラム間での通信のためのＧＭＳ ＰＤＵの構成を示す図。
【図１１】同エージェントがＧｅｔ、ＧｅｔＮｅｘｔ、ＧｅｔＦｉｒｓｔメッセージを上記アプリケーションプログラムに転送する場合における、その手続きとその応答に関する動作を示す図。
【図１２】同エージェントがＰｒｅＳｅｔ、Ｓｅｔメッセージを同アプリケーションプログラムに転送する場合における、その手続きとその応答に関する動作を示す図。
【図１３】同エージェントがＧｅｔＢｕｌｋメッセージを同アプリケーションプログラムに転送する場合における、その手続きとその応答に関する動作を示す図。
【図１４】同エージェントがノティフィケーショントラップメッセージを同アプリケーションプログラムに転送する場合における、その手続きとその応答に関する動作を示す図。
【図１５ａ】同ＯＩＤＩｎｆｏファイルを構成する項目を概略的に示す図。
【図１５ｂ】上記Ａにおける各項目を構成する情報を示すテーブル。
【図１６】ＯＩＤＩｎｆｏ記憶部の構造を概略的に示す図。
【図１７】本発明の実施の形態によるＯＩＤＩｎｆｏ処理部がＧＭＳ情報を検索する方法を示す図。
【図１８】本発明の実施の形態によるエージェントがアプリケーションプログラムからトラップメッセージを受け取るときおける、ノティフィケーション情報を検索する方法を示す図。
【符号の説明】
【０１６５】
１０２  ＳＮＭＰエージェント
４００  エージェント
４０２  ＯＩＤＩｎｆｏ処理部４０５
４０４  抽出部
４０６  ヘッダファイル
５０４  アプリケーションプログラム
【図１】
2006146927.tif 000033
【図２】
2006146927.tif 000034
【図３】
2006146927.tif 000035
【図４】
2006146927.tif 000036
【図５】
2006146927.tif 000037
【図６】
2006146927.tif 000038
【図７】
2006146927.tif 000039
【図８】
2006146927.tif 000040
【図９】
2006146927.tif 000041
【図１０】
2006146927.tif 000042
【図１１】
2006146927.tif 000043
【図１２】
2006146927.tif 000044
【図１３】
2006146927.tif 000045
【図１４】
2006146927.tif 000046
【図１５ａ】
2006146927.tif 000047
【図１５ｂ】
2006146927.tif 000048
【図１６】
2006146927.tif 000049
【図１７】
2006146927.tif 000050
【図１８】
2006146927.tif 000051
【外国語明細書】
2006146927.tif 000052
2006146927.tif 000053
2006146927.tif 000054
2006146927.tif 000055
2006146927.tif 000056
2006146927.tif 000057
2006146927.tif 000058
2006146927.tif 000059
2006146927.tif 000060
2006146927.tif 000061
2006146927.tif 000062
2006146927.tif 000063
2006146927.tif 000064
2006146927.tif 000065
2006146927.tif 000066
2006146927.tif 000067
2006146927.tif 000068
2006146927.tif 000069
2006146927.tif 000070
2006146927.tif 000071
2006146927.tif 000072
2006146927.tif 000073
2006146927.tif 000074
2006146927.tif 000075
2006146927.tif 000076
2006146927.tif 000077
2006146927.tif 000078
2006146927.tif 000079
2006146927.tif 000080
2006146927.tif 000081
2006146927.tif 000082
2006146927.tif 000083
2006146927.tif 000084
2006146927.tif 000085
2006146927.tif 000086
2006146927.tif 000087
2006146927.tif 000088
2006146927.tif 000089
2006146927.tif 000090
2006146927.tif 000091
2006146927.tif 000092
2006146927.tif 000093
2006146927.tif 000094
2006146927.tif 000095
2006146927.tif 000096
2006146927.tif 000097
2006146927.tif 000098
2006146927.tif 000099
2006146927.tif 000100
2006146927.tif 000101
2006146927.tif 000102
2006146927.tif 000103
2006146927.tif 000104
2006146927.tif 000105
2006146927.tif 000106
2006146927.tif 000107
2006146927.tif 000108
2006146927.tif 000109
2006146927.tif 000110
2006146927.tif 000111
2006146927.tif 000112
2006146927.tif 000113
2006146927.tif 000114
2006146927.tif 000115
2006146927.tif 000116
2006146927.tif 000117
2006146927.tif 000118
2006146927.tif 000119
2006146927.tif 000120
2006146927.tif 000121