insideIT.fr : le blog des architectes IT de SFEIR

Aller au contenu | Aller au menu | Aller à la recherche

lundi 23 novembre 2009

Atmosphere, atmosphere


Au devoxx de cette année nous avons pu assister à la présentation du framework Atmosphere par Jean-François Arcand, créateur du framework et Paul Sandoz, contributeur sur le projet Jersey utilisé par Atmosphere en ce qui concerne les aspects REST.

Après une rapide présentation des concepts liés aux architectures PUSH pour les applications WEB. Les deux speakers sont rentrés dans le vif du sujet en développant en direct une petite application permettant de démontrer les possibilités offertes par Atmosphere.



Le PUSH ?

Dans les applications WEB, le PUSH correspond à l'utilisation des protocoles WEB pour permettre aux différents clients (navigateurs généralement) de se voir notifier des informations de la part du serveur sans avoir à faire des requêtes périodiques sur ce dernier. Comme son nom l'indique, les informations sont poussées du serveur vers le(s) client(s) et non plus tirées par chaque client désireux d'y avoir accès. L'intérêt d'une telle technique réside dans la possibilité de voir se propager rapidement une modification de l'état du serveur et atteindre ainsi un pseudo temps-réel tout en économisant des échanges réseaux inutiles. Avec le PUSH on peut par exemple dans le cas d'un tchat, propager les nouveaux messages d'une discussion du serveur vers les clients connectés de manière quasi instantanée.
Lors de cette conférence Jean-François nous a décrit les trois types de communications existantes dans les applications WEB à savoir :
  • Polling (technique traditionnelle)
  • Ajax PUSH  ou Long Polling : ce que propose Atmosphere
  • Http Streaming : Une technique idéale théoriquement mais qui souffre de problème d'intégration avec les proxys notamment.
Atmosphere est un framework (le premier) à base de POJO proposant aux développeurs d'applications PUSH une couche de programmation masquant la complexité des serveurs Java dans ce domaine.
Pour développer la partie serveur d'une application, le framework est utilisable sur de nombreux serveurs : des conteneurs legers (Tomcat, Jetty), certains serveurs d'applications comme Glassfish et Weblogic, il est même disponible pour le Google App Engine. Concernant ce dernier, on est en droit de se demander comment peut fonctionner le Long Polling avec des requêtes censées durer moins de 30s ? Jean-François nous a donné la solution en expliquant qu'Atmosphere implémente sont propre système de continuation permettant de passer outre cette contrainte. Il faut aussi noter la compatibilité d'Atmosphere avec les Servlets 3.0.

En ce qui concerne la partie cliente des applications, de nombreux frameworks sont supportés dont GWT et Wicket. 
Lors de la présentation, les speakers se sont focalisés sur une sous-partie du framework à savoir les annotations disponibles pour les POJOs et les aspects REST intégrés via Jersey.

Lors de la démo, les deux conférenciers ont pu nous démontrer la simplicité avec laquelle il est possible de créer une application WEB asynchrone utilisant le PUSH. Ils ont insisté sur le fait d'utiliser de simples POJO et de les rendre manipulables via REST. On obtient par exemple des classes ressemblant à ceci :

@Path("/{topic}")
@Produces("text/plain;charset=ISO-8859-1")
public class PubSub {
    private @PathParam("topic") Broadcaster topic;
    @GET
    @Suspend
    public Broadcastable subscribe() {
        return new Broadcastable("OK",topic);
    }
    @POST
    @Consumes(MediaType.APPLICATION_FORM_URLENCODED)
    @Broadcast
    public Broadcastable publish(@FormParam("message") String message){
        return new Broadcastable(message,topic);
    }
}
L'idée principale de cette démo était d'utiliser Atmosphere pour suspendre la connection client lorsqu'il s'incrit à un topic "test" en appelant http://mon_serveur/test. Un autre client peut alors publier des messages qui seront diffusés à tous les clients connectés sur ce topic en soumettant un simple formulaire HTML contenant un paramètre "message" sous forme textuelle.

Ce que nous aurons retenu

Atmosphere simplifie effectivement le travail des développeurs en ce qui concerne la gestion du PUSH dans une application Java. Il n'est pas nécessaire de refondre entièrement une application existante pour y intégrer Atmosphere, la plupart des problèmes d'intégration sont adressés par le framework (gestion des proxys pour les connections HTTP, les limitations de chacun des navigateurs).

Resources:
Le site du projet : http://atmosphere.dev.java.net
Blogs :
Twitter : 
    @atmosphere_java 
    @jfarcand 

Ludovic Meurillon et Vincent Bostoen

jeudi 19 juin 2008

TheServerSide Java Symposium - Jour 2

La journée d’aujourd’hui a commencé fort, avec un keynote de Neal Ford Language Oriented Programming: Shifting Paradigms. Une présentation impressionnante, avec des slides à faire pâlir d’envie Al Gore, et une parfaite maîtrise…

S’appuyant sur un cas concret, Neal montre que la façon de résoudre un problème dans le monde informatique d’aujourd’hui est souvent de créer un framework (aussi petit soit-il) qui généralise le problème, puis de le configurer pour résoudre le cas particulier qui nous préoccupe. Or cela conduit à du code qui est rempli de “bruit” (comprendre: redondance et constructions syntaxiques), illisible par les personnes du domaine métier, et donc ne peut être validé. Que fait-on alors? On externalise le code dans un fichier de paramétrage, XML forcément, mais ça ne le rend pas plus lisible par le métier…

La solution ce sont les DSL, Domain-Specific Languages, qui permettent d’exprimer des notions propres au métier d’une façon accessible aux hommes du métier. On peut les diviser en:

  • DSL internes: utilisant les constructions du langage hôte
  • DSL externes: indépendants d’un langage

Un exemple de DSL interne en Java est JMock, qui permet d’écrire des choses du genre:

   one(gt).getGreeting(); will(returnValue(”Good afternoon”));

C’est ce quon appelle “fluent interface”, car on cherche à imiter le langage naturel, quitte à introduire des artefacts sans utilité (“bubble words”). En Java ça reste fortement contraint par la rigidité du langage, mais dans les langages dynamiques on peut faire des choses beaucoup plus avancées.

XML est une forme de DSL externe, a fortiori.. Mais selon Neal XML est obsolète ! (Pas de polémique…). Le futur c’est de modéliser le métier à un niveau d’abstraction supérieur, que ce soit via un langage ou en manipulant un arbre abstrait (ce que certains IDEs tendent déjà à faire), et ensuite d’exécuter le résultat dans un contexte qui, selon le cas, donnera un schéma de DB, un exécutable, etc.

Ce fut de loin la meilleure conf des 2 premiers jours, prenante et stimulante…

Ensuite je choisis d’assister à la conf Son of SOA: Event-Driven Architecture and the Real World, par Eugene Ciurana (LeapFrog). Ca commence par des challenges (calendrier serré, équipe à construire, politique IT rigide, existant à intégrer, …) qui sont autant de challenges si on les voit d’un autre angle. Le choix a été de mettre en place un architecture Resource-Oriented, où tout est considéré comme une ressource, services comme données, et acccessible par une URI. Même si ça ressemble furieusement à du REST, Eugene s’en défend; en effet il y a quelques différences, notamment le mélange entre verbe et nom dans l’URI, mais globalement la différence est si fine qu’elle est invisible.

Eugene a mis en place des outils “best of breed”, avec MuleESB à la place d’honneur, en tant que backbone et resource container. Aussi choisis: Crowd pour le SSO, GWT (tiens…), Wicket, Communiqué (CMS). Au final une success story bien ficelée.

Ensuite je vais découvrir Comet: Building a richer, more interactive web application, avec Ric Smith de kaazing.com. Il s’agit d’expliquer les mécanismes qui permettent de faire du reverse push, ou reverse AJAX, c'est à dire de permettre à une application AJAX d'être notifiée par le serveur de nouveaux événements, par opposition au polling où c'est le client qui interroge périodiquement le serveur. Les avantages sont clairs dans des applications type finances, jeux ou paris, ou tous domaines où le 1/10 de seconde peut faire la différence.

Historiquement, la première façon d'implémenter le push est un iframe invisible, dans lequel le serveur reçoit en continu des balises <script> qui déclenchent l'exécution de callbacks côté browser. Ca marche, mais avec des effets de bord parfois très gênants (clignotement du curseur, fuites mémoire, ...).

Deuxième technique, le XHT long-polling: le client lance une requête qui ne revient que lorsque des données sont dispo. La connexion est fermée, et ré-établie immédiatement. Problèmes: léger overhead dû à la reconnexion, et latence possible.

Autre option, XHR streaming. Pour cela, on a besoin que le browser implémente "onreadystate". La réponse à la requête XHR ne se termine jamais, et lorsque des données sont dispo un callback est appelé. Principal souci, le support limité de cette fonctionnalité dans le parc de browers.

Dernière option, la connexion socket, qui nécessite un plugin (Flash, SIlverlight, Java). Ici on s'appuie sur des fonctionnalités du plugin pour établir une connexion serveur rémanente et notifier le browser.

Enfin, à l'avenir HTML5 intégrera la notion de server-side events, et le serveur pourra alors envoyer un type MIME application/x-dom-server-event qui activera un callback. Mais ce n'est pas pour demain.

Un point important à considérer est le couplage connexion-thread qui existe dans les serveurs classiques; en effet si 100 000 clients sont en attente d'évenements, on ne peut pas admettre de créer autant de threads. Jetty et d'autres résolvent ce problème avec la notion de "Continutation" qui permet de rendre les threads indépendants des connexions.

Un tour d'horizon super intéressant du problème !

Avant de manger, un Expert Panel: Languages: The Next Generation, composé de Ted Neward, Ola Bini et Guilaume Laforge, discute de la prochaine génération de languages. C'est très divertissant, et il en ressort surtout qu'il n'y aura pas de "next big language", mais que comme Neal Ford l'a prédit, les DSL vont prendre le devant de la scène, avec les langages dynamiques...

 

Midi, cette fois j'ai compris le truc pour ne pas faire la queue aux plats chauds: d'abord le buffet froid où il n'y a personne, ensuite les plats chauds!

 

Je saute le Vendor Tech Brief, encore GigaSpaces (eh oui ils sont le principal sponsor). Je vais récupérer mon T-shirt JavaBlackBelt gagné au concours hier, et une petite démo de JavaRebel s'avère assez impressionnante: rechargement à chaud des classes sans arrêt redémarrage! Un confort et une productivité qu'on a oublié sous Java, à force d'appeler des scripts ant et de redéployer à tout bout de champ.

The Enterprise Without a DB, par John Davies: ça fait longtemps que je traîne l'obligation de travailler avec des bases relationnelles comme un boulet, d'où mon intérêt pour ce sujet. John montre l'absurdité de la situation: le schéma FpML compte plus de 4000 éléments, et peut aller jusqu'à 12 niveaux de profondeur. Il est quasiment impossible de mapper un tel schéma avec un ORM. Les DB XML de leur côté n'ont pas d'API standard, et ont des performances sous optimales. Ce que propose John: utiliser le caching, la mémoire quoi, et travailler avec un data grid. Il cite plusieurs outils qui tendent vers ce but: GemStone, TangoSol (acheté par Oracle), GigaSpaces, Terracotta.

Malheureusement, de trop nombreux outils (reporting, etc) et un poids historique des tenants du camp "DB" rend cette approche exotique, et pour encore longtemps.

What's new in EJB 3.1, par Anotnio Goncalves: Non EJB n'est pas mort! Même si la spec 2.1 l'a presque tué... Aujourd'hui les EJB 3 (JSR 220) sont un soulagement pour qui fait des EJB: POJOs, interfaces simples, injection, annotations, peu de XML à écrire... Les EJB 3.1 (JSR 318) ont pour objectif de les rendre encore plus simple à utiliser, et d'amener de nouvelles foinctionnalités. On note déjà que JPA a son propre JSR (317), ce qui aidera peut-être à redorer son blason. Ensuite l'interface locale devient facultative! l'injection reste obligatoire. Il sera aussi possible de packager des EJB dans un WAR tout simplement, en gardant la fonctionnalité EJB. Enfin différents profils seront définis: A (minimal, pas d'EJB), B (EJB lite), full (EJB complet plus une trentaine d'autres specs). Nouveau encore: la notion de singleton, les appels asynchrones, et le timer service.

Java EE 6 (sortie Q1 2009) embarquera EJB 3.1.

On finit par un Fireside Chat: Zero Turneround in Java Development, où je revois les démos JavaRebel et Grails, plus Geert Bevin (Uwyn) qui présente RIFE.

Rendez-vous demain pour la clôture!