Petit compte-rendu cher lecteur ce soir. D’abord il est tard (dans les 01h36 du matin) et ensuite je dois me lever tôt pour le boulot (dans les 06h50 du matin aussi).

Tout d’abord j’ai fait 3 soirées ce soir : tout d’abord la présentation de Didier Girard sur GWT qui était vraiment sympa, la présentation de Jérome Louvel sur RESTlet et enfin la troisième mi-temps avec toute l’équipe du JUG et une dizaine de geeks autour d’une petite bière.

De l’avis de tout le monde, Didier a donné l’envie d’essayer GWT. La présentation rondement menée nous a permis de voir ce qu’est GWT. Cher lecteur ce soir je suis fainéant pour la première fois… Je ne vais pas bloguer des pages et des pages, je vous propose en attendant de relire des billets plus anciens sur GWT comme celui-ci ou celui-la sur Ext-GWT vs GWT-Ext.
Comme discuté avec Antonio, cela fait plaisir d’avoir quelqu’un qui apporte son expérience et partage sa passion sans concessions. En effet, Didier étant directeur technique de SFEIR, il parle en connaissance de cause, ce qui m’a intéressé.
Nous avons vu entre autre un plugin dans Eclipse facilitant l’écriture de code pour GWT, que GWT fonctionne avec Java 5 depuis le 28 août 2008, et un ensemble d’URL de sites d’exemples qui montrent GWT en action.
Mon avis sur la question c’est que GWT est destiné à réaliser des applications riches, et qu’en terme de productivité c’est un moteur puissant qui permet facilement de construire son application. Maintenant d’un point de vue web, je pense qu’il serait dommage de penser que GWT permet de faire une application type « vente de billet de trains »… Mais j’aimerai être convaincu du contraire.
En terme de mise en place, là où Adobe Flex propose avec BlazeDS et LiveCycle des solutions du côté du serveur, il n’y pas de solutions en GWT, car on parle bien d’un framework de présentation.
Je trouve par contre génial ce concept d’écrire du Java, de débuger dans Eclipse (ou IDEA IntelliJ) puis ensuite seulement de produire son code Javascript pour chacun des navigateurs, chacunes des langues supportées. Google est sur une niche et ce concept est réellement novateur.
Donc je reste fortement intéressé mais mon coeur balance plus pour Flex. Quitte à faire une application type client riche, je préfère travailler avec Flex. Cela me coûte une phase d’apprentissage du langage ActionScript, mais je gagne quelque chose par rapport à GWT, qui est le support de différents protocoles d’échanges entre le client et le serveur. Soit un échange de XML basique, soit du JSON, soit encore mieux, un format binaire propriétaire à Adobe qui permet d’optimiser encore plus la bande passante et les échanges entre le client et le serveur.
Merci en tout cas à Didier et vous pouvez retrouversur son site les URLs des démonstrations.

Ensuite un petit break pour le buffet organisé par la société Novedia Solutions. Honnêtement merci à eux car j’ai réussi à me caser derrière le buffet avec Cyrille Leclerc, Antonio Goncalves, Thomas et Alexis Moussine-Pouchkine. A nous 4 nous avons appliqué le pattern « Interceptor » et « Introspection » sur les plats de petits fours, que du bonheur.
Ma conclusion c’est que Spring n’a rien inventé. Au lieu de devoir faire un get et un set sur les petits fours, le serveur nous a tendu le plat et nous n’avions plus qu’à nous injecter ces bons petits gâteaux. Vive l’inversion de contrôle.

Bon reprenons la suite. Jérôme Louvel, membre de l’OSSGTP et auteur de Restlet nous a fait une démonstration plutôt pointue de Restlet. Tout d’abord ce que j’ai compris : Restlet est un framework léger REST en JAVA qui offre un système du côté client comme du côté serveur pour acceder à des Ressources. Je trouve que l’architecture REST est franchement intéressantante, et si vous voulez relire une présentation à ce sujet, voici un billet que j’aime bien écris il y a quelques mois sur REST.
Parlons un peu des choses qui fâche, désolé Jérôme si tu me lis. La présentation était vraiment très complète, voir un peu trop détaillé je pense pour le sujet de ce soir. Les efforts de migration et de portage vers la dernière version de GWT, quoique vraiment intéressant d’un point de vue technique, ont peut-être fait décrocher une partie de la salle.
Je pense qu’il est difficile en une heure de parler à la fois de Restlet et à la fois de GWT, c’était le format de la soirée qui donnait peut-être le cadre.
En tous les cas la présentation nous a donné un bon aperçu de Restlet et j’aurai aimé te poser des questions sur les annotations.
J’ai pensé un moment que Restlet se propose d’être un ‘ESB’ à la fois du côté du client et du côté du serveur, en simplifiant l’accès aux ressources et en utilisant les principes de REST. Durant la présentation, tu as cependant bien expliqué que grâce à Restlet, une application de type webmail a ajouté le support de GWT pour un coût de développement léger. Le système de sélection du type de rendu selon la source était bien expliqué.

Après la présentation nous nous sommes retrouvés au Falstaff à côté de l’ISEP autour d’une bonne bière. Moment agréable où j’ai écouté pas mal de monde, très sympa.

Sur ce, je vous donne rendez-vous la semaine prochaine pour un billet spécial pour fêter l’anniversaire du Touilleur Express ainsi que des nouveautés autour de Spring dès jeudi 13 novembre après la journée « Les Rencontres Spring« .

Je vous en reparlerai cette semaine.

6 réflexions sur « Soirée GWT et Restlet au Paris JUG »

  1. (le touilleur ne dort jamais ?)

    Très bon résumé de la soirée. J’ai bien compris les avantages de Rest mais je ne vois pas encore comment le mettre en place. Est-ce du travail en plus ou un moyen de faire différemment (exemple : au lieu de code une vue web classique, je vais exposer une URI Rest) ?

    Côté JUG, je suis 100% d’accord.
    D’ailleurs, commence ici la liste des astuces des Juggers :

    Astuce n°1 : se placer prés d’Antonio Goncalves pour avoir accès aux petits fours et aux boissons (mais surtout ne pas toucher à SES éclairs au café)

    Astuce n°2 : toujours boire du cocktail bleu fluo aux couleurs de la société partenaire (Novedia), ça vous rapportera de beaux goodies. Hier, c’était une clé USB. Le prochain sponsor qui offre des IPhone, aura l’unanimité.

    Tom

  2. « Soit un échange de XML basique, soit du JSON, soit encore mieux, un format binaire propriétaire à Adobe qui permet d’optimiser encore plus la bande passante et les échanges entre le client et le serveur. »

    Juste un petit mot pour préciser que GWT propose tous ces modes de communication client serveur nativement. Le mécanisme RPC de GWT est extrêment performant, fiable et simple à mettre en oeuvre avec un serveur en Java : simples POJOs (partagés entre client et serveur) + interfaces synchrones (serveur) et asynchrones (client) des services.

    Si vous êtes utilisateurs de Spring, il existe une librairie permettant de publier les services RPC via Spring, et donc d’y injecter ses services métiers en toute tranquillité.

    D’experience, après plusieurs projets en Flex et GWT, mon coeur penche plutôt pour GWT…

    Johann

  3. Hello Nicolas,

    Je me permet de rebondir sur ton article : je suis actuellement en plein projet GWT pour un groupe financier qui perd énormément d’argent…

    Le projet a pour but de valider des factures via un workflow FileNet, à partir de facture dématérialiser et versé dans FileNet.
    L’accès à FileNet se faisant pas WebService (WASP).

    Le tout sera déployé en WebSphere (pourquoi parceque…) j’ai d’ailleurs eu pas mal de galère au déploiement du WAR final, car le comportement en débuggage eclipse n’est pas le même au final sous WebSphere ou JBOSS. (problème au niveau de la lecture des paramètres entre deux pages et constitution d’URL, problème aussi à la remontée des erreurs, si les catch sont implémenté par des petits cochons)…Alors surement des problèmes dus à l’inexpérience.

    Si le principe GWT est assez séduisant, je pense que partir du java pour le compiler en java script, HTML est une fausse bonne idée.
    Certain package java en tant que tel ne sont pas reconnu par le compilateur, et certaines sont donc réécrites en « GWT ». Alors peut être que j’ai pas les bons plugin, mais on peut partir sur une solution et se la voir refouler au déploiement du compilo GWT. Pas dramatique mais sérieusement agaçant.. .

    De plus pour l’ingénieur novice (car n’oublions pas que c’est le gros d’une SSII), ce langage est extrêmement déroutant, je suis pas mal confronté a des gros problèmes de compréhension entre client et serveur qui se visualise mal en développement GWT.

    Pour le coup si je dois donner un conseil, partez plutôt sur du Flex…

Les commentaires sont fermés.