juin
2008
Un article de Hikage
Voici un résume des conférences de la deuxième journée à SpringOne.
Using Spring Web Services
Durant cette session, Arjen Poutsma a tout d’abord commencé par expliquer les concepts sur lesquels est créé Spring WS.
Il a expliqué l’avantage de la méthode contract-First par rapport à la méthode Java First. Il a ensuite expliqué le coté technique du Framework : les différents moyens d’implémenter des endpoints, les intercepteurs, l’API cliente, etc.
Il a ensuite présenté les nouveautés de la version 1.5 par un petit exemple de service web sur JMS, et l’avantage de Spring WS pour cela. En effet, il n’y a aucune modification à réaliser au niveau du code de l’endpoint, la différence entre un endpoint HTTP et JMS se faisant uniquement par la configuration Spring.
Building Web Applications with the Springsource Application Platform
Cette session explique la migration d’une archive WAR JEE normale ( qui est déployable directement dans l’application Platform ), vers un module Web spécifique.
Etape 1 : un WAR simple, avec sa faiblesse : toutes les bibliothèques JAR sont incluses dans WEB-INF/lib, ce qui entraine une empreinte mémoire importante et surtout un risque de jar-hell ( utilisation de la même API par plusieurs modules différents, mais dans des versions différentes et incompatibles entre elles )
Etape 2 : Un WAR Shared Library. En fait c’est un WAR tout à fait normal en soit dans lequel ont été retirées les bibliothèques de WEB-INF/lib. La dépendance se faisant via le manifest grâce aux en-têtes OSGi. Résultat : le WAR est nettement plus petit, mais toujours une seule version de JAR à la fois.
Etape 3 : Un War Shared Service. Le niveau de complextié augmente, il n’y a plus une seule archive à deployée, mais plusieurs. Le WAR en lui même ne contient plus les JARs dans WEB-INF/lib mais en plus la configuration Spring change dans le sens ou les services « métiers » ( tout ce qui n’est pas pure WEB ) sont récupérés via OSGi, ce qui nécessite une configuration spécifique basée sur Spring DM. A coté du WAR plusieurs autres Bundle OSGi : Un Bundle pour les classes du domaine, un Bundle pour l’API de la couche Service, un Bundle pour l’implémentation du service. Et lors du déploiement, il faudra bien faire attention à déployer tout cela dans le bon ordre.
Etape 4 : un Module Web. Plus de WARs, mais un Bundle OSGi spécifique pour le Web, avec configuration via le manifest.
Inside SpringSource Application Platform
Le but de cette conférence était de présenter différents aspects de S2AP tels que la modularité, le load time Weaving, les profils ou encore la configuration.
Par exemple, ils ont expliqué leur choix de JSON pour les fichiers de configuration. Pas de fichier properties car ils ne sont pas bien adaptés à la configuration avec des éléments hierarchiques. Le format XML a été exclu quand à lui car la structure de la configuration S2AP n’est pas fixe, et peut évoluer. Dans le cas de XML, un namespace par « type » de configuration aurait été nécessaire. De son coté JSON est beaucoup plus flexible.
La notion de dump a été présentée, qui permet d’avoir l’état dans lequel se trouve un bundle ( thread, etc ) à un moment donné. Ce qui permet de détecter et reproduire des cas d’erreurs, et ainsi trouver plus facilement la cause du problème tels que des dead lock.
Classloading in OSGi
Session intéressante mais comme souvent avec le classloading, difficile à assimiler rapidement 
En gros, cette conférence présentait le modèle de classloading qui a été développé afin de permettre le résolution de problème tels que le versioning de Jars, l’arrivée/suppression d’un Bundle dynamiquement etc.
Les problèmes de Load Time Weaving ont aussi été présentés.
Commentaires récents
- dans SpringSource acquiert Hyperic
- dans Sortie de la huitième béta de SpringSource Application Platform (S2AP)
- dans Sortie de la huitième béta de SpringSource Application Platform (S2AP)
- dans Sortie de la huitième béta de SpringSource Application Platform (S2AP)
- dans Spring One 2008 en direct – Jour 1