2

私の環境では、長時間実行されるタスクをスケジュールする必要があります。現在実行中のタスクのリストをクライアントに表示し、新しいタスクをスケジュールできるアプリケーションAがあります。実際のハードワークを行うアプリケーションBもあります。

そのため、アプリAはアプリBでタスクをスケジュールする必要があります。共通しているのはデータベースだけです。最も簡単な方法は、タスクのリストを含むテーブルを追加し、アプリBにそのテーブルをときどきクエリして、新しくスケジュールされたタスクを実行させることです。

それでも、それはそれを行う適切な方法ではないようです。一見すると、エンタープライズ環境でのジョブのツールはメッセージキューのように見えます。アプリAはタスクの説明を含むメッセージをキューに送信し、アプリBはキューからメッセージを読み取ってタスクを実行します。このような場合、アプリBが完了したタスクのステータスを書き込む上記のようなテーブルを作成せずに、アプリAがスケジュールされたすべてのタスクのステータス（永続キュー？）を取得することは可能ですか？また、アプリAには複数のインスタンスが存在する可能性があり、それぞれがすべてのインスタンスのすべてのタスクについて知っている必要があることにも注意してください。

「テーブルアプローチ」の欠点は、DBポーリングが必要なことです。

「メッセージキューアプローチ」の欠点は、インフラストラクチャに新しい通信チャネルを導入していることです（失敗する可能性のあるもう1つのこと）。

どう思いますか？他のアイデアはありますか？アドバイスをよろしくお願いします:)

==========更新==========

最終的に、私は次のアプローチを決定しました。この問題には2つの側面があります。1つはAとBの間の通信です。もう1つは、タスクに関する情報を取得することです。

通信の場合、ジョブに適したツールはJMSです。データを取得するための適切なツールはデータベースです。そのため、アプリAにタスクを説明する「tasks」テーブルに新しい行を追加させます（後でこのテーブルをクエリして、すべてのタスクのリストを取得できます）。次に、AはJMSを介してBにメッセージを送信し、「やるべきことがあります」とだけ伝えます。Bは作業を行い、テーブルのタスクステータスを更新します。

すべての回答ありがとうございます！

4

4 に答える 4

2

現在の展開環境と将来の変更の可能性の両方について考える必要があります。

2つの問題を効果的に検討しています。どちらも、取得できるインフラストラクチャの量に応じていくつかの方法で解決でき、導入する意思もありますが、問題に合わせて設計を「適切なサイズ」にすることも重要です。

データベースとメッセージングの両方の使用について考えるのは正しいですが、これらの項目がドメインにとってやり過ぎであるかどうかを検討する必要があり、ドメインを知っているあなたと他の人だけが本当にそれに答えることができます。

私のアドバイスは、あなたの地域ですでに使用されているものを調べることです。組み込むことができるデータベースインフラストラクチャがすでにある場合は、タスクアクティビティを監視し、データベースでジョブをスケジュールすることは悪い考えではありません。ただし、独自のデータベースを実行し、新しいハードウェアを入手し、十分なサポートリソースがない場合は、データベースの導入は賢明な選択肢ではない可能性があり、より単純ですが、より脆弱なアプローチを検討することができます。プロセスは、ファイルを書き込んでジョブをスケジュールし、タスクを報告します。

同時に、DBまたはJMSの導入を本質的にエラーが発生しやすいと見なさないでください。正しく実装されたこれらは、システムをスケーラブルで管理しやすくする安定した実績のあるテクノロジーです。

@kanが言うように、Webサービスインターフェイスを公開することも便利なオプションです。

于 2013-01-24T09:51:05.563 に答える
1

もう1つのオプションは、Bをサービスとして作成することです。たとえば、制御インターフェイスとステータスインターフェイスをRESTまたはSOAPインターフェイスとして公開します。この場合、AはBのクライアントアプリケーションと同じようになります。Bはその状態をデータベースに保存します。Aは、Bと通信するだけのステートレスアプリケーションです。

ところで、Spring Remoteを使用すると、インターフェイスを公開し、JMS、REST、SOAP、またはRMIのいずれかをトランスポート層として使用できます。これらは必要に応じて後で変更できます。

于 2013-01-24T09:40:53.600 に答える
1

エンタープライズアーキテクチャにメッセージ（JMS）があります。これらを使用すると、Glassfishな​​どのJavaEEコンテナで利用できます。メッセージをシリアル化して、キューにある間にサーバーが再起動した場合でも確実に配信されるようにすることができます。そして、これらすべてがどのように実装されているかを気にする必要さえありません。

于 2013-01-24T09:37:48.373 に答える
0

ここにはいくつかのアプローチがあります。まず、@ kanが提案したように、アプリBにインタラクション用のWebサービスを公開させます。これにより、異種のクライアントがアプリBと通信できるようになります。良いアプローチのようです。アプリBは、適切と思われる永続ストアを内部的に使用できます。

または、アプリBにJMXを介して管理インターフェースを公開させ、アプリAなどのアプリケーションにこの管理インターフェースを介してアプリBと通信させることもできます。タスクの送信の実装や統計の取得などが簡単になります。さらに、JMX通知を利用して、タスクの送信や成果などをリアルタイムで更新することもできます。これの欠点は、これがJava固有のソリューションであるため、異種クライアントのサポートが遠い夢になることです。

于 2013-01-24T10:23:03.553 に答える