Avant de commencer, et avant qu’on me le signale, je souhaiterais juste ajouter que le titre de cet article peut s’adapter a d’autres langages ou frameworks :
Ca marche aussi pour Rails (par exemple) , qui n’est pas la solution a tous les problemes.

Aujourd’hui, il appartient a l’architecte et au developpeur, chacun s’appuyant sur son experience, de se faire un chemin sur les routes tortueuses des frameworks Web, et de s’adapter au besoin.
Dans certains cas par exemple, des frameworks lightweight seront suffisants (les RIFE, Stripes, Grails, Rails), dans d’autres cas, toute la batterie de services fournie par JEE sera nécessaire, et des frameworks sachant en tirer partie , comme Spring, seront adaptes.

Je suis tombe en cette fin de semaine sur un article de Bruce Eckel , “Hybridizing Java” sur Artima, dans lequel Monsieur ‘Thinking in X’, et particulierement de Thinking in Java (dont les différentes éditions ont été mon livre de chevet pendant quelques années), nous explique sa vision sur les RIAs , et pourquoi Java et Ajax ne font pas vraiment l’affaire.

Globalement je suis assez d’accord avec lui, a quelques differences que je vais tacher de mettre en evidence dans cet article.

Dans le meme esprit, Bruce Tate avait parle de J2EE (plus vulgairement, pourquoi J2EE est un beau bordel) dans son livre Beyond Java, et expliquait pourquoi un language comme Ruby et un framework comme Rails pouvait faire l’affaire, dans 80% des cas dirons nous.

Bruce Eckel commence son discours sur Java, et particulierement les Applets ainsi que les applications JavaWebStart:
pourquoi ne sont elles jamais devenues des technologies privilégiées pour les RIAs.

L’un des plus grands problemes etant :
- la barrière de l’installation du JRE sur le poste client pour les applets comme pour les applications desktop: difficile pour la plupart des utilisateurs lambda du web.

JavaWebStart quant a lui, a beaucoup ameliore les choses :
evidemment , le poste client doit toujours etre dote d’un JRE; dans une entreprise, ce n’est pas reellement une barriere sachant que la plupart du temps, les applications sont installees et mises a jour regulierement via le reseau depuis des serveurs.
Il souleve neanmoins les problemes de cohabitation de plusieurs Jdk (1.3, 1.4, 1.5, 6): nous, developpeurs, sommes habitues a switcher de jdk depuis notre IDE et lors de nos tests, mais pour un utilisateur lambda…c’est toujours le meme probleme.
JavaWebStart ameliore significativement le deploiement, mais fonctionne toujours dans le meme esprit qu’une applet, avec une “sandbox”. Des policies de securite doivent etre configurees afin de donner des droits a l’application desktop (pour ecrire par exemple sur le disque dur du poste client). De meme , il faut signer les jars de l’application. Cependant , des solutions comme NetX facilitent les choses : permettent de profiter de la technologie JavaWebStart en faisant sauter quelques verrous (signatures des jars par exemple).

Il souligne le manque de support Multimedia de Java. L’API JMF (Java Media Framework) n’a jamais supporte le MP3 par exemple. Pour avoir travaille quelques temps avec JMF sur une application de visio-conference, je me suis bien rendu compte de de la difficulte a supporter les differents devices (WebCam, Audio).

Il ne faut pas oublier egalement la complexite de Swing au depart qui peut arreter bon nombre de developpeurs. Des API sont apparues telles que SWT (du cote d’Eclipse), et toutes les familles des RCP (Rich Client Platform) de chez Eclipse, Netbeans, et recemment Spring , pour tenter de remedier a ce probleme. Je ne serais pas aussi radical que Bruce Eckel, et je dirais que ces solutions devraient tout de meme etre etudiees sur tout projet , dans lequel une application desktop devrait etre implementee.

Viennent ensuite quelques explications sur les problèmes liés à Ajax :
- Coût : les applications ajaxifiées (HTML, CSS, Javascript) sont la plupart du temps difficiles et chères à développer.
- Confrontation du developpeur aux différences entre les navigateurs (IE 5/6/7, Firefox, Safari, Opera), plus varies aujourd’hui qu’au debut des annees 2000 (IE 4, Netscape).
Ormis les grosses différences pour XMLHttpRequest, on est toujours confronté a un moment ou a un autre à un problème quelconque lié aux navigateurs (Fonts, marges…). Bien qu’aujourd’hui certains frameworks ‘cross browser’ tels que Prototype ou Dojo (pour ne citer que les plus connus) resolvent ces problemes, dès qu’on veut coder soi-meme, pas d’autre choix que devenir un expert de chaque navigateur.

Plusieurs frameworks ont pourtant radicalement change la facon de developper des applications Ajax:
- je commencerai par Rails (s’appuie sur Prototype et script.aculo.us), qui permet de se passer de coder en Javascript pour tout ce qui est Ajax. Dans Rails, des helpers permettent de developper des composants ajaxifies en Ruby.
- Google a sorti son GWT (Google Web Toolkit), un framework ’serveur’ , qui permet de developper des applications Ajax en Java. Le code client etant retranscrit ensuite en Javascript. Surveiller ce framework, qui est annonce comme un des frameworks phares de 2007.

Finalement , Bruce en arrive a la conclusion que Flash, et particulierement Flex, apparu en 2004 et aujourd’hui mature, serait la plateforme de choix des RIAs :
La présence du plugin Flash sur 98% des ordinateurs (d’apres Adobe), son portage sur les 3 principaux OS (Windows, Mac OS X, Linux), le support du multimedia (MP3, divers formats vidéo, webcams), le Look & Feel agreable des UIs, la capitalisation sur Javascript non perdue avec ActionScript (devenu OpenSource dans sa version 3.0 recemment), le paradigme ‘write once run everywhere’.
Des frameworks autour de Flex existent, tel que Cairngorm, et surtout, l’annee 2007 va etre marquee par la sortie du tres attendu Apollo, qui permettra aux applications Flex/Flash de ’sortir du browser’.

Ce qu’il faut savoir au minimum sur Flex (2) :

Flex offre un langage de description d’UI appelé MXML, un langage de scripting (ActionScript) pour toute la logique.
Le Flex 2 SDK (compiler) est desormais gratuit (ce qui n’etait pas le cas avec la version 1.5), et ainsi, chaque developpeur est invité à consacrer un peu de temps pour tester le produit.
Adobe a rendu payant l’IDE FlexBuilder, réécrit il y a 2 ans sur une base d’Eclipse ( l’IDE peut être utilisé un mois a l’essai).
Certains composants, tels que Flex Charting, sont restes quant a eux payants.
Il existe aussi un bridge entre Flex et Ajax desormais (depuis la version 2.0).

L’UI Flex communique avec le serveur de plusieurs facons (plus ou moins performantes) :

AMF (Action Message Format): passerelle d’objets distants (Java Beans, EJB, POJO). AMF est un protocole binaire de transferts de données (son utilisation est conseillée par Adobe, car plus performant que SOAP).

XML avec les HTTPServices (REST) ou SOAP Service.

Il est egalement possible d’utiliser sur le serveur des services plus avancés :

le serveur Flex Data Services (gratuit pour une CPU) : Flex Data Services permet developper des applications non seulement riches en terme d’interface, mais aussi en terme d’échange des données entre les tiers. Déployé en tant qu’application J2EE, Flex Data Services offre une connectivité améliorée entre le client et les composants coté serveur (données, business logic). Basé sur une architecture orientée message, il s’intègre avec les middlewares du marché et fournit des services améliorés tels que :
Data push server (sans polling de la part du client), publish/subscribe messaging.
Il facilite le développement d’applications de collaboration, et d’applications disconnectées.

Flash Media Server (anciennement Flash Communication Server) : pour tout ce qui est diffusion (broadcast) de flux audio/video.

De facon generale, la plateforme de choix cote serveur est J2EE, avec une preference pour JRun , rachete par Macromedia a Allaire il y a quelques annees (mais pour Flex, d’autres serveurs sont supportes tels que Oracle AS 10g, Tomcat, JBoss, BEA). Neanmoins, les Labs d’Adobe travaillent sur des solutions d’integration avec d’autres technos; par exemple PHP ou Rails (Rails RIA SDK).
Un bresilien a recemment cree un Flex Scaffold, a l’image du scaffold dans Ruby on Rails.

Quelques exemples interessants :

Flex 1.5 Application Examples

Un BarCode Reader fait avec Flex. Fonctionnalite identique a la fonction de scan des barcodes dans Delicious Library.

Une alternative open-source à Flex est OpenLaszlo :
Comme pour Flex , l’UI est du Flash. Pour ce qui est scripting ce n’est plus ActionScript mais un dérivé de Javascript.
Quelques applications ‘impressionnantes’ développées avec OpenLaszlo :
Une version Flash de l’outil Visio, Gliffy .
Le service de ‘discovery music’, Pandora .

Sinon d’autres alternatives Open Source a certains composants Flash existent :
OpenAMF repond a Flash Remoting
Gnash repond au Flash Player

Il faut egalement savoir que des applications Flash peuvent etre declinees dans le monde de la mobilite (PDA, Smart Phone) grace a FlashLite.

Pour avoir travaille avec Flex quelques mois (etude de comparaison Flex, OpenLaszlo, Ajax – maquettage d’une RIA avec Flex 1.5 au dessus d’une BackEnd Java Struts deploye sur Oracle AS 10g) voila les conclusions dans les grandes lignes :
- FlexBuilder facilite grandement la tache pour la creation de l’UI (Layouter evitant d’ecrire le MXML a la main)… suffisant pour une application relativement simple.
- Par contre, pour une application plus complexe, l’immersion dans le codage ActionScript est obligatoire, et l’utilisation d’un Framework (Cairngorm ou fait maison) est conseillee.
- Ne pas sous-estimer la partie infographie : si vous en avez le talent , sinon faire appel a des infographistes, la composition de widgets graphiques sera necessaire dans le cas d’un Look & Feel sortant des sentiers battus pour votre application.
- Par contre le grand avantage (par rapport a Ajax) est que le paradigme ‘Write Once Run EveryWhere’ est respecte : on ne se soucie plus du type de navigateur, pourvu qu’on ait un Flash Player. En gros, connaitre Java, Php, .NET ou Rails pour la partie Serveur, et cote client, la connaissance du couple MXML/ActionScript suffit.

Pour conclure, les defenseurs de Flash craignent cette annee l’arrivee de Microsoft Sparkle / Interactive Designer, pour developper des applications basees sur WPF (Windows Presentation Foundation), ex-Avalon . A surveiller egalement de pres.

Lecture :

Programming Flex 2 : Rough Cuts version

Flexible Rails