JP2006338357A - データ管理システム及びデータサーバ及びデータ管理方法 - Google Patents

Abstract

【課題】サーバ間でデータが移動した場合でも、そのデータを見つけ出せるようにする。【解決手段】データ管理部１２に登録されるデータは、データサーバ１０内で一意なローカル識別情報とグローバルに一意なグローバル識別情報を有する。ローカル識別情報とグローバル識別情報との対応関係はＩＤ変換部１３で管理される。データサーバ１０は、クライアントから受け取ったデータ要求の要求対象データをデータ管理部１２から検索し、該当するデータが検索できた場合はそのデータをクライアントに提供し、検索できなかった場合は、他のデータサーバ１０に対し該要求対象データのグローバル識別情報を含むデータ問合せを送ることにより、要求対象データを持つデータサーバ１０を探索する。ここでデータ要求が要求対象データをローカル識別情報により指定している場合は、ＩＤ変換部１３からその要求対象データのグローバル識別情報を求めることで、前記データ問合せを生成する。
【選択図】図１

Description

本発明は、ユーザが要求したデータの所在場所（ロケーション）を解決するための技術に関する。

この分野の従来技術として、特許文献１に示される技術がある。この技術では、データ管理システムが、各ファイルに対してハンドルと呼ぶ一意な識別子を付与して管理している。そして、そのファイルのＵＲＬとして、従来一般的なファイルの所在場所（所在サーバとそのサーバ内でのファイルのパス名の組合せ）を示したＵＲＬではなく、当該システムのサーバ名とファイルのハンドルとを指定した仮想ＵＲＬをユーザに提供する。ユーザがその仮想ＵＲＬを用いて当該システムにアクセスすると、システムはそのハンドルからファイルの所在場所を特定し、ユーザに提供する。このような仕組みにより、ファイルがデータ管理システム上のどの場所（ディレクトリ）に移動しても、ユーザからの要求に応じてそのファイルを見つけることができる。

また、同様の従来技術として、特許文献２に示されるものがある。特許文献２のサーバは、管理する各コンテンツに識別子を付与し、ユーザから検索要求があった場合、その要求に合致するコンテンツの識別子を含んだ仮想ＵＲＬをユーザに提供する。このサーバは、仮想ＵＲＬを用いてユーザからアクセスがあると、その仮想ＵＲＬに含まれる識別子を蓄積システムに渡し、蓄積システムはその識別子に対応するコンテンツをキャッシュメモリにコピーし、キャッシュメモリ上のコンテンツのコピーのアドレスをサーバに返す。これにより、サーバはそのキャッシュメモリ上のコンテンツをユーザに提供することができる。

また、非特許文献１には、マサチューセッツ工科大学（ＭＩＴ）が開発したオープンソースソフトウェアのデータ管理システム「Ｄｓｐａｃｅ」が照会されている。Ｄｓｐａｃｅでは、中央にハンドルサーバを用意し、そのハンドルサーバでデータのハンドル（識別子）と、各データを管理しているサーバの情報とを管理する。各Ｄｓｐａｃｅプラットフォームは、ユーザより提示されたハンドルをハンドルサーバに問い合わせることで、そのハンドルに対応する実際のデータを管理しているサーバを解決する。

特開平１１−３２６５号公報 特開平２０００−２０７４２１号公報 ロバート・タンズリー（Robert Tansley）他４名，"DSpace System Documentation"、[online]、Documentation Version: 1.1-2, ２００３年６月３日、［平成１７年（２００５年）３月９日検索］、インターネット＜ＵＲＬ： http://libraries.mit.edu/dspace-mit/technology/system-docs/index.html＞ 、特にその項目Functional Overview - Handles ＜ＵＲＬ： http://libraries.mit.edu/dspace-mit/technology/system-docs/functional.html#handles＞

特許文献１及び２の技術は、１つのデータ管理システム内で管理されているファイル・コンテンツの所在場所解決に限定されており、例えばファイル・コンテンツの所在場所がネットワーク上の複数のデータ管理システムの中で移動してしまうようなケースには対応できない。

非特許文献１の技術はこのようなケースに対応できるものであるが、中央管理サーバに完全に依存しているため、中央管理サーバに登録されていないサーバ上のデータは解決できない、中央管理サーバが停止した場合は全くデータの所在を解決できない、といった集中管理であるが故の問題が発生する。

本発明は、データが他のサーバに移動しても移動前に発行されたＵＲＬ等のデータの所在情報からそのデータの所在を解決することを、非特許文献１のような中央管理サーバを用いずに実現する。

本発明は、ネットワークを介して接続された他のデータサーバと連携してデータ管理システムを構成するデータサーバとして、コンピュータシステムを動作させるためのプログラムであって、該コンピュータシステムを、登録されるデータを記憶するデータ管理部であって、登録されるデータに対し当該データサーバ内で一意なローカル識別情報を付与するとともに、そのデータに対しグローバルに一意なグローバル識別情報が付与されていない場合はグローバル識別情報を付与するデータ管理部、データに付与されたローカル識別情報とグローバル識別情報との対応関係を記憶する対応関係記憶部、クライアントから受け取ったデータ要求の要求対象データをデータ管理部から検索し、該当するデータが検索できた場合はそのデータをクライアントに提供し、検索できなかった場合は、データ管理システムを構成する他のデータサーバに対し該要求対象データのグローバル識別情報を含むデータ問合せを送ることにより、前記要求対象データを持つデータサーバを探索する要求処理部であって、前記データ要求が要求対象データをローカル識別情報により指定している場合は、前記対応関係記憶部からその要求対象データのグローバル識別情報を求めて前記データ問合せを生成する要求処理部、他のデータサーバからデータ問合せを受けた場合、該データ問合せに含まれるグローバル識別情報に対応するデータを前記データ管理部から検索し、その検索の結果に応じた応答を前記他のデータサーバに送る応答部、として機能させるためのプログラム、を提供する。

本発明によれば、各データサーバが他のデータサーバを検出し、グローバルに一意なグローバル識別情報を用いた問合せにより、要求対象データを持つデータサーバを探索するので、非特許文献１の中央管理サーバのような集中管理をしなくても、データの所在を解決できる。また、本発明によれば、クライアントが要求対象データをローカル識別情報で指定した場合でも、その要求対象データのグローバル識別情報を対応関係記憶部から求めることで、他のデータサーバへの問合せが可能となる。

以下、図面を参照して、本発明を実施するための最良の形態（以下「実施形態」と呼ぶ）について説明する。

図１は、本発明に係るデータ管理システムの概略構成を示す図である。図１に示すように、本システムは、ＬＡＮ（ローカル・エリア・ネットワーク）やインターネットなどのネットワーク２０に接続された複数のデータサーバ１０−１，１０−２，．．．（以下では、区別の必要のない場合は「データサーバ１０」と総称する。データサーバ１０内のモジュールについても同様）から構成される。本システムは、ネットワーク２０上のクライアント３０（例えばパーソナルコンピュータ）からのデータ要求に応じ、要求対象のデータを提供する。

図２は、本発明に係るデータ管理システムを構成するデータサーバ１０の概略構成を示す図である。データサーバ１０は、データ管理部１２、ＩＤ変換部１３，検出部１４及び問合せ部１６を備えている。データ管理部１２には、ユーザが操作するクライアント３０に提供することができる１以上のデータ（言い換えれば、オブジェクト）が登録される。ここでデータ管理部１２に登録される各データには、グローバルに一意なグローバルＩＤ（識別情報）と、当該データサーバ１０内で一意なローカルＩＤとが付与されている。

グローバルＩＤとしては、例えばＵＵＩＤ（Universally Unique IDentifier）又はＧＵＩＤ（Globally Unique IDentifier）と呼ばれる１２８ビットの識別情報を用いることができる。ちなみに、ＵＵＩＤは、グローバルな一意性を保証するために、そのＵＵＩＤを作成した時刻や作成に使用したマシンに装着されたネットワークカードのＭＡＣ（Media Access Control）アドレス等を含んでいる。ＵＲＬ(Uniform Resource Locator)は、データを有するデータサーバ１０のホスト名とそのサーバ１０において当該データが実際に記憶されている場所を示すパス名とによって当該データを一意に指すのに対し、本実施形態のグローバルＩＤは、そのようなデータの所在場所の情報とは独立した識別情報である。

一方、ローカルＩＤは、データ管理部１２に記憶されたデータの中で一意であればよい。したがって、ローカルＩＤは、グローバルＩＤに比べてデータ量（桁数）が小さくて済む。本実施形態では、一例として、データ（オブジェクト）の種類と通し番号との組合せからなるローカルＩＤを用いる。データの種類は、例えば、文書(Document)やフォルダ(Folder)又はディレクトリ等といった種別である。通し番号は、例えば、データ管理部１２に登録された順番でよい。この順番は、データの種類ごとのものでよい。例えば、１０番目に登録された文書のローカルＩＤは「Document-10」となる。データの種類と通し番号の組合せのローカルＩＤは、データ管理部１２が自動生成できるとともに、ユーザにとっても比較的覚えやすく入力も容易である。

図３にデータ管理部１２が管理する各データの管理情報のデータ構造を示す。この図に示すように、データ管理部１２は、登録された各データにつき、そのデータのデータＩＤ１０２と、データサーバ１０内でそのデータを指し示すリンク情報（例えばそのデータのパス名）１０４とを対応づけて管理している。ここで、データＩＤ１０２は、ローカルＩＤでもグローバルＩＤでもよいが、データ検索の効率からすれば、桁数が小さいローカルＩＤを用いることが好ましい。

ＩＤ変換部１３は、グローバルＩＤとローカルＩＤとの間のＩＤ変換を行う。この変換のため、ＩＤ変換部１３は、同じデータに対して付与されたグローバルＩＤとローカルＩＤとの対応関係を示す対応表を有している。図４に対応表のデータ内容の一例を示す。例えば、ＩＤ変換部１３は、ローカルＩＤが与えられた場合、この対応表からそれに対応するグローバルＩＤを求める。なお、ＩＤ変換部１３は、必ずしもローカルＩＤとグローバルＩＤの間の双方向の変換ができる必要はないが、ローカルＩＤからグローバルＩＤへの変換機能は必要である。これは、ユーザからローカルＩＤで指定されたデータを他のデータサーバに問い合わせるためである（詳細は後述）。データ管理部１２がグローバルＩＤでデータを管理している場合はこれで足りる。逆に、データ管理部１２がローカルＩＤでデータを管理している場合において、ユーザからグローバルＩＤを用いたデータ要求を受け付ける場合には、逆方向の変換機能も必要となる。

図５に示すように、データサーバ１０は、データをデータ管理部１２に新たに登録する場合、まずそのデータに対してローカルＩＤを付与する（Ｓ１０）。そして、そのデータにグローバルＩＤが付属しているかどうかを調べ（Ｓ１２）、付属していれば、そのグローバルＩＤとステップＳ１０で付与したローカルＩＤとの対応関係をＩＤ変換部１３の対応表に登録する（Ｓ１６）。データにグローバルＩＤが付属していなければ、データサーバ１０は、そのデータにグローバルＩＤを付与し（Ｓ１４）、これとステップＳ１０で付与したローカルＩＤとをＩＤ変換部１３に登録する（Ｓ１６）。

なお、ＩＤ変換部１３の対応表に登録した情報は、データ管理部１２に登録されていたデータが削除されても、また他のデータサーバに移動しても、削除はしない。これは、ユーザからのデータへのアクセスを容易にするためである。なお、データ管理部１２に登録されていたデータが削除された場合に、その旨を例えば対応表の当該データのローカル又はグローバルＩＤに対応づけて記録するようにすることも好適である。

検出部１４は、ネットワーク２０上に存在する他のデータサーバ１０を検出する手段である。

問合せ部１６は、クライアント３０から要求されたデータを有しているか否かを、他のデータサーバ１０に対して問い合わせる手段である。また問合せ部１６は、他のデータサーバ１０の問合せ部１６からの問合せに対して回答する機能も備える。

本実施形態では、ユーザの操作するクライアント３０は、データ管理システムに対してデータを要求する場合、図６ａ又は図６ｂに示すような仮想ＵＲＬ１１０のを用いて要求を行う。図６ａの例は、当該データを管理するデータサーバ１０のホスト名１１２（ＩＰアドレスでも良い）と、そのデータのグローバルＩＤ１１４ａとを含む仮想ＵＲＬ１１０である。グローバルＩＤは桁数が非常に多くなるため、図６ａではその一部を省略して示した。この仮想ＵＲＬは、「xxx.fx.co.jp」という名前のデータサーバが管理している「12345......67890」というグローバルＩＤをもつデータを指している。なお、図６ａの仮想ＵＲＬのうちホスト名１１２とグローバルＩＤ１１４ａに挟まれた「get」は、データサーバ１０が提供するメソッドの名前である。データサーバ１０が管理するデータに対して複数種類の操作をクライアント３０に認める場合、仮想ＵＲＬにはその操作を示すメソッドを含めるようにする。逆に言えば、データサーバ１０が単に要求されたデータをクライアント３０に提供するだけであれば、このようなメソッドの記述は不要である。また、図６ｂの例は、グローバルＩＤ１１４ａの代わりにローカルＩＤ１１４ｂを含んだ仮想ＵＲＬの例である。この場合のローカルＩＤ１１４ｂは、その仮想ＵＲＬが発行されたときに当該データが存在したデータサーバ１０における、当該データのローカルＩＤである。

なお、これら仮想ＵＲＬはＵＲＬであるため、当然プロトコル、ポート等の情報も含まれるが、ここでは特に説明しない。

なお、データへのアクセスのための仮想ＵＲＬは、例えば電子メールなどに記述されてユーザへと提供される。ユーザはその仮想ＵＲＬをクリックするなどの操作により、クライアント３０にインストールされたウェブブラウザを介してそのデータへのアクセスを試みる。

仮想ＵＲＬ通知の仕組みの一つとして、データサーバ１０は、データ管理部１２に対して新たなデータが登録されたり、登録されているデータが更新されたりするなど、データ管理部１２に変更が生じた場合に、その変更に係るデータを示す仮想ＵＲＬを関係ユーザに通知する機能を備えていてもよい。この通知は、例えば電子メールの形で送信する。通知に記述する仮想ＵＲＬは、グローバルＩＤを用いたものでもローカルＩＤを用いたものでもよいが、ユーザの利便性を考えた場合、ローカルＩＤの方が好ましい。通知を送信する関連ユーザは、例えばデータごと、或いはフォルダごとなどの単位で、予めデータサーバ１０に登録されている。また、ユーザがデータをデータサーバ１０に登録する際に、このデータへのアクセスを許す人を通知送信先ユーザとして登録してもよい。

いずれにしても、ユーザは、過去に取得した仮想ＵＲＬを用いて、そのデータに対するアクセスを行うことができる。

ユーザが、クライアント３０を操作し、仮想ＵＲＬ１１０を用いてデータ要求を行った場合、ホスト名１１２が示すサーバに対し、グローバルＩＤ１１４ａ又はローカルＩＤ１１４ｂを含んだデータ要求情報が送信されることになる。

次に図７を参照して、データサーバ１０がクライアント３０からデータ要求情報を受け取ったときの処理手順を説明する。以下では、便宜上、システムを構成する複数のデータサーバ１０のうちの１つ、すなわちデータサーバ１０−１の処理として説明するが、他のデータサーバもこれと同様の処理を行う。

この手順では、まずデータサーバ１０−１は、クライアント３０からのデータ要求情報からデータＩＤを抽出し（Ｓ１００）、データ管理部１２−１からそのデータＩＤに対応する実データのリンク情報を検索する（Ｓ１０２）。ここで、仮想ＵＲＬを用いて行われるデータ要求からは、データＩＤとしてグローバルＩＤ１１４ａが抽出される場合もあれば、ローカルＩＤ１１４ｂが抽出される場合もある。一方、データ管理部１２−１も、登録されたデータのインデックスとしてグローバルＩＤを用いる構成の場合もあれば、ローカルＩＤを用いる構成の場合もある。したがって、この検索ステップＳ１０２においては、必要に応じて、ＩＤ変換部１３−１を用い、データ要求に示されたデータＩＤをデータ管理部１２−１の検索インデックスのＩＤタイプへと変換する。例えば、データ管理部１２−１がデータをローカルＩＤで管理している場合に、クライアント３０からグローバルＩＤによるデータ要求を受けた場合、データ管理部１２−１はそのグローバルＩＤをＩＤ変換部１３−１に渡してローカルＩＤに変換させ、得られたローカルＩＤに対応するデータを検索する。データ要求中のデータＩＤのタイプと検索インデックスのＩＤタイプとが同じ場合は、ＩＤ変換は不要である。検索により、要求されたデータに対応するリンク情報が検索できた場合（Ｓ１０４の判定結果が肯定（Ｙ））、データサーバ１０−１は、そのリンク情報が指し示すデータの実体をデータサーバ１０−１内の記憶装置から取得し、クライアント３０に提供する（Ｓ１１４）。

一方、要求されたデータＩＤに対応するリンク情報がなかった場合（Ｓ１０４の判定結果が否定（Ｎ））、データサーバ１０−１は検出部１４−１に、本システムを構成する他のデータサーバ１０−２等の検出を指示し、検出部１４−１はこの指示に応じて他のデータサーバ１０−２等の検出を行う（Ｓ１０６）。他のデータサーバ１０の検出は、例えば、他サーバ検出用の所定のメッセージを、検出部１４−１からネットワーク２０へブロードキャストすることで行うことができる。各データサーバ１０−２等の検出部１４−２等は、他サーバ検出用のメッセージを認識し、それに対して応答するためのプロトコルを有している。すなわち、他サーバ検出用メッセージを受け取った他のデータサーバ１０−２等の検出部１４−２等は、このプロトコルに従い、当該他のデータサーバ１０−２等のサーバＩＤ（識別情報）を含んだ応答を返す。サーバＩＤとしては、例えばＩＰアドレスや、ホスト名を用いることができる。他サーバ検出用のメッセージを発信した検出部１４−１は、他のデータサーバ１０−２等からの応答を受け取り、その応答に含まれるサーバＩＤを取得する。これにより、本システムを構成する他のデータサーバ１０−２を見つけることができる。

他のデータサーバ１０−２が見つかると、データサーバ１０−１は、問合せ部１６−１に、見つけた他のデータサーバ１０−２に対する問合せを指示する。この指示に応じ、問合せ部１６−１は、クライアント３０から要求されたデータのグローバルＩＤを含んだデータ問合せをデータサーバ１０−２に送り、そのグローバルＩＤに対応するデータを持っているか否かを問い合わせる（Ｓ１０８）。すなわち、問合せ部１４は、クライアント３０からのデータ要求中のデータＩＤがグローバルＩＤであればこれをそのまま用い、ローカルＩＤであれば、それをＩＤ変換部１３によりグローバルＩＤに変換して問合せを生成する。この問合せを受けたデータサーバ１０−２の問合せ部１６−２の動作については、後で詳しく説明する。

この問合せの結果、問合せ先の他のデータサーバ１０−２が当該データを持っていないことが判明した場合は（Ｓ１１０の判定結果が否定（Ｎ））、他のデータサーバの検出（Ｓ１０６）及びそれに対する問合せ（Ｓ１０８）を繰り返す。当該データを持つデータサーバ１０が見つかるまで、ステップＳ１０６及びＳ１０８が繰り返される。

なお、図７では、他のデータサーバをステップＳ１０６で１つ検出してはステップＳ１０８でそれに対して問合せを行うという手順を示したが、これに限らず、例えばステップＳ１０６でブロードキャストにより検出可能なデータサーバ１０を全て検出して記憶し、それら記憶した各データサーバ１０に対しステップＳ１０８で順に問合せを行うようにしてももちろんよい。

問合せ先の他のデータサーバ１０−２が当該データを持っていることが判明した場合は（Ｓ１１０の判定結果が肯定（Ｙ））、データサーバ１０−１はデータサーバ１０−２のサーバＩＤを含んだリダイレクト情報をクライアント３０に返す（Ｓ１１２）。このリダイレクト情報の返送は、例えば、一般的なＨＴＴＰ(HyperText Transfer Protocol)リダイレクトの方式に従って行うことができる。すなわち、データサーバ１０−１は、302(Found)等のリダイレクトを示すステータスコードと、リダイレクト先のＵＲＬを含んだLocationフィールドと、を含むリダイレクト情報をクライアント３０に返す。なお、リダイレクト情報に含まれるリダイレクト先のＵＲＬは、リダイレクト先のデータサーバ１０−２のサーバＩＤと要求対象データのデータＩＤとを含んだ上述の仮想ＵＲＬである。この場合のデータＩＤは、グローバルＩＤでもローカルＩＤでもよいが、ユーザの使いやすさを優先するとローカルＩＤが好適である。ただし、このときのローカルＩＤは、当該データを持つと判明した他のデータサーバ１０−２でのローカルＩＤである。

グローバルＩＤを用いた仮想ＵＲＬの場合、リダイレクト先のサーバＩＤも要求対象データのグローバルＩＤも問合せの時点で既知なので、データサーバ１０−１はそのような仮想ＵＲＬを生成できる。ローカルＩＤを用いた仮想ＵＲＬの場合は、問合せ先のデータサーバ１０−２からそのデータのローカルＩＤを取得し、それとサーバＩＤを組み合わせて作成する。

このリダイレクト情報を受けたクライアント３０は、ＨＴＴＰに従って、リダイレクト情報中のサーバＩＤが示すデータサーバ１０−２に対し、同じくリダイレクト情報中のデータＩＤを含んだデータ要求を送る。

次に、他のデータサーバから問合せを受けたときのデータサーバの処理手順を、図８を参照して説明する。以下では、便宜上、データサーバ１０−２の処理として説明するが、他のデータサーバもこれと同様の処理を行う。

データサーバ１０−２の問合せ部１６は、他のデータサーバ１０−１の問合せ部１６からデータ問合せを受けた場合、そのデータ問合せの情報の中から対象データのグローバルＩＤを取り出し（Ｓ２００）、そのグローバルＩＤに対応するリンク情報をデータ管理部１２−２から検索する（Ｓ２０２）。この検索の際、データ管理部１２−２がローカルＩＤによりデータを管理している場合は、ＩＤ変換部１３−２によりそのグローバルＩＤをローカルＩＤに変換し、検索を行う。この検索の結果、データ管理部１２−２からそのグローバルＩＤに対応するリンク情報が検索できた場合（Ｓ２０４の判定結果が肯定（Ｙ））、問合せ部１６−２は、問合せ対象のデータが存在する旨を示すメッセージを問合せ元のデータサーバ１０−１に返す（Ｓ２０６）。一方、検索できなかった場合（Ｓ２０４の判定結果が肯定（Ｙ））、問合せ部１６−２は、問合せ対象のデータが存在しない旨を示すメッセージを問合せ元のデータサーバ１０−１に返す（Ｓ２０８）。

なお、ステップＳ２０６では、問合せ対象のデータが存在する旨を示すメッセージを問合せ元に返す代わりに、問合せ対象のデータの仮想ＵＲＬ（すなわちそのデータを持つデータサーバ１０−２のサーバＩＤと、そのデータのデータＩＤを含む）を返してもよい。仮想ＵＲＬに示されるデータＩＤとしては、ローカルＩＤを用いた方がユーザにとって記憶しやすく、また入力もしやすい。本システムが、ユーザに対して提供するリダイレクト情報としてローカルＩＤを用いたものを提供する場合には、問合せ部１６−２は、ローカルＩＤを含んだ仮想ＵＲＬをデータサーバ１０−１に返す。このように問合せ先のデータサーバ１０−２からデータの仮想ＵＲＬが返される場合、問合せ元のデータサーバ１０−１は、ステップＳ１１２において、データサーバ１０−２から返された仮想ＵＲＬをリダイレクト情報としてクライアント３０に返せばよい。

以上説明したようなデータ管理システムの動作を、具体例を用いて説明する。

まず図１の構成において、クライアント３０からデータサーバ１０−１に送ったデータ要求の対象データがデータサーバ１０−１に存在する場合は、上述のフローチャートの処理に従って、その対象データがデータサーバ１０−１からクライアント３０に提供される。

一方、クライアント３０からデータサーバ１０−１に送ったデータ要求の対象データがデータサーバ１０−１に存在しない場合は、例えば図９のような流れとなる。図９の例では、データ管理部１２−１，１２−２はデータをローカルＩＤで管理しているものとする。

図９において、クライアント３０から要求対象データをローカルＩＤ（図中では「ＳＩＤ−１」と表記した）で示したデータ要求が来ると（１）、データサーバ１０−１はそのローカルＩＤ「ＳＩＤ−１」のデータがデータ管理部１２にあるか検索する（２）。この例ではデータ管理部１２−１に当該データは存在しないので、次に検出部１４−１が他のデータサーバ１０−２を検出する（３）。そして、ローカルＩＤ「ＳＩＤ−１」に対応するグローバルＩＤ（この例では「ＵＵＩＤ−１」とする）をＩＤ変換部１３−１から求める（４）。要求対象データがデータサーバ１０−１に登録されていたことがあれば、ＩＤ変換部１３−１に当該データのローカルＩＤとグローバルＩＤの対応関係が登録されているので、ＩＤ変換が可能である。ユーザがデータサーバ１０−１やその他のユーザなどから当該データを示す仮想ＵＲＬを受け取っていた場合は、そのデータはデータサーバ１０−１に登録されていたことがある可能性が高い。要求対象データのグローバルＩＤ「ＵＵＩＤ−１」が求められると、問合せ部１６−１は、そのグローバルＩＤを含んだデータ問合せを、データサーバ１０−２に対して送信する（５）。

この問合せを受けたデータサーバ１０−２の問合せ部１６−２は、その問合せ中のグローバルＩＤ「ＵＵＩＤ−１」に対応するローカルＩＤをＩＤ変換部１３−２により求める（６）。この例では、ＵＵＩＤ−１のデータがデータ管理部１２−２に登録されているので、ＵＵＩＤ−１に対応するローカルＩＤ（「ＳＩＤ−２」とする）は求めることができる。データ管理部１２−２は、「ＳＩＤ−２」に対応するデータを自身の記憶部から検索し、その検索結果を問合せ部１６−２に渡す（７）。この例では、ローカルＩＤ「ＳＩＤ−２」のデータが検索できたので、問合せ部１６−２は、「ＳＩＤ−２」を含んだ返答情報をデータサーバ１０−１の問合せ部１６−１に返す（８）。これを受け取ったデータサーバ１０−１は、「ＳＩＤ−２」を含んだリダイレクト情報を作成し、要求元のクライアント３０に返す（９）。このリダイレクト情報は、データサーバ１０−２のホスト名とローカルＩＤ「ＳＩＤ−２」を含んだものである。クライアント３０は、そのリダイレクト情報に従ってデータサーバ１０−２にアクセスし（１０）、「ＳＩＤ−２」のデータを取得する（１１）。

図９の例は、データ管理部１２がデータをローカルＩＤで管理している場合であったが、グローバルＩＤで管理している場合は、データ管理部１２の検索のためにデータ要求中のローカルＩＤをグローバルＩＤに変換する必要が出てきたり、他のデータサーバ１０からのデータ問合せを受けた場合、その問合せに含まれるグローバルＩＤでそのままデータ管理部１２を検索できたりする点が異なるだけで、その他の点は図９の場合と同様でよい。

次に、クライアント３０の要求するデータがデータサーバ１０−１にも１０−２にも存在せず、データサーバ１０−３に存在する場合の例を図１０に示す。

この例は、データサーバ１０−１がデータサーバ１０−２を検出して問合せを行い、問合せ部１６−２がその問合せに係るグローバルＩＤ「ＵＵＩＤ−１」に対応するローカルＩＤをＩＤ変換部１３−２に問い合わせるところまでは（６）、図９の例と同じである。そして、この図１０の例では、グローバルＩＤ「ＵＵＩＤ−１」に対応するローカルＩＤがＩＤ変換部１３−２から得られない。当該データがデータサーバ１０−２に一度も登録されたことがない場合は、このような事態が生ずる。この場合、問合せ部１６−２は、問合せに係るデータが当該サーバ１０−２にない旨を示す返答情報をデータサーバ１０−１に返す（７）。

なお、要求対象データがデータサーバ１０−２にないケースとしては、上述のように一度も登録されたことがない場合の他、過去に登録された後、現在までの間にそのデータが移動させられたり削除されたりする場合もある。このような場合、ＩＤ変換部１３−２にはＵＵＩＤ−１に対応するローカルＩＤが存在するが、データ管理部１２−２からはそのデータは検索できないので、結局のところそのデータが存在しない旨を示す返答情報がデータサーバ１０−２に返されることになる。

データサーバ１０−１の問合せ部１６−１はこの返答情報からサーバ１０−２に要求対象データがないことがを知る。この場合、検出部１４−１が更に別のデータサーバ１０−３を検出し（８）、「ＵＵＩＤ−１」を含んだデータ問合せを送る（９）。データサーバ１０−３では、その「ＵＵＩＤ−１」がＩＤ変換部１３−３によりローカルＩＤ（「ＳＩＤ−２」とする）に変換され（１０）、このローカルＩＤを用いてデータ管理部１２−３の登録データが検索される（１１）。この例では、この検索により要求対象データが見つかる。したがって、問合せ部１６−３は、そのローカルＩＤ「ＳＩＤ−２」を含んだ返答情報をデータサーバ１０−１に返す（１２）。以降は、図９の例と同様である（１３）〜（１５）。

以上のように、クライアント３０からの要求されたデータがデータサーバ１０−１にない場合も、データサーバ１０−１はそのデータのグローバルＩＤを用いて他のデータサーバ１０−２，３，．．．にそのデータがあるかどうかを問い合わせていく。したがって、いずれかのデータサーバ１０にそのデータがあれば、そのデータサーバ１０へのリダイレクト情報がデータサーバ１０−１を介してクライアント３０に提供され、クライアント３０はそのリダイレクト情報を用いてそのデータにアクセスすることができる。

なお、要求対象データを現在保持しているデータサーバ１０が停止していたり、或いはそのデータが削除されている場合は、ネットワーク２０上をいくら探索してもそのデータは見つからない。したがって、クライアント３０からデータ要求を受けたデータサーバ１０−１は、あらかじめ設定された終了条件を満足した時点で他のデータサーバへの問合せを終了し、クライアント３０にデータが見つからなかった旨を回答するようにしてもよい。終了条件としては、（ａ）あらかじめ指定された数のデータサーバ１０に問い合わせても要求対象データが見つからない場合、（ｂ）あらかじめ指定された時間が経過しても要求対象データが見つからない場合、（ｃ）データサーバ１０を探すドメインがあらかじめ指定されており、そのドメイン内のすべてのデータサーバ１０に問い合わせても要求対象データが見つからない場合、などのいずれかを用いることができる。また、（ｄ）データ管理システムを構成するデータサーバの一部又は全部のサーバＩＤが登録されたリストがデータサーバ１０−１に登録されている場合は、「そのリストにあるデータサーバ１０の全てに問い合わせても要求対象データが見つからないこと」、を終了条件とすることもできる。

なお、データの削除操作が行われた場合、データ管理部１２がその旨をそのデータのローカルＩＤ又はグローバルＩＤに対応づけて削除リストに記憶することも好適である。この場合、データサーバ１０−２は、他のデータサーバ１０−１から問い合わせられたデータがその削除リストに載っている場合は、そのデータが削除する旨を回答する。これにより、データサーバ１０はそれ以上の探索を打ち切り、クライアント３０に対し要求対象データが削除されていることを通知することができる。

以上の実施形態の説明では、クライアント３０からローカルＩＤを用いたデータ要求を受け取った場合の例を示したが、グローバルＩＤを用いた場合も同様の探索処理が可能なことは容易に理解できるであろう。

以上説明したように、本実施形態では、各データサーバ１０が、クライアント３０から要求されたデータを持つデータサーバ１０を探し、見つけたデータサーバ１０に対してその要求をリダイレクトする。したがって、非特許文献１のような中央管理サーバが無くても要求されたデータを見つけることができため、サーバ停止によりデータが解決不能になる問題も従来技術に比べて大幅に抑制することができる。

また、本実施形態では、データサーバ１０間でデータが移動されデータの所在場所が変わったとしても、クライアント３０は既存の仮想ＵＲＬを用いてデータにアクセスすれば、元々そのデータを管理していたデータサーバ１０、すなわち仮想ＵＲＬ中のサーバＩＤに対応するデータサーバ１０がそのアクセス要求を受け取り、現在そのデータを有しているデータサーバ１０を探索する。したがって、クライアント３０は、既に有している仮想ＵＲＬをそのまま利用しても、データを取得することができる。

例えば、既存のデータサーバの中には、新たにデータが登録されるなどサーバ上のデータに変更が生じると変更を確認可能なＵＲＬをメールでユーザに配布する機能を持つものがある。しかし、このサーバ上のデータが他のサーバへ移動されると、既に配布したＵＲＬは利用できなくなってしまう。これに対し、本実施形態の仕組みを適用すれば、そのようなケースでも、クライアント３０はデータ移動前に配布された仮想ＵＲＬを利用してそのデータを取得することができる。また、管理対象のデータの増大などによりデータサーバ１０を分割する必要が出てくることがよくあるが、このような場合でも、本実施形態では、分割前にユーザに配布した仮想ＵＲＬを分割後にも使用することができる。

また、本実施形態では、グローバルＩＤよりも桁数の少ないローカルＩＤを用いた仮想ＵＲＬでデータ要求を行うことができるので、グローバルＩＤを用いる場合に比べユーザにとって仮想ＵＲＬを覚えたり、口頭で近くの人に伝えたりするのが容易になり、また仮想ＵＲＬのタイプ入力も容易になる。

また本実施形態では、データがデータサーバ１０に登録されると、当該データの当該サーバ内でのローカルＩＤとグローバルＩＤとの対応関係がＩＤ変換部１３に登録され、その対応関係の情報は、当該データが他のデータサーバに移動しても消えない。これにより、データがデータサーバ間で移動しても、一度でもそのデータが登録されていたデータサーバ１０があれば、そのサーバ１０に対し、そのサーバ１０におけるそのデータのローカルＩＤを用いて問合せを行うことで、そのデータを見つけ出すことができる。

なお、データサーバ１０間のデータの移動は、例えば、次のように行われる。すなわち、ユーザがあるデータサーバ１０−１のデータ管理部１２−１に登録されているデータを別のデータサーバ１０−２に移動させる指示を入力したとする。この場合、データ管理部１２−１は、そのデータのグローバルＩＤをそのデータと共にデータサーバ１０−２に渡す。移動対象のデータをローカルＩＤで指定されている場合、データ管理部１２−１は、ＩＤ変換部１３−１からそのデータのグローバルＩＤを取得した上で、データと共にデータサーバ１０−２に送る。これを受け取ったデータサーバ１０−２は、前述の図５の手順に従い、そのデータをデータ管理部１２−２に登録する。

次に、図１１及び図１２を参照して、上記実施形態の変形例を説明する。図１１に示すように、この変形例では、データサーバ１０は認証部１７を備える。認証部１７は、データ要求元のユーザが当該データサーバ１０、又は要求対象データに対するアクセスできるかどうかを判定する。例えば、各ユーザの当該データサーバ１０に対するアクセス権、又は当該データサーバ１０内に登録された各データへのアクセス権を、データサーバ１０又は該サーバ１０からアクセス可能な他のサーバに登録しておき、このアクセス権情報に基づき上述の判定を行えばよい。このアクセス権の判定は、クライアント３０からのデータ要求に対してだけでなく、他のサーバ１０からのデータ問合せに対しても行う。アクセス権判定のための基礎となるユーザ情報（ユーザＩＤなど）は、例えばクライアント３０からデータ要求を受け取ったデータサーバ１０が、その要求を処理する前に、例えばユーザＩＤとパスワードの入力を求めるなどの方法でユーザ認証を行うことで、取得できる。そして、他のデータサーバ１０−１からデータ問合せを受けたデータサーバ１０−２に当該データが存在する場合、サーバ１０−２がサーバ１０−１に要求元のユーザＩＤを送信するよう要求する。この代わりに、データ問合せの際にユーザＩＤを併せて送るようにしても良い。サーバ１０−２は、問合せ元から送られてきたユーザＩＤをもとに、アクセス権情報を参照して、当該要求元のユーザがサーバ１０−２及び当該データにアクセスする権限を持つかどうかを判定する。サーバ及びデータの一方でもアクセス権がない場合は、当該ユーザはそのデータにアクセスできないと判定する。

また、アクセス可否判定の別の例として次のようなものもある。すなわち、データサーバ１０が定期メンテナンス等でユーザからのアクセスを制限している場合に、他のデータサーバ１０からのデータ問合せに対して一律に、ユーザからのアクセスを不可と判定するという方法である。

また、問合せが受けたデータサーバ１０−２が、常時監視している自身の処理負荷に基づき、要求元のユーザからのアクセスを認めるかどうかを判定しても良い。すなわち、処理負荷が所定の閾値より高ければユーザからのアクセスを認めず、そうでなければアクセスを認めるようにするなどである。

この変形例において、他のデータサーバ１０−１からデータ問合せを受けたデータサーバ１０−２の処理手順を図１２に示す。この手順では、データサーバ１０−２は、データ問合せから対象データのグローバルＩＤを取得し（Ｓ２００）、上述の方法で要求元ユーザからその対象データへのアクセスを認めるかどうかを判定する（Ｓ２１０）。アクセスを認める（すなわち「アクセス不可」ではない）場合は、図８のステップＳ２０２以降の処理に進めばよい。一方、アクセス不可の場合は、データサーバ１０−２はその旨をデータサーバ１０−１に通知する（Ｓ２１２）。この通知を受け取ったデータサーバ１０−１は、別のデータサーバ１０を探してデータ問合せを繰り返す。

データサーバ１０−２は、ステップＳ２１２で処理を終了しても良いが、図１２の例では、更に対象データが自身のデータ管理部１２−２に登録されているかどうかを調べている（Ｓ２１４）。このとき、必要に応じてＩＤ変換部１３−２によりＩＤ変換を行う。そして、対象データがデータ管理部１２−２にあれば（ステップＳ２１６の判定結果がＹ）、対象データのローカルＩＤは通知せずに対象データを持っている旨をデータサーバ１０−１に通知する（Ｓ２１８）。その通知を受け取ったデータサーバ１０−１は、要求対象データがアクセス不可のデータサーバ１０−２にあることが判明したので、探索を打ち切る。このとき、データサーバ１０−１が、データ要求元のクライアント３０に対して、ユーザのアクセスできないデータサーバに要求対象データがある旨を回答するようにしてもよい。

なお、ステップＳ２１２でアクセス不可の旨の通知を問合せ元のサーバ１０−１に送る代わりに、データ管理部１２−２の検索の後で、その結果を踏まえた通知（「アクセス不可且つ対象データ存在」又は「アクセス不可且つ対象データなし）を送るようにしてもよい。

次に、別の変形例を説明する。上記実施形態では、検出部１４が所定のメッセージをブロードキャストすることにより他のデータサーバ１０を検出した。これに対し、図１３に示すような変形例も考えられる。この変形例では、データ管理システムを構成する各データサーバ１０ａが、他のデータサーバ１０ａのサーバＩＤのリスト（「サーバリスト」と呼ぶ）を記憶したサーバリスト記憶部１８を備えている。サーバリストは、データサーバ１０ａの管理者がサーバリスト記憶部１８に登録してもよいし、上記実施形態のブロードキャストによる検出の手法での検出結果に基づき自動作成してもよい。また、後述する手順の中で他のデータサーバ１０ａから取得したサーバリストの情報をサーバリスト記憶部１８に追加することもできる。検出部１４ａは、このサーバリスト記憶部１８から他のデータサーバ１０ａを検出する。

また、この場合、他のデータサーバ１０ａ−１からデータ問合せを受けたデータサーバ１０ａ−２は、問合せ対象のデータが当該サーバ１０ａ−２に存在しないことが判った場合、単にその旨をサーバ１０ａ−１に回答しても良いが、当該サーバ１０ａ−２のサーバリスト記憶部１８内のサーバＩＤ（又はそのリスト）を回答しても良い。サーバ１０ａ−１は回答として受け取ったサーバＩＤ（又はそのリスト）を自身のサーバリスト記憶部１８に追加することで、サーバリストを拡張することができる。

この変形例によれば、データサーバ１０ａは、他のデータサーバ１０ａが持つサーバリストを取得することで、サーバリスト記憶部１８に未登録のデータサーバ１０ａを知ることができ、それら新たに知ったデータサーバ１０ａに対しても問合せを行うことができる。

また、図１１の例でサーバリスト記憶部１８から問合せ未済のサーバが無くなった場合に、ブロードキャストによる検出を行い、その結果をサーバリスト記憶部１８に登録するようにしてもよい。

また、以上の実施形態では、クライアント３０からのデータ要求が、要求先のサーバ１０−１により他のサーバ１０−２にリダイレクトされた場合、リダイレクト先のサーバ１０−２に要求対象データが存在していた。リダイレクトはデータ問合せの結果に基づき行われるので、リダイレクト先に要求対象データが存在する可能性は極めて高いが、存在しない場合も考えられる。例えば、データ問合せの後、リダイレクトされたデータ要求が到来するまでの間に、要求対象データがデータサーバ１０−２から他のデータサーバに移動した場合などである。

また、別の例として、各データサーバ１０が、他のデータサーバへのデータ問合せの結果をキャッシュする場合も考えられる。すなわちこの場合、データサーバ１０は、データ問合せの結果、要求対象データが存在すると判明したデータサーバ１０のサーバＩＤをその要求対象データのデータＩＤと対応づけてキャッシュメモリに一時的に記憶する。そして、データサーバ１０は、他のデータサーバを検出してデータ問合せを行う前に、そのキャッシュメモリの中に、要求対象データを保持するデータサーバの情報が存在するかどうかを調べ、存在すればそのデータサーバに対してデータ要求をリダイレクトする。この場合も、キャッシュの情報が古くなっていると、リダイレクトにより導かれたデータサーバ１０には要求対象データが存在しない場合がある。

このようにリダイレクト先のデータサーバ１０に要求対象データが存在しない場合、リダイレクト先のサーバ１０は、クライアント３０からデータ要求を受け取ったサーバという意味では、最初に要求を受け取ったサーバと何ら変わらないので、今度はそのリダイレクト先のデータサーバ１０が、上述の同じ処理手順を実行することで、要求対象データを持つデータサーバ１０を探すことになる。このように、リダイレクト先に要求対象データが無くても、本実施形態によれば、リダイレクト先のサーバ１０がクライアント３０から要求を受けたサーバとなって再帰的に探索を繰り返すことができる。

以上に説明した実施形態及び変形例は、データがサーバ間で移動した場合に限らず、同一サーバ内でデータが移動してＵＲＬが変わってしまう場合にも適用可能である。例えば、データの仮想ＵＲＬが"http://xxx.fx.co.jp/Folder1/Folder2/uuid1"であったとする。このうち"uuid1"がそのデータのグローバルＩＤであり、"/Folder1/Folder2/"はサーバ"xxx.fx.co.jp"内でのそのデータのパスである。すなわち、この仮想ＵＲＬは、一般的なロケーションベースのＵＲＬと、グローバルに一意なグローバルＩＤとの折衷型である。このような折衷型の仮想ＵＲＬでも、グローバルＩＤを含んでいる以上、上記実施形態の仕組みでそのデータを検索することができる。更に、この仮想ＵＲＬでは、サーバ内でのデータのパス情報も含んでいるので、従来からのロケーション（ディレクトリ）ベースでのデータの所在場所の表示（例えばフォルダツリー表示）等を行うことができる。このようなデータ"uuid1"が同じサーバ内のディレクトリ"/Folder3/Folder4/"に移動した場合、仮想ＵＲＬは正しくは"http://xxx.fx.co.jp/Folder3/Folder4/uuid1"となるが、ユーザが元の仮想ＵＲＬ"http://xxx.fx.co.jp/Folder1/Folder2/uuid1"を用いてアクセスしたとしても、その仮想ＵＲＬはグローバルＩＤを含んでいるので、ディレクトリ"/Folder3/Folder4/"内のデータ"uuid1"に正しくアクセスできる。もちろん、この場合、データ管理部１２におけるデータ"uuid1"のリンク情報がディレクトリ"/Folder3/Folder4/"内のそのデータを指すように正しく更新されているものとする。

以上説明した実施形態及び変形例に係るデータサーバは、汎用のコンピュータシステムに、上述したデータサーバの機能・動作を記述したプログラムを実行させることにより実現される。

本発明に係るデータ管理システムの概略構成を示す図である。 実施例のデータサーバの構成を示す図である。 データ管理部におけるデータの管理情報の構造を示す図である。 ＩＤ変換部に登録される対応表の一例を示す図である。 データ管理部に新たにデータが登録される場合の処理手順を示すフローチャートである。 仮想ＵＲＬの例を示す図である。 仮想ＵＲＬの例を示す図である。 データサーバがクライアントからデータ要求情報を受け取ったときの処理手順を示すフローチャートである。 他のデータサーバから問合せを受けたときのデータサーバの処理手順を示すフローチャートである。 実施形態のシステムの動作を説明するための図である。 実施形態のシステムの動作を説明するための図である。 変形例のデータサーバの概略構成を示す図である。 変形例のデータサーバがクライアントからデータ要求情報を受け取ったときの処理手順を示すフローチャートである。 別の変形例のデータサーバの概略構成を示す図である。

符号の説明

１０ データサーバ、１２ データ管理部、１３ ＩＤ変換部、１４ 検出部、１６ 問合せ部、２０ ネットワーク、３０ クライアント。

Claims (7)

1. ネットワークを介して接続された他のデータサーバと連携してデータ管理システムを構成するデータサーバとして、コンピュータシステムを動作させるためのプログラムであって、該コンピュータシステムを、
   登録されるデータを記憶するデータ管理部であって、登録されるデータに対し当該データサーバ内で一意なローカル識別情報を付与するとともに、そのデータに対しグローバルに一意なグローバル識別情報が付与されていない場合はグローバル識別情報を付与するデータ管理部、
   データに付与されたローカル識別情報とグローバル識別情報との対応関係を記憶する対応関係記憶部、
   クライアントから受け取ったデータ要求の要求対象データをデータ管理部から検索し、該当するデータが検索できた場合はそのデータをクライアントに提供し、検索できなかった場合は、データ管理システムを構成する他のデータサーバに対し該要求対象データのグローバル識別情報を含むデータ問合せを送ることにより、前記要求対象データを持つデータサーバを探索する要求処理部であって、前記データ要求が要求対象データをローカル識別情報により指定している場合は、前記対応関係記憶部からその要求対象データのグローバル識別情報を求めて前記データ問合せを生成する要求処理部、
   他のデータサーバからデータ問合せを受けた場合、該データ問合せに含まれるグローバル識別情報に対応するデータを前記データ管理部から検索し、その検索の結果に応じた応答を前記他のデータサーバに送る応答部、
   として機能させるためのプログラム。
2. 前記コンピュータシステムを、前記データ管理システムを構成する他のデータサーバを検出する検出部、として機能させるとともに、
   前記要求処理部は、該検出部が検出した他のデータサーバに対して前記データ問合せを送る、
   ことを特徴とする請求項１記載のプログラム。
3. 前記要求処理部は、前記データ要求の要求対象データが前記データ管理部から検索できなかった場合、前記データ問合せにより探索した前記要求対象データを持つデータサーバのサーバ識別情報を含むリダイレクト情報を前記クライアントに送信する、ことを特徴とする請求項１記載のプログラム。
4. 前記応答部は、当該データサーバが前記要求対象データに対する前記クライアントからのアクセスを認めない場合、他のデータサーバからのデータ問合せに対してその旨を回答すると共に、該データ問合せに含まれるグローバル識別情報に対応するデータが前記データ管理部から検索された場合は、前記データ問合せの対象であるデータが当該データサーバに存在する旨を前記他のデータサーバに回答し、
   前記要求処理部は、前記要求対象データに対する前記クライアントのアクセスを認めない旨の回答をデータ問合せの送り先のデータサーバから受け取った場合において、更に該データ問合せの対象であるデータが該送り先のデータサーバに存在する旨の回答を受け取った場合は、前記クライアントに対して前記リダイレクト情報を送ることなく前記要求対象データを持つデータサーバの探索を終了する、
   ことを特徴とする請求項３記載のプログラム。
5. ネットワークに接続された複数のデータサーバから構成されるデータ管理システムであって、
   各データサーバが、
   登録されるデータを記憶するデータ管理部であって、登録されるデータに対し当該データサーバ内で一意なローカル識別情報を付与するとともに、そのデータに対しグローバルに一意なグローバル識別情報が付与されていない場合はグローバル識別情報を付与するデータ管理部と、
   データに付与されたローカル識別情報とグローバル識別情報との対応関係を記憶する対応関係記憶部と、
   クライアントから受け取ったデータ要求の要求対象データをデータ管理部から検索し、該当するデータが検索できた場合はそのデータをクライアントに提供し、検索できなかった場合は、データ管理システムを構成する他のデータサーバに対し該要求対象データのグローバル識別情報を含むデータ問合せを送ることにより、前記要求対象データを持つデータサーバを探索する要求処理部であって、前記データ要求が要求対象データをローカル識別情報により指定している場合は、前記対応関係記憶部からその要求対象データのグローバル識別情報を求めて前記データ問合せを生成する要求処理部と、
   他のデータサーバからデータ問合せを受けた場合、該データ問合せに含まれるグローバル識別情報に対応するデータを前記データ管理部から検索し、その検索の結果に応じた応答を前記他のデータサーバに送る応答部と、
   を備えることを特徴とするデータ管理システム。
6. ネットワークを介して接続された他のデータサーバと連携してデータ管理システムを構成するデータサーバであって、
   登録されるデータを記憶するデータ管理部であって、登録されるデータに対し当該データサーバ内で一意なローカル識別情報を付与するとともに、そのデータに対しグローバルに一意なグローバル識別情報が付与されていない場合はグローバル識別情報を付与するデータ管理部と、
   データに付与されたローカル識別情報とグローバル識別情報との対応関係を記憶する対応関係記憶部と、
   クライアントから受け取ったデータ要求の要求対象データをデータ管理部から検索し、該当するデータが検索できた場合はそのデータをクライアントに提供し、検索できなかった場合は、データ管理システムを構成する他のデータサーバに対し該要求対象データのグローバル識別情報を含むデータ問合せを送ることにより、前記要求対象データを持つデータサーバを探索する要求処理部であって、前記データ要求が要求対象データをローカル識別情報により指定している場合は、前記対応関係記憶部からその要求対象データのグローバル識別情報を求めて前記データ問合せを生成する要求処理部と、
   他のデータサーバからデータ問合せを受けた場合、該データ問合せに含まれるグローバル識別情報に対応するデータを前記データ管理部から検索し、その検索の結果に応じた応答を前記他のデータサーバに送る応答部と、
   を備えるデータサーバ。
7. ネットワークに接続された複数のデータサーバから構成されるデータ管理システムにより実行されるデータ管理方法であって、
   各データサーバが、
   自身が備えるデータ管理部に登録されるデータに対し当該データサーバ内で一意なローカル識別情報を付与するとともに、そのデータに対しグローバルに一意なグローバル識別情報が付与されていない場合はグローバル識別情報を付与するステップと、
   データに付与されたローカル識別情報とグローバル識別情報との対応関係を対応関係記憶部に記憶するステップと、
   クライアントから受け取ったデータ要求の要求対象データをデータ管理部から検索し、該当するデータが検索できた場合はそのデータをクライアントに提供し、検索できなかった場合は、データ管理システムを構成する他のデータサーバに対し該要求対象データのグローバル識別情報を含むデータ問合せを送ることにより前記要求対象データを持つデータサーバを探索するステップであって、前記データ要求が要求対象データをローカル識別情報により指定している場合は、前記対応関係記憶部からその要求対象データのグローバル識別情報を求めて前記データ問合せを生成するステップと、
   他のデータサーバからデータ問合せを受けた場合、該データ問合せに含まれるグローバル識別情報に対応するデータを前記データ管理部から検索し、その検索の結果に応じた応答を前記他のデータサーバに送るステップと、
   を実行するデータ管理方法。

Images