JP6324304B2

JP6324304B2 - クライアント装置及び通信システム及びデータ処理方法及びプログラム

Info

Publication number: JP6324304B2
Application number: JP2014243741A
Authority: JP
Inventors: 淳平羽藤
Original assignee: Mitsubishi Electric Corp
Current assignee: Mitsubishi Electric Corp
Priority date: 2014-12-02
Filing date: 2014-12-02
Publication date: 2018-05-16
Anticipated expiration: 2034-12-02
Also published as: JP2016110175A

Description

本発明は、クライアント・サーバシステムに関する。

サーバ装置（以下、単にサーバともいう）が様々な処理やデータをクライアント装置（以下、単にクライアントともいう）に提供するクライアント・サーバシステムにおいて、クライアント装置の台数、もしくはクライアント装置からサーバ装置への要求数が増大した場合、その増加率に応じてサーバ装置の処理負荷は増大する。

サーバ装置の処理負荷を分散・平準化する方法として、以下の方法が存在する。
サーバ装置とクライアント装置の間にロードバランサーを配置し、クライアント装置はロードバランサーに対して要求を送信し、ロードバランサーがある一定の基準に従ってその要求を、複数あるサーバ装置のうち、どのサーバ装置が処理するかを決定する。
そして、ロードバランサーが、処理を行わせるサーバ装置に要求に対処するよう命令を発行する。
これにより、個々のサーバ装置の処理負荷を分散・平準化させることができる。

しかし、この先行技術では複数のサーバ装置とロードバランサーをサーバシステム側で確保する必要があり、サーバ装置が単体のサーバシステムを構築する場合には、当該技術を利用できないという課題がある。

また、サーバ装置の処理負荷の分散・平準化技術として、例えば、特許文献１に記載される方法が存在する。
特許文献１の技術では、サーバ装置と複数のクライアント装置で構成され、クライアント装置にソフトウエアイメージを配布するシステムにおいて、サーバ装置がクライアント装置を複数のグループに分類し、グループごとに代表クライアント装置を決め、サーバ装置は代表クライアント装置へソフトウエアイメージを配布する。
代表クライアント装置は、同一グループに所属する他のクライアント装置からの要求に基づいてソフトウエアイメージを同一グループに属するクライアント装置に配布する。

国際公開ＷＯ２０１１／１３５６２９号

しかし、特許文献１の技術では、サーバ装置が複数のクライアント装置のグループ分類と代表クライアント装置の決定を行う必要がある。
クライアント装置のシステムへの参加、離脱が頻繁に発生するような、例えば高速移動体からの無線通信によるシステム参加が行われる状況においては、サーバ装置が頻繁にグループ管理、代表クライアント装置の決定を行う必要があり、サーバ装置の処理負荷が増加してしまうという課題がある。

本発明は、上述の課題を解決することを主な目的とし、サーバ装置を増強させることなく、また、サーバ装置が単体で構成される場合でも、サーバ装置の負荷を軽減することを主な目的とする。

本発明に係るクライアント装置は、
複数のクライアント装置が含まれる通信システムに含まれるクライアント装置であって、
いずれかのクライアント装置により生成されたサーバ装置へのリクエストを取得した場合に、取得した取得リクエストについて、代表してリクエストを処理する役割である代表クライアントロールが自装置に割り当てられているか否かを判定する代表クライアント判定部と、
前記取得リクエストについての代表クライアントロールが自装置に割り当てられている場合に、前記取得リクエストに対応する前記サーバ装置からのレスポンスが、自装置がアクセスできるキャッシュ領域にキャッシュされているか否かを判定する代表クライアント処理部と、
前記取得リクエストについての代表クライアントロールが自装置に割り当てられており、前記取得リクエストに対応するレスポンスが前記キャッシュ領域にキャッシュされていない場合に、前記取得リクエストを前記サーバ装置に送信するサーバ通信部と、
前記取得リクエストについての代表クライアントロールが自装置に割り当てられていない場合に、前記取得リクエストを他のクライアント装置に送信する他クライアント通信部とを有する。

本発明では、代表クライアントロールが割り当てられているクライアント装置にリクエストの処理を集約しているため、クライアント装置ごとにリクエストが送信され、サーバ装置が個別にレスポンスを返信するという事態を回避することができる。
また、代表クライアントロールが割り当てられているクライアント装置においてレスポンスがキャッシュされている場合には、サーバ装置にリクエストを送信することなく、リクエスト生成元のクライアント装置にレスポンスを提供することができる。
このため、サーバ装置を増強させることなく、また、サーバ装置が単体で構成される場合でも、サーバ装置の負荷を軽減することができる。

実施の形態１に係るサーバ装置及びクライアント装置のハードウエア構成例を示す図。実施の形態１に係るサーバ装置の内部処理モジュールの構成例を示す図。実施の形態１に係るクライアント装置の内部処理モジュールの構成例を示す図。実施の形態１に係るリクエスト生成元のクライアント装置の動作例を示すフローチャート図。実施の形態１に係るリクエスト送信先のクライアント装置の動作例を示すフローチャート図。実施の形態１に係るＡＰＩ呼び出し例とリクエスト例とを示す図。実施の形態１に係るリクエスト生成部の動作例を示すフローチャート図。実施の形態１に係る代表クライアント判定部の動作例を示すフローチャート図。実施の形態１に係る代表クライアント判定部の動作例を示すフローチャート図。実施の形態１に係る代表クライアント処理部の動作例を示すフローチャート図。実施の形態１に係る受信データ管理部でのリクエストとレスポンス保存例を示す図。実施の形態２に係る仮想空間上のノードとキーの配置例を示す図。実施の形態２に係る仮想空間上のノードとキーの配置例を示す図。実施の形態２に係る代表クライアント処理部の動作例を示す図。実施の形態３に係る予備代表クライアントの情報をＨＴＴＰリクエストに結合した例を示す図。実施の形態３に係る予備代表クライアントの情報をＨＴＴＰリクエストに結合した例を示す図。実施の形態３に係るサーバ装置の動作例を示すフローチャート図。実施の形態４に係る代表クライアント処理部の動作例を示すフローチャート図。実施の形態４に係る代表クライアント処理部の動作例を示すフローチャート図。実施の形態４に係る代表クライアント処理部の動作例を示すフローチャート図。実施の形態４に係るリクエストとリクエスト発行元とを管理するリストの例を示す図。実施の形態４に係る代表クライアントとリクエスト発行元クライアントとの関係を示す図。実施の形態４に係る代表クライアントとリクエスト発行元クライアントとの関係を示す図。実施の形態４に係る代表クライアントとリクエスト発行元クライアントと代表クライアントクローンとの関係を示す図。実施の形態４に係る代表クライアントとリクエスト発行元クライアントと代表クライアントクローンとの関係を示す図。実施の形態４に係る代表クライアントとリクエスト発行元クライアントと代表クライアントクローンとの関係を示す図。実施の形態４に係る代表クライアントとリクエスト発行元クライアントと代表クライアントクローンとの関係を示す図。実施の形態４に係る代表クライアントとリクエスト発行元クライアントと代表クライアントクローンとの関係を示す図。実施の形態４に係る代表クライアント処理部の動作例を示すフローチャート図。実施の形態４に係る代表クライアント処理部の動作例を示すフローチャート図。実施の形態５に係る代表クライアント判定部の動作例を示すフローチャート図。実施の形態５に係る代表クライアント判定部の動作例を示すフローチャート図。実施の形態５に係る代表クライアント処理部の動作例を示すフローチャート図。実施の形態５に係る代表クライアント処理部の動作例を示すフローチャート図。実施の形態５に係る論理和リクエストとレスポンスとを管理するテーブルの例を図。実施の形態５に係るレスポンスの例を示す図。

実施の形態１．
以下にて、本実施の形態を説明する。
本実施の形態では、サーバ装置のリソースを増強させることなく、また、サーバ装置単体のみで構成した場合でも、サーバ装置の負荷軽減効果が得られるようにする。
このため、本実施の形態では、サーバ装置に負荷分散のための処理を行わせるのではなく、クライアント装置に負荷分散のための処理を行わせる。

＊＊＊構成の説明＊＊＊
図１は、本実施の形態に係るクライアント・サーバシステムの構成例を示す。

図１に示すように、本実施の形態に係るクライアント・サーバシステムは、２台以上のクライアント装置１０１、クライアント装置１０２、クライアント装置１０３、クライアント装置１０４と、１台以上のサーバ装置１０５が存在し、それぞれがネットワーク１３０を経由して接続されている。
クライアント装置１０１、クライアント装置１０２、クライアント装置１０３、クライアント装置１０４で構成されるシステムは、通信システム１０００という。
なお、クライアント装置１０１、クライアント装置１０２、クライアント装置１０３、クライアント装置１０４は、あくまで複数のクライアント装置が存在する事を示すため、一つの例として４台のクライアント構成としている。
クライアント装置の台数は複数であれば構わず、４台以外の構成で構わない。
以下では、サーバ装置１０５を単にサーバともいい、クライアント装置１０１、クライアント装置１０２、クライアント装置１０３、クライアント装置１０４を単にクライアントともいう。

次に、クライアント装置１０１、クライアント装置１０２、クライアント装置１０３、クライアント装置１０４のハードウエア構成例を説明する。
なお、クライアント装置１０１、クライアント装置１０２、クライアント装置１０３、クライアント装置１０４のハードウエア構成例は共通しているため、以下では、代表として、クライアント装置１０１のハードウエア構成例を説明する。
以下の説明は、クライアント装置１０２、クライアント装置１０３、クライアント装置１０４にも同様に当てはまる。

クライアント装置１０１は、情報処理装置であり、ＣＰＵ（ＣｅｎｔｒａｌＰｒｏｃｅｓｓｉｎｇＵｎｉｔ）１１０、メモリ１１１、入力インタフェース１１２、出力インタフェース１１３、通信インタフェース１１４、永続記憶インタフェース１１５、ディスク１１６などの要素を内蔵し、それらがバス１１７で接続されている。

ＣＰＵ１１０は、メモリ１１１に格納されているプログラムやデータ、各種要素からの割り込みやデータ受け処理を行い、クライアント装置１０１としての動作を実現する。
より具体的には、ＣＰＵ１１０が、後述するアプリケーションロジック部２０６、リクエスト生成部２０７、代表クライアント判定部２０８、他クライアント通信部２０９、代表クライアント処理部２１０、受信データ管理部２１１、サーバ通信部２１２の機能を実現するプログラムを実行することで、クライアント装置１０１の後述する処理が行われる。
入力インタフェース１１２は、マウスやキーボードなどの入力デバイスが接続されるインタフェースであり、クライアント装置１０１のユーザは入力インタフェース１１２に接続された入力デバイスを操作して、クライアント装置１０１を操作する。
出力インタフェース１１３は、ディスプレイやスピーカーなどの出力デバイスが接続されるインタフェースであり、クライアント装置１０１のユーザは出力デバイスに出力される光や音などの刺激を元にクライアント装置１０１の状況を知覚する事が可能となる。
通信インタフェース１１４は、クライアント装置１０１がサーバ装置１０５や他クライアント装置１０２、クライアント装置１０３、クライアント装置１０４とデータの交換を行うためのインタフェースであり、ネットワーク１３０に接続される。
永続記憶インタフェース１１５は、ディスクなどの不揮発性の記憶装置が接続されるインタフェースであり、電源断後にも記憶したいデータや一時データの保存読み出しはこのインタフェースを通して行われる。

次に、サーバ装置１０５のハードウエア構成例を説明する。
サーバ装置１０５は、クライアント装置１０１〜１０４と同等の情報処理装置である。
サーバ装置１０５は、ＣＰＵ１２０、メモリ１２１、入力インタフェース１２２、出力インタフェース１２３、通信インタフェース１２４、永続記憶インタフェース１２５、ディスク１２６などの要素を内蔵しており、それらがバス１２７で接続されている。

ＣＰＵ１２０は、メモリ１２１に格納されているプログラムやデータ、各種要素からの割り込みやデータ受け処理を行い、サーバ装置１０５としての動作を実現する。
より具体的には、ＣＰＵ１２０が、後述する通信部２１３及び要求処理部２１４の機能を実現するプログラムを実行することで、サーバ装置１０５の後述する処理が行われる。
入力インタフェース１２２は、マウスやキーボードなどの入力デバイスが接続されるインタフェースであり、サーバ管理者は入力インタフェース１２２に接続された入力デバイスを操作して、サーバ装置１０５を操作する。
出力インタフェース１２３は、ディスプレイやスピーカーなどの出力デバイスが接続されるインタフェースであり、サーバ管理者は出力デバイスに出力される光や音などの刺激を元にサーバ装置１０５の状況を知覚する事が可能となる。
通信インタフェース１２４は、クライアント装置１０１、クライアント装置１０２、クライアント装置１０３、クライアント装置１０４とデータの交換を行うためのインタフェースであり、ネットワーク１３０に接続される。
永続記憶インタフェース１２５は、ディスクなどの不揮発性の記憶装置が接続されるインタフェースであり、電源断後にも記憶したいデータや一時データの保存読み出しはこのインタフェースを通して行われる。

クライアント装置１０１、クライアント装置１０２、クライアント装置１０３、クライアント装置１０４はクライアント装置のユーザに対してあるサービスを提供するため、ネットワーク１３０を経由してサーバ装置１０５と連携処理を行う。
クライアント装置１０１、クライアント装置１０２、クライアント装置１０３、クライアント装置１０４は、サーバ装置１０５に何らかの処理を要求する場合、その要求内容をデータとして記述したリクエストをサーバ装置１０５に発行する。
例えばＷｅｂシステムではクライアント・サーバ間の通信はＨＴＴＰ（ＨｙｐｅｒＴｅｘｔＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ）を用いて行われ、そのリクエストはＨＴＴＰリクエストのメソッド、ＵＲＩ（ＵｎｉｆｉｅｄＲｅｓｏｕｒｃｅＩｄｅｎｔｉｆｉｅｒ）、ボディなどとして表現される。
なお、サーバ・クライアント間の通信はＨＴＴＰ以外にもＷｅｂＳｏｃｋｅｔＡＰＩ（ＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍｍｉｎｇＩｎｔｅｒｆａｃｅ）など他のプロトコルを用いたとしても、本質的には同等であり、違いはない。

クライアント装置１０１、クライアント装置１０２、クライアント装置１０３、クライアント装置１０４が送信したリクエストを受信したサーバ装置１０５は、そのリクエストの内容を解析し、どの様な処理を行うべきかを決定する。
ＨＴＴＰを用いてリクエストを受け取った場合、サーバ装置１０５は、一般的にはＵＲＩで処理を行うべき対象となるリソースを一意に特定し、メソッドでそのリソースに対する具体的な動作を特定する。
その他処理に必要となるパラメータをクライアント装置から指定する場合にはＵＲＩのクエリー部もしくはボディとしてパラメータを与えて、クライアント装置から送信されてくるため、サーバ装置１０５は適時その情報（パラメータ）を利用して処理を行う。
サーバ装置１０５がクライアント装置に提供する処理は、ファイルの内容の送信、ファイルの書き換え、データベース等の他プロセスの制御や、サーバ装置１０５に接続されている各種機器の制御など多岐にわたる。

図２を用いて、本実施の形態に係るサーバ装置１０５の内部処理モジュールの説明を行う。

サーバ装置１０５は、システム内に存在するクライアント装置１０１、クライアント装置１０２、クライアント装置１０３、クライアント装置１０４と通信するための通信部２１３を持つ。
通信部２１３は、複数のクライアント装置と並行して通信のコネクションを確立できる。
通信部２１３は、クライアント装置からのリクエストを受信すると、そのリクエストを要求処理部２１４に転送する。

要求処理部２１４は、リクエストを解析し、どの様な処理が要求されているのかを特定する。
その後、要求処理部２１４は、特定された要求処理を実行し、その処理結果を得る。
処理結果を得た要求処理部２１４はクライアント装置が解釈可能な形式にその処理結果を変換しレスポンスを生成する。
レスポンス生成後、要求処理部２１４は通信部２１３を利用してレスポンスを、リクエスト送信元のクライアント装置に返信する。

次に、図３を用いて本実施の形態に係るクライアント装置の内部処理モジュールの説明を行う。
各クライアント装置は、それぞれ同等の内部処理モジュール構成となっており、どのクライアント装置も基本的に等価である。
図３では、クライアント装置１０１、クライアント装置１０２のみ内部処理モジュールを記述しているが、クライアント装置１０３、クライアント装置１０４にはその記述がないのは、記述を省略しているためであり、クライアント装置１０３、クライアント装置１０４はクライアント装置１０１、クライアント装置１０２と同等の内部処理モジュールを持つ。
以下では、代表として、クライアント装置１０１の内部処理モジュールを説明する。
以下の説明は、クライアント装置１０２、クライアント装置１０３、クライアント装置１０４にも同様に当てはまる。

クライアント装置１０１がクライアント装置１０１のユーザに提供するサービスの具体的なロジックを記述するのがアプリケーションロジック部２０６である。
例えば、提供するサービスがサーバ装置１０５と連動して動作するゲームアプリケーションであれば、ゲームアプリケーションに必要となるデータやゲームロジックなどがプログラミングされたソフトウエア等がアプリケーションロジック部２０６に相当する。
それ以外にサーバ装置１０５を経由したプラント監視制御を提供するサービスであれば、監視制御に必要な制御手続きやプラントから取得したデータを表示するための表示ロジック等がプログラミングされたソフトウエア等がアプリケーションロジック部２０６に相当する。
アプリケーションロジック部２０６は、サーバ装置１０５と連動して動作するアプリケーションであれば何でも構わない。
アプリケーションロジック部２０６は、サーバ装置１０５と連動する必要が発生すると、リクエスト生成部２０７に対してサーバ装置１０５と連動すべき具体的な処理内容を伝える処理を行う。

リクエスト生成部２０７は、アプリケーションロジック部２０６に対して、サーバ装置１０５がクライアント装置１０１に提供する処理内容に対応したＡＰＩを提供する。
アプリケーションロジック部２０６は連動すべき処理内容に対応するＡＰＩを呼び出す。
また、リクエスト生成部２０７は、必要に応じてパラメータをＡＰＩに提供する。
更に、リクエスト生成部２０７は、アプリケーションロジック部２０６がサーバ装置１０５と通信する際のプロトコルやリクエストのデータ形式を意識することなく、またサーバ装置１０５からのレスポンスのデータ形式を意識することなく処理を遂行できるようにするための抽象化層の役割を持つ。
また、リクエスト生成部２０７は、本実施の形態に関わる振る舞いをアプリケーションロジック部２０６と独立にするための抽象化層の役割も併せ持つ。
呼び出されたＡＰＩに対応する処理内容と提供されたパラメータを元にサーバ装置１０５が解釈可能なリクエストを生成したリクエスト生成部２０７は、代表クライアント判定部２０８に生成したリクエストを出力する。

代表クライアント判定部２０８は、いずれかのクライアント装置により生成されたサーバ装置１０５へのリクエストを取得した場合に、取得したリクエストについて、代表してリクエストを処理する役割である代表クライアントロールが自装置（クライアント装置１０１）に割り当てられているか否かを判定する。
代表クライアントロールが割り当てられているクライアント装置を、代表クライアント装置又は単に代表クライアントという。
なお、上記「リクエストを処理する」における「処理」には、リクエストに対するレスポンスがキャッシュされているか否かを判定する処理、レスポンスがキャッシュされていない場合に、リクエストをサーバ装置１０５に送信する処理、サーバ装置１０５からレスポンスを受信する処理、受信したレスポンスをリクエスト発行元に返信する処理、受信したレスポンスをキャッシュする処理が含まれる。
代表クライアント判定部２０８は、前述したように、自装置のリクエスト生成部２０７により生成されたリクエストを取得する場合もあるし、他のクライアント装置のリクエスト生成部２０７により生成されたリクエストを取得する場合もある。
自装置のリクエスト生成部２０７により生成されたリクエストであって代表クライアント判定部２０８が取得したリクエスト、他のクライアント装置のリクエスト生成部２０７により生成されたリクエストであって代表クライアント判定部２０８が取得したリクエストの両者を、以下では取得リクエストという。
代表クライアント判定部２０８は、複数のクライアント装置の間で共有している分散ハッシュテーブルを用いて、取得リクエストについての代表クライアントロールが自装置（クライアント装置１０１）に割り当てられているか否かを判定する。
代表クライアント判定部２０８は、取得リクエストについて、代表クライアントロールが自装置（クライアント装置１０１）に割り当てられている場合は、取得リクエストを代表クライアント処理部２１０に出力する。
一方、取得リクエストについて、代表クライアントロールが自装置（クライアント装置１０１）に割り当てられていない場合は、代表クライアント判定部２０８は、取得リクエストを他クライアント通信部２０９に出力する。

前述したように、取得リクエストについての代表クライアントロールが自装置（クライアント装置１０１）に割り当てられていない場合は、代表クライアント判定部２０８から取得リクエストが出力され、他クライアント通信部２０９が、取得リクエストを他のクライアント装置に送信する。
また、取得リクエストが他のクライアント装置で生成されたリクエストであり、取得リクエストについての代表クライアントロールが自装置（クライアント装置１０１）に割り当てられており、キャッシュ領域に取得リクエストに対応するレスポンスがキャッシュされている場合に、他クライアント通信部２０９は、受信データ管理部２１１にキャッシュされているレスポンスを取得リクエストの生成元のクライアント装置に送信する。
他クライアント通信部２０９は、通信インタフェース１１４を用いて他クライアント装置と通信を行うためのＡＰＩ（ＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍｍｉｎｇＩｎｔｅｒｆａｃｅ）を提供している。
例えば、本実施の形態に係るシステムがＷｅｂシステムとして構築されており、クライアント装置１０１がＷｅｂブラウザ上に実装されている場合には、ＷｅｂＲＴＣなどのＡＰＩを提供する事となる。
他クライアント通信部２０９は、何らかのデータ送信要求がＡＰＩ経由で通知された場合には、その要求に従い送信先となるクライアント装置にデータを送信する。
また、他のクライアント装置から何らかのデータが送信されてきた場合には、他のクライアント装置からデータが送信されてきた旨をイベントなどの形式でクライアント装置１０１内に通知し、そのイベントを監視しているモジュールがその受信データを処理する事となる。

代表クライアント処理部２１０は、自装置（クライアント装置１０１）に代表クライアントロールが割り当てられている場合に、代表クライアントとして振る舞うための動作を行う。
具体的には、代表クライアント処理部２１０は、取得リクエストがリクエスト生成部２０７で生成されたリクエストであり、取得リクエストについての代表クライアントロール（クライアント装置１０１）が自装置に割り当てられており、受信データ管理部２１１に取得リクエストに対応するサーバ装置１０５からのレスポンスであって有効期限内のレスポンスがキャッシュされている場合に、受信データ管理部２１１にキャッシュされているレスポンスを代表クライアント判定部２０８を介してリクエスト生成部２０７に出力する。
また、取得リクエストが他のクライアント装置のリクエスト生成部２０７で生成されたリクエストであり、取得リクエストについての代表クライアントロール（クライアント装置１０１）が自装置に割り当てられており、受信データ管理部２１１に取得リクエストに対応するサーバ装置１０５からのレスポンスがキャッシュされている場合に、受信データ管理部２１１にキャッシュされているレスポンスを他クライアント通信部２０９に出力する。

受信データ管理部２１１は、サーバ装置１０５からのレスポンスを保存するキャッシュ領域を持ち、キャッシュ領域を管理する。
受信データ管理部２１１は、代表クライアント処理部２１０がサーバ装置１０５より取得したレスポンスを対応するリクエストと対応付けしてキャッシュ領域に保存する。
また、受信データ管理部２１１は、あるリクエストをキーとして対応するレスポンスを取得することができる。
なお、本実施の形態では、キャッシュ領域はクライアント装置１０１に内蔵されているが、キャッシュ領域は、クライアント装置１０１（より厳密には、代表クライアント処理部２１０）がアクセスできればよく、クライアント装置１０１に内蔵されていなくてもよい。
なお、以下では、レスポンスが受信データ管理部２１１にキャッシュされている旨の表現も用いるが、これは受信データ管理部２１１が管理するキャッシュ領域にレスポンスがキャッシュされているという意味である。

サーバ通信部２１２は、取得リクエストについての代表クライアントロールが自装置（クライアント装置１０１）に割り当てられており、取得リクエストに対応するレスポンスが受信データ管理部２１１にキャッシュされていない場合に、取得リクエストをサーバ装置１０５に送信する。
サーバ通信部２１２は、通信インタフェース１１４を用いてサーバ装置１０５と通信を行うためのＡＰＩを提供している。
例えば、本実施の形態に係るシステムがＷｅｂシステムとして構築されており、クライアント装置１０１がＷｅｂブラウザ上に実装されている場合には、ＸＭＬＨｔｔｐＲｅｑｕｅｓｔオブジェクトやＷｅｂＳｏｃｋｅｔＡＰＩなどがサーバ通信部２１２に相当する。
なおサーバ装置、クライアント装置間の通信プロトコルをＨＴＴＰとする場合にはＸＭＬＨｔｔｐＲｅｑｕｅｓｔオブジェクトを用いる事になるが、ＷｅｂＳｏｃｋｅｔＡＰＩを用いたとしてもＨＴＴＰと同等の機能を実現できるため、実質的にどちらを用いたとしても、両方を併用したとしても、違いはない。

＊＊＊動作の説明＊＊＊
次に、本実施の形態に係るクライアント装置におけるデータ処理方法の概要を説明する。

図４は、リクエスト生成元のクライアント装置の動作例を示す。
以下では、クライアント装置１０１がリクエスト生成元である例を用いて説明を進める。

クライアント装置１０１のリクエスト生成部２０７は、アプリケーションロジック部２０６からの指示に基づき、サーバ装置１０５へのリクエストを生成する（処理１０１）。
そして、リクエスト生成部２０７は生成したリクエストを代表クライアント判定部２０８に出力する。

代表クライアント判定部２０８は、当該リクエスト（取得リクエスト）についての代表クライアントロールが自装置（クライアント装置１０１）に割り当てられているか否かを判定する（処理１０２）。
この処理１０２は、代表クライアント判定ステップに相当する。

リクエストについて自装置に代表クライアントロールが割り当てられている場合（処理１０２でＹＥＳ）は、代表クライアント判定部２０８はリクエストを代表クライアント処理部２１０に出力し、代表クライアント処理部２１０が、サーバ通信部２１２にリクエストに対応するレスポンスがキャッシュされているか否かを判定する（処理１０３）。
この処理１０３は、代表クライアント処理ステップに相当する。

受信データ管理部２１１にレスポンスがキャッシュされている場合（処理１０３でＹＥＳ）は、代表クライアント処理部２１０は、受信データ管理部２１１にキャッシュされているレスポンスをリクエスト生成部２０７に返し、また、リクエスト生成部２０７が当該レスポンスをアプリケーションロジック部２０６に返し、アプリケーションロジック部２０６は当該レスポンスを用いた処理を行う（処理１０４）。

一方、受信データ管理部２１１にレスポンスがキャッシュされていない場合（処理１０３でＮＯ）は、代表クライアント処理部２１０はリクエストをサーバ通信部２１２に出力し、サーバ通信部２１２がサーバ装置１０５にリクエストを送信する（処理１０５）。
この処理１０５は、サーバ通信ステップに相当する。

サーバ通信部２１２は、サーバ装置１０５からレスポンスを受信する（処理１０６）。
その後、サーバ通信部２１２はサーバ装置１０５からのレスポンスを代表クライアント処理部２１０及び代表クライアント判定部２０８を経由してリクエスト生成部２０７に返し、リクエスト生成部２０７がアプリケーションロジック部２０６にレスポンスを返し、リクエスト生成部２０７が当該レスポンスを用いた処理を行う（処理１０４）。

一方、リクエストについて自装置に代表クライアントロールが割り当てられていない場合（処理１０２でＮＯ）は、代表クライアント判定部２０８はリクエストを他クライアント通信部２０９に出力し、他クライアント通信部２０９がリクエストを他のクライアント装置（例えば、クライアント装置１０２）に送信する（処理１０７）。
この処理１０７は、他クライアント通信ステップに相当する。

他クライアント通信部２０９は、他のクライアント装置（例えば、クライアント装置１０２）からレスポンスを受信する（処理１０８）。
その後、他クライアント通信部２０９は、受信したレスポンスを代表クライアント処理部２１０に出力する。

代表クライアント処理部２１０は、他クライアント通信部２０９から出力されたレスポンスが自装置（クライアント装置１０１）宛のレスポンスであるか否かを判定する（処理１０９）。

自装置（クライアント装置１０１）宛のレスポンスであれば（処理１０９でＹＥＳ）、代表クライアント処理部２１０は、代表クライアント判定部２０８を経由して当該レスポンスをリクエスト生成部２０７に返し、また、リクエスト生成部２０７が当該レスポンスをアプリケーションロジック部２０６に返し、アプリケーションロジック部２０６は当該レスポンスを用いた処理を行う（処理１０４）。

一方、自装置（クライアント装置１０１）宛のレスポンスでなければ（処理１０９でＮＯ）、代表クライアント判定部２０８は、当該レスポンスを他クライアント通信部２０９に出力し、他クライアント通信部２０９が当該レスポンスを他のクライアント装置（例えば、クライアント装置１０３）に転送する（処理１１０）。
処理１０９でＮＯとなるのは、リクエスト生成部２０７で生成されたリクエストを他のクライアント装置（例えば、クライアント装置１０２）に送信するとともに、他のクライアント装置（例えば、クライアント装置１０３）で生成されたリクエストを他のクライアント装置（クライアント装置１０２）に送信し、他のクライアント装置（クライアント装置１０２）から他のクライアント装置（クライアント装置１０３）で生成されたリクエストに対するレスポンスを受信した場合である。

図５は、リクエストの送信先のクライアント装置の動作例を示す。
ここでは、クライアント装置１０２がクライアント装置１０１で生成されたリクエストを受信した例を用いて、説明を進める。

クライアント装置１０２では、他クライアント通信部２０９が他のクライアント装置（クライアント装置１０１）から送信されたリクエストを受信する（処理２０１）。
他クライアント通信部２０９は、受信したリクエストを代表クライアント判定部２０８に出力する。

代表クライアント判定部２０８は、当該リクエスト（取得リクエスト）についての代表クライアントロールが自装置（クライアント装置１０２）に割り当てられているか否かを判定する（処理２０２）。

当該リクエストについて自装置に代表クライアントロールが割り当てられている場合（処理２０２でＹＥＳ）は、代表クライアント判定部２０８は当該リクエストを代表クライアント処理部２１０に出力し、代表クライアント処理部２１０が、受信データ管理部２１１に当該リクエストに対応するレスポンスがキャッシュされているか否かを判定する（処理２０３）。

受信データ管理部２１１にレスポンスがキャッシュされている場合（処理２０３でＹＥＳ）は、代表クライアント処理部２１０は、受信データ管理部２１１にキャッシュされているレスポンスを代表クライアント判定部２０８を経由して他クライアント通信部２０９に返し、他クライアント通信部２０９が当該レスポンスを他のクライアント装置（クライアント装置１０１）に返信する（処理２０４）。

一方、受信データ管理部２１１にレスポンスがキャッシュされていない場合（処理２０３でＮＯ）は、代表クライアント処理部２１０はリクエストをサーバ通信部２１２に出力し、サーバ通信部２１２がサーバ装置１０５にリクエストを送信する（処理２０５）。

サーバ通信部２１２は、サーバ装置１０５からレスポンスを受信する（処理２０６）。
その後、サーバ通信部２１２はサーバ装置１０５からのレスポンスを代表クライアント処理部２１０及び代表クライアント判定部２０８を経由して他クライアント通信部２０９に返し、他クライアント通信部２０９が当該レスポンスを他のクライアント装置（クライアント装置１０１）に返信する（処理２０４）。

一方、当該リクエストについて自装置に代表クライアントロールが割り当てられていない場合（処理２０２でＮＯ）は、代表クライアント判定部２０８は当該リクエストを他クライアント通信部２０９に出力し、他クライアント通信部２０９が当該リクエストを他のクライアント装置（例えば、クライアント装置１０４）に送信する（処理２０７）。

他クライアント通信部２０９は、他のクライアント装置（クライアント装置１０４）からレスポンスを受信する（処理２０８）。
その後、他クライアント通信部２０９は当該レスポンスを他のクライアント装置（クライアント装置１０１）に返信する（処理２０４）。

次に、本実施の形態に係るクライアント装置の動作を詳細に説明する。
まず、ＡＰＩの呼び出し後にリクエスト生成部２０７が行う処理を、図７を用いて説明する。

処理４０１で、リクエスト生成部２０７は、呼び出されたＡＰＩに対応する処理内容と提供されたパラメータを元にサーバ装置１０５が解釈可能なリクエストを生成する。

図６に処理４０１の一つの具体例を示す。
図６はＡＰＩ呼出し時のコード上の記述に対応する、生成されるリクエストの一例を示した対応表である。
ここでは、アプリケーションロジック部２０６が提供すべきサービスはプラント監視制御を想定し、プラントの監視時間間隔を取得するＡＰＩ、監視時間間隔を変更するＡＰＩ、ディスプレイに表示すべき画面の定義データを取得するＡＰＩがあるとし、それぞれのＡＰＩ名は「ｇｅｔＭｏｎｉｔｏｒＩｎｔｅｒｖａｌ」、「ｓｅｔＭｏｎｉｔｏｒＩｎｔｅｒｖａｌ」、「ｇｅｔＰａｇｅＣｏｎｔｅｎｔ」としている。
また、サーバ装置１０５とクライアント装置はＨＴＴＰで通信すると仮定している。
監視時間間隔を取得する場合、アプリケーションロジック部２０６は引数なしで「ｇｅｔＭｏｎｉｔｏｒＩｎｔｅｒｖａｌ」を呼び出す。
呼び出されたリクエスト生成部２０７はデータ取得を意味するメソッドＧＥＴと時間間隔を一意に特定するＵＲＩである「ｈｔｔｐ：／／ｘｘｘ／ａｐｉ／ｍｏｎｉｔｏｒ＿ｉｎｔｅｒｖａｌ／」で構成されるＨＴＴＰリクエストを生成する。
また、監視時間間隔を変更する場合、アプリケーションロジック部２０６は引数で設定した時間間隔を与えて「ｓｅｔＭｏｎｉｔｏｒＩｎｔｅｒｖａｌ」を呼び出す。
呼び出されたリクエスト生成部２０７は、データ送信を意味するメソッドＰＯＳＴと時間間隔を一意に特定するＵＲＩである「ｈｔｔｐ：／／ｘｘｘ／ａｐｉ／ｍｏｎｉｔｏｒ＿ｉｎｔｅｒｖａｌ／」に対してクエリーとして引数で指定された値を加えたＵＲＬを生成し、それらで構成されるＨＴＴＰリクエストを生成する。
加えて、画面の定義データを取得する場合、アプリケーションロジック部２０６は引数で画面名を与えて「ｇｅｔＰａｇｅｔＣｏｎｔｅｎｔ」を呼び出す。
呼び出されたリクエスト生成部２０７は、データ取得を意味するメソッドＧＥＴと要求された画面の定義データを一意に特定するＵＲＩである「ｈｔｔｐ：／／ｘｘｘ／ｈｔｍｌ／Ｍｏｎｉｔｏｒ．ｈｔｍｌ」で構成されるＨＴＴＰリクエストを生成する。
この例では、画面定義データをＨＴＭＬ（ＨｙｐｅｒＴｅｘｔＭａｒｋｕｐＬａｎｇｕａｇｅ）で記述されているファイルであると仮定しており、「ｈｔｔｐ：／／ｘｘｘ／ｈｔｍｌ／」と「．ｈｔｍｌ」の間に引数で受けた画面名を挿入してＵＲＩを構成している。

図７に戻り、処理４０１でリクエストを生成した後、リクエスト生成部２０７は、処理４０２で、代表クライアント判定部２０８にリクエストを送信し、処理４０３でそのレスポンスが代表クライアント判定部２０８から返信されるまで待機する。
レスポンスが代表クライアント判定部２０８から返信されると、リクエスト生成部２０７は、処理４０４で、返信されたレスポンスをアプリケーションロジック部２０６が解釈可能な形式に変換する。
そして、処理４０５で、リクエスト生成部２０７は、その変換結果をアプリケーションロジック部２０６に返信し処理を完了する。

処理４０４でのレスポンスの変換処理の一例としてレスポンスがＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ（登録商標）ＯｂｊｅｃｔＮｏｔａｔｉｏｎ）形式のデータである場合には、ＪａｖａＳｃｒｉｐｔ（登録商標）が解釈可能なオブジェクトに変換するなどが考えられる。

リクエストの転送を受けた代表クライアント判定部２０８の処理を、図８を用いて説明する。

リクエストの転送を受けた代表クライアント判定部２０８は、処理５０１で、分散ハッシュテーブルを用い、そのリクエストのＩＤを算出する。

分散ハッシュテーブルとは複数のピアでハッシュテーブルを分散して管理する技術の事であり、ピアを本実施の形態ではクライアント装置に対応づけて解釈する。
分散ハッシュテーブルは分散管理されている以外はハッシュテーブルと機能面では同等であり、ある値をハッシュ関数を用いてある空間の点に射影し、その点をＩＤとして値に関連付けを行う。
この関連付けを行う事によってＩＤから値を検索する事が可能となる。
ハッシュ関数への入力値は異なる尺度の値でも構わず、それぞれの尺度の値同士の関連性を作り出すためにも用いる事が出来る。
そのため、分散ファイルシステムでどのファイルをどのノードで管理するかを決定するために分散ハッシュテーブルを用いてファイルとノードの関連性を作り出す事にも用いられる事がある。
本実施の形態では、リクエストとクライアント装置の通信時の識別情報となるネットワークＩＤをハッシュ関数の入力として扱い、各リクエストのＩＤと各クライアント装置のＩＤの関係に応じて、どのリクエストに対して、どのクライアント装置がサーバに発行するクライアント装置である代表クライアント装置になるか（どのクライアント装置に代表クライアントロールが割り当てられているか）を分散ハッシュテーブルを用いて決定する。
リクエストのＩＤの具体例としてＵＲＩが考えられる。
また、クライアント装置のネットワークＩＤの具体例として、そのクライアント装置のＩＰ（ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ）アドレスやＭＡＣ（ＭｅｄｉａＡｃｃｅｓｓＣｏｎｔｒｏｌ）アドレスが考えられる。
分散ハッシュテーブルはハッシュ関数を選択する事によって、代表クライアントロールを確率的に一様に各クライアント装置に振り分ける事が理論上可能となるため、ある特定のクライアント装置に多くの代表クライアントロールを割り当てる様なクライアント装置間の処理負荷の偏りを回避可能である。

図８に戻り、処理５０２では、代表クライアント判定部２０８は、リクエストＩＤとそのクライアント装置に対する分散ハッシュテーブル上のＩＤおよび分散ハッシュテーブル自身を用いて、そのクライアント装置自身が、サーバ装置にそのリクエストを発行するクライアント装置である代表クライアント装置となるかを判定する。
つまり、そのクライアント装置に、そのリクエストについて代表クライアントロールが割り当てられているかを判定する。
そのクライアント装置自身が代表クライアント装置である場合には処理５０３、そのクライアント装置ではない他のクライアント装置が代表クライアント装置である場合には処理５０５に処理を分岐する。

処理５０３では、クライアント装置自身が代表クライアント装置となるため、代表クライアント判定部２０８は、そのリクエストを代表クライアント処理部２１０に転送し、処理５０４で代表クライアント処理部２１０からリクエストに対応するレスポンスが返信されるまで待機を行う。
その後、レスポンスが返信された場合には処理５０７に遷移する。

一方で、処理５０５では、そのクライアント装置以外の他のクライアント装置が代表クライアント装置となるため、代表クライアント判定部２０８は、リクエストを分散ハッシュテーブルのアルゴリズムに従って他クライアント通信部２０９より他のクライアント装置に転送する。
この時、リクエストに加えて、クライアント装置自身の分散ハッシュテーブルに従って算出されたＩＤもしくはクライアント装置自身のネットワークＩＤなど、リクエストに対応するレスポンスを最終的にどのクライアント装置に返信すればよいかを判断できる情報を付加して転送する。

リクエストの転送後、処理５０６で、代表クライアント判定部２０８は、そのクライアント装置が転送したリクエストに対応するレスポンスが代表クライアント装置から返信されるまで待機する。
代表クライアント装置からのレスポンスの返信があった場合には処理５０７に遷移する。

処理５０７では、代表クライアント判定部２０８は、レスポンスに対応するリクエストの発行元クライアントが現在処理を行っているクライアント装置自身であるか判定を行う。
その結果、クライアント装置自身である場合には処理５０８に遷移し、サーバ装置１０５、もしくは代表クライアントからのレスポンスをリクエスト生成部２０７に返信する。
逆に、その結果がクライアント装置自身でない場合には、代表クライアント判定部２０８は、処理５０９で、リクエストの発行元のクライアント装置に向け分散ハッシュテーブルに従い、他のクライアント装置にレスポンスを転送する。
例えば、図８の処理を行っているクライアント装置がクライアント装置１０１であり、代表クライアント装置がクライアント装置１０３であり、リクエスト発行元のクライアント装置がクライアント装置１０４である場合は、クライアント装置１０１の代表クライアント判定部２０８は、クライアント装置１０２にレスポンスを転送する。

次に、処理５０５でリクエストを他のクライアント装置に転送した際の、リクエストの転送先となるクライアント装置の処理を図９を用いて説明する。
図９はリクエストの転送先となるクライアント装置の代表クライアント判定部２０８の処理フローである。

リクエストの転送を他クライアント通信部２０９で受けたクライアント装置は、代表クライアント判定部２０８にそのリクエストを転送する。
リクエストの転送を受けた代表クライアント判定部２０８は、処理６０１で、分散ハッシュテーブルを用い、そのリクエストのＩＤを算出する。

処理６０２では、代表クライアント判定部２０８は、リクエストＩＤとそのクライアント装置自身に対する分散ハッシュテーブル上のＩＤおよび分散ハッシュテーブル自身を用いて、そのクライアント装置自身が、代表クライアント装置となるかを判定する。
そのクライアント装置自身が代表クライアント装置である場合には処理６０３、そのクライアント装置ではない他のクライアント装置が代表クライアント装置である場合には処理６０５に処理を分岐する。

処理６０３では、クライアント装置自身が処理中のリクエストに対する代表クライアント装置となるため、代表クライアント判定部２０８は、そのリクエストを代表クライアント処理部２１０に転送し、処理６０４で、代表クライアント処理部２１０からリクエストに対応するレスポンスが返信されるまで待機を行う。

その後、レスポンスが返信された場合には処理６０６に遷移し、代表クライアント判定部２０８は、リクエスト発行元のクライアント装置に向け分散ハッシュテーブルに従い、他クライアント通信部２０９を介して、他のクライアント装置にレスポンスを転送する。
ただし、この時にリクエスト発行元のクライアント装置のネットワークＩＤが既知である場合には、分散ハッシュテーブルに従うことなく、直接リクエスト発行元のクライアント装置にレスポンスを返信しても構わない。

処理６０５では、クライアント装置自身は処理中のリクエストに対する代表クライアント装置ではないため、代表クライアント判定部２０８は、分散ハッシュテーブルに従い、他のクライアント装置にレスポンスを転送する。
処理６０５でリクエストを他のクライアント装置に転送した際の、リクエストの転送先となるクライアント装置の処理は図９で説明した通りの処理が行われ、システム内でリクエストに対応する代表クライアント装置に到達するまで、クライアント装置を渡り歩く形で、再帰的に処理が繰り返される。

次に、代表クライアント処理部２１０の処理を図１０を用いて説明する。

リクエストを受けた代表クライアント処理部２１０は、処理７０１で、そのリクエストが安全であるかどうかを判定する。
リクエストが安全であるとは、そのリクエストをサーバ装置１０５が処理する事によってサーバ装置１０５の内部に変更が発生しない事を意味する。
例えば、ＨＴＴＰではＧＥＴメソッドを用いたリクエストは指定したリソースの取得を行うメソッドであり、安全なリクエストであると言える。
一方で、ＰＯＳＴやＰＵＴと言ったメソッドを用いたリクエストはサーバ装置１０５の内部に変更が発生する可能性があるため、安全でないリクエストとなる。
リクエストが安全である場合には処理７０２へ遷移し、安全でない場合には処理７０３に遷移する。

安全なリクエストの場合には、サーバ装置１０５に変更が発生しないため、もし代表クライアント装置となっているクライアント装置の内部に現在処理中のリクエストに対応するレスポンスが保存されている場合には、そのレスポンスを流用する事が出来る可能性がある。
そこで、処理７０２では、代表クライアント処理部２１０は、現在処理中のリクエストに対応するレスポンスが受信データ管理部２１１に保存されているかを判定する。
対応するレスポンスが受信データ管理部２１１に保存されている場合には処理７０６へ遷移し、保存されていない場合には処理７０３に遷移する。

処理７０６では、受信データ管理部２１１に対応するレスポンスが保存されている事が確認できている。
しかし、そのレスポンスを再利用して問題ないかの判定が行われていない状態である。そこで、レスポンスの有効期限が切れているか否かの判定を処理７０６で行う。
有効期限はＨＴＴＰであればレスポンスヘッダの中からＥｘｐｉｒｅｓレスポンスヘッダもしくはＣａｃｈｅ−Ｃｏｎｔｒｏｌレスポンスヘッダのｍａｘ−ａｇｅを用いて判定する事が可能である。
Ｅｘｐｉｒｅｓレスポンスヘッダにはそのレスポンスの有効期限が値として記述されている。
その有効期限が現在日時と比較して過去であればそのレスポンスの有効期限は切れていると判定可能である。
Ｃａｃｈｅ−Ｃｏｎｔｒｏｌレスポンスヘッダのｍａｘ−ａｇｅにはそのレスポンスをキャッシュして構わない時間が値として記述されている。
レスポンスの受信時刻にｍａｘ−ａｇｅの時間を加算した結果と現在日時を比較し、過去であればそのレスポンスの有効期限は切れていると判定可能である。

処理７０６で有効期限が切れていると判定された場合には処理７０３に遷移し、有効期限が切れていないと判定された場合には処理７０７に遷移する。
なお、有効期限が切れていると判定された場合には、代表クライアント処理部２１０は、受信データ管理部２１１に対してリクエストに対応するエントリーを削除させても構わない。
なお、データの有効期限が存在しない場合、全てのレスポンスは変更されない場合、もしくは全てのレスポンスは常に更新されており、流用する事が出来ない様な場合には、処理７０６の処理はなくても構わない。
その場合、例えば全てのレスポンスが変更されない場合には、処理７０６への処理遷移は処理７０７への処理遷移に置き換えられる。
また、全てのレスポンスが常に更新されている場合には、処理７０６への処理遷移は処理７０３への処理遷移に置き換えられる。

処理７０７は、現在処理中のリクエストが安全でかつ有効期限が切れていない事が確認できている状態で処理が行われる。
この処理では、代表クライアント処理部２１０は、現在処理中のリクエストに対応するレスポンスを受信データ管理部２１１から取得する。
取得完了後に処理７０８に遷移する。

処理７０３は、現在処理中のリクエストに対応するレスポンスが代表クライアント装置であるクライアント装置が保持していたとしても、再利用する事が出来ない事が確認できている状態で行われる。
この処理では現在処理中のリクエストをサーバ通信部２１２を介して、サーバ装置１０５に発行する処理を行う。
リクエスト発行完了後、処理７０４に遷移する。

処理７０４は、発行したリクエストに対応するサーバからのレスポンスが返信されているまで待機する処理である。
レスポンスがサーバ装置１０５から返信された事をトリガーとして処理７０５に遷移する。

処理７０５では、サーバ装置１０５から受信したレスポンスが対応するリクエストが安全である場合には、代表クライアント処理部２１０は、そのレスポンスとそのリクエストを関連付けて受信データ管理部２１１に保存する。
受信データ管理部２１１ではリクエストとそのレスポンスを対応づけて保存しているため、処理７０２でリクエストをキーとしてレスポンスを存在するか確認する事が可能となっている。
保存完了後、処理７０８に遷移する。

処理７０８では、代表クライアント処理部２１０は、サーバ装置１０５もしくは受信データ管理部２１１から取得したレスポンスが対応するリクエストの発行元となるクライアント装置が自身であるか判定する。
判定の結果、リクエストの発行元がクライアント装置自身である場合には処理７０９に遷移し、代表クライアント判定部２０８にレスポンスを返信する。
リクエストの発行元がクライアント装置自身ではない場合には処理７１０に遷移し、代表クライアント処理部２１０は、リクエスト発行元のクライアント装置に向け分散ハッシュテーブルに従い、他クライアント通信部２０９を介して、他クライアント装置にレスポンスを転送する。

図１１に受信データ管理部２１１でのリクエストとレスポンスの保存の具体例を示す。
この例では、ＨＴＴＰに従ったリクエストとレスポンスを想定している。
リクエストではＨＴＴＰのリクエストのスタートライン、ヘッダ、ボディをリクエストとして保存し、対応するレスポンスに関しても同様にＨＴＴＰのレスポンスのスタートライン、ヘッダ、ボディを保存する。
この例では、同じ行のリクエストとレスポンスが対応づけられているとして表現している。
つまり、あるリクエストをキーとしてレスポンスを検索する場合、まずリクエスト列にキーとなるリクエストに合致するリクエストが存在するか検索し、あった場合にはそのリクエストと同じ行のレスポンスが検索すべきレスポンスとなる。
また、キーとなるリクエストとリクエスト列のリクエストを比較する場合にスタートライン、ヘッダ、ボディ全てが完全一致した場合、そのリクエスト同士は同一であるとする。
しかし、簡略化のためスタートライン中のＵＲＩのみの比較で行う事も可能である。

＊＊＊効果の説明＊＊＊
以上までで説明した本実施の形態におけるクライアント処理を行う事によって、複数のクライアント装置で同一のリクエストをサーバ装置１０５に発行する必要がある状況において、複数のクライアント装置の全てが同一のリクエストを独立に発行することなく、そのリクエストに対応する代表クライアント装置を一意に決定し、その代表クライアント装置のみがサーバ装置１０５に対してリクエストを発行する事が可能となる。
この時、リクエスト発行を代表クライアント装置のみに決定する処理にサーバ装置１０５が関与していない事が重要であり、代表クライアント装置を決めるための処理負荷がサーバ装置１０５の新たな負荷として発生しない事が一つの効果である。

また、代表クライアント装置を決定するに当たり、分散ハッシュテーブルを用い、公平な代表クライアント装置の決定アルゴリズムを実現する事が可能となっているため、クライアント装置がクライアント・サーバシステムへ参加したタイミングによって多くのリクエストに対する代表クライアント装置が一つのクライアント装置に偏って決定される不公平が理論上発生しない点ももう一つの効果である。
参加したタイミングによって代表クライアント装置が偏る不公平が発生する一つの理由として、リクエストを発行する前にクライアント装置間でリクエストに対応するレスポンスを保持しているクライアント装置の検索を行い、保持するクライアント装置がいない場合には、リクエストを発行するクライアント装置が代表クライアント装置となる方式が、考えられる。
この方式では、システムに最初に参加したクライアント装置の参加時刻とその次に参加したクライアント装置の参加時刻との間の時間幅が大きい場合、最初に参加したクライアント装置が多くのリクエストをサーバ装置１０５に出す事になり、必然的に最初に参加したクライアント装置が多くのリクエストの代表クライアント装置に決定されやすくなる。
しかし、分散ハッシュテーブルを用いた本実施の形態による方式では、同様の状況であっても、２番目に参加したクライアント装置が発生すると、分散ハッシュテーブルの機能を利用して、代表クライアント装置の再配分が行われる事になる。
そのため、最初に参加したクライアント装置に多くのリクエストに対応する代表クライアント装置が決定していたとしても、２番目のクライアント装置が参加する事によって、代表クライアント装置の受け持ち数を平準化させる事が可能となる。
このような効果を得るために用いられる具体的な分散ハッシュテーブルのアルゴリズムの一つとしてＣｈｏｒｄなどがあげられる。
Ｃｈｏｒｄはネットワークに参加するクライアント装置が動的に増減しても、分散ハッシュテーブルの維持・管理が可能である。

実施の形態２．
以下では、実施の形態１に示したシステム構成において分散ハッシュテーブルとしてＣｈｏｒｄを用いた場合の具体例を説明する。
本実施の形態では、通信システム１０００に新たなクライアント装置が参入する際の代表クライアントロールの引き継ぎ動作と、通信システム１０００からクライアント装置が離脱する際の代表クライアントロールの引き継ぎ動作を説明する。

＊＊＊構成の説明＊＊＊
本実施の形態に係るサーバ装置１０５の構成例は、図２に示す通りであり、また、本実施の形態に係る各クライアント装置の構成例は、図３に示す通りである。
本実施の形態では、主に実施の形態１との差異を説明する。
本実施の形態で説明していない事項は、実施の形態１と同様である。

新たなクライアント装置が通信システム１０００に参加する際には、新たなクライアント装置に代表クライアントロールを引き継ぐクライアント装置では、他クライアント通信部２０９が以下のように動作する。
新たなクライアント装置に割り当てられる代表クライアントロールが対象とするリクエストに対応するレスポンスが受信データ管理部２１１にキャッシュされている場合に、他クライアント通信部２０９は、受信データ管理部２１１にキャッシュされているレスポンスを、新たなクライアント装置に送信する。
新たなクライアント装置は、送信されたレスポンスを記憶する。

また、通信システム１０００からクライアント装置が離脱する際には、残留するクライアント装置では、他クライアント通信部２０９が以下のように動作する。
通信システムから離脱する離脱クライアント装置に割り当てられている代表クライアントロールが対象とするリクエストに対応するレスポンスが離脱クライアント装置にキャッシュされている場合に、他クライアント通信部２０９は、キャッシュされているレスポンスを離脱クライアント装置から受信する。
そして、残留するクライアント装置では、離脱クライアント装置から受信したレスポンスを受信データ管理部２１１で保存する。

＊＊＊動作の説明＊＊＊
次に、本実施の形態に係るクライアント装置の動作例を図１２及び図１３を参照して説明する。

図１２は、Ｃｈｏｒｄを用いた本システムでのクライアント装置とリクエストとで構成する仮想空間を示す。
Ｃｈｏｒｄでは、ノードとキーが同一の仮想空間上に配置される。
ノードとは実施の形態１のクライアント装置に対応し、キーとは実施の形態１のリクエストに対応する。
つまり、図１２のノード９０２、９０３、９０４、９０５は、通信システム１０００に参加しているクライアント装置１０１、１０２、１０３、１０４のいずれかに相当する。
ノードとキーの仮想空間上の配置の決定はハッシュ関数を用い、それぞれにＩＤを割り振り、そのＩＤの位置に配置する。
図１２は、複数のノードとキーが仮想空間上に配置されている一例を図示している。
仮想空間９０１上にノード９０２、９０３、９０４、９０５とキー９０６、９０７、９０８、９０９、９１０、９１１、９１２がハッシュ関数によってそれぞれ求められたＩＤの位置に配置されている。
Ｃｈｏｒｄではキーおよびそのキーに対応するデータの管理はノードが行う。
どのノードがどのキーおよびそのキーに対応するデータを管理するかの決定方法は以下の通りである。
あるノードとそのノードが仮想空間上で右回りで隣接するノードとの間に存在するキーおよびそのキーに対応するデータをそのノードが管理する。
例えば、ノード９０３は右回りで隣接するノード９０２の間にはキー９０６、９０７が存在する。
よって、ノード９０３はキー９０６、９０７およびそれらに対応するデータの管理を行う。
同様に、ノード９０４はキー９０８、９０９、９１０およびそれらに対応するデータの管理を行う。

図１２に基づいて、本実施の形態における代表クライアント装置とリクエストとの関係を説明する。
前述の通り、ノードはクライアント装置、キーはリクエストに対応する。
Ｃｈｏｒｄでは、キーおよびキーに対応するデータの管理をノードで行うが、そのキーに対応するデータとして、本実施の形態では少なくとも以下のものが対応する。
・リクエストによって取得されるレスポンス
・リクエストの発行元のクライアント装置のリスト
よってノード９０４に対応するクライアント装置はキー９０８、９０９、９１０に対応するリクエストの代表クライアント装置である事を意味する。
そのため、ノード９０４以外のノードに対応するクライアント装置が例えばキー９０８に対応するリクエストのレスポンスを取得するためには、そのリクエストをノード９０４に対応するクライアント装置に転送し、ノード９０４に対応するクライアント装置からレスポンスを入手する。

次に、図１３を用いて新規にクライアント装置が通信システム１０００に参加した場合の挙動を説明する。

図１３は、図１２の状態の仮想空間に対してノード１００１に対応するクライアント装置が新規に参加した状況を示す。
この場合は、ノード１００１に対応するクライアント装置はキー９０６に対応するリクエストの代表クライアント装置とならなければならない。
Ｃｈｏｒｄでは新規参加ノードが仮想空間に参加した場合、新規参加ノードの前後のノードと通信を行い、状態更新を行う。
その際に、新規参加ノードに対応するクライアント装置は、代表クライアント装置を担当すべきリクエストおよびその関連データ（レスポンス、リクエスト発行元のクライアント装置のリスト）を参加前の代表クライアント装置から受け取る。
ノード１００１に対応するクライアント装置の参加前の代表クライアント装置は、ノード９０３に対応するクライアント装置である。
このため、ノード１００１に対応するクライアント装置は、ノード９０３に対応するクライアント装置からキー９０６に対応するリクエストおよび関連データを引継ぐ必要がある。
この時、引継ぎ元のクライアント装置からリクエストおよび関連データを引き継ぎ先のクライアント装置に引継ぐ際、引継ぎ元のクライアント装置がレスポンスをサーバ装置１０５から受信中の場合には、受信完了を待ってから引継ぎ処理を開始する。
受信完了を待つ事によって、不完全なレスポンスが引継がれる事を回避できる。

次に、図１３の状態からノード１００１に対応するクライアント装置が通信システム１０００から離脱した場合の挙動を例にクライアント装置の離脱時の処理を説明する。
なお、この離脱が完了すると図１２の状態に戻る事を意味する。

ノード１００１に対応するクライアント装置が離脱した場合、そのクライアント装置が代表クライアント装置を担当していたキー９０６に対応するリクエストの代表クライアントを引き続きシステムに残るクライアント装置に引継ぐ必要がある。
Ｃｈｏｒｄを用いた場合には、代表クライアントを引継ぐクライアント装置はノード９０３に対応するクライアント装置となる。
そこで、ノード１００１に対応するクライアントは、離脱する前に、自身が代表クライアント装置を担当するリクエストおよび関連データをノード９０３に対応するクライアント装置に引継ぐ。
この時、新規参加と同様にサーバ装置１０５からレスポンスを受信している場合は、レスポンスの受信完了を待ってからノード９０３に対応するクライアント装置に引継ぐ。

＊＊＊効果の説明＊＊＊
本実施の形態によれば、システムに対するクライアント装置の参加、離脱が発生した場合であっても、適切な代表クライアント装置の引継ぎが可能となる。

実施の形態３．
本実施の形態では、通信システム１０００からのクライアント装置の離脱に関する手順を更に説明する。

あるクライアント装置のシステム離脱は大きく分けて、クライアント装置として計画した離脱と、主に不正処理による強制終了などを要因とした計画していない離脱に分けられる。
計画した離脱の場合には実施の形態２に前述した通りの手順にて分散ハッシュテーブルを用いる事で代表クライアントロールの引継ぎが適切に行えるが、計画していない離脱の場合には、代表クライアントロールの引継ぎを前述の手順で行えない。
本実施の形態では、計画していないクライアント装置の離脱に対応する手順を説明する。

＊＊＊構成の説明＊＊＊
本実施の形態に係るサーバ装置１０５の構成例は、図２に示す通りであり、また、本実施の形態に係る各クライアント装置の構成例は、図３に示す通りである。
本実施の形態では、主に実施の形態１、２との差異を説明する。
本実施の形態で説明していない事項は、実施の形態１、２と同様である。

本実施の形態では、代表クライアント処理部２１０が、自装置が通信システム１０００から離脱した後に自装置に代わって動作する予備代表クライアント装置（以下、単に予備代表クライアントともいう）を他のクライアント装置の中から選択し、サーバ装置１０５に送信するリクエストに予備代表クライアント装置の識別子を追加する。
そして、サーバ通信部２１２は、代表クライアント処理部２１０により予備代表クライアント装置の識別子が追加されたリクエストをサーバ装置１０５に送信する。
サーバ装置１０５では、通信部２１３が、リクエスト発行元のクライアント装置にレスポンスを送信できない場合に、予備代表クライアント装置にレスポンスを送信する。

＊＊＊動作の説明＊＊＊
次に、本実施の形態に係る代表クライアント処理部２１０の動作例を図１４を用いて説明する。
図１４は、図１０で示した代表クライアント処理部２１０の処理を拡張した処理フロー図であり、図１０に対して処理１１０１、１１０２が追加されている。
以下では、追加処理に関連する部分のみを説明する。

処理１１０１は、代表クライアント装置として、サーバ装置１０５にリクエストを送信する事が決定した時に最初に処理される処理である。
そのため、処理７０２でレスポンスが受信データ管理部２１１に保存されていない事が判明した場合、および処理７０６で受信データ管理部２１１に保存される対応するレスポンスの有効期限が切れている事が判明した場合に、処理１１０１に遷移する。

処理１１０１では、この処理を行っているクライアント装置が処理７０４でサーバ装置１０５からのレスポンスの返信待機中に計画していない離脱を余儀なくされた場合に、処理中の代表クライアントの処理を引継ぐクライアント装置である予備代表クライアント装置の探索を行う。
具体的にはその時点の分散ハッシュテーブルにて、代表クライアント装置が離脱した場合に、その代表クライアント装置が担当する全てのリクエスト及びレスポンスの処理を引継ぐクライアント装置を予備代表クライアント装置として決定する。
分散ハッシュテーブルとしてＣｈｏｒｄを用いている場合であれば、その代表クライアントの時計回りに隣接するノードに対応するクライアント装置となる。

次に、処理１１０２では、代表クライアント処理部２１０が、処理１１０１で決定した予備代表クライアントの情報をリクエストに結合する。

図１５は予備代表クライアントの情報をＨＴＴＰリクエストに結合した一つの例である。
図１５では、予備代表クライアントの情報をＨＴＴＰＨｅａｄｅｒとして結合している。
具体的にはＸ−Ｒｅｐｒｅｓｅｎｔａｔｉｖｅ−Ｃｌｉｅｎｔ−ＡｄｄｒｅｓｓヘッダとＸ−Ｒｅｑｕｅｓｔｏｒ−Ｃｌｉｅｎｔ−Ａｄｄｒｅｓｓｅｓ−Ｌｉｓｔヘッダである。
Ｘ−Ｒｅｐｒｅｓｅｎｔａｔｉｖｅ−Ｃｌｉｅｎｔ−Ａｄｄｒｅｓｓヘッダには予備代表クライアントのネットワークＩＤを値として設定し、Ｘ−Ｒｅｑｕｅｓｔｏｒ−Ｃｌｉｅｎｔ−Ａｄｄｒｅｓｓｅｓ−Ｌｉｓｔヘッダにはこのリクエストのリクエスト元のクライアントのネットワークＩＤのリストを値として設定している。
なお、ヘッダ名は一つの例であり、ヘッダ名が異なる場合であっても、本質的な違いはない。

また、図１６は予備代表クライアントの情報をＨＴＴＰリクエストに結合したもう一つの例である。
図１６では、予備代表クライアントの情報をＨＴＴＰＲｅｑｕｅｓｔＢｏｄｙとして結合している。
具体的には予備代表クライアントの情報をＪＳＯＮ形式で表現しており、Ｒｅｐｒｅｓｅｎｔａｔｉｖｅプロパティに予備代表クライアントのネットワークＩＤを値として設定し、Ｒｅｑｕｅｓｔｏｒｓプロパティにこのリクエストのリクエスト元のクライアントのネットワークＩＤのリストを値として設定している。
なお、予備代表クライアントは唯一とする必要はなく、予備代表クライアントも離脱している場合を想定して、その先の予備代表クライアントも含めて複数の予備代表クライアントをサーバ装置１０５に送信するとしても構わない。
その場合には、予備代表クライアントのネットワークＩＤはリストとしてサーバ装置１０５に送信される事になる。

次に、図１７を用いて予備代表クライアントの情報を用いたサーバ処理を説明する。
なお、説明を簡単化するため本サーバの処理フローはシングルスレッドで動作する事を前提としているが、マルチスレッドでの動作で動作するサーバでも構わない。

処理１４０１で、サーバ装置１０５はクライアント装置からリクエストが送信されるのを待機する。
クライアント装置からリクエストが送信されてくると処理１４０２に遷移する。

処理１４０２では、通信部２１３が、送信されてきたリクエストを受信し、メモリ上に展開する。

処理１４０３では、要求処理部２１４が、メモリ上に展開したリクエストを解析し、内容を解釈可能な状態にする。

処理１４０４で、要求処理部２１４が、そのリクエストに記述されている内容に従った処理を実施する。
その処理内容についてはリクエストに依存するため、ここでは言及しない。

処理１４０５では、要求処理部２１４が、処理１４０４で処理した結果、クライアントに通知すべき内容をレスポンスとして生成する。

処理１４０６では、通信部２１３が、処理１４０５で生成したレスポンスをリクエストを送信してきたクライアント装置に送信する。

処理１４０７では、要求処理部２１４が、処理１４０６での送信処理が正常に完了したかを判定し、正常に完了した場合には処理１４０１に遷移し、他のクライアント装置からのリクエスト送信に備えて待機を行う。
逆に正常に完了しなかった場合は、処理１４０８に遷移する。

処理１４０８では、クライアント装置に正常にレスポンスを返信できなかったため、サーバ装置１０５では、要求処理部２１４が、処理１４０３でリクエストを解析した結果から未処理の予備代表クライアントの情報のうちの一つの取得を試みる。

処理１４０９では、要求処理部２１４が、処理１４０８の結果、未処理である予備代表クライアントの情報の取得に成功したかを判定する。
取得に成功した場合には処理１４１０に遷移し、失敗した場合には、これ以上予備代表クライアントの情報はないため、今回の処理はエラー終了として結果を破棄し処理１４０１に遷移する。

処理１４１０では、通信部２１３が、処理１４０８で取得した未処理である予備代表クライアントの情報に記載されている予備代表クライアントのネットワークＩＤを取得し、そのネットワークＩＤの相手に対してレスポンスの送信を試みる。
ここでの送信ではＨＴＴＰの様にクライアントからのリクエストを起点とするプロトコルは用いる事ができないため、例えばＷｅｂＳｏｃｋｅｔやＳｅｒｖｅｒ−ＳｅｎｔＥｖｅｎｔｓなどのサーバを起点とする事が可能なプロトコルを用いる。

処理１４１１では、要求処理部２１４が、処理１４１０での送信処理が正常に完了したかを判定し、正常に完了した場合には処理１４０１に遷移し、他のクライアント装置からのリクエスト送信に備えて待機を行う。
逆に正常に完了しなかった場合は、処理１４０８に遷移し、残る未処理である予備代表クライアントの情報を用いた送信処理を繰り返す。

＊＊＊効果の説明＊＊＊
本実施の形態によれば、代表クライアント装置に計画外の離脱が発生した場合であっても、予備代表クライアント装置により、リクエスト発行元に確実にレスポンスを返すことができる。

実施の形態４．
クライアント・サーバシステムにおいて、サーバ装置はクライアント装置の要求に必ず即時にレスポンスを返信するとは限らない。
例えば、要求に対応するサーバ処理に非常に時間がかかる場合、サーバ装置の都合に応じてレスポンスの返信タイミングが遅延する場合が想定され、その場合には時間をおいてクライアント装置にレスポンスが返信される事になる。
複数のクライアント装置から同一のリクエストが発生している状況でサーバ装置からのレスポンスが遅延した場合に、マルチキャスト配信ができないシステムでは、そのリクエストの代表クライアント装置はレスポンスの受信後に、全てのリクエスト発行元のクライアント装置に順次レスポンスを返信しなければならない。
このような場合は、代表クライアント装置の返信負荷が一時期に集中してしまう。
また、最初にレスポンスが返信されるリクエスト発行元のクライアント装置と最後にレスポンスが返信されるリクエスト発行元のクライアント装置では、レスポンスを受信するタイミングに差異が生じる。
リクエスト発行元のクライアント装置が多いほど、この差異は大きくなる。
本実施の形態は、これらの事情に鑑みたものである。

本実施の形態では、代表クライアント処理部２１０は、２以上のクライアント装置で生成された同一のリクエストが取得リクエストとして取得され、当該取得リクエストについての代表クライアントロールが自装置に割り当てられている場合に、リクエスト生成元の２以上のクライアント装置のうちのいずれかのクライアント装置を、自装置と協働する代表クライアントクローン装置（以下、単に代表クライアントクローンともいう）に指定する。
より具体的には、代表クライアント処理部２１０は、取得リクエストのリクエスト生成元のクライアント装置の個数が閾値を超える場合に、代表クライアントクローン装置を指定する。
他クライアント通信部２０９は、代表クライアントクローン装置に指定されたクライアント装置に対して、代表クライアントクローン装置に指定された旨を通知するとともに、前記２以上のクライアント装置のうち代表クライアントクローン装置に指定されなかったクライアント装置をレスポンスの送信先として通知する通知メッセージを送信する。
また、他クライアント通信部２０９は、取得リクエストに対応するレスポンスを、代表クライアントクローン装置に送信し、代表クライアントクローン装置から、通知メッセージで通知した送信先のクライアント装置にレスポンスを送信させる。
他クライアント通信部２０９は、代表クライアントクローン装置がレスポンスを送信するクライアント装置には、レスポンスを送信しない。

また、代表クライアントクローン装置に指定されたクライアント装置では、他クライアント通信部２０９が、他のクライアント装置から通知メッセージを受信する。
通知メッセージでは、前述のように、代表クライアントクローン装置に指定された旨が通知されるとともに、レスポンスの送信先のクライアント装置が通知される。
他クライアント通信部２０９は、通知メッセージを受信した後に、他のクライアント装置からレスポンスを受信した場合に、受信したレスポンスを、通知メッセージで通知された送信先のクライアント装置に送信する。

また、代表クライアントクローン装置に指定されたクライアント装置では、代表クライアント処理部２１０は、通知メッセージで通知された送信先のクライアント装置の個数が２以上であり、当該個数が閾値以上である場合に、２以上のクライアント装置のうちのいずれかのクライアント装置を、新たな代表クライアントクローン装置に指定する。
そして、他クライアント通信部２０９が、新たな代表クライアントクローン装置に指定されたクライアント装置に対して、代表クライアントクローン装置に指定された旨を通知するとともに、２以上のクライアント装置のうち新たな代表クライアントクローン装置に指定されなかったクライアント装置をレスポンスの送信先として通知する通知メッセージを送信する。
そして、他クライアント通信部２０９は、他のクライアント装置からレスポンスを受信した場合に、受信したレスポンスを、新たな代表クライアントクローン装置に送信し、新たな代表クライアントクローン装置から、新たな代表クライアントクローン装置への通知メッセージで通知した送信先のクライアント装置にレスポンスを送信させる。
他クライアント通信部２０９は、新たな代表クライアントクローン装置がレスポンスを送信するクライアント装置には、レスポンスを送信しない。

＊＊＊動作の説明＊＊＊
図２２〜図２８を用いて、本実施の形態に係るクライアント装置の動作の概略を説明する。
図２２〜図２８において、あるリクエストに対する代表クライアント装置をクライアント０とし、代表クライアント装置を丸図形で表現する。
また、図２２〜図２８では、代表クライアント装置に対するリクエストの発行元となるクライアント装置は正方形で表現する。
また、図２２〜図２８では、代表クライアントクローン装置となるクライアント装置は六角形で表現する。
また、図２２〜図２８において、番号０〜７は、クライアント装置のＩＤ番号である。
また、代表クライアントおよび代表クライアントクローンがレスポンスを返信する担当となるクライアントの図形に対しては矢印が伸びる事で表現する。
例えば、図２２は、代表クライアント０はリクエスト発行元クライアント１にレスポンスを返信する担当である事を意味する。

以下では、代表クライアントクローンを指定するための閾値をＮ＝３として説明を進める。
つまり、同一のリクエストが３つのクライアントで発行された場合には、代表クライアント装置の代表クライアント処理部２１０は、当該３つのクライアントの中から代表クライアントクローンを指定する。
同様に、代表クライアントクローンの代表クライアント処理部２１０は、代表クライアントから、３つのクライアントへのレスポンスの送信が要求された場合に、当該３つのクライアントの中から新たな代表クライアントクローンを指定する。

図２２に示す通り、最初にクライアント１がリクエストを発行した際には、代表クライアント０がリクエストの処理を担当する。
次に、クライアント２がリクエストを発行した際にも同様に代表クライアント０がリクエストの処理を担当し、図２３の通りとなる。
次に、クライアント３がリクエストを発行した際は、閾値Ｎ＝３に達するため、代表クライアント０の代表クライアント処理部２１０は、例えばクライアント１をクライアント３に対する代表クライアントクローンに指定する。
そして、代表クライアント０の他クライアント通信部２０９が、クライアント１に通知メッセージ（以下、代表クライアントクローン要求という）を送信する。
代表クライアントクローン要求では、クライアント１が代表クライアントクローンに指定された旨と、クライアント３にレスポンスを送信する旨が通知される。
この結果、図２４の通り、クライアント１がクライアント３を担当する代表クライアントクローンとなる。

次に、クライアント４がリクエストを発行した際は、閾値Ｎ＝３に達しているので、代表クライアント０の代表クライアント処理部２１０は、例えばクライアント２をクライアント４に対する代表クライアントクローンに指定する。
そして、代表クライアント０の他クライアント通信部２０９が、クライアント２に代表クライアントクローン要求を送信する。
この代表クライアントクローン要求では、クライアント２が代表クライアントクローンに指定された旨と、クライアント４にレスポンスを送信する旨が通知される。
この結果、図２５の通り、クライアント２がクライアント４を担当する代表クライアントクローンとなる。

次に、クライアント５がリクエストを発行した際は、閾値Ｎ＝３に達しているので、代表クライアント０の代表クライアント処理部２１０は、例えばクライアント１をクライアント５に対する代表クライアントクローンに指定する。
そして、代表クライアント０の他クライアント通信部２０９が、クライアント１に代表クライアントクローン要求を送信する。
この代表クライアントクローン要求では、クライアント１が代表クライアントクローンに指定された旨と、クライアント５にレスポンスを送信する旨が通知される。
この結果、図２６の通り、クライアント１がクライアント３とクライアント５を担当する代表クライアントクローンとなる。

次に、クライアント６がリクエストを発行した際は、閾値Ｎ＝３に達しているので、代表クライアント０の代表クライアント処理部２１０は、例えばクライアント２をクライアント６に対する代表クライアントクローンに指定する。
そして、代表クライアント０の他クライアント通信部２０９が、クライアント２に代表クライアントクローン要求を送信する。
この代表クライアントクローン要求では、クライアント２が代表クライアントクローンに指定された旨と、クライアント６にレスポンスを送信する旨が通知される。
この結果、図２７の通り、クライアント２がクライアント４とクライアント６を担当する代表クライアントクローンとなる。

次に、クライアント７がリクエストを発行した際は、閾値Ｎ＝３に達しているので、代表クライアント０の代表クライアント処理部２１０は、例えばクライアント１をクライアント７に対する代表クライアントクローンに指定する。
そして、代表クライアント０の他クライアント通信部２０９が、クライアント１に代表クライアントクローン要求を送信する。
しかし、代表クライアントクローン１でも閾値Ｎ＝３に達する。
このため、代表クライアントクローン１の代表クライアント処理部２１０は、例えば、クライアント３をクライアント７に対する代表クライアントクローンとして新たに指定する。
そして、代表クライアントクローン１の他クライアント通信部２０９が、クライアント３に代表クライアントクローン要求を送信する。
この代表クライアントクローン要求では、クライアント３が代表クライアントクローンに指定された旨と、クライアント７にレスポンスを送信する旨が通知される。
この結果、図２７の通り、クライアント３がクライアント７を担当する新たな代表クライアントクローンとなる。

次に、図１８、図１９、図２０を用いて本実施の形態における代表クライアント処理部２１０の処理フローを説明する。
図１８、図１９、図２０は、図１０で示した代表クライアント処理部２１０の処理フローを拡張した処理フローであり、図１０に対して処理１５０１〜１５０９の処理が追加されている。
以下では、追加処理に関連する部分のみを説明する。

また、本実施の形態では、代表クライアント処理部２１０はリクエストと、そのリクエスト発行元のリストを管理する。
図２１にリクエストとリクエスト発行元のリスト管理の一例を示す。

図２１に示すリストでは、リクエスト一つに対して複数のリクエスト発行元の情報を管理する事が可能となっている。
リクエスト発行元の情報には、少なくともリクエスト発行元のネットワークＩＤなどの対応するレスポンスを各リクエスト発行元に通信にて転送する事が可能な情報が含まれている。
この例では、「ＧＥＴｈｔｔｐ：／／ｘｘｘ／ａｐｉ／ｍｏｎｉｔｏｒ＿ｉｎｔｅｒｖａｌ／」リクエストに対してリクエスト発行元は「１９２．１６８．０．１」、「１９２．１６８．０．２」、「１９２．１６８．０．３」の合計３個が登録されている。
また、「ＧＥＴｈｔｔｐ：／／ｘｘｘ／ｈｔｍｌ／Ｍｏｎｉｔｏｒ．ｈｔｍｌ」リクエストに対してリクエスト発行元は「１９２．１６８．０．５」、「１９２．１６８．０．２」、「１９２．１６８．０．６」、「１９２．１６８．０．８」の合計４個が登録されている。

図１８に戻り、代表クライアント処理部２１０は、処理１５０１によって、転送されたリクエストに対応するレスポンスを取得出来るのを待機している他のクライアントが存在するかを確認する。
例えば確認はリクエストとリクエスト発行元のリストで現在処理中のリストが存在する場合には、他のクライアントが存在すると確認可能である。
他のクライアントが存在しない場合には処理７０１に遷移し、存在する場合には処理１５０２に遷移する。

処理７０１にてリクエストが安全でない場合には処理７０３ではなく処理１５０７に遷移する処理が異なっている。
同様に、処理７０２で保存されていない場合の遷移先が処理７０３ではなく処理１５０７に変更されている。
なお、処理７０１で行っているリクエストが安全でない場合の処理については、リクエストの発行元となるクライアントがリクエストを処理する際に判定し、安全でない場合には、本処理を実施せず、リクエスト発行元のクライアントが直接サーバにリクエストを発行するとしても構わない。
その様な挙動にする事によって、リクエストの転送分の通信処理を削減可能である。

処理１５０７では、代表クライアント処理部２１０は、現在処理中のリクエストに対応するエントリーがリクエストとリクエスト発行元のリスト（図２１）に存在していないため、そのエントリーを作成し、そのエントリーのリクエスト発行元として現在処理中のリクエスト発行元を登録する。
登録完了後、処理７０３に遷移する。

また、処理７０５および処理７０７の遷移先が処理７０８から処理１５０８に変更となっている。
処理１５０８では、代表クライアント処理部２１０は、処理中のリクエストに対応するレスポンスの転送先となる未処理のリクエスト発行元クライアントがリクエスト発行元のリスト（図２１）に存在するかを判定する。
存在しない場合には処理を完了し、存在する場合には処理１５０９に遷移し、代表クライアント処理部２１０は、その未処理リクエスト発行元を取得して、処理７０８に遷移する。
その後の処理として処理７０９および処理７１０の遷移先が終了ではなく、処理１５０８となり、全ての未処理のリクエスト発行元に対してレスポンスを返信するまで処理を繰り返す。

処理１５０２では、現在処理中のリクエストに対するリクエスト発行元が存在している状態であり、代表クライアント処理部２１０は、リクエストとリクエスト発行元のリスト（図２１）のそのリクエストに対応するエントリーのリクエスト発行元に現在処理中のリクエスト発行元を追加登録する。

処理１５０３では、代表クライアント処理部２１０は、同一リクエストに対するリクエスト発行元の個数が閾値となるＮ個以上あるかを判定する。
その判定の結果、Ｎ個未満である場合には処理を終了する。
一方で、Ｎ個以上存在する場合には処理１５０４に遷移する。
なお、閾値Ｎは固定値として与えてもよいし、ネットワークやクライアントの処理負荷状況などを考慮して動的に変更される値として与えてもよいが、（Ｎ−１）は単一の代表クライアントがある単一のリクエストに対するレスポンスをそのリクエスト発行元となるクライアントに転送する処理の繰返し最大回数を意味する。

処理１５０４では、代表クライアント処理部２１０は、現在処理中のリクエストに対する全てのリクエスト発行元の中から代表クライアントクローンを決定する。
この時に代表クライアントクローンを唯一に決めてもよいし、複数個決めても構わない。
ただし、複数個に決めた場合、処理１５０５および処理１５０６はその個数分だけ繰り返される事になる。

処理１５０５では、代表クライアント処理部２１０は、処理１５０４で決定した各代表クライアントクローンがレスポンスの転送を担当するリクエスト発行元クライアントを決定する。

処理１５０６では、他クライアント通信部２０９が、処理１５０５で決定した担当するリクエスト発行元クライアントに関する情報とリクエスト情報を持たせた代表クライアントクローン要求を代表クライアントクローンに対して送付し、処理を完了する。

次に、図２９及び図３０を用いて代表クライアントクローン要求を受信した際の代表クライアント処理部２１０の処理フローを説明する。

処理２４０１では、代表クライアント処理部２１０は、代表クライアントクローン要求から代表クライアントクローンになる事を要求されている対応するリクエストの情報を取得する。

処理２４０２では、代表クライアント処理部２１０は、処理２４０１で取得したリクエストに対応するエントリーがリクエストとリクエスト発行元のリスト（図２１）に存在するかを判定する。
エントリーが存在した場合には処理２４０４、存在しない場合には処理２４０３に遷移する。

処理２４０３では、代表クライアント処理部２１０は、リクエストとリクエスト発行元のリスト（図２１）に現在処理中のリクエストに対応するエントリーを新規作成し、処理２４０４に遷移する。

処理２４０４では、代表クライアント処理部２１０は、リクエストとリクエスト発行元のリスト（図２１）の現在処理中のリクエストに対応するエントリーに代表クライアントクローン要求に記載されている担当するリクエスト発行元クライアントに関する情報に記載の全てのリクエスト発行元を追加する。

処理２４０５では、代表クライアント処理部２１０は、同一リクエストに対するリクエスト発行元の個数が閾値となるＮ個以上あるかを判定する。
その判定の結果、Ｎ個未満である場合には処理２４０９に遷移する。
一方で、Ｎ個以上存在する場合には処理２４０６に遷移する。
なお、閾値Ｎは固定値として与えてもよいし、ネットワークやクライアントの処理負荷状況などを考慮して動的に変更される値として与えてもよいが、（Ｎ−１）は単一の代表クライアントクローンがある単一のリクエストに対するレスポンスをそのリクエスト発行元となるクライアントに転送する処理の繰返し最大回数を意味する。

処理２４０６では、代表クライアント処理部２１０は、現在処理中のリクエストに対する全てのリクエスト発行元の中から代表クライアントクローンを決定する。
この時に代表クライアントクローンを唯一に決めてもよいし、複数個決めても構わない。
ただし、複数個に決めた場合、処理２４０７および処理２４０８はその個数分だけ繰り返される事になる。

処理２４０７では、代表クライアント処理部２１０は、処理２４０６で決定した各代表クライアントクローンがレスポンスの返信を担当するリクエスト発行元クライアントを決定する。

処理２４０８では、他クライアント通信部２０９は、処理２４０７で決定した担当するリクエスト発行元に関する情報とリクエスト情報を持たせた代表クライアントクローン要求を代表クライアントクローンに対して送付し、処理２４０９に遷移する。

処理２４０９では、代表クライアントもしくは他の代表クライアントクローンから処理中のリクエストに対応するレスポンスが送信されるまで待機する。
処理中のリクエストに対応するレスポンスが送信されてきた場合には処理１５０８に遷移する。
それ以降の処理は図１８、図１９、図２０を用いて説明した処理と同一であるため、説明は省略する。

＊＊＊効果の説明＊＊＊
以上の処理を行う事で、単一リクエストに対して多数のリクエスト発行元が待機状態となった場合に、レスポンスのリクエスト発行元への転送処理を代表クライアントクローンに分散して処理する事が可能となり、単一の代表クライアントの処理負荷が高くなることなく、全てのリクエスト発行元に対して転送し終わるまでの処理時間を短縮する事が可能となる。

図２２〜図２８を用いて本実施の形態の具体的な効果を説明する。
図２２〜図２８に示すように、クライアント１〜クライアント７から同一のリクエストが発生した場合を想定する。
この時、代表クライアントクローンを設定しない場合、代表クライアント０が全てのリクエスト発行元クライアントに対して順次レスポンスを返信するため、返信処理は７回実施される。
また、返信処理時間が一定と仮定し、その時間をＴとして表現すると、最後に返信されるクライアントレスポンスは７Ｔだけの遅延が発生する事になる。
一方で、閾値Ｎ＝３として代表クライアントクローンを設定した場合は、代表クライアントおよび各代表クライアントクローンのレスポンスの返信処理回数は高々２回である。
つまり、代表クライアント０は、代表クライアントクローン１と代表クライアントクローン２にのみレスポンスを返信すればよい。
代表クライアントクローン１は、代表クライアントクローン３とクライアント５にのみレスポンスを返信すればよい。
代表クライアントクローン２は、クライアント４とクライアント６にのみレスポンスを返信すればよい。
代表クライアントクローン３は、クライアント７にのみレスポンスを返信すればよい。
このように、代表クライアントクローンを設定しない場合と比べると代表クライアントの負荷の偏りがない事が分かる。
また、図２８において返信処理を左側の矢印を右側の矢印よりも先に処理するとした場合、最後に返信されるクライアントはクライアント６である。
クライアント０→クライアント１、クライアント０→クライアント２、クライアント２→クライアント４、クライアント２→クライアント６という順序でレスポンスが返信される。
このため、クライアント６での遅延時間は４Ｔとなり、代表クライアントクローンを設定しない場合と比べると３Ｔだけ短縮される事が分かる。

実施の形態５．
一般的にクライアント装置からサーバ装置１０５に発行するリクエストにはパラメータを付加する事がある。
例えばＵＲＩであれば「？」記号の後にパラメータの名前と値の間に「＝」記号を挟む形でパラメータを付加する事がある。
例えば、図６に記載のリクエスト例の一つである「ＰＯＳＴｈｔｔｐ：／／ｘｘｘ／ａｐｉ／ｍｏｎｉｔｏｒ＿ｉｎｔｅｒｖａｌ／？ｖａｌ＝５」における「ｖａｌ＝５」がパラメータであり、名前が「ｖａｌ」のパラメータの値として「５」を指定している。
また、複数のパラメータを付加する場合には、各パラメータ間を「＆」記号で区切って連結する事がある。
例えば、「ｈｔｔｐ：／／ｘｘｘ／ａｐｉ／ｍｏｎｉｔｏｒ＿ｉｎｔｅｒｖａｌ／？ｖａｌ＝５＆ｔａｒｇｅｔ＝ｔｅｍｐｅｒａｔｕｒｅ」の場合には名前が「ｖａｌ」のパラメータの値として「５」を、名前が「ｔａｒｇｅｔ」のパラメータの値として「ｔｅｍｐｅｒａｔｕｒｅ」を指定している。
これらパラメータを記述する「？」記号の後の文字列をクエリー部と呼ぶ事にする。
クエリー部には、サーバ装置１０５での検索の対象となる検索条件式が定義される。

ここまでに例示したパラメータでは具体的な値を指定しているが、パラメータ自体の解釈として値の集合や範囲を指定する事も可能である。
例えば、「ｈｔｔｐ：／／ｘｘｘ／ａｐｉ／ｕｓｅｒ？ｈｅｉｇｈｔ＝１６０｜１７０｜１８０」は、パラメータ「ｈｅｉｇｈｔ」の値が「１６０」もしくは「１７０」もしくは「１８０」を指定すると解釈させる事も可能である。
また、例えば「ｈｔｔｐ：／／ｘｘｘ／ａｐｉ／ｕｓｅｒ？ｈｅｉｇｈｔ＿ｇｔ＝１６０」はパラメータ「ｈｅｉｇｈｔ＿ｇｔ」の値が「１６０」と言う意味になるが、パラメータ「ｈｅｉｇｈｔ＿ｇｔ」はパラメータ「ｈｅｉｇｈｔ」の値が「ｈｅｉｇｈｔ＿ｇｔ」の値より大きい（ｇｔ＝ＧｒｅａｔｅｒＴｈａｎ）事を示すパラメータと解釈させる事で、最終的にパラメータ「ｈｅｉｇｈｔ」の値が「１６０」より大きい値と言う範囲を指定する事も可能となる。
ＵＲＩのクエリー部は前述の例の様な表現に限定されるものではなく、同じ内容を別の書式にて表現しても構わない。
また、説明を単純化するため、本実施の形態ではＵＲＩのクエリー部のみを例として説明するが、ＵＲＩのクエリー部でパラメータを表現しなくとも、ＨＴＴＰのＰＯＳＴメソッドのリクエストボディ部に同様にパラメータを指定する方法でも構わない。

上記の説明の通り、リクエストにパラメータが与えられる事を想定した場合、リクエストからＵＲＩのクエリー部を除外した内容は同一だが、クエリー部のみが異なるリクエストが発生する事が考えられる。
例えば、
ｈｔｔｐ：／／ｘｘｘ／ａｐｉ／ｕｓｅｒ？ｈｅｉｇｈｔ＿ｇｔ＝１６０
ｈｔｔｐ：／／ｘｘｘ／ａｐｉ／ｕｓｅｒ？ｈｅｉｇｈｔ＿ｇｔ＝１７０
の２つのＵＲＩを例に挙げて考えると、それぞれ別のリクエストとして処理する事になるが、実際には、
ｈｔｔｐ：／／ｘｘｘ／ａｐｉ／ｕｓｅｒ？ｈｅｉｇｈｔ＿ｇｔ＝１６０
に関するリクエストのみをサーバに発行し、得られたレスポンスから
ｈｔｔｐ：／／ｘｘｘ／ａｐｉ／ｕｓｅｒ？ｈｅｉｇｈｔ＿ｇｔ＝１７０
に適合するレスポンスのみを代表クライアントで抽出可能な場合がある。
具体的にはレスポンスのデータ群それぞれがプロパティ「ｈｅｉｇｈｔ」の値を持っている場合などが挙げられるが、それはシステム開発時にレスポンスのデータ構造を決定する時点で明らかとなる。
その場合には、上記２種類のリクエストに対して、サーバ装置１０５には１種類のリクエストを発行するのみで、２種類のリクエストに対するレスポンスを得る事が可能となる。

以上を考慮して更なるサーバ負荷軽減を実現するための実施の形態を説明する。

本実施の形態では、取得リクエストについての代表クライアントロールが自装置に割り当てられており、取得リクエストに対応するレスポンスが受信データ管理部２１１にキャッシュされておらず、取得リクエストに検索条件式が含まれ、当該検索条件式で得られる検索結果よりも広範な検索結果が得られる広範検索条件式に当該検索条件式を変換可能である場合に、代表クライアント処理部２１０は、検索条件式を広範検索条件式に変換する。
例えば、取得リクエストが前述の「ｈｔｔｐ：／／ｘｘｘ／ａｐｉ／ｕｓｅｒ？ｈｅｉｇｈｔ＿ｇｔ＝１７０」である場合に、クエリー部に含まれる検索条件式「ｈｅｉｇｈｔ＿ｇｔ＝１７０」は、より広範な検索結果が得られる「ｈｅｉｇｈｔ＿ｇｔ＝１６０」という検索条件式に変換可能である。
このため、代表クライアント処理部２１０は、クエリー部の「ｈｅｉｇｈｔ＿ｇｔ＝１７０」という検索条件式を「ｈｅｉｇｈｔ＿ｇｔ＝１６０」という広範検索条件式に変換する。
サーバ通信部２１２は、代表クライアント処理部２１０により変換された広範検索条件式が含まれるリクエストをサーバ装置１０５に送信する。
前述の例では、サーバ通信部２１２は、「ｈｔｔｐ：／／ｘｘｘ／ａｐｉ／ｕｓｅｒ？ｈｅｉｇｈｔ＿ｇｔ＝１６０」をサーバ装置１０５に送信する。

＊＊＊動作の説明＊＊＊
図３１を用いて、本実施の形態におけるリクエスト生成元のクライアント装置の代表クライアント判定部２０８の処理フローを説明する。
図３１は、図８で示した代表クライアント判定部２０８の処理フローを拡張した処理フローであり、図８に対して処理２５０１〜２５０３の処理が追加されている。
追加処理に関連する部分のみを説明する。

処理２５０１では、代表クライアント判定部２０８は、転送されたリクエストにクエリー部があるかを判定する。
判定にはＵＲＩに「？」が存在するかどうかを条件として利用可能である。
クエリー部がある場合には処理２５０２へ遷移し、クエリー部がない場合は、これまでの実施の形態と同様の処理可能であるため処理５０１に遷移する。

処理２５０２では、代表クライアント判定部２０８は、処理中のリクエストのクエリー部をクエリー部の内容のみ異なる同一のリクエストと論理和構成したリクエストでレスポンスを取得した際に、各クエリー部に対応するレスポンスに分離可能か判定する。
この判定には前述の通り、例えばシステム開発時にクエリーを含まないリクエストに対して論理和構成可能かが決定するため、その可否情報をテーブルとしてデータ化し、そのテーブルに基づいて判定する方法が考えられる。
論理和構成可能である場合には処理２５０３に遷移し、論理和構成不可能である場合には処理５０１に遷移する。

処理２５０３では、クエリー部を論理和構成可能なリクエストに対するリクエストのＩＤ算出処理を行う。
ＩＤ算出のキーとして少なくともリクエストからクエリー部の情報を除去した結果をキーとして算出する。
ＩＤ算出完了後、処理５０２に遷移する。
それ以降の処理は前述の通りであり説明は省略する。

次に、処理５０５でリクエストを他クライアント装置に転送した際の、リクエストの転送先となるクライアント装置の処理を図３２を用いて説明する。
図３２はリクエストの転送先となるクライアントの代表クライアント判定部２０８の処理フローである。

図３２は、図９で示した代表クライアント判定部２０８の処理フローを拡張した処理フローであり、図９に対して処理２６０１〜２６０３の処理が追加されている。
追加処理に関連する部分のみを説明する。

処理２６０１では、代表クライアント判定部２０８は、転送されたリクエストにクエリー部があるかを判定する。
判定にはＵＲＩに「？」が存在するかどうかを条件として利用可能である。
クエリー部がある場合には処理２６０２へ遷移し、クエリー部がない場合は、これまでの実施の形態と同様の処理が可能であるため処理６０１に遷移する。

処理２６０２では、代表クライアント判定部２０８は、処理中のリクエストのクエリー部をクエリー部の内容のみ異なる同一のリクエストと論理和構成したリクエストでレスポンスを取得した際に、各クエリー部に対応するレスポンスに分離可能か判定する。
この判定には前述の通り、例えばシステム開発時にクエリーを含まないリクエストに対して論理和構成可能かが決定するため、その可否情報をテーブルとしてデータ化し、そのテーブルに基づいて判定する方法が考えられる。
論理和構成可能である場合には処理２６０３に遷移し、論理和構成不可能である場合には処理６０１に遷移する。

処理２６０３では、クエリー部を論理和構成可能なリクエストに対するリクエストのＩＤ算出処理を行う。
ＩＤ算出のキーとして少なくともリクエストからクエリー部の情報を除去した結果をキーとして算出する。
ＩＤ算出完了後、処理６０２に遷移する。
それ以降の処理は前述の通りであり説明は省略する。

次に、図３３及び図３４は、図１０で示した代表クライアント処理部２１０の処理を拡張した処理フロー図であり、図１０に対して処理２７０１、２７０２、２７０３、２７０４が追加されている。
追加処理に関連する部分のみを説明する。

処理２７０１は、処理７０２で対応するレスポンスが受信データ管理部２１１に保存されていない場合、もしくは処理７０６で対応レスポンスの有効期限が切れている場合に到達する処理である。
本処理では、代表クライアント処理部２１０は、現在処理中のリクエストからクエリー部を比較対象外として対応するレスポンスが受信データ管理部２１１に保存されているか判定する。
保存されていない場合には、現在処理中のリクエストをそのままサーバ装置に発行する必要があるため処理７０３に遷移する。
保存されている場合には、処理２７０２に遷移する。

処理２７０２では、代表クライアント処理部２１０は、現在処理中のリクエストのクエリー部と処理２７０１でヒットしたレスポンスに対応するリクエストのクエリー部とでクエリーの論理和を生成し、その生成結果を新たなクエリー部とする論理和リクエストを生成し、それを処理７０３でサーバ装置１０５に発行するリクエストとする。
論理和リクエストの生成完了後、処理２７０５に遷移する。

処理２７０３は、処理７０５又は処理７０７から遷移する処理となる。
本処理では、代表クライアント処理部２１０は、サーバ装置１０５から受け取ったレスポンスに対応するリクエストが処理２７０２で生成した論理和リクエストに基づくものかを判定する。
論理和リクエストに基づかない場合には処理７０８に遷移し、基づく場合には処理２７０４に遷移する。

処理２７０４では、論理和リクエストに基づくレスポンスをサーバ装置１０５から受け取った状態であるため、現在処理中のリクエストのクエリー部に対応するデータのみで構成されるレスポンスを生成する必要があり、その生成処理を行う。
生成処理結果を処理中のリクエストに対応するレスポンスとして処理７０８に遷移する。

処理２７０５は、処理２７０２から遷移する処理である。
本処理では、処理２７０２で生成したリクエストに対応するレスポンスが受信データ管理部２１１に保存済みかどうかを判断する。
レスポンスが受信データ管理部２１１に保存済みである場合には処理７０６に遷移し、保存済みでない場合には処理７０３に遷移する。

なお、本実施の形態では、処理７０７の後は処理７０８ではなく処理２７０３に遷移する。

図３５に、論理和リクエストと対応するレスポンスとを保存したテーブルの一例を示す。
図３５ではＵＲＩが「ｈｔｔｐ：／／ｘｘｘ／ｄａｔａ．ｄａｔ」に対してクエリー部に「ｍｉｎ＝３」という検索条件式が存在するリクエストと「ｍｉｎ＝４」という検索条件式が存在するリクエストという２つのリクエストを想定している。
ここで、プロパティ「ｍｉｎ」は、レスポンスで得られるプロパティ「ｖａｌ」の値がプロパティ「ｍｉｎ」の値を下限とする事を意味する。
この意味に従うと２つのリクエストのクエリー部の論理和は「ｍｉｎ＝３」となり、その論理和リクエストによって得られたレスポンスをレスポンスエントリーに保存している。
処理２７０４で各リクエストに対応するデータのみで構成されるレスポンスを生成すると、クエリー部が「ｍｉｎ＝３」のリクエストに対しては論理和リクエストと一致するため、レスポンスエントリーの内容がそのままレスポンスとなる。
一方で、クエリー部が「ｍｉｎ＝４」のリクエストに対しては論理和リクエストと一致せず、各データのプロパティ「ｖａｌ」の値が下限となる４以上となるもののみを抽出する処理を処理２７０４で行う事となる。
その結果、得られるレスポンスは図３６の通りとなる。

＊＊＊効果の説明＊＊＊
以上の処理を行う事によって、リクエストにおけるクエリー部のみが異なる複数のリクエストに関して、クエリー部を論理和構成可能な場合には、それら複数のリクエストを一つの論理和リクエストとしてまとめ、それぞれのリクエストをサーバに発行するのではなく、論理和リクエストのみをサーバに発行するだけで済ませる事が可能となり、サーバ負荷の軽減が達成される。

以上、本発明の実施の形態について説明したが、これらの実施の形態のうち、２つ以上を組み合わせて実施しても構わない。
あるいは、これらの実施の形態のうち、１つを部分的に実施しても構わない。
あるいは、これらの実施の形態のうち、２つ以上を部分的に組み合わせて実施しても構わない。
なお、本発明は、これらの実施の形態に限定されるものではなく、必要に応じて種々の変更が可能である。

１０１クライアント装置、１０２クライアント装置、１０３クライアント装置、１０４クライアント装置、１０５サーバ装置、１１０ＣＰＵ、１１１メモリ、１１２入力インタフェース、１１３出力インタフェース、１１４通信インタフェース、１１５永続記憶インタフェース、１１６ディスク、１２０ＣＰＵ、１２１メモリ、１２２入力インタフェース、１２３出力インタフェース、１２４通信インタフェース、１２５永続記憶インタフェース、１２６ディスク、２０６アプリケーションロジック部、２０７リクエスト生成部、２０８代表クライアント判定部、２０９他クライアント通信部、２１０代表クライアント処理部、２１１受信データ管理部、２１２サーバ通信部、２１３通信部、２１４要求処理部。

Claims

複数のクライアント装置が含まれる通信システムに含まれるクライアント装置であって、
サーバ装置へのリクエストを代表して処理する役割である代表クライアントロールが自装置に割り当てられている場合に、自装置が前記通信システムから離脱した後に自装置に代わって動作する予備代表クライアント装置を他のクライアント装置の中から選択し、前記サーバ装置に送信するリクエストに前記予備代表クライアント装置の識別子を追加する代表クライアント処理部と、
前記代表クライアント処理部により前記予備代表クライアント装置の識別子が追加されたリクエストを前記サーバ装置に送信するサーバ通信部とを有するクライアント装置。
複数のクライアント装置が含まれる通信システムに含まれるクライアント装置であって、
２以上のクライアント装置で生成されたサーバ装置への同一のリクエストを取得した場合に、取得した取得リクエストを代表して処理する役割である代表クライアントロールが自装置に割り当てられているか否かを判定する代表クライアント判定部と、
前記取得リクエストについての代表クライアントロールが自装置に割り当てられている場合に、リクエスト生成元の２以上のクライアント装置のうちのいずれかのクライアント装置を、自装置と協働する代表クライアントクローン装置に指定する代表クライアント処理部と、
前記代表クライアントクローン装置に指定されたクライアント装置に対して、前記代表クライアントクローン装置に指定された旨を通知するとともに、前記２以上のクライアント装置のうち前記代表クライアントクローン装置に指定されなかったクライアント装置をレスポンスの送信先として通知する通知メッセージを送信し、前記取得リクエストに対応するレスポンスを、前記代表クライアントクローン装置に送信し、前記代表クライアントクローン装置から、前記通知メッセージで通知した送信先のクライアント装置に前記レスポンスを送信させる他クライアント通信部とを有するクライアント装置。
前記他クライアント通信部は、
前記代表クライアントクローン装置がレスポンスを送信するクライアント装置には、レスポンスを送信しない請求項２に記載のクライアント装置。
前記代表クライアント処理部は、
前記取得リクエストのリクエスト生成元のクライアント装置の個数が閾値を超える場合に、前記代表クライアントクローン装置を指定する請求項２に記載のクライアント装置。
前記他クライアント通信部は、
他のクライアント装置から、前記代表クライアントクローン装置に指定された旨を通知するとともに、レスポンスの送信先のクライアント装置を通知する通知メッセージを受信する場合があり、
前記通知メッセージを受信した後に、前記他のクライアント装置からレスポンスを受信した場合に、受信したレスポンスを、前記通知メッセージで通知された送信先のクライアント装置に送信する請求項２に記載のクライアント装置。
前記代表クライアント処理部は、
前記通知メッセージで通知された送信先のクライアント装置の個数が２以上である場合に、２以上のクライアント装置のうちのいずれかのクライアント装置を、新たな代表クライアントクローン装置に指定し、
前記他クライアント通信部は、
前記新たな代表クライアントクローン装置に指定されたクライアント装置に対して、代表クライアントクローン装置に指定された旨を通知するとともに、前記２以上のクライアント装置のうち前記新たな代表クライアントクローン装置に指定されなかったクライアント装置をレスポンスの送信先として通知する通知メッセージを送信し、
前記他のクライアント装置からレスポンスを受信した場合に、受信したレスポンスを、前記新たな代表クライアントクローン装置に送信し、前記新たな代表クライアントクローン装置から、前記新たな代表クライアントクローン装置への通知メッセージで通知した送信先のクライアント装置に前記レスポンスを送信させる請求項５に記載のクライアント装置。
複数のクライアント装置が含まれる通信システムに含まれるクライアント装置であって、
いずれかのクライアント装置により生成されたサーバ装置へのリクエストを取得した場合に、取得した取得リクエストを代表して処理する役割である代表クライアントロールが自装置に割り当てられているか否かを判定する代表クライアント判定部と、
前記取得リクエストについての代表クライアントロールが自装置に割り当てられている場合に、前記取得リクエストに対応する前記サーバ装置からのレスポンスが、自装置がアクセスできるキャッシュ領域にキャッシュされているか否かを判定し、前記取得リクエストに対応するレスポンスが前記キャッシュ領域にキャッシュされておらず、前記取得リクエストに検索条件式が含まれ、当該検索条件式で得られる検索結果よりも広範な検索結果が得られる広範検索条件式に当該検索条件式を変換可能である場合に、前記検索条件式を前記広範検索条件式に変換する代表クライアント処理部と、
前記代表クライアント処理部により変換された前記広範検索条件式が含まれるリクエストを前記サーバ装置に送信するサーバ通信部とを有するクライアント装置。
複数のクライアント装置が含まれる通信システムであって、
各クライアント装置は、
サーバ装置へのリクエストを代表して処理する役割である代表クライアントロールが自装置に割り当てられている場合に、自装置が前記通信システムから離脱した後に自装置に代わって動作する予備代表クライアント装置を他のクライアント装置の中から選択し、前記サーバ装置に送信するリクエストに前記予備代表クライアント装置の識別子を追加し、
前記予備代表クライアント装置の識別子が追加されたリクエストを前記サーバ装置に送信する通信システム。
複数のクライアント装置が含まれる通信システムであって、
各クライアント装置は、
２以上のクライアント装置で生成されたサーバ装置への同一のリクエストを取得した場合に、取得した取得リクエストを代表して処理する役割である代表クライアントロールが自装置に割り当てられているか否かを判定し、
前記取得リクエストについての代表クライアントロールが自装置に割り当てられている場合に、リクエスト生成元の２以上のクライアント装置のうちのいずれかのクライアント装置を、自装置と協働する代表クライアントクローン装置に指定し、
前記代表クライアントクローン装置に指定されたクライアント装置に対して、前記代表クライアントクローン装置に指定された旨を通知するとともに、前記２以上のクライアント装置のうち前記代表クライアントクローン装置に指定されなかったクライアント装置をレスポンスの送信先として通知する通知メッセージを送信し、前記取得リクエストに対応するレスポンスを、前記代表クライアントクローン装置に送信し、前記代表クライアントクローン装置から、前記通知メッセージで通知した送信先のクライアント装置に前記レスポンスを送信させる通信システム。
複数のクライアント装置が含まれる通信システムであって、
各クライアント装置は、
いずれかのクライアント装置により生成されたサーバ装置へのリクエストを取得した場合に、取得した取得リクエストを代表して処理する役割である代表クライアントロールが自装置に割り当てられているか否かを判定し、
前記取得リクエストについての代表クライアントロールが自装置に割り当てられている場合に、前記取得リクエストに対応する前記サーバ装置からのレスポンスが、自装置がアクセスできるキャッシュ領域にキャッシュされているか否かを判定し、前記取得リクエストに対応するレスポンスが前記キャッシュ領域にキャッシュされておらず、前記取得リクエストに検索条件式が含まれ、当該検索条件式で得られる検索結果よりも広範な検索結果が得られる広範検索条件式に当該検索条件式を変換可能である場合に、前記検索条件式を前記広範検索条件式に変換し、
変換された前記広範検索条件式が含まれるリクエストを前記サーバ装置に送信する通信システム。
複数のクライアント装置が含まれる通信システムに含まれるコンピュータであるクライアント装置が行うデータ処理方法であって、
サーバ装置へのリクエストを代表して処理する役割である代表クライアントロールが自装置に割り当てられている場合に、前記クライアント装置が、自装置が前記通信システムから離脱した後に自装置に代わって動作する予備代表クライアント装置を他のクライアント装置の中から選択し、前記サーバ装置に送信するリクエストに前記予備代表クライアント装置の識別子を追加する代表クライアント処理ステップと、
前記クライアント装置が、前記代表クライアント処理ステップにより前記予備代表クライアント装置の識別子が追加されたリクエストを前記サーバ装置に送信するサーバ通信ステップとを有するデータ処理方法。
複数のクライアント装置が含まれる通信システムに含まれるコンピュータであるクライアント装置が行うデータ処理方法であって、
前記クライアント装置が、２以上のクライアント装置で生成されたサーバ装置への同一のリクエストを取得した場合に、取得した取得リクエストを代表して処理する役割である代表クライアントロールが自装置に割り当てられているか否かを判定する代表クライアント判定ステップと、
前記取得リクエストについての代表クライアントロールが自装置に割り当てられている場合に、前記クライアント装置が、リクエスト生成元の２以上のクライアント装置のうちのいずれかのクライアント装置を、自装置と協働する代表クライアントクローン装置に指定する代表クライアント処理ステップと、
前記クライアント装置が、前記代表クライアントクローン装置に指定されたクライアント装置に対して、前記代表クライアントクローン装置に指定された旨を通知するとともに、前記２以上のクライアント装置のうち前記代表クライアントクローン装置に指定されなかったクライアント装置をレスポンスの送信先として通知する通知メッセージを送信し、前記取得リクエストに対応するレスポンスを、前記代表クライアントクローン装置に送信し、前記代表クライアントクローン装置から、前記通知メッセージで通知した送信先のクライアント装置に前記レスポンスを送信させる他クライアント通信ステップとを有するデータ処理方法。
複数のクライアント装置が含まれる通信システムに含まれるコンピュータであるクライアント装置が行うデータ処理方法であって、
前記クライアント装置が、いずれかのクライアント装置により生成されたサーバ装置へのリクエストを取得した場合に、取得した取得リクエストを代表して処理する役割である代表クライアントロールが自装置に割り当てられているか否かを判定する代表クライアント判定ステップと、
前記取得リクエストについての代表クライアントロールが自装置に割り当てられている場合に、前記クライアント装置が、前記取得リクエストに対応する前記サーバ装置からのレスポンスが、自装置がアクセスできるキャッシュ領域にキャッシュされているか否かを判定し、前記取得リクエストに対応するレスポンスが前記キャッシュ領域にキャッシュされておらず、前記取得リクエストに検索条件式が含まれ、当該検索条件式で得られる検索結果よりも広範な検索結果が得られる広範検索条件式に当該検索条件式を変換可能である場合に、前記検索条件式を前記広範検索条件式に変換する代表クライアント処理ステップと、
前記代表クライアント処理ステップにより変換された前記広範検索条件式が含まれるリクエストを前記サーバ装置に送信するサーバ通信ステップとを有するデータ処理方法。
複数のクライアント装置が含まれる通信システムに含まれるコンピュータであるクライアント装置に、
サーバ装置へのリクエストを代表して処理する役割である代表クライアントロールが自装置に割り当てられている場合に、自装置が前記通信システムから離脱した後に自装置に代わって動作する予備代表クライアント装置を他のクライアント装置の中から選択し、前記サーバ装置に送信するリクエストに前記予備代表クライアント装置の識別子を追加する代表クライアント処理ステップと、
前記代表クライアント処理ステップにより前記予備代表クライアント装置の識別子が追加されたリクエストを前記サーバ装置に送信するサーバ通信ステップとを実行させるプログラム。
複数のクライアント装置が含まれる通信システムに含まれるコンピュータであるクライアント装置に、
２以上のクライアント装置で生成されたサーバ装置への同一のリクエストを取得した場合に、取得した取得リクエストを代表して処理する役割である代表クライアントロールが自装置に割り当てられているか否かを判定する代表クライアント判定ステップと、
前記取得リクエストについての代表クライアントロールが自装置に割り当てられている場合に、リクエスト生成元の２以上のクライアント装置のうちのいずれかのクライアント装置を、自装置と協働する代表クライアントクローン装置に指定する代表クライアント処理ステップと、
前記代表クライアントクローン装置に指定されたクライアント装置に対して、前記代表クライアントクローン装置に指定された旨を通知するとともに、前記２以上のクライアント装置のうち前記代表クライアントクローン装置に指定されなかったクライアント装置をレスポンスの送信先として通知する通知メッセージを送信し、前記取得リクエストに対応するレスポンスを、前記代表クライアントクローン装置に送信し、前記代表クライアントクローン装置から、前記通知メッセージで通知した送信先のクライアント装置に前記レスポンスを送信させる他クライアント通信ステップとを実行させるプログラム。
複数のクライアント装置が含まれる通信システムに含まれるコンピュータであるクライアント装置に、
いずれかのクライアント装置により生成されたサーバ装置へのリクエストを取得した場合に、取得した取得リクエストを代表して処理する役割である代表クライアントロールが自装置に割り当てられているか否かを判定する代表クライアント判定ステップと、
前記取得リクエストについての代表クライアントロールが自装置に割り当てられている場合に、前記取得リクエストに対応する前記サーバ装置からのレスポンスが、自装置がアクセスできるキャッシュ領域にキャッシュされているか否かを判定し、前記取得リクエストに対応するレスポンスが前記キャッシュ領域にキャッシュされておらず、前記取得リクエストに検索条件式が含まれ、当該検索条件式で得られる検索結果よりも広範な検索結果が得られる広範検索条件式に当該検索条件式を変換可能である場合に、前記検索条件式を前記広範検索条件式に変換する代表クライアント処理ステップと、
前記代表クライアント処理ステップにより変換された前記広範検索条件式が含まれるリクエストを前記サーバ装置に送信するサーバ通信ステップとを実行させるプログラム。