+ [Зачем нужны сервера приложений, если есть контейнеры сервлетов?](#Зачем-нужны-сервера-приложений-если-есть-контейнеры-сервлетов)

+ WildFly

+ __Пулы соединений с БД__

+ Возможность периодического тестирования доступности СУБД и обновления соединения в случае восстановления после сбоев

+ Замена прав доступа при подключении

+ Балансировка нагрузки между несколькими СУБД, определение доступность или недоступность того или иного узла

+ Защита пула соединений от некорректного кода в приложении, которое по недосмотру не возвращает соединения, просто отбирая его после какого-то таймаута.

+ __JMS__

+ Доступность сервера очередей сообщений "из-коробки".

+ Возможность кластеризации очередей, т.е. доступность построения распределенных очередей, расположенных сразу на нескольких серверах, что существенно увеличивает масштабируемость и доступность приложения

+ Возможность миграции очередей - в случае падения одного из серверов, его очереди автоматически перемещаются на другой, сохраняя необработанные сообщения.

+ В некоторых серверах приложений поддерживается _Unit-of-Order_ - гарантированный порядок обработки сообщений, удовлетворяющих некоторым критериям.

+ __JTA__ Встроенная поддержка распределенных транзакций для обеспечения согласованности данных в разные СУБД или очереди.

+ __Безопасность__

+ Наличие множества провайдеров безопасности и аутентификации:

+ во встроенном или внешнем _LDAP-сервере_

+ в базе данных

+ в различных _Internet-directory_ (специализированных приложениях для управления правами доступа)

+ Доступность _Single-Sign-On_ (возможности разделения пользовательской сессии между приложениями) посредством _Security Assertion Markup Language (SAML) 1/2_ или _Simple and Protected Negotiate (SPNEGO)_ и _Kerberos_: один из серверов выступает в роли базы для хранения пользователей, все другие сервера при аутентификации пользователя обращаются к этой базе.

+ Возможность авторизации посредством протокола _eXtensible Access Control Markup Language (XACML)_, позволяющего описывать довольно сложные политики (например, приложение доступно пользователю только в рабочее время).

+ Кластеризация всего вышеперечисленного

+ __Масштабируемость и высокая доступность__ Для контейнера сервлетов обычно так же возможно настроить кластеризацию, но она будет довольно примитивной, так как в случае его использования имееются следующие ограничения:

+ Сложность передачи пользовательской сессии из одного _центра обработки данных (ЦоД)_ в другой через Интернет

+ Отсутствие возможности эффективно настроить репликации сессий на большом (состоящем из 40-50 экземпляров серверов) кластере

+ Невозможность обеспечения миграции экземпляров приложения на другой сервер

+ Недоступность механизмов автоматического мониторинга и реакции на ошибки

+ __Управляемость__

+ Присутствие единого центра управления, т.н. _AdminServer_ и аналога _NodeManager_’а, обеспечивающего

+ Возможность одновременного запуска нескольких экземпляров сервера

+ Просмотр состояния запущенных экземпляров сервера, обработчиков той или иной очереди, на том или ином сервере, количества соединений с той или иной БД

+ __Административный канал и развертывание в промышленном режиме__ Некоторые сервера приложений позволяют включить так называемый "административный канал" - отдельный порт, запросы по которому имеют приоритет.

+ Просмотр состояния (выполняющихся транзакций, потоков, очередей) в случае недоступности ("зависания") сервера

+ Обновление приложений "на-лету", без простоя:

+ добавление на сервер новой версии приложения в "закрытом" режиме, пока пользователи продолжают работать со предыдущей

+ тестирование корректности развертывания новой версии

+ "скрытый" перевод на использование новой версии всех пользователей

[к оглавлению](#servlets-jsp-jstl)

+ [JavaTalks Articles](https://articles.javatalks.ru/articles/24)