JP5373770B2 - 分散型、耐障害性、および高可用性を達成するための決定性コンピューティング・システム、方法、およびプログラム・ストレージ・デバイス（分散型、耐障害性、および高可用性のコンピューティング・システム） - Google Patents

Description

本発明は、一般に、分散型システムを開発および実行するためのアプリケーション開発ツール、方法、およびシステムに関し、とりわけ、コンポーネント指向アプリケーションを実行するための分散型、トランスペアレントな耐障害性、および高可用性のシステムを開発および実行するために改善された環境に関する。

ＳＣＡサービス・コンポーネント・アーキテクチャは、ビジネス機能を定義するＩＴサービスを実装するための、オープンで技術に無関係な（technology-neutral）モデルを提供する。ＳＣＡは、アクセス方法およびセキュリティなどのソリューション面にわたる制御によって、個々のサービスの集合からビジネス・ソリューションを組み立てるためのモデルも提供する。顧客はＳＣＡを使用して、より簡単に新しいＩＴ資産を作成すること、および既存のＩＴ資産を、変化するビジネス要件に即時に適合可能な再使用可能サービスに変換することが可能になる。ＳＣＡ（ミドルウェア）コンポーネントの構築を可能にする規格は、ビジネス機能を実行する一連の再使用可能サービスとしてＩＴ資産を構築する、サービス指向アーキテクチャ（ＳＯＡ）を利用する。サービス指向アーキテクチャは、リモートのオブジェクトおよび機能（「サービス」と呼ぶ）を呼び出す機能と、相互運用性に重きを置いた動的サービス発見のためのツールとを組み合わせる。現在、この業界の目標は、ＳＯＡに基づくアプリケーションを構築するためのより単純かつより強力な方法を、アプリケーション開発者に提供することである。

さらに、ＳＣＡコンポーネントを実装する分散型システムの開発において、持続的な「設定」（分散型システム全体にわたって大容量媒体上に格納されることになる）、または障害に対して耐性のあるように保持された「状態」の、いずれかを表すことが可能な、「不揮発性」データのトランスペアレントな対障害性機能を提供することが目標である。現在、分散型の耐障害性および高可用性システムの開発は、その場しのぎの、エラーを起こしやすい、時間のかかるものである。現在のソリューションは、通貨価格の変動および為替動作が異常であるかまたはアトミックでない可能性のある、例示的な為替システムに類似している。実行は、ネットワークまたはスレッディングによって、通常は非決定性であり、持続性のための既存のメカニズム（エンティティ・ビーン、ＪＤＢＣなど）は非常に重く、特別な知識および特別なコードを必要とする。

たとえば、現在のソリューションは、たとえば「エンタープライズＪａｖａビーン」（ＥＪＢ）などの、Ｊ２ＥＥプラットフォーム用のサーバ側のコンポーネント・アーキテクチャを含むエンティティ・ビーンを実装する。ＥＪＢは、その称するところによれば、分散型、トランザクション、セキュア、およびポータブルな、Ｊａｖａアプリケーションの、高速かつ簡略化された開発をサポートしている。ＥＪＢは、メッセージの同時消費を可能にするコンテナ・アーキテクチャをサポートし、分散型トランザクションのサポートを提供するため、データベース更新、メッセージ処理、およびＪ２ＥＥアーキテクチャを使用する企業システムへの接続が、同じトランザクション・コンテキストに関与することができる。

プログラマが、コンポーネント状態を別々のオブジェクトに分割する、トランザクション、ＪＤＢＣ、またはエンティティ・ビーンなどの特別な方法および構造を習得すること、ならびに、その状態を持続すること、さらにはその代わりに、通常のコードに対して持続性および耐障害性を自動的に提供すること（トランスペアレントな耐障害性とも呼ばれる）を、必要としなくなることが、強く望まれている。

本発明の譲受人によって共同所有された米国特許出願第４，６６５，５２０号に記載された技法を含む、分散型システムにおけるトランスペアレントな耐障害性に関する技法が存在する。こうした技法の性能は、分散型コンポーネント間での各通信を記録する必要があるため、分散型システムにおける通信コンポーネントの動作の非決定性によって制限される。

さらに、非決定性分散型システムの回復の性能問題を避けるために、決定的実行、耐障害性、および高可用性をトランスペアレントにサポートする、実行サーバを提供することが強く望まれている。

さらに、単純なコンポーネント・ベース・モデルをプログラマに提供すること、およびとりわけ、アプリケーション開発者がミドルウェア機能によりアクセスしやすくするためのシステムおよび方法を提供することが、強く望まれている。

米国特許出願第４，６６５，５２０号

Ｄａｖｉｄ Ｂａｃｏｎ、Ｒｏｂｅｒｔ Ｓｔｒｏｍ、Ａｓｈｉｓ Ｔａｒａｆｄａｒ著、「Ｇｕａｖａ：ａ ｄｉａｌｅｃｔ ｏｆ Ｊａｖａ ｗｉｔｈｏｕｔ ｄａｔａ ｒａｃｅｓ」と題するオブジェクト指向のプログラミング、システム、言語、およびアプリケーションに関する第１５回ＡＣＭ ＳＩＧＰＬＡＮ会議２０００の議事録 １９８５年７月付けのＪｅｆｆｅｒｓｏｎ，Ｄによる「Ｖｉｒｔｕａｌ ｔｉｍｅ」と題するＡＣＭ Ｔｒａｎｓａｃｔｉｏｎｓ ｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｌａｎｇｕａｇｅｓ ａｎｄ Ｓｙｓｔｅｍｓ

したがって、本発明の広義な目的は、前述のような従来技術の欠点を改善することである。

本発明の他の目的は、コンポーネント指向アプリケーションに関する決定的実行、耐障害性、および高可用性をトランスペアレントにサポートする、実行環境を提供することである。

これらおよび他の関連する目的の実施は、コンピューティング・システムおよび方法によって達成される。決定性コンピューティング・システムは、
タスクを実行するための論理をそれぞれが実装する複数のソフトウェア・コンポーネントであって、このコンポーネントが、ネットワーク内で接続され、コンポーネント間でメッセージを通信するように適合された、１つまたは複数のマシンを備える実行環境内で実行する、複数のソフトウェア・コンポーネントと、
プログラム実行中に送信側コンポーネントから受信側コンポーネントへと送られるメッセージに関して、決定性タイムスタンプを自動的に関連付けるための手段であって、当該タイムスタンプが受信側コンポーネントでの当該メッセージの着信の推定時刻を表す、自動的に関連付けるための手段と、
入力メッセージの固有の着信順序を生成するために当該タイムスタンプを使用することによって、当該コンポーネントを決定的に実行するための手段と、
プログラム実行中にコンポーネント状態を追跡し、その状態をローカル・ストレージ・デバイスに定期的にチェックポインティング（checkpointing）するための手段と、
を備え、
マシンの障害時には、最近格納されたチェックポイントを回復すること、および最後のチェックポイント以降に発生したイベントを再実行することによって、このコンポーネント状態が復元される。

コンピューティング・システムは、関連付けられたタイムスタンプと同じ順序でメッセージを処理することにより、受信側コンポーネントの実行を反復することで、決定性を持つ。

本発明の他の態様では、コンポーネント状態をバックアップ・プロセッサ・デバイスに対してチェックポインティングすることができる。

本発明の他の実施形態によれば、
コンピューティング・システム内のコンポーネントを、それらのコンポーネント間でのメッセージ通信を実行可能にするように適合されたコンピューティング・システム内で決定的に実行するための方法であって、各コンポーネントがタスクを実行するための論理を実装し、
プログラム実行中に送信側コンポーネントから受信側コンポーネントへと送られるメッセージに関して、タイムスタンプを自動的に関連付けることであって、このタイムスタンプが受信側コンポーネントでのメッセージの着信の推定時刻を表す、自動的に関連付けることと、
入力メッセージの固有の着信順序を生成するために当該タイムスタンプを使用することによって、当該コンポーネントを決定的に実行することと、
プログラム実行中にそのコンポーネント状態を追跡し、その状態をローカル・ストレージ・デバイスに定期的にチェックポインティングすることと、
を含み、
コンポーネントの障害時には、最近格納されたチェックポイントを回復すること、および最後のチェックポイント以降に発生したイベントを再実行することによって、このコンポーネント状態が復元される。

さらに本発明の他の実施形態によれば、コンポーネント指向アプリケーションを実行するための環境が提供され、この環境はコンポーネント間でメッセージを通信するように適合される。この環境は、
各コンポーネントがタスクを実行するための論理を実装する、メッセージのコンポーネントへの入力およびコンポーネントからの出力を表すポートの仕様を含む、コンポーネントの高水準設計を実行可能にするサブシステムと、
コンポーネントが当該実行環境の特定の処理エンジンに割り当てられた低水準実装に、高水準設計をマッピングするための、配置サービスと、
プログラム実行中に送信側コンポーネントから受信側コンポーネントへと送られるメッセージに関して、タイムスタンプに関連付けられたコンポーネントの入力または出力メッセージを自動的に増補するためであって、このタイムスタンプが受信側コンポーネントでのメッセージの着信の推定時刻を表す、自動的に増補するため、および
その状態に対する増分変化を追跡するためのコードでコンポーネントを増補するための、
コード強化手段と、
を備え、
プログラム実行中にコンポーネント状態が追跡され、コンポーネント状態はローカル・ストレージ・デバイス内でチェックポインティングされ、
コンポーネントの障害時には、最近のチェックポイントを回復すること、および最後のチェックポイント以降に発生したイベントを再実行することによって、このコンポーネント状態が復元される。

本発明のこの態様により、高水準設計は、当該実行環境内のどこでコンポーネントが実行されるかに無関係である。

さらに、時間の推定が自動的な非時間認識（non-time-aware）コンポーネントと、プログラマが実時間制約を指定することが可能な時間認識コンポーネントという、２つのタイプのコンポーネントの共存を実行可能にする、前述の諸実施形態のそれぞれに従った分散型システムを提供することが、強く望まれている。

当業者であれば、本発明の他の利点は、図面および詳細な説明の審査により明らかとなろう。任意の追加の利点が本明細書に組み込まれることが意図されている。

当業者であれば、添付の図面と組み合わされた以下の詳細な説明に鑑みて、本発明の目的、特徴、および利点が明らかとなろう。

本発明に従った、コンポーネントおよびコンポーネント指向アプリケーションを実行するためのミドルウェア・アプリケーションが実行される、実行サーバ・アーキテクチャ１０を示す図である。 本発明の実行サーバ・アーキテクチャに従った、単一実行エンジン、この例ではＪａｖａ仮想マシン（ＪＶＭ）内のコンポーネント間での、および、複数の実行エンジン間での、例示的メッセージングおよび通信を示す図である。 例示的ユーザ設計からのコンポーネントの配置を含む、本発明のサーバ・ミドルウェア・コンポーネントによって実行可能化された例示的アプリケーションを示す図である。 例示的ユーザ設計からのコンポーネントの配置を含む、本発明のサーバ・ミドルウェア・コンポーネントによって実行可能化された例示的アプリケーションを示す図である。 仮想時間推定を含む、本発明のサーバ・ミドルウェア・コンポーネントによって実行可能化された例示的アプリケーションを示す図である。 沈黙（silence）および好奇（curiosity）メッセージ生成を含む、本発明のサーバ・ミドルウェア・コンポーネントによって実行可能化された例示的アプリケーションを示す図である。 本発明の原理に従った、メモリ・ストレージ・デバイスへのチェックポインティングおよびハード・ディスクからのチェックポイントの復元を示す概略図である。 本発明によって与えられる高可用性を提供するための、受動リモート・バックアップの使用、およびスケジューラ・レプリカの生成（spawning）を示す、概略図である。 本発明によって与えられる高可用性を提供するための、受動リモート・バックアップの使用、およびスケジューラ・レプリカの生成（spawning）を示す、概略図である。 本発明によって与えられる高可用性を提供するための、受動リモート・バックアップの使用、およびスケジューラ・レプリカの生成（spawning）を示す、概略図である。

前述のように、提案された発明は、当分野の問題、すなわち、コンポーネント状態を持続させるためにその状態を別々のオブジェクトに分割する、トランザクション、ＪＤＢＣ、またはエンティティ・ビーンなどの、特化された方法および構造をプログラマに提供するという継続的な必要性、ならびに、非決定的実装においてコンポーネント間でのメッセージを記録する必要性に、対処することを目標としている。これは、コンポーネント指向アプリケーションを実行するために持続性および耐障害性を自動的に提供する、決定性かつ高可用性の実行サーバを提供することによって、対処される。

図１は、全体としてコンポーネント２０ａ、．．．、２０ｎとして表されるコンポーネントおよびコンポーネント指向アプリケーションを実行するための、ミドルウェア・アプリケーションが実行される、実行サーバ・アーキテクチャ１０を示す。図１に示されるように、各サーバは、図１に示されるような全体としてＪＶＭ １２ａ、．．．１２ｎとして表される１つまたは複数のＪａｖａ仮想マシンを含む。複数のサーバが存在可能であり、各サーバ内には、たとえば、単一マシン内の異なるプロセスとして実行するＪａｖａ仮想マシン（ＪＶＭ）の複数のインスタンスが存在可能であることを理解されよう。ＪａｖａおよびＪＶＭの使用は純粋に例示的なものであり、ＪＶＭの代わりに、アプリケーション・コンポーネントが作成された他の言語の実行環境も使用可能であることを理解されよう。各ＪＶＭ内には、開発者に対してトランスペアレントな、階層内のＪＶＭとコンポーネントとの間の層として、全体としてスケジューラ１５ａ、．．．１５ｎとして表される少なくとも１つのスケジューラを含むスケジューラ層が提供される。スケジューラ１５ａ、１５ｂ．．．１５ｎは、ＪＶＭ内の１つまたは複数の緊密に関係するコンポーネントと、これらのコンポーネントをいつ実行するかを決定する論理との、グループ化である。ＪＶＭ内には、独自のそれぞれのコンポーネントの実行をそれぞれが管理する複数のスケジューラが存在可能である。たとえば図２に示されるように、ＪＶＭ １２は、コンポーネント２１および２２の実行を管理するためのスケジューラ１５を実装し、コンポーネント２６および２７を実行するためのスケジューラ１６を実装する。第２のＪＶＭ １３は、コンポーネント２８および２９を管理するためのスケジューラ１７を含む。具体的に言えば、図２に示されるように、階層内のＪＶＭとコンポーネントとの間のスケジューラ層が、ＪＶＭ内のコンポーネントの実行を管理する。ＪＶＭ内では、コンポーネント間の通信およびスケジューラ間の通信が、参照を渡すことによって効率的に実施されることを理解されよう。ＪＶＭ内には、それぞれが独自のコンポーネントの実行を管理する複数のスケジューラが存在可能である。コンポーネントが保留中の入力メッセージを有する場合、スケジューラは、それを実行するのに使用可能なスレッドを割り当てるための適切な時間を選択することになる。この決定は、システム・ロード、ユーザが必要とするスループット、キューイングによって生じるメモリ消費などの、いくつかの要素に基づいて行われる。スケジューラが複数のコンポーネントを同時に実行することを決定した場合、同時処理が取得される。

コンポーネント
周知のように、コンポーネントはサービス指向またはイベント指向とすることが可能であり、ＳＣＡのようなコンポーネント・モデルに適合した「オブジェクト」の任意の集合とすることができる。典型的には、Ｊａｖａ言語またはＣ＋＋言語または同様のオブジェクト指向言語、あるいは、ＰｙｔｈｏｎまたはＰｅｒｌなどの他の言語が、ＳＣＡサービス・コンポーネントおよびコンポーネント間で送信されるデータを実装するために使用される。すなわち、コンポーネント間の対話は、ポートを横切ってデータ・メッセージを渡すことによって、またはサービス消費者からサービス提供者へのサービス呼び出しによってのみ、実行され、ここではデータ値を渡すことおよび戻すことが可能である。送信されたメッセージまたはサービス呼び出しの受信者は、同期方法を備えたオブジェクトとして表される。いかなる時点でも、コンポーネント内には１つの制御スレッドが存在する。コンポーネント間ではいかなるオブジェクトも共有されない。オブジェクトは、（ａ）コンポーネント・オブジェクトそれ自体、同期方法を備えた「モニタ」、（ｂ）コンポーネント間で渡すことが可能であるが決して共有されない、「値」オブジェクト、または（ｃ）共有可能であるが、コンポーネント・オブジェクト自体の中で、または同じ値オブジェクト内での、いずれかのみで可能な、「実装」オブジェクトの、いずれかである。とりわけ、複数の実行コンポーネントによってデータが同時に所有されないことを保証する、この規律は、Ｄａｖｉｄ Ｂａｃｏｎ、Ｒｏｂｅｒｔ Ｓｔｒｏｍ、Ａｓｈｉｓ Ｔａｒａｆｄａｒ等による、「Ｇｕａｖａ：ａ ｄｉａｌｅｃｔ ｏｆ Ｊａｖａ ｗｉｔｈｏｕｔ ｄａｔａ ｒａｃｅｓ」と題するオブジェクト指向のプログラミング、システム、言語、およびアプリケーションに関する第１５回ＡＣＭ ＳＩＧＰＬＡＮ会議２０００の議事録において、様式化および記述されている。Ｇｕａｖａ技法によれば、特定のコンポーネントがこの規律に従うことを静的にチェックすることが可能である。ＪＶＭで実行されるＪａｖａのＧｕａｖａ言語は、本発明の環境で使用するのに好適なコンポーネント実装言語の単なる一例である。

コンポーネントを「配線可能（wireable）」にするために、コンポーネントによって処理されるサービス呼び出しのための入力方法、またはコンポーネントによって受け取られる非同期メッセージに関するメッセージ・キューは、入力「ポート」として外部で使用できるようになっている。他のコンポーネントに対して呼び出しを実行するかまたはメッセージを送信するサイトは、図２に示されるように、出力「ポート」として外部で使用できるようになっている。（ａ）出力ポートを入力ポートにどのように「配線する」か、および（ｂ）コンポーネントをどこに配置するか、を決定する、別の展開時間決定が実行されることが想定される。これらの決定の結果として、いくつかのポート接続がローカルであり、その他がリモートであるものとすることができる。メッセージおよびサービス呼び出しは、ポート接続が同じＪＶＭ内のコンポーネントを接続する場合（たとえば、図２の接続４０）、より効率的に（たとえば「参照によって」）通信され、これらのコンポーネントが異なるＪＶＭ内にある場合（たとえば、図２の接続４２）、より非効率的に（たとえば、コピーによるか、またはネットワーク・メッセージの送信によって）通信される可能性があることを、理解されよう。

前述のように、本発明の実行サーバは、マシン間にまたがる分散型実行をサポートするように設計される。Ｊａｖａ仮想マシン（ＪＶＭ）の複数のインスタンスは、展開に応じて、それらのマシン上で実行可能であるか、または単一のマシン内の異なるプロセスとして実行可能である。図２に示されるように、ＪＶＭ間でのメッセージ通信に関する例示的プロトコルは、ユーザ・データグラム・プロトコル（ＵＤＰ）３０である。したがって、図２に示された例示的実施形態では、ＪＶＭ １２はＵＤＰメッセージング・プロトコルを介してＪＶＭ １３と通信する。周知のように、ＵＤＰの使用では保証された送達は提供されないが、伝送制御プロトコル（ＴＣＰ）よりも良好な性能を特徴とする。その代わりに、以下でより詳細に説明するように、本発明のミドルウェア・コンポーネント内には、損失がなく、順序が保持される、メッセージングが構築される。

開発
本発明の実行サーバは、（１）開発環境が根本的に簡略化されており、コンポーネントはプレーンＪａｖａで作成可能であり、分散型フロー・ネットワークを構築するためにＳＣＡコンポーネント・モデルのように配線可能であること、（２）コンポーネントは、プレーンＪａｖａの基本変数および集合クラスで状態を格納すること、（３）プログラマは、コンポーネント状態を別々のオブジェクトに分割するため、およびその状態を持続するために、トランザクション、ＪＤＢＣ、またはエンティティ・ビーンなどの、特化された方法および構造を使用する必要がないこと、という理由から、他の手法と区別される。その代わりに、マシン障害、ならびに、メッセージをドロップ、再順序付け、または複製する可能性のある不良ネットワークにもかかわらず、本発明の実行サーバによって、持続性および耐障害性が自動的に提供される。

決定的実行
本発明の方法によれば、耐障害性に関する技術は、決定的で再生可能なシステムの実行を保証することに基づく。これは、トランザクションに基づく、または複製に基づく、またはすべてのコンポーネント間メッセージの持続的記録に基づく、他の手法に勝る、改良点である。決定的実行とは、システムに同じ状態および同じ入力メッセージが与えられた場合、同じ出力メッセージを生成することを意味する。決定性とは、コンポーネントの障害時に、最近のチェックポイントを回復すること、およびそのチェックポイント以降に発生したイベントを再生することによって、その状態を復元できることを示唆する。決定性のために、再生以後の状態は失われた状態と同じであることが保証される。これは、状態を、更新されるごとに持続的に保存しておく必要がなく、断続的に保存すればよいことを意味する。

決定的実行の達成は、離散型イベント・シミュレーションからの技法を一般化すること、およびそれらを実行サーバの実行時環境に適用することに基づく。イベント・シミュレータの場合と同様に、コンポーネント間で通信される各メッセージには、仮想時間（ＶＴ）タグが付けられる。イベント・シミュレータとは異なり、この仮想時間は、メッセージが受信側コンポーネントに到達することになる実時間の決定的推定となるように選択される。本発明の実行サーバは、あたかもメッセージが仮想時間順に到達したかのように、システムが動作することを保証する。仮想時間と実時間とが良好に一致するほど、システムは良好に動作するが、この一致がどれほど良好であるかにかかわらず、決定的実行は保証される。この手法の変形では、仮想時間は実時間のデッドラインであり、システムはこれらの実時間デッドラインに合致することを保証するように、スケジューリングを調整する。これも、シミュレートされた仮想時間が実時間と明白に相関しない可能性のある、イベント・シミュレータの場合とは異なる。

決定的実行は、仮想時間（ＶＴ）を含むタイムスタンプですべての通信を増補することによって達成される。システム境界で、生成された時点ではタイムスタンプを含んでいない外部イベントが受信される。本発明によれば、システムは手動介入なしで、それらのイベントにＶＴを自動的に割り当てる。ＶＴは、因果的（causal）順序に従い、すなわち、入力によって出力が発生する場合、初期の仮想時間では決して発生せず、実時間近くに発生する。ログは、割り当てられるすべてのＶＴを記録するが、これは、それらの生成が非決定性であり、後に再生が必要な場合にそのログが不可欠となるためである。イベントは、ＶＴによって境界上で増補されると、コンポーネント間の接続を介して移動し、決定的順序で処理される。その後のログは不要である。これは、非決定性着信順序が再生可能なようにコンポーネント間でのメッセージのログが必要な、楽観的回復によって使用される手法およびトランスペアレントな耐障害性の他の従来技術の技法とは対照的である。２つのメッセージが同一のＶＴを有することは決してないことを理解されよう。

実行するコンポーネントが選択されると、その入力メッセージの処理の結果として出力を生成することができる。この出力は、非ゼロの計算遅延を反映して、入力メッセージのＶＴよりも厳密に大きいＶＴと関連付けられる。ＶＴにおける増分、ならびに出力メッセージは、入力メッセージによって完全に決定される。コンポーネントは、たとえば送信されたメッセージまたはサービス呼び出しメッセージなどの、複数の先行コンポーネントからの入力を受信することができる。この場合、メッセージのＶＴに基づいて決定性マージが利用される。ＶＴは先行要素によって独立に生成されるが、マージの際にローカルに比較される。最小ＶＴを有するメッセージは、いかなる先行要素も、今後、より早期のＶＴを備えたメッセージを送信できないことがわかると、安全に処理することができる。代替実施形態では、１９８５年７月付けのＪｅｆｆｅｒｓｏｎ，Ｄによる「Ｖｉｒｔｕａｌ ｔｉｍｅ」と題するＡＣＭ Ｔｒａｎｓａｃｔｉｏｎｓ ｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｌａｎｇｕａｇｅｓ ａｎｄ Ｓｙｓｔｅｍｓに記載された、離散型イベント・シミュレーション環境の場合と同様に、早期のＶＴを備えたメッセージが着信すると、メッセージを積極的に処理し、ロールバックすることが可能であることを理解されよう。決定性ＶＴ生成および決定性マージング（どちらもコンポーネントに対してローカルである）により、メッセージ処理の順序は決定的である。

展開時間メカニズム
持続的な分散型計算に関する決定的実行メカニズム間の主な相違点として、本発明の手法では、わずかながらユーザの介入が必要である。具体的に言えば、開発者は、ＶＴまたはそれらの計算方法を知る必要がない。アプリケーション開発者の作業を劇的に簡略化するためのツール・セットが提供されるが、本明細書で説明される恩恵はまったく損なわれることがない。

配置サービス
図３に示されるように、設計時、コンポーネントの計算論理は、プレーンＪａｖａ、Ｃ＋＋、または同様のオブジェクト指向コード、あるいはＰｙｔｈｏｎまたはＰｅｒｌなどの他の言語で作成することができる。ポートは、たとえばＪａｖａインターフェースで定義される。論理接続は、２つまたはそれ以上のポートを配線することにより、設計者によって作成される。この高水準設計は、結果として生じるシステムの分散性を完全に取り除く（abstract）。さらに、決定的実行および耐障害性などの特性を当然のものとみなす。図４に示されるように、ミドルウェア配置サービス・コンポーネント５０を使用して、図３に示される設計などのこの高水準設計を、低水準実装にマッピングし、ここでは最も相互に関係するコンポーネントがスケジューラにグループ化され、スケジューラは、おそらくは異なるマシン上のＪＶＭ内に割り当てられる。実行前の配置は、マシンの計算能力のメトリクス、ネットワーク機能、および配置プリファレンスなどの、ユーザ供給パラメータにより、半自動式である。性能を最大限にするために、異なるマシン上の作業負荷は平均化される。実行時、全体の性能を良くするために、スケジューラをそれらの元のマシンから他のマシンへと移動させることによって、初期の配置を微調整することができる。配置に応じて、開発者ビューにおける論理接続を物理接続にマッピングすることもできる。

この配置サービス５０は展開タスクを簡略化するが、ユーザ指定の構成を受け入れることによって、依然として十分な柔軟性を提供する。

したがって、例示の目的で提示された図３に示されるような配置の非限定的な一例では、２つの異なる要求パスからのメッセージの受け取り、すなわち、たとえばイベントで座席を予約する要求者３２、３４をモデル化するために使用可能な、チケット（チケット販売）システム３０の例示的設計者ビューの高水準手法が示される。これらのチケット要求は、第１に、各要求者によって要求されているチケットの枚数（たとえば５チケットまたは１０チケット）を決定するために、受信および処理された後、最終的にプリンタ・デバイスでチケットを印刷するためのプロセスが割り当てられる。以下の例示的なコード部分は、図３に示された例示的システムの高水準設計に従って、プレーンＪａｖａで作成可能な、コンポーネントの論理（たとえば、基本変数、集合クラスなど）を示す。

配置サービス５０は、図４に示されるような低レベル実装に関するコードを生成する。結果として生じる、図４に示される低レベル実装では、要求者は、メッセージを受信する第１のＪＶＭ ６２に関するポートを定義することによってモデル化され、それぞれの要求を処理し、その要求を割り当て者コンポーネント６５でマージする、第２のＪＶＭ ６４で、定義されたそれぞれのポートがさらにモデル化され、割り当て者コンポーネント６５は、スケジューリングされたチケット印刷プロセスを実行するためのプリンタ・コンポーネント６７を含む第３のＪＶＭ ６６に関する単一のポート定義することによってモデル化される、プリンタ機能コンポーネントを割り当てる。以下の例示的コード部分は、図４に示された例示的システムの低レベル設計に従ってプレーンＪａｖａで作成可能な、配置論理を示す。この以下の例示的コードは、図４に示されるように、要求者コンポーネント３２、３４を管理するための第１のスケジューラ７２を含むように設計された、第１のＪＶＭ ６２の構成を示す。

以下の例示的コードは、図４に示されるように、要求者コンポーネント３２、３４に対応する処理コンポーネントを管理するためのスケジューラ７４を含むように設計された、第２のＪＶＭ ６４の構成を示す。

この以下の例示的コードは、図４に示されるように、単一の入力から印刷処理コンポーネントを管理するためのスケジューラ７６を含むように設計された、第３のＪＶＭ ６６の構成を示す。

自動コード・エンハンサ（enhancer）
本発明では、プログラム変換器が、実行時実行環境に適合可能なコンポーネントを生成するために、ユーザ作成コンポーネントを増補する。具体的に言えば、プログラム変換器は、以下の拡張機能を供給する。１）入力および出力メッセージまたは方法呼び出しのすべてのインターフェースが、ＶＴを保持するフィールドで増補される。２）入力ポートに着信するメッセージを処理する各方法が、生成する各出力メッセージに関して、およびその方法からの戻りに関して、「デルタＶＴ」を算出するエスティメータで増補される。デルタＶＴは、方法の開始から生成された出力メッセージまで、または戻りまで、経過することになる、実時間量の決定的推定を表す。さらに３）各コンポーネントは、最後のソフト・チェックポイント以降のその状態に対する増分変化を追跡し、スケジューラからの要求時に、増分ソフト・チェックポイント記録を直列化する、コードで増補される。

ソフト・チェックポイントとは、システムの回復機能を損なうことなく、いずれかの単一のチェックポイントが失われる可能性があるため、そのように呼ばれるが、損失チェックポイントは、前のチェックポイントから回復処理を進めなければならないことを意味するため、障害後の回復時間を長引かせる可能性があるが、最終的な回復機能には影響を与えない。これとは逆に、コンポーネントは、増分ソフト・チェックポイント記録の集合から状態を再構築するコードで増補される。オプションとして、コンポーネントは、「熱心な沈黙（eager silence）」を生成するコードで増補することが可能である。すなわち、所与の時間ｔを通じてその入力ポートに着信する入力メッセージがないことがわかった場合、メッセージが所与の出力ポートに出現可能な時間ｔを超えた、最も早期のデルタＶＴを計算する。こうした計算は、これらの入力ポートに接続されたコンポーネントに沈黙を送信する目的に使用することができる。沈黙タイムスタンプの範囲は、それらのタイムスタンプを備えたメッセージが今後そのコンポーネントから送信されることがない旨を約束するものであることから、こうした情報によって、待機メッセージが最も早期の可能メッセージであることがわかるため、おそらく、受信側コンポーネントにその処理を進行させることが可能である。

図５は、図４の例に示された例示的チケット・システムにおいて低水準設計によって示されるような、本発明を実装するために必要なメッセージ構造を増補するために使用される、ＶＴの決定性をより詳細に示す。メッセージまたはイベント（「ｅ」）は、システム境界上のＶＴと関連付けられることを理解されよう。現時点で、ＶＴは、因果関係と一致する任意の方法で生成される。しかしながら、それらは実時間の推定とすることも可能である。したがって、図５に示されるように、実行時中、第１のＪＶＭ ６２の第１の要求者コンポーネント３２で受信された例示的な関連データ文字列（ｅ_１ ^１）を含む、受信メッセージ構造４２については、メッセージ構造４２に追加される第１のＶＴ値（ｖｔ_１ ^１）が関連付けられ、第２の要求者３４で受信された例示的な関連データ文字列（ｅ_１ ^２）を含む、受信メッセージ構造４４については、メッセージ構造４４に追加されるＶＴ値（ｖｔ_１ ^２）が関連付けられる。加えて図５は、スケジューラからの要求時に、データ・ストレージ・デバイス内のログ９９へのエントリで示される、増分ソフト・チェックポイント記録の生成を実行する、最後のソフト・チェックポイント以降のその状態に対する増分変化の追跡を示す。このログ９９は、割り当てられるすべてのＶＴを記録するが、これは、それらの生成が非決定性であり、以下でより詳細に説明するように、再生が必要な場合にそのログが不可欠となるためである。これらの増補されたイベントまたは要求メッセージ４２（ｅ_１ ^１；ｖｔ_１ ^１）および４４（ｅ_１ ^２；ｖｔ_１ ^２）は、それぞれ、それらのスケジューリングされたＶＴ（仮想時間）に第２のＪＶＭ ６４に入力され、ここで、ＪＶＭ ６４内のコンポーネントを処理するそれぞれの要求メッセージによって処理される。すなわち、図５に示されるように、第２のＪＶＭ ６４で受信した入力増補要求メッセージ４２を処理した後、第２のＪＶＭ ６４の第１のコンポーネントから出力された算出ＶＴ値（ｅ_２ ^１；ｖｔ_２ ^１）を含むように増補された他のメッセージ５２が生成され、同様に、第２のＪＶＭ ６４の第２のコンポーネントから出力された算出ＶＴ値（ｅ_２ ^２；ｖｔ_２ ^２）を含むように増補された他のメッセージ５４が生成される。割り当て者コンポーネント６５によって示されるマージ・ポイントで、複数のストリームからのイベントがそれらのＶＴを使用して比較される。したがって、図５に示されるように、第２のＪＶＭの割り当て者コンポーネントからの出力は、一時的に配列されたメッセージ５２および５４、すなわち［ｅ_２ ^１；ｖｔ_２ ^１］および［ｅ_２ ^２；ｖｔ_２ ^２］を備える、決定的にマージされたメッセージ・シーケンス５５である。第３のＪＶＭ ６６で実装されるこの決定的マージャは、その後、受信メッセージ５５内にマージされたＶＴ値に基づいて、印刷コンポーネント６７に関して決定的順序で動作を配列する。

メッセージ損失および再順序付けの許容範囲
前述のように、ＪＶＭ内では、コンポーネント間の通信は参照を渡すことによって効率的に実施される。さらにＪＶＭ内通信は、損失が無く、順序が保持される。ＪＶＭ間では、たとえメッセージ損失または再順序付けが発生する可能性があっても、スケジューラ間では送信されるがスケジューラ内では送信されない、沈黙および好奇メッセージの概念を実装する、本発明のミドルウェア・コンポーネントによって、こうした損失または再順序付けが許容されるため、ＵＤＰ通信を使用することができる。

図６に進むと、本発明のシステム内での紛失メッセージの検出を確実にするための、沈黙および好奇メッセージの組み込みが示されている。図３〜図５に示されたような、本発明の例示的適用例で言及され、次に図６で示されるように、すなわち、２つのメッセージが時間線内で互いに厳密に隣り合っていない限り、ＶＴ内には時間のギャップが存在することが想定される。時間のギャップの存在は、サーバのミドルウェア・コンポーネント、たとえばスケジューラによって検出される。たとえば、第１のＪＶＭ ６２が第１の増補メッセージ４２を送信した後、および第２の増補メッセージを送信するのに先立ち、ＪＶＭ ６２は、ギャップを埋めるために１つまたは複数の沈黙、すなわち沈黙メッセージ８１を生成および送信することから、結果として受信者、たとえばＪＶＭ ６４は、メッセージまたは沈黙のいずれかの連続的な知識を取得することになる。沈黙メッセージは、メッセージを含まないことが知られているＶＴの時間チック（tick）範囲を指定する、１対の数字を定義する。たとえば、図６でメッセージ４２の直前に送信されるメッセージ８０は、データ［Ｓｉｌｅｎｃｅ；１００：ｖｔ_１ ^１−１］を含むことが可能であり、これは、１００からｖｔ_１ ^１−１までの範囲内にあるすべてのＶＴチックがメッセージを含まないことを知られていることを意味する。沈黙メッセージのために、受信者はあらゆるチックを、明確にメッセージを含むかまたは沈黙かの、いずれかとして説明することができる。データまたは沈黙メッセージが失われた場合、受信者はギャップに気付くことになる。ギャップの検出は、受信者側で実行される。（ユーザ構成可能またはプログラム可能パラメータとして定義された）ある期間中にギャップが存在する場合、受信者、たとえばＪＶＭ ６４は、何らかのメッセージまたは沈黙が失われたものと決定し、送信者、たとえばＪＶＭ ６２に対して、受け取りに関する好奇メッセージ８３を逆に発行することができる。好奇メッセージは、受信者がデータまたは沈黙に関する知識を持たない、したがってそれに関して「好奇心がある」、ＶＴの時間「チック」範囲を指定する１対の数を定義する。たとえば、この沈黙メッセージが何らかの形で失われた場合、好奇メッセージは［Ｃｕｒｉｏｓｉｔｙ；１００：ｖｔ_１ ^１−１］を読み取ることになる。好奇メッセージは、照会されているチックの範囲に関して、送信者による以前のメッセージまたは沈黙の再送をトリガする。送信者は、受信者がソフト・チェックポイントを正常に受け取り、再度再送要求をしないことを約束するまで、これらのメッセージまたは沈黙の再送に備えなければならない。

好奇メッセージが失われるか、または再送メッセージが失われた場合、好奇メッセージが再送されることになる。同じメッセージが極めて頻繁に失われない限り、失われたメッセージは最終的に取り戻されることになる。メッセージは遅れて着信する可能性があり、再送メッセージを複製する可能性があるが、すでに処理したメッセージに関する時間とそのＶＴが合致するいかなるメッセージも廃棄することが、受信者にとって安全であるため、これによっていかなる問題も生じないことを理解されたい。（２つのメッセージが同一のＶＴを有することは決してない。）受信者は、その前に依然としてギャップがある場合、単にメッセージの処理を拒否するだけであるため、再順序付けも許容される。したがって、図６に示されるように、照会、沈黙、および好奇は、正しい順序でメッセージを処理することを全体で保証する。

今までのところ、ＶＴ生成は、完全に決定性である場合、およびメッセージの因果性を保持する場合、任意とすることができる。こうした任意のＶＴ割り当てが、決定的実行を保証する。しかしながら、ＶＴが実時間とはるかに同期していない場合、マージの時点で受信者は、ＶＴの早期にはいかなるメッセージも受信しないことが確実になるまで、次のメッセージの処理を拒否することになるため、性能上の不利が見られる。これにより、実時間で早期に生成されたメッセージは、推定の不正確さによってより長いＶＴを獲得することから、後で処理されることになる可能性がある。ＶＴおよび実時間をほぼ同期して維持しようとするために、自動ＶＴエスティメータが提供され、結果としてこの悲観論によって受け入れがたい性能の損失が生じることはない。このＶＴ推定に対して、静的（すなわち事前実行）および動的（すなわち実行中）コンポーネントの両方が存在する。静的には、自動ＶＴエスティメータは、コードの既知の複雑さに基づいて個々のコンポーネントにおける計算遅延を推定する。展開時、エスティメータは、コンポーネントが展開された環境の既知の特性を考慮に入れることもできる。これにより、ネットワーク待ち時間、平均ＣＰＵロード、ガーベージ・コレクタ性能、予測されるメモリ消費量、スレッディングなどを反映するように、計算遅延の推定が調整されることになる。しかしながら、計算遅延の推定は、コンポーネント状態の決定的な反復可能機能でなければならないことを強調すべきである。実電流ＣＰＵロードなどの非決定性要素は考慮しない可能性がある。不運にも、ＶＴと実時間との間の相違が大きくなり過ぎたことにスケジューラが気付いた場合、以下の２つの可能な処置のうちの１つを講じることができる。
１．スケジューラは、速度をダウンまたはアップし、相違を少なくするように、マシンの他のスケジューラに対してその優先順位を変更することが可能である。
２．スケジューラは、スケジューラ内で使用されるエスティメータに対してパラメータを調節するために、非決定性決定、いわゆる「決定性障害」を実行することが可能である。この調節は、通常の計算遅延の推定とは異なり、非決定性要素を考慮に入れるために、非決定性とすることができる。こうした決定によって決定性が侵害されることから、適切な再生を保証するために、この処置は安定ストレージ内にログ記録しなければならない。実際のところ、決定以前には、いかなるＶＴの再生も古いエスティメータを使用しなければならず、決定後には、いかなるＶＴの再生も新しいエスティメータを使用しなければならない。決定性障害は、結果として、特定のメッセージに関する特定の時間推定値の変更を生じさせる可能性がある。このシステムの目標は、ＶＴと実時間との間のドリフトが最小限となり、スケジューリング優先順位の調整によって制御可能であるように、さらに結果として、決定性障害が極端に稀なイベントであるように、静的エスティメータを十分良好にすることである。

実時間分析
非時間認識コンポーネントの場合、本発明のミドルウェアのＶＴエスティメータを使用してタイムスタンプの導入が自動化される。しかしながら、一部のアプリケーションは時間認識とする必要がある可能性があり、またはより複雑なシナリオの場合、ある種のアプリケーションが非時間認識コンポーネントおよび時間認識コンポーネントの混合を含む可能性がある。タイミング制御の必要性を満たすために、本発明のミドルウェア・コンポーネントでは、特別な時間制御コードに自動的にコンパイルされるタイミング制約を、設計者によって指定することができる。実行時、このコードは、コンポーネントの優先順位付けまたはコンポーネントの移動によって、スケジューラが時間制約を満たすように実行することができる。すなわち、実時間スケジューラは、実時間デッドラインを保証するために配置サービスと共に動作するようにプログラミングすることができる。配置サービスは、デッドラインを満たすだけの十分な予約容量があることを確認するために、こうしたスケジューラを展開する前に、何らかの入場制御を実行する必要がある確率が高い。加えて、新しい種類の決定性障害が発生する可能性もあり、異常な条件によって所与の計算が実時間デッドラインを満たさないことが明らかになった場合、（おそらくはオーバヘッドの少ない）代替計算を使用するという非決定性決定を実行することができる。いずれの決定性障害とも同様に、こうした変更を行うという決定は、ログ記録しておく必要がある。

高可用性によるマシン障害の許容範囲
分散型システムでは、予期せずにマシンがシャットダウンされ、ネットワークから切断されるか、または障害を起こす可能性がある。多くの現在のアプリケーションは、マシン間の協働を利用する。複数のマシンを使用することによって、高可用性が実行可能になる。この特性により、いくつかのマシンの障害がアプリケーション全体の機能を妨害することはない。本発明の実行サーバでは、耐障害性はトランスペアレントである。ミドルウェア・コンポーネントは、個々のスケジューラに対して断続的にソフト・チェックポイントを作成する。ソフト・チェックポイントとは、内部にコンポーネント、確立された接続、キューに入れられたメッセージ、待機中のサービス呼び出しなどを含む、スケジューラの状態のコンパクト・イメージである。ソフト・チェックポイントは、全状態を含むか、または前のソフト・チェックポイント以降の増分変化を含むことができる。ユーザ定義コンポーネントの状態（たとえば、相互参照のＪａｖａ基本値およびオブジェクトなどの言語水準エンティティを含む）もチェックポイントに記録されるため、マシンに障害が発生し、回復した場合、計算を再開することができる。

したがって、図３から図６に示され、次に図７で示されるような、本発明の例示的アプリケーションでは、ＪＶＭ ６４、６６内の各スケジューラに関するチェックポイント情報８４、８６は、たとえば、それぞれハード・ディスク・ドライブ９４、９６などのローカル・メモリ・ストレージ・デバイス上に格納され、断続的または増分的に更新される。しかしながら、これらのチェックポイントは、リモート・マシンで、またはリモート・マシン上に格納可能であることを理解されよう。

ＪＶＭマシンは、実行中にクラッシュする可能性があり、このイベントにより、その上で実行中のスケジューラは停止し、それらの最後のチェックポイント以降の状態は完全に失われる。マシンは再始動すると、それらの最後のチェックポイントでスケジューラを再作成する。したがって、図３〜図６に示され、図７に示されたような、本発明の例示的アプリケーションの場合、ＪＶＭ ６４でクラッシュ・イベントが発生したものと想定すると、格納されたＪＶＭ ６４内の例示的スケジューラに関するチェックポイント情報８４’が、たとえばハード・ディスク・ドライブ９４などのローカル・メモリ・ストレージ・デバイスから、ＪＶＭ ６４で実行中の再始動したスケジューラ・コンポーネントへと再送されることになる。チェックポイントが取得された後に、いくつかのメッセージが受信され、処理された可能性さえもあるため、これらのチェックポイントはスケジューラの過去の要素内にある。したがってスケジューラは、それらの先行要素に別個に好奇メッセージ８５を送信し、これによって先行要素が紛失メッセージを再送することになる。その後、本発明に従ってこの紛失メッセージが再処理され、本発明によって与えられる決定的実行によって、同じ結果が生成されることになる。スケジューラが障害の発生した時点まで遅れを取り戻した場合、その状態は、障害が発生する直前の状態と同一になる。その後、新しいメッセージの処理を続行する。

前述のように、ＪＶＭ内の各スケジューラに関するチェックポイント情報は、リモート・マシン（たとえばＪＶＭ）上に格納し、断続的または増分的に更新することができる。したがって、代替実施形態では、リモートに配置されたスケジューラが、他のスケジューラからのチェックポイントを格納することによって、「受動的バックアップ」を実行することができる。受動的バックアップを使用してチェックポイントが格納された場合、障害が検出されると、この受動的バックアップがバックアップされたコンポーネントのインスタンスを作成し、すなわちレプリカを生成し、アクティブとなって、再始動して紛失計算の遅れを取り戻すまで、障害を起こしたスケジューラの作業を再開する。受動的バックアップは、何らかの他の耐障害性システムのアクティブなレプリカとは異なり、冗長計算は実行しない。それらは単にチェックポインティングされた状態を保持するだけであるため、アクティブなマシンに障害が発生した場合、そのバックアップが最小遅延で計算を迅速に引き継ぐことができる。

したがって、図３〜図６に示され、次に図８に示されるような、本発明の例示的アプリケーションでは、ＪＶＭ ６４内の例示的スケジューラに関するソフト・チェックポイント情報８４は、そこで格納するために第３のＪＶＭ ６６内にリモートに格納された、第２のＪＶＭ ６４のためのバックアップ・スケジューラ・コンポーネント７４に関連付けられたメモリに送信されることになり、同様に、図８に示されるように、ＪＶＭ ６６内の例示的第３のスケジューラに関するソフト・チェックポイント情報８６は、そこで格納するために第２のＪＶＭ ６４内にリモートに格納された、第３のＪＶＭ ６６のためのバックアップ・スケジューラ・コンポーネント７６に関連付けられたメモリに送信されることになる。したがって、たとえば、スケジューラ２およびバックアップ・スケジューラ・コンポーネント７６を含むＪＶＭ ６４が使用不可になるか、またはそうでなければクラッシュした場合、図９に示されるように、ＪＶＭ ６４内で実行していたスケジューラ２のレプリカを生成することができる。すなわち、ＪＶＭ ６６では、ＪＶＭ ６４内で実行していたスケジューラ２のレプリカを、リモートの受動的バックアップに基づいて生成することができる。すなわち、実行用に第２のＪＶＭ ６４のコンポーネントを含む、新しいスケジューラ２’が生成される。高可用性保証を提供するものが障害を起こした場合、最大の障害検出遅延およびレプリカ作成時間に基づいて、最大のダウンタイムを推定することができる。

最終的に、図３〜図６に示されたように、また次に図１０で示されるように、本発明の例示的アプリケーションでは、クラッシュした第２のＪＶＭ ６４の回復時に、復活したスケジューラ２は、第３のＪＶＭ ６６内で生成されたレプリカ、すなわちスケジューラ２’で格納されていたチェックポインティング情報を、フェッチすることになる。したがって、第２のＪＶＭ ６４がアップされ、通知メッセージ９１を介して実行している旨を、他のマシン（たとえばＪＶＭ １）の先行コンポーネントに示すこと、さらに、生成されたスケジューラ２のリモート・バックアップ（すなわちスケジューラ２’）は終了可能である旨を、第３のＪＶＭ ６６に示すことが、可能である。

以上、本発明について、その例示的かつ事前形成された諸実施形態に関して、具体的に例示および説明してきたが、当業者であれば、添付の特許請求の範囲によってのみ制限されるべきである、本発明の趣旨および範囲を逸脱することなく、形式および細部における前述および他の変更が可能であることを理解されよう。

Claims (22)

1. タスクを実行するための論理をそれぞれが実装する複数のコンポーネントであって、前記コンポーネントが、ネットワーク内で接続され、前記コンポーネント間でメッセージを通信するように適合された、１つまたは複数のマシンを備える実行環境内で実行する、複数のソフトウェア・コンポーネントと、
   プログラム実行中に送信側コンポーネントから受信側コンポーネントへと送られるメッセージであって受信側コンポーネントにおいて非決定性着信順序をもつものとして特徴付けられるメッセージに関して、決定性タイムスタンプを自動的に生成して関連付けるための手段であって、前記タイムスタンプが受信側コンポーネントでの前記メッセージの着信の推定時刻を表す、自動的に生成して関連付けるための手段と、
   入力メッセージの固有の着信順序を生成するために前記タイムスタンプを使用することによって、前記コンポーネントを決定的に実行するための手段と、
   プログラム実行中にコンポーネント状態を追跡し、前記状態をローカル・ストレージ・デバイスにチェックポインティングするための手段と、
   を備え、
   マシンの障害時には、最近格納されたチェックポイントを回復すること、前記最後のチェックポイント以降に発生したイベントを再実行することによって、前記コンポーネント状態が復元される、
   コンピューティング・システム。
2. 前記コンポーネント状態がバックアップ・プロセッサ・デバイスにチェックポインティングされる、請求項１に記載のコンピューティング・システム。
3. 前記実行環境が単一のＪａｖａ仮想マシンを備え、前記コンポーネントのそれぞれが前記単一のＪａｖａ仮想マシンに格納される、請求項１に記載のコンピューティング・システム。
4. 前記実行環境が複数のＪａｖａ仮想マシンを備え、前記コンポーネントが、前記複数のＪａｖａ仮想マシン全体にわたって分散様式で実行する、請求項１に記載のコンピューティング・システム。
5. 前記実行環境が、１つまたは複数のコンポーネントの実行を管理するためのスケジューラ・コンポーネントを含み、スケジューリングが、前記実行環境内のコンポーネントに関する実行スレッドを割り振ることを含む、請求項４に記載のコンピューティング・システム。
6. コンポーネントが複数の先行コンポーネントから入力メッセージを受信し、前記システムが、前記入力メッセージのタイムスタンプに基づいて決定性マージを実行するためのマージャ手段をさらに備える、請求項４に記載のコンピューティング・システム。
7. 前記コンポーネントの状態が断続的に更新される、請求項１に記載のコンピューティング・システム。
8. 前記タイムスタンプが、メッセージが前記受信側コンポーネントに着信する実時間の推定として計算される、請求項１に記載のコンピューティング・システム。
9. コンポーネントからの連続するメッセージ伝送間の時間のギャップを検出するための手段と、
   前記実行環境における前記コンポーネントからのメッセージの正しい一時フローを保証するために、沈黙メッセージの伝送を実行可能にする手段と、
   をさらに備える、請求項１に記載のコンピューティング・システム。
10. マシン間のネットワーク接続における障害によって何らかのメッセージまたは沈黙メッセージが失われたものと、コンポーネント受信側が決定した場合、いずれかの以前のメッセージまたは沈黙メッセージの再送をトリガするために、送信側コンポーネントに好奇メッセージを逆に発行するための手段、
    をさらに備える、請求項９に記載のコンピューティング・システム。
11. コンポーネント間でのメッセージ通信を実行可能にするように適合された実行環境を提供するコンピューティング・システム内でコンポーネントを決定的に実行するための方法であって、各前記コンポーネントがタスクを実行するための論理を実装し、
    プログラム実行中に送信側コンポーネントから受信側コンポーネントへと送られるメッセージであって受信側コンポーネントにおいて非決定性着信順序をもつものとして特徴付けられるメッセージに関して、決定性タイムスタンプを自動的に生成して関連付けることであって、前記決定性タイムスタンプが受信側コンポーネントでの前記メッセージの着信の推定時刻を表す、自動的に生成して関連付けることと、
    入力メッセージの固有の着信順序を生成するために前記タイムスタンプを使用することによって、前記コンポーネントを決定的に実行することと、
    プログラム実行中に前記コンポーネントの状態を追跡し、前記状態をローカル・ストレージ・デバイスにチェックポインティングすることと、
    を含み、
    コンポーネントの障害時には、最近格納されたチェックポイントを回復すること、および前記最後のチェックポイント以降に発生したイベントを再実行することによって、前記コンポーネントの状態が復元される、
    方法。
12. 前記メッセージを、前記格納された状態で記録された前記タイムスタンプに関連付けられたメッセージと同じ順序で処理することによって、前記受信側コンポーネントの前記実行を反復することをさらに含む、請求項１１に記載の方法。
13. 受信されたメッセージに関連付けられた前記タイムスタンプに従って、前記実行環境内の前記コンポーネントの実行を管理することをさらに含み、前記管理することが、前記実行環境内のコンポーネントに実行スレッドを割り当てることを含む、請求項１１に記載の方法。
14. コンポーネントが複数の先行コンポーネントから入力メッセージを受信し、前記方法が、前記入力メッセージのタイムスタンプに基づいて決定性マージを実行することをさらに含む、請求項１３に記載の方法。
15. 前記コンポーネントのチェックポイントを断続的に更新することをさらに含む、請求項１３に記載の方法。
16. 前記タイムスタンプが、メッセージが前記受信側コンポーネントに着信する実時間の推定として計算される、請求項１１に記載の方法。
17. コンポーネントで、前記コンポーネントからの連続するメッセージ伝送間の時間のギャップを検出することと、
    前記実行環境における前記コンポーネントからのメッセージの正しい一時フローを保証するために、沈黙メッセージの伝送を実行可能にすることと、
    をさらに含む、請求項１１に記載の方法。
18. 何らかのメッセージまたは沈黙が失われたものと、コンポーネント受信側が決定した場合、いずれかの以前のメッセージまたは沈黙メッセージの再送をトリガするために、送信側コンポーネントに好奇メッセージを逆に発行することをさらに含む、請求項１７に記載の方法。
19. 実行環境においてコンポーネント間でのメッセージの通信を実行可能にするサブシステムであって、前記コンポーネントが、メッセージ入力が受信されるか、または前記コンポーネントから出力される、１つまたは複数のポートを備え、各前記コンポーネントがタスクを実行するための論理を実装する、サブシステムと、
    コンポーネントが前記実行環境の特定の処理エンジンに割り当てられた低水準実装に、高水準設計をマッピングするための手段と、
    プログラム実行中に送信側コンポーネントから受信側コンポーネントへと送られるメッセージであって受信側コンポーネントにおいて非決定性着信順序をもつものとして特徴付けられるメッセージに関して、タイムスタンプに関連付けられたコンポーネントの入力または出力メッセージを自動的に増補するためであって、前記タイムスタンプが受信側コンポーネントでの前記メッセージの着信の推定時刻を表す、自動的に増補するため、および
    その状態に対する増分変化を追跡するためのコードでコンポーネントを増補するための、
    コード強化手段と、
    を備え、
    プログラム実行中にコンポーネント状態が追跡され、前記コンポーネント状態はローカル・ストレージ・デバイス内でチェックポインティングされ、
    コンポーネントの障害時には、最近のチェックポイントを回復すること、および最後のチェックポイント以降に発生したイベントを再実行することによって、前記コンポーネント状態が復元される、
    コンポーネント指向アプリケーションの決定的実行を実行可能にするためのシステム。
20. 前記実行環境が分散型コンピューティング・システムである、請求項１９に記載のシステム。
21. コンポーネント間でのメッセージ通信を実行可能にするように適合された実行環境内でコンポーネントを決定的に実行するための方法ステップを実行するために、マシンによって実行可能な命令のプログラムを確実に記録する、マシンによる読み取り可能なプログラム・ストレージ・デバイスであって、各前記コンポーネントがタスクを実行するための論理を実装し、前記方法ステップが、
    プログラム実行中に送信側コンポーネントから受信側コンポーネントへと送られるメッセージであって受信側コンポーネントにおいて非決定性着信順序をもつものとして特徴付けられるメッセージに関して、決定性タイムスタンプを自動的に生成して関連付けることであって、前記決定性タイムスタンプが受信側コンポーネントでの前記メッセージの着信の推定時刻を表す、自動的に生成して関連付けることと、
    入力メッセージの固有の着信順序を生成するために前記タイムスタンプを使用することによって、前記コンポーネントを決定的に実行することと、
    コンポーネントで、プログラム実行中に前記コンポーネントの状態を追跡し、前記状態をローカル・ストレージ・デバイスにチェックポインティングすることと、
    を含み、
    コンポーネントの障害時には、最近格納されたチェックポイントを回復すること、および前記最後のチェックポイント以降に発生したイベントを再実行することによって、前記コンポーネントの状態が復元される、
    プログラム・ストレージ・デバイス。
22. 前記メッセージを前記格納された状態で記録された前記タイムスタンプに関連付けられたメッセージと同じ順序で処理することにより、前記受信側コンポーネントの前記実行を反復することによって、決定性となる、請求項２１に記載のマシンによる読み取り可能なプログラム・ストレージ・デバイス。

Images