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

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

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.

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.

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.

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

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.

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.

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

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.

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.

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.

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.

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.

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