Les frameworks web Java Haute Productivité

Les frameworks web Java "Haute Productivité"  Aurélien Maury  1 / 28 
Les frameworks web Java "Haute Productivité"
Depuis plusieurs mois déjà, une nouvelle génération de frameworks de développement agite
la communauté Java. Ils se nomment JRuby on Rails, Grails ou Spring ROO, et proposent
rien de moins que de repenser notre façon de construire des applications Web en Java.
Alliant génération de code, conventions de programmation, langages dynamiques et
instrumentation de bytecode Java, ces frameworks sont l'aboutissement d'une lente
maturation. Leur origine est à chercher dans une constante quête de simplicité dans un
environnement technique de plus en plus complexe.
Nous avons choisi de qualifier ces frameworks de frameworks haute productivité. Nous
estimons, en effet, qu'ils offrent un modèle programmatique très simple tout en bénéficiant de
la richesse et des capacités de l'écosystème Java. Ils constituent en cela une synthèse entre
les deux tendances souvent divergentes qui animent l'innovation technologique depuis
bientôt 15 ans : la standardisation des aspects les plus complexes des architectures
modernes d'une part, la recherche de simplicité, de rapidité et d'efficacité d'autre part.
Parler de haute productivité invite d'emblée à quelques précautions : un framework n'étant
qu'un outil, on conviendra sans peine que sa productivité dépend directement de la tâche
pour laquelle on s'en sert. L'usage d'une tronçonneuse améliore nettement la productivité
d'un bûcheron, mais freine plutôt celle de l'ébéniste... Les frameworks haute productivité
possèdent des caractéristiques similaires : ils augmentent fortement la productivité des
développements pour certaines typologies d'applications (essentiellement celles qui sont
orientées données), mais ne constituent en aucun cas une solution universelle à la
problématique de la productivité du développement logiciel en général.
Après un court aparté sur cette notion de productivité appliquée au développement logiciel,
nous vous raconterons la genèse de ces frameworks. Nous vous présenterons ensuite les
principaux acteurs de la mouvance : le précurseur, JRuby on Rails, le favori, Grails, le
challenger, Spring Roo et enfin l'outsider, Play!. Nous évoquerons enfin, avant de conclure, la
mise en œuvre de ces frameworks, les risques et opportunités liés à leur adoption.
"La simplicité est la sophistication suprême."
Léonard de Vinci
Aurélien Maury
http://blog.xebia.fr
http://www.xebia.fr
Xebia IT Architects SAS
10/12 Avenue de l’Arche
92419 Courbevoie Cedex
Tél : [phone]
Mail : [e-mail]

Les frameworks web Java "Haute Productivité"  Aurélien Maury  2 / 28 
A propos de productivité........................................................................................................3!
Brève histoire des frameworks Web Java ............................................................................5!
Tour d'horizon .........................................................................................................................7!
Caractéristiques communes ..................................................................................................7!
Architecture compacte .......................................................................................................7!
Convention contre configuration ........................................................................................7!
Langage dynamique et génération de code.......................................................................8!
Runtime Java .....................................................................................................................8!
Bon support des méthodes agiles......................................................................................9!
Les acteurs de la tendance..................................................................................................10!
Le précurseur relooké : JRuby on Rails ...........................................................................10!
Le favori : Grails ...............................................................................................................14!
Le challenger : Spring ROO .............................................................................................17!
L'outsider : Play!...............................................................................................................21!
Mise en œuvre .......................................................................................................................22!
Risques................................................................................................................................22!
Coût d'apprentissage .......................................................................................................22!
Disponibilité des compétences.........................................................................................22!
Support.............................................................................................................................22!
Débogage.........................................................................................................................23!
Migrations de base de données .......................................................................................23!
Qui utilise ces frameworks ?................................................................................................24!
Une solution d'avenir ?.........................................................................................................25!
Plus de productivité .............................................................................................................25!
Une initiative professionnelle ...............................................................................................25!
Adoptée par la communauté................................................................................................25!
Synthèse ................................................................................................................................26!
Conclusion.............................................................................................................................27!
Annexes .................................................................................................................................28!
Grails & Groovy ...................................................................................................................28!
Play! framework ...................................................................................................................28!
Spring ROO .........................................................................................................................28!
JRuby & Ruby on Rails........................................................................................................28!

Les frameworks web Java "Haute Productivité"  Aurélien Maury  3 / 28 
A"propos"de"productivité"
Avant d'aborder plus en détail les frameworks haute productivité, il est nécessaire de
s'intéresser un peu à la notion de productivité appliquée au développement logiciel.
En économie classique, la productivité désigne le rapport entre la valeur ajoutée et la quantité
de travail nécessaire à sa création. Rapportée au développement informatique, cette
définition pose un double problème. D'abord celui de la valeur ajoutée, qui échappe en
grande partie aux équipes de développement. Développer très vite un logiciel inutile ne
présente, bien sûr, pas le moindre intérêt. Symétriquement, et quelle que soit la valeur de ce
qui a été développé, cette valeur n'est actualisée qu'à partir du moment où le logiciel a été
déployé et a commencé à générer le revenu pour lequel il a été conçu. Et là aussi, le
processus de déploiement échappe bien souvent aux équipes de développement à
proprement parler. Optimiser la productivité du processus de développement logiciel relève
en conséquence d'une approche holistique qui dépasse largement le cadre de ce document.
Nous devrons donc ici nous contenter d'une définition plus modeste de la productivité, ne
prenant en compte que la portion de la création de valeur ajoutée attribuable à l'activité de
développement à proprement parler.
La question qui se pose alors est la suivante : comment réduire la quantité de travail
nécessaire à l'élaboration et la construction d'un logiciel informatique ?
Comme dans n'importe quel secteur, la recherche de gains de productivité dans le
développement logiciel est depuis longtemps un puissant vecteur d'innovation, à la fois
technologique et méthodologique. Mais peu de secteurs ont connu autant d'espoirs déçus en
la matière... Ce phénomène prend racine dans la nature même du développement : chaque
logiciel est un produit unique, dont la mise au point est tributaire d'opérations très
sophistiquées visant à en maîtriser la complexité. Il s'agit en somme de traduire des
primitives très frustres - un jeu d'opérations binaires limité, des registres, des espaces
mémoire adressables - en comportements de haut niveau visant le plus souvent à permettre
à des opérateurs humains de manipuler des symboles très élaborés.
En 1986, dans son célèbre article "No Silver Bullet", Frederick P. Brooks propose une lecture
originale et pertinente de cette complexité. Reprenant la distinction aristotélicienne entre
accident et essence, il distingue la complexité accidentelle, liée à la traduction des idées en
langage machine, et la complexité essentielle, qui concerne la structure et les fonctionnalités
du logiciel à proprement parler. Pour obtenir des gains de productivité, les technologies
devraient donc s'attacher à réduire l'une ou l'autre de ces complexités.
Selon Brooks, et dès la fin des années 80, l'évolution des langages de programmation a déjà
éliminé la majeure partie de la complexité accidentelle du développement logiciel. Langages
évolués, compilateurs, programmation orientée objet, ces innovations offrent aux
développeurs des abstractions de haut niveau les affranchissant des trivialités du langage
machine. Ajoutons qu'en supprimant en grande partie les problématiques de gestion et
d'adressage mémoire, les langages de dernière génération - dont Java - ont achevé cette
évolution, sans pour autant se traduire par des gains de productivité comparables, par
exemple, à l'émergence du langage C.
Brooks affirme ensuite qu'aucune évolution technologique ne permettra à elle seule de
réduire ne serait-ce que d'un ordre de grandeur la complexité essentielle du développement
logiciel - il se fait alors l'avocat d'une approche organique, incrémentielle, du développement,
ce qui le place parmi les précurseurs de ce que l'on nomme aujourd'hui les méthodes agiles.

Les frameworks web Java "Haute Productivité"  Aurélien Maury  4 / 28 
Les tentatives pour s'attaquer à la complexité essentielle du développement logiciel ont été
nombreuses au cours des trois dernières décennies - sans qu'aucune, conformément aux
intuitions de Brooks, n'apporte de solution définitive. Cette course semble d'autant plus
désespérante que l'évolution de l'informatique a fortement accru son niveau de complexité :
architectures ouvertes, distribution, interopérabilité, échanges, volumétrie, concurrence
massive, haute disponibilité, etc. Ces problématiques sont devenues le lot commun de la
plupart des logiciels modernes, augmentant sensiblement les difficultés d'élaboration et de
construction des applications informatiques.
Au cœur de ces tentatives, la notion de framework a pris une place prépondérante :
frameworks méthodologiques, avec Merise, RUP, CMMi ou plus récemment Scrum, pour ne
citer qu'eux ; frameworks techniques, bien sûr, sous forme d'API de plus ou moins haut
niveau, de développements "maison" ou d'écosystèmes complets tel celui offert par la
plateforme JEE.
L'idée commune, derrière cette notion de framework, est d'offrir au développeur un cadre de
travail homogène, visant à simplifier par standardisation chacune des grandes activités qui
constituent son quotidien : conception, programmation, test. L'enfer étant pavé de bonnes
intentions, les frameworks ont souvent souffert d'une vision trop étroite, ou idéalisée, de la
productivité ; les langages de quatrième génération ont ainsi accéléré la conception et la
programmation... mais en bridant de façon excessive les possibilités des langages, les
rendant incapables d'affronter les défis des architectures ouvertes. La génération de code,
incarnée par l'approche MDA, a transféré en l'amplifiant la complexité programmatique vers
les modèles de conception et les générateurs, transformant la maintenance évolutive, qui
constitue pourtant plus de la moitié du développement, en opération à haut risque - avec bien
souvent pour résultat une calcification des logiciels. La plate-forme JEE, en fournissant des
abstractions de haut niveau pour les problématiques les plus sophistiquées - distribution,
accès aux données, gestion de ressources, etc. - a réintroduit une complexité accidentelle
forte dans le développement, au détriment des applications les plus simples. Quant aux
frameworks de développement Web chargés de simplifier la mise en œuvre de l'architecture
Java, comme Struts, JSF, Tapestry, Wicket et autres, ils ont souvent fait pâle figure
comparés aux environnements RAD des années 90 - malgré l'apparition d'IDE très productifs.
Cette recherche de gains de productivité par élaboration successive de frameworks
techniques de plus en plus matures est le moteur de l'évolution de la plateforme Java, dont le
prolongement est aujourd'hui l'émergence des frameworks de haute productivité que nous
nous proposons de présenter ici.

Les frameworks web Java "Haute Productivité"  Aurélien Maury  5 / 28 
Brève"histoire"des"frameworks"Web"Java"
En 1999, Sun Microsystems livre la spécification J2EE (Java 2 Enterprise Edition), destinée à
apporter des solutions pour le développement, le déploiement, et la gestion des applications
multitiers centralisées sur serveur. Construit sur la base de Java 2 édition standard (Java
SE), Java EE spécifie une plateforme complète, stable, sécurisée, et rapide pour une
utilisation en entreprise. L'idée est de proposer un ensemble d'API standardisées, prenant en
charge les problématiques les plus complexes des architectures modernes : traitement des
requêtes HTTP, composants web, distribution, interopérabilité, gestion des transactions,
persistance et mapping objet-relationnel, composants, gestion des ressources, échanges
synchrones (remoting) ou asynchrones (messaging), annuaire, sécurité, assemblage et
déploiement, etc. Cette approche permet une séparation en principe rigoureuse des
responsabilités : aux éditeurs de serveurs d'applications d'implémenter les API ; aux
architectes de concevoir des solutions sans se soucier outre mesure de la technologie sous-
jacente ; aux équipes projet, enfin, de développer des applications exploitant les services
offerts par la plate-forme.
La standardisation apportée par Sun a soutenu la diffusion du langage Java dans l'entreprise,
devenu aujourd'hui incontournable. Comme pour tous les langages de programmation
populaires, une communauté très active de développeurs s'est naturellement formée.
Très rapidement des voix se sont élevées pour critiquer le modèle de développement
proposé par JEE, articulé autour des composants EJB et synthétisé dans les fameux Java
BluePrints publiés par Sun. Ce message, porté par la très nombreuse communauté Open
Source java peut se résumer ainsi : trop complexe! (entendons : pas assez productif). Pour
reprendre la grille de lecture de Brooks, JEE a réintroduit une forte complexité accidentelle
dans le développement Java, avec pour conséquence une baisse de productivité
considérable pour les applications les plus simples (celles essentiellement orientées données
que l'on retrouve en masse dans les entreprises). Quiconque a abandonné ses outils RAD
client-serveur pour adopter J2EE au début des années 2000 a probablement gardé de
l'expérience des souvenirs pour le moins mitigés... Pour pallier cette difficulté, c'est à cette
époque qu'ont émergé la plupart des frameworks de développement "maison" dans les
entreprises. C'est aussi à ce moment-là que la communauté Open Source a commencé à
offrir des alternatives, sous forme de frameworks plus ou moins spécialisés offrant des
modèles de programmation simplifiés pour le développement d'applications Java
d'entreprises ; on pourrait dater la fronde aux alentours des années 2003-2004, qui ont vu
successivement la sortie de l'ouvrage de Rod Johnson, "J2EE Development without EJB", le
lancement de la version 1.0 du framework Spring et celui de la version 1.0 du framework
Hibernate. Ces deux frameworks ont ouvert une voie originale : conserver le potentiel de la
plateforme JEE comme socle d'exécution, mais se soustraire au modèle de programmation
jugé inefficace proposé par la spécification EJB.
La mise en compétition du standard et de ces alternatives Open Source a donné lieu à une
dialectique subtile et parfois conflictuelle, dont nous vous épargnerons ici les péripéties. Elle
a surtout créé une émulation très forte, moteur d'innovations très nombreuses vers des
modèles de programmation de plus en plus matures, stables, souples et productifs. Même s'il
reste une très grande diversité de solutions, on peut penser que Java a atteint l'âge de
raison ; le modèle de programmation des applications Web Java a convergé :
 Un framework Web MVC, orienté actions (Struts 2, Wicket, Tapestry, Spring
MVC, etc.) ou événements (JSF), et associé à un puissant moteur de templates
pour le rendu graphique.
 Un framework d'injection de dépendances pour l'assemblage des composants
(Spring, EJB 3, Guice), complété des innombrables bibliothèques disponibles
dans l'écosystème Java.
 Un framework de mapping objet-relationnel (Hibernate ou d'autres
implémentations de JPA) pour la gestion de la persistance.