Inovia Blog

L’actualité des technologies innovantes

Les applications web gagnées par le temps-réel : un plan sur la Comet ?

Par Kadda SAHNINE

Publié le | 6 novembre 2009 |

push.jpgEn l’espace de quelques années, les applications web se sont imposées comme un référent technologique absolu pour la plupart des systèmes et logiciels informatiques. A partir d’un langage de description de document (X/HTML) associé à un protocole de requête/réponse sans état (HTTP), web designer, développeurs et architectes techniques ont produit de solides applications issues de composants de base en définitive assez élastiques.
Au gré des innovations successives, des frameworks ont permis d’organiser les développements et surtout d’imposer un paradigme de programmation masquant la rusticité induite par les molécules du web : HTML et HTTP.

En dépit ce cette rusticité, on assiste depuis quelques années à l’apparition d’applications web intégrant des fonctionnalités temps-réel : messageries instantanées, plateformes sociales ou applications financières en sont des exemples emblématiques.
Ce processus à l’œuvre est le fruit d’une lente maturation de diverses techniques en voie de standardisation. Le site de la société Kaazing, sur lequel nous reviendrons, est une expression spectaculaire du Web temps-réel à la portée de tous les navigateurs.

Ce que l’on désigne par Web temps-réel s’inscrit dans une problématique plus vaste, dont le real-time search en est aussi une expression (partenariats Google / Twitter, ou Yahoo! / OneRiot). Sous un angle plus technique, qui est celui de cet article, on parlera plutôt de Web asynchrone.

Du polling à Comet

Les techniques Ajax ont mis un terme définitif au syndrome du click and wait. En revanche, il n’existe pas à ce jour de technique établie visant à mettre en œuvre une communication asynchrone entre navigateurs et serveur. Toutefois, il semble que l’approche Ajax Push (ou Comet) est en train de s’imposer comme un standard de fait.

  • Le polling HTTP consiste à interroger le serveur à intervalle régulier. Simple à mettre en oeuvre, cette technique présente néanmoins plusieurs désavantages. En plus d’être une approximation d’un fonctionnement temps-réel, elle augmente l’overhead induit par le nombre potentiellement élevé de connexions et peut être désastreux en terme d’usage de la bande passante.
  • Dans le cas du streaming, la connexion entre le navigateur et le serveur est maintenue ouverte indéfiniment. Cette technique optimise certes le trafic réseau mais n’est pas fiable et pose un problème de performance évident à mesure que le nombre de clients augmente.
  • Dans le cas du long polling, le client initie une requête comme dans le cas du simple polling. Toutefois, si le serveur n’a aucune mise à jour à notifier, il maintient la connexion pendant une durée significative plutôt que de renvoyer une réponse vide. Le serveur ne renvoie de réponse que si une mise à jour des données est disponible ou en cas de timeout. Le client doit être capable de se reconnecter immédiatement après avoir reçu et traité une réponse.
  • Enfin, Ajax push est une technique combinant Ajax et long polling. Elle est notamment mise en œuvre par les services Google GMail et GTalk. Les frameworks Ajax Push open source APE (Ajax Push Engine) et StreamHub constituent des options intéressantes. Le projet Atmosphere, actuellement en cours de développement, est également à suivre de près.
    Reverse Ajax, Comet et Ajax Push sont 3 termes différents pour désigner la même technique.

A l’occasion des Tech Days 2008/2009, Doris Chen, évangéliste SUN, a donné une présentation très intéressante de Comet intitulée Developing Revolutionary Web Applications using Comet and Ajax.

Le protocole de Bayeux

Initié par la Dojo Foundation, il s’agit d’un protocole de transport de message (asynchrone) sur HTTP, fondé sur un modèle de type publish/subscribe. Les structures de données du protocole utilisent un format JSON. Les implémentations les plus connues sont les projets cometd (soutenu par la Dojo Foundation) et Grizzly (sous-projet Glassfish).
Le protocole de Bayeux constitue à ce jour l’effort de standardisation le plus abouti des techniques du Web asynchrone, à l’exception des initiatives portées par les spécifications HTML 5 que l’on évoquera plus loin.
Pour la petite histoire, le nom du protocole fait référence à la célèbre tapisserie de Bayeux contenant une représentation de la comète de Halley.

Quelle différence avec Comet ?

Le protocole de Bayeux impose un modèle de programmation (publish/subscribe) et définit un format d’échange utilisant JSON entre navigateurs et serveur. Comet n’est qu’une technique de communication asynchrone. Il n’y a pas de modèle de programmation sous-jacent et le format des données transitant entre clients et serveur est discrétionnaire (ce peut être HTML, JSON, XML, texte, etc. en fonction des choix d’implémentation)

Server-sent events et Web Sockets, futurs standards de développement du Web asynchrone ?

A plusieurs reprises, nous avons eu l’occasion de mettre en exergue le potentiel des travaux de spécification HTML 5, dont la masse d’innovations qu’elles fédèrent annonce une vraie révolution dans le développement d’applications web. Deux notions introduites par la spécification ouvrent la voie au développement d’applications web asynchrones : Server-sent events (SSE) et Web Sockets.

Les Server-sent events (SSE)

La spécification SSE formalise la façon dont un flux de données peut être transmise d’un serveur vers un navigateur (le server push). Il s’agit en somme d’une proposition de standardisation des techniques employées par l’approche Comet.

Les données transmises sont des évènements envoyées au client via une connexion HTTP permanente, dont le type Mime associé est application/x-dom-event-stream. Les évènements sont interceptés par le navigateur via un évènement DOM (balise HTML 5 eventsource). Le contenu des messages est très simple comme en atteste l’échantillon ci-dessous représentant les notifications de cours euro/dollar :

  1. event: currency-exchange
  2. data: 1.48

L’exemple ci-dessous illustre la façon dont un navigateur implémenterait l’affichage en temps réel du cours €/$.

Code HTML :

  1. < eventsource xsrc=’http://devises.example.com/euro_dollar’ onchange=’updateCurrEx(event)’ >
  2. <label>Cours :</label> <span id="lab">  </span>

Code Javascript (jQuery) :

  1. function updateCurrEx(evt) {$(‘#lab’).text(evt.data);}

L’API Web Sockets

La spécification des Web Sockets définit un protocole de communication bi-directionnelle entre le navigateur et un serveur hébergeant un ou des middlewares à messages (de type JMS, XMPP, IMAP, etc.).

Voici comment implémenter l’affichage en temps réel du cours euro/dollar via un Web Socket.

  1. var coursEuroDollar_WSock = new WebSocket(”ws://currency.example.com”)
  2. coursEuroDollar_WSock.onmessage = updateCurrEx(event);

Le serveur Web Socket peut être cablé sur un serveur Jabber dont les notifications (messages) contiendraient le cours €/$ en vigueur.

La base installée des navigateurs est loin de supporter les Web Sockets. Toutefois, la société Kaazing a développé une solution open source émulant l’ensemble de la technologie pour une grande variété de navigateurs, solution composée d’une librairie Javascript et d’un serveur Web Socket (Kaazing Enterprise Gateway), une passerelle routant les appels TCP vers les services idoines (serveur Jabber, broker JMS, etc.) comme le décrit le schéma d’architecture ci-dessous.
KaazingIl s’agit d’une technologie de transition respectant l’API Web Sockets, non encore supportée par la plupart des navigateurs. Si vous ne l’avez pas déjà fait, nous vous invitons à consulter leurs démonstrations, ou même à évaluer leur technologie dont le temps d’installation n’excède pas 20 minutes.

La prospective par les livres…

html5_oreilly.jpgpro_html.gifAPress et O’Reilly, deux éditeurs américains à la réputation bien établie, ont annoncé la publication prochaine de deux ouvrages pour le printemps 2010, respectivement Pro HTML 5 programming (qui consacrera plusieurs chapitres aux WebSockets / SSE) et HTML 5, up and running.
Ces publications informatiques sont un indicateur de tendance tangible, corroborant la montée en puissance de HTML 5, comme pour annoncer une ère nouvelle du développement d’applications web.

Abonnez vous !
  • RSS
  • Yahoo
  • Netvibes

Suivez l'auteur sur Twitter !
  • Suivre sur Twitter

A propos de l'auteur

Kadda SAHNINE
Architecte technique Java EE
#JavaEE #Linux #vim addict #OpenSoftware #OpenHardware
Voir le profil de Kadda Sahnine sur LinkedIn

Flux RSS

Rechercher

Administration