Nous souhaitons transférer des données d'un serveur vers des clients mais ne pouvons utiliser que HTTP (port 80). Quelle est la meilleure solution pour la messagerie? Une idée est Comet. Existe-t-il d'autres idées ou frameworks qui permettent de dire JMS sur HTTP? (Oui, ActiveMQ le supporte aussi, mais à mon humble avis, et JXTA le supporte aussi, mais la configuration est compliquée.)Meilleure solution pour Java HTTP push (messagerie)
La solution la plus simple pour de nombreuses raisons est d'utiliser une approche basée sur Comet (comme vous mentionnez). Cela signifie que les clients (à qui vous voulez "pousser" les messages) ouvrent des connexions HTTP de longue durée. Ces connexions restent ouvertes jusqu'à ce qu'elles expirent ou que vous envoyiez un message au client. Dès qu'il se produit, le client ouvre une nouvelle connexion.
La connexion directe aux clients peut être problématique pour plusieurs raisons: ils peuvent être derrière des pare-feu interdisant cela, ils peuvent être derrière des mandataires et ainsi de suite.
À moins que vos clients ne soient de vrais serveurs (dans ce cas, vous êtes vraiment le client), demandez-leur de vous contacter et d'envoyer une réponse à imiter push.
Nous avons utilisé COMET en conjonction avec JMS en utilisant WAS Web 2.0 Feature Pack; En effet, le serveur a fait l'abonnement JMS et COMET-poussé le message au navigateur. En tant que développeur, il "sentait" que le navigateur était abonné à JMS. Cela "a juste fonctionné" ainsi nous n'avons pas cherché plus loin pour des solutions de rechange.
Je pourrais imaginer une implémentation JavaScript JMS pure dans le navigateur, en utilisant HTTP comme moyen de transport, mais mon instinct est que ce serait très lourd. Je ne connais pas de telles implémentations.
L'approche alternative à celles déjà discutées (c'est-à-dire Comet etc.) consiste à implémenter l'interrogation dans le client. L'inconvénient de cette approche est que vous avez inévitablement un retard à partir du moment du message/événement et jusqu'à ce que le client le reçoive. Si votre application est très sensible à ces retards, l'interrogation est terminée.
Si un certain délai (au moins de l'ordre de quelques secondes) est acceptable, l'interrogation est moins un abus du protocole HTTP. Il est également plus robuste contre les problèmes de réseau temporaires car le serveur met en file d'attente par défaut les messages et ne se dérange pas si le client n'est pas disponible dans son emploi du temps.
Il n'y a vraiment pas de grande différence entre les interrogations et les connexions de longue durée. Dans les deux cas, vous initiez un sondage, et il reviendra immédiatement, ou avec un certain retard. Plus le délai est long, moins vous avez de connexions à ouvrir. Dans tous les cas, des problèmes tels que les appels terminés ou non répondus mènent au prochain sondage. Dans le protocole HTTP/1.1, la connexion (TCP) reste généralement ouverte. – eckes
Atmosphere et DWR sont deux frameworks open source qui peuvent rendre Comet facile en Java.
J'ai créé un exemple d'application en utilisant Comet, Raphael, Bayeux, Java et Maven exécutant PaaS Cloudbees et écrit un billet de blog à ce sujet, j'espère que cela sera utile à quelqu'un.
http://geeks.aretotally.in/thinking-in-reverse-not-taking-orders-from-yo
Le lien ne fonctionne pas. –
Est-ce exact? Lorsque le message arrive au navigateur, une nouvelle connexion est ouverte? – djna
Le client doit être programmé pour ouvrir une nouvelle connexion. Si ce n'est pas le cas, le serveur n'a aucun moyen de communiquer avec le client. – cletus
Je suis désolé. J'ai de la difficulté à comprendre. Le client a ouvert une connexion HTTP de longue durée. Le serveur envoie des messages là-bas - non? Vous dites alors: «Ces connexions restent ouvertes jusqu'à ce qu'elles expirent ou que vous envoyiez un message au client, dès que le client ouvre une nouvelle connexion. On dirait que nous ouvrons une deuxième connexion. Pourquoi? Le message que nous venons de recevoir contient les données que nous voulons, n'est-ce pas? – djna