• Пулы соединений с БД
  • Возможность периодического тестирования доступности СУБД и обновления соединения в случае восстановления после сбоев
  • Замена прав доступа при подключении
  • Балансировка нагрузки между несколькими СУБД, определение доступность или недоступность того или иного узла
  • Защита пула соединений от некорректного кода в приложении, которое по недосмотру не возвращает соединения, просто отбирая его после какого-то таймаута.
• 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’а, обеспечивающего
    • Возможность одновременного запуска нескольких экземпляров сервера
    • Просмотр состояния запущенных экземпляров сервера, обработчиков той или иной очереди, на том или ином сервере, количества соединений с той или иной БД
• Административный канал и развертывание в промышленном режиме Некоторые сервера приложений позволяют включить так называемый "административный канал" - отдельный порт, запросы по которому имеют приоритет.
  • Просмотр состояния (выполняющихся транзакций, потоков, очередей) в случае недоступности ("зависания") сервера
  • Обновление приложений "на-лету", без простоя:
    • добавление на сервер новой версии приложения в "закрытом" режиме, пока пользователи продолжают работать со предыдущей
    • тестирование корректности развертывания новой версии
    • "скрытый" перевод на использование новой версии всех пользователей

Oct. 23, 2023, Источник