3

私は、SOA スタイルを使用して実装されたリアルタイム アプリケーションに取り組んでいます (いくつかのメッセージング プロトコル - JMS、MQ、または HTTP を介して接続された疎結合コンポーネントを読み取ります)。

このシステムを設計したアーキテクトは、JMS を使用してコンポーネントを接続することを選択しました。このシステムはリアルタイムであるため、1 つのコンポーネントに障害が発生した場合にメッセージをキューに入れる必要はありません (トランザクションは単にタイムアウトします)。さらに、保証された配信やロールバックは必要ありません。

この場合、HTTP Web サービスのようなもの (速度、リソース フットプリントなど) よりも JMS を使用する利点はありますか?

私が考えていることの 1 つは、JMS のアプローチではスレッド プール サイズ (JMS トピック/キューをリッスンするコンポーネントの数) を設定する必要があるため、この追加の構成がそうではないため、HTTP サービスの方が適しているのではないかということです。必要です (HTTP 要求ごとに新しいスレッドが作成され、サーバーがリソースを使い果たすまで、アプリケーションを "無制限" の数の要求に拡張できます)。

何か不足していますか？

4

5 に答える 5

2

私は S.Lott の指摘にまったく同意しませんが、HTTP Web サービスに関して考慮すべき点をいくつか示します。

  • クライアントは、HTTP を介した通信方法を知っているだけで済みます。HTTP は、現在のほぼすべての言語でさまざまな形でサポートされているプロトコルです。JMS は人気がありますが、HTTP よりも専門的であるため、相互接続されたシステムで使用できる言語が制限されます。現時点ではシステムの問題ではないかもしれませんが、JMS 接続をサポートするのに苦労する可能性のある他のシステムを後でプラグインする必要がありますか?

  • サービスに利用できる WSDL や SOAP などの標準は、多くの言語で十分にサポートされており、WSDL ファイルからパイプラインの両端 (クライアントとサーバー) を実装するコードを生成するツールがたくさんあります。あなたがしなければならない開発の量。これらの標準により、システム間で受け渡すデータの仕様を定義して公開することも比較的簡単になります。これはおそらく、JMS のようなキューイング テクノロジを使用して手動で行う必要があります。

  • 欠点として、S.Lott が指摘したように、JMS は、(ステートレス) HTTP プロトコルを使用して破棄する機能を提供します。順序付けと信頼性が保証されます。モニタリング; スケーラビリティ; これらは必要ないですか、今後も必要ありませんか?

いい質問ですね。

于 2008-10-28T22:46:45.510 に答える
2

本当に状況によると思います。私が働いている場所では、Remoting、JMS、MQ、HTTP、および sFTP をサポートしています。Remoting、JMS、MQ、および HTTP を使用するミドルウェア アプライアンスと、JMS、MQ、および HTTP を使用するソフトウェア ミドルウェア コンポーネントを実装しています。

上で述べたように、標準は柔軟になるのに役立ちますが、独自のフォーマットはより多くの機能を可能にします。

簡単に言うと、ステートレス呼び出し (ほとんどすべてのニーズを満たすことになる可能性があります) には HTTP を使用し、ステートフル呼び出しに必要な独自の形式は何でも使用します。大企業で働いている場合、通常、ハードウェア アプライアンスはミドルウェアとして最適です。超高速の圧縮、暗号化、変換、および変換であり、総所有コストが非常に低くなります。

于 2008-10-29T17:21:31.203 に答える
1

リアルタイムの意味にもよると思います...私の意見では、JMSもHTTPも「リアルタイム」アプリケーションをうまくサポートしていません。

その一部は、これらのテクノロジーが TCP の上に構築されていることです。TCP は、すべてのトラフィックを単一の FIFO にシリアル化します。つまり、さまざまなトラフィック フローに簡単に優先順位を付けることができません。さらに、TCP タイマーは簡単に制御できないため、予測できないブロックやタイムアウトが発生します... このため、多くのストリーミング アプリケーションは、TCP の代わりに UDP を基になるプロトコルとして使用します。

JMS のもう 1 つの問題は、典型的な実装では、メッセージのディスパッチを集中化するブローカーを使用することです。これは、決定論的なパフォーマンスを得るための最適なアーキテクチャではありません。

JMS で得られるような信頼性の保証とパブリッシュ/サブスクライブ セマンティクスを提供できるが、リアルタイム アプリケーション ドメインに適合するように開発されたミドルウェアを探している場合は、OMG Data-Distribution Service を検討することをお勧めします。 (DDS)。dds.omg.org と、リアルタイム SOA を実装するのに DDS が最適なミドルウェアである理由について論じたこの記事を参照してください。http://soa.sys-con.com/node/467488

于 2010-11-17T07:10:39.900 に答える
1

私はあなたの要件について十分に知りませんが、管理性、柔軟性、およびパフォーマンスを見落としている可能性があります。

JMS を使用すると、キューを監視および管理できます。これらは HTTP にはない機能であり、ベンダーから購入するのではなく、構築する必要があります。

また、JMS にはキューとトピックがあり、単一のパブリッシャーに複数のサブスクライバーを許可します。HTTP ではできません。

これらはリリース 1.0 では必要ないかもしれませんが、将来必要になるかもしれません。

また、JMS は名前付きソケットなどの他のトランスポート メカニズムを使用できる場合があります。これにより、(ほぼ) すべてのリクエストでソケット ネゴシエーションがすべて行われない場合、オーバーヘッドが削減されます。

于 2008-10-28T19:53:29.010 に答える
1

HTTP ルートをたどり、複数のマシンまたはある種の信頼性をサポートしたい場合 - 利用可能な Web サーバーを検出し、それらの間でリクエストをロードできるロード バランサーが必要になります - その後、別の Web サーバーにフェイルオーバーします特定のボックス/プロセスが停止した場合。HTTP 要求を行うクライアントは、サーバーの障害に対処し、何らかのループで操作を再試行する必要もあります。

これは、メッセージ キューの主な機能の 1 つです。フェイルオーバーによる信頼性の高い負荷分散と、再試行ロジックを含める必要のないプロデューサーとコンシューマー間の疎結合です。そのため、クライアントまたはサーバー コードはこの種のことを心配する必要はありません。これは、メッセージの永続性が必要かどうか、または ACID トランザクションを使用してメッセージを生成/消費するかどうかとはまったく別のものです (これは非常に便利です)。

Java を使用するサーバー側だけに焦点を当てると、サーブレットであれ MessageListener/MDB であれ、どちらの方法でも実際には似ています。違いはロードバランサーです。

したがって、おそらく質問は、DNS/NAT/IP/HTTP ロード バランサ インフラストラクチャをセットアップするよりも、JMS ブローカーをセットアップして操作する方が簡単ですか?

于 2008-10-29T08:26:06.823 に答える