Разделяя веб-сервер и сервер приложений, нужны ли оба Java?

Question

Если мы хотим разделить наш веб-сервер и сервер приложений, нужна ли нам Java на обеих машинах? У меня был один коллега, который сказал установить jboss на обеих машинах (похоже, это не помогло, если на обеих машинах установлен сервер приложений), а другой сказал, что просто установите jboss на одну и apache на другую (сервер приложений / веб-сервер). *

У меня уже есть настройка веб-проекта, и он использует сервлеты и JSP. JSP отображают содержимое, пока сервлеты выполняют действие. Сервлеты получают запросы и пересылают ответы в JSP. У меня вопрос, как мне это сделать, если веб-сервер имеет только Apache и, следовательно, отображает статический контент? Я понимаю, как перенаправлять запросы с веб-сервера на сервер приложений, но как насчет поддержания состояния сеанса, выполняется ли это на веб-сервере, и если да, то как это будет сделано?

Если страница входа - html, а содержимое после входа - html, как я могу запретить людям доступ к содержимому, если они не вошли в систему?

Answer 1

Последняя настройка, которую вы описываете, с Apache, обслуживающим статический контент и перенаправляющим запросы на JSP / сервлеты на сервер приложений, является стандартной настройкой.

Состояние сеанса поддерживается как обычно, ваше веб-приложение Java на сервере приложений отправляет пользователю файл cookie, содержащий JSESSIONID, и когда пользователь делает последующие запросы, Apache включает всю информацию запроса (включая файлы cookie) в то, что он перенаправляет в приложение. сервер.

Установка становится немного более сложной, если вы хотите, чтобы Apache сидел впереди и запрашивал балансировку нагрузки для нескольких экземпляров JBoss, но все равно довольно легко настроить с помощью mod_proxy_balancer .

Некоторые ссылки, которые могут вам помочь:

http://help.shadocms.com/blog/2009/how-to-setup-apache-with-jboss-on-a-shado-site.cfm http://redlumxn.blogspot.com/2008/01/configure-apache2-and-jboss-422ga.html

Answer 2

Есть много возможностей.

1. На веб-машине установите Apache с mod_jk, чтобы перенаправить запросы в tomcat / jboss. В этом случае вам не нужна Java на этой машине.

2. Вы также можете разделить свой контейнер jsp (например, tomcat / jboss) и сервер приложений, в этом случае вам потребуется установить Java, где у вас есть веб-контейнер.

3. Как правило, там, где есть необходимость в повышенном уровне безопасности, люди объединяют вышеупомянутые возможности. Тонкий веб-слой (apache + no java) + веб-контейнер (например, tomcat) + прикладной слой (jboss / glassfish)

Первое решение обычно является стандартным.

Answer 3

Краткий ответ - Нет.

Длинный ответ -

Это зависит от потребностей вашего приложения. Есть несколько причин, по которым вы хотите использовать веб-сервер на другом физическом компьютере:

• Вы хотите, чтобы веб-сервер обслуживал статический контент, и оставить приложение сервер бесплатный только для обработки содержание сервлета / jsp

• Вы хотите реализовать программное обеспечение на основе балансировки нагрузки. Вы бы имели
  запросы прокси-сервера apache к
  несколько серверов приложений поддержки

В вашем примере входа в систему html-страница обслуживается apache, а действие html-формы указывает на ваш сервлет для обработки - так что JBoss / java все равно будет управлять сессией. Имейте в виду, что на веб-сервере должно присутствовать любое статическое содержимое, которое вы хотите использовать на Apache.

Answer 4

Распространенным развертыванием является использование внешних серверов Apache для обслуживания статического контента и перенаправления запросов на динамический контент на сервер JSP. Это в основном из соображений производительности: Apache быстрее обрабатывает контент и снижает нагрузку на сервер JSP.

Я не вижу причин, по которым вы не могли бы, например, использовать IIS в качестве сервера-фронтина (удаляя Java из уравнения), хотя, с богатыми модулями Apache и сопутствующей информацией о конфигурации, я думаю, что вы могли бы быть усложнить себе жизнь, если ты это сделал.

Answer 5

Ваш сценарий напоминает мне SiteMinder. Он был использован для контроля доступа в наше приложение. Он имеет встроенную HTTP-переадресацию, поэтому с точки зрения пользователя браузер общается с siteminder, а siteminder общается с реальным приложением. Они оба используют сессионные куки и siteminder под названием SMSESSION, в то время как приложение называется JSESSIONID, поэтому нет конфликта.