コンピュータシステム中でモジュールを分離する方法であって、非同期メッセージングを用いて第1のホスト中の第1のモジュールから第2のホスト中の第2のモジュールにメッセージを送信する段階と、前記メッセージを処理するのに必要なコンテキストを、スコープ階層中で管理されるスコープ中で維持する段階と、前記コンテキストのコピーを前記第2のホストに送信する段階と、前記第1のモジュールを一時停止する段階と、前記メッセージが前記第2のモジュールによって処理されたことを示す応答を受信する段階と、前記コンテキストの前記コピーの更新を前記第2のホストから受信する段階と、前記更新を前記スコープ階層中の前記コンテキストに組み込む段階と、前記第1のホスト上の前記第1のモジュールを再開する段階とを含む方法。前記メッセージを送信する段階および前記コンテキストの前記コピーを送信する段階が前記第1のモジュールおよび前記第2のモジュールに対してトランスペアレントである、請求項1に記載の方法。応答を受信する段階が、前記第1のホストにおいて前記第2のホストから返信メッセージを受信する段階を含む、請求項1に記載の方法。前記コンテキストの前記コピーが帯域内コピーとして前記メッセージに添付される、請求項1に記載の方法。前記コンテキストの前記コピーを帯域外コピーとして前記メッセージとは別に前記第2のホストに送信する段階をさらに含む、請求項1に記載の方法。前記コンテキストを前記第2のホストに送信する段階が、前記第1のホストの代わりとして前記コンテキストを事前対応的にコピーする段階を含む、請求項5に記載の方法。前記コンテキストの前記コピーを送信する段階が、前記第2のホストの需要があり次第、前記メッセージを処理するのに必要な前記コンテキストをコピーする段階を含む、請求項5に記載の方法。前記メッセージを処理するのに必要な前記コンテキストが前記スコープ階層中で識別可能である、請求項1に記載の方法。前記メッセージをメッセージキュー中に配置する段階をさらに含む、請求項1に記載の方法。前記キューを一時停止する段階と、前記第2のモジュールを更新する段階と、前記第2のモジュールが更新された後で前記キューから前記要求メッセージを処理する段階とをさらに含む、請求項9に記載の方法。前記コンテキストの前記コピーに基づいて前記メッセージを処理するように構成された一連の第2のホストを提供する段階と、ロードバランサを使用して前記メッセージを前記一連の第2のホストのうちの複数にルーティングする段階とをさらに含む、請求項9に記載の方法。モジュールをホストし、前記モジュールに対するリソース割振りを管理するための、コンピュータシステムであって、ネットワークを介してメッセージを送信するように構成された通信ユニットと、前記メッセージの送信を抑制するためのキューを記憶したメモリと、コンテキストをスコープ階層中で維持し、前記メッセージに関連するスコープを生み出し、前記コンテキストのうちの1つまたは複数を受信コンテキストとマージするための、リソースマネージャとを備えるコンピュータシステム。前記通信ユニットがさらに、前記メッセージに関連する前記スコープについてのコンテキストのコピーを送信するように構成された、請求項12に記載のコンピュータシステム。前記コンテキストの前記コピーが前記メッセージに添付される、請求項13に記載のコンピュータシステム。前記第2のホストへの前記コンテキストの前記コピーが前記メッセージとは別に送信される、請求項13に記載のコンピュータシステム。前記受信コンテキストが前記メッセージに応答して受信される、請求項12に記載のコンピュータシステム。モジュールをホストし、前記モジュールに対するリソース割振りを管理するための、コンピュータシステムであって、ネットワークを介して前記モジュールに対するメッセージを受信するための受信機と、前記モジュールを実行して前記メッセージを処理するためのプロセッサと、前記メッセージに関連するスコープを含むスコープの割振りおよび解放を行うためのリソースマネージャと、コンテキストのコピーを記憶するためのコンテキスト記憶エリアとを備え、前記コンテキストが、前記メッセージに関連する前記スコープのリソースを含む、コンピュータシステム。前記メッセージをキュー中に配置するためのキューマネージャをさらに備える、請求項17に記載のコンピュータシステム。前記キューマネージャが、前記キューを一時停止し、前記モジュールを更新し、前記モジュールが更新された後で前記キューから前記要求メッセージを処理する、請求項16に記載のコンピュータシステム。コンピュータシステム中でモジュールを分離する方法を実行するための命令を記憶した非一時的なコンピュータ可読媒体であって、前記方法が、非同期メッセージングを用いて第1のホスト中の第1のモジュールから第2のホスト中の第2のモジュールにメッセージを送信する段階と、前記メッセージを処理するのに必要なコンテキストを、スコープ階層中で管理されるスコープ中で維持する段階と、前記コンテキストのコピーを前記第2のホストに送信する段階と、前記第1のモジュールを一時停止する段階と、前記メッセージが前記第2のモジュールによって処理されたことを示す応答を受信する段階と、前記コンテキストの前記コピーの更新を前記第2のホストから受信する段階と、前記更新を前記スコープ階層中の前記コンテキストに組み込む段階と、前記第1のホスト上の前記第1のモジュールを再開する段階とを含む、非一時的なコンピュータ可読媒体。これらのモジュールを実行するには、サーバは、サーバリソースの一部をモジュールに割り振る必要がある。加えて、サーバのモジュールは通常、結合される。すなわち、例えばモジュールは、他のモジュールのパブリッシュされた機能に依拠したり、同じグローバルデータまたは変数にアクセスすることによって状態を共有したりすること等が可能である。さらに、クラウド環境では、単一のまたは種々のコンピュータシステム上に位置する結合されたモジュールを更新することは、問題を孕む可能性がある。同様に、結合されたモジュールをオペレータが自発的にスケーリングしたいときにもまた、困難が生じる。加えて、一般にサーバリソースは非常に非構造的な方式で割り振られ使用されるので、クラウド環境にわたるリソースの伝送は困難であることがある。したがって、より構造化されたサーバリソース管理手法を使用して、モジュールの分離を可能にすることが必要とされている。本発明の一実施形態によれば、コンピュータシステム中でモジュールを分離する方法、および、この方法を実行するための命令を記憶したコンピュータ可読媒体が開示される。この方法は、例えば、非同期メッセージングを用いて第1のホスト中の第1のモジュールから第2のホスト中の第2のモジュールにメッセージを送信すること、メッセージを処理するのに必要なコンテキストを、スコープ階層中で管理されるスコープ中で維持すること、コンテキストのコピーを第2のホストに送信すること、第1のモジュールを一時停止すること、メッセージが第2のモジュールによって処理されたことを示す応答を受信すること、コンテキストのコピーの更新を第2のホストから受信すること、更新をスコープ階層中のコンテキストに組み込むこと、および、第1のホスト上の第1のモジュールを再開することを含むことができる。本発明の別の実施形態によれば、モジュールをホストし、モジュールに対するリソース割振りを管理するための、コンピュータシステムが開示される。このシステムは、例えば、ネットワークを介してメッセージを送信するように構成された通信ユニットと、メッセージの送信を抑制するためのキューを記憶したメモリと、リソースマネージャとを備えることができる。リソースマネージャは、コンテキストをスコープ階層中で維持し、メッセージに関連するスコープを生み出し、コンテキストのうちの1つまたは複数を受信コンテキストとマージするためのものとすることができる。本発明の別の実施形態によれば、モジュールをホストし、モジュールに対するリソース割振りを管理するための、コンピュータシステムが開示される。このシステムは、ネットワークを介してモジュールに対するメッセージを受信するための受信機と、モジュールを実行してメッセージを処理するためのプロセッサと、メッセージに関連するスコープを含むスコープの割振りおよび解放を行うためのリソースマネージャと、コンテキストのコピーを記憶するためのコンテキスト記憶エリアとを備えることができ、コンテキストは、メッセージに関連するスコープのリソースを含む。以上の一般的な記述と、以下の詳細な記述とは両方とも、例示的および説明的なものに過ぎず、記述され特許請求される本発明の範囲を限定するものと考えるべきではないことを理解されたい。さらに、本明細書に述べるものに加えて特徴およびまたは変形を提供することもできる。例えば、本発明の実施形態は、詳細な記述で述べる特徴の様々な組合せおよびサブコンビネーションを対象とすることもできる。本開示に組み込まれ本開示の一部をなす添付の図面に、本発明の様々な実施形態および態様を示す。以下の詳細な記述では、添付の図面を参照する。可能な場合には、図面および以下の記述において、同じまたは類似の部分を指すのには、同じ参照番号を使用する。本発明のいくつかの例示的な実施形態および特徴について本明細書に述べるが、本発明の趣旨および範囲を逸脱することなく、修正、適応、および他の実施形態も可能である。例えば、図面に示すコンポーネントに対して代用、追加、または修正を行うこともでき、また、開示する方法に対してステップを代用、並べ替え、または追加することによって、本明細書に述べる例示的な方法を修正することもできる。したがって、以下の詳細な記述は本発明を限定しない。そうではなく、本発明の正しい範囲は、添付の特許請求の範囲によって定義される。発明の概観本発明によるシステムおよび方法は、一般に、モジュール分離およびトランスペアレントな分散を提供することに関する。本発明によるシステムおよび方法は、クラウドコンピューティング環境で利用することができる。トランスペアレントな分散およびモジュール分離は、非同期通信およびスコープを使用して達成することができる。図1Aに、本発明によるシステム100を示す。システム100は、メッセージ作成側110および120が通信ネットワーク130によってメッセージ消費側140に接続されているのを示す。例えば、メッセージ作成側110および120ならびにメッセージ消費側140は、ビジネスコンピュータシステムとすることができる。メッセージ作成側110および120ならびにメッセージ消費側140はまた、種々の抽象化レベルで見ることができる。例えばこれらは、システムのリソース全体をカバーするノードレベルから、スレッドのリソースをカバーするスレッドレベルまでで見ることができる。加えて、メッセージ作成側110および120ならびにメッセージ消費側140のユーザおよびクライアントは、メッセージ作成側110、120ならびにメッセージ消費側140の特定のセキュリティ領域に制限することができる。すなわち、セキュリティの目的で、ユーザおよびクライアントからメッセージ作成側110および120ならびにメッセージ消費側140のいくつかのリソースへのアクセスを制限することができる。通信ネットワーク130は、メッセージ作成側110および120とメッセージ消費側140との間の通信を容易にすることができる。図1Aに示すコンポーネント110、120、および140の数が例示的であることは、当業者なら理解するであろう。したがって、本発明によるシステム100は、任意の数のメッセージ作成側110もしくは120、または任意の数のメッセージ消費側140を含むことができる。図1Bに別の可能なシステムを示すが、このシステムは、メッセージ消費側とメッセージ作成側とがちょうど対称であってもよいことを強調するもので、メッセージ消費側とメッセージ作成側とがそれぞれの役割を実行時に切り替えることができる。通信ネットワーク130は、ワイドエリアネットワーク、ローカルエリアネットワーク、またはインターネットなど、1つまたは複数のネットワークタイプを含むことができる。通信ネットワーク130は、ワイヤラインおよびまたはワイヤレス技術によって動作することができ、伝送制御プロトコルインターネットプロトコルまたはいずれか他の適切なプロトコルを使用して、システム100のメッセージ作成側110および120とメッセージ消費側140との間の通信を容易にすることができる。ネットワーク130内のネットワーク接続は、イーサネット登録商標、電話回線、セルラーチャネル、または他の伝送媒体を介して確立することができる。ネットワーク130を介したデータ通信は、メッセージ作成側110および120ならびにメッセージ消費側140などのデバイス間でデータパケットを伝送することによって容易にすることができる。本明細書に述べるデータ伝送は、例えば、単一のデータパケット中で送信されてもよく、あるいはいくつかのデータパケットにわたって分割されてもよい。さらに、メッセージ作成側110および120は、ネットワーク130を介してメッセージ消費側140と非同期通信することができる。システム100のメッセージ作成側110および120ならびにメッセージ消費側140は、1つまたは複数のアプリケーションプログラムおよび1つまたは複数のハードウェアコンポーネントの組合せなど、多くのインフラストラクチャを含むことができる。例えば、アプリケーションプログラムは、本発明の開示される動作を実行する、ソフトウェアモジュール、命令のシーケンス、ルーチン、データ構造、表示インタフェース、および他のタイプの構造を含むことができる。メッセージ作成側110および120ならびにメッセージ消費側140のハードウェアコンポーネントは、中央処理装置、バス、メモリデバイス、記憶ユニット、データプロセッサ、入力デバイス、出力デバイス、ネットワークインタフェースデバイス、および、当業者には明らかであろう他のタイプのコンピュータシステムコンポーネントの組合せを含むことができる。したがって、メッセージ作成側110および120ならびにメッセージ消費側140は、ハンドヘルドデバイス、パーソナルコンピュータ、またはメインフレームコンピュータなど、任意のタイプのコンピュータデバイスによって実現することができる。メッセージ作成側110および120ならびにメッセージ消費側140は、それぞれプロセッサ1101、1201、および1401を備えることができる。プロセッサ1101、1201、および1401はプロセスを実行することができ、プロセスは、スレッド1102、1202、および1402などのスレッドに分割することができる。メッセージ作成側110および120ならびにメッセージ消費側140はさらに、メモリ1103、1203、および1403を備えることができる。メモリ1103、1203、および1403は、不揮発性または揮発性メモリなど任意の形のコンピュータ可読記憶媒体を含むことができ、例としてこれらには、EPROM、RAM、ROM、DRAM、EEPROM、フラッシュメモリデバイスなどの半導体メモリデバイス内蔵ハードディスクや取外し可能ディスクなどの磁気ディスク光磁気ディスクおよびCDROM、DVD、またはブルーレイディスクが含まれる。スコープおよびコンテキストメモリ1103、1203、および1403はそれぞれ、モジュール1104、1204、および1404などのソフトウェアモジュールを含むことができる。モジュール1104、1204、および1404は、それぞれプロセッサ1101、1201、および1401によって実行される命令を含むことができる。上に論じたように、命令はさらに、スレッド1102、1202、および1402などのスレッドに分割することができる。メッセージ作成側110および120ならびにメッセージ消費側140はそれぞれさらに、スコープを使用してリソースを管理するために、リソース管理モジュール1105、1205、および1405などのリソース管理モジュールを備えることができる。リソースは、例えばメモリデータ構造、データベース接続、またはセキュリティ許可において、特定のプロセスを実行するのに必要なものなら何でも含むことができる。スコープは、定義された期間にわたってコンピュータ上でグループ化される複数のリソースを含むことができる。スコープタイプの例は、要求スコープ、ユーザスコープ、プロセススコープなどである。スコープタイプの追加の例については、以下でさらに詳細に論じる。メッセージ作成側110および120ならびにメッセージ消費側140は、スコープタイプを実行時にインスタンス化して、スコープインスタンスを生み出すことができる。スコープインスタンスは、実行時にこのインスタンスを識別するための論理IDを含むことができる。このIDは、大域的に一意とすることができる。リソース管理モジュール1105、1205、および1405は、リソースをスコープインスタンスに関連付けて、システム100内部で割り振られる任意のリソースの寿命を明確に線引きすることができる。いくつかの実施形態では、システム100中には、スコープインスタンスに関連付けられないリソースがないことがある。しかし、本発明のいくつかの実施形態では、所有主であるスコープインスタンスは非常に粗粒であることがある。すなわち、スコープインスタンスは、システム100の大きなコンポーネントをカバーし、より小さいスコープインスタンスに細分できないことがある。例えば、この設定は、スコープインスタンスをバッチジョブよりも低い細粒度にさらに分割することから何の利益も得られそうにない場合の、ローカルバッチ処理のみに向けられたシステム中で適切であることがある。リソース管理モジュール1105、1205、および1405は、リソースをスコープインスタンス中で割り振ったりスコープインスタンスから解放したりすることによって、リソースを管理することができる。リソース管理モジュール1105、1205、および1405は、リソースが生み出されるとき、リソースをちょうど1つのスコープインスタンスに割り振ることができ、リソースが個別に削除されるとき、このスコープインスタンスからリソースを解放することができる。リソース管理モジュール1105、1205、および1405は、リソースを所有するスコープインスタンスが例えばタイムアウトのせいで解放されるとき、リソースを解放することができる。リソース管理モジュール1105、1205、および1405は、スコープインスタンスを暗黙的に定義することができ、それにより、メモリ領域、すなわちオブジェクトを割り振る構造をプログラマが明示的に宣言しなくて済むようにすることができる。さらに、リソース管理モジュール1105、1205、および1405は、スコープインスタンスを使用して、ローカルに割り振られたオブジェクトをメッセージ作成側110および120ならびにメッセージ消費側140などの協働ノードのネットワーク中で分散させて、リモート通信の透過性を高めることができる。リソース管理モジュール1105、1205、および1405は、スコープインスタンスを、そのコンテキストと呼ばれる定義された記憶エリアに関連付けることができる。コンテキストは、一時的とすることもでき、あるいは永続的とすることもできる。コンテキストはシステム100中で冗長的に存在できるが、スコープインスタンスは通常、いずれか所与の時点で単一のメッセージ作成側110もしくは120またはメッセージ消費側140上でのみアクティブであるという点で、コンテキストは、それに関連するスコープインスタンスとは異なるものとすることができる。例えば図1Aでは、メッセージ作成側110のメモリ1103は、第1のスコープインスタンスのコンテキスト1106を含む。同様に、メッセージ作成側120のメモリ1203は、第2のスコープインスタンスのコンテキスト1206を含む。リソース管理モジュール1105は、スコープインスタンスの寿命の間にスコープインスタンスに関連付けられる任意のリソースを割り振ることができる。例えば、第1のスコープインスタンスのコンテキスト1106は、割り振られたリソース1107および1108を含む。同様に、第2のスコープインスタンスのコンテキスト1206は、割り振られたリソース1207および1208を含む。スコープインスタンスは、メッセージ作成側110および120ならびにメッセージ消費側140のそれぞれにおいて1つのコンテキストを有することによって、メッセージ作成側110および120ならびにメッセージ消費側140の間を移行することができる。リソース管理モジュール1105、1205、および1405などのリソース管理モジュールは、これらのコンテキストのうちの1つを好ましいインスタンスとして割り当てて、種々のマシン間で過剰なデータ移動がないようにすることができる。スコープ中の好ましいインスタンスは、このスコープインスタンスに関係する全てのタスクをデフォルトで扱うインスタンスとすることができる。他のマシン上の他のコンテキストインスタンスは、コンテキストのこの好ましいインスタンスと同期して、所与のスコープインスタンス内でのデータ不整合を回避することができる。非同期通信図1Aに示すように、メモリ1103および1203は、それぞれアウトバウンドキュー1109および1209を含む。アウトバウンドキュー1109および1209は、それぞれアウトバウンドメッセージ11010および12010を含むことができる。コンテキスト1106は、リソース1107および1108など、メッセージ11010を処理するのに必要なリソースを含むことができる。すなわち、メッセージ11010は、第1のスコープインスタンスであるスコープ1に関連することができる。コンテキスト1206は、リソース1207および1208など、メッセージ12010を処理するのに必要なリソースを含むことができる。すなわち、メッセージ12010は、第2のスコープインスタンスであるスコープ2に関連することができる。メッセージ消費側140のメモリ1403は、インバウンドキュー1406を含むことができる。インバウンドキュー1406は、アウトバウンドキュー1109から受け取ったメッセージ11010、およびアウトバウンドキュー1209から受け取ったメッセージ12010を含むことができる。同様に、図1Bに示すように、メッセージ消費側140はまた、他のモジュール1409を備えることができ、リソースマネージャ1405は、リソース14011および14012を含むコンテキスト14010など、スコープインスタンスについてのコンテキストを割り振ることができる。メッセージ消費側140はまた、メッセージ作成側110などのメッセージ作成側または他のメッセージ消費側にメッセージ14014を送信するためのアウトバウンドキュー14013を備えることができる。メッセージ作成側110もまた、他のメッセージ作成側またはメッセージ消費側140からメッセージ14014を受信するためのインバウンドキュー11013を備えることができる。メッセージ作成側110は、モジュール1104または別のモジュール11011を使用して、メッセージ14014を処理することができる。加えて、メッセージ作成側110はまた、メッセージ14014についてのコンテキストのコピー、すなわちコンテキストコピー11012を受信することができる。例えば、図1B中のモジュール1104が、ネットワーク130によってメッセージ作成側110から分離されているメッセージ消費側140上にモジュール1404があることを知らずに、モジュール1404の機能にアクセスしたいと仮定する。モジュール1104は、モジュール1404を表すメモリ1103中のリソースに対して、メソッド呼出しを開始することができる。このメソッド呼出しは、スレッド1102上で実施することができる。次いで、呼び出されたリソースは、メソッド呼出しをメッセージ11010に変換することができ、スレッド1102は、メッセージ11010をアウトバウンドキュー1109上に配置することができる。その後、メッセージ14014などの応答メッセージまたは肯定応答がメッセージ作成側110に返されるまで、スレッド1102を保留するかまたはメッセージ作成側110中の他のタスクに利用することができる。メッセージ作成側110のスレッドスケジューリングアルゴリズムに応じて、同じまたは異なるスレッド1102が、メッセージ作成側110のインバウンドキュー11013からメッセージ14014などの応答メッセージを得て、元のメソッド呼出しのすぐ後に続く命令ステップでモジュール1104の処理を再開する。図1A中のメッセージ11010および12010を処理するために、メッセージ消費側140は、メッセージ11010および12010に関連するスコープインスタンスのリソースへのアクセスを必要とすることがある。これが起こるのを可能にするために、本発明によるシステム100は、メッセージ11010および12010に関連するスコープインスタンスのコンテキストを、メッセージ消費側140にコピーする。このプロセス中で、システム100は、データがコンテキストの様々なコピー間で同期するようにして、データ破損を防止する。コピープロセスがいくらかの時間を要する場合は、システム100は、コピープロセスが完了するまで、メッセージ消費側140へのメッセージ11010および12010の配信を遅延させることを選択することができる。したがって、メッセージ11010および12010がメッセージ消費側140中で処理されると、メモリ1403は、第1のスコープインスタンスのコンテキストの現コピー1407、ならびに第2のスコープインスタンスのコンテキストの現コピー1408を含む。前の2つの段落で述べた手法は、図1Aのモジュール1104および1204に同期するように見える呼出しをシステム100が非同期に実行するのを可能にすることができる。さらに、この手法はまた、システム100が参照渡しセマンティクスによってリモート呼出しを実施するのを可能にすることができる。というのは、呼出し中に使用されるどんな参照の現在の値も、メッセージ消費側140に利用可能にされるからである。この2つの能力の組合せにより、本発明の使用は確実に、モジュール1104および1204に対して完全にトランスペアレントのままとなる。すなわち、分散環境で実行されるにもかかわらず、モジュール1104および1204は、モジュール1404がモジュール1104および1204と同じメモリ1103中にあるかのように動作し続けることができる。特定の方式で構成された特定のコンポーネントを有するものとしてシステム100の例示的な実施形態について述べているが、システム100が、異なるように構成できる追加のまたはより少ないコンポーネントを含んでもよいことは、当業者なら理解するであろう。例えば、メッセージ作成側110および120ならびにメッセージ消費側140は、追加のプロセッサおよびまたはメモリデバイスを備えてもよい。さらに、コンポーネント1104、1105、1106、および1109に例えば含まれるプロセス命令は、複数のメモリデバイスにわたって分散させてもよい。また前述のように、システム100は、図1Aまたは1Bに示すよりも少ないかまたは多いメッセージ作成側110および120ならびにメッセージ消費側140を使用して実現してもよい。図2に、本発明による、スコープを使用してモジュールをトランスペアレントに分離するための例示的なシステムを示す。ステップS201で、メッセージ作成側110および120のうちの一方に位置することのできるモジュールAが、メッセージ消費側140上に位置することのできるモジュールBのオブジェクトインスタンス上のメソッドを呼び出す。モジュールAから見ると、これは、モジュールBのオブジェクトインスタンスを表すモジュールAのローカルアドレス空間中のオブジェクトインスタンスに対する、ローカルメソッド呼出しである。次いでメッセージ作成側110または120は、要求メッセージをキューに入れ、対応するスレッドを、モジュールA中のメソッド呼出しを実行するタスクから分離することができる。次いでこのスレッドは、モジュールAのローカルアドレス空間中での他の処理に使用することができる。この分離により、モジュールAの実行は、メソッド呼出しの継続時間にわたって一時停止される。次いでメッセージプロバイダ110または120は、要求メッセージをモジュールBに転送することができる。システム100はまた、関連するどんなスコープコンテキストもモジュールBのローカルアドレス空間に暗黙的にコピーすることができる。これを行うには3つの方法がある。すなわち、メッセージ添付、および事前対応または事後対応の帯域外複製である。ステップS204とS205は、並行して行われてよい。次いでシステム100は、要求メッセージをモジュールBのローカルアドレス空間中のメソッド呼出しのターゲットオブジェクトインスタンスに配信する。メッセージ消費側140は、複製されたスコープコンテキストを必要に応じて参照して、メソッドを実行する。例えば、メソッド呼出しがパラメータを利用した場合は、複製されたスコープコンテキストからこれらのパラメータにアクセスすることができる。次いでメッセージ消費側140は、メソッド実行の結果を応答メッセージに変換し、これをモジュールBのローカルアドレス空間でキューに入れることができる。次いでシステム100は、応答メッセージをモジュールAのローカルアドレス空間に転送することができる。システム100は、モジュールB中でのメソッド実行中に関連スコープコンテキストに対して加えられたどんな変更も、後で詳述する3つの複製メカニズムのうちの1つを使用してモジュールAのローカルアドレス空間に暗黙的に複製し返すことができる。やはりステップS209とS210は並行して行われてよい。次いでメッセージ作成側110または120は、モジュールAのアドレス空間中のスレッドによって応答メッセージをキューから取り出すことができ、モジュールAの実行が再開される。メッセージをキューから取り出すスレッドは、メソッド呼出しを開始したスレッドと同じスレッドでないことがあるが、元のスレッドと同じスレッドコンテキストを有する必要があることがある。モジュールAをさらに実行する間、どんな関連スコープコンテキストにも、モジュールAによってアクセスすることができる。このようなコンテキストに割り振られたリソースに対してモジュールB上でのメソッド呼出し中に加えられたどんな変更も、モジュールAから見える。システム100は、インバウンドキュー1406などのキューを使用して非同期通信することができる。図3に、キューを使用した例示的な非同期通信300を示す。図3に示すように、モジュール301が、メッセージ302をキュー303に送ることができる。次いでモジュール304が、メッセージ302を消費することができる。メッセージ302を消費した後、モジュール304は、メッセージ302の消費をモジュール301に肯定応答することができる。メッセージ302は、ポイントツーポイントメッセージとすることができる。すなわち、メッセージ302は、ちょうど1つの消費側を有することができる。さらに、モジュール301とモジュール304とは、ネットワークを介して接続された異なるコンピュータ上に位置することができる。メッセージングインフラストラクチャは、最低1回保証の配信、または順番にちょうど1回保証の配信など、メッセージ配信についての様々なサービス品質をサポートすることができる。このようなサービス品質は、トランスポート層におけるいくつかのネットワーク伝送エラーを隔離し、それにより、モジュール層からみたリモート通信の透過性を高める。システム100は、トピックを使用して非同期通信することができる。トピックは、ある基準を満たすメッセージをそれにパブリッシュすることのできる構造である。図4に、トピックを使用した例示的な非同期通信400を示す。図4に示すように、モジュール401は、メッセージ402をトピック403にパブリッシュすることができる。モジュール404および405は、トピック403に申し込むことができる。すなわち、モジュール404および405は、トピック403にパブリッシュされたメッセージを受け取りたいことを示すことができる。次いでトピック403は、メッセージ402をモジュール404および405に配信することができる。非同期通信400によるいくつかの実施形態では、モジュール404および405は、メッセージ402の消費を肯定応答しない。本発明による実施形態は、非同期通信をデフォルトのメカニズムとして使用して、システム100中で実行される種々のモジュールを分離することができる。このような全ての実施形態では、非同期通信の使用が参加モジュールに対してトランスペアレントのままであるように、非同期通信をシステム100に組み込むことができる。非同期通信は、図示の粗粒モジュール間、またはシステム100の内容を定義する種々のモジュール間における任意のメッセージについて行うことができるが、そうする必要があるわけではない。同期通信をモジュール間通信に使用すると、モジュール間の結合度が増すことがあり、本発明で述べる様々な技法の適用可能性が低下することがある。しかし、同期通信の使用は、本発明のコンテキストでは、例えばモジュール間の高頻度の対話に対する性能を改善するための、一時的な最適化に過ぎないと考えられる。特に、これはいつでもデフォルトの非同期通信で置換することができ、それにより、再びモジュール間の結合を低減し、本発明で述べる様々な技法の使用を可能にすることができる。メソッドを非同期で呼び出す決定は、厳密に、モジュール開発者によってではなくシステム管理者によって行われる管理上の決定とすることができる。その場合、この決定は、メッセージ作成側110および120またはメッセージ消費側140を再起動せずに、実行時に行うことができ、また覆すこともできる。スコープ階層およびスコープタイプスコープインスタンスは、しばしば階層に編成される。図5に、例示的なスコープインスタンスの階層500を示す。子スコープインスタンスがその親スコープインスタンスよりも長生きしないという制約を階層が満たす限り、階層の正確な形は、本発明の一実施形態において構成可能とすることができる。階層500中で、スコープインスタンス510は、スコープインスタンス510に割り振られたリソース512および513を含むコンテキスト511を有することができる。スコープインスタンス510は、子スコープインスタンス520および530に対する親としての働きをすることができる。子スコープインスタンス520は、子スコープインスタンス520に割り振られたリソース522および523を含むコンテキスト521を有することができる。同様に、子スコープインスタンス530は、子スコープインスタンス530に割り振られたリソース532および533を含むコンテキスト531を有することができる。子スコープインスタンス530はまた、それ自体のコンテキスト541ならびに割り振られたリソース542および543を有する親スコープインスタンス540の子とすることができる。子スコープインスタンス530はまた、それ自体のコンテキスト551ならびに割り振られたリソース552および553を有する子スコープインスタンス550の親としての働きをすることができる。階層は、参加スコープインスタンスのそれぞれの識別に依拠して、親から子へ、および子から親へナビゲート可能とすることができる。本明細書で論じるスコープは、いくつかのタイプのスコープのいずれかとすることができる。以下のTable1に、本発明による例示的なスコープタイプを列挙する。Table1は、網羅的でも必須でもない。本発明による一実施形態は、所与のビジネス問題を解決するために適切と見なされる場合には、追加のスコープタイプを定義することができ、あるいはTable1からいくつかのスコープタイプを省くことを選択することができる。例えば、バッチ処理システムがバッチスコープタイプを定義することができ、また、バッチシステムは通常はクライアントからのどんな要求にもサービスしないので、要求スコープタイプの使用を控えることができる。Table1中のいくつかのスコープタイプは、いずれか所与の個別ノードの寿命を超えることがあることに留意されたい。例えば、ユーザスコープまたはクラスタスコープは、それらが最初に生み出された場であるノードが消滅したとしても、存続することができる。このような長生きするスコープタイプは、特定のノードに固定されないことを示すために仮想スコープタイプと呼ぶことができる。仮想スコープタイプは、メッセージ作成側110および120ならびにメッセージ消費側140などの複数のノードを包含する単一のスコープインスタンスによって表すことができる。他のスコープインスタンスと同様、仮想インスタンスは、大域的に一意である単一のIDを有することができる。しかし、非仮想スコープインスタンスとは対照的に、仮想スコープインスタンスは、全て並行してアクセス可能なメッセージ作成側110および120ならびにメッセージ消費側140などの種々のノード上の複数のコンテキストインスタンスによって表すことができる。システム100は、種々のノード上で仮想スコープの複数のコンテキストインスタンスを同期的に維持して、どんなデータ破損も回避することを担うことができる。これは例えば、競合のない方式で仮想スコープインスタンスのコンテキストインスタンスを更新するために依拠することのできる中央ロックサービスを提供することによって、達成することができる。Table1の様々なスコープタイプのインスタンスは、階層に編成することができる。スコープインスタンスの階層は、実行時に動的に変化することがある。要求が完了したとき、対応する要求スコープインスタンスは、その全ての子と共に階層から除去される。この動的なスコープインスタンス階層はそれでもなお、展開時に構成することのできる明確に定義された安定したタイプ構造に依拠することができる。このタイプ構造が定義された場合は、このタイプ構造により、所与のタイプのスコープインスタンスは常に、階層の自由裁量レベルで挿入されるのではなく、階層中のいくつかの固定スコープタイプの親と子との間に挿入されるようになる。したがって、タイプ構造は、実行時の動的な階層全体のよりよい構造およびよりよい管理可能性に大きく貢献する。スコープおよびリソースのライフサイクル階層500のスコープインスタンスは、様々なタイプのスコープを表すことができる。例えば、リソースマネージャ1105、1205、および1405は、所与のユーザについての、かつ、このユーザのセキュリティ領域内の全てのコンピュータインフラストラクチャインスタンスにわたる、全てのクライアントスコープインスタンスの親であるユーザスコープインスタンスを共同で維持することができる。同時に、リソースマネージャ1105、1205、および1405のうちの1つは、単一のコンピュータインフラストラクチャインスタンス上で、このユーザのクライアントスコープインスタンスの親としてのアプリケーションスコープインスタンスを維持することができ、したがって、アプリケーションセッションが通常はユーザとアプリケーションとの組合せによって所有されることを反映することができる。リソースマネージャ1105、1205、および1405のうちの1つが親スコープインスタンスのうちの1つを明示的または暗黙的に解放したときは、この親の全ての子スコープインスタンスもまた解放することができる。例えば、ユーザがサインアウトしたとき、ユーザのセキュリティ領域中の全てのリソースマネージャは、関連するユーザスコープインスタンスを解放することができ、リソースマネージャ1105、1205、および1405はそれぞれ、各々システム110、120、および140上のこのユーザの全てのクライアントスコープを解放することができる。メッセージ作成側110上でアプリケーションを閉じると、この作成側上で生きているこのアプリケーションについての全てのクライアントセッションの解放をトリガすることができるが、メッセージ作成側110上の他のアプリケーションのどんなクライアントセッションも、またメッセージ作成側120またはメッセージ消費側140上で実行されているどんなアプリケーションのどんなクライアントセッションも、そのままにされる。メッセージ作成側110は、後でより詳細に論じるように、クリーンアップの前にクライアントスコープインスタンスのコンテキストを異なるメッセージ作成側に複製することによって、ユーザが異なるノード上でアプリケーションについてのクライアントセッションをトランスペアレントに再開するのを可能にすることができる。システム100は、リソース管理モジュール1105、1205、および1405のうちの1つまたは複数を使用して、1つまたは複数のスコープインスタンス510、520、530、540、および550に対して、定義された寿命を強いることができる。例えばタイムアウトのせいでまたは親がその寿命の終わりにあるせいで、スコープインスタンスがその寿命の終わりにあるとシステム100が決定したとき、システム100は、スコープインスタンスの寿命の間にこのコンテキスト中で割り振られていたどんなリソースも共に、スコープインスタンスを解放することができる。仮想スコープインスタンスの場合、スコープインスタンスのクリーンアップをトリガしたメッセージ作成側110および120ならびにメッセージ消費側140のうちの1つはまた、任意の関連するコンピュータインフラストラクチャインスタンスに、このスコープインスタンスのどんなコンテキストもクリーンアップするよう通知することができる。開発者は、例えば既存のクライアントスコープインスタンスを削除することによって、任意の時点でいくつかのスコープインスタンスを手動で解放するオプションを有することができる。加えて、開発者は、後述するようにリソース昇格を実施することによって、リソースがその最初のスコープインスタンスの寿命を超えて利用可能のままであるようにすることができる。いくつかの実施形態では、開発者はまた、所与のスコープのタイムアウト値をリセットすることによって、所与のスコープインスタンスのライフサイクルが延長されるよう要求することができる。しかし、このような要求がメッセージ作成側110もしくは120またはメッセージ消費側140によって許可された場合、この要求は、開発者がメッセージ作成側110もしくは120またはメッセージ消費側140のインフラストラクチャを通したスコープインスタンスのライフサイクル管理を迂回しないようにするために、定義された期間のみにわたって有効とすることができる。リソース管理モジュール1105、1205、または1405は、既存のリソースを新しいまたはより広いスコープインスタンスに昇格させることができ、これによりリソースは、その前のスコープインスタンスから除去されてよい。例えば、最初に要求スコープインスタンス中で割り振られたオブジェクトを、クライアントスコープインスタンスに昇格させて、このオブジェクトがクライアントからの次の要求に対して引き続き利用可能であるようにすることができる。別の例は、それ自体のメソッドスコープインスタンス中で実行されるメソッド呼出しの外部で戻り値または例外を公開することである。この戻り値または例外を使用して、最初にメソッドのスコープインスタンスの内部で割り振られていた任意の関連する結果をメソッドの呼出し元に渡すことができる。これにより、これらの結果は、メソッドのスコープインスタンスの終わりを生き延びることができ、メソッドスコープインスタンスの親に移動することができる。リソース昇格は、スコープ階層500の内部でのみ可能とすることができ、リソースの可視性を高めることができる。リソース管理モジュール1105、1205、および1405は、短命のスコープインスタンスを、それらの寿命が終わったときに解体することができ、それにより、そのスコープ中で割り振られた全てのリソースを解放することができる。いくつかの長命のスコープインスタンスの場合、メッセージ作成側110または120あるいはメッセージ消費側140は、このスコープインスタンスの寿命が終わる前に明示的なリソース割振り解除を開発者が要求できるようにしてよい。これは、対応するスコープタイプ上、例えばクライアントまたはアプリケーションスコープタイプ上で公開される専用APIによって達成することができる。一実施形態では、スコープインスタンスを、実行時のオブジェクトインスタンスによって表すことができる。例えば、セッションスコープインスタンスを、Java登録商標エンタープライズエディションサーブレットスタンダードの場合のように、セッションスコープオブジェクトインスタンスによって表すことができる。多くの並列セッションスコープインスタンスがある可能性があるので、実行時に多くの並列セッションスコープオブジェクトインスタンスがある可能性もまたある。このスコープオブジェクトは、このスコープオブジェクトインスタンスの寿命を終わらせるためのメソッドなど、任意の当事者が使用するためのいくつかのAPIを公開する。特に、スコープオブジェクトはまた、このスコープインスタンス中で現在生きておりしたがってスコープオブジェクトインスタンスの内部コンテキストの一部として記憶されているリソースを割振り解除するためのメソッドを公開することができる。開発者がこのメソッドをオブジェクトインスタンス上で呼び出して、割振り解除するリソースへの参照を渡した場合は、リソースはスコープオブジェクトインスタンスから明示的に除去される。データを除去するための明示的なAPIを公開しない長命のスコープタイプの場合、対応するスコープインスタンスのコンテキストは、リソース管理モジュール1105、1205、および1405によって必要に応じてクリーンアップすることができる。特に、いくつかの長命のスコープは、参照カウンティングに基づく通常のトラディショナルガベージコレクションの恩恵を受けて、使用されない記憶域を解放することができる。コンテキスト複製リソース管理モジュール1105、1205、および1405は、それぞれのインフラストラクチャの所与のインスタンス内部のリソースを管理することを超えて、スコープコンテキストを使用してメッセージ作成側110および120とメッセージ消費側140との間で関連データグループをトランスペアレントに共有することができる。図6Aに、メッセージ作成側110および120とメッセージ消費側140との間でコンテキストデータをトランスペアレントに共有するための例示的なメッセージ600を示す。メッセージ600は、メッセージヘッダ610およびメッセージペイロード620を含むことができる。メッセージヘッダ610は、例えば相関ID611および他のヘッダ612を含むことができる。メッセージペイロード620は、例えばターゲットオブジェクトID621、ターゲットメソッド名622、およびまたは1組のメソッド呼出しパラメータ623を含むことができる。一実施形態では、メッセージに関連するスコープについてのコンテキスト630が、メッセージ600に添付されるかまたは含まれてよい。コンテキストは、メッセージに関連するスコープに割り振られたリソース631および632を含むことができる。これにより、メッセージ作成側110および120とメッセージ消費側140とが、関係するデータグループをそれらの間でトランスペアレントに共有するのを可能にすることができる。したがって、本発明のこの実施形態は、ソースシステムとターゲットシステムとの間の進行中の要求に依拠して全ての当事者間でコンテキストデータをトランスペアレントに共有し、この実施形態は、コンテキストインスタンスが少量のデータしか含まない場合に適切とすることができる。図6Bに、それぞれのメッセージヘッダ610および650中の相関ID611および651によって要求メッセージ600と論理的に関連付けることのできる、対応する応答メッセージ601を示す。メッセージヘッダ650は、他のヘッダ652も含むことができる。応答メッセージは、メソッド呼出しの結果を発信側システムに搬送し返す。すなわち、メッセージペイロード640は、メソッド呼出し結果641を含むことができる。一実施形態では、スコープについてのコンテキスト630がメッセージ601に添付されるかまたは含まれてよい。このコンテキストは、メッセージ600に添付されたコンテキスト630と同じ論理識別を有するが、ターゲットシステム上でのメソッド呼出しの処理中に割り振られた修正済みのまたは新しいリソースを含んでもよい。すなわち、コンテキスト630は、修正済みリソース631、未修正リソース632、およびまたは新しいリソース633を含むことができる。図7に、スコープ複製のいくつかの代替実施形態を示す。これらの実施形態は、帯域外コンテキスト複製に依拠する点で共通し、コンテキストインスタンスが多量のデータを含む場合には前述のメッセージベースの手法よりも適切とすることができる。例えば、リソース管理モジュール1105は、クライアントスコープインスタンスのコンテキストを、予備のメッセージ作成側710、メッセージ消費側140、またはデータベース720に、事前対応的に複製することができる。最初のコピーの後は、後続の複製の手間は、最新の変更をコンテキストの様々なコピーに同期させることに限定することができ、したがって、転送されるデータの量を低減することができる。メッセージ作成側110は、通信ネットワーク130を介して、データベース720、メッセージ消費側140、および予備のメッセージ作成側710と通信することができる。メッセージ作成側710は、メッセージ作成側110と同様の構造とすることができ、例えばプロセッサ7101と、スレッド7102と、コンテキスト1106の複製7106をモジュール1104のコピー7104と共に記憶するためのメモリ7103とを備え、複製7106とコピー7104は両方ともリソース管理7105によって管理される。複製7106は、リソース1107の複製7107、およびリソース1108の複製7108を含むことができる。同様に、データベース720は、リソース複製7202とリソース複製7203とを含むコンテキスト複製7201を記憶することができる。スコープインスタンス中の個別の要素を、オンデマンドでメッセージ消費側140に複製することもできる。この手法は、スコープインスタンス全体よりも少ない何らかがメッセージ消費側140上で必要な場合に、使用することができる。例えば、子スコープインスタンスがメッセージ作成側110からメッセージ消費側140に複製済みであって、階層500中のその親のうちの1つの個別の要素を参照するときは、これらの要素もまたメッセージ消費側140上で利用可能にする必要がある。これらの参照は、親スコープインスタンスの個別のノードをターゲットとするだけなので、親スコープインスタンスのコンテキスト全体の複製は、性能の理由で得策ではない場合がある。このような場合、メッセージ消費側140は、親スコープの個別の要素をメッセージ作成側110にオンデマンドで要求することを選択することができる。スコープコンテキストを複製しても、元のスコープインスタンスの寿命は延長されないものとすることができる。そうではなく、ただ元のスコープコンテキストのリソースのコピーを含む、それ自体の独立したライフサイクルを有する2次スコープコンテキストを生み出すことができる。これは、スコープ階層500の全体構造および所有権関係を維持するのに必要であることがある。上の例では、予備のメッセージ作成側710上の複製されたクライアントスコープコンテキストは、それ自体のライフサイクルを有することができる。特に、予備のメッセージ作成側710が管理上の理由でシャットダウンされた場合、複製されたクライアントスコープコンテキストもまた閉じられる必要があることがある。これは、どんな形でも起源スコープインスタンスに影響を及ぼさないものとすることができるが、例外として、起源スコープインスタンスをホストするコンピュータは、新しい予備のノード上に別の複製クライアントスコープインスタンスを生み出す必要があることがある。トランスペアレントな分散およびモジュール更新メッセージ作成側110が突然死んだ場合、クライアントは、フェイルオーバ処理中にメッセージ作成側710上で生み出された新しいクライアントスコープインスタンスから、複製されたコンテキスト7106にアクセスすることによって、予備のメッセージ作成側710上でその作業を継続することができる。新しいクライアントスコープインスタンスはまた、データベース720の複製されたコンテキスト7201にアクセスすることによって、メッセージ作成側110上の失敗したコンテキストの内容をロードすることができる。トランスペアレントな分散のために、メッセージ作成側110は同様に、コンテキスト1106に関連するスコープインスタンスを有するメッセージをメッセージ消費側140が処理できるように、コンテキスト1106を帯域外複製によってメッセージ消費側140に複製することができる。図8に、本発明による、クライアント要求の終端間処理のために負荷を分散させるプロセスを示す。クライアント要求は、例えばHTTP要求を含むことができる。要求処理負荷を分散させるために、ロードバランサが、クライアントから要求を受信し、入来要求の発送先としての適切なメッセージ作成側110または710を決定することができる。ロードバランサは、この決定を行うために、ロードバランサの以前のルーティング決定に関する知識、ルーティングポリシ、利用可能な各メッセージ作成側の現在の負荷、ならびに利用可能なメッセージ作成側のスケジュールされたダウンタイムなど、その現在の構成および内部アルゴリズムに依拠することができる。選択されたメッセージ作成側110または710は、ロードバランサから要求を受信し、要求の処理を開始する。この処理中、メッセージ作成側110または710は、ローカルまたはリモートモジュール中のオブジェクト上の様々なメソッドを呼び出すことを選択することができる。これらのメソッド呼出しの実施の詳細は、図2に概説したステップに従い、それにより、リモートモジュールを呼び出すときであっても、高い程度のネットワーク透過性を保証する。例えば、メッセージ作成側110または710は、この能力を利用して、それ自体では現在扱うことのできないいくらかの負荷を他のシステムに移すことができ、あるいは、メッセージ作成側110または710以外のネットワーク中の専用システムインスタンスにクリティカルプロセスを限定する何らかのセキュリティ制約を施行することができる。要求処理の間、メッセージ作成側110または710はまた、以下および図10に概説するステップに続いて、モジュール1104または7104の実行をリフレッシュすることを選択することができる。要求の処理を完了した後、応答が、ロードバランサに返され、そこからクライアントに返される。実際の要求処理とは独立に、メッセージ作成側110および710、メッセージ消費側140、またはデータベース720は、バックグラウンドでアクティブであることができ、それにより、図7で述べた帯域外コンテキスト複製メカニズムに続いて全てのスコープコンテキストインスタンスがこれらの異なるシステム間で同期されたままであるようにすることができる。特にこれは、要求処理中に修正されたコンテキストインスタンスに適用されてよく、それにより、これらのシステムのうちの1つの、起こり得る突然の停止の影響が最小限に抑えられるようにすることができる。やはり実際の要求処理とは独立に、これらの各システムは、各システムの現在利用可能な容量に応じて、新しい入来クライアント要求からより多くのまたはより少ない負荷が割り当てられるように、ロードバランサに要求することができる。図9に、本発明による、メッセージ処理の負荷を分散させるための別のプロセスを示す。メッセージ作成側110は、すでにクライアントからの所与の要求を処理している間でも、メッセージ作成側110が過負荷かどうか判定することができる。メッセージ作成側110が過負荷でないと判定した場合は、メッセージを処理し応答を送信することによって、メッセージ作成側110上で通常通り処理を継続することができる。メッセージ作成側110が過負荷であると判定した場合は、メッセージ作成側110は、メッセージ11010、およびメッセージに関連するスコープについてのコンテキスト1106を、別のメッセージ作成側710に転送することができる。次いでメッセージ作成側710は、コンテキスト1106のコピー7104を使用してメッセージ11010を処理することができ、その後、要求に対する応答をロードバランサに直接返すことができる。同様のメカニズムにより、すでに所与の要求を処理しているメッセージ消費側140は、負荷を別のメッセージ消費側に動的に移すことができる。図10に、本発明による、システム100がオンラインのままである間にモジュールを更新するための例示的なプロセスを示す。モジュール1404などのモジュールを更新する必要があると判定されたとき、メッセージ消費側140は、モジュール1404によるキュー1406からのメッセージ消費を一時停止することができる。次いで、キュー1406は、メッセージ消費側140がモジュール1404を更新する間に、入来メッセージをキューイングし続けることができる。モジュール1404が更新された後、モジュール1404は、キュー1406からのメッセージの処理を再開することができる。キュー1406がメッセージでオーバーフローしない限り、モジュール1404の更新は、メッセージ作成側110および120に対してトランスペアレントのままとすることができる。加えて、モジュール1404によるメッセージの処理が再開できる前に、メッセージ消費側140は、キュー1406に記憶されたメッセージが、またはコンテキスト1407および1408に記憶されたリソースのコピーが、更新されたモジュール1404中のタイプ宣言と互換するようにする必要がある。これは、メッセージ処理を再開した後のタイプ互換性エラーを防止するために必要であることがある。実行の変形本明細書に開示するシステムおよび方法は、様々な形に組み入れることができ、例えば、データベースも備えたコンピュータなどのデータプロセッサの形、または、個別ではデータを永続させるどんな能力も持たないかもしれない組込みデバイスのネットワークの形が含まれる。さらに、本発明に関する上記の特徴ならびに他の態様および原理は、様々な環境で実現することができる。そのような環境および関係する適用例は、本発明による様々なプロセスおよび動作を実施するために特別に構築されたものであってもよく、あるいは、コードによって選択的にアクティブ化されるかまたは再構成されて必要な機能を提供する汎用コンピュータまたはコンピューティングプラットフォームを含むものであってもよい。本明細書に開示するプロセスは、どんな特定のコンピュータまたは他の装置にも本質的に関係せず、ハードウェア、ソフトウェア、およびまたはファームウェアの適切な組合せによって実現することができる。例えば、様々な汎用マシンを、本発明の教示に従って書かれたプログラムと共に使用することができ、あるいは、必要とされる方法および技法を実施するための特殊化された装置またはシステムを構築する方がより好都合であることもある。本発明によるシステムおよび方法はまた、本発明の方法およびプロセスに基づく様々なコンピュータ実行可能な動作を実施するためのプログラム命令またはコードを含むコンピュータ可読記憶媒体を含む。媒体およびプログラム命令は、本発明の目的のために特別に設計および構築されたものであってもよく、あるいは、コンピュータソフトウェア技術の当業者に周知かつ利用可能な種類のものであってもよい。プログラム命令の例としては、例えば、コンパイラによって作成されるものなどのマシンコード、および、インタープリタを使用してコンピュータによって実行できる高レベルコードを含むファイルが含まれる。特に明記しない限り、開示した方法における様々なステップは、本明細書に列挙した厳密な順序で実施する必要はない。そうではなく、これらのステップは、当業者に周知のように種々の順序で実施することができる。本発明による可能な実施形態に関する以上の記述は、述べた実施形態の全てのそのような実施形態または全ての変形の包括的なリストを表すものではない。いくつかの実施形態のみに関する記述を、他の実施形態を排除する意図として解釈すべきではない。以下の特許請求の範囲から逸脱しない均等物および代替を使用して、どのように添付の特許請求の範囲における本発明を多くの他の方法で実施するかについては、当業者なら理解するであろう。