ネットワークに接続された1以上のサーバーコンピュータと、前記サーバーコンピュータに処理を要求する手段を備えることを特徴とする1以上のクライアントコンピュータで構成されることを特徴とするコンピュータシステムであって、前記サーバーコンピュータが前記クライアントコンピュータの処理要求に応じるために必要なファイルやデータなど電子的に保存されうるリソースを取得する際、前記サーバーコンピュータ間で共有した、ネットワーク上の仮想的なリソース空間からファイルやデータを取得する手段を備えることを特徴とするコンピュータシステム。請求項1に記載したコンピュータシステムにおいて、前記リソースが仮想的なリソース空間にはないが前記クライアントコンピュータから処理の要求を受けたサーバーコンピュータに当該ファイルないしデータがある場合、前記ファイルないしデータを仮想的なリソース空間に保存する手段を備えることを特徴とするコンピュータシステム。請求項1に記載したコンピュータシステムにおいて、前記リソースが仮想的なリソース空間にもクライアントコンピュータから処理の要求を受けたサーバーコンピュータ内にもある場合、どちらのリソースが新しいかを判断するステップと、前記サーバーコンピュータのリソースがより新しい場合は仮想的なリソース空間のリソースと置き換えを行うステップが存在し、仮想的なリソース空間のリソースを更新する手段を備えることを特徴とするコンピュータシステム。請求項1、請求項2および請求項3に記載したリソースの取得保存更新を行う手段を備え、且つ、仮想的なリソース空間をネットワーク上に離散的に保持する手段を備え、且つ、仮想的なリソース空間の複製を持ち、高アクセス時および障害時に複製したリソース空間のリソース用いることを可能とする手段を備えたコンピュータシステム。クラウドコンピューティングでは複数サーバーコンピュータでのアプリケーション運営が前提となる。これは1つのアプリケーションが効率的にクラウド上コンピュータのリソースを使うためだけでなく、他のアプリケーションへのデータ、APIの提供、システムへのアクセシビリティの確保に於いても重要な前提条件となる。ここでリソースとは、オペレーティングシステムにおけるテキスト文書、バイナリ文書、画像、動画などのファイル、データベースシステムにおけるカラム、レコード、ドキュメントなどのデータ、またはアプリケーション自体を動作させる前記ファイルやデータ形式のモジュールを含む、不揮発性ハードウェアに保持されうるすべての電子的情報を指す。構築したコンピュータシステムを動かすためのモジュール、ファイルやデータは通常、各サーバーコンピュータのリソースを用いるため、各サーバーコンピュータに配置する必要がある。従って、アプリケーションモジュールを更新した場合に配置したモジュール、ファイルやデータは各サーバコンピュータに対して逐次更新処理を行う必要性が生じる。クラウドコンピューティングにおいてサーバーコンピュータはスケーラブルに増減するため、各サーバーにファイルを配信する方法では配信洩れや配信時の一部のサーバーへの障害が生じ易い。また、サーバーコンピュータ数が増加するほど管理コストが増大するという、デメリットを生じさせてしまう。本発明は上記課題を解決すべくなされたもので、請求項1に記載の発明は、ネットワークに接続された1以上のサーバーコンピュータと、前記サーバーコンピュータに処理を要求する手段を備えることを特徴とする1以上のクライアントコンピュータで構成されることを特徴とするコンピュータシステムであって、前記サーバーコンピュータが前記クライアントコンピュータの処理要求に応じるために必要なファイルやデータなど電子的に保存されうるリソースを取得する際、前記サーバーコンピュータ間で共有した、ネットワーク上の仮想的なリソース空間からファイルやデータを取得する手段を備えることを特徴とするコンピュータシステムである。請求項2に記載の発明は、請求項1に記載したコンピュータシステムにおいて、前記リソースが仮想的なリソース空間にはないが前記クライアントコンピュータから処理の要求を受けたサーバーコンピュータに当該リソースがある場合、前記リソースを仮想的なリソース空間に保存する手段を備えることを特徴とするコンピュータシステムである。請求項3に記載の発明は、請求項1に記載したコンピュータシステムにおいて、前記リソースが仮想的なリソース空間にもクライアントコンピュータから処理の要求を受けたサーバーコンピュータ内にもある場合、どちらのリソースが新しいかを判断するステップと、前記サーバーコンピュータのリソースがより新しい場合は仮想的なリソース空間のリソースと置き換えを行うステップが存在し、仮想的なリソース空間のリソースを更新する手段を備えることを特徴とするコンピュータシステムである。請求項4に記載の発明は、請求項1、請求項2および請求項3に記載したリソースの取得保存更新を行う手段を備え、且つ、仮想的なリソース空間をネットワーク上に離散的に保持する手段を備え、且つ、仮想的なリソース空間の複製を持ち、高アクセス時および障害時に複製したリソース空間のリソース用いることを可能とする手段を備えたコンピュータシステムである。以下、図面を参照し、この発明の本発明の一実施の形態以下本実施形態と呼ぶについて説明する。図1は本実施形態にかかるコンピュータシステムの概略図である。図1に基づき、本実施形態においての必要条件を述べる。コンピュータシステム40は、1以上のサーバーコンピュータ20、1以上のクライアントコンピュータ10と仮想的なリソース空間である仮想リソース空間30からなり、クライアント10はインターネット網やイントラネット網などのネットワークN1を介してサーバーコンピュータ20に接続されており、リクエストレスポンス通信方式もしくは、ソケット通信方式をして、サーバー20とファイル、データなどリソースの授受を行うことができる。また、サーバーコンピュータは仮想リソース空間30に対してリソースの登録取得更新を行うことができる。図2は本実施形態において、仮想リソース空間30の構成を示すブロック図である。仮想リソース空間30はデータの離散的保持shardingが可能なデータベースシステムを備えた、1または複数のサーバーコンピュータで構成される。図2ではN2を通じ、shardingされたデータベース30-1a、30-2a、がそれぞれの複製replicaである30-1b、30-2bを持ち、クライアントコンピュータからの処理要求を実行するサーバーコンピュータ20はネットワークN2を介してDBRouter31に対してリソースの登録取得更新命令を行うことで前記shardingされたデータベースからのリソースの取得、shardingされたデータベースへのリソースの登録更新を行うことができる。図2においては、shardingされたデータベースシステムは1つのサーバーに1つのデータベースが配置されているが、本実施形態はその限りでない。例えばsharingされたデータベース30-1aと30-2aが同じサーバーコンピュータで動作している状況や、DBRouter31とshardingされたデータベース30ー1aおよび30ー2bが同じサーバーコンピュータで動作している状況も本実施形態としての要件を満たしている。また、サーバーコンピュータはRouteDB31の数や位置を把握する必要があるが、この設定はサーバーコンピュータのメモリ上に配置されており、サーバーコンピュータはこれを外部から書き換え、運用を止めることなく仮想リソース空間30の構成変化に対応できるAPIを有する。図3は本実施形態において、クライアントコンピュータ10から処理の要求を受けたサーバーコンピュータ20がその過程でリソースを必要とした場合に、仮想リソース空間30からリソースを要求するアドレスの取得フロー図である。サーバーコンピュータ20には3つのアドレス状態が存在する。個々のサーバーコンピュータのリソース空間上のアドレスA10、そこから個々のサーバーコンピュータ依存部分を取り除いた中間アドレスA11および前記中間アドレスに仮想リソース空間30の空間名を付与した問い合わせアドレスA12である。サーバーコンピュータ20は自身依存部分を示す文字列または正規表現R10および、前記中間アドレスA11から仮想リソース空間30の空間名を示す文字列または正規表現R11を有しており、且つ、R10を用いてA10からA11を算出するステップS10と、R11を用いてA11からA12を算出するステップS11を有する。クライアントコンピュータ10から直接リソースの要求を受けるときはURLから変換されたA10のアドレスを元に仮想リソース空間30とリソースを授受する。また、サーバーコンピュータに配布されるコンピュータシステムのロジックプログラムではA10またはA12のアドレスを用いて仮想リソース空間30とリソースを授受する。図4は本実施形態において、クライアントコンピュータ10から処理の要求を受けたサーバーコンピュータ20がその過程でリソースを必要とした場合に、仮想リソース空間30からデータを取得する処理を行うシーケンスフロー図である。図4、図5に基づき、本発明の詳細な動作を述べる。前記仮想リソース空間30とリソースを授受するためのアドレスを取得するロジックによって、サーバーコンピュータ20は仮想リソース空間30とリソースを授受するためのアドレスAを取得する。サーバーコンピュータ20はDBRouter31に対してアドレスAおよび要求リソース状態確認命令を送信するS101。DBRouter31はアドレスAからリソースの格納場所を判断し、shardingされたデータベースへリソース状態確認コマンドを発行するS102。データベースからリソースの作成日時、更新日時、リソースのロック状態等を含むメタデータが送信されるS103。ここでメタデータとはXML、JSON等規則に従った並びをしたテキストデータを指す。前記アドレスAに該当するリソースが存在しない場合、参照先のないポインタnullが送信される。前記仮想リソース空間のメタデータをDBRouter31はサーバーコンピュータに送信するS104。サーバーコンピュータは前記仮想リソース空間から取得したメタデータである仮想リソース空間上のリソースメタデータM1を受け取ったS105のち、前記アドレスで自身のリソースの状態を捜査するS106。捜査するアドレスは前記仮想リソース空間30とリソースを授受するためのアドレスを取得するロジックに基づき、自身依存部分を含むアドレスを取得し、自メタデータM2として保持する。自身依存部分を含むアドレスにリソースが存在しない場合、参照先のないポインタnullを保持する。ここから3パターンに処理を分岐する。M1とM2がともにメタデータを持ち、且つ、M1の更新日時とM2の更新日時が同じかもしくはM1の更新日時がM2の更新日時より未来である、または、M1はメタデータを持ち、且つ、M2のメタデータが存在ない場合S200、単純に仮想リソース空間30からリソースを取得する。S201~S204M1とM2がともにメタデータを持ち、且つ、M1の更新日時がM2の更新日時より過去である、または、M1のメタデータが存在せず、且つ、M2のメタデータがある場合S300、自身のリソースを仮想リソース空間30に保存したのち、仮想リソース空間30からリソースを取得する。S301~S309M1とM2がともにメタデータを持たない場合S400、エラー処理をサーバーコンピュータ20で行う。以上が本実施形態における、詳細な動作の記述である。