Pile technologique pour projet Flex

Une fois Flex choisis comme technologie de présentation, il reste à monter sa pile technologique pour son projet: accès aux bases de données, découpage en "couches", architecture globale de communication entre ces couches...

Voici un retour d'expérience, pour vous aider à choisir:

• accès aux données: plusieurs choix possibles. Si vous avez les connaissances et que vous voulez coller le plus possible aux standards, partez sur du JPA (Java Persistence API). Contrairement aux EJB 2.x Entity et à JDO, la spécification semble bien partie pour s'imposer. Après, il vous reste une multitude d'implémentations; Hibernate ou Oracle TopLink (Essentials) sont des bons choix. Du côté de mon équipe, qui n'a pas beaucoup de compétence mapping objet-base relationnelle, on est sur du iBatis, solution très légère et très propre, très simple à mettre en place.

• EJB ou pas EJB? Tout dépend de la taille de votre projet. Pour des projets petits ou moyens, plutôt simples dans les process et ne demandant pas une fiabilité extrême, pas besoin d'EJB, un Tomcat suffira amplement. Après, si vous vous orientez vers EJB 3, cela reste un choix très valable. Dans ce cas, il vous faudra un serveur implémentant la spécification complète. GlassFish est un des plus populaire actuellement. JBoss et Apache Geronimo sont également très bons, et du côté des commerciaux, Oracle WebLogic reste très bien, même si en perte de vitesse par rapport aux Open Source.

• architecture interne de l'application: orientée Services (au sens architecture, pas au sens marketing...), à base de Spring (beans), ou de Guice (projet Google) assez à la mode en ce moment. Si vous êtes sur de l'EJB 3, vous avez déjà tout ce qu'il vous faut (à travers les annotations notamment).

• communication serveur - client Flex: assurément BlazeDS se révèle être une excellente surprise. Utilisez le mode AMF si vous le pouvez (ce qui est certainement possible), pour échanger en mode binaire et optimisé entre le serveur et le client. Il est très simple de brancher BlazeDS sur Spring (je suppose que cela se fait également facilement avec de l'EJB 3)

Au final, pour notre petit projet (200 jours/h), on est arrivé à d'excellents résultats avec:
- Frontal Apache HTTP
- Apache Tomcat

- BlazeDS
- Spring
- iBatis

Très léger à mettre en place, et les développeurs ont facilement appris toutes ces technos.

Java EE: Evolutions depuis 1 an et demi

Après une période à bosser sur mes projets, je reprends le clavier.

Une petite question toute innocente sur theserverside.com m'a replongé dans l'époque des grandes questions sur quelle techno de présentation Java EE utiliser (lien vers mon commentaire).

La situation générale s'est un peu éclaircie, bien que je pense toujours que l'univers Web est en période de transition:

• HTML vieillissant (avec une version 5 qui n'en finit pas d'être repoussée, et dont le contenu ne cesse de bouger)
• de plus en plus d'intérêt pour des pages plus riches et dynamiques; pour des sites professionnels, forte pression des clients pour en intégrer
  
• côté AJAX, quelques grandes bibliothèques javascript(jQuery, Dojo, Prototype, Scriptaculous et consors)
• de l'autre côté (plugin Adobe Flex et Microsoft Silverlight), une évangélisation à marche forcée, sauf pour JavaFX qui est complètement largué, et dont on peut être sûr que la récente version 1 sortie récemment n'aura rien à voir avec la prochaine version vu le peu de moyens qu'y a consacré Sun (d'ailleurs, ça rappelle ce qu'il s'est passé avec Flex 1 & 1.5 et Silverlight 1, très différents des versions actuelles, notamment au niveau conceptuel)
  
• des frameworks Java EE qui intègrent de facto ou à l'aide de wrapper/adapter l'AJAX et les technos javascript, et un écrémage au fur et à mesure de ces frameworks
  
• une tendance des navigateurs à décupler les performances des interpréteurs javascript

Au final, pour lancer un projet JEE, on a le choix pour la couche de présentation entre:

• Google GWT, qui évolue vite, qui s'appuie sur du HTML/Javascript donc pas besoin de plugin, mais dont la programmation s'éloigne pas mal des classiques JSP (ce qui est de toutes façons normal pour une techno de présentation Web riche, et c'est plutôt une bonne chose, d'ailleurs - gérer des formulaires HTTP et des urls va vite devenir la préhistoire des applis Web). Mais:
  • très lié à Google; même si le framework est Open Source, si Google arrête tout, qui va se plonger dans le code Google pour gérer la compilation de l'interface (écrite en Java dans le cas de GWT) vers chaque navigateur (voir chaque version de navigateur) ?
  • repose tout de même sur AJAX; or, AJAX est un hack du mode de fonctionnement classique request/response du HTTP, ce qui impose de multiples contraintes, et les échanges se font en mode texte, ce qui n'est pas très optimatal pour les échanges client/serveur. Cependant, étant donné que l'interface est écrite en Java, rien n'empêche Google de développé un compilateur de Java vers Flash/Silverlight/JavaFX, un peu à la mode d'OpenLaszlo (mais en plus performant...)
  Au final, GWT vaut vraiment le coup, même si le coût (d'apprentissage) n'est pas négligeable (mais je vous rassure, ça reste abordable et c'est très élégant).

• Apache Wicket, basé sur une logique de composants, framework séduisant et très soutenu par une communauté très active. J'ai pas grand chose à en dire, ce n'est pas un choix que je retiens personnellement parce qu'il se base trop sur du HTML pour la partie interface, et que pour moi ce n'est pas vraiment un choix d'avenir, mais les avantages sont aussi la simplicité et la courbe d'apprentissage moins abrupte que GWT (et Flex/Silverlight).
  

• JSF (avec Facelet et la couche intermédiaire JBoss Seam); là, je n'y crois plus trop. Trop compliqué, revu mais trop tard avec la version 2 qui sort cet hiver (ou pas...).

• Adobe Flex; le choix que j'ai fait pour mes nouveaux projets. Courbe d'apprentissage assez abrupte, nécessité d'avoir un plugin, même problème que GWT pour ce qui est du projet Open Source avec la dépendance à un éditeur (Adobe en l'occurence).
  Au bout d'un an, un développeur est capable de faire des choses vraiment biens, même si la logique de positionnement et redimensionnement des composants est ardue à comprendre lorsque l'on est habitué à faire des clients HTML (ça se rapproche des interfaces clients lourds comme le Swing, même si c'est tout de même beaucoup plus simple et élégant au niveau de la gestion des évènements).
  Et une fois que l'on maitrise un peu la techno, c'est que du bonheur (y compris pour le chef de projet, avec une productivité bien accrue par rapport aux frameworks MVC basé sur du HTML - Struts 1 & 2, Spring MVC...)
  

• Microsoft Silverlight; techno encore trop jeune, mais Microsoft met vraiment les moyens en ce moment. Sans doute promis à un bel avenir.
  

Pour passer rapidement sur les autres choix, certaines technos de bonne qualité ne vont, à mon avis pas tenir trop longtemps, par manque de visibilité ou par concept un peu dépassé:

• Tapestry, qui change du tout au tout entre les versions, et qui se dilue parmi les autres technos ci-dessus
  
• Struts 2, qui reste un choix lorsque l'on ne veut pas faire "le grand saut" vers une appli Web riche, mais qui est tout de même bien complexe et contraignant
  
• Echo, pas trop de visibilité, en perte de vitesse par rapport à GWT et Flex
  
• OpenLaszlo, pas assez de moyens par rapport à Flex (ils peuvent pas faire grand chose, malgré leur talent, face à une boite énorme comme Adobe, qui mise à fond sur Flex pour son futur)
• Spring MVC, Webworks... même problème que Struts 2: un peu dépassés
  

Au final, le paysage se clarifie un peu, mais reste assez flou. Je suis persuadé que le Web va évoluer vers une ou plusieurs technos riches et se détourner du HTML pour la plupart des sites professionnels. Google finira par faire son Flex/Silverlight, quitte à ce que ce soit du "Full Javascript" dans son navigateur Chrome, ou un plugin (native client, ou autre - par exemple un plugin similaire à celui développé il y a peu pour ajouter des conversations vidéos à Google Talk dans GMail).
Ce même HTML, du fait de sa simplicité, va certainement continuer à vivre pour les sites peu intéractifs.

Et en toutes franchise, je doute que ces technos riches qui vont changer le Web soit l'une de celles cités plus haut... on est encore en période de transition pendant quelques années.

Du mouvement dans le monde des RIA

Au cours de la conférence MIX07, microsoft a présenté de multiples démonstration de sa technologie Silverlight (v1.1 alpha - amusant sachant que la version 1.0 est toujours en bêta). Les démos semblent vraiment impressionnantes, la grosse machine qui s'était mise en route il y a quelques temps semble enfin offrir du concret (http://www.fredcavazza.net/index.php?2007/04/30/1507-mix07-las-vegas-jour-1-suite) .

En plus, l'architecture et les concepts ont l'air au point; les RIA (Rich Internet Application) vont-elles enfin percer au delà de l'AJAX mis en place plus ou moins maladroitement et simplement un peu partout ?

Parallèlement, Sun et le monde Java réagissent enfin sur ce créneau qui est à mon avis clé avec JavaFX. On en est par contre ici véritablement aux balbutiements.
Est-ce que la plate-forme Java est maintenant condamnée à être suiveur des technos microsoft? heureusement que la communauté autour de Java est active (Open Laszlo, Adobe Flex, et la multitude de framework Ajax), mais ces initiatives n'ont pas la puissance marketing et l'assise financière d'un projet stratégique de microsoft.
Avec JavaFX, on peut avoir le pire ou le meilleur. La technologie sera apparemment Open Source, donc j'espère bien qu'on finira par quelque chose de plus simple, rapide et utilisable que Swing.

Au final, tout se dirige, selon moi, dans la bonne direction: un langage simple, dédié à l'interface, concis et clair (que ce soit le XAML de microsoft, le MXML + ActionScript de Flex, ou le langage FX-Script de JavaFX qui semble très élégant).

Vers une généralisation des applications distribuées?

Depuis plusieurs années, les technologies distribuées ont tenté de s'imposer. Si cela marche très bien dans le cas d'applications spécifiquement adaptées (les ERP par exemple), ce type d'architecture n'a jamais été vraiment pertinent dans le cadre d'applications plus traditionnelles (la grosse majorité des applications). J'ai l'impression que ça change.

Globalement, j'ai vu passer 3 étapes:

Etape 1: une première grosse tentative plus ou moins viable
Les concepts intéressants de CORBA (trop complexe pour une application lambda) ont amené un intérêt (surtout de la curiosité) dans le monde de l'entreprise pour ce type d'applications. Cette curiosité a été renforcée par les EJB 1 et 2, un véritable engouement s'est créé.
Malheureusement, CORBA est trop complexe et complètement inadapté pour une application lambda (ça n'a jamais été son but), de même que l'étaient les EJB 1 et 2, inadaptés dans 95% des cas (design Sun de référence pour les applications Web, mais les limites de l'architecture sont trop contraignantes et la complexité est abusive).

Etape 2: de la curiosité à la solution élégante
Faisant suite au rejet des EJB par la communauté des développeurs nouvelles technos, les conteneurs plus léger d'inversion de contrôle (ou injection de dépendance), ont apporté une architecture claire et saine sur ces concepts déjà intéressants.
De manière similaire, la remise en cause de CORBA mène à l'apparition des Web Services, plus légers, basés là encore sur une technologie qui suscite beaucoup de curiosité de la part des décideurs: le XML (dont on parle à tort et à travers, et qui devient la solution miracle à tous les problèmes d'interconnexion - du moins dans la tête des directions informatiques...).
Les technologies de bus de messages se répandent et maturent.

On commence à parler de SOA, architecture orientée services, qui remet en cause le principe d'encapsulation des langages orientés objets ("les attributs des objets et les méthodes sur ces attributs sont dans la classe" devient "l'objet contient uniquement les données - POJO ou Javabean, les traitements sont déportés dans des classes de service"). Cette architecture entraine pour toute application, distributée ou non, de grands bénéfices en terme de maintenabilité et d'évolutivité).

Etape 3: Généralisation

Tout s'intègre très bien: SOA se généralise et bénéficie très bien des concepts de conteneurs légers, se prête très bien à la mise en place de Web Service et cerise sur le gateau, permet une évolution très transparente vers un style distribué: à partir du moment où les services sont clairement et proprement définis, on peut selon les besoins en distribuer certains très facilement.

Les concepts de grilles de calcul et de caches répartis sont connus et les décideurs informatiques s'y intéressent et investissent dessus, le plus souvent avec grand succès. Des startups qui ont développé ces produits enregistrent des succès flamboyants (Datasynape pour les grilles de calcul, Gigaspaces et Tangosol Coherence - racheté par Oracle il y a peu - pour les caches distribués avec haute valeur ajoutée).

J'ai l'impression que ce type d'application est enfin suffisamment simple pour la mise en place, suffisamment bien vu pour l'investissement des décideurs dans ces solutions et suffisamment mature pour se généraliser.

Par contre, cette évolution entraine un autre style de programmation; l'ordonnancement et la synchronisation des process, parfois asynchrones, exigent pour les programmeurs d'être plus malins et de voir l'application de plus loin, les transformant progressivement en architectes logiciel.

Le futur des IHM

Il y a quelques mois, dans un précédent billet, je parlais des diverses tendances au niveau de la couche présentation des applications web Java.

Effectivement, tout semble se clarifier dans ce monde très dynamique. En gros, il y a 3 mondes:

1. on améliore les concepts existants (JBoss Seam avec Facelets et JSF, Struts 2 basé sur Webwork)
2. on écrit le code de l'interface en Java et on compile vers de l'HTML/AJAX/Javascript (Google GWT)
3. on se base sur du Flash, généré à partir de code XML compilé (Flex, OpenLaszlo)

En fait, il me semble que les deux premiers mondes vont vite atteindre leurs limites. Même si l'AJAX apporte une relative fraicheur dans l'utilisabilité des applications, on reste vraiment bridé par le HTML/Javascript au niveau des possibilités et de la complexité.

Que l'on code directement avec du HTML ou à partir de code Java, on se retrouve avec au final une IHM construite à partir de technologies qui n'était pas initialement prévue pour faire de l'IHM (HTML a été créé pour lire des articles scientifiques, Java a été conçu pour faire des algorithmes, pas du layout ou de la configuration de composants).

Au final, il nous reste Flash, une technologie qui a été pensée dès le départ pour faire de l'IHM, qui le fait bien, de manière légère, cross-platform, avec un rendu identique sur toutes les plate-formes (Windows, Mac OS, Linux 32bits). Bref, pour moi, Flex est un bon aperçu de ce que seront les technologies d'IHM de demain.

La tendance est aux applications riches (RIA - Rich Interface Application), Adobe (Flash & Flex) et Microsoft (Windows Presentation Foundation / Express) l'ont très bien vu.

Je partage tout à fait l'analyse que fait Bruce Eckel sur son blog:
Hybridizing Java - http://www.artima.com/weblogs/viewpost.jsp?thread=193593

Simplicité et usabilité contre liberté

Un réflexe courant de développeur, lorsque l'on est confronté à une IHM, est d'offrir le plus de fonctionnalités possibles. On se retrouve vite avec des applications usine à gaz, extrèmement "fouillies".
En partant d'une bonne intention: offrir le plus de fonctionnalités possibles, on arrive à l'effet inverse: avoir tellement de fonctionnalités que l'on n'en utilise plus qu'un sous ensemble très minime; c'est un peu ce que l'on retrouve sur les anciennes versions de word (la toute dernière version, 2007, apporte de grandes avancées en terme d'ergonomie).

Pourtant, il est souvent possible d'offrir toutes ces fonctionnalités avec une interface beaucoup plus minimaliste, notamment en les regroupant intelligemment.
Voici un article intéressant avec un exemple concret de simplification d'interface:
http://www.joelonsoftware.com/items/2006/11/21.html

Source: http://application-servers.com/

Expérience utilisateur

J'ai toujours insisté sur l'importance de l'IHM (GUI), car un des éléments clé de l'acceptation d'une application est l'expérience utilisateur.

Voici une image qui donne à réfléchir, tirée d'un excellent blog:
Creating passionate users



Source: http://application-servers.com/