Pourquoi choisir Tomcat sur un serveur d'applications compatible Java EE?
Les serveurs d'applications Java EE fournissent toutes les fonctionnalités de Tomcat. Pourquoi utiliser donc Tomcat (au lieu de glassfish, par exemple, puisqu'il s'agit de la version officielle)?
En particulier lorsque des fonctionnalités Java EE sont nécessaires, telles que JPA, JAX-RS, JSF, et qu’il faut par conséquent un plus grand nombre de bibliothèques avec l’application, alors qu’un serveur d’application compatible EE l’aurait fournie immédiatement?
La question qui nous préoccupait et la raison pour laquelle nous avons créé TomEE était: pourquoi les gens devraient-ils choisir?
L'ensemble "Tomcat ou JavaEE" est fatigué et vieux.
Au bout de 10 ans, le problème se pose toujours et les gens se disputent pour déterminer lequel est le meilleur et pourquoi.
Voici le calcul sous forme abrégée:
- Dans Java EE 6, nous (JCP) avons créé le profil Web afin de reconnaître formellement la nécessité de prévoir des exécutions plus petites avec un ensemble de technologies ciblées.
Génial, nous en sommes à mi-chemin, mais les gens continuent de se disputer "Tomcat ou JavaEE". La solution était claire, Tomcat devait être certifié Java EE. Le profil Web a été créé pour permettre exactement cela _.
- En 2011, nous (Apache) avons commencé à certifier Apache Tomcat. Certification atteinte et annoncée à JavaOne 2011 sous le nom Apache TomEE. La version finale est annoncée en avril.
Génial, nous y sommes maintenant.
Le nouveau statu quo
- Il existe une version allégée de JavaEE
- Il existe une version certifiée JavaEE de Tomcat.
Tout cela s'est passé au cours des 2 dernières années. Les choses ont changé.
Si vous voulez Tomcat et JavaEE, vous pouvez l'avoir.
Rarement, voire jamais, les gens utilisent un Tomcat ordinaire. Ils toujours ajoutent des tonnes de choses supplémentaires, comme un cadre Web, un orme, un cadre DI, etc.
Vous pouvez utiliser Spring pour cela, mais le résultat final sera volumineux et saturé, ce qui vous obligera à utiliser beaucoup de programmation XML.
Les implémentations modernes de Java EE 6 sont très légères (TomEE et Resin ne font que 25 mb) et contiennent tout ce dont vous avez besoin (Web, persistance, DI). Le soi-disant profil Web ne contient aucun élément dont vous n’avez que rarement besoin. Les serveurs modernes Java EE 6 démarrent en une seconde ou deux, ce qui est dans la même ligue qu'un Tomcat nu, mais ils offrent en réalité les outils dont vous avez besoin au quotidien.
La plupart des serveurs d'applications Java EE sont volumineux, dotés de nombreuses fonctionnalités inutiles et d'un cycle de développement/test très lent (il suffit de consulter les rapports de productivité des rebelles Java). Si vous avez vraiment besoin de certaines fonctionnalités Java EE, vous devez l’utiliser, mais vous pouvez généralement disposer des mêmes fonctionnalités de base (conteneur de servlet, essentiellement, vous pouvez placer la plupart des technologies Java EE sur un serveur Tomcat, telles que des fonctionnalités légères). ejb, etc.) avec Tomcat ou tout autre conteneur de servlets léger.
Notez également que vous pouvez utiliser JPA, JSF, JAX-RS en dehors d'un serveur d'applications.
TL; DR: Les serveurs d'applications Java EE sont apparemment lents, ne rechargez pas les classes à la volée et forcent un cycle très irritant/déploiement/test (pensez de 20 à secondes à 8 minutes pour tester certains changements dans votre code Java). La plupart des gens n'ont besoin que des fonctionnalités de base (essentiellement le conteneur de servlets).
Voici un rapport sur les temps de redéploiement à partir de 2011: http://zeroturnaround.com/Java-ee-productivity-report-2011/#redeploy_times
Comme expliqué ci-dessus par @Miguel Ping, les serveurs d'applications contiennent des fonctionnalités dont les développeurs n'ont pas besoin.
Par exemple, de nombreux développeurs n’ont pas besoin de code pour la messagerie et n’ont donc pas besoin des jars JMS.
D'autres développeurs n'ont peut-être pas besoin de clustering, ils n'ont donc pas besoin de code de clustering, etc.
La plupart des interfaces utilisateur étant orientées vers le Web, le conteneur Servlet, qui doit être fourni par les serveurs d'applications, devient de plus en plus un composant crucial. C'est pourquoi de nombreux développeurs décident d'utiliser UNIQUEMENT un conteneur Servlet (i.e-Tomcat).
Dans ce cas, de nombreux développeurs utilisent Spring pour remplacer les fonctionnalités qu’ils utilisent avec Java EE (ou pour l’intégration avec Java EE - Spring peut également être exécuté sur le serveur d’applications).
Spring-core est un lightware et fournit principalement un conteneur Depdency Injection/Inversion-Of-Control (remplaçant le conteneur EJB de Java EE).
Vous pouvez ajouter d’autres modules du framework Spring pour apporter plus de fonctionnalités à votre application. Tandis que dans de nombreux serveurs d’applications (ceux d’EJB 3.0 et inférieurs), le serveur d’application charge toute la pile, ce qui affecte également le temps de veille du serveur d’applications. (et c'est assez énervant pour les développeurs, par expérience personnelle).
Cela étant dit, EJB 3.1 contient maintenant des profils, par exemple, le profil Web, qui charge un plus petit nombre de pièces à partir de la spécification Java EE. En outre, Jboss a introduit dans JBoss AS 7 un mécanisme de déploiement parallèle qui analyse les dépendances au sein d’une application et effectue un déploiement parallèle de composants indépendants.
Par exemple, dans le projet oVirt open source, nous avons réduit le temps de démarrage de plus d’une minute pour un simple déploiement d’un environnement de virtualisation à environ 3 secondes.
Je ne sais pas si un tel mécanisme existe dans d'autres serveurs d'applications EJB 3.1. Toutefois, comme mentionné précédemment, vous pouvez définir des profils assez facilement ou utiliser des profils existants, tels que profil Web (EJB lite) in order réduire le temps de démarrage
Pour conclure, Dans le passé, Tomcat était principalement utilisé pour réduire le temps de démarrage et le nombre de modules chargés.
Spring a présenté une alternative modulaire au développement Java EE et peut être utilisé avec Tomcat.
. Aujourd'hui, avec EJB 3.1, Java EE a également pris en charge la modularisation et il existe des serveurs d'applications tels que JBoss AS 7 qui réduisent le temps de démarrage à quelques secondes en raison de toutes les optimisations apportées lors du déploiement.
Tomcat est un conteneur de servlets léger et bien écrit qui fait tout ce qui est nécessaire pour un grand nombre d'applications Web JVM. Cela fonctionne bien en production en tant que serveur Web parlant directement au navigateur. Pour beaucoup de gens, Java EE contient trop de choses, plus que nécessaire pour créer des applications utiles et stables. Ce type de personne recherche des outils qui ont moins, pas plus, et valorise le code bien écrit stable au-dessus des fonctionnalités. Le monde du choix des logiciels est un marché, et Tomcat sert très bien une partie de ce marché. Comme dans tout marché, vous devez examiner les solutions de rechange et choisir celles qui répondent à vos besoins. Tomcat est l'une des nombreuses alternatives.
Il existe un point de vue intéressant sur Tomcat dans cet article http://www.people.hbs.edu/cbaldwin/DR2/LaMantia-Cai-MacCormack-Rusnak%20WICSA2008.pdf Sur les matrices de structure de conception. Ils le comparent à un concurrent anonyme et le trouvent bien conçu. Si vous êtes intéressé par l'analyse de votre propre code, la seule implémentation DSM que je sache est l'édition IntelliJ Enterprise, mais elle vous offre une période d'essai gratuite de quelques semaines.
Personnellement, j'estime que la simplicité est une vertu du logiciel de support et que le conteneur de servlets est un logiciel de support et non une partie de votre application.
Dans la plupart des cas, les décisions relatives à la sélection des serveurs d'applications (Tomcat ou AS, comme JBoss) seront prises en fonction de l'expérience et des connaissances de l'équipe d'administration/de développement des petits départements informatiques et de l'OMI, c'est une question politique que technique . , les projets qui sont tout au plus déployés sur Tomcat sont souvent des applications Web avec peu de concepts d’intégration et de complexité. Des conteneurs légers et des frameworks (Spring, Struts) sont souvent utilisés.Mais si les projets deviennent compliqués et plus distribués, les attributs tels que la scalabilité, le "suivi", la haute disponibilité (comme @HASingletons de JBoss), etc. en place. Et il peut alors être très pénible d'équiper votre Tomcat ordinaire de structures tierces afin de tirer parti de toutes les fonctionnalités d'AS. La plupart du temps, vous aurez du défi à relever pour les exploiter toutes ensemble.
Ils pensent choisir la légèreté, mais au final, leurs applications seront beaucoup plus lourdes qu’elles utiliseraient le profil Web Java EE. S'ils optent pour Spring, leurs déploiements seront probablement très volumineux, avec des délais de création et de démarrage du serveur plus lents. La productivité des développeurs diminue ... Si vous souhaitez que votre application soit aussi simple et légère que possible, optez pour un serveur Java EE prenant en charge le profil Web.