Voulez-vous, à la date actuelle, utiliser JBoss ou Glassfish (ou un autre) comme Java EE pour un nouveau projet?
Si vous démarrez un nouveau Java projet EE aujourd'hui qui doit être achevé 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 Java EE que vous avez choisi et avec les autres serveurs disponibles sur le marché. C’est intéressant car nous avons tous une idée de l’enquête et de la pensée qui a été mise dans votre réponse.
J'ai utilisé WebLogic, WebSphere, JBoss, GlassFish, Resin, Jetty, Tomcat et quelques autres au cours des 10 dernières années. Donc, si je pensais à un nouveau projet, je me poserais d'abord quelques questions. Une chose que je ne mettrais plus en doute, c’est que je refuserais carrément d’utiliser des JSP à moins d’être torturée jusqu’à ce que je pleure pour ma maman.
Dois-je être compatible/déployer avec un produit spécifique en raison du mandat de quelqu'un? N'y a-t-il pas moyen de les ignorer ou de les convaincre du contraire? Si oui, voici votre réponse.
Dois-je utiliser des EJB? Vraiment? Évitez-les autant que possible - ils ne sont vraiment nécessaires que pour les très grands systèmes d'entreprise. Rappelez-vous qu’il ne s’agit que d’outils, voire de gros outils (quelqu’un peut-il dire "Golden Sledgehammer"?). Ils sont fortement surutilisés, alors vraiment, vraiment se demander si vous en avez besoin. Si vous en avez besoin, plusieurs options sont supprimées, notamment Jetty, ma préférée.
Devez-vous utiliser l’une des principales technologies J2EE telles que JMS, ESB, etc.? Si tel est le cas et que vous ne pouvez vraiment pas vous en passer, vous êtes à nouveau contraint par un conteneur J2EE complet. Par exemple, réfléchissez bien et étudiez avant de vous engager dans BPM et évitez AquaLogic BPM à (presque) tous les coûts - c'est moche à l'extrême.
Si vous devez réellement utiliser un conteneur J2EE complet, envisagez d'abord l'open-source, car il est plus robuste, mieux pris en charge et plus économique. Ils ont de plus grandes bases de clients et une interaction de support plus ouverte, ils ont donc tendance à obtenir de meilleurs correctifs plus rapidement. Cependant, Resin est immature et je l’éviterais par rapport à GlassFish ou JBoss - j’ai trouvé qu’il était problématique de se déployer et de prendre en charge. Je préférerais JBoss en raison de sa clientèle plus large, de sa maturité, etc. GlassFish est plus difficile à incorporer dans un processus de construction/déploiement automatisé, mais il pourrait être plus pratique 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 avec quelque chose en plus.
Puis-je me contenter de servlets? J'utiliserais ensuite Jetty - c'est la solution la plus légère, la plus rapide, la plus simple et la plus flexible. Si je suis contre l'utilisation de Jetty, je me demanderais pourquoi. YAGNI s'applique.
Le mieux est d'utiliser StringTemplate/WebStringTemplate sur Jetty: une solution propre, robuste, rapide et facile à gérer, sans aucun frais de licence, sans réputation, sans assistance, 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 besoin que de servlets et de JDBC avec une architecture/conception décente. Vous vous demandez pourquoi vous avez besoin de plus.
Parmi les conteneurs complets, 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 reçoit plus de onze millions de visites par mois, d'autres sont comparables). La véritable revendication de WebLogic réside dans leur mise en cluster relativement facile, mais évitez leurs fonctionnalités exclusives de verrouillage du fournisseur à (presque) tous les coûts. WebSphere est tout simplement un cauchemar que j'éviterais littéralement à tout prix: je refuse de faire des projets impliquant WebSphere après en avoir fait deux ou trois auparavant. Aucun des deux produits ne vaut les énormes droits de licence, sauf si vous avez réellement un besoin particulier qui pousse à utiliser une fonctionnalité exclusive. Au cours des dix dernières années en tant qu’architecte/ingénieur principal dans de nombreuses entreprises du classement Fortune 500, je n’ai pas encore constaté ce besoin. D'autre part, j'ai vu BEAUCOUP de douleur en raison de la sélection de tels produits exclusifs.
Même pour les sites Web publics très volumineux et à fort trafic, les produits propriétaires restent discutables. Je préférerais dépenser ces millions de dollars par an en droits de licence sur du matériel de qualité et du temps de qualité avec une poignée de très bons consultants pour traiter 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 site de Nice ...
EDIT: une autre pièce à considérer ...
J'ai récemment rencontré Terracotta . Je repense tout et cherche à le déployer dans un système significatif 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'application" est ambigu. Avec GlassFish v3, vous pouvez commencer modestement avec, par exemple, un conteneur Web traditionnel et évoluer (en utilisant OSGi et la simple fonctionnalité "ajouter un conteneur") pour ajouter ce que vous souhaitez: JPA, JAX-RS, EJB, JTA, JMS, ESB , etc ... Pourtant, il s’agit du même produit, de la même interface d’administration, etc. Cela constitue-t-il un serveur d’application 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 car j'ai besoin de JMS ou de JTA, 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 aucun 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 de WebLogic, mais la politique de l'entreprise dictait WebSphere. J'ai trouvé que la courbe d'apprentissage sur WebSphere était beaucoup plus abrupte que WebLogic et que notre cycle de vie de génération/déploiement/test prenait tellement de temps que nous avons utilisé Tomcat dans l'environnement de développement. Mais le problème le plus important que j'ai rencontré avec WebSphere est le moment où nous avons rencontré un bogue qui nous a obligés à effectuer la mise à niveau vers la prochaine version du correctif, puis à rencontrer un nouveau problème lors de l'analyse du fichier web.xml. Il a fallu un quart de travail de 48 heures pour résoudre ce problème.
Pour le moment, j'utilise JBoss. Il y a environ 3 mois, j'étais sur le point de lancer mon nouveau projet avec Tomcat et Jetspeed 2. Cependant, j'ai remarqué que Jetspeed 2 semblait un peu stagnant à l'heure actuelle et que JBoss Portal 2.7.0 venait tout juste de sortir avec le support JSR 286/Portlet 2.0. J'ai essayé JBoss et j'ai trouvé qu'il était 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 modifié un fichier XML Spring quelque part.
J'utilise jBoss depuis 3-4 ans.
Arguments pour jBoss:
- Open source.
- Support commercial disponible.
- Grande communauté d'utilisateurs actifs.
Arguments contre jBoss:
- Pas d'accès général, pris en charge Java Version conteneur EE 5.
- Beaucoup de documentation mais verbeuse; peut être difficile de trouver les réponses à "Comment puis-je faire x?"
- Outils d'administration pour 4.x médiocre par rapport à d'autres offres commerciales.
Commander GlassFish 3.1! Construite sur le noyau GlassFish v3 modulaire et basé sur Java basé sur EE 6, la version 3.1 offre une mise en cluster, une administration centralisée et une haute disponibilité.
Reportez-vous à http://blogs.Oracle.com/nazrul/entry/glassfish_3_1 pour plus de détails.
Un autre point qui n’a pas été abordé ici est la performance. Si cela pose un problème en raison du type de service ou du nombre d'utilisateurs, les conditions suivantes seront applicables:
- Tomcat semble être plus lent que Glassfish
- Glassfish semble être plus lent que la résine
- La résine est beaucoup plus lente que G-WAN + Java
Notez que G-WAN repose uniquement sur la machine virtuelle: elle n'utilise aucun autre conteneur (sauf indication explicite) de sorte que vous pouvez le réserver aux parties critiques de vos applications Web en termes de performances.
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 pense toujours que WebLogic est le meilleur Java EE sur le marché. Je pense que cela en vaut la peine si vous pouvez vous permettre de payer ces droits 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 regarderais aussi dans le serveur Spring dm. Il est basé sur Tomcat, mais je pense que l’article OSGi qu’ils ont ajouté pourrait être partout très rapidement. Si c'est fait avec la même qualité que le framework Spring, ce sera très bien.
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 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 les innovations plus récentes. Je ne pense pas que JBoss soit mauvais dans tous les cas, il n’est tout simplement pas aussi à jour.
La plupart de mes expériences sont sur WebLogic, mais j’ai utilisé JBoss et GlassFish. Je viens de publier un nouveau site sur une pile open source complète de Sun (OpenSolaris, GlassFish, MySQL) et ce fut une excellente expérience avec seulement des frustrations mineures.
Une alternative: ne pas utiliser de serveur d'applications du tout.
Départ http://www.atomikos.com/Publications/J2eeWithoutApplicationServer .
Pour les projets Web, conservez si nécessaire un conteneur Web léger, associé à quelque chose comme Wicket pour éviter la complexité de JSP/JSF ou de struts.
HTH Guy