Qu’est-ce que Comet (programmation) ?
Comet est un paradigme de conception d’applications web qui décrit une interaction continue et bidirectionnelle entre un serveur et un navigateur web en utilisant des méthodes HTTP natives. Il a été conçu afin de fournir un modèle conceptuel pour la conception d’interfaces utilisateur web réactives et hautement interactives sans avoir à recourir à des plugins de navigateur comme les applets Java.
L’approche Comet met à l’envers le modèle client-serveur HTTP typique pour permettre une sorte de fonctionnalité Ajax inversée, dans laquelle le serveur web initie une connexion HTTP persistante avec un navigateur client et expulse activement des données au lieu d’attendre de servir des réponses. En d’autres termes, Comet représente un mécanisme de type « Push-Style » ou « Server-Push » par opposition au mécanisme HTTP « Request/Response » ou « Get/Pull ».
Techniques de Comet
Un certain nombre de techniques HTTP existent pour réaliser cette interaction événementielle, notamment le Push Ajax, le streaming HTTP et le Push serveur HTTP. Ces techniques s’appuient principalement sur JavaScript pour gérer les événements en continu du côté client, tandis que le format de messagerie est souvent en JSON ou XML.
Un exemple plus moderne est le WebSocket, un protocole de transport sophistiqué qui emprunte les principes de Comet mais qui offre une réalisation plus propre et plus standardisée de l’idée. Toutefois, WebSocket est un protocole distinct et n’est généralement pas considéré comme une forme de Comet.
Modèle de Comet
Le modèle Comet est souvent utilisé pour les applications web qui impliquent une collaboration multi-utilisateurs où la latence doit être maintenue aussi faible que possible pour une expérience partagée en temps réel. Traditionnellement, il est utilisé pour fournir un support pour l’édition collaborative de documents et le chat multi-protocole.
Pour appliquer Comet dans une application web, deux grandes méthodes sont disponibles :
– Le streaming : Les événements sont transmis du serveur au client via une seule connexion persistante et sont généralement traités dans une iframe cachée sur la page ou via XMLHttpRequest.
– Sondage long : Le navigateur interroge le serveur sur les nouveaux événements au moyen d’une requête persistante qui reste ouverte jusqu’à ce qu’il obtienne une réponse. Lorsque de nouvelles données sont disponibles, le serveur envoie la réponse et une nouvelle requête longue de sondage est faite par le navigateur pour de nouveaux événements. Rincez et répétez pour une interaction soutenue.
Bref aperçu des cadres WebSocket et Comet en Java
Les applications web deviennent de plus en plus interactives et dynamiques. Dans certains cas, un modèle de demande-réponse régulier n’est pas la meilleure solution, par exemple si l’application affiche des données fréquemment modifiées, elle doit alors se rendre sur le serveur pour des mises à jour de données à intervalles très courts. Une telle approche impose donc une charge importante au réseau en créant de nombreuses demandes de vérification des mises à jour. Les protocoles WebSocket et Comet sont conçus pour résoudre ce problème. WebSocket est un protocole full duplex et fait partie de HTML5. Comet est un terme général qui couvre plusieurs techniques et approches permettant à un serveur d’envoyer des données et des notifications à un navigateur.
Les principaux cas d’utilisation où WebSocket/Comet pourrait être utile sont les applications commerciales en temps réel, les jeux par navigateur, la messagerie instantanée et d’autres applications reposant sur des mises à jour fréquentes des données.
CometD
CometD est l’un des cadres Comet les plus matures. Il possède une API Java pour les clients et les serveurs, et fournit des bibliothèques de dojo et de jquery pour une intégration plus facile côté client. L’architecture du framework est concise et extensible. Le site web du projet contient une bonne documentation et un certain nombre d’exemples. Le cadre fournit la gestion de l’authentification et prend en charge la mise en grappe via une bibliothèque tierce.
Le développement du projet n’est pas très actif, mais de nouvelles versions sont publiées quelques fois par an.
Atmosphere
Contrairement à la communauté de CometD Atmosphere qui est très active sur Github, les nouvelles versions sont assez souvent publiées. La documentation d’Atmosphere contient beaucoup d’informations et d’exemples. Cependant, certains exemples utilisent l’annotation GET/POST de JAX-RS pour la cartographie des points terminaux, ce qui semble assez étrange en termes de paradigme canal/sujet de WebSocket/Comet et peut semer la confusion chez les développeurs. Le cadre a des extensions pour Spring, Wicket, GWT, JSF, Netty et supporte un tas d’extensions JS. Il prend également en charge les langages JVM Scala et Groovy.
Diffusion
Le seul cadre propriétaire dans cette revue a laissé un sentiment mitigé. En plus du protocole WebSocket, ce cadre peut également fonctionner sur un protocole propriétaire. Il possède un grand nombre de bibliothèques clientes, dont iOS, Android et Flex/Flash. L’architecture de Diffusion est assez différente de celle des applications web java typiques. Grâce à un cadre de réseau propriétaire et à un conteneur d’application autonome, ce cadre présente de très bonnes performances.
Toutefois, le prix de ces performances élevées limite les options de déploiement, car l’application Diffusion ne peut pas être déployée sur des conteneurs d’application standard comme Tomcat, Jetty, Jboss. Cela rend également difficile le déploiement dans un environnement cloud. Le cadre fournit une documentation qui couvre principalement des cas d’utilisation triviaux.
Java EE7
Java EE7 et son implémentation de référence GlassFish 4 sont livrés avec un support intégré des websockets à la fois sur le serveur et le client. L’API est simple, pratique et extensible. L’avantage évident de ce choix est une plate-forme solide qui ne nécessite aucune bibliothèque externe. Ce pourrait être le bon choix si le projet est construit autour de Java EE/ WebSocket et n’a pas besoin de supporter les anciens navigateurs et la compatibilité avec Comet.
DIY
La dernière façon de mettre en œuvre un système de notification côté serveur est de construire votre propre cadre. Ce n’est pas aussi difficile qu’il n’y paraît, puisque les dernières versions de Jetty et Tomcat ont une prise en charge intégrée du traitement asynchrone des demandes. En outre, le framework Netty peut être utilisé pour des déploiements sur des serveurs d’applications plus anciens. C’est le chemin le plus long, mais de cette façon, vous pouvez construire une solution qui répond parfaitement à vos besoins.
Résumé
Le monde de Java bénéficie d’une variété d’implémentations du protocole Сomet. Si vous avez besoin d’un support complet du transport WebSocket/Comet, les frameworks CometD et Atmosphere semblent être le choix le plus approprié. CometD est plus stable et plus mature tandis qu’Atmosphere prend en charge de nombreuses extensions et cadres. Si vous utilisez un serveur d’application Java EE 7 et que la prise en charge des anciens navigateurs n’est pas essentielle, la bibliothèque WebSocket intégrée est suffisante.