JPH08255133A - 分散型サーバシステムにおけるユーザｉｄ管理装置と方法 - Google Patents

Abstract

(57)【要約】 【目的】 サーバが分散して配置された分散型サーバシ
ステムのユーザＩＤ管理装置と方法に関し、分散型サー
バシステムのいずれのサーバにアクセスしても一元管理
された利用の登録ができ、時間的、経済的に効率良い利
用ができ、自由にサーバを選択して利用できるようにす
る手段を提供することを目的とする。 【構成】 各サーバが利用登録を受け付けたユーザのＩ
Ｄ管理情報を受信して各サーバ毎のＩＤ管理情報として
一括して登録するＩＤ登録手段１と、前記ＩＤ登録手段
１で登録されたＩＤ管理情報を利用登録を受け付けたサ
ーバ以外のサーバに通知するＩＤ通知管理手段２を有す
るように構成する。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は分散して配置されたサー
バシステムのユーザＩＤ管理装置と方法に関する。

【０００２】サーバシステムは登録されたユーザに対し
て、端末を経由して各種の情報を提供し、さらには多く
のユーザ間のコミュニケーションの道具として情報の交
換を行う機能を持つものである。

【０００３】上記の登録された各ユーザにはシステムの
利用に際して利用の権利を確認するための識別番号、パ
スワード等を発行し、ユーザＩＤ管理装置が管理、運用
する。

【０００４】また、分散サーバシステムは地域的に分散
して複数のサーバを設置し、センタサーバを介して有機
的に結合され、処理の分担と連携を実現するものであ
る。

【０００５】

【従来の技術】従来、集中型サーバシステムの構築にお
いては、データおよびＩＤの管理を一元的に行っている
ために、利用者はどの端末からでも自由に利用すること
ができた。また、従来も、サーバシステムのユーザが広
範囲にわたる場合や、ユーザ数が多い場合には、分散型
サーバシステムの適用が望まれることがあった。

【０００６】しかし、次に示すように、従来の分散型サ
ーバシステムの構築においては、集中型と同様にはシス
テムを運用することが難しい面があった。運用方法とし
て、ＩＤ管理を１つのサーバで集中して行うシステム
と、もう一つは電子メールシステムの標準プロトコルで
あるＭＨＳ（Ｍｅｓｓａｇｅ Ｈａｎｄｌｉｎｇ Ｓｙ
ｓｔｅｍ）を利用してデータは交換して各サーバに備
え、ＩＤの管理は各サーバでそれぞれに登録されたＩＤ
を管理するシステムがある。

【０００７】ところが、前者のシステムにおいては、遠
隔のサーバ間をＷＡＮ（ＷｉｄｅＡｒｅａ Ｎｅｔｗｏ
ｒｋ）で接続した場合、中継回線が低速であるとＩＤの
確認などに時間を要しレスポンスが低下することが避け
られない。

【０００８】また、後者のシステムにおいては、サーバ
間をＷＡＮ接続した場合においても、データについては
ＭＨＳにより定期的に交換されていて、回線を経由せず
に利用できるため、中継回線によるレスポンスの低下は
ないが、ＩＤ管理情報については各サーバが個別に保
持、管理しているため、他のサーバには利用登録されて
いるが、アクセスされたサーバにはＩＤが登録されてい
ないユーザについては、そのＩＤを受け付けることでき
ず利用が許されないことになる。

【０００９】図６〜図９に従って従来例の構成と動作を
説明する。図６は従来の分散型サーバシステムの原理を
示す構成例である。センタサーバ61は他の各サーバ(62a
〜62c)のＩＤ管理を一元的に行っているＩＤ管理サーバ
である。図中「ＩＤ管理＃１」〜「ＩＤ管理＃３」は＃
１〜＃３のサーバのＩＤ管理の領域を示している。ま
た、「データ＃１」〜「データ＃３」は各サーバのデー
タの領域を示している。

【００１０】図７のフローチャート例により図６の構成
例の動作を説明する。ステップS71においてユーザがサ
ーバ＃１にＩＤを提示して利用しようとしたとき、ステ
ップS72 においてサーバ＃１からセンタサーバ（ＩＤ管
理サーバ）に、上記提示されたＩＤが登録されたもので
あり正当な利用の権利があるか否かのＩＤ照合を行い登
録済ＩＤであるか否かを確認する。ＯＫならば利用開始
が許可される（ステップS73)。ＯＫでないときは利用を
受け付けたサーバが利用申請に基づきＩＤ管理手続きの
後、センタサーバ（ＩＤ管理サーバ）に新規にＩＤを登
録を行う (ステップS74)。

【００１１】このように、各サーバは新規ＩＤの登録時
だけでなく、利用開始のためのＩＤの照合毎にセンタサ
ーバとの接続が必要となり、センタサーバとの間の中継
回線における接続および伝送時間のためにレスポンスに
影響を受ける。また、データは各サーバそれぞれに登録
されたもののみがアクセス可能であり他のサーバに格納
されているデータはアクセスできない。

【００１２】図８および図９にもう一つの従来の分散型
サーバシステムの構成と動作の例を示す。図８はＩＤ管
理は各サーバがそれぞれのローカルなＩＤのみを管理し
ている従来の分散型サーバシステムの原理を示すもう一
つの構成例である。「サーバ＃０」81はセンタサーバで
あるがセンタとしての役割を追加して持つ以外は他のサ
ーバ 82a〜82c と同様のサービス機能をもち、ＩＤ管理
はセンタサーバ81を含めて各サーバ毎にローカルなＩＤ
のみを管理している。

【００１３】データについてはセンタサーバ81が各サー
バ82a 〜82c のデータ＃０〜データ＃３をＭＨＳにより
定期的に交換しており、各サーバには「データ＃０〜
３」が格納されており全て共用できるようになってい
る。

【００１４】図中「ＩＤ管理＃０」〜「ＩＤ管理＃３」
はＩＤ管理の領域を示しており、＃Ｎは＃Ｎサーバで登
録されたＩＤであることを表している。また、「データ
＃０〜３」はサーバ＃０〜サーバ＃３に入力されたデー
タをすべて格納していることを示している。

【００１５】図９に示すようにその動作は、サーバ＃１
にＩＤによるアクセスがあって場合、サーバ＃１では、
まずＩＤの照合が行われる（ステップS92 ）。その結果
から登録の有無を確認して登録されていないときは、サ
ーバ＃１に新規にＩＤの登録を行った後利用を開始する
ことができる（ステップS94 ）。ただし、新規のＩＤの
登録は他のサーバには反映されないので、他のサーバか
らアクセスするときは再度ＩＤ登録の必要がある。

【００１６】

【発明が解決しようとする課題】上記の従来の技術にお
いて述べたように、従来の分散型サーバシステムでは、
ＩＤの管理について利用開始手続きに時間がかかった
り、利用登録をしたサーバ以外のサーバについては利用
ができないという問題があった。

【００１７】本発明はこのような点にかんがみて、分散
型サーバシステムのいずれのサーバにアクセスしても一
元管理された利用の登録ができ、時間的、経済的に効率
良い利用ができ、自由にサーバを選択して利用できるよ
うにする手段を提供することを目的とする。

【００１８】

【課題を解決するための手段】上記の課題は下記の如く
に構成された分散型サーバシステムにおけるユーザＩＤ
管理装置と方法によって解決される。

【００１９】図１は、本発明の構成図である。ＩＤ登録
手段１は、分散して配置され、ネットワークで接続され
た複数のサーバからなる分散型サーバシステムにおい
て、各サーバが利用登録を受け付けたユーザのＩＤ管理
情報を受信して各サーバ毎のＩＤ管理情報として一括し
て登録するものである。また、ＩＤ通知管理手段２はＩ
Ｄ登録手段１で登録されたＩＤ管理情報を、利用登録を
受け付けたサーバ以外のサーバに通知するものである。

【００２０】

【作用】分散して配置され、ネットワークで接続された
複数のサーバからなる分散型サーバシステムにおいて、
ＩＤ登録手段１は、各サーバが利用登録を受け付けたユ
ーザのＩＤ管理情報を受信して各サーバ毎のＩＤ管理情
報として一括して登録し、上記登録されたＩＤ管理情報
を、ＩＤ通知管理手段２が利用登録を受け付けたサーバ
以外のサーバに通知するようにしている。

【００２１】

【実施例】図２に実施例のネットワーク構成図、図３に
その動作説明用フローチャートを示す。

【００２２】実施例は電話、ＦＡＸ、データ端末から各
アクセスポイントに電話網 24a〜24c 経由でアクセスし
た場合のＩＤによる管理の構成を示している。図２にお
いて、センタサーバ21はメディアサーバ＃１〜＃３(22a
〜22c)を各アクセスポイントとする分散型サーバシステ
ムの中でＩＤ管理およびデータ管理について各メディア
サーバのＩＤ管理情報とデータの全体の交換制御を行う
機能を備えているものである。

【００２３】各メディアサーバ22a 〜22c は電話網を経
由して電話機、ＦＡＸやデータ端末機からのアクセスを
受け、各サーバが保持しているデータから必要に応じて
取り出したデータを返すマルチメディア情報サービスを
行う。例えば、分散型サーバシステムが持っている利用
者への交通情報、天気情報、お知らせ、買物情報あるい
は利用者相互の情報の交換を行う掲示板、メール等を音
声情報、イメージ情報あるいはテキストデータとして提
供するサービスを行うものである。

【００２４】各メディアサーバは地理的に離れた場所に
設置されているが、広い地域の共通の情報を、分散する
利用者群にサービスする。例えば、県が県民に対して情
報をサービスする場合、各市に上記メディアサーバを設
置し、利用者である市民は通常は使用料の安い市内回線
で接続できる地元のメディアサーバにアクセスすること
で全ての情報を得られるようにする。

【００２５】各メディアサーバ 22a〜22c には県内の情
報はどこの地域で発生した情報もサービスできるように
定期的に、本実施例では３０分毎に各メディアサーバ 2
2a〜22c のデータの交換をしている。また、ユーザであ
る県民が県内の他市に転居した場合にもあらためて転居
先の市にあるサーバに利用登録をしないでも従来通り県
の情報にアクセスできるように、また、あるアクセスポ
イントが混み合っていたときに隣接の地域にあるアクセ
スポイントにアクセスする場合にも同じユーザＩＤで利
用できるように、データと同様に登録されたＩＤについ
ても３０分毎に各サーバに反映されるように交換するよ
うになっている。

【００２６】このように時間の遅れはあるが実用的には
常にデータおよびＩＤ管理情報が交換され、どのサーバ
にアクセスしても同じサービスが得られるようにした本
実施例の分散型サーバシステムについて、以下に図３の
フローチャートにより動作を説明する。

【００２７】ステップS31 においてユーザがアクセスポ
イント＃Ｎ（Ｎは１、２、３等）にダイヤルして接続を
要求する。ダイヤルされたサーバ＃ＮではそのＩＤ管理
部に保持しているＩＤ管理情報によりアクセスしてきた
利用者が正当に登録された利用者か否か、ＩＤの照合、
さらにはパスワードの照合を行う（ステップS32 ）。結
果として正規登録がされていることが確認されれば利用
許可が与えられ利用開始することになる（ステップS33
）。

【００２８】ＩＤ照合の結果未登録であり、新たに登録
が依頼されたときにはステップS34においてサーバ＃Ｎ
に新規ＩＤ登録を申請する。利用申請の受付は電子メー
ルにより即時に行われるが登録手続きには時間を要す
る。ステップS35 の利用許可までが点線の矢印で結んで
あるのはこれを示す。以下の点線の矢印も同様に時間の
経過が必要なことを表す。

【００２９】利用許可されると先ず＃Ｎのサーバにおけ
る利用開始が許される。ステップS36 は定期的に＃０の
センタサーバからの問い掛けに対応して＃Ｎから新規に
登録されたＩＤ管理情報を伝送しセンタサーバのＩＤ管
理部に登録更新する。

【００３０】さらに定期的にセンタサーバから各サーバ
に配信するときに上記のように＃Ｎからセンタサーバに
新規に登録されたＩＤを登録元の＃Ｎ以外のサーバのＩ
Ｄ管理部に反映させる。これによりすべてのサーバのＩ
Ｄ管理部に先程新規登録された＃ＮのユーザＩＤが反映
される（ステップS37 ）。

【００３１】さて、上記の様に各サーバに新規に登録さ
れたＩＤ管理情報の他のサーバのＩＤ管理部への反映の
方法について図４のＩＤ管理情報のサーバ間交換の説明
図と図５のＩＤ管理情報のサーバ間交換の説明用のフロ
ーチャートを用いて事例で説明する。

【００３２】まず、図４の（ａ）にはセンタサーバとし
てのサーバ＃０と、回線43a 〜43cで接続されたサーバ
＃１〜サーバ＃３があり、上記したようにこれら４台の
サーバには各サーバに登録されたデータおよび利用者の
ＩＤが全て各サーバに格納されるようになっている。す
なわち、各サーバのデータ＃０〜３には全てのデータ
が、ＩＤ管理＃０〜ＩＤ管理＃３には全ＩＤが格納され
るようになっている。

【００３３】本発明の実施例では上記したように各サー
バに新規にＩＤが登録されたり、今まで登録されていた
ＩＤの登録内容を変更したり、削除したりというＩＤ管
理情報に関する変更が不定期に行われる。各サーバは自
分のＩＤ管理部については即刻これらの変更を反映させ
るが他のサーバのくて管理部には反映されていないとい
う状態が発生する。

【００３４】そこで、センタサーバとして各サーバと回
線43a 〜43c で接続されているサーバ＃０のＩＤ管理情
報のサーバ間交換プログラムが定期的に３０分毎に起動
され、以上のようなアンバランスになったＩＤ管理情報
を交換して同一内容としていく。大まかには回線43a 〜
43c を使ってサーバ＃１から順にサーバ＃３までで各
サーバにＩＤ管理情報に変更がなかったかを問い合わ
せ、有ればでその変更情報を吸い上げ、でそれまで
にセンタサーバにのみ反映されていて各サーバには未だ
反映されていないものを送信するという段階で処理が進
む。

【００３５】図５のフローチャートにより動作を詳細に
説明する。なお、ここにはＩＤ管理情報の交換について
のみ記すが実際には前に説明したようにデータ部につい
ても交換を行っている。

【００３６】サーバ＃０で時計により３０分ごとに起動
されたプログラムは先ずステップS51 で先頭のサーバ＃
１から順にＩＤ管理情報交換のための通信を始める。ス
テップS52 でサーバ＃Ｓすなわちサーバ＃１のＩＤ管理
情報に何らかの変更つまり新規の登録があったか、内容
の更新があったか、あるいは削除されたものがあるかを
問い合わせる。サーバ＃１において前回センタサーバに
報告した後でこれらの何らかの変更が有ったときにはＹ
ＥＳの方に進みステップS53 において、サーバ＃1 で変
更のあったＩＤ管理情報を各ＩＤ毎に変更通知電文の形
式でサーバ＃０に送信する。

【００３７】変更通知電文の形式は図４（ｃ）に示す。
また、ＩＤ管理情報を納めたＩＤ管理部の構造を図４
（ｂ）に示してある。ここにＩＤ管理部はセンタサーバ
としてのサーバ＃０のものを一部例示しているが、他の
サーバについても先頭の＃０管理フラグの部分が各サー
バの分のみでよいところが違うだけであるので＃０を例
にして説明する。

【００３８】発生コードとあるのは最新のＩＤ管理情報
は上記のどの変化が原因であるか、発生の原因を示すも
のである。すなわちこのデータは０１のとき新規登録、
１０のとき内容変更（更新）、１１のとき削除されたも
のであることを示す。００は空きを表し新規に登録があ
ったときには発生コード欄が００のものを探してそこに
新規登録を示す０１を記入することになる。

【００３９】ＩＤ番号はサーバ番号＋追番でありサーバ
番号０〜３と各サーバで管理する追番をハイフンで結合
した形式をとっている。これはＩＤの新規登録はどのサ
ーバでも受け付けられるので番号の重複を防ぐ様にして
いる。ＩＤ番号「２−０４５」はサーバ番号＃２で発行
された４５番目のものであることを示す。パスワードは
利用者が申請して登録したものであり、安全のために時
々変更をするものであり、変更が行われたときは使用し
ていたサーバのＩＤ管理部は直ちに変更されるが、他の
サーバのＩＤ管理部はここで説明しているＩＤ管理情報
のサーバ間交換によって定期的に反映されることにな
る。

【００４０】属性はＩＤを登録した利用者に関する各種
情報を格納するものであり、氏名、住所、電話番号など
が含まれる。変更通知電文は上記の各情報を組として送
信するデータである。ステップS53で変更通知電文を受
け取ったセンタサーバは図４（ｂ）の様なサーバ＃０の
ＩＤ管理部に対して反映し更新する。更新は次のように
行う。

【００４１】発生コードが０１の場合は新規登録であり
ＩＤ番号は以前には存在しないのでＩＤ管理部の発生コ
ード欄が００、空きの状態のものを探し変更通知電文を
そのまま格納する。このとき、管理フラグは自分と通知
電文を送信してきたサーバに対応するところを１とし、
その他のフラグを０とする。すなわち、管理フラグは対
応する番号のサーバのＩＤ管理部が既に更新済か否かを
示す。たとえば、図４（ｂ）のＩＤ番号「１−０６６」
の変更通知電文を受信したときは＃０と＃１の管理フラ
グが１となっていて、残りの＃２と＃３のサーバにはま
だ反映されていないことを示す。

【００４２】発生コードが１０または１１である変更通
知電文を受信したときのＩＤ管理部への反映は、ＩＤ番
号をキーとして探し一致したＩＤ管理情報について変更
通知電文の内容で置き換えることにより行う。つまり、
内容変更を表す発生コード１０の場合はＩＤ番号以外の
いずれかの部分に変更があると考えられるのでパスワー
ド、属性について置き換える。削除を意味する１１の場
合は今までの情報はそのままにして発生コードのみ１１
とすればよい。

【００４３】＃０管理フラグは＃０のサーバがセンタサ
ーバであるためＩＤ管理情報の交換を行う必要から＃１
〜＃３までのフラグをも備えるようにしてあるが、他の
一般サーバでは自分のサーバ番号に対するフラグだけを
持てばよい。ただし、他のサーバを示す番号のフラグと
若干意味がことなる。例えば図４（ｂ）のＩＤ番号が
「０−１０７」について説明すると、全てのフラグが０
であるので、ＩＤ番号の先頭のサーバ番号が０であるの
でサーバ＃０で新規に登録されたＩＤ（発生コードが０
１）であり、＃１〜＃３までのサーバにまだ反映されて
いないことを示している。＃０のフラグも０であるが、
これは自分のサーバーの番号であるので、自分のサーバ
に発生したＩＤ管理情報の変更がまだ他のサーバに送信
しておらず反映していないことを示す。他のサーバにお
ける管理フラグは自分のサーバ番号に関するもののみで
よいが、上記の＃０に対応するフラグが持つのと同様の
意味を持つことになる。

【００４４】図５のフローチャートでステップS54 では
交信中のサーバに対して未だ送信していないＩＤ管理情
報があれば送信して反映するものである。ここで上記管
理フラグの中で、交信中の＃Ｓ、すなわち＃１のサーバ
を示すフラグが０つまり未だ送信していないデータを選
び変更通知電文としてサーバ＃１に送信する。送信済を
記すために＃１に対するフラグを１に変える。全てのサ
ーバに対応するフラグが１となったときに＃０のフラグ
が０であればこれを１としてサーバ＃０で発生した変更
が全てのサーバに反映済となったことを記録する。

【００４５】以下ステップS55 、S56 でサーバ＃２、サ
ーバ＃３についても反映するように繰り返す。ステップ
S52 でサーバ＃ＳでＩＤ管理情報に変更がなかったとき
は＃０に溜め込まれたＩＤ管理情報の変更情報の反映だ
けがステップS54 で行われる。

【００４６】以上のように定期的に、ここでは３０分に
１回であるが各サーバにＩＤ管理情報の交換を行うこと
により、瞬時をとれば違いが残ることもあるが、あまり
頻度が多くはないＩＤ管理情報の変更操作に関しては実
際上常に同一の状態に保持することができることにな
る。

【００４７】

【発明の効果】以上の説明から明らかなように本発明に
よれば分散型サーバシステムにおいて、一旦ユーザ登録
を行えば、それがどのサーバにおいて登録したかにかか
わらず、どのサーバにアクセスしても、自由に全てのサ
ーバから提供されたデータを短い時間で、安い料金で利
用でき、さらにはネットワークの混雑するときも地域的
に移動したときも他のアクセスポイントから同等なサー
ビスを享受でき、経済的な効果、利用者の効率向上の効
果、システムの利用可能性の拡大の効果、という著しい
工業的効果がある。

【図面の簡単な説明】

【図１】 本発明の構成図

【図２】 本発明の実施例のネットワーク構成図

【図３】 本発明の実施例の動作説明用フローチャート

【図４】 ＩＤ管理情報のサーバ間交換の説明図

【図５】 ＩＤ管理情報のサーバ間交換の説明用のフロ
ーチャート

【図６】 従来の分散型サーバシステムの構成例（その
１）

【図７】 従来の分散型サーバシステムの動作フローチ
ャート例（その１）

【図８】 従来の分散型サーバシステムの構成例（その
２）

【図９】 従来の分散型サーバシステムの動作フローチ
ャート例（その２）

【符号の説明】

１ ＩＤ登録手段 ２ ＩＤ通知管理手段

Claims (2)

【特許請求の範囲】
1. 【請求項１】 分散して配置され、ネットワークで接続
   された複数のサーバからなる分散型サーバシステムにお
   いて、 各サーバが利用登録を受け付けたユーザのＩＤ管理情報
   を受信して各サーバ毎のＩＤ管理情報として一括して登
   録するＩＤ登録手段と、 前記ＩＤ登録手段で登録されたＩＤ管理情報を、利用登
   録を受け付けたサーバ以外のサーバに通知するＩＤ通知
   管理手段と、を有することを特徴とする分散型サーバシ
   ステムにおけるユーザＩＤ管理装置。
2. 【請求項２】 分散して配置され、ネットワークで接続
   された複数のサーバからなる分散型サーバシステムにお
   いて、 各サーバが利用登録を受け付けたユーザのＩＤ管理情報
   を受信して各サーバ毎のＩＤ管理情報として一括して登
   録し、 前記登録されたＩＤ管理情報を、利用登録を受け付けた
   サーバ以外のサーバに通知することを特徴とする分散型
   サーバシステムにおけるユーザＩＤ管理方法。