Ответ 1
Apache Tomcat, Jetty и Веб-сервер Sun Java System - это только контейнеры Java Web (Servlet), что означает, что они могут выполнять только сервлеты /JSP - они не предоставляют полный стек API Java EE.
Таким образом, они могут развертывать только файлы .war, а не .ear (которые также включают в себя модули .jar с EJB), и не поддерживают из-за этого некоторые API Java EE, такие как JSF или CDI. или других функциональных возможностей /API. Важно отметить, что поскольку файлы Java EE6, .war могут содержать EJB. Подробнее о различиях в .war и .ear.
Каждый сервер Java EE имеет контейнер Web Container + EJB Container.
(Здесь вы можете увидеть здесь и здесь, что Tomcat и Jetty не претендует на роль серверов JavaEE, а только контейнеров сервлетов (web).)
Сервер приложений JBoss использует JbossWeb (вилка Apache Tomcat) в качестве своего веб-контейнера. Его контейнер EJB, ну, JBoss (у них нет отдельного имени, кроме "JBoss EJB Container" для него).
Другие (IBM WebSphere, Oracle/BEA WebLogic, TomEE, Glassfish) также имеют свой контейнер для контейнеров + EJB.
TomEE явно использует Apache Tomcat в качестве своего веб-контейнера. Glassfish также использует вилку Apache Tomcat. (Да, Apache Tomcat, кажется, очень популярен:)
В приведенном ниже обсуждении вы можете изменить Tomcat с помощью "Web Container" и JBoss с "Полностью поддерживающим Java EE Server" всякий раз, когда они появляются. (Я использовал названия продуктов для ясности.)
Изображение: Java EE Server и контейнеры - Источник: Учебное пособие по Java EE.
Каковы преимущества (преимущества) использования Java Web-серверов (таких как Tomcat) для обработки вызовов Servlet/JSP и перенаправления более сложных запросов на серверы приложений, такие как JBoss (или IBM WebSphere или BEA WebLogic)?
Из точки константы функциональности нет эффективного коэффициента усиления
Если вы разместите Tomcat перед JBoss, то на самом деле вы делаете Tomcat перед JBossWeb (веб-контейнер, таким образом, вход в каждое веб-приложение), который всегда будет находиться перед контейнером EJB JBoss. Если мы говорим о функциональности, это просто избыточно, так как у нас есть тот же сервис, который доставлен дважды.
Функции переключения или возможности кластеризации
Размещение Tomcat до JBoss может иметь смысл, если они используют JBoss только для своего контейнера EJB: выбор здесь будет простым коммутатором в реализации веб-контейнера.
Кроме того, если Tomcat находился в другой сети node (или более одного Tomcat/node), возможности кластеризации могут быть применены (в противном случае это невозможно, так как JBossWeb и JBoss обычно рассматриваются как один и таким образом, зайдите в одну и ту же машину).
Обслуживание статического содержимого и проблем с безопасностью
Что такое очень общий размещение веб-сервера (например, Apache HTTPD или IIS) до Java Web Container. Для этого есть две основные причины:
- Сделать HTTPD для статического содержимого (например, изображений) и переслать остальные в веб-контейнер Java. Это делается потому, что веб-серверы, как правило, лучше оптимизируются при задании статического содержимого.
- Безопасность: выставлять только HTTPD в DMZ. Можно настроить Apache HTTPD на DMZ и сделать его просто переадресацией всего на Web Containers (Tomcats и т.д.) И на серверы JavaEE (JBosses и т.д.).
Если вам нужна дополнительная безопасность, нет смысла использовать веб-контейнер в DMZ: если он обслуживает приложения (то есть имеет .war файлы, развернутые на нем), приложения по-прежнему "уязвимы"; если это его единственные запросы/ответы на пересылку, то Apache HTTPD - намного лучший вариант!