積極的

ProActive Parallel Suite は、 OW2コミュニティの一部である、エンタープライズワークロードオーケストレーション用のオープン ソースソフトウェアです。ワークフローモデルを使用すると、任意の言語で記述された実行可能ファイルまたはスクリプトのセットをその依存関係とともに定義できるため、ProActive Parallel Suite は計算リソースの使用を最適化しながら実行をスケジュールおよびオーケストレーションできます。

ProActive Parallel Suite は、「アクティブ オブジェクト」設計パターン (アクティブ オブジェクトを参照) に基づいて、タスクの分散とフォールト トレランスを最適化します。

• ワークフローは、タスクの並列化（Java、スクリプト、またはネイティブ実行可能ファイル）を容易にし、さまざまな制約（GPU アクセラレーション、ライブラリ、またはデータのローカリティなど）に一致するリソース上でタスクを実行します。
• ジョブ ワークフローを設計および実行し、コンピューティング リソースを管理するための Web インターフェイスが提供されます。RESTful API は、エンタープライズ アプリケーションとの相互運用性を提供します。
• コンピューティング リソース (クラウド、クラスター、仮想化インフラストラクチャ、デスクトップ マシン) を単一の仮想インフラストラクチャに統合できます。自動スケーリングと容易なリソース管理戦略を提供します。
• 異種ワークフローでは相互運用性が確保され、Windows、Mac、Linux などのさまざまなプラットフォームでタスクを実行できます。

このモデルはニース・ソフィア・アンティポリス大学の教授であるデニス・カロメルによって作成されました。^[1] その後、INRIAのOASISチームのメンバーによってモデルの拡張がいくつか行われました。^[2] 『分散オブジェクトの理論』 という本では、ProActive機能を形式化するASP計算が紹介されており、ProActiveプログラム実行の特性とともに、計算に形式的な意味論が提供されています。 ^[3]

アクティブ オブジェクトは、ProActive を使用して並行アプリケーションを構築するために使用されるアクティビティと分散の基本単位です。アクティブ オブジェクトは独自のスレッドで実行されます。このスレッドは、他のアクティブ オブジェクトによってこのアクティブ オブジェクトで呼び出されたメソッドと、このアクティブ オブジェクトに属するサブシステムのパッシブ オブジェクトのメソッドのみを実行します。ProActive では、標準の Java とは異なり、プログラマーはスレッド オブジェクトを明示的に操作する必要がありません。

アクティブ オブジェクトは、計算に関係するどのホストでも作成できます。アクティブ オブジェクトが作成されると、そのアクティビティ (独自のスレッドで実行されること) と場所 (ローカルまたはリモート) は完全に透過的になります。アクティブ オブジェクトはどれも、同じクラスのパッシブ インスタンスであるかのように操作できます。

アクティブオブジェクトは、本体と標準 Java オブジェクトの 2 つのオブジェクトで構成されます。本体は、アクティブ オブジェクトの外部からは見えません。

本体は、アクティブ オブジェクトに対する呼び出し (または要求) を受信し、それらを保留中の呼び出しのキューに格納する役割を担います。これらの呼び出しは、同期ポリシーで指定された順序で実行されます。同期ポリシーが指定されていない場合、呼び出しは「先入れ先出し(FIFO)」方式で管理されます。

アクティブ オブジェクトのスレッドは、保留中の要求のキュー内のメソッドを選択し、それを実行します。アクティブ オブジェクト内では並列処理は提供されません。これは ProActive の設計における重要な決定であり、「事前事後」条件とクラス不変条件の使用を可能にします。

アクティブ オブジェクトへの呼び出しを送信するサブシステム側では、アクティブ オブジェクトはプロキシによって表されます。プロキシは、将来の値を表すための将来のオブジェクトを生成し、呼び出しを Request オブジェクト (メタオブジェクトの観点からは、これは具体化) に変換し、パラメーターとして渡されたパッシブ オブジェクトのディープ コピーを実行します。

ProActive は、 Eiffel プログラミング言語の並列拡張である Eiffel// によって導入されたモデルでアプリケーションを開発するために設計されたライブラリです。

このモデルでは、アプリケーションはサブシステムに構造化されます。サブシステムごとに 1 つのアクティブ オブジェクト (したがって 1 つのスレッド) があり、アクティブ オブジェクト (またはスレッド) ごとに 1 つのサブシステムがあります。したがって、各サブシステムは 1 つのアクティブ オブジェクトと任意の数のパッシブ オブジェクトで構成されます (パッシブ オブジェクトが存在しない場合もあります)。1 つのサブシステムのスレッドは、このサブシステムのオブジェクトのメソッドのみを実行します。サブシステム間には「共有パッシブ オブジェクト」はありません。

これらの機能はアプリケーションのトポロジに影響します。サブシステムを構成するすべてのオブジェクト (アクティブ オブジェクトとパッシブ オブジェクト) のうち、サブシステム外部のオブジェクトに認識されるのはアクティブ オブジェクトのみです。アクティブとパッシブの両方のオブジェクトはすべて、アクティブ オブジェクトへの参照を持つことができます。オブジェクトo1にパッシブ オブジェクトo2への参照がある場合、o1とo2は同じサブシステムの一部です。

これは、サブシステム間のメッセージ パッシングのセマンティクスにも影響を及ぼします。サブシステム内のオブジェクトがアクティブ オブジェクトのメソッドを呼び出す場合、呼び出しのパラメーターはサブシステムのパッシブ オブジェクトへの参照である可能性があり、共有パッシブ オブジェクトにつながります。アクティブ オブジェクトの呼び出しのパラメーターとして渡されるパッシブ オブジェクトが常にディープ コピーによって渡されるのは、このためです。一方、アクティブ オブジェクトは常に参照によって渡されます。対称的に、これはアクティブ オブジェクトで呼び出されたメソッドから返されるオブジェクトにも当てはまります。

非同期呼び出し、futures、データ共有なしの概念のおかげで、ProActive で作成されたアプリケーションは、シーケンシャル環境、マルチスレッド環境、分散環境のいずれで実行する場合であっても、構造的な変更は一切必要ありません (実際、ほとんど変更は必要ありません) 。

可能な場合は常に、アクティブ オブジェクトに対するメソッド呼び出しは非同期要求として具体化されます。不可能な場合は、呼び出しは同期され、応答を受信するまでブロックされます。要求が非同期の場合は、直ちにfuture オブジェクトが返されます。

未来オブジェクトは、まだ実行されていないメソッド呼び出しの結果のプレースホルダーとして機能します。その結果、呼び出しスレッドは、返されたオブジェクトでメソッドを呼び出す必要がない限り、コードの実行を続行できます。必要が生じた場合、メソッド呼び出しの結果がまだ利用できない場合は、呼び出しスレッドが自動的にブロックされます。未来オブジェクトの構造はアクティブ オブジェクトに似ていますが、未来オブジェクトはアクティブではありません。スタブとプロキシのみがあります。

以下のコードの抜粋は、将来のオブジェクトの概念を強調しています。ユーザーがアクティブ オブジェクトからメソッドfooとメソッドを呼び出すとします。メソッドは void を返し、メソッドはクラスのオブジェクトを返します。 barafoobarV

// (リモート) AO a への一方向の型付き非同期通信
// リクエストが a に送信されます
a . foo ( param ); 

// 結果を伴う型付き非同期通信。// 
v はまず待機中の Future であり、
リクエストの処理後に透過的に入力され、応答します。
V v = a . bar ( param ); ... // 非同期呼び出しの結果の使用。// v がまだ待機中の Future である場合、自動的に待機がトリガーされます。必要に応じて待機します。v . gee ( param );    




 

fooがアクティブ オブジェクトで呼び出されるとa、すぐに戻ります (現在のスレッドは他のサブシステムのメソッドを実行できないため)。同様に、barが で呼び出されるとa、すぐに戻りますが、結果はvまだ計算できません。メソッド呼び出しの結果のプレースホルダーである future オブジェクトが返されます。呼び出し元サブシステムの観点からは、future オブジェクトと、同じ呼び出しがパッシブ オブジェクトに対して発行された場合に返されるオブジェクトとの間に違いはありません。

両方のメソッドが返された後、呼び出しスレッドは、呼び出しが実際に実行されたかのようにコードの実行を続けます。future メカニズムの役割は、メソッドgeeが呼び出されv、結果がまだ設定されていない場合に、呼び出しスレッドをブロックすることです。このオブジェクト間の同期ポリシーは、wait-by-necessityと呼ばれます。

• ジョブスケジューラソフトウェアの一覧

• Ranaldo, N.; Tretola, G.; Zimeo, E. (2008 年 4 月 14 ～ 18 日)。「XPDL ベースのワークフロー エンジンによる ProActive アクティビティのスケジュール設定」。2008 IEEE国際並列分散処理シンポジウム。マイアミ: IEEE。pp. 1 ～ 8。doi :10.1109/ IPDPS.2008.4536336。ISBN 978-1-4244-1693-6. ISSN  1530-2075. S2CID  10082749. {{cite book}}:|journal=無視されました (ヘルプ)
• Sun, Hailong; Zhu, Yanmin; Hu, Chunming; Huai, Jinpeng; Liu, Yunhao; Li, Jianxin (2005)。「CROWN Grid における信頼性を備えたリモートおよびホット サービス展開の初期経験」。Cao, Jiannong、Nejdl, Wolfgang、Xu, Ming (編)。高度な並列処理テクノロジ。コンピュータ サイエンスの講義ノート。第 3756 巻。ベルリン: Springer。pp. 301–312。doi :10.1007/ 11573937_33。ISBN 978-3-540-29639-3。
• Quéma, Vivien; Balter, Roland; Bellissard, Luc; Féliot, David; Freyssinet, André; Lacourte, Serge (2004)。「コンポーネント ベース アプリケーションの非同期、階層的、スケーラブルな展開」。Emmerich, Wolfgang、Wolf, Alexander L. (編)。コンポーネント展開。Lecture Notes in Computer Science。第 3083 巻。ベルリン: Springer。pp. 50–64。doi : 10.1007 / 978-3-540-24848-4_4。ISBN 978-3-540-22059-6。
• ProActive-CLIF-Fractal が 2012 OW2 賞を受賞
• グリッドのパワーを解き放つソフトウェア (ICT Results)
• ActiveEon と MetaQuant による Cloud ProActive の専門性の強化(フランス語)

• 公式サイト
• グリッドコンポーネントモデル仕様