JP6621470B2 - 分散コンピューティング環境において実行可能コードの動的配置をサポートするシステムおよび方法 - Google Patents

Description

著作権の表示
この特許文書の開示の一部には、著作権保護の対象となるものが含まれている。著作権者は、特許商標庁の特許ファイルまたは記録に掲載された特許文書または特許開示の複製に対しては異議を唱えないが、その他の場合、すべての著作権を留保する。

発明の分野
本発明は、一般にコンピュータシステムに関し、特に分散コンピューティング環境に関する。

概要
本開示は、分散コンピューティング環境において実行可能コードの動的配置をサポートすることができるシステムおよび方法を記載する。クライアントは、１つ以上のクラスまたは更新クラスのクラス定義を生成する。クラス定義は、シリアル化され、分散コンピューティング環境内のサーバに送信される。分散コンピューティング環境内のサーバは、シリアル化されたクラス定義を受信し、シリアル化されたクラス定義をデシリアル化し、サーバ上で処理されるための１つ以上のクラスまたは更新クラスを生成する。１つ以上のクラスまたは更新クラスは、ラムダ式を表すことができる。さらに、１つ以上のクラスまたは更新クラスは、正しいクラスまたは正しいクラスバージョンが実行され、サーバ上で存在しないクラス定義がシリアル化され、配布されることを保証する一意のＩＤ（識別子）を備える。実行可能コードの動的配置は、サーバノード上でエージェントの実行を可能にする。この場合、エージェントは、そうでなければサーバノードに利用できない新規クラスの定義に依存する。

一実施形態において、本開示は、分散コンピューティング環境においてラムダ式をサポートする方法を説明する。この方法は、サーバを介して、ラムダ式を実装するクラス定義を受信するステップを含む。クライアントは、ラムダ式を実装するクラス定義を生成し、生成したクラス定義をシリアル化してサーバに送信する。サーバは、受信したクラス定義に基づいて、ラムダクラスを定義する。ラムダ式がクライアント側で更新された場合、更新されたラムダ式を表す新規クラス定義がサーバに送信される。

本発明のこれらのおよび他の目的および利点は、当業者なら、添付図面を参照して、さまざまな実施形態の以下の説明から分かるであろう。

本発明の一実施形態に従った分散データグリッドを示す図である。 本発明の一実施形態に従って、実行可能コードの動的配置をサポートする分散コンピューティング環境を示す図である。 本発明の一実施形態に従って、実行可能コードの動的配置をサポートする方法を示す図である。 本発明の一実施形態に従って、ラムダ式を実装する実行可能コードの動的配置をサポートする分散コンピューティング環境を示す図である。 本発明の一実施形態に従って、ラムダ式を実装する実行可能コードの動的配置をサポートする方法を示す図である。

詳細な説明
本開示は、分散コンピューティング環境において実行可能コードの動的配置をサポートするシステムおよび方法を記載する。分散コンピューティング環境内のサーバノードは、サーバノードを再起動または再配置することなく、クライアントから実行するクラス定義を受信し、受信したクラス定義を用いて、クラスのインスタンスを生成し、メモリにロードすることができる。クラス定義は、そうでなければサーバノードに利用できない新規または更新クラス定義を実装することができる。クラスは、一意のクラスＩＤを用いて特定される。クラスＩＤを用いて、クラスが新規または更新クラスであるか否かを判断することができる。クラスＩＤを用いて、クラス定義をサーバノードに送信する必要性を判断することができ、正しいバージョンのクラスが実装されたことを保証することができる。実行可能コードの動的配置は、サーバノード上でエージェントの実行を可能にする。この場合、エージェントは、そうでなければサーバノードに利用できない新規クラスの定義に依存する。

特定の実施形態において、本開示は、分散コンピューティング環境においてラムダ式を実装するクラス定義の動的配置をサポートすることができるシステムおよび方法を記載する。分散コンピューティング環境内のサーバは、クライアントから１つ以上のクラス定義を受信することができ、クライアントは、ラムダ式を実装する１つ以上のクラス定義を生成する。サーバは、受信したクラス定義に基づいて、サーバ側でラムダクラスを定義することができる。さらに、ラムダ式がクライアント側で更新された場合、更新されたラムダクラスの新規クラス定義が生成され、クライアントからサーバに送信される。

本開示に記載され、図２Ａ、２Ｂ、３Ａおよび３Ｂに示されるように、ラムダ式を実装するクラス定義の動的配置を含む実行可能コードの動的配置をサポートするシステムおよび方法は、図１を参照して以下に説明する分散データグリッドに特に有用である。ラムダ式を実装するクラス定義の動的配置を含む実行可能コードの動的配置をサポートするシステムおよび方法は、さまざまな代替的分散コンピューティング環境に適用することもできる。

以下の説明において、本発明は、限定ではなく例示として、添付の図面に示される。本開示において、さまざまな実施形態の言及は、必ずしも同一の実施形態に限定されず、少なくとも１つの実施形態を意味する。特定の実装形態を説明する場合、これらの特定の実装形態は、例示のみの目的で提供されていることを理解すべきである。当業者なら、本発明の範囲および精神から逸脱することなく、他の要素および構成を使用できることを理解するであろう。

場合によって、本発明の完全な説明を提供するように、多数の具体的な詳細を記載する。しかしながら、これらの具体的な詳細がなくても、本発明を実施できることは、当業者にとって明らかであろう。また、場合によって、本発明を不明瞭にしないように、周知の特徴は、詳細に記載されない。

本発明は、特定の機能の実行およびそれらの関係を示す機能性構成ブロックを用いて説明される。これらの機能性構成ブロックの境界は、通常、説明の便宜上、本開示に任意に定義される。したがって、同様の要素によって実行されるように示された機能は、代替的な実施形態において、異なる要素によって実行されてもよい。代替的には、別々の要素によって実行されるように示された機能は、１つの要素によって実行されてもよい。特定の機能およびそれらの関係が適切に実行される限り、代替的な境界を定義してもよい。したがって、これらの代替的な境界のいずれも、本発明の範囲および精神内に含まれる。

共通の参照番号を使用して、図面および詳細な説明における同様の要素を示す。したがって、他の箇所で図示された要素を説明する場合、図面に使用されている参照番号は、必ずしもこの図面に対応する詳細な説明に記載する必要がない。３桁の参照番号のうち、最初の数字は、要素が最初に現れる図面の順番を示す。

分散データグリッド
分散データグリッドとは、分散型環境またはクラスタ化環境において情報および関連作業、例えば演算を管理するために、複数のコンピュータサーバが１つ以上のクラスタに協働して動作するシステムを指す。分散データグリッドを使用して、サーバ間に共有されているアプリケーションオブジェクトおよびデータを管理することができる。分散データグリッドは、短い応答時間、高い処理量、予測可能な拡張性、継続的な可用性、情報の信頼性を提供する。その結果、分散データグリッドは、計算集約型ステートフル中間層アプリケーションの使用に適している。特定の例において、分散データグリッド、例えばOracle（登録商標）Coherenceデータグリッドは、高性能を達成するように情報をインメモリに格納し、その情報のコピーを複数のサーバ間に同期するように冗長性を採用しているため、サーバの故障時に、システムの復元性およびデータの継続的な可用性を確保する。

以下の記載において、分割キャッシュを有するOracle（登録商標）Coherenceデータグリッドを説明する。しかしながら、当業者であれば、本発明の範囲から逸脱することなく、例えば上記の概要に記載された発明を当該技術分野に知られている任意の分散データグリッドに適用することができることを理解するであろう。さらに、本発明の完全な説明を提供するために、Oracle（登録商標）Coherence分散データグリッドの多くの具体的な詳細を記載するが、本発明は、これらの特定の詳細がなくても、分散データグリッドに実施することができる。したがって、いくつかの実施形態において、本発明を具体化する分散データグリッドの特定の実装は、本発明の範囲から逸脱することなく、以下に説明する分散データグリッドの特定の特徴を含まなくてもよく、および／または以下に説明する分散データグリッドの特定の特徴と異なる特徴またはその変更特徴を含んでもよい。

図１は、データを格納し、クライアント１５０にデータの利用を提供する分散データグリッド１００の例を示している。「データグリッドクラスタ」または「分散データグリッド」は、分散型環境またはクラスタ化環境において情報および関連作業、例えば計算を格納および管理するために、１つ以上のクラスタ（例えば、１００ａ、１００ｂ、１００ｃ）に協働して動作する複数のコンピュータサーバ（例えば、１２０ａ、１２０ｂ、１２０ｃおよび１２０ｄ）を含むシステムを指す。分散データグリッド１００は、例として、クラスタ１００ａ内に５つのデータノード１３０ａ、１３０ｂ、１３０ｃ、１３０ｄおよび１３０ｅを有する４つのサーバ１２０ａ、１２０ｂ、１２０ｃおよび１２０ｄを含むものとして図示されているが、任意数のクラスタを含むことができ、各クラスタ内に任意数のサーバおよび／または任意数のノードを含むことができる。分散データグリッドは、高性能を達成するように情報をインメモリに格納し、その情報のコピーを複数のサーバ間に同期するように冗長性を採用しているため、サーバの故障時に、システムの復元性およびデータの継続的な可用性を確保することができる。一実施形態において、分散データグリッド１００は、例えば、上記の概要および以下の詳細な説明に記載される本発明を実現する。

図１に示すように、分散データグリッドは、協働して動作する多数のサーバ（例えば、１２０ａ、１２０ｂ、１２０ｃおよび１２０ｄ）の間にデータを分散することによって、データの記憶および管理機能を提供する。データグリッドクラスタの各サーバは、例えば、１〜２個のプロセッサソケットを備え、各プロセッサソケットに２〜４個のＣＰＵコアを配置した「汎用ｘ８６」サーバハードウェアプラットフォームなどの従来のコンピュータシステムであってもよい。各サーバ（例えば、１２０ａ、１２０ｂ、１２０ｃおよび１２０ｄ）は、例えば、１つ以上のＣＰＵ、ネットワークインターフェイスカード（ＮＩＣ）、および最低４ＧＢ最大６４ＧＢまたはそれ以上のＲＡＭを含むメモリを備えるように構成される。図示されたサーバ１２０ａは、ＣＰＵ１２２ａ、メモリ１２４ａおよびＮＩＣ１２６ａ（これらの要素は、他のサーバ１２０ｂ、１２０ｃ、１２０ｄにも存在するが、図示されていない）を備える。必要に応じて、各サーバは、データあふれ用の記憶容量を提供するために、フラッシュメモリ（例えば、ＳＳＤ１２８ａ）を備えてもよい。ＳＳＤを備える場合、その容量は、好ましくはＲＡＭの容量の１０倍である。データグリッドクラスタ１００ａ内のサーバ（例えば、１２０ａ、１２０ｂ、１２０ｃおよび１２０ｄ）は、高帯域幅のＮＩＣ（例えば、ＰＣＩ−ＸまたはＰＣＩｅ）を介して、高性能（例えば、ギガビットイーサネット（登録商標）またはそれ以上）ネットワークスイッチ１２０に接続される。

故障時にデータを損失する可能性を回避するために、クラスタ１００ａは、好ましくは最低４つの物理サーバを含むが、典型的な実装として、より多くのサーバを含んでもよい。各クラスタに存在するサーバが多くなればなるほど、フェイルオーバ（failover）およびフェイルバック（failback）がより効率的になり、サーバの故障によってクラスタに与える影響が軽減される。サーバ間の通信時間を最短にするために、各データグリッドクラスタは、理想的には、サーバ間にシングルホップ通信を提供する単一のスイッチ１０２に接続される。したがって、クラスタは、スイッチ１０２上のポート数によって制限される。よって、典型的なクラスタは、４〜９６個の物理サーバを含む。

分散データグリッド１００の殆どの広域ネットワーク（ＷＡＮ）構成において、ＷＡＮ内の各データセンタは、相互独立しているが、相互接続されたデータグリッドクラスタ（例えば、１００ａ、１００ｂおよび１００ｃ）を備える。ＷＡＮは、例えば図１に示されたクラスタよりも多くのクラスタを含んでもよい。さらに、相互接続されているが相互独立しているクラスタ（例えば、１００ａ、１００ｂ、１００ｃ）を使用することによって、および／または相互接続されているが相互独立しているクラスタを相互遠隔であるデータセンタに配置することによって、分配型データグリッドは、自然災害、火災、洪水、長期間の電力損失などによって、１つのクラスタ内のすべてのサーバが同時に喪失しないように、安全性のあるデータおよびサービスをクライアント１５０に提供することができる。企業および地区の全体に亘って維持されているクラスタは、企業データの自動バックアップ記憶および高可用性サービスを構成する。

１つ以上のノード（例えば、１３０ａ、１３０ｂ、１３０ｃ、１３０ｄおよび１３０ｅ）は、クラスタ１００ａの各サーバ（例えば、１２０ａ、１２０ｂ、１２０ｃおよび１２０ｄ）上で動作する。分散データグリッドにおいて、ノードは、例えばソフトウェアアプリケーション、仮想マシンなどであってもよく、サーバは、ノードが動作するオペレーティングシステム、ハイパーバイザ（図示せず）などを含んでもよい。Oracle（登録商標）Coherenceデータグリッドにおいて、各ノードは、Ｊａｖａ（登録商標）仮想マシン（ＪＶＭ）である。サーバのＣＰＵ処理能力および利用可能なメモリに応じて、各サーバは、複数のＪＶＭ／ノードを備えてもよい。分散データグリッドの需要に応じて、ＪＶＭ／ノードを起動、停止、追加および削除することができる。Oracle（登録商標）Coherenceを実行するＪＶＭは、起動時に自動的に結合し、クラスタ化する。クラスタに加入したＪＶＭ／ノードは、クラスタメンバまたはクラスタノードと呼ばれる。

Oracle（登録商標）Coherenceデータグリッドにおいて、クラスタメンバは、ＴＣＭＰ（Tangosol Cluster Management Protocol）を使用して通信する。ＴＣＭＰは、クラスタメンバの検出、クラスタの管理、サービスの提供、およびクラスタメンバ間でデータの送信に使用されているＩＰベースプロトコルである。ＴＣＭＰプロトコルは、完全な信頼性で順序通りに、すべてのメッセージを配信する。基礎のＵＤＰ／ＩＰプロトコルが信頼性のある配信または順序通りの配信を提供しないため、ＴＣＭＰは、行列化された完全非同期ＡＣＫおよびＮＡＣＫに基づくメカニズムを使用することによって、信頼性のあるメッセージ配信を行うと共に、一体化された特定のＩＤを使用することによって、サーバ上で動作するＪＶＭに関連して行列化されたメッセージの順序を保証する。ＴＣＭＰプロトコルは、クラスタサイズに関係なく、ＪＶＭ／ノード毎に３つのＵＤＰ／ＩＰソケット（１つのマルチキャスト、２つのユニキャスト）および６つのスレッドしか必要としない。

データグリッドクラスタの機能は、クラスタノードによって提供されたサービスに依存する。クラスタノードによって提供された各サービスは、特定の機能を有する。各クラスタノードは、クラスタサービスの提供およびクラスタサービスの使用の両方の観点から、多くのクラスタサービスに加入することができる（メンバになることができる）。一部のクラスタサービスは、クラスタ内のすべてのノードによって提供されるが、他のサービスは、クラスタ内の１つのノードのみまたは一部のノードのみによって提供される。各サービスは、データグリッドクラスタ内のサービスを一意に識別するサービス名と、行えるサービスを規定するサービス種類とを有する。（ルートクラスタサービスを除き）データグリッドクラスタのノードによって提供された各サービス種類には、複数の名前付きインスタンスが存在することがある。すべてのサービスは、好ましくは、データ損失なしに、フェイルオーバーおよびフェイルバックを提供する。

クラスタノードによって提供された各サービスインスタンスは、通常、１つのサービススレッドを使用して、サービスの特定の機能を提供する。例えば、あるノードによって提供された分散キャッシュサービスは、そのノードの単一サービススレッドによって提供される。ＪＶＭ／ノードで分散キャッシュのスキーマ定義を解析する場合、サービススレッドは、スキーマに指定された名前でインスタンス化される。このサービススレッドは、スキーマ定義を使用して作成されたキャッシュ内にデータを管理する。一部のサービスは、必要に応じて、サービススレッドに追加の処理リソースを提供するように構成することができる作業スレッドのスレッドプールをサポートする。このサービススレッドは、スレッドプール内の作業スレッドと連携して、特定のサービス機能を提供する。

Oracle（登録商標）Coherenceデータグリッドにおいて、クラスタサービス（例えば、１３６ａ、１３６ｂ、１３６ｃ、１３６ｄ、１３６ｅ）は、クラスタ内のメンバシップおよびサービスを追跡する。各クラスタノードは、常に１つのみのこの種のサービスを実行している。クラスタサービスは、自動的に起動して、クラスタノードをクラスタに加入することができる。クラスタサービスは、他のクラスタノードの検出、クラスタノードの故障（停止）の検出、およびクラスタに利用可能な他のサービスの登録を行う。プロキシサービス（例えば、１３８ｃ）によって、クラスタ外部のクライアントは、（例えば、ＴＣＰを使用して）クラスタに接続することができる。呼び出しサービス（例えば、１３４ｄ）によって、アプリケーションコードは、エージェントを呼び出して、クラスタ内の任意のノードまたは任意のノードグループまたはクラスタ全体に亘って、作業を実行することができる。呼び出しサービスおよびプロキシサービスは、図示では各々が１つのみのノードに設けられていると示されているが、分散データグリッド内の任意数のノード上に、最大すべてのノード上に設けられることができる。

Oracle（登録商標）Coherenceデータグリッドにおいて、分散キャッシュサービス（例えば、１３２ａ、１３２ｂ、１３２ｃ、１３２ｄ、１３２ｅ）は、分散データグリッドにデータ記憶を提供し、クラスタ内のノードが記憶不能に設定されても、クラスタ内のすべてのノード上でキャッシュデータの読み取り／書き込み／記憶を行うことができる。分散キャッシュサービスによって、クラスタノードは、クラスタ１００ａの全体にデータを分散（分配）することができる。これによって、キャッシュ内の各データは、主に１つのみのクラスタノードによって管理（保持）される。分散キャッシュサービスは、putおよびgetなどの記憶操作要求を処理する。分散キャッシュサービスは、分散スキーマ定義に定義され、クラスタのノード間に分配された分散キャッシュ（例えば、１４０ａ、１４０ｂ、１４０ｃ、１４０ｄ、１４０ｅ）を管理する。

パーティションは、分散データグリッドに管理されたデータの基本単位であり、分散キャッシュ（例えば、１４０ａ、１４０ｂ、１４０ｃ、１４０ｄおよび１４０ｅ）に格納される。論理的に、データは、基本パーティション（例えば、１４２ａ、１４２ｂ、１４２ｃ、１４２ｄおよび１４２ｅ）に分配される。これらの基本パーティションは、複数のクラスタノードに分散され、クラスタ内の１つのみのノードがキャッシュ内の各データを格納する。各キャッシュ（例えば、１４０ａ、１４０ｂ、１４０ｃ、１４０ｄおよび１４０ｅ）は、複数のパーティションを保持することができる。各パーティション（例えば、１４２ａ、１４２ｂ、１４２ｃ、１４２ｄ、１４２ｅ）は、１つのデータム（datum）を保持することができ、多くのデータムを保持することもできる。パーティションは、必要または要望に応じて、１つのノードのキャッシュから、別のノードのキャッシュに移行することができる。例えば、クラスタにノードを追加する場合、新しく追加されたノードを含む使用可能なノード間にパーティションを分散するように、これらのパーティションを移行する。非複製型の分散データグリッドには、各パーティション（基本パーティション）は、１つのアクティブコピーしか有しない。しかしながら、通常、各パーティションは、１つ以上のレプリカ／バックアップコピーを有する。これらのレプリカ／バックアップコピーは、別のサーバに格納され、フェイルオーバーに使用される。クラスタのサーバ間に分散されたパーティションにデータを分配するため、データを管理する負荷およびデータを利用する負荷は、クラスタの全体に自動的に分散される。

分散キャッシュサービスは、各データが１つ以上の他のクラスタノードによってバックアップされ、データ損失なしにフェイルオーバーをサポートするように構成することができる。例えば、図１に示すように、各データは、基本パーティション（例えば、濃い色の四角形１４２ａ、１４２ｂ、１４２ｃ、１４２ｄおよび１４２ｅ）および同期されたパーティションの１つ以上のバックアップコピー（例えば、薄い色の四角形１４４ａ、１４４ｂ、１４４ｃ、１４４ｄおよび１４４ｅ）に格納される。各パーティションのバックアップコピーは、同期の元である基本パーティションと異なるサーバ／ノードに格納される。ノード上の分散キャッシュサービスのフェイルオーバーは、パーティションのバックアップコピーを基本パーティションに昇格する必要がある。特定のサーバ／ノードが故障した場合、残りのすべてのクラスタノードは、故障したノードの基本パーティションに対応して保持されたバックアップパーティションを決定する。次に、クラスタノードは、任意のクラスタノード上に保持されているバックアップパーティションを基本パーティションに昇格する（その後、新規バックアップパーティションを作成する）。

分散キャッシュは、データオブジェクトの集合である。各データオブジェクト／データムは、例えば、データベーステーブルの一行に等価することができる。各データムは、データムを識別する特定のキーに関連付けられる。各パーティション（例えば、１４２ａ、１４２ｂ、１４２ｃ、１４２ｄ、１４２ｅ）は、１つのデータムを保持することができ、多くのデータムを保持することもできる。これらのパーティションは、クラスタ内のすべてのノード間に分散される。Oracle（登録商標）Coherenceのデータグリッドにおいて、各キーおよび各データムは、ＰＯＦ（Portable Object Format）と呼ばれる効率的な非圧縮バイナリエンコーディングによってシリアル化されたデータオブジェクトとして、格納される。

特定のデータムを探し出すために、各ノードは、キーをパーティションにマッピングするマップ、例えばハッシュマップを有する。このマップは、クラスタ内のすべてのノードに認識され、クラスタのすべてのノード間に同期され、更新される。各パーティションは、パーティションに関連付けられた各キーをそのパーティションに格納された対応のデータムにマッピングするバッキングマップを有する。分散データグリッド内の任意のノードは、クライアントから、特定のキー／データムに関連付けられた作業を受信することができる。ノードが作業を受信すると、キーが受信ノード上の基本パーティションに関連付けられている場合、ノードは、そのキーに関連付けられた値／オブジェクトを直接に利用することができる。キーが受信ノード上の基本パーティションに関連付けられていない場合、ノードは、操作をそのキーに関連付けられた基本パーティションを保持するノードに直接に（シングルホップで）導くことができる。したがって、各ノードは、ハッシュマップおよびパーティションマップを使用することによって、分散キャッシュにおいて、各キーに対応する各データムを直接利用するまたはシングルホップを介して利用することができる。

いくつかのアプリケーションにおいて、分散キャッシュ内のデータは、最初に、データ１１２を含むデータベース１１０から取り込まれる。データベース１１０内のデータ１１２は、シリアル化され、分散データグリッドのノード間に分配され、分散される。分散データグリッド１００は、データベース１１０のデータ１１２から作成されたデータオブジェクトをサーバ１１０ａ、１２０ｂ、１２０ｃ、１２０ｄのメモリ内のパーティションに格納する。これによって、クライアント１５０および／またはデータグリッド１００内のアプリケーションは、メモリからこれらのデータオブジェクトを直接利用することができる。したがって、分散データグリッド１００からデータオブジェクトの読み出しおよび分散データグリッド１００にデータオブジェクトの書き込みは、遥かに高速になり、データベース１１０を直接使用することよりも、多くの同時接続を達成できる。データのインメモリ複製および保証されたデータ一貫性によって、分散データグリッドは、保管および報告のためにトランザクションをデータベース１１０などの外部データソースに長期保存されるまで、メモリ内でトランザクションを管理することができる。メモリ内のデータオブジェクトに変更があった場合、その変更は、基本パーティションとバックアップパーティションとの間に同期された後、非同期書き込み（ライトバック）を用いてデータベース１１０に書き込まれ、ボトルネックを回避する。

データがクラスタノード間に分散されていることにも関わらず、クライアント１５０は、任意のクラスタノードに接続して、任意のデータを取り出すことができる。このことは、位置透明性（location transparency）と呼ばれ、開発者がキャッシュのトポロジーに基づいてコードを作成する必要がない。いくつかの実施形態において、クライアントは、特定のサービス、例えば特定のノード上のプロキシサービスに接続することができる。他の実施形態において、接続プールまたはロードバランサを使用して、クライアントを特定のノードに導くことができ、クライアントの接続を一部またはすべてのデータノード間に確実に分散することができる。どのように接続されても、分散データグリッド内の受信ノードは、クライアント１５０からタスクを受信することができる。各タスクは、特定のデータムに関連付けられているため、特定のノードによって処理されなければならない。ノードは、特定のデータムに対応するタスク（例えば、キャッシュサービスに対するコール）を受信すると、そのデータムを格納するパーティション、およびそのパーティションに対応するノードを特定する。その後、受信ノードは、例えばリモートキャッシュを呼び出すことによって、タスクを要求されたパーティションを保持するノードに導く。各データムが１つのみのクラスタノードにより管理されているため、ネットワークを経由したアクセスは、「シングルホップ」作業である。この種のアクセスは、ポイントツーポイント（point-to-point）通信を使用するので、インフィニバンド（InfiniBand）などのスイッチドファブリックネットワークを最大限に活用することができるため、拡張性が非常に高い。

同様に、キャッシュ更新作業は、同様のシングルホップポイントツーポイント方法を使用して、基本パーティションを備えるノードおよびパーティションのバックアップコピーを備えるノードの両方にデータを送信する。キャッシュに対する変更は、すべてのバックアップから承認応答を受け取るまで完了していないとみなされる。これによって、データの一貫性が維持され、書き込み操作中にクラスタノードが予期せず故障した場合に、データが損失しないことが保証される。また、分散キャッシュサービスは、一部のクラスタノードを、データを格納するように構成することができ、他のクラスタノードを、データを格納しないように構成することができる。

いくつかの実施形態において、必要に応じて、分散データグリッドは、固体記憶装置（例えば、ＳＳＤ１２８ａ）、最も典型的にはフラッシュドライブを利用して、キャッシュに対するデータあふれ用の容量を提供する弾性（伸縮性）データ機構を有するように構成される。弾性データ機構を使用する場合、キャッシュは、ＲＡＭまたはＤＩＳＫジャーナルに基づくバッキングマップを使用するように指定される。ジャーナルは、オブジェクトの状態変化を格納するメカニズムを提供する。各データム／値は、特定のキーに関連して記録され、インメモリ木を使用して、データムへのポインタを格納する（小さなデータム／値は、木に直接格納されてもよい）。これにより、一部の値（データ）を固体記憶装置（例えば、ＳＳＤ１２８ａ）に格納すると共に、索引／メモリ木をメモリ（例えば、ＲＡＭ１２４ａ）に格納することができる。弾性データ機構によって、分散データグリッドは、完全にＲＡＭに基づいた解決策に比べて、性能を殆ど損なうことなく、各ノードにより多くのデータをサポートすることができる。

上述したOracle（登録商標）Coherenceデータグリッドのような分散データグリッドは、データ操作の遅延問題を解決し、リアルタイムでデータをキャッシュおよび処理することによって、システムの性能を改善することができる。アプリケーションは、データをデータグリッドにキャッシュすることによって、高価なバックエンドデータソースを要求することを回避する。共有データキャッシュは、キャッシュされたデータの一貫性のある単一のビュー（view）を提供する。キャッシュからの読み取りは、バックエンドデータソースのクエリよりも高速であり、アプリケーション層の規模に従って変化する。インメモリ実行は、ボトルネックを軽減し、データの競合を減少し、アプリケーションの応答性を改善する。並列のクエリおよび演算をサポートすることによって、データに基づく計算の性能を改善する。分散データグリッドは、故障許容性（フォールトトレラント）を有するため、データの信頼性、正確性、一貫性、高可用性および災害復旧性を実現する。分散データグリッドによって、予測可能なコストで、リソース使用率を改善するように、アプリケーションを線形的に且つ動的に拡張することができる。分散データグリッドは、多くのアプリケーションに、データソースを共有する貴重な解決策を提供する。

分散データグリッド内でコードの実行
実施形態において、分散データグリッドは、エージェントを使用して、分散データグリッドのノード上で処理を実行することをサポートする。区分データの場合、エージェントは、処理するデータを保有するノード（または複数のノード）上で実行するように構成され得る。行列化および並列化の管理、エージェントの実行、エージェントによるデータのアクセス、エージェントによるデータの変更は、すべてグリッドのノード上で行われる（得られたデータに変更があった場合に、データの変更を同期バックアップするときのみ、追加のネットワークトラフィックが必要である）。多くの処理目的に対して、分散型並列制御、可干渉性およびデータ更新を処理するよりも、エージェントをノードに提供する方が遥かに効率的である。換言すれば、データグリッドは、データトポロジの構成に基づいて、エージェントを実行する場所を決定し、エージェントをその場所に移動し、エージェントを実行し（エージェントの実行中に、アイテムの並列制御を自動的に処理する）、変更があった場合にその変更をバックアップし、結果を返す。

エントリプロセッサは、分散データグリッドのノード上で作業を実行するために使用されるエージェントの一例である。エージェント／実行可能コードの他の例として、アグリゲータ、フィルタ、値エクストラクタ、および呼び出し可能なコードを含むがこれらに限定されない。たとえば、Oracle（登録商標）Coherenceデータグリッドは、エントリプロセッサ（EntryProcessor）ＡＰＩを介して、ロックフリーなプログラミングモデルをサポートする。有利なことに、エントリプロセッサは、処理中のエントリに暗示的な低レベルロックをかける。これによって、クライアントは、並行処理を考えることなく、処理コードをエントリプロセッサに配置することができる。エントリプロセッサを、特定のキー、キーの集合、またはフィルタで呼び出すことができる（フィルタは、キャッシュエントリに対して実行され、フィルタ条件と一致する各エントリは、当該エントリに対して実行されるエントリプロセッサを有する）。エントリプロセッサは、クラスタ全体で（個々のエントリを所有するノード上で）並列に実行される。このことは、クライアントがすべての影響されたキーをロックし、すべての必要なデータをキャッシュから取り出し、データを処理し、キャッシュに格納し、キーのロックを解除することに比べて、著しく有利である。処理は、（１台のコンピュータ上で連続的に実行されるではなく）複数のコンピュータ上で並列に実行され、ロックの実行およびロックの解除によるネットワーク負荷を排除する。選択されたエントリに対して処理を行うエントリプロセッサのコードは、分散データグリッドに送信される。多くの種類のトランザクションにおいて、エントリプロセッサを使用することによって、競合および遅延を最小限に抑え、データ処理の故障許容性を損なうことなく、システムの処理量を向上させる。

例えば、図１に示す分散データグリッド１００のクライアント１５０上で、エージェントを作成することができる。エージェントを実行するために、このエージェントは、シリアル化され、分散データグリッド１００内の１つ以上のノードに送信される。オブジェクトをシリアル化することは、オブジェクトの状態をバイトストリームに変換し、このバイトストリームを逆変換する（デシリアル化する）と、オブジェクトのコピーを得ることができることを意味する。デシリアル化は、シリアル化されたオブジェクトをオブジェクトのコピーに変換するプロセスである。Ｊａｖａ（登録商標）プラットフォームは、シリアル化可能なオブジェクトをシリアル化するデフォルト方法を指定する。（Ｊａｖａ）クラスは、このデフォルトのシリアル化方法をオーバーライドして、そのクラスのオブジェクトをシリアル化する独自の方法を定義することができる。オブジェクトをシリアル化すると、そのクラスを特定する情報が、シリアル化されたストリームに記録される。しかしながら、クラスの定義（「クラスファイル」）自体は、通常記録されない。一般に、オブジェクトをデシリアル化するシステム（例えば、サーバ）は、必要なクラスファイルを検索してロードする方法を決定する。

エージェントを実現するために、分散データグリッドのノード上で存在しないクラス定義（「クラスファイル」）を利用する場合、問題が生じる可能性がある。この状況では、エージェントが動作しようとするノード上で必要なクラスを発見できないため、このエージェントは、このノード上で動作できない。クライアント上のクラス定義がノード上のクラス定義と異なる場合、別の問題が生じる可能性がある。例えば、クラス定義がクライアント上で変更／更新されても、分散データグリッドのノード上で変更／更新されない可能性がある。この状況では、必要なクラスがノード上で存在するため、エージェントは、動作する可能性がある。しかしながら、エージェントは、作成者が意図したクラス定義と異なるものを使用するため、意図通りに動作しない可能性がある。従来の実施形態において、新規クラスファイルまたは更新クラスファイルをクライアント上に配置する場合、分散データグリッド内で動作するエージェントによって利用される前に、新規クラスファイルまたは更新クラスファイルをサポートするように分散データグリッド内のノードを再配置および再起動する必要がある。大規模なクラスタの場合、このことは、非常に面倒で時間を浪費する。

実施形態において、分散データグリッド１００は、エージェント内で実行するために、分散データグリッド１００のノードにおいて、クライアント１５０からの新規または更新クラス定義の動的配置をサポートするシステムおよび方法を実施することによって、これらの問題を解決する。また、分散データグリッド１００は、クラス定義のバージョン管理を実施することによって、エージェント（例えば、エントリプロセッサ）によって呼び出されたクラスが、エージェントを作成したクライアント１５０上のクラスと同様のクラス定義を有することを保証する。クラス定義の動的配置およびクラス定義のバージョン管理をサポートするシステムおよび方法を利用することにより、分散データグリッドのノード上で新規または更新クラス定義を正しく実行することができ、分散データグリッドの有用性が増す。さらに、新規または更新クラス定義をサポートするため、分散データグリッド内のノードを再配置および再起動する必要性を回避することにより、分散データグリッドの性能が改善される。

クラス定義の動的配置
図２Ａは、ノード上で新規クラス定義を利用するエージェントの実現を可能にするように、クライアント１５０からの新規クラス定義を分散データグリッドのノード１３０ａに動的に配置するシステムを示す図である。図示では１つのクライアントおよび１つのノードしか示されていないが、同様の機能は、すべてのクライアントおよび分散データグリッドのすべてのノードに適用できる。図２Ａに示すように、ノード１３０ａは、Ｊａｖａ（登録商標）仮想マシン（ＪＶＭ）、例えばOracle（登録商標）JRockit ＪＶＭ、ＩＢＭ（登録商標）ＪＶＭ、Oracle（登録商標）ＪＶＭ、または別のベンダーのＪＶＭ実装として実装される。ノード１３０ａは、実行エンジン２１０、ネイティブメソッドインターフェイス２１２、ネイティブメソッドライブラリ２１４、およびクラスローダ２１７を含む。ノード１３０ａは、ＪＶＭメモリ領域２２０を備える。ＪＶＭメモリ領域２２０は、メソッド領域２１２、ヒープ２１４、ＪＶＭ言語スタック２１６、ＰＣレジスタ２１８、およびネイティブメソッドスタック２３０を含む。ノード１３０ａの起動時に、クラスローダ２１７は、ＪＶＭのクラスパスで発見されたクラス定義に基づいて、クラスをロードおよび準備して、初期化する。クライアント１５０は、リモートクラスサポート２６２を備え、ノード１３０ａは、リモートクラスサポート２３２を備える。以下に説明するように、リモートクラスサポートの機能によって、wireプロトコルを介してクライアント１５０からノード１３０ａに送信されたリモートクラスコンストラクタ２６４を用いて、クライアント１５０からの新規クラス定義を分散データグリッドのノード１３０ａに動的に配置することができる。

図２Ａに示すように、クライアントシステム１５０のユーザは、ノード１３０ａ上で操作されるエージェント用のエージェントコード２５０を準備することができる。エージェントコードは、新規クラス定義２５２を含むことができる。新規クラス定義２５２は、新規クラス名を有する新規クラスの定義であってもよく、または（既存する）クラスの更新定義であってもよい。なお、クラス定義が変更された場合、クライアントの観点からみれば、そのクラスは、技術的に新規クラス定義を有する新規クラスになる。クライアント上の既存クラスを変更することはできない。その代わりに、変更を含む新規クラスが実装される。ノード１３０ａ上で実行するためにエージェントコード２５０を送信するときに、リモートクラスサポート２６２は、エージェントコード２５０を検査することによって、エージェントコード２５０が新規クラス定義２５２を含むか否かを判定する。１つ以上の新規クラス定義２５２を発見した場合、リモートクラスサポート２６２は、新規クラス定義２５２のためにリモートクラスコンストラクタ２６４を準備する。リモートクラスコンストラクタ２６４は、新規クラス定義２６６と、ノード１３０ａ上でエージェントのインスタンスを構築するために必要なエージェントの捕捉状態２６８とを含む。リモートクラスコンストラクタ２６４を使用して、新規クラスのwireプロトコルに従う伝送、およびwireプロコトルを介してノード１３０ａに伝送された新規クラス定義の自動シリアル化を行うことができる。

リモートクラスサポート２６２は、クラス／ＩＤテーブル２６０を利用する。クラス／ＩＤテーブル２６０は、クラス名およびクラス定義のハッシュ関数（例えば、ＭＤ５ハッシュ）に基づいて、各既存クラスを特定するクラス識別子を含む。これによって、各クラスの識別子が一意であることが保証される。さらに、クラス定義が更新される場合、ハッシュは、新規識別子が割り当てられることを保証し、更新クラスは、新規クラスＩＤを有することになる。したがって、リモートクラスサポート２６２は、クラス／ＩＤテーブル２６０を使用して、エージェントコード２５０が任意の新規クラス定義２５２を含むか否かを判定することができる。

したがって、リモートクラスサポート２６２は、クラス／ＩＤテーブル２６０を使用して、新規クラス定義２５２がエージェントコード２５０に利用されているか否かを判定する。すべてのクラスがノード上で既に存在する場合、リモートクラスサポートは、（ノード１３０ａ上で実行することができる）クラスのＩＤを返送する。しかしながら、新規クラス定義２５２がエージェントコード２５０に利用される場合（すなわち、クラスがノード上で存在しない場合）、新規クラス定義２５２が準備され、新規クラス定義２５２に対応する新規ＩＤがクラス／ＩＤテーブル２６０に格納される。ノード１３０ａ上でエージェントを実現するために必要とされる新規クラス定義２６６とエージェントの捕捉状態２６８とを含むリモートクラスコンストラクタ２６４が準備される。リモートクラスコンストラクタのインスタンスは、自動的にシリアル化され、wireプロトコルを介してノード１３０ａに送信される。

リモートクラスコンストラクタ２６４は、ノード１３０ａによって受信され、リモートクラスサポート２３２によって処理される。リモートクラスコンストラクタ２６４は、Wireプロトコルを介してクライアント１５０から受信されると、自動的にデシリアル化される。ノード１３０ａは、クラスＩＤを検証するために、独自のＩＤテーブル２６０を保有する。ノード１３０ａは、デシリアル化後のリモートクラスコンストラクタ２６４およびリモートクラスサポート２３２を使用して、新規クラス定義２６６用のクラスローダを準備し、クラスをＪＶＭメモリ２２０にロードし、ＪＶＭ内の新規クラスのインスタンスを初期化する。したがって、ノード１３０ａは、新規クラス定義に基づいたクラスインスタンスを利用して、コードを実行することができる。リモートクラスサポート２３２は、ノード１３０ａ上で実行するためのエージェント２３８を実現することができる。

図２Ｂは、クライアント１５０からの新規または更新クラス定義を分散データグリッドのノード１３０ａに動的に配置するための方法２７０を示す図である。ステップ２７２において、クライアントは、ノード上で実行するためのエージェントを送信しようとする。ステップ２７４において、クライアントは、クラスのＩＤを判断する。ＩＤは一意的なものであるため、クライアントは、ステップ２７６において、そのＩＤをクラス／ＩＤテーブルに事前に記憶されたＩＤと比較することによって、クラスが既に存在しているか否かを判断することができる。ＩＤがクラス／ＩＤテーブルのクラスと一致しない場合、そのクラスが新規クラスまたは更新クラスである。

ステップ２７８において、クラスが新規クラスまたは更新クラスである（ＩＤがクラス／ＩＤテーブルに存在しない）場合、クライアントは、そのクラスに新規クラス定義を生成する。リモートクラスコンストラクタは、クライアント上で用意される。リモートクラスコンストラクタは、ノード上でエージェントを実現するために必要とされる新規クラス定義とエージェントの捕捉状態とを含む。ステップ２８０において、リモートクラスコンストラクタインスタンスは、自動的にシリアル化され、wireプロトコルを介してノードに送信される。

ステップ２８２において、ノードは、wireプロトコルを介して、クライアントからリモートクラスコンストラクタを受信する。ステップ２８４において、リモートクラスコンストラクタは、ノード上でデシリアル化され、実行される。ステップ２８６において、エージェントを実現するために必要とされた新規クラス定義とエージェントの捕捉状態とをＪＶＭメモリにロードすることによって、ノード上で新規クラスまたは更新クラスのインスタンスを作成する。ステップ２８８において、ノード上でエージェントを実装するために、新規または更新クラスのインスタンスは、ノード上で実行可能に構成される。なお、クラス定義が変更された場合、クライアントの観点からみれば、そのクラスは、技術的に新規クラス定義を有する新規クラスになる。クライアント上の既存クラスを変更することはできない。その代わりに、変更を含む（新規クラスＩＤを有する）新規クラスが実装される。ステップ２９０において、エージェントは、ノード上で実行される。

したがって、この方法は、ノード／ＪＶＭの再配置を必要とせずに、新規クラスまたは更新クラスの実装を可能にするために、クライアントからの新規または更新クラス定義をノードに動的に配置することができる。ノード／ＪＶＭの再配置の必要がない、新規クラスまたは更新クラスの動的配置は、エージェントを実行するための分散データグリッドの有用性を強化し、新規または更新クラス定義を必要するときにノードを再起動する必要性を排除する。

ラムダを実装するクラス定義の動的配置
一実施形態において、クラス定義の動的配置を行うためのシステムおよび方法は、ラムダ式に関連するクラス定義に適用することができる。近年、Ｊａｖａ（登録商標）のようなオブジェクト指向プログラミング言語は、多くの異なる種類のプラットフォーム上で動作する多種さまざまなアプリケーションにますます普及されている。一部のプログラミング言語は、「ラムダ式」をサポートすることができる。オブジェクト指向プログラミング言語において、ラムダ式は、メソッドを１つしか持たず、状態を持たないオブジェクトを定義するための軽量メカニズムとして使用できる。ラムダ式の軽量構文は、さまざまなプログラミング言語環境に一般的に使用されるように最適化することができる。Ｊａｖａ（登録商標）プログラミング言語は、命令型プログラミング言語の一例であるレキシカルスコープ言語である。ラムダ式のサポートは、Ｊａｖａ（登録商標）８プログラミング言語に導入された。したがって、場合によっては、分散データグリッドのノード上で実行されるエージェントのコードは、ラムダ式を含んでもよい。

ラムダ式は、プログラミング言語によって値として取り扱うことができる関数を記述する軽量な方法である。ラムダ式は、匿名の内部クラスの仕組みを構文的に軽量なメカニズムに置き換えることによって、「縦の問題」または膨大構文を取り扱う匿名メソッドでもよい。メソッドは、ラムダ（関数）を引数として受け入れ、結果として返すことができるため、ラムダ式は、「コードをデータとして」サポートするものとして見なすことができる。ラムダ式は、メソッドに似ている。具体的に、ラムダ式は、仮パラメータのリスト、およびこれらのパラメータで表現された本体（式またはブロック）を提供する。ラムダ式は、次のような構文、すなわち、「（引数リスト）→本文」を使用して表現されてもよい。

Ｊａｖａ（登録商標）プログラミング言語におけるラムダ式の使用の態様は、例えば、２０１４年２月２７日に出願され、「ラムダ式の互換性チェックをサポートするシステムおよび方法」と題された米国特許出願第１３／７７９５３６号、２０１２年１１月１４日に出願され、「過負荷メソッドおよびコンストラクタ引数のターゲット分類」と題された米国特許出願第１３／６７７００１号、２０１２年１１月１４日に出願され、「プログラム変数の不変性を推定するためのシステムおよび方法」と題された米国特許出願第１３／６７７０００号、２０１３年２月２７日に出願され、「プログラミング言語環境においてラムダ式をコンパイルするためのシステムおよび方法」と題された米国特許出願第１３／７７９５５７号、および２０１１年２月１５日に出願され、「ソフトウェアプログラムにおける閉鎖の結合に基づく特性付け」と題された米国特許出願第１３／０２８１１１号に記載されている。これらの出願は、参照により本開示に援用される。

ラムダ式は、名前を有しないため、「匿名」である。したがって、ラムダ式は、匿名メソッドを定義することができ、匿名メソッドを機能インターフェイスのインスタンスとして取り扱うことができる。匿名の内部クラスを有する機能インターフェイスの使用がＪａｖａ（登録商標）プログラミング言語において共通パターンであるため、Ｊａｖａ（登録商標）プログラミング言語は、機能インターフェイスを利用してラムダ式を実装する。Ｊａｖａ（登録商標）８プログラミング言語において、ラムダ式は、匿名クラス宣言の基本フォームとして記述することができる。このフォームにおいて、ラムダ式のパラメータは、匿名クラス宣言メソッドのパラメータと同様であり、ラムダ式の本体は、匿名クラス宣言メソッドの本体と同様である（ただし、この特定のラムダ式の本体が唯一に行えるのは、値を返すことであるため、キーワード「return」を省くことができる）。式−本体形式では、キーワード「return」が不要になる。そうでなければ、式のサイズに対する構文上の負荷が大きくなる可能性がある。したがって、Ｊａｖａ（登録商標）８プログラミング言語では、ラムダ式は、機能インターフェイスのクラス定義において実装される。

本開示は、例えば、図１の分散データグリッドを含む分散コンピューティング環境にラムダを実装するクラスの動的配置をサポートすることができるシステムおよび方法を説明する。上述したように、分散データグリッドは、分散データグリッドのノード上で動作するエージェントを用いて、トランザクションの実行をサポートする。このようなエージェントのコードには、ラムダ式を含む。しかしながら、従来の実装では、エージェントで使用されるクラスは、各クラスタノードのクラスパスに存在（既存）しなければならない。これによって、ラムダを実装するクラスを予め分散データグリッドのノードに配置しない限り（またはノードを再配置しない限り）、エージェントにラムダ式を使用できない。サーバで実際にラムダ式を処理するためには、クライアントおよびサーバクラスパスの両方には同様のコンパイル済みコードが必要である。換言すれば、サーバは、サーバクラスパスにおいてラムダ式に対応するクラスを有する必要がある。クライアント上のラムダ式を変更するまたは新規ラムダ式を導入する場合、ラムダ式に対応する新規クラスをサーバに配置するために、クライアントおよびサーバの両方を再配置および再起動する必要がある。大規模なクラスタの場合、このことは、非常に面倒で時間を浪費する。

この制約を克服するために、本発明の実施形態において、クライアントは、エージェントに使用されるラムダ式を記述するメタデータと共に、ラムダ式を実装するクラスの実際のクラス定義を送信する。ラムダ式を実装するクラスの動的配置は、上述したクラス定義の動的配置の特例として実行することができる。サーバ側では、クライアントから受信したクラス定義を構文解析することによって、エージェント／エントリプロセッサに使用される新規のラムダクラスを生成する。サーバは、クライアントから受信したクラス定義に基づいて、ラムダクラスを定義し、実行する。これにより、既存のラムダ式を変更した後または新規のラムダ式を導入した後、サーバの再配置または再起動を必要とせず、ラムダ式のコンパイル済みコードをクラスパスに配置することができる。

図３Ａは、本発明の一実施形態に従って、分散コンピューティング環境において動的ラムダをサポートするシステムを示す図である。図３に示すように、分散データグリッドなどの分散コンピューティング環境３００は、クライアント３０１およびサーバ３０２を含む。一実施形態において、分散コンピューティング環境は、図１に示された分散データグリッド１００であってもよい。この場合、クライアント３０１は、１つ以上のクライアント１５０を表し、サーバ３０２は、１つ以上のノード１３０ａ、１３０ｂ、１３０ｃ、１３０ｄおよび１３０ｅを表す。

上述のように、クラス定義の動的配置をサポートしない従来の実施形態において、ラムダ式３０３を記述するメタデータ３０５のみがクライアント３０１からサーバ３０２に送信される。その後、サーバ３０２は、受信したメタデータ３０６に基づいて、クライアント上のラムダ式３０３を利用する。サーバ３０２は、受信したメタデータ３０６をデシリアル化して、静的ラムダに必要なクラスファイルを検索してロードする方法を決定する。したがって、サーバ３０２上でクラスファイルを予め配置する必要があり、クライアント３０１上で同様のクラスファイル（すなわち、クライアント上で変更／更新されていないクラスファイル）を配置する必要がある。したがって、クライアント側で変更したラムダ式または新たに導入したラムダ式は、クライアントによってサーバ３０２上で呼び出される前に、クライアント３０１およびサーバ３０２の両方に再配置および／または再起動する必要がある。

一方、クラス定義の動的配置を使用可能にする本発明の実施形態において、新規または更新クラス定義を使用してラムダを実装するときに、クライアント３０１は、ラムダ式３０３から、実行する１つ以上のクラス定義３０７を生成し、生成されたクラス定義３０７を分散コンピューティング環境３００内のサーバ３０２に送信する。サーバ３０２は、実行するクラス定義３０８を受信した後、受信したクラス定義３０８に基づいて、サーバ側でラムダインスタンス３０４を定義する。次いで、サーバ３０２は、受信したクラス定義３０８によって定義されたラムダインスタンス３０４を実行する。さらに、クライアント３０１がラムダ式３０３をクライアント側で更新する場合、すなわち、ラムダ式３０３が変更されたときまたは新しい挙動が導入されたときに、新規クラス定義３０７を用意してサーバ３０２に送信することによって、新しい挙動を有するように、新規ラムダインスタンスを作成し、実行することができる。

図３Ｂは、分散コンピューティング環境において動的ラムダをサポートする方法を示す図である。ステップ３２０において、クライアントは、ラムダ式からクラス定義を生成する。ステップ３２２において、サーバは、クライアントから実行するクラス定義を受信する。ステップ３２４において、サーバは、受信したクラス定義に基づいて、サーバ側でラムダクラスを定義し、ロードする。ステップ３２６において、サーバは、受信したクラス定義に基づいて、サーバ側で定義されたラムダインスタンスを作成し、実行する。ラムダ式がクライアント側で更新された場合、更新されたラムダ式に基づいた新規クラス定義を用いて、ステップ３２０からステップ３２６までのプロセスを繰り返すことによって、サーバ側で新規のラムダクラス定義およびインスタンスを生成する。

上記で本発明のさまざまな実施形態を説明したが、これらの実施形態は、限定ではなく例示として提示されることを理解すべきである。本発明の精神および範囲から逸脱することなく、形態および詳細のさまざまな変更を行うことができることは、当業者にとって明らかであろう。

例示の目的のために、上記の説明は、主にＪａｖａ（商標）プログラミング言語（またはＪａｖａ（商標）に緊密に関連する言語）を使用する文脈に関連して提供されたが、記載された技術は、ラムダ式、メソッド、コンストラクタまたは関数などの呼び出し操作のオーバーロードをサポートするプログラミング言語に適用することができる。いくつかの実施形態では、この技術をオブジェクト指向言語に適用することができ、他の実施形態では、この技術を非オブジェクト指向言語（さまざまな手続き型言語）に適用することができる。

本発明の多くの特徴は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの組み合わせに実行する、またはそれらを使用して実行する、またはそれらの援助で実行することができる。本発明は、本開示の教示に従ってプログラムされた１つ以上のプロセッサ、メモリおよび／またはコンピュータ可読記憶媒体を含む１つ以上の従来の汎用または専用デジタルコンピュータ、コンピューティング装置、機械、またはマイクロプロセッサを使用して都合よく実施することができる。本発明の特徴は、例えば、特定用途向け集積回路（ＡＳＩＣ）およびプログラマブル論理装置などのハードウェア要素を使用して、ハードウェアで実施することもできる。本開示に記載の機能を実行するために、ハードウェア状態機械を実装することは、当業者には明らかであろう。

本発明の特徴は、処理システムのハードウェアを制御し、本発明の結果を利用して処理システムと他の機構との相互作用を可能にするソフトウェアおよび／またはファームウェアに組み込むことができる。そのようなソフトウェアまたはファームウェアは、アプリケーションコード、装置ドライバ、オペレーティングシステムおよび実行環境／コンテナを含むことができるがこれらに限定されない。ソフトウェア分野の当業者には明らかであるように、熟練したプログラマは、本開示の教示に基づいて、適切なソフトウェアのコーディングを容易に準備することができる。

いくつかの実施形態において、本発明は、本発明のプロセスのうちいずれかを実行するようにコンピュータをプログラムするために使用できる命令を格納する非一時的な記録媒体またはコンピュータ読取可能な媒体であるコンピュータプログラム製品を含む。この記録媒体は、フロッピー（登録商標）ディスク、光ディスク、ＤＶＤ、ＣＤ−ＲＯＭ、マイクロドライブ、および光磁気ディスクを含む、任意の種類のディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＤＲＡＭ、ＶＲＡＭ、フラッシュメモリデバイス、磁気もしくは光カード、ナノシステム（分子メモリＩＣを含む）、または、命令および／もしくはデータを格納するのに適した任意の種類の媒体もしくは装置を含むことができるが、これらに限定されない。

本発明の上記記載は、例示および説明を目的として提供される。本発明を網羅的なものまたは開示された形態そのものに限定することを意図していない。当業者には数多くの変更および変形が明らかであろう。実施形態は、本発明の原理およびその実際の応用を最も良く説明することによって、他の当業者がさまざまな実施形態および考えられる特定の用途に適したさまざまな変形に応じて本発明を理解できるように、選択され説明される。本発明の範囲は、添付の特許請求の範囲およびそれらの同等物によって規定されると意図する。

Claims (20)

1. 分散コンピューティング環境内のノードにおいて、クライアントからの実行可能コードの動的配置をサポートする方法であって、
   前記ノード上で、前記クライアントからのシリアル化されたオブジェクトを受信するステップを含み、前記シリアル化されたオブジェクトは、前記ノードのクラスパスに存在しない新規クラスのクラス定義と、前記新規クラスを利用するエージェントの捕捉状態とを含み、
   前記ノード上で、前記シリアル化されたオブジェクトをデシリアル化することによって、前記クラス定義と前記エージェントの前記捕捉状態とを取得するステップと、
   前記クラス定義と前記エージェントの前記捕捉状態とを前記ノードのメモリにロードすることによって、前記ノード上で前記新規クラスのインスタンスを生成するステップと、
   前記ノード上で前記エージェントを実行するステップとを含む、方法。
2. 前記クラス定義は、ラムダ式を実装する、請求項１に記載の方法。
3. 前記クライアント上でエージェントコードを受信するステップと、
   前記クライアント上の前記エージェントコードから、前記新規クラスのクラス定義を判断するステップと、
   前記クラス定義に基づいて、前記新規クラスのクラスＩＤを生成するステップとをさらに含む、請求項１または２に記載の方法。
4. 前記クライアント上でクラス／ＩＤテーブルを保持するステップと、
   前記クライアント上で前記エージェントのエージェントコードを受信するステップと、
   前記クライアント上の前記エージェントコードから、前記新規クラスのクラス定義を判断するステップと、
   前記クラス定義に基づいて、前記新規クラスのクラスＩＤを生成するステップと、
   前記クラス／ＩＤテーブルを用いて、前記新規クラスが前記ノードのクラスパスに存在しないことを判断するステップとをさらに含む、請求項１〜３のいずれか１項に記載の方法。
5. 前記クライアント上でクラス／ＩＤテーブルを保持するステップと、
   前記クライアント上で前記エージェントのエージェントコードを受信するステップと、
   前記クライアント上の前記エージェントコードから、前記新規クラスのクラス定義を判断するステップと、
   前記クラス定義に基づいて、前記新規クラスのクラスＩＤを生成するステップと、
   前記クラス／ＩＤテーブルを用いて、前記新規クラスが前記ノードのクラスパスに存在しないことを判断するステップと、
   前記新規クラスの前記クラスＩＤを前記クラス／ＩＤテーブルに追加するステップとをさらに含む、請求項１〜３のいずれか１項に記載の方法。
6. 前記クライアント上で前記エージェントのエージェントコードを受信するステップと、
   前記クライアント上の前記エージェントコードから、前記新規クラスのクラス定義を判断するステップと、
   前記クライアント上で、前記ノードのクラスパスに存在しない新規クラスのクラス定義と、前記新規クラスを利用するエージェントの捕捉状態とを含む前記シリアル化されたオブジェクトを生成するステップと、
   前記シリアル化されたオブジェクトを前記ノードに送信するステップとをさらに含む、請求項１〜５のいずれか１項に記載の方法。
7. 前記クライアント上で前記クライアントのエージェントコードを受信するステップを含み、前記エージェントコードは、ラムダ式を含み、
   前記クライアント上の前記エージェントコードから、前記新規クラスのクラス定義を判断するステップを含み、前記クラス定義は、前記ラムダ式を実装し、
   前記クライアント上で、前記ノードのクラスパスに存在しない新規クラスのクラス定義と、前記新規クラスを利用するエージェントの捕捉状態とを含む前記シリアル化されたオブジェクトを生成するステップと、
   前記シリアル化されたオブジェクトを前記ノードに送信するステップとをさらに含む、請求項１〜６のいずれか１項に記載の方法。
8. 前記分散コンピューティング環境は、データグリッドクラスタを含み、
   前記実行可能コードの動的配置は、前記エージェントによって操作されるデータを保持する複数のノードを前記データグリッドクラスタに再配置することなく、前記データグリッドクラスタ内の前記複数のノード上で前記エージェントの実行を可能にする、請求項１〜７のいずれか１項に記載の方法。
9. 前記分散コンピューティング環境は、データグリッドクラスタを含み、
   前記エージェントは、前記ノードに保持されたデータを処理するためのエントリプロセッサである、請求項１〜８のいずれか１項に記載の方法。
10. 前記分散コンピューティング環境は、データグリッドクラスタを含み、
    前記エージェントは、前記ノードに保持されたデータを処理するためのアグリゲータ、フィルタ、値エクストラクタおよび呼び出し可能物のうち、１つである、請求項１〜９のいずれか１項に記載の方法。
11. 分散コンピューティング環境において実行可能コードの動的配置をサポートするシステムであって、
    マイクロプロセッサとメモリとを含むコンピュータシステムと、
    前記分散コンピューティング環境の一部として前記コンピュータシステム上で配置されたノードとを備え、
    前記ノードは、
    クライアントからのシリアル化されたオブジェクトを受信するように構成され、前記シリアル化されたオブジェクトは、前記ノードのクラスパスに存在しない新規クラスのクラス定義と、前記新規クラスを利用するエージェントの捕捉状態とを含み、
    前記ノード上で前記シリアル化されたオブジェクトをデシリアル化することによって、前記クラス定義と前記エージェントの前記捕捉状態とを取得し、
    前記クラス定義と前記エージェントの前記捕捉状態とを前記ノードに割り当てられた前記メモリの一部にロードすることによって、前記ノード上で前記新規クラスのインスタンスを生成し、
    前記ノード上で前記エージェントを実行するように構成される、システム。
12. 前記クラス定義は、ラムダ式を実装する、請求項１１に記載のシステム。
13. マイクロプロセッサとメモリとを含むクライアントコンピュータシステムと、
    前記クライアントコンピュータシステム上で動作するクライアントとをさらに備え、
    前記クライアントは、
    前記エージェントのエージェントコードを受信し、
    前記エージェントコードから、前記新規クラスのクラス定義を判断し、
    前記クラス定義に基づいて、前記新規クラスのクラスＩＤを生成するように構成される、請求項１１または１２に記載のシステム。
14. マイクロプロセッサとメモリとを含むクライアントコンピュータシステムと、
    前記クライアントコンピュータシステム上で動作するクライアントとをさらに備え、
    前記クライアントは、
    クラス／ＩＤテーブルを保持し、
    前記エージェントのエージェントコードを受信し、
    前記エージェントコードから、前記新規クラスのクラス定義を判断し、
    前記クラス定義に基づいて、前記新規クラスのクラスＩＤを生成し、
    前記クラス／ＩＤテーブルを用いて、前記新規クラスが前記ノードのクラスパスに存在しないことを判断するように構成される、請求項１１〜１３のいずれか１項に記載のシステム。
15. マイクロプロセッサとメモリとを含むクライアントコンピュータシステムと、
    前記クライアントコンピュータシステム上で動作するクライアントとをさらに備え、
    前記クライアントは、
    クラス／ＩＤテーブルを保持し、
    前記エージェントのエージェントコードを受信し、
    前記エージェントコードから、前記新規クラスのクラス定義を判断し、
    前記クラス定義に基づいて、前記新規クラスのクラスＩＤを生成し、
    前記クラス／ＩＤテーブルを用いて、前記新規クラスが前記ノードのクラスパスに存在しないことを判断し、
    前記新規クラスの前記クラスＩＤを前記クラス／ＩＤテーブルに追加するように構成される、請求項１１〜１３のいずれか１項に記載のシステム。
16. マイクロプロセッサとメモリとを含むクライアントコンピュータシステムと、
    前記クライアントコンピュータシステム上で動作するクライアントとをさらに備え、
    前記クライアントは、
    クラス／ＩＤテーブルを保持し、
    前記エージェントのエージェントコードを受信し、
    前記エージェントコードから、前記新規クラスのクラス定義を判断し、
    前記ノードのクラスパスに存在しない新規クラスのクラス定義と、前記新規クラスを利用するエージェントの捕捉状態とを含む前記シリアル化されたオブジェクトを生成し、
    前記シリアル化されたオブジェクトを前記ノードに送信するように構成される、請求項１１〜１５のいずれか１項に記載のシステム。
17. マイクロプロセッサとメモリとを含むクライアントコンピュータシステムと、
    前記クライアントコンピュータシステム上で動作するクライアントとをさらに備え、
    前記クライアントは、
    クラス／ＩＤテーブルを保持し、
    前記エージェントのエージェントコードを受信するように構成され、前記エージェントコードは、ラムダ式を含み、
    前記エージェントコードから、前記新規クラスのクラス定義を判断するように構成され、前記クラス定義は、前記ラムダ式を実装し、
    前記ノードのクラスパスに存在しない新規クラスのクラス定義と、前記新規クラスを利用するエージェントの捕捉状態とを含む前記シリアル化されたオブジェクトを生成し、
    前記シリアル化されたオブジェクトを前記ノードに送信するように構成される、請求項１１〜１６のいずれか１項に記載のシステム。
18. 前記分散コンピューティング環境は、データグリッドクラスタを含み、
    前記実行可能コードの動的配置は、前記エージェントによって操作されるデータを保持
    する複数のノードを前記データグリッドクラスタに再配置することなく、前記データグリッドクラスタ内の前記複数のノード上で前記エージェントの実行を可能にする、請求項１１〜１７のいずれか１項に記載のシステム。
19. 前記分散コンピューティング環境は、データグリッドクラスタを含み、
    前記エージェントは、前記ノードに保持されたデータを処理するためのアグリゲータ、フィルタ、値エクストラクタおよび呼び出し可能物のうち、１つである、請求項１１〜１８のいずれか１項に記載のシステム。
20. １つ以上のコンピュータシステム上で実行するためのプログラム命令を含むコンピュータプログラムであって、これらの命令は、コンピュータシステムによって実行されると、前記コンピュータシステムに、請求項１〜１０のいずれか１項に記載の方法を実行させる、コンピュータプログラム。