Le mardi 4 novembre s'est tenue une soirée du Paris JUG; organisée comme d'habitude en deux sessions d'une heure :

• Didier Girard a pu démontrer la puissance et la simplicité de GWT,
• Jérôme Louvel a présenté les bénéfices de l'intégration avec Restlet.

Session 1 : Présentation de GWT

Cette session était animée par Didier Girard, directeur technique de SFEIR et responsable de onGWT.com, la référence sur GWT.

Introduction

Après avoir sondé l'assistance sur ses compétences en Javascript, Java, Flex, Silverlight et GWT, Didier a rappelé les principes d'AJAX : avoir des données fraîches sur une page web sans la recharger entièrement. Cette technologie est intéressante sur plus d'un point :

• L'utilisateur a une impression de meilleure réactivité, et ne subit plus le phénomène de "page blanche" caractéristique lors du chargement d'une page.
• Les applications de type "single page" (comme GMail, GoogleAgenda, mais aussi les WebOS) donnent une meilleure scalabilité, car l'état de l'application est stocké sur le client et non plus dans la session du serveur.

Cependant, le gros problème d'AJAX est... le javascript (compatibilité cross-browser, fuites mémoire, complexité, support des IDE, sécurité, accessibilité...). La phase de prototypage est souvent amusante et valorisante pour le développeur (premiers résultats rapides), mais le développement de "vrais" projets est une autre paire de manches...
GWT vise à supprimer ces limitations, et à produire du code stable, cross-browser, et compatible avec les IDE (refactoring, debugage...)

Présentation d'applications réalisées en GWT

Didier a ensuite présenté (sous Google Chrome, évidemment !) quelques applications réalisées en GWT :

• l'application de démonstration des composants (showcase, mailer, etc) livrée avec le SDK
• quelques jeux simples : portage de Xpilot sur le navigateur de la wii (opera), mastermind, jeu de frappe rapide au clavier...
• mais aussi des applications plus professionnelles : génération de charts (encapsulation d'une librairie flash), client de mail, agenda, un ERP (myerp.com), et un WebOS avec un backend PHP.

Comment vendre GWT aux décideurs

Cette partie fut à mon avis la plus intéressante, car elle se détachait du plan technique pour resituer la technologie dans un cadre d'entreprise.
Quels sont donc les avantages décisifs de GWT ?

• GWT est simple (c'est un peu le "VB du web", surtout avec GWTDesigner)
• Temps de démarrage faible pour les nouveaux développeurs (d'après un sondage réalisé sur le site onGWT.com)
• Opensource et supporté par Google
• Stack technique réduit et configuration minimale, permettant une extrême rapidité de déploiement et de mise en oeuvre par rapport à Struts, JSF, etc., autorisant un prototypage rapide
• Techologie solide et mature, et efficace en termes de bande passante (agrégation d'images, optimisation et compression du javascript...)
• Fonctionne en mode déconnecté, synchronisation grâce à Google Gears
• Ergonomie riche : il est possible de reproduire des interfaces héritées de clients lourds, et de réutiliser les compétences de développeurs Swing
• Performance : le code javascript est optimisé par suppression du code mort et compression... (A ce propos, en règle générale il faut considérer le javascript produit comme du binaire, non modifiable à la main - même s'il existe une option pour que le code généré soit en mode "lisible").
• Forte communauté et bonne documentation.
• S'insère parfaitement dans un stack technologique existant côté serveur (php, struts...), car n'oublions pas que le code produit est du Javascript, donc côté client. GWT n'est donc pas en rupture avec les technologies déjà déployées chez le client.

Démonstration de dévelopement d'une application GWT

Nous avons ensuite assisté à une courte démonstration pratique.
A l'aide d'un simple Eclipse et du plugin "GWTDesigner" (qui permet de faire de la composition graphique par drag'n'drop, et synchronise en temps réel le code et l'éditeur graphique), Didier a réalisé le "HelloWorld" réglementaire, puis une petite calculatrice en ligne.
Il a ensuite utilisé le débugger Java d'Eclipse pour poser des points d'arrêt dans le code et l'exécuter pas à pas, chose impossible avec du Javascript traditionnel.

Architecture

GWT s'appuie sur la syntaxe Java, mais certaines API du SDK ne sont pas supportées - n'oublions pas que le code javascript produit sera exécuté sur le navigateur client, où certaines notions Java n'ont tout simplement pas de sens ou pas d'équivalent : JDBC, les sockets, les threads... Suite à la compilation, des fichiers Javascript optimisés sont produits. Une application typique pèse seulement ~100-200ko, et peut être mise en cache par le navigateur ; son déploiement est donc peu gourmand en bande passante, contrairement à certaines idées reçues sur les RIA.
GWT fournit assez peu de composants en standard, mais la communauté produit beaucoup d'extensions de qualité.

A noter (et en vrac) :

• Le bouton "Back" est supporté grâce aux "ancres" HTML ajoutées dans les URLs. La "bookmarkabilité" et l'accessibilité sont les nouveaux chevaux de bataille des technologies RIA ; Flex les supporte également, depuis peu.
• Possibilité de communiquer avec le serveur via RPC (propriétaire), HTTP et REST.
• Optimisation et support de l'I18N : le compilateur génère un fichier Javascript par Locale et par navigateur supportés. Cela permet de limiter la charge réseau en n'envoyant au navigateur que le code qui lui est strictement spécifique (aucun test de type "if (IE6)" dans le code).
• Tests unitaires : les tests en Java sont faciles. En revanche, les tests d'interface commencent seulement à être gérés, notamment par Selenium.
• Intégration possible avec des frameworks javascripts existants, qu'ils soient standard (ExtJS, Prototype...) ou "historiques" en entreprise.

Points sensibles

La nature même et l'architecture particulière de GWT force les architectes et les développeurs à repenser le paradigme du développement web. Premièrement, GWT est focalisé sur le développement d'applications de type "single screen", peu habituel sur le web. Ensuite, les design patterns mis en oeuvre sont ceux du client lourd, à base d'événements et de listeners ; or, cette compétence n'est plus enseignée dans les écoles d'informatiques, qui depuis plusieurs années ont orienté leurs cursus sur les technologies web traditionnelles (request/response...). Les architectes en particulier devront prévoir une phase de (ré-)adaptation.

Questions/réponses

Q : Le HTML étant généré dynamiquement par l'application, comment intégrer le département "design" dans le processus de maquettage ?
A : Il est possible de créer des composants personnalisés générant très exactement le code HTML conçu par les designers.

Q : Est-il possible de régler le design au millimètre (selon une charte graphique).
A : En principe oui, mais cela dépend naturellement du niveau de détail et de sophistication des écrans. Et de l'exigence des MOA / designers...

Q : Est-il possible d'intégrer le compilateur GWT aux builds Maven ?
A : Oui, c'est possible.

Q : Est-il possible d'effectuer des tests unitaires ?
A : Oui, avec JUnit pour le code métier, et Selenium pour tester les IHMs.

Conclusion

GWT est un outil puissant mais relativement simple d'accès, permettant de réaliser très rapidement des interfaces riches pour des applications de type "single-screen".
Didier pratique GWT quotidiennement et l'a déjà déployée chez des grands comptes, il ne s'agit donc pas du dernier gadget à la mode mais véritablement d'une technologie utilisable en production. Si vous avez d'anciens développeurs Swing, ils seront sans doute heureux de se reconvertir sur du Web 2.0 par ce biais.

Et maintenant, la pub...

A l'issue de cette première présentation, les sponsors du Paris JUG ont distribué des cadeaux sympa :

• 3 licences GWTDesigner, aux personnes qui ont posé les trois premières questions (je suis l'un des heureux élus)
• 2 livres Java EE 5
• 2 licences IDEA, par tirage au sort chaotique
• Des clés USB aux couleurs de Novedia - qui s'allument ! Il fallait bien ça à l'approche de Noël.

Le buffet était égal à lui-même, avec des assortiments de chips, petits fours et boissons diverses. Nous retiendrons en particulier un énorme saladier contenant un jus bleu/vert fluo du plus bel effet mais à la composition inconnue - mais heureusement, aucune mutation génétique spontanée n'a été à déplorer après absorption.
J'en ai profité pour discuter avec quelques habitués des lieux, dont bien sûr l'équipe du JUG (Antonio et Zouheir), Jaxio au grand complet, Nicolas (touilleur fou à ses heures), Fabrice de chez Octo...

Session 2 : GWT et Restlet

Cette seconde session était animée par Jérôme Louvel, auteur de Restlet.

Introduction : Rappels sur REST

Tout d'abord, il faut rappeler que REST n'est pas un protocole : c'est un style d'architecture web à part entière.
Il s'appuie sur les notions de :

• Ressource : "le concept que je manipule". Les ressources sont identifiées par des URI fixes (ressource-oriented architecture). Exemples : http://www.parisjug.org, urn:isbn:1-933988-23-1.
• Représentation : "sous quelle forme la ressource est-elle représentée. Les formats les plus utilisés sont HTML, XML, JSON...
• Action : "comment lire ou modifier l'état de la ressource". Les actions sont portées par les verbes HTTP (GET, POST, DELETE, PUT...), et non plus par les URLs (plus de /deleteItem?id=3) :
  • GET renvoie l'état courant de la ressource (action idempotente)
  • PUT crée ou met à jour son état
  • DELETE supprime son état
  • POST déclenche un traitement sur son état
  • etc.

Cette architecture est intéressante pour sa simplicité (grâce à son fonctionnement stateless) et sa performance (les URI étant fixes, les ressources peuvent être mises en cache, et l'absence d'état sur le serveur permet de les clusteriser facilement). Par ailleurs, il est amusant de constater qu'il s'agit en fait d'un retour aux principes fondateurs d'Internet...
Voyons maintenant ce que ça donne en pratique.

Présentation et architecture du framework Restlet

Le framework Restlet tente d'implémenter les notions de REST le plus fidèlement possible. On retrouve ainsi une classe java par concept (Ressource, Representation, Reference, Component, Connector...).
Si vous avez l'oeil affûté, vous avez dû remarquer la classe Connector dans la phrase précédente. Quitte à manipuler des abstractions, Restlet a voulu se rendre également indépendant du protocole sous-jacent. Il propose donc un ensemble de connecteurs pour HTTP, FTP, File, SMTP..., même si, en pratique, c'est HTTP qui est utilisé le plus souvent.
Concrètement, la relation entre ces classes est la suivante : une application REST gère des ressources, et les expose dans différentes représentations. Un composant héberge une ou plusieurs applications et dispose de connecteurs acceptant les requêtes des clients.

Restlet offre les bénéfices suivants :

• Une API simple, qui autorise des extensions (par exemple, pour Atom, JAX-RS, JSON...)
• Une grande souplesse d'utilisation : il peut être lancé en standalone, déployé dans un conteneur de servlets, dans un conteneur IOC...
• Support de WADL qui permet d'auto-documenter les ressources exportées (il existe ensuite des feuilles de style pour générer de la documentation HTML, XML...).
• Support de la sécurité au niveau protocole via HTTPS, etc.

Exemple : un client HTTP simple

Après la théorie, un peu de pratique.
Jérôme nous a présenté deux exemples, afin de nous convaincre de la simplicité de mise en oeuvre de Restlet.

Le premier consistait en un client HTTP minimal :

Client client = new Client(Protocol.HTTP);
Request request = new Request(Method.GET, "url")
Response response = client.handle(request)
System.out.println(response.getStatus());

Le second, plus complexe, démarrait un serveur HTTP en mode standalone. Je n'ai malheureusement pas eu le temps de le noter, mais vous pourrez le retrouver sur les slides de la présentation, lorsqu'ils seront mis en ligne sur le site du Paris JUG. En tout cas, une vingtaine de lignes suffisaient à obtenir un serveur minimal mais fonctionnel.

Intégration Restlet – GWT

Pour la communication avec les serveurs, GWT propose en standard un connecteur RPC et un connecteur HTTP. Mais le format d'échange de GWT-RPC, bien que basé sur JSON, est opaque (propriétaire) et il est donc impossible de communiquer avec d'autres backends : le couplage est fort entre le code client et le code serveur.
L'intégration de Restlet permet d'abstraire la couche protocole et d'accéder à toute ressource exposée en REST. Le support des représentations XML et JSON est particulièrement bien intégré, car ces deux formats sont très liés à Ajax.

Côté client, certaines fonctionnalités de Restlet sont réduites ou absentes, car en s'intégrant à GWT, il en hérite les limitations, notamment dans les APIs java supportées. Par exemple, il n'est plus possible de créer un serveur HTTP, puisque la notion de socket n'existe pas en Javascript.
Côté serveur en revanche, Restlet peut servir des ressources (et remplacer Tomcat ou PHP), ou se comporter comme un simple reverse proxy transparent (classe Redirector). Ce dernier usage est notamment pratique dans les cas où le client ne supporte qu'un ensemble limité d'actions (ex: pas de PUT) : le proxy peut alors mapper certaines actions POST en PUT, par exemple.

Exemple d'utilisation :
Après modification de l'application de démonstration "Mailer" de GWT, chaque mail est une Ressource accessible à une URI unique, et possédant plusieurs rerpésentations (HTML, JSON, etc.).

Evolutions futures

Pour finir, Jérôme nous a brièvement parlé des prochains travaux sur Restlet. Deux pistes se dégagent :

• Automatisation de la synchronisation avec le code de GWT, afin de bénéficier des nouvelles classes du JRE gérées par GWT, et supprimer automatiquement du code de Restlet celles qui ne le sont toujours pas.
• Support de Google Gears pour gérer le mode déconnecté.

Questions/réponses

Q : GWT ne savait pas faire des requêtes DELETE et PUT (il ne gérait que GET/POST). Est-ce que Restlet permet de le faire ?
A : La plupart des navigateurs récents gèrent toutes ces méthodes, cela devrait donc être faisable. Restlet peut également faire de la conversion POST->PUT par exemple.

Q : Y a-t-il compétition avec JAX-RS ?
A : Restlet préfère l'approche orientée classes, contrairement à JAX-RS qui utilise les annotations et n'est pas forcément multi-protocoles.

Q : Restlet peut-il rendre les applications GWT bookmarkables ?
A : GWT est déjà bookmarkable grâce aux ancres dans les URLs

Conclusion

Cette séance, plus technique et moins démonstrative que la première, m'a laissé comme un goût d'inachevé (et un bon mal de crâne dû au volume du micro et à la proximité des enceintes...). Certes, le format court d'une heure ne permet pas de traiter les sujets dans toute leur complexité, mais tout de même...
Au final, je pense que je n'étais pas le seul à me demander : A quoi ça sert réellement ? Quels sont les use-cases et les best practices ? Est-ce vraiment utile pour des applications de gestion standard ?

Notes additionnelles :

• Le Touilleur-express a également publié un compte-rendu de la soirée
• La prochaine soirée du JUG aura pour thème : JBoss. Vous serez prévenus lorsque les inscriptions seront ouvertes !