Discussion :

[romarseille]

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 ?

[viena]

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.

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

@+

[romarseille]

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.

[romarseille]

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

[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é.

[romarseille]

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

[romarseille]

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

[FreshVic]

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

[romarseille]

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 ?

[romarseille]

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 ?

[FreshVic]

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.

[romarseille]

OK,
Pour en revenir aux webservices, je comprend l'interet que tu leur trouve, mais dans mon cas, l'appli est une appli web et le client un simple navigateur (IE ou de préférence Firefox), dès lors je ne pense pas que les WS soient nécessaires. De plus l'appli n'est pas distribuée si ce n'est que l'archi de déploiement sera "éclatée", c'est à dire avec apache, Jonas ou Jboss (serveur d'appli) et les BD sur des serveurs différents.

[yopiyop]

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 ?

Il faut bien distinguer les frameworks et les serveurs d'applications...
Les contraintes sont toujours les memes : version de JAVA (5 ou pas) et niveau de servlet/JSP/EJB du serveur d'application.

Si tu as les pleins pouvoirs de décisions :
sans hésiter : EJB3.
par contre pour la couche présentation, il est temps d'arréter struts, ca fait 2 ans que ce projet est mort et il souffre de beaucoup de défauts de conception. si tu veux garder un modele MVC, prends celui de spring qui est très souple. sinon JSF + facelets est surement est bon choix si le niveau des developpeurs est corrects ...

Il y a en ce moment énormement d'alternatives excellentes pour les couches présentations :
-wicket
-echo2
-ZK
-Lazslo
-stripes
-gwt (pas très mature)
-...


Bon courage car le choix n'est pas facile...

[viena]

par contre pour la couche présentation, il est temps d'arréter struts, ca fait 2 ans que ce projet est mort

Qu'est ce qui te fai dire cela ?

[KiLVaiDeN]

Il y a Struts 2 qui est en préparation au fait, déjà téléchargeable sur le site de jakarta. Donc dire qu'il est mort est à mon avis prématuré

[viena]

Il y a Struts 2 qui est en préparation au fait, déjà téléchargeable sur le site de jakarta. Donc dire qu'il est mort est à mon avis prématuré

Et même la première version de Struts, elle est encore très largement utilisé par les entreprises développant en web/java, donc même s'il n'est plus de première jeunesse, je pense qu'il est très loin d'etre mort.

[KiLVaiDeN]

Et même la première version de Struts, elle est encore très largement utilisé par les entreprises développant en web/java, donc même s'il n'est plus de première jeunesse, je pense qu'il est très loin d'etre mort.

Oui bien sûr, 100% d'accord avec toi, Bellissima !

[yopiyop]

Et même la première version de Struts, elle est encore très largement utilisé par les entreprises développant en web/java, donc même s'il n'est plus de première jeunesse, je pense qu'il est très loin d'etre mort.

Je dis simplement que utiliser struts sur un projet tout neuf si on est pas obligé par la politique maison, c'est vraiment dommage...struts n'a pas évolué depuis 2 ans ! en informatique et surtout en nouvelles technos Java, ca fait vieux.

struts 1.x est lourd et rigide (erreurs de jeunesses du modele MVC2), il y a des alternatives mieux concues.
Il suffit d'essayer webwork (qui devient d'ailleurs le coeur de struts avec son fameux Xwork) ou springmvc pour comprendre...

struts 1.x est largement utilisé et déployé donc survivra longtemps. c'est comme le cobol. c'est pas pour ca que je me sens obligé de commencer un nouveau projet avec.

La 'nouvelle' version (ou plutot les nouvelles versions) de struts ne sont pas LE struts que tout le monde connait. Il ne reste que le nom, ca c'est du marketing. on change le produit, on garde le nom pour continuer a rassurer les décideurs informatiques...

@+