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

1. Qu’est ce que Diffusion ?

Diffusion est une solution standalone de diffusion de message éditée par la société PushTechnology, société fondée en 2006 et basée à Londres, spécialisée dans les problématiques de middleware orientés messages et de push web.

PushTechnology propose :

• Un serveur, appelé Diffusion Message Broker, basé sur le protocole TCP
• Une surcouche orientée push web, appelée Diffusion Internet Message Broker, basé sur les protocoles HTTP et WebSocket
• Une API, disponible dans différents langages

1.1. Diffusion Message Broker

Le serveur Message Broker est un serveur orienté message développé en Java, multi-threadé et utilisant le framework NIO (gestion d’I/O non bloquantes) afin de garantir le service auprès d’un grand nombre de clients concurrents.

Citons quelques-unes des key features mises en avant par l’éditeur :

• Hautes performances : jusqu’à 300k messages (de l’ordre de quelques octets) par seconde pour un unique broker déployé sur un serveur de configuration standard et dans un contexte intranet. L’éditeur n’indique pas d’informations supplémentaires sur les conditions de test.
  Il est à noter que ces messages sont au format binaire, permettant ainsi d’adapter leur structure au plus proche des besoins et de transmettre tout type de contenu.
• Très faible latence (de l’ordre de quelques millisecondes) et synchronisation entre les différents brokers au sein d’une architecture distribuée, permettant d’assurer l’intégrité des messages et leur localisation à tout instant.
• Canaux bidirectionnels de transmission des messages : un client peut donc répondre à un message qui lui serait soumis.

1.2. Diffusion Internet Message Broker

L’une des spécificités de la solution Diffusion, celle qui nous intéresse aujourd’hui, est qu’elle offre une surcouche orientée web (et donc sur protocole HTTP). Appelée internet message broker, cette surcouche permet de diffuser des messages via Internet à destination de navigateurs, clients mobiles ou clients lourds connectés. Des tests de performance réalisés par l’éditeur ont montré qu’il était possible de diffuser jusqu’à 90k messages par secondes auprès de tels clients via Internet (conditions de test non précisées).

Plusieurs API sont ainsi mises à disposition afin de connecter ces différents types de clients à un broker Diffusion, parmi lesquelles :

• Navigateur : JavaScript, Flash, Silverlight,
• Client mobile : Android, iOS, Windows Phone, J2ME
• Client lourd : Java, .Net

Les protocoles disponibles sont les suivants :

• Web Socket
• Flash socket
• Silverlight socket
• XmlHttpRequest (HTTP Callback ou IFrame + long polling)
• RTMP (streaming de médias)

L’API JavaScript se différencie des autres API disponibles car elle possède un mécanisme de « fallback » : elle est capable de permuter parmi les 5 protocoles disponibles en fonction de la nature du client et de la connectivité disponible. Ce choix est donc transparent à la fois pour l’utilisateur et pour le développeur.

2. Focus sur Internet Message Broker

Comment fonctionne Diffusion et comment utiliser les différentes API mises à disposition afin d’implémenter rapidement une solution basée sur du web messaging ? Ouvrons un peu plus le capot…

2.1. Architecture

Le schéma ci-après présente le schéma général d’une architecture Diffusion :

On distingue trois couches :

• Les sources de message ou d’événement (en haut du schéma)
• La centralisation, le traitement et la distribution de ces messages (la couche Diffusion Message Broker)
• Les consommateurs de message (la couche Diffusion Clients)

Nous allons détailler ces différentes couches dans ce qui suit.

2.2. Concepts

Dans son implémentation la plus simple, une architecture Diffusion est constituée de Topics, de Publishers et de Clients. Transitent entre ces acteurs des TopicMessages, qui peuvent être routés de manière avancée grâce à différents mécanismes.

2.2.1. Le socle Topic, Publisher, Client

Les Topics sont des fils de messages sur lesquelles il est possible de publier. Ils peuvent être hiérarchisés en sous Topics. Ainsi, un message publié à la racine d’un arbre sera diffusé dans toutes ses branches, autrement dit dans chacun des sous Topics.

Les Topics peuvent être déclarés :

• Par configuration, lors du déploiement d’un serveur Diffusion
• Programmatiquement (dans le code des « Publisher », voir ci-après)

Les Publisher sont garants d’un ou plusieurs Topics mais également des Clients y souscrivant. Ils ont pour rôle de traiter les nouveaux messages et leur diffusion auprès d’un, plusieurs ou la totalité des clients ayant souscrit au Topic. Un Publisher peut être de deux types :

• internal : ils sont alors déployés au sein du serveur Diffusion. C’est la forme de Publisher recommandée.
• external : ils sont alors déployés à l’extérieur d’une instance Diffusion et s’enregistrent auprès des serveurs Diffusion disponibles. Leur utilisation peut être justifiée par des besoins fonctionnelles ou techniques.

Ils ont donc à leur charge la transmission des nouveaux messages vers tout ou partie des clients ayant souscrit au Topic.

Les Clients se connectent sur un serveur Diffusion et s’inscrivent à un ou plusieurs Topics. Ils reçoivent ainsi tous les messages dès lors qu’ils sont publiés sur ces derniers, mais ils peuvent également en publier de nouveaux : la chaine de transmission des messages est bidirectionnelle.

Chaque Client possède sa propre pile de messages au sein d’une instance Diffusion. Cette pile est de type FIFO. Elle est alimentée par les Publishers et continuellement déchargée à destination du Client.

2.2.2. Les TopicMessages

Un TopicMessage est l’implémentation des messages échangés entre les différents acteurs. Il se compose de fixed headers (utilisés par Diffusion pour sa mécanique interne), de user headers et d’un bloc user data (zone libre du message pour l’utilisateur).

Le contenu d’un message est binaire. Diffusion propose une hiérarchisation des données en deux niveaux grâce à des records, des fields et des delimiters. Ces delimiters sont en réalité de simples caractères ASCII, permettant de sérialiser simplement les données.

Il est possible d’utiliser des métadonnées afin de décrire les différents champs composants un message. Ces métadonnées permettent également de faire de la validation et de la transformation des données. Elles ne sont pas transmises avec le message et devront donc être connues à l’avance par les différents lecteurs du message.

Un TopicMessage existe sous deux formes :

• Load message : reçu par le client lors de la souscription à un Topic. Il permet généralement d’initialiser un contexte
• Delta message : utilisé après le LoadMessage, il permet de transmettre toutes les mises à jour du contexte

Il peut également avoir trois états :

• Normal : le message est ajouté sur la pile de chacun des Clients
• Expedited : c’est un message prioritaire, il est ajouté au début de chaque pile (de chaque client) ayant souscrits au Topic. Il est donc le suivant à partir.
• Requiring acknowledegement : ce message requiert un acquittement de la part de son destinataire. Si le message n’a pas été acquitté, il est placé dans une file dédiée et le publisher est alors notifié.

Aux différents acteurs étant en mesure de publier sur un Topic, nous pouvons ajouter l’EventPublisher. Il permet d’implémenter facilement des sources externes d’événements, directement connectées à un ou plusieurs Topics via un Publisher. Il peut s’intégrer à n’importe quel applicatif Java ou .Net grâce aux deux API mises à disposition.

2.2.3. Mécanismes avancés de traitement de files

Diffusion propose une gestion avancée des files de messages, avec entre autre les mécanismes suivants :

• La conflation : correspond aux messages dupliqués ou similaires au sein d’une file. Il ainsi possible de définir des règles de comparaison de message permettant d’éviter ce genre de situation. En plus d’offrir une information plus pertinente aux clients, cette technique permet de réduire le trafic sur le réseau, en évitant l’envoie de messages inutiles car déjà obsolète.
• Le throttling : correspond à la capacité de temporiser (bufferiser) les messages avant leur envoi vers le Client. Cette technique permet de contrôler la bande passante. Il est possible de régler le throttling pour chaque client selon 3 critères :
  • le nombre de message par seconde
  • le nombre d’octet par seconde
  • l’intervalle de temps entre chaque message.

3. Conclusion

L’architecture et les mécanismes de Diffusion ne divergent pas tellement de celle d’un autre Message-Oriented Middleware, et les habitués retrouveront rapidement leurs marques. L’intérêt est ici de pouvoir connecter facilement un grand nombre de clients web, quel qu’en soit leur nature, à des files de messages.

Dans la seconde partie, nous aborderons, autour d’un use-case simple, les bases permettant de mettre en œuvre un navigateur connecté recevant des informations en temps réel depuis un serveur Diffusion.

Suggestion d'articles :

1. Le push web vu par Diffusion – Partie 2
2. Le push web avec Pusher
3. Sécurité des services web – 1ère partie

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).

Le protocole Websocket, HTTP et les proxys

Websocket n’est donc pas une spécification des techniques de push sur HTTP (long polling, HTTP Streaming, …), ni une surcouche à HTTP mais bien un protocole à part entière.
Il reste pourtant lié à HTTP en réutilisant l’architecture réseau de celui-ci. En effet, l’ouverture d’une connexion Websocket s’effectue avec une requête HTTP qui demande au serveur « de mettre à jour la connexion » en connexion Websocket.

GET /demo HTTP/1.1
Host: example.com
Connection: Upgrade
Sec-WebSocket-Key2: 12998 5 Y3 1  .P00
Sec-WebSocket-Protocol: sample
Upgrade: WebSocket
Sec-WebSocket-Key1: 4 @1  46546xW%0l 1 5
Origin: http://example.com

^n:ds[4U

Le serveur, s’il supporte le protocole Websocket, peut ainsi terminer l’ouverture de la connexion et la suite du dialogue entre le client et le serveur s’effectuera avec le protocole Websocket.

HTTP/1.1 101 WebSocket Protocol Handshake
Upgrade: WebSocket
Connection: Upgrade
Sec-WebSocket-Origin: http://example.com
Sec-WebSocket-Location: ws://example.com/demo
Sec-WebSocket-Protocol: sample

8jKS'y:G*Co,Wxa-

Ce type d’ouverture de connexion permet de réutiliser le port HTTP (ou HTTPS) classiquement utilisé et de passer les proxys comme une simple requête HTTP. Cependant, certains proxy n’autorisant pas les connexions longues risquent de poser problème en coupant les connexions Websocket.
Avec la démocratisation du protocole Websocket, on peut cependant espérer que ce type de proxy disparaîtra peu à peu.
L’utilisation de Websocket sécurisé (wss:// dans l’URL au lieu de ws://) permet d’augmenter les chances de passer à travers ces proxys peu coopératifs. En effet, si un proxy est explicitement configuré dans le navigateur, les implémentations actuelles de Websocket utilisent des tunnels via HTTP CONNECT de la même façon que HTTPS. La connexion n’est ainsi plus différentiable d’une connexion HTTPS du point de vue des proxys.

Le support des Websockets

Le support par les navigateurs

Comme pour les autres fonctionnalités qui viennent avec HTML5, les Websockets ne sont pas supportées par tous les navigateurs :

• Chrome les supporte depuis sa version 4.0.429
• Safari depuis la version 5.0

Quant aux autres navigateurs, ils ne les supportent tout simplement pas encore.

Pour pallier à ce manque temporaire, deux approches ont été implémentées :

• un wrapper Javascript client qui bascule sur une implémentation Flash (qui est capable d’ouvrir des sockets TCP). Cette solution permet de garder tous les avantages des Websockets mais ajoute une dépendance vers le Player Flash,
• un wrapper Javascript client qui bascule sur du long polling ou HTTP Streaming. Cette fois-ci, plus de dépendance vers le Player Flash mais on revient vers une émulation du push avec HTTP.

Le support côté serveur

Côté serveur, il faut distinguer deux types de composants (dans le monde Java) :

• les implémentations du protocole Websocket comme Netty, Grizzly, Jetty 7 (l’article de Xavier montre comment utiliser les Websockets avec Jetty 7), JWebSocket (et son implémentation TCP), Kaazing, … Ces implémentations proposent une API plus (Jetty) ou moins (Kaazing) bas niveau pour exploiter les fonctionnalités du push serveur.
• les frameworks qui proposent une API de plus haut niveau et qui s’appuient sur les implémentations précédentes. On retrouve ainsi Atmoshpere, Cometd (en version 2) ou encore JWebSocket. Ces frameworks proposent donc une API indépendante de l’implémentation WebSocket sous-jacente (d’ailleurs, Atmosphere était avant tout une implémentation de Comet).

Cette distinction ne veut cependant pas dire que les frameworks implémentant le protocole Websocket sont forcément de plus bas niveau que Atmosphere ou JWebSocket. Par exemple, Kaazing propose des fonctionnalités et une API d’au moins aussi haut niveau que celle de JWebSocket.

Pourquoi (pas) les Websockets ?

Au-dela de pouvoir pousser des données du serveur vers le client, encore faut-il pouvoir l’exploiter sans passer son temps dans la plomberie. C’est bien de pouvoir réagir à une connexion, un message, une déconnexion, … mais il faut gérer les clients connectés, les timeouts des connexions (le client ne connait pas le timeout après lequel le serveur coupe la connexion), savoir quels messages renvoyer lorsqu’une coupure de connexion survient et autres limitations du fait de la jeunesse du protocole Websocket.

Là encore les frameworks comme Kaazing, JWebsocket ou Cometd sont bien utiles pour s’occuper de ces problématiques bas niveau mais aussi pour proposer des fonctionnalités utilisant tout le potentiel des Websockets.

Parmi celles-ci, on peut trouver :

• du publish subscribe
• du RPC (Remote Procedure Call) et RRPC (Reverse Remote Procedure Call) pour que le serveur puisse appeler des services du client
• des passerelles vers des protocoles connectés comme JMS, JDBC, Jabber, IMAP, …
• bus événementiel

Enfin, il est légitime de se dire que toutes ces fonctionnalités sont envisageables avec des techniques comme Comet sur HTTP. Alors pourquoi préférer les Websockets alors que leur support par les navigateurs est encore limité et que les proxys risquent de ne pas toujours jouer le jeu ?

Tout d’abord, lorsqu’on utilise du polling ou tout autre technique sur HTTP, on utilise forcément une connexion dédiée pour recevoir des données poussées du serveur vers le client et une autre connexion pour envoyer des données depuis le client (via une requête HTTP classique). Une connexion Websocket, quant à elle, est full duplex. C’est à dire que la même connexion est utilisée pour recevoir et envoyer des données. Le serveur gère donc moins de connexions ouvertes et moins d’ouvertures et fermetures de connexions ponctuelles. Il faut cependant souligner que les implémentations serveur doivent être adaptées à la gestion d’un grand nombre de connexions simultanées et continues (utilisation d’un pool de threads plutôt qu’un thread par socket ouverte, entrées-sorties non bloquantes, notifications par l’OS de l’activité des sockets, …), que ce soit en utilisant Comet ou les Websockets.

Ensuite, en terme de bande passante, la taille du message minimum du protocole WebSocket est de 2 octets (0×00 pour le début du message et 0xFF pour la fin). Avec HTTP, il faut compter au moins 200 octets pour un header. Quand il s’agit d’envoyer des messages de maintient de connexions (ou de réouverture de connexion avec Comet), avec un nombre important de clients connectés, l’occupation de la bande passante avec Comet devient non négligeable.

Conclusion

Le protocole Websocket est donc un moyen de répondre au besoin de push de données depuis le serveur qui était jusque-là implémenté en détournant HTTP de son usage prévu initialement. Il permet ainsi d’optimiser l’usage des resources côté serveur et de faire le pont entre une architecture web (ie. centrée autour de HTTP et des navigateurs Internet) et les autres protocoles connectés (JMS, IMAP, Jabber, …) ouvrant ainsi la porte au web « temp réel ».

Suggestion d'articles :

1. Jetty & HTML 5: les WebSockets sont là !
2. Des téléphones mobiles connectés à internet. Pourquoi faire ?
3. Dynamocracy : pourquoi ?

-  » 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 ;-)

Le besoin est réel et tend à se démocratiser sur le web : informer l’utilisateur de la modification d’information au niveau du serveur, en (quasi) temps réel. Les cas d’utilisations sont tout autant réels. Les exemples classiques sont Gmail et Gtalk. L’iphone 3G en a fait un argument publicitaire. Des applications d’alarming ou de monitoring en web peuvent en avoir l’utilité, les plateformes de  » e-trading  » ou certaines applications de call-center également.

Il existe 3 solutions pour  » remonter  » de l’information au client

Le poll. Dans ce cas, la remontée d’information du serveur vers le client est simulée. En effet, dans le cas du poll ou pull, le client exécute une requête vers son serveur à intervalle de temps régulier, espérant ainsi être mis au courant d’une mise à jour. Cette approche montre les limitations suivantes :  Certains évènements peuvent être manqués si l’intervalle entre deux requêtes est trop long A l’inverse, il est tout à fait possible de réaliser un appel  » à vide  » si aucun évènement n’est disponible Un intervalle de temps trop court entre deux requêtes aura tendance à (sur)charger le serveur
Le Streaming http. A l’exact opposé du poll, le streaming http repose sur l’utilisation de connexion http persistantes, ie. qui ne sont jamais relâchés. Les informations de réponse sont écrites au fur et à mesure de leurs arrivées. Très usitée par les applications multimedia (vidéo, audio…), la mise en oeuvre de cette solution demande néanmoins une infrastructure adaptée aux connexions permanentes et il n’est pas évident que tous les proxys (en entreprise surtout) l’accepte.
Le Reverse Ajax ou Comet. A mi chemin entre les précédentes solutions, les termes  » Comet  » et son synonyme  » Reverse Ajax  » ont été introduit Alex Russel et Joe Walker et décrivent un mode de fonctionnement où le serveur  » remonte  » de l’information au client sans que ce dernier ne l’ait expressément demandée. Ce mode de fonctionnement est en fait basé sur le principe du poll sauf que la requête http peut rester en attente, d’un évènement ou du timeout, auquel cas, cette dernière se  » clôt  » classiquement. Ce mécanisme de long-polling repose – et cela de manière à assurer la scalabilité – sur le découplage des notions de requêtes http et des notions de Threads : il faut être capable de mettre en attente certains clients http, tout en exécutant des services – donc des threads – sans pour autant avoir autant de threads que de clients http potentiels…bref, vu d’avion ca n’a déjà pas l’air simple…

L’élément différentiant entre ces solutions reste la fréquence de mise à jour de la donnée et l’importance qu’à la fraîcheur de cette donnée pour le client.

Comet ou le « long polling »

In web development, Comet is a neologism to describe a web application model in which a long-held HTTP request allows a web server to push data to a browser, without the browser explicitly requesting it

Source: wikipedia

Contrairement à ce que peut laisser penser la première partie, cette problématique de  » long-polling  » impacte à la fois le client et le serveur :

• Le client car il faut gérer l’ouverture et surtout la réouverture des connexions http – lors de la fermeture normale ou du timeout -.
• Le serveur car il faut gérer ces histoires de long polling et de découplage requête/thread sans avoir à trop mettre les mains dans le cambouis…

Il existe aujourd’hui plusieurs solutions open source implémentant les concepts de Comet. La plupart de ces solutions adressent  » uniquement  » – en même temps c’est déjà beaucoup… – la partie serveur, et ce de manière plus ou moins light en terme d’APIs proposées :

• Tomcat 6 propose les NIO – advanced IO. Côté code, Tomcat propose uniquement une interface CometProcessor que devra implémenter votre servlet. A vous de jouer avec les threads pour écrire les messages sur les HttpServletResponse souhaitées. La configuration de ces Advanced IO, sans être insurmontable n’est pas immédiate : il est nécessaire de modifier la configuration du connecteur http au niveau du fichier server.xml et de rajouter une dll dans la variable java.library.path
• Jetty 6 propose une API un peu plus haut niveau que celle de Tomcat. Jetty introduit ainsi le concept de continuations, un objet appelable depuis une servlet et qui permet de suspendre la requête http en cours et de libérer le thread courant.
• DOJO et le protocole de Bayeux. DOJO est l’initiateur du protocole de Bayeux – j’avoue ne pas avoir trouver de relation avec la ville de Bayeux et ces tapisseries, en même temps il n’y a certainement aucune relation…Bref, Dojo propose une API cliente JavaScript permettant d’interagir avec un serveur implémentant ce fameux protocole de Bayeux. Glassfish – via Grizzly – étant un des serveurs implémentant ce protocole, il est tout à fait possible d’imaginer un client utilisant DOJO et s’interfaçant avec Glassfish.
• Grizzly/Glassfish. Glassfish dans sa version 3 embarque le moteur http Grizzly et propose une solution  » out of the box « . Ce moteur propose un support de comet soit via
  • Une implémentation du protocole de Bayeux.
  • Une API masquant les mécanismes  » Asynchronous Request Processing  » disponible dans Grizzly.La mise en oeuvre de comet dans glassfish est simplissime et consiste à modifier le fichier domain.xml.

Certaines solutions de développement – a contrario des solutions portées par le serveur d’application ou le conteneur de servlet présentés précédemment – intègrent cette problématique :

• Côté GWT, on peut noter l’initiative Rocket/GWT qui encapsule ces problématiques dans des APIs java client et serveur
• Côté Flex, Adobe BlazeDS (et son équivalent payant) propose des mécanismes de  » push serveur « . Le principe réside dans la définition de  » channel  » auxquels s’abonnent et publient les clients
• Côté JSF, IceFaces annonce une solution de  » push server  » alors que jBoss RichFaces ne fournit que le poll

Le protocole de Bayeux : une tentative de standardisation des échanges type  » push « 

Le protocole de Bayeux, poussé par DOJO, vise une normalisation permettant de délivrer des évènements, au format JSON, entre des clients et un serveur, des clients et des clients (via le serveur..), sur la base du modèle publish/subscribe.

Ce protocole repose  » principalement  » sur :

• La notion de  » channel « , une destination déterminée par un nom logique (ou plus exactement une uri) sur laquelle seront poussés des messages, eux-mêmes consommés par les clients ayant souscris à ce channel. Formuler autrement, ce  » channel  » peut être vu comme le sujet de conversation que les clients vont partager. Ce protocole définit de plus des  » channels  » techniques pour gérer l’abonnement et le désabonnement des clients…
• Les messages encodés en JSON et proposant quelques propriétés intéressantes comme le channel, un identifiant unique du client…

Ainsi dans ce protocole, un exemple de message est :

1
2
3

/*[{"channel":"/cometd/myChannel","successful":true,"clientId":"2d714396f339f90d","id":"6"},
{"channel":"/cometd/myChannel","data":{"test":"one 
message"},"id":"6","clientId":"2d714396f339f90d"}]*/

Ce protocole ne définit pas d’API cliente ou serveur mais décrit seulement les mécanismes d’échanges entre serveur et clients dans le cadre d’échange de type  » push « .

Mise en oeuvre…

…avec les APIs Grizzly/glassfish

Loin de moi l’envie de vous refaire un tutorial complet sur Grizzly. Reste que ces APIs sont assez simples et proposent les principaux concepts suivants :

• CometEngine. C’est par la que tout commence et ce moteur permet de gérer des CometContext
• CometContext. Cet objet CometContext est associé à une URL – en fait l’url où seront faits les GET et les POST… – et gère un ensemble de CometHandler
• CometHandler. On peut voir cet objet comme un  » client « . Une nouvelle instance du CometHandler est associé au context lors de la méthode doGet() de votre servlet et tout ou partie de ces handlers sont notifiés sur le doPost()…

En terme de code, les APIs sont utilisées dans une servlet comme suit :

• Le CometContext est initialisé dans le méthode init() de votre servlet

1
2
3

public void init(ServletConfig config) throws ServletException {... 
CometEngine engine = CometEngine.getEngine(); 
CometContext cometContext = engine.register(contextPath);

• Un nouvel handler est instancié dans la méthode doGet(), donc pour chaque requête, et associé au CometContext. Chaque requête est ainsi mise en attente (regardez avec FireBugs ;-) )

1
2
3
4
5
6

protected void doGet(HttpServletRequest req, HttpServletResponse resp)   throws ServletException, IOException { 
    SampleCometHandler handler = new SampleCometHandler(); 
    handler.attach(resp); 
    CometContext context = CometEngine.getEngine().getCometContext(contextPath);   
    context.addCometHandler(handler); 
}

• Lors d’un POST, le paramètre company est récupérer de la requête, l’ensemble des handlers associés au CometContext est notifié. A noter qu’il est possible dans ce cas de ne notifier qu’un seul handler (et donc un seul client)

1
2
3
4
5

protected void doPost(HttpServletRequest req, HttpServletResponse resp)  throws ServletException, IOException { 
    CometEngine engine = CometEngine.getEngine(); 
    CometContext context = engine.getCometContext(contextPath);
    context.notify(req.getParameter("company"));  
...

• L’implémentation du handler peut se faire de la manière suivante. Lors de la notification, chaque handler écrit le CometEvent (ie. le message) sur la HttpServeltResponse qui lui est associée.

1
2
3
4
5
6
7
8
9
10
11

private class SampleCometHandler implements   CometHandler {
 
  public void onEvent(com.sun.grizzly.comet.CometEvent event)    throws IOException {   
    if (event.getType() != CometEvent.NOTIFY) {    
    // le client a fait le post    
    this.response.getWriter().write("message: " + event.attachment()); 
    this.response.getWriter().flush();
    // supprimer cette ligne pour faire du streaming
    event.getCometContext().resumeCometHandler(this);
}
}

Reste maintenant à implémenter un  » petit  » client, simplement en JavaScript et de la manière suivante :

• Une requête client réalise un GET et attend

1
2
3
4
5
6
7
8

function doGet(){
  new Ajax.Request('/CometSample/CometSampleServlet', {
   method:'get',
   onSuccess: function(transport){
     $('result').update(transport.responseText);
    }
  });
 }

• Un autre client poste son message

1
2
3
4
5
6
7

function doPost(){
  new Ajax.Request('/CometSample/CometSampleServlet', {
  method:'post',
   parameters: {company:'octo' },
  onSuccess: function(transport){...}
 });
}

…de l’implémentation Grizzly du protocole de bayeux

Grizzly fournit une implémentation du protocole de Bayeux via une servlet  » générique  » qu’il est simplement nécessaire de configurer au niveau du fichier web.xml

1
2
3
4
5
6
7
8
9
10
11
12
13

 
<servlet>
        </servlet><servlet -name>Grizzly Cometd Servlet</servlet>
        <servlet -class>com.sun.grizzly.cometd.servlet.CometdServlet</servlet>
        <init -param>
            <param -name>expirationDelay</param>
            <param -value>60000</param>
        </init>
        <load -on-startup>1</load>
 
    <servlet -mapping>
        </servlet><servlet -name>Grizzly Cometd Servlet</servlet>
        <url -pattern>/cometd/*</url>

Côté client, le framework DOJO fournit une extension JavaScript permettant de s’abonner à un channel et de publier des messages.

• Concernant la souscription

1
2
3
4
5
6
7
8
9
10
11
12
13

 
<script type="text/javascript">
    	dojo.require("dojox.cometd");
    	dojox.cometd.init("http://localhost:8080/CometSample/cometd" );
    	dojox.cometd.subscribe("/cometd/myChannel", function(msg)
    	{
    		$('result').update('message received : ' + msg.data.test);
    	});
</script>
 
<ul>
	<li>Concernant la publication</li>
</ul>

1
2

var data = $F('text2Send');
dojox.cometd.publish('/cometd/myChannel',{test: data });

Les limitations de Comet

La principale limitation à la mise en oeuvre de Comet vient en fait des browsers.
Ces derniers ne permettent en général de n’ouvrir que deux connexions http par domaine. En fait, c’est même conseillé dans la norme HTTP/1.1. Cet article de 2006 donne pas mal de détail sur cette limitation.
J’ai pu tester cette limitation (sur Firefox 3.0.1) sur mes exemples : lorsque deux de mes browsers ouvraient des connexions de type GET sur le domaine localhost :8080, la seconde connexion GET était systématiquement mise en attente…en remplaçant simplement localhost par mon IP (et donc en changeant de domaine), le problème se résout.
Au-delà de l’anecdote, cette limite de deux connexions pose un problème avec le long-polling qui monopolise une des deux connections mais il y a fort à parier que les constructeurs vont résoudre le problème, IE8 devrait déjà porter le nombre de connections à 8…

Pour conclure…

L’API Grizzly me parait très naturelle à utiliser et masque vraiment les problématiques de manipulation de thread ; elle gagnerait à fournir une petite librairie JavaScript permettant d’automatiser l’ouverture de la connexion ainsi que la reprise en cas de timeout… On peut de plus regretter la forte imbrication Grizzly/Glassfish : il semble délicat – pour avoir essayé, rapidement certes… – d’imaginer utiliser le moteur http Grizzly dans Tomcat…
A l’inverse, DOJO fournit un client JavaScript bien pensé – au travers de son extension dojox.cometd – et l’implémentation du protocole de Bayeux par Grizzly a cela de génial qu’elle ne demande – pour les cas nominaux d’utilisation – pas de développement supplémentaire : juste la configuration d’une servlet.
Reste que ces solutions sont encore artisanales – au sens étymologique, donc positif. Les APIs aussi bien côté serveur que client ne sont pas encore définies mais il faut noter que les mécanismes de  » push server  » seront standardisés dans la version 3.0 de Servlet – donc les containeurs de servlet JEE6 -.
Reste enfin que les cas d’application dans l’informatique d’entreprise ne sont pas forcément des plus répandus et aujourd’hui plutôt implémentés par des solutions RDA, mais demain qui sait ? ;-)

Suggestion d'articles :

1. Et après RIA?
2. 5 minutes pour : Monter en complexité, Approche TDD / Tests en PHP, PHP & Ajax
3. Pourquoi les Websockets ?