SpringSource met l'agilité au coeur de sa plate-forme Java (Gauvain Girault, FastConnect) L'absence d'une brique de middleware distribué
Spring ne s'adresse plus seulement aux développeurs et architectes
Au-delà de la vision d'ensemble fournie par le CTO SpringSource, l'ensemble des sessions sur les nouveautés du framework Spring 3.0, Spring Roo ou la comparaison entre Spring et JavaEE ont permis de faire ressortir les caractéristiques suivantes de l'offre SpringSource :
SpringSource tient à rester fidèle à sa philosophie qui considère que le développement d'applications Java se doit d'être simple, modulaire, léger et surtout contrôlé par le développeur. Spring propose, simplifie, et le développeur dispose.
JSF 2.0, JPA 2.0 et JSR-303 supportés par Spring 3
Au delà de la couverture des fonctionnalités d'entreprise fournies par le framework Spring à travers ses différents projets Spring Core / Web / BlazeDS, Spring Integration ou Spring Batch, un accent particulier est mis sur les aspects productivité et la simplicité d'utilisation. Des outils tels que Spring Roo et Groovy / Grails, mais aussi Spring STS et Spring Insight par exemple sont là pour en attester.
Les technologies SpringSource ne s'adressent plus uniquement aux développeurs et architectes, mais couvrent l'ensemble du cycle de vie d'une application Java, de son développement jusqu'à son déploiement et sa supervision.
Les concepts de modularité, de simplicité et de non intrusivité qui ont fait le succès du framework Spring pour la phase de développement sont appliqués aux phases d'exécution, de déploiement et de supervision. D'autre part, l'effort d'unification et de liant entre les différentes briques modulaires de l'offre est visible, notamment avec le plug in Eclipse STS.
SpringSource avance rapidement sur les aspects virtualisation applicative et déploiement sur des cloud publics ou privés à travers son intégration à VMWare et CloudFoundry. Le projet NAPA est à suivre avec attention.
SpringSource n'oublie pas les bienfaits de la standardisation à travers le support de certaines spécifications de Java EE 6 dans Spring 3.0, tels que JSF 2.0, JPA 2.0, le modèle de validation JSR-303 (Bean Validation) exploité par l'ensemble des couches du framework (présentation, persistance). Le support Java EE 6 sera un des points importants de la version 3.1.
Une différence de vision entre Java EE et le "standard de fait" Spring
Il est vrai qu'on s'est bien rendu compte, lors de la dernière session d'Alexis Moussine-Pouchkine (middleware evangelist chez Sun) et Michaël Isvy (senior consultant chez SpringSource), de la différence de vision et d'objectifs entre la spécification Java EE et le "standard de fait" Spring.
Cependant, il est clair que malgré ses différences, SpringSource ne désire pas s'isoler de la communauté Java, et a pour objectif de s'intégrer de la meilleure manière à Java EE6 . Le défi des équipes SpringSource est donc de réaliser cette intégration sans renier les qualités de son framework.
J'aurais aimé entendre la vision de SpringSource sur la présence dans l'offre d'une brique middleware distribué
A la sortie de cette matinée, j'ai été extrêmement séduit par l'offre SpringSource et la vision proposée. Une interrogation autour de la brique middleware subsiste dans mon esprit cependant. Travaillant au jour le jour sur des problématiques d'architecture distribuées, j'aurais aimé entendre la vision de SpringSource sur la présence dans l'offre d'une brique middleware distribué (caching, messaging).
Cette brique est actuellement laissée au choix de chaque projet, qui doit alors définir ses bonnes pratiques dans ce domaine, et gérer son intégration. Tout vient à point qui sait attendre.
Pour résumer, je dirais que la force de l'offre SpringSource est de combiner, dans toutes les phases du cycle de vie d'une application, les aspects agilité, flexibilité, et légèreté, tout en embarquant au niveau des composants techniques les meilleures pratiques de développement ou d'architecture.
Cela me semble une approche en ligne avec les besoins de qualité, de disponibilité et de performance de nos applications Java d'entreprise.
Cette combinaison gagnante permet de minimiser le temps de création de valeur métier, sans compromettre les aspects qualité et maintenabilité des applications.