Pour ceux qui n'en aurait pas entendu parler, OSGi est (pour faire court) une architecture Java qui héberge à des applications décomposées en "bundles". Chaque bundle expose une interface "publique", la seule accessible aux autres bundles - d'où une sparation très propre. OSGi permet un redéploiement à chaud des bundles, des versions concurrentes, des mises à niveau "à chaud" ... bref plein de fonctionnalités alléchantes.
De son côté, JEE n'offre absolument rien de comparable (en standard : Weblogic permet par exemple une mise à niveau N+1 sans interrruption de service). Java en général n'offre pas de séparation "stricte" entre modules, bien que quelques JSR tentent de ratrapper le retard.
SpringSource - décidément très actif ce printemps - lance "SpringSource Application Platform". Pour faire très schématique, vous prener un conteneur OSGi (celui qui est au coeur d'Eclipse et de ses plugins), vous ajouter Spring-Dynamic-Modules (aka "Spring-osgi"), puis vous placez au dessus un Tomcat retravaillé pour l'occasion et vous déployez vos application web dessus.
Dans un premier temps ça ne change pas grand chose.
Maintenant vous remplacez votre WEB-INF/lib par des déclarations de bundles OSGi. Le war ne fait plus que quelques ko et toutes les librairies sont mutualisées. Une mise à niveau d'une seule librairie se fait sans interruption du service.
Bonus complémentaire, OSGi vous assure que vous n'utilisez pas "par mégarde" des classes interne d'une librairie, qui risque de changer ou disparaître dans une version N+1.
Et on peut aller plus loin en utilisant un packaging dédié ".par" pour construire l'application en bundles OSGi, tout en bénéficiant d'un des meilleurs moteur de servlet et de l'API servlet/JSP complète.
Personne ne sera surpris de voir les prochaines versions de Websphere, Weblogic, Jboss et autres proposer des passerelles vers les fonctionnalités OSGi.
Faut il passer sous SpringSource Application Platform ?
Dans ma vie à moi, je n'ai pas mon mot a dire et je me coltine toujours un Websphere 5.0.2. Le sujet n'est pas là. L'intérêt est que SpringSource propose une solution JEE + OSGi qui donne un apperçu de ce que seront les serveurs d'application dans quelques années.
Spring-DM de son côté propose un modèle de développement typiquement Spring (100% POJO) qui permet de passer à OSGi sans douleur - ce qui n'est pas gagné a priori vu les restrictions que cela implique sur la manipulation du ClassPath.
Autrement dit, jettez un oeil à la doc Spring-DM, apprenez les ficelles d'OSGi, comme ça dans quelques années, quand il faudra migrer dynosaure-2.1 sous Websphere-12-Adanced-OSGi, vous aurez déjà préparé le terrain.
Et pour ceux qui peuvent se le permettre, surfez sur la vague OSGi !
3 commentaires:
Bien sûr qu'il y a du monde qui lit ton blog! Même s'il n'y a pas beaucoup qui poste des commentaires.
Bon, mais la question c'est "faut-il passer sous SpringSource Application Plateform?"
Déjà un premier constat sur les constantes de temps des spec des serveurs d'application : J2EE 1.2 en 1999, 1.3 en 2001, 1.4 en 2003 et Java EE 5 en 2006.
Ca c'est pour les specs. Et les implémentations? 2 ans après (oui, DEUX ans) les serveurs d'application Java EE 5, en exploitation ne courent pas les rues. Et pour cause! les éditeurs ne se pressent pas.
Bref, entre le moment ou une spec est finalisée (et je ne parle pas du drat) et le moment ou c'est utilisé, il se passe quelques 3 à 4 ans.
Pendant un tel laps de temps (2005 à 2008), on a vu presque toutes les applications d'entreprise opter pour le modèle de programmation en POJO et utiliser Spring. Par ailleurs, toutes les architectures se modularisent, en OSGi.
Autant dire que le passage à SpringSource AP sera sans doute plus naturel qu'un "retour" à un usage réel d'un serveur d'application Java EE 5...
Les EJB3 n'arrivent-ils pas avec quelques 4 ans de retard? C'est la partie visible de la perte de vitesse des serveurs JEE.
Mais c'est pas la première fois qu'un standard de fait occupe le terrain avec qu'un standard ait le temps d'être voté et adopté...
Pour ma part c'est bien pire : en raison de l'hébergement mutualisé, mon client (un opérateur mobile .. je te laisse deviner) utilise encore de "vieux" Websphere 5.0, soit java et J2ee 1.3. Autant te dire que lorsque j'ai posé la question lors de SpringOne 07 "Pourquoi abandonner le support java 1.3 ?" et qu'on m'a répondu "Java 1.3 a terminé la phase End-Of-Life chez Sun", ça me fait bien rigoler !
Quand à SSAS, le problème est le même que de migrer vers JEE5 ou 6 : il faut migrer le serveur !
Pour ma part je prêche sur l'utilisation minimale des API J2ee qui ne peuvent pas être "embarquées" dans un WAR ton bête, comme ça tomcat ou websphère, c'est le même topo.
A bientôt
Ce qui est bien dans tout ça c'est qu'on arrive à avoir des outils très performant open source avec des communautés ouvertes sur le partage.
Enregistrer un commentaire