Utiliseriez-vous actuellement JBoss ou Glassfish (ou un autre) comme serveur Java EE pour un nouveau projet? [fermé]
Si vous avez commencé un nouveau projet Java EE aujourd'hui qui doit être terminé dans environ un an, quel serveur d'applications choisiriez-vous et pourquoi?
Une partie de votre réponse devrait inclure vos arguments pour votre décision. Et aussi combien d'expérience vous avez avec le serveur Java EE que vous choisissez et avec les autres serveurs disponibles sur le marché. Ceux-ci sont intéressants car nous avons tous une idée de l'enquête et de la pensée qui a été mise dans votre réponse.
9 réponses
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 Est que je refuserais complètement d'utiliser JSPs à 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? Il n'y a pas moyen de les ignorer ou de les convaincre du contraire? Si oui, il y a votre réponse.
Dois-je utiliser des EJB? Vrai? Évitez-les si possible-ils ne sont vraiment nécessaires que pour de très grands systèmes de classe entreprise. Rappelez-vous qu'ils ne sont que des outils, et les grands à cela (quelqu'un peut-il dire "marteau D'or"?). Ils sont fortement surutilisés, alors vraiment, vraiment question de savoir si vous en avez besoin. Si vous en avez besoin, cela supprime plusieurs de vos options, y compris mon préféré, Jetty.
Devez-vous utiliser l'un des autres majeurs Les technologies J2EE comme JMS, ESB, etc? Si oui, et vous ne pouvez vraiment pas vous en passer, alors vous êtes à nouveau contraint à un conteneur J2EE complet. Réfléchissez bien et étudiez avant de vous engager à BPM, par exemple, et évitez les BPM Aqualogiques à (presque) tous les coûts-c'est moche à l'extrême.
Si vous devez vraiment utiliser un conteneur J2EE complet, envisagez d'abord l'open-source car il est plus robuste, mieux supporté et plus rentable. Ils ont des bases de clients plus grandes et plus ouvertes soutenir l'interaction, de sorte qu'ils ont tendance à obtenir de meilleures corrections plus rapidement. Cependant, la résine est immature et je l'éviterais par rapport à GlassFish ou JBoss-j'ai trouvé problématique de déployer et de soutenir. 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 pourrait être plus agréable pour certaines de ses fonctionnalités spécifiques (si vous en avez besoin).
Ai-je une raison particulière d'avoir besoin D'Apache? Puis penchez vous vers Tomcat, peut-être quelque chose de plus.
Puis-je me contenter de servlets? Ensuite, j'utiliserais Jetty-c'est la solution la plus légère, la plus rapide, la plus facile et la plus flexible. Si je suis penché contre être en mesure d'utiliser Jetty, je remettrais en question toutes mes hypothèses de pourquoi. YAGNI s'applique.
Le mieux est d'utiliser StringTemplate / WebStringTemplate sur Jetty: une solution propre, robuste, rapide et maintenable sans frais de licence, solide réputation et support, etc. C'est là que je commence aujourd'hui.
Plus les applications / systèmes choisissent beaucoup de fonctionnalités J2EE de fantaisie quand tout ce dont ils ont vraiment besoin est servlets et JDBC avec une architecture/conception décente. Question pourquoi vous pensez que vous avez besoin de plus.
Parmi les conteneurs à part entière, j'éviterais WebLogic et WebSphere à moins que vous ne souteniez 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 leur relativement facile clustering, mais évitez leurs 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 avoir fait un couple dans le passé. Aucun des deux produits ne vaut les frais de licence massifs, sauf si vous avez vraiment un besoin particulier qui entraîne l'utilisation d'une fonctionnalité propriétaire. En une décennie en tant qu'architecte/ingénieur principal pour beaucoup de sociétés Fortune 500, Je n'ai pas encore vu un tel besoin. Sur d'autre part, j'ai vu beaucoup de douleur en raison de la cueillette de ces produits exclusifs.
Même pour les sites Web publics très volumineux et très fréquentés, les produits propriétaires sont encore discutables. Je préférerais dépenser plusieurs millions de dollars par an de frais de licence sur un bon matériel et du temps de qualité d'une poignée de très bons consultants pour aborder une solution d'évolutivité simple. Les millions supplémentaires par an pourraient alors être utilisés pour produire quelque chose digne de vente sur que beau site...
EDIT: une autre pièce à considérer...
J'ai récemment rencontré en terre Cuite. Je repense tout, et cherche à le déployer dans un système important bientôt. En particulier, Terracotta fait le clustering mieux que toute autre chose, donc je ne recommanderais plus WebLogic pour son clustering.
Le terme "serveur d'applications" est ambigu. Avec GlassFish v3, vous pouvez commencer petit avec, disons, un conteneur Web traditionnel et évoluer (en utilisant OSGi et la fonctionnalité simple "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 admissible en tant que serveur d'applications pour vous? - Alexis (Soleil)
La première question que je me pose habituellement est "Puis-je faire cela avec Tomcat?". Si la réponse est non parce que j'ai besoin de JMS ou de JTA, j'ai recours à 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 avons utilisé pour cela deux projets, l'un était un service web et l'autre était un portail. Nous n'avons rencontré aucun problème avec WebLogic ou Weblogic Portal dans l'un ou l'autre de ces projets.
Pendant les deux dernières années, j'étais travailler 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 dictait WebSphere. J'ai trouvé la courbe d'apprentissage sur WebSphere beaucoup plus raide que WebLogic et 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 était quand nous avons rencontré un bug qui nous a forcés à passer au patch suivant relâchez seulement pour rencontrer un nouveau problème d'analyse web.XML. Il a fallu un quart de travail de 48 heures pour travailler à travers 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 semblait un peu stagnant en ce moment et que JBoss Portal 2.7.0 venait de sortir avec le support JSR 286/Portlet 2.0. J'ai donné un spin à JBoss et je l'ai trouvé très facile à mettre en place et à administrer. Le cycle build / deploy / test est très rapide et j'ai rarement je dois redémarrer le serveur sauf si j'ai changé un fichier XML Spring quelque part.
J'utilise jBoss depuis 3-4 ans.
Arguments pour jBoss:
- Open source.
- soutien Commercial disponible.
- grande communauté d'utilisateurs active.
Arguments contre jBoss:
- Pas d'Accès Général, pris en charge la version du conteneur Java EE 5.
- beaucoup de documentation mais verbeux; peut être difficile de trouver les réponses à " Comment puis-je faire x?"
- outils D'administration pour 4.x pauvres par rapport aux autres offres commerciales.
Commander GlassFish 3.1! Construit sur le noyau modulaire Glassfish V3 basé sur Java EE 6, la version 3.1 offre un clustering, une administration centralisée et une haute disponibilité.
Se Référer à http://blogs.oracle.com/nazrul/entry/glassfish_3_1 pour plus de détails.
Un autre point qui n'a pas été discuté ici est la performance. S'il s'agit d'une préoccupation 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: elle n'utilise aucun autre conteneur (sauf indication explicite), vous pouvez donc le réserver aux parties critiques des 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.
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 OS et app server. Si vous avez déjà une relation avec un ou les deux fournisseurs considèrent si elles sont bonnes à traiter.
D'un point de vue technique, je choisirais GlassFish car il supporte 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 je 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 grande expérience avec seulement des frustrations mineures.
Je pense toujours que WebLogic est le meilleur serveur D'applications Java EE sur le marché. Je pense que ça vaut le coup 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. Qui me semble être une alternative peu coûteuse.
Je voudrais aussi regarder dans 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 dans un court laps de temps. Si c'est fait avec la même qualité que le Cadre de printemps, ce sera très bon en effet.
Une alternative: n'utilisez aucun appserver.
Découvrez http://www.atomikos.com/Publications/J2eeWithoutApplicationServer.
Pour les projets web, gardez un conteneur Web léger si vous le devez, combiné avec quelque chose comme Wicket pour éviter la complexité de JSP / JSF ou struts.
HTH Guy