6

O'Reilly Media の本「Java Message Service」には次のように書かれています。

ポイント ツー ポイント メッセージングで要求/応答モデルを使用します。

pub/sub メッセージングでメッセージ セレクターを使用できるため、リクエスト/リプライ モデルの作成は、リプライ トピックで単純なセレクターを作成するのと同じくらい簡単です。

  1. パブリッシャーは、いくつかの固有のプロパティ ( など) を持つメッセージをパブリッシュしUUIDますcorrelationID。
  2. UUIDサブスクライバーはメッセージに対して次のように応答しますcorrelationID
  3. パブリッシャー (返信トピックのサブスクライバーでもある) は、UUID送信済みのメッセージを選択します。

これは間違ったパターンですか？

4

1 に答える 1

2

Request/Reply メッセージング パターンは、通常、サービス プロバイダーがホストするサービスを呼び出すために使用されます。サービス要求に基づいて、プロバイダーは適切な応答で応答します。だから一対一です。ここで、リクエスターとレスポンダーはお互いを認識しています。

パブリッシャーとサブスクライバーの場合、パブリッシャーとサブスクライバーはお互いを知りません。あるトピックについて多数のパブリッシャーが公開している可能性があり、そのトピックを聞いている何千もの購読者がいる可能性があります。したがって、パブリケーションを受信した後、サブスクライバーがトピックを使用して要求に応答した場合、そのパブリケーションは多数のサブスクライバーに送信される可能性があります。そのようなことは、ネットワークをフラッディングする可能性があります。

私の意見では、リクエスト/リプライ モデルは、Pub/Sub ではなく P2P メッセージングで使用する必要があります。

于 2012-06-19T06:13:47.517 に答える