JPH0934820A

JPH0934820A - ネットワーク情報管理装置

Info

Publication number: JPH0934820A
Application number: JP7182621A
Authority: JP
Inventors: Yasuyuki Shimizu; 泰行清水
Original assignee: Fuji Xerox Co Ltd
Current assignee: Fujifilm Business Innovation Corp
Priority date: 1995-07-19
Filing date: 1995-07-19
Publication date: 1997-02-07

Abstract

(57)【要約】【目的】特定のネットワーク情報に依存しないで、サ
ーバ間の情報交換ができるネットワーク情報管理装置を
提供することを目的とする。【構成】情報一元管理サーバにおけるネットワーク情
報管理装置は、複数のネットワーク情報管理部３０ａ〜
３０ｄからのネットワーク情報を個々に受け付ける情報
受付手段２１ａ〜２１ｄと、受け付けたネットワーク情
報をそれぞれ独自のデータ構造から共通のデータ構造に
変換するデータ構造変換手段２２ａ〜２２ｄと、共通の
データ構造に変換されたネットワーク情報を基にして情
報の一元管理を行う情報モデル管理手段２３とを有して
いる。複数のサーバ間の情報交換はこの共通化されたデ
ータ構造の情報で行う。このため、上に実装されるネッ
トワーク情報管理部はサーバ間の情報交換を考慮するこ
となく独自のデータ構造を持つ情報を使用することがで
きるので、実装が容易になる。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明はネットワーク情報管理装
置に関し、特にネットワークにおけるユーザ情報、サー
バ情報などのネットワーク情報を一元的に管理すること
ができるネットワーク情報管理装置に関する。

【０００２】

【従来の技術】近年、ワークステーションまたはパーソ
ナルコンピュータによってそれぞれ構成することができ
る複数のクライアントおよび複数のサーバがローカルエ
リアネットワーク（ＬＡＮ）によって相互に接続されて
構成されているクライアント・サーバシステムが普及し
てきている。このシステム内にて、ネットワーク情報を
一元管理しているのが情報一元管理サーバである。

【０００３】図８はクライアント・サーバシステムの概
略を示すシステム構成図である。図示の構成例によれ
ば、クライアント・サーバシステムは複数のクライアン
ト１，２と複数のサーバ３，４，５とによって構成さ
れ、これらはそれぞれ通信機能を使ってネットワーク６
に相互に接続されている。サーバ３，４，５はそれぞれ
異なった観点からネットワーク資源を管理するものであ
り、たとえばネットワーク上でプリンタを共有するのに
使用するプリントサーバであったり、ネットワーク上の
ファイルを共有するのに使用するファイルサーバであっ
たり、ネットワーク上のユーザ情報やサーバ情報などの
ネットワーク情報を一元管理する情報一元管理サーバで
あったりする。

【０００４】ここで、情報一元管理サーバについて説明
する。ネットワーク環境においては、ユーザが必要とす
る情報はネットワークの各所に分散しているために、ネ
ットワーク内の情報を管理する機構が必要になる。たと
えば、ユーザ名やそのパスワードなどのユーザ情報を一
括管理しておくことにより、ユーザはネットワーク上の
どのクライアントマシンを使用しても認証を行うことが
できるし、サーバ名やサーバアドレスなどのサーバ情報
を一括管理しておくことにより、ユーザはどのクライア
ントマシンを使用していても必要なサーバにアクセスす
ることができるようになる。

【０００５】また、ネットワーク情報をユーザの利用形
態に応じてドメイン（領域）という単位に分割して管理
することにより、ユーザはネットワーク情報をより選択
し易くすることができる。

【０００６】ここで、いわゆるネットワーク上の情報管
理においては、他のドメインを管理している情報管理サ
ービスとの管理情報の交換が重要となる。また、同一ド
メインを複数台の情報管理サービスで管理しているよう
な場合でも、一台の情報管理サービスに障害が発生した
ときに、同一ドメインを管理する複数台の情報管理サー
ビス間で情報管理を行うことができるようにするための
管理情報の交換が重要となる。

【０００７】このような管理情報の交換ができることに
より、ユーザは所属しているドメイン以外のドメインの
ネットワーク情報を使用することができるし、また、情
報管理サービスの障害によるネットワーク情報にアクセ
スできない事態を避けることができる。

【０００８】ネットワーク上の情報管理についての従来
例としては、複数のドメイン間での管理情報の交換につ
いて開示した特開平７−４９８２６号公報、複数のサー
バ間でのデータの交換の際のデータの更新手続きについ
ての方式を開示した特開平５−５３８９６号公報、サー
バを複数個立ち上げて、１つのサーバがクラッシュして
もネットワーク全体が停止しないように対処した環境に
おいて、クライアントがどのサーバを使用するかを設定
するアルゴリズムを開示した特開平５−７５６３７号公
報などがある。

【０００９】

【発明が解決しようとする課題】これまで、ネットワー
ク上で管理しなければならない情報は限られたものであ
った。管理情報としては、たとえば、ユーザ名、パスワ
ード、ユーザ別名（ａｌｉａｓ）、サーバ名、サーバア
ドレス程度であり、これらはネットワーク管理や有効利
用に必要な情報をサービスする、たとえば、ＮＩＳ（Ne
twork Information Service）、ＷｉｎｄｏｗｓＮＴ
（マイクロソフト社）のサーバなどを使用して管理して
いた。

【００１０】これまで、これらユーザ情報およびサーバ
情報の限定されたネットワーク情報の管理においては、
情報を個別に管理し、データに密接して上記のドメイン
間の情報交換や複数サーバ間の情報交換を行っている。

【００１１】この情報を個別に管理する方式では、想定
されていない種類のネットワーク情報を管理しようとす
ると、その種類の情報に対して新たにデータを定義し上
記のサーバ間情報交換を新たに実装しなければならな
い。実際、ネットワーク上に分散されたファイルを管理
するファイルサーバにおいても、ファイルの属性名、属
性識別子、属性型、デフォルト値などの属性情報や、フ
ァイルが所属するキャビネットのキャビネット名、キャ
ビネットの存在するサーバ名、サーバの存在するサーバ
アドレス、キャビネットの説明などのキャビネット情報
の管理も必要になってきている。これらの多種多様なネ
ットワーク情報の管理を従来方式では個別に実装してい
たので、ムダが多く、開発期間も長くなる。また、同種
のバグが複数箇所に分散してしまうことにもなるという
問題点があった。

【００１２】本発明はこのような点に鑑みてなされたも
のであり、ユーザ情報やサーバ情報のような特定のネッ
トワーク情報に依存しないで、サーバ間の情報交換がで
き、管理サービスが拡張された場合でもサービスの変更
が最小限で済むようなネットワーク情報管理装置を提供
することを目的とする。

【００１３】

【課題を解決するための手段】図１は上記目的を達成す
る本発明の原理図である。この図において、情報一元管
理サーバにおけるネットワーク情報管理装置は、プラッ
トフォーム１０の上に載ったネットワーク情報一元管理
手段２０を具備し、この上に各種サービスを実現するネ
ットワーク情報管理部３０ａ，３０ｂ，３０ｃ，・・・
３０ｄが実装されている。ネットワーク情報一元管理手
段は、複数のネットワーク情報管理部からのそれぞれ独
自のデータ構造を有するネットワーク情報を個々に受け
付ける情報受付手段２１ａ，２１ｂ，２１ｃ，・・・２
１ｄと、この情報受付手段にて受け付けたネットワーク
情報のデータ構造を共通のデータ構造に変換するデータ
構造変換手段２２ａ，２２ｂ，２２ｃ，・・・２２ｄ
と、このデータ構造変換手段にて共通のデータ構造に変
換されたネットワーク情報を基にして情報の一元管理を
行う情報モデル管理手段２３とを有している。

【００１４】

【作用】上述の手段によれば、ネットワーク情報管理部
３０ａ，３０ｂ，３０ｃ，・・・３０ｄにてそれぞれ独
自のデータ構造を有するネットワーク情報、たとえばユ
ーザ情報、サーバ情報、属性情報、資源情報などが管理
されており、これらのネットワーク情報はそれぞれ情報
受付手段２１ａ，２１ｂ，２１ｃ，・・・２１ｄを介し
てデータ構造変換手段２２ａ，２２ｂ，２２ｃ，・・・
２２ｄで共通のデータ構造を有する情報に変換される。
情報モデル管理手段２３は、データ構造が共通化された
ネットワーク情報にてネットワーク上の資源の情報を一
元管理する。情報モデル管理手段２３は、また、この共
通のデータ構造を有する情報によって複数のサーバ間の
情報交換を行うことができる。さらに、本ネットワーク
情報管理装置の上に実装されるネットワーク情報管理部
は複数のサーバ間の情報交換を考慮することなく独自の
データ構造を持つ情報を使用することができ、これによ
り、ユーザ情報、サーバ情報、属性情報、資源情報など
の上位サービスの実装が非常に容易になる。

【００１５】

【実施例】以下、本発明の実施例を添付図面を参照して
説明する。図２は本発明のネットワーク情報管理装置を
含む情報一元管理サーバの構成例を示すブロック図であ
る。

【００１６】図２によれば、情報一元管理サーバはネッ
トワーク情報を個別に管理する複数の管理部を有し、こ
こでは、ユーザ情報管理部４１、サーバ情報管理部４
２、属性情報管理部４３、資源情報管理部４４、および
その他の情報管理部４５を有している。これら管理部は
情報受付部５０に接続され、この情報受付部５０はネッ
トワーク情報毎に有する個別のデータ構造を共通のデー
タ構造にマッピングするデータ構造変換部６０に接続さ
れている。データ構造変換部６０は共通のデータ構造に
変換されたネットワーク情報ですべてのネットワーク情
報を管理する情報モデル管理部７０に接続されている。
情報モデル管理部７０は名称／識別子対応管理部８０お
よびオブジェクト属性管理部９０を介してプラットフォ
ーム対応部１００に接続され、また、同一領域管理部１
１０および分割領域管理部１２０に接続されている。プ
ラットフォーム対応部１００、同一領域管理部１１０お
よび分割領域管理部１２０はそれぞれプラットフォーム
１３０に接続されている。

【００１７】データ構造変換部６０で変換されたネット
ワーク情報は、実際には、プラットフォーム１３０を通
じてこの情報一元管理サーバの図示しないどこかに置か
れる。情報モデル管理部７０はそのネットワーク情報の
登録や検索などを行ったり、同一領域管理部１１０およ
び分割領域管理部１２０を通じて本装置がネットワーク
を複数領域に分割した場合の処理、およびマスタ／スレ
ーブ方式のような同一領域内の管理による信頼性の向上
に対応した場合の処理を行う。また、構造の詳細は後述
するが、共通のデータ構造の情報が有する名称および識
別子については名称／識別子対応管理部８０が、その情
報に付けられた属性はオブジェクト属性管理部９０がそ
れぞれ管理する。プラットフォーム対応部１００はプラ
ットフォーム１３０が採用しているオペレーティングシ
ステムに応じて構成され、ネットワーク情報管理装置か
らはプラットフォーム１３０の違いを吸収するようにし
ている。

【００１８】情報モデル管理部７０において、情報をこ
のような汎用性のある共通のデータ構成にしておくこと
により、ユーザ情報管理部４１、サーバ情報管理部４
２、属性情報管理部４３、資源情報管理部４４、および
その他の情報管理部４５のいわゆる上位サービスが管理
しているネットワーク情報は、複数サーバ間での資源管
理情報の交換を考慮することなく、データ構造変換部６
０において独自データと共通データとのマッピングを行
うだけでよい。すなわち、上位サービスの実装が非常に
容易となり、また、容易に新たな上位サービスの追加を
行うことが可能になる。

【００１９】また、前記のように、上位サービスはネッ
トワーク情報管理装置とのデータをやり取りするだけで
特定の情報一元管理サービスを実装することができる。
つまり、上位サービスは、ネットワーク情報管理装置が
どのような形式でデータを保管しているのかに依存しな
いし、プラットフォーム対応部１００によってどのよう
なプラットフォームを使用しているのかに依存しない。
このため上位サービスはデータの保管方法およびプラッ
トフォームに依存しないものとなり、ソフトウェアの移
植性が高くなる。

【００２０】図３はネットワーク情報管理装置で管理す
る情報モデルのデータ構造を示す図である。ネットワー
ク上で一元管理すべきネットワーク情報は図２のように
抽象化される。すなわち、ネットワーク情報１４０は、
情報の種類を表す「種別」１４１と、情報を識別するた
めの一意な値が入る「識別子」１４２と、情報を識別す
るための一意な名前が入る「名称」１４３とからなり、
これに属性型１４４および属性値１４５の属性が付く構
成になっている。

【００２１】ここで、「種別」１４１は、ネットワーク
情報１４０の種類が、たとえば「ユーザ情報」であれば
「ユーザ」、「サーバ情報」であれば「サーバ」が入
る。「識別子」１４２はこのネットワーク情報１４０を
識別するための一意な値、たとえばネットワーク情報１
４０の種類が「ユーザ情報」であれば「ユーザ番号」が
入る。「名称」１４３はこのネットワーク情報１４０を
識別するための一意な名前、たとえばネットワーク情報
１４０の種類が「ユーザ情報」であればクライアントマ
シンにログインするときのユーザアカウント名である
「ユーザ名」が入る。このネットワーク情報１４０に付
加される属性は、どのグループに属するかを表す「属性
型」１４４とその「属性値」１４５とからなり、たとえ
ばネットワーク情報１４０の種類が「ユーザ情報」であ
り、これにパスワードを設定した場合には、パスワード
を表す「属性型」１４４のところの「属性値」１４５
に、パスワードを示す値が入り、ネットワーク情報１４
０の種類が「サーバ情報」であれば、この属性として
は、たとえばサーバのアドレス、サーバの説明（サーバ
の所有者名など）などが入る。

【００２２】このように、ネットワーク情報１４０の種
類がたとえば「ユーザ情報」であって、たとえば各ユー
ザはパスワード、ユーザの説明情報を持つとすれば、そ
れぞれ属性型を割り振って、その属性値としてこれらの
値を保管することになる。すなわち、情報モデル管理部
７０はこの情報モデルを唯一の情報形式として取り扱
う。ネットワーク上で一元管理すべき情報はすべてこの
図３の形式に置き換えて保管・取り出し・検索が行われ
る。ネットワーク情報管理装置の上に載っているユーザ
情報管理部４１、サーバ情報管理部４２、属性情報管理
部４３、資源情報管理部４４、その他の情報管理部４５
が提供するサービスを上位サービスというが、これらが
取り扱う情報をどのようにしてこの情報モデルに当ては
めるかは上位サービスの実現による。また、上位サービ
スは種別を重ならないように取扱い、他の上位サービス
の取り扱うデータに影響を及ぼさないようにする。

【００２３】この情報モデルはファイルとディレクトリ
を用いて実現することができる。以下に、情報モデル管
理部７０が名称／識別子対応管理部８０、オブジェクト
属性管理部９０、およびプラットフォーム対応部１００
を通じてプラットフォーム１３０に載っているたとえば
ディスクシステム上に情報モデルを保存する例について
示す。

【００２４】図４はネットワーク情報をファイルシステ
ムを用いて保存する場合の一例を示す図である。図中、
丸枠はディレクトリ、四角枠はファイルを示す。情報モ
デル管理部７０はデータルートディレクトリ１５０の下
にデータを保管する。データルートディレクトリ１５０
の下には「種別１」，「種別２」，「種別ｎ」と、種別
毎に種別ディレクトリ１５１，１５２，１５３が作られ
る。種別ディレクトリ、たとえば「種別２」の種別ディ
レクトリ１５２の下には次にどの識別子を割り振るかを
示すファイルである識別子インデックスファイル１６１
と、識別子と名称を対応させるテーブルである名称イン
デックスファイル１６２と、種別ディレクトリ下のファ
イル数が増え過ぎないように幾つかの数ごとに属性ファ
イル（属性型と属性値を対応させるテーブル）を取りま
とめる「識別子ｄｉｒ０１」，「識別子ｄｉｒ０２」お
よび「識別子ｄｉｒｎ」なる識別子ディレクトリ１５
４，１５５，１５６とがある。そして、識別子ディレク
トリ、ここでは「識別子ｄｉｒ０２」の識別子ディレク
トリ１５５の下には属性ファイル１６３、１６４、１６
５、１６６が入れられている。なお、ディレクトリ内の
ファイル数を気にしないのであれば、識別子ディレクト
リは必要ない。

【００２５】識別子インデックスファイル１６１は次に
割り振る識別子もしくはオブジェクトが削除されて再利
用できる識別子を記述しておく。名称インデックスファ
イル１６２および属性ファイル１６３、１６４、１６
５、１６６の形式はたとえば、特開平３−１７７５３号
公報に記載の「ファイルアクセス方式」に記述された形
式を用いて変換テーブルを実現している。属性ファイル
は識別子から容易に指定できるようなファイル名にして
おくとよい。たとえば、識別子を文字列に変換したもの
をファイル名にする。

【００２６】この情報に対する操作としては、たとえ
ば、「オブジェクト生成」、「名称変更」、「オブジェ
クト削除」、「属性設定（属性型と属性値を組で指定す
る）」、「属性削除」、「属性取り出し」、「オブジェ
クトに付加された属性型の一覧を取る」、「オブジェク
ト検索（条件を指定して、一致するオブジェクト群を得
る）」、「識別子から名称を得る」、「名称から識別子
を得る」がある。

【００２７】これらの操作の手順を以下に示す。「オブ
ジェクト生成」の操作の場合は、まず、名称インデック
スファイル１６２を見て、名称が既存でないことを確認
し、識別子インデックスファイル１６１を見て、作成し
たオブジェクトに割り振る値を決める。識別子インデッ
クスファイル１６１に次のオブジェクトに指定する識別
子を書き込み、名称インデックスファイル１６２に名称
と識別子との組を保管し、そのオブジェクトに対する中
身が空の属性ファイルを指定する。

【００２８】「名称変更」の操作の場合は、名称インデ
ックスファイル１６２を見て、指定されたオブジェクト
が存在することを確認し、名称インデックスファイル１
６２のそのオブジェクトに対する名称を書き換える。

【００２９】「オブジェクト削除」の操作の場合は、名
称インデックスファイル１６２を見て、指定されたオブ
ジェクトが存在することを確認し、名称インデックスフ
ァイル１６２からそのオブジェクトのエントリを削除
し、そのオブジェクトに対応する属性ファイルを削除す
る。

【００３０】「属性設定（属性型と属性値を組で指定す
る）」の操作の場合は、名称インデックスファイル１６
２を見て、指定されたオブジェクトが存在することを確
認し、そのオブジェクトの属性ファイルに指定された属
性を書き込む。

【００３１】「属性削除」の操作の場合は、名称インデ
ックスファイル１６２を見て、指定されたオブジェクト
が存在することを確認し、そのオブジェクトの属性ファ
イルから指定された属性を削除する。

【００３２】「属性取り出し」の操作の場合は、名称イ
ンデックスファイル１６２を見て、指定されたオブジェ
クトが存在することを確認し、そのオブジェクトの属性
ファイルから指定された属性を読み出す。

【００３３】「オブジェクトに付加された属性型の一覧
を取る」の操作の場合は、名称インデックスファイル１
６２を見て、指定されたオブジェクトが存在することを
確認し、そのオブジェクトの属性ファイルから設定され
ている属性を一覧する。

【００３４】「オブジェクト検索（条件を指定して、一
致するオブジェクト群を得る）」の操作の場合は、各名
称インデックスファイル１６２および各属性ファイルを
見て、指定された条件に一致するオブジェクトを一覧す
る。

【００３５】「識別子から名称を得る」の操作の場合
は、名称インデックスファイル１６２を見て、指定され
たオブジェクトの名称を得る。「名称から識別子を得
る」の操作の場合は、名称インデックスファイル１６２
を見て、指定されたオブジェクトの識別子を得る。

【００３６】このように、プラットフォームとなるオペ
レーティングシステムのファイルシステム上に情報モデ
ルのデータを作成すれば、ファイルおよびディレクトリ
の階層構成ファイルシステムを持つオペレーティングシ
ステムに移植することが容易である。

【００３７】また、情報モデルはプラットフォーム１３
０に載っているたとえばデータベースを利用し、保存す
るすることができる。以下、この例について説明する。
図５はネットワーク情報をデータベースを用いて保存す
る場合の例を示す図である。

【００３８】データベースにおいて、図示のようなフィ
ールドを有するテーブル１７０を作成し、これに、デー
タ構造変換部６０によってネットワーク情報管理装置の
データ構造に変換された上位サービスのネットワーク情
報が格納される。

【００３９】テーブル１７０は、ネットワーク情報１４
０の構造に合わせて、「種別」フィールド、「識別子」
フィールド、「名称」フィールド、「属性型」フィール
ド、「属性値」フィールドを有している。この例によれ
ば、たとえば、最初のエントリを見ると、「種別」フィ
ールドにはたとえばユーザ情報であることを示す「１」
が、「識別子」フィールドにはたとえば「０００１」
が、「名称」フィールドにはたとえば「ＡＢＣ」が、
「属性型」フィールドにはたとえば「０００１」が、そ
して「属性値」フィールドには「ｐａｓｓｗｏｒｄ１」
が入っている。

【００４０】ネットワーク情報をユーザとやり取りする
場合は、上位サービスの持つデータ構造をネットワーク
情報管理装置のデータ構造に直してこのテーブル１７０
に格納し、格納された情報を取り出すときはデータベー
スの検索機能などを用いて逆の経路を辿り、上位サービ
スの持つデータ構造に直してユーザに提供される。

【００４１】このように、データベースを使用すること
により、上位サービスがネットワーク情報一元管理サー
ビスの複数のオブジェクトを使用する際に、トランザク
ション処理が可能になり、より複雑な検索機能の実現が
容易となる。

【００４２】次に、上位サービスの、たとえばユーザ情
報管理部におけるユーザ登録の場合の処理内容について
説明する。図６はユーザ登録の処理内容を示すフローチ
ャートである。

【００４３】ユーザ登録処理を行う場合には、まず、既
に同一ユーザが登録されているかどうかをチェックする
（ステップＳ１）。ここで、既に登録済みであれば、登
録済エラーの処理をして終了する（ステップＳ２）。登
録がなければ、ユーザオブジェクトを作成する（ステッ
プＳ３）。ここで、ユーザオブジェクトの作成が正常に
終了したかどうかを判断し（ステップＳ４）、正常に終
了しなければ、システムエラーの処理をし（ステップＳ
５）、正常に終了すれば、ユーザオブジェクトの属性と
してパスワードを設定する（ステップＳ６）。パスワー
ドの設定が正常に終了したかどうかを判断し（ステップ
Ｓ７）、正常に終了しなければ、システムエラーの処理
をし（ステップＳ５）、正常に終了すれば、ユーザ登録
処理は完了となる。

【００４４】従来ではこれらの処理の他に複数資源管理
サーバ間での情報の整合性を取る処理が必要になるが、
この処理をネットワーク情報管理装置が行うために、上
位サービスでは処理する必要はない。

【００４５】次に、上位サービスのユーザ情報管理部に
おけるパスワードの変更の場合の処理内容について説明
する。図７はパスワードの変更の処理内容を示すフロー
チャートである。

【００４６】パスワードの変更処理を行う場合には、ま
ず、指定したユーザが登録されているかどうかをチェッ
クする（ステップＳ１１）。ここで、登録済みでなけれ
ば、不正ユーザ名エラーの処理をし（ステップＳ１
２）、登録がなされていれば、ユーザオブジェクトの属
性に設定されているパスワードを変更する（ステップＳ
１３）。そして、このパスワードの変更が正常に終了し
たかどうかを判断し（ステップＳ１４）、正常終了でな
ければ、システムエラーの処理をし（ステップＳ１
５）、正常に終了すれば、パスワードの変更処理は完了
となる。

【００４７】パスワードの変更処理の場合も同様に、従
来はこれらの処理の他に複数資源管理サーバ間での情報
の整合性を取る処理が必要になるが、この処理をネット
ワーク情報管理装置が行うために、上位サービスでは処
理する必要はない。

【００４８】

【発明の効果】以上説明したように本発明では、ネット
ワーク情報のデータ構造を独自のデータ構造から汎用性
のある共通のデータ構造に変換してその変換した情報で
一元管理するようにしたので、ネットワーク上で一元的
に管理すべき情報の種類は限定されず、データの操作を
単純化することができる。

【００４９】ネットワーク情報管理装置がネットワーク
内の情報の一元性を保つために、上位サービスは情報の
一元性を考慮することなく情報の保管、取り出しを行う
ことができる。たとえば、ネットワーク内をいくつかの
領域に分割し、その領域間の情報の一元性を保証するよ
うにネットワーク情報管理装置の機能が向上した場合で
も、また、たとえば、２台のサーバを設置してマスタ／
スレーブ方式でネットワーク情報管理装置の信頼性を向
上させたとしても、上位サービスの変更は最小限にする
ことができる。

【００５０】さらに、ネットワーク情報管理装置が上位
サービスとプラットフォームとの仲介をしているので、
別のプラットフォームに乗せようとする場合には、その
プラットフォームに対応させる部分のみを一部手直しす
るだけでよく、上位サービスの手直しは必要ない。

【図面の簡単な説明】

【図１】本発明のネットワーク情報管理装置の原理構成
を示すブロック図である。

【図２】本発明のネットワーク情報管理装置を含む情報
一元管理サーバの構成例を示すブロック図である。

【図３】ネットワーク情報管理装置で管理する情報モデ
ルのデータ構造を示す図である。

【図４】ネットワーク情報をファイルシステムを用いて
保存する場合の一例を示す図である。

【図５】ネットワーク情報をデータベースを用いて保存
する場合の例を示す図である。

【図６】ユーザ登録の処理内容を示すフローチャートで
ある。

【図７】パスワードの変更の処理内容を示すフローチャ
ートである。

【図８】クライアント・サーバシステムの概略を示すシ
ステム構成図である。

【符号の説明】

１０プラットフォーム２０ネットワーク情報一元管理手段２１ａ，２１ｂ，２１ｃ，２１ｄ情報受付手段２２ａ，２２ｂ，２２ｃ，２２ｄデータ構造変換手段２３情報モデル管理手段３０ａ，３０ｂ，３０ｃ，３０ｄネットワーク情報管
理部

Claims

【特許請求の範囲】

【請求項１】ネットワーク上のネットワーク情報を一
元管理するネットワーク情報管理装置において、複数のネットワーク情報管理部からのそれぞれ独自のデ
ータ構造を有するネットワーク情報を個々に受け付ける
情報受付手段と、前記情報受付手段にて受け付けたネットワーク情報のデ
ータ構造を共通のデータ構造に変換するデータ構造変換
手段と、前記データ構造変換手段にて前記共通のデータ構造に変
換されたネットワーク情報を基に情報の一元管理を行う
情報モデル管理手段と、を有するネットワーク情報一元管理手段を具備している
ことを特徴とするネットワーク情報管理装置。