JP2000090027A - オブジェクト管理システム、情報処理システム、オブジェクト管理プログラムを記録した記録媒体及び情報処理プログラムを記録した記録媒体 - Google Patents

オブジェクト管理システム、情報処理システム、オブジェクト管理プログラムを記録した記録媒体及び情報処理プログラムを記録した記録媒体

Info

Publication number
JP2000090027A
JP2000090027A JP10256366A JP25636698A JP2000090027A JP 2000090027 A JP2000090027 A JP 2000090027A JP 10256366 A JP10256366 A JP 10256366A JP 25636698 A JP25636698 A JP 25636698A JP 2000090027 A JP2000090027 A JP 2000090027A
Authority
JP
Japan
Prior art keywords
tree
management
information
resource management
managed
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP10256366A
Other languages
English (en)
Inventor
Hiroaki Komine
浩昭 小峰
Noriyuki Yogoshi
紀之 余越
Kazuaki Ikeda
和章 池田
Takeshi Naka
剛 中
Toshiharu Nakamura
俊晴 中村
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP10256366A priority Critical patent/JP2000090027A/ja
Priority to US09/334,172 priority patent/US6760733B1/en
Publication of JP2000090027A publication Critical patent/JP2000090027A/ja
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02—Standardisation; Integration
    • H04L41/0233—Object-oriented techniques, for representation of network management data, e.g. common object request broker architecture [CORBA]
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99941—Database schema or data structure
    • Y10S707/99943—Generating database or data structure, e.g. via user interface

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Computer And Data Communications (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

(57)【要約】 【課題】 クライアントアプリケーションに影響を与え
ることなくリソース管理オブジェクト（ＲＭ）間の関係
の変更を可能とする。 【解決手段】 メッセージ処理手段１１０は、クライア
ントアプリケーション１１、１２からＲＭ５１〜５６に
対して出力される操作要求を受け付ける。ツリー管理手
段１２０は、ＲＭ５１〜５６を特定するための識別情報
及びＲＭ５１〜５６間の包含関係が定義されたツリー情
報を管理する。オブジェクト管理手段１３０は、ツリー
情報を参照することで、ＲＭ間の包含関係を包含木１３
１として認識する。そして、メッセージ処理手段１１０
が受け取った操作要求を送信すべきＲＭの識別情報を包
含木１３１から判断し、該当するＲＭに対して操作要求
を出力する。これにより、ツリー情報を一カ所で管理す
ることができ、ＲＭの追加や削除が容易となる。

Description

【発明の詳細な説明】
【０００１】
【発明の属する技術分野】本発明はオブジェクト管理シ
ステム、情報処理システム、オブジェクト管理プログラ
ムを記録した記録媒体及び情報処理プログラムを記録し
た記録媒体に関し、特にネットワークシステムを構成す
る各オブジェクト間の関係を階層的な包含木構造によっ
て管理するオブジェクト管理システム、階層構造を有す
るオブジェクトによりシステムを動作させる情報処理シ
ステム、ネットワークシステムを構成する各オブジェク
ト間の関係を階層的な包含木構造によって管理する処理
をコンピュータに行わせるためのオブジェクト管理プロ
グラムを記録した記録媒体、及び階層構造を有するオブ
ジェクトによりシステムを動作させるための管理をコン
ピュータに行わせるための情報処理プログラムを記録し
た記録媒体に関する。
【０００２】
【従来の技術】複数のネットワークを相互接続した環境
を管理するために、ＩＴＵ−Ｔ(International Telecom
munication Union Telecommunication standardization
sector)においてＴＭＮ(Telecommunication Managemen
t Network)が規定されている。この規定に従ったシステ
ムでは、システムを構成する各オブジェクト間の関係
を、階層的な包含木構造を用いて管理する必要がある。
例えば、ＳＤＨ(Synchronous Digital Hierarchy) ネッ
トワーク網のノードを管理するネットワークマネージメ
ントシステム(NMS：Network Management System)に用い
られる。
【０００３】図４１は、従来のネットワーク管理システ
ムの構成図である。従来のネットワーク管理システムに
おけるオブジェクトの管理方式では、各クライアントア
プリケーション１１００，１２００には、メッセージ処
理部１１１０，１２１０とツリー管理部１１２０，１２
２０が設けられている。
【０００４】メッセージ管理部１１１０，１２１０は、
インタフェース１１４１を介して接続されている複数の
リソース管理オブジェクト(RM ：Resource Manager) １
１３１〜１１３６との間で、メッセージの送受信を行
う。ＲＭ１１３１〜１１３６は、被管理オブジェクト(M
O ：Managed Object) １１３１ａ，１１３２ａ，１１３
３ａ，１１３４ａ，１１３５ａ，１１３６ａの生成／削
除を管理している。ＭＯ１１３１ａ，１１３２ａ，１１
３３ａ，１１３４ａ，１１３５ａ，１１３６ａが、ネッ
トワークシステムを運用するために必要な各種処理を実
行する。メッセージ処理部１１１０，１２１０は、ツリ
ー管理部１１２０，１２２０が管理するテーブル１１２
１，１２２１の読出を行い（ステップＳ３１１、Ｓ３２
１）、その情報を基に操作対象となるリソース管理オブ
ジェクト１１３１〜１１３６に対して操作要求／応答結
果（ステップＳ３１２，Ｓ３２２）を行う。
【０００５】ツリー管理部１１２０，１２２０は、オブ
ジェクト間の関係を示す包含木１１２２，１２２２を管
理する。すなわち、ツリー管理部１１２０，１２２０
は、リソース管理情報ベース(RMIB ：Resource Managem
ent Information Base) をテーブル１１２１，１２２１
で固定的に保持し、そのテーブルの情報を基に包含木１
１２２，１２２２を生成する。この包含木１１２２，１
２２２に基づいて、ＲＭ１１３１〜１１３６の通信先ア
ドレスを管理する。
【０００６】なお、従来技術ではクライアントアプリケ
ーション１１００，１２００において包含木１１２２、
１２２２を管理しているため、システムの立ち上げ／立
ち下げ時には、リソース管理オブジェクト１１３１〜１
１３６からツリー管理部１１２０，１２２０に対し、生
成／削除通知（ステップＳ３１３，Ｓ３２３）が行われ
る。
【０００７】このように、各クライアントアプリケーシ
ョン１１００，１２００がＲＭＩＢをテーブル１１２
１，１２２１として保持しているため、オブジェクト間
の関係を各アプリケーション１１００，１２００が把握
することができる。
【０００８】
【発明が解決しようとする課題】しかし、従来技術では
各クライアントアプリケーションにおいてＲＭＩＢを固
定的に保持しているため、包含木の構成を変更出来ない
という問題点があった。すなわち、オブジェクト間の関
係はシステム設計時に決定され、その関係を示すテーブ
ルを保持するクライアントアプリケーションが作成され
る。そのため、システムの包含木の構成を変更（リソー
ス管理オブジェクトの追加／削除）することは基本的に
はできなかった。包含木の構成を変更するには、クライ
アントアプリケーションの変更が必要となり、多大な労
力が必要となってしまう。
【０００９】また、複数クライアントアプリケーション
で包含木を管理しているため（複数の包含木が存在して
いるため）、複数のクライアントアプリケーションと複
数のリソース管理オブジェクトとの間で、相互にメッセ
ージの送受信を行わなければならなかった。これによ
り、クライアントアプリケーション及びリソース管理オ
ブジェクトが増えるにつれ、クライアントアプリケーシ
ョンとリソース管理オブジェクトとの間の処理が煩雑か
つ通信量が多くなるという問題が生じていた。
【００１０】本発明はこのような点に鑑みなされたもの
であり、クライアントアプリケーションに影響を与える
ことなくリソース管理オブジェクト間の関係の変更を可
能とすると共に、オブジェクト管理を行うために送受信
される情報量を削減したオブジェクト管理システムを提
供することを目的とする。
【００１１】また、本発明の他の目的は、クライアント
アプリケーションに影響を与えることなくリソース管理
オブジェクト間の関係の変更を可能とすると共に、オブ
ジェクト管理を行うために送受信される情報量を削減し
た情報処理システムを提供することである。
【００１２】また、本発明の別の目的は、クライアント
アプリケーションに影響を与えることなくリソース管理
オブジェクト間の関係の変更を可能とする処理をコンピ
ュータに行わせることができるオブジェクト管理プログ
ラムを記録したコンピュータ読み取り可能な記録媒体を
提供することである。
【００１３】また、本発明のさらに別の目的は、クライ
アントアプリケーションに影響を与えることなくリソー
ス管理オブジェクト間の関係の変更を可能とすると共
に、オブジェクト管理を行うために送受信される情報量
を削減した情報処理プログラムを記録したコンピュータ
読み取り可能な記録媒体を提供することである。
【００１４】
【課題を解決するための手段】本発明では上記課題を解
決するために、管理対象となる被管理オブジェクトを管
理するリソース管理オブジェクト間の関係を階層的な包
含木構造によって管理するオブジェクト管理システムに
おいて、前記リソース管理オブジェクトに対する操作要
求を受け付けるメッセージ処理手段と、前記リソース管
理オブジェクトを特定するための識別情報及び前記リソ
ース管理オブジェクト間の包含関係が定義されたツリー
情報を保持するツリー管理手段と、前記メッセージ処理
手段が受け取った前記操作要求を送信すべき宛先リソー
ス管理オブジェクトの識別情報を前記ツリー管理手段が
管理するツリー情報により認識し、前記宛先リソース管
理オブジェクトに対して前記操作要求を出力するオブジ
ェクト管理手段と、 を有することを特徴とするオブジェ
クト管理システムが提供される。
【００１５】このようなオブジェクト管理システムによ
れば、リソース管理オブジェクトに対する操作要求が発
生すると、メッセージ処理手段によって受け取られる。
すると、オブジェクト管理手段が、操作要求を送信すべ
き宛先リソース管理オブジェクトの識別情報をツリー管
理手段が管理するツリー情報により認識し、さらに宛先
リソース管理オブジェクトに対して操作要求を出力す
る。これにより、操作要求を出力するアプリケーション
においてリソース管理オブジェクト間の関係を管理する
必要がなくなる。
【００１６】また、上記課題を解決するために複数のオ
ブジェクト間の関係を階層的な包含木構造によって管理
する情報処理システムにおいて、管理対象となる被管理
オブジェクトを管理する複数のリソース管理オブジェク
トと、前記リソース管理オブジェクトに対する操作要求
を受け付けるメッセージ処理手段と、前記リソース管理
オブジェクトを特定するための識別情報及び前記リソー
ス管理オブジェクト間の包含関係が定義されたツリー情
報を保持するツリー管理手段と、前記メッセージ処理手
段が受け取った前記操作要求を送信すべき宛先リソース
管理オブジェクトの識別情報を前記ツリー管理手段が管
理するツリー情報により認識し、前記宛先リソース管理
オブジェクトに対して前記操作要求を出力するオブジェ
クト管理手段と、 を有することを特徴とする情報処理シ
ステムが提供される。
【００１７】このような情報処理システムによれば、リ
ソース管理オブジェクトに対する操作要求が発生する
と、メッセージ処理手段によって受け取られる。する
と、オブジェクト管理手段が、操作要求を送信すべき宛
先リソース管理オブジェクトの識別情報をツリー管理手
段が管理するツリー情報により認識し、さらに宛先リソ
ース管理オブジェクトに対して操作要求を出力する。こ
れにより、操作要求を出力するアプリケーションにおい
てリソース管理オブジェクト間の関係を管理する必要が
なくなる。
【００１８】また、上記課題を解決するために、オブジ
ェクト間の関係を階層的な包含木構造によって管理する
オブジェクト管理プログラムを記録したコンピュータ読
み取り可能な記録媒体において、前記リソース管理オブ
ジェクトに対する操作要求を受け付けるメッセージ処理
手段、前記リソース管理オブジェクトを特定するための
識別情報及び前記リソース管理オブジェクト間の包含関
係が定義されたツリー情報を保持するツリー管理手段、
前記メッセージ処理手段が受け取った前記操作要求を送
信すべき宛先リソース管理オブジェクトの識別情報を前
記ツリー管理手段が管理するツリー情報により認識し、
前記宛先リソース管理オブジェクトに対して前記操作要
求を出力するオブジェクト管理手段、 としてコンピュー
タを機能させることを特徴とするオブジェクト管理プロ
グラムを記録したコンピュータ読み取り可能な記録媒体
が提供される。
【００１９】このような記録媒体に記録されたオブジェ
クト管理プログラムをコンピュータに実行させれば、上
記本発明に係るオブジェクト管理システムに必要な機能
がコンピュータ上に構成される。
【００２０】また、上記課題を解決するために、複数の
オブジェクト間の関係を階層的な包含木構造によって管
理する情報処理プログラムを記録したコンピュータ読み
取り可能な記録媒体において、管理対象となる被管理オ
ブジェクトを管理する複数のリソース管理オブジェク
ト、前記リソース管理オブジェクトに対する操作要求を
受け付けるメッセージ処理手段、前記リソース管理オブ
ジェクトを特定するための識別情報及び前記リソース管
理オブジェクト間の包含関係が定義されたツリー情報を
保持するツリー管理手段、前記メッセージ処理手段が受
け取った前記操作要求を送信すべき宛先リソース管理オ
ブジェクトの識別情報を前記ツリー管理手段が管理する
ツリー情報により認識し、前記宛先リソース管理オブジ
ェクトに対して前記操作要求を出力するオブジェクト管
理手段、としてコンピュータを機能させることを特徴と
する情報処理プログラムを記録したコンピュータ読み取
り可能な記録媒体が提供される。
【００２１】このような記録媒体に記録された情報処理
プログラムをコンピュータに実行させれば、上記本発明
に係る情報処理システムに必要な機能がコンピュータ上
に構成される。
【００２２】
【発明の実施の形態】以下、本発明の実施の形態を図面
を参照して説明する。図１は、本発明の原理構成図であ
る。本発明のオブジェクト管理システム１００は、イン
タフェース２１を介して複数のクライアントアプリケー
ション１１，１２に接続されていると共に、インタフェ
ース２２を介して複数のリソース管理オブジェクト（Ｒ
Ｍ）５１〜５６に接続されている。ＲＭ５１〜５６は、
管理対象となる被管理オブジェクト（ＭＯ）を管理して
いる。ＭＯは、クライアントアプリケーション１１，１
２から出力された要求に従って様々な処理を行う。な
お、ＲＭ５１〜５６には、それぞれ「RM1 」、「RM2
」、「RM3 」、「RM4 」、「RM5 」、「RM6 」という
関連識別名が付与されている。
【００２３】オブジェクト管理システム１００は、メッ
セージ処理手段１１０、ツリー管理手段１２０及びオブ
ジェクト管理手段１３０からなる。メッセージ処理手段
１１０は、クライアントアプリケーション１１、１２か
らＲＭ５１〜５６に対して出力される操作要求を受け付
ける。受け取った操作要求は、オブジェクト管理手段１
３０に渡す。ツリー管理手段１２０は、データベース４
０内に保持されたツリー情報を取得することで、ＲＭ５
１〜５６間の包含関係が定義されたツリー情報を管理
し、同時にＲＭ５１〜５６を特定するための識別情報を
管理する。オブジェクト管理手段１３０は、ツリー管理
手段１２０が保持するツリー情報を参照することで、Ｒ
Ｍ間の包含関係を包含木１３１として認識する。包含木
１３１は、各ＲＭ５１〜５６に対応するノードオブジェ
クト１３１ａ〜１３１ｆで構成される。そして、オブジ
ェクト管理手段１３０は、メッセージ処理手段１１０が
受け取った操作要求を送信すべきＲＭの識別情報を包含
木１３１より認識し、該当するＲＭに対して操作要求を
出力する。
【００２４】これにより、クライアントアプリケーショ
ン１１，１２が包含木の情報を管理していなくても、Ｒ
Ｍの包含関係に従った操作要求を、ＲＭ５１〜５６に対
して出力することができる。その結果、ＲＭ５１〜５６
間の包含関係に変更が生じた場合には、ツリー管理手段
１２０で保持しているツリー情報の内容を変更するだけ
でよいため、リソース管理オブジェクトの追加や削除が
容易となる。しかも、ＲＭ５１〜５６やＲＭを操作する
ために交換するメッセージの量が減るため、システム全
体の処理速度が向上する。
【００２５】以下に、本発明のオブジェクト管理システ
ム１００において行われる様々な処理の手順を説明す
る。図２は、リソース管理オブジェクトに対する操作手
順を示す図である。この図では、クライアントアプリケ
ーション１１からＲＭ５４に対して操作を行う場合の例
を示している。
【００２６】まず、クライアントアプリケーション１１
からＲＭ５４に対する操作要求は、インタフェース２１
を介してオブジェクト管理システム１００に送られ、メ
ッセージ処理手段１１０で受け取られる（ステップＳ
１）。メッセージ処理手段１１０は、オブジェクト管理
手段１３０に対してＲＭ５４に対する操作要求を行う
（ステップＳ２）。オブジェクト管理手段１３０は、包
含木１３１内のノードオブジェクト１３１ｄによりＲＭ
５４を認識し、ＲＭ５４に対して操作要求を行う（ステ
ップＳ３）。
【００２７】ＲＭ５４が要求に応じた処理を行った後、
ＲＭ５４からの操作結果応答がオブジェクト管理手段１
３０へ返される（ステップＳ４）。送られた操作結果応
答をオブジェクト管理手段１３０が受け取り、ノードオ
ブジェクト１３１ｄによってＲＭ５４からの応答である
ことを認識し、操作結果応答をメッセージ処理手段１１
０に返す（ステップＳ５）。メッセージ処理手段１１０
は、クライアントアプリケーション１１に操作結果応答
を返す（ステップＳ６）。
【００２８】これにより、クライアントアプリケーショ
ンで包含木を管理することなく、ＲＭに対して所望の処
理を実行させることが可能となる。次に、包含木の生成
手順を説明する。
【００２９】図３は、包含木の生成手順を示す図であ
る。まず、ツリー情報としてＲＭ間の包含関係（親子関
係）を表したＲＭＩＢをデータベース４０で定義し、シ
ステムの立ち上げ時にツリー管理手段１２０がデータベ
ース４０からＲＭＩＢの読出を行う（ステップＳ１
１）。その結果、データベース４０からＲＭＩＢの内容
が返される（ステップＳ１２）。ツリー管理手段１２０
は、読み出したＲＭＩＢの内容をテーブル１２１で保持
する。
【００３０】例えば、図４のようなＲＭＩＢがデータベ
ース４０に登録されているものとする。図４は、データ
ベースに保持されたＲＭＩＢの例を示す図である。ＲＭ
ＩＢには、「ＲＭの関連識別名」、「親ＲＭ名」、「Ｒ
Ｍ名」の設定項目が設けられている。「ＲＭの関連識別
名」には、個々のＲＭを識別するための関連識別名が登
録されている。「親ＲＭ名」には、登録されたＲＭの親
に当たるＲＭの識別名が登録されている。「ＲＭ名」に
は、登録されたＲＭの識別名が登録されている。この識
別名は、最上位のＲＭから順にたどった場合に経路上に
存在するＲＭの関連識別名の並びを設定し、その並びの
後ろに、自己の関連識別名とそのＲＭの機能を示す名称
とを追加したものである。
【００３１】このようなＲＭＩＢをツリー管理手段１２
０が読み出すと、図５のようなテーブルが生成される。
図５は、テーブル情報の例を示す図である。テーブル１
２１には、「ＲＭの関連識別名」、「親ＲＭ名」、「ノ
ードオブジェクト名」、及び「オブジェクトのＩＤ情
報」の設定項目が設けられている。「ＲＭの関連識別
名」には、個々のＲＭを識別するための関連識別名が登
録されている。「親ＲＭ名」には、登録されたＲＭの親
に当たるＲＭの識別名が登録されている。「ノードオブ
ジェクト名」には、包含木を構成するノードオブジェク
トに与えられる識別名が登録される。このノードオブジ
ェクト名には、ＲＭＩＢにおいて「ＲＭ名」として登録
されていた内容をそのまま設定する。「オブジェクトＩ
Ｄ情報」には、システム上で要求の送受信をする際に各
ＲＭを特定するのに必要な識別子が登録される。この段
階では、「オブジェクトＩＤ情報」の内容は設定されて
いない。
【００３２】このようなテーブルをツリー管理手段１２
０が保持することにより、絶えずデータベースにアクセ
スする必要が無くなり、包含木の生成（初期化）が容易
となる。
【００３３】ツリー管理手段１２０のテーブル１２１に
ＲＭＩＢ情報を保持した後に、オブジェクト管理手段１
３０はツリー管理手段１２０のテーブル１２１に対して
ツリー情報読出を行い（ステップＳ１３）、読出応答を
受け取る（ステップＳ１４）。オブジェクト管理手段１
３０は、受け取ったツリー情報を基に、包含木１３１の
生成を行う。
【００３４】その後、メッセージ処理手段１１０はＲＭ
５１〜５６からオブジェクトＩＤ情報登録通知を受け取
る（ステップＳ１５）。すると、メッセージ処理手段１
１０はツリー管理手段１２０にオブジェクトＩＤ情報の
登録を要求する（ステップＳ１６）。ツリー管理手段１
２０はテーブル１２１にオブジェクトＩＤ情報を保持
し、メッセージ処理手段１１０に登録が完了した旨の応
答を返す（ステップＳ１７）。
【００３５】その結果、ツリー管理手段１２０の保持す
るテーブルの内容は、図６のようになる。図６は、オブ
ジェクトＩＤ情報登録後のテーブルを示す図である。図
に示すように、各ＲＭに対応するオブジェクトＩＤ情報
が登録されている。
【００３６】次に、メッセージ処理手段１１０はオブジ
ェクト管理手段１３０にオブジェクトＩＤ情報取得要求
を行う（ステップＳ１８）。オブジェクト管理手段１３
０はツリー管理手段１２０のテーブル１２１に対してオ
ブジェクトＩＤ情報読出を行い（ステップＳ１９）、読
出応答（ステップＳ２０）を受け取る。これにより、各
ＲＭのオブジェクトＩＤ情報が取得できる。そして、オ
ブジェクト管理手段１３０は、メッセージ処理手段１１
０に取得が終了した旨の応答をする（ステップＳ２
１）。
【００３７】以上にようにして、オブジェクト管理手段
１３０において包含木１３１を生成し、包含木１３１を
構成する各ノードオブジェクト１３１ａ〜１３１ｆに対
応するＲＭのオブジェクトＩＤ情報を設定することがで
きる。
【００３８】次に、ＲＭの生成／削除手順を説明する。
図７は、ＲＭの生成／削除手順を示す図である。この図
は、関連識別名が「RM7 」であるＲＭ５７が新たに生成
されると共に、ＲＭ５４が削除された場合の例である。
生成されたＲＭ５７及び削除されたＲＭ５４は、メッセ
ージ処理手段１１０にＲＭ生成通知（ステップＳ３１）
及びＲＭ削除通知（ステップＳ３２）を通知する。これ
らの通知を受け取ったメッセージ処理手段１１０は、オ
ブジェクト管理手段１３０に対してツリー情報更新要求
を行う（ステップＳ３３）。すると、オブジェクト管理
手段１３０はツリー管理手段１２０に対してツリー情報
読出要求を行う（ステップＳ３４）。ツリー管理手段１
２０は、ＲＭ生成時は、親ＲＭが存在するかの確認を行
い、ＲＭ削除時は、該当ＲＭ及び配下ＲＭが存在するか
の確認を行う。そして、確認の結果を読出応答としてオ
ブジェクト管理手段１３０に返す（ステップＳ３５）。
その後、オブジェクト管理手段１３０はツリー管理手段
１２０に対してツリー情報更新要求を行う（ステップＳ
３６）。ツリー管理手段１２０はデータベース４０に対
してＲＭＩＢ情報更新を行い（ステップＳ３７）、ＲＭ
ＩＢ情報更新応答を受ける（ステップＳ３８）。
【００３９】図８は、ＲＭＩＢ情報更新によるデータベ
ースの内容の変化を示す図である。このように、更新前
には関連識別名「ＲＭ４」のレコードが登録されていた
が、ＲＭＩＢが更新されることによりそのレコードは削
除されている。また、更新前は、「ＲＭ７」のレコード
は登録されていなかったが、ＲＭＩＢが更新されること
によりそのレコードが新たに追加されている。
【００４０】さらにツリー管理手段１２０はテーブル１
２１を更新し、オブジェクト管理手段１３０に更新応答
を行う（ステップＳ３９）。図９は、テーブルの内容の
変化を示す図である。ＲＭＩＢに対する更新と同様に、
更新前には関連識別名「ＲＭ４」のレコードが登録され
ていたが、更新されることによりそのレコードは削除さ
れている。また、更新前は「ＲＭ７」のレコードは登録
されていなかったが、更新されることによりそのレコー
ドが新たに追加されている。
【００４１】その後、オブジェクト管理手段１３０は包
含木１３１の更新を行い、メッセージ処理手段１１０に
対して更新応答を行う（ステップＳ４０）。これによ
り、クライアントアプリケーション１１，１２に影響な
くツリー情報を自動的に更新できる。
【００４２】次に、ＲＭを削除する際に、そのＲＭの配
下のＲＭが存在した場合の処理手順について説明する。
図１０は、配下のＲＭが存在する場合の削除処理手順を
示す図である。この図は、関連識別名が「MR2 」である
ＲＭ５２が削除された場合の例である。ＲＭの削除処理
において、削除されたＲＭ５２は、メッセージ処理手段
１１０にＲＭ削除通知を送信する（ステップＳ５１）。
メッセージ処理手段１１０は通知を受信するとオブジェ
クト管理手段１３０にツリー情報更新要求を行う（ステ
ップＳ５２）。オブジェクト管理手段１３０はツリー管
理手段１２０に対してツリー情報読出を行う（ステップ
Ｓ５３）。ツリー管理手段１２０は、削除されたＲＭ及
び配下ＲＭが存在するか否かの確認を行い、確認結果を
読出応答としてオブジェクト管理手段１３０に送る（ス
テップＳ５４）。
【００４３】オブジェクト管理手段１３０は配下のＲＭ
５４，５５に対して、ＲＭ削除要求を行う（ステップＳ
５５，Ｓ５６）。その後、オブジェクト管理手段１３０
は、ツリー管理手段１２０に対してツリー情報更新要求
を行う（ステップＳ５７）。ツリー情報更新要求を受け
取ったツリー管理手段１２０は、データベース４０に対
してＲＭＩＢ情報更新を行い（ステップＳ５８）、ＲＭ
ＩＢ情報更新応答を受ける（ステップＳ５９）。
【００４４】図１１は、ＲＭＩＢの更新状況を示す図で
ある。更新前に登録されていた「ＲＭ２」、「ＲＭ
４」、「ＲＭ５」のレコードは更新処理によって削除さ
れる。ＲＭＩＢ情報更新応答を受け取ったツリー管理手
段１２０はテーブル１２１の内容を更新する。
【００４５】図１２は、テーブルの更新状況を示す図で
ある。ＲＭＩＢの更新処理と同様に、更新前に登録され
ていた「ＲＭ２」、「ＲＭ４」、「ＲＭ５」のレコード
は更新処理によって削除される。
【００４６】テーブル１２１の更新が終了したら、ツリ
ー管理手段１２０からオブジェクト管理手段１３０へ、
更新応答が返される（ステップＳ６０）。オブジェクト
管理手段１３０は、更新応答を受け取ると、削除された
ＲＭ５２，５４，５５に対応する包含木１３１内のノー
ドオブジェクト１３１ｂ，１３１ｄ，１３１ｅを、最下
層から順（図中ノードオブジェクト１３１ｄ→１３１ｅ
→１３１ｂの順）に削除する。そして、メッセージ処理
手段１１０に対して更新応答を行う（ステップＳ６
１）。
【００４７】これにより、配下のＲＭを有するＲＭを削
除する場合には、配下のＲＭも削除され、使用されない
ＲＭが存続し続けることがなくなる。次に、ＭＯの生成
処理について説明する。ここでは、ＲＭ５４が管理する
ＭＯを生成する場合を考える。
【００４８】図１３は、ＲＭが管理するＭＯの包含関係
を示す図である。包含木１３１で示されるＲＭ間の包含
関係と同様の関係が、各ＲＭ５１〜５６のそれぞれが管
理するＭＯ６１〜６６の間でも成立している。各ＭＯ６
１〜６６には関連識別名が与えられており、それぞれ
「RM1MO1」、「RM2MO1」、「RM3MO1」、「RM4MO1」、
「RM5MO1」、「RM6MO1」である。なお、ＭＯの識別名
は、上位ＭＯからＭＯ自身までの関連識別名の列挙型で
表す。この例では、ＲＭ５４が管理するＭＯ６４の生成
要求が出される。このＭＯ６４の識別名は、「RM1 ：RM
1MO1：RM2 ：RM2MO1：RM4 ：RM4MO1」である。また、Ｍ
Ｏ６４の親に当たるＭＯ６２の識別名は、「RM1 ：RM1M
O1：RM2 ：RM2MO1」である。
【００４９】図１４は、ＭＯの生成処理手順を示す図で
ある。まず、クライアントアプリケーション１１からメ
ッセージ処理手段１１０へ、ＲＭ５４が管理するＭＯ６
４の生成要求が送信される（ステップＳ７１）。する
と、メッセージ処理手段１１０はオブジェクト管理手段
１３０に対してＭＯ６４の生成要求を行う（ステップＳ
７２）。オブジェクト管理手段１３０は、ツリー管理手
段１２０に対してＭＯ６４を管理するＲＭ５４の親ＲＭ
５２の存否確認を行う（ステップＳ７３）。ツリー管理
手段１２０は、存在するか否かを確認し、存否確認応答
をオブジェクト管理手段１３０に返す（ステップＳ７
４）。親ＲＭ５２が存在する場合、オブジェクト管理手
段１３０は、ＲＭ５２に対して親ＭＯ６２の存否チェッ
ク処理の要求をＲＭ５２へ送信する（ステップＳ７
５）。ＲＭ５２は、ＲＭ６２の存否チェックを行い、そ
の結果を返す（ステップＳ７６）。親ＭＯが存在する場
合は、オブジェクト管理手段１３０が生成するＭＯ６４
の生成要求を、ＲＭ５４に対して行う（ステップＳ７
７）。その要求に応じて、ＲＭ５４がＭＯ６４を生成
し、その結果を返す（ステップＳ７８）。オブジェクト
管理手段１３０は、ＭＯ６４の生成処理の結果を、メッ
セージ処理手段１１０に応答する（ステップＳ７９）。
最後に、メッセージ処理手段１１０がクライアントアプ
リケーション１１に対して、ＭＯ６４の生成処理の結果
を応答する（ステップＳ８０）。
【００５０】なお、親ＭＯが存在していない場合には、
ＭＯ６４の生成は行われず、その旨の応答がクライアン
トアプリケーション１１に返される。このように、ＭＯ
の生成要求が出された場合には親ＭＯの存否を確認する
ため、正常に機能しないＭＯが生成されることはない。
【００５１】次に、ＭＯ生成処理の別の方法について説
明する。これは、クライアントアプリケーション１１が
直接ＲＭ５４に対してＭＯ６４の生成要求を行った場合
の処理である。
【００５２】図１５は、クライアントアプリケーション
から直接ＭＯ生成処理を行う際の処理手順を示す図であ
る。クライアントアプリケーション１１が直接ＲＭ５４
に対してＭＯ６４の生成要求を行う（ステップＳ９
１）。要求を受け取ったＲＭ５４は、ＭＯ６４を生成す
る前に、メッセージ処理手段１１０に親ＭＯの存否チェ
ック要求を行う（ステップＳ９２）。メッセージ処理手
段１１０はオブジェクト管理手段１３０に対して親ＭＯ
の存否確認要求を行う（ステップＳ９３）。オブジェク
ト管理手段１３０はツリー管理手段１２０に親ＲＭの存
否確認を行い（ステップＳ９４）、存否確認応答（ステ
ップＳ９５）を受ける。
【００５３】親ＲＭであるＲＭ５２が存在する場合、オ
ブジェクト管理手段１３０は、ＲＭ５２に対して親ＭＯ
の存否チェック処理を行い（ステップＳ９６）、存否チ
ェック応答を受ける（ステップＳ９７）。オブジェクト
管理手段１３０はメッセージ処理手段１１０に存否確認
結果を応答する（ステップＳ９８）。メッセージ処理手
段１１０はＲＭ５４に対して存否チェック結果を応答す
る（ステップＳ９９）。ＲＭ５４は、親ＭＯが存在した
場合にはＭＯ６４の生成を行い、クライアントアプリケ
ーション１１にＭＯ生成応答を返す（ステップＳ１０
０）。これにより、ＭＯのツリー情報に矛盾が生じない
ようになる。次に、ＭＯの削除処理について説明する。
【００５４】以下の説明では、関連識別名が「RM3MO1」
であるＭＯ６３を削除する場合を考える。図１６は、Ｍ
Ｏの包含関係における削除ＭＯの位置を示す図である。
図に示すように、削除すべきＭＯ６３は配下のＭＯ６６
を有している。このような場合、以下のような手順でＭ
Ｏの削除処理が行われる。
【００５５】図１７は、ＭＯ削除処理の手順を示す図で
ある。まず、クライアントアプリケーション１１からメ
ッセージ処理手段１１０へ、ＲＭ５３が管理するＭＯ６
３の削除要求が出される（ステップＳ１１１）。メッセ
ージ処理手段１１０はオブジェクト管理手段１３０に対
してＭＯ削除要求を行う（ステップＳ１１２）。ＭＯ削
除要求を受け取ったオブジェクト管理手段１３０はツリ
ー管理手段１２０に対して配下ＲＭ５６の存否確認を行
い（ステップＳ１１３）、ツリー管理手段１２０から存
否確認応答が返される（ステップＳ１１４）。配下ＲＭ
であるＲＭ５６が存在する場合、オブジェクト管理手段
１３０はＲＭ５６に対して、ＲＭ５６が管理する配下Ｍ
Ｏ６６の削除要求を行う（ステップＳ１１５）。ＲＭ５
６は、自己の管理するＭＯ６６を削除した後、ＭＯ削除
応答をオブジェクト管理手段１３０へ返す（ステップＳ
１１６）。オブジェクト管理手段１３０は、配下ＭＯの
削除後、ＲＭ５３に対してＭＯ６３の削除要求を行う
（ステップＳ１１７）。ＲＭ５３は、自己の管理するＭ
Ｏ６３を削除した後、ＭＯ削除応答を返す（ステップＳ
１１８）。オブジェクト管理手段１３０はメッセージ処
理手段１１０に応答結果を返し（ステップＳ１１９）、
さらにメッセージ処理手段１１０が、クライアントアプ
リケーション１１に応答結果を返す（ステップＳ１２
０）。
【００５６】なお、配下ＭＯ及び削除ＭＯの削除時に
は、各ＲＭに削除ＭＯの識別名「RM1：RM1MO1：RM3 ：R
M3MO1」を渡す。この識別名に基づいて、各ＲＭは削除
すべきＭＯを特定することができる。このようにして、
クライアントアプリケーションが包含木を有してなくて
も、ＭＯ間の包含関係を乱すことなくＭＯの削除を行う
ことができる。
【００５７】次に、１つのＲＭに対して複数の操作要求
が出された場合の排他制御について説明する。本発明で
は、クライアントアプリケーションからの操作要求に対
する排他制御を行うために、メッセージ処理手段１１０
でメッセージ処理中フラグ及びメッセージキューを設け
る。
【００５８】図１８は、メッセージ処理手段の内部構成
を示す図である。メッセージ処理手段１１０は、メッセ
ージ管理テーブル１１１を有している。メッセージ管理
テーブル１１１は、ＲＭ種別ごとに設けられており、さ
らにオペレーション種別で分けられている。オペレーシ
ョン種別とは、削除要求、生成要求などの別である。あ
るＲＭの１つのオペレーションに対して処理中フラグと
メッセージキューとが設けられている。メッセージによ
る処理を実行中には処理中フラグがオンとなり、処理を
実行していない場合には処理中フラグがオフとなる。メ
ッセージキューには、クライアントアプリケーションか
ら出されたメッセージがキューイングされる。
【００５９】このようなメッセージ管理テーブル１１１
を用いて、以下のような排他制御が行われる。図１９
は、操作要求受信時の処理手順を示すフローチャートで
ある。この処理は、すべてメッセージ処理手段１１０が
行う処理である。以下、このフローチャートをステップ
番号に沿って説明する。 ［Ｓ１３１］操作要求を受信する。 ［Ｓ１３２］操作要求の送信先となるＲＭを識別する。 ［Ｓ１３３］操作要求のオペレーション内容を識別す
る。 ［Ｓ１３４］送信先ＲＭの該当オペレーションの処理中
フラグを判定する。処理中フラグが「ＯＮ」であればス
テップＳ１３７に進み、「ＯＦＦ」であればステップＳ
１３５に進む。 ［Ｓ１３５］処理中フラグがＯＦＦ（処理中操作要求な
し）の場合は、まず処理中フラグを「ＯＮ」にする。 ［Ｓ１３６］操作要求を実行し、処理を終了する ［Ｓ１３７］処理中フラグがＯＮ（処理中操作要求あ
り）の場合は、送信先ＲＭの該当オペレーションのメッ
セージキューに操作要求を格納し、処理を終了する。
【００６０】図２０は、キューイングされた操作要求の
処理手順を示す図である。この処理は、メッセージキュ
ーの処理中フラグがＯＮとなった場合に、メッセージ処
理手段１１０がそのメッセージキューに対して行う処理
である。 ［Ｓ１４１］処理中の操作要求の終了通知を受け取る。 ［Ｓ１４２］メッセージキューが空か否かを判定する。
空の場合はステップＳ１４４に進む、空でない場合はス
テップＳ１４３に進む。 ［Ｓ１４３］メッセージキューが空でない場合、メッセ
ージキューから先頭の操作要求を取り出し実行する。そ
の後、ステップＳ１４１に進む。 ［Ｓ１４４］メッセージキューが空であれば、処理中フ
ラグをＯＦＦにして、処理を終了する。
【００６１】このように、排他制御を行うことにより、
同一のＲＭに対する同じオペレーションの操作要求が同
時期に出されても、混乱することなく処理される。以下
に、本発明のオブジェクト管理システムをネットワーク
管理システムに適用した場合の例を具体的に説明する。
【００６２】図２１は、ネットワーク管理システムの構
成を示す図である。このネットワーク管理システムはオ
ブジェクト管理システム２００を中心に構成されてい
る。このオブジェクト管理システム２００は、オペレー
ティングシステム(OS ：Operating System) としてＮＥ
−ＯＳ(Network Element Operating System)が動作して
いるコンピュータであり、ＮＥ−ＯＳ上でオブジェクト
管理プログラムが実行されている。オブジェクト管理プ
ログラムは、コンピュータを本発明に係るオブジェクト
管理システムとして機能させるための命令が記述された
プログラムである。
【００６３】オブジェクト管理システム２００は、ＤＣ
Ｎ(Data Communications Network)６０１を介して上位
システム群３００に接続されている。また、ＴＣＰ／Ｉ
Ｐ(Transmission Control Protocol/Internet Protoco
l) によるネットワーク６０２を介してＧＵＩ(Graphic
User Interface)端末群４００に接続されている。さら
に、ＤＣＮ６０３を介してＮＥ(Network Element) 群５
００に接続されている。
【００６４】上位システム群３００は、複数のコンピュ
ータ３１０，３２０，３３０の集合である。また、ＧＵ
Ｉ端末群４００は、クライアント用の複数のコンピュー
タ４１０，４２０の集合である。これらのコンピュータ
３１０，３２０，３３０，４１０，４２０において、情
報通信ネットワークの管理制御要求を行うためのクライ
アントアプリケーションが実行されている。
【００６５】ＮＥ群５００は、交換機５１０，５２０や
伝送装置５３０，５４０の集合である。交換機５１０，
５２０や伝送装置５３０，５４０内には、ＲＭやＭＯが
生成されており、ＭＯが交換機等の動作を制御してい
る。
【００６６】図２２は、オブジェクト管理プログラムを
実行することにより構築される機能を示す図である。図
に示すようにオブジェクト管理システム２００でオブジ
ェクト管理プログラムを実行することによって、メッセ
ージ処理部２１０、ツリー管理部２２０、及びオブジェ
クト管理部２３０の機能が構築される。メッセージ処理
部２１０は、上位システム群３００やＧＵＩ端末群４０
０からの操作要求などを受け取り、その内容に従って処
理要求を転送する。ツリー管理部２２０は、データベー
ス２０１からＲＭＩＢを取得し、ＲＭの包含関係を示す
テーブル２２１を生成することによって、複数のＲＭ間
の木構造を管理する。オブジェクト管理部２３０は、Ｍ
Ｏの全ライフサイクルを管理しＭＯの種別あるいはクラ
ス毎に存在するＲＭに対し、全ＲＭのライフサイクルお
よびＲＭ間の包含関係を包含木により管理する。
【００６７】図２３は、ネットワーク管理システムにお
けるレイヤネットワークを示す図である。ネットワーク
は上位から順に、回線レイヤネットワーク７１０、パス
レイヤネットワーク７２０、伝送媒体レイヤネットワー
ク７３０である。伝送媒体レイヤネットワーク７３０
は、複数のサブネットワーク７３１〜７３３を配下に有
している。サブネットワーク７３１〜７３３はさらに、
ノード７３１ａ，７３１ｂ，７３２ａ，７３２ｂ，７３
２ｃ，７３３ａ，７３３ｂを有している。ノードは、リ
ンク７３１ｃ，７３２ｄ，７３２ｅ，７３３ｃによって
関連付けられている。なお、サブネットワーク７３１〜
７３３は、それぞれ「SubNetwork01」、「SubNetwork0
2」、「SubNetwork03」という関連識別名のＭＯであ
る。同様に、ノード７３１ａ，７３１ｂ，７３２ａ，７
３２ｂ，７３２ｃ，７３３ａ，７３３ｂは、それぞれ
「Node11」、「Node12」、「Node21」、「Node22」、
「Node23」、「Node31」、「Node32」という関連識別名
のＭＯである。さらに、リンク７３１ｃ，７３２ｄ，７
３２ｅ，７３３ｃは、それぞれ「Link11」、「Link2
1」、「Link22」、「Link31」という関連識別名のＭＯ
である。
【００６８】このようなレイヤネットワークを構成する
リソースの包含関係を木構造で表すと、図２４のように
なる。図２４は、レイヤネットワークの包含木構造を示
す図である。このように、複数のＲＭ５０１〜５０６
は、包含木構成によって互いに関連付けられている。各
ＲＭ５０１〜５０６には、それぞれ「System」、「Admi
n 」、「Layer 」、「SubNetwork」、「Node」、「Lin
k」という関連識別名が与えられている。
【００６９】図２５は、図２４の木構造の包含関係を定
義したＲＭＩＢ情報である。このＲＭＩＢ情報は、デー
タベース２０１内に保持されている。このようなＲＭＩ
Ｂ情報に基づいて、以下のようにして包含木の生成が行
われる。
【００７０】図２６は、システムの立ち上げ時の包含木
の生成（初期化）処理手順を示す図である。包含木の生
成（初期化）処理においてオブジェクト管理システム２
００のツリー管理部２２０は、データベース２０１に対
してＲＭＩＢの読出を行い（ステップＳ２０１）、ＲＭ
ＩＢ読出応答を得る（ステップＳ２０２）。そして、Ｒ
ＭＩＢ情報をテーブル２２１に保持する。
【００７１】その後、オブジェクト管理部２３０は、ツ
リー管理部２２０のテーブル２２１に対してツリー情報
読出を行い（ステップＳ２０３）、読出応答を受ける
（ステップＳ２０４）。受け取った情報を基に、オブジ
ェクト管理部２３０は包含木２３１の生成（初期化）と
して、ＲＭ５０１〜５０６のそれぞれに対応するノード
オブジェクト２３１ａ〜２３１ｆを生成する。
【００７２】各ＲＭ５０１〜５０６は、メッセージ処理
部２１０にオブジェクトＩＤ情報登録通知を行う（ステ
ップＳ２０５）。すると、メッセージ処理部２１０はツ
リー管理部２２０のテーブル２２１にオブジェクトＩＤ
情報の登録を行い（ステップＳ２０６）、登録応答を受
ける（ステップＳ２０７）。次に、メッセージ処理部２
１０は、オブジェクト管理部２３０に対してオブジェク
トＩＤ情報取得要求を行う（ステップＳ２０８）。オブ
ジェクト管理部２３０は、ツリー管理部２２０のテーブ
ル２２１にオブジェクトＩＤ情報読出を行い（ステップ
Ｓ２０９）、読出応答を受け取る（ステップＳ２１
０）。その後、オブジェクト管理部２３０は、メッセー
ジ処理部２１０に取得終了を応答する（ステップＳ２１
１）。
【００７３】図２７は、システム立ち上げ後のツリー管
理部が保持するテーブル情報である。ツリー管理部２２
０内のテーブル２２１では、データベース２０１に登録
されていたＲＭＩＢ情報に加えて、オブジェクトＩＤ情
報も保持されている。
【００７４】次に、システム起動中にＲＭが生成された
場合の、ツリー情報更新処理について説明する。図２８
は、システム起動中にＲＭの生成によるツリー情報の更
新処理手順を示す図である。関連識別名が「NewRM 」で
あるＲＭ５０７が生成されると、そのＲＭ５０７からメ
ッセージ処理部２１０にＲＭ生成通知が通知される（ス
テップＳ２２１）。メッセージ処理部２１０はオブジェ
クト管理部２３０にツリー情報更新要求を行う（ステッ
プＳ２２２）。オブジェクト管理部２３０はツリー管理
部２２０に親ＲＭが存在するか確認を行う（ステップＳ
２２３）。これに応じて、ツリー管理部２２０が読出応
答を返す（ステップＳ２２４）。オブジェクト管理部２
３０は、親ＲＭが存在している場合にはツリー管理部２
２０にツリー情報更新要求を行う（ステップＳ２２
５）。ツリー管理部２２０はデータベース２０１に対し
てＲＭＩＢ情報更新を行い（ステップＳ２２６）、ＲＭ
ＩＢ情報更新応答を受ける（ステップＳ２２７）。ま
た、ツリー管理部２２０はテーブル２２１の更新も行
い、オブジェクト管理部２３０に更新応答を行う（ステ
ップＳ２２８）。その後、オブジェクト管理部２３０は
包含木２３１にノードオブジェクト２３１ｇを生成し、
メッセージ処理部２１０に更新応答を行う（ステップＳ
２２９）。
【００７５】図２９は、ＲＭの生成によって更新された
ＲＭＩＢ情報の内容を示す図である。データベース２０
１に保持されたＲＭＩＢ情報には、新たに生成されたＲ
Ｍ５０７に関するレコードが追加されている。
【００７６】図３０は、ＲＭの生成によって更新された
テーブル情報の内容を示す図である。ＲＭＩＢ情報に対
する変更と同様に、ツリー管理部２２０で保持されたテ
ーブル２２１には、新たに生成されたＲＭ５０７に関す
るレコードが追加されている。
【００７７】次に、ＲＭが削除された場合の処理手順を
説明する。図３１は、システム起動中にＲＭの削除によ
るツリー情報の更新処理の手順を示す図である。関連識
別名が「SubNetwork」であるＲＭ５０４が削除される際
に、ＲＭ５０４からメッセージ処理部２１０へＲＭ削除
通知が通知される（ステップＳ２３１）。すると、メッ
セージ処理部２１０はオブジェクト管理部２３０にツリ
ー情報更新要求を行う（ステップＳ２３２）。オブジェ
クト管理部２３０はツリー管理部２２０に配下ＲＭが存
在するかどうかの確認を行う（ステップＳ２３３）。そ
れに応じて、確認に対する読出応答がツリー管理部２２
０から返される（ステップＳ２３４）。配下ＲＭが存在
している場合は、オブジェクト管理部２３０が配下のＲ
Ｍ５０５，５０６に対してＲＭ削除要求を行う（ステッ
プＳ２３５，Ｓ２３６）。その後、オブジェクト管理部
２３０からツリー管理部２２０にツリー情報更新要求が
行われる（ステップＳ２３７）。ツリー管理部２２０は
データベース２０１に対してＲＭＩＢ情報更新を行い
（ステップＳ２３８）、ＲＭＩＢ情報更新応答を受ける
（ステップＳ２３９）。また、ツリー管理部２２０はテ
ーブル２２１の更新も行い、オブジェクト管理部２３０
に更新応答を行う（ステップＳ２４０）。その後、オブ
ジェクト管理部２３０は包含木２３１内のノードオブジ
ェクト２３１ｄ，２３１ｅ，２３１ｆに対して、オブジ
ェクトID情報の削除及びノードオブジェクト２３１ｄ，
２３１ｅ，２３１ｆ自身の削除を行い、メッセージ処理
部２１０に更新応答を行う（ステップＳ２４１）。な
お、オブジェクト管理部２３０が包含木２３１からノー
ドオブジェクトを削除する場合、包含木２３１の最下層
から該当ＲＭの順（ノードオブジェクト２３１ｅ→２３
１ｆ→２３１ｄの順）に削除する。
【００７８】図３２は、ＲＭの削除によって更新された
ＲＭＩＢ情報の内容を示す図である。データベース２０
１に保持されたＲＭＩＢ情報には、削除されたＲＭ５０
４〜５０６に関するレコードが消去されている。
【００７９】図３３は、ＲＭの削除によって更新された
テーブル情報の内容を示す図である。ＲＭＩＢ情報に対
する変更と同様に、ツリー管理部２２０で保持されたテ
ーブル２２１には、削除されたＲＭ５０４〜５０６に関
するレコードが消去されている。
【００８０】次に、レイヤネットワークを変更する場合
の例を説明する。図３４は、レイヤネットワーク構造の
変更例を示す図である。この図では、図２３に示したレ
イヤネットワーク構造に対してノード７３３ｄを追加す
ると共に、サブネットワーク７３１全体を削除してい
る。なお、ノード７３３ｄが追加されたことにより、２
つのリンク７３３ｅ，７３３ｆも追加されている。
【００８１】図３５は、ＭＯ間の包含関係を示す図であ
る。図に示すように、生成するノード７３３ｄの識別名
は、「System：System01：Layer ：Layer01 ：SubNetwo
rk：Subnetwork03：Node：Node33」である。また、親と
なるサブネットワーク７３３の識別名は、「System：Sy
stem01：Layer ：Layer01 ：SubNetwork：Subnetwork0
3」である。
【００８２】図３６は、上位システム内アプリケーショ
ンからMOの生成要求が出された場合の処理を示す図であ
る。上位システム内アプリケーション３０１からノード
７３３ｄの生成要求がメッセージ処理部２１０に出され
る（ステップＳ２５１）。このとき、生成時の情報とし
て、生成すべきＭＯの識別名「System：System01：Laye
r ：Layer01 ：SubNetwork：SubNetwork03：Node：Node
33」を受け取る。メッセージ処理部２１０は、オブジェ
クト管理部２３０にＭＯ生成要求を行う（ステップＳ２
５２）。オブジェクト管理部２３０はＭＯを生成する前
に、親となるサブネットワーク７３３（関連識別名「Su
bNetwork03」）が存在するかどうか確認するために、ツ
リー管理部２２０に対して親ＲＭの存否確認を行い（ス
テップＳ２５３）、ツリー管理部２２０から存否確認応
答を受ける（ステップＳ２５４）。
【００８３】親ＲＭが存在する場合には、オブジェクト
管理部２３０は親ＭＯの存否確認を行うために、ノード
オブジェクト２３１ｃが持つオブジェクトＩＤ情報を基
に、ＲＭ５０４に対して親ＭＯの識別名「System：Syst
em01：Layer ：Layer01 ：SubNetwork：SubNetwork03」
を情報として渡し、親ＭＯであるサブネットワーク７３
３の存否チェック処理を行う（ステップＳ２５５）。Ｒ
Ｍ５０４からは存否チェック応答が返される（ステップ
Ｓ２５６）を受ける。
【００８４】親ＭＯが存在する場合は、オブジェクト管
理部２３０がノード７３３ｄの生成を行う。すなわち、
ノードオブジェクト２３１ｅが持つオブジェクトＩＤ情
報を基に、ＲＭ５０５に対して生成すべきノード７３３
ｄの識別名「System：System01：Layer ：Layer01 ：Su
bNetwork：SubNetwork03：Node：Node33」を情報として
渡し、ノード７３３ｄの生成要求を行う（ステップＳ２
５７）。ＲＭ５０５からは、ノード７３３ｄの生成後、
ＭＯ生成応答が返される（ステップＳ２５８）。ＭＯ生
成応答を受けたオブジェクト管理部２３０は、メッセー
ジ処理部２１０に対して応答結果を返す（ステップＳ２
５９）。すると、メッセージ処理部２１０は上位システ
ム内アプリケーション３０１に応答結果を返す（ステッ
プＳ２６０）。
【００８５】なお、ＭＯの生成要求を上位システム内ア
プリケーションが直接ＲＭに対して行うこともできる。
そのような場合の処理手順を以下に示す。図３７は、上
位システム内アプリケーションが直接ＲＭに対してＭＯ
の生成要求を行った場合の処理手順を示す図である。上
位システム内アプリケーション３０１から直接ＲＭ５０
５に対してＭＯ生成要求を行われる（ステップＳ２７
１）。すると、ＲＭ５０５はメッセージ処理部２１０に
対して親ＭＯの存否チェック要求を行う（ステップＳ２
７２）。このときメッセージ処理部２１０は、生成すべ
きＭＯ７３３ｄの識別名「System：System01：Layer ：
Layer01 ：SubNetwork：SubNetwork03：Node：Node33」
を情報として受ける。メッセージ処理部２１０は要求を
受けると、オブジェクト管理部２３０に親ＭＯ存否確認
要求を行う（ステップＳ２７３）。オブジェクト管理部
２３０は親となるＲＭ５０４が存在するか確認するため
に、ツリー管理部２２０に対して親ＲＭの存否確認を行
い（ステップＳ２７４）、存否確認応答を受ける（ステ
ップＳ２７５）。
【００８６】親ＲＭが存在する場合、オブジェクト管理
部２３０は、親ＭＯの存否確認を行うためにノードオブ
ジェクト２３１ｄが持つオブジェクトＩＤ情報を基に、
ＲＭ５０４に対して親ＭＯの識別名「System：System0
1：Layer ：Layer01 ：SubNetwork：SubNetwork03」を
情報として渡し、親ＭＯの存否チェック処理を行う（ス
テップＳ２７６）。ＲＭ５０４は存否チェックを行った
後、存否チェック応答を返す（ステップＳ２７７）。オ
ブジェクト管理部２３０はメッセージ処理部２１０に存
否確認結果を返し（ステップＳ２７８）、メッセージ処
理部２１０はＲＭ５０５に存否チェック結果を返す（ス
テップＳ２７９）。ＲＭ５０５は存否チェック結果で親
ＭＯが存在している場合は、ノード７３３ｄを生成し、
上位システム内アプリケーション３０１にＭＯ生成応答
を返す（ステップＳ２８０）。
【００８７】図３８は、削除すべきＭＯに関する包含関
係を示す図である。これは、図３４で示した変更内容の
中で、関連識別名が「SubNetwork01」であるサブネット
ワーク７３１の削除に関する包含関係を示すものであ
る。削除すべきサブネットワーク７３１の識別名は「Sy
stem：System01：Layer ：Layer01 ：SubNetwork：Subn
etworkO1」である。このサブネットワーク７３１には、
配下のノード７３１ａ，７３１ｂと配下のリンク７３１
ｃが存在する。これらの配下のノード７３１ａ，７３１
ｂと配下のリンク７３１ｃの識別名は、それぞれ「Syst
em：System01：Layer ：Layer01 ：SubNetwork：Subnet
work01：Node：Node11」、「System：System01：Layer
：Layer01 ：SubNetwork：Subnetwork01：Node：Node1
2」、「System：System01：Layer ：Layer01 ：SubNetw
ork：Subnetwork01：Link：Link11」である。
【００８８】図３９は、ＭＯを削除する際の処理手順を
示す図である。上位システム内アプリケーション３０１
からメッセージ処理部２１０へ、削除ＭＯであるサブネ
ットワーク７３１のＭＯ削除要求が出される（ステップ
Ｓ２９１）。このときメッセージ処理部２１０は、削除
時の情報として、削除ＭＯの識別名「System：System0
1：Layer ：Layer01 ：SubNetwork：SubNetwork01」を
受ける。そして、メッセージ処理部２１０はオブジェク
ト管理部２３０にＭＯ削除要求を行う（ステップＳ２９
２）。配下にＭＯが存在する場合は配下から削除する必
要があるため、オブジェクト管理部２３０はＭＯを削除
する前に、ツリー管理部２２０に対して配下ＲＭの存否
確認を行い（ステップＳ２９３）、存否確認応答を受け
る（ステップＳ２９４）。
【００８９】ここでは、配下のＲＭ５０５，５０６が存
在するため、削除ＭＯであるサブネットワーク７３１の
配下にもＭＯが存在する可能性がある。そこで、オブジ
ェクト管理部２３０は、ノードオブジェクト２３１ｅ、
２３１ｆが持つオブジェクトＩＤ情報を基に、ＲＭ５０
５，５０６に対して識別名が「System：System01：Laye
r ：Layer01 ：SubNetwork：SubNetwork01」であるＭＯ
の配下ＭＯの削除要求を行う（ステップＳ２９５，Ｓ２
９７）。これにより、各ＲＭ５０５，５０６において、
識別名「System：System01：Layer ：Layer01 ：SubNet
work：SubNetwork01」を基に、識別名「System：System
01：Layer ：Layer01 ：SubNetwork：SubNetwork01：No
de：Node11」、識別名「System：System01：Layer ：La
yer01 ：SubNetwork：SubNetwork01：Node：Node12」、
識別名「System：System01：Layer ：Layer01 ：SubNet
work：SubNetwork01：Link：Link11」にあたるノード７
３１ａ，７３１ｂとリンク７３１ｃが削除される。そし
て、ＲＭ５０５，５０６からオブジェクト管理部２３０
へ、ＭＯ削除応答が返される（ステップＳ２９６，Ｓ２
９８）。
【００９０】その後、オブジェクト管理部２３０は、削
除ＭＯであるサブネットワーク７３１の削除を行う。す
なわち、ノードオブジェクト２３１ｄが持つオブジェク
トＩＤ情報を基に、ＲＭ５０４に対して削除ＭＯの識別
名「System：System01：Layer ：Layer01 ：SubNetwor
k：SubNetwork01」を情報として渡し、ＭＯの削除要求
を行う（ステップＳ２９９）。ＲＭ５０４は、サブネッ
トワーク７３１の削除後、ＭＯ削除応答を返す（ステッ
プＳ３００）。すると、オブジェクト管理部２３０はメ
ッセージ処理部２１０に対して応答結果を返し（ステッ
プＳ３０１）、メッセージ処理部２１０は上位システム
内アプリケーション３０１に応答結果を返す（ステップ
Ｓ３０２）。
【００９１】次に、操作要求のキューイングを具体的に
説明する。図４０は、上位システム内アプリケーション
からの操作要求に対する排他制御例である。上位システ
ム内アプリケーション３０１からメッセージ処理部２１
０が操作要求「Admin-get 」を受ける。すると、メッセ
ージ処理部２１０は操作要求の送信先としてＲＭ種別の
識別を行い、対象ＲＭを「Admin 」と判定する。さら
に、操作要求のオペレーション種別の識別を行い、「ge
t 」と判定する。これにより、該当する処理中フラグ及
びメッセージキューが確定する。処理中フラグ及びメッ
セージキューが確定すると、メッセージ処理部２１０は
処理中フラグの判定を行う。ここでは、処理中フラグが
「フラグＯＮ（処理中操作要求あり）」であるため、メ
ッセージキューに「操作要求３」を格納する。 メッセー
ジキュー内の操作要求は、「操作要求１」、「操作要求
２」、「操作要求３」の順に実行し、メッセージキュー
内が空になったら、処理中フラグを「フラグＯＦＦ（処
理中操作要求なし）」にする。
【００９２】なお、「get 」のオペレーションは情報の
取得要求であり、「set 」のオペレーションは情報の設
定要求であり、「action」のオペレーションは所定の処
理の開始要求であり、「create」のオペレーションはＭ
Ｏの生成要求であり、「delete」のオペレーションはＭ
Ｏの削除要求である。
【００９３】以上説明したように、本発明に係るオブジ
ェクト管理システムを用いてネットワーク管理システム
を構築すれば、クライアントアプリケーションはシステ
ムの包含木の構成を意識することなくオブジェクトに対
して操作要求を行うことが可能となり、クライアントア
プリケーションに影響を与えることなく包含木の構成を
変更することが可能となる。しかも、クライアントアプ
リケーションとオブジェクトとの間で送受信された情報
量が減り、ネットワーク管理システムの全体の性能向上
に寄与するところが大きい。
【００９４】なお、上記の処理機能は、コンピュータに
よって実現することができる。その場合、オブジェクト
管理システムが有すべき機能の処理内容は、コンピュー
タで読み取り可能な記録媒体に記録されたプログラムに
記述しておく。そして、このプログラムをコンピュータ
で実行することにより、上記処理がコンピュータで実現
される。コンピュータで読み取り可能な記録媒体として
は、磁気記録装置や半導体メモリ等がある。市場に流通
させる場合には、ＣＤ−ＲＯＭ(Compact DiskRead Only
Memory) やフロッピーディスク等の可搬型記録媒体に
プログラムを格納して流通させたり、ネットワークを介
して接続されたコンピュータの記憶装置に格納してお
き、ネットワークを通じて他のコンピュータに転送する
こともできる。コンピュータで実行する際には、コンピ
ュータ内のハードディスク装置等にプログラムを格納し
ておき、メインメモリにロードして実行する。
【００９５】
【発明の効果】以上説明したように本発明のオブジェク
ト管理システム及び情報処理システムでは、ツリー管理
手段がリソース管理オブジェクトの包含関係を示すツリ
ー情報を管理し、オブジェクト管理手段がツリー情報か
ら操作要求の宛先を認識し、該当するリソース管理オブ
ジェクトへ操作要求を出力するようにしたため、クライ
アントアプリケーションはシステムの包含木の構成を意
識することなくオブジェクトに対して操作要求を行うこ
とが可能となり、クライアントアプリケーションに影響
を与えることなく包含木の構成を変更することが可能と
なる。さらに、クライアントアプリケーションとリソー
ス管理オブジェクトとの間でオブジェクト管理のための
情報の送受信を行う必要がないため、システム全体の負
荷が軽減される。
【００９６】また、本発明のオブジェクト管理プログラ
ムを記録したコンピュータ読み取り可能な記録媒体及び
情報処理プログラムを記録したコンピュータ読み取り可
能な記録媒体では、記録されたオブジェクト管理プログ
ラムをコンピュータに実行させることにより、リソース
管理オブジェクトの包含関係を示すツリー情報を一括管
理し、入力された操作要求を該当するリソース管理オブ
ジェクトへ出力するような処理をコンピュータに行わせ
ることが可能となる。
【図面の簡単な説明】
【図１】本発明の原理構成図である。
【図２】リソース管理オブジェクトに対する操作手順を
示す図である。
【図３】包含木の生成手順を示す図である。
【図４】データベースに保持されたＲＭＩＢの例を示す
図である。
【図５】テーブル情報の例を示す図である。
【図６】オブジェクトＩＤ情報登録後のテーブルを示す
図である。
【図７】ＲＭの生成／削除手順を示す図である。
【図８】ＲＭＩＢ情報更新によるデータベースの内容の
変化を示す図である。
【図９】テーブルの内容の変化を示す図である。
【図１０】配下のＲＭが存在する場合の削除処理手順を
示す図である。
【図１１】ＲＭＩＢの更新状況を示す図である。
【図１２】テーブルの更新状況を示す図である。
【図１３】ＲＭが管理するＭＯの包含関係を示す図であ
る。
【図１４】ＭＯの生成処理手順を示す図である。
【図１５】クライアントアプリケーションから直接ＭＯ
生成処理を行う際の処理手順を示す図である。
【図１６】ＭＯの包含関係における削除ＭＯの位置を示
す図である。
【図１７】ＭＯ削除処理の手順を示す図である。
【図１８】メッセージ処理手段の内部構成を示す図であ
る。
【図１９】操作要求受信時の処理手順を示すフローチャ
ートである。
【図２０】キューイングされた操作要求の処理手順を示
す図である。
【図２１】ネットワーク管理システムの構成を示す図で
ある。
【図２２】オブジェクト管理プログラムを実行すること
により構築される機能を示す図である。
【図２３】ネットワーク管理システムにおけるレイヤネ
ットワークを示す図である。
【図２４】レイヤネットワークの包含木構造を示す図で
ある。
【図２５】図２４の木構造の包含関係を定義したＲＭＩ
Ｂ情報である。
【図２６】システムの立ち上げ時の包含木の生成（初期
化）処理手順を示す図である。
【図２７】システム立ち上げ後のツリー管理部が保持す
るテーブル情報である。
【図２８】システム起動中にＲＭの生成によるツリー情
報の更新処理手順を示す図である。
【図２９】ＲＭの生成によって更新されたＲＭＩＢ情報
の内容を示す図である。
【図３０】ＲＭの生成によって更新されたテーブル情報
の内容を示す図である。
【図３１】システム起動中にＲＭの削除によるツリー情
報の更新処理の手順を示す図である。
【図３２】ＲＭの削除によって更新されたＲＭＩＢ情報
の内容を示す図である。
【図３３】ＲＭの削除によって更新されたテーブル情報
の内容を示す図である。
【図３４】レイヤネットワーク構造の変更例を示す図で
ある。
【図３５】ＭＯ間の包含関係を示す図である。
【図３６】上位システム内アプリケーションからMOの生
成要求が出された場合の処理を示す図である。
【図３７】上位システム内アプリケーションが直接ＲＭ
に対してＭＯの生成要求を行った場合の処理手順を示す
図である。
【図３８】削除すべきＭＯに関する包含関係を示す図で
ある。
【図３９】ＭＯを削除する際の処理手順を示す図であ
る。
【図４０】上位システム内アプリケーションからの操作
要求に対する排他制御例である。
【図４１】従来のネットワーク管理システムの構成図で
ある。
【符号の説明】
１１，１２ クライアントアプリケーション ２１，２２ インタフェース ４０ データベース ５１〜５６ リソース管理オブジェクト（ＲＭ） １００ オブジェクト管理システム １１０ メッセージ処理手段 １２０ ツリー管理手段 １３０ オブジェクト管理手段 １３１ 包含木
───────────────────────────────────────────────────── フロントページの続き (72)発明者 池田 和章 石川県金沢市広岡３丁目１番１号 富士通 北陸通信システム株式会社内 (72)発明者 中 剛 石川県金沢市広岡３丁目１番１号 富士通 北陸通信システム株式会社内 (72)発明者 中村 俊晴 石川県金沢市広岡３丁目１番１号 富士通 北陸通信システム株式会社内 Ｆターム(参考） 5B089 AA21 AA22 AC03 AD00 AE01 AE09 AF02 AF07 BB09 CB02 CB03 CC17 DD01 5K030 GA11 JL10 KA07 MA01

Claims (16)

    【特許請求の範囲】
  1. 【請求項１】 管理対象となる被管理オブジェクトを管
    理するリソース管理オブジェクト間の関係を階層的な包
    含木構造によって管理するオブジェクト管理システムに
    おいて、 前記リソース管理オブジェクトに対する操作要求を受け
    付けるメッセージ処理手段と、 前記リソース管理オブジェクトを特定するための識別情
    報及び前記リソース管理オブジェクト間の包含関係が定
    義されたツリー情報を保持するツリー管理手段と、 前記メッセージ処理手段が受け取った前記操作要求を送
    信すべき宛先リソース管理オブジェクトの識別情報を前
    記ツリー管理手段が管理するツリー情報により認識し、
    前記宛先リソース管理オブジェクトに対して前記操作要
    求を出力するオブジェクト管理手段と、を有することを
    特徴とするオブジェクト管理システム。
  2. 【請求項２】 前記ツリー管理手段は、システムの立ち
    上げ時に前記リソース管理オブジェクト間の包含関係を
    示す情報をデータベースから読み出し、読み出した情報
    を内部のテーブルで保持することにより前記ツリー情報
    の管理を行うことを特徴とする請求項１記載のオブジェ
    クト管理システム。
  3. 【請求項３】 前記ツリー管理手段は、前記ツリー情報
    の内容を変更する際には、同時に前記データベースの内
    容の変更を行い、前記ツリー情報の内容と前記データベ
    ースの内容との整合性を保つことを特徴とする請求項２
    記載のオブジェクト管理システム。
  4. 【請求項４】 前記メッセージ処理手段は、システムの
    立ち上げ時に、前記リソース管理オブジェクトから識別
    情報を取得し、 前記ツリー管理手段は、前記メッセージ処理手段が取得
    した前記リソース管理オブジェクトの識別情報を内部の
    テーブルで保持することで前記ツリー情報の管理を行う
    ことを特徴とする請求項１記載のオブジェクト管理シス
    テム。
  5. 【請求項５】 前記ツリー管理手段は、ツリー構造変更
    要求が入力された際には、前記ツリー構造更新要求に従
    って前記ツリー情報の更新を行うことを特徴とする請求
    項１記載のオブジェクト管理システム。
  6. 【請求項６】 前記メッセージ処理手段は、前記リソー
    ス管理オブジェクトが生成／削除される際に出力する生
    成／削除通知を受け取り、 前記オブジェクト管理手段は、前記メッセージ処理手段
    が受け取った生成／削除通知に応じて前記ツリー構造更
    新要求を前記ツリー管理手段へ出力することを特徴とす
    る請求項５記載のオブジェクト管理システム。
  7. 【請求項７】 前記オブジェクト管理手段は、前記リソ
    ース管理オブジェクトが削除された際には、前記ツリー
    管理手段が管理する前記ツリー情報に基づいて、削除さ
    れた前記リソース管理オブジェクトに包含される配下リ
    ソース管理オブジェクトの存否を確認し、前記配下リソ
    ース管理オブジェクトが存在する場合には、前記配下リ
    ソース管理オブジェクトを削除すると共に前記ツリー管
    理手段に対して前記配下リソース管理オブジェクトの削
    除に伴うツリー構造更新要求を出力することを特徴とす
    る請求項５記載のオブジェクト管理システム。
  8. 【請求項８】 前記オブジェクト管理手段は、前記被管
    理オブジェクトの生成処理を行う際には、前記ツリー管
    理手段が保持する前記ツリー情報に基づいて、生成すべ
    き被管理オブジェクトの属するリソース管理オブジェク
    トの上位リソース管理オブジェクトを前記ツリー情報か
    ら検索し、前記上位リソース管理オブジェクトが存在す
    る場合は、生成すべき前記被管理オブジェクトを包含す
    べき上位被管理オブジェクトの存否を前記上位リソース
    管理オブジェクトに対して確認し、前記上位被管理オブ
    ジェクトが存在していた場合にのみ前記被管理オブジェ
    クトの生成を行うことを特徴とする請求項１記載のオブ
    ジェクト管理システム。
  9. 【請求項９】 前記メッセージ処理手段は、クライアン
    トアプリケーションが直接前記リソース管理オブジェク
    トに対して前記被管理オブジェクトの生成要求を行った
    場合に、前記リソース管理オブジェクトが出力する上位
    被管理オブジェクトの存否チェック依頼を受け取り、 前記オブジェクト管理手段は、前記メッセージ処理手段
    が上位被管理オブジェクトの存否チェック依頼を受け取
    った際には、前記ツリー管理手段が保持する前記ツリー
    情報に基づいて、生成すべき被管理オブジェクトの属す
    るリソース管理オブジェクトの上位リソース管理オブジ
    ェクトを前記ツリー情報から検索し、前記上位リソース
    管理オブジェクトが存在する場合は、生成すべき前記被
    管理オブジェクトを包含すべき上位被管理オブジェクト
    の存否を前記上位リソース管理オブジェクトに対して確
    認し、前記上位被管理オブジェクトが存在していた場合
    にのみ前記被管理オブジェクトの生成を行うことを特徴
    とする請求項１記載のオブジェクト管理システム。
  10. 【請求項１０】 前記オブジェクト管理手段は、前記被
    管理オブジェクトの削除処理において、削除すべき被管
    理オブジェクトを管理するリソース管理オブジェクトの
    配下のすべてのリソース管理オブジェクトに対して、削
    除すべき被管理オブジェクトの配下の被管理オブジェク
    トの削除要求を出力することを特徴とする請求項１記載
    のオブジェクト管理システム。
  11. 【請求項１１】 前記メッセージ処理手段は、メッセー
    ジキューを設け、受け取った操作要求を前記メッセージ
    キューに格納すると共に、前記メッセージキューに先に
    格納された操作要求から順に処理を進めることを特徴と
    する請求項１記載のオブジェクト管理システム。
  12. 【請求項１２】 前記メッセージ処理手段は、前記リソ
    ース管理オブジェクトごとに前記メッセージキューを設
    けることを特徴とする請求項１１記載のオブジェクト管
    理システム。
  13. 【請求項１３】 前記メッセージ処理手段は、個々の前
    記リソース管理オブジェクトに対するオペレーション種
    別毎に前記メッセージキューを設けることを特徴とする
    請求項１１記載のオブジェクト管理システム。
  14. 【請求項１４】 複数のオブジェクト間の関係を階層的
    な包含木構造によって管理する情報処理システムにおい
    て、 管理対象となる被管理オブジェクトを管理する複数のリ
    ソース管理オブジェクトと、 前記リソース管理オブジェクトに対する操作要求を受け
    付けるメッセージ処理手段と、 前記リソース管理オブジェクトを特定するための識別情
    報及び前記リソース管理オブジェクト間の包含関係が定
    義されたツリー情報を保持するツリー管理手段と、 前記メッセージ処理手段が受け取った前記操作要求を送
    信すべき宛先リソース管理オブジェクトの識別情報を前
    記ツリー管理手段が管理するツリー情報により認識し、
    前記宛先リソース管理オブジェクトに対して前記操作要
    求を出力するオブジェクト管理手段と、を有することを
    特徴とする情報処理システム。
  15. 【請求項１５】 オブジェクト間の関係を階層的な包含
    木構造によって管理するオブジェクト管理プログラムを
    記録したコンピュータ読み取り可能な記録媒体におい
    て、 前記リソース管理オブジェクトに対する操作要求を受け
    付けるメッセージ処理手段、 前記リソース管理オブジェクトを特定するための識別情
    報及び前記リソース管理オブジェクト間の包含関係が定
    義されたツリー情報を保持するツリー管理手段、 前記メッセージ処理手段が受け取った前記操作要求を送
    信すべき宛先リソース管理オブジェクトの識別情報を前
    記ツリー管理手段が管理するツリー情報により認識し、
    前記宛先リソース管理オブジェクトに対して前記操作要
    求を出力するオブジェクト管理手段、としてコンピュー
    タを機能させることを特徴とするオブジェクト管理プロ
    グラムを記録したコンピュータ読み取り可能な記録媒
    体。
  16. 【請求項１６】 複数のオブジェクト間の関係を階層的
    な包含木構造によって管理する情報処理プログラムを記
    録したコンピュータ読み取り可能な記録媒体において、 管理対象となる被管理オブジェクトを管理する複数のリ
    ソース管理オブジェクト、 前記リソース管理オブジェクトに対する操作要求を受け
    付けるメッセージ処理手段、 前記リソース管理オブジェクトを特定するための識別情
    報及び前記リソース管理オブジェクト間の包含関係が定
    義されたツリー情報を保持するツリー管理手段、 前記メッセージ処理手段が受け取った前記操作要求を送
    信すべき宛先リソース管理オブジェクトの識別情報を前
    記ツリー管理手段が管理するツリー情報により認識し、
    前記宛先リソース管理オブジェクトに対して前記操作要
    求を出力するオブジェクト管理手段、としてコンピュー
    タを機能させることを特徴とする情報処理プログラムを
    記録したコンピュータ読み取り可能な記録媒体。
JP10256366A 1998-09-10 1998-09-10 オブジェクト管理システム、情報処理システム、オブジェクト管理プログラムを記録した記録媒体及び情報処理プログラムを記録した記録媒体 Pending JP2000090027A (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP10256366A JP2000090027A (ja) 1998-09-10 1998-09-10 オブジェクト管理システム、情報処理システム、オブジェクト管理プログラムを記録した記録媒体及び情報処理プログラムを記録した記録媒体
US09/334,172 US6760733B1 (en) 1998-09-10 1999-06-15 Object management system and data processing system with centralized mechanism for managing containment relationships among objects

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP10256366A JP2000090027A (ja) 1998-09-10 1998-09-10 オブジェクト管理システム、情報処理システム、オブジェクト管理プログラムを記録した記録媒体及び情報処理プログラムを記録した記録媒体

Publications (1)

Publication Number Publication Date
JP2000090027A true JP2000090027A (ja) 2000-03-31

Family

ID=17291695

Family Applications (1)

Application Number Title Priority Date Filing Date
JP10256366A Pending JP2000090027A (ja) 1998-09-10 1998-09-10 オブジェクト管理システム、情報処理システム、オブジェクト管理プログラムを記録した記録媒体及び情報処理プログラムを記録した記録媒体

Country Status (2)

Country Link
US (1) US6760733B1 (ja)
JP (1) JP2000090027A (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005085281A (ja) * 2003-09-08 2005-03-31 Microsoft Corp モバイル装置構成の設定を管理するｏｍａｄｍ拡張のためのシステムおよび方法
JP2009500759A (ja) * 2005-07-15 2009-01-08 フアウェイジシュヨウシアンゴンシ シンプルネットワーク管理プロトコルに基づいたデータ管理のための方法及びシステム
JP2011526119A (ja) * 2008-06-27 2011-09-29 テレフオンアクチーボラゲット エル エム エリクソン（パブル） 通信ネットワークシステムにおける方法及び装置

Families Citing this family (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2293062A1 (en) * 1999-12-22 2001-06-22 Ibm Canada Limited-Ibm Canada Limitee Efficient use of domain socket pairs in communication for tightly coupled transactions
US20020069288A1 (en) * 2000-08-10 2002-06-06 Rising Hawley K. Use of unique ID's in a distributed environment to make changes to an MPEG-7 description at run time
US6775700B2 (en) * 2001-03-27 2004-08-10 Intel Corporation System and method for common information model object manager proxy interface and management
JP3991628B2 (ja) * 2001-07-19 2007-10-17 セイコーエプソン株式会社 管理情報データベース構造定義ファイル結合方法、ネットワークデバイス管理システムおよび管理情報データベース構造定義ファイルを結合するための処理プログラムならびに管理デバイス
US20030126182A1 (en) * 2001-12-28 2003-07-03 Wyatt David A. Method and apparatus for managing physical and virtual resources within a multi-function integrated chipset
US20030126304A1 (en) * 2001-12-31 2003-07-03 Wyatt David A. Method for attaching a resource to a parent within a global resource namespace
US7996507B2 (en) * 2002-01-16 2011-08-09 International Business Machines Corporation Intelligent system control agent for managing jobs on a network by managing a plurality of queues on a client
US7085831B2 (en) * 2002-01-16 2006-08-01 International Business Machines Corporation Intelligent system control agent for managing jobs on a network by managing a plurality of queues on a client
US7389303B2 (en) * 2003-06-30 2008-06-17 Microsoft Corporation Method and system for supporting multiple independent transactional resource managers on a single logical volume
US7451431B2 (en) * 2003-12-12 2008-11-11 International Business Machines Corporation Registry driven real-time configuration of resource management objects for deployment in an instance of an integrated solutions console
US9268607B2 (en) * 2004-03-13 2016-02-23 Adaptive Computing Enterprises, Inc. System and method of providing a self-optimizing reservation in space of compute resources
CN100383733C (zh) * 2005-10-10 2008-04-23 华为技术有限公司 电子信息系统的软件子系统
US7818328B2 (en) * 2006-01-20 2010-10-19 Siebel Systems, Inc. API for obtaining unambiguous representation of objects in a relational database
US8706776B1 (en) 2006-06-30 2014-04-22 Sap Ag Extending status models in a computer system
US8522261B2 (en) * 2006-06-30 2013-08-27 Sap Ag Using status models with state guards in a computer system
US8365200B1 (en) * 2006-06-30 2013-01-29 Sap Ag Using cancellation status models in a computer system
US8577931B2 (en) * 2007-05-21 2013-11-05 Honeywell International Inc. Systems and methods for modeling building resources
US7783651B2 (en) * 2007-05-23 2010-08-24 Sap Ag Base tree node infrastructure
US7895599B2 (en) * 2007-05-23 2011-02-22 Sap Ag User interface independent remote interface data loader
US9928349B2 (en) * 2008-02-14 2018-03-27 International Business Machines Corporation System and method for controlling the disposition of computer-based objects
US8504980B1 (en) 2008-04-14 2013-08-06 Sap Ag Constraining data changes during transaction processing by a computer system
US8386457B2 (en) * 2011-06-22 2013-02-26 International Business Machines Corporation Using a dynamically-generated content-level newsworthiness rating to provide content recommendations
US8996472B2 (en) 2012-04-16 2015-03-31 Sap Se Verification of status schemas based on business goal definitions
US8996473B2 (en) 2012-08-06 2015-03-31 Sap Se Checking compatibility of extended and core SAM schemas based on complex goals
US10417594B2 (en) 2013-05-02 2019-09-17 Sap Se Validation of functional correctness of SAM schemas including action chains
CN104468339B (zh) * 2014-12-30 2018-03-27 合一网络技术(北京)有限公司 订阅消息管理方法及系统
US11379474B2 (en) 2020-02-19 2022-07-05 International Business Machines Corporation Computation of containment relationships
US11875156B2 (en) * 2021-09-14 2024-01-16 Open Text Holdings, Inc. System and method for centralized configuration of distributed and heterogeneous applications

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5165018A (en) * 1987-01-05 1992-11-17 Motorola, Inc. Self-configuration of nodes in a distributed message-based operating system
US5315057A (en) * 1991-11-25 1994-05-24 Lucasarts Entertainment Company Method and apparatus for dynamically composing music and sound effects using a computer entertainment system
US5608720A (en) * 1993-03-09 1997-03-04 Hubbell Incorporated Control system and operations system interface for a network element in an access system
JP3714483B2 (ja) * 1993-11-29 2005-11-09 三菱電機株式会社 マネジメント・インフォメーション・ベース・管理システム
JP3521955B2 (ja) * 1994-06-14 2004-04-26 株式会社日立製作所 階層型ネットワーク管理システム
JPH09270793A (ja) * 1996-04-03 1997-10-14 Sony Corp 通信制御方法
US6167438A (en) * 1997-05-22 2000-12-26 Trustees Of Boston University Method and system for distributed caching, prefetching and replication
US6425017B1 (en) * 1998-08-17 2002-07-23 Microsoft Corporation Queued method invocations on distributed component applications

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005085281A (ja) * 2003-09-08 2005-03-31 Microsoft Corp モバイル装置構成の設定を管理するｏｍａｄｍ拡張のためのシステムおよび方法
JP2009500759A (ja) * 2005-07-15 2009-01-08 フアウェイジシュヨウシアンゴンシ シンプルネットワーク管理プロトコルに基づいたデータ管理のための方法及びシステム
JP2011526119A (ja) * 2008-06-27 2011-09-29 テレフオンアクチーボラゲット エル エム エリクソン（パブル） 通信ネットワークシステムにおける方法及び装置
US8719394B2 (en) 2008-06-27 2014-05-06 Telefonaktiebolaget L M Ericsson (Publ) Method and arrangement for a modification of network management schema

Also Published As

Publication number Publication date
US6760733B1 (en) 2004-07-06

Similar Documents

Publication Publication Date Title
JP2000090027A (ja) オブジェクト管理システム、情報処理システム、オブジェクト管理プログラムを記録した記録媒体及び情報処理プログラムを記録した記録媒体
CN108199897B (zh) 一种支持缓存管理的opc ua多服务器聚合方法
EP0973296A2 (en) Controlling devices on a network through policies
JP3439337B2 (ja) ネットワーク管理システム
EP0772319B1 (en) Method and system for sharing information between network managers
US6915338B1 (en) System and method providing automatic policy enforcement in a multi-computer service application
US7181436B1 (en) Automatically generating replication topology information for use by a directory service
US6615230B2 (en) Data access right management apparatus in a data-independent computer system
US20010011277A1 (en) Network directory access mechanism
US20080059613A1 (en) System and Method for Enabling Directory-Enabled Networking
JPH04271454A (ja) 疎結合計算機システム
JPH11232226A (ja) 協同作業支援システム及び記録媒体
US20050149468A1 (en) System and method for providing location profile data for network nodes
US20030033410A1 (en) Machine resource management system, method and program
JP2001326660A (ja) コンピュータの構成情報管理方法および該方法を実現するプログラムを記録した記録媒体および装置
CN110851186A (zh) 网络设备重启的方法、装置、电子设备及可读存储介质
WO2022267646A1 (zh) 一种容器集的部署方法及装置
JP4272105B2 (ja) ストレージグループ設定方法および装置
JP2002014861A (ja) ファイルレプリケーションシステム、ファイルレプリケーション制御方法及び記憶媒体
US6622146B1 (en) System managing method and apparatus for decreasing a load applied to a common processing unit
JP5080636B2 (ja) レプリ処理方法、プログラム及び装置
JP2000357145A (ja) ネットワークデバイス管理装置および方法
JP3342735B2 (ja) Ｏｓｉインタフェース装置
JP3741818B2 (ja) 多数のコンピュータが参加する情報分配応答システム
WO2023127146A1 (ja) 情報処理システム及び情報処理方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20050606

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20070518

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20070605

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20070802

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20080422

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20080623

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20081111

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20090310