ミドルウェアマシンまたは同様のプラットフォームを提供するためのシステムであって、1つ以上のプロセッサと、高性能メモリと、冗長インフィニバンドおよびイーサネットネットワーキングとを含む、高性能コンピューティングハードウェアと、前記ハードウェア上で機能し、1つ以上のアプリケーションサーバインスタンスを含むミドルウェア環境とを備え、前記システムは、ゼロバッファコピー、分散/収集I/O、パラレル多重化T3接続、および/または遅延デシリアライゼーションのうち1つ以上を含み、素早くプロビジョニングすることができかつ要求に応じて拡大縮小できる、システム。前記システムはさらに、Java仮想マシンJVMおよび1つ以上のアプリケーションサーバインスタンスを含むユーザスペースと、前記JVMにアクセス可能な複数のバイトバッファおよび1つ以上のアプリケーションサーバインスタンスとを備え、前記システムは、第1のアプリケーションサーバインスタンスが要求を受けたときに、‐前記要求に関連付けられたデータが前記JVMに関連付けられたヒープスペースに格納され、‐前記JVMが、前記データが格納されるヒープスペースの部分をピニングし、‐前記データが、第1のアプリケーションサーバインスタンスがアクセスする第1のバイトバッファに押し出され、‐第1のアプリケーションサーバが前記データを用いて応答を生成し、‐第1のアプリケーションサーバが前記応答を送信するように、構成されている、請求項1に記載のシステム。前記システムはさらに、各々が1つ以上のプロセッサと高性能メモリとを含む1つ以上の高性能コンピューティングシステムのクラスタを備え、前記クラスタはインフィニバンドネットワーク上で通信し、前記クラスタ上で実行し1つ以上のアプリケーションサーバインスタンスを含むミドルウェア環境と、複数のマルチプレクサとを備え、各アプリケーションサーバインスタンスは少なくとも1つのマルチプレクサを含み、各マルチプレクサは、高性能メモリ内の複数の場所からデータを収集し前記データをまとめて転送するように機能する、請求項1または2に記載のシステム。前記システムはさらに、各々が1つ以上のプロセッサと高性能メモリとを含む1つ以上の高性能コンピューティングシステムのクラスタを備え、前記クラスタはインフィニバンドネットワーク上で通信し、前記クラスタ上で実行し、1つ以上のアプリケーションサーバインスタンスを含むミドルウェア環境と、複数のマルチプレクサとを備え、各アプリケーションサーバインスタンスは少なくとも1つのマルチプレクサを含み、各マルチプレクサは、情報を、複数のスレッドから受信し、前記インフィニバンドネットワーク上で、複数のパラレルチャネルを用いて、異なるアプリケーションサーバインスタンス上の異なるマルチプレクサに送信する、請求項1~3のいずれか1項に記載のシステム。前記システムはさらに、クライアントからセッションに関連付けられた要求を受けるように機能するプライマリアプリケーションサーバを備え、前記プライマリアプリケーションサーバは、前記セッションに関連付けられたセッション情報を保持し前記セッション情報に基づいて前記クライアントに応答し、前記プライマリアプリケーションサーバからシリアライズされたセッション情報を受信し保持するように機能するセカンダリアプリケーションサーバを備え、前記セカンダリアプリケーションサーバは、前記プライマリアプリケーションサーバから受信した1つ以上のセッション更新に基づいて、前記シリアライズされたセッション情報を更新するように機能し、前記セカンダリアプリケーションサーバは、前記更新されたシリアライズされたセッション情報に基づいて、デシリアライズされたセッション情報を生成するように機能し、前記プライマリアプリケーションサーバに障害が生じたときに限り、前記デシリアライズされたセッション情報に基づいてクライアントに応答する、請求項1~4のいずれか1項に記載のシステム。前記システムは、アプリケーションサーバグリッド、ストレージエリアネットワーク、およびインフィニバンドネットワークを提供する、満杯の、2分の1の、もしくは4分の1のラックとしてまたはその他の構成として準備される、請求項1~5のいずれか1項に記載のシステム。前記満杯の、2分の1の、もしくは4分の1のラックまたはその他の構成は、インフィニバンドネットワークを介して互いに通信する、1つ以上の計算ノード、インフィニバンドスイッチゲートウェイ、およびストレージノードまたはユニットを含む、請求項6に記載のシステム。前記ミドルウェア環境は、アプリケーションサーバ、ミドルウェア、ならびに、ウェブロジックサーバ、ジェイロキットまたはホットスポットJVM、オラクルリナックスまたはソラリス、およびオラクルVMといったその他の機能を提供する、請求項1~7のいずれか1項に記載のシステム。ミドルウェアマシンまたは同様のプラットフォームを提供する方法であって、1つ以上のプロセッサと、高性能メモリと、冗長インフィニバンドおよびイーサネットネットワーキングとを含む、高性能コンピューティングハードウェアシステムを準備するステップと、前記ハードウェアシステム上に、1つ以上のアプリケーションサーバインスタンスを含むミドルウェア環境を準備するステップとを含み、前記システムは、ゼロバッファコピー、分散/収集I/O、パラレル多重化T3接続、および/または遅延デシリアライゼーションのうち1つ以上を含み、素早くプロビジョニングすることができかつ要求に応じて拡大縮小できる、方法。前記システムは、Java仮想マシンJVMおよび1つ以上のアプリケーションサーバインスタンスを含むユーザスペースと、前記JVMにアクセス可能な複数のバイトバッファおよび1つ以上のアプリケーションサーバインスタンスとを備え、前記方法は、第1のアプリケーションサーバインスタンスが要求を受けたときに、前記要求に関連付けられたデータをJVMに関連付けられたヒープスペースに格納するステップと、前記JVMが、データが格納されるヒープスペースの部分をピニングするステップと、前記データを、第1のアプリケーションサーバインスタンスがアクセスする第1のバイトバッファに押し出すステップと、第1のアプリケーションサーバが前記データを用いて応答を生成するステップと、第1のアプリケーションサーバが前記応答を送信するステップとを含む、請求項9に記載の方法。前記システムはさらに、各々が1つ以上のプロセッサと高性能メモリとを含む1つ以上の高性能コンピューティングシステムのクラスタを備え、前記クラスタはインフィニバンドネットワーク上で通信し、前記クラスタ上で実行し、1つ以上のアプリケーションサーバインスタンスを含むミドルウェア環境と、複数のマルチプレクサとを備え、各アプリケーションサーバインスタンスは少なくとも1つのマルチプレクサを含み、各マルチプレクサは、高性能メモリ内の複数の場所からデータを収集し前記データをまとめて転送するように機能する、請求項9または10に記載の方法。前記システムは、各々が1つ以上のプロセッサと高性能メモリとを含む1つ以上の高性能コンピューティングシステムのクラスタを備え、前記クラスタはインフィニバンドネットワーク上で通信し、前記クラスタ上で機能し、1つ以上のアプリケーションサーバインスタンスを含むミドルウェア環境と、複数のマルチプレクサとを備え、各アプリケーションサーバインスタンスは少なくとも1つのマルチプレクサを含み、各マルチプレクサは、情報を、複数のスレッドから受信し、インフィニバンドネットワーク上で、複数のパラレルチャネルを用いて、異なるアプリケーションサーバインスタンス上の異なるマルチプレクサに送信する、請求項9~11のいずれか1項に記載の方法。前記方法はさらに、プライマリアプリケーションサーバを、クライアントからセッションに関連付けられた要求を受けるように機能させるステップを含み、前記プライマリアプリケーションサーバは、前記セッションに関連付けられたセッション情報を保持し前記セッション情報に基づいて前記クライアントに応答し、セカンダリアプリケーションサーバを、前記プライマリアプリケーションサーバからシリアライズされたセッション情報を受信し保持するように機能させるステップを含み、前記セカンダリアプリケーションサーバは、前記プライマリアプリケーションサーバから受信した1つ以上のセッション更新に基づいて、前記シリアライズされたセッション情報を更新するように機能し、前記セカンダリアプリケーションサーバは、前記更新されたシリアライズされたセッション情報に基づいて、デシリアライズされたセッション情報を生成するように機能し、前記プライマリアプリケーションサーバに障害が生じたときに限り、前記デシリアライズされたセッション情報に基づいてクライアントに応答する、請求項9~12のいずれか1項に記載の方法。前記システムは、アプリケーションサーバグリッド、ストレージエリアネットワーク、およびインフィニバンドネットワークを提供する、満杯の、2分の1の、もしくは4分の1のラックとしてまたはその他の構成として準備される、請求項9~13のいずれか1項に記載の方法。前記満杯の、2分の1の、もしくは4分の1のラックまたはその他の構成は、インフィニバンドネットワークを介して互いに通信する、1つ以上の計算ノード、インフィニバンドスイッチゲートウェイ、およびストレージノードまたはユニットを含む、請求項14に記載の方法。前記ミドルウェア環境は、アプリケーションサーバ、ミドルウェア、ならびに、ウェブロジックサーバ、ジェイロキットまたはホットスポットJVM、オラクルリナックスまたはソラリス、およびオラクルVMといったその他の機能を提供する、請求項9~15のいずれか1項に記載の方法。1つ以上のコンピュータシステムにロードされこのシステムによって実行されたときに、請求項9~16のいずれか1項に記載の方法を前記1つ以上のコンピュータシステムに実施させる、プログラム可読命令を含む、コンピュータプログラム。請求項17に記載のコンピュータプログラムを格納するコンピュータ可読記憶媒体を含むコンピュータプログラムプロダクト。命令が格納された非一時的コンピュータ可読記憶媒体であって、前記命令がコンピュータによって実行されたときに、前記コンピュータに、1つ以上のプロセッサと、高性能メモリと、冗長インフィニバンドおよびイーサネットネットワーキングとを含む、高性能コンピューティングハードウェアシステムを準備するステップと、前記ハードウェアシステム上に、1つ以上のアプリケーションサーバインスタンスを含むミドルウェア環境を準備するステップとを実施させ、前記システムは、ゼロバッファコピー、分散/収集I/O、パラレル多重化T3接続、および/または遅延デシリアライゼーションのうち1つ以上を含み、素早くプロビジョニングすることができかつ要求に応じて拡大縮小できる、非一時的コンピュータ可読記憶媒体。コンピュータプログラムであって、コンピュータに、1つ以上のプロセッサと、高性能メモリと、冗長インフィニバンドおよびイーサネットネットワーキングとを含む、高性能コンピューティングハードウェアシステムを準備するステップと、前記ハードウェアシステム上に、1つ以上のアプリケーションサーバインスタンスを含むミドルウェア環境を準備するステップとを実施させ、前記システムは、ゼロバッファコピー、分散/収集I/O、パラレル多重化T3接続、および/または遅延デシリアライゼーションのうち1つ以上を含み、素早くプロビジョニングすることができかつ要求に応じて拡大縮小できる、コンピュータプログラム。概要本明細書では、ミドルウェアマシンまたは同様のプラットフォームを提供するためのシステムおよび方法について説明する。ある実施の形態に従うと、このシステム本明細書において実装形態によってはエクサロジックExalogicと呼ぶは、高性能ハードウェアと、アプリケーションサーバまたはミドルウェア環境との組合せを含むことにより、完全なJava登録商標EEアプリケーションサーバ複合体を提供する。この複合体は、大規模並列処理インメモリグリッドを含み、素早くプロビジョニングすることができ、要求に応じて拡大縮小できる。ある実施の形態に従うと、このシステムは、アプリケーションサーバグリッド、ストレージエリアネットワーク、およびインフィニバンドInfiniBandネットワークを提供する、満杯の、2分の1の、もしくは4分の1のラックとしてまたはその他の構成として準備できる。これは、アプリケーションサーバの、ミドルウェアの、または、たとえばウェブロジックWebLogicサーバ、ジェイロキットJRockitJVM、オラクルリナックスLinux登録商標、およびオラクルVMといった他の機能の実行をサポートする。このシステムのさらに他の特徴は、例として、ゼロバッファコピーZeroBufferCopy、分散/収集ScatterGatherI/O、T3接続、および遅延デシリアライゼーションLazyDeserializationを含み得る。詳細な説明上記のように、どのような大きな組織でも、その中では、長年を経て、さまざまな異なるコンピュータハードウェア、オペレーティングシステム、およびアプリケーションソフトウェアを含むITインフラストラクチャが無秩序に拡大していることが多い。このようなインフラストラクチャの個々の構成要素自体は巧みに設計され適切に維持管理されているかもしれないが、このような構成要素を相互に接続、または、リソースを共有しようとすると、それは困難な管理タスクであることが多い。近年、組織の関心は、仮想化およびストレージの集中化といった技術に向けられるようになっており、さらに近年では、共有インフラストラクチャの基礎を提供できるクラウドコンピューティングに向けられている。しかしながら、このような環境に特に適したオールインワンのプラットフォームはほとんどない。これに対し、本明細書では、ミドルウェアマシンまたは同様のプラットフォームを提供するためのシステムおよび方法について説明する。ある実施の形態に従うと、このシステム本明細書において実装形態によってはエクサロジックと呼ぶは、たとえば64ビットプロセッサ技術、高性能大型メモリ、ならびに冗長インフィニバンドおよびイーサネットネットワーキングといった高性能ハードウェアと、ウェブロジックスイートWebLogicSuiteといったアプリケーションサーバまたはミドルウェア環境との組合せを含むことにより、完全なJavaEEアプリケーションサーバ複合体を提供する。この複合体は、大規模並列処理インメモリグリッドを含み、素早くプロビジョニングすることができ、要求に応じて拡大縮小できる。ある実施の形態に従うと、このシステムは、アプリケーションサーバグリッドと、ストレージエリアネットワークと、インフィニバンドネットワークとを提供する、満杯の、2分の1の、もしくは4分の1のラックとしてまたはその他の構成として準備できる。ミドルウェアマシンソフトウェアは、アプリケーションサーバ、ミドルウェア、および、たとえばウェブロジックサーバ、ジェイロキットまたはホットスポットHotspotJVM、オラクルリナックスまたはソラリスSolaris、およびオラクルVMといった他の機能を提供できる。ある実施の形態に従うと、このシステムは、インフィニバンドネットワークを介して互いに通信する、複数の計算ノードと、インフィニバンドスイッチゲートウェイと、ストレージノードまたはユニットとを含み得る。ラック構成として実装される場合、ラックの未使用部分は、空のままでもフィラーfillerによって占められてもよい。このシステムのさらに他の特徴は、例として、ゼロバッファコピー、分散/収集I/O、T3接続、および遅延デシリアライゼーションを含み得る。図1は、ある実施の形態に従うミドルウェアマシン環境100の例を示す。図1に示されるように、各ミドルウェアマシンシステム102は、数個のミドルウェアマシンラック構成要素104を含み、ミドルウェアマシンラック構成要素104は各々、高性能ミドルウェアマシンハードウェアノード106たとえば64ビットプロセッサ、高性能大型メモリ、ならびに冗長インフィニバンドおよびイーサネットネットワーキングと、ミドルウェアマシンソフトウェア環境108との組合せを含む。これにより、数日または数カ月ではなく数分でプロビジョニングすることができ、要求に応じて拡大縮小できる、完全なアプリケーションサーバ環境を提供できる。ある実施の形態に従うと、各ミドルウェアマシンシステムは、満杯の、2分の1の、もしくは4分の1のラックとしてまたはラック構成要素からなるその他の構成として準備することができ、数個のミドルウェアマシンシステムを、ここでもインフィニバンドを用いて連結することにより、より大きな環境を作ることができる。各ミドルウェアマシンソフトウェア環境に、数個のアプリケーションサーバインスタンスまたはその他のソフトウエアインスタンスを設けることができる。たとえば、図1に示されるように、第1のアプリケーションサーバインスタンス109が、仮想マシン116と、オペレーティングシステム120と、仮想化層124と、アプリケーションサーバ層128たとえば、サーブレットServlet132、EJB134、およびグリッドリンクGlidLink136それぞれのコンテナを含むウェブロジックとを含み得るのに対し、第2またはその他のアプリケーションサーバインスタンス110は、仮想マシン116と、オペレーティングシステム120と、仮想化層124と、データグリッド層140たとえばアクティブキャッシュ142を含むコヒーレンスCoherenceとを含み得る。ある実施の形態に従うと、アプリケーションサーバインスタンスは各々、本明細書においてエクサロジック統合integrationパックと呼ぶ、ミドルウェアマシン統合構成要素150を用いて、互いに通信でき、かつ、そのミドルウェアマシンハードウェアノードおよびその他のノード双方とも通信できる。ミドルウェアマシン統合構成要素150自体が、インフィニバンドおよびその他の特徴に対するサポートといったいくつかの最適化特徴を提供し、その各々については以下でさらに詳細に説明する。図2は、ある実施の形態に従うミドルウェアマシンプラットフォームまたは環境の別の例を示す。図2に示されるように、各アプリケーションサーバインスタンスは、ミドルウェアマシン環境内において送信側および/または受信側160、161いずれかとして機能し得る。ある実施の形態に従うと、各アプリケーションサーバインスタンスは、インフィニバンドネットワーク164を介してアプリケーションサーバインスタンスが他のアプリケーションサーバインスタンスと通信できるようにするマルチプレクサ162、163に関連付けられている。図2に示される例では、特定の実装形態に応じて、アプリケーションサーバインスタンスは、ソケットダイレクトプロトコルsocketsdirectprotocol168を含み得るカーネルスペースkernelspace162と、ユーザスペース164と、アプリケーションサーバたとえばウェブロジック166と、JVMたとえばジェイロキット/ホットスポット層170と、WLSコア172構成要素と、サーブレットコンテナ174構成要素と、JSPコンパイラ176構成要素とを含み得る。他の実装形態に従うと、ミドルウェアタイプのソフトウェアおよび構成要素の他の組合せが含まれていてもよい。さまざまな実施の形態に従い、マシン統合構成要素は、ゼロバッファコピー、分散/収集I/O、T3接続、および遅延デシリアライゼーション等の特徴を1つ以上提供することにより、共有されるインフラストラクチャの基礎を提供するとともにこのインフラストラクチャ内での性能を改善することもできる。上記特徴各々については以下でより詳細に説明する。当業者には容易にわかるように、本発明の機能ブロックを、ハードウェアによって、ソフトウェアによって、またはハードウェアとソフトウェアの組合せによって実現することにより、本発明の原理を実施してもよい。図面に記載された機能ブロックを組合わせるまたはサブブロックに分割することにより、上記本発明の原理を実現してもよいことが、当業者に理解される。したがって、本明細書における説明は、本明細書に記載の機能ブロックの任意の可能な組合せまたは分割またはさらに他の定義をサポートし得る。図3は、ある実施の形態に従う、4分の1ラック構成として提供されるミドルウェアマシンの例を示す。図3に示されるように、4分の1ラック構成202として提供される場合、ミドルウェアマシンは、X4170M2サーバノード等の、複数の高性能サーバと、NM2-GWノード等の、1つ以上のインフィニバンドスイッチ/ゲートウェイSwitchGatewayと、MaguroRW-2ノード等の、1つ以上のストレージ構成要素と、Cisco4948スイッチ等の、1つ以上の管理スイッチとを含み得る。ラックの未使用の部分は、空のままでもフィラーによって占められてもよい。図4は、ある実施の形態に従う、2分の1ラック構成として提供されるミドルウェアマシンの例を示す。図4に示されるように、2分の1ラック構成216として提供される場合、ミドルウェアマシンは、同じく、X4170M2サーバノード等の、多数の高性能サーバと、NM2-GWノード等の、1つ以上のインフィニバンドスイッチ/ゲートウェイと、MaguroRW-2ノード等の、1つ以上のストレージ構成要素と、Cisco4948スイッチ等の、1つ以上の管理スイッチとを含み得る。ラックの未使用の部分は、空のままでもフィラーによって占められてもよい。ハードウェア構成要素は、その数がより多いものの、それ以外の点は4分の1ラック構成のハードウェア構成要素と同一である。図5は、ある実施の形態に従う、満杯のラック構成として提供されるミドルウェアマシンの例を示す。図5に示されるように、満杯のラック構成222として提供される場合、ミドルウェアマシンは、より数が多い、X4170M2サーバノード等の、高性能サーバと、NM2-GWノード等の、1つ以上のインフィニバンドスイッチ/ゲートウェイと、MaguroRW-2ノード等の、1つ以上のストレージ構成要素と、Cisco4948スイッチ等の、1つ以上の管理スイッチとを含み得る。ここでも、ハードウェア構成要素は、その数がより多いものの、それ以外の点は4分の1ラック構成および2分の1ラック構成のハードウェア構成要素と同一である。図6は、ある実施の形態に従う、他のシステムおよびネットワークとのインターフェイスのために使用できるミドルウェアマシンプラットフォームまたは環境の例を示す。図6に示されるように、ミドルウェアマシン230の構成が4分の1ラックであるか2分の1ラックであるか満杯のラックであるかにかかわらず、ミドルウェアマシンハードウェア232は、X4170M2サーバノード等の、複数の高性能サーバと、NM2-GWノード等の、1つ以上のインフィニバンドスイッチ/ゲートウェイと、MaguroRW-2ノード等の、1つ以上のストレージ構成要素と、Cisco4948スイッチ等の、1つ以上の管理スイッチとを含み得る。これらは、インフィニバンドを用いて連結され、管理ネットワーク234を用いて管理できる。ある実施の形態に従うと、NM2-GWノード等のインフィニバンドスイッチ/ゲートウェイを用いて、1つ以上のデータセンターサービスネットワーク236への10Gbイーサネット接続を与えることができる。1つ以上の管理スイッチたとえばCisco4948スイッチを用いて、1つ以上のデータセンター管理ネットワーク236への1Gbイーサネット接続を与えることができる。インフィニバンドネットワークを用いて、ミドルウェアマシンを他のミドルウェアマシンにまたはエクサデータExadataマシン240等の他のマシン環境に接続することもできる。ある実施の形態に従うと、ミドルウェアマシン230の構成が4分の1ラックであるか2分の1ラックであるか満杯のラックであるかにかかわらず、ミドルウェアマシンハードウェアおよび/またはソフトウェア環境は、ミドルウェアマシンの性能を改善する、たとえばゼロバッファコピー、分散/収集I/O、T3接続、および遅延デシリアライゼーションといったさらに他の特徴を含み得る。ゼロバッファコピーある実施の形態に従うと、このシステムは、ウェブロジックサーバWLS、ジェイロキットまたはホットスポットJVM、オラクルリナックスまたはソラリス、およびオペレーティングシステムOS等の構成要素におけるバッファコピーを回避するゼロバッファコピーを使用することができる。従来、システムの各層たとえばサーバ層、JVM層、OS層などは、他の層、アプリケーション、およびプロセスがアクセスできない専用メモリスペースを保有する。これは、外部システムが重要なメモリスペースおよびデータを破壊してシステムクラッシュの原因となることがないようにすることによって、システムの全体的な安定性を守るためである。したがって、要求と応答の処理の間、要求および応答に関連するデータは、層と層の間で、専用メモリスペースから専用メモリスペースに、コピーされる。すなわち、所与の層は、データを処理した後、このデータを次の層に押出し、この、次の層は、データをその専用メモリスペースにコピーし、これに対して処理を行ない、次の層に押出す。他の層と層の間でも同じことが行なわれる。しかしながら、本発明の実施の形態は、さまざまな層を密に統合することにより、システムの安定性にとっての危険を高めることなく、これらの層が安全にメモリスペースを共有できるようにする。したがって、このことは、ユーザおよびカーネルスペースにおけるCPUの利用を減らし、故にレイテンシを短縮する。図7は、ある実施の形態に従う、ゼロバッファコピーを提供するためのシステム300を示す。図7に示されるように、アプリケーションサーバ302、ユーザスペース304、およびカーネルスペース306各々に、多数の異なる特徴を与えることができる。サーバレベルでは、バイトバッファを、静的バイト配列および一時バッファの代わりに使用することができる。たとえば、JSPコンパイラは、静的バイト配列の代わりにバイトバッファを使用することができる308。バイトバッファは、補助バイト配列をラップすることによって作成できる。バイトバッファおよび補助バイト配列のうちいずれか一方に対して行なわれた変更は他方に反映される。したがって、処理を行なう各層に対して新たなバイト配列を作成してからこのバイト配列をコピーして次の層のための新たなバイト配列にするのではなく、1つのバイト配列を保存しバイトバッファをこのバイト配列にラップすればよい。各層はバイト配列に対して処理を行なうので、変更はバイト配列に対して適用される。これは、必要なコピーの量を制限し、性能を改善する。同様に、サーブレットコンテナは、一時バッファにコピーする代わりにバイトバッファを使用することができ310、サーバコアは、カーネルレベルチャンクストリームの代わりにバイトバッファ認識ストリームbytebufferawarestreamsを使用することができ312、JVMが、コピーの代わりに固有のメモリをWLSバッファにピニングpinningできるようにする314。メモリをピニングすることにより、JVMは、確実に、メモリがごみ集めgarbagecollectionの対象となったり他のプロセスによって使用されたりしないようにする。このように、データ処理における各段階で、メモリ内のデータへのポインタまたはリファレンスを、各段階でデータをコピーする代わりに、使用することができる。これらの改良により、サーバ層316におけるゼロコピーを実現し、CPUサイクルを少なくし性能を改善する。ある実施の形態に従うと、プラットフォームは、ユーザスペースで実行するJVMからカーネルスペースのネットワークスタックへのバイトバッファデータのコピーを回避するソケットダイレクトプロトコルSDPの使用もサポートする318。これにより、HTTP要求に応じながら、バッファコピーの数をさらに減じる。コピーを回避することにより、CPUサイクルがユーザおよびカーネルスペース双方において少なくなり、したがってHTTPトラフィックのレイテンシが短くなる。代表的な実施の形態では、アプリケーションサーバたとえばウェブロジックサーバを変形することにより、HTTP要求に応えながらゼロバッファコピーを実現することができる。ウェブロジックサーバJSPコンパイラは、静的JSPコンテンツを直接JavaNewI/ONIOバイトバッファに書込むことができる。実行時に、ウェブコンテナは、これらバイトバッファを直接、コピーせずに、バイトバッファ認識ウェブロジックサーバIOストリームに送ることができる。これらバイトバッファを次に、集合書出しgatheredwriteを用いてNIOマルチプレクサによって直接書き出すことができる。エクサロジック上で実行するJVMたとえばジェイロキットまたはホットスポットJVMは、これらバイトバッファをメモリにピニングし、データを固有のメモリにコピーすることを回避する。図8は、ある実施の形態に従う、ゼロバッファコピーの方法のフローチャートを示す。ステップ400で、各々が1つ以上のプロセッサと高性能メモリとを含む1つ以上の高性能コンピューティングシステムが与えられる。ステップ402で、Java仮想マシンJVMと1つ以上のアプリケーションサーバインスタンスとを含むユーザスペースが与えられる。ステップ404で、JVMにアクセス可能な複数のバイトバッファおよび1つ以上のアプリケーションサーバインスタンスが与えられる。ステップ406で、第1のアプリケーションサーバインスタンスが要求を受ける。ステップ408で、この要求に関連付けられたデータが、JVMに関連付けられたヒープheapスペースに格納される。ステップ410で、JVMは、データが格納されているヒープスペースの一部をピニングする。ステップ412で、データは、第1のアプリケーションサーバインスタンスがアクセスする第1のバイトバッファに押出される。ステップ414で、第1のアプリケーションサーバがデータを用いて応答を生成する。ステップ416で、第1のアプリケーションサーバがこの応答を送信する。ある実施の形態に従うと、図8に示される方法はさらに、ソケットダイレクトプロトコルSDPに対するサポートを含むカーネルスペースを与えるステップと、カーネルスペースおよびユーザスペースにアクセス可能な、1つ以上の、バイトバッファ認識ストリームを与えるステップとを含み得る。加えて、図8に示される方法において、各バイトバッファはJavaNewI/Oバイトバッファであってもよい。さらに、要求はHTTP要求であってもよい。また、図8に示される方法において、第1のバイトバッファはヒープスペース内のどこにデータが格納されているかを示すリファレンスを含んでいてもよい。分散/収集I/Oある実施の形態に従うと、システムは、ネットワークパケットの細分化を最小にする分散/収集I/Oを用いることにより、OSがJavaNewI/ONIOの使用に基づいて細分化を行なうことができるようにする。加えて、ある実施の形態に従うと、システムは、最大転送単位MTUが64KBであるインフィニバンド上のインターネットプロトコルInternetProtocoloverInfiniBand属性に基づく。暗黙チャネルは、ClusterMBeanReplicationChannelsからの属性付きのものすべてをコピーする一方で、ポート情報をオーバライドすることにより固有にしておく。オーバライドポート情報は、ServerMBeangetReplicationPortsから得られる。加えて、システムは、複数のチャネルを構成するか否か判断するのに使用できるユーティリティ機能を含み得る。このユーティリティは、構成の変更に応じて、および/またはユーザの指示に従って、この判断を一度、自動的に等間隔で、行ない、その結果を、後のコールに備えてキャッシュすることができる。システムはさらに、構成された各レプリケーションチャネルに対し排他的RMIスタブを作成することができる各接続に割当てられるスタブ。システムは、セッションIDをハッシュすることにより、たとえばラウンドロビンまたはその他同様のバランシングアルゴリズムを用いて、すべてのスタブ間でレプリケーション要求をバランシングする。このシステムはまた、レプリケーションコールを、サーバのために構成されたレプリケーションチャネルのうち1つで確実に受けることができるようにする。ある実施の形態に従うと、インフィニバンドの使用によって従来のシステムよりも大きな帯域幅が得られるので、データを送信できるより大きなパイプが効果的に与えられる。このより大きなパイプをより有効に利用するために、複数のパラレル論理接続すなわちチャネルを、シングル論理接続の代わりに使用することができる。複数の接続は、互いにブロックし合うさまざまな実行スレッドなしで、同時性がより高いアクティビティの実行が可能であることを意味する。これは、たとえばクラスタリングに、すなわち、複数のサーバがクラスタ内で互いに通信する場合に、役立ち得る。クラスタ内では、サーバ間のセッションデータレプリケーションが重要な特徴である。セッションデータは、たとえば、ウェブサイトへの特定の訪問またはセッションに特有のショッピングカートまたはその他のユーザデータである。クラスタ内のサーバ間に複数の接続を用いることにより、各サーバへのインメモリセッションレプリケーションをより確実にかつより効率的に行なうことができる。これは、サーバの障害に備えてセッションデータを格納し、エンドユーザおよびサービスプロバイダの経験を改善する。図14は、ある実施の形態に従う、クラスタ内のサーバ間におけるパラレル多重化を提供するための方法のフローチャートを示す。ステップ800で、1つ以上の高性能コンピューティングシステムのクラスタが与えられる。高性能コンピューティングシステムは各々、1つ以上のプロセッサと高性能メモリとを含み得る。加えて、クラスタはインフィニバンドネットワーク上で通信できる。ステップ802で、クラスタ上で実行するミドルウェア環境が与えられる。ミドルウェア環境は、1つ以上のアプリケーションサーバインスタンスを含み得る。ステップ804で、複数のマルチプレクサが与えられる。各アプリケーションサーバインスタンスは、少なくとも1つのマルチプレクサを含み得る。ステップ806で、第1のアプリケーションサーバインスタンスの第1のマルチプレクサが、情報を複数のスレッドから受信し、第2のアプリケーションサーバインスタンスの第2のマルチプレクサに送信する。ステップ808で、この情報は、インフィニバンドネットワーク上で、複数のパラレルチャネルを用いて、第2のマルチプレクサに送信される。ある実施の形態に従うと、図14に示される方法はまた、ユーザからの入力に基づいて、複数のパラレルチャネルに含まれるパラレルチャネルの数を設定することを含み得る。加えて、送信される情報は、セッションデータを含み得る。さらに、各マルチプレクサはNewI/ONIOマルチプレクサであってもよい。図14に示される方法は、さらに、複数のパラレルチャネル各々についてRMIスタブを作成することを含み得る。サーバクラスタ内でのインメモリセッションレプリケーションある実施の形態に従うと、システムは、遅延デシリアライゼーションという方法を用いて、サーバクラスタ内でのインメモリセッションレプリケーションをサポートすることができる。ミドルウェアマシンプラットフォームまたは環境は、アプリケーションサーバの1つ以上のクラスタを含み得る。システムは、ミドルウェアマシンプラットフォームが高い可用性を提供できるように、使用中の障害から回復することができる。ある実施の形態に従うと、セッション状態をミドルウェアマシンプラットフォームにおいて用いて、重要なユーザセッション情報を記憶する。システムは、インメモリレプリケーションinmemoryreplicationおよびJDBCベースの永続性JDBCbasedpersistenceといった異なる方法を用いて、クラスタ間で、ユーザサービス要求に関連するセッション状態をレプリケートすることができる。システムは、インメモリレプリケーションを使用して、セッション状態を、あるサーバインスタンスから別のサーバインスタンスにコピーする。プライマリアプリケーションサーバは、クライアントが最初に接続するサーバ上にプライマリセッション状態を作成し、クラスタ内の別のサーバインスタンス上にセカンダリレプリカを作成する。レプリカは、プライマリアプリケーションサーバたとえばサーブレットをホストするサーバに障害が生じた場合に使用されることができるよう、最新状態に保たれる。JDBCベースの永続性の場合、システムは、セッション状態たとえばサーブレットまたはJSPのセッション状態を、ファイルベースまたはJDBCベースの永続性を用いて保持する。JDBCベースの永続性は、ワイドエリアネットワークWAN内でのセッション状態レプリケーションにも使用される。ある実施の形態に従うと、システムは、シリアライズステップを行なうことにより、プライマリセッションデータをデータ送信のために変換することができる。シリアライズステップは、データのパラレルな配置といった複雑なデータ構造をシリアル形式に変換するプロセスである。データのパラレルな配置では、一度に多数のビットをパラレルチャネルに沿って送信する。一方、シリアル形式は一度に1ビットずつ送信する。シリアライズセッションデータは、セッション状態のレプリケーションのために何らかのオーバヘッドを導入する。オーバヘッドはシリアライズされるオブジェクトのサイズが大きいほど大きくなる。たとえば、ユーザがHTTPセッションの中で非常にサイズが大きなオブジェクトを作成しようと計画している場合、サーブレットの性能をテストして性能が許容範囲にあることを保証する必要がある。ある実施の形態に従うと、セッションのインメモリレプリケーションをサポートするためには、セッション状態がシリアライズ可能である必要がある。オブジェクトがシリアライズ可能であるとみなされるためには、オブジェクト内のすべてのフィールドが、シリアライズ可能または一時的である必要がある。たとえば、HTTPセッション状態内のすべてのサーブレットおよびJSPセッションデータがシリアライズ可能でなければならない。サーブレットまたはJSPが、シリアライズ可能なオブジェクトとシリアライズ不能なオブジェクトの組合せを使用する場合、システムはシリアライズ不能なオブジェクトのセッション状態をレプリケートしないことがある。ある実施の形態に従うと、セッション状態は、システムが提供する機能を用いて変更できる。たとえば、特殊機能であるHttpSessionsetAttributeを用いて、javaxservlethttpHttpSessionを実装するHTTPサーブレット内のセッションオブジェクトにおける属性を変更することができる。ユーザがsetAttributeを用いてセッションオブジェクトにおける属性を設定する場合、オブジェクトおよびその属性は、インメモリレプリケーションを用いてクラスタ内でレプリケートされる。ユーザが他の設定方法を用いてセッション内でオブジェクトを変更する場合、システムはこういった変更をレプリケートしないことがある。セッション内のオブジェクトに変更がなされる度に、setAttributeを呼び出してそのオブジェクトをクラスタ間で更新することができる。同様に、removeAttributeを用いて属性をセッションオブジェクトから削除することができる。図15は、ある実施の形態に従う、サーバクラスタ内でのインメモリセッションレプリケーションをサポートするシステムの例を示す。図15に示されるように、クライアント901は、プライマリアプリケーションサーバ902とセカンダリアプリケーションサーバ903とを含むサーバクラスタ900と対話できる。プライマリアプリケーションサーバは、ステップ921で、クライアントからセッション911に関連付けられた要求を受け、このセッションに関連付けられたセッション情報912を保持する。プライマリアプリケーションサーバは、セッション情報に基づいてクライアントに対して応答することもできる。さらに、セカンダリアプリケーションサーバは、ステップ922で、プライマリアプリケーションサーバからシリアライズされたセッション情報913を受けて保持するように機能する。ある実施の形態に従うと、クライアントとプライマリアプリケーションサーバとの対話中、プライマリアプリケーションサーバで保持されているセッション情報をステップ924で変更することができる。実行時に、プライマリアプリケーションサーバはこれらセッション更新904をステップ925でセカンダリアプリケーションサーバに送信することができる。また、セカンダリアプリケーションサーバは、プライマリアプリケーションサーバから受けたセッション更新に基づいて、格納されているシリアライズされたセッション情報を更新するように機能する。ある実施の形態に従うと、シリアライズされたセッションデータを、バイナリフォーマットで、たとえば、バイト配列として、セカンダリアプリケーションサーバに格納することができる。システムは、異なるロジックを適用して、シリアライズされたバイナリセッションデータを効率的に更新することができる。ある実施の形態では、システムが、特定のセッション更新の影響を受ける、セカンダリアプリケーションサーバ内のバイト配列におけるエントリを検出する。次にシステムは、バイト配列内のシリアライズされたセッションデータ全体を置換しなくても、直接、バイト配列内の影響を受けたエントリを更新することができる。これは特に、格納されたシリアライズされたセッションデータのサイズが大きいときに有用である。ある実施の形態に従うと、プライマリアプリケーションサーバに障害が生じると、セカンダリアプリケーションサーバが、ステップ923で、更新されたシリアライズされたセッション情報に基づいて、デシリアライズされたセッション情報914を生成するように機能する。セカンダリアプリケーションサーバまたはミドルウェア環境内の別のアプリケーションサーバは、デシリアライズされたセッション情報を用いステップ926でクライアントに応答することができる。ある実施の形態に従うと、システムは、プライマリアプリケーションサーバに障害が生じた場合に限り、デシリアライズステップを実行することによって、インメモリセッションレプリケーションプロセスを最適化することができる。この最適化によって、プライマリアプリケーションサーバが動作している場合には、デシリアライズ動作を防止する。このような最適化により、システムは、すべてのセッション更新について、特にセッション更新が頻繁である場合にCPU利用コストおよびレイテンシオーバヘッドの点で費用がかかる、シリアライズステップをプライマリアプリケーションサーバで行ないデシリアライズステップをセカンダリアプリケーションサーバで行なうことを、回避できる。ある実施の形態に従うと、ユーザはさらに、レプリケーショングループを用いて、セカンダリ状態が位置する場所を制御することができる。レプリケーショングループは、セッション状態のレプリカを格納するのに使用されるクラスタ化されたサーバの優先順リストである。ユーザは、サーバを、レプリケーショングループと、サーバ上に作成されたプライマリHTTPセッション状態のシリアライズされたレプリカをホストするための好ましいセカンダリレプリケーショングル―プとに、割当てることができる。クライアントがクラスタ内のサーバに接続されプライマリセッション状態を作成すると、プライマリ状態をホストしているサーバは、クラスタ内の他のサーバを順位付けして、どのサーバがセカンダリをホストすべきか決定する。サーバの順位は、サーバの場所プライマリアプリケーションサーバと同じマシン上にあるか否かと、プライマリアプリケーションサーバの優先レプリケーショングループのメンバーであるか否かの組合せを用いて、割当てられる。図16は、ある実施の形態に従う、サーバクラスタ内でのインメモリセッションレプリケーションをサポートするための代表的なフローチャートを示す。図16に示されるように、プライマリアプリケーションサーバは、ステップ1001で、セッションに関連付けられた要求をクライアントから受ける。プライマリアプリケーションサーバはまた、セッションに関連付けられたセッション情報を保持し、セッション情報に基づいてクライアントに応答する。次に、ステップ1002で、セカンダリアプリケーションサーバは、プライマリアプリケーションサーバからシリアライズされたセッション情報を受けて保持することができる。ステップ1003で、セカンダリアプリケーションサーバは、プライマリアプリケーションサーバから受けた1つ以上のセッション更新に基づいて、シリアライズされたセッション情報をさらに更新できる。最後に、ステップ1004で、プライマリアプリケーションサーバに障害が生じた場合に限り、更新されたシリアライズされたセッション情報をデシリアライズすることができ、アプリケーションサーバはこのデシリアライズされたセッション情報に基づいてクライアントに応答できる。HTTPセッションレプリケーションクラスタ内でのサーブレットおよびJSPの自動レプリケーションおよびフェイルオーバをサポートするために、システムは、HTTPセッション状態を保持する2つのメカニズム、すなわちハードウェアロードバランサとプロキシプラグインをサポートすることができる。ある実施の形態に従うと、プライマリアプリケーションサーバに障害が発生したとき、ロードバランシングハードウェアは、クライアントからの要求を、アプリケーションサーバクラスタ内で使用可能な任意のサーバに、単純にリダイレクトすればよい。このクラスタは、クライアントのHTTPセッション状態のレプリカを、クラスタ内のセカンダリアプリケーションサーバから、取得できる。図17は、ある実施の形態に従う、ロードバランサを用いてサーバクラスタ内でのインメモリセッションレプリケーションをサポートするシステムの例を示す。図17に示されるように、ステップ1121で、ウェブアプリケーションのクライアント1101が、パブリックIPアドレスを用いてサーブレットを要求すると、ロードバランサ1110は、その構成済みのポリシーに従って、クライアントの接続要求を、アプリケーションサーバクラスタ1100に転送する。ステップ1122で、システムは、この要求を、クライアントのサーブレットセッション状態のプライマリホストとして機能するアプリケーションサーバA1102に転送する。ステップ1123で、システムは、順位付けシステムを用いて、セカンダリアプリケーションサーバB1103を、セッションに関連するシリアライズされたセッション状態をホストするサーバとして選択する。ステップ1124で、クライアントは、アプリケーションサーバインスタンスAおよびB双方の場所をローカルクッキー1111に記録することができる。クライアントがクッキーを許可しなければ、プライマリおよびセカンダリアプリケーションサーバの記録は、URL書換を介してクライアントに戻されるURLに記録できる。クライアントがクラスタに対してさらに要求を行なう場合、ロードバランサは、クライアント側のクッキーにある識別子を用いて、確実に、この要求が、クラスタ内の別のサーバにロードバランスされるのではなく、引続きアプリケーションサーバAに送られるようにする。これにより、クライアントは確実に、セッションが終了するまで、プライマリセッションのオブジェクトをホストしているサーバとの関係を維持する。接続に障害が発生すると、ステップ1125で、ロードバランシングハードウェアは、その構成済みのポリシーを用いて、要求を、クラスタ内で使用可能なサーバに送る。上記の例では、サーバAに障害が発生すると、その後、ロードバランサがクライアントの要求をアプリケーションサーバC1104に送ると想定している。クライアントがサーバCに接続すると、サーバはクライアントのクッキー内の情報を、または、URL書換が使用される場合はHTTP要求内の情報を用いて、サーバBに接続する。アプリケーションサーバCはさらに、ステップ1126で、サーバB上のシリアライズされたセッション状態をデシリアライズすることによってセッション状態をさらに取得することができる。このフェイルオーバプロセスは、クライアントに意識させることはない。デシリアライズステップは、接続障害後一度実行するだけでよい。サーバCはクライアントのプライマリセッション状態の新ホストとなり、サーバBは引続きシリアライズされたセッション状態のホストでありステップ1127でサーバCからセッション更新を受ける。この、プライマリおよびセカンダリホストに関する新情報は、クライアントのクッキー内でまたはURL書換で再び更新される。ある実施の形態に従うと、アプリケーションサーバプロキシプラグインは、クラスタ化されたサーブレットまたはJSPのホストであるアプリケーションサーバインスタンスのリストを保持し、ラウンドロビン方式を用いてHTTP要求をそれらのインスタンスに転送する。このプラグインは、アプリケーションサーバインスタンスに障害が生じた場合に、クライアントのHTTPセッション状態のシリアライズされたレプリカの位置を求めるのに必要なロジックも提供する。図18は、ある実施の形態に従う、プロキシプラグインを用いてサーバクラスタ内でのインメモリセッションレプリケーションをサポートするシステムの例を示す。図18に示されるように、ステップ1221でHTTPクライアント1201がサーブレットを要求すると、HTTPサーバ1210上のHttpClusterServlet1212がプロキシとして機能し、この要求をアプリケーションサーバクラスタ1200に転送する。HttpClusterServletは、クラスタ内のすべてのサーバのリストと、クラスタにアクセスするときに使用するロードバランシングロジックとを保持する。上記の例では、HttpClusterServletは、ステップ1222でクライアントのサーブレットセッションをホストするプライマリアプリケーションサーバになるアプリケーションサーバA1202上でホストされているサーブレットに、クライアント要求を送ることができる。サーブレットのフェイルオーバサービスを提供するために、プライマリアプリケーションサーバは、ステップ1222で、シリアライズされたクライアントのサーブレットセッション状態を、クラスタ内のセカンダリアプリケーションサーバに送る。上記の例では、アプリケーションサーバB1203が、セカンダリアプリケーションサーバとして選択される。サーブレットページは、HttpClusterServletを通してクライアントに返すことができ、クライアントブラウザは、ステップ1224で、サーブレットセッション状態のプライマリおよびセカンダリの場所のリストを有するクッキー1211に書込むよう指示される。クライアントブラウザがクッキーをサポートしないのであれば、アプリケーションサーバはその代わりにURL書換を用いることができる。プライマリアプリケーションサーバAに障害が発生すると、HttpClusterServletは、クライアントのクッキー情報を用いて、セッション状態のレプリカをホストするセカンダリアプリケーションサーバの場所を特定することができる。HttpClusterServletは、ステップ1225で、クライアントの次のHTTP要求をセカンダリアプリケーションサーバに自動的にリダイレクトすることができる。このフェイルオーバはクライアントに意識させることはない。ステップ1226で、サーバBはシリアライズされたセッション状態をデシリアライズすることができ、セッション状態を取得する。この障害後、サーバBがサーブレットセッション状態をホストするプライマリアプリケーションサーバになり、新たなセカンダリを、たとえばアプリケーションサーバC604上に作成することができる。ステップ1227で、サーバCは、シリアライズされたセッション状態をホストし、サーバBからセッション更新を受けることができる。HTTP応答では、プロキシはクライアントのクッキーを更新して新たなプライマリおよびセカンダリアプリケーションサーバを反映させ、今後のフェイルオーバの可能性に備える。クラスタ間でのセッションレプリケーションある実施の形態に従うと、アプリケーションサーバは、クラスタ内のサーバ間でのHTTPセッション状態レプリケーションに加えて、複数のクラスタ間でHTTPセッション状態をレプリケートする機能を提供する。これにより、クラスタを複数の地理的領域、送電網、およびインターネットサービスプロバイダに分散させることによって、高い可用性および耐障害性が改善される。図19は、ある実施の形態に従う、サーバクラスタ間でのインメモリセッションレプリケーションをサポートするシステムの例を示す。図19に示されるように、クラスタ間でのレプリケーションをサポートするネットワーク構成において、グローバルロードバランサ1302は、クラスタ1305とクラスタ1306との間でHTTP要求をバランシングする役割を果たす。ステップ1311で、クライアント1301からの要求を受けると、グローバルロードバランサは、各クラスタが現在扱っている要求の数に基づいて、要求をいずれのクラスタに送るかを決定する。次に、要求は、ステップ1312または1313で、選択されたクラスタのローカルロードバランサ1303または1304に送られる。ローカルロードバランサは、グローバルロードバランサからHTTP要求を受けると、ステップ1314または1315で、クラスタ内のサーバ間でHTTP要求をバランシングする役割を果たす。セッションデータを1つのクラスタから別のクラスタにレプリケートするために、レプリケーションチャネル1310を、プライマリクラスタからセカンダリクラスタにセッション状態情報を伝えるように構成することができる。レプリケーションチャネルは、クラスタ間のレプリケーショントラフィック専用のネットワークチャネルであってもよい。クラスタ内のサーバに障害が発生すると、ローカルロードバランサは、要求をクラスタ内の他のサーバに転送する役割を果たす。クラスタ全体に障害が生じた場合、ローカルロードバランサはHTTP要求をグローバルロードバランサに返す。グローバルロードバランサは次にこの要求を他のローカルロードバランサにリダイレクトする。本発明は、1つ以上のプロセッサ、メモリ、および/または本開示の教示に従いプログラムされたコンピュータ可読記憶媒体を含む、従来の汎用または専用デジタルコンピュータ、コンピューティングデバイス、マシン、またはマイクロプロセッサを1つ以上用いて、適宜実現し得る。適切なソフトウェアコーディングは、熟練したプログラマが本開示の教示に基づいて容易に準備できる。これはソフトウェア技術の当業者には明らかであろう。実施の形態によっては、本発明は、本発明のプロセスのうちいずれかを実行するためにコンピュータをプログラムするのに使用できる命令が格納された記憶媒体または1つまたは複数のコンピュータ可読記憶媒体であるコンピュータプログラムプロダクトを含む。この記憶媒体は、フロッピーディスク登録商標、光ディスク、DVD、CD-ROM、マイクロドライブ、および光磁気ディスクを含む、任意の種類のディスク、ROM、RAM、EPROM、EEPROM、DRAM、VRAM、フラッシュメモリデバイス、磁気もしくは光カード、ナノシステム分子メモリICを含む、または、命令および/またはデータを記憶するのに適した任意の種類の媒体もしくはデバイスを含み得るものの、これらに限定されない。本発明に関するこれまでの記載は例示および説明を目的として提供されている。すべてを網羅するまたは本発明を開示された形態そのものに限定することは意図されていない。当業者には数多くの変更および変形が明らかであろう。実施の形態は、本発明の原理およびその実際の応用を最もうまく説明することによって当業者が本発明のさまざまな実施の形態および意図している実際の用途に適したさまざまな変形を理解できるようにするために、選択され説明されている。本発明の範囲は、以下の特許請求の範囲およびその均等物によって定められることが意図されている。