JP2012093829A - 検索装置、検索方法および検索プログラム - Google Patents

Abstract

【課題】ＸＲＰＣではＸＱｕｅｒｙ内にＸＲＰＣを明示的に記述する必要がある。
【解決手段】検索装置は、第１受付部と、第１生成部と、第１送信部と、第２送信部と、第２受付部と、受信部と、実行部と、第３送信部と、を備える。第１受付部は、検索要求をクライアントから受け付ける。第１生成部は、検索要求からサーバに対して検索を要求する分散検索要求と、分散検索要求による検索結果を統合する統合要求とを生成する。第１送信部は、分散検索要求をサーバに送信する。第２送信部は、統合要求の実行結果の識別情報をクライアントに送信する。第２受付部は、識別情報で識別される実行結果の取得要求をクライアントから受け付ける。受信部は、分散検索要求に対する検索結果をサーバから受信する。実行部は、受信した検索結果に対して統合要求を実行する。第３送信部は、統合要求の実行結果を、取得要求を送信したクライアントに対して送信する。
【選択図】図４

Description

本発明の実施形態は、検索装置、検索方法および検索プログラムに関する。

ＸＱｕｅｒｙ処理を分散システムにより実現させる分散ＸＱｕｅｒｙ処理技術が開発されている。しかし、分散ＸＱｕｅｒｙ処理の試みはまだ始まったばかりであり、分散ＸＱｕｅｒｙ処理について記述した論文が散見される程度である。

分散ＸＱｕｅｒｙ処理の１つであるＸＲＰＣは、異種分散データソースに対するＸＱｕｅｒｙの言語拡張であり、ＸＱｕｅｒｙの組込み関数としてＲＰＣ（Ｒｅｍｏｔｅ Ｐｒｏｃｅｄｕｒｅ Ｃａｌｌ）機能を備えることで分散ＸＱｕｅｒｙを実現する。

Ying Zhang, et. al, "ＸＲＰＣ: Interoperable and Efficient Distributed XQuery", VLDB2007

しかしながら、分散ＸＱｕｅｒｙ処理として代表的な従来技術であるＸＲＰＣでは、例えば、ユーザがＸＱｕｅｒｙ内に特別な言語拡張であるＸＲＰＣを明示的に記述する必要があるという問題があった。

実施形態の検索装置は、第１受付部と、第１生成部と、第１送信部と、第２送信部と、第２受付部と、受信部と、実行部と、第３送信部と、を備える。第１受付部は、検索要求をクライアントから受け付ける。第１生成部は、検索要求からサーバに対して検索を要求する分散検索要求と、分散検索要求による検索結果を統合する統合要求とを生成する。第１送信部は、分散検索要求をサーバに送信する。第２送信部は、統合要求の実行結果の識別情報をクライアントに送信する。第２受付部は、識別情報で識別される実行結果の取得要求をクライアントから受け付ける。受信部は、分散検索要求に対する検索結果をサーバから受信する。実行部は、受信した検索結果に対して統合要求を実行する。第３送信部は、統合要求の実行結果を、取得要求を送信したクライアントに対して送信する。

図１は、ＸＲＰＣを用いる場合の検索装置を含むデータベースシステムの構成の一例を示すブロック図である。 図２は、本実施形態の仮想ＸＭＬデータベースシステムのネットワーク構成例を示すブロック図である。 図３は、ＨＴＴＰ上の通信手順を示す図である。 図４は、第１の実施形態の中央サーバの構成例を示すブロック図である。 図５は、第１の実施形態における検索処理の全体の流れを示すフローチャートである。 図６は、ＧＥＴメッセージを構文解析して処理を振り分ける要求処理を説明するための図である。 図７は、仮想化プランナにより実行される分散ＸＱｕｅｒｙ処理の一例を示すフローチャートである。 図８は、ＤＸＱｕｅｒｙ生成処理の一例を示すフローチャートである。 図９は、ＧＸＱｕｅｒｙ生成処理の一例を示すフローチャートである。 図１０は、ＸＱｕｅｒｙ処理の一例を示すフローチャートである。 図１１は、取得処理の一例を示すフローチャートである。 図１２は、マージ処理の一例を示すフローチャートである。 図１３は、クライアントおよび複数のサーバの相互作用の様子を時系列で表現したシーケンス図である。 図１４は、クライアントから入力されたＸＱｕｅｒｙの一例を示す図である。 図１５は、図２のＤＢに記憶されるデータの一例を示す図である。 図１６は、図１４のＸＱｕｅｒｙから生成されるＤＸＱｕｅｒｙの一例を示す図である。 図１７は、図１６のＤＸＱｕｅｒｙの実行結果である結果ＸＭＬの一例を示す図である。 図１８は、図１４のＸＱｕｅｒｙから生成されるＧＸＱｕｅｒｙの一例を示す図である。 図１９は、図１８のＧＸＱｕｅｒｙの実行結果である結果ＸＭＬの一例を示す図である。 図２０は、クライアントから入力されたＸＱｕｅｒｙの他の例を示す図である。 図２１は、図２０に対するＤＸＱｕｅｒｙ生成のイメージを示す図である。 図２２は、ＤＸＱｕｅｒｙ１の一例を示す図である。 図２３は、図２２のＤＸＱｕｅｒｙ１の実行結果である結果ＸＭＬの一例を示す図である。 図２４は、ＤＸＱｕｅｒｙ２の一例を示す図である。 図２５は、図２４のＤＸＱｕｅｒｙ２の実行結果である結果ＸＭＬの一例を示す図である。 図２６は、図２０のＸＱｕｅｒｙから生成されるＧＸＱｕｅｒｙの一例を示す図である。 図２７は、図２６のＧＸＱｕｅｒｙの実行結果である結果ＸＭＬの一例を示す図である。 図２８は、第２の実施形態の中央サーバの構成例を示すブロック図である。 図２９は、仮想化プランナおよび汎化プロセッサにより実行される分散ＸＱｕｅｒｙ処理の一例を示すフローチャートである。 図３０は、汎化処理の一例を示すフローチャートである。 図３１は、分散サーバ定義の一例を示す図である。 図３２は、図１４のＸＱｕｅｒｙと図３１の分散サーバ定義が入力されたときに汎化処理で出力されるＤＸＱｕｅｒｙ’の一例を示す図である。 図３３は、図１４のＸＱｕｅｒｙと図３１の分散サーバ定義が入力されたときに汎化処理で出力されるＶＸＱｕｅｒｙの一例を示す図である。 図３４は、第２の実施形態で処理されるＸＱｕｅｒｙ、リソース、およびＸＭＬの関係の一例を示す図である。 図３５は、第１または第２の実施形態にかかる検索装置のハードウェア構成を示す説明図である。

以下に添付図面を参照して、この発明にかかる検索装置の好適な実施形態を詳細に説明する。以下では、ＸＱｕｅｒｙ形式による検索要求によりＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）形式のデータを検索するシステムを例に説明するが適用可能なシステムはこれに限られるものではない。

（第１の実施形態）
ＸＭＬでは、文書構造を構成する個々のパーツは「要素（エレメント：Ｅｌｅｍｅｎｔ）」と呼ばれる。各要素はタグ（Ｔａｇ）を使って記述される。具体的には、要素の始まりを示すタグ（開始タグ）と、要素の終わりを示すタグ（終了タグ）との２つのタグでテキストデータを挟み込んで、１つの要素が表現される。なお、開始タグと終了タグとで挟み込まれたテキストデータは、開始タグと終了タグとで表された１つの要素に含まれるテキスト要素（テキストノード）となる。

ＸＱｕｅｒｙは、ＸＭＬデータベース（ＸＭＬ−ＤＢＭＳ）への問合せのための関数型言語であり、ＦＬＷＯＲ（ｆｏｒ−ｌｅｔ−ｗｈｅｒｅ−ｏｒｄｅｒ ｂｙ−ｒｅｔｕｒｎ）構文が特徴になっている。ＲＤＢでの問合せ言語であるＳＱＬが宣言的な言語であるのに対して、ＸＱｕｅｒｙは関数型言語としての特徴を多く持つ。以下に、ＸＱｕｅｒｙの言語仕様を手続き的な観点から説明する。

ｆｏｒ節の構文は、「ｆｏｒ 変数 ｉｎ 式」である。ｆｏｒ節の構文は、式を満足するものを変数に代入してループするという意味を持つ。ｌｅｔ節の構文は、「ｌｅｔ 変数 ：＝ 式」である。ｌｅｔ節の構文は、式を満足するものを集約してシーケンスとして変数に代入するという意味を持つ。シーケンスとは、フラットなリストである。ｗｈｅｒｅ節は、ｆｏｒ節で繰り返されるループを制限するものである。ｗｈｅｒｅ節の構文は、「ｗｈｅｒｅ 式」である。ｗｈｅｒｅ節の構文は、式を満足するものだけループをまわし、そうでないものはループをスキップするという意味を持つ。ｒｅｔｕｒｎ節は、ＸＱｕｅｒｙを処理した結果をフォーマット化するものである。ｒｅｔｕｒｎ節の構文は、「ｒｅｔｕｒｎ 式」である。ｒｅｔｕｒｎ節の構文では、変数を含む任意のＸＭＬデータを記述することができる。変数の構文は、「＄文字列」である。入れ子問合せなどで２重宣言された場合を除き、同じ文字列を持つ変数は同一のものと見なされる。ＸＭＬデータの要素間の階層条件を指定するパス演算子として、ＸＱｕｅｒｙでは以下のようなオペレータが存在する。
（１）「／」：要素間は親子関係であることを示すオペレータ
（２）「／／」：要素間は先祖子孫関係であることを示すオペレータ
（３）「．」：任意の要素

上述のように、ＸＱｕｅｒｙ処理を分散システムにより実現させる分散ＸＱｕｅｒｙ処理技術としてＸＲＰＣが知られている。

図１は、ＸＲＰＣを用いる場合の検索装置（中央サーバ１００’）を含むデータベースシステムの構成の一例を示すブロック図である。図１に示すように、データベースシステムは、中央サーバ１００’と、クライアント１０’と、データベース（ＤＢ）２１を備えたＤＢサーバ２０’と、がネットワーク３０を介して接続された構成となっている。

クライアント１０’は、ＸＱｕｅｒｙ形式で記述された問い合わせ４１を中央サーバ１００’に要求する。問い合わせ４１は、「ＡｃｔｏｒＡとＡｃｔｏｒＢに関してｘ．ｅｘａｍｐｌｅ．ｏｒｇサイトに存在するＸＱｕｅｒｙ４３の関数ｆｉｌｍｓＢｙＡｃｔｏｒを呼び出せ」という意味である。ＸＱｕｅｒｙ４３は、「ＸＭＬファイル４２から変数＄ａｃｔｏｒに合致するａｃｔｏｒＮａｍｅを持つｆｉｌｍＮａｍｅを取出せ」という意味である。

このような問い合わせ４１が受け付けられたときの処理の概要を以下に示す。
（１）「ＡｃｔｏｒＡ」について関数ｆｉｌｍｓＢｙＡｃｔｏｒを呼び出す。ＸＭＬファイル４２には、ａｃｔｏｒＮａｍｅに「ＡｃｔｏｒＡ」を含むものが２件存在するため、この２件のｆｉｌｍＮａｍｅを返す。
（２）「ＡｃｔｏｒＢ」について関数ｆｉｌｍｓＢｙＡｃｔｏｒを呼び出す。ＸＭＬファイル４２、ａｃｔｏｒＮａｍｅに「ＡｃｔｏｒＢ」を含むものが存在しないため空データを返す。
（３）得られたｆｉｌｍＮａｍｅを問い合わせ４１に記述されたＸＭＬ形式で表す。結果ＸＭＬ４４が、このときに得られるＸＭＬを表している。結果ＸＭＬ４４は、ｆｉｌｍｓ要素を、関数により返されたｆｉｌｍＮａｍｅ要素の上下に付加したものである。

ＸＲＰＣでは、以下のような課題が存在する。
（１）ＸＱｕｅｒｙ非透過：ユーザはＸＱｕｅｒｙ内に特別な言語拡張であるＸＲＰＣを明示的に記述する必要がある。
（２）同種統合：ＤＢサーバ２０’の問い合わせ処理能力としてＸＱｕｅｒｙとＸＲＰＣをサポートしなければならない。その結果、異種データに対する真の仮想化はできないことになる。
（３）性能問題：ＲＰＣ関数がＸＱｕｅｒｙのｆｏｒループ内に存在すると、ＲＰＣのメッセージ（ＳＯＡＰフォーマット）の送受信回数が増大する。また、ＲＰＣ関数は１値を返却するのでタプルの返却には適していない。また、ＲＰＣ関数として内部のＸＱｕｅｒｙが隠蔽化されるので、入れ子のＸＱｕｅｒｙを最適化するのが難しい。

そこで、第１の実施形態にかかる検索装置としての中央サーバ１００を含む仮想ＸＭＬデータベースシステムは、ＸＲＰＣを用いずに分散ＸＱｕｅｒｙ処理を実現する。

図２は、本実施形態の仮想ＸＭＬデータベースシステムのネットワーク構成例を示すブロック図である。仮想ＸＭＬデータベースシステムは、クライアント１０と、中央サーバ１００と、２台のＤＢサーバ２０ａ、２０ｂと、がネットワーク３０を介して接続されている。

ＤＢサーバ２０ａ、２０ｂは、それぞれ例えばＸＭＬ形式のデータを記憶するデータベース（ＤＢ）２１ａ、２１ｂを備えている。なお、ＤＢサーバ２０ａ、２０ｂは同様の機能を備えるため、以下では単にＤＢサーバ２０という場合がある。

クライアント１０は、ＸＱｕｅｒｙ形式で記述された問い合わせを中央サーバ１００に要求する。ネットワーク３０は、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、およびＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）などの任意のネットワーク構成とすることができる。

ネットワーク３０上の通信プロトコルとしては様々なものが存在するが、以降、インターネットプロトコル技術を利用して相互接続されたコンピュータネットワークであるＩＰネットワークを使用した例を説明する。ＩＰ以外の通信プロトコルを用いても同様の手法を適用できる。

図３は、ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）上の通信手順を示す図である。図３は、クライアント１０と中央サーバ１００との間のＨＴＴＰ通信手順を示しているが、中央サーバ１００とＤＢサーバ２０との間も同様の通信手順で通信が行われる。図３の通信手順は、ＲＥＳＴ（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ Ｓｔａｔｅ Ｔｒａｎｓｆｅｒ）を拡張したものである。

ＲＥＳＴとは、分散ハイパーメディアシステムのためのソフトウェアアーキテクチャのスタイルであり、ステートレスなクライアント／サーバプロトコルが特徴である。ＨＴＴＰメッセージは、そのリクエスト（メッセージ）を理解するために必要な全ての情報を含んでいる。このため、クライアント１０および中央サーバ１００のいずれも、メッセージ間のセッションの状態を記憶しておく必要がない。また、使用頻度の高いいくつかのメソッドが定義されている。その中で重要なメソッドは、ｇｅｔ、ｐｏｓｔ、ｐｕｔ、およびｄｅｌｅｔｅである。

また、ＲＥＳＴでは、リソースを一意に識別するＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）で表されるユニークアドレスが利用される。ＵＲＩはメソッドの引数になる。ＵＲＩは、ＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）の考え方を拡張したものである。ＵＲＩは、一定の書式によってリソースを指し示す識別子であり、１９９８年にＲＦＣ２３９６として規定され、２００５年にＲＦＣ３９８６として改定された。

例えば、「ｘｘｘｘ．ｎｅ．ｊｐ」上のリソース「ｉｎｄｅｘ．ｈｔｍｌ」のＵＲＩは、「ｈｔｔｐ：／／ｗｗｗ．ｘｘｘｘ．ｎｅ．ｊｐ／ｙｙｙｙ／ｐｕｂｌｉｃ／ｉｎｄｅｘ．ｈｔｍｌ」のように表される。

本実施形態では、メソッド「ｑｕｅｒｙ」およびメソッド「ｇｑｕｅｒｙ」を含むようにＲＥＳＴを拡張する。これらは以下の（１）および（２）に示すように、それぞれＸＱｕｅｒｙ処理および分散ＸＱｕｅｒｙ処理の実行を要求するためのメソッドである。

以下に、本実施形態で用いるメソッドの一例を示す。なお、以下では、小文字の「ｕｒｉ」および「ｕｒｉ＿＊（＊は任意の文字列）」は、ＵＲＩの書式で表された識別子であることを意味する。また、「リソースｕｒｉ」または「リソースｕｒｉ＿＊」は、識別子「ｕｒｉ」または「ｕｒｉ＿＊」で識別されるリソースを意味する。
（１）ｑｕｅｒｙメソッド
ＸＱｕｅｒｙ（図３の「ｘｑｕｅｒｙ」）を指定し（ステップＳ１０１）、指定したＸＱｕｅｒｙによるＸＱｕｅｒｙ処理の結果ＸＭＬが格納されるリソースｕｒｉを取得する（ステップＳ１０２）。
（２）ｇｑｕｅｒｙメソッド
ＸＱｕｅｒｙ（図３の「ｘｑｕｅｒｙ」）を指定し（ステップＳ１０１）、指定したＸＱｕｅｒｙによる分散ＸＱｕｅｒｙ処理の結果ＸＭＬが格納されるリソースｕｒｉを取得する（ステップＳ１０２）。
（３）ｇｅｔメソッド
ｕｒｉを指定し（ステップＳ１０３）、指定したｕｒｉのリソースに格納される結果ＸＭＬを取得する（ステップＳ１０４）。
（４）ｐｕｔメソッド
ｕｒｉとＸＭＬとを指定し（ステップＳ１０５）、指定したｕｒｉのリソースにＸＭＬを格納し、格納結果（図３の「ｓｔａｔｕｓ」）を取得する（ステップＳ１０６）。

図４は、第１の実施形態の中央サーバ１００の構成例を示すブロック図である。中央サーバ１００は、要求受付部１１０（第１受付部、第２受付部）と、仮想化プランナ１２０と、ＸＱｕｅｒｙプロセッサ１０２（実行部）と、リソース割当部１０３（割当部）と、サーバ通知検出部１０４（検出部）と、を備えている。

要求受付部１１０は、クライアント１０や他サーバ（ＤＢサーバ２０ａ、２０ｂ等）からの要求を受け付ける。例えば、要求受付部１１０は、ｑｕｅｒｙやｇｑｕｅｒｙなどのＸＱｕｅｒｙ処理要求、および、ｇｅｔやｐｕｔなどのリソース処理要求を受け付けて、必要な処理を呼び出す。要求受付部１１０は、要求に対する応答を送信する送信部１１１（第２送信部、第３送信部）を備えている。

図４の左側に図示するように、要求受付部１１０は、例えば、データの検索要求４０１をクライアント１０から受け付ける。送信部１１１は、検索要求４０１を送信したクライアント１０に対して、結果ＸＭＬが格納されるリソースのｕｒｉ４０２を返信する。また、要求受付部１１０は、ｕｒｉで指定されるリソースに格納される結果ＸＭＬの取得要求４０３をクライアント１０から受け付ける。送信部１１１は、取得要求４０３を送信したクライアント１０に対して、結果ＸＭＬ４０４を返信する。

仮想化プランナ１２０は、分散ＸＱｕｅｒｙ処理でのプランニングを行う。仮想化プランナ１２０は、生成部１２１（第１生成部）と、送信部１２２（第１送信部）と、受信部１２３とを備えている。

生成部１２１は、要求受付部１１０により分散ＸＱｕｅｒｙ処理の実行を要求する分散ｇｑｕｅｒｙが受け付けられた場合に、受け付けられた検索要求（ｇｑｕｅｒｙ）で指定されたＸＱｕｅｒｙから、ＤＢサーバ２０の集合に対してデータの検索を要求するＤＸＱｕｅｒｙ（分散検索要求）と、ＤＸＱｕｅｒｙによる検索結果を統合するＧＸＱｕｅｒｙ（統合要求）とを生成する。

送信部１２２は、ＤＸＱｕｅｒｙによる検索要求を、ＤＢサーバ２０に対して送信する。受信部１２３は、ＤＸＱｕｅｒｙに対する検索結果をＤＢサーバ２０から受信する。

ＸＱｕｅｒｙプロセッサ１０２は、ＸＱｕｅｒｙを実行する。

リソース割当部１０３は、ｕｒｉをキーにしたリソースの管理を行う。ＸＱｕｅｒｙでは、ＸＭＬデータが受け渡されるが、その受け渡しをコントロールするために、リソース割当部１０３が、各ＸＭＬデータに対してリソースｕｒｉを割り当てる。リソース割当部１０３は、リソースを格納する領域を確保する機能、確保した領域のＵＲＩを表すｕｒｉを返す機能、リソースｕｒｉに対してＸＭＬデータを代入する機能、および、ｕｒｉが示す領域に格納されたＸＭＬデータを取得する機能などを備える。

サーバ通知検出部１０４は、ブロードキャストなどを使って、サーバ間でサーバ情報（ＳＩｎｆｏ）の受け渡しを行い、ネットワーク３０に接続されたサーバを検出する。仮想化プランナ１２０は、このようにして検出されたＤＢサーバ２０に対してＤＸＱｕｅｒｙを送信する。なお、サーバ通知検出部１０４を備えず、仮想化プランナ１２０が事前に指定されたＤＢサーバ２０にアクセスするように構成してもよい。

次に、このように構成された第１の実施形態にかかる中央サーバ１００による検索処理について図５を用いて説明する。図５は、第１の実施形態における検索処理の全体の流れを示すフローチャートである。

まず、中央サーバ１００の起動によりメインスレッドが生成される（ステップＳ２０１）。以下のステップＳ２０２からステップＳ２０８は、メインスレッド内で実行される各処理を表している。

メインスレッドでは、２つのサーバ通知検出スレッド（サーバ情報通知スレッドおよびサーバ情報検出スレッド）と、要求ごとに生成される要求処理スレッドとが生成される（ステップＳ２０２、ステップＳ２０４、ステップＳ２０７）。

サーバ情報通知スレッドでは、サーバ通知検出部１０４が、ＤＢサーバ２０等のネットワーク３０に接続された他の装置に対して、例えばブロードキャストにより、定期的に中央サーバ１００のサーバ情報を送信する（ステップＳ２０３）。この処理は、サーバ情報通知スレッドが終了するまで繰り返される。

サーバ情報検出スレッドでは、サーバ通知検出部１０４が、ＤＢサーバ２０等のネットワーク３０に接続された他の装置からサーバ情報を受信して既存のサーバ情報を更新する（ステップＳ２０５）。この処理は、サーバ情報検出スレッドが終了するまで繰り返される。

要求処理スレッドは、ソケットでのａｃｃｅｐｔ処理完了後に生成される。ａｃｃｅｐｔ処理では、接続待ちの要求（リクエスト）を受付けて接続を確立し、新しいソケットが作成される。

要求受付部１１０は、作成されたソケットにより、ＸＱｕｅｒｙ処理要求（ｑｕｅｒｙ、ｇｑｕｅｒｙ）またはリソース処理要求（ｇｅｔ、ｐｕｔ）などの要求を受け付けたか否かを判断する（ステップＳ２０６）。受け付けられていない場合（ステップＳ２０６：Ｎｏ）、受け付けられるまで処理が繰り返される。

要求が受け付けられた場合（ステップＳ２０６：Ｙｅｓ）、要求受付部１１０は、要求処理スレッドを生成する（ステップＳ２０７）。要求処理スレッドでは、受け付けられた要求を処理する要求処理が実行される（ステップＳ２０８）。

要求処理では、受信したＨＴＴＰメッセージ、ここではＧＥＴメッセージが構文解析される。ＨＴＴＰメッセージとは、クライアント１０から中央サーバ１００へのリクエスト（要求）として送られ、中央サーバ１００からクライアント１０へのレスポンス（応答）として返されるメッセージである。

ＨＴＴＰメッセージの構造は、複数行の「メッセージヘッダ」と「メッセージボディ」とから成り立っており、それぞれは空行（ＣＲ＋ＬＦ）で区切られている。メッセージヘッダには、中央サーバ１００やクライアント１０が処理すべきリクエストやレスポンスの内容などが含まれている。メッセージボディには、転送されるべきデータそのものが含まれている。

ＧＥＴメソッドは、ＨＴＴＰ／０．９で定義された唯一のメソッドであり、ＨＴＴＰでは最も使用される。ＨＴＴＰ／１．１に準拠したサーバは、ＧＥＴメソッドをサポートする必要がある。

図６は、ＧＥＴメッセージを構文解析して処理を振り分ける要求処理を説明するための図である。

要求受付部１１０は、メッセージからメソッドを取出し、取出したメソッドの種類（メッセージタイプ）により条件分岐する。
（１）ｇｑｕｅｒｙメソッドの場合：
分散ＸＱｕｅｒｙ処理が要求されたので、仮想化プランナ１２０を呼び出す。
（２）ｑｕｅｒｙメソッドの場合：
ＸＱｕｅｒｙ処理を要求されたので、ＸＱｕｅｒｙプロセッサ１０２によりＸＱｕｅｒｙを実行する。
（３）ｐｏｓｔメソッドの場合：
リソース割当部１０３によりリソースを作成し、作成したリソースのｕｒｉを返す。
（４）ｇｅｔメソッドの場合：
ｕｒｉで指定されたリソースのデータを取得する。
（５）ｐｕｔメソッド
ｕｒｉで指定されたリソースへデータ代入する。
（６）ｍｅｒｇｅメソッド
データをマージし、指定されたリソースへデータ代入する。

図７は、仮想化プランナ１２０により実行される分散ＸＱｕｅｒｙ処理の一例を示すフローチャートである。分散ＸＱｕｅｒｙ処理では、入力されたＸＱｕｅｒｙから、以下の２種類のＸＱｕｅｒｙが生成される。なお、ＤＸＱｕｅｒｙは、ＤＢサーバ２０ごとに複数生成される。ＧＸＱｕｅｒｙは、通常１個生成される。
（１）ＤＸＱｕｅｒｙ：ＤＢサーバ２０に記憶されているＸＭＬデータにアクセスするためのＸＱｕｅｒｙ
（２）ＧＸＱｕｅｒｙ：ＤＸＱｕｅｒｙが出力したＸＭＬデータを統合するためのＸＱｕｅｒｙ

まず、仮想化プランナ１２０の生成部１２１が、入力されたＸＱｕｅｒｙを解析することにより複数のＤＸＱｕｅｒｙを生成するＤＸＱｕｅｒｙ生成処理を実行する（ステップＳ３０１）。ＤＸＱｕｅｒｙ生成処理の詳細は後述する。

仮想化プランナ１２０は、生成されたＤＸＱｕｅｒｙのうち１つを選択する（ステップＳ３０２）。仮想化プランナ１２０は、複数のＤＢサーバ２０のうち１つを選択する（ステップＳ３０３）。仮想化プランナ１２０の送信部１２２は、選択したＤＢサーバ２０に対して、選択したＤＸＱｕｅｒｙの実行要求を送信する（ステップＳ３０４）。実行要求が送信されたＤＢサーバ２０は、ＤＸＱｕｅｒｙの実行結果（結果ＸＭＬ）が格納されるリソースのＵＲＩ（ｕｒｉ＿ｄ）を中央サーバ１００に送信する。これにより仮想化プランナ１２０は、結果ＸＭＬが格納されるリソースのＵＲＩであるｕｒｉ＿ｄを取得する。

次に、仮想化プランナ１２０は、すべてのＤＢサーバ２０に対して実行要求を送信したか否かを判断する（ステップＳ３０５）。送信していない場合（ステップＳ３０５：Ｎｏ）、未処理のＤＢサーバ２０の１つを選択して処理を繰り返す（ステップＳ３０３）。

送信した場合（ステップＳ３０５：Ｙｅｓ）、仮想化プランナ１２０は、自サーバ（中央サーバ１００）に対して、各ＤＢサーバ２０から得られる複数のリソースｕｒｉ＿ｄそれぞれに格納されるデータをマージするためのｍｅｒｇｅメソッドを要求する（ステップＳ３０６）。中央サーバ１００の要求受付部１１０は、ｍｅｒｇｅメソッドが要求されたメッセージを受信すると、まず、マージした結果（結果ＸＭＬ）が格納されるリソースのＵＲＩ（ｕｒｉ＿ｍ）を仮想化プランナ１２０に返す。これにより、仮想化プランナ１２０は、結果ＸＭＬが格納されるリソースのＵＲＩであるｕｒｉ＿ｍを取得する。

次に、仮想化プランナ１２０は、すべてのＤＸＱｕｅｒｙを処理したか否かを判断する（ステップＳ３０７）。処理していない場合（ステップＳ３０７：Ｎｏ）、未処理のＤＸＱｕｅｒｙを１つ選択して処理を繰り返す（ステップＳ３０２）。

すべてのＤＸＱｕｅｒｙを処理した場合（ステップＳ３０７：Ｙｅｓ）、仮想化プランナ１２０の生成部１２１は、入力されたＸＱｕｅｒｙを満たす結果ＸＭＬを出力するＧＸＱｕｅｒｙを生成するＧＸＱｕｅｒｙ生成処理を実行する（ステップＳ３０８）。ＧＸＱｕｅｒｙ生成処理の詳細については後述する。

次に、仮想化プランナ１２０は、ＧＸＱｕｅｒｙのｄｏｃ（）関数を、ｕｒｉ＿ｍで書換える（ステップＳ３０９）。リソース割当部１０３は、ＧＸＱｕｅｒｙの実行結果を格納するリソースｕｒｉ＿ｇを確保する（ステップＳ３１０）。仮想化プランナ１２０は、ＧＥＴレスポンスとしてｕｒｉ＿ｇをクライアントに返す（ステップＳ３１１）。

ＸＱｕｅｒｙプロセッサ１０２は、ＧＸＱｕｅｒｙを実行する（ステップＳ３１２）。ＸＱｕｅｒｙプロセッサ１０２は、ＧＸＱｕｅｒｙの実行結果である結果ＸＭＬをリソースｕｒｉ＿ｇに代入する（ステップＳ３１３）。

後述するように、クライアント１０は、ｕｒｉ＿ｇを指定したｇｅｔメソッドを中央サーバ１００に送信する。このｇｅｔメソッドの実行要求を受け付けると、要求受付部１１０は、リソースｕｒｉ＿ｇに対する結果ＸＭＬの代入を待つための要求処理スレッドを生成する（図５のステップＳ２０７）。ステップＳ３１３で結果ＸＭＬがリソースｕｒｉ＿ｇに代入されると、この要求処理スレッドでは、結果ＸＭＬがＧＥＴレスポンスとしてクライアント１０に返信される。

次に、ステップＳ３０１のＤＸＱｕｅｒｙ生成処理の詳細について説明する。図８は、ＤＸＱｕｅｒｙ生成処理の一例を示すフローチャートである。ＤＸＱｕｅｒｙ生成処理では、ＸＱｕｅｒｙＸと同じようにＸＱｕｅｒｙをツリーと見なしてｄｏｃ（）関数からノードトラバースする処理が中心となる。なお、ＸＱｕｅｒｙＸとは、ＸＱｕｅｒｙ式をＸＭＬの構文で記述できる仕様である。

トラバースのルールは以下のようなものである。
（１）ｄｏｃ（）関数以下のパス式を辿る。
（２）同じｄｏｃ（）関数以下のパス式同士の比較式を辿る。

返り値のルールは以下のようなものである。
（１）返り値を以下の＜ｒｅｃ＞で囲まれた形式のＸＭＬ（以下、ＲＥＣフォーマットという）に変換して返す。
＜ｒｅｃ＞＜ｃｏｌ？＞．．．＜／ｃｏｌ？＞＜／ｒｅｃ＞
（２）＜ｃｏｌ？>は変数の値を区切るために用いる。

まず、生成部１２１は、入力されたＸＱｕｅｒｙを正規化する（ステップＳ４０１）。正規化では、生成部１２１は、述語節をＦＬＷＯＲ構文に展開する処理、および、ｒｅｔｕｒｎ節を変数とタグとからなるようにｌｅｔ節で括り出す処理などを実行する。

次に、生成部１２１は、入力されたＸＱｕｅｒｙに出現するｄｏｃ（）関数をマーク（検出）する（ステップＳ４０２）。以下、出現するｄｏｃ（）関数ごとにステップＳ４０３からステップＳ４１５の処理のループが繰り返される。すなわち、ｄｏｃ（）関数ごとにＤＸＱｕｅｒｙが生成される。基本的なアルゴリズムは、ｄｏｃ（）関数からパスや定数を経由して辿れる範囲をマークしながら求めることである。

生成部１２１は、マークした部分（ｄｏｃ（）関数）がＦＬＷＯＲ構文のいずれの節に含まれるかを判断して処理を振り分ける。すなわち、生成部１２１は、マークした部分がｆｏｒ節に含まれるか否かを判断する（ステップＳ４０３）。ｆｏｒ節に含まれる場合（ステップＳ４０３：Ｙｅｓ）、生成部１２１は、マークされた変数、定数、関数、およびパスから構成される部分を新たにマークする（ステップＳ４０４）。すなわち、生成部１２１は、マークしたｄｏｃ（）関数を起点としてパスを辿り、辿った部分を新たにマークする。生成部１２１は、マーク部分をＤＸＱｕｅｒｙのｆｏｒ節として出力する（ステップＳ４０５）。

ｆｏｒ節に含まれない場合（ステップＳ４０３：Ｎｏ）、生成部１２１は、マークした部分がｌｅｔ節に含まれるか否かを判断する（ステップＳ４０６）。ｌｅｔ節に含まれる場合（ステップＳ４０６：Ｙｅｓ）、生成部１２１は、マークされた変数、定数、関数、およびパスから構成される部分を新たにマークする（ステップＳ４０７）。すなわち、生成部１２１は、マークしたｄｏｃ（）関数を起点としてパスを辿り、辿った部分を新たにマークする。生成部１２１は、マーク部分をＤＸＱｕｅｒｙのｌｅｔ節として出力する（ステップＳ４０８）。

ｌｅｔ節に含まれない場合（ステップＳ４０６：Ｎｏ）、生成部１２１は、マークした部分がｏｒｄｅｒ ｂｙ節に含まれるか否かを判断する（ステップＳ４０９）。ｏｒｄｅｒ ｂｙ節に含まれる場合（ステップＳ４０９：Ｙｅｓ）、ステップＳ４１５に遷移する。

ｏｒｄｅｒ ｂｙ節に含まれない場合（ステップＳ４０９：Ｎｏ）、生成部１２１は、マークした部分がｗｈｅｒｅ節に含まれるか否かを判断する（ステップＳ４１０）。ｗｈｅｒｅ節に含まれる場合（ステップＳ４１０：Ｙｅｓ）、生成部１２１は、マークされた変数、定数、関数、およびパスから構成される部分を新たにマークする（ステップＳ４１１）。生成部１２１は、マーク部分をＤＸＱｕｅｒｙのｗｈｅｒｅ節として出力する（ステップＳ４１２）。

ｗｈｅｒｅ節に含まれない場合（ステップＳ４１０：Ｎｏ）、生成部１２１は、マークした部分がｒｅｔｕｒｎ節に含まれるか否かを判断する（ステップＳ４１３）。ｒｅｔｕｒｎ節に含まれる場合（ステップＳ４１３：Ｙｅｓ）、生成部１２１は、「ｒｅｔｕｒｎ ＜ｒｅｃ＞｛Ｘ｝＜／ｒｅｃ＞」の形式でＤＸＱｕｅｒｙのｒｅｔｕｒｎ節を出力する（ステップＳ４１４）。Ｘの部分には、以下の（１）および（２）の形式の節を出力する。
（１）：
＜ｃｏｌ０＞
｛＄変数｝
＜／ｃｏｌ０＞
（２）：
ｆｏｒ ＄ダミー変数 ｉｎ ＄変数
ｒｅｔｕｒｎ
＜ｃｏｌ１＞
｛＄ダミー変数｝
＜／ｃｏｌ１＞

ステップＳ４１３でｒｅｔｕｒｎ節に含まれないと判断された場合（ステップＳ４１３：Ｎｏ）、ステップＳ４１５に遷移する。ステップＳ４１５では、生成部１２１は、マーク部分から辿れる節、すなわち、マーク部分に含まれる変数、定数、関数、パス等を含む他の節が存在するか否かを判断する（ステップＳ４１５）。存在する場合（ステップＳ４１５：Ｙｅｓ）、その節に対してステップＳ４０３以降の処理を繰り返す。存在しない場合（ステップＳ４１５：Ｎｏ）、ステップＳ４１６に遷移する。

ステップＳ４１６では、生成部１２１は、入力されたＸＱｕｅｒｙに出現するすべてのｄｏｃ（）関数を処理したか否かを判断する（ステップＳ４１６）。処理していない場合（ステップＳ４１６：Ｎｏ）、次に出現するｄｏｃ（）関数をマークして処理を繰り返す（ステップＳ４０２）。処理した場合（ステップＳ４１６：Ｙｅｓ）、ＤＸＱｕｅｒｙ生成処理を終了する。

次に、ステップＳ３０８のＧＸＱｕｅｒｙ生成処理の詳細について説明する。図９は、ＧＸＱｕｅｒｙ生成処理の一例を示すフローチャートである。ＧＸＱｕｅｒｙ生成処理では、ＤＸＱｕｅｒｙ生成処理でマークされたＸＱｕｅｒｙを使って処理する。ＧＸＱｕｅｒｙ生成処理では、主にマークされた部分について、先に生成したＤＸＱｕｅｒｙから該当するデータを取出すｆｏｒ節またはｌｅｔ節を計算し、その節で置換することである。

まず、生成部１２１は、入力されたＸＱｕｅｒｙでマークされた部分（マーク部分）を取得する（ステップＳ５０１）。生成部１２１は、マークされた部分がｆｏｒ節を含むか否かを判断する（ステップＳ５０２）。ｆｏｒ節を含む場合（ステップＳ５０２：Ｙｅｓ）、生成部１２１は、マークされた部分を、ＤＸＱｕｅｒｙから該当するデータを取出すｆｏｒ節に置換して出力する（ステップＳ５０３）。生成部１２１は、例えば以下の（１）に示す形式のｆｏｒ節を出力する。
（１）：
ｆｏｒ ＄ダミー変数 ｉｎ
ｄｏｃ（［ｕｒｉ］）／ｒｏｏｔ／ｒｅｃ
ｆｏｒ ＄変数 ｉｎ
＄ダミー変数／ｃｏｌ／＊

ｆｏｒ節を含まない場合（ステップＳ５０２：Ｎｏ）、生成部１２１は、マークされた部分がｌｅｔ節を含むか否かを判断する（ステップＳ５０４）。ｌｅｔ節を含む場合（ステップＳ５０４：Ｙｅｓ）、生成部１２１は、マークされた部分を、ＤＸＱｕｅｒｙから該当するデータを取出すｌｅｔ節に置換して出力する（ステップＳ５０５）。生成部１２１は、例えば以下の（２）に示す形式のｌｅｔ節を出力する。
（２）：
ｌｅｔ ＄変数 ：＝
ｆｏｒ ＄ダミー変数１ ｉｎ
ｄｏｃ（［ｕｒｉ］）／ｒｏｏｔ／ｒｅｃ
ｆｏｒ ＄ダミー変数２ ｉｎ
＄ダミー変数１／ｃｏｌ／＊
ｒｅｔｕｒｎ ＄ダミー変数２

ｌｅｔ節を含まない場合（ステップＳ５０４：Ｎｏ）、生成部１２１は、マークされた部分がｏｒｄｅｒ ｂｙ節を含むか否かを判断する（ステップＳ５０６）。ｏｒｄｅｒ ｂｙ節を含む場合（ステップＳ５０６：Ｙｅｓ）、生成部１２１は、ｏｒｄｅｒ ｂｙ節をそのまま出力する（ステップＳ５０７）。

ｏｒｄｅｒ ｂｙ節を含まない場合（ステップＳ５０６：Ｎｏ）、生成部１２１は、マークされた部分がｗｈｅｒｅ節を含むか否かを判断する（ステップＳ５０８）。ｗｈｅｒｅ節を含む場合（ステップＳ５０８：Ｙｅｓ）、生成部１２１は、マークされた部分を、ＤＸＱｕｅｒｙから該当するデータを取出すｌｅｔ節に置換して出力する（ステップＳ５０９）。生成部１２１は、例えば以下の（３）に示す形式のｌｅｔ節を出力する。
（３）：
ｌｅｔ ＄ダミー変数：＝ｉｎ
＄変数／ｃｏｌ／＊
ｗｈｅｒｅ ダミー変数 比較式

ｗｈｅｒｅ節を含まない場合（ステップＳ５０８：Ｎｏ）、生成部１２１は、マークされた部分がｒｅｔｕｒｎ節を含むか否かを判断する（ステップＳ５１０）。ｒｅｔｕｒｎ節を含む場合（ステップＳ５１０：Ｙｅｓ）、生成部１２１は、ｒｅｔｕｒｎ節をそのまま出力する（ステップＳ５１１）。

ステップＳ５０３、ステップＳ５０５、ステップＳ５０７、ステップＳ５０９、およびステップＳ５１１の実行後、または、ステップＳ５１０でｒｅｔｕｒｎ節を含まないと判断された場合（ステップＳ５１０：Ｎｏ）、生成部１２１は、すべてのマーク部分を処理したか否かを判断する（ステップＳ５１２）。処理していない場合（ステップＳ５１２：Ｎｏ）、未処理のマーク部分を取得して処理を繰り返す（ステップＳ５０１）。処理した場合（ステップＳ５１２：Ｙｅｓ）、ＧＸＱｕｅｒｙ生成処理を終了する。

次に、仮想化プランナ１２０のＤＸＱｕｅｒｙの実行要求に応じてＤＢサーバ２０が実行するＸＱｕｅｒｙ処理について説明する。なお、クライアント１０から分散ＸＱｕｅｒｙ処理（ｇｑｕｅｒｙ）ではなく、ＸＱｕｅｒｙ処理（ｑｕｅｒｙ）を要求された場合にＸＱｕｅｒｙプロセッサ１０２により実行されるＸＱｕｅｒｙ処理も同様の手順で実行される。図１０は、ＸＱｕｅｒｙ処理の一例を示すフローチャートである。

ＤＢサーバ２０は、要求されたＤＸＱｕｅｒｙに対するリソースｕｒｉ＿ｄを確保する（ステップＳ６０１）。ＤＢサーバ２０は、ＧＥＴレスポンスとしてｕｒｉ＿ｄを中央サーバ１００に返す（ステップＳ６０２）。ＤＢサーバ２０は、ＤＸＱｕｅｒｙをＸＱｕｅｒｙプロセッサで実行する（ステップＳ６０３）。ＤＢサーバ２０は、ＤＸＱｕｅｒｙの実行結果である結果ＸＭＬをリソースｕｒｉ＿ｄに代入する（ステップＳ６０４）。ＸＱｕｅｒｙプロセッサ１０２がＸＱｕｅｒｙ処理を実行する場合は、リソースｕｒｉ＿ｄに対する結果ＸＭＬの代入を待つための要求処理スレッドが生成される。

次に、ｇｅｔメソッドによりリソースのデータを取得する取得処理について説明する。図１１は、取得処理の一例を示すフローチャートである。

要求受付部１１０は、ｇｅｔメソッドで指定されたリソースｕｒｉに対するデータを取得する（ステップＳ７０１）。取得できない場合は、データの代入を待つための要求処理スレッドを生成し、代入のイベント待ち状態に入る。データがリソースｕｒｉに代入されると、要求受付部１１０は、データをＧＥＴレスポンスとしてｇｅｔメソッドの要求元に返信する（ステップＳ７０２）。

次に、ｍｅｒｇｅメソッドによりリソースのデータをマージするマージ処理について説明する。図１２は、マージ処理の一例を示すフローチャートである。

要求受付部１１０は、マージ処理の結果を格納するリソースｕｒｉ＿ｍを確保する（ステップＳ８０１）。要求受付部１１０は、確保したリソースのＵＲＩであるｕｒｉ＿ｍをＧＥＴレスポンスとして要求元に返信する（ステップＳ８０２）。要求受付部１１０は、ｍｅｒｇｅメソッドでマージが要求されたリソース集合に含まれる各リソースのマージ処理を行う（ステップＳ８０３）。

なお、図１２の「Ｕ ｕｒｉ＿ｄ」は、マージが要求されたリソースｕｒｉ＿ｄの集合を意味する。また、マージとは、各リソースのデータを直列に連結することを意味する。

要求受付部１１０は、マージの結果得られたＸＭＬデータである結果ＸＭＬを、ｕｒｉ＿ｍに代入する（ステップＳ８０４）。なお、他のスレッド等によるｕｒｉ＿ｍに対する結果ＸＭＬの代入待ちの場合は、結果ＸＭＬの代入を待つための要求処理スレッドが生成される。

図１３は、クライアント１０および複数のサーバ（中央サーバ１００、ＤＢサーバ２０ａ、ＤＢサーバ２０ｂ）の相互作用の様子を時系列で表現したシーケンス図である。図１３では、左から右に時間が進むと仮定する。

まず、クライアント１０が、中央サーバ１００に対してｇｑｕｅｒｙメソッドで分散ＸＱｕｅｒｙ処理を要求する（ステップＳ９０１）。

中央サーバ１００は、ＤＢサーバ２０ａに対してｑｕｅｒｙメソッドでＸＱｕｅｒｙ処理を要求する（ステップＳ９０２）。このときのｑｕｅｒｙメソッドは、生成部１２１により生成したＤＸＱｕｅｒｙを引数に持つ。中央サーバ１００は、ｑｕｅｒｙメソッドの結果ＸＭＬのリソースのＵＲＩを示すｕｒｉ＿ｄ１をＤＢサーバ２０ａから取得する（ステップＳ９０３）。

中央サーバ１００は、ＤＢサーバ２０ｂに対してｑｕｅｒｙメソッドでＸＱｕｅｒｙ処理を要求する（ステップＳ９０４）。このときのｑｕｅｒｙメソッドは、生成部１２１により生成したＤＸＱｕｅｒｙを引数に持つ。中央サーバ１００は、ｑｕｅｒｙメソッドの結果ＸＭＬのリソースのＵＲＩを示すｕｒｉ＿ｄ２をＤＢサーバ２０ｂから取得する（ステップＳ９０５）。

中央サーバ１００は、自サーバ（中央サーバ１００）に対してリソースｕｒｉ＿ｄ１とリソースｕｒｉ＿ｄ２とのマージをｍｅｒｇｅメソッドで要求する（ステップＳ９０６）。中央サーバ１００は、自サーバ（中央サーバ１００）から、ｍｅｒｇｅメソッドの結果ＸＭＬのリソースのＵＲＩを示すｕｒｉ＿ｍを取得する（ステップＳ９０７）。

中央サーバ１００は、ＤＢサーバ２０ａに対してｕｒｉ＿ｄ１の結果ＸＭＬの取得をｇｅｔメソッドで要求する（ステップＳ９０８）。中央サーバ１００は、ＤＢサーバ２０ｂに対してｕｒｉ＿ｄ２の結果ＸＭＬの取得をｇｅｔメソッドで要求する（ステップＳ９０９）。

中央サーバ１００は、ｇｑｕｅｒｙメソッドに対するＧＥＴレスポンスとしてｕｒｉ＿ｇをクライアント１０に返す（ステップＳ９１０）。

クライアント１０は、中央サーバ１００に対して、ｕｒｉ＿ｇの結果ＸＭＬの取得をｇｅｔメソッドで要求する（ステップＳ９１１）。

中央サーバ１００は、自サーバ（中央サーバ１００）に対して、ステップＳ９０７で取得したｕｒｉ＿ｍの結果ＸＭＬの取得をｇｅｔメソッドで要求する（ステップＳ９１２）。

一方、中央サーバ１００からＤＢサーバ２０ａに要求していたｑｕｅｒｙメソッドの実行結果を表す結果ＸＭＬが生成された場合、ＤＢサーバ２０ａは、リソースｕｒｉ＿ｄ１に結果ＸＭＬであるｘｍｌ＿ｄ１を代入する（ステップＳ９１３）。

同様に、中央サーバ１００からＤＢサーバ２０ｂに要求していたｑｕｅｒｙメソッドの実行結果を表す結果ＸＭＬが生成された場合、ＤＢサーバ２０ｂは、リソースｕｒｉ＿ｄ２に結果ＸＭＬであるｘｍｌ＿ｄ２を代入する（ステップＳ９１４）。

自サーバ（中央サーバ１００）に対して、ｍｅｒｇｅメソッドで要求したｕｒｉ＿ｄ１とｕｒｉ＿ｄ２とのマージ結果である結果ＸＭＬが生成された場合は、中央サーバ１００は、リソースｕｒｉ＿ｍに結果ＸＭＬであるｘｍｌ＿ｍを代入する（ステップＳ９１５）。

クライアント１０から中央サーバ１００に対してｇｅｔメソッドで要求されていたｕｒｉ＿ｇの結果ＸＭＬが生成された場合、中央サーバ１００は、ｕｒｉ＿ｇに結果ＸＭＬを代入する（ステップＳ９１６）。

なお、図１３に示すように、ＤＢサーバ２０は、要求されたｑｕｅｒｙメソッドに対して、実行結果が得られる前に実行結果を格納するリソースを通知するレスポンスを返信する（ステップＳ９０３、ステップＳ９０５等）。すなわち、ＤＢサーバ２０は、ｑｕｅｒｙメソッドに対して、ＸＱｕｅｒｙ処理の実行結果が得られてから実行結果を通知するレスポンスを返信するのではなく、実行結果が得られる前に実行結果を格納するリソースを通知するレスポンスを返信する機能を備える必要がある。ＤＢサーバ２０がこの機能を備えない場合は、中央サーバ１００内に、この機能を代替する機能を備えるように構成してもよい。

図１３の右側には、上記シーケンスで処理されるＸＱｕｅｒｙ、リソース、およびＸＭＬの関係が示されている。すなわち、ＤＢサーバ２０ａおよび２０ｂでそれぞれＤＸＱｕｅｒｙが実行され、実行結果がリソースｕｒｉ＿ｄ１およびリソースｕｒｉ＿ｄ２に格納される。そして、リソースｕｒｉ＿ｄ１およびリソースｕｒｉ＿ｄ２がマージされたリソースｕｒｉ＿ｍを埋め込んだＧＸＱｕｅｒｙの実行結果を格納するリソースｕｒｉ＿ｇがクライアント１０に送信される。ＧＸＱｕｅｒｙの実行結果である結果ＸＭＬが得られると、その結果ＸＭＬがクライアント１０に送信される。

次に、検索処理の具体例について説明する。図１４は、クライアントから入力されたＸＱｕｅｒｙの一例を示す図である。図１４のＸＱｕｅｒｙは、「ｃｏｌｕｍｎ３に“神奈川”を含むｒｏｗを全て取出せ」という意味である。

図１５は、図２のＤＢ２１ａに記憶されるデータの一例を示す図である。図１５に示すように、ＤＢ２１ａは、事業所名（ｃｏｌｕｍｎ１）、住所（ｃｏｌｕｍｎ２）、都道府県（ｃｏｌｕｍｎ３）を記憶する事業所のデータベースの例を示している。図１５では、４つのｒｏｗ（事業所）のデータが例示されている。

図１６は、図１４のＸＱｕｅｒｙから生成されるＤＸＱｕｅｒｙの一例を示す図である。基本構造は図１４と同様である。図１６のＤＸＱｕｅｒｙは、「ｃｏｌｕｍｎ３に“神奈川”を含むｒｏｗをＲＥＣフォーマットで全て取出せ」という意味を表している。

図１７は、図１６のＤＸＱｕｅｒｙの実行結果である結果ＸＭＬの一例を示す図である。図１７は、図１５に示すＤＢ２１ａからＤＸＱｕｅｒｙにより検索された結果ＸＭＬ（ｘｍｌ＿ｄ１）の例を示している。

図１８は、図１４のＸＱｕｅｒｙから生成されるＧＸＱｕｅｒｙの一例を示す図である。図１８のＧＸＱｕｅｒｙは、以下の２つの部分から構成されている。
（１）ＤＸＱｕｅｒｙの結果ＸＭＬを読み込んで各ｒｅｃを取出す部分
（２）ｒｅｃのｃｏｌ？の値を取出す部分

図１６および図１８に示すように、ＧＸＱｕｅｒｙ＋ＤＸＱｕｅｒｙ＝入力されたＸＱｕｅｒｙとなっている。

ここで、図１４のＸＱｕｅｒｙから図１６のＤＸＱｕｅｒｙおよび図１８のＧＸＱｕｅｒｙを生成する処理についてさらに説明する。

まず、図１４のＸＱｕｅｒｙからｄｏｃ（）関数「ｄｏｃ（“ｄａｔａｂａｓｅ．ＸＭＬ”）が取出される（図８のステップＳ４０２）。

ｆｏｒ節については、ｄｏｃ（）関数から「／／ｒｏｗ」を辿り、この節の本体がマークされたので「＄ｘ」までマークされる。

ｗｈｅｒｅ節については、「＄ｘ」が既にマークされている。「＄ｘ／／ｃｏｌｕｍｎ３」もマークされる。“神奈川”は定数である。そこでｗｈｅｒｅ節の全部がマークされる。その結果、図１６に示すような１個のＤＸＱｕｅｒｙが生成される。

次に、ＧＸＱｕｅｒｙを生成する。ＤＸＱｕｅｒｙでｆｏｒ節とｗｈｅｒｅ節とがマークされているので、ＤＸＱｕｅｒｙから該当するデータを取出すｆｏｒ節は図１８に示すようになる。

図１９は、図１８のＧＸＱｕｅｒｙの実行結果である結果ＸＭＬの一例を示す図である。図１９に示すように、ＧＸＱｕｅｒｙの実行結果である結果ＸＭＬは、リソースｘｍｌ＿ｇに格納される。

次に、図１４より複雑なＸＱｕｅｒｙを例にさらに説明する。図２０は、クライアントから入力されたＸＱｕｅｒｙの他の例を示す図である。図２０のＸＱｕｅｒｙは、「ｒｏｗのｃｏｌｕｍｎ３ごとにｒｏｗを集計せよ」という意味である。例えば図１５のようなデータに対しては、「都道府県別に事業所を集計せよ」を意味する。

ここで、いくつかの組み込み関数について説明する。
（１）ｄｉｓｔｉｎｃｔ−ｖａｌｕｅｓ：入力されたシーケンスから値として異なる要素シーケンスを取出す。
（２）ｃｏｕｎｔ：入力されたシーケンスの要素数を返す。

図２１は、図２０に対するＤＸＱｕｅｒｙ生成のイメージを示す図である。
（１）ｄｏｃ（）関数以下のパス式を辿る。
（２）同じｄｏｃ（）関数以下のパス式同士の比較式を辿る。
というトラバースのルールにより、２つのＤＸＱｕｅｒｙ（ＤＸＱｕｅｒｙ１、ＤＸＱｕｅｒｙ２）が生成されることになる。

図２２は、ＤＸＱｕｅｒｙ１の一例を示す図である。図２３は、図２２のＤＸＱｕｅｒｙ１の実行結果である結果ＸＭＬの一例を示す図である。図２４は、ＤＸＱｕｅｒｙ２の一例を示す図である。図２５は、図２４のＤＸＱｕｅｒｙ２の実行結果である結果ＸＭＬの一例を示す図である。図２６は、図２０のＸＱｕｅｒｙから生成されるＧＸＱｕｅｒｙの一例を示す図である。

図２２、図２４および図２６に示すように、ＧＸＱｕｅｒｙ＋ＤＸＱｕｅｒｙ（ＤＸＱｕｅｒｙ１、ＤＸＱｕｅｒｙ２）＝入力されたＸＱｕｅｒｙとなっている。図２７は、図２６のＧＸＱｕｅｒｙの実行結果である結果ＸＭＬの一例を示す図である。図２７に示すように、「都道府県別に事業所を集計」した結果が結果ＸＭＬとして得られている。

このように、第１の実施形態にかかる検索装置では、ＸＲＰＣを用いずに分散ＸＱｕｅｒｙ処理を実現することができる。したがって、以下のような効果が得られる。
（１）ＸＱｕｅｒｙ透過：ユーザはＸＱｕｅｒｙ内に特別な言語拡張を明示的に記述する必要がない。
（２）異種統合：通常のネットワークや通信プロトコル上で、ＲＤＢＭＳやＷｅｂサービスなど異種データベースも接続して仮想ＸＭＬデータベースを構成できる。わずかな定義で地図情報サービスや天気情報サービスなどＸＱｕｅｒｙをサポートしていない非ＸＭＬ−ＤＢＭＳのＷｅｂサービスも仮想ＸＭＬデータベースの構成要素になりえる。
（３）高速性：ＸＱｕｅｒｙにｆｏｒループが含まれていても、そのループ回数だけネットワーク上をメッセージが流れることはない。ＲＰＣのように関数実行が逐次化されず複数サーバで並列処理できる。通常の分散データベースで結合演算を行うとき通信負荷を最も小さくする手法としてセミジョイン法が容易に適用できる。

（第２の実施形態）
第２の実施形態にかかる検索装置は、ＤＢサーバの検索能力（問い合わせ処理能力）を満たすようにＤＸＱｕｅｒｙを変換（汎化）し、変換したＤＸＱｕｅｒｙによる検索結果から、変換前のＤＸＱｕｅｒｙによる検索結果を生成する。これにより、ＤＢサーバの問い合わせ処理能力に応じた高精度な検索を実現できる。

図２８は、第２の実施形態の中央サーバ２００の構成例を示すブロック図である。中央サーバ２００は、要求受付部１１０と、仮想化プランナ２２０と、ＸＱｕｅｒｙプロセッサ１０２と、リソース割当部１０３と、サーバ通知検出部１０４と、汎化プロセッサ２３０と、を備えている。

第２の実施形態では、仮想化プランナ２２０の機能、および、汎化プロセッサ２３０を追加したことが第１の実施形態と異なっている。その他の構成および機能は、第１の実施形態にかかる中央サーバ１００のブロック図である図４と同様であるので、同一符号を付し、ここでの説明は省略する。

仮想化プランナ２２０は、生成したＤＸＱｕｅｒｙの汎化を汎化プロセッサ２３０に要求し、汎化されたＤＸＱｕｅｒｙ（以下、ＤＸＱｕｅｒｙ’という）を送信部２２２によりＤＢサーバ２０に送信する点が、第１の実施形態の仮想化プランナ１２０と異なっている。

汎化プロセッサ２３０は、変換部２３１と、生成部２３２（第２生成部）とを備えている。変換部２３１は、仮想化プランナ２２０の生成部１２１が生成したＤＸＱｕｅｒｙを、ＤＢサーバ２０の問い合わせ処理能力に合わせて汎化したＤＸＱｕｅｒｙ’に変換する。生成部２３２は、ＤＸＱｕｅｒｙ’による検索結果を検証するＸＱｕｅｒｙであるＶＸＱｕｅｒｙ（生成要求）を生成する。ＶＸＱｕｅｒｙは、ＤＸＱｕｅｒｙ’による検索結果で発生した、ＤＢサーバ２０の問い合わせ処理能力の不足部分を検証し、不足部分を補って変換前のＤＸＱｕｅｒｙを用いた場合の検索結果となるような検索結果を生成するＸＱｕｅｒｙである。

図２９は、仮想化プランナ２２０および汎化プロセッサ２３０により実行される分散ＸＱｕｅｒｙ処理の一例を示すフローチャートである。本実施形態の分散ＸＱｕｅｒｙ処理では、ＤＸＱｕｅｒｙを汎化したＤＸＱｕｅｒｙ’、ＶＸＱｕｅｒｙ、および、ＶＸＱｕｅｒｙの結果を統合するＧＸＱｕｅｒｙが生成される。

ステップＳ１００１からステップＳ１００３までは、第１の実施形態にかかる中央サーバ１００におけるステップＳ３０１からステップＳ３０３までと同様の処理なので、その説明を省略する。

ステップＳ１００４では、ＤＸＱｕｅｒｙからＤＸＱｕｅｒｙ’およびＶＸＱｕｅｒｙを生成する汎化処理が実行される。汎化処理の詳細については後述する。

次に、仮想化プランナ２２０の送信部２２２は、選択したＤＢサーバ２０に対して、汎化されたＤＸＱｕｅｒｙ’の実行要求を送信する（ステップＳ１００５）。実行要求が送信されたＤＢサーバ２０は、ＤＸＱｕｅｒｙ’の実行結果（結果ＸＭＬ）が格納されるリソースのＵＲＩ（ｕｒｉ＿ｄ）を中央サーバ２００に送信する。これにより仮想化プランナ２２０は、結果ＸＭＬが格納されるリソースのＵＲＩであるｕｒｉ＿ｄを取得する。

次に、仮想化プランナ２２０は、ＶＸＱｕｅｒｙのｄｏｃ（）関数を取得したｕｒｉ＿ｄで書換える（ステップＳ１００６）。仮想化プランナ２２０は、自サーバ（中央サーバ２００）に対して、ｑｕｅｒｙメソッドを指定して、ＶＸＱｕｅｒｙの実行を要求し（ステップＳ１００７）、ＶＸＱｕｅｒｙの結果ＸＭＬが格納されるｕｒｉ＿ｖを取得する。

ステップＳ１００８は図７のステップＳ３０５と同様であるため説明を省略する。ステップＳ１００９は、リソースｕｒｉ＿ｄの代わりにリソースｕｒｉ＿ｖを用いる点が図７のステップＳ３０６と異なる。すなわち、仮想化プランナ２２０は、自サーバ（中央サーバ２００）に対して、複数のリソースｕｒｉ＿ｖそれぞれに格納されるデータをマージするためのｍｅｒｇｅメソッドを要求する（ステップＳ１００９）。

ステップＳ１０１０からステップＳ１０１６までは、第１の実施形態にかかる中央サーバ１００におけるステップＳ３０７からステップＳ３１３までと同様の処理なので、その説明を省略する。

次に、ステップＳ１００４の汎化処理について説明する。図３０は、汎化処理の一例を示すフローチャートである。

まず、汎化プロセッサ２３０は、各ＤＢサーバ２０から分散サーバ定義を取得する（ステップＳ１１０１）。分散サーバ定義とは、ＤＢサーバの問い合わせ処理能力を表す情報である。図３１は、分散サーバ定義の一例を示す図である。「ＳＥＲＶＩＣＥ ｈｔｔｐ：／／ｅｘａｍｐｌｅ．ｃｏｍ／？ｋｅｙ＝％１」は、「ｋｅｙ」へのパラメータを処理できることを意味する。「ＸＱｕｅｒｙ ｆｏｒ ＄ｘ ｉｎ 〜」は、「ｋｅｙ」へのパラメータは「ｃｏｎｔａｉｎｓ（＄ｘ，“％１”）に置き換えられることを意味する。

図３０に戻り、汎化プロセッサ２３０は、選択されたＤＸＱｕｅｒｙと分散サーバ定義のＸＱｕｅｒｙパターンとを照合する（ステップＳ１１０２）。照合できない場合（ステップＳ１１０３：Ｎｏ）、変換部２３１がＤＸＱｕｅｒｙを汎化し（ステップＳ１１０４）、ステップＳ１１０２に戻って処理を繰り返す。

ＤＸＱｕｅｒｙの汎化では、変換部２３１は、例えば（１）パスの省略、（２）ＯＲ条件の展開、（３）タグ名を「＊」に変換（ＸＭＬデータに含まれる要素の名称の変換）などの処理を行う。

ＤＸＱｕｅｒｙと分散サーバ定義のＸＱｕｅｒｙパターンとが照合された場合（ステップＳ１１０３：Ｙｅｓ）、変換部２３１は、汎化されたＤＸＱｕｅｒｙ（汎化していない場合は選択されたＤＸＱｕｅｒｙ）をＤＸＱｕｅｒｙ’として出力する（ステップＳ１１０５）。次に、生成部２３２が、元のＤＸＱｕｅｒｙからＶＸＱｕｅｒｙを生成し（ステップＳ１１０６）、汎化処理を終了する。

図３２は、図１４のＸＱｕｅｒｙと図３１の分散サーバ定義が入力されたときに汎化処理で出力されるＤＸＱｕｅｒｙ’の一例を示す図である。図１６のＤＸＱｕｅｒｙと比較すると、図３２のＤＸＱｕｅｒｙ’は、「ｒｏｗ」というタグ名、および、「＄ｘ／／ｃｏｌｕｍｎ３」といったパスが省略されている。このように、ＤＸＱｕｅｒｙに対して汎化操作を繰り返すことで、ＤＢサーバ２０の問い合わせ処理能力に照合したＤＸＱｕｅｒｙ’が生成されている。

図３３は、図１４のＸＱｕｅｒｙと図３１の分散サーバ定義が入力されたときに汎化処理で出力されるＶＸＱｕｅｒｙの一例を示す図である。

図３４は、第２の実施形態で処理されるＸＱｕｅｒｙ、リソース、およびＸＭＬの関係の一例を示す図である。図３４では、ＤＢサーバ２０ｂに送信するＤＸＱｕｅｒｙに対してのみ汎化処理が実行された例が示されている。ＤＢサーバ２０ａおよび２０ｂでそれぞれＤＸＱｕｅｒｙおよびＤＸＱｕｅｒｙ’が実行され、実行結果がリソースｕｒｉ＿ｄ１およびリソースｕｒｉ＿ｄ２に格納される。リソースｕｒｉ＿ｄ２に対してはＶＸＱｕｅｒｙが実行され、実行結果であるｕｒｉ＿ｖ２が出力される。リソースｕｒｉ＿ｄ１およびリソースｕｒｉ＿ｖ２がマージされたリソースｕｒｉ＿ｍを埋め込んだＧＸＱｕｅｒｙの実行結果を格納するリソースｕｒｉ＿ｇがクライアント１０に送信される。ＧＸＱｕｅｒｙの実行結果である結果ＸＭＬが得られると、その結果ＸＭＬがクライアント１０に送信される。

ここで、図１４のＸＱｕｅｒｙと図３１の分散サーバ定義から図３２のＤＸＱｕｅｒｙ’が生成する過程についてさらに説明する。

図３１の分散サーバ定義には、「このＤＢサーバはデータ取得するのにキーワード（ｋｅｙ）を使った検索（ｃｏｎｔａｉｎｓ）しかできない」というＤＢサーバ２０の問い合わせ処理能力に関する宣言が記述されている。

汎化プロセッサ２３０は、図１４のＸＱｕｅｒｙと図３１の分散サーバ定義とを比較して構文上の違いを列挙する（図３０のステップＳ１１０２）。汎化プロセッサ２３０は、例えば、Ｙａｃｃ＆Ｌｅｘなどの字句解析と構文解析のツールを組み合わせてメモリ上にＸＱｕｅｒｙの構文木を展開し、２つのメモリ上の構文木同士を比較する。

その結果、汎化プロセッサ２３０は、「ｄｏｃ（）／／ｒｏｗ」と「ｄｏｃ（）／＊」、および、「＄ｘ／／ｃｏｌｕｍｎ３」と「＄ｘ」の部分が相違することを検出できる。この２つの相違は、ＸＱｕｅｒｙのパスに関するものである。そこで、変換部２３１は、「パスの省略」という汎化操作を適用する。汎化操作は、例えばルールベースシステム技術を使うことで実現可能である。すなわち、「ＩＦ パス上の相違が存在すれば ＴＨＥＮ パスを省略する」といったＩＦ節とＴＨＥＮ節の２つの部分から構成されるルールで汎化操作を表現し、推論エンジンを使ってそのようなルール集合を停止条件まで繰り返し適用することで実現できる。この場合の停止条件とは、ＤＸＱｕｅｒｙと分散サーバ定義との違いが無くなることである。

例えば、図１４のＸＱｕｅｒｙについては、（１）「ｄｏｃ（）／／ｒｏｗ」から「ｄｏｃ（）／＊」へのパスの省略、（２）「＄ｘ／／ｃｏｌｕｍｎ３」から「＄ｘ」へのパスの省略、の２つの汎化操作を行えば停止条件を満たす。

その後、ｒｅｔｕｒｎ節を「ｒｅｔｕｒｎ ＜ｒｅｃ＞｛．．．｝＜／ｒｅｃ＞」の形式で出力することで図３２のＤＸＱｕｅｒｙが生成される。

次に、図１４のＸＱｕｅｒｙと図３１の分散サーバ定義から図３３のＶＸＱｕｅｒｙが生成する過程についてさらに説明する。

上記汎化操作で汎化された相違部分である「ｄｏｃ（）／／ｒｏｗ」と「ｄｏｃ（）／＊」、および、「＄ｘ／／ｃｏｌｕｍｎ３」と「＄ｘ」をチェックするような特別なＸＱｕｅｒｙをＶＸＱｕｅｒｙとして生成する。

生成部２３２は、例えば、相違部分を含む節である「ｆｏｒ ＄ｘ ｉｎ ｄｏｃ（）／／ｒｏｗ」と「ｗｈｅｒｅ ｃｏｎｔａｉｎｓ（＄ｘ／／ｃｏｌｕｍｎ３，“神奈川”）」とを、以下の（Ａ）に示すようなベースとなるＸＱｕｅｒｙに埋め込むことによりＶＸＱｕｅｒｙを生成する。このとき、必要に応じて埋め込む相違部分内の変数を、ベースとなるＸＱｕｅｒｙ内の変数で書き換える。ベースとなるＸＱｕｅｒｙは事前に設定することができる。
（Ａ）：
ｆｏｒ ＄＿０ ｉｎ ｄｏｃ（［ｕｒｉ＿ｄ１］）／ｒｅｃ
ｆｏｒ ＄＿１ ｉｎ ＄＿０／ｃｏｌ０／＊
ｒｅｔｕｒｎ
＜ｒｅｃ＞
｛＜ｃｏｌ０＞｛＄ｘ｝＜／ｃｏｌ０＞｝
＜／ｒｅｃ＞

埋め込んだＶＸＱｕｅｒｙは以下の（Ｂ）のようになる。
（Ｂ）：
ｆｏｒ ＄＿０ ｉｎ ｄｏｃ（［ｕｒｉ＿ｄ１］）／ｒｅｃ
ｆｏｒ ＄＿１ ｉｎ ＄＿０／ｃｏｌ０／＊
ｆｏｒ ＄ｘ ｉｎ ＄＿１／／ｒｏｗ
ｗｈｅｒｅ ｃｏｎｔａｉｎｓ（＄ｘ／／ｃｏｌｕｍｎ３，“神奈川”）
ｒｅｔｕｒｎ
＜ｒｅｃ＞
｛＜ｃｏｌ０＞｛＄ｘ｝＜／ｃｏｌ０＞｝
＜／ｒｅｃ＞

上記ＶＸＱｕｅｒｙでは、３行目および４行目が埋め込まれている。また、３行目の「＄ｘ」は「＄＿１」に置き換えられる。

以上説明したとおり、第１から第２の実施形態によれば、ＸＲＰＣを用いずにＸＱｕｅｒｙ透過な分散ＸＱｕｅｒｙ処理を実現することができる。

次に、第１または第２の実施形態にかかる検索装置（中央サーバ）のハードウェア構成について図３５を用いて説明する。図３５は、第１または第２の実施形態にかかる検索装置のハードウェア構成を示す説明図である。

第１または第２の実施形態にかかる検索装置は、ＣＰＵ（Central Processing Unit）５１などの制御装置と、ＲＯＭ（Read Only Memory）５２やＲＡＭ（Random Access Memory）５３などの記憶装置と、ネットワークに接続して通信を行う通信Ｉ／Ｆ５４と、ＨＤＤ（Hard Disk Drive）、ＣＤ（Compact Disc）ドライブ装置などの外部記憶装置と、ディスプレイ装置などの表示装置と、キーボードやマウスなどの入力装置と、各部を接続するバス６１を備えており、通常のコンピュータを利用したハードウェア構成となっている。

第１または第２の実施形態にかかる検索装置で実行される検索プログラムは、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ（Compact Disk Read Only Memory）、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ（Compact Disk Recordable）、ＤＶＤ（Digital Versatile Disk）等のコンピュータで読み取り可能な記録媒体に記録されてコンピュータプログラムプロダクトとして提供される。

また、第１または第２の実施形態にかかる検索装置で実行される検索プログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成してもよい。また、第１または第２の実施形態にかかる検索装置で実行される検索プログラムをインターネット等のネットワーク経由で提供または配布するように構成してもよい。

また、第１または第２の実施形態の検索プログラムを、ＲＯＭ等に予め組み込んで提供するように構成してもよい。

第１または第２の実施形態にかかる検索装置で実行される検索プログラムは、上述した各部（要求受付部、仮想化プランナ、ＸＱｕｅｒｙプロセッサ、リソース割当部、サーバ通知検出部）を含むモジュール構成となっており、実際のハードウェアとしてはＣＰＵ５１（プロセッサ）が上記記憶媒体から検索プログラムを読み出して実行することにより上記各部が主記憶装置上にロードされ、上述した各部が主記憶装置上に生成されるようになっている。

なお、本実施形態は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化することができる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成することができる。例えば、実施形態に示される全構成要素からいくつかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせても良い。

１０ クライアント
２０ａ、２０ｂ ＤＢサーバ
３０ ネットワーク
１００、２００ 中央サーバ
１０２ ＸＱｕｅｒｙプロセッサ
１０３ リソース割当部
１０４ サーバ通知検出部
１１０ 要求受付部
１１１ 送信部
１２０、２２０ 仮想化プランナ
１２１ 生成部
１２２、２２２ 送信部
１２３ 受信部
２３０ 汎化プロセッサ
２３１ 変換部
２３２ 生成部

Claims (7)

1. クライアントと、データを記憶する複数のサーバと、にネットワークを介して接続された検索装置であって、
   前記データのＸＱｕｅｒｙ形式の検索要求を前記クライアントから受け付ける第１受付部と、
   前記検索要求から、複数の前記サーバそれぞれに対して前記データの検索を要求するＸＱｕｅｒｙ形式の分散検索要求と、前記分散検索要求による検索結果を統合するＸＱｕｅｒｙ形式の統合要求とを生成する第１生成部と、
   前記分散検索要求を複数の前記サーバに送信する第１送信部と、
   前記統合要求の実行結果の識別情報を前記クライアントに送信する第２送信部と、
   前記識別情報で識別される実行結果の取得要求を前記クライアントから受け付ける第２受付部と、
   前記分散検索要求に対するＸＭＬ形式の検索結果を複数の前記サーバから受信する受信部と、
   複数の前記サーバそれぞれから受信した前記検索結果に対して前記統合要求を実行する実行部と、
   前記統合要求の実行結果を、前記取得要求を送信した前記クライアントに対して送信する第３送信部と、
   を備えることを特徴とする検索装置。
2. 前記統合要求の実行結果を格納する領域を確保し、前記領域の識別情報を前記実行結果に割り当てる割当部をさらに備え、
   前記第２送信部は、割り当てられた前記識別情報を前記クライアントに送信し、
   前記実行部は、前記統合要求の実行結果を前記領域に格納し、
   前記第３送信部は、前記領域に格納された前記実行結果を、前記取得要求を送信した前記クライアントに対して送信すること、
   を特徴とする請求項１に記載の検索装置。
3. 前記分散検索要求を、前記サーバの検索能力を満たすＸＱｕｅｒｙ形式の検索要求に変換する変換部と、
   変換された検索要求による検索結果から、前記分散検索要求による検索結果を生成するＸＱｕｅｒｙ形式の生成要求を生成する第２生成部と、をさらに備え、
   前記第１送信部は、変換された検索要求を前記サーバに送信し、
   前記受信部は、変換された検索要求に対する検索結果を前記サーバから受信し、
   前記実行部は、さらに、受信した検索結果に対して前記生成要求を実行し、前記生成要求の実行結果に対して前記統合要求を実行すること、
   を特徴とする請求項１に記載の検索装置。
4. 前記変換部は、前記分散検索要求に含まれるパスの省略、ＯＲ条件の展開、および、前記データに含まれる要素の名称の変換の少なくとも１つにより、前記分散検索要求を前記サーバの検索能力を満たす検索要求に変換すること、
   を特徴とする請求項３に記載の検索装置。
5. 前記ネットワークに接続された前記サーバを検出する検出部をさらに備え、
   前記第１送信部は、前記分散検索要求を検出された前記サーバに送信すること、
   を特徴とする請求項１に記載の検索装置。
6. クライアントと、データを記憶する複数のサーバと、にネットワークを介して接続された検索装置で実行される検索方法あって、
   前記データのＸＱｕｅｒｙ形式の検索要求を前記クライアントから受け付ける第１受付ステップと、
   前記検索要求から、複数の前記サーバそれぞれに対して前記データの検索を要求するＸＱｕｅｒｙ形式の分散検索要求と、前記分散検索要求による検索結果を統合するＸＱｕｅｒｙ形式の統合要求とを生成する第１生成ステップと、
   前記分散検索要求を複数の前記サーバに送信する第１送信ステップと、
   前記統合要求の実行結果の識別情報を前記クライアントに送信する第２送信ステップと、
   前記識別情報で識別される実行結果の取得要求を前記クライアントから受け付ける第２受付ステップと、
   前記分散検索要求に対するＸＭＬ形式の検索結果を複数の前記サーバから受信する受信ステップと、
   複数の前記サーバそれぞれから受信した前記検索結果に対して前記統合要求を実行する実行ステップと、
   前記統合要求の実行結果を、前記取得要求を送信した前記クライアントに対して送信する第３送信ステップと、
   を含むことを特徴とする検索方法。
7. クライアントと、データを記憶する複数のサーバと、にネットワークを介して接続されたコンピュータを、
   前記データのＸＱｕｅｒｙ形式の検索要求を前記クライアントから受け付ける第１受付部と、
   前記検索要求から、複数の前記サーバそれぞれに対して前記データの検索を要求するＸＱｕｅｒｙ形式の分散検索要求と、前記分散検索要求による検索結果を統合するＸＱｕｅｒｙ形式の統合要求とを生成する第１生成部と、
   前記分散検索要求を複数の前記サーバに送信する第１送信部と、
   前記統合要求の実行結果の識別情報を前記クライアントに送信する第２送信部と、
   前記識別情報で識別される実行結果の取得要求を前記クライアントから受け付ける第２受付部と、
   前記分散検索要求に対するＸＭＬ形式の検索結果を複数の前記サーバから受信する受信部と、
   複数の前記サーバそれぞれから受信した前記検索結果に対して前記統合要求を実行する実行部と、
   前記統合要求の実行結果を、前記取得要求を送信した前記クライアントに対して送信する第３送信部、
   として機能させるための検索プログラム。

Images