xebia les frameworks web java haute productivite

8/3/2019 Xebia Les Frameworks Web Java Haute Productivite

1/28

Les frameworks web Java "Haute Productivit" Aurlien Maury 1 / 28

Les frameworks web Java "Haute Productivit"

Depuis plusieurs mois dj, une nouvelle gnration de frameworks de dveloppement agitela communaut Java. Ils se nomment JRuby on Rails, Grails ou Spring ROO, et proposentrien de moins que de repenser notre faon de construire des applications Web en Java.Alliant gnration de code, conventions de programmation, langages dynamiques etinstrumentation de bytecode Java, ces frameworks sont l'aboutissement d'une lentematuration. Leur origine est chercher dans une constante qute de simplicit dans unenvironnement technique de plus en plus complexe.

Nous avons choisi de qualifier ces frameworks de frameworks haute productivit. Nousestimons, en effet, qu'ils offrent un modle programmatique trs simple tout en bnficiant dela richesse et des capacits de l'cosystme Java. Ils constituent en cela une synthse entreles deux tendances souvent divergentes qui animent l'innovation technologique depuisbientt 15 ans : la standardisation des aspects les plus complexes des architecturesmodernes d'une part, la recherche de simplicit, de rapidit et d'efficacit d'autre part.

Parler de haute productivit invite d'emble quelques prcautions : un framework n'tantqu'un outil, on conviendra sans peine que sa productivit dpend directement de la tchepour laquelle on s'en sert. L'usage d'une trononneuse amliore nettement la productivitd'un bcheron, mais freine plutt celle de l'bniste... Les frameworks haute productivitpossdent des caractristiques similaires : ils augmentent fortement la productivit desdveloppements pour certaines typologies d'applications (essentiellement celles qui sontorientes donnes), mais ne constituent en aucun cas une solution universelle laproblmatique de la productivit du dveloppement logiciel en gnral.

Aprs un court apart sur cette notion de productivit applique au dveloppement logiciel,nous vous raconterons la gense de ces frameworks. Nous vous prsenterons ensuite lesprincipaux acteurs de la mouvance : le prcurseur, JRuby on Rails, le favori, Grails, lechallenger, Spring Roo et enfin l'outsider, Play!. Nous voquerons enfin, avant de conclure, lamise en uvre de ces frameworks, les risques et opportunits lis leur adoption.

"La simplicit est la sophistication suprme."

Lonard de Vinci

Aurlien Maury

http://blog.xebia.frhttp://www.xebia.fr

Xebia IT Architects SAS

10/12 Avenue de lArche

92419 Courbevoie Cedex

Tl : 01 46 91 76 16Mail : [email protected]


2/28


A propos de productivit........................................................................................................3Brve histoire des frameworks Web Java ............................................................................5Tour d'horizon .........................................................................................................................7

Caractristiques communes ..................................................................................................7 Architecture compacte .......................................................................................................7 Convention contre configuration ........................................................................................ 7Langage dynamique et gnration de code.......................................................................8Runtime Java .....................................................................................................................8Bon support des mthodes agiles......................................................................................9

Les acteurs de la tendance..................................................................................................10Le prcurseur relook : JRuby on Rails ........................................................................... 10Le favori : Grails ...............................................................................................................14Le challenger : Spring ROO .............................................................................................17 L'outsider : Play!...............................................................................................................21

Mise en uvre .......................................................................................................................22Risques................................................................................................................................22

Cot d'apprentissage .......................................................................................................22 Disponibilit des comptences.........................................................................................22Support.............................................................................................................................22 Dbogage.........................................................................................................................23 Migrations de base de donnes ....................................................................................... 23

Qui utilise ces frameworks ?................................................................................................24Une solution d'avenir ?.........................................................................................................25

Plus de productivit .............................................................................................................25Une initiative professionnelle ...............................................................................................25 Adopte par la communaut................................................................................................25

Synthse ................................................................................................................................26Conclusion.............................................................................................................................27 Annexes .................................................................................................................................28

Grails & Groovy ...................................................................................................................28Play! framework ...................................................................................................................28Spring ROO .........................................................................................................................28JRuby & Ruby on Rails........................................................................................................28


3/28


Aproposdeproductivit

Avant d'aborder plus en dtail les frameworks haute productivit, il est ncessaire des'intresser un peu la notion de productivit applique au dveloppement logiciel.

En conomie classique, la productivit dsigne le rapport entre la valeur ajoute et la quantitde travail ncessaire sa cration. Rapporte au dveloppement informatique, cettedfinition pose un double problme. D'abord celui de la valeur ajoute, qui chappe engrande partie aux quipes de dveloppement. Dvelopper trs vite un logiciel inutile neprsente, bien sr, pas le moindre intrt. Symtriquement, et quelle que soit la valeur de cequi a t dvelopp, cette valeur n'est actualise qu' partir du moment o le logiciel a tdploy et a commenc gnrer le revenu pour lequel il a t conu. Et l aussi, leprocessus de dploiement chappe bien souvent aux quipes de dveloppement proprement parler. Optimiser la productivit du processus de dveloppement logiciel relveen consquence d'une approche holistique qui dpasse largement le cadre de ce document.

Nous devrons donc ici nous contenter d'une dfinition plus modeste de la productivit, ne

prenant en compte que la portion de la cration de valeur ajoute attribuable l'activit dedveloppement proprement parler.

La question qui se pose alors est la suivante : comment rduire la quantit de travailncessaire l'laboration et la construction d'un logiciel informatique ?

Comme dans n'importe quel secteur, la recherche de gains de productivit dans ledveloppement logiciel est depuis longtemps un puissant vecteur d'innovation, la foistechnologique et mthodologique. Mais peu de secteurs ont connu autant d'espoirs dus enla matire... Ce phnomne prend racine dans la nature mme du dveloppement : chaquelogiciel est un produit unique, dont la mise au point est tributaire d'oprations trssophistiques visant en matriser la complexit. Il s'agit en somme de traduire desprimitives trs frustres - un jeu d'oprations binaires limit, des registres, des espacesmmoire adressables - en comportements de haut niveau visant le plus souvent permettre des oprateurs humains de manipuler des symboles trs labors.

En 1986, dans son clbre article "No Silver Bullet", Frederick P. Brooks propose une lectureoriginale et pertinente de cette complexit. Reprenant la distinction aristotlicienne entreaccident et essence, il distingue la complexit accidentelle, lie la traduction des ides enlangage machine, et la complexit essentielle, qui concerne la structure et les fonctionnalitsdu logiciel proprement parler. Pour obtenir des gains de productivit, les technologiesdevraient donc s'attacher rduire l'une ou l'autre de ces complexits.

Selon Brooks, et ds la fin des annes 80, l'volution des langages de programmation a djlimin la majeure partie de la complexit accidentelle du dveloppement logiciel. Langagesvolus, compilateurs, programmation oriente objet, ces innovations offrent auxdveloppeurs des abstractions de haut niveau les affranchissant des trivialits du langage

machine. Ajoutons qu'en supprimant en grande partie les problmatiques de gestion etd'adressage mmoire, les langages de dernire gnration - dont Java - ont achev cettevolution, sans pour autant se traduire par des gains de productivit comparables, parexemple, l'mergence du langage C.

Brooks affirme ensuite qu'aucune volution technologique ne permettra elle seule derduire ne serait-ce que d'un ordre de grandeur la complexit essentielle du dveloppementlogiciel - il se fait alors l'avocat d'une approche organique, incrmentielle, du dveloppement,ce qui le place parmi les prcurseurs de ce que l'on nomme aujourd'hui les mthodes agiles.


4/28


Les tentatives pour s'attaquer la complexit essentielle du dveloppement logiciel ont tnombreuses au cours des trois dernires dcennies - sans qu'aucune, conformment auxintuitions de Brooks, n'apporte de solution dfinitive. Cette course semble d'autant plusdsesprante que l'volution de l'informatique a fortement accru son niveau de complexit :architectures ouvertes, distribution, interoprabilit, changes, volumtrie, concurrence

massive, haute disponibilit, etc. Ces problmatiques sont devenues le lot commun de laplupart des logiciels modernes, augmentant sensiblement les difficults d'laboration et deconstruction des applications informatiques.

Au cur de ces tentatives, la notion de framework a pris une place prpondrante :frameworks mthodologiques, avec Merise, RUP, CMMi ou plus rcemment Scrum, pour neciter qu'eux ; frameworks techniques, bien sr, sous forme d'API de plus ou moins hautniveau, de dveloppements "maison" ou d'cosystmes complets tel celui offert par laplateforme JEE.

L'ide commune, derrire cette notion de framework, est d'offrir au dveloppeur un cadre detravail homogne, visant simplifier par standardisation chacune des grandes activits quiconstituent son quotidien : conception, programmation, test. L'enfer tant pav de bonnes

intentions, les frameworks ont souvent souffert d'une vision trop troite, ou idalise, de laproductivit ; les langages de quatrime gnration ont ainsi acclr la conception et laprogrammation... mais en bridant de faon excessive les possibilits des langages, lesrendant incapables d'affronter les dfis des architectures ouvertes. La gnration de code,incarne par l'approche MDA, a transfr en l'amplifiant la complexit programmatique versles modles de conception et les gnrateurs, transformant la maintenance volutive, quiconstitue pourtant plus de la moiti du dveloppement, en opration haut risque - avec biensouvent pour rsultat une calcification des logiciels. La plate-forme JEE, en fournissant desabstractions de haut niveau pour les problmatiques les plus sophistiques - distribution,accs aux donnes, gestion de ressources, etc. - a rintroduit une complexit accidentelleforte dans le dveloppement, au dtriment des applications les plus simples. Quant auxframeworks de dveloppement Web chargs de simplifier la mise en uvre de l'architectureJava, comme Struts, JSF, Tapestry, Wicket et autres, ils ont souvent fait ple figure

compars aux environnements RAD des annes 90 - malgr l'apparition d'IDE trs productifs.

Cette recherche de gains de productivit par laboration successive de frameworkstechniques de plus en plus matures est le moteur de l'volution de la plateforme Java, dont leprolongement est aujourd'hui l'mergence des frameworks de haute productivit que nousnous proposons de prsenter ici.


5/28


BrvehistoiredesframeworksWebJava

En 1999, Sun Microsystems livre la spcification J2EE (Java 2 Enterprise Edition), destine apporter des solutions pour le dveloppement, le dploiement, et la gestion des applications

multitiers centralises sur serveur. Construit sur la base de Java 2 dition standard (JavaSE), Java EE spcifie une plateforme complte, stable, scurise, et rapide pour uneutilisation en entreprise. L'ide est de proposer un ensemble d'API standardises, prenant encharge les problmatiques les plus complexes des architectures modernes : traitement desrequtes HTTP, composants web, distribution, interoprabilit, gestion des transactions,persistance et mapping objet-relationnel, composants, gestion des ressources, changessynchrones (remoting) ou asynchrones (messaging), annuaire, scurit, assemblage etdploiement, etc. Cette approche permet une sparation en principe rigoureuse desresponsabilits : aux diteurs de serveurs d'applications d'implmenter les API ; auxarchitectes de concevoir des solutions sans se soucier outre mesure de la technologie sous-

jacente ; aux quipes projet, enfin, de dvelopper des applications exploitant les servicesofferts par la plate-forme.

La standardisation apporte par Sun a soutenu la diffusion du langage Java dans l'entreprise,devenu aujourd'hui incontournable. Comme pour tous les langages de programmationpopulaires, une communaut trs active de dveloppeurs s'est naturellement forme.

Trs rapidement des voix se sont leves pour critiquer le modle de dveloppementpropos par JEE, articul autour des composants EJB et synthtis dans les fameux JavaBluePrints publis par Sun. Ce message, port par la trs nombreuse communaut OpenSource java peut se rsumer ainsi : trop complexe! (entendons : pas assez productif). Pourreprendre la grille de lecture de Brooks, JEE a rintroduit une forte complexit accidentelledans le dveloppement Java, avec pour consquence une baisse de productivitconsidrable pour les applications les plus simples (celles essentiellement orientes donnesque l'on retrouve en masse dans les entreprises). Quiconque a abandonn ses outils RADclient-serveur pour adopter J2EE au dbut des annes 2000 a probablement gard de

l'exprience des souvenirs pour le moins mitigs... Pour pallier cette difficult, c'est cettepoque qu'ont merg la plupart des frameworks de dveloppement "maison" dans lesentreprises. C'est aussi ce moment-l que la communaut Open Source a commenc offrir des alternatives, sous forme de frameworks plus ou moins spcialiss offrant desmodles de programmation simplifis pour le dveloppement d'applications Javad'entreprises ; on pourrait dater la fronde aux alentours des annes 2003-2004, qui ont vusuccessivement la sortie de l'ouvrage de Rod Johnson, "J2EE Development without EJB", lelancement de la version 1.0 du framework Spring et celui de la version 1.0 du frameworkHibernate. Ces deux frameworks ont ouvert une voie originale : conserver le potentiel de laplateforme JEE comme socle d'excution, mais se soustraire au modle de programmation

jug inefficace propos par la spcification EJB.

La mise en comptition du standard et de ces alternatives Open Source a donn lieu une

dialectique subtile et parfois conflictuelle, dont nous vous pargnerons ici les pripties. Ellea surtout cr une mulation trs forte, moteur d'innovations trs nombreuses vers desmodles de programmation de plus en plus matures, stables, souples et productifs. Mme s'ilreste une trs grande diversit de solutions, on peut penser que Java a atteint l'ge deraison ; le modle de programmation des applications Web Java a converg :

Un framework Web MVC, orient actions (Struts 2, Wicket, Tapestry, SpringMVC, etc.) ou vnements (JSF), et associ un puissant moteur de templatespour le rendu graphique.

Un framework d'injection de dpendances pour l'assemblage des composants(Spring, EJB 3, Guice), complt des innombrables bibliothques disponiblesdans l'cosystme Java.

Un framework de mapping objet-relationnel (Hibernate ou d'autresimplmentations de JPA) pour la gestion de la persistance.


6/28


Le tout est accompagn d'environnements de dveloppement qui simplifient l'intgration et lamanipulation de ces frameworks. Certaines solutions, enfin, encapsulent l'intgralit de cescouches dans une solution homogne. C'est le cas en particulier de JBoss Seam.

Cette maturit s'est naturellement accompagne de l'mergence d'outils de gnration de

code, comme AppFuse, qui permettent de dmarrer facilement un projet s'appuyant sur descomposants standards.

Paralllement cette effervescence du monde Java, une autre branche d'innovationtechnologique a progressivement acquis ses lettres de noblesse. Davantage tourne vers ledveloppement Web proprement parler (par opposition aux applications d'entreprise), elles'articule autour de langages alternatifs : PHP, Ruby, Python... Les contraintes originellessont sensiblement diffrentes de celles adresses par la plateforme Java : schmatiquement,le dveloppement de sites Web dynamiques repose gnralement sur une architecturecompacte mais hautement scalable ; les contraintes de time-to-market imposent des cyclesde dveloppement trs courts que les langages de scripting semblent plus mme desatisfaire.

Issu de ce mouvement, le projet Ruby on Rails, n en 2004 rsume lui seul cettedmarche : une architecture trs simplifie, compltement libre de l'hritage JEE, un outillagede gnration de code et des mthodes adaptes au dveloppement Web.

L'apparition de moteurs de scriptingau sein de la JVM a ouvert la voie de la synthse de cesdeux mouvements. En hbergeant au cur du runtime Java des interprteurs de langagesdynamiques, il est possible de bnficier du meilleur des deux mondes : un modle dedveloppement hautement productif, adapt au dveloppement Web, et la plateforme JavaEntreprise, sa robustesse, ses capacits d'intgration et ses milliers de bibliothques libres.C'est cette synthse que les frameworks web Java haute productivit cherchent raliser.


7/28


Tourd'horizon

Caractristiquescommunes

Les frameworks que nous vous proposons prsentent tous un ensemble de caractristiquescommunes :

Une architecture compacte, pragmatique. Le principe Convention over Configuration. Le scaffolding (gnration de code dynamique). Pour certains, un langage dynamique. Une approche RAD, base sur un prototypage rapide. Une gestion dynamique de la base de donnes.

Le runtime Java comme moteur sous-jacent.

L'intgration des technologies web les plus rcentes (Ajax, Comet, REST). Un support intgr des mthodes agiles (dveloppement incrmental, build et

intgration continus, refactoring, dveloppement pilot par les tests).

Architecturecompacte

Ces frameworks proposent le plus souvent une architecture compacte, reposant sur uneimplmentation stricte du pattern MVC (Model-View-Controller). La couche "service", souventmise en place de faon un peu artificielle dans les applications Java d'entreprise estsupprime, au profit d'un modle riche, vritablement orient objet et autosuffisant. Cetteapproche n'interdit bien sr pas d'introduire au besoin une couche de service, mais celle-ci

n'est ni obligatoire, ni systmatique, et devra rpondre des besoins de conceptionclairement identifis. Symtriquement, l'accs aux donnes est gnralement fournidirectement par les entits (sous forme de mthodes statiques, par exemple).

Conventioncontreconfiguration

L'une des problmatiques les plus largement aborde par ces nouveaux frameworks est celledes fichiers de configuration rallonge. L'adoption du paradigme "Convention overconfiguration" (CoC) permet de rduire au minimum les besoins de configurer le frameworken lui-mme. Le temps d'criture des fichiers de configuration est ainsi libr et rendudisponible pour les dveloppeurs.

Dans la pratique, cela se traduit par des conventions de nommage de classes, de variables

et/ou de packages, qui permettent au framework, l'excution, de raliser les injections dedpendances ou la mise en place des aspects utiles. L'conomie de code crire profitegalement la maintenabilit long terme de l'application.

Bien videmment, comme pour tout standard, les conventions ne pourront satisfaire 100%des projets. Pour les besoins spcifiques ou en marge, il est toujours possible d'adapter lecomportement des frameworks en surchargeant la convention par des directives deconfiguration spcifiques.


8/28


Langagedynamiqueetgnrationdecode

La seconde activit consommatrice de temps que les outils haute-productivit visent radiquer est la rdaction des CRUD (Create-Read-Update-Delete). Il s'agit des crans qui

permettent, dans toute application, de crer, visualiser, diter et supprimer les donnes dumodle. Quel que soit le modle de donnes, la structure de ces pages est la plupart dutemps identique et demande l'criture de beaucoup de lignes de code pour trs peu de valeurajoute mtier.

En rponse cela, les outils que nous allons prsenter proposent de passer directement dela spcification du modle la gnration de code pour crer ces pages de visualisation/mise jour. Ce mcanisme de gnration de code est plus connu sous le nom de "scaffolding"chez nos collgues anglophones. Mais gardons la tte froide : le code gnr, quel que soitl'outil, reste une simple base pour soutenir le dveloppement. Les cas dans lesquels on peuts'appuyer intgralement sur du code gnr non modifi restent trs marginaux.

Le problme de la gnration de code est la maintenance. Car une fois le code gnr il fautl'adapter aux besoins spcifiques de l'application. Puis vient un jour o le modle de donnes

doit voluer, laissant alors 2 options :

Re-gnrer le code partir du nouveau modle puis refaire des adaptations surle code regnr.

Modifier la main toutes les couches impactes, ce qui demande une prcisionchirurgicale vue la quantit de code gnre.

Dans les deux cas, le risque de rgression est rdhibitoire.

Les langages dynamiques apportent une solution pour viter cette maintenance. Ilspermettent de gnrer au runtime le code ncessaire l'application en fonction du modle dedonnes uniquement. Ainsi lorsque le modle change, il suffit de relancer l'application pourque les nouvelles pages refltent les modifications. La question qui se pose alors est :Comment customiser les pages puisqu'elles sont gnres au runtime ?

Grails, par exemple, rpond cette question en permettant de surcharger uniquement lesmthodes ou les pages dont vous voulez modifier le comportement. De cette manire, lecode surcharg n'est pas impact par le changement du modle et il ne reste qu' relancerl'application pour la voir s'adapter au nouveau modle.

RuntimeJava

L'une des forces de ces nouveaux frameworks est de s'excuter sur une machine virtuelleJava, et donc d'offrir des passerelles naturelles avec l'cosystme Java. En pratique, celasignifie que le dveloppeur peut bnficier des API JEE ou de toutes les bibliothques critesen Java. Il est galement trs simple de conserver le langage Java pour certainsdveloppement, lorsque les langages dynamiques ne semblent pas les plus adapts. Enfin,en matire d'exploitation, les applications sont dployes sur les serveurs d'application Java,aujourd'hui matriss par la plupart des entreprises.


9/28


Bonsupportdesmthodesagiles

Parmi les conventions portes par les framework haute productivit, on retrouve aussi desmthodes de gestion de suivi de qualit. Chaque outil offre une arborescence projet

standard, qui inclut les notions de tests unitaires et d'intgration, des mcanismes dechargement de la base de donnes pour effectuer les tests, etc. Les grands principes portsdans les mthodes agiles ou des mthodes comme l'Extreme Programming sont doncpromus par l'utilisation de ces outils.

Cette intgration s'est faite de faon naturelle car les tendances se sont dveloppes lamme poque. De plus, chacune avait pour objectif de rompre avec les lourdeurs passespour construire une meilleure approche. La gnration de code et les langages dynamiquespermettent ds lors d'obtenir des prototypes dans un temps trs court, pour ensuite lesretoucher, les amliorer. Des frameworks comme JRuby on Rails ou Grails sont ainsinaturellement devenus d'excellents supports pour la mise en uvre des mthodes agiles.

"La simplicit n'a pas besoin d'tre simple, mais du complexe resserr et synthtis."

Alfred Jarry


10/28


Lesacteursdelatendance

Nous allons maintenant nous pencher sur les principaux outils qui existent dj pour tenter derpondre aux problmatiques de haute productivit. Pour cela, aprs une prsentation, nous

illustrerons leur mise en uvre par un exemple minimaliste : une application Librairie,permettant la saisie d'auteurs et des livres qui leur sont associs.

Nous avons videmment d faire des choix parmi les diffrents projets actifs. Ruby on Railsayant le privilge de lantriorit, nous commencerons naturellement par voquer son portagepour la plateforme Java, JRuby on Rails. Nous tudierons ensuite son clone bas sur lelangage Groovy : Grails. Nous nous intresserons ensuite Spring ROO, pour son approcheradicalement diffrente, oriente application Spring pure et gnration dynamique de code.Pour finir, nous mettrons rapidement en lumire le framework Play!, qui parat trs prometteurdans un futur proche.

Notre slection 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 prsente des aspectsintressants (notamment le langage dynamique, l'infrence de type, le dveloppement pilotpar la vue et le runtime Java), mais il n'offre pas encore notre sens la rupture propose parGrails ou JRuby on Rails en matire de cycle de dveloppement. JBoss Seam, enfin, quiintgre depuis peu du scaffolding, reste un framework assez conventionnel.

Leprcurseurrelook:JRubyonRails

Ruby est un langage de programmation objet paru en 1995. La syntaxe agrable, ledynamisme du langage et l'orientation objet ont rapidement attir un grand nombre dedveloppeurs travers la plante. En 2004 sort un framework web nomm Ruby on Rails, quiva changer la donne sur la conception des applications web. Ruby on Rails est crit en Rubyet offre de nombreuses fonctionnalits pour le dveloppement d'application web : scripts de

gnration de code, systme de versionnage du modle de donnes, systme de plugins.Son arrive a permis de populariser encore plus le langage Ruby, de nombreux plugins sontapparus et le framework a vite gagn en maturit.

JRuby est un interprteur de langage Ruby crit en Java. Initi par Jan Arne Petersen, en2001, le projet a t soutenu au fil des ans par les socits Sun Microsystems,ThoughtWorks et dernirement EngineYard, qui ont embauch les dveloppeurs principauxdu projet pour y travailler plein temps. JRuby est aujourd'hui une plateforme stable etmature pour le dploiement d'applications dveloppes grce Ruby on Rails, et c'est unepriorit de JRuby de continuer supporter ce framework.

Une fois JRuby install sur la machine, pour dmarrer notre dveloppement, une commandesuffit pour gnrer une arborescence de projet type :

$ jruby -S rails librairie -d mysql

$ cd librairie


11/28


La configuration de la connexion la base de donnes est situe dans le fichier

config/database.yml du projet. Nous allons donc le modifier pour utiliser desconnecteurs JDBC :

development:adapter: jdbcmysql

encoding: utf8

database: librairie_development

username: root

password:

En deux commandes de plus nous avons notre modle de donnes simplifi :

$ jruby -S script/generate scaffold livre titre:stringdate_edition:date

$ jruby -S script/generate scaffold auteur nom:string prenom:string

Une fois celui-ci adapt, on peut lancer la cration de la base puis le dploiement du modle :

$ jruby -S rake db:create

$ jruby -S rake db:migrate

Les classes du modle de donnes ressemblent ceci :

class Livre < ActiveRecord::Base

end

On remarque que la classe Ruby est vide, la seule information utile est qu'elle tend la classede base de la bibliothque ActiveRecord, qui constitue la couche d'accs aux donnes detoute application Ruby on Rails. La dfinition des colonnes de notre ligne de commande seretrouve dans un autre fichier, qui contient un script de manipulation de la base de donnespour crer 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


12/28


Au runtime, ActiveRecord fait le lien entre le nom de la table et le nom de la classe, etreconstitue tous les accesseurs ncessaires partir des intituls de colonnes. Ainsi on peututiliser les traditionnels getter/setter mais galement d'autres accesseurs permettant deremonter le contenu de la base de donnes.

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 modle ne sont pas lies. Nous allons donc ajouter uneassociation de faon ce qu'un Livre soit li un Auteur. Nous modifions donc la classe

Livre de cette faon :

class Livre < ActiveRecord::Base

belongs_to :auteur

end

Et nous rajoutons une colonne auteur_id dans notre table de livres pour stocker l'identifiantde l'Auteur. Pour finir nous dployons les modifications sur la base de donnes :

$ jruby -S script/generate migration add_auteur_id_to_livreauteur_id:integer

$ jruby -S rake db:migrate

Grce aux oprations que nous venons de raliser, il est maintenant possible de rcuprer

l'objet Auteur li un Livre en appelant la mthode monLivre.auteur. On remarquera queles classes et les associations dans les modles de Ruby On Rails ressemblent fortement la logique de base de donnes. C'est une approche radicalement diffrente des logiques JPAou Hibernate mais qui offre l'avantage d'tre plus concis dans la structure finale des tables.

La couche de prsentation des applications s'appuie sur des modles de documentsintgrant du scripting Ruby. Ruby on Rails propose de nombreuses mthodes pour crer destags HTML remplis par paramtrage. Cela facilite beaucoup l'criture et la maintenance despages web. Comme il s'agit de scripting Ruby intgr l'application, toutes les mthodesaccessibles dans les classes Contrleurs, le sont galement dans les vues. On peut donccrer trs simplement une liste de slection dans un formulaire :


13/28


Donnera, une fois le HTML gnr :

Dickens

La lisibilit du modle en est grandement amliore. L'exemple, donn ici pour le tag

vaut pour beaucoup d'autres, comme les tag , tous les champs deformulaires, les champs fichier destins au chargement vers le serveur, etc.

Un autre point fort de cette solution est que la communaut Ruby est trs active et ladocumentation de bonne qualit. Il est assez simple de s'autoformer sur Ruby On Rails supposer qu'on dispose d'un accs internet. JRuby fournit galement un plugin pourempaqueter une application Rails dans une archive WAR. De cette faon, il devient possiblede dployer une application Ruby on Rails sur un serveur d'applications Java. Cette mthodepermet de faire des conomies pour les entreprises qui se lancent dans l'aventure du Rubyalors qu'elles possdent dj une infrastructure Java. Il est galement possible de lancer desappels vers des classes Java et ainsi de rutiliser certains composants mtiers djdisponibles. Enfin, JRuby est un excellent interprteur Ruby qui tient largement lacomparaison avec les implmentations open source en C.

Des applications consquentes ont dj fait le choix de JRuby On Rails. Oracle, avec son

portail communautaire Oracle Mix, Sun avec le site de publication Mediacast ou le serveur desuivi de qualit de code source Sonar ont notamment opt pour cette solution.


14/28


Pour finir, Ruby on Rails possde un systme de plugins qui permet de crer descomposants rutilisables d'un projet l'autre. Le framework tant mature, de nombreuxplugins ont t dvelopps et sont disponibles sur les sites de la communaut tels querubyforge.org ou github.com. Ruby on Rails possde la force de l'exprience et de lamaturit. Grce JRuby il peut tre excut sur une JVM et bnficie donc de la portabilit et

de la stabilit du socle Java.

Lefavori:Grails

Le projet Grails a t initi par Graeme Rocher en 2005 dans le but d'apporter une rponsepour le monde Java la concurrence des frameworks de dveloppement rapide tels queRuby on Rails et le framework .Net de Microsoft. Le principe fondateur est de rpliquer lesfonctionnalits de Ruby on Rails en remplaant l'utilisation du Ruby par celle du langageGroovy. 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 qutes. Fin2008, SpringSource intgre Grails son portefeuille de produits en rachetant la socitG2One. Encore aujourd'hui, Grails est sous licence Apache 2.0.

Grails vise masquer l'utilisation des librairies standards constituant une application web enJava, par l'utilisation du langage de scripting JVM Groovy. C'est une architecture Modle-Vues-Contrleurs classique.

Pour faciliter le travail des dveloppeurs, les couches applicatives "passe-plat" ont tsupprimes, au profit d'une architecture simplifie. La couche service disparat totalement,tandis que la couche d'accs aux donnes est gre dynamiquement par un outil nommGORM (Grails Object Relational Mapping). Par exemple, si on dfinit la classe de Modlesuivante :

class Livre {

String titre

Date dateEdition

}


15/28


Au runtime, GORM instrumente cette classe avec des mthodes respectant une conventionde nom intelligente. La structure de la requte est directement dans le nom des mthodes etles valeurs sont passes en paramtres. Par exemple pour retrouver des objets de la classeLivre, 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 etP%', uneDateQuelconque)

Les associations entre entits du Modle sont galement gres par des directivescomprhensibles, directement dans les classes. Si on veut par exemple ajouter la gestiondes auteurs notre Modle, il nous suffit de crer une classe :

class Auteur {

String nomString prenom

static hasMany = [livres : Livre]

}

Le modle de la base de donnes est gnr en consquence et un code comme celui-ciragira comme on pourrait s'y attendre :

def monAuteur = Auteur.findByNomAndPrenom('Dickens', 'Charles')

monAuteur.livres.each{ arg -> println "${arg.titre}"}

Les associations faon GORM sont diffrentes des standards Hibernate ou JPA, mais leursimplicit permet de se familiariser assez vite avec cette approche. Il faut cependant faireattention aux comportements inattendus. Une bonne connaissance des conventions estncessaire pour tirer un bon parti de GORM.

Pour la partie prsentation des pages web, Grails propose une librairie de tags sur mesure,qui permet de faciliter la rdaction des pages. Les modles de pages web rdigs avec cestags sont appels 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 pourdonner un aperu du rsultat :

...

${flash.message}


16/28


Date:

...

L'utilisation de taglib est une chose trs courante dans les Java Server Pages de nombreuxautres frameworks. Les tags des Groovy Server Pages sont donc assez intuitifs pour toutdveloppeur Java.

Il est possible de crer des plugins pour les applications Grails, et ainsi d'obtenir desfonctionnalits instalables la demande. SpringSource hberge une bibliothque de pluginsdveloppe activement. Il suffit donc de quelques lignes de commandes pour ajouter unenouvelle application Grails des composants comme :

Un client CAS Un Content Management System basique. Le moteur de rgles Drools. Un paiement par PayPal Plusieurs librairies JavaScript, comme Mootools ou jQuery. Une taglib lie un player vido 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 ncessite moins d'adaptation de la part desdveloppeurs 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 possde certainessimilitudes de syntaxe avec Java. Mais il n'en est pas moins un langage de scripting partentire, qu'il faut apprivoiser. Le passage du mode explicite du Java pur au mode implicite deGroovy demande une adaptation. Par consquent il est normal de n'observer les gains deproductivit qu'aprs ce petit temps d'apprentissage.

Ce cot d'adaptation est compens par l'intgration Grails. Pour l'architecte, Grails offrel'avantage d'une pile de librairies dont la compatibilit est teste. La possibilit d'intgrer desplugins permet de conserver encore cet aspect lisse. Chaque plugin tant test et validpour une gamme de versions de Grails. On diminue ainsi fortement les risquesd'incompatibilit entre librairies. De plus les dlicates oprations de mapping de donnes etde configuration de la base, l'injection de dpendances, etc, sont gres en coulisse de faonefficace. Mme sil est toujours possible de prendre la main sur ces oprations pour desmodifications spcifiques, dans 90% des cas, le gain de temps est norme.


17/28


Lechallenger:SpringROO

Sur la voie de la haute productivit, Spring ROO propose une autre approche diffrente decelle de JRuby/Groovy On Rails. Le concept est ici trs simple : l'architecture base sur le

modle Spring est bonne mais longue rdiger, donc on conserve l'architecture et on cre unoutillage pour acclrer son criture. Au moment de la rdaction de ce document, SpringROO est en version 1.0RC3. L'outil se prsente sous la forme d'un shell permettant de lancerdes commandes de gnration de code. Le framework proprement parler est donc Spring,Spring ROO permet de monter une application beaucoup plus rapidement et de faonstandardise.

Une commande 'hint' permet de guider le dveloppeur. Cette commande, en scannant l'tatdu projet, affiche la documentation de l'tape suivante. Un projet initi par Spring ROO est unprojet classique au format Maven 2, bas sur Spring 3 et Spring MVC. Le code gnrs'appuie massivement sur la programmation oriente aspect, en s'appuyant sur la librairieAspectJ.

Voyons comment dmarrer un nouveau projet. A supposer que nous soyons dans unrpertoire cr pour hberger les fichiers du projet, on lance le shell ROO et on lance lescommandes 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 --databaseHYPERSONIC_IN_MEMORY

roo> entity --name ~.domain.Livre

Les trois commandes ci-dessus correspondent :

Gnration de l'arborescence du projet avec le nom du package racine. Configuration du projet pour l'utilisation d'une base de donnes HSQLDB stocke

en mmoire.

Cration d'une classe d'entit nomme Livre.


18/28


A partir de l nous disposons d'un projet Maven 2 complet, d'une classe de domaine

gnre, ainsi que 4 fichiers suffixs '.aj' contenant le code source AspectJ des aspectsappliqus cette classe. Il est maintenant possible d'aller directement diter le code sourcede notre classe de modle.

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

@RooEntitypublic class Livre {

}

Cette simple classe est dj instrumente par environ 120 lignes de code d'aspect. Tant quele shell ROO reste lanc, toute modification sur la classe dclenche une regnration desfichiers d'aspects pour correspondre la classe Java. C'est ce que Spring appelle de lagnration de code "active". Ainsi, si on rajoute des champs notre classe, ils serontdirectement pris en compte par le gnrateur Spring ROO. Il est galement possible decontinuer utiliser le shell pour ajouter les champs.

roo> field string --fieldName titre --class

fr.xebia.sample.roo.domain.Livreroo> field date --fieldName dateEdition --type java.util.Date --classfr.xebia.sample.roo.domain.Livre


19/28


Le shell joue un rle de chane de montage d'application. Les commandes sont trs longuesmais le shell dispose d'une compltion d'excellente qualit. L'utilisateur est trs bien guid.On peut aussi scripter une suite de commandes ROO pour dmarrer encore plus vite. Voici lecycle de dveloppement/gnration de code des applications avec Spring ROO :

Puisque nous disposons d'une classe, nous pouvons maintenant gnrer les Contrleurs etles Vues ncessaires en lanant :

roo> controller scaffold ~.web.LivreController

Ensuite, pour lancer le projet, on quitte le shell ROO et on lance tomcat grce un pluginMaven.

$ mvn tomcat:run


20/28


La mthode parat beaucoup moins directe que pour JRoR ou Grails, dans la mesure o onperd l'avantage des langages dynamiques. On ne peut plus diter, rafrachir le navigateur etvoir le rsultat. Le cycle de dveloppement, bien que fortement aid par le shell, resterelativement classique. On peut tout de mme raliser une application CRUD dployable enune dizaine de minutes :

L'un des points forts est que le code gnr est 100% Java-JSP. Il est donc accessible tousles dveloppeurs web Java. Cependant, ce code exploite beaucoup les concepts deprogrammation orient aspect, qui ne sont pas toujours matriss. Les classes de l'applicationsont dcores avec un ensemble d'annotations spcifiques et des classes AspectJ sontgnrs par ROO pour enrichir l'application. Cette complexit nouvelle est de nature temprer l'enthousiasme des dveloppeurs. Il est toutefois possible de se sparer 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 biencomprendre les mcanismes en uvre dans le projet. Dans les applications gnres,seules les couches contrleur et d'accs aux donnes subsistent. Spring ROO impose l unerupture non seulement par rapport au modle J2EE mais aussi par rapport aux principes desframework haute productivit inspirs de Ruby on Rails. Ici pas de "convention-over-configuration", tout est explicite, mais facilit par la gnration. Aucun dynamisme "magique"ne vient se rajouter au runtime.

ROO est un outil jeune et ambitieux. Il diffre dans ses choix architecturaux la fois dumonde J2EE et de celui des JRuby/Groovy on Rails. Il permet d'obtenir un excellentdmarrage projet et ensuite d'teindre le pilote automatique et lancer son quipe sur unprototype qui respecte les standards, bas sur les versions les plus rcentes de la pile

Spring. Parmi les dfauts de jeunesse du projet, on notera tout de mme que :

Bien que le shell soit intuitif et verbeux, la documentation de l'outil est quasiinexistante.

La communaut de dveloppeurs est quasi inexistante. Aucun projet d'envergure n'a t mis en production avec cet outil.

L'avenir nous dira comment voluera sa popularit.


21/28


L'outsider:Play!

Play! est un framework cr par Guillaume Bort et soutenu par la socit Zenexity. Djutilis pour certaines ralisations de la socit, Il semble que la diffusion de ce framework en

dehors des contrats de service Zenexity commence prendre un peu d'ampleur. Un site depreuve de concept a t mont pour permettre aux internautes de tester une interface richeralise avec Play! (http://en.dorse.me).

Ici le modle est gr directement par des POJO, et la couche de prsentation est constituede modles de pages en Groovy. L'accs aux donnes est gr de faon similaire Grails ouJRuby on Rails, par instrumentation des classes du modle de donnes. Le code del'application reste intgralement en Java et ne fait pas usage d'annotations sotriques. Leplus apport par Play! est de fournir un service de rechargement des classes Java qui viteles phases de recompilation et de redploiement. Il est donc possible de conserver sonapplication en cours d'excution durant tout le cycle de dveloppement. Pour chaquemodification, un rechargement du navigateur suffit voir le rsultat. Les erreurs decompilation sont gres par le framework et affiches aux dveloppeurs dans une page typepour en faciliter le diagnostic.

Plusieurs librairies sont fournies dans la pile de librairies du projet pour faciliter la vie desdveloppeurs, comme de la manipulation d'images la vole ou des mthodes JSON pour

faciliter l'interaction avec la partie Javascript de l'application. La librairie Javascript JQuery estintgre par dfaut. Du fait de sa faible audience actuelle, nous ne dvelopperons pas plusd'exemple ici. Il est bon nanmoins de connaitre l'existence de ce framework dont l'utilisationpourrait, dans le futur, se rpandre dans la communaut des dveloppeurs Web. Aprs l'avoirrd en usage interne, Zenexity fait des efforts pour diffuser son framework auprs de lacommunaut, comme semble en tmoigner leur prsence la confrence Devoxx 2009.

"The greatest things about standards is there are so many to choose from."

Martin Atkins.


22/28


Miseenuvre

Risques

Cotd'apprentissage

Les frameworks de haute productivit apportent un certain nombre de concepts nouveauxqu'il faut intgrer avant d'en tirer un bon parti. Mme si le pattern Modle-Vue-Contrleur estaujourd'hui un classique des applications web, sa mise en uvre est ici particulire. Lesconventions des framework permettent de se passer de beaucoup de code et deconfiguration mais il faut s'astreindre les respecter pour ne pas tomber dans le traversd'expliciter des oprations qui devraient tre automatises par les frameworks. Lesdocumentations sont en gnral assez compltes et claires et permettent de se formerrapidement.

L'utilisation des langages dynamiques supprime le garde-fou du compilateur. Leraccourcissement du cycle de dveloppement permet de compenser cette lacune. Ainsi, letemps ncessaire l'assimilation des nouveaux concepts et l'esquive des piges deslangages dynamiques est galement rduit. On constate en gnral une courbed'apprentissage plutt favorable sur les outils base de langage dynamique. Le cotd'apprentissage existe mais il est trs supportable et les gains retirer de cet effort valentclairement la peine.

Spring ROO est le cas part, puisqu'il reste dans le cadre d'un dveloppement standard.L'usage outrance de la programmation oriente aspect est un peu droutante mais le codegnr reste du Java pur. Il vite ainsi les problmes des langages dynamiques, mais enconservant un cycle de dveloppement plus long. Le lancement d'un serveur d'applicationJava, mme lger, chaque modification du code, reste consommateur de temps.

Disponibilitdescomptences

Les outils que nous avons dcrits au chapitre prcdent sont, pour la plupart, relativementjeunes. Par consquent, l'heure de la rdaction de ce document, il est difficile de trouver surle march des gens ayant une longue exprience de ces frameworks. La seule exception estpeut-tre JRuby on Rails. En effet, Ruby on Rails date de 2004 et a t adopt trsrapidement et trs largement. Par consquent, il existe beaucoup de dveloppeursexpriments pour cette plateforme.

Il faut se souvenir que le point commun tous ces outils est de privilgier la simplicit tousles tages. On constate en gnral une courbe d'apprentissage trs rapide. Par consquent,mme avec une exprience minime voire inexistante, la prise en main et la monte encomptence se fait assez vite.

Support

Lorsqu'on tudie la question de choisir certaines technologies pour un nouveau projet, on sedemande souvent si l'on sera couvert par des experts en cas de problme. Spring ROO etGrails sont dvelopps par la socit SpringSource qui propose de nombreuses formationsde qualit sur ses produits. De plus, comme les produits Spring sont trs rpandus dans lesapplications d'entreprises, il est relativement ais de trouver des prestataires comptentsdans ce domaine.


23/28


Grails, comme beaucoup de produits SpringSource est open source (Licence Apache v2.0) etsa large implantation a permis une forte communaut de se dvelopper. Par consquent,trouver des tutoriels, ou simplement de l'aide sur des forums, est assez simple.

JRuby on Rails bnficie de la large communaut de dveloppeurs Ruby on Rails pour ce qui

est des ressources sur la partie Ruby. Mais la partie spcifique JRuby n'est pas en reste :mme si elle est nettement plus restreinte, la communaut JRuby est active et le projet estmature et soutenu par des entreprises depuis des annes. Documentations et tutoriels sontdonc au rendez-vous.

Pour le soutien des professionnels, on peut se tourner vers l'diteur qui soutient le projet :EngineYard. Actuellement 3 des 4 dveloppeurs piliers de JRuby y travaillent. La socitThoughtWorks est galement prsente et offre des outils, des formations et du support surJRuby, sans parler de tous les organismes de formation en tous genres qui fleurissent autourde Ruby on Rails.

Pour le framework Play! la donne est diffrente. Mme sil tend se diffuser, il est encorerelativement peu rpandu. Zenexity, l'diteur soutenant Play!, est virtuellement le seul acteur

pouvoir proposer une vritable expertise professionnelle sur son framework. Lacommunaut de dveloppeurs est galement la mesure de son succs en entreprise :grandissante mais mince.

Dbogage

Le point noir de ces nouveaux frameworks se situe dans le dbogage des applications.L'utilisation des langages dynamiques supprime la phase de compilation, et reporte donc ladtection de problmes au runtime. Le cycle de dveloppement raccourci permet decompenser cela : on dite les sources, on rafrachit le navigateur web, on voit immdiatementle rsultat. De plus, des pages d'erreurs gres par les frameworks permettent de mettre enlumire les problmes survenant au runtime.

L'utilisation de mthodes existant uniquement au runtime multiplie les risques d'erreur lors dela rdaction du code et les environnements de dveloppement sont plutt mal outills pourfaire face ce problme. Encore une fois, Spring ROO fait exception grce l'utilisation deJava pur.

Migrationsdebasededonnes

Dans l'optique d'une migration vers les frameworks haute productivit, un risque importantporte sur l'hritage du modle de la base de donnes. Dans le cas de la reprise d'uneapplication existante, un modle de donnes est forcment dj utilis en production.L'inconvnient de cette situation est quelle va l'encontre de la logique de construction deces outils. La convention est de rdiger le modle de donnes dans l'application et de laisserle framework gnrer le schma pour le moteur de base de donnes.

Il est possible, qu'il s'agisse de Grails ou de JRuby on Rails, de spcifier, champs parchamps le nom de colonnes utiliser pour le stockage. L'inconvnient de cette mthode estqu'elle introduit, avec la saisie manuelle, de nombreux risques d'erreur. De plus, toute la forcedes frameworks haute productivit repose sur l'usage de conventions intelligentes. Plus ons'carte de ces conventions, plus on risque de perdre les dveloppeurs amens dans le futur travailler sur le code.


24/28


D'une faon gnrale, il est prfrable de travailler dans le cadre d'utilisation classique del'outil. Une mthode de reprise de l'existant pourrait alors consister :

Figer le schma de base de donnes de l'application en cours de migration.

Dvelopper la nouvelle application et dployer son modle dans une autre base. Rdiger des scripts de migration de donnes de l'ancien modle vers le nouveau.

Cette mthode prsente l'avantage de supprimer la dette technique due la conservation del'ancien modle. Les scripts de migration de donnes sont susceptibles d'tre rejousplusieurs fois. Cela permet de procder des sries de tests de la nouvelle application avecles donnes issues de l'ancienne.

"Une personne qui n'a jamais commis d'erreurs, n'a jamais tent d'innover"Albert Einstein

Quiutilisecesframeworks?

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.


25/28


Unesolutiond'avenir?

Plusdeproductivit

Le nombre de projets lancs et mens bien depuis les dbuts de ces frameworks sembleconfirmer que les promesses de gain de productivit sont effectivement au rendez-vous.Aujourd'hui le dveloppement d'applications subit des mutations dans le but de produire plusvite des logiciels de meilleure qualit. La dmocratisation des mthodes agiles, telles queScrum, montre bien que les mthodes changent. Les outils suivent la mme tendance et lesframeworks haute productivit en sont un bon exemple. Ils tentent de s'affranchir desarchitectures et mthodes vieillissantes pour se concentrer sur l'essentiel, le simple etl'efficace.

Uneinitiativeprofessionnelle

JRuby existe depuis 2001, Ruby on Rails depuis 2004 et Grails depuis 2005. Tous cesprojets, Play! y compris, ont reu le soutien d'entreprises. Ils sont aujourd'hui mature etcontinuent tre ports par le monde professionnel. Spring ROO est plus jeune mais faitpartie du portefeuille d'applications SpringSource.

SpringSource est aujourd'hui parmi les socits incontournables du monde Java. Elle faitpartie de l'alliance OSGI, participe au Java Community Process, et ditent un frameworkparmi les leaders dans les dveloppements rcents. Si SpringSource s'est lanc dans la voiede la haute productivit, il faut envisager que cela devienne un standard ou presque dans lesannes venir.

Adopteparlacommunaut

Les frameworks haute productivit possdent une courbe d'apprentissage trs rapide. Ils sontdonc tout fait adapts l'autoformation. C'est surement pourquoi ils sont si largementadopts par la communaut des dveloppeurs. Leur large diffusion est un gage de prennitpour l'avenir. De plus, la combinaison Open Source et large communaut assure dtectionset corrections rapides des bugs.


26/28


Synthse

Au fil de ce document, nous avons pu mettre en vidence les avantages et les risques queprsente l'utilisation des frameworks haute productivit. Cette approche neuve est dj trs

populaire chez les dveloppeurs et commence faire son entre dans le monde del'entreprise. La philosophie de ces outils est tout fait compatible avec les mthodes agilesqui ont actuellement le vent en poupe. Elle vient mme les complter de faon trs efficace.Le prototypage rapide et la possibilit d'affiner petit petit le code gnr s'intgrenaturellement dans le processus de dveloppement itratif promu par Scrum.

Les outils sont dj l. Ils sont de plus en plus utiliss dans de nouveaux projetsd'applications d'entreprise. Parmi eux, il semble que Grails soit le plus mme de sepositionner comme un leader de la tendance. En effet, JRuby, bien que plus mature,reprsente un pas plus grand franchir, puisqu'il impose d'adopter un nouveau langage deprogrammation au sein des quipes.

Spring ROO est un autre bon candidat. Le support d'une socit comme SpringSource peut

apparatre comme un gage de prennit. Il prsente un autre avantage, celui de proposer dela gnration de projets avec toute la pile Spring, y compris Spring MVC, qui existe depuisquelques temps dj, permettant ainsi de capitaliser sur les connaissances existantes desquipes. Ici, point de langage de script, mais un code gnr orient aspects un peudroutant et extrmement verbeux. De plus, le projet n'est pas encore parvenu la livraisonde la version 1.0 stable. Ce jalon semble indispensable pour prtendre devenir le socled'applications en production.

Le framework Play! semble assez prometteur mais ne bnficie pas de la communaut d'unGrails ou d'un Ruby on Rails. La socit qui soutient le projet ne fait pas vraiment le poidsface la dtermination d'un SpringSource. Mais il pourrait l'avenir gagner en popularit,notamment grce la ractivit de l'quipe projet.

Finalement le meilleur candidat pour passer le cap des frameworks haute productivit, dumoins pour le monde Java, est incontestablement Grails. Pour toutes les entreprisespossdant des comptences Java, il est le plus mature du paysage actuel. Le langage descripting Groovy est trs digeste et le projet est dj utilis en production sur des applicationsconsquentes. Le soutien de SpringSource et la forte communaut en place sont galementun gage de prennit et assurent un bon support en cas de besoin.


27/28


Conclusion

Les frameworks que nous vous avons prsents ici ne rglent bien sr pas dfinitivement leproblme de la productivit des dveloppements - il s'agit probablement d'une qute sans fin.

La productivit reste, rappelons-le, contrainte par la complexit intrinsque - essentielle - dela conception logicielle.

Nous estimons, l'instar de Brooks ds 1986, que la matrise de cette complexit passe pardes mthodes de travail pragmatiques, autorisant une construction incrmentale dessolutions - mthodes aujourd'hui regroupes sous le vocable agile, et dont Xebia se faitl'avocat depuis plusieurs annes. Les frameworks web Java haute productivit nous semblentle complment idal de cette nouvelle praxis. Ils permettent de construire une vitessestupfiante des prototypes oprationnels qui pourront tre peaufins mesure que ledveloppement progresse. La compacit du code produit est un gage de maintenabilit etd'volutivit. L'assise Java permet de bnficier spontanment de la puissance la plateformeJEE, et ouvre les portes de l'informatique d'entreprise.

Ces solutions sont jeunes, bien sr, et leur succs repose sur leur capacit rassurer. Maisles plus matures d'entre elles sont d'ores et dj de qualit production - et des applicationsconsquentes sont dj dployes sur ce socle. Cette prcocit est au demeurant la preuvequ'elles remplissent bien leurs promesses - dvelopper et dployer plus vite.

Xebia a dj pu constater chez certains de ses clients quel point l'utilisation combine deScrum et de Grails permet d'acclrer considrablement le dveloppement. Et nous gageonsqu'une telle combinaison est l'une des cls de l'informatique de demain.

"Il faut faire des choses folles avec le maximum de prudence."

Michel Mohrt


28/28

Annexes

Grails&Groovy

http://grails.org/ http://groovy.codehaus.org/

Play!framework

http://www.playframework.org/

SpringROO

http://www.springsource.org/roo

JRuby&RubyonRails

http://www.jruby.org/ http://rubyonrails.org/ http://www.business-on-rails.com/

xebia les frameworks web java haute productivite

Documents