Le push web vu par Diffusion – Partie 1

Les problématiques de push de messages vers des clients connectés (encore appelé « web messaging ») sont courantes dans les secteurs où l’information varie sur des temps très court, comme la finance, la sureté, la supervision ou encore les réseaux sociaux. Les données doivent être diffusées le plus rapidement possible à de nombreux clients, car ces données n’ont de valeur (ou d’intérêt) que pendant un temps limité.

Pour faire du web messaging, il existe aujourd’hui différentes techniques (polling, « comet » long polling et streaming) qui s’appuient sur des technologies variées (XmlHttpRequest, WebSocket, Flash socket, Silverlight socket, iFrame, RTMP). Le marché évolue d’ailleurs clairement dans ce sens : des solutions, jusqu’à présent concentrées sur la problématique Message-Oriented Middleware (RabbitMQ, HornetQ) offrent désormais une API HTTP, avec pour certaines d’entre elles, une API cliente basée sur WebSocket (même si cette technologie n’est pas encore compatible avec tous les navigateurs).

Nous allons ici parler d’une de ces solutions, permettant à la fois d’assurer une grande compatibilité et de hautes performances : Diffusion. Cet article a pour objet de présenter cette solution. Il se découpera en deux parties :

  • Une présentation des concepts et du framework Diffusion
  • Une présentation plus technique via la mise en œuvre d’un POC

(Lire la suite…)

Pourquoi les Websockets ?

Après la démocratisation d’Ajax (ie. requêtes HTTP asynchrones en Javascript), plusieurs techniques ont été élaborées afin de permettre le push de données depuis le serveur toujours en utilisant HTTP. C’est grâce à ces techniques que l’on reçoit nos mails dans une application web sans avoir à cliquer sur le bouton « Refresh », que les applications de chat sont possibles sans plugin tierce (Flash, Java, …), etc. Le W3C et l’IETF ont spécifié une API Javascript et un protocole nommé Websocket. Ce protocole connecté est adapté à l’envoi de données dans les deux sens et évite de détourner HTTP de son usage initial (ie. un protocole déconnecté sans état).
(Lire la suite…)

Après Ajax, le « Reverse Ajax »…et le Grizzly !

-  » Encore plus fort ! ce n’est plus ton browser qui demande de l’information. C’est ton serveur qui lui remonte, lui push de l’information et le tout en technologie web !  »
-  » oulà, oulà…tu ne serai pas en train de me prendre pour un gars sorti de sa campagne toi ?! « 

En fait, si un peu mais pas tant que ca non plus ;-)

(Lire la suite…)