Développement d'une application RIA - Choisir entre GWT et FLEX
Written by Gaetan Zoritchak & Pierre Mariac
Les « Rich Internet Application » ou RIA, sont nées de la volonté de proposer des applications web aux fonctionnalités proches des applications traditionnelles (richesse des contrôles, temps de réponse…). Une telle application est supportée par le navigateur, mais contrairement aux applications web classiques elle n’est pas architecturée autour de pages statiques et propose une expérience plus riche, plus proche d’une application classique. Ce type d’application met en exergue le concept de « User Experience » et tend à proposer des solutions plus agréables à utiliser, plus dynamiques et performantes tout en garantissant une maintenabilité optimale.
Les applications d’entreprises ont connu un mouvement de balancier dans les années 90, d’applications « client lourd » on est passé au tout internet, mais les entreprises ont souvent perdu en productivité ce qu’elles ont gagné en facilité de déploiement et de maintenance.
Les applications internet riches combinent aujourd’hui le meilleur de deux mondes. Elles permettent de présenter des contenus riches et à haute fidélité quels que soient leur volumes. Elles profitent d’une meilleure interactivité et offrent toutes les facilités attendues d’une application classique (Drag & Drop, tooltips, validation instantanée….) tout en offrant des temps de réponses accrus. Enfin les coûts opérationnels sont réduits par rapport aux deux types d’applications sus-citées, la distribution, l’hamonisation et le support technique étant grandement facilité sur une RIA.
C’est pour toutes ces raisons que de grands noms de l’industrie comme Oracle ou SAP travaillent actuellement à proposer des déclinaisons RIA de leurs produits et c’est également dans ce but que, selon Gartner Group, 48% des banques prévoyaient le déploiement de clients riches dès 2008.
Parmi les solutions plébiscitées par les développeurs et les clients nous allons plus précisément nous pencher sur deux des plus connues:
Google Web Toolkit (GWT), une solution développée par les ingénieurs de Google, qui repose sur un système unique de développement en Java compilé en Javascript.
Flex, une solution proposée par Adobe qui offre un framework apte à la création d’applications riches en se basant sur l’utilisation du lecteur Flash.
Ces deux solutions divergent grandement dans leur approche, leur fonctionnement et leur implémentation, nous verrons donc dans quel cas utiliser l’une ou l’autre selon votre projet.
Ce framework est né d'une volonté d'Adobe de fournir une solution performante pour la création d'application de gestion, en corrigeant les défauts de l'environnement Flash inutilisable dans un tel cadre. Pour faire simple, Flex offre aux développeurs une bibliothèque riche de composants graphiques et un environnement d'édition orienté vers la production d'applications de gestion.
Toute application développée en Flex fonctionne dans le flash Player, un plugin de navigateur extrêmement répandu et pérenne, qui offre une richesse en terme graphique doublée d'un langage de script puissant, l'Actionscript. Si ce langage apparu il y a une dizaine d'année permettait au départ de coder de simples interactions utilisateurs, il a su évoluer et s'adapter pour offrir maintenant les fonctionnalités objets équivalentes à celle de Java.
Une application Flex est composée :
De code Actionscript 3 (AS3) pour les briques de bases de l'application (widgets graphiques, briques de communication...)
De code MXML pour assembler ces briques et les lier entre elles de façon simple
Le gros avantage du MXML est qu'il est très concis et qu'il est générable en WYSIWYG depuis l'éditeur. Par conséquent Flex est un outil qui permet de maquetter très rapidement et simplement un prototype d'application. Néanmoins, lors du développement d'une application complète, la part du code Actionscript va vite devenir plus importante. C'est ce code AS3 qui va par exemple gérer les interactions client, les échanges avec le serveur ou encore qui va permettre le développement de composants spécifiques. C'est également ce code qui va supporter la logique métier de l'application. Toute cette partie nécessitera des compétences en développement et en conception objet.
Adobe soutient fortement sa solution depuis les premières versions de 2004. Le framework a d'abord connu un enrichissement fonctionnel qui lui permet aujourd'hui de proposer d'emblée une centaine de composants parmi les plus utilisés, de la textBox à l'histogramme 3D. L'offre s'est ensuite enrichie de briques techniques pour la communication client-serveur et propose en solutions payantes ou open source de gérer des communication par messages, push d'information ou socket pour le temps réel, ceci décliné dans plusieurs protocoles selon l'usage désiré. Enfin Adobe poursuit actuellement son effort en mettant actuellement à disposition des développeurs des solutions plus structurelles comme un framework MVC.
Critères fonctionnels
Intégration bureautique
Parmi les opérations supportées on notera le drag & drop, le copier/coller de texte, le support de raccourcis clavier définissable dans l’application, mais également l’impression et l’export PDF.
Flex permet également de mettre en place des menus d'application ou des menus contextuels, gère nativement les multi-sélections (CTRL-click, SHIFT-click etc...) et respecte les normes Windows de raccourcis (ex : la touche TAB permet de passer d'un champ de saisie au suivant).
Toutes les fonctionnalités d'une interface riche sont présentes et respectent les standards
Rendu visuel
Il s’agit ici clairement du point fort de flex. L’utilisation du plugin flash offre des possibilités très larges en terme de rendu : possibilité d’inclure images et design vectoriel et de les gérer de manière interactive (utilisation de filtres, manipulation d’images, gestion des couleurs, transformations 3D…).
Les briques de base ont un rendu très agréable qui est entièrement paramétrable via l’utilisation de CSS.
Enfin Flex offre des fonctions d’animation et de transition qui permettent de tirer le meilleur de l’IHM, et de représenter de manière intelligible de gros volumes de données.
Flash offre d'énormes possibilités en terme de personnalisation des interfaces
Ergonomie productive
La bibliothèque d’éléments du framework Flex est très riche et couvre tous les besoins en terme de contrôle, mise en page et de navigation… Des composants plus avancés sont également disponibles comme le slider, le datePicker…
Le drag & drop, les raccourcis clavier, la gestion du focus permettent de compléter une interface riche et très productive.
Il est possible de surcharger les composants existants, le code source du framework est disponible. Enfin la documentation riche et la communauté très réactive permet d’envisager sereinement la conception « from scratch » de composants spécifiques.
Le binding des éléments permet de gérer simplement les interactions au sein de l'interface
Installation et mise à jour
Une application développée sous Flex nécessite un lecteur Flash de version 9 ou supérieure (le taux actuel d’installation de ce flash player est de 98%). La mise à jour d'une application Flex se fait de manière totalement transparente pour le client.
Sécurité
Des possibilités d’encryption sont accessibles et les données transitent par flux binaires. Le Flash player supporte les connexions sécurisées sur HTTPS et gère indépendamment celles-ci des requêtes HTTP classiques en les plaçant dans une sandBox indépendante. Le support SSL, le traitement des clés de sécurité et des certificats est délégué au navigateur. Le flash player respecte donc les paramètres de sécurité mis en place pour la navigation par la stratégie d'entreprise. Il est également possible de configurer les paramètres de sécurité cross-domain de chaque application.
Le flash player ne peut en aucun cas modifier, supprimer ni même accéder à des fichiers de l'ordinateur client. Il peut recourir à des objets partagés et les stocker sur les disque du client (après autorisation) mais ces fichiers seront isolés par application et sandbox, de plus le volume qui leur est alloué est automatiquement limité.
Critères techniques
Ouverture de la solution
Une partie du framework est en open source, en revanche certaines parties restent propriétaires (communication flash-AMF, runtime flash…). Les solutions proposées par adobe sont généralement déclinées en plusieurs politiques tarifaires, selon le degré d’assistance demandé.
De nombreuses solutions open source ont été développées et certaines ont rejoint le giron d’Adobe sans perdre leur statut (par exemple BlazeDS pour la communication client serveur).
Maturité technique de la solution
Flex 2 s’appuie sur la version 3 d’Actionscript sortie en 2006. Ce langage orienté objet et prototype est basé sur la norme ECMAScript qu’il respecte a 100%. La technologie Flash existe depuis plus de 10 ans néanmoins elle a beaucoup évolué, les possibilités offertes par Flex en terme de développement d’applications de gestion sont encore récentes et certaines parties sont inabouties (gestion des modules, compilation SWC…).
Perennité
Flex a connu de profonds remaniements depuis sa première version en 2004 dont la principale a été le portage du framework pour la version 3 d’Actionscript. Actuellement en version 3.2, le framework semble s’être stabilisé mais n’est pas pour autant totalement abouti et des évolutions sont à prévoir.
Performance / montée en charge
Les prérequis sur le poste de travail pour l’utilisation d’une application Flex peuvent être assez élevés dans le cas d’une interface particulièrement riche ou d’un volume conséquent de données à afficher. Dans le cas d'une interface de manipulation de données la configuration minimale sera 1GHz de CPU, 512Mo RAM (sous Windows XP).
D’un autre coté Flex utilise un protocole particulièrement optimisé pour gérer ses flux de données (70% de taux de compression) et les solutions serveur gèrent nativement le buffering et la pagination lors de gros volumes, ce qui permet au client de conserver des performances respectables même lors de la manipulation de gros volumes d’information
La manipulation de données peut s'effectuer coté client afin de libérer une partie de la charge serveur, enfin les composants de visualisation peuvent manipuler nativement les données sous plusieurs formes : tableaux, XML, collections... et s'adaptent ainsi au besoin client : affichage extensif, drill down, synthèse multi-axes...
Flex est un outil particulièrement performant pour synthétiser de gros volumes de données
Robustesse / fiabilité
Le flash player affiche une grande statibilité, les soucis de fuites mémoires qu’il a connu dans les versions précédentes sont maintenant effacés. Chaque version du flash player améliore généralement les performances de manière parfois drastique.
Critères organisationnels
Productivité
Alors que Flex dispose par l’intermédiaire de Flex Builder d’un outil de design WYSIWIG particulièrement performant, ses capacités en terme d’édition de code sont particulièrement pauvres : le refactoring est inexistant, l’affichage des erreurs à l’édition très limité… Les possibilités offertes sont clairement en deçà de ce qu’on serait en droit d’attendre aujourd’hui d’un outil pareil et il ne tient en aucun cas la comparaison avec les éditeurs que l’on peut trouver dans le monde Java.
D’un autre coté les API du framework Flex sont intéressantes, riches, et permettent de mettre en place très rapidement un code concis à défaut d’être facile à maintenir.
Basé sur Eclipse Flex Builder 3 permet de passer d'un clic du code à la vue WYSIWYG
Support / maintenance
La solution est très largement poussée par l’éditeur, les forums et les communautés sont pour l’instant assez limités bien qu’actives et pointus. Une source d’information de qualité est fournie via les blogs de développeurs officiels sur des points particuliers (webservices, pagination, oprimisation….)
Facilité d’apprentissage
L’actionscript 3 est un langage objet dynamique qui est assez différent du Java. Certaines spécificités peuvent poser problème à un développeur débutant. Flex croise également ce code Actionscript à un langage de description d’interface le MXML qui demande un peu de temps pour être correctement appréhendé.
Maintenabilité du code
Flex nécessite une forte implication des développeurs à produire du code structuré.
L’existence de Framework MVC comme Cairngorm et la génération automatique de services clients, permettent de s'assurer d'une bonne séparation des couches traitements / présentation. Il existe des conventions de codage pour garantir une meilleure lisibilité / maintenabilité du code.
Par ailleurs il n'existe actuellement pas d'outils capables d'assurer le refactoring du code ce qui présente un risque important pour des applications à durée de vie moyenne à longue.
Compétences sur le marché
Les compétences sont rares. Nombre de développeurs proviennent du monde flash, et rencontrent beaucoup de difficultés à appréhender le changement complet d'orientation qui s'est opéré avec la sortie d'Actionscript 3. Le profil idéal d'un développeur Flex se trouve plutôt dans celui d'un développeur Java ou .net ayant déjà une expérience en terme de développement d'interface.
Relativement jeune, ce framework open-source a apporté une solution élégante aux problématiques de développement des applications RIA basées sur les seules capacités du navigateur internet (HTML + CSS + javascript).
Les principales difficultés posées alors par ce type de développement étaient notamment:
la gestion d’un comportement identique indépendamment du navigateur utilisé,
le manque d’outils de développement pour le code javascript,
le javascript est un langage dynamique qui autorise beaucoup de liberté dans l'écriture et rend la maintenance ardue,
l’inexistence de composants graphiques.
La solution radicale proposée par Google consiste à s’affranchir du javascript en réalisant les développements en java puis de réaliser une phase de compilation traduisant le code en javascript.
Les avantages de ce mécanisme sont nombreux. On relèvera notamment :
la compilation réalise une batterie d’optimisation impossible à obtenir en codant manuellement le javascript,
le framework fournit une API standard et gère ensuite les variations entre les navigateur,
La première version de GWT a été proposée à la communauté en mai 2006. Depuis le framework a fait l’objet de mises à jours régulières, la sixième évolution étant annoncée pour le premier trimestre 2009.
GWT est une solution de relativement bas niveau. Les éléments compris dans le framework sont:
les composants visuels de base (bouton, champs de saisie, tableaux, ...),
la mise en oeuvre de la communication client serveur GWT-RPC,
l'internationalisation avec notamment prise en charge des langues écrites de droite à gauche,
des outils de développement évolués : transformation java vers javascript, exécution en mode debug, outils de tests,...
Ce framework a depuis été complété par des centaines d’autres librairies prenant en charge des problématiques spécifiques.
Critères fonctionnels
Inégration poste de travail
Les capacités d’intégration avec le poste client sont fixées par le navigateur client. Il n’est pas possible d’accéder directement aux fonctions de l’OS, comme l’accès direct au système de fichiers, à l’impression, …
Rendu Visuel
L’aspect visuel est réalisé par l’application de feuilles de style sur un DOM HTML. Ce mécanisme permet d’aller assez loin dans la personnalisation d’une application (cf : http://www.studyblue.com ) mais se trouve tout de même limité par des différences d’interprétration entre les navigateurs.
La transcription d’un design réalisé sous photoshop en feuille de style CSS compatible avec tous les navigateurs s’avère parfois très complexe et l'obtention de rendu parfait (au pixel près) est difficile.
L'interface GWT de studyblue.com utilise au maximum le stylage par CSS
Certains des frameworks s’appuyant sur GWT proposent de remplacer l’ensemble de la couche de composants graphiques par un ensemble plus riche. On peut citer par exemple Ext-GWT et SmartGWT. Cette logique permet de disposer rapidement d’un rendu visuel abouti au pris d’une dépendance forte avec un framework externe.
Composant tableau éditable en ext-gwt
Productivité de l’ergonomie
Les applications développées en GWT peuvent être extrêmement productives. GWT permet d’offrir à l’utilisateur un environnement de travail proche de celui d’une application installée sur le poste : clic-droit, Drag & Drop, édition de texte riche, suggestion et validation en cours de saisie, …
La limitation provient du navigateur qui n’est pas toujours capable de traiter de gros volumes de données. Ainsi, il est illusoire de vouloir charger des tableaux de données de plusieurs centaines de lignes. Les temps de traitements du navigateur (notamment IE) lors du parsing du DOM HTML deviennent rédhibitoires. Il faut alors mettre en place des stratégies alternatives comme le « paging » ou le filtrage.
Installation et mises à jour
Basé sur le navigateur internet, GWT ne nécessite aucun pré-requis au démarrage d’une nouvelle application. L’installation se limite à l’ouverture de la page web contenant le code javascript.
Sécurité
Dans sa version actuelle GWT ne propose pas de mécanismes spécifiques liés à la sécurité. Les éléments importants tels que l’authentification et le cryptage sont portés par la couche de communication http.
Critères techniques
Ouverture de la solution
Même si GWT est proposé par un acteur majeur du net, cette solution est complètement ouverte. Elle s’appuie sur une licence Apache 2 qui autorise une utilisation très large de ce framework (inclusion dans une application commercialisée, modification, …).
La communauté est importante et contribue à l’effort de Google pour améliorer le framework. Elle joue également un rôle dans la planification des fonctionnalités livrées dans les futures versions de GWT.
Maturité de GWT
Le framework est relativement récent mais les technologies et l’architecture mise en œuvre sont beaucoup plus éprouvées. GMail créé en 2004 s’appuie très largement sur les mécanismes utilisés dans GWT. Les technologies HTML + CSS + JavaScript sont très largement éprouvées. Les développements réalisés sous GWT sont utilisables dans la version 6 d’Internet Explorer sortie en octobre 2001.
Pérennité
Les évolutions ont été réalisées jusqu'à présent par ajout de fonctionnalités. Le fait que le code ne réponde à aucun Runtime est plutôt positif pour les compatibilités. Par ailleurs la très large adoption du framework et sa masse critique crédibilisent l'idée d’une solution durable. La dernière version officielle de GWT (1.5.3) a été téléchargée plus de 800.000 fois depuis sa sortie en octobre 2008.
Par ailleurs, il faut noter que les évolutions du framework ont jusqu’à maintenant garanti une compatibilité ascendante du code. La compilation d’un code existant dans une nouvelle version de GWT amène généralement un gain de performance.
Performances
Les performances sont à nouveaux dépendantes du navigateur. Les écarts observés d’un navigateur à l’autre sont parfois très importants. Elles sont nécessairement inférieures à celles d’une application installée sur le poste utilisateur mais toutefois suffisantes pour la majorité des cas. Lors de traitements consommateurs ou portant sur d’importants volumes de données il nécessite la mise en oeuvre de patterns adéquats (ne pas tenter de trier des tableaux avec des centaines de lignes!).
Il est intéressant de noter les évolutions récentes des moteurs JavaScript utilisés par Firefox, Google Chrome et Safari. Les mécanismes de machines virtuelles tels que mis en œuvre lors de l’exécution du code java ou C# commencent à apparaître dans les moteurs JavaScript). On peut s’attendre ce que les applications GWT s’exécutent jusqu’à 10 fois plus rapidement sur les nouvelles versions de ces moteurs.
Robustesse /Fiabilité
La robustesse des applications dépend de la version du navigateur. Certains présentent des fuites mémoires et imposent de relancer le navigateur quotidiennement afin de garder des niveaux de ressources suffisants.
Critères organisationnels
Productivité
Le choix de java comme support à GWT a été réalisé en raison des outils existants pour ce langage. Le développement bénéficie de l’excellence des éditeurs java (intellij Idea, eclipse) dans les tâches de d’écriture, de debug, d’analyse de code, …
Ainsi, un développement d’envergure comprenant des centaines ou des milliers de fichiers de code pourra être maintenu par les techniques habituelles de re-factorisation du code.
GWT présente des faiblesses dans l’organisation graphique des applications. Les outils de design WYSIWIG ne sont pas aussi matures ou productif que leurs équivalents en FLEX, SWING, Eclipse RCP…
Le succès de GWT se traduit aujourd’hui par un écosystème assez étendu qui offre des composants pour tous les domaines imaginables (réalisation de formulaires, validation de saisie, …). La productivité est accrue une fois que les composants constitutifs d’une applications sont sélectionnés et mis en place.
La compilation complète d'une application GWT en javascript peut être un peu longue (plusieurs minutes) mais elle n'est nécessaire que lors du déploiement de l'application.
Support/Maintenance
La communauté de développeurs GWT est très large et il existe aujourd’hui une base d’information en ligne très importante. Le forum dédié au développement sous GWT comprend plus de 15000 personnes. Il faut noter que les développeurs GWT sont à l’origine des développeurs java ayant généralement un niveau de compétence relativement élevé.
Si Google n’assure pas de support payant sur GWT, le niveau de connaissance de GWT augmente et il existe des experts capables de faire monter en compétence une équipe de développement ou de mettre en place rapidement les éléments nécessaires au démarrage d’un projet.
Facilité d’apprentissage
GWT est très facile d’approche pour un développeur java client riche (SWING, SWT). Les notions, les patterns et les APIs sont très proches. Un développeur ayant ces compétences pourra être très rapidement opérationnel et productif sur la plateforme.
La couche de présentation s’appuyant fortement sur les CSS demandera en revanche plus de temps avant d’être maîtrisée. Il peut s’avérer judicieux de s’appuyer sur un développeur web pour cette partie du travail.
Compétences sur le marché
Au vu de la relative jeunesse de GWT, il n’existe pas une offre de compétence spécifique très large sur le marché. En revanche, deux éléments viennent contrebalancer ce point :
le nombre de téléchargements indique un degré d’utilisation très important de ce framework,
les APIs et les concepts étant très proches des technologies java SWING et Eclipse RCP utilisées depuis longtemps, il existe de nombreux profils pouvant être très rapidement opérationnel en GWT.
La synthèse de notre étude remonte les points suivants :
FLEX
GWT
Critères fonctionnels
Intégration poste de travail
++
+
Rendu visuel
++
+
Ergonomie
++
+
Installation
+
++
Sécurité
+
+
Critères techniques
Ouverture de la solution
+
++
Maturité technique
+
+
Pérennité
+
++
Performances
++
+
Robustesse
++
+
Critères organisationnels
Productivité (petit / grand projet)
++ / -
+ / +
Support maintenance
+
++
Facilité d'apprentissage
+
++
Compétences sur le marché
-
+
Cette évaluation ne permet pas d'affirmer qu'une solution est meilleure que l'une autre. Les paramètres doivent être pondérés en fonction du projet. L'impact de tel ou tel paramètre sera complètement différent entre un projet "jetable" développé pour du très court terme et un progiciel de gestion.
Ainsi, par exemple la productivité est difficile à juger. La productivité de Flex est inversement proportionnelle à la quantité de code du projet. Flex pourra être la solution idéale pour le projet jetable et court terme et devenir un cauchemar au bout de quelques mois de développement d'une solution lourde. De son côté GWT propose une productivité inférieure pour des petits projets mais réagit mieux à l'augmentation du volume de code.
Par ailleurs, le choix d'inclure des librairies externes influe également sur cette évaluation. La productivité de GWT sur des petits projets est améliorée par la mise en oeuvre de framework tel que ext-gwt au détriment de la pérennité du code.
Lors du démarrage d'un nouveau projet, il sera nécessaire d'évaluer les critères prépondérants afin de choisir la technologie la plus adéquate. Une fois ce premier choix effectué, il faudra également sélectionner les librairies externes qui viendront faciliter le développement en complétant les fonctionnalités de la technologie. Enfin, le succès d'un développement ne sera pas assuré sans un travail de conception et de structuration du code par la mise en place des modèles de développement propres aux architectures "client riche".
Le dialogue entre Flex et GWT est possible, cette interface montre une application Flex qui se met à jour depuis un "pont javascript" et qui transmet dynamiquement ses modifications
Il est possible de concilier le meilleur des 2 mondes et c'est ce que nous avons choisi de faire dans nos projets. Que la technologie de base soit GWT, Wicket ou simplement du HTML, il est possible de faire interagir son application Flex comme le montre ce simulateur dédié au rachat de crédit immobilier.
Su cette page, tout changement des données d'un formulaire classique de type HTML modifie (sans rechargement de la page) les données du graphique Flex. L'application Flex elle-même n'étant utilisée qu'à des fins de visualisation / manipulation, elle ne fait que reproduire les données calculées pour la page. A chaque manipulation du slider, on a donc un échange qui se fait via un script de la page et qui adresse une requête au serveur. Comme vous pouvez le voir en le manipulant le tout parait pourtant tout à fait instantané.
Nous avons détaillé plus précisément la procédure d'intégration de Flex dans GWT dans un article plus complet. Comme vous pourrez le lire, la technique est simple et elle peut être facilement généralisée pour des applications de taille importante.
Pour aller plus loin, vous pouvez également visiter notre site qui utilise Flex, GWT, et JQuery pour fournir la meilleure expérience utilisateur : http://www.mon-credit-immobilier.info
Pour la remarque sur GWT: nous mentionnons GMail comme témoin de la maturité technique de la solution javascript/Ajax. Effectivement, GMail n'est pas développé en GWT mais les technologies sont les mêmes.
Sur l'ouverture de Flex, effectivement le compilateur MXML est devenu open-source. Nous avons corrigé cette référence. Merci de l'intervention.
Très bon article ! Bravo ! Il m'a donné envie de participer à un véritable projet Flex pour me faire ma propre idée. Je suis convaincu par GWT mais je ne voudrai pas passer à côté de Flex qui parait être une bonne alternative dans certains cas de figure.
