Nouvelle version de APE (Ajax Push Engine)

Posté par (page perso) . Modéré par Christophe Guilloux.
Tags :
11
8
déc.
2009
Technologie
APE est une solution COMET complète (système permettant à une application web de rester à l'écoute du serveur pour recevoir des données quand celles-ci sont disponibles) pour le développement d'applications web en temps réel.

Dans le modèle actuel, entreprises et développeurs sont confrontés à un problème de plus en plus répandu lors du développement de leurs applications web. Lorsque le besoin d'interconnexion des flux et des utilisateurs se présente, aucune solution viable nʼest disponible, en terme de réactivité, de fiabilité et de charge serveur. La notion de temps réel sur le web est difficilement réalisable compte tenu des nombreuses contraintes techniques actuelles.

Les solutions techniques disponibles présentent des lacunes importantes. En effet, la contrainte obligatoire veut que le "client" soit aveugle face aux agissements du serveur. Pour être averti des nouvelles informations disponibles, le navigateur web doit forcément être lʼinstigateur de la demande dʼinformations, en effectuant des requêtes au serveur de manière périodique. Ainsi le serveur web doit faire face aux demandes incessantes des utilisateurs, et la disponibilité dʼune information devient vite coûteuse.

Avec APE, la société Weelya a inversé la situation, en proposant un modèle technique novateur respectueux des standards web (sans addition client), qui permet au serveur dʼenvoyer les informations à tous les utilisateurs dès quʼelles sont disponibles. Ainsi, ceux-ci ne sont plus aveugles aux agissements du serveur, et peuvent attendre que les informations leur soient envoyées en temps réel.

NdM : le client est publié sous licence LGPL, et le serveur sous licence GPL. Voir également le serveur cometD (serveur HTTP libre de la fondation Dojo, la version 1.0 étant sortie il y a quelques jours) et le protocole BOSH (utilisé notamment pour Jabber, implémenté dans Gajim 0.13 par exemple). APE pour Ajax Push Engine

Réactivité : APE résout le problème de réactivité réelle pour nʼimporte quelle application web. Lʼinformation est relayée en moins de 100 millisecondes, contrairement au modèle classique où les requêtes des utilisateurs sont périodiques, et souvent sous une fréquence élevée (à la seconde, à la minute...).

Réduction des charges serveur : APE réduit considérablement les charges supportés par le serveur, puisque celui-ci nʼa plus à gérer les requêtes utilisateur incessantes, demandant de nouvelles informations.

Passage à l'échelle : APE peut supporter jusqu'à 100 000 utilisateurs par nœud.

Un serveur mais aussi un client : Contrairement à la plupart des solutions COMET, APE propose également une partie client, avec la mise à disposition dʼune bibliothèque JavaScript libre complète, permettant de gérer simplement toute la communication avec le serveur, afin de recevoir, envoyer, traiter et afficher les données. Concentrez votre développement seulement sur lʼéchange dʼinformations, sans vous soucier des problèmes techniques.

Extensible : Le serveur APE est construit autour dʼune architecture modulaire, permettant dʼajouter facilement de nouvelles fonctionnalités quant au traitement des données reçues et envoyés. Ceci largement facilité par l'implémentation du JavaScript côté serveur, donnant la possibilité aux développeurs dʼutiliser le même langage côté client et serveur.


Nouvelles fonctionnalités de APE 1.0 :
  • Nouveau protocole :
    • Entièrement en JSON et facilement extensible
    • Possibilité dʼenvoyer plusieurs commandes en une requête.

  • Nouvelles méthodes de transport :
    • XHRStreaming : Une seule connexion utilisée pour recevoir les données en continu. Meilleures performances, et latence réduite.
    • JSONP : Permet de réaliser des requêtes « cross-domain ».

  • Support BSD & Mac OS X. (avec lʼutilisation de KQueue)
  • ServerSide JavaScript (SSJS) implémenté avec lʼutilisation de TraceMonkey (Mozilla
    SpiderMonkey)
  • Support de Mootools côté serveur.
  • API server-side JavaScript complète :
    • Gestion des utilisateurs, RAWs, Commands, Channels, Sockets
    • Utilisation de sockets non bloquants (Client et Serveur)
    • Connecteur MySQL
    • API pour requêtes HTTP
    • WebHooks

  • Journaux dʼerreurs, dʼaccès et dʼinformations
  • # Big Brother is watching you

    Posté par (page perso) . Évalué à 3.

    Google propose grosso modo la meme fonctionnalité avec leur proposition de protocole SPDY mais ils en rajoutent pas mal d'autres en plus.
    SPDY me semble aller un peu plus loin quand meme mais il est plus en rupture avec l'existant que APE et semble bien moins "production ready".

    Tout ca est interessant et je ne serais pas etonné que notre bon vieux HTTP va evoluer prochainement (il serait temps !) car quand des remplacants commencent a pointer le bout de leur nez, il est temps de bouger...
    • [^] # Re: Big Brother is watching you

      Posté par (page perso) . Évalué à 6.

      Je n'ose même imaginé le temps que prendrais un nouvelle version de HTTP (ou un remplaçant) pour se répandre (sans parler de s'imposer tout cours). Quand on voit que IE6 est encore courant, et que pour un nouveau protocole ou une nouvelle version il faudrait que les éditeurs de navigateurs commencent par l'implémenter...

      Bref, je ne tablerai pas sur l'utilisabilité d'une évolution de HTTP avant au moins 5ans si elle été publié demain et en supposant qu'un mode de rétro-compatibilité soit présent.

      Mais je suis un vieux con aigri et pessimiste :'(
      • [^] # Re: Big Brother is watching you

        Posté par (page perso) . Évalué à 3.

        Ouais bien sur...

        Mais bon, 5 ans de gestation pour un protocole qui vivra au moins 30 ou 40 ans a l'echelle planetaire, on peut pas dire que ce soit un "investissement" deraisonnable.

        En informatique, on a trop l'habitude de voir debarquer des trucs en 3 mois alors forcement quand on parle de remplacer un protocole ou un format aussi repandus qu'HTTP ou l'HTML 4, forcement, faut pas s'attendre a ce que ca deboule dans l'annee qui vient...
  • # Apparté...

    Posté par . Évalué à 6.

    Viens de sortir, après 10 ans de travaux, la nouvelle version de ECMA Script ( javascript en version 5, donc)

    http://developers.slashdot.org/story/09/12/08/1416202/ECMASc(...)
  • # CometD

    Posté par . Évalué à 4.

    Pour ce qui est de CometD, le logiciel sorti par la fondation Dojo n'est pas un serveur HTTP, mais va s'appuyer généralement sur un serveur HTTP existant.

    Je ne vais pas m'avancer sur le code perl ou python, mais le code Java s'appuie clairement sur un serveur Java classique. Et même, il me semble qu'il ne fonctionne que sur un Jetty (ce qui se comprend vu que ce sont les dev de Jetty qui ont travaillé sur cette version).

    Vivement une implémentation node.js ;-)
  • # HandBaller

    Posté par (page perso) . Évalué à 5.

    Ca a l'air vraiment génial...

    < autopromo humilité="aucune" >

    Et parce que la variété c'est bien, voici un autre projet dédié à l'auto-hébergé et à l'embarqué:

    "HandBaller" est un bus HTTP minimaliste codé en C, une sorte d'APE en beaucoup plus simple.

    Ami bidouilleur, HandBaller sera tout juste suffisant pour pousser dans votre application web des messages envoyés par des scripts shell ou autres programmes résidents sur votre serveur.

    "Out of the box", HandBaller peut relayer des messages entre deux instances d'une applications web, comme un routeur de JSON. Parfait pour auto-héberger un système de tchat.

    HandBaller a d'abord été pensé pour brancher du web (disons un portail dans un navigateur en mode kiosque) avec des sources d'évènements de la machine hôte, du LAN et d'aileurs. Par exemple, si vous faites tourner un gestionnaire de scoubidou sur votre machine et que vous développer un vue-mêtre de scoubidou à afficher dans un navigateur (genre un gadget iGoogle).

    * http://code.google.com/p/handballer/ : les sources et la démo
    * http://tinyurl.com/yzp9smr : la doc de quelques pages

    < /autopromo >

    Je me la joue, mais si quelqu'un veut m'aider à mettre une hashtable par ci par là, ou à porter ma démo sous IE, ou à déboguer ce fichu mode Push/Multipart avec les balises image, heu... ben... je... serais très content.
    • [^] # Re: HandBaller

      Posté par . Évalué à 3.

      Dans le même acabit, msgbus fournit des fonctionnalités équivalentes: MoM basé sur du HTTP. Il est basé sur libevent pour le multiplexing d'I/O et la couche HTTP.

      cf [http://code.google.com/p/msgbus/].

      Je suis partant pour te filer un coup de main :D
      • [^] # Re: HandBaller

        Posté par (page perso) . Évalué à 3.

        Félicitations! te voilà immédiatement promu "project owner" de HandBaller. C'étais pas dur de trouver ton profil.

        "msgbus" a été ma première source d'inspiration (cf. credits sur la page projet). Mais j'avais alors besoin d'une solution fiable qui marche tout de suite pour ce sur quoi je travaillais. C'était il y a 3 ans et msgbus était encore en développement.

        C'est alors que thttpd s'est rappelé à mes bons souvenirs. On le trouvait dans plein de distrib Linux embarqué et c'est lui qui faisait tourner le site des pages perso de mon FAI de l'époque.

        J'avais déja jeté un coup d'oeil au code avant. Alors voila, ca m'a pris quoi... 1 jour, pour trouver où et quoi patcher pour transformer thttpd en un bus à messages.

        Ca m'a pris un peu plus longtemps à mettre au point le flux de push. Mais finalement j'ai pu utiliser ce travail dans une maquette pour avoir un feedback temps-réel de tout ce qui se passait à l'extérieur d'un moteur de Firefox 3 en kiosque (via un XmlHttpRequest avec multipart=true). Succès total.

        thttpd n'a pas libevent. Mais il dispose de sa propre logique de scruptation d'I/O qui semble tout à fait au fait de la technologie.

        Au départ HandBaller ne fonctionnait qu'en multipart. Mais WebKit est monté en puissance, et j'ai bien vu qu'il fallait que je me mette au long polling. Ca tombait bien, thttpd embarque aussi une solution de timers et de pattern matching légère... alors j'ai décidé de tout refaire. L'architecture actuelle repose sur des micro boîtes à messages (une pour chaque agent) qui persistent quelques secondes entre 2 requêtes de long pooling ou lors d'une coupure d'une connection de push.

        J'ai essayé de joindre les développeurs de msgbus en septembre sans succès. Je leur avais proposé de partager nos expériences. Et surtout je leur ai demandé de l'aide. J'arrive pas à faire marcher le multipart/x-mixed-replace comme il faut en HTTP/1.1 et le mode chuncked comme décrit dans la page projet de msgbus.

        Voilà, voilà. Sinon, pour te décourager, voici les principaux défauts de HandBaller.

        - le pattern matching qui sert à la souscription aux messages est trop souple, je suis obligé de passer en revue toutes les souscriptions pour voir si un message matche, sans pouvoir faire de haché... HandBaller n'est donc pas vraiment scalable, la complexité du reroutage d'un message étant en o(n).

        - HandBaller ne supporte pas les connections keep-alive. Donc le long-pooling est coûteux. J'aimerais bien que Webkit se mette au multipart/x-mixed-replace ou à la balise HTML5 de "server side DOM event".
        • [^] # Re: HandBaller

          Posté par . Évalué à 1.

          Dans le même genre d'outil, on trouve aussi les serveurs de messageries web.

          Voici la config qu'on a mise en place :

          ejarber - navigateur web avec la library javascript "jsjac".

          http://wiki.jabberfr.org/JSJaC

          J'utilise cette solution depuis 2 ans pour remonter en temps réél des alertes systèmes (les messages sont des data JSON)

          Le serveur de messagerie peut stocker temporairement des messages en cas de perte de connexion et les transmettre dès que la connexion est rétablie, ce qui assure la cohérence des flux.
  • # Http long polling ou http streaming

    Posté par . Évalué à 3.

    Ca fait quand même un bail que c'est connu.
    Contrairement au titre, il ne s'agit pas de vrai push, mais d'une sorte de polling persistant. On appelle cette technique long polling et dans sa version plus poussée, http streaming.
    En gros on garde une connexion ouverte avec le serveur (jusqu'à ce qu'elle soit coupé ou perdue) pour être notifié par le serveur quand il y a des changements.
    Celà demande donc de mettre en place un protocole au dessus d'http pour pouvoir parser les notifications de manière générique.
    Par souci de simplicité on utilise généralement JSON, car c'est un format naturel pour le javascript.
    Toutes les grosses plateformes du marché utilisent déjà ce genre de techniques : gmail, facebook etc...
    Dans la même veine qu'APE il existe donc gwt-comet.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.