Livre Blanc - Les frameworks Web Java « Haute Productivité »

| Aurélien Maury (xebia) | ellene | Xebia |

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 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

Commentez

- Titre : Livre Blanc - Les frameworks Web Java « Haute Productivité »

- Auteurs : Aurélien Maury (xebia), ellene, Xebia

- Parution : 17 décembre 2009

- Mise à jour : 28 décembre 2012

- Licence : Copyright ® 2009 Xebia. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.

Sommaire

- I. A propos de productivité

- II. Brève histoire des frameworks Web Java

- III. Tour d'horizon

- III-A. Caractéristiques communes

- III-A-1. Architecture compacte

- III-A-2. Convention contre configuration

- III-A-3. Langage dynamique et génération de code

- III-A-4. Runtime Java

- III-A-5. Bon support des méthodes agiles

- III-B. Les acteurs de la tendance

- III-B-1. Le précurseur relooké : JRuby on Rails

- III-B-2. Le favori : Grails

- III-B-3. Le challenger : Spring ROO

- III-B-4. L'outsider : Play!

- IV. Mise en œuvre

- IV-A. Risques

- IV-A-1. Coût d'apprentissage

- IV-A-2. Disponibilité des compétences

- IV-A-3. Support

- IV-A-4. Débogage

- IV-A-5. Migrations de base de données

- IV-B. Qui utilise ces frameworks ?

- V. Une solution d'avenir ?

- V-A. Plus de productivité

- V-B. Une initiative professionnelle

- V-C. Adoptés par la communauté

- VI. Synthèse

- VII. Conclusion

- VIII. Annexes

- VIII-A. Grails & Groovy

- VIII-B. Play! framework

- VIII-C. Spring ROO

- VIII-D. JRuby & Ruby on Rails

- IX. Remerciements

I - 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 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 plateforme 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.

II - 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 plateforme.

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.

Le tout est accompagné d'environnements de développement qui simplifient l'intégration et la manipulation de ces frameworks. Certaines solutions, enfin, encapsulent l'intégralité de ces couches dans une solution homogène. C'est le cas en particulier de JBoss Seam.

Cette maturité s'est naturellement accompagnée de l'émergence d'outils de génération de code, comme AppFuse, qui permettent de démarrer facilement un projet s'appuyant sur des composants standards.

Parallèlement à cette effervescence du monde Java, une autre branche d'innovation technologique a progressivement acquis ses lettres de noblesse. Davantage tournée vers le développement Web à proprement parler (par opposition aux applications d'entreprise), elle s'articule autour de langages alternatifs : PHP, Ruby, Python… Les contraintes originelles sont sensiblement différentes de celles adressées par la plateforme Java : schématiquement, le développement de sites Web dynamiques repose généralement sur une architecture compacte mais hautement scalable ; les contraintes de time-to-market imposent des cycles de développement très courts que les langages de scripting semblent plus à même de satisfaire.

Issu de ce mouvement, le projet Ruby on Rails, né en 2004 résume à lui seul cette démarche : une architecture très simplifiée, complètement libre de l'héritage JEE, un outillage de génération de code et des méthodes adaptées au développement Web.

L'apparition de moteurs de scripting au sein de la JVM a ouvert la voie de la synthèse de ces deux mouvements. En hébergeant au cœur du runtime Java des interpréteurs de langages dynamiques, il est possible de bénéficier du meilleur des deux mondes : un modèle de développement hautement productif, adapté au développement Web, et la plateforme Java Entreprise, sa robustesse, ses capacités d'intégration et ses milliers de bibliothèques libres. C'est cette synthèse que les frameworks Web Java haute productivité cherchent à réaliser.

III - Tour d'horizon

III-A - Caractéristiques communes

Les frameworks que nous vous proposons présentent tous un ensemble de caractéristiques communes :

- une architecture compacte, pragmatique ;

- le principe Convention over Configuration ;

- le scaffolding (génération de code dynamique) ;

- pour certains, un langage dynamique ;

- une approche RAD, basée sur un prototypage rapide ;

- une gestion dynamique de la base de données ;

- le runtime Java comme moteur sous-jacent ;

- l'intégration des technologies Web les plus récentes (Ajax, Comet, REST) ;

- un support intégré des méthodes agiles (développement incrémental, build et intégration continus, refactoring, développement piloté par les tests).

III-A-1 - Architecture compacte

Ces frameworks proposent le plus souvent une architecture compacte, reposant sur une implémentation stricte du pattern MVC (Model-View-Controller). La couche « service », souvent mise en place de façon un peu artificielle dans les applications Java d'entreprise est supprimée, au profit d'un modèle riche, véritablement orienté objet et autosuffisant. Cette approche n'interdit bien sûr pas d'introduire au besoin une couche de service, mais celle-ci n'est ni obligatoire, ni systématique, et devra répondre à des besoins de conception clairement identifiés. Symétriquement, l'accès aux données est généralement fourni directement par les entités (sous forme de méthodes statiques, par exemple).

III-A-2 - Convention contre configuration

L'une des problématiques les plus largement abordées par ces nouveaux frameworks est celle des fichiers de configuration à rallonge. L'adoption du paradigme « Convention over configuration » (CoC) permet de réduire au minimum les besoins de configurer le framework en lui-même. Le temps d'écriture des fichiers de configuration est ainsi libéré et rendu disponible pour les développeurs.

Dans la pratique, cela se traduit par des conventions de nommage de classes, de variables et/ou de packages, qui permettent au framework, à l'exécution, de réaliser les injections de dépendances ou la mise en place des aspects utiles. L'économie de code à écrire profite également à la maintenabilité à long terme de l'application.

Bien évidemment, comme pour tout standard, les conventions ne pourront satisfaire 100 % des projets. Pour les besoins spécifiques ou en marge, il est toujours possible d'adapter le comportement des frameworks en surchargeant la convention par des directives de configuration spécifiques.

III-A-3 - Langage dynamique et génération de code

La seconde activité consommatrice de temps que les outils haute-productivité visent à éradiquer est la rédaction des CRUD (Create-Read-Update-Delete). Il s'agit des écrans qui permettent, dans toute application, de créer, visualiser, éditer et supprimer les données du modèle. Quel que soit le modèle de données, la structure de ces pages est la plupart du temps identique et demande l'écriture de beaucoup de lignes de code pour très peu de valeur ajoutée métier.

En réponse à cela, les outils que nous allons présenter proposent de passer directement de la spécification du modèle à la génération de code pour créer ces pages de visualisation/mise à jour. Ce mécanisme de génération de code est plus connu sous le nom de « scaffolding » chez nos collègues anglophones. Mais gardons la tête froide : le code généré, quel que soit l'outil, reste une simple base pour soutenir le développement. Les cas dans lesquels on peut s'appuyer intégralement sur du code généré non modifié restent très marginaux.

Le problème de la génération de code est la maintenance. Car, une fois le code généré, il faut l'adapter aux besoins spécifiques de l'application. Puis vient un jour où le modèle de données doit évoluer, laissant alors 2 options :

- re-générer le code à partir du nouveau modèle puis refaire des adaptations sur le code re-généré ;

- modifier à la main toutes les couches impactées, ce qui demande une précision chirurgicale vue la quantité de code générée.

Dans les deux cas, le risque de régression est rédhibitoire.

Les langages dynamiques apportent une solution pour éviter cette maintenance. Ils permettent de générer au runtime le code nécessaire à l'application en fonction du modèle de données uniquement. Ainsi lorsque le modèle change, il suffit de relancer l'application pour que les nouvelles pages reflètent les modifications. La question qui se pose alors est : Comment customiser les pages puisqu'elles sont générées au runtime ?

Grails, par exemple, répond à cette question en permettant de surcharger uniquement les méthodes ou les pages dont vous voulez modifier le comportement. De cette manière, le code surchargé n'est pas impacté par le changement du modèle et il ne reste qu'à relancer l'application pour la voir s'adapter au nouveau modèle.

III-A-4 - Runtime Java

L'une des forces de ces nouveaux frameworks est de s'exécuter sur une machine virtuelle Java, et donc d'offrir des passerelles naturelles avec l'écosystème Java. En pratique, cela signifie que le développeur peut bénéficier des API JEE ou de toutes les bibliothèques écrites en Java. Il est également très simple de conserver le langage Java pour certains développement, lorsque les langages dynamiques ne semblent pas les plus adaptés. Enfin, en matière d'exploitation, les applications sont déployées sur les serveurs d'application Java, aujourd'hui maîtrisés par la plupart des entreprises.

III-A-5 - Bon support des méthodes agiles

Parmi les conventions portées par les framework haute productivité, on retrouve aussi des méthodes de gestion de suivi de qualité. Chaque outil offre une arborescence projet standard, qui inclut les notions de tests unitaires et d'intégration, des mécanismes de chargement de la base de données pour effectuer les tests, etc. Les grands principes portés dans les méthodes agiles ou des méthodes comme l'Extreme Programming sont donc promus par l'utilisation de ces outils.

Cette intégration s'est faite de façon naturelle car les tendances se sont développées à la même époque. De plus, chacune avait pour objectif de rompre avec les lourdeurs passées pour construire une meilleure approche. La génération de code et les langages dynamiques permettent dès lors d'obtenir des prototypes dans un temps très court, pour ensuite les retoucher, les améliorer. Des frameworks comme JRuby on Rails ou Grails sont ainsi naturellement devenus d'excellents supports pour la mise en œuvre des méthodes agiles.

« La simplicité n'a pas besoin d'être simple, mais du complexe resserré et synthétisé. » Alfred Jarry

III-B - Les acteurs de la tendance

Nous allons maintenant nous pencher sur les principaux outils qui existent déjà pour tenter de répondre aux problématiques de haute productivité. Pour cela, après une présentation, nous illustrerons leur mise en œuvre par un exemple minimaliste : une application Librairie, permettant la saisie d'auteurs et des livres qui leur sont associés.

Nous avons évidemment dû faire des choix parmi les différents projets actifs. Ruby on Rails ayant le privilège de l'antériorité, nous commencerons naturellement par évoquer son portage pour la plateforme Java, JRuby on Rails. Nous étudierons ensuite son clone basé sur le langage Groovy : Grails. Nous nous intéresserons ensuite à Spring ROO, pour son approche radicalement différente, orientée application Spring pure et génération dynamique de code. Pour finir, nous mettrons rapidement en lumière le framework Play!, qui paraît très prometteur dans un futur proche.

Notre sélection aurait pu être un peu plus large : DJango, le fameux framework Python, fonctionne en principe en Jython sur une JVM… mais cet usage n'a pas d'exemple concret à notre connaissance. Quand à Lift, framework basé sur Scala, il présente des aspects intéressants (notamment le langage dynamique, l'inférence de type, le développement piloté par la vue et le runtime Java), mais il n'offre pas encore à notre sens la rupture proposée par Grails ou JRuby on Rails en matière de cycle de développement. JBoss Seam, enfin, qui intègre depuis peu du scaffolding, reste un framework assez conventionnel.

III-B-1 - Le précurseur relooké : JRuby on Rails

Ruby est un langage de programmation objet paru en 1995. La syntaxe agréable, le dynamisme du langage et l'orientation objet ont rapidement attiré un grand nombre de développeurs à travers la planète. En 2004 sort un framework Web nommé Ruby on Rails, qui va changer la donne sur la conception des applications Web. Ruby on Rails est écrit en Ruby et offre de nombreuses fonctionnalités pour le développement d'application Web : scripts de génération de code, système de versionnage du modèle de données, système de plugins. Son arrivée a permis de populariser encore plus le langage Ruby, de nombreux plugins sont apparus et le framework a vite gagné en maturité.

JRuby est un interpréteur de langage Ruby écrit en Java. Initié par Jan Arne Petersen en 2001, le projet a été soutenu au fil des ans par les sociétés Sun Microsystems, ThoughtWorks et dernièrement EngineYard, qui ont embauché les développeurs principaux du projet pour y travailler à plein temps. JRuby est aujourd'hui une plateforme stable et mature pour le déploiement d'applications développées grâce à Ruby on Rails, et c'est une priorité de JRuby de continuer à supporter ce framework. Une fois JRuby installé sur la machine, pour démarrer notre développement, une commande suffit pour générer une arborescence de projet type :

$ jruby -S rails librairie -d mysql
$ cd librairie

La configuration de la connexion à la base de données est située dans le fichier config/database.yml du projet. Nous allons donc le modifier pour utiliser des connecteurs JDBC :

development:
adapter: jdbcmysql
encoding: utf8
database: librairie_development
username: root
password:

En deux commandes de plus, nous avons notre modèle de données simplifié :

$ jruby -S script/generate scaffold livre titre:string date_edition:date
$ jruby -S script/generate scaffold auteur nom:string prenom:string

Une fois celui-ci adapté, on peut lancer la création de la base puis le déploiement du modèle :

$ jruby -S rake db:create
$ jruby -S rake db:migrate

Les classes du modèle de données ressemblent à ceci :

class Livre < ActiveRecord::Base
end

On remarque que la classe Ruby est vide, la seule information utile est qu'elle étend la classe de base de la bibliothèque ActiveRecord, qui constitue la couche d'accès aux données de toute application Ruby on Rails. La définition des colonnes de notre ligne de commande se retrouve dans un autre fichier, qui contient un script de manipulation de la base de données pour créer la table correspondante :

class CreateLivres < ActiveRecord::Migration
def self.up
create_table :livres do |t|
t.string :titre
t.date :date_edition

t.timestamps
end
end

def self.down
drop_table :livres
end
end

Au runtime, ActiveRecord fait le lien entre le nom de la table et le nom de la classe, et reconstitue tous les accesseurs nécessaires à partir des intitulés de colonnes. Ainsi on peut utiliser les traditionnels getter/setter mais également d'autres accesseurs permettant de remonter le contenu de la base de données.

Livre.all()
Livre.find(id)
Livre.find_by_titre('1984')
Livre.find(:all, :conditions => ["date_edition < ?", '2009-11-11'])

A ce stade nos classes de modèle ne sont pas liées. Nous allons donc ajouter une association de façon à ce qu'un Livre soit lié à un Auteur. Nous modifions donc la classe Livre de cette façon :

class Livre < ActiveRecord::Base
belongs_to :auteur
end

Et nous rajoutons une colonne auteur_id dans notre table de livres pour stocker l'identifiant de l'Auteur. Pour finir nous déployons les modifications sur la base de données :

$ jruby -S script/generate migration add_auteur_id_to_livre auteur_id:integer
$ jruby -S rake db:migrate

Grâce aux opérations que nous venons de réaliser, il est maintenant possible de récupérer l'objet Auteur lié à un Livre en appelant la méthode monLivre.auteur. On remarquera que les classes et les associations dans les modèles de Ruby On Rails ressemblent fortement à la logique de base de données. C'est une approche radicalement différente des logiques JPA ou Hibernate mais qui offre l'avantage d'être plus concis dans la structure finale des tables.

La couche de présentation des applications s'appuie sur des modèles de documents intégrant du scripting Ruby. Ruby on Rails propose de nombreuses méthodes pour créer des tags HTML remplis par paramétrage. Cela facilite beaucoup l'écriture et la maintenance des pages Web. Comme il s'agit de scripting Ruby intégré à l'application, toutes les méthodes accessibles dans les classes Contrôleurs, le sont également dans les vues. On peut donc créer très simplement une liste de sélection dans un formulaire :

<% form_for(@livre) do |f| %>
<%= f.text_field :titre %>
<%= select :auteur, :auteur_id, Auteur.all().collect{|p| [p.nom, p.id]} %>
<%= f.submit "Enregistrer" %>
<% end %>

Donnera, une fois le HTML généré :

<form action="/livres" class="new_livre" id="new_livre" method="post">
<input id="livre_titre" name="livre[titre]" size="30" type="text" />
<select id="auteur_auteur_id" name="auteur[auteur_id]">
<option value="1">Dickens</option>
</select>
<input id="livre_submit" name="commit" type="submit" value="Enregistrer" />
</form>

La lisibilité du modèle en est grandement améliorée. L'exemple, donné ici pour le tag lt;select/> vaut pour beaucoup d'autres, comme les tag <img/>, tous les champs de formulaires, les champs fichier destinés au chargement vers le serveur, etc.

Un autre point fort de cette solution est que la communauté Ruby est très active et la documentation de bonne qualité. Il est assez simple de s'autoformer sur Ruby On Rails, à supposer qu'on dispose d'un accès Internet. JRuby fournit également un plugin pour empaqueter une application Rails dans une archive WAR. De cette façon, il devient possible de déployer une application Ruby on Rails sur un serveur d'applications Java. Cette méthode permet de faire des économies pour les entreprises qui se lancent dans l'aventure du Ruby alors qu'elles possèdent déjà une infrastructure Java. Il est également possible de lancer des appels vers des classes Java et ainsi de réutiliser certains composants métiers déjà disponibles. Enfin, JRuby est un excellent interpréteur Ruby qui tient largement la comparaison avec les implémentations open source en C.

Des applications conséquentes ont déjà fait le choix de JRuby On Rails. Oracle, avec son portail communautaire Oracle Mix, Sun avec le site de publication Mediacast ou le serveur de suivi de qualité de code source Sonar ont notamment opté pour cette solution.

Pour finir, Ruby on Rails possède un système de plugins qui permet de créer des composants réutilisables d'un projet à l'autre. Le framework étant mature, de nombreux plugins ont été développés et sont disponibles sur les sites de la communauté tels que rubyforge.org ou github.com. Ruby on Rails possède la force de l'expérience et de la maturité. Grâce à Jruby, il peut être exécuté sur une JVM et bénéficie donc de la portabilité et de la stabilité du socle Java.

III-B-2 - Le favori : Grails

Le projet Grails a été initié par Graeme Rocher en 2005 dans le but d'apporter une réponse pour le monde Java à la concurrence des frameworks de développement rapide tels que Ruby on Rails et le framework .Net de Microsoft. Le principe fondateur est de répliquer les fonctionnalités de Ruby on Rails en remplaçant l'utilisation du Ruby par celle du langage Groovy. Son nom vient d'ailleurs de la contraction de « Groovy on Rails ». Le nom « Grails » forme également un jeu de mot avec le mot « Graal », le calice objet de toutes les quêtes. Fin 2008, SpringSource intègre Grails à son portefeuille de produits en rachetant la société G2One. Encore aujourd'hui, Grails est sous licence Apache 2.0.

Grails vise à masquer l'utilisation des librairies standard constituant une application Web en Java, par l'utilisation du langage de scripting JVM Groovy. C'est une architecture Modèle-Vues-Contrôleurs classique.

Pour faciliter le travail des développeurs, les couches applicatives « passe-plat » ont été supprimées, au profit d'une architecture simplifiée. La couche service disparaît totalement, tandis que la couche d'accès aux données est gérée dynamiquement par un outil nommé GORM (Grails Object Relational Mapping). Par exemple, si on définit la classe de Modèle suivante :

class Livre {
String titre
Date dateEdition
}

Au runtime, GORM instrumente cette classe avec des méthodes respectant une convention de nom intelligente. La structure de la requête est directement dans le nom des méthodes et les valeurs sont passées en paramètres. Par exemple pour retrouver des objets de la classe Livre, on peut faire appel à :

def resultats = Livre.findByTitre('Guerre et Paix')
resultats = Livre.findByTitreLike('Guerre et P%')
resultats = Livre.findByDateEditionGreaterThan(uneDateQuelconque)
resultats = Livre.findByTitreLikeAndDateEditionLessThan('Guerre et P%', uneDateQuelconque)

Les associations entre entités du Modèle sont également gérées par des directives compréhensibles, directement dans les classes. Si on veut par exemple ajouter la gestion des auteurs à notre Modèle, il nous suffit de créer une classe :

class Auteur {
String nom
String prenom

static hasMany = [livres : Livre]
}

Le modèle de la base de données est généré en conséquence et un code comme celui-ci réagira comme on pourrait s'y attendre :

def monAuteur = Auteur.findByNomAndPrenom('Dickens', 'Charles')
monAuteur.livres.each{ arg -> println "${arg.titre}"}

Les associations façon GORM sont différentes des standards Hibernate ou JPA, mais leur simplicité permet de se familiariser assez vite avec cette approche. Il faut cependant faire attention aux comportements inattendus. Une bonne connaissance des conventions est nécessaire pour tirer un bon parti de GORM.

Pour la partie présentation des pages web, Grails propose une librairie de tags sur mesure, qui permet de faciliter la rédaction des pages. Les modèles de pages Web rédigés avec ces tags sont appelés Groovy Server Pages (GSP). Il est possible de faire appel directement à l'espace de nommage de l'application depuis les vues. Voici un extrait de page GSP pour donner un aperçu du résultat :

...

<!-- Ici un simple test conditionnel -->
<g:if test="${flash.message}">
<div class="message">${flash.message}</div>
</g:if>

<!-- Ici un test plus haut niveau sur une instance du modèle -->
<g:hasErrors bean="${etapeChantierInstance}">
<div class="errors">
<g:renderErrors bean="${etapeChantierInstance}" as="list" />
</div>
</g:hasErrors>

<!-- Ouverture d'un formulaire -->
<g:form action="save" method="post" >

<label for="date">Date:</label>

<!-- composant de sélection de date -->
<g:datePicker name="date" value="${etapeChantierInstance?.date}" precision="minute">
</g:datePicker>

...

L'utilisation de taglib est une chose très courante dans les Java Server Pages de nombreux autres frameworks. Les tags des Groovy Server Pages sont donc assez intuitifs pour tout développeur Java.

Il est possible de créer des plugins pour les applications Grails, et ainsi d'obtenir des fonctionnalités installables à la demande. SpringSource héberge une bibliothèque de plugins développée activement. Il suffit donc de quelques lignes de commandes pour ajouter à une nouvelle application Grails des composants comme :

- un client CAS ;

- un Content Management System basique ;

- le moteur de règles Drools ;

- un paiement par PayPal ;

- plusieurs librairies JavaScript, comme Mootools ou jQuery ;

- une taglib liée à un player vidéo Flash ;

- …

La liste est longue et s'allonge au fil du temps, enrichie par la communauté (http://www.grails.org/plugin/category/all).

Il est souvent mis en avant que Grails nécessite moins d'adaptation de la part des développeurs Java que d'autres solutions, parce que Groovy est un langage basé sur la JVM. Ce n'est pas tout à fait exact… Groovy est bien basé sur la JVM, et possède certaines similitudes de syntaxe avec Java. Mais il n'en est pas moins un langage de scripting à part entière, qu'il faut apprivoiser. Le passage du mode explicite du Java pur au mode implicite de Groovy demande une adaptation. Par conséquent, il est normal de n'observer les gains de productivité qu'après ce petit temps d'apprentissage.

Ce coût d'adaptation est compensé par l'intégration Grails. Pour l'architecte, Grails offre l'avantage d'une pile de librairies dont la compatibilité est testée. La possibilité d'intégrer des plugins permet de conserver encore cet aspect lisse. Chaque plugin étant testé et validé pour une gamme de versions de Grails. On diminue ainsi fortement les risques d'incompatibilité entre librairies. De plus les délicates opérations de mapping de données et de configuration de la base, l'injection de dépendances, etc., sont gérées en coulisse de façon efficace. Même s'il est toujours possible de prendre la main sur ces opérations pour des modifications spécifiques, dans 90 % des cas, le gain de temps est énorme.

III-B-3 - Le challenger : Spring ROO

Sur la voie de la haute productivité, Spring ROO propose une autre approche différente de celle de JRuby/Groovy On Rails. Le concept est ici très simple : l'architecture basée sur le modèle Spring est bonne mais longue à rédiger, donc on conserve l'architecture et on crée un outillage pour accélérer son écriture. Au moment de la rédaction de ce document, Spring ROO est en version 1.0RC3. L'outil se présente sous la forme d'un shell permettant de lancer des commandes de génération de code. Le framework à proprement parler est donc Spring, Spring ROO permet de monter une application beaucoup plus rapidement et de façon standardisée.

Une commande 'hint' permet de guider le développeur. Cette commande, en scannant l'état du projet, affiche la documentation de l'étape suivante. Un projet initié par Spring ROO est un projet classique au format Maven 2, basé sur Spring 3 et Spring MVC. Le code généré s'appuie massivement sur la programmation orientée aspect, en s'appuyant sur la librairie AspectJ.

Voyons comment démarrer un nouveau projet. A supposer que nous soyons dans un répertoire créé pour héberger les fichiers du projet, on lance le shell ROO et on lance les commandes suivantes :

$ roo.sh
____ ____ ____
/ __ \/ __ \/ __ \
/ /_/ / / / / / / /
/ _, _/ /_/ / /_/ /
/_/ |_|\____/\____/ 1.0.0.RC3 [rev 401]

Welcome to Spring Roo. For assistance press TAB or type "hint" then hit ENTER.
roo> project --topLevelPackage fr.xebia.sample.roo
roo> persistence setup --provider HIBERNATE --database HYPERSONIC_IN_MEMORY
roo> entity --name ~.domain.Livre

Les trois commandes ci-dessus correspondent à :

- génération de l'arborescence du projet avec le nom du package racine ;

- configuration du projet pour l'utilisation d'une base de données HSQLDB stockée en mémoire ;

- création d'une classe d'entité nommée Livre.

A partir de là, nous disposons d'un projet Maven 2 complet, d'une classe de domaine générée, ainsi que 4 fichiers suffixés '.aj' contenant le code source AspectJ des aspects appliqués à cette classe. Il est maintenant possible d'aller directement éditer le code source de notre classe de modèle.

package fr.xebia.sample.roo.domain;

import javax.persistence.Entity;
import org.springframework.roo.addon.javabean.RooJavaBean;
import org.springframework.roo.addon.tostring.RooToString;
import org.springframework.roo.addon.entity.RooEntity;

@Entity
@RooJavaBean
@RooToString
@RooEntity
public class Livre {
}

Cette simple classe est déjà instrumentée par environ 120 lignes de code d'aspect. Tant que le shell ROO reste lancé, toute modification sur la classe déclenche une re-génération des fichiers d'aspects pour correspondre à la classe Java. C'est ce que Spring appelle de la génération de code « active ». Ainsi, si on rajoute des champs à notre classe, ils seront directement pris en compte par le générateur Spring ROO. Il est également possible de continuer à utiliser le shell pour ajouter les champs.

roo> field string --fieldName titre --class fr.xebia.sample.roo.domain.Livre
roo> field date --fieldName dateEdition --type java.util.Date --class fr.xebia.sample.roo.domain.Livre

Le shell joue un rôle de chaîne de montage d'application. Les commandes sont très longues mais le shell dispose d'une complétion d'excellente qualité. L'utilisateur est très bien guidé. On peut aussi scripter une suite de commandes ROO pour démarrer encore plus vite. Voici le cycle de développement/génération de code des applications avec Spring ROO :

Puisque nous disposons d'une classe, nous pouvons maintenant générer les Contrôleurs et les Vues nécessaires en lançant :

roo> controller scaffold ~.web.LivreController

Ensuite, pour lancer le projet, on quitte le shell ROO et on lance tomcat grâce à un plugin Maven.

$ mvn tomcat:run

La méthode paraît beaucoup moins directe que pour JRoR ou Grails, dans la mesure où on perd l'avantage des langages dynamiques. On ne peut plus éditer, rafraîchir le navigateur et voir le résultat. Le cycle de développement, bien que fortement aidé par le shell, reste relativement classique. On peut tout de même réaliser une application CRUD déployable en une dizaine de minutes :

L'un des points forts est que le code généré est 100 % Java-JSP. Il est donc accessible à tous les développeurs Web Java. Cependant, ce code exploite beaucoup les concepts de programmation orientés aspect, qui ne sont pas toujours maîtrisés. Les classes de l'application sont décorées avec un ensemble d'annotations spécifiques et des classes AspectJ sont générés par ROO pour enrichir l'application. Cette complexité nouvelle est de nature à tempérer l'enthousiasme des développeurs. Il est toutefois possible de se séparer de ROO en une commande qui rapatrie le code des aspects dans le code principal.

Une bonne connaissance de la programmation par aspects est importante pour bien comprendre les mécanismes en œuvre dans le projet. Dans les applications générées, seules les couches contrôleur et d'accès aux données subsistent. Spring ROO impose là une rupture non seulement par rapport au modèle J2EE, mais aussi par rapport aux principes des framework haute productivité inspirés de Ruby on Rails. Ici pas de « convention-over-configuration », tout est explicite, mais facilité par la génération. Aucun dynamisme « magique » ne vient se rajouter au runtime.

ROO est un outil jeune et ambitieux. Il diffère dans ses choix architecturaux à la fois du monde J2EE et de celui des JRuby/Groovy on Rails. Il permet d'obtenir un excellent démarrage projet et ensuite d'éteindre le pilote automatique et lancer son équipe sur un prototype qui respecte les standards, basé sur les versions les plus récentes de la pile Spring. Parmi les défauts de jeunesse du projet, on notera tout de même que :

- bien que le shell soit intuitif et verbeux, la documentation de l'outil est quasi inexistante ;

- la communauté de développeurs est quasi inexistante ;

- aucun projet d'envergure n'a été mis en production avec cet outil.

L'avenir nous dira comment évoluera sa popularité.

III-B-4 - L'outsider : Play!

Play! est un framework créé par Guillaume Bort et soutenu par la société Zenexity. Déjà utilisé pour certaines réalisations de la société, il semble que la diffusion de ce framework en dehors des contrats de service Zenexity commence à prendre un peu d'ampleur. Un site de preuve de concept a été monté pour permettre aux internautes de tester une interface riche réalisée avec Play! (http://en.dorse.me).

Ici le modèle est géré directement par des POJO, et la couche de présentation est constituée de modèles de pages en Groovy. L'accès aux données est géré de façon similaire à Grails ou JRuby on Rails, par instrumentation des classes du modèle de données. Le code de l'application reste intégralement en Java et ne fait pas usage d'annotations ésotériques. Le plus apporté par Play! est de fournir un service de rechargement des classes Java qui évite les phases de recompilation et de redéploiement. Il est donc possible de conserver son application en cours d'exécution durant tout le cycle de développement. Pour chaque modification, un rechargement du navigateur suffit à voir le résultat. Les erreurs de compilation sont gérées par le framework et affichées aux développeurs dans une page type pour en faciliter le diagnostic.

Plusieurs librairies sont fournies dans la pile de librairies du projet pour faciliter la vie des développeurs, comme de la manipulation d'images à la volée ou des méthodes JSON pour faciliter l'interaction avec la partie Javascript de l'application. La librairie Javascript JQuery est intégrée par défaut. Du fait de sa faible audience actuelle, nous ne développerons pas plus d'exemple ici. Il est bon néanmoins de connaître l'existence de ce framework dont l'utilisation pourrait, dans le futur, se répandre dans la communauté des développeurs Web. Après l'avoir rôdé en usage interne, Zenexity fait des efforts pour diffuser son framework auprès de la communauté, comme semble en témoigner leur présence à la conférence Devoxx 2009.

« The greatest things about standards is there are so many to choose from. » Martin Atkins.

IV - Mise en œuvre

IV-A - Risques

IV-A-1 - Coût d'apprentissage

Les frameworks de haute productivité apportent un certain nombre de concepts nouveaux qu'il faut intégrer avant d'en tirer un bon parti. Même si le pattern Modèle-Vue-Contrôleur est aujourd'hui un classique des applications Web, sa mise en œuvre est ici particulière. Les conventions des frameworks permettent de se passer de beaucoup de code et de configuration, mais il faut s'astreindre à les respecter pour ne pas tomber dans le travers d'expliciter des opérations qui devraient être automatisées par les frameworks. Les documentations sont en général assez complètes et claires et permettent de se former rapidement.

L'utilisation des langages dynamiques supprime le garde-fou du compilateur. Le raccourcissement du cycle de développement permet de compenser cette lacune. Ainsi, le temps nécessaire à l'assimilation des nouveaux concepts et à l'esquive des pièges des langages dynamiques est également réduit. On constate en général une courbe d'apprentissage plutôt favorable sur les outils à base de langage dynamique. Le coût d'apprentissage existe mais il est très supportable et les gains à retirer de cet effort valent clairement la peine.

Spring ROO est le cas à part, puisqu'il reste dans le cadre d'un développement standard. L'usage à outrance de la programmation orientée aspect est un peu déroutante mais le code généré reste du Java pur. Il évite ainsi les problèmes des langages dynamiques, mais en conservant un cycle de développement plus long. Le lancement d'un serveur d'application Java, même léger, à chaque modification du code, reste consommateur de temps.

IV-A-2 - Disponibilité des compétences

Les outils que nous avons décrits au chapitre précédent sont, pour la plupart, relativement jeunes. Par conséquent, à l'heure de la rédaction de ce document, il est difficile de trouver sur le marché des gens ayant une longue expérience de ces frameworks. La seule exception est peut-être JRuby on Rails. En effet, Ruby on Rails date de 2004 et a été adopté très rapidement et très largement. Par conséquent, il existe beaucoup de développeurs expérimentés pour cette plateforme.

Il faut se souvenir que le point commun à tous ces outils est de privilégier la simplicité à tous les étages. On constate en général une courbe d'apprentissage très rapide. Par conséquent, même avec une expérience minime voire inexistante, la prise en main et la montée en compétence se fait assez vite.

IV-A-3 - Support

Lorsqu'on étudie la question de choisir certaines technologies pour un nouveau projet, on se demande souvent si l'on sera couvert par des experts en cas de problème. Spring ROO et Grails sont développés par la société SpringSource qui propose de nombreuses formations de qualité sur ses produits. De plus, comme les produits Spring sont très répandus dans les applications d'entreprises, il est relativement aisé de trouver des prestataires compétents dans ce domaine.

Grails, comme beaucoup de produits SpringSource est open source (Licence Apache v2.0) et sa large implantation a permis à une forte communauté de se développer. Par conséquent, trouver des tutoriels ou simplement de l'aide sur des forums, est assez simple.

JRuby on Rails bénéficie de la large communauté de développeurs Ruby on Rails pour ce qui est des ressources sur la partie Ruby. Mais la partie spécifique JRuby n'est pas en reste : même si elle est nettement plus restreinte, la communauté JRuby est active et le projet est mature et soutenu par des entreprises depuis des années. Documentations et tutoriels sont donc au rendez-vous.

Pour le soutien des professionnels, on peut se tourner vers l'éditeur qui soutient le projet : EngineYard. Actuellement, trois des quatre développeurs piliers de JRuby y travaillent. La société ThoughtWorks est également présente et offre des outils, des formations et du support sur JRuby, sans parler de tous les organismes de formation en tous genres qui fleurissent autour de Ruby on Rails.

Pour le framework Play!, la donne est différente. Même s'il tend à se diffuser, il est encore relativement peu répandu. Zenexity, l'éditeur soutenant Play!, est virtuellement le seul acteur à pouvoir proposer une véritable expertise professionnelle sur son framework. La communauté de développeurs est également à la mesure de son succès en entreprise : grandissante mais mince.

IV-A-4 - Débogage

Le point noir de ces nouveaux frameworks se situe dans le débogage des applications. L'utilisation des langages dynamiques supprime la phase de compilation, et reporte donc la détection de problèmes au runtime. Le cycle de développement raccourci permet de compenser cela : on édite les sources, on rafraîchit le navigateur Web, on voit immédiatement le résultat. De plus, des pages d'erreurs gérées par les frameworks permettent de mettre en lumière les problèmes survenant au runtime.

L'utilisation de méthodes existant uniquement au runtime multiplie les risques d'erreur lors de la rédaction du code et les environnements de développement sont plutôt mal outillés pour faire face à ce problème. Encore une fois, Spring ROO fait exception grâce à l'utilisation de Java pur.

IV-A-5 - Migrations de base de données

Dans l'optique d'une migration vers les frameworks haute productivité, un risque important porte sur l'héritage du modèle de la base de données. Dans le cas de la reprise d'une application existante, un modèle de données est forcément déjà utilisé en production. L'inconvénient de cette situation est qu'elle va à l'encontre de la logique de construction de ces outils. La convention est de rédiger le modèle de données dans l'application et de laisser le framework générer le schéma pour le moteur de base de données.

Il est possible, qu'il s'agisse de Grails ou de JRuby on Rails, de spécifier, champ par champ le nom des colonnes à utiliser pour le stockage. L'inconvénient de cette méthode est qu'elle introduit, avec la saisie manuelle, de nombreux risques d'erreur. De plus, toute la force des frameworks haute productivité repose sur l'usage de conventions intelligentes. Plus on s'écarte de ces conventions, plus on risque de perdre les développeurs amenés dans le futur à travailler sur le code.

D'une façon générale, il est préférable de travailler dans le cadre d'utilisation classique de l'outil. Une méthode de reprise de l'existant pourrait alors consister à :

- figer le schéma de base de données de l'application en cours de migration ;

- développer la nouvelle application et déployer son modèle dans une autre base ;

- rédiger des scripts de migration de données de l'ancien modèle vers le nouveau.

Cette méthode présente l'avantage de supprimer la dette technique due à la conservation de l'ancien modèle. Les scripts de migration de données sont susceptibles d'être rejoués plusieurs fois. Cela permet de procéder à des séries de tests de la nouvelle application avec les données issues de l'ancienne.

« Une personne qui n'a jamais commis d'erreurs, n'a jamais tenté d'innover » Albert Einstein

IV-B - Qui utilise ces frameworks ?

Pour JRuby on Rails :

- Oracle ;

- Sun Microsystems ;

- SonarSource ;

- et d'autres (http://kenai.com/projects/jruby/pages/SuccessStories)…

Pour Grails :

- Wired.com ;

- Linked In ;

- Sky TV ;

- et d'autres (http://grails.org/Success+Stories)…

Pour Play! :

- http://www.bandbmedia.com ;

- http://www.seine-et-marne.fr ;

- http://sushiwidget.blogspot.com ;

- et d'autres (http://www.playframework.org/documentation/1.0/home)…

Pour Spring ROO :

- Il n'existe encore aucun projet professionnel mis en production sur cette base.

V - Une solution d'avenir ?

V-A - Plus de productivité

Le nombre de projets lancés et menés à bien depuis les débuts de ces frameworks semble confirmer que les promesses de gain de productivité sont effectivement au rendez-vous. Aujourd'hui le développement d'applications subit des mutations dans le but de produire plus vite des logiciels de meilleure qualité. La démocratisation des méthodes agiles, telles que Scrum, montre bien que les méthodes changent. Les outils suivent la même tendance et les frameworks haute productivité en sont un bon exemple. Ils tentent de s'affranchir des architectures et méthodes vieillissantes pour se concentrer sur l'essentiel, le simple et l'efficace.

V-B - Une initiative professionnelle

JRuby existe depuis 2001, Ruby on Rails depuis 2004 et Grails depuis 2005. Tous ces projets, Play! y compris, ont reçu le soutien d'entreprises. Ils sont aujourd'hui matures et continuent à être portés par le monde professionnel. Spring ROO est plus jeune mais fait partie du portefeuille d'applications SpringSource.

SpringSource est aujourd'hui parmi les sociétés incontournables du monde Java. Elle fait partie de l'alliance OSGI, participe au Java Community Process, et édite un framework parmi les leaders dans les développements récents. Si SpringSource s'est lancée dans la voie de la haute productivité, il faut envisager que cela devienne un standard ou presque dans les années à venir.

V-C - Adoptés par la communauté

Les frameworks haute productivité possèdent une courbe d'apprentissage très rapide. Ils sont donc tout à fait adaptés à l'autoformation. C'est sûrement pourquoi ils sont si largement adoptés par la communauté des développeurs. Leur large diffusion est un gage de pérennité pour l'avenir. De plus, la combinaison Open Source et large communauté assure détection et correction rapide des bugs.

VI - Synthèse

Au fil de ce document, nous avons pu mettre en évidence les avantages et les risques que présente l'utilisation des frameworks haute productivité. Cette approche neuve est déjà très populaire chez les développeurs et commence à faire son entrée dans le monde de l'entreprise. La philosophie de ces outils est tout à fait compatible avec les méthodes agiles qui ont actuellement le vent en poupe. Elle vient même les compléter de façon très efficace. Le prototypage rapide et la possibilité d'affiner petit à petit le code généré s'intègre naturellement dans le processus de développement itératif promu par Scrum.

Les outils sont déjà là. Ils sont de plus en plus utilisés dans de nouveaux projets d'applications d'entreprise. Parmi eux, il semble que Grails soit le plus à même de se positionner comme un leader de la tendance. En effet, JRuby, bien que plus mature, représente un pas plus grand à franchir, puisqu'il impose d'adopter un nouveau langage de programmation au sein des équipes.

Spring ROO est un autre bon candidat. Le support d'une société comme SpringSource peut apparaître comme un gage de pérennité. Il présente un autre avantage, celui de proposer de la génération de projets avec toute la pile Spring, y compris Spring MVC, qui existe depuis quelque temps déjà, permettant ainsi de capitaliser sur les connaissances existantes des équipes. Ici, point de langage de script, mais un code généré orienté aspects un peu déroutant et extrêmement verbeux. De plus, le projet n'est pas encore parvenu à la livraison de la version 1.0 stable. Ce jalon semble indispensable pour prétendre devenir le socle d'applications en production.

Le framework Play! semble assez prometteur mais ne bénéficie pas de la communauté d'un Grails ou d'un Ruby on Rails. La société qui soutient le projet ne fait pas vraiment le poids face à la détermination d'un SpringSource. Mais il pourrait à l'avenir gagner en popularité, notamment grâce à la réactivité de l'équipe projet.

Finalement le meilleur candidat pour passer le cap des frameworks haute productivité, du moins pour le monde Java, est incontestablement Grails. Pour toutes les entreprises possédant des compétences Java, il est le plus mature du paysage actuel. Le langage de scripting Groovy est très digeste et le projet est déjà utilisé en production sur des applications conséquentes. Le soutien de SpringSource et la forte communauté en place sont également un gage de pérennité et assurent un bon support en cas de besoin.

VII - Conclusion

Les frameworks que nous vous avons présentés ici ne règlent bien sûr pas définitivement le problème de la productivité des développements - il s'agit probablement d'une quête sans fin. La productivité reste, rappelons-le, contrainte par la complexité intrinsèque - essentielle - de la conception logicielle.

Nous estimons, à l'instar de Brooks dès 1986, que la maîtrise de cette complexité passe par des méthodes de travail pragmatiques, autorisant une construction incrémentale des solutions - méthodes aujourd'hui regroupées sous le vocable agile, et dont Xebia se fait l'avocat depuis plusieurs années. Les frameworks Web Java haute productivité nous semblent le complément idéal de cette nouvelle praxis. Ils permettent de construire à une vitesse stupéfiante des prototypes opérationnels qui pourront être peaufinés à mesure que le développement progresse. La compacité du code produit est un gage de maintenabilité et d'évolutivité. L'assise Java permet de bénéficier spontanément de la puissance la plateforme JEE, et ouvre les portes de l'informatique d'entreprise.

Ces solutions sont jeunes, bien sûr, et leur succès repose sur leur capacité à rassurer. Mais les plus matures d'entre elles sont d'ores et déjà de qualité production - et des applications conséquentes sont déjà déployées sur ce socle. Cette précocité est, au demeurant, la preuve qu'elles remplissent bien leurs promesses - développer et déployer plus vite.

Xebia a déjà pu constater chez certains de ses clients à quel point l'utilisation combinée de Scrum et de Grails permet d'accélérer considérablement le développement. Et nous gageons qu'une telle combinaison est l'une des clés de l'informatique de demain.

« Il faut faire des choses folles avec le maximum de prudence. » Michel Mohrt

VIII - Annexes

VIII-A - Grails & Groovy

- http://grails.org/

- http://groovy.codehaus.org/

VIII-B - Play! framework

- http://www.playframework.org/

VIII-C - Spring ROO

- http://www.springsource.org/roo

VIII-D - JRuby & Ruby on Rails

- http://www.jruby.org/

- http://rubyonrails.org/

- http://www.business-on-rails.com/

IX - Remerciements

Cet article a été mis au gabarit de developpez.com : voici le lien vers le PDF d'origine : Xebia_Les_frameworks_web_Java_Haute_Productivite.pdf.

Nous tenons à remercier Philippe DUVAL pour sa correction orthographique attentive de cet article et Régis Pouiller pour la mise au gabarit.