Diffuser un message aux clients

Question

design

Un agent serveur conserve le vote DB (SQL Server 2012) pour trouver s'il y a un changement d'horaire et/ou configuration requise pour l'agent client. L'agent client s'exécute sur toutes les machines du réseau et doit obtenir une planification et une configuration d'analyse mises à jour à partir de l'agent serveur et mettre à jour son planificateur de travaux. L'agent serveur et l'agent client sont tous deux construits en Java.

problème Déclaration

Server pour envoyer des données à un nombre n d'agents clients une fois DB est mis à jour.

Solution1

Créer webservices sur les agents de serveur et client et consomment l'autre. Chaque fois qu'il y a un changement dans la planification/configuration d'analyse dans la base de données, le serveur appelle la méthode de l'agent client et met à jour les fichiers de configuration.

Inconvénient Solution1

Dans runnable JAR, deploy Axis2/Jetty/webserrver similaires sur tous les agents clients. Considérant ceci est le déploiement de serveurs Web sur tous les agents clients où le nombre peut aller jusqu'à 150000, est-ce conseillé? En outre, s'il existe des serveurs Web sur toutes les machines clientes, l'application peut-elle effacer la certification de sécurité?

Solution2

Utilisez RMI pour communiquer entre le serveur et le client. Dans ce scénario, le client conservera le serveur d'interrogation car la communication RMI est unidirectionnelle. L'utilisation d'appels bidirectionnels doit être évitée car elle implique de nouveau des sockets de serveur sur chaque machine client.

Inconvénient Solution2

Chaque fois que DB est mis à jour, il ne peut pas envoyer directement un message à toutes les machines clientes. Il doit attendre que l'ordinateur client l'interroge. Dans le cas où une analyse immédiate est requise, tous les agents clients devront fréquemment interroger l'agent maître. est-ce conseillé étant donné que le nombre d'agents clients peut être énorme? Un autre inconvénient informé par Java architecte est que RMI est plus lent que webservice. Est-ce exact?

Je dois choisir l'une de ces deux solutions OU s'il y a une troisième solution que vous pouvez me donner. Une personne a également suggéré JMS comme moyen de diffusion.

Answer 1

Votre solution 1 a un autre problème - tout le monde connaît le serveur, mais le serveur ne connaît pas tous les clients. Bien sûr, vous pouvez faire un flux de travail d'enregistrement client sur le serveur, mais cela rend le serveur lourd à publier les messages

Je ne considère même pas la solution 2 ici. RMI pour moi est aussi bon que mort, nous avons de meilleures architectures en place en ce moment. Lancez une file d'attente de messagerie dans un modèle d'abonnement.

1. Chaque fois qu'il y a une mise à jour, envoyez les messages au gestionnaire de files d'attente et laissez le gestionnaire de files d'attente s'inquiéter de la diffusion sur tous les clients disponibles. Vous pouvez utiliser ici des files d'attente fiables telles que RabbitMQ, MQTT, etc.

L'avantage principal est la fiabilité de la messagerie. Il y a des options pour s'assurer que chaque abonné reçoive le message, ce qui est bien. Vous pouvez faire un push/pull plus tard si vous voulez. Vous pouvez également mettre en cluster les files d'attente de messagerie, ce qui créera une solution à charge équilibrée si le nombre de clients augmente plus tard.

2. Vous pouvez également utiliser une prise Web si la vitesse de transmission est requise. Mais ce n'est pas aussi bon que l'option 1, en raison de son utilisation des ressources. Mais si vous n'êtes pas inquiet à ce sujet, les Websockets sont un moyen super cool de communications full duplex.