Сервер приложений java linux

Итак — ваше веб-приложение готово для развертывания на сервере. Заказчик оповещен о том, что все работает и осталось только несколько штрихов, — и он просит продемонстрировать это веб-приложение, разместив его на вашем сервере или на сервере заказчика. Как правило, это Linux. Пока проект жил и творился под бдительным контролем RAD-среды, например JBuilder, все было хорошо. К счастью, эта или аналогичная ей среда может без труда сгенерировать строку со всеми необходимыми атрибутами для запуска вашего веб-приложения. И теперь вам нужно показать ваше приложение миру :-).

Начнем с некоторых определений, которые понадобятся нам в дальнейшем.

Что такое v1.X JK?

Самое простое объяснение — это модули (библиотеки), которые являются реализацией своеобразных каналов общения между веб-серверами и Tomcat (являющимся самым популярным на сегодня JSP/servlet-контейнером). Они заменяют предшествующие серверные модули — mod_jserv, имевшие много недостатков. Новые модули JK предусматривают поддержку более широкого ряда веб-серверов, лучше взаимодействуют со SSL, реализуют протокол AJP13, а также осуществляют поддержку более широкой линейки Tomcat, начиная с версии 3.2.x и вплоть до 5.x.

Инсталляция Tomcat и Apache

Прежде чем продолжить эксперименты, необходимо убедиться, что у вас есть все компоненты, необходимые для конфигурации Tomcat. Вам нужно будет инсталлировать следующее:

Apache 1.3.xx;
Jakarta-Tomcat 4.1.xx;
mod_jk v1.x

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

Обратите внимание, что версии, в названии которых присутствует LE (light edition), не включают документации и примеров приложений. Кроме того, там отсутствуют некоторые библиотеки — и, как следствие, соответствующие возможности. Эти версии специально оптимизированы для работы с JDK 1.4. Лучше загрузите полную версию.

Если в качестве сервера используется Linux-система с поддержкой rpm, то rpm-пакет с Tomcat можно скачать по адресу.

После инсталляции этого дистрибутива вам будет предложено активизировать tomcat-сервис с помощью Linux-утилиты snsys. Лично на меня этот факт произвел очень благоприятное впечатление. В RedHat-дистрибутивах вместо этой утилиты можно использовать setup.

Как только вы загрузите все указанные компоненты, переходите к следующим шагам:

Установите Apache, как указано в его документации (скорее всего, он у вас уже установлен. Даже если это не так, то его инсталляция с rpm-пакета не должна вызвать у вас каких-либо затруднений);
Протестируйте Apache, стартуйте его (обычно это происходит автоматически после инсталляции). Если старта не произошло, используйте утилиту snsys для активации Apache как сервиса, после чего перезапустите Linux или просто запустите демон как обычное приложение.

Если у вас нет утилиты snsys или setup для активизации сервисов, а вы все же собираетесь инсталлировать ваши сервера как сервисы, то не отчаивайтесь — все это не так уж сложно прописать и вручную (ниже этот процесс будет описан более подробно).

Откройте окно вашего браузера: http://localhost — в случае локального тестирования, или соответствующий адрес вашей Linux-машины — если вы тестируете Apache с вашего рабочего места (я, например, делал это с использованием ssh). Вы должны теперь увидеть нечто подобное тому, что показано на рис. 1.

Установить Tomcat не сложно — просто следуйте документации. Собственно, его инсталляция сводится либо к запуску rpm-пакета, либо (если вы скачали архив) к простой разархивации в выбранную вами директорию. Установите переменную среды окружения JAVA_HOME (указывающую на корневую директорию, где была установлена JDK) и CATALINA_HOME (указывающую на корневую директорию, которую вы выбрали для установки Tomcat).

Теперь проверяем, заработал ли Tomcat. Запустите его и, используя ваш браузер, перейдите на станицу http://localhost:8080 — или страницу с соответствующим адресом вашей Linux-машины. Не забудьте добавить:8080 — Tomcat прослушивает запросы не на стандартном HTTP-порту 80, а на порту 8080.

Вы увидите что-то вроде изображенного на рис. 2.

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

Если на данный момент для ваших целей хватит Tomcat и интеграция с Apache вам не нужна — пропустите следующую главу и сразу переходите к инсталляции (развертыванию на сервере) вашего приложения.

Интеграция между Tomcat и Apache

Пришло время, чтобы начать фактическую интеграцию между Apache и Tomcat. Этот процесс может быть условно разбит в две части: конфигурирование Tomcat и конфигурирование Apache.

Конфигурирование Tomcat

Чтобы научить ваш Tomcat понимать Apache, нужно сначала сообщать ему, что он должен начать слушать запросы от Apache. Для этого служит протокол AJP13 — для связи с Tomcat его используют как JK, так и JK2. Для установки этой связи в настройках нужно добавить дополнительный -элемент в CATALINA_HOME/server.xml (файл Tomcat). Добавьте следующую секцию к server.xml, убедитесь в том, что эта секция находится внутри тега и следует сразу за любыми определенными до этого -элементами.

Как правило, эта секция уже определена в server.xml — и во время старта Tomcat начинает прослушивать запросы как от HTTP-клиентов на порту 8080, так и от Apache на порту 8009. Если вы нашли в вашем server.xml что-то подобное, пропустите этот шаг. Проверьте также наличие самого файла класса внутри пакета, и если он называется не так, скорректируйте его название в записи. Выглядеть она должна следующим образом:

Атрибут port сообщает Tomcat, что ему нужно открыть новый Connector, который слушает порт 8009 для входящих запросов. Атрибут className сообщает Tomcat, что все запросы, приходящие на этот порт, должны обслуживаться java-классом «org.apache.ajp.tomcat4.Ajp13Connector», который также использует протокол AJP 1.3.

Конфигурирование Apache

Теперь, когда Tomcat сконфигурирован, чтобы слушать на порту 8009 для обслуживания запросов AJP13, давайте сообщим Apache, что мы хотим, чтобы он поговорил с Tomcat, используя этот порт и протокол. Этот процесс относительно прост — немногим сложнее аналогичного конфигурирования Tomcat.

Начнем конфигурацию Apache с того, что создадим Tomcat worker definition — определение для Tomcat worker. Это определение сообщит Apache, как и когда говорить с Tomcat. Для этого создадим Tomcat-working-файл, содержащий необходимые определения хотя бы для одного такого Tomcat worker’а. Tomcat worker — это процесс, создающий коммуникационный линк между Apache и Tomcat. Процесс-посредник необходим в данном случае для того, чтобы внутри него создать клиентский сокет, который будет посылать запросы к коннектору Tomcat и получать ответы.

В нашем примере назовем файл конфигурации workers.properties и скопируем его в /conf-директорию Tomcat. ( — это базовая директория вашей установки Tomcat.). Теперь добавьте туда следующие строчки:

worker.list=myWorker
worker.myWorker.port=8009
worker.myWorker.host=localhost
worker.myWorker.type=ajp13

Эти данные определяют имя посредника — myWorker. Он находится на том же Linux box, что и сервер Apache, localhost, и слушает порт 8009 для клиента, использующего протокол AJP13.

worker.list — определяет список рабочих (перечисляемых через запятую), посредством которых он будет общаться с Apache. Этот список может определять любoe количество рабочих Tomcat.

В данном примере определяем единственного рабочего — myWorker. Как только мы назвали рабочего, можем модифицировать его атрибуты, явно используя следующий синтаксис:

worker.myWorker + Имя атрибута = Значение

Все, что мы модифицировали в этом примере, это три атрибута нашего рабочего: порт, хост и тип протокола. Все они достаточно понятны, а потому не требуют дополнительного объяснения.

Хотелось бы отметить, что на самом деле сохранение файла описания workers в /conf является скорее хорошей традицией, чем правилом. Это совсем не обязательно — и вы можете сохранить этот файл где угодно. Но традиции лучше не нарушать.

Далее скопируйте коннектор в поддиректорию libexec/ сервера Apache.

Модификация httpd.conf конфигурационного файла Apache

Откройте этот файл для редактирования и добавьте в его конец следующие строки:

# загружаем модуль:
# for windows box:
# LoadModule jk_module libexec/mod_jk-1.3.26.dll
# for Linux box:
LoadModule jk_module libexec/mod_jk2-1.3-noeapi.so
AddModule mod_jk.c
#JkWorkersFile C:/Tomcat4_1_12/conf/workers.properties
JkWorkersFile /var/tomcat4/conf/workers.properties
# for windows box:
# JkLogFile C:/Tomcat4_1_12/logs/mod_jk.log
# for Linux box:
JkLogFile /var/tomcat4/logs/mod_jk.log
JkLogLevel debug
# for windows box:
# Alias /examples C:/Tomcat4_1_12/webapps/examples
# for linux box:
Alias /examples /var/tomcat4/webapps/examples
JkMount /examples/servlet/* myWorker
JkMount /examples/*.jsp myWorker

AllowOverride None
deny from all

Tеперь посмотрим, что происходит при старте Apache.

Apache находит запись о том, что ему необходимо загрузить дополнительный модуль. Модуль, загрузившись, сам начинает читать все необходимые ему настройки. Прежде всего, он определяет количество и характеристики рабочих, которых ему надо создать. Далее определяются маски файлов (пути указываются абсолютно — от корня вашего сервера). Рабочие будут переадресовывать Tomcat запросы с соответствующими расширениями и получать ответы, передавая их обратно в Apache. Выглядят эти ответы так:

JkMount /examples/servlet/* myWorker
JkMount /examples/*.jsp myWorker

Обратите внимание: для каждой такой маски в соответствие ставится определенный рабочий.

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

Хотелось бы еще отметить стандартный для Apache тег — он создает виртуальный каталог для Apache (используется терминология Microsoft, но более точного определения не подобрать), для того чтобы обслуживать запросы к страницам, которые не попали в маски файлов для JK,- то есть к статическим файлам или файлам, обрабатываемым другими серверными препроцессорами (например, PHP), минуя при этом сервис рабочих JK.

Теперь запустите Tomcat и Apache.

Развертывание веб-приложения на Tomcat

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

Предположим, что JBuilder автоматически создал файл report.war вашего проекта, где report — имя проекта, заданное в визарде при создании скелета приложения.

Для того чтобы приложение стало доступно для Tomcat, скопируйте этот файл в CATALINA_HOME/webapps/.

Теперь все, что остается сделать, это прописать необходимые сведения в файл CATALINA_HOME/conf/server.xml.

Найдите то место, где начинается описание контекста приложения examples. Эта запись должна начинаться со строки вида:

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

Теперь несколько коротких пояснений по этому примеру.

Как можно заметить, имя нашего файла приложения в этом примере — report.war. Относительный адрес хоста приложения при этом «./report/» от корня сервера, то есть полный адрес вашего приложения — http://host/report/index.jsp (при условии, что первая страница — это index.jsp).

reloadable=»true» — сообщает, что приложение не нуждается в перезапуске сервера и автоматически будет обновлено, если вы скопируете на место старого файла *.war его новую версию.

crossContext=»true» — сообщает серверу, что этот каталог будет доступен также и из других веб-приложений.

Запустите Tomcat — и увидите, что архив вашего приложения автоматически развернулся в папку в CATALINA_HOME/webapps/.

Если вы хотите, чтобы этого не происходило, найдите запись:

— и присвойте параметру unpackWARs значение «false».

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

WEB-INF/lib-директория в вашем *.war-файле не содержит оных библиотек.
Названия библиотек оканчиваются расширением *.zip. Странно, но Tomcat в таком случае не видит их. Измените расширение этих файлов на *.jar и перезапустите сервер.
Точные копии ваших библиотек находятся еще в каком-то каталоге /lib Tomcat.

Впрочем, стоит заметить, что для последних версий Tomcat эта проблема была устранена.

В ближайшем будущем мы рассмотрим также некоторые тонкости и подходы при создании Java веб-приложений на примере создания простого веб-приложения с использованием технологии Java2.

Надеюсь, эта статья окажется полезной для всех, кто собирается разрабатывать собственные веб-приложения с использованием технологии Java на Linux-сервере.

AJP 13

AJP 13 — это протокол, который позволяет веб-серверу общаться с Tomcat JSP/servlet контейнером посредством TCP-соединения. Все, что нам необходимо знать для наших целей, это то, что AJP13 является более эффективным протоколом, чем его предшественники, и включает лучшую поддержку для SSL.

Более подробная информация доступна по адресу.

Источник

Обзор серверов приложений Java и JavaEE

Многие разработчики используют сервер приложений Java с открытым исходным кодом. Я задумался над альтернативами Glassfish и решил немного изучить другие.

Расскажу про лучших 10 серверов приложений Java и JavaEE с открытым исходным кодом.

Что такое сервер приложений?

Сервер приложений часто можно описать как программную среду, которая находится на среднем уровне серверно-ориентированной архитектуры.

Сервер приложений часто можно рассматривать как часть трехуровневого приложения, которое представляет собой сервер графического пользовательского интерфейса (GUI), сервер приложений (бизнес-логики) и сервер базы данных и транзакций и предоставляет услуги для обеспечения безопасности и поддержания состояния.

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

Для тех кто далек от темы, объясню — это позволяет вам писать код для запуска на сервере и код на клиенте и разрешать им общаться друг с другом. Разработчики, которые предъявляют повышенные требования к производительности могут взять в аренду сервера rackstore.ru

GlassFish

GlassFish — это проект первоначально начатый Sun Microsystems для платформы Java EE, а теперь являющийся частью корпорации Oracle. Он доступен по двойной лицензии:

Общая лицензия на разработку и распространение (CDDL);
Стандартная общественная лицензия GNU (GPL) с исключением пути к классам.

Oracle больше не предоставляет коммерческую поддержку GlassFish Server.

GlassFish часто рассматривается как эталонная реализация Java EE и поэтому поддерживает Enterprise JavaBeans (управляемая серверная архитектура компонентов для модульного конструирования корпоративных приложений), JPA (Java Persistence API), JavaServer Faces, JMS (Java Message Service), RMI (Java Remote Method Invocation), JavaServer Pages, сервлеты и многое другое.

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

Он построен на модульном ядре на базе OSGi и работает прямо поверх реализации Apache Felix. Он также может работать с Equinox OSGi или Knopflerfish OSGi. HK2 абстрагирует систему модулей OSGi для предоставления компонентов, которые также можно просматривать как сервисы и внедрять во время выполнения, и использует производную Apache Tomcat в качестве контейнера сервлета для обслуживания веб-контента, с добавленным компонентом Grizzly, который использует Java New I/O (NIO) для масштабируемости и скорости.

Платформа корпоративных приложений JBoss

Платформа JBoss Enterprise Application Platform, также известная как JBoss EAP, является платформой с открытым исходным кодом (доступной в рамках Стандартной общедоступной лицензии GNU). Используемая для создания, развертывания и размещения высокотранзакционных приложений и служб Java. Она также доступна в качестве сервера на основе подписки. Платформа JBoss Enterprise Application Platform является частью более широкого портфеля программного обеспечения, известного как портфель JBoss Enterprise Middleware.

JBoss работает кроссплатформенно и может использоваться в любой операционной системе, поддерживающей Java. Его основные функции включают поддержку стандартов Java EE и веб-служб, Enterprise Java Beans (EJB), сохранение Java с использованием Hibernate, брокер объектных запросов (ORB), использующий JacORB для взаимодействия с объектами CORBA, инфраструктуру JBoss Seam, включая аннотации Java, JavaServer Faces (JSF), включая RichFaces, службы веб-приложений, в том числе Apache Tomcat для страниц JavaServer (JSP) и сервлеты Java.

JBoss включает в себя службы безопасности, в том числе службу аутентификации и авторизации Java (JAAS) и подключаемые модули аутентификации (PAM), а также дополнительные веб-службы и средства взаимодействия, в том числе JAX-RPC, JAX-WS, многие стандарты WS- * и MTOM / XOP.

Wildfly

WildFly, более известный как JBoss AS — это сервер приложений, созданный JBoss, но в настоящее время постоянно развивающийся Red Hat. WildFly написан на Java и реализует спецификацию Java Platform, Enterprise Edition (Java EE) отдельно от JBoss Enterprise Application Platform.

WildFly — это бесплатное программное обеспечение с открытым исходным кодом, доступное по лицензии GNU Lesser General Public License (LGPL), версия 2.1. Wild Fly в настоящее время находится в 8.2.0 Final и 9.0.0Beta2 Release.

Некоторые из функциональных возможностей и функций, включенных в WildFly: кластеризация, API развертывания, распределенное кеширование (с использованием Infinispan, автономный проект), распределенное развертывание, Enterprise JavaBeans версий 3 и 2.1, отказоустойчивость (включая сеансы Web и EJB), постоянное программирование, аутентификацию Java и Служба авторизации (JAAS), интеграция Java EE Connector Architecture (JCA), расширения Java Management, интеграция службы сообщений Java (JMS), интерфейс именования и каталогов Java (JNDI), API транзакций Java (JTA), контракт авторизации Java для контейнеров, (JACC) интеграция JavaMail, Java Server Faces 1.2 (Mojarra) Java Server Pages (JSP) / Java Servlet 2.1 / 2.5

Wildfly также поддерживает веб-сервисы, такие как балансировка JAX-WSJDBCLoad, и включает в себя API-интерфейс управления, OSGi frameworkRMI-IIOP и может выполняться в двух режимах сервера: традиционный, одиночная JVM, автономный режим и вариант с несколькими JVM, режим домена, который синхронизирует конфигурацию между любым количеством процессов и хостов.

Apache Tomcat

Apache Tomcat — это программная реализация с открытым исходным кодом технологий Java Servlet и JavaServer Pages, выпущенная по лицензии Apache License version 2 и разработанная Apache Software Foundation (ASF). Apache Tomcat реализует несколько спецификаций Java EE, в том числе Java Servlet, JavaServer Pages (JSP), Java EL и WebSocket, и предоставляет среду веб-сервера HTTP на «чистой Java» для запуска кода.

Apache TomEE

Apache TomEE — это корпоративная версия Java Apache Tomcat, которая объединяет несколько корпоративных проектов Java, в том числе Apache OpenEJB, Apache OpenWebBeans, Apache OpenJPA, Apache MyFaces.

Веб-профиль Apache TomEE может предоставлять сервлеты, JSP, JSF, JTA, JPA, CDI, проверку бинов и EJB Lite, а также предоставляет JAX-RS (службы RESTfull) плюс EJB Full, архитектуру коннектора Java EE, JMS (служба сообщений Java) и JAX -WS (веб-сервисы) и включает поддержку Mojarra и EclipseLink.

Apache Geronimo

Apache Geronimo — это сервер, разработанный Apache Software Foundation и распространяемый по лицензии Apache. Apache Geronimo совместим со спецификацией Java Enterprise Edition (Java EE) 6 и поддерживает различные технологии, такие как JMS, Enterprise JavaBeans, коннекторы, сервлеты, JSP, JSF, Unified Expression Language и JavaMail.

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

Jetty

Jetty — это HTTP-сервер на основе Java и контейнер сервлетов, бесплатный проект с открытым исходным кодом в рамках Eclipse Foundation (изначально он разрабатывался как независимый проект с открытым исходным кодом).

Веб-сервер является относительно популярным и используется в таких продуктах, как Apache ActiveMQ, Alfresco, Apache Geronimo, Apache Maven, Apache Spark, Google App Engine, Eclipse, API потоковой передачи Twitter, а также поддерживает последнюю версию Java Servlet API (с поддержкой JSP) в качестве: а также AJP, JASPI, JMX, JNDI, OSGi, SPDY и WebSocket.

JOnAS

JOnAS — это открытая реализация спецификации сервера приложений Java EE, выпущенная по лицензии LGPL с открытым исходным кодом и разработанная и поддерживаемая консорциумом ObjectWeb (ObjectWeb — это некоммерческий европейский консорциум).

JOnAS предоставляет полностью совместимый EJB-контейнер через EasyBeans и доступен со встроенным веб-контейнером Tomcat или Jetty, который поддерживает 1.6 JVM, и может работать в различных операционных системах, включая Linux, Windows, AIX и многие платформы Posix.

Версия 5 JOnAS полностью основана на платформе OSGi; использование Apache Felix, Eclipse Equinox или Knopflerfish, что означает, что компоненты JOnAS упакованы в пакеты и содержат инструменты для создания, развертывания и мониторинга кластеров JOnAS; он также включает в себя функции самоуправления.

Resin

Resin — это веб-сервер и сервер приложений, созданные компанией Caucho Technology. Доступен по лицензии GPL и коммерческой лицензии. Коммерческая лицензионная версия Resin Pro доступна для корпоративных и производственных сред. Resin поддерживает стандарт Java EE, а также механизм mod_php / PHP, известный как Quercus.

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

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

Веб-сервер включает в себя поддержку статических файлов / JSP / Servlet / JSF, перезапись URL-адресов, кэширование прокси, сжатие Gzip, SSL, виртуальные хосты, отправку Comet / Server и WebSockets.

Blazix

Blazix — это полнофункциональный сервер приложений Java и веб-сервер (обслуживающий HTML-файлы и изображения в дополнение к стандартной рабочей нагрузке сервера приложений). В настоящее время Blazix предоставляет Servlet 2.3, JSP 1.2, EJB 1.1 и JMS 1.0.2. Он также реализует HTTP / 1.1 и полностью написан на Java, и может использоваться кроссплатформенно. Он может использоваться в качестве полноценного веб-сервера сам по себе, особенно при большом объеме трафика.

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

Средняя оценка / 5. Количество голосов:

Спасибо, помогите другим — напишите комментарий, добавьте информации к статье.

Или поделись статьей

Видим, что вы не нашли ответ на свой вопрос.

Источник

Читайте также: Fan control windows это