私は (純粋な Java サーブレットを使用した) WEB アプリケーションを使用しており、非同期モードで実行できる、データベースへのアクセスを伴う重い計算作業を行っています。このようなバッチ ジョブを実行するために専用サーバーを使用する予定ですが、WEB サーバーのサーブレットと新しい専用サーバーのバッチ ジョブ間の通信に使用するツール/手法/プロトコルを考えています。私はJMSを見ています。それは正しい選択ですか?業界標準の技術や広く採用されている技術はありますか? 複数の同時ジョブのキューと優先度の処理も必要です。
5 に答える
JMS はかなり標準的なソリューションです。ハイエンド プラットフォーム (Sun の JCAPS など) では、JMS を多用して Web サービスのワークロードを分割および管理します。
Sun (または IBM または Microsoft) からハイエンドの JMS 実装を購入することには、多くの利点があります。まず、ファイル システムにバックアップされる信頼性の高いメッセージ キューなどを取得します。メッセージが失われることはありません。次に、いくつかの監視および管理ツールを取得します。
優れた点の 1 つは、(潜在的に) 複数のサブスクライバーを持つ JMS キューを用意して、ワークロードのバランスを取ることです。
もう 1 つの優れた点は、ログ プロセスと実際の作業プロセスをサブスクライブする JMS トピックを用意することです。ロギング プロセスはメッセージを取り出し、ジョブの開始および停止の重要な段階を単純に記録します。
メッセージングは最良のオプションの1つです。
メッセージングフレームワークを非常に汎用的にして、あらゆるタイプのバッチジョブを処理できるようにします。
1つのアプローチは、イベントをキューに入れ、キューコンシューマーがイベントを処理し、それを一連のタスクに変換するイベント/タスクマネージャーを用意することです。その後、タスクは個別のタスクハンドラーによって実行できます。タスクは、フィードバックループを提供するために再びキューに入れることができる、さらにいくつかのイベントを生成することもできます。このようにして、ワークフローのような機能をフレームワークに追加し、バッチジョブが相互に依存できるようにすることができます。
JMS は、サーブレットからバッチ ジョブを送信するための適切なソリューションです。ただし、バッチ サーバーがサーブレットと通信するのは、メッセージのリスナーになれないため、最適なソリューションではない可能性があります。
バッチ サーバーからサーブレットへの通信が何を必要とするかはわからないので、使用できるオプションがおそらくいくつかあるとしか言えません (はい、JMS はその 1 つです)。しかし、それらはすべて基本的にサーブレットへのポーリング呼び出しに依存しており、サーブレットは何らかの方法でチェックして、バッチ サーバーから待機中のものがあるかどうかを確認します。これは、単にバッチ サーバー上のサーブレットであるか、JMS 応答キューへの受信呼び出しを行っている可能性があります。他のソリューションも利用できますが、ポイントは、AJAX などを介してバッチ サーバーからクライアント エンド (私が推測しているブラウザー) にプッシュする機能がない限り、非同期ではないということです。
とにかく、心に留めておくべきことがあります。
非同期処理のもう 1 つの方法は、Web アプリケーションで要求をデータベースに保存し、バッチ プロセスでデータベースをポーリングして新しいバッチ ジョブを処理することです。あなたのアプリケーションはより小さく (純粋な Java サーブレット) 見えるので、これはよりシンプルで低コストのソリューションかもしれません。
それが役に立てば幸い。
JMS を Web サービスで使用します。
- クライアントは Web サービス経由で計算を要求します
- サーバーは JMS メッセージを書き込み、ステータス (最初は「保留中」) とともにデータベースに格納される ID 値を作成します。サーバーは ID をクライアントに返します。
- サーバー (別のサーバーの場合もある) は JMS メッセージを読み取り、計算を行い、完了するとデータベースのステータスを「完了」に更新します。
- 計算が進行している間、クライアントはサーバーをポーリングして、別の Web サービスを (ID と共に) 使用してステータスを判断します。サーバーは、データベースから取得したステータスを返します。サーバーの計算が完了すると、クライアントには「完了」ステータスが表示され、計算が完了したことがわかります。