リアルタイムのSOAアプリケーションに最適なメッセージングメディアですか？

Question

SOAスタイルを使用して実装されたリアルタイムアプリケーションで作業しています（メッセージングプロトコル-JMS、MQ、またはHTTPで接続された疎結合コンポーネントを読み取ります）。

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

この例では、HTTP Webサービス（速度、リソースフットプリントなど）のようなものよりもJMSを使用する利点がありますか？

私が考えていることの1つは、JMSアプローチではスレッドプールサイズ（JMSトピック/キューをリッスンするコンポーネントの数）を設定する必要があるためです。設定は必要ありません（HTTPリクエストごとに新しいスレッドが作成され、サーバーがリソースを使い果たすまで「無制限」のリクエスト数までアプリケーションをスケーラブルにします。）

何かが足りませんか？

Answer 1

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

• クライアントは、HTTPを介して通信する方法を知っている必要があります。これは、現代のあらゆる言語で何らかの形で十分にサポートされているプロトコルです。 JMSは一般的ですが、HTTPよりも専門的であるため、相互接続システムで使用できる言語が制限されています。現時点ではシステムの問題ではないかもしれませんが、後でJMS接続のサポートに苦労する可能性のある他のシステムをプラグインする必要がありますか？

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

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

素晴らしい質問、ところで。

Answer 2

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

上記に言及したように、標準は柔軟性を高めるのに役立ちますが、独自の形式はより多くの機能を許可します。

一言で言えば、ステートレスコール（最終的にはほぼすべてのニーズを満たすことができます）、およびステートフルコールに必要な独自の形式にはHTTPを使用すると言います。大企業で作業する場合、ハードウェアアプライアンスは通常、ミドルウェアとして最適です。超高速の圧縮、暗号化、変換、および翻訳であり、総所有コストは非常に低くなります。

Answer 3

要件については十分に知りませんが、管理性、柔軟性、パフォーマンスを見過ごされている可能性があります。

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

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

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

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

Answer 4

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

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

Javaを使用してサーバー側だけに焦点を合わせている場合-サーブレットであれMessageListener / MDBであれ、どちらも実際には似ています。違いはロードバランサーです。

だから、おそらく質問は本当にあるべきです-JMSブローカーはセットアップが簡単ですか？ DNS / NAT / IP / HTTPロードバランサーインフラストラクチャを設定するよりも動作しますか？

Answer 5

リアルタイムの意味に依存すると思います...私の意見ではJMSもHTTPも「リアルタイム」をサポートしていません。つまり、予測可能な/決定論的なパフォーマンスを提供することも、競合が存在するフローを適切に優先順位付けすることもできません。

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

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

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