ファットクライアントアプリケーションを分散ワークフローとして再度

Question

私の会社は現在、ワークフロー処理が組み込まれたWindowsベースのファットクライアントアプリケーションを使用してクライアントにサービスを提供しています。基本的に、顧客は一連の文書をワークフローの先頭に挿入し、文書は多数のワークフローステップで処理され、一定期間後に出力が顧客に提示されます。現在、他のマシンにアプリケーションをインストールし、マシンのクラスターを異なる文書サブセットで動作させることで、大規模な顧客のためにスケールアップしています。理想的ではありませんが、アプリケーションの変更を最小限に抑えれば、現在のレベルまで簡単にスケールアップすることができました。

私たちが直面している問題は、お客様が大規模なドキュメントセットを提供しているため、マシンやITサポートなどに期待以上に費やしていることです。それを拡張可能にするプラットフォームです。私たちのソリューションの特徴は、各ドキュメントを互いに独立して処理できることです。また、10のワークフローステップがあり、そのうちの2つのステップが処理時間の約90％を占めます。

私たちが検討している考え方の1つは、ドキュメントスキーマにワークフローステップフィールドを追加して、ドキュメントに対して完了したワークフローステップを追跡することです。次に、単一のドキュメントセット上で動作するようにマシンのクラスタ全体をスローすることができます。単一のマシンは、すべてのワークフロー・ステップを介して文書を逐次的に処理するのではなく、次の文書/ワークフロー・ステップのペアについてdbに照会し、その処理を実行します。これは合理的なアプローチのように聞こえますか？助言がありますか？

ありがとうございます。

Answer 1

どのような開発環境で作業しているか分かりませんが、さまざまな種類のソースドキュメントやさまざまな手順など、さまざまなパフォーマンス特性を持つ類似のワークフローを扱わなければなりませんでした。

ステップAの作業成果物がステップBの入力であり、ステップBの製品がステップCの入力であるとすると、私は潜在的な解決策としてメッセージキューイングを検討します。

たとえば、すべての新しいドキュメントがキューに入れられます。 1つまたは複数のリスナーアプリケーションがキューにヒットし、次に使用可能なドキュメントを取得してステップAを実行します。ステップAが完了すると、出力製品および/または関連データへのリンクが別のキューにスローされます。別のリスナーアプリは、最終出力プロダクトが作成されるまで、この第2のキューからステップBなどにプルする。

このように、ディスクリートステップ間の保持領域に1つのキューを使用し、キュー間の個々のプロセスを拡大または縮小することができます。

たとえば、これを使用して、いくつかのデータ変換、レンダリングプロセス、およびスプーラへの移行が行われます。データは高速で、レンダリングはCPUバウンドで、印刷はI/Oバウンドですが、個々のステップは必要に応じてスケールアウトできます。

これはDBを（技術的に）使用することができますが、メッセージキューやサービスバスが役立つでしょう。

うまくいけば、それは正しい方向にあなたを指し示すでしょう！