すべてのサーバーは、同じデータベースと共通のファイル共有を使用します。ファイル共有は、ログとその他のいくつかのディレクトリー (具体的には、logs、var/email、var/plugins、および var/repository) で使用されます。また、ポートやホストなどの一部の構成情報のように各サーバーが個別に維持するものもあります。データベースは、構成情報、ランタイム・データなどに使用されます。
サーバーはデータベースを共有しているので、すべてのサーバーは同じ間隔で実行されます。
データベースと JMS の接続情報など、一部の構成プロパティーはサーバー上に残ります。データベース構成は製品のインストール中に処理されます。インストール後に追加構成は不要です。
ワークフローはアクティビティーで構成されます。アクティビティーは、1 つずつ順番に実行することも、相互に並行して実行することもできます。さらに、その 2 つを組み合わせて実行することもできます。典型的なワークフローは、以下に示すような複数の順次アクティビティーで構成されます。
JMS ベースの通信では、以下に示すような数とおりの方法でエージェントを構成できます。
すべてのサーバーは、常にポーリングによって処理待ちのワークフローがあるかどうかを問い合わせます。したがって、どのサーバーでもワークフローを開始する可能性があります。このワークフローを獲得するサーバーは、以下のタスクを実行します。
処理を完了すると、エージェントは、JMS を介して応答メッセージを送信します。メッセージは、いずれかのサーバーによってデータベースに書き込まれ、次のアクティビティーがいずれかのサーバーによって開始されます。アクティビティー B を開始したサーバーは、上で説明したのと同じステップを実行します。
ここで概略を説明している単純なワークフローでは、複数のアクティビティーをすべて同じサーバーが処理することもあれば、それぞれ異なるサーバーが処理することもあります。さらに、その両方が組み合わされることもあります。もちろん、このワークフローが 3 つの並行アクティビティーで構成されている場合でも、同じことが言えます。
1 つのアプリケーション・ワークフローは、データベースの単一のレコードによって維持されます (1 つのワークフローを同時に処理するスレッドは 1 つのみです)。
アプリケーションの処理中には、コマンドが失敗すると、ワークフローにマークが付けられます。エラー処理は、アプリケーションの作成者の責任です。コンポーネントのロールバックは、ロールバック・コマンド/ステップで処理できます。ここで使用しているロールバックという言葉は、コンポーネントの前のバージョンを再インストールすることを意味しています。
エージェントがコマンドを実行している最中にサーバーが異常終了すると、JMS メッシュはそのワークフローを別のサーバーに割り当てます。
コマンドの実行中にエージェントが異常終了したり消滅したりした場合、(ステップの失敗がエージェント自体の失敗原因にはならないため) サーバーはコマンドがまだ実行中であると見なし、自動タイムアウトにはなりません。 通常、タイムアウト間隔を割り当てることは適切ではなく、現実的でもありません。