Vous pouvez développer aujourd’hui 2 types d’applications. Un site web classique pour des utilisateurs tout public, pour un extranet, pour un intranet. Et vous pouvez aussi développer des logiciels complets basés sur ces technologies, ce qui est plus mon domaine. Entre la page web classique, la gestion du bouton back, des onglets du navigateurs, et une application riche embarquée dans un navigateur, il y a un monde.

Dans le monde de la finance, les contraintes en terme de temps réel sont importantes. La volumétrie des données est aussi un critère important. Il faut limiter et bien réfléchir au découpage en couche de toute l’architecture. En terme d’ergonomie, les traders doivent être les homo sapiens les plus exigeants en terme de réactivité, d’utilisation du clavier et de « ...ça doit marcher ton machin…« .

Après avoir travaillé avec GWT, un prototype .NET et Adobe Flex, je mettrai mon argent sur Flex. La technologie simple et efficace proposée pour l’échange de messages entre le serveur et le client Flex m’a complétement séduit. Si vous téléchargez BlazeDS et que justement, vous jetez un œil sur la démo « trader », vous verrez qu’il est tout à fait possible d’avoir du pseudo-temps réel sans trop d’efforts sur un poste client.

BlazeDS est un composant serveur qui fonctionne dans un conteneur de servlets et qui permet de pousser vers un client Adobe Flex ou Adobe AIR des flux de données ou des objets sérialisés. Ce serveur est open-source et distribué en licence LGPL v3.

J’ai fait quelques tests avec Flex et un chargement d’un flux HTTP avec un tag mx:HTTPService et un tag mx:RemoteObject afin de comparer les performances avec Firebugs. Le chargement via RemoteObject est 2 fois plus rapide sur la démo « testdrive-remoteobject » par rapport à la démo « testdrive-httpservice » distribué dans la version Turnkey de BlazeDS.

Vous allez m’entendre parler Adobe Flex pas mal ici dans les semaines qui viennent. J’ai fait aussi un proto avec Spring 2.5 en prenant Spring MVC, une factory particulière pour Flex et IDEA IntelliJ. Il faudrait faire un petit screencast pour vous montrer tout cela car c’est long à raconter par écrit…

Lien supplémentaire:

http://flexbox.mrinalwadhwa.com/

La présentation sur Flex sera animée par James Ward. Sur son blog vous pouvez retrouver quelques articles sympathiques dont un proto Google Apps, Adobe Air développé avec Dick Wall, l’un des orateurs du podcast Java Posse. Avec quelques lignes en python pour faire la partie backend serveur, et quelques lignes de MXML pour charger l’objet via RemoteObject. Elegant et simple.

J’en profite pour dire un mot sur une application qui permet de traiter un grand volume de données, et qui m’intéresse particulièrement : NASDAQ Replay développé avec Flex. C’est François qui m’en a parlé lors de la réunion OSSGTP, et j’ai bien fait d’aller y jeter un œil.

Cette application légère fonctionne avec Adobe AIR sur votre machine et vous permet de rejouer les évolutions des cotations d’actions sur le NASDAQ. Pour cela l’ensemble des Quotes ont été stockées sur Amazon S3, un énorme volume de stockage virtuel proposé par la société Amazon. Les milliers d’enregistrement sont stockés sous la forme de simples fichiers textes afin que l’accès aux données soit très rapide. L’application permet à un Trader de rejouer des prises de position sur le NASDAQ et de valider par exemple, des moteurs d’évaluation de Risk. Ce prototype montre à mon avis le futur des applications d’analyse en ligne.

J’imagine des cubes OLAP stockés de manière organisée sur S3 avec un frontal développé en Flex… Il y a des millions d’euros sur ce marché dans la finance pour qui veut bien se pencher sur la question… Avis aux amateurs, l’analyse du Risk est un marché porteur dans la finance.

Thomson Reuters avait racheté une entreprise appelée Applications Networks en juin 2006 pour récupérer un produit appelé JRisk. Ce produit à l’époque était un moteur d’analyse de risque avec une partie OLAP. Le montant du deal publié sur l’annonce presse était de 42 millions de dollar. Pour information, le secteur du Trade and Risk Managment chez Thomson Reuters représente un chiffre d’affaire supérieur à 100 millions de livres sterling… de quoi payer une petite licence Adobe Flex Builder non ?

Pour mon « projet-de-dans-deux-ans » que je commence en septembre si tout va bien, je crois que je vais reprendre cette idée pour stocker les données que je collecte avec mon moteur…

Je crois bien qu’Amazon S3 vient de résoudre mon problème de volumétrie des données.

Allez on se voit la semaine prochaine, passez une bonne semaine.

La semaine dernière, à l’occasion de la journée Client Riche organisée par Valtech, je vous ai reparlé un petit peu de Google Web Toolkit. En quelques mots, GWT permet d’écrire en Java du code qui sera transformé en Javascript pour fonctionner du côté du navigateur du client. L’intérêt de GWT est son mode hébergé. Lorsque vous développez, ce qui est bluffant c’est la rapidité à laquelle vous pouvez construire votre interface. En effet, nul besoin de compiler quoique ce soit. Vous éditez simplement votre code Java, vous sauvez votre fichier, un rechargement dans l’outil GWT et votre modification apparaît immédiatement dans un navigateur utilisant la DLL d’internet explorer.

GWT ne dispose pas d’une librairie de composants très riche. Il existe dans le monde Javascript des librairies très puissantes. La librairie Ext-JS est l’une de mes favorites. Le problème de cette librairie est qu’il faut une bonne maitrise du langage Javascript et pas mal d’énergie pour développer une interface complète. Croyez-moi, je sais de quoi je parle.

Pour rejoindre le meilleur de ces 2 mondes, Sanji Jivan a développé GWT-Ext, une librairie qui se repose sur GWT, Ext-JS 2.0.2 ainsi que quelques composants supplémentaires comme les courbes en 2D (YUI) et le module Pagebus destiné à s’interfacer avec Tibco. Cette librairie est distribuée sous licence LGPL v3.
Je vous conseille de regarder la page d’exemple pour vous faire une idée de ce qu’il est possible d’écrire en Java, et qui se transformera en Javascript au final pour le client.

Le souci et le débat est que Jack Soclum, qui travaille sur la librairie Ext-JS a effectué un changement de licence en avril dernier. La librairie Javascript est passée d’une licence LGPL à une licence GPL v3. La conséquence pour les logiciels développés sur cette librairie, est qu’ils doivent soit adopter une licence virale comme la GPL, soit acheter une licence commerciale à l’entreprise de Jack. Cela a provoqué pas mal de remous dans la communauté des utilisateurs de la librairie Ext-JS. A priori les choses sont entrain de changer et on parle de mettre en place des exceptions pour les produits open-source quant à l’utilisation de la librairie Ext-JS. Voir ce post sur Ajaxian. En tout les cas Jack Solum s’est fait largement critiquer pour le passage d’une licence LGPL à une licence GPLv3, comme il l’explique sur son blog (note: il y a un post de Ludovic Dubost, OSSGTP, XWiki dans les comments). Quelque part c’est très informatif sur le côté épidermique des licences et de ce que les gens en font… On entre dans le débat LGPL/GPL…

Toujours est-il que le problème pour GWT-Ext est que ce projet reste à la version 2.0.2 de la librairie Ext-JS et ne pourra pas passer à la version 2.1 d’Ext-JS distribué en GPL. Dans le même temps, le groupe Ext-JS a lancé sa propre version du portage vers GWT de la librairie Ext-JS (honnêtement si vous suivez et vous êtes encore entrain de me lire, chapeau…). Actuellement la couverture fonctionnelle n’est pas encore très complete. Voici les deux liens pour comparer la première librairie (GWT-Ext) et donc la deuxième que j’appelle GXT mais dont le nom officiel est Ext-GWT… Comment embrouiller le développeur lambda…

• Démo GWT-Ext http://www.gwt-ext.com/demo/
• Démo Ext-GWT dit « GXT » http://extjs.com/products/gxt/

Je travaille sur un projet pour le mois de septembre pour lequel, après avoir fait un prototype avec JBoss Seam et IceFaces, j’ai eu envie de tester un rendu basé sur GWT. J’ai donc développé 2 prototypes avec chacune de ces librairies (GWT-Ext et GXT) afin de me faire une idée précise des lacunes et des points forts de chacune d’elle.

La librairie GWT-Ext est sortie en juillet 2007. La documentation est assez complète et la prise en main assez rapide. Complètement basée sur Ext-JS, on retrouve donc la manière de programmer cette librairie. Simplement, le fait de travailler en Java me permet de travailler plus rapidement qu’en pur Javascript. De plus, Sanji le développeur derrière cette librairie a intégré aussi des composants de Charts (de YUI) ce qui m’évite d’utiliser une librairie propriétaire.

La librairie GXT est encore en phase de béta. La documentation et les exemples sont moins fournis. Elle apporte un modèle léger événementielle qui fait que le code écrit me semble plus clair. La javadoc est plus complète, et lors des phases de debug, une partie de cette librairie étant écrit en Java, il est plus facile de travailler qu’avec GWT-Ext.

GWT-Ext est un wrapper complet qui utilise JSNI pour effectuer des appels Javascripts vers la librairie Ext-JS directement. Au contraire, GXT dispose de sa propre implémentation en Java. Au final c’est bien du javascript qui est généré.

Le post suivant de Didier Girard propose un petit tableau pour comparer les 2 librairies.
http://www.ongwt.com/post/2008/04/22/MyGWT-is-dead-Long-live-Ext-GWT

Au final je vais m’arrêter là… J’ai un prototype développé avec les 2 librairies. Je me suis cassé la tête sur GWT-Ext en particulier lors de la mise en place de la partie dynamique. Ext-GWT par contre me permet d’écrire du code avec une architecture plus propre. Donc c’est fait.

Fin du débat

L’organisation de Valtech était à la hauteur de l’événement. Environ 90 personnes étaient présentes. En majorité des développeurs Java. Il y avait quelques développeurs .NET, PHP et des graphistes. Mais le premier constat, c’est que soit le fichier de prospection de Valtech n’a contacté que des équipes Java, soit clairement un développeur client riche en France n’est pas un graphiste mais un développeur…

Nous étions environ une cinquantaine dans mon groupe. Tout le monde était équipé d’un portable avec les différents environnements de développement installés grâce à un CD donné par Valtech. La première session sur Google Web Toolkit était animé par Sami Jaber de DNG Consulting, ancien directeur technique chez Valtech Toulouse. Sami a été interviewé plusieurs fois dans 01 Informatique (ici, là sur JavaFX et ici sur RDA). Son blog parle aussi de .NET. Je retiens plusieurs points sur sa présentation. Tout d’abord il explique que GWT n’est pas réellement comparable à SilverLight ou Flex. Il n’y a pas de plugin et pas de rendu vectoriel. GWT est orienté application web riche. L’avantage de GWT est son intégration complète dans l’espace de travail du développeur. Le développeur écrit en Java une application similaire à de la programmation ave Swing pour décrire votre interface et vos actions. Ce code génère du Javascript avec l’outil GWT qui est ensuite déployé vers le client. L’un des points forts de GWT est la génération optimisée du Javascript selon le navigateur ainsi que selon la langue de l’utilisateur. GWT prend en charge la complexité de gestion des différents navigateurs et permet donc de ne se concentrer que sur la partie métier. A peu de chose prêt c’est ce que nous faisons avec mon équipe sur le framework Karma depuis 3 ans, pour la finance. Là où par contre GWT va plus loin, c’est son intégration dans l’environnement de travail. Chez nous la productivité n’est pas mirobolante car la phase de debug est assez délicate. Sur GWT la productivité est bien meilleure que notre solution.

GWT seul est pauvre en terme de composants graphiques. Cependant il faut savoir qu’un bon nombre des librairies Javascript sont en court de portage vers GWT. Sami a présenté une intégration de la librairie ExtJS dans le projet Ext GWT (ou GXT) qui m’a particulièrement intéressé. ExtJS est une librairie très puissante mais difficile à programmer proprement, car c’est du Javascript. Il existe bien une taglib pour ExtJS mais je ne suis pas convaincu. Ext GWT par contre est vraiment une librairie qui a un avenir au sens industriel du terme. Je vois déjà les applications chez Thomson-Reuters qui pourraient en bénéficier pour pas très cher. La librairie est disponible soit sous licence GPL v3, soit sous licence commerciale si vous souhaitez l’intégrer dans un produit. C’est la mode en ce moment.

GWT est donc une librairie et un moteur complet qui permet de travailler d’Eclipse (ou d’IDEA IntelliJ) rapidement, sans devoir déployer son application et perdre du temps. L’exemple de Sami utilisait Apache OpenEJB, un tout petit moteur EJB3 qui a l’avantage de se lancer très vite par rapport à un JBoss. Je ne parle même pas d’IBM Websphere et compagnie…

Deuxième séance: Microsoft Silvertlight beta 2 release 2. Je ne vais pas m’étendre. Très décevant. La présentation était moyenne, les 2 présentateurs ont proposé d’axer la présentation sur l’intégration entre l’utilisation de Microsoft Blend et d’un outil de développement C#/XAML afin d’expliquer la séparation entre le design graphique et la partie codage. Mon sentiment sur ce que j’ai vu, c’est que Silverlight n’est pas encore terminé. Certes on parle d’une béta. Mais en fin de présentation, l’un des speakers a expliqué que dès aujourd’hui il était possible d’aller en production avec un support qui sera assuré par Microsoft… Moi désolé mais je n’ai rien compris.

J’ai apprecié Microsoft Blend qui est un outil puissant pour construire son interface. Il écrase Flex Builder car il permet vraiment d’aller très loin sur les effets graphiques et de présentation. En terme d’ergonomie, je trouve qu’il y a encore quelques points à clarifier, mais l’outil est utilisable pour faire une interface très sympa. Du côté de XAML et du pont avec la partie métier et service, une application cliente Silverlight est agnostique avec la partie serveur. Elle peut donc être client d’un Tomcat sans soucis. Silverlight supporte un grand nombre de modèle de communication comme REST ou RPC. Il y a une couche de sécurité que je n’ai pas vu du côté de Flex. Anecdote cependant qu’un des présentateurs a laché : le contenu XAP d’un fichier silverlight est placé dans le cache du navigateur. Il serait possible de récuperer ce contenu pour le décompiler et en faire ce que l’on veut. Il explique donc qu’il faut faire attention à ne pas stocker de choses sensibles dans l’application, mais à aller les chercher sur le serveur. Ce qui me paraît logique.

Quoi d’autre sur Silverlight ? je vous passe les manipulations assez acrobatiques que nous avons dû faire car il y a un souci de Namespace sur la dernière version de Blend. C’était folklorique. Moi en tant que client j’attendrai encore un peu avant de m’en servir pour un client final. Je n’ai pas du tout aimé la partie C#. Cela dit, Silverlight a aussi un support pour PHP et Ruby. Donc on peut envisager d’écrire autrement la partie Page de l’application. Voili voilà.

Nous avons terminé la journée par la présentation qui m’a le plus bluffé : Adobe Flex. Je connais bien la techno puisque l’an passé j’ai réalisé tout un prototype avec Flex de l’une de nos applications. Je voulais rester afin de voir comment présenter Flex aux gens qui ne connaissent pas. Yann Chevalier de Baao nous a fait une superbe présentation. C’est un très bon speaker et je pense que toute la salle a réussi à réaliser les ateliers qu’il présentait. Nous avons codé un player de vidéo en Flex, avec une timeline, des boutons Pause et Stop et un compteur de temps. Cela permet de voir comment utiliser le Designer pour créer l’interface. Ensuite comment binder un composant à un événement. Comment déclarer un composant réutilisable… Bref une très bonne présentation. Rien à dire, je reste convaincu que pour l’instant Flex a une bonne longueur d’avance sur Silverlight. Flex est pensé par des graphistes, des ergonomes, des développeurs Flash qui ont une grande expérience du Web là où Silverlight est orienté développeur. Cependant j’ai vu qu’en terme de rendu, Silverlight est plus puissant dans ses effets graphiques. Là où pour l’instant cela pêche un peu, c’est que des applications avec de la vidéo et des cubes qui tournent, il y a peu d’intérêt à en faire… Nous sommes encore en phase de transition vers du Web un peu plus riche, ce que GWT qui reste sur du HTML et du JS fait très bien.

En conclusion, je suis reparti avec un tee-shirt GWT. C’est pas marrant à dire mais les teeshirts Silverlight sont restés sur les tables de la salle d’accueil. Problème de publique je pense. Les gens présents étaient en majorité des pro-Java et malheureusement le fossé continue à se creuser. J’en suis responsalbe aussi en faisant du bashing ici. Mais je ne vais pas pipoter en racontant que c’est une techno mature et prête à être mise en production chez un client, un trader, dans une salle de marché… C’est une bonne techno mais avec un concurrent comme Adobe Flex et un produit comme Thermo qui devrait bientôt arriver, la concurrence va être rude pour Silverlight. A noter en juillet nous devrions avoir une présentation sur Flex par l’équipe d’Adobe France aux Paris Java User Group (Paris JUG).

Le coeur de mon métier, c’est le client riche. Avec mon équipe nous nous occupons d’un framework java propriétaire qui fonctionne en client léger dans IE ainsi qu’en mode client lourd (swing). Aujourd’hui je me rends compte qu’il est encore difficile de faire accepter l’évolution de l’architecture qui est en place. Nous passons d’un client lourd installé sur le poste de nos clients à une architecture déployée J2EE dont l’interface fonctionne dans un simple navigateur. Nous avons fait de gros efforts pour que l’application web soit aussi interactive que possible. En quelques sortes, cela fait plus de 2 ans que nous faisons de l’AJAX avant même que ce terme ne soit publié il y a maintenant 2 ans.
Et honnêtement le résultat est là.
Des tableaux éditables qui s’exportent vers Excel ou PDF, des graphiques avec JFreeChart, des blotters de données du marché qui se mettent à jour en temps réel… le tout avec du HTML, du CSS, des Javascripts et des composants HTC. Bref on est au limite de ce que peut faire un navigateur tel qu’IE6 sans aucuns plugins. Mais ça marche !

Aujourd’hui il y a encore quelques blocages qui font que nous avons ressorti le client lourd des cartons (Swing). Il y a aussi un coût plus important pour développer une interface riche web qu’une interface classique car les technologies actuelles (css,html,js,htc…) si l’on peut parler de technologies, ne sont pas très bien maîtrisées ou enseignées.

Ensuite sachez que tout n’est pas rose dans le monde AJAX. Ne vous emballez pas trop vite pour toutes ces librairies javascript comme Scriptaculous ou Prototype. Certes, elles vous font gagner du temps. Mais malheureusement elles ne sont pas toujours exemptes de bugs. Attention aussi au navigateur de Microsoft. Je pense particulièrement à Internet Explorer 6 (avant le SP2) et son moteur javascript. J’ai rencontré 2 fois un problème de fuite mémoire en javascript. Très difficile à identifier.

Pour revenir au débat « client riche/client lourd », je vois 2 soucis: je pense qu’il faut maintenant se tourner vers des technologies plus avancées pour faire un vrai produit fonctionnant dans un navigateur. J’ai testé Adobe Flex2 ainsi que Microsoft Expression Blend. Ces 2 produits sont adaptés pour construire un produit avancé qui fonctionnera en mode client lourd comme en mode client léger. Pour la technologie d’Adobe, Apollo AIR permet de faire fonctionner une application Flex en mode client lourd. Une syntaxe XML permet de définir l’interface, le MXML.

Chez Microsoft, la Beta 2 d’Expression Blend m’a agréablement surpris. Elle permet de construire une application qui fonctionnera avec le .Net framework 3,5. Elle peut fonctionner en client lourd comme en client léger grâce à Silverlight.

Adobe Flex 3 m’a semblé plus pratique au niveau des Layout Manager pour construire mon interface. Il est possible de définir un ensemble de composant et de les sauver dans sa boîte à outil afin de pouvoir s’en resservir. C’est aussi vrai pour Expression Blend. Du côté de Microsoft, l’éditeur est plus puissant. Il est moins facile à prendre en main mais la séparation entre l’interface et la partie dynamique est plus simple que chez Adobe. Je pense qu’il ne faut pas néglier ce que propose Microsoft. Nous arrivons à une solution mature pour développer à la fois en mode client lourd et en mode client léger.

Maintenant réveillons-nous un peu: je ne suis pas entrain de jeter aux orties tout le boulot web, et ce qui se passe derrière le décor. Je pense qu’il faut investir et commencer à regarder sérieusement Adobe Flex et/ou la couche Windows Presentation Framework avec Silverlight de Microsoft. Par contre je ne pense pas qu’il faille jeter l’architecture service J2EE pour autant. Et c’est l’un de mes soucis. On me demande de faire du client lourd. Du vrai client lourd 2-tiers avec la base de données et des services financiers déportés. Pour ma part, ma vision est que l’on devrait conserver un serveur d’application afin d’effectuer un certain nombre de services (profiling, authentification, authorisation…). Sur le serveur d’application, le coeur du produit continue à fonctionner. EJB3 ou pas, peu importe. En conservant une architecture Web+J2EE il reste possible de fonctionner en mode client léger dans un navigateur comme en mode client lourd déporté. Je pense que la méconnaissance de l’architecture J2EE nous conduit aujourd’hui à revenir en arrière, ce qui est vraiment dommage…

Deuxième réflexion: nous avons plusieurs produits. Nous offrons à nos clients une Suite qui regroupe tout ou partie de ces produits. Or si vous pensez en terme de client lourd, il devient rapidement compliqué de construire et livrer le binaire adapté à ce que le client a acheté. Pareil pour ce qui concerne les installations de patches… Avec 6 produits majeurs financiers, je peux vous assurer que vos équipes vont passer leur temps à mettre à jour tel ou tel produit… Mais bon, c’est envisageable.

En conservant une architecture 3 tiers, il est possible facilement d’ajouter ou de retirer tout ou partie d’un produit, car le coeur du produit n’est pas dans le client riche mais déporté sur le serveur d’application J2EE. Par ailleurs on concentrera les efforts sur l’ergonomie, l’interface du client, mais on se contentera d’effecteur des appels vers le serveur pour les traitements…

Voilà c’est tout… ce sont quelques idées qui me trottent dans la tête. L’arrivée des technologies de type client riche va bousculer une nouvelle fois nos connaissances d’architecture. Il faut penser maintenant à ce qui se passe derrière l’écran et la jolie fenêtre animé dans un écran Flex… Pensez-y si vous faites du client riche…

Par rapport à d’autres librairies comme tomahawk qui a du mal à s’intégrer avec Seam, ICEFaces a été testé et validé avec JBoss Seam. Pour ma part je cherche un composant jsf d’agenda qui tienne la route. J’aimerai bien tester MyFaces Schedule mais pour mettre en place tomahawk dans JBoss il faut désactiver l’implémentation jsf par défaut. Je n’ai pas encore testé, car je regarde une autre alternative utilisant Google Agenda. L’idée est de récuperer l’agenda via du HTML, ce que j’ai réussi à faire hier soir sans trop d’effort. Google met aussi à disposition une API Java pour poster des évenements vers un agenda Google. Bref j’ai tout, sauf qu’au niveau de l’ergonomie l’agenda qui s’affiche en mode HTML est moins sympa à utiliser que la vraie version de Google Agenda… Donc me voilà revenu au point de départ.

Sinon JBoss Seam est vraiment puissant… mais chut, tant pis pour ceux qui se réveilleront trop tard…

Une application Flex s’écrit avec du XML, plus précisement du MXML. Il suffit de décrire la composition de l’application, et de déclarer ce que voit en fait l’utilisateur. Il est aussi très facile de créer des composants ou des vues réutilisables. MXML me fait penser à Xaml de Microsoft ou encore à la syntaxe XUL de Mozilla. Cependant il y a aussi ActionScript, un langage de script qui vous permet de brancher des évenements, d’appeler des Web Services ou des applications de type REST via HTTP.

J’ai bossé tard hier soir après avoir installé le Flex Builder basé sur Eclipse RCP. Je me suis lancé sur l’écriture de quelques écrans standards de nos applications utilisant notre framework Java « pour voir ». Et franchement le résultat est très sympa. En terme d’ergonomie, on est loin devant AJAX, HTML et CSS. Nous utilisons même des composants HTC de Microsoft pour faire des tableaux éditables ou le support du drag-and-drop. Avec Flex tout est plus facile, simple et propre. Et évidemment je peux faire tourner mon application dans Firefox, comme dans Internet Explorer.

En fouillant sur le web ce matin j’ai déjà reperé quelques blogs, et quelques sites sympas.

Kuler est un module pour sélectionner la couleur primaire et les couleurs secondaires d’un site web. Cela vous permet de faire un site « beau » et pas un site d’informaticien avec 3 couleurs moches.
http://kuler.adobe.com/

Le blog de Bruce PHILIPS est très sympa car on suit au jour le jour ses progrès et ses découvertes avec Flex. Il a maintenant une sacré maitrise et j’y ai trouvé un bon tutorial pour faire la partie login de mon application. http://www.brucephillips.name/blog/index.cfm 

Si vous voulez voir une liste des composants, des layouts et des charts de Flex vous pouvez regarder sur ce site: http://examples.adobe.com/flex2/inproduct/sdk/explorer/explorer.html 

Enfin pour terminer je voulais mettre ici en ligne le fichier SWF réalisé cette nuit, mais JRoller refuse que j’upload des SWF. J’ai donc simplement mis une capture d’écran…
Désolé pour l’image, j’essayerai de mettre un fichier SWF sur un autre serveur.

Flex est simple à apprendre, et le Flex Builder me paraît franchement indispensable pour gagner du temps lors de la création des écrans. Cette technologie au premier coup d’oeil fonctionnera bien si du côté serveur, l’architecture est de type REST, si vous pouvez générer du XML ou encore mieux, si vous disposez de Web Services.
A tester donc.

Qu’est-ce qu’un client riche ?
Un client riche est un système qui est hébergé sur un serveur pour faciliter les mises-à-jour et le déploiement, tout en offrant une interface riche à l’utilisateur. Il n’embarque pas toute la logique de l’application. La majorité des traitements sera effectuées côté serveur. Cependant l’ergonomie et la richesse fonctionnelle offertes à l’utilisateur sont très proches d’un client lourd classique.

La conception d’une application en mode page au sens Web du terme tend à disparaître. Aujourd’hui une application doit offrir une ergonomie et une navigation par composant plutôt que par page d’état comme ce fut le cas au début des applications webs.

Idéalement une techno doit proposer des composants graphiques de haut niveau tout en restant facilement déployable. D’autre part, quelque soit la techno retenue, la notion de conteneur sur le poste client apparaît. En règle général le navigateur internet est suffisant.

1. XUL
XUL (prononcer [Zool]) est le précurseur des technologies de présentation web. Il s’agit d’un langage XML décrivant des composants (Menu, ComboBox) destiné à remplacer le langage HTML. Dans les faits aujourd’hui, XUL est porté par la communauté open-source Mozilla, mais Microsoft s’y intéresse aussi.
Un exemple de site utilisant XUL: http://www.georgenava.com/
Ce site ne fonctionne que si vous avez Firefox ou Mozilla. Il ne fonctionne pas avec Internet Explorer.

2. AJAX
AJAX (Asynchronous Javascript And XML) n’est pas réellement une nouveauté même si en ce moment c’est un sujet chaud dans la communauté Web. Au départ il ne s’agit que d’un article écrit par un consultant destiné à formaliser un mécanisme Asynchrone qui permet de rafraichir une page dans un navigateur sans devoir recharger toute la page. AJAX fonctionne avec Internet Explorer et Firefox car il s’agit ni plus ni moins que du? Javascript côté client. Premier avantage donc: la portabilité.
AJAX du côté serveur n’impose pas de modèle de programmation. Il n’y a donc aucunes normes XML, ni DTD. Le message envoyé par le serveur est au format XML et le client le reçoit de manière indirecte. Il peut alors afficher des informations en utilisant du Javascript, du Dynamic HTML et des feuilles de style.
Donc pour résumer: le serveur envoie un message XML, le navigateur le reçoit via un objet XMLHttpRequest de manière asynchrone. Une librairie Javascript modifie la page, change la couleur d’un combo, fait apparaître un menu déroulant ou masque un tableau par exemple.
Puisqu’une démo est mieux qu’un long discours voici quelques sites utilisant AJAX:
GoogleSuggest
Si vous tapez JAV puis vous attendez un instant, votre navigateur envoi au serveur ces 3 lettres. Le serveur retourne une réponse au format XML en utilisant un format propriétaire à Google. La partie Javascript d’AJAX dans le navigateur lit la réponse, construit alors un DIV en HTML (une boîte) et vous liste le nombre de site parlant de java, javascript…
AJAX permet d’ajouter des mécanismes côté client pour ne recharger qu’une partie d’une page internet. Il existe aussi des librairies Javascript destinées à faciliter les développements d’application AJAX comme ScriptAcuLous (http://script.aculo.us/) ou surtout ProToType (http://prototype.conio.net/). Elles permettent de coder des fonctions de Drag-and-drop par exemple (http://wiki.script.aculo.us/scriptaculous/show/DragAndDrop)

Les inconvénients ?

• Pas de DTD/XSD côté serveur concernant le XML. Chacun fait ce qui lui plait.
• Le Javascript est difficile à coder/débugger et n’est pas un langage très puissant.
• Difficile à tester en phase de développement
• Il existe des composants riches mais ils sont payant
• Pertinence et pérennité du JavaScript dans 2 ou 3 ans ?

Les avantages?

• Simple à mettre en ?uvre
• Puissant
• Effets intéressants offrant de nouvelles possibilités en terme d’ergonomie
• Compatible Internet Explorer et Firefox dans la mesure où le code JS l’est
• Communauté de développeur très active
• Bientôt intégré dans des composants Java Server Faces (JSF) pour faciliter le codage.

Outils AJAX:
- ATLAS (Microsoft) framework intégré dans Visual Studio et .NET destiné à simplifier le développement d’application Web. A noter que Microsoft a annoncé que d’ici 2 ans, Office 13 sera majoritairement en mode serveur lourd-client riche et que c’est l’une des raisons qui font que Microsoft pousse cette techno. Voir l’article d’un des gourou de Microsoft http://weblogs.asp.net/scottgu/archive/2005/06/28/416185.aspx
Est-ce un effet d’annonce de Microsoft ou vas-t-on voir un nouveau système pour créer une application riche ?

- SAJAX: Toolkit de dév pour AJAX (http://www.modernmethod.com/sajax)

- DoJoToolKit http://dojotoolkit.org) API Javascript pour résoudre les problèmes de portabilité entre IE et les autres navigateurs.

3. Macromédia FLASH
Sans doute pour moi la révélation de cette présentation. Je pensais que Macromedia Flash servait soi à faire un site joli et animé, soit à afficher des bandeaux de publicité lorsque Firefox bloque les pop-ups. Et bien non? nous sommes en 2005 et ce que j’ai vu était vraiment intéressant.

Flash est une techno créée par Macromédia (qui appartient à ADOBE) utilisant un plug-in installé sur un navigateur Web. Conçu à l’origine pour l’animation Web, Flash est un outil pour les graphistes ou les animateurs. Aujourd’hui l’évolution est le fait que Flash peut aussi servir à faire des applications type Client Riche.
Exemple 1: Le site internet du Club Med utilise Flash pour vous permettre de trouver un séjour sur mesure.
L’évolution est du côté de la conception. La première monture du Studio Flash était destinée à des animateurs Web, avec une ligne de temps et des outils de déformation vectorielle. Ce qui est nouveau c’est la phase de développement et de rendu dynamique.

Il existe 2 solutions basées sur Flash: Macromedia Flex et Laszlo

Macromedia Flex:
Solution propriétaire et payante de Macromédia. Il s’agit d’un studio qui vous permet de construire votre page en utilisant des composants (Label, Buttons, ComboBox?).

Flex se décompose d’un fichier MXML pour décrire l’interface et d’un fichiet ActionScript pour décrire ce qui se passe et les interactions entre les composants. Ces fichiers sont compilés par un conteneur de Servlet (comme JSP) pour générer un flux binaire de type Flash qui sera envoyé au client. Etant donné qu’il ne s’agit que d’une servlet il est donc possible de rendre dynamique une partie du contenu XML par exemple.

Un plugin Eclipse pour FLEX est en cours de réalisation.

OpenLaszlo est basé sur le même système que Flex, à la différence prêt qu’il s’agit d’une initiative Open-source. Démo disponible à cette adresse : http://www.laszlosystems.com/demos.
La société LaszloSystem propose des services comme le fait Jboss Inc. en terme de support si nécessaire.
Flash est finalement intéressant car les outils de conception de page existent déjà et permettent donc de bien séparer la partie GUI de la partie data. Cependant difficile de se rendre compte si les données dynamiques sont faciles à gérer ou non.

4. Java Web Start
JWS ajoute à Java des fonctionnalités de déploiement, de gestion de cache et d’exécution distante. A ce titre c’est donc une technologie pour Client riche. JWS fonctionne via un navigateur internet ou non. Permet de mettre à jour rapidement les clients répartis, tout en ayant une richesse fonctionnelle complexe.
En gros inconvénient, il faudra recoder un container pour remplacer ce qu’offre le navigateur Web (partie réseau, chargement du contenu, gestion Proxy, CSS?)
JWS ne convient que si le client riche doit vraiment avoir des fonctions qu’un navigateur web ne peut pas offrir.
En terme d’avantage, on revient au modèle client-serveur classique, ce qui est beaucoup plus facile à coder/débuger que via le Javascript par exemple.

5. Eclipse Platform
Eclipse est un éditeur Java bien connu mais surtout un moteur de rendu appelé Platform.
Ce système est composé d’un ensemble de service, de widgets, de gestion des ressources qui permettent d’utiliser le squelette d’eclipse comme base de dévelopement de client lourd.
D’autre part, il est possible d’intégrer d’autres plugins et donc d’enrichir son application facilement. A noter que l’on peut utiliser JWS pour installer une application basée sur Eclipse.

http://www.eclipse.org/platform/index.html

Conclusion
Les clients riches seront fortement présent dans les années à venir car les navigateurs Web deviennent aussi de plus en plus puissant. La facilité de déploiement, l’absence de gestion de mise à jour sur le poste client et l’ergonomie riche sont les critères qui font un client riche. On parle beaucoup d’AJAX et je sais qu’il existe des composants JSF (côté serveur) qui permettent de s’interfacer via J2EE avec les applications métiers. Il sera donc certainement facile d’ici quelques mois de tester et voir si ce genre de solution peut nous intéresser.
Flash via Flex ou Laszlo offre le meilleur résultat en terme de rendu côté client. N’ayant pas vu en détail le côté serveur, il est difficile d’estimer si cette technique est adaptée à des données très dynamique comme dans la finance. Java Web Start et Eclipse Platform sont deux solutions pour développer des clients riches sans retomber dans le modèle client-serveur.