Le match entre Spring et Seam ne fait que commencer. L’un a séduit une bonne partie de la communauté des développeurs, l’autre essaye de séduire par son intégration avec EJB et JSF et la définition d’une spécification par Gavin King.
Dans ce billet, je vous propose ce lien vers une présentation ppt qui compare point par point les différences et les points communs entre les deux frameworks.
Je suis un grand fan de Spring pour l’avoir utilisé sur plusieurs projets dans de grandes entreprises. Actuellement, je travaille dans un environnement EJB3/JPA/JSF et je suis en train d’étudier le framework Seam à titre d’expérience personnelle. Et je dois dire que je suis loin d’être convaincu, j’attends d’avoir des exemples plus concrets et de voir un peu l’impact de la spécification Web Beans de JCP. Peut-être à ce moment-là je serais un peu plus convaincu.
Je pense que le JCP fait du très bon boulot, actuellement j’en fais partie, mais qu’avec EJB 1.x et EJB 2.x, beaucoup de développeurs ont une impression négative sur les JSR. Il est vrai que lorsque l’on voit le travail effectué par Spring et Hibernate, aussitôt EJB 3.x et JPA inspirés par ces derniers, c’est un sacré retour en arrière.
A mon avis, la guerre entre Spring et Seam ne fait que commencer. Spring a un très bonne réputation mais Seam semble plus matcher avec les décisions business des grandes entreprises. Deux cibles différentes alors ?
Je n’ai pas encore essayer Seam, donc je ne tenterai pas ici de le descendre.
Mais de ce que j’en sais, Seam reste un framework Web, qui à l’air très intéressant, mais qui reste limité dans le domaine Web.
Spring est nettement plus large, Web ( Spring MVC, Spring WebFlow ), WebService ( Spring WS, Intégration Axis/XFire/JAX-WS ), Intégration ORM ( Hibernate, iBatis, JPA ), ESB ( Spring Integration ), … je ne vais pas tenter ici de lister tout
S’il faut comparer deux choses c’est Spring WebFlow et Seam, qui ont plus au moins le même but je pense.
Hum juste pour être sûr, tu parles de Seam 1 ou 2 ?
J’ai un ami qui est dans une mission Seam, la mission a débuté il y a un peu plus d’un an et demi et le framework (en version 1) était loin d’être éprouvé. A l’époque, il avait beaucoup de mal à trouver de la doc ou des réponses à leurs problèmes.
Par contre, je ne sais pas quelles sont les nouveautés de Seam 2.
@Hikage
J’attends comme je l’ai dit la version finale de la spécification Web Beans afin de réellement connaître toutes les possibilités du futur Seam.
@Julien
Je parles de Seam en général, mais je dirais que maintenant le niveau de documentation est satisfaisant maintenant.
Bonjour Alexis,
J’ai eu l’occasion d’étudier les deux frameworks. Voilà les informations que je peux partager avec toi. Il y a tellement de choses à dire que je pense que je ne serais pas exhautif. De plus il y a des choses subtiles à expliquer avec Seam, ce n’est pas évident de le présenter dans un réponse comme celle ci.
Comme dit précédemment Spring apporte beaucoup de bonnnes choses. Spring a fait ces preuves en production. Spring est bien connu de la communauté : il existe de nombreux exemples, livres, expertises, projets qui utilisent Spring.
Seam intégre des technologies Java EE 5, comme JSF, EJB 3, JPA. Il fournit également un ensemble d’API et d’annotations afin de faciliter le développement avec ces technologies. L’objectif de Seam est de prendre le meilleur de chaque technologie pour le développement d’application, sans que le développeur ai de la couture¹ à faire, c’est à dire du développement purement technique pour intégrer les différentes couches de l’application.
Seam est un framework qui pose les bases de la spécification Web Beans, JSR 299. Cette spécification a pour objectif d’unifier le modèle de composant JSF (Managed Bean) et le modèle de composant EJB pour obtenir un modèle de programmation plus simple et plus complet pour le développement d’application Web.
Comme Spring à son époque, Seam essaye d’apporter de nouvelles choses conceptuelles et techniques:
- Conversation (gérer une transaction métier sur plusieurs écrans),
- Ne plus faire du code technique (intégration de la couche JSF au service, etc),
- Ne plus utiliser des patterns techniques comme MVC, mais cela n’est q’une préconisation. De manière générale, Seam essaye d’apporter d’autres solutions pour l’intégration de la couche Web avec les services.
- Gestion des workflows métiers
- Gestion de la navigation entre les pages Web
Comme Hibernate, la documentation de Seam n’est pas toujours explicite et claire. Il faut faire un effort intellectuel assez important pour comprendre la manière la plus simple d’utiliser Seam. Cependant plusieurs livres sont sortis.
Pour moi, la force de Seam réside dans :
- L’uniformisation des annotations (validation Web et données avec les mêmes annotations)
- Le langage EL étendu (ca c’est vraiment pas mal)
- Il intégre le mieux des standards (par exemple le managed-bean de JSF disparait dans Seam)
- L’intégration de JSF avec les services métiers
- Il apporte des nouvelles solutions de design (surtout pour l’intégration couche Web avec les services, intégration des Workflows)
Tout n’est pas parfait, comme par exemple, on peut se demander l’utiliter de la bijection @in, @out. Sur ce point il y a des choses à améliorer (on aurait préférer une annotation sur un paramètre de méthode plutôt que sur un attribut de classe car ca dénature le design)
Les principales différences avec Spring sont :
- Seam préfére la configuration par annotation plutôt que par Xml (ce n’est pas entièrement vrai, il a de nombreux fichiers de configuration Xml pour initialiser le framework Seam, Spring annotation continue sa progression)
- Seam est un prémice au standard Web Beans (JSR 299) (avec Guice) – Java EE 6
- Seam s’appuie essentiellement sur des standards Sun, dans certains contextes c’est un avantage certain.
- Le modèle de composants Seam facilite les composants à état (stateful vs stateless) ce qui n’est pas toujours évident en Spring, même avec l’introduction de la notion de scope en Spring 2.0
- Seam d’un point de vue architectural est moins souple que Spring, c’est à la fois un avantage est un défaut. Un avantage il y a moins de problème à résoudre en début de projet. Un défaut car les choix de Seam peut être impactant par la suite. Par exemple par défaut Seam utilise du JSF ce n’est pas forcement le domaine ou une équipe de développement qui a toujours fait du struts sera la plus sereinne. Seam propose d’autres intégrations par exemple dans la version 2.1 de Seam il y aura un support Wicket. Cependant et à mon avis l’intégration ne sera jamais aussi bonne que l’intégration JSF.
A mon avis, si tu pars sur une base technologique JPA/EJB3/JSF, Seam a une vrai valeur ajoutée et te premettra de gagner en productivité sur des tâches quotidiennes (l’exemple du managed bean JSF est toujours valable). Il te permettra aussi d’avoir un design plus proche des bonnes pratiques (cf MailingList du Domain Driven Design). Attention, le framework Seam, couvre des problèmatiques vastes, complexes par moment et pas encore stable (intégration des workflows, etc), mais ca reste très intéressant.
¹ seam signifie en français couture