Architecture de JBoss Seam [Débat]

**manblaizo** · 30/11/2007, 13h26

Envoyé par Uncle Dave

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 richesses 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.

Bonjour,
Pourrais-tu développer un peu ta pensée sur la gestion des transactions, et en quoi Spring et Seam proposent des solutions différentes ? En quoi par exemple serait-il moins simple de récupérer le transaction manager avec Seam ? Seam étant conçu et développé par la même équipe que celle de Hibernate, étant en plus mieux intégré à EJB3, il me semble que cet aspect de transactions ne devrait pas être un souci, je me trompe ?

Pour ce qui est de l'accès au framework (le "learning curve"), je crois que les deux frameworks, Spring et Seam, sont équivalents dans la mesure où les deux se proposent d'être fondamentalement des frameworks d'intégration, ce qui nécessite d'abord une bonne maîtrise des autres frameworks qui seront intégrés. Dans le cas de Seam, pour réaliser une application sérieuse il faudrait d'abord bien connaître au moins JSF, EJB3, JPA (Hibernate/TopLink), jBPM..., ce qui évidemment représente beaucoup pour commencer.
De même pour Spring, il faudrait déjà connaître au moins Hibernate (ou JPA), peut-être aussi EJB 3, AspectJ (AOP), et au moins un framework web (Struts1/2, SpringMVC, Tapestry,...), ce qui fait beaucoup aussi quand on débute.
Mais pour ce qui est de Spring et Seam en tant que frameworks eux-mêmes, je crois qu'ils ne sont pas très difficiles à apprendre, dans la manière dont ils facilitent l'intégration et surtout les plus qu'ils apportent au développeur en facilitant encore plus le développement d'applications d'architecture complexe, et moins complexe aussi d'ailleurs.

**Uncle Dave** · 30/11/2007, 15h43

Pourrais-tu développer un peu ta pensée sur la gestion des transactions

Je ne parle pas du cas EJB mais du cas hibernate pur, dans le cas de Spring il le fait pour toi avec une ligne du genre.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<bean id="transactionManager" class="org.springframework.transaction.jta.JtaTransactionManager" />

Ce n'est pas à proprement parler un souci c'était simplement un exemple pour illustrer les différences avec Spring ce n'est en rien structurant, c'est simplement l'exemple qui me viens.

Bien sur c'est un exemple biaisé puisqu'il il ne correspond pas à un cas d'utilisation JEE mais JSE. Cependant cela illustre bien que dans certain cas il peut être interessant de s'appuyer également sur Spring.

(dans le cas JEE je pense que seam pourrai même être mieux intégré mais je ne suis pas cappable d'exprimer un avis fiable sur la question)

Pour l'aspect learning curve, je suis d'accord avec toi, je ne songeai cependant pas à comparer les deux qui, je le répète me semble avoir une intersection de fonctionnalité non-nulle mais par ailleur offrir des possibilité différentes.
Ceci dit au delà de leurs principes architecturaux qui sans être simplistes sont relativement facile d'accès, ces frameworks trouvent leur principal intérêt dans leur capacité à intégrer d'autres tiers. Par conséquent on en bénéficie réellement qu'en ayant une vision suffisament large du vaste écosystème dans lequel elles s'intégrent.

**ericw78** · 30/11/2007, 21h23

Sur la question des couches.

Je pense plutôt que c'est la couche controlleur qui est absente par défaut (ou bien confondu avec la notion de service), effectivement, comme quelqu'un la fait remarquer, les EJB session jouent le rôle de classes de service.

C'est exactement le reproche que je ferai. Confondre la couche controleur et la couche service c'est caca

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évelloppe 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 persistence. Et puis pour pousser mon raisonnement à l'extreme (de sa stupidité) on peut bien mélanger JSP et couches de persistence.

Ba ca c'est pas bien non plus : mettre des fonctionnalités métiers dans la couche Action...Parce que comme tu le dit, pour "pousser à l'extreme", on revient aux développements d'y a 5 ans, style "asp", tout dans une page !!! Et on se retrouve avec des applis in-maintenable

Enfin, ce genre de remarque s'applique plus à JSF qu'à Seam à mon avis. C'est la liberté fournit pour l'implémentation des backing beans qui laisse le devellopeur se débrouiller.

C'est la où le bas blesse, non ? Si le framework ne fournit pas les bases minimumes, on se retrouve avec une appli non structurée et donc difficile à faire évoluer.

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 ?

Je pense qu'avec seam-gen, tu peux générer tres rapidement les structures de ton appli. Qu'elle soit petite ou importante, peu importe la taille de ton appli, le gain de temps est appréciable.
Alors pourquoi le faire, si c'est pour le faire mal ? Peu importe la taille de l'appli, personne n'aurait l'idée de constuire une appli de nos jours sans utiliser le pattern MVC ni la séparation en 3 couches.

Non, vraiment, il me semble que Seam est un bon produit, mais les exemples dans les tutoriaux ainsi que seam-gen sont à revoir....

**djo.mos** · 01/12/2007, 01h27

Bonjour.

Envoyé par Uncle Dave

Enfin, ce genre de remarque s'applique plus à JSF qu'à Seam à mon avis. C'est la liberté fournit pour l'implémentation des backing beans qui laisse le devellopeur se débrouiller.

Envoyé par ericw78

C'est la où le bas blesse, non ? Si le framework ne fournit pas les bases minimumes, on se retrouve avec une appli non structurée et donc difficile à faire évoluer.

Oh la là ! Qui est ce qui dit du mal de mon JSF chéri ? La, je me dois de réagir !
Plus sérieusement, ça n'a strictement rien à voir avec JSF (ni tout autre framework Web Java d'ailleurs)! On ne peut pas empêcher un programmeur de ne pas respecter la MVC que ce soit dans JSF ou Struts: Il est parfaitement possible de faire du code métier dans les actions Struts aussi ! Ce n'est pas parceque les managed beans de JSF sont flexibles (POJOs ordinaires, au lieu de suivre un plan rigide (à la Struts 1.x) ) qu'il encourage à casser le MVC !

A moins bien sur qu'un jour on puisse réaliser des outils intelligents et proactifs qui instrospectent le code des controleurs en les emêchant de toucher à la base ou de faure de la logique métier, le MVC restera toujours à la seule et unique responsabilité des programmeurs !

**XmasRock** · 01/12/2007, 12h15

Un outil n'est qu'un outil. C'est ton expertise qui te permet d'avoir une valeur ajoutée en tirant profit du meilleurs de l'outil pour adresser ta problématique courante.

**ericw78** · 01/12/2007, 13h04

Oh la là ! Qui est ce qui dit du mal de mon JSF chéri ? La, je me dois de réagir !
Plus sérieusement, ça n'a strictement rien à voir avec JSF (ni tout autre framework Web Java d'ailleurs)! On ne peut pas empêcher un programmeur de ne pas respecter la MVC que ce soit dans JSF ou Struts: Il est parfaitement possible de faire du code métier dans les actions Struts aussi ! Ce n'est pas parceque les managed beans de JSF sont flexibles (POJOs ordinaires, au lieu de suivre un plan rigide (à la Struts 1.x) ) qu'il encourage à casser le MVC !

Non, mon intention n'est pas de juger ni JSF ni Struts ni tel autre framework.

A moins bien sur qu'un jour on puisse réaliser des outils intelligents et proactifs qui instrospectent le code des controleurs en les emêchant de toucher à la base ou de faure de la logique métier, le MVC restera toujours à la seule et unique responsabilité des programmeurs !

Je suis à 100% d'acccord avec toi c'est pourquoi j'insiste sur le fait de disposer de "bons tutoriaux" qui pousseront le plus possible le développeur vers les "bonnes méthodes"

**Uncle Dave** · 03/12/2007, 15h56

Citation:
Sur la question des couches.

Je pense plutôt que c'est la couche controlleur qui est absente par défaut (ou bien confondu avec la notion de service), effectivement, comme quelqu'un la fait remarquer, les EJB session jouent le rôle de classes de service.

C'est exactement le reproche que je ferai. Confondre la couche controleur et la couche service c'est caca

mettre ses services dans les ejb session n'est pas une erreur de conception (au contraire), utiliser les ejb session comme contrôlleur par contre peut être considéré comme tel (separation of concern).

Personnellement pour moi, l'important est le respect de la separation of concern, après l'utilisation de tel ou tel pattern (MVC2 en l'occurence) me semble secondaire.

Je suis à 100% d'acccord avec toi c'est pourquoi j'insiste sur le fait de disposer de "bons tutoriaux" qui pousseront le plus possible le développeur vers les "bonnes méthodes"

Là OK, je vais essayer de trouver un contre exemple, mais c'est pas gagné

**Uncle Dave** · 03/12/2007, 17h01

OK après quelques lecture, je trouve que l'exemple du blog livré avec seam est plutôt orienté MVC, la partie contrôleur est entièrement réalisée avec le fichier de configuration de la navigation.

**jlemoine** · 21/02/2008, 13h48

Euh, vous me pardonnerez mon impertinence, mais la fameuse couche contrôleur que vous réclamez n'est-elle pas Seam itself ?

Blague à part, avez-vous de bonnes sources d'infos, conseils, tutos... pour maîtriser les conversations en profondeur ? Je trouve ça puissant sur le papier, mais pas trivial du tout sur le terrain.
En particulier, pour faire de la réutilisation de "use case" : je suis dans une conversation, je débranche temporairement vers une "sous conversation", et quand cette dernière est finie je reviens automatiquement vers la conversation principale.
Je n'ai pas trouvé de moyen autrement qu'en spécifiant un outcome prédéfini, ce qui casse la notion de "use case réutilisable".

**KneXtasY** · 08/04/2008, 12h58

J'ai eu l'occasion d'essayer ce Frameworks et voici mon point de vue.

N'hésitez pas à me corriger, si je dis des bêtises ...

Les exemples fournis montrent souvent des affichages avec des DataTables. Les checkboxs sont utilisés dans les formulaires et sont souvent mappées avec des propriétés booléennes des objets. Jusque là tout va bien !

Mais, si l'on souhaite effectuer une sélection d'objet avec des checkboxs, on se retrouve avec une "Map<Objet,Boolean> objetsSelectionnes" dans le backing bean qui joue aussi le rôle de Service. Le but de cette Map est d'extraire la liste des objets sélectionnés afin d'y effectuer des actions. Elle n'est utilisée que pour la sélection qui se fait à partir de la Vue (JSF). Au niveau métier, je n'ai besoin que d'une liste d'objet.

En fait, je trouve que la couche Service/Métier qui correspond pour moi aux EJB Session, se retrouve "polluée" par des fonctionnalités qui sont spécifiques à la Vue.

Ai-je raison ?
Y a-t-il un moyen de pallier à cela ?

Dans l'ensemble, Seam reste assez sympa à utiliser.

**Uncle Dave** · 29/05/2008, 12h35

Salut,

pour ton histoire de checkbox, je passe mon tour, par contre pour le côté pollution, on peut tout à fait faire cohabiter un jar "pojo" d'un coté et un jar ejb de l'autre. Ca se déploie très bien dans jboss, faut juste que ton jar ait un fichier seam.properties dans son META-INF. Comme ça tu code chaque chose à sa place.

**Uncle Dave** · 29/05/2008, 12h52

Euh, vous me pardonnerez mon impertinence, mais la fameuse couche contrôleur que vous réclamez n'est-elle pas Seam itself ?

oui, on aurait peut-être dû commencer par là

Blague à part, avez-vous de bonnes sources d'infos, conseils, tutos... pour maîtriser les conversations en profondeur ? Je trouve ça puissant sur le papier, mais pas trivial du tout sur le terrain.

la doc est déjà pas mal faite, moi je me suis pas mal appuyé sur le bouquin de Michael Yuan

En particulier, pour faire de la réutilisation de "use case" : je suis dans une conversation, je débranche temporairement vers une "sous conversation", et quand cette dernière est finie je reviens automatiquement vers la conversation principale.
Je n'ai pas trouvé de moyen autrement qu'en spécifiant un outcome prédéfini, ce qui casse la notion de "use case réutilisable".

Hum, arrête-moi si je me trompe, mais je pense que tu mélanges conversation et navigation.
Quand tu termines une conversation imbriquée (<end-conversation/> ou @end), tu te retrouves automatiquement dans le contexte de la conversation parente, mais cela n'est pas automatiquement corrélé à la navigation.
Une des manières de corréler plus fortement conversation et navigation est d'utiliser un pageflow pdl au lieu de la navigation normale
http://docs.jboss.com/seam/2.0.2.GA/...l_single/#jbpm

Mais je ne pense pas que cela résolve exactement ton problème. Ce qui serait envisageable serait de capter l'id de la vue précédent la création de la conversation et de l'utiliser comme outcome de ta méthode de fin de conversation, ce qui te renverrait à la dernière vue de la conversation parente si aucune règle plus forte n'est décrit dans le page.xml.

Dav

**kisitomomotene** · 05/06/2008, 13h38

Je ne comprends pas bien les problématiques débattues jusqu'ici :

1) Annotations vs fichiers de configuration.
- Est-ce que les deux notions s'excluent ?
- Je pense que la spécification EJB3 permet d'utiliser les deux, le fichier de config ayant la priorité sur les annotations quand les deux existent
- Est ce que Seam ne permet pas de gérer les deux ? Dans ce cas, c'est le monde idéal, on utilise les annotations pendant la phase de développement, puis les fichiers de configuration pendant la phase de maintenance.

2) La présence d'une couche service/contrôleur.
- La division en couche n'est-elle pas du ressort du concepteur ?
- Où est le problème si on utilise une session bean S1 comme contrôleur et une autre S2 comme fournisseur de service ? Les sessions bean devraient être vus tout simplement comme des objets serveur manageable par un conteneur JEE. C'est au concepteur de leur assigner un rôle dans son appli.

**Mikrob** · 13/01/2009, 17h51

Envoyé par kisitomomotene

Je ne comprends pas bien les problématiques débattues jusqu'ici :

1) Annotations vs fichiers de configuration.
- Est-ce que les deux notions s'excluent ?
- Je pense que la spécification EJB3 permet d'utiliser les deux, le fichier de config ayant la priorité sur les annotations quand les deux existent
- Est ce que Seam ne permet pas de gérer les deux ? Dans ce cas, c'est le monde idéal, on utilise les annotations pendant la phase de développement, puis les fichiers de configuration pendant la phase de maintenance.

2) La présence d'une couche service/contrôleur.
- La division en couche n'est-elle pas du ressort du concepteur ?
- Où est le problème si on utilise une session bean S1 comme contrôleur et une autre S2 comme fournisseur de service ? Les sessions bean devraient être vus tout simplement comme des objets serveur manageable par un conteneur JEE. C'est au concepteur de leur assigner un rôle dans son appli.

Seam permet bien entendu de gérer les deux. Il intègre EJB3, il ne les sur-couche pas. La seule pseudo sur-couche aux EJB ce sont les composants Seam qui sont transactionnels.

Entièrement d'accord pour le point numéro 2, c'est au concepteur d'architecturer le projet.

Pour revenir à ce qui a été dit sur le Seam-gen, les concepteurs de Seam le disent eux-même, il n'a pas pour but de créer des gros projets d'entreprise, mais de faciliter la développement d'applis CRUD, qui globalement reviennent toujours à faire la même chose, si ce n'est de changer le nom et deux ou trois associations entre objets. J'exagère un peu mais peut-être pas tant que ça ?
Je l'ai aussi utilisé pour démarrer des projets et faire des maquettes.

Ca fait grosso modo 6 mois que je bosse avec Seam, Spring m'as toujours rebuté car pour moi il y a beaucoup trop de configuration XML à faire et le démarrage d'un projet est complètement laborieux. Je reconnais ses qualités mais là dessus je ne démords pas.

Les annotations de Seam permettent de voir tout clairement au niveau de l'objet. En plus la gestion des cycles de vie et des contexte est d'une simplicité déconcertante une fois qu'on a pas mal exploré le framework

Mais pour revenir à un des posts que j'ai lu, il est clair que Seam demande pas mal de formations avant de l'utiliser correctement, et qu'au début on peut faire beaucoup de grosses bêtises sans le vouloir, en essayant d'utiliser à tort les facilités du framework (j'en ai fait pas mal au début).

Maintenant pour l'architecture, personnellement je divise toujours mes projets en 3 sous-projets :

Projet entities qui contient les EJB Entity
Projet services qui contient les services, que ce soit des services de type EJB Session, Message, ou les composants Seam.
Projet war, qui est la webapp et qui contient la partie JSF et les quelques fichiers de conf XML que Seam conserve (faces-config.xml, web.xml, components.xml, pages.xml ..) dans le WEB-INF.

Et on peut continuer sur ce modèle pour architecturer encore plus.

Le tout buildé avec Maven pour arriver soit à un seul ear contenant les 3 projets, soit à 2 ear (un pour le front et un pour le back office) quand c'est une appli distribuée. Ca demande un peu de travail sur Maven mais soit dit en passant, l'association Seam/Maven permet vraiment une grande flexibilité.

Pour la maitrise de la conversation, j'ai qu'un seul conseil c'est la pratique, puis c'est déjà commencer par essayer de mettre le plus d'objets à conservation d'état possible dans cette dernière.
Beaucoup d'objets qu'on va mettre naturellement et par automatisme en session, auraient tout à fait leur place en conversation. Cela demande un peu plus de réflexion et peut-être de travail (gestion des long running conversation) mais cela permet d'optimiser pas mal la mémoire et le cycle de vie des objets.