Architecture de JBoss Seam [Débat]

[ericw78]

J'ai entendu dire beaucoup de bien de Seam et à la lecture du tutorial Seam, je commence effectivement à trouver ce framework pas mal du tout.

Toutefois, l'architecture Seam me surprend
Dans le monde j2ee, on est quand même habitué à une séparation des couches (ihm <-> service <-> dao et notament à présence de la couche service que je trouve indispensable.
Or dans les exemples du tutoriel, je ne retrouve pas la couche service

Je n'en suis qu'au début de mon apprentissage de Seam mais la déjà je bloque sur le principe...

[djo.mos]

Bonjour et pour avoir évoqué ce point de détail là!
Tu as osé dire tout haut ce que je pensais dans mon for intérieur ...

Bref, moi aussi je me trouve dans la même situation. Je suis en train de me battre avec Spring 2.5 pour faire fonctionner Tomcat / Toplink / JPA / JSF dans une même application et je n'y arrive toujours pas.
J'avais entendu parler de Seam et de comment il simplifiait tout ça, mais ce qui me bloquait était justement la non-séparation des taches qu'il prone (IMHO).

Un ténor de Seam peut-il éclairer nos lanternes ?

[omaro1978]

je viens de commencer à lire la documentation de référence de seam, que je trouve bien jusqu'à présent, pour le petit blem que vous avez remonté, à mon avis , on peut toujours utiliser une couche itérmédiaire pour les service, en utilisant des sessionbean ou autre, que tu invoque depuis l'action.

[ericw78]

oui certainement qu'on peut rajouter la couche service mais ce que je trouve malheureux c'est que ce ne soit pas par défaut dans les exemples
De plus, le module Seam Gen que je trouve d'ailleurs assez impressionnant, n'inclut pas non plus de couche service. Ce qui gache un peu quand même

[anicaise]

Seam s'appuie en effet sur une architecture 2 tiers. Exit donc la couche services !

J'utilise depuis quelques jours maintenant Seam 2.0.0GA mais l'architecture me pose quelques problèmes. En effet Seam gen me génére un nouveau projet vierge avec deux répertoires sources Actions et Models. Mes beans Entites sont donc stockés dans le répertoire/package Models et mes actions, bean managés dans le répertoire Actions.

Cependant j'ai des classes utilitaires comme le cryptage d'un mot de passe mais je ne sais pas ou les mettre !! Il ne s'agit pas ici d'un bean ni d'un bean entité ....

Quelqu'un peut donc m'aider sur ce point ??

[manblaizo]

Envoyé par anicaise

Seam s'appuie en effet sur une architecture 2 tiers. Exit donc la couche services !

Je n'ai pas encore fait de réelle plongée dans Seam, mais les quelques lectures que j'ai faites sur le sujet me permettraient plutôt de douter d'une telle affirmation. Seam est un web framework qui s'appuie sur les technologies JSF et EJB 3.0, et la couche EJB 3.0 constitue donc la couche service permettant de bénéficier de la gestion transparente des transactions, de la persistence JPA, de la sécurité, etc., comme dans une application classique multi-couches intégrant des ejb. L'objectif de Seam est surtout de faciliter l'intégration de ces couches, et en cela il se présente comme un concurrent direct au framework Spring.
http://www.theserverside.com/tt/arti...sSeamFramework

En tout cas, moi je ne vois pas ce qui dans l'architecture de Seam ferait penser qu'il n'y aurait pas de couche service, a priori, puisque les ejb constituent la couche métier, et dans tous les exemples Seam on parle des session beans. Donc je pense que ça dépend plutôt de l'architecture de sa propre application.

[KiLVaiDeN]

Salut tout le monde,

Je m'immisce dans la conversation pour donner mon avis sur le sujet.

Je suis vraiment beaucoup plus plongé dans le monde de Spring, et je ne connais Seam que superficiellement. Je viens de lire les deux liens fournis dans ce fil de discussion en diagonale ( suite à un renvoi que djo.mos sur un autre thread ) et j'ai quelques remarques.

Une chose qui me gène énormément : la configuration via des annotations. J'aime beaucoup avoir ma configuration dans des fichiers XML, et avoir des pojos simple pour mes différentes couches, ce que le "design" de Spring prône. Pourquoi vouloir à tout prix avoir des classes Java qui gère deux choses différentes ( configuration et logique ) ?

Ensuite, peut-être que mon parcours des liens donnés était trop rapide, mais je confirme que je n'ai vu aucune mention à une quelconque "couche métier". Les objets dits "métiers" semblent être un mélange de DAO et de Service classiques. La séparation des couches est essentielle pour permettre une évolution facile vers d'autres framework de persistence sans perdre la logique métier. Hors là, je vois mal comment on pourrait le faire...

Donc, pour résumé, voici ce que je pense de ma première vision rapide de Seam :

Avantages :
rapidité de développement. Quand on voit la taille des codes sources donnés en exemple et les fonctionnalités qu'ils implémentent, on ne peut qu'admettre que ça a l'air plutôt facile à appréhender.
configuration via les annotations : je mettrais ce point aussi dans les inconvénients, mais il est vrai que certaines personnes peuvent aussi apprécier d'avoir à la fois la configuration et la logique dans un même listing. De plus ça peut aider pour le refactoring.
intégration avec les standards J2EE : Seam parait forcer l'utilisation des standards, ce qui dans l'ensemble est une bonne chose pour le futur, et pour la portabilité. jpa
outils de developpement : les outils mis en place paraissent simples et efficaces dans la génération de code.

Inconvénients :
où est passée la couche service ? peut-être qu'il faudra attendre un peu pour qu'avec le retour sur l'experience on voit de nouveaux patterns afin de bien gérer ce type de projet avec une meilleure séparation des couches.
la configuration via les annotations : je cite ceci dans les inconvénients aussi, car j'adore le coté "mon Pojo fait une chose, mes fichiers de configurations le configure". Ca permet d'avoir un code beaucoup plus simple à lire et à maintenir..
serveur J2EE obligatoire : avec Spring, on peut faire une application qui ne necessite pas forcément un serveur J2EE complet pour tourner, et bien fonctionner.

Donc dans l'ensemble, je dirais qu'il y a encore de la marge pour que je me fasse un avis sur la chose plus complet, lorsque j'aurais le temps de le tester et de voir ce que ça donne, mais pour l'instant, je n'ai pas trop l'intention d'abandonner mon bon vieux Spring

A+

[manblaizo]

Moi aussi j'utilise beaucoup Spring dans mes applications, et je dois dire que la première fois que j'ai lu quelques lignes sur JBoss Seam, la première chose qui m'est venue à l'esprit c'est de me dire : "tiens, il s'avance sur le terrain de Spring, ce Seam !!", ce qui m'a amené entre autres à lire ce débat ici : http://www.weiqigao.com/blog/2005/10...titor_now.html

Mais pour tenter de répondre un peu aux critiques formulées par KiLVaiDeN, concernant les annotations, je crois que c'est une vaste question qui ne concerne pas que Seam, et on ne peut y échapper, même Spring s'y met aussi.
Je ne configure plus ma gestion de transactions dans Spring qu'avec @Transactional, et c'est vraiment très pratique, plutôt que d'avoir à tout écrire dans le fichier XML. Plus l'application est de grande taille et plus les fichiers xml deviennent compliqués à gérer et peuvent ralentir le développement.
Les annotations sont un grand bond en avant pour le développeur, mais en même temps elles réduisent la flexibilité apportée par une configuration xml qui permet de modifier le comportement d'un composant au déploiement. Mais heureusement que dans Java EE 5 rien n'empêche d'avoir les deux, la config xml "surpassant" celle de l'annotation.

D'autre part, Seam ne nécessite pas un serveur d'applications, l'installation est possible sur Tomcat, mais n'ayant rien testé encore, je ne sais pas si c'est plus compliqué que pour Spring.

Enfin, pour ce qui est de la couche service, je n'arrive pas à voir où est le problème. Si je devais faire une application Spring intégrant des EJB, j'aurais exactement la même architecture que si je devais utiliser Seam à la place de Spring, et ma couche EJB constituerait bien la couche service. C'est moi qui décide de l'architecture de mon application, et ensuite j'utilise un framework qui me permet d'intégrer plus facilement les différentes couches avec toutes les fonctionnalités qu'elles offrent. Et d'après ce que j'ai compris jusque-là, Seam me permet de le faire autant que Spring.

La seule chose que je reproche à Seam, c'est cette fixation pour l'instant sur JSF comme framework de présentation, alors que moi je préférerais rester à Struts2, par exemple, mais je crois que ça devrait intégrer d'autres framework également à l'avenir, si ce n'est pas déjà fait.

[ericw78]

Enfin, pour ce qui est de la couche service, je n'arrive pas à voir où est le problème.

Le problème c'est que si tu veux utiliser Seam Gen pour générer rapidement du code et gagner un peu de temps, tu n'as pas de couche service....

Si je devais faire une application Spring intégrant des EJB, j'aurais exactement la même architecture que si je devais utiliser Seam à la place de Spring, et ma couche EJB constituerait bien la couche service. C'est moi qui décide de l'architecture de mon application, et ensuite j'utilise un framework qui me permette d'intégrer plus facilement les différentes couches avec toutes les fonctionnalités qu'elles offrent. Et d'après ce que j'ai compris jusque-là, Seam me permet de le faire autant que Spring.

Oui je suis entièrement d'accord avec toi à condition de tout coder à la main (ou te recoder ce qu'à produit Seam Gen). Seam Gen peut certainement etre très utile dans les back-office. Mais même dans un back-office, ce serait dommage de se passer de la couche métier

[anicaise]

J'utilise maintenant Seam depuis quelques jours, mais je me pose encore des questions quant à l'architecture. Dans le projet que me génére Seam Gen, je place des EJB Stateless et Stateful dans le répertoire "Src/Action" et mes beans Entités dans le repertoire "Src/Model".

Cependant j'ai des classes utilitaires mais je ne sais pas ou les mettre. Biensur je pourrai les mettre dans le répertoire "Src/Action" avec les EJB mais çà ne me semble pas cohérent.

Quelqu'un de confirmé peut-il répondre à ce problème ? Merci à vous

[XmasRock]

• Annotation : permet de définir les défaut que peuvent être surchargés ensuite via des fichiers de configuration
• Seam-gen : permet de faciliter l'écriture d'applications simples (à la Ruby & Rails). Fonctionne à base de templates que vous pouvez prendre en main pour les adapter à vos besoins. Mais vous pouvez aussi ne pas l'utiliser si l'organisation qu'il génère par défaut ne vous aide pas
• Couche service : si vous générez une application CRUD à partir d'un schéma de base de données, vous devriez y retrouver vos petits avec les DAO pour accéder aux entités. La conversation devrait être utilisé.
• EJB3 : vous pouvez utiliser les EJB3 ou de simples POJOs.
• EJB3 bis : pour rappel, les EJB3 n'ont rien à voir avec les EJB2. C'est à mon avis plus simple à utiliser qu'avec une appli hibernate car l'intégration est déjà faite avec les différents services (sécurité, transaction, cluster, ...)
• Stateful : non abordé ici, les coté contextes et stateful qui apporte énormément au modèle

N'hésitez pas à consulter l'excellent livre : http://www.michaelyuan.com/blog/seam...web-framework/

[anicaise]

Je me trompe peut être mais la couche "Services" correspond aux EJB3 ?

D'après la documentation, Seam permettrait de rapprocher la couche applicative (JSF) et la couche services (EJB3). De ce fait, il n'y a plus d'intérêt à partir sur une architecture en 3 couches .. dans ce cas là, autant partir sur Tapestry, Spring et Hibernate.

Seam me semble en revanche très complexe à mettre en place. Je suis partie sur un projet généré par Seam Gen ...

Mon but étant de développer un site de vente en ligne, j'aimerais partir sur une architecture clean.

XmasRock je rebondis sur ce que tu dis ... En effet "seam gen" se base sur des templates mais ce ne sont rien d'autres que des Facelets ....

Quelqu'un a-t-il un exemple d'architecture de projet Seam mais non généré avec "Seam gen" ? Tous les exemples qui sont livrés avec Seam se basent sur "Seam Gen" ....

Merci à vous tous pour votre soutient...

[XmasRock]

Je me trompe peut être mais la couche "Services" correspond aux EJB3 ?

EJB3 ou Pojo (regardes l'exemple appelé "hibernate2")

D'après la documentation, Seam permettrait de rapprocher la couche applicative (JSF) et la couche services (EJB3). De ce fait, il n'y a plus d'intérêt à partir sur une architecture en 3 couches .. dans ce cas là, autant partir sur Tapestry, Spring et Hibernate.

Seam c'est plus que ça : http://jboss.com/products/seam/whyseam

Mon but étant de développer un site de vente en ligne, j'aimerais partir sur une architecture clean.

Pour moi Seam est vraiment ce sur quoi je commencerais un nouveau projet. Mais ton choix t'appartient

En effet "seam gen" se base sur des templates mais ce ne sont rien d'autres que des Facelets ....

Regardes les sous-répertoires de seam-gen, il y a aussi les templates (squelettes) freemarker servant de base au classes java/fichiers de description ainsi que des tokens qui seront remplacés lors de la copie par ant.

[KiLVaiDeN]

Est-ce que Seam fonctionne uniquement sur JBoss ou il est portable sur n'importe quel serveur J2EE ? Excuse moi si la question est évidente, mais elle est suffisament importante pour savoir si s'engager dans Seam est équivalent à signer un pacte avec JBoss

[XmasRock]

Quelqu'un a-t-il un exemple d'architecture de projet Seam mais non généré avec "Seam gen" ?

J'imagine qu'il te faut lire la doc notamment le chapitre 25 (page 228) : "Configuring Seam and packaging Seam applications"

Envoyé par KiLVaiDeN

Est-ce que Seam fonctionne uniquement sur JBoss ou il est portable sur n'importe quel serveur J2EE ? Excuse moi si la question est évidente, mais elle est suffisamment importante pour savoir si s'engager dans Seam est équivalent à signer un pacte avec JBoss

l'exemple hibernate2 est ton ami

[anicaise]

J'imagine qu'il te faut lire la doc notamment le chapitre 25 (page 228) : "Configuring Seam and packaging Seam applications"

Merci pour le tuyau !!

En fait j'ai déjà commencé à développer mon appli Ecommerce en attaquant la partie Authentification.

Ma question première concernait le cryptage d'un mot de passe. Je me demandais à quel niveau je pouvais stocker mes classes. Mais je pense avoir la réponse !!! Je vais me faire un petit fichier jar que je vais intégrer à mon projet !!

As tu déjà développé un petit projet avec Seam ? Moi j'en suis très content .... çà marche très bien et c'est très puissant ....

[XmasRock]

ce que j'aime, c'est la panoplie de truc prêt à l'emploi et puissants

Pour la secu, tu as vu le chapitre 13 ?

[anicaise]

Oui j'ai vu le chapitre 13 comme le reste de la doc ... pourquoi j'aurais loupé quelque chose sur le cryptage de chaines ?

[XmasRock]

non, c'est juste qu'il y a plein de trucs sympas pour la sécu et que ce serait dommage de passer à coté

[Uncle Dave]

Bon je vais donner mon avis :

Sur la question des couches.

Je pense plutôt que c'est la couche contrôleur qui est absente par défaut (ou bien confondu avec la notion de service), effectivement, comme quelqu'un l'a fait remarquer, les EJB session jouent le rôle de classes de service.
De plus je n'ai pas en tête de framework ou combinaison de framework dont l'utilisation implique de séparation en trois couche. Pour ma part je développe beaucoup d'application Struts(1/2) / Spring / Hibernate, rien ne m'empêche de fusionner les couches mes actions Struts peuvent très bien réaliser les tâches métiers et accéder la couche de persistance. Et puis pour pousser mon raisonnement à l'extrême (de sa stupidité) on peut bien mélanger JSP et couches de persistance.
Enfin, ce genre de remarque s'applique plus à JSF qu'à Seam à mon avis. C'est la liberté fournie pour l'implémentation des backing beans qui laisse le développeur se débrouiller.

En ce qui concerne Seam-gen.

Je crois qu'il ne faut pas essayer de le détourner de son but. De mon point de vue seam-gen est un quickstart pour démarrer une appli web qui fait du CRUD. C'est à mon sens un cas d'utilisation simple avec une valeur ajoutée nulle du développeur. Pour une application aussi simple, pourquoi vouloir à tout prix appliquer le pattern MVC ?

Sur la question de la portabilité du framework.

Là tout n'est pas rose, si beaucoup de choses ont été faites avec la version 2, notamment pour l'utilisation de Tomcat et Hibernate, il y a encore des manques, des choses que l'on peut faire avec JPA et EJB et qui ne marchent pas avec Hibernate. Voici un lien qui décrit quelques configurations qui marchent ou pas
http://www.michaelyuan.com/blog/2007...ation-servers/

Les annotations.

Pour ceux chez qui les annotations provoquent des cauchemar , sachez qu'il est également possible de déclarer ses composant dans un fichier xml (component.xml). C'est d'ailleurs la seule manière de créer plusieurs composants de même type avec des noms et des scope différents, cela permet également d'impacter sur les composants prédéfinis.

Spring et Seam.

Je ne pense pas que Spring et Seam s'excluent mutuellement. Je pense que Spring est d'une très (très (très)) grande richesse et que Seam apporte d'autres moyens d'intégration de certains framework (drools, jBPM, etc ...) ainsi que la notion de Statefull. Bien sûr, les deux framework proposent certains outils concurrents (la gestion des transactions pour ne citer que cela), mais ils s'enrichissent mutuellement. Exemple 1 : avec Hibernate et Spring il est (me semble-t-il) plus simple de récupérer le transaction manager du serveur d'applis J2EE qu'avec Seam. Exemple 2 : Seam permet d'encapsuler les bean Spring pour leur donner la notion de Statefull.

Pour finir je reprends la liste des avantages inconvénients énoncée précédemment.

Avantages :

• rapidité de développement. Quand on voit la taille des codes sources donnés en exemple et les fonctionnalités qu'ils implémentent, on ne peut qu'admettre que ça a l'air plutôt facile à appréhender.

• configuration via les annotations : je mettrais ce point aussi dans les inconvénients, mais il est vrai que certaines personnes peuvent aussi apprécier d'avoir à la fois la configuration et la logique dans un même listing. De plus ça peut aider pour le refactoring.

• intégration avec les standards J2EE : Seam parait forcer l'utilisation des standards, ce qui dans l'ensemble est une bonne chose pour le futur, et pour la portabilité. jpa

• outils de développement : les outils mis en place paraissent simples et efficaces dans la génération de code.

Inconvénients :

• où est passée la couche service ? peut-être qu'il faudra attendre un peu pour qu'avec le retour sur l'expérience on voit de nouveaux patterns afin de bien gérer ce type de projet avec une meilleure séparation des couches.

• la configuration via les annotations : je cite ceci dans les inconvénients aussi, car j'adore le coté "mon Pojo fait une chose, mes fichiers de configuration le configure". Ça permet d'avoir un code beaucoup plus simple à lire et à maintenir..

• serveur J2EE obligatoire : avec Spring, on peut faire une application qui ne nécessite pas forcément un serveur J2EE complet pour tourner, et bien fonctionner.

Malheureusement pour la rapidité de développement, je mettrai un bémol car le ticket d'entrée dans le framework me semble assez élevé par contre c'est clair qu'une fois le framework bien connu c'est certainement l'un de ceux qui permettent de mettre en place une appli entreprise le plus rapidement.
Pour les annotations, comme je l'ai fait remarquer, ce n'est pas la seule manière de faire. Je pense que sur ce point les querelles de clocher ne sont pas les bienvenues. Certaines choses seront plus élégantes avec des annotations, d'autres seront moins complexes avec des fichiers de déclaration.
Pour le côté J2EE de la chose, ça bouge beaucoup. Je n'ai pas spécialement de problème à faire tourner des applis avec Tomcat et Hibernate (surtout avec Seam v2). Il manque quelques bricoles, mais cela va changer dans les prochaines versions.

David