JMSは何に適していますか？
JMSが優れたソリューションである問題の（簡単な）例と、JMSがこれらのケースで優れたソリューションである理由を探しています。過去に、メッセージをすぐにBで処理できるとは限らないときに、AからBにメッセージを渡す手段としてデータベースを使用しました。
このようなシステムの架空の例は、新規に登録されたすべてのユーザーに、登録から24時間以内にウェルカムメールを送信することです。引数のために、各ユーザーが登録された時刻をDBが記録せず、代わりに各新しいユーザーへの参照（外部キー）がpending_emailテーブルに保存されると仮定します。電子メール送信者ジョブは24時間に1回実行され、このテーブルのすべてのユーザーに電子メールを送信してから、すべてのpending_emailレコードを削除します。
これは、JMSを使用すべき問題のように思えますが、私が説明したアプローチに対してJMSがどのようなメリットをもたらすかは明確ではありません。 DBアプローチの利点の1つは、メッセージが永続的であることです。 JMSメッセージキューも永続化できることを理解していますが、その場合、JMSと、説明した「メッセージキューとしてのデータベース」アプローチとの違いはほとんどないようです。
私は何が欠けていますか？ - ドン
JMSとメッセージングは、実際には2つのまったく異なるものです。
- パブリッシュおよびサブスクライブ（興味のある消費者にメッセージを送信する-メーリングリストにメールを送信するのと同じように、送信者は誰がサブスクライブされているかを知る必要がありません
- 高性能で信頼性の高い負荷分散（メッセージキュー）
キューがトピックと比較する方法についての詳細を参照してください
話しているケースは2番目のケースです。データベーステーブルを使用して、メッセージキューを少しシミュレートできます。
主な違いは、JMSメッセージキューは、巨大なスループット用に設計された高性能で高度な同時ロードバランサであるということです。通常、1秒あたり数万のメッセージを多くのプロセスとスレッドの多くの同時消費者に送信できます。この理由は、メッセージキューは基本的に非常に非同期であるためです- 優れたJMSプロバイダーは、事前に各コンシューマーにメッセージをストリーミングするため 、数千RAMで消費者が利用可能になるとすぐに処理できるメッセージの数。これは、大量のスループットと非常に低いレイテンシーにつながります。
例えばデータベーステーブルを使用してウェブロードバランサーを書くことを想像してください:)
データベーステーブルを使用する場合、通常、1つのスレッドがテーブル全体をロックする傾向があるため、高性能のロードバランサーを実装しようとすると、スループットが非常に低くなる傾向があります。
しかし、ほとんどのミドルウェアと同様に、それはすべて必要なものに依存します。 1秒あたり数メッセージのみの低スループットシステムを使用している場合は、データベーステーブルをキューとして自由に使用してください。ただし、低レイテンシと高スループットが必要な場合は、JMSキューを強くお勧めします。
私の意見では、JMSおよびその他のメッセージベースのシステムは、以下を必要とする問題を解決するためのものです。
- 非同期通信：アプリケーションは、応答を待つ必要なく、イベントが発生したことを別のアプリケーションに通知する必要があります。
- 信頼性。一度だけのメッセージ配信を確認してください。 DBのアプローチでは、特にメッセージを読むクライアントが複数いる場合、「車輪を再発明」する必要があります。
- 疎結合。すべてのシステムがデータベースを使用して通信できるわけではありません。したがって、JMSは、システムの境界を越えて通信できる分離システムを備えた異種環境で使用するのに適しています。
JMS実装は「プッシュ」です。つまり、キューをポーリングして新しいメッセージを検出する必要はありませんが、新しいメッセージが到着するとすぐに呼び出されるコールバックを登録します。
JMSの利点の1つは、データベースソリューションでも実行できる非同期処理を有効にすることです。ただし、データベースソリューションに対するJMSのその他の利点は次のとおりです。
a）メッセージの消費者は遠隔地にいることができます。リモートアクセス用のデータベースの公開は危険です。これを回避するには、データベースからメッセージを読み取るための追加サービスを提供しますが、これにはより多くの労力が必要です。
b）データベースの場合、メッセージコンシューマは、JMSがメッセージの到着時にコールバックを提供する（skが言及されているように）メッセージをデータベースでポーリングする必要があります。
c）負荷分散-大量のメッセージが着信する場合、JMSにメッセージプロセッサのプールを簡単に作成できます。
d）一般に、JMSを介した実装は、データベースルートよりも簡単で、労力も少なくなります。
元のコメントに対処するため。元々説明されていたのは、（ポイントツーポイント）JMSの要点です。ただし、JMSの利点は次のとおりです。
自分でコードを記述する必要はありません（そして、考えているほど永続的ではないようにロジックを台無しにする可能性があります）。また、サードパーティの実装は、単純なデータベースアプローチよりも拡張性が高い場合があります。
jmsはパブリッシュ/サブスクライブを処理します。これは、指定したポイントツーポイントの例よりも少し複雑です
あなたは特定の実装に縛られておらず、将来あなたのニーズが変わった場合、あなたのJavaコードをいじってw/out.
JMSは、2つ以上のクライアント間でメッセージを転送するために使用されるAPIです。仕様はJSR 914で定義されています。
JMSの主な利点は、通信エンティティの分離された性質です。送信者は受信者に関する情報を持っている必要はありません。他の利点には、異種プラットフォームの統合、システムのボトルネックの削減、スケーラビリティの向上、および変更への迅速な対応が含まれます。
JMSはインターフェイス/ APIの一種であり、具体的なクラスを実装する必要があります。これらは、さまざまな組織/プロバイダーによって既に実装されています。それらはJMSプロバイダーと呼ばれます。例は WebSphere by IBMまたは FioranoMQ by Fiorano SoftwaresまたはActiveMQ by Apache、HornetQ、OpenMQなどです。使用される他の用語はAdmin Objects（Topics、Queues、ConnectionFactories）、JMSです。プロデューサー/パブリッシャー、JMSクライアント、およびメッセージ自体。
あなたの質問に来て-what is JMS good for?その重要性を説明するための実用的な例を挙げたいと思います。
デイトレード
[〜＃〜] lvc [〜＃〜] （Last value cache）と呼ばれるこの機能があります
取引では、株価は出版社によって定期的に公開されます。各共有には、公開先のトピックが関連付けられています。トピックが何であるかを知っている場合、メッセージはキューのように保存されないことを知っておく必要があります。メッセージは、メッセージが発行された時点で生きているサブスクライバーに発行されます（作成された時点から発行されたすべてのメッセージを取得するDurablesサブスクライバーである例外は、再び古い株価を取得したくないため、それを使用して）。そのため、クライアントが株価を知りたい場合は、サブスクライバーを作成し、次の株価が公開されるまで待つ必要があります（これは、私たちが望むものではありません）。 LVCが登場するのはここです。各LVCメッセージには、関連付けられたキーがあります。 （特定の株式の）LVCキーでメッセージが送信され、同じキーで別の更新メッセージが送信された場合、後のメッセージが前のメッセージをオーバーライドします。サブスクライバーが（LVCが有効になっている）トピックにサブスクライブするたびに、サブスクライバーは個別のLVCキーを持つすべてのメッセージを取得します。上場企業ごとに個別のキーを保持する場合、クライアントがサブスクライブすると、最新の株価と最終的にすべての更新が取得されます。
もちろん、これは、JMSを非常に強力にする信頼性、セキュリティなどの他の要因の1つです。
ここにいくつかの例が記載された素敵な記事があります： http://www.winslam.com/laramee/jms/index.html
Guidoには完全な定義があります。私の経験から、これらのすべてが適切にフィットするために重要です。
私が見た用途の1つは、倉庫での注文配送です。大規模なオフィスに事務用品を供給するかなりの数の倉庫を持つオフィス用品会社を想像してください。これらの注文は中央の場所に届き、正しい倉庫に配送するためにまとめられます。ほとんどの場合、倉庫には高速接続がないため、ダイヤルアップモデムを介して注文がプッシュダウンされます。これは、非同期が入る場所です。これは信頼性が重要な場所です。
主な利点は、関連のないシステムをcomonデータベースで共有したり、データをやり取りするカスタムサービスを構築したりするのではなく、分離することです。
銀行は、日中のメッセージングを使用して、ライブデータの変更が発生したときにそれをやり取りするという好例です。ソースシステムが「壁を越えて」メッセージを投げるのは非常に簡単です。欠点は、これらのシステム間の契約の方法がほとんどないことであり、通常、入院が消費者側で実施されているのがわかります。ほとんど疎結合です。
その他の利点は、多くのアプリケーションサーバーなどですぐに使用できるJMSのサポートと、その周辺のすべてのツール（耐久性、監視、レポート、調整）にあります。
JMSは、JTA（Java Transaction API）およびJPA（Java永続性API）と組み合わせて非常に便利です。簡単な注釈を使用すると、複数のデータベースアクションとメッセージの送受信を同じトランザクションに配置できます。そのため、それらの1つが失敗すると、同じトランザクションメカニズムを使用してすべてがロールバックされます。
「メッセージキューとしてのデータベース」ソリューションは、タスクにとって重いかもしれません。 JMS送信者は、メッセージ送信者が受信者について何も知る必要がないという点で、あまり密接に結合されていません。これは、「データベースとしてのメッセージキュー」の追加の抽象化でも実現できるため、大きなメリットはありません...また、キューを「パブリッシュアンドサブスクライブ」方式で使用することもできます。あなたは達成しようとしています。また、コンポーネントをさらに分離する良い方法でもあります。すべての通信が1つのシステム内にある場合、および/またはアプリケーションですぐに利用できるログを保持することが非常に重要な場合、方法は適切と思われます。別々のシステム間で通信する場合は、JMSが適しています。