Приложение Java EE с веб-сервером + сервер приложений

Ответ 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 - намного лучший вариант!

Ответ 2

Sun Java Web Server, IBM WebSphere Application Server, WebLogic, JBoss Application Server, Tomcat, Jetty... Они все Серверы веб-приложений Java и делают то же самое - запустите свою WAR или EAR (EAR для "Enterprise", содержит 1+ WAR).

Если у вас есть два сервера в вашей установке для запуска одного приложения, скорее всего, что-то не так в вашей стратегии развертывания/дизайне.

Существуют случаи многосерверных настроек, но обычно это балансировка нагрузки и настройки прокси-сервера, которые имеют HTTP-сервер Apache перед вашим сервером приложений Java.

Например, у вас есть Tomcat, обслуживающий ваше приложение на порту 8080, и вы хотите использовать http://myserver.com/myapp/ вместо http://myserver.com:8080/myapp/. Вы не можете сделать это с Tomcat самостоятельно, потому что Java не может идти ниже порта 1024 (*). Для этого вам нужно настроить HTTP-сервер Apache на порт 80 и настроить его mod_proxy на перенаправление всего трафика с /myapp на http://myserver.com:8080/myapp.

*: Я не помню точного номера, но это около 1024. И это верно для Linux, но, возможно, не для Windows, прошло некоторое время с тех пор, как я использовал настройку Windows.

UPDATE: Мой плохой, я забыл подчеркнуть, что часть "запустить как системный сервис" описана здесь.

Ответ 3

Хорошо, так как серверы приложений уже содержат сервлет-контейнер на плате, наличие еще одного веб-сервера, который обрабатывает входящий HTTP-запрос, является избыточным.

Однако, как только я работал над проектом, где эти слои были разделены. У нас был кластер серверов JBoss и отдельный кластер серверов Tomcat. Tomcat вызывал JBoss через RMI с балансировкой нагрузки. Это было сделано для обеспечения безопасности (серверы Jboss были внутри VPN) и масштабируемость.