Серверы приложений и web-контейнеры - hello-world

Серверы приложений и web-контейнеры
(Самые базовые сведения)
Оглавление
Серверы приложений и web-контейнеры ............................................................................................................. 1
Web-контейнеры ...........................................................................................................................................1
Серверы приложений ...................................................................................................................................3
Web-контейнеры
Web-контейнер нужен для исполнения веб-приложений. По сути дела он представляет
собой веб-сервер с набором инструментов для развёртывания (deployment) приложений
пользователя и управления их жизненным циклом.
Веб-приложение в JavaEE представляет собой специальную сборку (myApp.war,
WAR=Web Archive), которая удовлетворяет определённым правилам.
По сути дела, веб-приложение – это архив, содержащий классы, требуемые библиотеки
(JAR) и файл-дескриптор, описывающий структуру этого приложения. Подробнее об
этом будет далее, так что в данный момент не будем останавливаться на формате
WAR-файла.
Контейнер может обслуживать несколько развернутых приложений, которые
изолированы друг от друга разными класс-лоадерами, так что они могу содержать одни
и те же классы. Более того, в контейнере можно развернуть несколько раз одно и то же
приложение.
Как известно, веб-сервер нужен для обработки HTTP-запросов. Таким образом,
основная задача web-контейнера состоит в том, чтобы:

Принять HTTP-запрос от клиента

Определить развернутое приложение, которое его должно обработать

Найти зарегистрированный данным
(терминология будет вводиться позже).

Передать параметры HTTP-запроса найденному обработчику если обработчик
найден, либо отправить запрос в лес, если подходящего обработчика нет.

Дождаться пока обработчик сумеет обработать запрос и вернёт ответ.

Передать ответ обработчика клиенту.
приложением
обработчик
запроса
На данном этапе важно только то, каким образом сервер находит соответствующее
приложение и обработчик.
Определение приложения.
Для того, чтобы определить, какое приложение обрабатывает какие запросы,
используется такое понятие как биндинг (binding) или контекст. Понять это проще всего
так:
Предположим, сервер принимает HTTP-запрос такого рода:
GET /app1/module2/something3/showProduct?id=10 HTTP/1.1
….
Это возможно, например, если пользователь нажмет на ссылку или сам в адресной
строке браузера напишет http://server.com/app1/module2/something3/showProduct?id=10
Что делает север? Он ищет приложения, с биндингом, соответствующим пришедшему
URL. В нашем примере это /app1/module2/something3/showProduct
По сути дела, сервер последовательно проверяет, не связано (страшное слово
забиндено я не любю) ли какое-либо развернутое приложение со следующими
шаблонами URL:
/*
/app1/*
/app1/module2/*
и так далее. Если он обнаруживает, что /* не обрабатывает никто, то он идёт дальше.
Предположим, что в контейнере развернуто приложение app1.war. По-умолчанию, имя
файла соответствует биндингу этого приложения. Т.о. app1.war обрабатывает запросы
вида /app1/*
Этот самый биндинг /app1/* называется корневым контекстом (context root) приложения
app1.
Для того, чтобы корневым контекстом приложения сделать /* нужно немного
продвинуться от умолчаний, но это будет потом.
Поиск обработчика
Благодаря дескриптору, который содержится в war-файле, контейнер может получить
список обработчиков и их биндинги относительно корневого контекста.
Например, приложение app1 может зарегистрировать обработчики для следующих
шаблонов URL:
/module1/*
/module2/something3/*
/module2/something4
…
Контейнер перебирает обработчики в том же порядке и вызывает первый, чей шаблон
соответствует URL запроса.
На данном этапе этих сведений достаточно.
Самым популярным web-контейнером является Apache Tomcat.
Серверы приложений
Сервер приложений – это более широкое понятие, чем web-контейнер. Как правило
любой сервер приложений содержит в своём составе web-контейнер.
Зачем нужен сервер приложений? Проще всего понять на примере.
Допустим, web-контейнер принял запрос регистрации нового пользователя в системе.
Он сам о том, что это за запрос не знает, но нашел нужное приложение и обработчик,
который отвечает за регистрацию. Этому обработчику нужно сделать примерно
следующее:
1. Проверить, может быть учетная запись пользователя уже существует в базе
данных. Если так, то выдать ошибку.
2. Если записи нет, то создать новую запись
3. Выслать на указанный в регистрационной форме почтовый адрес письмо с
предложением активировать учётную запись
4. Вернуть пользователю страницу, на которой будет большой смайлик и просьба
проверить свою почту.
Уже из этого простого сценария понятно, что в обработке запроса поучаствовали база
данных и почтовый сервер.
Сервер приложений позволяет настроить пулы соединений с СУБД, параметры
почтовых серверов и другие ресурсы, которые станут доступны приложениям внутри
контейнера с помощью специальных имён.
Другими словами, сервер приложений является посредником между приложением и
внешними ресурсами, особенности доступа к которым известны только серверу
приложений, и который позволяет общаться с этими ресурсами достаточно
единообразно.
У сервера приложений есть и другие обязанности, но мы раскроем всё это позже. А
пока некоторые примеры, чтобы всё это не повисло в воздухе.
О развертывании приложений
Предположим, для нашего приложения app1 потребуется всего два ресурса: доступ к
СУБД и серверу электронной почты. Разработчики договариваются между собой о том,
что будут требовать у сервера приложений наличия пула соединений с именем, ну
скажем, APP1_DB, а соединения с почтовым сервером будут требовать по имени
java:/Mail.
Формат этих имён на данном этапе значения не имеет, тем более, что он до сих пор не
до конца стандартизован. Но что происходит дальше?
Схематично, если при обработке запроса потребуется доступ к СУБД, то обработчик
запросит у сервера приложений ресурс с именем APP1_DB, и получив его сможет
получить для себя новое соединение с СУБД. Приложение не знает ни на каком
сервере на самом деле находится СУБД, ни какой пароль доступа, и возможно даже не
очень знает какая именно это СУБД (Oracle, MySQL,..?).
Все эти настройки, о которых не знает приложение, остаются на стороне сервера
приложений, который сам устанавливает соединения и раздаёт их развернутым внутри
него приложениям.
Разработчики выпускают свою систему и пишут мануал как его разворачивать.
Например, они пишут, что они поддерживают СУБД Oracle, что нужно создать схему
данных вот таким-то скриптом, а потом определить в сервере приложений пул
соединений с именем APP1_DB.
То же самое с почтовым сервером.
Админ всё это настраивает в сервере приложений, кидает файлы сборки приложения
app1 внутрь сервера и приложение запускается.
Серверов приложений существует значительное количество. Они очень сильно
отличаются друг от друга способами конфигурирования, пользовательским
интерфейсом, набором фич и ресурсов, которые предоставляются приложениям, и
ценой (от нуля до +бесконечности). Вот некоторые популярные серверы: Glassfish,
JBoss, WebLogic, WebSphere.