回答:
JMS（ActiveMQはJMSブローカーの実装です）は、非同期要求処理を可能にするメカニズムとして使用できます。これは、リクエストの完了に時間がかかるため、または複数の関係者が実際のリクエストに関心を持っている可能性があるためです。これを使用するもう1つの理由は、複数のクライアント（異なる言語で書かれている可能性がある）がJMS経由で情報にアクセスできるようにするためです。STOMPプロトコルを使用してC＃/ Java / Rubyクライアントからのアクセスを許可できるため、ActiveMQはここでの良い例です。
実際の例は、特定の顧客の注文に使用されるWebアプリケーションの例です。その注文を行う（およびそれをデータベースに保存する）一環として、いくつかの追加タスクを実行することができます。
これを行うには、アプリケーションコードで、注文IDを含むJMSキューにメッセージを発行します。キューをリッスンするアプリケーションの一部は、orderIdを取得し、データベースで注文を検索して、別のサードパーティシステムにその注文を出すことにより、イベントに応答する場合があります。アプリケーションの別の部分が、orderIdを取得し、確認メールを顧客に送信する場合があります。
これらを常に使用して、実行時間の長い操作を非同期で処理します。Webユーザーは、リクエストが処理されるのを5秒以上待ちたくないでしょう。それよりも長く実行するものがある場合、1つの設計は、要求をキューに送信し、ユーザーがジョブの終了を確認できるURLをすぐに送信することです。
パブリッシュ/サブスクライブは、送信者を多くの受信者から切り離すためのもう1つの優れた手法です。サブスクライバーは必要に応じて行き来できるため、これは柔軟なアーキテクチャーです。
JMSには驚くほど多くの用途があります。
カスタマーサービスのWebチャット通信。
バックエンドのデバッグログ。すべてのアプリサーバーがさまざまなレベルでデバッグメッセージをブロードキャストしました。次に、JMSクライアントを起動して、デバッグメッセージを監視できます。もちろん、syslogのようなものを使用することもできましたが、これにより、コンテキスト情報（アプリサーバー名、APIコール、ログレベル、ユーザーID、メッセージタイプなどによって）に基づいて出力をフィルタリングするあらゆる種類の方法が得られました。出力も色分けしました。
ファイルへのログのデバッグ。上記と同様に、特定の部分のみがフィルターを使用して抽出され、一般的なロギングのためにファイルに記録されました。
警告。ここでも、上記のロギングと同様の設定、特定のエラーの監視、およびさまざまな手段（電子メール、テキストメッセージ、IM、Growlポップアップなど）による警告が行われます。
ソフトウェアクラスターの動的な構成と制御。各アプリサーバーは「configure me」メッセージをブロードキャストし、次に構成デーモンがあらゆる種類の構成情報を含むメッセージで応答します。その後、すべてのアプリサーバーで一度に構成を変更する必要がある場合は、構成デーモンから行うことができます。
そして通常-請求、注文処理、プロビジョニング、電子メール生成などの遅延アクティビティのためのキューに入れられたトランザクション...
非同期のメッセージ配信を保証したい場所ならどこでも素晴らしいです。
分散（a）同期コンピューティング。
実際の例は、アプリケーション全体の通知フレームワークであり、アプリケーションの使用過程のさまざまな時点で関係者にメールを送信します。したがって、アプリケーションはProducer、Messageオブジェクトを作成し、それを特定のに配置してQueue、次に進むことによって機能します。問題のにサブスクライブし、送信されたの処理に注意を払うの
セットがあります。このトランザクションの過程で、sは特定の処理方法のロジックから切り離されることに注意してください。
メッセージングフレームワーク（ActiveMQなど）は、を提供することにより、このようなトランザクションを容易にするバックボーンとして機能します。ConsumerQueueMessageProducerMessageMessageMessageBroker
私はこれを使用して、異なるファンド管理システム間で日中の取引を送信しました。優れたテクノロジーメッセージングについて詳しく知りたい場合は、「エンタープライズ統合パターン」という本を完全にお勧めします。リクエスト/返信やパブリッシュ/サブスクライブなどのJMSの例がいくつかあります。
メッセージングは、統合のための優れたツールです。
これを使用して、既存のトランザクションを中断したり競合させたりしたくない非同期処理を開始します。
たとえば、「ものを買う」のような高価で非常に重要なロジックがあるとすると、ものを買う際の重要な部分は「通知ストア」です。通知呼び出しを非同期にして、通知呼び出しに関係するロジック/処理が、buyビジネスロジックでリソースをブロックまたは競合しないようにします。最終的に、購入が完了し、ユーザーが満足し、私たちはお金を受け取ります。キューは配達が保証されているため、ストアが開いたとき、またはキューに新しいアイテムが入ったときにすぐに通知されます。
アマゾンに似たオンライン小売サイトである私の学術プロジェクトにそれを使用しました。JMSは、次の機能を処理するために使用されました。
メインサーバーに接続された複数のリモートクライアントも実装されました。接続が利用可能な場合は、メインデータベースへのアクセスに使用します。そうでない場合は、独自のデータベースを使用します。データの一貫性を処理するために、2PCメカニズムを実装しました。このため、これらのシステム間でメッセージを交換するためにJMSを使用しました。つまり、キューにメッセージを送信してプロセスを開始するコーディネーターとして機能するシステムと、キューにメッセージを再送信することによって応答するシステムがあります。他の人がすでに述べたように、これはpub / subモデルに似ていました。
ActiveMQと組み合わせて使用されるApache Camelは、エンタープライズ統合パターンを実行するための優れた方法です