放送メッセージクライアントに

Question

デザイン

A Serverエージェントは、任意のスケジュールの変更および/またはクライアントエージェントに必要な設定があるかどうかを見つけるためにポーリングDB（SQL Server 2012の）を続けています。クライアントエージェントはネットワーク上のすべてのマシン上で実行され、更新されたスキャンスケジュールと構成をサーバーエージェントから取得し、そのジョブスケジューラを更新する必要があります。サーバーエージェントとクライアントエージェントの両方がJavaで構築されています。 DBが更新されると

問題に関する声明

Serverは、クライアントエージェントのn個の数にデータを送信します。

ソリューション1

サーバとクライアントエージェントのWebサービスを作成し、お互いを消費します。 DBのスキャンスケジュールや設定に変更があると、サーバはクライアントエージェントのメソッドを呼び出して設定ファイルを更新します。

デメリットソリューション1

実行可能JARには、すべてのクライアントエージェント上のAxis2 /突堤/類似webserrverを展開。これが150000まで増えることができるすべてのクライアントエージェントにウェブサーバを配備していることを考えると、それはお勧めですか？また、すべてのクライアントマシンにWebサーバーがある場合、アプリケーションはセキュリティ証明書をクリアできますか？

対処方法2

サーバとクライアント間の通信にRMIを使用してください。このシナリオでは、クライアントはRMI通信が一方向であるため、ポーリングサーバーを保持します。双方向呼び出しの使用は、各クライアントマシンにサーバーソケットが含まれているので、避けてください。

デメリット対処方法2

DBが更新されるたびに、それが直接、すべてのクライアントマシンにメッセージを送信傾けます。それはクライアントマシンがそれをポーリングするのを待つ必要があります。即時スキャンが必要な場合は、すべてのクライアントエージェントが頻繁にマスターエージェントをポーリングする必要があります。これは、クライアントエージェントの数が膨大になる可能性を考慮してお勧めですか？ Javaアーキテクトのもう一つの欠点は、RMIがWebサービスよりも遅いことです。あれは正しいですか？

私はこれらの2つのソリューションのいずれかに行く必要がありますか、またはあなたが私に与えることができる任意の3番目のソリューションがある場合。 1人はJMSを放送方法として提案しました。

Answer 1

解決策1には別の問題があります。誰もがサーバーを知っていますが、サーバーはすべてのクライアントを認識しません。もちろん、サーバー上でクライアント登録のワークフローを行うこともできますが、サーバーを重くしてメッセージを公開することがあります。

私はここでも解決策2は考えていません。私にとってのRMIは死んだものと同じくらい良いです、私たちは今よりずっと優れたアーキテクチャを持っています。

1. サブスクリプションモデルでメッセージングキューを起動します。更新があるときはいつでも、キューマネージャにメッセージをプッシュし、キューマネージャが利用可能なすべてのクライアントにブロードキャストすることを心配させる。 RabbitMQ、MQTTなど、信頼性の高いキューを使用できます。

主なメリットはメッセージングの信頼性です。すべての加入者が確実にメッセージを受け取れるようにするオプションがあります。必要に応じて後でプッシュ/プルすることができます。クライアントの数が後で増える場合は、負荷分散ソリューションを作成するメッセージキューをクラスタ化することもできます。

2. 送信速度が必要な場合は、ウェブソケットを使用することもできます。しかし、これは、そのリソース使用のためにオプション1ほど良くはありません。しかし、あなたがそれについて心配していなければ、ウェブソケットは全二重通信の超クールな方法です。