Application Java EE avec Web Server + Application Server
Une application Java EE doit-elle disposer de serveurs Web tels que Sun Java Web Server pour gérer la demande servlet/jsp et les transmettre à des serveurs d'applications tels que IBM WebSphere ou BEA WebLogic?
Étant donné que les serveurs d'applications sont capables de gérer de tels servlets/jsp?
Quels sont les avantages/inconvénients d'une telle architecture de serveur?
Apache Tomcat , Jetty et Serveur Web Sun Java System ne sont que des conteneurs Java Web (Servlet), ce qui signifie qu'ils ne peuvent exécuter que des Servlets/JSP. fournir la pile complète d'API Java EE.
En tant que tels, ils ne peuvent déployer que des fichiers .war, pas .ear (qui incluraient également des modules .jar avec des EJB), et ne prennent pas en charge certaines API Java EE telles que JSF ou CDI. ou d'autres fonctionnalités/API. Il est important de noter que, depuis Java EE6, les fichiers .war peuvent contenir des EJB . Plus d'informations sur les différences entre .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 pour être des serveurs JavaEE, juste des conteneurs servlet (web).)
JBoss Application Server utilise JbossWeb (un fork Apache Tomcat) comme conteneur Web. Son conteneur EJB est, eh bien, JBoss (ils n’ont pas de nom distinct à part "JBoss EJB Container").
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 une fourche Apache Tomcat. (Oui, Apache Tomcat semble être très populaire :)
Dans la discussion ci-dessous, vous pouvez modifier Tomcat avec "Conteneur Web" et JBoss avec "Serveur Java EE entièrement compatible" à chaque fois qu'ils apparaissent. (J'ai utilisé les noms du produit pour plus de clarté.)
Image: Serveur Java EE et conteneurs - Source: didacticiel Java EE.
Quels sont les avantages ou désavantages d'avoir des serveurs Web Java (tels que Tomcat) qui gèrent les appels Servlet/JSP et transmettent des demandes plus complexes à 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, vous placez un Tomcat avant un JBossWeb (conteneur Web, donnant ainsi accès à toutes les applications Web), qui sera toujours avant. le conteneur EJB de JBoss. Si nous parlons de fonctionnalité, c'est simplement redondant, car le même service est fourni deux fois.
Commutation des implémenteurs ou des capacités de clustering
Placer un Tomcat avant un JBoss peut avoir un sens s'il utilise JBoss uniquement pour son conteneur EJB: le choix ici serait donc un simple commutateur dans l'implémenteur du conteneur Web.
De même, si le Tomcat se trouvait sur un nœud de réseau différent (ou sur plusieurs nœuds/nœuds Tomcat), des fonctionnalités de clustering pourraient être appliquées (ce qui ne pourrait pas autrement, car JBossWeb et JBoss sont généralement traités comme un et vont donc sur le même ordinateur). .
Traitement du contenu statique et des problèmes de sécurité
Qu'est-ce que very common est placer un serveur Web (tel qu'Apache HTTPD ou IIS) avant le conteneur Web Java . Il y a deux motivations principales à cela:
- Permet à HTTPD de servir le contenu statique (tel que des images) et de transférer le reste au conteneur Web Java. Cela est dû au fait que les serveurs Web sont généralement mieux optimisés pour la fourniture de contenu statique.
- Sécurité: Exposez uniquement le HTTPD dans le DMZ . Il est possible de configurer un HTTPD Apache au niveau de la zone démilitarisée et de le transférer simplement vers les conteneurs Web (Tomcats, etc.) et les serveurs JavaEE (JBosses, etc.).
Si vous souhaitez renforcer la sécurité, il n’est pas utile d’utiliser un conteneur Web dans la zone démilitarisée: s’il dessert 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 demandes/réponses, un HTTPD Apache est une bien meilleure option!
Serveur Web Java Sun, Serveur d'applications Web IBM, WebLogic, Serveur d'applications JBoss, Tomcat, Jetty ... Ils sont tous Serveurs d'applications Web Java et font la même chose - exécutez votre application packée WAR ou EAR (EAR est pour "Enterprise", contient 1+ WAR).
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 il s'agit généralement de configurations d'équilibrage de charge et de proxy avec Apache HTTP Server devant votre serveur d'applications Java.
Par exemple, vous avez un Tomcat qui dessert 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 faire cela avec Tomcat seul car Java ne peut pas aller au-dessous du port 1024 (*). Pour cela, vous devez configurer Apache HTTP Server 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 il se situe autour de 1024. Et ceci est vrai pour Linux, mais peut-être pas pour Windows, cela fait longtemps que je n'ai pas utilisé d'installation Windows.
UPDATE: Mon mal, j'ai oublié d'insister sur la partie "exécuter en tant que service système" telle que décrite ici .
Eh bien, puisque les serveurs d’applications contiennent déjà le conteneur de servlet sur la carte, il est redondant d’avoir un serveur Web supplémentaire qui gère les demandes HTTP entrantes.
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 appelait JBoss via RMI avec un équilibrage de charge. C'était fait pour la sécurité (les serveurs Jboss étaient à l'intérieur d'un VPN) et l'évolutivité.