ここには特定のクエリはありません。設計ガイドラインが必要なだけです。
Node.js 、 MQTT 、および Websocketsに関するこの記事に出会いました。Node/Java + ActiveMQ + Websockets を使用して同様の目的を達成できると思います。私の質問は MQ と MQTT の間で選択する方法ですか? ActiveMQ と比較して、 mosquittoのような「オープン」サーバーを中規模から大規模のプロジェクトで安全に使用できますか?
この記事にはある程度の洞察があり、MQ と MQTT の両方を使用する必要があるように思われます。将来軽量クライアントを取得した場合に MQTT が役立つ可能性があるからです。
ありがとう ！
Shashi の発言に加えて、これらにはさまざまな機能とユース ケースがあります。
MQTT は pub/sub の標準ワイヤ プロトコルを定義し、Shashi が指摘したように、非常に軽量な環境向けに設計されています。そのため、非常に最小限のワイヤ形式、いくつかの基本的なサービス品質、および基本的な機能セットを備えています。
一方、従来のメッセージ キューイング システムは一般に独自仕様であり (ただし、AMQP はそれを変更することを目指しています)、ポイント ツー ポイントとパブ/サブの両方をカバーし、多くのサービス品質を提供し、より重いワイヤー フォーマットを使用する傾向がありますが、これは存在しますが返信先アドレッシング、プロトコル変換などの拡張機能セットをサポートします。
MQTT の良い例は、電話、タブレット、セットトップ ボックスにエンドポイントがある場合です。これらには、最小限の馬力、メモリ、およびシステム リソースがあります。通常、これらからの接続は MQTT のままで相互に通信するか、バックエンド アプリケーションと相互通信できるエンタープライズ クラスの MQ にブリッジされます。たとえば、MQTT ベースのチャット クライアントは、MQTT ブローカーを介して別のクライアントと直接会話する場合があります。あるいは、MQTT ベースのコンテンツ配信システムは、携帯電話やタブレットで実行されるアプリに配信される広告やその他のコンテンツをホストするエンタープライズ メッセージング ネットワークにブリッジします。
そのため、MQTT は、電力、帯域幅、ネットワークの安定性が問題となる組み込みシステムやエンド ユーザー デバイスに使用されます。これは多くの場合、従来の MQ メッセージングと組み合わせて使用されますが、MQTT が従来のメッセージング アプリケーション専用のトランスポートとして使用されているのを見たことがありません。おそらくこれは、MQTT には、20 年間メッセージングの中核を成してきたメッセージ相関、応答先アドレス指定、ポイントツーポイント アドレス指定などのより堅牢な機能がいくつか欠けているためです。
MQTT プロトコルは、メモリ フットプリントが小さいセンサーや携帯電話などの小型デバイスに適しています。これらのデバイスは通常、脆弱なネットワークに配置されており、通常は計算能力が低くなっています。
これらのデバイスは、MQTT プロトコルを介して組織のバックエンド ネットワークに接続し、メッセージを送受信します。たとえば、オイル パイプラインの温度センサーは、パイプを流れるオイルの温度を収集し、コントロール センターに送信します。応答として、MQTT を介して別のデバイスにコマンド メッセージを送信し、そのパイプを通るオイルの流れを減らしたり停止したりすることができます。
WebSphere MQ には、MQTT デバイスとの間でメッセージを送受信する機能があります。したがって、デバイスとセンサーを含むメッセージング ベースのソリューションの実装を計画している場合は、MQ と MQTT を検討できます。
HTH