Compte-rendu de SpringOne 2008

Orateur : Rod Johnson
Fonction : Président et CEO SpringSource

Le début de la keynote par Rod Johnson fut une légère propagande de Spring vis à vis de l'architecture lourde de JEE/EJB.
Le discours de Rod est ensuite devenu un peu plus technique en présentant les nouveautés de la version 2.5 et le portfolio Spring.

Il présenta par exemple le support des annotations pour l'injection de dépendances, et l'avantage de celles-ci par rapport à l'autowiring sur les types ou sur le nom.
L'utilisation de @Qualifier ou des Méta-Annotation (une annotation spécifique annotée elle-même par @Qualifier ) permet de marquer explicitement un Bean. Ce qui permettra à un autre Bean de spécifier que l'on doit lui injecter un Bean qui correspond à la fois à la classe nécessaire mais aussi du qualifier voulu.

Un autre sujet présenté par Rod Johnson est le nouveau module destiné aux tests unitaires et d'intégration.
Celui-ci permet de créer un jeu de tests basé sur des annotations spécifiques sans se lier à une technologie. C'est le module Spring qui aura la responsabilité de transformer ces jeux de tests selon le framework de tests utilisé : JUnit 3.8, JUnit 4 ou TestNG

Rod Johnson a ensuite cédé la parole à Keith Donald qui a présenté le framework Web lui aussi profitant des annotations. Il est désormais plus facile de créer un contrôleur Web :

@Controller
public monControlleur {
 
	private	LinkService linkService;
 
	@Autowired
	public void setLinkService(LinkService service){ 
		this.linkService = service;
	}
 
	@RequestMapping("/addLink.do")
    public String addLink(@RequestParam("linkText") String text, @RequestParam("linkUrl")URL url) {
		try {	
			Link link = new Link(text, url);
			linkService.addLink(link);
			return "success";
		} catch (ServiceException e) {
			return "error";
		}    
    }
}

Le contrôleur devient un simple POJOs pouvant complètement s'abstraire de l'API Servlet, ce qui facilite grandement les tests unitaires d'une telle classe.

Les Framework Spring JavaScript et Spring Faces ont ensuite été brièvement expliqués. Ce dernier étant le nouveau module de développement JSF/Spring.
Celui-ci n'utilisant plus JSF que pour la création des vues grâce aux composants JSF (JBoss Faces, Apache Tomahawk, Apache Trinidad, etc .. ) tandis que la gestion des URLs et de la navigation devient la responsabilité de Spring MVC (ou Spring WebFlow ).

Ce fut ensuite au tour de Christian Dupuis de prendre la parole afin de nous présenter Spring Tools Suite. Par le biais d'une démonstration sur la création d'un module pour SpringSource Application Platform, nous avons pu voir l'IDE en action.
L'intégration de S2AP mise à part, citons comme fonctionnalité intéressante la présence d'un outil d'analyse de stacktrace. En se basant sur une base de données, Spring Tools Suite va proposer quelques causes probables de l'erreur et leurs solutions.

Peter Cooper-Ellis, récemment intégré à SpringSource, et venant de BEA, nous à exprimé son point de vue sur SpringSource et Spring en général.

Orateur : Juergen Hoeller
Fonction : Co-fondateur du projet Spring Framework

Malgré son nom prometteur, Spring 3.0 n'a été que (trop) brièvement abordé. La majorité de la conférence fut une présentation des nouveautés et caractéristiques de la version 2.5.

Celle-ci reste par exemple compatible Java 1.4 tout en apportant le support de Java 5 et 6, ainsi que JEE 5 pour le cêté entreprise.

Notons par exemple le support des annotations JSR 250 :

public class MaClasse {
 
	@Resource
	private monService
	@PostConstruct
	public void uneMethode(){
		// équivalent à afterPropertiesSet() de l'interface InitializingBean
	}
 
	@PreDestroy
	public void uneAutresMethode(){
		// équivalent à destroy() de l'interface DisposableBean
	}
}

Ces annotations sont une standardisation récente de certaines fonctionnalités déjà présentes dans Spring depuis longtemps.
D'autres annotations sont disponibles : @EJB, @WebServiceRef, @TransactionAttribute (équivalent @Transactional des packages Spring ), @PersistenceContext/@PersistenceUnit (pour JPA )

En supplément de ces annotations standard, Spring 2.5 en possède quelques unes propres à son modèle :

@Autowired/@Qualifier : Pour la gestion de l'injection de dépendance.
@Controller/@RequestMapping : Pour Spring MVC
@ContextConfiguration, @TransactionConfiguration,@RunWith : pour le nouveau framework de test.

Spring 3.0 a été l'objet des 10 dernières minutes de la conférence. Nous apprenons ainsi que le cœur de Spring sera remanié en étant basé sur Java 5 (génériques, méthodes à arguments variables ).
De ce fait Java 1.4 ne sera plus supporté, et donc a fortiori les plus vieux serveurs d'application non plus.

Coté API Spring, la nouvelle version restera globalement compatible avec Spring 2.x. Cependant certaines veilles APIs seront supprimées tandis que d'autres seront marquées comme dépréciées.
La hiérarchie de contrôleur Web - remplacée par les annotations - serait sans doute dépréciée, le support de Toplink - remplacé par EclipseLink - serait supprimé ainsi que Commons Attributes (remplacé par les Annotations ).

Parmi les nouveaux supports citons : Portlet 2.0, Servlet 3.0, REST, Expression Langage, et support des "conversations" au niveau Web.

Au niveau de la roadmap, nouvelle mise à jour de Spring 2.5 (Spring 2.5.5/Spring 2.5.6 ) jusqu'en juillet. Et première Release Candidate de la version 3.0 normalement pour Aout.
La version Spring 3.0 GA devrait quand à elle être disponible pour le dernier trimestre.

Orateur : Jennifer Hickey
Fonction : Technical lead de SpringSource Application Management Suite (AMS)

La session concerne le monitoring et l'exploitation d'une application Spring. Une première partie explique les concepts, et insiste sur la notion de métriques agrégées - pour ne pas être noyé dans la masse et obtenir une vue synthétique fiable - et d'actions - pour pouvoir intervenir.

JMX

Suit une présentation de JMX et de la mise en oeuvre d'un MBean pour récupérer les performances d'un service. Rien de très nouveau.

Ensuite, Jennifer nous fait une démo utilisant la nouvelle annotation @ManagedResource pour faire la même chose avec trois fois moins de code et une ligne de XML. C'est nettement mieux. Un petit passage par l'AOP pour nous mettre l'eau à la bouche : tous les services sont monitorés en une ligne de XML et sans rien coder. Seul bémol à mes yeux, l'utilisation de JamonAPI - étant initiateur de commons-monitoring, je ne peux que m'insurger ;-)

Spring AMS

Enfin, on passe au gros du morceau : Spring Application Management Suite

Sur la base d'une version "instrumentée" de Spring, AMS introduit un agent qui va recueillir toutes les infos utiles de l'application, et bien sûr toutes celles que le code spécifique voudra bien exposer via JMX ou par AOP interposée. Bonus, AMS détecte automatiquement tous les Beans annotés @Component (donc @Repository, @Service...) et les instrumente via Spring-aop pour surveiller l'invocation de leurs méthodes.

On passe ensuite à l'interface web du "client" de monitoring. On est très loin du modeste jconsole. Onglets, graphes en tout genre, groupes de mesures, courbes d'évolution... Un point intéressant : sur une période de temps on a à la fois l'évolution d'un indicateur et la liste des actions d'exploitation qui ont été menées. Un bon moyen de voir ce qui a changé et pourquoi. AMS affiche dans la "timeline" tous les événements importants (action d'exploitation, alarmes...), tout ceci étant bien entendu totalement configurable. Cerise sur le gâteau, on peut programmer une action sur alarme, comme augmenter la taille d'un pool lorsqu'un pic de charge est détecté.

Bref, un très bel outil de supervision et de mise au point.

Orateur : Thomas Risberg
Fonction : Consultant indépendante spécialisé dans JEE et les bases de données

Qui n'a jamais eu de problème de performance ? Cette session s'attaque à cette problématique appliquée aux accès en base de données : outils, pratiques, solutions de repli...

Premier conseil : collaborer avec le DBA ! Les développeurs java comprennent mal les bases de données (ou croient comprendre, ce qui est pire), les DBA ne comprennent pas les développeurs Java. Il est indispensable de partager les infos de volumétrie, les besoins de performances, les stratégies de test ... de l'impliquer dans la mise au point des mapping utilisées par Hibernate et de la structure physique qui s'y prête le mieux.

Ensuite, quelques infos pour utiliser mieux l'API JDBC et les pools de connexion (dont le méconnu oracle.jdbc.pool.OracleDataSource), en particulier via les templates de Spring. Info intéressante : l'utilisation des indexes de colonnes à la place des noms améliore très peu les perfs et dégrade nettement la lisibilité - ne cherchez donc pas de ce côté pour expliquer des performances désastreuses.

Lorsqu'un outil de mapping Objet/Relationnel est à l'œuvre, tracer le SQL exécuté pour identifier les points noirs. Penser que cette option peut être activée par JMX ! La compréhension des mécanismes de mapping est indispensable, en particulier le fameux problème du chargement "n+1". Un tunning fin des requêtes et des caches est indispensable pour tirer le meilleur de ce type d'outil

Enfin, un rapide tour d'horizon des outils qui peuvent accompagner le développeur dans ce délicat travail, aussi bien sous forme externe (p6spy) qu'en exploitant les possibilités de la base de donnée, comme les commandes EXPLAIN ou ANALYSE.. et donc, mais on vous l'a déjà dis, collaborer avec le DBA !

Si cette session ne nous offre pas le mouton à cinq pattes qui résout tous les problèmes, elle a le mérite de rappeler des règles essentielles et d'insister sur le rôle du DBA, même (surtout ?) quand on fait du mapping O/R.

Orateur : Adrian Colyer
Fonction : CTO SpringSource et Leader du projet AspectJ

Cette conférence fut une bonne introduction à OSGi en montrant les avantages de celui-ci par rapport au traditionnel déploiement de WAR/EAR.

Dans OSGi, l'indépendance des couches est explicitement présente. Chacune d'entre elles sera déployée séparément comme un Bundle, et la dépendance de l'une vers l'autre sera réduite au minimum : une interface. De plus grâce à cette modularité, il n'est plus obligatoire de recharger l'application complète pour corriger un bug de la couche d'accès : seule le module concerné devra être mis à jour.

Une autre particularité de OSGi est qu'un bundle possède un nom mais aussi un numéro de version. L'intérêt est de pouvoir avoir dans la même application une référence à deux versions différentes d'un même Jars.
Un Bundle aura ainsi la possibilité de spécifier quelle version (ou encore un range de version ) il désire.

OSGI permet aussi le chargement/déchargement à chaud d'un bundle : dès qu'un bundle est déchargé, tout les autres bundles l'utilisant sont notifiés de ce changement, et peuvent réagir en conséquence : utiliser une alternative, attendre ou ne rien faire.

Ce n'est que quelques avantages de la technologie OSGi, je vous invite à vous renseigner sur divers blog ou attendre la vidéo sur Parleys pour suivre la conférence et voir par vous même !

Orateur : Costin Leau
Fonction : Leader du projet Spring Dynamic Modules

Après une introduction à OSGi, il était normal de voir en quoi Spring pouvait intervenir dans le développement de Bundle. Et encore une fois, Spring fait des merveilles !

Il est en effet assez impressionnant de voir qu'il est possible de développer une application OSGi sans (presque) connaitre cette technologie. A partir d'une interface d'un service, de son implémentation et d'un namespace XML, Spring permet le déploiement d'un service OSGi aussi simplement que ça :

<osgi:service id="monServiceOsgi" ref="implementationServiceOSGi"      interface="com.developpez.hikage.osgi.MonServiceInterface" />
 
<Bean id="implementationServiceOSGi" class="com.developpez.hikage.osgi.MonServiceImpl"/>

L'importation d'un service OSGi côté application cliente est aussi aisée, toujours grâce au namespace fourni.
Mieux encore, Spring DM gère l'aspect modulaire de OSGi correctement. Il gère la notion de dépendance optionnelle, obligatoire ou de liste de dépendances via une notion de multiplicité.
Un service de multiplicité [0..1] sera par exemple optionnel et au maximum 1. Une multiplicité de [0..N] désignera une liste de services du même type.
Et que se passe-t-il lors qu'une dépendance disparait ? Spring DM s'en occupe toujours de manière transparente en mettant en attente tout appel vers ce service. Et cet appel sera bloqué temporairement en attendant le retour du service. Ce mécanisme permet de mettre à jour un service de manière quasi transparente et à la volée.

De plus grâce au travail sur le classloader OSGi de l'équipe de Spring DM, l'utilisation des ressources situées dans le classpath peut être effectuée de manière traditionnelle avec Spring.

Un autre atout de Spring DM est qu'il apporte une solution pour le développement Web avec OSGi. De base OSGi ne permet que du développement base sur des Servlet 2.1 et est donc fort limitatif. Spring DM permet de travailler avec OSGi avec deux serveurs de servlet : Tomcat et Jetty.

(Gildas) Bref, cette session fut l'une des plus intéressante pour moi. Je ne connaissais que de nom Spring DM et je suis assez conquis par la simplicité qu'apporte celui ci pour OSGi.

(Nicolas) La session, entrecoupée de démos, a été très enrichissante, mais je reste toujours dubitatif. Certes, cette technologie, pour laquelle Spring DM masque de très nombreuses difficultés, peut apporter des choses, mais à quel prix !

Orateur : Alef Arendsen
Fonction: Principal Consultant SpringSource et co-auteur du livre Professional Development with the Spring Framework

Derrière son cêté obscur, la programmation orientée Aspect peut s'avérer très intéressant et puissante. Le plus difficile est de savoir pour quel problème elle sera réellement utile.
Ce fut un peu le but de cette conférence : montrer des cas pratiques d'AOP.

Pour le premier aspect, Alef a mis en avant un problème lors de l'utilisation conjointe de Hibernate et de JDBC. Dans la même transaction, lorsqu'un appel JDBC accède aux mêmes données qu'Hibernate, le résultat de la requête JDBC ne tiendra pas compte des modification d'Hibernate.
Le problème est que toute modification de données réalisée grâce Hibernate est réalisée temporairement dans la session et la synchronisation avec la base de donnée est réalisée lors du flush de la session, celle-ci n'étant flushée qu'à la fin de la transaction.

Solution 1 : effectuer le flush manuellement
Solution 2 : créer un aspect qui le fait pour nous.

Bien évidemment, la solution 2 est préférée ;-).

Le second aspect fut la mise en place d'un système de localisation des données grâce à Hibernate, une vue, une table de données et une table de métadonnées.
Le principe est le suivant :

1. la table contient des données, y compris une notion d'emplacement (Paris, Londres, .. )
2. la table de métadonnées contient deux informations : un identifiant de transaction, et un emplacement
3. la vue effectue une requête du type "select * from maTable where maTable.emplacement = metaData.emplacement AND metaData.transactionId = CURRENT TRANSACTION"

Reste maintenant à populer la table de métadonnées pour qu'à l'identifiant de transaction soit associé l'emplacement courant. Et encore une fois, c'est grâce à un Aspect que cela est possible.
=> "Pour chaque premier appel métier, ajouter une ligne dans la table de métadonnées".

Le troisième aspect présenté est plus qu'intéressant car il propose de connaitre l'erreur exacte qui est à l'origine d'une exception.
En effet, si dans le traitement, une exception est catchée et qu'elle n'est pas ajoutée à l'exception relancée, l'erreur initiale ne sera pas connue et une information sur la cause de l'erreur pourra être perdue.

On peut faire des choses étonnamment puissantes avec AspectJ une fois qu'on met le doigt dedans... du contrôle d'architecture en amont à l'assistance à l'identification des erreurs critiques.

Orateur : Mark Fisher
Fonction : Leader du projet Spring Integration

Spring Integration est l'un des derniers projets ajoutés au portfolio. N'ayant eu le temps de regarder que très furtivement celui-ci j'espérais en apprendre davantage durant cette conférence.

Durant la première partie, Mark Fisher a fait un léger rappel sur les différentes fonctionnalités en terme d'intégration déjà présente dans Spring : Déploiement de services Web (SOAP ou style HttpInvoker ), intégration grâce à JMS, scheduling grâce à Quartz, etc..

Il a ensuite présenté Spring Integration proprement dit. Celui-ci a pour but d'implémenter les Entreprises Integration Pattern décrit par Gregor Hohpe et Bobby Woolf.

L'un des points importants de Spring Integrations est qu'il se limite réellement à la gestion de l'intégration, toute la composante métier sera de simple POJOs (utilisé de manière conventionnelle avec Spring ). Spring Intégration apporte uniquement la couche qui va permettre de mettre en relation les différents composants.
La logique métier n'est donc plus du tout couplée à la manière dont elle est intégrée avec le reste, et peut donc se concentrer sur ses propres fonctionnalités. Cela falicite ainsi la modularité ainsi que le testing des composants métiers.

D'un point de vue technique, Spring Integration apporte son namespace XML ainsi qu'un certain nombre de composants.

L'objet utilisé pour la communication est un Message - qui comprend un payload, un entête et un identifiant - qui est envoyé sur un MessageChannel par un Producer.

Ce modèle ressemble à ce que propose JMS, et Spring Integration possède d'ailleurs un adapteur vers ce mode de communication.
Le rôle de l'adapteur est de faire la conversion entre le Message (formation Spring Integration ) et un moyen de communication. Spring Integration propose un adapteur JMS, Fichier, Stream et ApplicationEvent.

Après ce petit discours technique, Mark Fisher nous a montré comment cela fonctionne en pratique à travers un petit exemple.
Celui-ci consistait à simuler la demande d'une boisson dans un café, et de router correctement la demande selon le type de boisson (chaud ou froide ) :

Vous pouvez retrouver l'exemple décrit en détail dans la documentation de Spring Integration

Orateur : Jeremy Greller
Fonction : Leader de Spring Faces

La session présente le tout nouveau module Spring-JavaScript, qui vient enrichir la pile "web" de Spring.

Spring JS préfère à la mode Rich Internet Application (flex, GWT...) le progressive enhancement : partant d'une application web classique, Spring JS propose tout d'abord d'utiliser css framework pour obtenir une mise en page élégante, simplement en respectant des conventions de balisage de la page. Ensuite, Spring JS propose une API javascript simple (Spring.js) qui propose de "décorer" des éléments de la page avec des widgets, pour l'instant issues de Dojo (jQuery étant le prochain dans la liste).

Un formulaire HTML basique peut ainsi se parer de jolis calendriers, tooltips sur les champs de saisie, validation de la saisie...

Spring JS permet également de recharger des fragments de la page par Ajax interposé. La seule contrainte étant d'avoir côté serveur un "handler" qu'on puisse utiliser à la fois en mode HTML et Ajax, et une "vue" basée sur la composition de fragments - typiquement tiles avec Spring MVC.

Et tout cela fonctionne toujours si on désactive javascript, sur un téléphone mobile, un PDA, ou tout simplement pour rester accessible aux malvoyants ! C'est le principe du progressive enhancement ! Le gros avantage est que l'application, même en mode dégradée est totalement fonctionnelle.

L'objectif de Spring JS n'est donc pas de venir ratisser sur les plates bandes de GWT, mais bien de proposer une solution intermédiaire, permettant à des développeurs "classiques" webMVC de moderniser leur application, de la rendre sexy et fonctionnellement attrayante, sans avoir besoin de développer du code spécifique (comme c'est nécessaire par exemple si on utilise DWR). La simplicité de mise en œuvre est remarquable, et permet rapidement de donner un coup de neuf à une application web devenue trop classique.

La journée se termine dans une ambiance festive (désolé, je ne peux pas copier/coller la musique d'ambiance) arrosée de bière belge sur lit de frites mayonnaise. L'occasion de débrider les dernières réticences pour aborder les Messieurs en Jaune (la nouvelle chemise SpringSource) et leur poser tout un tas de questions plus ou moins pertinentes !

Voici par exemple une explication imagée du load-balancing par Mr Rod Johson en personne.

La soirée se termine pour certains en ville autour d'un dernier verre, à échanger ses expériences et ses attentes avant d'attaquer la deuxième journée.

Adrian Coyler ne nous refait pas cette année le coup du canard qui code sur un clavier water-proof (cf photo), présentation très personnelle du ducktyping qui avait eu un grand succès l'année dernière.

Assisté de Rob Harrop, Adrian dresse un tableau rapide des apports de Spring comme modèle de composants, et conclut par la question qui tue "is that it ?". L'invasion des POJOs résout elle définitivement tous nos problèmes ? Quelques problèmes subsistent :

• La modularité : malgré un découpage en Beans avec des interfaces, il n'existe pas de séparation "dure" entre les composants. Il n'y a pas non plus de modularité de haut niveau dans les contextes Spring, qui peuvent contenir des centaines de Beans de toutes natures
• La gestion de version est un problème général : comment gérer les centaines de librairies qui composent la plupart des applications java, avec des conflits potentiels de versions ?
• L'aspect dynamique : comment assurer une mise à niveau sans devoir déployer le WAR dans son ensemble ?
• L'exploitabilité : malgré un modèle en couches et de beaux composants, au niveau exploitation on ne voit plus que le .WAR en tant que boîte noire.

OSGi fait bien sûr partie de la réponse. Une démo rapide de S2AP nous le démontre avec le redéploiement quasi instantané d'un DAO sans interruption de l'application web.

Alors, "is that it ?". Toujours pas : il reste à gérer une notion allant au delà du concept OSGi de bundle, ce que S2AP appelle une "library", soit un groupement de bundles selon un axe logique. Il y a aussi des soucis pour héberger plusieurs applications, car si deux d'entre elles dépendent de Spring-orm, elles ne peuvent pas préciser Hibernate 3.1 pour l'une, et Hibernate 3.2 pour l'autre ... Il faut aussi gérer l'approvisionnement des bundles sur un environnement réparti (cluster, cloud-computing...). Encore du pain sur la planche !

Orateur : Arjen Poutsma
Fonction : Leader du projet Spring Web Services

Ayant déjà écrit un article sur le sujet, j'espérais en apprendre plus sur Spring WS durant cette présentation. Ce ne fût malheureusement pas le cas.

Arjen Poutsma a cependant très bien présenté Spring WS 1.5 ainsi que les nouveautés.

Spring WS 1.5 propose par exemple une nouvelle intégration avec JMS ainsi que Email, et ne se limite plus au service HTTP.
Le plus intéressant est que l'endpoint sera exactement le même, et que déployer un service HTTP, JMS ou Email ne diffèrera que par la configuration XML.

Une autre nouveauté intéressante est le support de WS-Adressing ou WS-Security côté client. Associé à Spring Security, Spring WS permet donc assez facilement de déployer des applications sécurisées.

Durant cette conférence, on apprend que les services REST ne seront pas gérés par Spring WS mais par Spring MVC.

Orateur :Andy Wilkinson
Fonction : Membre de l'équipe Spring Application Platform

Un tour d'horizon de la plateforme S2AP, à mi chemin d'OSGi et de JEE, et toujours dans le souci de simplicité de Spring.

Installation: download et unzip, c'est tout !

S2AP est basé sur Tomcat et lui ressemble beaucoup. Seul le répertoire "lib" a été nettement revisité, et se décompose en un lib de base (démarrage du socle de la plateforme), accompagné d'un référentiel de bundles OSGi. De nouveaux bundles sont déployés par simple glisser/déposer dans ce répertoire, la prise en compte se faisant à chaud.

La configuration se fait dans des fichiers au format JSON, plus concis que du XML. On peut par exemple désactiver le "module" tomcat pour n'exécuter que des batchs sur la plateforme, l'allégeant ainsi d'autant - ce que ne permet pas JEE !

L'exploitation peut bénéficier de JMX et d'une intéressante fonction de "dump", qui expose la configuration des bundles et comment ils sont liés, difficultés majeures de cette technologie. La recherche de bundles OSGi est largement facilité par une application web proposée par SpringSource (http://www.springsource.com/repository) qui met à disposition untrès grand nombre de librairies OpenSource communes, préparées et testées pour la plateforme.

Il s'agit finalement d'un bon aperçu de la plateforme, qui donne une idée de ce que sera peut être dans quelque années le développement JEE, et permet d'aborder sereinement les autres sessions.

Orateur : Sam Brannen
Fonction : Senior Software Engineer chez SpringSource

S2AP est censé améliorer la gestion de dépendances entres modules et permettre le développement d'applications Web. Mais comment ?
Cette présentation répond à cette question en expliquant ce qui est possible et comment passer d'un WAR traditionnel à un module Web.

Etape 1 : Le WAR Traditionnel
Le WAR traditionnel est une grosse archive qui comprends"tout" : les classes métiers, les APIs, les images et différentes ressources.
Bref, en général un bon gros fichier volumineux qu'il suffit de déployer en une fois.

Oui mais encore faut-il qu'il soit correctement créé. Il y a parfois des surprises quand un Framework utilise une version d'un JAR et qu'un autre utilise une version différente.
Si la nouvelle version est compatible avec l'ancienne, pas de soucis. Dans le cas contraire, bienvenue dans le Jar Hell.

De plus, si un des composants métier devait être modifié, c'est tout le WAR qui devra être redéployé.

Malgré les inconvénients du WAR monolithique, S2AP les gère directement. Il est donc tout à fait possible de déployer vos anciennes applications dans S2AP.

Etape 2 : Le WAR à bibliothèques partagées.
La première amélioration consiste à ne plus embarquer dans le WAR tout les jars nécessaires à l'application mais de déléguer la gestion de ceux-ci à OSGi/S2AP.
Pour cela, il faut retirer toutes les bibliothèques de WEB-INF/lib, et en contrepartie ajouter tout les import-package (ou import-library ) dans le fichier META-INF/manifest.mf :


Il est bien sûr nécessaire de placer une version OSGifiée des jars dans le répertoire adéquat de S2AP. Pour cela, le repository de SpringSource fournit une bonne base.

Dans cette version, il est donc possible de gérer les versions multiples d'une bibliothèque. Par contre, la partie "propre" à l'application sera toujours placée dans WEB-INF/classes et nécessitera toujours une recharge du WAR si une des classes est modifiée.

Etape 3 : WAR à services partagés
Une deuxième amélioration consiste à créer un WAR qui contiendra toujours tout ce qui se rapporte directement à l'application Web : Images, pages JSP, et autres composants de type servlet ou framework Web.
Mais toute autre couche sera déployée comme un Bundle : un bundle Service Interface, un Bundle Service Implementation, un Bundle DAO interface et un Bundle DAO implémentation.

Pour cela, d'autres modifications sont nécessaires, comme l'ajout d'un fichier de configuration spécifique à Spring DM qui va réaliser l'injection du service OSGi dans l'application Web.
De plus, une refonte du projet est nécessaire afin de créer un jar par Bundle.

L'intérêt de ce système est de pouvoir modifier à chaud une partie spécifique de l'application. Si un bug est découvert dans l'implémentation du DAO, seule cette partie devra être redéployée par exemple.

Etape 3 : Module Web
Le module Web fait complètement disparaitre la notion de WAR. La composante Web devient elle même un Bundle OSGi.

Je vous conseille un billet sur le blog de Sam Brannen pour un peu plus de détail sur ce sujet

Orateur : Keith Donald
Fonction : principal and founding partner at SpringSource

Avec la version 2.5 de Spring, la couche Web MVC devient "Spring @MVC". En effet, Spring applique le concept de "conventions over configuration" qui permet d'écrire du code nettement plus simple et lisible, en se basant sur des règles simples. Ainsi :

@Controller
public class HotelsController {
   public List<Hotel> search(Criteria c ) { ... }
}

.. permettra automatiquement (en deux lignes de XML) de mapper /hotels/search?name=xx sur la méthode search, et d'exposer la liste "hotelList" à la JSP /WEB-INF/hotels/search.jsp

Evidemment, une série d'annotations permet de déroger à ces règles, et on peut également obtenir en paramètre du contrôleur les objets de l'API Servlet (request, session...) ou propres à Spring.

J'avais jeté un oeil à Spring MVC il y a longtemps et lui préférait Struts2 pour ses plugins "Zero Config", toujours en cours de stabilisation (fusion avec ses concurrents). Je suis très tenté de changer d'avis, surtout avec l'ajout de Spring JS qui permet d'ajouter les widgets Dojo et le support Ajax à tout ceci.

Web Flow 2.0 exploite également le concept de "comportements par défaut intelligents", qui permet sur l'application "travel" qui sert d'exemple à web flow de passer de 163 à 33 lignes de configuration. OGNL est utilisé comme langage pour invoquer les actions et lier les données au contexte "flow", allégeant notablement la configuration. La notion d'héritage entre flows permet de mutualiser les définitions globales, et il est possible d'associer une exécution d'un flow à un persistentContext JPA pour résoudre en un coup de baguette magique tous les problèmes de lazyInitialisationException.

Enfin, Spring Faces permet de marier Spring et JSF de manière fluide et légère. Une autre session aborde JSF 2.0 et comment son évolution résout ses problèmes de surpoids. Les Beans JSF bénéficient de la gestion par Spring, et Facelets peut être utilisé comme librairie de rendu.

L'association de toutes ces nouveautés fait de la pile web Spring un candidat très alléchant pour remplacer le bon vieux Struts !

Spring 3.0 vise à intégrer :

• un support REST naturel : /hotels/{id} -> public Hotel show(Long id )
• le partage de la validation client/serveur via une définition au niveau du modèle (piste également explorée par Seam avec hibernate-validation)
• un namespace dédié "site web", permettant de simplifier tout ce qui est directement lié au web et d'y intégrer simplement des références à webflow.

Orateur : Rob Harrop
Fonction : Auteur de Pro Spring, leader de Spring Modules

Cette conférence présente de manière un peu plus détaillée S2AP et les travaux qui ont été effectués par SpringSource pour celui-ci.

S2AP est donc basé sur Eclipse Equinox sur lequel une surcouche a été apportée. Parmi les fonctionnalités de celle-ci, citons l'excellente gestion des erreurs dans la gestion des dépendances entre Bundle.
Les messages d'erreurs sont en effet très clairs (un module nécessaire à tel bundle qui n'est pas trouvé ) voire intelligent en vous proposant un nom proche, utile dans le cas d'une erreur de frappe.

Cette conférence présenta d'autres fonctionnalités techniques de S2AP : gestion des logs, notion de scope, etc.

Au niveau exploitation, en plus des logs, les traces internes sont toujours actives pour fournir le maximum d'info en cas de plantage sans avoir besoin de reproduire le problème. Le mécanisme de dump permet d'analyser la configuration, et une détection de deadLocks effectue automatiquement un dump, dans lequel on peut rapidement identifier les threads impliqués et les bundles associés. Très fort !

Une application S2AP est un groupement de bundles. La notion de "scope" permet de créer des frontières entre applications au-delà de ce que les bundles OSGi proposent. C'est utilisé par S2AP pour permettre le Load-Time-Weaving AspectJ ou JPA, ou éviter qu'une application utilise par erreur la DataSource déclarée par une autre (lesquelles sont deux bundles de même niveau au niveau d'OGSi).

Enfin, l'utilisation d'Hibernate & Co a été résolue en permettant à un import dans un bundle d'être "promu" au niveau application, et donc visible par tous les bundles de l'application. En fait, S2AP réécrit à la volée tous les fichiers MANIFEST et les contextes OSGi.

En résumé ... ça marche, sans que l'on ait à se soucier de comment, ce qui n'est pas peu dire vu la complexité introduite par OSGi (voir la session qui suit) - un sacré boulot !

Orateur : Frederik Santens

Dernière conférence de la journée pour ma part, et certainement la plus difficile à suivre :-).

Elle fut cependant très intéressante et commença par un rappel du classloading "normal" en Java, et en particulier le problème du chargement d'un même fichier .class par deux classloaders.

Le classloading de OSGi fût ensuite présenté et Frederik Santens nous expliqua le fonctionnement d'OSGi qui permet le rechargement à chaud d'un Bundle. Il mit aussi en avant tout le travail de l'équipe Spring-DM qui à fait un énorme boulot afin de permettre une utilisation classique des ressources.
En effet, avec un classloader normal, il est possible d'accéder aux ressources d'un jar par class.getClassloader.getRessource(). Mais dans le cas du classloading OSGI cette étape est nettement plus complexe du fait de la visibilité des packages.

Il expliqua ensuite les difficultés d'utiliser JPA et AspectJ avec OSGI à cause du Load Time Weaving qui pose soucis.

La fusion de l'AOP AspectJ avec OSGi est clairement l'écueil le plus lourd pour l'évolution du couple Spring / OSGi, et la solution est loin d'être triviale en raison des contradictions entre les deux outils. Une extension spécifique doit être développée pour le couple AspectJ / equinox (projets AOSGi et Ajeer) - not official yet : work in progess ! OSGi v4 inclut des mécanismes d'extension qui pourront offrir les hooks nécessaires.

Orateur : Eberhard Wolff
Fonction : co-auteur de "Server Component Patterns" and "Java Persisten Strategie"

Il reste bien moins de monde en fin de journée. Pour cause de retour avant la nuit, nombreux sont ceux qui ont renoncé à la dernière session...

Cette dernière session cherche à mettre en oeuvre plusieurs principes d'architecture avec Spring :

• décomposition en composants = interface publique, définition explicite des dépendances, réutilisable et composable.
• décomposition "verticale" en couches (chaque couche ne peut accéder qu'à la couche d'en dessous)
• décomposition "horizontale" par domaine fonctionnel

Option 1: un fichier XML par "bloc" (gros carré sur le schéma d'architecture de l'application).

Quelque soit l'option choisie pour construire le contexte Spring, on ne peut pas composer les fichiers XML pour répondre à la fois à la structuration horizontale et verticale : à chaque fois, la visibilité entre Beans est trop grande

Option 2: Spring JavaConfig propose de manière inattendue de répondre à ce besoin, via la définition de "Beans" protected (visibles uniquement dans le contexte local) et de Beans abstract (dépendances).

Option 3 : OSGI ... on s'en serait un peu douté

Option 4 : Utiliser AspectJ pour valider l'architecture. Exemple :

@DeclareError("SystemArchitecture.inDaoLayer() && SystemArchitecture.callBusinessService" ) 
youCantCallBusinessServiceFromDao()

J'ai personnellement déjà essayé cette dernière option, et je la trouve à la fois très puissante et très pratique, car elle est très évolutive