Apache Tomcat — это контейнер, который позволяет вам использовать интернет приложения такие, как Java сервлеты и JSP (серверные страницы Java).Пакеты Tomcat 6.0 в Ubuntu поддерживают два варианта запуска Tomcat. Вы можете установить его как классический одиночный экземпляр на всю систему, который будет запускаться при загрузке системы от имени непривилегированного пользователя tomcat6 . Но вы можете развернуть частные экземпляры, которые будут запускаться с правами вашего собственного пользователя, и вам придется запускать и останавливать их самостоятельно. Второй вариант особенно полезен в контексте сервера разработки, где нескольким пользователям требуется тестировать их собственные частные экземпляры Tomcat.

Масштабная установка на всю систему

Linux настройка tomcat

Изменение портов по умолчанию

Изначально Tomcat 6.0 запускает HTTP соединитель (connector) на порту 8080 и AJP соединитель на порту 8009. Вы можете захотеть изменить эти порты для избежания конфликтов с другими серверами на системе. Это делается изменением следующих строк в /etc/tomcat6/server.xml:

...

Изменение используемой JVM

По умолчанию Tomcat предпочитает использовать OpenJDK-6, затем пробует JVM от Sun (Oracle), а затем иные JVM. Если у вас установлено несколько JVM, вы можете определить какая из них будет использоваться, установив JAVA_HOME в /etc/default/tomcat6:

JAVA_HOME=/usr/lib/jvm/java-6-sun

Определение пользователей и ролей

Пользователи, пароли и роли (группы) могут быть определены централизованно в секции Servlet. Для Tomcat 6.0 это настраивается в файле /etc/tomcat6/tomcat-users.xml:

Использование стандартных приложений Tomcat

Tomcat поставляется с приложениями, которые вы можете установить для документирования, администрирования или демонстрационных целей.

Документация Tomcat

Пакет tomcat6-docs содержит документацию Tomcat 6.0, упакованную в качестве интернет приложения, которое доступно по умолчанию по адресу http://yourserver:8080/docs . Вы можете его установить следующей командой в терминале: sudo apt-get install tomcat6-docs

Приложения администрирования Tomcat

Пакет tomcat6-admin содержит два приложения, которые могут быть использованы для администрирования сервера Tomcat через web интерфейс. Для их установки введите следующую команду в терминале:

Sudo apt-get install tomcat6-admin

Первое из них это приложение manager , которое по умолчанию доступно по адресу http://yourserver:8080/manager/html . Оно в первую очередь используется для получения статуса сервера и перезапуска web приложений.

Доступ к приложению manager по умолчанию защищено: вам надо определить пользователя с ролью «manager» в /etc/tomcat6/tomcat-users.xml для получения к нему доступа.

Второе приложение — это host-manager , которое по умолчанию доступно вам по адресу http://yourserver:8080/host-manager/html . Оно может быть использовано для создания виртуальных хостов динамически.

Доступ к приложению host-manager также закрыто по умолчанию: вам надо определить пользователя с ролью «admin» в /etc/tomcat6/tomcat-users.xml для получения к нему доступа.

По соображениям безопасности пользователь tomcat6 по умолчанию не может писать в каталог /etc/tomcat6. Некоторые возможности в этих приложениях администрирования (разработка приложений, создание виртуальных хостов) требуют права записи на этот каталог. Если вы хотите пользоваться этими возможностями, выполните следующее для предоставления группе tomcat6 необходимых прав:

Sudo chgrp -R tomcat6 /etc/tomcat6 sudo chmod -R g+w /etc/tomcat6

Приложения примеров Tomcat

Пакет tomcat6-examples содержит два приложения, которые могут быть использованы для тестирования или демонстрации возможностей сервлетов и JSP, которые по умолчанию вы можете найти по адресу http://yourserver:8080/examples . Вы можете установить их следующей командой в терминале:

Sudo apt-get install tomcat6-examples

Использование пользовательских экземпляров

Tomcat в большей степени используется при разработке и тестировании , когда использование одиночной оболочки на сервере не удовлетворяет требованиям множества пользователей на одной системе. Пакеты Tomcat 6.0 в Ubuntu поставляются с инструментарием, помогающим создать ваши собственные настроенные на пользователя оболочки, позволяя каждому пользователю в системе запускать (без прав суперпользователя) отдельные частные экземпляры, при том, что они будут использовать библиотеки, установленные в системе.

Существует возможность запускать общий и частные экземпляры в параллель, до тех пор пока они не используют одни и те же TCP порты.

Установка поддержки частных оболочек

Вы можете установить все необходимое для запуска частных оболочек вводом следующей команды в терминале:

Sudo apt-get install tomcat6-user

Создание частного экземпляра

Вы можете создать каталог частной оболочки вводом следующей команды в терминале:

Tomcat6-instance-create my-instance

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

Настройка вашего частного экземпляра

Вы обнаружите обычные файлы настроек Tomcat для вашего частного экземпляра в подкаталоге conf/. Вы конечно же можете отредактировать файл conf/server.xml для изменения портов по умолчанию, используемых вашим частным экземпляром Tomcat для предотвращения конфликтов с другими экземплярами, которые также могут быть запущены.

Запуск/остановка вашего частного экземпляра

Вы можете стартовать свой частный экземпляр, набрав следующую команду в терминале (подразумевается, что ваш экземпляр расположен в каталоге my-instance):

My-instance/bin/startup.sh

Вы можете проверить подкаталог logs/ на предмет обнаружения каких-либо ошибок. Если вы получили ошибкуjava.net.BindException: Address already in use:8080 , это означает, что порт, который вы используете уже занят и вам следует его поменять.

Вы можете остановить свой экземпляр, используя следующую команду в терминале (подразумевается, что ваш экземпляр все еще находится в каталоге my-instance).

В статье рассказывается о том, как поднять на своем компьютере локальный java сервер и прописать простейшее web-приложение.

Tomcat нужен для работы Java сервера с применением сервлетов . Если грубо говоря, то сервелеты это аналог тех же php скриптов. На сервер Tomcat от клиентов приходят запросы. В зависимости от них сервер запустит те или иные сервелеты, которые сформируют ответы в виде текстовых файлов. Чаще всего это html страницы.

Установка JDK

Для работы современных версий Android Studio или IntelliJ IDEA не нужно производить дополнительные действия, чтобы программы могли найти JDK и запускать java приложения. Но мы будем на данный момент компилировать сервлеты вручную, так что для удобства мы пропишем путь к папке JDK в системную переменную Path в Windows. Ниже приведена инструкция для Windows 10.

У меня JDK находится в папке C:\Program Files\Java\jdk1.8.0_121\bin .

Кликните правой кнопкой по иконке Этот компьютер и перейдите в Свойства .

Внимание! Не вздумайте удалять всё содержимое переменной Path . Иначе у операционной системы возникнут очень большие проблемы. Вы должны дописать в эту переменную нужный путь.

Установка Apache Tomcat

Скачиваем установочный файл.

Устанавливаем Tomcat.

Эти компоненты должны быть выбраны.

Для учебных целей можно параметры оставить по умолчанию.

После этого в трее должен появится значок запущенного сервиса.

В папке webapps создадим папку с названием web-приложения. Допустим, testingapp .

На протяжении всего времени изучения и освоения Java, я старался разобраться и научиться программировать/писать Window Application. Но, если честно, поразмыслив на досуге, решил все-таки сменить вектор обучения: решил освоить Servlet -ы и податься в облака Web -программирование. Для работы /изучения сервлетов нам понадобится веб-сервер Apache Tomcat .
Apache Tomcat - программа-контейнер сервлетов, написанная на языке Java и реализующая спецификацию сервлетов и спецификацию JavaServer Pages (JSP), которые являются стандартами для разработки веб-приложений на языке Java.

Tomcat позволяет запускать веб-приложения, содержит ряд программ для самоконфигурирования.

Tomcat используется в качестве самостоятельного веб-сервера, в качестве сервера контента в сочетании с веб-сервером Apache HTTP Server, а также в качестве контейнера сервлетов в сервере приложений JBoss.

Другими словами без Tomcat при написании сервлетов нам не обойтись.

Когда-то в одном из своих постов на блоге я уже писал про установку и настройку Apache Tomcat, но хотелось бы рассмотреть эту тему более подробно и детально.

В данной статье хотелось бы более подробно рассмотреть настройку и установку Tomcatдля ОС Windows. Настройку Apache Tomcat для ОС Linux вынесу в отельную статью. Материал по данной тематике огромный, поэтому этот пост будет добавляться/обновляться по мере изучения и освоения Tomcat.

Итак, понеслось....
Для начала нам необходимо скачать TomCat с официального сайта разработчиков . Описание доступных версий TomCat можно посмотреть на данной страничке . На момент написания статьи последней стабильной версией была 7.0.14 .
Приведу прямые ссылки для скачивания данной версии:
Рассмотрим вариант установки Tomcat при помощи исполняемого файла, который установит Tomcat в качестве службы Windows и TomCat будет запускаться при старте системы. После скачивания установщика запускаем его и отвечаем на простые вопросы:вначале соглашаемся с лицензионным соглашением, затем выбираем тип установки (полный, выборочный, нормальный, минимальный) - я выбрал полный. Дальше установщик запросит у нас некоторую конфигурацию: порт подключения (по умоланию 8080):

Настройки Apache TomCat
Это означает, что для запуска Tomcat в командной строке броузера нам нужно будет вводить адрес вида: https://localhost:8080 Значение порта подключения можно оставить по умолчанию, но если у нас на компьютере или сервере будет использоваться в качестве Web-сервера только Tomcat , то значение порта можно поставить равное 80 . Следовательно строка ввода адреса в браузере будет выглядеть просто https://localhost (без указания порта). Укажем порт 80. В последствие данное значение можно будет изменить вручную в настройках сервера (файл server.xml ).
Далее указываем свой логин и пароль. Роли оставим указанные по умолчанию: admin-gui, manager-gui . Далее указываем путь к установленной jdk на нашем компьютере. И в завершение указываем путь куда устанавливать TomCat и нажимаем Install.
После завершения установки оставляем галочку "Запустить TomCat ":
Завершение установки TomCat
Нажав кнопку Finish , мы увидим окно запуска TomCat в качестве сервиса ОС Windows:
Теперь наступила пора проверить работоспособность сервера TomCat: для этого в сроке ввода адреса в нашем любимом браузере вводим команду:
https://localhost:8080 В результате, если все прошло гладко, откроется домашняя страница TomCat:
Домашняя страница Apache TomCat на нашем localhost

Часть информации и документации на открывшейся страничке localhost будет дублируется с официального сайта.
Кроме того, установленный сервер TomCat будет доступен пользователям Вашей локальной сети - никаких дополнительных настроек делать не нужно.
На этом данный вид установки TomCat можно считать завершенным.

Теперь коротко рассмотрим другой вариант установки и запуска: из архива. Итак.. после скачивания архива для соответствующей архитектуры Winsows распаковываем его в любое удобное для нас место, например D:/Java/apache-tomcat-7.0.14/ Запускаем командную строку Windows и переходим в папку: D:/Java/apache-tomcat-7.0.14/bin/ - в данной папке находятся исполняемые файлы для TomCat. Для установки TomCat в качестве службы Windows вводим команду:
service.bat install Более подробную информацию по установке можно почитать на данной страничке .
Запускать TomCat можно при помощи команды
startup.bat Остановить сервер можно при помощи команды команды:
shutdown.bat Не забываем предварительно добавить системные переменные: CATALINA_HOME и JAVA_HOME . Выглядеть они будут примерно так:
JAVA_HOME: c:\Program Files\Java\jdk1.6.0_18\
CATALINA_HOME: D:/Java/apache-tomcat-7.0.14

Собственно на этом установка Apache TomCat закончена. Информация о дополнительной настройке и использовании TomCat будет чуть позже.

|

Apache Tomcat – это сервер приложений, который используется для обслуживания приложений Java. Tomcat – это открытая реализация технологий Java Servlet и JavaServer Pages, выпущенная Apache Software Foundation. Данное руководство описывает базовую установку и настойку Tomcat 8 на сервере Ubuntu 16.04.

Требования

  • Предварительно настроенный сервер Ubuntu 16.04 (инструкции по начальной настройке – ).
  • Не-root пользователь с доступом к sudo.

1: Установка Java

Для работы Tomcat необходимо установить Java, иначе код Java не будет выполняться. Установите OpenJDK при помощи стандартного пакетного менеджера apt-get.

Сначала нужно обновить индекс пакетов.

sudo apt-get update

Чтобы установить JDK, введите:

sudo apt-get install default-jdk

После установки Java создайте пользователя tomcat для запуска сервиса Tomcat.

2: Создание пользователя Tomcat

В целях безопасности сервер Tomcat следует запускать с правами обычного пользователя (т.е. не-рутового). Для этого создайте нового пользователя и группу.

Чтобы создать группу tomcat, введите:

sudo groupadd tomcat

После этого нужно создать пользователя tomcat, который должен состоять в одноименной группе. Домашний каталог пользователя – /opt/tomcat (в него будет установлен Tomcat); оболочка – /bin/false (чтобы никто не мог открыть учётную запись):

sudo useradd -s /bin/false -g tomcat -d /opt/tomcat tomcat

После этого приступайте к установке Tomcat.

3: Установка Tomcat

На данный момент Tomcat 8 проще всего установить вручную из бинарного релиза.

На странице загрузки найдите последнюю версию Tomcat. На данный момент такой версией является 8.0.33. В разделе Binary Distributions найдите список Core и скопируйте ссылку на tar.gz.

Перейдите в каталог /tmp на сервере. Этот каталог предназначен для временных пакетов.

Чтобы загрузить архив Tomcat, используйте следующую команду (приведенная ниже ссылка может отличаться):

curl -O http://apache.mirrors.ionfish.org/tomcat/tomcat-8/v8.0.33/bin/apache-tomcat-8.0.33.tar.gz

Установите Tomcat в каталог /opt/tomcat. Создайте этот каталог и извлеките в него архив:

sudo mkdir /opt/tomcat
sudo tar xzvf apache-tomcat-8*tar.gz -C /opt/tomcat --strip-components=1

После этого нужно установить соответствующие права на каталог.

4: Права

Пользователь tomcat должен иметь доступ к установке Tomcat.

Откройте каталог Tomcat:

Дайте пользователю tomcat право на изменение каталога conf и право на чтение файлов в нём:

sudo chgrp -R tomcat conf
sudo chmod g+rwx conf
sudo chmod g+r conf/*

Затем сделайте пользователя tomcat владельцем каталогов work, temp и logs.

sudo chown -R tomcat webapps/ work/ temp/ logs/

5: Создание файла systemd

Чтобы запустить Tomcat как сервис, нужно создать service-файл systemd.

Серверу Tomcat нужно знать, где находится установка Java. Этот путь называется JAVA_HOME. Чтобы узнать местонахождение установки, используйте команду:

sudo update-java-alternatives -l
java-1.8.0-openjdk-amd64 1081 /usr/lib/jvm/java-1.8.0-openjdk-amd64

Примечание : В данном примере JAVA_HOME выделен красным.

Теперь добавьте к полученному значению секцию /jre и установите в качестве значения JAVA_HOME:

JAVA_HOME
/usr/lib/jvm/java-1.8.0-openjdk-amd64/jre

Примечание : Переменная JAVA_HOME может отличаться.

Теперь можно создать service-файл. Откройте tomcat.service в каталоге /etc/systemd/system:

sudo nano /etc/systemd/system/tomcat.service

Внесите в файл следующий скрипт, при необходимости изменив JAVA_HOME; также можно изменить настройки распределения памяти, которые указаны в CATALINA_OPTS:


Description=Apache Tomcat Web Application Container
After=network.target
Type=forking
Environment=JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64/jre
Environment=CATALINA_PID=/opt/tomcat/temp/tomcat.pid
Environment=CATALINA_HOME=/opt/tomcat
Environment=CATALINA_BASE=/opt/tomcat
Environment="CATALINA_OPTS=-Xms512M -Xmx1024M -server -XX:+UseParallelGC"
Environment="JAVA_OPTS=-Djava.awt.headless=true -Djava.security.egd=file:/dev/./urandom"
ExecStart=/opt/tomcat/bin/startup.sh
ExecStop=/opt/tomcat/bin/shutdown.sh
User=tomcat
Group=tomcat
WantedBy=multi-user.target

Сохраните и закройте файл.

После этого нужно перезапустить демон systemd:

sudo systemctl daemon-reload

Теперь сервис Tomcat готов к запуску. Для этого используйте:

sudo systemctl start tomcat

Убедитесь, что при запуске не произошло ошибок:

sudo systemctl status tomcat

6: Настройка брандмауэра и тестирование сервера Tomcat

После запуска сервиса Tomcat нужно убедиться, что стандартная страница доступна.

Но сначала нужно откорректировать настройки брандмауэра и разблокировать порт Tomcat. Если вы следовали , на данный момент сервер защищён брандмауэром ufw.

Для обработки запросов Tomcat использует порт 8080. Чтобы разблокировать трафик этого порта, введите:

sudo ufw allow 8080

Теперь брандмауэр пропускает трафик Tomcat. Чтобы получить доступ к стандартной странице сервиса, откройте ссылку:

http://server_domain_or_IP:8080

На экране появится приветственная страница Tomcat, которая содержит некоторую информацию о программе. Однако доступа к ссылкам (например, Manager App) у вас на данный момент нет.

Если всё работает должным образом, включите service-файл, чтобы сервис Tomcat автоматически запускался вместе с сервером.

sudo systemctl enable tomcat

7: Настройка веб-интерфейса управления Tomcat

Чтобы использовать поставляемый с Tomcat интерфейс, добавьте логин на сервер Tomcat. Для этого отредактируйте файл tomcat-users.xml:

sudo nano /opt/tomcat/conf/tomcat-users.xml

Теперь нужно добавить пользователя, который будет иметь доступ к поставляемым с Tomcat интерфейсам: manager-gui и admin-gui. Для этого можно использовать приведённый ниже код (но укажите более надёжное имя и пароль пользователя):



Сохраните и закройте файл tomcat-users.xml. Чтобы обновить настойки, перезапустите сервис Tomcat.

sudo systemctl restart tomcat

8: Доступ к веб-интерфейсу

Теперь сервер Tomcat запущен. Откройте в браузере веб-интерфейс управления. http://server_IP_address:8080

На экране появится страница с сообщением:

If you’re seeing this, you’ve successfully installed Tomcat. Congratulations!

Теперь откройте Manager App, доступный по ссылке:

http://server_IP_address:8080/manager/html

Этот менеджер нужен для управления приложениями Java. Он позволяет запускать, перезапускать, останавливать и сворачивать их. Кроме того, он может выполнять диагностику приложений (к примеру, обнаруживать утечки памяти). В конце этой страницы содержится информация о сервере.

Теперь откройте Host Manager:

http://server_IP_address:8080/host-manager/html/:

Страница Virtual Host Manager нужна для управления виртуальными хостами; она позволяет добавлять виртуальные хосты для развёртывания приложений.

Заключение

Готово! Теперь сервер Tomcat полностью готов к обслуживанию приложений Java.

Tags: ,

Молодые программисты часто задают вопрос: а зачем нужны зачастую довольно тяжелые и дорогие промышленные сервера приложений (такие как JBoss AS , Oracle WebLogic , IBM WebSphere AS ), если у нас есть замечательный легковесный фреймворк Spring и контейнер сервлетов Apache TomCat . Попробуем на него ответить. Сразу замечу, речь сейчас не идет об архитектуре приложения! Не важно, используете вы EJB или нет. Предположим, у вас приложение на Spring Framework и стоит вопрос, на чем его запускать. Итак, какие дополнительные сервисы предлагает нам сервер приложений.

  • Пулы соединений с БД . Да, у TomCat тоже есть пул соединений, но каковы его возможности? Может ли он периодически тестировать доступность СУБД и обновлять соединения в случае восстановления после сбоев? Умеет ли он делать замену прав доступа? Грубо говоря, подключаемся к БД под пользователем в зависимости от того, кто аутентифицировался в нашем приложении, если часть логики вынесена на уровень СУБД, то это бывает полезно. Может ли пул соединений Tomcat балансировать нагрузку между несколькими базами данных (например, в случае Oracle RAC ), а так же определять, что вот эти узлы RAC умерли и теперь к ним не нужно пытаться подключаться, а затем понять, что они снова доступны и теперь их тоже можно использовать? В конце концов, может ли ваш пул соединений защитить от некорректного кода в приложении, которое по недосмотру не возвращает соединения, просто отбирая его после какого-то таймаута?
  • JMS . Если вы хотите использовать очереди в вашем приложении, развернутом на TomCat , то придется отдельно еще поднимать сервера очередей сообщений. В случае сервера приложений, очереди как правило доступны их коробки. Вместе с очередями доступны так же следующие вещи: кластеризация - вы можете строить распределенные очереди, расположенные сразу на нескольких серверах, что существенно увеличивает масштабируемость и доступность вашего приложения, миграция - в случае падения одного из серверов, его очереди автоматически перемещаются на другой, сохраняя необработанные сообщения. В некоторых серверах приложений поддерживается Unit-of-Order - гарантированный порядок обработки сообщений, удовлетворяющих некоторым критериям, очень часто при интеграции бывает полезен.
  • JTA . Те самые распределенные транзакции. Кто-то их понимает и использует, кто-то считает слишком тяжелыми. Как правило это так, они слишком тяжелые, но если вам нужно обеспечить согласованность данных в СУБД, разнесенных по разным углам нашей необъятной, или в СУБД и очереди, то без таких транзакций будет трудно. Суть распределенных транзакций в том, что мы не коммитим ни в одну из БД, пока не убедимся, что все БД, участвующие в транзакции, смогут принять наши данные. Тем самым мы избегаем проблемы “с одного счета в одном банке деньги списали, а на другой - в другом банке - не зачислили - сработало ограничение целостности”.
  • Безопасность . Современные сервера приложений предоставляют множество различных провайдеров безопасности. Доступны различные провайдеры аутентификации, вы можете хранить ваших пользователей во множестве мест: во встроенном LDAP -сервере, в базе данных, во внешнем LDAP -сервере, в различных Internet-directory - специализированных приложениях для управления правами доступа. Возможны следующие сценарии: на работу наняли человека, добавили его в , там запустился процесс раздачи прав, который выдал человеку права на все ресурсы вашего предприятия и теперь каждый сервер приложений в вашей компании (а их может быть очень много) видит эти права, так как подключен к этой Internet-directory/Access-manager . Доступно разделение пользовательской сессии между приложениями: мы аутентифицировались в одном приложении - нам уже не нужно аутентифицироваться в другом. Так же доступна реализация Single-Sign-On : вы делаете один из серверов базой для хранения пользователей, все другие сервера при аутентификации пользователя обращаются к этой базе. Реализуется SSO посредством Security Assertion Markup Language (SAML) 1/2 или посредством Simple and Protected Negotiate (SPNEGO) и Kerberos для Windows -клиентов. Возможна авторизация посредством протокола eXtensible Access Control Markup Language (XACML) , позволяющего описывать довольно сложные политики (например, приложение доступно пользователю только в рабочее время). Опять же все данные возможности работают в кластерном окружении. Впрочем, стоит отметить, что с помощью Spring Security и Apache Shiro можно реализовать большинство из них, но вам придется “тянуть” эти реализации за каждой вашей программой, в то время как в сервере приложений они доступны из коробки.
  • Масштабируемость и высокая доступность . Да, для TomCat мы можем настроить кластеризацию, но она будет довольно примитивной. Мы не сможем сделать передачу пользовательской сессии из одного центра обработки данных (ЦоД) в другой через Интернет, мы не сможем эффективно настроить репликацию сессий на большом кластере, состоящем из 40-50 экземпляров сервера приложений. В случае сбоев, мы не сможем обеспечить миграцию экземпляров сервера на другую машину и т.д. Так же в TomCat нет механизмов автоматического мониторинга и реакции на ошибки: мы не можем автоматически перезапустить экземпляр сервера, если на нем зависло 10 потоков, мы не можем автоматически отправить письмо администратору при переполнении пула соединений и т.д.
  • Управляемость . В случае большого кластера TomCat у нас нет единого центра управления, т.н. AdminServer и аналога NodeManager’ а. Мы не сможем одновременно запустить на старт 50 экземпляров сервера. Мы не можем посмотреть состояние экземпляров, посмотреть сколько у нас обработчиков на той или иной очереди, на том или ином сервере, сколько создано соединений с той или иной БД, какие из них можно убить, какие в данный момент выполняются транзакции, какие ресурсы в них задействованы и т.д. Конечно, можно все сделать “за три минуты на скриптах, ну как в Линуксе принято”, но результат будет плачевный.
  • Скриптовый язык . Кстати о скриптах, большинство промышленных серверов приложений содержат утилиты для выполнения скриптов как правило на языке Python , Пользоваться данными утилитами одно удовольствие. Администратор может описать в виде скрипта все шаги для подготовке к развертыванию сколь угодно большого приложения, таким образом запуск в продуктив или обновление займет сравнительно немного времени. С помощью таких скриптов можно создавать источники данных (представьте себе сервисную шину, подключенную к 120 экземплярам БД), JMS -очереди, менеджеры потоков, создавать новые экземпляры серверов и добавлять их в кластер, выполнять остановку и запуск серверов, их миграцию.
  • Административный канал и развертывание в промышленном режиме . Некоторые сервера приложений позволяют включить так называемый административный канал - отдельный порт, защищенный SSL , запросы по которому имеют приоритет. Таким образом, даже если ваш сервер завис, вы сможете на него зайти и посмотреть, какие транзакции выполняются и какие потоки висят. Но у данного канала есть и другое применение. При обновлении приложения вам не нужно выключать старую версию! Вы можете добавить на сервер новую версию приложения в административном режиме - пользователи продолжают работать со старой, а по административному каналу доступна новая, соответственно мы можем выполнить последнее тестирование перед запуском, проверить все ли у нас правильно развернулось. Затем мы окончательно публикуем приложение, при этом пользователи, уже имеющие сессию, продолжают работать со старой версией, чтобы не потерять данные. Новые пользователи аутентифицируются на новой версии. Тем самым мы обновляем приложение без его простоя, что очень важно для критических систем.

Как мы видим, сервисов, предоставляемых промышленными серверами приложений, довольно много. Возникает вполне закономерный вопрос, а почему сервлет-контейнер TomCat такой популярный? Здесь есть несколько соображений:

  • В первую очередь, цена. За все хорошее нужно платить, за отличное платить еще больше, особенно, если мы хотим доступ к технической поддержке и патчам. К примеру, сервер приложений Oracle WebLogic в базовой комплектации стоит $10 000/processor (под processor здесь понимается одно ядро, умноженное на т.н. core factor ). Не каждый заказчик может себе позволить такое решение.
  • Не всем приложениям нужны вышеперечисленные сервисы, а иногда разработчики не умеют ими пользоваться. Например, если у нас простая учетная система, работающая с одной БД, то нам не нужны распределенные транзакции. С другой стороны, масштабирование. Приложение может следовать всем Java EE спецификациям, но при этом не быть масштабируемым. Простой пример: приложение читает из БД измененные записи (которые пишутся с помощью триггеров в отдельную табличку) и передает их в другую БД. При этом авторы как-то забыли про блокировки. Если мы запустим данную программу на кластере, то у нас каждая запись будет обрабатываться N -раз, по числу экземпляров TomCat в кластере. Такая масштабируемость нам не нужна. Аналогичные соображения можно привести и для других сервисов.
  • Простота и легкость освоения. Вообще администратор сервера приложений это отдельная профессия, такая же как и администратор баз данных. Это не просто линукс-админ. Посмотрим еще раз на список сервисов и задумаемся как долго нужно изучать возможности выбранного сервера приложений по их реализации и настройке. Курсы по администрированию IBM WebSphere или Oracle WebLogic могут стоить десятки тысяч рублей.
  • Сварим кашу из топора сами. Бывают ситуации, когда это необходимо. Не всегда есть смысл ждать патча, исправляющего какие-то критические для нашего приложения ошибки. Гораздо быстрее просто подменить версию библиотеки. Правда зачастую это можно сделать и на сервере приложений, добавив библиотеку к нашему приложению и настроив загрузчик классов. Причем современные сервера содержат в себе утилиты для поиска ошибок в иерархии загрузчиков.

Отдельно отметим причины популярности Spring Framework как на TomCat’ е, так и на промышленных серверах приложений и немного их прокомментируем:

  • Исторические причины. Почему Spring Framework , а не EJB ? Ну потому что я в 88-м году программировал на С++ , фигня этот ваш С++ . Да, действительно EJB 1.1 и EJB 2.x были очень тяжелы для освоения и для использования, но времена меняются. Опять же, начиная с Java EE 6 , появился легковесный IoC -контейнер - CDI . Зачем тянуть в свое приложение сотни мегабайт библиотек, которые будут существенно замедлять процесс развертывания, если можно использовать готовые и довольно качественные реализации, предоставленные производителем сервера приложений? На самом деле иногда есть зачем.
  • Баланс между завязкой на конкретном производителе и переносимостью. Да, EJB это часть спецификации Java EE , причем наиболее сложная, сложнее только J2CA и по хорошему приложения, написанные для одного сервера, должны работать на другом. На практике это не всегда так. Зачастую для эффективного использования всех возможностей сервера приложений приходится в коде вызывать его API , а это уже делает приложение непереносимым. Правда, справедливости ради, с каждой новой версией Java EE таких завязок становится все меньше. С другой стороны, даже без явных завязок на API части стандарта могут быть реализованы разными серверами по своему, например, один сервер будет закрывать EntityManagerFactory при остановке приложения, другой - нет. Реализации иерархии загрузчиков классов так же могут отличаться.
  • При этом, явная завязка на Spring Framework тоже имеет свои минусы. Это такая же завязка на производителе, как и решение использовать только WebLogic . Но если с WebLogic хоть и со скрипом мы сможем уйти, то со Spring Framework скорее всего нет. Что будет, если завтра ведущие разработчики решат оставить свое детище и все дружно перейти в Oracle ? Впрочем, думаю, что вероятность такого сценария не высока.
  • Отдельно стоит отметить поддержку Spring Framework со стороны разработчиков серверов приложений. Например, в Oracle WebLogic можно включить отдельную страницу в консоли администрирования для каждого построенного на данном фреймворке приложения. На странице будет отображено дерево бинов и показаны их свойства. Так же доступны бины самого сервера и упрощена разработка MBean ’ов. Помимо этого, Spring Framework прозрачно интегрируется в кластерное окружение, а Spring Security может использовать подсистему безопасности сервера приложений.

В заключение хочется отметить, что выбор платформы для приложения это довольно нетривиальная инженерная задача, в которой должна учитываться масса факторов. Это и соотношение стоимости разработки к стоимости поддержки (при этом нужно учитывать, что разработка может идти год, а использоваться ПО может десяток лет), стоимость самих серверов приложений, ваши отношения с вендором, т.к. несмотря на высокую номинальную стоимость зачастую предоставляются скидки под 80%. Учитывайте вашу и вашей команды квалификацию в конце концов. Ну и не нужно быть ретроградом, если вы в 2001-м писали на EJB и с тех пор смотреть на них не можете, то это еще не повод отказываться от этой замечательной технологии и реализующих ее серверов приложений, но даже если вы гуру Spring Framework , подумайте, может быть для него на промышленном сервере тоже найдется место?