News originale publiée le 11 décembre 2008
Au milieu des années 90, le World Wide Web a subi une forte et rapide évolution qui l'a conduit à devenir le principal moyen de distribution de l'information. Avec des navigateurs internet qui devenaient incontournables, des utilisateurs qui s'étaient habitués à ce type d'expérience, le WWW apparut à cette époque comme une plateforme pour applications possédant un potentiel d'accessibilité aux utilisateurs jamais vu jusqu'à lors. Il était pourtant bien tôt et les principaux standards (HTML, HTTP, etc.) n'avaient pas été conçus à la base pour proposer des interactions évoluées et des expériences utilisateur poussées. Une partie du travail d'origine sur le déploiement d'applications riches en ligne, peut être attribuée à l'équipe d'ingénieurs de Microsoft Exchange. Depuis 1996, ils avaient utilisé l'élément IFrame afin de pouvoir proposer un rendu proche d'Outlook à leur système de mail. Ces essais précurseurs étaient certes décevants en terme de réactivité et d'expérience utilisateur, mais ils représentaient un tournant laissant entrevoir ce qui était à venir. En 1998 quand ils commencèrent à implémenter un front-end web pour MS Exchange Server 2000, ils développèrent XMLHTTP, un composant qui rendait possible les communications asynchrones entre le serveur et une unique page web. Comme la dernière phrase laisse entendre, XMLHTTP n'avait d'origine pas de lien direct à XML. Alex Hopmann, membre de l'équipe à cette époque, émit l'hypothèse que la seule raison pour laquelle ils optèrent pour le préfixe XML fut que IE5 était alors proche de sa deuxième version beta et qu'ils devaient livrer leur travail en tant que partie de la bibliothèque MSXML.
Cette nouvelle technologie fut aussi implémentée par la fondation Mozilla sous le nom XMLHttpRequest (XHR) en 2002 à l'occasion de la première version de leur navigateur, qui devint par la suite Firefox. Bien que d'autres éditeurs s'employèrent à utiliser la puissance de ces APIs, le paradigme de script à distance qu'ils mettaient en avant ne bénéficia pas de la visibilité du public, jusqu'au jour où Google déploya une série de services nouvelle génération basée sur JavaScript et XHR. Le premier service fut Google Maps dont la présentation eut lieu sur Google Blog le 8 février 2005. Après cela et dans les mois qui suivirent, XHR devint l'un des sujets les plus médiatiques de notre industrie. A cette époque, personne ne pouvait concevoir vraiment quelle révolution dans le développement d'applications Web XHR représentait, mais il était déjà sûr que cette technologie allait changer notre vision du WWW.
Avec la publication de Kaazing Gateway, InfoQ interrogea Richard Smith sur l'évolution des technologies comme AJAX, Comet et le prometteur HTML5 Web Sockets:
Ajax fit évoluer le modèle classique de communication HTTP en permettant aux clients d'effectuer des requêtes de type poll lors d'événements serveur. En utilisant une stratégie de « polling », les événements serveur peuvent être mis dans une pile et transmis au navigateur lors de chaque intervalle de poll, ce qui émule l'effet d'un serveur initiant les communications et donne un comportement de type temps réel dans les limitations imposées par l'intervalle de temps du poll. De ce fait, les communications en temps réel pur ne peuvent être mises en place avec Ajax comme seul outil à notre disposition.
Le modèle de communication HTTP fut de même encore plus secoué avec l'arrivée de Comet, cette technologie permettait des communications de type « Push » sur HTTP. Comet propose plusieurs techniques qui permettent au serveur d'envoyer des données au navigateur sans demander une action du client. Grâce à l'addition d'une connexion HTTP, Comet facilite les communications bi-directionnelles sur 2 connexions HTTP. Toutefois, le principal défaut de Comet est son absence d'implémentation standarde à cause du manque de support fourni par chaque éditeur de navigateur Web au sujet de XHR et IFrame – deux couches techniques importantes sur lesquelles sont bâties les communications Comet. De plus, une surcharge importante est à prévoir, à la fois d'un point de vue réseau mais aussi au niveau du développement, pour la gestion des deux connexions de communications. Ces coûts peuvent induire de la latence dans les applications reposant sur Comet ce qui limite la précision des communications temps réel que cette technologie permet.
Les WebSockets de HTML5 représentent la prochaine tentative, après Comet et Ajax, d'évolution du modèle de communications HTTP. La spécification HTML5 WebSocket définit une connexion par socket full-duplex (bi-directionnel) pour l'envoi et la réception de données entre le navigateur et le serveur. Ainsi, cette technologie évite les inconvénients de portabilité et de connexion de Comet, tout en proposant une solution plus efficace que le polling d'Ajax. A présent, le mécanisme des WebSockets HTML5 est la solution prédominante et préférée pour les besoins de communications temps réel bi-directionnelles sur le Web.
Richard pense que les approches d'AJAX et de Comet possèdent de nombreuses limitations
Essayer de simuler une initiation de la communication du serveur vers le client avec Ajax nécessite beaucoup d'actions de polling, qui vérifient aveuglément la présence de changements sans prendre en compte les changements d'état de l'application. Le résultat est une mauvaise gestion des ressources du côté client mais aussi serveur, les cycles CPU et la mémoire se retrouvant alloués d'office parfois inutilement: de manière trop prématurée ou au contraire trop tardive, afin de permettre la détection de changements côté serveur. Par conséquent, en fonction du ratio de publication d'événements du serveur, les applications AJAX traditionnelles doivent constamment chercher le meilleur intervalle de temps de polling possible afin d'obtenir le meilleur compromis performance / consommation de ressources pour chaque requête effectuée. Pour compliquer cela, les fréquences de polling hautes sont synonymes de traffic réseau plus élevé et de demandes serveur plus nombreuses tandis que les fréquences basses peuvent quant à elles conduire à des pertes de données ou à la délivrance de données périmées. Dans tous les cas, une latence trop élevée est la cause de la mauvaise livraison de données au navigateur. De leur côté, les intervalles de temps de polling courts sont beaucoup plus coûteux en ressources car ils impliquent un support élévé de ping serveur posant divers problèmes de mise à l'echelle (scaling). Comet essaie de fournir des communications de type push en maintenant une connexion permanente ou en utilisant des requêtes HTTP sur de longs lapses de temps entre le serveur et le navigateur. Cette connexion permet au serveur d'envoyer des événements, initiés par le client au navigateur. Les autres requêtes, pouvant être réalisées par le navigateur au serveur, ont lieu sur une connexion HTTP supplémentaire. De ce fait, Comet facilite les communications bidirectionnelles sur deux connexions. Toutefois, la maintenance induite de ces 2 connexions implique une surcharge en termes de ressources serveur car deux fois plus de ressources sont requises pour chaque client. De plus, les navigateurs sont configurés pour limiter le nombre de connexions HTTP disponibles par domaine. Cela rend l'utilisation de Comet complexe et des techniques avancées comme le multiplexing ou la gestion de plusieurs domaines doivent souvent être utilisées pour que Comet soit efficace. Certaines utilisations de Comet se basent sur le long-polling afin de réduire la consommation de ressources. Toutefois, cette technique a pour inconvénient d'envoyer un grand nombre de headers HTTP pour les requêtes et les réponses. Par exemple, chaque fois qu'un événement serveur est envoyé, le serveur se sert de sa connexion avec le navigateur, forçant celui-ci à réétablir une nouvelle connexion. Cette action provoque une nouvelle requête du client et une réponse serveur à travers le réseau pour chaque intervalle de long-poll. Le plus souvent, les headers HTTP dans la réponse surchargent le message à délivrer en terme de poids:
Du client (navigateur web) au serveur: GET /long-polling HTTP/1.1\r\n Host: www.kaazing.com\r\n User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9) Gecko/2008061017 Firefox/3.0\r\n Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n Accept-Language: en-us,en;q=0.5\r\n Accept-Encoding: gzip,deflate\r\n Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7\r\n Keep-Alive: 300\r\n Connection: keep-alive\r\n Cache-Control: max-age=0\r\n \r\n Du serveur au client (navigateur): Date: Tue, 16 Aug 2008 00:00:00 GMT\r\n Server: Apache/2.2.9 (Unix)\r\n Content-Type: text/plain\r\n Content-Length: 12\r\n \r\n Hello, world Le développement avec Comet s'accompagne de plusieurs challenges. Il est possible d'avoir à définir sa propre solution. Pour cela, il faut développer une bibliothèque JavaScript qui utilise un certain nombre de techniques comme les frames immortelles (forever frames) et le streaming XHR afin de maintenir une connexion permanente. L'implémentation de ces techniques dépend malheureusement du navigateur, elles requièrent souvent du code serveur renvoyant des morceaux de code JavaScript, ce qui accentue la complexité de l'implémentation et pose des soucis de portabilité / maintenabilité. Heureusement, plusieurs frameworks simplifient le développement avec Comet en proposant plusieurs abstractions dans la gestion de ces transports. Le plus remarqué est Cometd de SitePen, qui est une implémentation du protocole de Bayeux référence – une spécification qui définit le modèle publish-subscribe pour Comet. Les récentes versions de Jetty incluent aussi une implémentation Java du protocole de Bayeux. Bayeux et Cometd sont une aide indéniable. Toutefois, les APIs en question et le protocole réseau sont au cœur de diverses polémiques. Comet Daily nous donne son avis approfondi sur les problématiques propres à Bayeux dans sa série d'articles Colliding Comet: Battle of the Bayeux.
Il suggère que les WebSockets HTML5 dans leur définition présente ont plusieurs avantages par rapport aux solutions actuellement utilisées:
Bien que Comet et Ajax permettent tous deux de fournir des expériences utilisateur de qualité de type desktop avec une bonne réactivité, seuls les WebSockets peuvent tenir la promesse d'une solution native au problème de latence en la rendant négligeable, permettant ainsi des échanges efficaces d'événements avec le navigateur. Ils représentent de loin la solution la plus évidente à la gestion de données en temps réel sur le Web. Non seulement ils permettent des communications bi-directionelles asynchrones sur une unique connexion TCP/IP, mais ils comportent aussi moins de headers HTTP et surtout, ils permettent au navigateur et au service d'origine d'utiliser le même format de message d'échange. La plupart des implémentations de Comet reposent sur le protocole de Bayeux. L'utilisation de ce protocole nécessite la transformation des messages issus des services sources vers un format conforme à Bayeux. Cela ajoute de la complexité à l'architecture inutilement, obligeant les développeurs à manipuler un format du message sur le serveur (par exemple JMS, IMAP, XMPP, etc.) et un second sur le client (Bayeux et JSON par exemple). De plus, cette transformation voulue afin de lier le protocole d'origine à Bayeux a des impacts sur les performances car chaque message doit être interprété et traité avant d'être envoyé sur le réseau. Avec les WebSockets, le message envoyé par le serveur est le même que celui reçu par le navigateur, retirant ainsi les soucis de performance et de complexité liés à la transformation des messages. Une question de disponibilité est souvent abordée à l'égard des WebSockets. Pour le moment, les navigateurs ne proposent pas de support natif. Toutefois, cela doit changer dans les prochains mois car les navigateurs WebKit, Firefox et Opera ont toujours été rapides historiquement pour intégrer des fonctionnalités HTML5 comme canvas, postMessage, le stockage hors ligne, et les Server-sent events (SSE). Les WebSockets nécessitent aussi un certain support côté serveur car une action d'initialisation sur HTTP est nécessaire afin de faire évoluer la connexion HTTP existante en une connexion TCP/IP native. Le projet open source Kaazing Gateway est le premier serveur à fournir ce support tout en permettant d'avoir la scalabilité nécessaire pour servir des dizaines de miliers de connexions permanentes. Kaazing, l'éditeur de Kaazing Gateway, fournit aussi une bibliothèque JavaScript qui permet à chaque navigateur Web récent de tirer profit des WebSockets. De cette façon, le support des WebSockets est déjà disponible aujourd'hui.
Pour travailler avec les WebSockets HTML5, Kaazing a publié Kaazing Gateway 8.09_2 Atlantis qui est un serveur open source HTML5 WebSockets disponible sous la licence [OSI approved Common Public Attribution License(CPAL)] (http://www.opensource.org/licenses/cpal_1.0) – un dérivé de la licence Mozilla MPL (Mozilla Public License):
Kaazing Gateway permet aux développeurs de tirer profit des WebSockets aujourd'hui via une bibliothèque JavaScript qui peut émuler les WebSockets HTML5, il est donc possible de construire des applications se basant sur l'interface WebSocket pouvant être déployée à la fois sur les navigateurs actuels mais aussi les futurs. Le serveur à hautes performances derrière Kaazing Gateway peut supporter des dizaines de milliers de connexions concurrentes sur un seul nœud. Plusieurs instances peuvent être mises en clusters avec des serveurs de load-balancing classiques ou via du round-robin DNS, permettant de supporter n'importe quel nombre de connexions permanentes simultanées. En addition du support d'un grand nombre de connexions, Kaazing Gateway peut aussi délivrer de hauts débits de données grace à son architecture de type SEDA (Staged Event Driven Architecture). La version Atlantis de Kaazing Gateway inclut des clients JavaScript pour le support de plusieurs services de messaging connus tels que Apache ActiveMQ et RabbitMQ, des clients aussi pour les services XMPP comme OpenFire, Jabber, et d'autres serveurs de chat populaires. Cela permet de faciliter la construction d'applications Web de chat ou des applications de messaging comme des applications de gestion de stock (stock matrices), des plateformes d'échange en ligne (online trading), ou des jeux en ligne (online gaming).
La version 8.12 de Kaazing Gateway prévoit de fournir de nouvelles fonctionnalités HTML5 comme les Server-sent Events (SSE), des services de sécurité avancés, un support étendu de [XMPP] (http://xmpp.org/) (Jabber) et STOMP (par exemple ActiveMQ, RabbitMQ, ou OpenMQ):
Grace à ces bibliothèques, chaque navigateur Web peut supporter les SSE et postMessage, ce qui facilite l'échange de messages entre documents. Les bibliothèques de Kaazing ajoutent aussi le stockage hors ligne de HTML5 se basant sur DOM. Kaazing Gateway comprend aussi le support du W3C Access Controls for Cross-Site Requests, qui est une technique utilisée pour gérer les requêtes clientes entre différents domaines Web, on parle aussi plus généralement de Cross-Site XmlHttpRequests. Au delà du support étendu de HTML5, Kaazing Gateway 8.12 possède aussi des fonctions XMPP avancées comme le chat en groupe. Cette version introduit STOMP-JMS Adapter, qui permet de connecter un service existant de type Java Message Service (JMS) (comme JBoss Messaging, Tibco EMS, OpenMQ, SwiftMQ, WebSphere MQ, etc.) avec Kaazing Gateway.
Plus d'information à propos d'AJAX, Comet et les applications riches en ligne : Rich Internet Applications sont disponibles ici sur InfoQ.