JP2006323721A - データ管理システム及びデータサーバ及びデータ管理方法 - 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)は、データを有するデータサーバ１０のホスト名とそのサーバ１０において当該データが実際に記憶されている場所を示すパス名とによって当該データを一意に指すのに対し、本実施形態のデータＩＤは、そのようなデータの所在場所の情報とは独立した識別情報である。

図２にデータ管理部１２が管理する各データの管理情報のデータ構造を示す。この図に示すように、データ管理部１２は、登録された各データにつき、そのデータのデータＩＤ１０２と、データサーバ１０内でそのデータを指し示すリンク情報（例えばそのデータのパス名）１０４とを対応づけて管理している。

データ管理部１２は、新規のデータを登録する場合、グローバルに一意なデータＩＤを生成し、これをそのデータの記憶場所を示すリンク情報と対応づけて管理する。また、データ管理部１２は、管理していたデータがデータサーバ１０から削除された場合には、そのデータの管理情報も削除する。

なお、既にデータＩＤが付与済みのデータがデータ管理部１２に登録される場合（例えばあるデータサーバが管理しているデータを別のデータサーバに移動する場合）には、データ管理部１２は、そのデータに対して新たにデータＩＤを付与することをせず、その既付与のデータＩＤに対し、そのデータのリンク情報の対応づけて管理する。

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

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

本実施形態では、クライアント３０は、本システムに対してデータを要求する場合、図３に示すように、データを管理するデータサーバ１０のホスト名１１２と、そのデータのデータＩＤ１１４とを含む仮想ＵＲＬ１１０を用いてデータを指定する。当然ＵＲＬであるため、プロトコル、ポート等の情報も含まれるが、ここでは特に説明しない。グローバルに一意的なデータＩＤは図３に例示したデータＩＤ１１４の桁数よりも遥かに長くなるため、図３ではその一部を省略して示した。この仮想ＵＲＬは、「xxx.fx.co.jp」という名前のデータサーバが管理している「12345......67890」というデータＩＤをもつデータを指している。なお、図３の仮想ＵＲＬのうちホスト名１１２とデータＩＤ１１４に挟まれた「get」は、データサーバ１０が提供するメソッドの名前である。データサーバ１０が管理するデータに対して複数種類の操作をクライアント３０に認める場合、仮想ＵＲＬにはその操作を示すメソッドを含めるようにする。逆に言えば、データサーバ１０が単に要求されたデータをクライアント３０に提供するだけであれば、このようなメソッドの記述は不要である。

クライアント３０（例えばウェブブラウザ）が、この仮想ＵＲＬ１１０を用いてデータ要求を行った場合、ホスト名１１２が示すサーバに対し、データＩＤ１１４を含んだデータ要求情報が送信されることになる。

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

この手順では、まずデータサーバ１０−１は、クライアント３０からのデータ要求情報からデータＩＤを抽出し（Ｓ１００）、データ管理部１２−１からそのデータＩＤに対応する実データのリンク情報を検索する（Ｓ１０２）。そのデータＩＤに対応するリンク情報が検索できた場合（Ｓ１０４の判定結果が肯定（Ｙ））、データサーバ１０−１は、そのリンク情報が指し示すデータの実体をデータサーバ１０−１内の記憶装置から取得し、クライアント３０に提供する（Ｓ１１４）。

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

他のデータサーバ１０−２が見つかると、データサーバ１０−１は、問合せ部１６−１に、見つけた他のデータサーバ１０−２に対する問合せを指示する。この指示に応じ、問合せ部１６−１は、クライアント３０からのデータ要求に含まれるデータ識別情報を含んだデータ問合せをデータサーバ１０−２に送り、そのデータ識別情報に対応するデータを持っているか否かを問い合わせる（Ｓ１０８）。この問合せを受けたデータサーバ１０−２の問合せ部１６−２の動作については、後で詳しく説明する。

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

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

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

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

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

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

なお、ステップＳ２０６では、問合せ対象のデータが存在する旨を示すメッセージを問合せ元に返す代わりに、問合せ対象のデータの仮想ＵＲＬ（すなわちそのデータを持つデータサーバ１０−２のサーバＩＤと、そのデータのデータ識別情報を含んだ仮想ＵＲＬ）を返してもよい。この場合、問合せ元のデータサーバ１０−１は、ステップＳ１１２において、データサーバ１０−２から返された仮想ＵＲＬをクライアント３０に返せばよい。

以上説明したようなデータ管理システムの動作を、図６〜図８を参照して説明する。

図６に示すように、クライアント３０からデータサーバ１０−１に送ったデータ要求（１）の対象データがデータサーバ１０−１に存在する場合は、その対象データがデータサーバ１０−１からクライアント３０に提供される（２）。

一方、図７に示すように、クライアント３０からデータサーバ１０−１に送ったデータ要求（１）の対象データがデータサーバ１０−１に存在しない場合は、検出部１４−１が他のデータサーバ１０−２を検出し（２）、このデータサーバ１０−２に対してデータ問合せを行う（３）。この問合せにより、データサーバ１０−２に要求対象データが存在することが判明すると、データサーバ１０−１はクライアント３０からのデータ要求をデータサーバ１０−２にリダイレクトする（４）。このデータサーバ１０−２は、リダイレクトされたデータ要求に対して、要求対象データをクライアント３０をクライアント３０に提供する（５）。

また、図８は、クライアント３０の要求するデータがデータサーバ１０−１にも１０−２にも存在せず、データサーバ１０−３に存在する場合を示している。この場合、（２）検出部１４−１が検出した他のデータサーバ１０−２，１０−３のうち、まず問合せ部１６−１はサーバ１０−２に対し問合せを行い、データは存在しないとの回答を得る（３）。そこで、問合せ部１６−１は次のデータサーバ１０−３に問合せを行い、データが存在するとの回答を得る（４）。すると、データサーバ１０−１は、クライアント３０からのデータ要求をデータサーバ１０−３にリダイレクトする（５）。データサーバ１０−３は、リダイレクトされたデータ要求に対し、要求対象データをクライアント３０に提供する（６）。

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

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

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

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

図１０に、この変形例のデータサーバ１０ａがクライアント３０からデータ要求を受け取ったときの処理手順を示す。また、図１１に、この変形例のデータサーバ１０ａが他のサーバからデータ問合せを受けたときの処理手順を示す。これら手順において、図４及び図５に示した手順と同様のステップには同一符号を付し、説明を省略する。

図１０の手順では、クライアント３０から要求されたデータがデータサーバ１０ａ内にない場合、検出部１４ａがサーバリスト記憶部１８から問合せ未済のサーバの識別情報を検出し（Ｓ１０６ａ）、そのサーバに対し、要求対象データを持っているか否かの問合せを行う（Ｓ１０８）。

この問合せを受けたデータサーバ１０ａでは、図１１に示したように、その要求対象データのデータＩＤを自身のデータ管理部１２から検索できなかった場合に、自身のサーバリスト記憶部１８に記憶しているサーバリスト全体又はその一部（例えば１つのサーバＩＤだけでもよい）を、問合せ元のデータサーバ１０ａに返す（Ｓ２１０）。

再び図１０の手順に戻り、問合せ先からの応答を受け取ったデータサーバ１０ａは、その応答が、要求対象データがある旨を示すものであれば、上記実施形態同様クライアント３０からの要求をその問合せ先にリダイレクトし（Ｓ１１２）、そうでなければ、問合せ先から受け取ったサーバリストの情報を自身のサーバリスト記憶部１８に追加した上で（Ｓ１２０）、ステップＳ１０６ａに戻る。

この変形例のシステムの動作を、図１２を参照して説明する。この図では、煩雑さを避けるため、データサーバ１０ａ内の手段の一部の記載を省略している。また、この例は、データサーバ１０ａ−１のサーバリスト記憶部１８（図示省略）には、サーバ１０ａ−２が登録されており、サーバ１０ａ−３は登録されていない場合の例である。

クライアント３０からデータサーバ１０ａ−１に送ったデータ要求（１）の対象データがデータサーバ１０ａ−１に存在しない場合は、検出部１４ａがサーバリスト記憶部１８から他のデータサーバ１０ａ−２を検出し（２）、このデータサーバ１０ａ−２に対してデータ問合せを行う（３）。この問合せに対しデータサーバ１０ａ−２からデータが存在しないとの回答を得ると、問合せ部１６は次のデータサーバ１０ａ−３に問合せを行い、データが存在するとの回答を得る（４）。すると、データサーバ１０ａ−１は、クライアント３０からのデータ要求をデータサーバ１０ａ−３にリダイレクトする（５）。データサーバ１０ａ−３は、リダイレクトされたデータ要求に対し、要求対象データをクライアント３０をクライアント３０に提供する（６）。

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

また、この変形例における他のデータサーバの検出手法と、上記実施形態におけるブロードキャストによる検出手法とを組み合わせることも可能である。例えば、図１２の例において、データサーバ１０ａ−１が最初はサーバリストを持たず、ブロードキャストによりデータサーバ１０ａ−２を検出し、このサーバ１０ａ−２からサーバリストの情報を取得するといった手順も可能である。この場合、サーバ１０ａ−１は、ブロードキャストにより検出したサーバＩＤや、サーバ１０ａ−２から取得したサーバリストを自己のサーバリスト管理部１８に保存すれば、次回以降のデータ要求に対しては図１１の手順でサーバ検出が行える。もちろん、サーバ１０ａ−１が検出したサーバＩＤ等を保存しない構成も可能である。

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

次に、図１３〜図１７を参照して、第２の変形例を説明する。この変形例では、図１３に示すように、データサーバ１０ｂは、問合せ部１６による問合せにより判明したデータの所在情報をキャッシュする所在情報キャッシュ２０を備えている。所在情報キャッシュ２０にキャッシュされる所在情報レコードは、図１４に示すように、データＩＤ１２２と、そのデータＩＤ１２２により示されるデータの所在を示す仮想ＵＲＬ１２４（図３に例示したものと同様のもの）とを含んでいる。なお、仮想ＵＲＬ１２４の代わりに、当該データを管理するデータサーバ１０ｂのサーバＩＤを所在情報レコードに含めるようにしてもよい。

図１５に、クライアントからデータ要求情報を受けたときの、第２の変形例のデータサーバ１０ｂの処理手順を示す。また、図１６に、この変形例のデータサーバ１０ｂが他のサーバからデータ問合せを受けたときの処理手順を示す。これら手順において、図４及び図５に示した手順と同様のステップには同一符号を付し、説明を省略する。

図１５の手順では、クライアント３０から要求されたデータがデータサーバ１０ｂ内にない場合、データサーバ１０ｂは、所在情報キャッシュ２０から、要求されたデータのデータＩＤに該当する所在情報レコードを検索する（Ｓ１３０）。検索できた場合は（ステップＳ１３２の判定結果が肯定（Ｙ））、その所在情報レコードに示される仮想ＵＲＬをクライアント３０に返すことで、クライアント３０のデータ要求をリダイレクトする（Ｓ１１２）。

ステップＳ１３２の判定結果が否定（Ｎ）の場合、データサーバ１０ｂは検出部１２に他のデータサーバ１０ｂを検出させ（Ｓ１０６）、これにより検出されたデータサーバ１０ｂに対して、要求対象データのデータＩＤを含んだデータ問合せを送る（Ｓ１０８）。

この問合せを受けた他のデータサーバ１０ｂでは、図１６に示したように、その要求対象データのデータＩＤを自身のデータ管理部１２から検索できなかった場合に、自身の所在情報キャッシュ２０からそのデータＩＤに該当する所在情報レコードを検索する（Ｓ２１２）。そして、所在情報レコードが検索できた場合（ステップＳ２１４の判定結果が肯定（Ｙ））は、その所在情報レコード中の仮想ＵＲＬ（又はサーバＩＤ）を、要求対象データの所在の候補の情報として、問合せ元のデータサーバ１０ｂに返す（Ｓ２１６）。ここで、キャッシュ２０から検索した所在情報は、時間の経過により現在の状況を正しく示していない場合もあるので、確認されたデータの所在情報ではなく、その候補として取り扱う。一方、所在情報が検索できなかった場合は、問合せ対象のデータが存在しない旨を問合せ元のデータサーバ１０ｂに応答する（Ｓ２１８）。

再び図１５の手順に戻り、問合せ先からの応答を受け取ったデータサーバ１０ａは、その応答が、要求対象データが存在する旨を示すもの（又は問合せのサーバＩＤを含んだ仮想ＵＲＬ）であれば（ステップＳ１１０）、要求対象データが問合せ先に確実に存在するということなので、そのデータのデータ識別情報と問合せ先のサーバＩＤを含んだ仮想ＵＲＬ（サーバＩＤだけでもよい）とを所在情報キャッシュ２０に追加（Ｓ１３４）すると共に、上記実施形態同様クライアント３０からの要求をその問合せ先にリダイレクトする（Ｓ１１２）。なお、ステップＳ１３４とＳ１１２の順序は逆でも構わない。問合せ先からの回答が、要求対象データが存在する旨を示す情報でなければ、その回答が要求対象データの仮想ＵＲＬ（又はサーバＩＤ）を含むかどうかを判定する（Ｓ１３６）。

ステップＳ１３６の判定で、仮想ＵＲＬ（又はサーバＩＤ）が含まれると判定された場合（ステップＳ１３６の判定結果が肯定（Ｙ））、データサーバ１０ｂは、その仮想ＵＲＬ（又はサーバＩＤ）をクライアント３０に返すことでデータ要求をリダイレクトする（Ｓ１１２）。そうでない場合は、ステップＳ１０６に戻る。

図１５の手順では、問合せ先からの回答が所在情報の候補であった場合（ステップＳ１３６の判定結果がＹ）、その所在情報をキャッシュ２０に追加せずにリダイレクトのみを行ったが、これは、各サーバ１０ｂがキャッシュ２０に保持している所在情報が、時間の経過により現在の状況を正しく示していない場合もあるためである。すなわち、図１５の手順では、問合せ先が要求対象データを持っていることが確認された場合にのみ、キャッシュ２０に所在情報を登録することとしたわけである。ただし、この方式は一例に過ぎず、この代わりに問合せ先から受け取った所在情報は、問合せ先のものであっても他のサーバのものであっても、すべて所在情報キャッシュ２０に登録するようにしてもよい。

なお、第２の変形例において、所在情報キャッシュ２０から求められた所在情報（問合せ先のキャッシュ２０から求められたものも含む）を用いてリダイレクト（Ｓ１１２）を行った場合、キャッシュ２０の情報が古い等の理由から、リダイレクト先のデータサーバ１０ｂに要求対象データがないという事態も生じ得る。この場合は、リダイレクト先のデータサーバ１０ｂが、図１５の手順に従ってそのデータを持つデータサーバを探索し、探索できたデータサーバにデータ要求をリダイレクトする。このようなリダイレクトを繰り返すうちに、クライアント３０は要求対象データを取得できる。

また、図１５の手順では、他のデータサーバを検出するのにブロードキャストを利用したが、これに限らず、サーバリストを利用する第１の変形例と同様の方式を用いてもよい。

この変形例のシステムの動作を、図１７を参照して説明する。この図では、煩雑さを避けるため、データサーバ１０ｂ内の手段の一部の記載を省略している。

クライアント３０からデータサーバ１０ｂ−１に送ったデータ要求（１）の対象データがデータサーバ１０ｂ−１に存在しない場合、検出部１４が他のデータサーバ１０ｂ−２を検出し（２）、このデータサーバ１０ｂ−２に対してデータ問合せを行う（３）。ここで、データサーバ１０ｂ−２が、そのデータを持っていないが、そのデータがデータサーバ１０ｂ−３にある旨を示す所在情報をキャッシュ２０に持っている場合には、その所在情報がサーバ１０ｂ−１に返される。これを受け取ったデータサーバ１０ｂ−１は、その所在情報をクライアント３０に送ることにより、データ要求をデータサーバ１０ｂ−３にリダイレクトする（４）。データサーバ１０ｂ−３は、リダイレクトされたデータ要求の対象データを保持していれば、その要求対象データをクライアント３０に提供する（５）。

このように、この第２の変形例によれば、データサーバ１０ｂがクライアント３０からの要求や他のサーバ１０ｂからの問合せの対象データの所在情報をキャッシュしていれば、その所在情報を要求元や問合せ元に通知することで、より効率的にクライアント３０がデータに到達することができる。

なお、第２の変形例では、所在情報キャッシュ２０が持っているデータが古いと、誤ったサーバ１０ｂにデータ要求をリダイレクトしてしまうことになる。このような不具合を解消するための第３の変形例について、図１８〜図２５を参照して説明する。

第３の変形例の基本的な考え方は、要求対象データの所在（すなわち該データを管理するデータサーバ）が確認された場合に、所在が確認されるまでに関与した各データサーバに通知することで、それら各サーバの所在情報キャッシュ２０を更新するというものである。

この方式を実現するため、第３の変形例では、まずリダイレクト先のデータサーバに対し、リダイレクト元のデータサーバを知らせる仕組みを導入する。すなわち、リダイレクト元のデータサーバがクライアント３０に返すリダイレクト情報、すなわち仮想ＵＲＬの中に、リダイレクト元のデータサーバのサーバＩＤを組み込む。例えば、図１８に例示する仮想ＵＲＬ１１０ａ、リダイレクト先のサーバの識別情報（ホスト名１１２）とデータＩＤ１１４を含む仮想ＵＲＬの末尾に、リダイレクト元のサーバの識別情報を示したＨＴＴＰのクエリ文字列を、リダイレクト元情報１１６として含んでいる。これは、リダイレクト元のサーバの識別情報をＩＰアドレス（「160.8.***.***」）で示したものである。もちろん、サーバＩＤはホスト名など他の表現方式で表したものでも構わない。このように仮想ＵＲＬにリダイレクト元情報１１６を組み込んでリダイレクト先のサーバに渡すことで、リダイレクト先のサーバは、要求されたデータの所在が確認できた場合、その所在情報をリダイレクト元のサーバにフィードバックすることができる。

また、第３の変形例では、要求対象データの所在が確認されるまでに各データサーバがデータ問合せを送った問合せ先のデータサーバを記録し、確認された所在情報をそれら各問合せ先にも通知する。

また第３の変形例では、図１９に示すように、各データサーバ１０ｃは、所在情報キャッシュ２０に加え、ログ記憶部２２を備える。ログ記憶部２２は、他のデータサーバ１０ｃからのリダイレクトや、他のデータサーバへのデータ問合せやリダイレクトの事実を記録するログを保持する。ログ記憶部２２には、クライアント３０から受け取ったデータ要求に対して、１つのログレコードが記憶される。このログレコードのデータ構造の例を図２０に示す。この例では、ログレコードには、当該データ要求の要求対象データのデータＩＤ１３２，当該データ要求のリダイレクト元１３２のサーバＩＤ１３４，当該データ要求に応じたデータ問合せを送った問合せ先のサーバＩＤ１３６，及び当該データ要求をリダイレクトしたリダイレクト先のサーバＩＤ１３８が含まれる。１つのログレコードに対し、データＩＤ１３２は１つであり、リダイレクト元１３４とリダイレクト先１３８は高々１つである。また、データサーバ１０ｃ自身の所在情報キャッシュ２０からリダイレクト先１３８が見つかる場合（したがって問合せは一度もしない）もあれば、リダイレクト先１３８が見つかるまで複数の問合せ先に問い合わせることもあるので、問合せ先１３６は０以上である。

第３の変形例のデータサーバ１０ｃがクライアントからデータ要求情報を受け取ったときの処理手順を図２１Ａ及び２１Ｂに示す。これら手順において、図４及び図１５に示した手順と同様のステップには同一符号を付し、説明を省略する。

この手順では、クライアント３０からのデータ要求の要求対象データがデータ管理部１２から検索できなかった場合、データサーバ１０ｃは、まずログ記憶部２２に当該要求対象データについてのログレコードの生成する（Ｓ１４０）。ただし、この時点では、ログレコードには、その要求対象データのデータＩＤ１３２のみが登録されている（図２０参照）。次に、そのデータ要求が、リダイレクト元情報を含むかどうかを判定し（Ｓ１４２）、リダイレクト元情報を含む場合には、それをログレコードのリダイレクト元１３４の欄に登録する（Ｓ１４４）。データ要求がリダイレクト元情報を含まない場合は、ステップＳ１４４はスキップされる。

そして、データサーバ１０ｃは、キャッシュ２０から要求対象データの所在情報を検索する（Ｓ１３０）。この検索で所在情報が見つかった場合（Ｓ１３２）、データサーバ１０ｃは、その所在情報をクライアント３０に通知することで、データ要求をリダイレクトする（Ｓ１１２）。このとき、その所在情報に示されるリダイレクト先のサーバＩＤを、ログレコードのリダイレクト先１３８の欄に登録する（Ｓ１４８）。

要求対象データの所在情報がキャッシュ２０になかった場合（Ｓ１３２）は、検出部１４が他のデータサーバを検出し（Ｓ１０６）、検出できたデータサーバに対して問合せ部１６が要求対象データのデータ識別情報を含んだデータ問合せを送る（Ｓ１０８）。データサーバ１０ｃは他のデータサーバにデータ問合せを送った場合、その問合せの送り先のサーバＩＤを、そのデータ識別情報に対応するログレコードの問合せ先１３６の欄に追加する（Ｓ１４６）。そして、問合せ先が要求対象データを持っている旨を示す回答を受けると、データサーバ１０ｃは、要求対象データが問合せ先のサーバに存在する旨を示す所在情報をキャッシュに追加し（Ｓ１３４）、クライアント３０からの要求をその問合せ先にリダイレクトする（Ｓ１１２）。そして、リダイレクト先（この場合は問合せ先と同じ）のサーバＩＤを、当該要求対象データのログレコードに登録する（Ｓ１４８）。

ステップＳ１１０の判定結果が否定（Ｎ）の場合、問合せ先からの回答が要求対象データの所在情報を含むかどうかを判定する（Ｓ１３６）。この判定で、所在情報が含まれると判定された場合、データサーバ１０ｃ、その所在情報をクライアント３０に返すことでデータ要求をリダイレクトし（Ｓ１１２）、その所在情報に含まれるサーバＩＤを当該要求対象データに対応するログレコードのリダイレクト先１３８の欄に登録する（Ｓ１４８）。ステップＳ１３６の判定結果が否定（Ｎ）の場合は、ステップＳ１０６に戻る。

また、データサーバ１０ｃは、ステップＳ１０２で要求対象データを自身のデータ管理部１２から検索できた場合、検索したデータをクライアント３０に提供する（Ｓ１１４）。そして、クライアント３０からのデータ要求にリダイレクト元情報が含まれるか否かを判定し（Ｓ１５０）、含まれていれば、要求対象データが当該データサーバ１０ｃに存在する旨を示すキャッシュ更新情報を生成し、それをリダイレクト元情報が示すデータサーバに対して送信する（Ｓ１５２）。ここでキャッシュ更新情報は、要求対象データのデータＩＤと当該データサーバ１０ｃの識別情報とを含んだものでよい。

次に、図２２を参照して、キャッシュ更新情報を受け取ったデータサーバ１０ｃの動作を説明する。

この手順では、データサーバ１０ｃは、他のサーバからキャッシュ更新情報を受け取ると（Ｓ３００）、その情報を用いて所在情報キャッシュ２０を更新する（Ｓ３０２）。このキャッシュ更新では、例えば、キャッシュ更新情報に含まれるデータＩＤに該当する所在情報をキャッシュ２０から検索し、そのような所在情報がなければ、キャッシュ更新情報に含まれるデータＩＤとサーバＩＤのペアを所在情報としてキャッシュ２０に登録する。キャッシュ更新情報のデータＩＤに該当するものがキャッシュ２０中にあれば、それをキャッシュから削除し、キャッシュ更新情報から生成した所在情報をキャッシュ２０に追加する。そしてデータサーバ１０ｃは、そのデータＩＤに対応するログレコードをログ記憶部２２から検索し（Ｓ３０４）、そのようなログレコードがあれば、その中に示される問合せ先１３６及びリダイレクト元１３４の各データサーバに対し、同様のキャッシュ更新情報を送信する（Ｓ３０６，Ｓ３０８）。なお、問合せ先１３６とリダイレクト元１３４のいずれか一方が空欄の場合もある。また、問合せ先１３６の欄に複数のサーバが登録されている場合があり、この場合には、それら全ての問合せ先サーバに対してキャッシュ更新情報を送る。

データサーバ１０ｃは、キャッシュ更新情報を、リダイレクト先又は問合せ元から受け取る可能性があれば、図２２の手順はそのいずれの場合にも該当するものである。

なお、第３の変形例のデータサーバ１０ｃが他のサーバからデータ問合せを受けたときの処理手順は、第２の変形例の場合と同様でよい（図１６参照）。

第３の変形例のシステムの動作の具体例を、図２３及び図２４を参照して説明する。図２３では、煩雑さを避けるため、データサーバ１０ｃ内の手段の一部の記載を省略している。

クライアント３０からデータサーバ１０ｃ−１に送ったデータ要求（１）の対象データがデータサーバ１０ｃ−１に存在しない場合、検出部１４が他のデータサーバ１０ｃ−２を検出し（２）、このデータサーバ１０ｃ−２に対してデータ問合せを行う（３）。ここで、データサーバ１０ｃ−２は、そのデータを持っていないが、そのデータがデータサーバ１０ｃ−３にある旨を示す所在情報をキャッシュ２０に持っているので、その所在情報をサーバ１０ｃ−１に返す。これを受け取ったデータサーバ１０ｃ−１は、その所在情報をクライアント３０に送ることにより、データ要求をデータサーバ１０ｃ−３にリダイレクトする（４）。この一連の動作でデータサーバ１０ｃ−１に記録されるログレコードは、図２４Ａに示すようになる。すなわち、この場合のログレコードは、リダイレクト元１３４はなく、問合せ先１３６はサーバ１０ｃ−２であり、リダイレクト先１３８はサーバ１０ｃ−３である。

この例では、リダイレクトされたデータ要求をクライアント３０から受け取ったデータサーバ１０ｃ−３は、要求対象データを保持していないが、そのデータがサーバ１０ｃ−４にある旨の所在情報をキャッシュ２０に保持している。したがって、サーバ１０ｃ−３は、その所在情報を用いてデータ要求をサーバ１０ｃ−４にリダイレクトする（５）。この一連の動作でサーバ１０ｃ−３に記録されるログレコードは、図２４Ｂに示すようなものとなる。すなわち、この場合のログレコードは、リダイレクト元１３４はサーバ１０ｃ−１であり、問合せ先１３６はなく、リダイレクト先１３８はサーバ１０ｃ−４である。

データサーバ１０ｃ−４は、リダイレクトされたデータ要求の対象データを有しているので、そのデータをクライアント３０に提供する（６）。また、サーバ１０ｃ−４は、キャッシュ更新情報を生成してリダイレクト元のサーバ１０ｃ−３に送る（７）。

これを受けたサーバ１０ｃ−３は、そのキャッシュ更新情報を用いて所在情報キャッシュ２０のデータを更新する（ただしこの場合は、サーバ１０ｃ−３のキャッシュ２０内の所在情報は正しかったので、所在情報の内容は結果的には変わらない）。またサーバ１０ｃ−３は、ログレコード（図２４Ｂ参照）に示されたリダイレクト元のサーバ１０ｃ−１にそのキャッシュ更新情報を転送する（８）。

これを受けたサーバ１０ｃ−１は、その更新情報に基づき自身のキャッシュ２０を更新する。この場合、サーバ１０ｃ−１は当該要求対象データについての所在情報をキャッシュ２０に保持していないので、更新情報に含まれる所在情報がキャッシュ２０に追加されることになる。またサーバ１０ｃ−１は、ログレコード（図２４Ａ参照）に示された問合せ先サーバ１０ｃ−２にそのキャッシュ更新情報を転送する（９）。

これを受けたサーバ１０ｃ−２は、その更新情報に基づき自身のキャッシュ２０を更新する。この場合、キャッシュ２０には、当該要求対象データがサーバ１０ｃ−３にある旨の所在情報が存在するので、その所在情報が更新情報に含まれる所在情報に置き換えられる。

以上に説明したように、第３の変形例では、データサーバ１０ｃが自身のデータ管理部１２から要求対象データを見つけたことを以て、要求対象データの所在が確認されたとし、キャッシュ更新情報のフィードバックを開始している。しかし、これに限らず、データサーバ１０ｃが他のデータサーバへ問合せを行った際に、問合せ先から、問合せ先自身が要求対象データを持っている旨の回答を得た時点で、問合せ元がキャッシュ更新情報を生成し、リダイレクト元や他の問合せ先にフィードバックしてもよい。この場合、問合せ元からクライアント３０に返すリダイレクト情報（仮想ＵＲＬ）には、リダイレクト元の情報は含めない。リダイレクト先に要求対象データが存在することが問合せにより確認されているので、リダイレクト先からのフィードバックが不要だからである。

また、上述のように要求対象データの所在が確認されたときにキャッシュ更新情報のフィードバックを行う他に、リダイレクトされたデータ要求を受け取ったデータサーバ１０ｃが、自身のデータ管理部１２に要求対象データが無いことを確認したときに、その旨を示すキャッシュ更新情報をリダイレクト元にフィードバックしてもよい。

この場合の処理手順は図２５のようになる。図２５に示したのは、一連の処理手順のうち図２１Ａの手順に対応する部分であり、後半部分は図２１Ｂと同様でよい。また、図２１Ａの手順と同様のステップには同一符号を付して説明を省略する。

この手順では、要求対象データがデータ管理部１２に無いと判明した場合（Ｓ１０４）、クライアント３０からの要求がリダイレクトされたものかどうかを判定し（Ｓ１４２）、リダイレクトされたものであれば、要求対象データが当該データサーバ１０ｃに無いことを示すキャッシュ更新情報を生成し、これをリダイレクト元へフィードバックする（Ｓ１４５）。このときのキャッシュ更新情報は、例えば、データＩＤ、サーバＩＤ、及びデータが無い旨を示すフラグを含むデータでよい。なお、このキャッシュ更新情報を受け取ったデータサーバは、自身の所在情報キャッシュ２０に、そのキャッシュ更新情報に示されるデータＩＤとサーバＩＤの組合せと同じ所在情報があればそれを削除し、更にログレコードに示される問合せ先やリダイレクト元にそのキャッシュ更新情報を逆伝搬する。

このように第３の変形例によれば、１つのデータ要求を連携して解決した一連のデータサーバ１０ｃの所在情報キャッシュ２２の内容を最新状態へと更新できるため、誤ったリダイレクトを減らすことができる。

第３の変形例では、キャッシュ更新情報をリダイレクト元及び問合せ先の両方にフィードバックしたが、いずれか一方だけでもある程度の効果を得ることができる。

以上に説明した実施形態及び変形例は、データがサーバ間で移動した場合に限らず、同一サーバ内でデータが移動してＵＲＬが変わってしまう場合にも適用可能である。例えば、データの仮想ＵＲＬが"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 (16)

1. ネットワークを介して接続された他のデータサーバと連携してデータ管理システムを構成するデータサーバとして、コンピュータシステムを動作させるためのプログラムであって、該コンピュータシステムを、
   データが、そのデータに対して付与されたグローバルに一意なデータ識別情報と対応づけて登録されるデータ管理部、
   データ管理システムを構成する他のデータサーバを検出する検出部、
   クライアントから受け取ったデータ要求の要求対象データをデータ管理部から検索し、該当するデータが検索できた場合はそのデータをクライアントに提供し、検索できなかった場合は、該要求対象データのデータ識別情報を含むデータ問合せを検出部が検出した他のデータサーバに送ることにより、前記要求対象データを持つデータサーバを探索する要求処理部、
   他のデータサーバからデータ問合せを受けた場合、該データ問合せに含まれるデータ識別情報に対応するデータを前記データ管理部から検索し、その検索の結果に応じた応答を前記他のデータサーバに送る応答部、
   として機能させるためのプログラム。
2. 前記要求処理部は、前記データ要求の要求対象データが前記データ管理部から検索できなかった場合、前記データ問合せにより探索した前記要求対象データを持つデータサーバのサーバ識別情報を含む回答情報を前記クライアントに送信する、ことを特徴とする請求項１記載のプログラム。
3. クライアントからのデータ要求は、データサーバのサーバ識別情報と要求対象データのデータ識別情報とを含んだ仮想ＵＲＬを用いてなされ、
   前記回答情報は、前記データ問合せにより探索した前記要求対象データを持つデータサーバのサーバ識別情報と前記データ識別情報とを含んだ仮想ＵＲＬを含む、
   ことを特徴とする請求項２記載のプログラム。
4. 前記データ管理部は、登録対象として入力されたデータに前記データ識別情報が付与されていない場合は、該データにグローバルに一意なデータ識別情報を付した上で登録する、
   ことを特徴とする請求項１記載のプログラム。
5. 前記検出部は、あらかじめ当該データ管理システムにおいて取り決められている所定のメッセージを前記ネットワークに送出し、該メッセージに対して所定の応答を送ってきた装置を、前記データ管理システムを構成する他のデータサーバとして検出する、
   ことを特徴とする請求項１記載のプログラム。
6. 前記コンピュータシステムを、前記データ管理システムを構成する他のデータサーバのサーバ識別情報のリストを記憶するサーバリスト記憶部、として機能させると共に、
   前記応答部は、他のデータサーバからのデータ問合せに含まれるデータ識別情報に対応するデータを前記データ管理部から検索できなかった場合に、前記サーバリスト記憶部に記憶した前記他のデータサーバのサーバ識別情報を前記他のデータサーバに送信し、
   前記検出部は、前記サーバリスト記憶部から当該データ管理システムを構成する他のデータサーバを検出するとともに、前記要求処理部からのデータ問合せに対して他のデータサーバからサーバ識別情報を受け取った場合、そのサーバ識別情報により前記サーバリスト記憶部に記憶したリストを更新する、
   ことを特徴とする請求項１記載のプログラム。
7. 前記コンピュータシステムを、データとこのデータを保持するデータサーバのサーバ識別情報との対応関係の情報を記憶する所在情報管理部として機能させると共に、
   前記要求処理部は、クライアントからのデータ要求に含まれるデータ識別情報に対応するデータを前記データ管理部から検索できなかった場合、該データ識別情報に対応するデータサーバのサーバ識別情報を前記所在情報管理部から検索し、検索できた場合は検索したサーバ識別情報を前記データ要求の要求元のクライアントに送信する、
   ことを特徴とする請求項１記載のプログラム。
8. 前記応答部は、他のデータサーバからのデータ問合せに含まれるデータ識別情報に対応するデータを前記データ管理部から検索できなかった場合に、該データ識別情報に対応するデータサーバのサーバ識別情報を前記所在情報管理部から検索し、検索できた場合は検索したデータサーバのサーバ識別情報を前記他のデータサーバに送信し、
   前記要求処理部は、前記データ問合せを送った他のデータサーバから、その問合せに対する応答としてデータサーバのサーバ識別情報を受け取った場合には、そのデータサーバのサーバ識別情報を前記クライアントに送信する、
   ことを特徴とする請求項７記載のプログラム。
9. クライアントからのデータ要求は、データサーバのサーバ識別情報と要求対象データのデータ識別情報とを含んだ仮想ＵＲＬを用いてなされ、
   当該プログラムは、前記コンピュータシステムを、
   クライアントからのデータ要求の要求対象データが前記データ管理部から検索できなかった場合、前記データ問合せにより探索した前記要求対象データを持つデータサーバのサーバ識別情報と該要求対象データのデータ識別情報と当該コンピュータシステムのサーバ識別情報をリダイレクト元情報として含む仮想ＵＲＬを前記クライアントに送信するリダイレクト情報提供部、
   クライアントからのデータ要求の仮想ＵＲＬにリダイレクト元情報が含まれる場合、該リダイレクト元情報を該データ要求の要求対象データのデータ識別情報と対応づけて記憶するリダイレクト元記憶部、
   前記要求対象データを持つデータサーバが確認された場合に、該要求対象データのデータ識別情報に対応するリダイレクト元情報を前記リダイレクト元記憶部から求め、該リダイレクト元情報が示すデータサーバに対し、該要求対象データを持つデータサーバのサーバ識別情報を含んだ所在更新情報を送信する所在更新情報提供部、
   として機能させると共に、
   前記所在情報管理部は、他のデータサーバから受け取った所在更新情報に応じ、自身が有する前記対応関係の情報を更新する、
   ことを特徴とする請求項７記載のプログラム。
10. クライアントからのデータ要求は、データサーバのサーバ識別情報と該要求対象データのデータ識別情報とを含んだ仮想ＵＲＬを用いてなされ、
    当該プログラムは、前記コンピュータシステムを、
    クライアントからのデータ要求の要求対象データが前記データ管理部から検索できなかった場合、前記データ問合せにより探索した前記要求対象データを持つデータサーバのサーバ識別情報と該要求対象データのデータ識別情報と当該コンピュータシステムのサーバ識別情報をリダイレクト元情報として含む仮想ＵＲＬを前記クライアントに送信するリダイレクト情報提供部と、
    クライアントからのデータ要求の仮想ＵＲＬにリダイレクト元情報が含まれる場合、該リダイレクト元情報を該データ要求の要求対象データのデータ識別情報と対応づけて記憶するリダイレクト元記憶部、
    クライアントからのデータ要求の仮想ＵＲＬにリダイレクト情報が含まれており、該データ要求の要求対象データが前記データ管理部から検索できなかった場合、当該コンピュータシステムには当該要求対象データが無い旨を示す所在更新情報を作成し、該要求対象データのデータ識別情報に対応するリダイレクト元情報を前記リダイレクト元記憶部から求め、該リダイレクト元情報が示すデータサーバに対し、前記所在更新情報を送信する所在更新情報提供部、
    として機能させると共に、
    前記所在情報管理部は、他のデータサーバから受け取った所在更新情報に応じ、自身が有する前記対応関係の情報を更新する、
    ことを特徴とする請求項７記載のプログラム。
11. 前記所在情報管理部は、他のデータサーバから受け取った所在更新情報に含まれるデータ識別情報に対応するリダイレクト元情報が前記リダイレクト元記憶部にあれば、該リダイレクト元情報の示すデータサーバに対し、前記所在更新情報を転送する、
    ことを特徴とする請求項９又は１０に記載のプログラム。
12. 前記コンピュータシステムを、
    前記データ問合せの送信先のデータサーバのサーバ識別情報を、該データ問合せの対象である要求対象データのデータ識別情報に対応づけて記憶する問合せ先記憶部、
    前記要求対象データを持つデータサーバが確認された場合に、該要求対象データのデータ識別情報に対応する問合せ先のデータサーバを前記問合せ記憶部から求め、求めた問合せ先のデータサーバに対し、前記要求対象データを持つデータサーバのサーバ識別情報を含んだ所在更新情報を送信する所在更新情報提供部、
    として機能させると共に、
    前記所在情報管理部は、他のデータサーバから受け取った所在更新情報に応じ、自身が有する前記対応関係の情報を更新する、
    ことを特徴とする請求項７記載のプログラム。
13. 前記コンピュータシステムを、
    前記データ問合せの送信先のデータサーバのサーバ識別情報を、該データ問合せの対象である要求対象データのデータ識別情報に対応づけて記憶する問合せ先記憶部、
    前記データ要求のリダイレクト先のデータサーバから前記要求対象データを有していない旨の通知があった場合に、該要求対象データのデータ識別情報に対応する問合せ先のデータサーバを前記問合せ記憶部から求め、求めた問合せ先のデータサーバに対し、前記リダイレクト先のデータサーバには前記要求対象データが無い旨を示す所在更新情報を送信する所在更新情報提供部、
    として機能させると共に、
    前記所在情報管理部は、他のデータサーバから受け取った所在更新情報に応じ、自身が有する前記対応関係の情報を更新する、
    ことを特徴とする請求項７記載のプログラム。
14. ネットワークに接続された複数のデータサーバから構成されるデータ管理システムであって、
    各データサーバが、
    データが、そのデータに対して付与されたグローバルに一意なデータ識別情報と対応づけて登録されるデータ管理部と、
    データ管理システムを構成する他のデータサーバを検出する検出部と、
    クライアントから受け取ったデータ要求の要求対象データをデータ管理部から検索し、該当するデータが検索できた場合はそのデータをクライアントに提供し、検索できなかった場合は、該要求対象データのデータ識別情報を含むデータ問合せを検出部が検出した他のデータサーバに送ることにより、前記要求対象データを持つデータサーバを探索する要求処理部と、
    他のデータサーバからデータ問合せを受けた場合、該データ問合せに含まれるデータ識別情報に対応するデータを前記データ管理部から検索し、その検索の結果に応じた応答を前記他のデータサーバに送る応答部と、
    とを備えるデータ管理システム。
15. ネットワークを介して接続された他のデータサーバと連携してデータ管理システムを構成するデータサーバであって、
    データが、そのデータに対して付与されたグローバルに一意なデータ識別情報と対応づけて登録されるデータ管理部と、
    データ管理システムを構成する他のデータサーバを検出する検出部と、
    クライアントから受け取ったデータ要求の要求対象データをデータ管理部から検索し、該当するデータが検索できた場合はそのデータをクライアントに提供し、検索できなかった場合は、該要求対象データのデータ識別情報を含むデータ問合せを検出部が検出した他のデータサーバに送ることにより、前記要求対象データを持つデータサーバを探索する要求処理部と、
    他のデータサーバからデータ問合せを受けた場合、該データ問合せに含まれるデータ識別情報に対応するデータを前記データ管理部から検索し、その検索の結果に応じた応答を前記他のデータサーバに送る応答部と、
    を備えるデータサーバ。
16. ネットワークに接続された複数のデータサーバから構成されるデータ管理システムにより実行されるデータ管理方法であって、
    各データサーバが、
    データ管理部により、データを、そのデータに対して付与されたグローバルに一意なデータ識別情報と対応づけて管理し、
    検出部により、データ管理システムを構成する他のデータサーバを検出し、
    要求処理部により、クライアントから受け取ったデータ要求の要求対象データをデータ管理部から検索し、該当するデータが検索できた場合はそのデータをクライアントに提供し、検索できなかった場合は、該要求対象データのデータ識別情報を含むデータ問合せを検出部が検出した他のデータサーバに送ることにより、前記要求対象データを持つデータサーバを探索し、
    応答部により、他のデータサーバからデータ問合せを受けた場合、該データ問合せに含まれるデータ識別情報に対応するデータを前記データ管理部から検索し、その検索の結果に応じた応答を前記他のデータサーバに送る、
    ことを特徴とするデータ管理方法。

Images