Jeudi s’est tenu dans les locaux d’ADEO une session du Ch’ti Jug sur HTML5 et tout particulièrement les WebSockets: Kaazing HTML5 WebSocket Talk at the Ch’ti JUG Meeting in Lille, France

Pour ceux qui ne savent pas ce qu’est le Ch’ti Jug ou ce qu’est un Jug, voir l’introduction de mon article sur la session précédente:  Ch’ti Jug: les technologies Google

Une petite phrase de notre hôte, le groupe ADEO, qui rassemble entre autre les enseigne Leroy Merlin et Weldom. C’est donc ce qu’on appel dans le jargon des SSII un « client final », et c’est la premièer fois qu’une session du JUG se tient chez un client final. Le responsable des developpement de chez ADEO qui nous a reçu (je ne me rappel plus de son nom ni de sa fonction exacte) nous as expliquer la démarche très simple et que beaucoup d’autre client finaux (ou DSI) devrait mettre en place. Il fait en sorte que ses équipes de développement s’organisent en communauté pour partager leur savoir et progresser ensemble. Et c’est dans cette optique qu’il trouve tout naturel de supporter les communautés extérieures qui permettent à ses équipes de prolonger en dehors du bureau leur esprit de communauté et de continuer à grandir dans leur travail (là je trouve que je l’ai presque aussi bien dit que lui:) ).

Bon, après cette longue digression, venons en a la présentation elle même. Elle été assuré par Peter Lubbers de chez Kaazing, qui été de passage à Paris pour une formation et as accepté de venir faire un tour dans le nord avant de repartir dans la Silicon Valley. Et ce qu’on peut dire c’est que la présentation été de grande qualité, digne des grandes conférences payantes de la communauté Java.

Pour commencer, Peter nous as exposé le problème, à grand renfort d’exemple et de démo: aujourd’hui de plus en plus d’applications web riche (RIA, Rich Web Application) nécessitent une communication temps réelle (ou quasi temps réelle). Les protocoles web existants ne sont pas capable de faire ça, ils sont basé sur HTTP qui ne permet qu’une communication half-duplexe (soit montante: une request, soit descendante: une response, mais pas les deux en même temps).
Il existe donc différents patterns de développement pour la mise en place de solution pour que les RIA puisse s’approcher le plus possible d’une communication temps réelle. Je ne vais pas vous les présenter tous en détail mais il sont basé sur ce qu’on appel le polling (normal ou long polling) et ils souffrent tous de trois choses:

1. Limitation d’une communication half-duplex: une request est obligatoire avant toute response, le serveur ne peut pas envoyer de données sans qu’une request ai été initié au préalable.
2. La communication temps réelle nécessite des mise à jours constante qui nécessite de nombreuses request/response en un laps de temps très court. Le protocole HTTP comprend des en-tête qui dans ce cas d’utilisation particulier peuvent être importante. La taille d’une en-tête HTTP standard étant de 500 à 2000 octets, dans le cas d’un polling vers 10 000 clients toutes les secondes basé sur une taille d’en-tête de 1K on a 200Ko/s (10 000 * 1Ko * 2, une entête pour la request et une pour la response) de bande passante prise uniquement pour les en-tête. Et si on calcul pour 100000 client avec un polling de 200ms (plus cohérent pour donner une impression de temps réel) ça nous donne 10Mo/s de bande passante uniquement pour les entêtes!
3. Le browser ne pouvant accéder qu’a un serveur HTTP, on a nécessité de déployer un serveur d’application ou autre composant complexe pour réaliser ce polling.

Et voila la solution, les WebSockets. Ils permettent de se passer de tout ces problèmes, en voici le mécanisme, dans une explication simplifié:

1. Le browser demande un upgrade de la connexion HTTP en web socket.
2. Le serveur accèpte, la connexion HTTP devient un WebSocket vers le serveur: c’est un nouveau protocole directement au dessus de TCP.
3. La communication s’effectue alors en full-duplexe: request et response sont maintenant indépendante et peuvent être émise en même temps. Ce qui ouvre la possibilité d’une réel push data vers le serveur.
4. Les headers d’une request/response WebSocket sont minimum: 1 octet de début et un octet de fin! La bande passante ne sert donc uniquement qu’aux données!

On peut même imaginer faire directement communiquer un serveur de type JMS, Jabber ou autre directement avec un WebSocket sans passer par HTTP.

De plus, l’établissement d’une websocket est très facile, via JavaScript on fait juste initialise juste un objet websocket en lui passant l’URL (de type ws://hote:port/uri, websocket étant un réel protocole il a son propre addressage) et la méthode javascript à appeler en callback lors de la réception de la requête: WebSocket étant asynchrone.

Les possibilité sont grande pour tout ce qui nécessite des connexion de type temps réelle.

Peter Lubbers nous as ensuite présenté quelques autres nouveautés d’HTML5 accès sur la communications telle que:

• L’XmtlHttpRequest Level 2: XmlHttpRequest cross domaine (avec mécanisme de sécurisation)
• La communication cross domaine entre iframe (avec mécanisme de sécurisation)
• Les PostEvents
• Et bien d’autres choses …

Tout ça est bien beau, mais pour l’instant, seul les nighly builds de chrome (projet chromium) supportent ces nouveautés (et normalement la future version de Firefox, la 3.6, les supportera). En attendant: Kaazing a une solution:
Kaazing a créer une framework qui permet d’utiliser ces nouveauté, et si le browser ne le supportent pas nativement il va les émuler en utilisant soit un plugin du browser (flash, ActiveX, …) soit du JavaScript au mieux de ce que supporte le browser.
En plus, la société propose une passerelle qui permet d’accéder directement à une multitude de protocoles directement depuis des websocket sans passer par un serveur applicatif, en gros il permet de faire passerelle entre le protocole websocket et des protocoles telle que JMS ou Jabber. Allez sur le site de Kaazing si vous cherchez à en savoir plus.

Voila une conférences très complète sur le sujet et de grande qualité. Merci Peter et merci le Ch’ti Jug!