Rodion Alukhanov[досье]

Нельзя сказать, чтобы среда разработки Java была сильно популярна на платформе Windows. В большинстве случаем на рынке хостинга присутствуют именно Unix решения с поддержкой Java. Но, тем не менее, разрабатываясь как мультиплатформенный язык программирования, Java ни чуть не хуже работает и на Windows платформе, что безусловно может использоваться как для отладки, так и для хостинга приложений на этой платформа. Дополнительную популярность на платформе Windows язык Java, как это ни странно, приобрел после выхода конкурирующего продукта непосредственно от разработчика Windows. Агрессивная политика Microsoft заставила задуматься многих специалистов о разработке более переносимого кода, который "в случае чего" можно будет портировать на Unix платформу с меньшими потерями.

Я не буду здесь касаться проблем выбора языка разработки, равно как и преимуществ одной платформы над другой. Будем считать, что вам просто понадобилась именно такая конфигурация: Windows+Tomcat.

Оглавление

Подготовительный этап

Разумеется любая настройка сервера начинается с подбора необходимых программных компонент. В нашем случае, все компоненты, кроме собственно ОС являются бесплатными или условно-бесплатными и могут быть успешно скачены из Интерента.

И так нам очевидно потребуется:

Компьютер с Windows

Компьютер с установленной Windows.

Здесь и далее я буду рассказывать про Windows 2000 Server, но при этом я не вижу принципиальных сложностей, если вы захотите установить рассматриваемую конфигурацию на любую другую версию Windows. В частности, я по тексту буду упоминать о возможных отличиях в настройке ПО под другие версии ОС.

Если у вас система из NT-семейства, то начните с установки на нее последнего Service Pack (). Для NT очевидно потребуется SP6a, а для Windows 2000 как минимум SP2, без установки которого у вас элементарно не заработает Java 1.4.1. Инсталятор Java SDK вас предупредит о необходимости установки SP2 и будет прав, ибо без SP2 он действительно не работает.

Очевидно также, что на вашем компьютере должна стоять подключенная к сети сетевая карта с установленным и настроенным протоколом /. В случае ее отсутствия, рекомендую установить и настроить виртуальную сетевую карту, т.н. "Microsoft loopback adapter", драйвер которого входит в дистрибутив Windows 2000.

Java JDK

Java очевидно берется с сайта java.sun.com. На момент написания статьи последней была версия 1.4.1_02. Вам потребуется Java 2 JDK Standard Edition (J2SE).

Разумеется соблазнительно скачать сразу Enterprise Edition (J2EE), но как таковой отдельно этой версии не существует. Реализации классов J2EE есть часть соответствующих серверов приложений. Таким образом с сайта можно скачать лишь спецификацию на J2EE и другие подобные документы.

Далее — не стоит скачивать JRE. Во первых, JRE не включает в себя компилятор javac, то не позволяет разрабатывать приложения (что в общем то логично), а, во-вторых, установке Tomcat требует именно JDK. Это также очевидно, т.к. при работе с файлами именно на Tomcat ложится задача по компиляции JSP в байт-код Java. Другое отличие JRE для Windows состоит в отсутствии в его составе серверной версии библиотек JIT-компилятора (подробнее о JIT – см. ниже). Также отмечу, что JDK самодостаточный комплект библиотек и отдельно JRE не нужен.

Tomcat

Tomcat скачивается отсюда — jakarta.apache.org. На момент написания, последний релиз был 4.1.24. В процессе написания статьи я также использовал версию 4.1.18, скаченную мной ранее, мной не было замечено принципиальных отличий. Сайт jakarta немного запутанный, поэтому готовьтесь, что вы прокопаетесь минут 15, пока найдете нужный вам дистрибутив.

Для Windows там вам будет предложено две версии – exe и zip. Первая отличается наличием инсталятора. Этот инсталятор, кроме распаковки архива в указанный каталог, проводит еще ряд действий:

• создает группу в меню "Programs".
• устанавливает Tomcat как сервис в Windows NT.

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

На некоторых зеркалах попадается так называемая "lightweight" версия, которая отличается от обычной отсутствием библиотек Xerces 2.0.1, которые входят в состав JDK версии 1.4. Учитывая, что эта "облегченная" версия меньше "обычной" лишь на 1.5Mb, смысл ее создания мне не очень понятен.

Разное

Очевидно вам потребуется архиватор с поддержкой формата ZIP. Также скачайте программу HandleEx, которая позволит отцеплять от ядра системы JAR библиотеки без перезагрузки машины.

Apache Tomcat 8 для Windows.

Это довольно часто требуется, когда вам нужно удалить библиотеку с целью замены ее на другую версию. Скачивается здесь — www.sysinternals.com.

Начинаем установку

Надеюсь вы уже установили свежий Service Pack и необходимое число раз перезагрузили компьютер.

Установка Java SDK

При установке Java SDK ни в коем случае не ставьте ее в каталог предлагаемый по умолчанию. Введите каталог, путь которого как можно более короткий, без пробелов и других экзотических символов, например:

C:\j2sdk1.4.1_02

Tomcat

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

C:\Tomcat

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

Архив может иметь сложную структуру, соответственно вам нужно распаковать его так, чтобы при входе в каталог у вас отображались были каталоги bin, common, conf, logs и т.д.

Настраиваем Tomcat

Установка PATH

В принципе, установка PATH для работы Tomcat не обязательна и вы можете пропустить этот шаг, но в случае, если у вас установлено несколько Java JRE, установка PATH даст дополнительную подсказку различным программам, где искать библиотеки Java. В частности, без указания PATH может возникнуть конфликт с родной JVM от Microsoft, которая входит в некоторые версии Windows. Кроме этого, установка PATH потребуется для запуска из командной строки компилятора javac, который вам может потребоваться при дальнейшем тестировании сервера.

Таким образом, убедитесь, что у вас на компьютере работает только одна версия Java-машины и эта именно та версия, которую мы поставили. Для этого введите команду

SET PATH

и убедитесь, что в переменной PATH присутствует ссылка только на один каталог . В нашем случае это будет . Здесь будьте внимательны, т.к. java может входить в комплект к огромному числу разных программ, в частности, компания IBM и Oracle. Для верности, отредактируйте переменную PATH таким образом, чтобы ссылка на нашу Java была первой с списке. Напомню, что настройка переменных окружения в NT-семействе производится на вкладке Advanced свойств "Моего компьютера".

Проверить правильность настройки PATH можно так: зайдите в каталог и запустите команды и из каталога . Затем перейдите куда-нибудь в другой каталог и повторите эти команды. Результат должен быть один и тот же.

Установка переменных окружения Tomcat

Теперь перейдем непосредственно к настройке Tomcat. Для своей работы он требует установки нескольких переменных окружения:

• должна указывать на каталог с установленным Tomcat. В нашем случае это .
• должна указывать на каталог с SDK. В нашем случае, это: . Обратите внимания, что, в отличии от переменной , данная переменная указывает не на каталог .

Пожалуйста проверьте правильность установки этих переменных окружения. При неверной установке, tomcat выводит совершенно невразумительное сообщение об ошибке, типа "The system cannot find the file -Djava.endorsed.dirs=.".

Для настройки Tomcat есть еще несколько переменных, но пока они нам не потребуются.

Краткое описание этих и других переменных можно посмотреть в файле

Хотелось бы напомнить, если в дальнейшем планируется запускать Tomcat как сервис (службу) Windows NT, нужно создавать и устанавливать системные переменные окружения (System variables), а не пользовательские (User variables). Также стоит напомнить, что для того чтобы установленные переменные вступили в силу, требуется перезапустить приложение, которое планирует их использовать. В нашем случае следует перезапустить sell (или FAR) из которого планируется тестовый запуск Tomcat.

Настройка порта

По умолчанию Tomcat "садиться" на порт 8080. Если этот порт у вас по каким-то причинам занят – найдите соответствующий параметр в файле и исправьте по вкусу. Этот параметр выглядит приблизительно так:

<Connector className="org.apache.coyote.tomcat4.CoyoteConnector" port="8080" … />

В частности, если вы не планируете использовать IIS для доступа к Tomcat’у, то можете повесить Tomcat на порт 80 (только не забудьте отключить в этом случае IIS).

Отмечу, что, если порт на который вы устанавливаете Tomcat, занят, то Tomcat не запуститься и даже не оставит ни единого сообщения в log-файле. При этом окошко Tomcat’а закроется сразу после открытия. Аналогичная картина будет также в случае, если одна копия сервера уже запущена и случает указанный порт.

Запуск Tomcat

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

Для Windows 9x/ME разработчики также рекомендуют в свойствах файлах и установить параметр "Initial environment" на вкладке Memory в значение как минимум 4096. Т.к. в противном случае возможно аварийное завершение сервиса с сообщением "out of environment space". Это видимо связано с обилием переменных окружения, необходимых для работы сервера.

После этого откройте броузер и обратитесь по адресу http://127.0.0.1:8080. Должен открыться локальный сайт, на котором, кроме прочего, присутствуют тестовые сервлеты и документация к Томкату. Tomcat запускается не сильно быстро, поэтому не торопитесь сразу открывать броузер.

Тюнинг JVM

Компилятор JIT (Just In Time) от Sun предлагает два режима работы – серверный и клиентский. По сути это два различных JIT, вызываемых командой java. В серверном режиме производится более тщательная оптимизация кода.

Разумеется за оптимизацию приходится платить большим временем компиляции, но в случае с сервлетами, компиляция производится лишь единожды. Далее класс используется для обслуживания любого количества клиентов безе перекомпиляции. Таким образом для серверных решений Sun рекомендует использовать именно серверный режим JIT.

Из командной строки тот или иной режим запускается посредством указаний ключа -server или -client первым ключом командной строки.

Следующий важный параметр – объем доступной для виртуальной машины памяти (heap size). Секрет состоит в том, что по умолчанию объем максимально выделяемой памяти равняется 64Mb. Разумеется это катастрофически мало для серверного приложения и, запуская систему со значениями по умолчанию, оперирование в памяти с файлами объемом в пару десятков мегабайт будет приводить к останову сервлета с сообщением OutOfMemory.

Для настройки размеров выделяемой памяти служит два ключа: -Xms и -Xmx, которые отвечают за минимальный и максимальный объем соответственно.

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

CATALINA_OPTS = -server –Xms64m –Xmx256m

Что настроит серверный JIT, плюс установит выделяемый объем памяти в диапазоне от 64 до 256Mb

Установка Tomcat как сервиса

Для установки сервера как сервиса Windows NT, сайт Jakarta предлагает нам выполнить следующую "простую" команду (что любопытно, без каких либо комментариев):

%CATALINA_HOME%\bin\tomcat.exe -install Apache-Catalina %JAVA_HOME%\jre\bin\server\jvm.dll -Djava.class.path=%CATALINA_HOME%\bin\bootstrap.jar;%JAVA_HOME%\lib\tools.jar -Dcatalina.home=%CATALINA_HOME% %CATALINA_OPTS% -Xrs -start org.apache.catalina.startup.BootstrapService -params start -stop org.apache.catalina.startup.BootstrapService -params stop -out %CATALINA_HOME%\logs\stdout.log -err %CATALINA_HOME%\logs\stderr.log

Если попытаться разобраться в этой команде, и отобразим контекстную помощь команды tomcat.exe, то мы получим приблизительно следующее описание параметров:

-install service_name jvm_library (jvm_option) -start start_class [-method start_method] [-params (start_parameter)+] [-stop start_class [-method stop_method] [-params (stop_parameter)+]] [-out out_log_file] [-err err_log_file] [-current current_dir] [-path extra_path]

Таким образом мы последовательно указываем:

• Имя сервиса, которое будет отображаться в оснастке Services Windows.

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

• Указание ссылки библиотеки на библиотеку Java-машины с рядом необходимых параметров. Среди которых и параметры указанные нами в переменной . Собственно эта библиотека и будет загружена как сервис.
• Указания на методы запуска и останова сервиса, также с необходимыми параметрами
• Ссылки на файлы журналов и ряд других необязательных параметром.

Замечу что, рекомендованный код также использует параметр –Xrs для запуска библиотеки Java-машины. Данный ключ позволяет пользовательским приложениям корректно завершить работу в случае получения процессом сигнала на аварийное завершение. К сожалению, мне не удалось выяснить особенности реализации данного подхода в Windows, как и необходимости принятия каких либо дополнительных мер со стороны разработчика кода.

Удаление сервиса производится командой:

tomcat.exe -uninstall service_name

где – указанное нами при установке имя сервиса.

Все введенные нами данные аккуратненько размещаются в реестре по адресу:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Service\<service_name>

Таким образом мы можем исправить отдельные параметры, не проводя перерегистрацию сервиса. Аналогичным образом мы можем исправить имя, отображаемое в оснастке и дать нашему сервису описание. Для этого, соответственно, служат значения и указанного ключа.

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

Конфигурация собственного Web-узла

По умолчанию Tomcat создает лишь один Web-сайт, плюс сваливает все в один каталог. Такое положение вещей редко подходит даже для тестового сервера. Таким образом проделаем несколько шагов для упорядочивания информации.

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

C:\host1

В каталоге conf сервера Tomcat есть файл . В этом файле следует найти элемент . Внутри этого элемента по умолчанию описаны два коннектора: один для доступа по протоколу 1.1 и один для доступа по протоколу AJP 1.3. Первый используется для работы Tomcat’а в роли самостоятельного Web-сервера, а второй потребуется для подключения к IIS. Кроме этого, в теге , по умолчанию заданы шаблоны (закомментаринные по умолчанию) для коннекторов подключения по и AJP 1.2.

Полученные запросы коннекторы передают так называемому Engine’у, который в свою очередь анализируют заголовок пакета HTTP и передает управления соответствующему виртуальному сайту.

Для создания виртуального сайта, нам потребуется создать новый тег Host внутри тега Engine.

Следует отметить, что у файла нет , таким образом вы не сможете проверить корректность отредактированного файла. Таким образом правку файла следует проводить осторожно. При ошибке в файле , сервер не запустится, а в каталоге появится сообщение об этом.

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

<Host name="host1.loc" debug="0" appBase="C:\host1" unpackWARs="true" autoDeploy="true"> <Alias>www.host1.loc</Alias> </Host>

Этой строкой мы создадим виртуальный сайт окликающийся по адресам http://host1.loc и с внутренним именем host1.loc. Кроме того мы указываем серверу, автоматически подключать скопированные в каталог appBase приложения и автоматически разворачивать скопированные туда WAR файлы.

Теперь мы можем скопировать в наш каталог приложение примеров (которое по умолчанию размещено в каталоге ) и убедится, что оно работает по адресу !http://www.host1.loc/examples/servlets. Разумеется, для тестирования в файле HOSTS операционной системы нужно создать записи вида

195.42.130.28 host1.loc 195.42.130.28 www.host1.loc

Указав IP адреса вашей машины.

Замечу, что если мы обратимся просто по адресу http://www.host1.loc, мы получим ошибку, т.к. к этому адресу у нас не привязано ни одного приложения, а функция autoDeploy может привязывать только приложения с адресами http://www.host1.loc/<имя приложения>.

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

<Host name="host1.loc" debug="0" appBase="C:\host1" unpackWARs="true" autoDeploy="true"> <Alias>www.host1.loc</Alias> <Context path="" docBase="examples" debug="0" reloadable="true"> </Host>

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

Учитывая, что перезапуск сервера происходит сравнительно долго, данная функция крайне полезна при разработке.

Заключение

В полученной конфигурации Tomcat может вполне успешно функционировать как на тестовом, так и на production-сервере. Напомню, что в созданной нами конфигурации сервер самостоятельно обрабатывает HTTP запросы. При небольших и средних нагрузках Tomcat вполне справляется с этой ролью, в случае же больших требований, рекомендуется задействовать Tomcat лишь как контейнер сервлетов, а роль Web-сервера передать IIS или Apache.

Apache Tomcat

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

Настройка

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

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

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

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

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

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

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

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

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

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

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

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

Ссылки

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

• Пулы соединений с БД. Да, у TomCat тоже есть пул соединений, но каковы его возможности?

  Установка Java, Apache Tomcat и PostgreSQL в Linux-е

  Может ли он периодически тестировать доступность СУБД и обновлять соединения в случае восстановления после сбоев? Умеет ли он делать замену прав доступа? Грубо говоря, подключаемся к БД под пользователем в зависимости от того, кто аутентифицировался в нашем приложении, если часть логики вынесена на уровень СУБД, то это бывает полезно. Может ли пул соединений Tomcat балансировать нагрузку между несколькими базами данных (например, в случае Oracle RAC), а так же определять, что вот эти узлы RAC умерли и теперь к ним не нужно пытаться подключаться, а затем понять, что они снова доступны и теперь их тоже можно использовать? В конце концов, может ли ваш пул соединений защитить от некорректного кода в приложении, которое по недосмотру не возвращает соединения, просто отбирая его после какого-то таймаута?

• JMS. Если вы хотите использовать очереди в вашем приложении, развернутом на TomCat, то придется отдельно еще поднимать сервера очередей сообщений. В случае сервера приложений, очереди как правило доступны их коробки. Вместе с очередями доступны так же следующие вещи: кластеризация — вы можете строить распределенные очереди, расположенные сразу на нескольких серверах, что существенно увеличивает масштабируемость и доступность вашего приложения, миграция — в случае падения одного из серверов, его очереди автоматически перемещаются на другой, сохраняя необработанные сообщения. В некоторых серверах приложений поддерживается Unit-of-Order — гарантированный порядок обработки сообщений, удовлетворяющих некоторым критериям, очень часто при интеграции бывает полезен.

• JTA. Те самые распределенные транзакции. Кто-то их понимает и использует, кто-то считает слишком тяжелыми. Как правило это так, они слишком тяжелые, но если вам нужно обеспечить согласованность данных в СУБД, разнесенных по разным углам нашей необъятной, или в СУБД и очереди, то без таких транзакций будет трудно. Суть распределенных транзакций в том, что мы не коммитим ни в одну из БД, пока не убедимся, что все БД, участвующие в транзакции, смогут принять наши данные. Тем самым мы избегаем проблемы “с одного счета в одном банке деньги списали, а на другой — в другом банке — не зачислили — сработало ограничение целостности”.

• Безопасность. Современные сервера приложений предоставляют множество различных провайдеров безопасности.

  Доступны различные провайдеры аутентификации, вы можете хранить ваших пользователей во множестве мест: во встроенном LDAP-сервере, в базе данных, во внешнем LDAP-сервере, в различных Internet-directory — специализированных приложениях для управления правами доступа. Возможны следующие сценарии: на работу наняли человека, добавили его в Internet-directory/Access-manager, там запустился процесс раздачи прав, который выдал человеку права на все ресурсы вашего предприятия и теперь каждый сервер приложений в вашей компании (а их может быть очень много) видит эти права, так как подключен к этой 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, подумайте, может быть для него на промышленном сервере тоже найдется место?