私はむしろそのような種類のものにBPMツールを使用したいのですが、長期にわたるオーケストレーションをサポートすることを明確に意図しています。正しく説明することはできませんが、BPMサーバーについてを確認することをお勧めします。以下にいくつかの部分を引用していますが、論文全体を読む価値があります。
オーケストレーションの状態の管理
オーケストレーションとそれが使用するビジネスサービスの最大の違いの1つは、それぞれの実行にかかる時間です。一般的なサービスへのリクエストは、数秒以内に応答を生成します。ただし、通常はビジネスプロセスのすべてまたは一部を駆動するため、オーケストレーションは、プロセスの完了にかかる時間に応じて、数時間、数日、または数週間実行される場合があります。たとえば、プロセスのある時点で人間の承認が必要であり、承認を与えなければならない人が休暇中の場合はどうなりますか？ビジネスプロセスは完了するまでに長い時間がかかる可能性があるため、それらを制御するオーケストレーションも長時間実行される可能性があります。
この長期実行の性質は、オーケストレーションが実行中のプロセスについて維持するメモリ内情報（状態）を管理する方法に影響を与えます。オーケストレーションがかなりの期間ブロックされている場合、この状態をメモリに保持することはあまり意味がありません。代わりに、BPMサーバーは、オーケストレーションの状態を自動的にディスクに書き込み、数日または数週間後であっても、ビジネスプロセスが再開したときに再度復元する方法を提供する必要があります。
状態管理は、BPMサーバーとアプリケーションサーバーのもう1つの注目すべき違いを示しています。長時間実行されるビジネスプロセスをサポートすることが主な目的ではないため、アプリケーションサーバーは従来この種の状態管理に対応していませんでした。ただし、これらは長期実行のオーケストレーションをサポートすることを明示的に意図しているため、BPMサーバーはこのサービスを提供します。
トランザクションの処理
多くのビジネスプロセスでは、トランザクションによって特徴付けられるオールオアナッシングの動作が必要です。たとえば、ビジネスプロセスを推進するオーケストレーションでは、2つのビジネスサービスを呼び出して、両方の要求が成功するか、両方が失敗するかを確認する必要があります。この種のアトミックトランザクションは、標準の2フェーズコミットプロトコルを使用して実行できます。これは、BPMサーバーが通常サポートするものです。実際、アプリケーションサーバーにはこの機能が含まれているため、アプリケーションサーバー上に構築されたBPMサーバーはこれを非常に簡単に提供できます。
ただし、多くのビジネスプロセスの性質により、別の問題が発生します。特定のプロセスでオールオアナッシングの動作が必要であるが、従来のアトミックトランザクションが不可能な場合はどうなりますか？アトミックトランザクションでは、トランザクションの存続期間中、データをロックする必要があります。これは、トランザクションが短い場合でも問題にはなりません。ただし、オールオアナッシンググループにバンドルする必要のあるサービスに、人間の承認が必要なサービスが含まれているとします。必要な承認者が休暇中でなくても、人が応答するのにかかる時間は、データがロックされたままになるには長すぎる可能性があります。または、このトランザクショングループに含まれている必要がある1つのサービスが、アトミックトランザクションに参加しない場合はどうなりますか？多くのアプリケーションは任意のクライアントにデータをロックさせないため、これは大した心配ではありません。
このような状況を処理するために、BPMサーバーは長時間実行されるトランザクションをサポートします。ビジネスアクティビティやその他の名前とも呼ばれる長時間実行トランザクションは、すべての更新をロールバックするのではなく、エラーが発生したときに何らかの補正ロジックを実行することによってエラーを処理します。たとえば、特定の長期実行トランザクションに、ある銀行から別の銀行に送金するアトミックトランザクションが含まれ、その後、送金が成功すると別のアプリケーションを実行する操作が続くとします。この最後の操作が失敗した場合、ビジネスプロセスのロジックでは、送金を元に戻す必要があります。しかし、この転送を実行したアトミックトランザクションはすでにコミットされています。どうすれば元に戻すことができますか？答えは、障害が発生した場合に補償ロジックを実行する必要があるということです。転送の効果を元に戻すために別のアトミックトランザクションを実行する可能性のあるロジック。BPMサーバーは、オーケストレーションの作成者がこの補正アクションを定義し、長時間実行されるトランザクションが失敗したときに自動的に実行できるようにする組み込み機能を提供します。
補償はアトミックトランザクションが不可能な場合に役立ちますが、問題がないわけではありません。たとえば、オーケストレーションが長時間実行されるトランザクションの初期の部分で一部のデータを変更し、後でこのデータを元の状態に戻すために補正操作を実行するとします。これらの2つのイベントの間に、他のアプリケーションがそのデータにアクセスするとどうなりますか？この2番目のアプリケーションは、信用リスクの計算など、ビジネス上の意思決定を行う際に最終的に正しくないと見なされるデータを使用する可能性があります。または、明らかな補償がない操作について考えてみてください。オーケストレーションによってミサイルが発射された場合、そのオーケストレーションのコードを補正してこれを元に戻す方法はありません。補償は完璧な解決策ではありませんが、