SpringOne 2009 – Synthèse

SpringOne Europe 2009 terminé, il est temps de faire le bilan de ces 3 jours à Amsterdam : une ligne directrice, quelques annonces, de belles présentations menées par des spécialistes de renom, et surtout, beaucoup de belles rencontres et discussions off intéressantes (dont certaines ne sont pas avouables sur ce blog :))

Rod Johnson a placé SpringSource sous le signe des gains de productivité pour l’écosystème Java. Gains de productivité aussi bien sur la phase de build que dans celle du déploiement et de l’exploitation d’applications Java, un domaine dans lequel SpringSource est moins connu.

Pour la phase de build, SpringSource introduit une rupture dans le développement d’applications Java en proposant le duo Groovy&Grails qui concilie la puissance de la plateforme Java avec la productivité des très en vogue langages dynamiques. Si cette rupture est trop forte pour vous, Springsource propose un axe intermédiaire mais déjà très innovant avec Spring Roo, un façonnage du langage générique Java pour les spécificités de l’informatique de gestion.

Pour la phase de déploiement et d’exploitation, Adrian Coyler a présenté une vision inspirée des architectures Platform as a Service (e.g. Google App Engine) et Data Center as a Service (e.g. Amazon EC2, Cloud Foundry) pour aboutir à une proposition de Your Data Center as a Service. Cette vision est séduisante, dm Server, Application Management Suite et un partenariat avec VMWare en seront les piliers mais rien de concret n’est encore disponible.

Côté annonces, peu de nouvelles fracassantes pour cette édition. Pas de grands communiqués depuis notre revue de presse de lundi dernier, en résumé :

• Sortie de tcServer 1.0 en GA, probablement le meilleur moyen pour SpringSource de faire rentrer de l’argent.
• Un nouveau produit : Spring ROO, il s’agit d’un générateur de code Java offrant la possibilité d’effectuer des opérations CRUD facilement mais pas seulement…
• Diffusion gratuite de Spring Tool Suite, ensemble de plugins Eclipse dédiés aux technologies Spring.

Le catalogue de produits et services s’agrandit, et la communauté avec. La parade de SpringSource afin de séduire un éventuel racheteur continue de se mettre en place.

Nous vous avions soumis une liste de questions, c’est maintenant l’heure de relever les copies :) voici quelques débuts de réponses aux interrogations que nous nous posions :

Tomcat, tcServer et dmServer

SpringSource a beaucoup investi sur les technologies serveur autour de Tomcat depuis le rachat de Covalent l’année dernière. Tomcat 6 reste un projet Apache et n’est pas sous le contrôle direct de SpringSource. Cela dit, Mark Thomas devenant probablement Release Manager de Tomcat 7, SpringSource devrait avoir la possibilité de pousser d’avantage ses idées, même si le mécanisme de vote par les committers du projet Tomcat permet à n’importe lequel d’entre eux de bloquer une initiative de SpringSource. Par exemple, nous verrons si le nouveau pool de connexions JDBC développé par Filip Hanik deviendra le pool par défaut de Tomcat 7.

La plus belle carte à jouer reste probablement celle de tcServer. Avec ce nouveau serveur d’applications, SpringSource espère charmer aussi bien les utilisateurs de gros serveurs d’applications onéreux et compliqués n’utilisant que peu de fonctionnalités de leur bulldozer, que les utilisateurs de Tomcat en manque d’outils d’administration et de supervision.

A plus long terme, ce serveur doit également jouer le rôle de chant des sirènes en proposant aux utilisateurs de tcServer une migration simple vers dmServer. C’est là que la stratégie de SpringSource n’est pas complètement claire. Nous avons eu deux sons de cloches à la question : que deviendra tcServer lorsque dmServer disposera de la compatibilité Tomcat (comme cela est prévu dans la roadmap) ? Là où le directeur Marketing de SpringSource Europe nous affirme que, peu à peu, dmServer sera amené à remplacer complètement tcServer et que ce dernier devra disparaître probablement à moyen terme; Mark Thomas nous répond qu’au contraire les deux serveurs continueront leur existence avec des roadmaps bien différentes. Dans les faits, tcServer a été créé pour combler des fonctionnalités en avance de phase par rapport à la roadmap de dmServer. Peut-être cet appel d’air a-t-il donné plus d’idées aux développeurs de tcServer ?

Quant à dmServer, il n’est pas encore tout à fait sec. Non seulement la communauté n’est pas forcement prête à passer à un serveur d’applications full modulaires, mais aussi, de l’aveu même de Jurgen Holler, il manque un certain nombre de fonctionnalités core. C’est d’ailleurs l’une des raisons qu’il donne pour expliquer le descopage de la certification Java EE 6 Web Profile, qui n’apparait plus dans leur roadmap. Ils ne sont pas complètement opposés à la passer (et encore) mais ce ne sera pas pour demain. On aurait pourtant pensé qu’il s’agirait d’un moyen supplémentaire de rassurer les équipes d’exploitation et faciliter l’accès à leurs produits.

Et enfin, pour clôturer ce sujet, à titre informatif, dmServer est développé par une équipe anglaise constituée de 5 à 8 personnes. Cette petite taille d’équipe est voulue car propice aux méthodes agiles et à un fonctionnement itératif à cycle court.

Spring 3.0 et Java EE

Si la certification dmServer avec Java EE n’est plus d’actualité, cela ne veut pas forcement dire que SpringSource se ferme complètement à Java EE. La présentation de Jurgen Holler à ce sujet était d’ailleurs probablement l’une des plus intéressantes de ces 3 jours. Là où Rod Johnson, durant son Keynote, se contentait de casser Java EE sans trop apporter d’arguments, Jurgen a effectué un tour détaché et pragmatique des futures fonctionnalités de Java EE 6.

Java EE est source d’inspiration de Spring. De nombreux composants Java EE 5 et 6 se retrouvent ou se retrouveront directement dans Spring. L’inverse est également vrai, pour Jurgen, les EJB 3.1 sont par exemple très largement inspirés de la stack Spring. Au-delà de la petite guerre des chapelles, prendre les bonnes idées où elles se trouvent est une bonne chose. Il me semble que cette inspiration mutuelle fait avancer tout le monde dans la bonne direction et que cette petite concurrence est propice à l’innovation. Ces deux stacks proposent des approches différentes : là où Java EE reste bas niveau en offrant une plateforme de déploiement et des providers de services système, Spring s’attache à rester le plus proche possible de vos applications.

C’est donc un fait, Spring 3.x disposera de fonctionnalité Java EE 6, en voici un petit tour d’horizon :

• Servlet 3.0 est prévu pour être intégré à Spring 3.2. Le support d’endpoints HTTP asynchrones comet sera rendu compatible avec Spring MVC par l’intermédiaire d’une requête et réponse spéciale (pas plus d’information à ce sujet). La détection automatique des servlets destinée à réduire la taille du fichier web.xml permettra l’auto déploiement du Spring Web Context, cette fonctionnalité n’apportera évidemment que peu de choses dans une stack Spring.
• JSR-236 – Concurrency utility for Java EE, Spring 3.0 contiendra probablement un nouvel adaptateur de scheduling si cette JSR, passé en statut inactif n’est pas descopé de Java EE 6.
• Évolutions naturelles des supports JSF et JPA, leurs versions 2.0 respectives seront donc également intégrées à Spring 3.0. Il en est de même pour la JSR-303 bean validation.
• Le support REST est l’une des grandes nouveautés de Spring 3.0. Dans ce sens, les endpoints JAX-RS pourront être managés comme de simples beans Spring.
• La JSR-299 – Java Contexts and Dependency Injection (JCDI), anciennement appelée WebBeans, est probablement la JSR la plus problématique. D’après Jurgen, chaque question posée sur cette JSR remet en cause les bases même de cette spécification dont le scope d’utilisation reste relativement flou.

Spring ROO, le petit dernier

Bien que nous connaissions l’existence de ce projet, la conférence nous a permis d’en savoir plus à son sujet et surtout de le voir fonctionner en live. Ce générateur de code est le fruit du travail d’un homme sur plusieurs années. C’est Ben Alex, le papa de Spring Security qui s’y est collé. Il a été rejoint plus récemment par une seconde personne à mi-temps.

ROO permet la génération et la configuration d’applications Java sans avoir à taper la moindre ligne de code. De la persistance à la couche présentation, tout est généré à la demande par l’intermédiaire de lignes de commandes à exécuter dans une console spécifique. La console est disponible sous plusieurs formes : directement intégrée au shell ou par l’intermédiaire d’un plugin Eclipse SpringSource Tool Suite. ROO est téléchargeable dans sa version alpha depuis mercredi soir. Pour l’avoir testé un peu, en voici nos premiers retours. Un billet complémentaire dédié à ce sujet viendra probablement compléter celui-ci.

// initialisation d'un projet à partir d'un répertoire vierge
roo> create project -topLevelPackage fr.xebia.roosample.blog
// configuration du niveau de log 
roo> configure logging -level DEBUG

// ajout du support JPA
roo> install jpa -database H2_IN_MEMORY -provider HIBERNATE

// création d'une entité JPA et de ses champs
roo> new persistent class jpa -name ~.model.Article
roo> add field string -fieldName title -notNull -sizeMax 100
roo> add field string -fieldName content

// génération de finders
roo> list finders for -class ~.model.Article
roo> install finder -class ~.model.Article -finderName findArticlesByTitleLike

// generation du controller associé
roo> new controller automatic -name ~.web.ArticleController -formBackingObject ~.model.Article

Si les lignes de commandes vous paraissent longues et compliquées, il n’en est rien. J’avoue avoir été séduit par la facilité avec laquelle vous écrivez vos commandes : la console vous guide à chaque étape en vous fournissant une aide à chaque instant et surtout une complétion très pratique d’utilisation. Autre facilité non négligeable, la saisie contextuelle. Les commandes que vous tapez s’exécutent toujours en fonction du dernier concept manipulé. Cela vous permet d’omettre de saisir certaines options, la console se charge que les retrouver en fonction du contexte. Une console dans un monde d’IDE et de wizzards ? Quelle drôle d’idée ! Et pourtant, le résultat plutôt efficace, le gain en productivité est notable.

Une fois que le projet est créé, vous pouvez à tout moment générer le squelette Eclipse via Maven pour consulter et étoffer vos sources. Et là encore, vous risquez d’être surpris ! ROO remet en cause le modèle en couche qui faisait autrefois l’unanimité dans le monde Java. En plus de l’utilisation des objets du domaine dans la vue, ROO supprime la couche DAO au profit du modèle Active Record avec l’ajout de méthodes d’instance merge / remove et statiques … cela risque de ne pas plaire à tout le monde. De plus, le code source est façonné aux besoins de l’informatique de gestion. Pour le développeur, le code est généré de manière transparente (getter, setter, toString merge, remove, finder, …) grâce au compilateur AOP d’AspectJ : la majorité de celui-ci est déléguée dans des aspects, les beans sont annotés par des Annotations spécifiques Roo : @RooEntity, @RooJavaBean, @RooToString pour les activer.

Pour plus d’information sur le sujet, Ben Alex vient de blogger sur ROO.

Groovy

Six mois après le rachat de G2One, Spring ne semble pas tirer pleinement profit des possibilités Groovy et Grails. Guillaume Laforge passe plus de temps sur les évolutions de Groovy et sa prochaine version 1.7 que sur des intégrations avec la stack Spring. Il m’a tout de même dit avoir effectué quelques prototypes : intégration Groovy avec Spring Batch, configuration tcServer et dmServer avec Groovy, mais aucun d’entre eux n’a pour le moment débouché sur un développement concret.

Concernant Grails, G2One a été racheté après le démarrage de Spring ROO, aucune coordination n’a donc été possible entre ses deux projets.

Les partenariats

De manière générale, nous avons été déçus des fruits récoltés des différents partenariats (représentés à la conférence).
Seul Spring Batch, porté par Accenture, propose un outil finalisé et abouti.

Concernant le partenariat Terracotta, rien de concret pour le moment. Là où nous espérions une collaboration forte avec Spring, il nous a semblé que la roadmap était plutôt vide. Par ailleurs, en discutant avec eux, on avait plus l’impression de leur donner des idées que de récolter des informations.

Le partenariat avec Adobe est légèrement plus abouti avec un début d’intégration entre Spring et Blase DS. Après en avoir descendu les sources, le contenu du projet ne nous a pas fait rêver. Nous n’avons pas pu récolter d’autres informations sur d’éventuels autres futurs projets en commun.

Le mot de la fin

La communication sur leur site officiel en témoigne, SpringSource ne se focalise plus seulement sur la phase de développement. Leur catalogue d’offres et de services leur permet de toucher un plus large public, autour d’un maître mot : ‘gain en productivité’.

• depuis la phase de développement : avec Spring ROO, Groovy…
• jusqu’à l’exploitation : avec AMS, tcServer…
• en passant par le déploiement : virtualisation, platform as a service…