Souhaitez-vous, à l'heure actuelle, utiliser JBoss ou Glassfish (ou autre) comme serveur Java EE pour un nouveau projet? [fermé]


136

Si vous avez lancé aujourd'hui un nouveau projet Java EE qui doit être terminé dans environ un an, quel serveur d'application choisiriez-vous et pourquoi?

Une partie de votre réponse devrait inclure vos arguments en faveur de votre décision. Et aussi votre expérience avec le serveur Java EE que vous choisissez et avec les autres serveurs disponibles sur le marché. Celles-ci sont intéressantes car nous avons tous une idée de l'enquête et de la réflexion qui ont été mises dans votre réponse.

Réponses:


181

J'ai utilisé WebLogic, WebSphere, JBoss, GlassFish, Resin, Jetty, Tomcat et quelques autres au cours des 10 dernières années. Donc, si j'envisageais un nouveau projet, je me poserais d'abord quelques questions. Une chose que je ne remettrais plus en question, c'est que je refuserais catégoriquement d'utiliser les JSP à moins d'être torturé jusqu'à ce que je pleure pour ma maman.

Dois-je être compatible / déployer sur un produit spécifique en raison du mandat de quelqu'un? N'y a-t-il aucun moyen de les ignorer ou de les convaincre du contraire? Si oui, voici votre réponse.

Dois-je utiliser des EJB? Vraiment? Évitez-les si possible - ils ne sont vraiment nécessaires que pour les très grands systèmes de classe entreprise. Rappelez-vous que ce ne sont que des outils, et des outils importants (quelqu'un peut-il dire "Golden Sledgehammer"?). Ils sont largement surutilisés, alors demandez-vous vraiment si vous en avez besoin. Si vous en avez besoin, cela supprime plusieurs de vos options, y compris ma préférée, Jetty.

Devez-vous utiliser l'une des autres technologies J2EE majeures telles que JMS, ESB, etc.? Si tel est le cas, et vous ne pouvez vraiment pas vous en passer, vous êtes de nouveau contraint à un conteneur J2EE à part entière. Réfléchissez attentivement et étudiez avant de vous engager dans le BPM, par exemple, et évitez AquaLogic BPM à (presque) tout prix - c'est moche à l'extrême.

Si vous devez vraiment utiliser un conteneur J2EE à part entière, envisagez d'abord l'open source car il est plus robuste, mieux pris en charge et plus rentable. Ils ont une plus grande base de clients et une interaction de support plus ouverte, ils ont donc tendance à obtenir de meilleures solutions plus rapidement. Cependant, Resin est immature et je l'éviterais par rapport à GlassFish ou JBoss - j'ai trouvé problématique de déployer et de supporter. Je préférerais JBoss en raison de sa clientèle plus large, de sa maturité, etc. GlassFish est plus difficile à intégrer dans un processus de construction / déploiement automatisé, mais il peut être plus agréable pour certaines de ses fonctionnalités spécifiques (si vous en avez besoin).

Ai-je une raison particulière pour avoir besoin d'Apache? Puis penchez-vous vers Tomcat, peut-être plus quelque chose.

Puis-je me contenter de servlets uniquement? Ensuite, j'utiliserais Jetty - c'est la solution la plus légère, la plus rapide, la plus simple et la plus flexible. Si je suis contre la possibilité d'utiliser Jetty, je remettrais en question toutes mes hypothèses sur le pourquoi. YAGNI s'applique.

Le mieux est d'utiliser StringTemplate / WebStringTemplate sur Jetty: une solution propre, robuste, rapide et maintenable sans frais de licence, une solide réputation et un support solide, etc. C'est là que je commence aujourd'hui.

La plupart des applications / systèmes choisissent de nombreuses fonctionnalités J2EE sophistiquées alors qu'elles n'ont vraiment besoin que de servlets et de JDBC avec une architecture / conception décente. Demandez pourquoi vous pensez avoir besoin de plus.

Parmi les conteneurs à part entière, j'éviterais WebLogic et WebSphere à moins que vous ne preniez en charge un site Web public MAJEUR (le site Web de mon employeur actuel est déployé sur WebLogic et il obtient onze + millions de visites par mois, d'autres ont été comparables). La véritable prétention à la renommée de WebLogic est son clustering relativement facile, mais évite ses fonctionnalités propriétaires de verrouillage du fournisseur à (presque) tout prix. WebSphere est simplement un cauchemar que j'éviterais littéralement à tout prix - je refuse de faire des projets impliquant WebSphere après en avoir fait quelques-uns dans le passé. Aucun des deux produits ne vaut les frais de licence massifs, à moins que vous n'ayez vraiment un besoin particulier qui entraîne l'utilisation d'une fonctionnalité propriétaire. En une décennie en tant qu'architecte / ingénieur senior pour de nombreuses entreprises Fortune 500, je n'ai pas encore vu un tel besoin. D'autre part,

Même pour les sites Web publics très volumineux et à fort trafic, les produits propriétaires sont toujours discutables. Je préfère dépenser plusieurs millions de dollars par an de frais de licence sur du bon matériel et du temps de qualité avec une poignée de très bons consultants pour aborder une solution d'évolutivité simple. Les millions supplémentaires par an pourraient ensuite être utilisés pour produire quelque chose qui mérite d'être vendu sur ce joli site Web ...

EDIT: une autre pièce à considérer ...

J'ai récemment rencontré Terracotta . Je repense tout et cherche à le déployer prochainement dans un système important. En particulier, Terracotta fait le clustering mieux que toute autre chose, je ne recommanderais donc PLUS WebLogic pour son clustering.


7
Pour référence future, vous pouvez généralement trouver les définitions des acronymes via une recherche Google ou Wikipedia. YAGNI = Vous n'en aurez pas besoin = n'en faites pas trop JMS = Java Message Service ESB = Enterprise Service Bus BPM = Business Process Management
Rob Williams

21
Vos commentaires sur Java EE et EJB sont un peu dépassés. J2EE?! C'était il y a 5 ans. Jetez un œil à Java EE 6 et modernisez votre perspective!
Brian Leathem

6
@Brian: Je suis d'accord avec Brian, en particulier avec EJBLite, il est devenu beaucoup plus léger.
Thang Pham

7
@Brian, regardez le post - il a été écrit trois ans avant votre commentaire. Et je dirais toujours que Spring est plus léger que même un Java EE allégé.
duffymo

2
Quel est le verdict maintenant en 2012? JBoss 7 AS devient-il roi de Glassfish dans le royaume de Java 6 EE? Ou l'inverse?
Rolando

10

Le terme «serveur d'applications» est ambigu. Avec GlassFish v3, vous pouvez commencer petit avec, par exemple, un conteneur Web traditionnel et évoluer (en utilisant OSGi et une simple fonctionnalité «ajouter un conteneur») pour ajouter tout ce que vous voulez: JPA, JAX-RS, EJB, JTA, JMS, ESB , etc ... Pourtant, c'est le même produit, la même interface d'administration, etc. Est-ce que cela vous qualifie de serveur d'application? -Alexis (soleil)


1
Malheureusement Glassfish n'est plus un produit officiel, mais "seulement" l'implémentation de référence.
Thorbjørn Ravn Andersen

9

La première question que je me pose habituellement est "Puis-je faire ça avec Tomcat?". Si la réponse est non parce que j'ai besoin de JMS ou JTA, alors je recourt à un serveur d'applications.

J'ai utilisé WebLogic 8 il y a environ 3 ans, satisfait de la facilité d'utilisation de WebLogic et du modèle de licence / coût. Nous l'avons utilisé pour deux projets, l'un était un service Web et l'autre un portail. Nous n'avons rencontré aucun problème avec WebLogic ou WebLogic Portal dans l'un ou l'autre de ces projets.

Ces deux dernières années, je travaillais avec WebSphere. Chaque fois que je négociais avec IBM, cela coûtait toujours deux fois plus cher qu'un équivalent WebLogic, mais la politique d'entreprise dictée par WebSphere devait être utilisée. J'ai trouvé que la courbe d'apprentissage sur WebSphere était considérablement plus raide que WebLogic et que notre cycle de vie de construction / déploiement / test prenait tellement de temps que nous avons utilisé Tomcat dans l'environnement de développement. Mais le plus gros problème que j'ai eu avec WebSphere a été lorsque nous avons rencontré un bogue qui nous a forcé à passer à la prochaine version du correctif uniquement pour rencontrer un nouveau problème d'analyse de web.xml. Il a fallu un quart de travail de 48 heures pour résoudre tout cela.

Pour le moment, j'utilise JBoss. Il y a environ 3 mois, j'étais sur le point de me lancer dans mon nouveau projet avec Tomcat et Jetspeed 2, mais j'ai remarqué que Jetspeed 2 semble un peu stagnant en ce moment et que JBoss Portal 2.7.0 vient de sortir avec le support JSR 286 / Portlet 2.0. J'ai fait un tour à JBoss et je l'ai trouvé très facile à configurer et à administrer. Le cycle de construction / déploiement / test est très rapide et je dois rarement redémarrer le serveur à moins d'avoir changé un fichier XML Spring quelque part.


Bonne réponse! Avez-vous essayé Jetty? Et quelle est votre opinion là-dessus au cas où vous l'auriez fait?

7

J'utilise jBoss depuis 3-4 ans.

Arguments pour jBoss:

  1. Open source.
  2. Support commercial disponible.
  3. Grande communauté d'utilisateurs active.

Arguments contre jBoss:

  1. Aucune version de conteneur Java EE 5 prise en charge à accès général.
  2. Beaucoup de documentation mais verbeuse; peut être difficile de trouver les réponses à "Comment faire x?"
  3. Les outils administratifs pour 4.x sont médiocres par rapport aux autres offres commerciales.

"Aucune version de conteneur JEE 5 prise en charge à accès général." Je suppose que ce n'est plus le cas, n'est-ce pas?
Raedwald

@Raedwald: oui, maintenant que JEE 6 existe depuis un certain temps ;-)
ymajoros


3

Un autre point qui n'a pas été abordé ici est la performance. Si cela pose problème en raison du type de service ou du nombre d'utilisateurs, alors ce qui suit sera applicable:

  • Tomcat semble être plus lent que Glassfish
  • Glassfish semble être plus lent que Resin
  • La résine est beaucoup plus lente que G-WAN + Java

Notez que G-WAN repose uniquement sur la JVM: il n'utilise aucun autre conteneur (sauf indication explicite), vous pouvez donc le réserver à des parties critiques de performances de vos applications Web.

Comme G-WAN prend en charge d'autres langages (C, C ++, C #, D, Objective-C), vous pouvez même traiter certaines parties des applications en C brut tout en conservant Java pour d'autres tâches.


2

Je pourrais inclure votre système d'exploitation préféré comme critère de décision. Cela devrait faciliter la prise en charge si vous utilisez le même fournisseur pour le système d'exploitation et le serveur d'applications. Si vous avez déjà une relation avec l'un ou les deux fournisseurs, demandez-vous s'ils sont bons à traiter.

D'un point de vue technique, je choisirais GlassFish car il prend en charge des innovations plus récentes. Je ne pense pas que JBoss soit mauvais de toute façon, il n'est tout simplement pas aussi à jour.

La plupart de mon expérience est sur WebLogic mais j'ai utilisé JBoss et GlassFish. Je viens de publier un nouveau site sur une pile open source Sun complète (OpenSolaris, GlassFish, MySQL) et ce fut une expérience formidable avec seulement des frustrations mineures.


Le système d'exploitation n'est pas vraiment un problème, sauf si vous avez des dépendances binaires très spécifiques (ce qui ne devrait pas être le cas pour la plupart des projets java). Nous développons sur windows, 32 et 64 bits, et déployons sur Glassfish sur Solaris. La plupart des développeurs ne savent pas vraiment et ne doivent pas s'en soucier. Les utilisateurs ne le voient pas (la plupart de nos développements étant des applications Web).
ymajoros le

2

Je pense toujours que WebLogic est le meilleur serveur d'applications Java EE du marché. Je pense que cela en vaut la peine si vous pouvez vous permettre ces frais de licence.

J'ai été surpris de voir jusqu'où vous pouvez aller en combinant Tomcat, OpenEJB et ActiveMQ. Cela me semble être une alternative peu coûteuse.

Je me pencherai également sur le serveur Spring dm. Il est basé sur Tomcat, mais je pense que la pièce OSGi qu'ils ont ajoutée pourrait être partout en peu de temps. Si c'est fait avec la même qualité que le framework Spring, ce sera vraiment très bien.


2
Le problème que j'ai avec WebLogic est le verrouillage du fournisseur, c'est une pilule méchante à avaler quand vous n'en avez vraiment pas besoin!
Manius

1
C'est vrai pour tous les fournisseurs Java EE que je connais, pas seulement WebLogic. Si vous utilisez des fonctionnalités spécifiques à un fournisseur, vous êtes verrouillé. Il faut parfois écrire du code.
duffymo

3
WebLogic est uniquement commercial - c'est ce que je veux dire - une fois que vous écrivez un gros chèque, vous êtes plus "verrouillé" que vous ne l'êtes avec une alternative open source. De toute évidence, si vous vous souciez de l'indépendance de la plate-forme, vous n'utiliserez pas les fonctionnalités spécifiques du fournisseur, ce n'est donc pas ce à quoi je fais référence. En fait, une enquête que j'ai lue une fois a déclaré que les développeurs pensaient que le blocage des fournisseurs dans l'évitement est l'avantage n ° 1 de l'open source (et non le coût).
Manius

Un non-sens complet? Pensez-vous que la signature d'un contrat de plusieurs millions de dollars avec un fournisseur ne vous enferme pas ? Voilà votre preuve.
duffymo

@ymajoros Vouliez-vous dire "ne devrait pas" avoir le verrouillage des fournisseurs? Franchement, je ne comprends pas votre commentaire.
Patrick M

1

Une alternative: n'utilisez pas du tout de serveur d'applications.

Check-out http://www.atomikos.com/Publications/J2eeWithoutApplicationServer .

Pour les projets Web, conservez un conteneur Web léger si nécessaire, combiné à quelque chose comme Wicket pour éviter la complexité de JSP / JSF ou des struts.

HTH Guy


Si vous ne voulez pas apprendre à utiliser des outils, n'en utilisez pas. Ou essayez de devenir un professionnel qualifié et investissez dans votre environnement, vous serez récompensé. Je dois admettre que j'ai fait ça pour certains projets. Les mêmes projets ont évolué sans serveur d'applications, vers un client-serveur personnalisé au printemps, vers Java EE et Glassfish purs. Je ne voudrais jamais revenir en arrière, la première solution était en fait beaucoup trop complexe, elle est aussi simple que possible aujourd'hui (et standard, se déploierait sur n'importe quel serveur d'application Java EE sans beaucoup de changement).
ymajoros

bonne réponse, mauvaise façon d'obtenir le document
msangel
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.