2

JMSまたはメッセージングは​​、異種のアプリケーションを結び付け、多くのESBおよびSOAアーキテクチャーのインフラストラクチャーを形成するのに非常に優れています。

ただし、アプリケーションAがアプリケーションBのサービスからの即時応答を必要としているとします。たとえば、注文のプロビジョニングの詳細が必要であるか、更新の即時確認が必要です。パフォーマンスの観点から、メッセージングは​​そのための適切なソリューションですか？通常、クライアントはキュー上のMoMに接続します。その後、解放されている必要のあるリスナーがメッセージを取得してサーバー側のプロセッサに転送します。このプロセッサは、応答を処理して、キューまたはトピックと要求元に送り返します。クライアントは同じプロセスに従い、それを受け取ります。メッセージサイズが大きい場合、MoMはそれも考慮に入れる必要があります。

メッセージングルートを経由するのではなく、Httpがそのようなソリューションにアクセスするためのより良いソリューションであるかどうか疑問に思いますか？多くのアプリケーションがAMQやTIBCORvdなどのMoMを使用して、即時の要求/応答に実際に使用しているのを見てきましたが、それは悪い設計であるか、それをHttpと同じにする微調整または設定です。

4

1 に答える 1

2

それは本当にあなたの要件に依存します。通常、メッセージングサービスは、次の1つまたはすべてをサポートします。

  • 配達保証
  • トランザクション
  • 永続的（つまり、システムが中間で障害を起こした場合でも、メッセージは配信されるまで永続化されます）

HTTP接続はこれらの属性を[簡単に]実装することはできませんが、必要がなければ、「単純な」HTTPがより単純で軽量なソリューションを提供するというケースを作ることができると思います。（一部のメッセージング実装はHTTPを介して動作するため、「単純」に重点を置いています）。

メッセージングを介して実装された要求/応答は、それ自体が悪い設計ではないと思います。つまり、これが問題です....このプロセスの両側を実装していますか？そうでない場合、要求に応答する確立されたメッセージングサービスがすでにある場合は、他のすべての考慮事項は別として、それが進むべき道のように思われます...そして、いくつかの設計概念のためにHTTPを使用して再実装するためにそれをバイパスするには、かなりの量が必要になります私の見解では、その背後にある強い推論。

しかし、その逆も同様です。すでにHTTPアクセス可能なリソースがあり、より堅牢なメッセージングソリューションを提案するような非常に厳しい要件がない場合は、保証されていない場所に強制することはありません。

あなたが完全にタブララサを始めていて、最初から両側を実装しなければならないなら.....それから.....ここにいくつかの詳細を含む別の質問を投稿してください！:)

于 2013-02-26T22:22:52.053 に答える