[ARCHITECTURE J2EE] SEAM, Spring, Hibernate, JDO : que choisir ?

Bonjour à tous,
Je suis étudiant en écolé d'ingénieur et j'ai un projet à réaliser de A à Z.
Les besoins sont biens déterminés, et maintenant je souhaiterais définir l'architecture que j'utiliserai.
La seule demande du client est d'utiliser des technologies J2EE.
Après moults recherches et lecture de tests et autres conseils, je dois avouer que je suis plutôt perdu parmi toutes les possibilités qui s'offrent à moi :
- Jboss SEAM
- Jonas
- Hibernate
- EJB3
- JDO
- JSF
...
Je connais le principe de ces différents "outils" mais j'ai vraiment du mal à savoir lesquels combiner pour avoir une architecture la plus cohérente possible. Ce projet étant voué à être repris par d'autres développeur sur les 2 années à venir, je dois mettre en place une architecture utilisant les dernières avancées technologiques du monde JAVA.

A priori, je pensais utiliser SEAM (qui, si j'ai bien compris implémente JSF, EJB3 et Hibernate), mais certaines critiques me donnent à réfléchir. Parrallèlement à celà, je viens de voir que JDO 2.0 vient d'etre signé par la plupart des membres du consortium sauf Jboss (qui apparemment défend sa solution).

Dès lors, et je pense que la plupart des architectes J2EE se posent cette question actuellement, QUE CHOISIR ?

ormis les offres "tout compris" comme SEAM, tu peux piocher toi même dans les différents outils qui existent.
Pour le serveur d'appli, tu as effectivement le choix entre jonas et jboss en gratuit. Les deux se valent selon moi, les différences se font sur la doc, sur la nationnalité, sur "l'experience"... enfin, tu trouveras des comparatifs dans des posts précédents.
Pour l'accés aux BDD, tu as Castor, Hibernate, JDBC, EJB entity... là également, tu trouveras des comparatifs. Hibernate restant la référence en la matiere et JDBC (pas de mapping) le plus simple.
Pour la facade, Struts reste le plus utilisé, JSF n'a pas eu le succes escompté mais est une bonne solution (évenementielle). Mais quoi qu'il en soit, je te conseille les JSP, quelque soit l'outil que tu utilises pour "t'aider".
Pour le métier, à toi de voir s'il est utile d'utiliser les EJB session. Ca peut être un bazooka pour tuer une mouche, mais bon, ton projet d'etude est la pour te permettre d'apprendre... sinon, une solution java utilisant des pattern et une bonne séparation des couches peut suffir. Tu as aussi les Web service, dans le principe de faire pour apprendre ;)

Sinon, penche toi sur Spring, il propose des solution à tous les niveaux de couches et à l'avantage d'etre indépendant dans ce couches. Tu peux donc l'utiliser uniquement pour la facade par exemple.

Perso j'utilise struts + spring + hibernate pour respecter une architecture MVC que je juge tres satisfaisante.
Tu trouvera sur http://www.developpez.net/forums/sho...d.php?t=136904 une image représentant cette architecture et une description du fonctionnement de celle çi avec un bout de code.

Je te conseil de lire quelques tutos sur le modèle MVC dispos sur le site (tres important pour avoir une bonne architecture).

Ps: niveau serveur d'appli gratuit j'utilise tomcat mais j'avoue avoir des petits problèmes de performances que je n'arrive pas à résoudre.

@+

Merci pour ta réponse.
En fait, en plus du coté apprentissage, je dois choisir une architecture qui permettra d'avoir une application pérenne, évolutive et ayant une bonne capacité de montée en charge.
La version actuellement en test est basée sur Struts, on me demande donc d'en faire la migration vers une solution plus "récente". A terme, elle comptera environ 100 000 utilisateurs...

En ce qui concerne JSF, c'était surtout pour "apprendre" car je connais assez bien Struts et je voulais voir autre chose. Dans tout les cas, la partie "Vue" sera faite en JSP.
Pour l'accès aux BDD, il m'est demander qu'elle permette de faire abstraction de la source, Hibernate se détache donc.

Ma plus grande hésitation repose donc sur le metier. Je connais et utilise déjà fréquemment le pattern MVC, cependant EJB3 et JDO voire spring (avec le pattern IOC) étant plus récent je me demandais si ils pourraient m'apporter quelques chose.

Si certains ont des avis éclairés à ce sujet...

Citation:

---

Envoyé par nikalkal

Perso j'utilise struts + spring + hibernate pour respecter une architecture MVC que je juge tres satisfaisante.
Tu trouvera sur http://www.developpez.net/forums/sho...d.php?t=136904 une image représentant cette architecture et une description du fonctionnement de celle çi avec un bout de code.

Je te conseil de lire quelques tutos sur le modèle MVC dispos sur le site (tres important pour avoir une bonne architecture).

Ps: niveau serveur d'appli gratuit j'utilise tomcat mais j'avoue avoir des petits problèmes de performances que je n'arrive pas à résoudre.

@+

---

Merci à toi aussi pour ta réponse, comme je le dis plus haut, je connais assez bien le modele MVC mais en lisant quelques articels sur Internet, il me semblait que ce modèle était fortement remis en question par les nouveau framework. Etant donné que l'on me demande d'utiliser les "meilleures solutions" je voulais donc savoir ce que SEAM peut apporter en plus, idem pour l'utilisation des EJB3.

Pour résumer :

Faut-il continuer à utiliser Struts en façade ou dès à présent utiliser JSF, et est-il interessant de s'engager sur JBoss SEAM ?

Le tout en tenant bien compte du fait que l'architecture définit aujourd'hui ne sera mise en oeuvre que dans un an...

Très franchement, JSF n'a vraiment pas tenu son pari et n'est pas en voie de remplacer Struts. Cependant, dans un but d'apprentissage, pourquoi pas, la seule question étant : est il utile d'apprendre une technologie peu utiliser plutot qu'une autre ? Il me semble que Spring peut vraiment être une altérnative, même si je la connais très peu pour l'interface.
Pour ce qui est de la couche métier, privilégie Spring ou les EJB3 plutot que JDO (avis personnel). A ta place j'utiliserais Spring, qui est vraiment une altérnative étudiée actuellement sur le marché.

Je ne connais pas JDO, mais avec les EJB tu peux faire de la répartition de charge sur plusieurs serveurs (du moins avec un Websphere). Si ton appli doit pouvoir tenir la charge, EJB3 me semble une bonne solution au moins pour la couche Service (EJB Session).

Citation:

---

Envoyé par viena

Très franchement, JSF n'a vraiment pas tenu son pari et n'est pas en voie de remplacer Struts. Cependant, dans un but d'apprentissage, pourquoi pas, la seule question étant : est il utile d'apprendre une technologie peu utiliser plutot qu'une autre ? Il me semble que Spring peut vraiment être une altérnative, même si je la connais très peu pour l'interface.
Pour ce qui est de la couche métier, privilégie Spring ou les EJB3 plutot que JDO (avis personnel). A ta place j'utiliserais Spring, qui est vraiment une altérnative étudiée actuellement sur le marché.

---

Ok, merci pour cette avis.

La question qui em pose problème n'étant pas pas "Jsf est-il plus utilisé actuellement que Struts ?" mais plutôt "Pour une application dont le déploiement n'est pas prévu avant l'année prochaine, vaut-il continuer avec Struts ou bien migrer dès aujourd"hui vers JSF ?"

Pour le métier, Spring semble être le plus recommandé même si les récent EJB3 (et leur implémentation dans SEAM) semble pouvoir remettre l'état de l'art en question, toujours dans l'optique d'un déploiement prévu pour l'année prochaine.

Citation:

---

Envoyé par neuromencien

Je ne connais pas JDO, mais avec les EJB tu peux faire de la répartition de charge sur plusieurs serveurs (du moins avec un Websphere). Si ton appli doit pouvoir tenir la charge, EJB3 me semble une bonne solution au moins pour la couche Service (EJB Session).

---

Oui, effectivement, je ne l'ai pas mentionné explicitement, mais je dois faire du "load balancing" avec plusieurs serveurs de BD, idem pour les serveurs d'applications. (Pour l'application actuelle : modèle MVC s'appuyant sur Struts, tomcat en serveur d'appli et Mysql en BD, nous avons déployé un serveur frontal pour la bd et l'appli + deux serveurs dorsaux).

Personne ne connaitrait un "Gourou" qui aurait testé toutes les architectures possibles en J2EE actuellement et qui serait capable de deviner quel sera l'état de l'art dans un an ou plus ?

:lol: :oops:

Même une personne qui aurait éprouver toutes les techno ne pourrait le savoir.
L'emergence d'une techno ne vient pas seulement du fait qu'elle est stable, facile, puissante... mais également du fait que les entreprises l'utilisent ou pas et les choix des entreprises ne suivent pas toujours les mêmes logiques que celles des developpeurs ;)

Citation:

---

Envoyé par viena

Même une personne qui aurait éprouver toutes les techno ne pourrait le savoir.
L'emergence d'une techno ne vient pas seulement du fait qu'elle est stable, facile, puissante... mais également du fait que les entreprises l'utilisent ou pas et les choix des entreprises ne suivent pas toujours les mêmes logiques que celles des developpeurs ;)

---

Oui c'est vrai, mais je pense que des personnes très impliquées dans ce secteur (architectes,...) peuvent, en prenant en compte aussi bien les apscets techno qu'économiques, anticiper sur l'avenir de telle ou telle techno.

En ce qui te concerne, si j'ai bien compris, tu "défendrais" plutot Struts au dépend de JSF et Spring au dépend de SEAM.

SEAM est trop recent pour pouvoir se prononcer. De plus, ce n'est pas exactement la meme chose (concurent) que Spring.
Pour ma part, je défendrais pour l'instant Struts et Spring effectivement. Hibernate, bien sur. les EJB3 qui reglent pas mal de problemes sur les EJB.
Pour ajouter de la souplesse et pour se former (sachant que ca perce fort!) je te conseillerais également Ajax.
Cette techno est pour l'instant assez représentative de ce qu'on trouve en entreprise et donc ce qui est recherché. Je pense que d'ici 1 an, ca sera encore le cas. Dans les 5 ans à venir, c'est plus délicat de se prononcer.

NB : je suis architecte et je n'aurais pas la prétention de dire que je connais l'avenir ;)

Citation:

---

Envoyé par viena

SEAM est trop recent pour pouvoir se prononcer. De plus, ce n'est pas exactement la meme chose (concurent) que Spring.
Pour ma part, je défendrais pour l'instant Struts et Spring effectivement. Hibernate, bien sur. les EJB3 qui reglent pas mal de problemes sur les EJB.
Pour ajouter de la souplesse et pour se former (sachant que ca perce fort!) je te conseillerais également Ajax.
Cette techno est pour l'instant assez représentative de ce qu'on trouve en entreprise et donc ce qui est recherché. Je pense que d'ici 1 an, ca sera encore le cas. Dans les 5 ans à venir, c'est plus délicat de se prononcer.

NB : je suis architecte et je n'aurais pas la prétention de dire que je connais l'avenir ;)

---

:ave: merci madame !

Si d'autre personnes passant par là ont des avis convergents ou divergents, je suis toujours preneur... ;)

Alors, pas d'autres avis (contradictoires ou non) ?

Moi perso , j'hesiterais pas a faire du spring ca fait 2 ans que je bosse et je suis un peu frustrer de ne pas avoir travaillé avec, mais les societe on du mal a migrer niveau techno, d'autant plus que certains projet sur lesquels je suis intervenu etait loin d'un model en couche "propre"
Par j'eviterais les EJB mais bon je ne connais pas assez les probleme de load balancing et de monter en charge peut etre qu'effectivement un serveur d'appli performant gerera tres bien ce genre de choses .

D'apres moi il est difficile d'eviter les web services pour le coté distribué HTTP+XML est un duo de standard permettant de ne pas dependre d'une techno tel que les EJB, tu peu toujours mettre un web service en frontal devant un EJB session , ca permettra de rendre le client independant de la techno du serveur (PHP,JAVA,.NET ... etc).

Par contre je voulais intervenir sur la parti presentation , il y a une emergence des framework dit a base de composant, c'est a dire developper du web comme une appli swing, je siterais :

Wicket : http://wicket.sourceforge.net/Features.html (on commence a en entendre parler, et en bien )

Tapestry : http://jakarta.apache.org/tapestry/
Du jakarta probabelement efficace mais selon il vendent pas bien leur truc mais bon c mon opinion , mais il s'agit la d'un framework important tout de meme !!

Millstone : http://millstone.org/
Mais on m'a dit qu'il est destiné a devenir payant (a verifier)

et puis certains disent que JSF est loin d'etre enterré.

Je ne fait que repeté ce que j'ai lu ou entendu mais j'aime bcp l'idée des framework a base de composants, developpé du html comme du swing permettrais de rester "objet" de bout en bout du dev.

Mais la guerre des framework ne fait que commencé , personne n'a encore vraiment percé, dernierement je dirait que Wicket fait un peu plus de bruit que les autres , mais il est evident que choisir maintenant represente un risque .

Enfin ce n'est que mon humble avis

Ok merci,
donc apparemment la plupart d'entre vous privilégie l'usage de Spring.

Par contre, j'ai du mal à cerner l'intéret d'intégrer des WS ici, si tu pouvais m'expliquer un peu mieux...

Concernant les EJB, j'ai un peu l'impression que personne ne peut réellement dire quel est leur interet par rapport aux autres technos.

Enfin pour la partie présentation, je ne connaissais pas les wicket, ça à l'air interessant : sais-tu si l'utilisation d'AJAX est facilité par l'usage de cette techno ?

Re,
Alors, pour ceux que ça intéresse, je viens de tomber sur un article http://www.dotnetguru2.org/sami/index.php sur l'intéret d'utiliser Spring par rapport aux dernières sépcifications d'EJB3, celà vaut ce que ça vaut... mais, selon lui, les avantages de Spring sont maintenant disponibles avec les EJB3 (disposer de l'Ioc, des transactions automatiques, du mode POJO).
Spring serait donc "fagocité" par EJB3...

En ce qui concerne Wicket, je conseille vivement à ceux qui ne connaissent pas d'y jeter un oeil, car pour moi, c'est le seul framework qui semble réellement permettre la séparation entre code et vue (je me trompe ?).

Je pense donc me diriger vers une solution du type :
-> Ajax et wicket pour la vue et la coordination
-> EJB3 pour les services (métiers)
-> Hibernate pour le domaine (quoi que selon le même article JPA pourrait à son tour remettre l'intéret d'hibernate en question...).

Bref, ce projet, m'aura au moins permis de me confronter à la difficulté de faire le tri et d'opter pour telle ou telle solution du monde Java. (Je commence à comprendre les inconditionnels du .net...).

Quand pensez-vous ?

Je ne connais pas Wicket je me suis contenter de regarder les demo et quelques exemple de code , je ne pourrais donc pas en dire plus.

En ce qui concerne les Web services, pour moi leur interet est de ne pas dependre de techno particuliere , si tu utilise les EJB pour faire du distribué (appel a distance) ton client devrat absolument etre en java, alors que si tu utilise des web service le client peu tres bien etre en .Net et le serveur basé sur J2EE.

Et puis les web service utilise Http sur le port 80 generalement le seul port d'ouvert dans une societe proteger par un firewall.

En ce qui concerne Hibernate j'ai lu qu'Hibernate sera l'une des premiere implementation des EJB 3.0 (c peut etre deja le cas j'ai pas trop suivi dernierement) avec Toplink egalement (qui lui est payant), je pense pas qu'hibernate soit amener a disparaitre d'ici 1 an.