Discussion :

[muad'dib]

Bonjour à tous,

Tout est dans le titre ! Je développe actuellement une application struts 2 + hibernate + spring sur un serveur tomcat. Tout marche pour le moment correctement, et je me demandais s'il pouvait être intéressant de passer sur JBoss (ou un autre serveur d'applications)

J'ai vu que JBoss venait intégré avec hibernate par exemple, aurais-je intérêt à passer sur ce type de serveur pour mon projet ? Je ne vois pas bien la différence. À chaque fois on dit que JBoss supporte les EJB, ne serait-ce pas l'équivalent de Spring ?

Je suis un peu largué sur l'intérêt de JBoss, si quelqu'un pouvais m'éclairer ^^

Merci !

[DevServlet]

Personnellement si ton appli ne déploie pas les EJB, tu restes sur du tomcat, mis à part les EJB, jboss déploie beaucoup d'autres services dont une simple appli web n'en a pas besoin, tu peux lister tous ces services dans son fichier de conf(jboss-service.xml). Jboss c'est du tomcat + conteneur EJB + plus d'autres services additionnels. D'où sa lenteur de démarrage tu remarqueras. dans ton cas tomcat te fera très bien l'affaire, je me souviens pour un client qui nous l'avait imposé avoir passé du temps à désactiver ces services pour accélérer son démarrage, mais bon tu me diras un serveur d'appli n'est pas censé redemarrer tout le temps

[muad'dib]

Merci pour ta réponse

J'ai été voir un peu les service qu'il y a dans ce fichier, j'ai vu entre autres web service, logging factory, JTA et security config..

Donc selon toi je n'ai rien à gagner à passer mon appli sur jboss ? Quid de la web-console ? Ça a l'air pas mal à première vue, un outil de visualisation de charge du serveur, de statistiques etc.. c'est ça non ? Ça peut se trouver un équivalent pour Tomcat?

[DevServlet]

Merci pour ta réponse

J'ai été voir un peu les service qu'il y a dans ce fichier, j'ai vu entre autres web service, logging factory, JTA et security config..

Donc selon toi je n'ai rien à gagner à passer mon appli sur jboss ? Quid de la web-console ? Ça a l'air pas mal à première vue, un outil de visualisation de charge du serveur, de statistiques etc.. c'est ça non ? Ça peut se trouver un équivalent pour Tomcat?

Tu peux coupler tomcat à une JConsole pour suivre à chaud les transactions, ils expliquent ici, après si ton choix se porte sur Jboss je n'ai rien contre, mais son utilisation n'est pas indispensable pour ton cas.

[Jidefix]

Merci pour ta réponse

J'ai été voir un peu les service qu'il y a dans ce fichier, j'ai vu entre autres web service, logging factory, JTA et security config..

Donc selon toi je n'ai rien à gagner à passer mon appli sur jboss ? Quid de la web-console ? Ça a l'air pas mal à première vue, un outil de visualisation de charge du serveur, de statistiques etc.. c'est ça non ? Ça peut se trouver un équivalent pour Tomcat?

La web-app JProbe est pas mal du tout pour ça. Un minimum de configuration (tutorial d'install sur leur site), et tu peux voir tout ce que tu veux (tu peux même naviguer dans le données des sessions utilisateurs)

[kdmbella]

utiliser Jboss dans ton cas c'est comme vouloir utiliser une scie a moteur pour couper un crayon. Donc oui tu peut l'utilise, mais utiliser Tomcat serait plus judicieux pour les besoins que tu as spécifiées.

[muad'dib]

Merci beaucoup à tous pour vos réponses

Tant que j'y suis j'aimerais vous demander alors dans quel cas utiliser JBoss ? Pourquoi utiliser des EJB plutôt que spring ? Pourquoi utiliser une version JAR d'hibernate quand jboss vient avec hibernate intégré (d'après ce que j'ai compris)

Enfin pourquoi choisir JBoss ? Pour des architectures d'application n-tiers ?
Dans le cas où je souhaiterais diviser le code source de mon appli sur plusieurs serveurs (par exemple la vue sur un ou 2 serveurs, la partie modèle sur 1 autre et la partie metier sur un autre (je dis le nombre des serveurs au hasard)) : est-ce que choisir JBoss simplifierait cette répartition des parties de l'application ?

Est-ce possible de diviser l'applications sur plusieurs serveurs sans un serveur d'applications ? Si plus tard, le site que je suis entrain de créer commence à souffrir niveau charge, passer à JBoss sera compliqué ?

[NoClassDefFound]

Spring et JBoss n'ont pas rien à voir l'un avec l'autre.
Spring est un conteneur léger, il a besoin d'être déployé dans un conteneur de servlet (Tomcat, Jetty, ...), tandis que JBoss est un serveur d'application J2EE à part entière (embarquant un Tomcat d'ailleurs).

Côté Spring, rien ne t'empêche d'utiliser un autre ORM qu'Hibernate, comme MyIbatis par exemple.
Côté J2EE, tout dépend du serveur d'application que tu va choisir.
Par exemple, Hibernate est l'implémentation de la spécification JPA choisie par JBoss; mais d'autres serveurs d'applications comme Glassfish utilisent une autre implémentation (EclipseLink en l'occurence).

Quant à choisir entre le pattern J2EE et Spring, le débat est sans fin.
Spring te permet de fournir les mêmes services que du J2EE standard : EJB3, JMS, WebServices, Injection de dépendances, ...
A titre personnel, pour avoir travaillé avec les deux, la légèreté de Spring est appréciable au niveau développement, en contraste avec la lourdeur du pattern J2EE.
Maintenant, la majorité des serveurs d'application J2EE du marché fournissent un certain nombre de fonctionnalités intéressantes comme la gestion des pools d'EJB, des pools de connexion BDD, des files JMS, ce qui s'avère fort appréciable pour l'exploitation. Qui plus est, tous ces serveurs J2EE implémentent la spécification, donc tu est à peu près sur d'avoir des comportements homogènes, cela peut t'éviter d'oublier de fermer une session Hibernate par exemple.

Par expérience, séparer la couche métier et la couche présentation entraîne une baisse des performances de l'applicatif à cause du temps de sérialisation/désérialisation des objets. Il est préférable de multiplier le nombre de serveurs que de séparer les différentes logiques.

Quant à la répartition de charge, généralement les architectures sont basées sur les couples Apache+Tomcat+Spring ou Apache+Serveur J2EE.
La seule différence majeure que je vois est que tu peux faire tourner un Tomcat sur une machine beaucoup moins puissante que pour un serveur JBoss (quantité de mémoire allouée)