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:
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.
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)
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.
J'utilise jBoss depuis 3-4 ans.
Arguments pour jBoss:
Arguments contre jBoss:
Commander GlassFish 3.1! Basée sur le noyau modulaire GlassFish v3 basé sur Java EE 6, la version 3.1 offre la mise en cluster, l'administration centralisée et la 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 problème en raison du type de service ou du nombre d'utilisateurs, alors ce qui suit sera applicable:
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.
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.
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.
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