Version imprimable
J'ai du mal à comprendre les réels atouts de SpringSource Application Server...
J'y vois bien :Mais concrètement est-ce la révolution ?
- la maj à chaud de l'appli, pour avoir un service 24/24h
- le découpage en bundle, pour les architectures N-tiers
Faut-il laisser tomber Tomcat pour S2AP ?
S2AP est-il réservé à certains cas d'utilisation ?
Vos avis m'intéressent car j'ai l'impression de louper quelque chose....
S2AP est basé sur Tomcat, Equinox, et Spring Dynamic Modules.
En fait l'OSGi propose de totalement repenser les serveurs d'applications.
Prenons un cas concret.
Dans un serveur J2EE classique tu vas avoir un EAR, avec à l'intérieur une couche web (war) et une couche de service (des jar, un contexte spring).
Si tu veux réutiliser la couche service avec autre chose, par exemple ajouter un point d'entrée WebService, soit :
- Tu integres la couche WebService dans ton EAR existant.
- Tu fork ton service et donc tu crées un autre EAR. Dans ce cas tu auras 2 appli, 2 instances de ta couche service.
Avec l'OSGi, il n'y a plus de d'isolation comme avec les EAR, c'est comme si dans le serveur tout pouvait communiquer. C'est la notion d'application orientée service (SOA), mais au sein même du serveur.
Et dans ce cas tu pourras faire :
déployer 1 fois ta couche service dans le serveur.
déployer ta couche web.
déployer ta couche web service.
Voilà juste parce que je trouve ce schéma très explicite :
http://static.springframework.org/os...osgi-model.png
Un autre interet est que S2AP est capable de gérer differente version d'un meme service.
Et le best du best c'est un chainage utilisant des versions differentes :
http://static.springsource.com/proje...versioning.png
Il gère également les dépendances de service. Il est meme possible de rendre des services optionnels.
Il gère en interne un repository à la maven, donc tous les JAR sont centralisées, fini les duplications, fini le web-inf/lib, etc...
Bon je n'ai pas été très très clair, mais pour mieu comprendre je t'invite à parcourir cette doc :
http://static.springsource.com/proje...tml/index.html
Excellente réponse de Bugsan!
Je ne vais pas trop en rajouter car je suis partisan dans ce débat, mais si vous voulez plus d'informations sur S2AP, je vous conseille :
- Nos Webinars (il y en a un le 16 juillet qui s'annonce prometteur) : http://www.springsource.com/webinars
- En Français, la présentation que j'ai faite au Paris Java User Group, dont le support est téléchargeable ici : http://www.parisjug.org/xwiki/bin/view/Meeting/20080610
Salut,
Pour ajouter mon avis ladessus, je ne crois pas que l'interêt de S2AP est dans les architectures N-tiers, i.e. découpage vertical (Couche DAO, Couche Service, Couche Contrôle, etc.) car on a déjà cette notion qui est bien ancrée dans le monde JEE.
L'interêt de S2AP (ou plutôt de l'OSGi) est le découpage Horizontal + l'infrastructure.
Le découpage horizontal est intéresant car ça te permet de modulariser à l'extrême chacune des couches de l'application, avec tout ce que ceci implique:
- Simplification de la maintenance.
- Isolation : ce qu'un bundle (jar) exporte et ce qu'il importe est explicitement précisé, ce qui permet de minimiser l'utilisation de classes internes et non destinées à être utilisées de l'extérieur.
- Ca permet de travailler à plusieurs sur un projet : avec un découpage assez fin, tu as rarement deux personnes travaillant sur le mêmeprojet (au sens d'Eclipse).
Pour ce qui de l'infrastructure, je veux dire que tu peux simuler le découpage horizontal sans l'OSGi, mais ce serait vraiment une perte de temps car OSGi offre déjà une fondation solide et bien pensée pour ce cas d'utilisation.
Pour ce qui est de spécifique à S2AP, je dirais que le point le plus important est le modèle proposé par Spring DM : les mots sont parfois insuffisants, donc je t'invite à voir comment on publie correctement un service et comment on l'importe avec l'API "nu" d'OSGi : sans vouloir déprecier cette techno, mais c'est effrayant AMHA.
Or, via Spring DM, tu fais celà d'une manière complètement déclarative en ddeux lignes d'XML, avec en bonus la thread-safety, une gestion de timeout, une intégration parfaite avec l'applicationContext de Spring, etc.
En ce qui me concerne, j'etais sur le point de laisser tomber l'OSGi avant de tomber sur Spring DM (ok, j'en fais trop là, donc j'arrête :mrgreen: )
Bref, S2AP utilise Spring DM comme noyeau, tout en l'étendant vers le Web (ce que Spring DM 1.1 va apporter, mais S2AP y va différamment).
De plus, S2AP apporte tout un modèle etoffé pour le développement : gestion fine des logs (servicability), des bundles, de la configuration, etc.
Toutefois, et oui, y'a toujours un hic, il y'a un problème de taille dans la version 1 de S2AP qui à priori (et je l'espère) va être résolu dans la version 2 : la gestion de l'ordre du chargement des bundles selon les dépendances (ce que fait eclipse par exemple) est confinée à l'intérieur d'un PAR.
J'ai une idée vague sur ce qui a poussé l'équipe de S2AP d'agir de la sorte (dans un but d'isolation de la portée de modifications initiés par un bundle, comme pour le weaving par exemple), mais ça limite sérieusement la puissance de la plateforme.
Par exemple, dans Eclipse, si je développe un ensemble de plugins qui ajoutent une fonctionnalité donnée, je peux par la suite l'étoffer par simple ajout d'un jar (autre plugin).
Or avec la limitation actuelle de S2AP 1, on peut pas agir de la sorte, car il faut repackager tout le par et le redeployer en entier :?
Voilou.