Application Java EE avec Serveur Web + Serveur d'applications
Est-il nécessaire qu'une application Java EE dispose de serveurs Web tels que SUN Java Web Server pour gérer la demande de servlet/jsp et la transférer vers des serveurs d'applications tels que IBM WebSphere ou BEA WebLogic?
Puisque les serveurs d'applications sont également capables de gérer de tels servlets/jsp?
Quels sont les avantages / inconvénients d'une telle architecture de serveur?
3 answers
Apache Tomcat, Jetty et Sun Java System Web Server ne sont que des conteneurs Java Web (Servlet), ce qui signifie qu'ils ne peuvent exécuter que des Servlets/JSP - ils ne fournissent pas la pile d'API Java EE complète.
En tant que tel, ils ne peuvent déployer que des fichiers .war, pas .ear (qui inclurait également des modules .jar avec EJBs), et ne prennent pas en charge certaines API Java EE prêtes à l'emploi comme JSF ou CDI. ou d'autres fonctionnalités/API. Il est important de noter que, puisque Java EE6, .war les fichiers peuvent contenir des EJB. Plus d'infos sur les différences à propos de .war et .ear.
Chaque serveur Java EE a un conteneur Web + conteneur EJB.
(Vous pouvez voir ici et ici que Tomcat et Jetty ne prétendent pas être des serveurs JavaEE, juste des conteneurs servlet (web).)
JBoss Application Server utilise JbossWeb (Apache Tomcat fourche) en tant que conteneur web. Son conteneur EJB est, eh bien, JBoss (ils ne le font pas avoir un nom distinct autre que "JBoss EJB Container" pour cela).
Les autres (IBM WebSphere, Oracle/BEA WebLogic, TomEE, Glassfish) ont également leur conteneur web + conteneur EJB.
TomEE utilise évidemment Apache Tomcat comme conteneur Web. Glassfish utilise également un Apache Tomcat fourche. (Oui, Apache Tomcat semble être très populaire:)
Dans la discussion ci-dessous, vous pouvez changer Tomcat avec "Conteneur Web" et JBoss avec "Serveur Java EE entièrement capable" chaque fois qu'ils apparaître. (J'ai utilisé les noms du produit pour plus de clarté.)
Image: Serveur et conteneurs Java EE-Source: Le tutoriel Java EE.
Quels sont les (dés)avantages d'avoir des serveurs Web Java (tels que Tomcat) qui gèrent les appels Servlet/JSP et qui transfèrent des requêtes plus complexes vers des serveurs d'applications tels que JBoss (ou IBM WebSphere ou BEA WebLogic)?
À partir d'une fonctionnalité stantdpoint, il n'y a pas de gain effectif
Si vous placez un Tomcat avant un JBoss, ce que vous faites réellement est de mettre un Tomcat avant un JBossWeb (conteneur web, donc l'entrée de chaque application Web) qui sera toujours avant le conteneur EJB de JBoss. Si nous parlons de fonctionnalité, c'est juste redondant, car nous avons le même service fourni deux fois.
Implémenteurs de commutation ou capacités de clustering
Placer un Tomcat avant un JBoss peut avoir du sens s'ils utilisent JBoss pour son conteneur EJB uniquement: le choix ici serait donc un simple commutateur dans l'implémenteur du conteneur Web.
De plus, si le Tomcat se trouvait sur un nœud réseau différent (ou plus d'un Tomcat/nœud), les capacités de clustering pourraient être appliquées (ce qui ne pourrait pas être le cas sinon, car JBossWeb et JBoss sont généralement traités comme un et vont donc dans la même machine).
Traitement des problèmes de contenu statique et de sécurité
Qu'est-Ce que très commune est placer un serveur web (comme Apache HTTPD ou IIS) avant le conteneur Web Java. Il y a deux motivations principales à cela:
- Faites en sorte que HTTPD serve le contenu statique (comme les images) et transférez le reste au conteneur Web Java. Ceci est fait parce que les serveurs Web sont généralement mieux optimisés pour fournir du contenu statique.
- Sécurité: Exposer uniquement le HTTPD dans la DMZ . On peut configurer un Apache HTTPD à la DMZ, et le faire simplement avancer tout dans les conteneurs Web (Tomcats, etc.) et les serveurs JavaEE (JBosses, etc.).
Si l'on veut plus de sécurité, il est inutile d'utiliser un conteneur web dans la DMZ: S'il sert des applications (c'est-à-dire que des fichiers .war y sont déployés), les applications sont toujours "vulnérables"; s'il ne fait que transférer des requêtes/réponses, alors un Apache HTTPD est une bien meilleure option!
Il s'agit d'un serveur Web Java, d'IBM WebSphere Application Server, de WebLogic, de JBoss Application Server, de Tomcat, de Jetty... Ils sont tous Serveurs d'applications Web Java et font la même chose - exécutez votre application packagée WAR ou EAR (EAR est pour "Enterprise", contient 1+ WARs).
Si vous avez deux serveurs dans votre configuration pour exécuter une application, il est probable que quelque chose ne va pas dans votre stratégie/conception de déploiement.
Il existe des cas de configurations multi-serveurs mais ceux-ci sont généralement configurations d'équilibrage de charge et de proxy qui ont le serveur HTTP Apache devant votre serveur d'applications Java.
Par exemple, vous avez un Tomcat servant votre application sur le port 8080 et vous souhaitez utiliser http://myserver.com/myapp/ au lieu de http://myserver.com:8080/myapp/. Vous ne pouvez pas le faire avec Tomcat seul car Java ne peut pas aller en dessous du port 1024 (*). Pour cela, vous devez configurer le Serveur HTTP Apache sur le port 80 et configurer son mod_proxy pour rediriger tout le trafic de /myapp à http://myserver.com:8080/myapp.
*: Je ne me souviens pas du nombre exact mais c'est autour de 1024. Et cela est vrai pour Linux, mais peut-être pas pour Windows, cela fait un moment que j'ai utilisé une configuration Windows.
MISE À JOUR: Mon mauvais, j'ai oublié de souligner la partie "exécuter en tant que service système" comme décrit ici.
Eh bien, puisque les serveurs d'applications contiennent déjà un conteneur de servlet sur la carte, avoir un serveur Web de plus qui gère les requêtes http entrantes est redondant.
Cependant, une fois que j'ai travaillé sur le projet, où ces couches ont été séparées. Nous avions un cluster de serveurs JBoss et un cluster séparé de serveurs Tomcat. Tomcat invoquait JBoss via RMI avec équilibrage de charge. Cela a été fait pour la sécurité (les serveurs Jboss étaient à l'intérieur du VPN) et l'évolutivité.