Что такое сервер приложения / Хабр
Когда вы открываете любой сайт — например, google или facebook, вы видите конечный продукт. Но чтобы этот продукт увидеть, и пощупать, нужно:
Написать код приложения
Собрать проект
Поднять его на сервере приложения
Сегодня я расскажу про третий этап: что вообще такое сервер приложения и зачем он нужен.
Что это такое и зачем он нужен
Жила была Анечка. Она пекла вкусные кексики и тортики на заказ. Чтобы удобнее было делать заказ, решила Анечка сделать свой интернет-магазин. И обратилась за помощью к брату, разработчику Ване.
Ваня говорит:
— Да не вопрос!
Он как раз занимается фриланс-заказами с простыми системами типа интернет-магазинчиков. Поэтому он быстренько написал код на php. Но код — это просто набор файликов с расширением .php.
А как сделать так, чтобы у нас в интернете появилась страничка? Для этого нужен сервер приложения. Ваня для магазинчика выбирает apache (Apache HTTP Server), как наиболее популярный.
Мои тестовые системы:
— Users
— ShopТоже подняты на Apache. И написаны на php, то есть не требуют сборки))
Сервер обеспечивает возможность обращаться с приложением по HTTP-протоколу. Вы, конечно, можете и сами написать такой код, но зачем? Когда для этого уже есть готовая система. Причем бесплатная и open-source.
Положили код PHP в сервер. Запустили — вуаля, оно работает! Теперь у Анечки есть свой интернет-магазин, доступный извне, с любого устройства.
Если бы код был не на PHP, а на Java, у нас добавился бы шаг «собрать проект» — из набора текстовых файликов получить приложение. Обычно это архив, например, test.war. И уже его мы подкладываем в сервер. Ну а PHP — интерпретируемый язык. Ему не нужен сборщик.
Конечно, пока сайт доступен только по его IP. Чтобы это исправить, Анечке нужно выбрать доменное имя и купить домен. И тогда уже будет красивое название:
http://46.
36.217.134:80/ → http://shop.cakes.ru/
36.217.134:80/ → http://shop.cakes.ru/Вот теперь точно все готово!
Использование сервера приложений помогло Ване сконцентрироваться именно на бизнес-логике программы, не отвлекаясь на детали обеспечения транспортного пути. Ведь сервер приложения — это подобранный набор согласованных по версиям инфраструктурных библиотек. Например, http-сервер, который умеет принимать запросы.
Преимущества серверов приложений
Готовый HTTP-сервер
Пожалуй, самая важная и популярная функция сервера приложений — поддержка HTTP-сервисов и текущих HTTP-стандартов. Зайдите на любой сайт в интернете — фактически вы отправляете HTTP-запрос в приложение:
Да, можно написать обработку запросов самостоятельно. И следить за стандартами, постоянно обновлять код… Но зачем, когда есть готовый сервер?
Для небольших проектов хватает HTTP-сервера, без дополнительных функций и плюшек. На текущий момент самый популярный сервер — Apache HTTP Server.
Есть и более сложные сервера, например, Wildfly. Они имеют больше функций и используются в энтерпрайз системах.
Систему Users мне делал фриланс разработчик. Она написана на PHP и поднята на сервере Apache.
А на работе у меня на одном из проектов был enterprise продукт.. Написан на Java, поднимается на сервере Wildfly.
Поддержка горячего резерва
Если упал сервер, то есть испортилось 1 звено в клиент-серверной архитектуре — всё, все в ступоре, все отдыхают. Сотни, тысячи, да хоть миллионы клиентов если есть — никто не может работать. Открываешь сайт в интернете и грустно смотришь на окно «Простите, что-то пошло не так»
Именно поэтому в бизнес-критичном ПО архитектуру усложняют и даже дублируют. Банк с тысячами операционистов не может позволить себе простой. Поэтому они используют кластер серверов — один упал, остальные работают.
Сервера в кластере называются нодами. На каждой ноде (железке) стоит свой wildfly (или аналог).
Когда приходит запрос на одну ноду, она оповещает об этом вторую, третью, четвертую, или сколько их там будет.
Каждая нода может обработать запрос независимо. Если приложение имеет какое-либо состояние, то оно может быть сохранено в общую БД. А также ноды могут оповещать другие ноды об изменении состояния через очереди/топики.
Такая схема называется горячим резервом — когда у нас есть несколько работающих в параллели серверов. Может быть и схема холодного резерва, когда второй сервер у нас «на всякий случай», а не для постоянного использования.
Но какой бы ни был резерв, фишка в том, что синхронизацией занимается сервер приложения, а не разработчик. У разработчика не болит голова о том, как бы данные на разных серверах не разъехались. Он может сосредоточиться на бизнес-логике системы.
Централизованная настройка и управление
В сервере приложений обычно есть админка. Заходишь по специальному URL — и у тебя есть доступ к настройкам приложения.
Вот так выглядит приветственная страница админки wildfly:
Если у вас несколько серверов приложения, то изменение настроек может быть опасным занятием. Одну ноду (сервер) обновили, вторую забыли, а потом ловим баг.
Но так как сервер поддерживает работу в кластере, то все упрощается:
Мы меняем настройки в админке.
Они сами расползаются по всем нодам.
Безопасность
В больших бюрократических компаниях разделяют разных админов:
админ физического сервера (железка, на которой установлено ПО)
админ сервера приложений (например, wildfly)
Так вот, админу приложения дают доступ только в админку wildfly. Физически на сервер он зайти не может, или может, но на птичьих правах, логи почитать. А если нужно параметры системы изменить — извольте заводить заявку для админа железяки.
Так безопаснее, когда у тебя нет лишних прав. Иначе неопытный админ системы может наворотить дел, разгребай потом за ним.
Поэтому чем больше контора, тем важнее иметь возможность разделить права. Сервер приложения позволяет это сделать: OS отдельно, приложение отдельно.
Поддержка транзакций
Сервер поддерживает поддержку XA транзакций — когда несколько транзакционных источников поддерживают распределенную спецификацию, и сервер ее координирует.
Например, что-то записали в БД и послали сообщение по JMS, всё в одной транзакции, вот сервер приложений предоставляет в том числе менеджера распределенных транзакций.
Фишка всё та же — пока сервер приложений выполняет массу инфраструктурного кода, разработчики могут сфокусироваться на бизнес-логике.
И наверняка есть что-то еще
Я честно пыталась выведать у знакомых разработчиков, зачем вообще сервер приложения нужен.
Оказалось, что он, в общем-то, и не особо нужен. Ну разве что как HTTP-сервер, хотя и для этого уже есть готовые библиотеки, можно в коде это все делать и запускать условный Main.
java, без всякого дополнительного сервера.
На работе в одном из проектов мы использовали wildfly. Он дает кучу возможностей, но по факту мы использовали:
• HTTP-сервер — а куда же без него?
• Datasource — файл, где прописывается соединение с БД
• MQ-очереди — для горячего резерва, синхронизация нод между собой. Один сервер уведомляет другой об изменениях. Если другой сервер пока занят, то это сообщение встает в очередь.Вот и всё!
Иногда сервер приложений используется просто потому, что так принято. Например, все старые приложения поднимались на Jboss, ну и новые тоже требуют делать на нем же. Потому что админы умеют работать именно с ним.
Или безопасники требуют разграничить доступ. Или по другим причинам используется именно этот сервер приложения, а не какой-то другой.
При этом я уверена, что в каких-то компаниях используют сервер приложения на полную катушку. И что в разных серверах есть еще куча разного полезного функционала, который вы могли бы написать сами в коде, но.
.. Зачем? Когда вот оно, готовое.
Можно обойтись и без сервера. Да. Но с ним удобнее =)
Другие определения сервера
Когда вы разговариваете с коллегами, очень важно, чтобы вы говорили на одном языке!
Поэтому учтите, что под сервером приложений могут понимать разные вещи:
Сервер приложения как ПО — Apache, Wildfly, и другие. Та программа, которая запускает ваше приложение.
Физический сервер — компьютер, на котором установлен wildfly
Вот, например, одно из определений:
Сервер приложений — это сервисная программа, которая обеспечивает доступ клиентов к прикладным программам, выполняющимся на сервере. Сервер приложений обычно выделяется как среднее звено в трехуровневой клиент-серверной архитектуре (3-tier)
Тут сервером называется именно программа. А вот другое определение:
Сервер приложений это набор физического и программного обеспечения, которое способно обеспечить доступ клиентов к программам, выполняющихся непосредственно на серверном оборудовании.
Тут уже сервером называют не только программное обеспечение, но и физический сервер.
Так что если сомневаетесь, что вы с собеседником говорите об одном и том же, лучше уточнить, что он имеет в виду!
Дополнительные материалы
List of application servers
Top 10 Open Source Java and JavaEE Application Servers
Итого
Сервер приложения — это ПО, которое запускает ваше приложение. Сначала разработчик пишет код, потом собирает билд сборщиком… Но это просто некий архив с кодом. А вот чтобы это стало доступной в интернете ссылочкой, и нужен сервер приложения.
Сервер берет на себя скучную инфраструктурную работу. Например, организацию HTTP-уровня OSI. Он принимает запросы и обрабатывает их по всем стандартам. А разработчик может сконцентрироваться на бизнес-логике, не отвлекаясь на детали обеспечения транспортного пути.
Другие статьи из цикла «Что такое…»
Что такое VCS (система контроля версий)
Что такое сборщик продукта
Что такое API
Что такое XML
Что такое JSON
Что такое клиент-серверная архитектура
Что такое CI (Continuous Integration)
Что такое транзакция
Что такое регулярные выражения (regexp)
Что такое Docker
PS — больше полезных статей ищите в моем блоге по метке «полезное».
А полезные видео — на моем youtube-канале
Обзор серверов приложений и, конечно же, Tomcat
Дорогие джаварашовцы, что я хочу рассмотреть в этой статье? Я просто хочу сделать небольшой обзор той части серверов приложений, которые заслуживают внимания хотя бы тем, что являются бесплатными и доступен их исходный код. Я буду исходить из того, что ваша система сходна с моей. У меня стоит Windows 7 64 бита, кроме того у меня стоит JDK 1.7 и JDK 1.8, а переменная окружения JAVA_HOME ссылается на последний из них. В моем случае это значит, что в JAVA_HOME прописан путь C:\Program Files\Java\jdk1.8.0_31.Чтобы у вас при повторении ниже описанного возникало как можно меньше вопросов типа «а почему у меня не получилось, может я что-то не так делаю?», я буду пытаться описывать каждое действие, которое я делал на своей машине. Начинаем…
Кастинг, т.е. отбор
Для начала нужно отобрать сервера приложений для нашего обзора.
- Glassfish (не проприетарный, а тот, что от сообщества glassfish.java.net, но который поддерживается корпорацией Oracle до такой степени, что если нужен javaEE SDK с сайта Oracle, то тебе впиндюрят и этот сервер приложений, иначе никак)
- (Red Hat) WildFly (бывший JBoss)
- (Apache) Geronimo
- (Apache) Tomcat (это лишь контейнер сервлетов, а не сервер приложений, но он является таким эталоном, на котором, если программа написана правильно, то она точно заработает. На других серверах программа может быть написана правильно с точки зрения JavaEE, но работать все равно будет не корректно или вообще не будет. Это я о Geronimo, о глюках которого можно говорить долго)
На других серверах программа может быть написана правильно с точки зрения JavaEE, но работать все равно будет не корректно или вообще не будет. Это я о Geronimo, о глюках которого можно говорить долго)Теперь давайте накачаем этих серверов.
- Для Tomcat это будет сайт http://tomcat.apache.org.
- Для Glassfish – сайт http://glassfish.java.net.
- Для WildFly – сайт http://wildfly.org.
- И, наконец, для Geronimo – сайт http://geronimo.apache.org.
Установка
В плане установки все просто и для каждого из выбранных серверов установка – это просто распаковка архива. Я, например, создал папку AppServers на рабочем столе, куда и стал всё распаковывать.
Настройка
Настройку серверов начнем с настройки порта HTTP, на котором он будет работать.
Потом пропишем себя как админа сервера. Для каждого из серверов есть свои особенности настройки. Для Tomcat. Заходим в папку с распакованным tomcat, далее папка conf, файл server.xml. Находим в этом файле число 8080 (http порт по умолчанию) и меняем его на что захотим. Я поставил 9713.
Чтобы прописать себя как админа сервера нужно, находясь в этой же папке, открыть файл tomcat-users.xml
Должно все заработать и мы увидим тигру.
Теперь давайте проверим наличие доступа в админку. Для этого переходим по адресу http://localhost:9713/manager, вводим выбранные логин и пароль и получаем доступ.
УРА! Можно временно отключить Tomcat, для этого достаточно закрыть консоль, в которой он работает. 
Далее, попав на красивую построенную на JSF страницу административной консоли, жмем пункт Change Administrator Passwordи вводим нужный нам пароль для пользователя admin, потом подтверждаем его и жмем кнопку Save.
При последующих входах в административную консоль нужно будет указывать логин admin и заданный пароль.
Теперь можно временно отключить Glassfish, для этого достаточно закрыть консоль, в которой он работает. Для WildFly. Заходим в папку с распакованным wildfly. Далее заходим в папку standalone, потом папка configuration, а в ней файл standalone.xml. Далее действуем по отлаженной схеме. Я поставил порт 9913.
Запустим сервер. Для этого перейдем в папку с распакованным wildfly. Далее заходим в папку bin и запускаем файл standalone.bat. Открываем браузер и вводим адрес http://localhost:9913.
Жмем ссылку Administration Console для входа в админскую консоль (проще говоря, админку сервера приложений).
Для Geronimo. Заходим в папку с распакованным geronimo. Далее в подпапку var, потом в папку config, а в ней файл config-substitutions.properties. В этом файле описаны все используемые сервером приложений порты в удобном формате, но схема замены порта та же. Я поставил порт 10013.
Запустим сервер geronimo. Перейдем в папку с распакованным geronimo, потом в подпапку bin и запустим там файл startup.bat. Переходим на страницу http://localhost:10013. Чтобы вы думали?
Скорее всего, страницы там не будет. Почему? Все дело в том, последняя версия Geronimo (3.0) не может работать с последней версией JDK (1.8), поэтому если у вас стоит только она или пусть даже есть, скажем, 7-ая версия, но переменная окружения JAVA_HOME все равно ссылается именно на 8-ую, как у меня, то запуск сервера приложений не произойдет. Таким образом, для работы Geronimo нужно обязательно скачать JDK 1.7.
Теперь допустим вы поставили 7-ой JDK, но не хотите менять значение переменной JAVA_HOME (в конце-то концов, другие программы на нее не жалуются, а значит пусть и работают с последней версией JDK).
Почему? Черт его знает, особенно если учесть, что согласно данным с форумов, эту ошибку в 3-ей версии Geronimo должны были исправить. Но ни фига подобного. Главное в этом деле не делать пи-пи, если индейцы не исправили, то мы поправим. Для этого есть два способа, которые я предпочитаю комбинировать, чтобы уж наверняка. Во-первых, опять идем а файл 
Поэтому если вы в файле setjavaenv.bat после метки :okJdkFileCheck установите следующее значение переменной JAVA_HOME set JAVA_HOME=C:\Progra~2\Java\jdk1.7.0_75 то у вас тоже заработает сервер Geronimo под управление 32-х битного JDK в 64-х битной операционной системе. Как-то так…
Ну, наконец-то, можно и запускать Geronimo, вызвав startup.bat. Теперь проблем быть не должно. Переходим в браузере на страницу http://localhost:10013. Слева вверху находим ссылку Console и жмем на нее.
Надо ввести админские логин и пароль. Сразу подскажу, что это пользователь system с паролем manager (значения по умолчанию).
Пройдя в саму консоль и проследовав по пунктам меню как на картинке ниже (выбрать радиобатон Advanced, потом выбрать Security > Users and Groups), можно как сменить пароль для пользователя system, так и создать другого админского пользователя, а этого удалить.
Остановить сервер Geronimo можно также простым закрытием окна консоли, в котором сервер был запущен.
Заключение
В этом обзоре я, по сути, просто провел установку и первоначальную настройку популярных серверов приложений и контейнера сервлетов Tomcat. За исключение Geronimo, остальные сервера были очень дружелюбны ко мне и проявили гостеприимство. В следующем посте я продолжу рассмотрение серверов приложений и сделаю 3-ий шаг на пути рассмотрения веб-сервисов, а именно, покажу как задеплоить описанный на первом шаге веб-сервис в эти сервера. Для этого мы создадим war-архив нашего веб-сервиса, и я наглядно покажу, что набор сторонних jar-ников, которые надо включать в этот архив для корректной работы сервиса, сильно меняется от сервера к серверу.
Tomcat против Jetty против GlassFish против WildFly
Василий Зуканов Советы, хитрости и ресурсы для разработчиков
Если вы хотите написать веб-приложение на Java, первое, что вам нужно сделать – это принять сложное решение: выбрать сервер приложений Java.
на котором будет работать ваше приложение. Это сложный выбор, потому что есть много выдающихся, и различия между ними не всегда очевидны. Легко впасть в состояние паралича анализа.
Но давайте отойдем на секунду. Что такое серверы приложений? Вообще говоря, серверы приложений выполняют Java-приложения. Вы запускаете их в своей операционной системе, а затем развертываете в них приложения. Думайте о серверах приложений как о контейнерах, которые запускают ваш Java-код и делают его функциональным. Кроме того, серверы приложений предоставляют некоторую общую инфраструктуру и функциональные возможности, которые можно использовать в собственном коде.
В этой статье я проведу общее сравнение между самыми популярными бесплатными серверами приложений Java и серверами с открытым исходным кодом.
Совет. Мгновенно находите ошибки приложений и проблемы с производительностью с помощью Stackify Retrace
Устранение неполадок и оптимизация кода упрощается благодаря встроенным ошибкам, журналам и анализу производительности на уровне кода.
Tomcat
Tomcat — самый популярный сервер приложений, используемый с веб-приложениями Java, разработанными Apache Software Foundation. Некоторые источники утверждают, что доля рынка Tomcat превышает колоссальные 60% всех приложений Java 9.0025 развертываний серверов.
Это много.
Однако существует некоторая путаница (и даже разногласия) по поводу достоинств Tomcat как сервера приложений. Видите ли, я называю это сервером приложений, хотя технически… это не так.
Поясню. Помните, я говорил, что серверы приложений предоставляют вашему приложению некоторую инфраструктуру и функциональные возможности? Что ж, этот набор возможностей не является произвольным. Спецификация под названием Java EE точно определяет функциональные возможности серверов приложений. Поэтому, строго говоря, я должен называть серверами приложений только те контейнеры, которые проходят тесты на совместимость с Java EE. На сегодняшний день Oracle перечисляет три таких контейнера, и Tomcat не входит в их число.
Oracle передала Java EE в Eclipse Foundation, и теперь она называется Jakarta EE после Java EE 8. Кроме того, теперь доступно подмножество веб-профилей полной платформы EE, а также веб-контейнер, состоящий только из сервлетов.
Действительно, Tomcat не реализует все функции, необходимые для сервера приложений Java EE. Точное название Tomcat будет либо «веб-сервер», либо «контейнер сервлетов». Но даже несмотря на то, что Tomcat не поддерживает некоторые функции Java EE «из коробки», вы все равно можете использовать большинство этих функций. Вам просто нужно включить их в качестве дополнительных сторонних зависимостей в ваше приложение.
Суть в том, что вы можете запускать приложения Java EE на Tomcat. Я предполагаю, что вы ищете решение и не слишком интересуетесь тонкостями терминологии, поэтому я буду продолжать называть Tomcat (а позже и Jetty) сервером приложений, чтобы не усложнять ситуацию слишком большим количеством терминов.
Таким образом, Tomcat является зрелым, хорошо задокументированным и наиболее широко используемым сервером приложений Java.
Имея хорошую документацию и нехватку руководств по нему в Интернете, Tomcat является серьезным претендентом на роль сервера приложений почти во всех веб-приложениях Java.
Jetty
Jetty — еще один сервер приложений (разработанный Eclipse Foundation), технически не являющийся полнофункциональным контейнером Java EE. Как и в Tomcat, ему не хватает поддержки многих функций Java EE. И, как и в случае с Tomcat, вы по-прежнему можете использовать большинство функций, включив дополнительные сторонние зависимости.
Несмотря на то, что рыночная доля Jetty и близко не соответствует доле Tomcat, она по-прежнему широко используется в отрасли. Двумя его главными преимуществами являются компактность и небольшая занимаемая площадь. И то, и другое делает Jetty отлично подходящим для ограниченных сред и для встраивания в другие продукты.
GlassFish
GlassFish — полнофункциональный и сертифицированный сервер приложений Java EE, разработанный Oracle.
Таким образом, GlassFish более тяжеловесен, чем Tomcat или Jetty, и, возможно, с ним немного сложнее работать.
На самом деле GlassFish — это больше, чем просто универсальный сервер приложений Java EE. Это эталонная реализация стандарта Java EE. Это означает, что GlassFish используется для демонстрации возможностей Java EE и получает вклад от тех же людей, которые определяют стандарты Java EE. Поэтому GlassFish всегда в первую очередь будет поддерживать новейшие функции Java EE. Это плюс.
Недостатком GlassFish является отсутствие коммерческой поддержки. Да, эта статья о бесплатных серверах приложений с открытым исходным кодом, но это все же важный момент. По мере того, как ваш проект растет и становится финансово успешным, вы можете захотеть платить за долгосрочную поддержку, обновления безопасности, поддержку клиентов и т. д. для вашего сервера приложений. Это то, что обеспечивает коммерческая поддержка, и многие компании покупают ее. Поэтому имейте в виду, что если вы используете GlassFish и вам в будущем потребуется коммерческая поддержка, вам придется перейти на совершенно другой сервер приложений.
Возможно, сейчас это не кажется вам чем-то особенным, но для многих компаний это является препятствием. Подумайте, как могут выглядеть ваши будущие потребности, по крайней мере.
WildFly
WildFly, ранее известный как JBoss Application Server и разработанный Red Hat, является еще одним полнофункциональным и сертифицированным сервером приложений.
Большим преимуществом WildFly по сравнению с GlassFish является то, что Red Hat обеспечивает простой путь миграции с WildFly на коммерчески поддерживаемый сервер приложений под названием JBoss Enterprise Application Platform. Это означает, что вы можете использовать WildFly сегодня и быстро перейти на JBoss EAP в будущем, чтобы получить коммерческую поддержку, если решите, что это то, что вам нужно.
Red Hat также является одним из самых уважаемых поставщиков программного обеспечения. Это многое говорит о политике компании и поддержке клиентов. Примечание. Red Hat только что была приобретена IBM за 34 миллиарда долларов, что стало крупнейшей сделкой за всю ее историю.
Выбор сервера приложений
Итак, какой сервер приложений Java следует использовать в вашем собственном проекте?
Это тонкий вопрос. Честно говоря, ответ будет варьироваться от проекта к проекту. При этом я все же хочу заложить общую основу, которая поможет вам сделать выбор.
Если ваша организация уже использует определенный сервер приложений в других проектах, то лучше всего, если это возможно, придерживаться его. Стандартизация — это всегда хорошая идея. Кроме того, бесценна возможность перейти к другой команде и попросить о помощи.
Это простое дело. Теперь скажем, что это не применимо; ваша организация еще не использует определенный сервер приложений.
Если вам не нужны возможности Java EE (например, вы собираетесь использовать Spring Framework), я бы посоветовал использовать Tomcat. Это отраслевой стандарт де-факто, и поэтому вам будет проще всего найти документацию и примеры, если вы выберете его. Но если вы уже знаете, что будете запускать свое приложение в ограниченной среде, рассмотрите возможность выбора Jetty из-за его меньшей занимаемой площади.
Если вы планируете написать приложение Java EE, все становится еще сложнее.
Как я уже сказал, можно использовать Tomcat для запуска приложений Java EE, включая сторонние зависимости. Поэтому, если вы знаете, что будете использовать только небольшое подмножество Java EE, тогда Tomcat все равно может быть хорошим выбором. Например: если все, что вам нужно, это реализация JPA, то достаточно импортировать EclipseLink в ваш проект, и вы можете с радостью продолжить работу с Tomcat. Однако, если вы знаете, что будете интенсивно использовать Java EE или что необходимые вам функции недоступны в виде стороннего плагина, выберите WildFly.
Заключение
В целом, я бы посоветовал отдать предпочтение Tomcat, но рассмотрите Jetty, если вам нужен его меньший размер. В противном случае, если вам нужна обширная поддержка Java EE в вашем проекте, возьмите WildFly. Самое главное, если ваша организация уже использует определенный сервер приложений в других проектах, то просто следуйте его примеру.
Инструмент управления производительностью приложений Stackify, Retrace, помогает повысить производительность ваших Java-приложений с помощью APM, показателей работоспособности сервера и интеграции журнала ошибок. Начните бесплатную 14-дневную пробную версию Retrace уже сегодня.
- Об авторе
- Последние сообщения
О Василии Зуканове
Василий работал в полупроводниковой промышленности, а затем стал инженером-программистом, специализирующимся на Android. После нескольких лет работы с 9 до 5 он решил стать фрилансером Android-разработчика. В настоящее время он консультирует и создает видеокурсы по Android для разработчиков.- Лучшие серверы приложений Java: Tomcat, Jetty, GlassFish, WildFly — 5 ноября 2018 г.
Информация о документе Предисловие 1. Введение 2. Различия между Java EE и Java SE Платформы языка программирования Java Java SE Java EE Ява МЭ JavaFX Обзор корпоративных приложений Многоуровневые приложения Уровень клиента Веб-уровень Технологии Java EE, используемые на веб-уровне Уровень бизнеса Технологии Java EE, используемые на уровне Business Уровень корпоративных информационных систем Технологии Java EE, используемые на уровне EIS Серверы Java EE Контейнеры Java EE Веб-контейнер Контейнер клиента приложения Контейнер EJB 3. Создание вашего первого приложения Java EE 4. Создание второго веб-приложения 5. Следующие шаги | Сервер Java EE — это серверное приложение, которое реализует
API платформы EE и предоставляет стандартные службы Java EE. Серверы Java EE содержат несколько типов компонентов приложений, соответствующих уровням в многоуровневом приложении. Сервер Java EE предоставляет услуги этим компоненты в виде контейнера . Контейнеры Java EEКонтейнеры Java EE представляют собой интерфейс между компонентом и функциями нижнего уровня предоставляется платформой для поддержки этого компонента. Функциональность контейнера. определяется платформой и отличается для каждого типа компонента. Тем не менее, сервер позволяет различным типам компонентов работать вместе для обеспечения функциональности в корпоративное приложение. Веб-контейнер Веб-контейнер — это интерфейс между веб-компонентами и веб-сервером.
Веб-компонент может быть сервлетом, страницей Facelets JavaServer Faces или
JSP-страница. |
Знакомство с платформой Java, Enterprise Edition
Серверы Java EE
иногда называемые серверами приложений, потому что они позволяют обслуживать данные приложений для
клиенты, подобно веб-серверам, обслуживают веб-страницы в веб-браузерах.