сервер для java приложений
Пример простого клиент-серверного приложения на Java
«Клиент-сервер» это очень распространенная и логичная архитектура приложений. Мне кажется, что в наши дни редко можно встретить standalone-клиентское приложение. Поэтому я принял решение рассмотреть пример построения клиент-серверного приложения на Java без привязки к конкретной задаче. Сначала вкратце пробежимся по классовой структуре приложения, потом посмотрим на отдельную реализацию каждого класса. В самом конце статьи я дам ссылку на скачивание архива с готовой структурой приложения. Итак, начнем.
Основные компоненты приложения
Основными компонентами, естественно, являются непосредственно клиент и сервер. Однако, кроме них необходим еще пакет вспомогательных классов, которые, в простейшем случае, будут отвечать за обмен сообщениями между клиентом и сервером. В минимальной комплектации нужны такие классы: MessageReader/MessageWriter(считывает/записывает сообщение в поток на сокете), MessageFactory(содержит идентификаторы всех возможных сообщений), набор сообщений-запросов(Request) и набор сообщений-ответов(Response). Все они будут размещены в пакете «core», который должны иметь у себя и клиент и сервер.
Рассмотрим классовую структуру всего проекта, а потом перейдем к реализации.
Классовая структура клиент-серверного приложения
Исходный код клиента на Java
Разобраться с клиентом гораздо проще, он по сути своей не делает ничего супер сложного, просто создает сокет и подключается к сервер-сокету с помощью связки host:port. Лаунчер создает объект класса Client и запускает его работу. Исходный код привожу без импортов, ибо любая IDE вам их подключит(те, кто пишет на Java точно знают, что без IDE очень сложно). Кроме того, в конце статьи вы сможете скачать архив с этим проектом.
ClientLauncher.java
Client.java
Под словами «логика приложения» я подразумеваю протокол обмена сообщениями с сервером, передачу каких-либо данных для достижения конечной цели.
Исходный код сервера на Java
Задача сервера поднять свой серверный сокет на нужном адресе и ждать новых подключений. Для каждого подключения, которое принято называть клиентской сессией, создается отдельный поток обработки логики работы с клиентом.
Напомню, что в классе ClientSession описан основной алгоритм работы с клиентом, обмен сообщениями, данными и прочее. В классе Context содержится общая информация для всех клиентов сервера, например, пути для сохранения логов.
ServerLauncher.java
Server.java
Context.java
ClientSession.java
SessionsManager.java
Вспомогательные классы из пакета «core»
Помещу все вспомогательные классы под один кат, название классов в точности соответствует названиям из списка «классовая структура» выше, по нему вы можете определить пакет каждого класса.
Пара слов о сообщениях, классы Request и Response являются абстрактными и играют роль классификаторов сообщения. Благодаря этому очень удобно разграничивать «запросы» от «ответов». В этом примере я привел только одно сообщение — Handshake, которое отвечает за первое «рукопожатие» клиента и сервера. Все последующие сообщения должны быть прописаны в классе MessageFactory по примеру этих двух.
Скачать архив с шаблоном клиент-серверного приложения на Java
Заключение
Главная цель, которую я преследовал при написании этой статьи заключается в том, чтобы дать возможность мне или кому-либо еще за считанные минуты «собрать» готовое клиент-серверное приложение. Кажется, я с этим справился, если будут дополнения или замечания, пишите в комментариях или на почту. А на сегодня у меня все, спасибо за внимание!
Java EE сервер приложений
Java EE сервер приложений — продукт промежуточного уровня, который реализует набор J2EE технологий (спецификаций), тем самым предоставляя среду для деплоймента, управления и выполнения Java EE компонентов.
Java EE компоненты выполняются в контейнерах сервера приложений, которые управляют их выполнениям. Контейнеры являются интерфейсом между компонентом и низкоуровневой функциональностью, которая поддерживает компонент, также предоставляя стандарнтые сервисы (Security, JTA, JNDI, Web Services, JMS, JPA и другие), которыми могут воспользоваться компоненты. Рассмотрим возможную архитектуру Java EE приложения.
В данном случае Applet Container и Application Client Container хотя и являются частью Java EE приложения, но не являются частью Java EE сервера приложений.
Web Container предоставляет среду для выполнения следующих Java EE компонентов: Servlets, JSP, JSF.
EJB Container предоставляет среду для выполнения Enterprise JavaBeans (EJB) компонентов.
Следует отметить, что функциональность, реализуемую контейнерами возможно использовать вне сервера приложений. К примеру, Apache Tomcat является самостоятельным продуктом, который реализует Java Servlets и Java Server Pages спецификации, возможно использовать для разработки полноценных приложений, не прибегая к использованию сервера приложений. Apache OpenEJB является реализацией EJB спецификации, предоставляя среду выполнения для EJB компонентов. Многие компании-поставщики серверов приложений используют данные продукты для разработки контейнеров в своих серверах приложений.
Помимо стандартной функциональности компании-поставщики Java EE серверов приложений могут предоставлять дополнительные возможности, к примеру, кластеризация, балансировка нагрузки, широкий спектр инструментов мониторинга и анализа выполнения и другие.
Ресурсы:
Підписуйтеся на Telegram-канал редакції DOU, щоб не пропустити найважливіші статті.
Сервер приложений и веб-сервер
Сервер приложений (Application Sever) – это сервер промежуточного программного обеспечения (ПО, middleware). Это системное ПО, которое располагается между операционной системой (ОС) с одной стороны, внешними ресурсами, например, системой управления базами данных СУБД (DBMS, Database Management System) или Интернет-сервисами, с другой стороны, и приложениями пользователя.
Сервер приложений действует как хост для бизнес-логики пользователя, он также обеспечивает доступ к бизнес-приложениям и задаёт их параметры для пользователя. Сервер приложений должен устойчиво работать независимо от изменений трафика клиентских запросов, отказов оборудования и ПО, распределённого характера масштабных приложений, а также возможной разнородности форматов данных и ресурсов их обработки.
Внешние ресурсы, например, СУБД и Интернет-сервисы, предоставляют веб-серверы (Web Server). Они отвечает на запросы пользователя по доставке контента.
Серверы приложений иногда путают с веб-серверами. У них есть общие функции, но есть и много различий. Понимание этих различий поможет правильно сконфигурировать программное обеспечение и инфраструктуру оборудования для нужд предприятия.
Различия между серверами приложений и веб-серверами
Параметр сравнения
Веб-сервер
Сервер приложений
Основная цель
Хостинг сайтов и ответы на простые веб-запросы
Хостинг приложений и обеспечение сложных взаимосвязей бизнес-логики
Тип контента
Доставка только статического контента HTML
Доставка как статического, так и динамического контента
Протоколы
HTTP/HTTPS и другие протоколы
Соединение с приложениями
Подключения к базами данных
К статическим базам данных
К базам данных приложений
Типичные клиенты
Веб- и мобильные приложения, а также веб-браузеры
Многопотоковая обработка
Поддерживается параллельная обработка многих запросов
Потребление ресурсов
Трафик не потребляет много ресурсов
Процессы с интенсивным потреблением ресурсов
Контейнеры
Веб-контейнеры (сервлеты, JSP, JSF, веб-сервисы), контейнеры клиентских приложений (DI, безопасность)
Ёмкость
Результат запроса
Гипертекстовый документ, отображающий информацию в браузере
Файлы, содержащие данные, по требованию клиента
Что такое веб-сервер?
Веб-сервер – это компьютерная система, которая хранит, обрабатывает и доставляет веб-страницы для клиента. Клиентом в этом случае является веб-браузер на компьютере пользователя или мобильное приложение на его смартфоне или планшете. В зависимости от настроек, веб-сервер может хранить один или множество веб-сайтов. Веб-серверы доставляют клиенту только статический HTML-контент, такой как документы, изображения, видео, шрифты и пр.
Обычно веб-серверы не обрабатывают динамический контент и не позволяют программировать свои программы. Веб-серверы работают по протоколу передачи гипертекста HTTP (Hypertext Transfer Protocol) или HTTPS (Hypertext Transfer Protocol Secure). Однако, опционально, некоторые веб-серверы позволяют добавлять компоненты, позволяющие работать с динамическим контентом.
Что такое сервер приложений?
Сервер приложений (Application Server, App-Server) – это программный комплекс, предназначенный для доставки контента и средств его представления для клиентских приложений. Клиентами могут быть веб-приложения, браузеры или мобильные приложения.
Серверы приложений предоставляют для клиентов бизнес-логику, то есть, преобразуют данные в динамический контент и обеспечивают функционал приложений. Примеры такого контента:
Сервер приложений – это связующее звено между клиентом и программным кодом физического сервера. Типичные задачи сервера приложений:
Серверы приложений также обрабатывают такие процессы, как кластеризация, исправление отказов и балансировка нагрузки.
Рис. 2. Сервер приложений.
Что общего у веб-сервера и сервера приложений
Если в качестве основного приложения клиента выступает веб-браузер, то различия между двумя типами серверов размываются. Большинство веб-серверов имеют плагины на основе скриптов (ASP, JSP, JSF, PHP, Perl, и пр.), которые позволяют генерировать динамический контент.
Поскольку в сценариях применения у веб-серверов и серверов приложений много общего, то наиболее популярные серверы являются гибридами этих двух типов. Гибридное решение, совмещающее свойства обеих серверов, обеспечивает максимальную скорость и функциональность системы.
Для хостинга веб-сайта со статическим контентом лучше всего подходят объектные СХД.
Наиболее популярные веб-серверы
Nginx – веб-сервер с открытым кодом, который может работать как обратный прокси-сервер (reverse proxy). Обратный прокси-сервер работает не в сторону клиента, фильтруя контент и обеспечивая безопасность, а в сторону веб-сервера. Nginx имеет архитектуру, управляемую событиями EDA (event-driven architecture), позволяющую создавать и определять события, реагировать на события, измерять потребление ресурсов реакции на событие. Кроме того, он может выполнять функции прокси-сервера электронной почты и балансировщика нагрузки и может выполнять одновременно множество запросов.
HTTP-сервер Apache – популярный веб-сервер на ОС Linux, который входит с стек LAMP (Linux, Apache, MySQL, PHP). На этом веб-сервере работает около 40% Интернет-сайтов. Apache имеет богатый выбор функций, включая htaccess, FTP, HTTP/2, ограничение полосы пропускания для определённых клиентов (throttling), балансировку нагрузки и пр.
Microsoft IIS (Internet Information Services) – свободно распространяемый пакет серверного ПО, представляющий собой проприетарный набор служб от компании Microsoft. IIS распространяется с пакетом Windows NT. IIS поддерживает протоколы HTTP, HTTPS, FTP, POP3, SMTP, NNTP.
Jetty – проект свободного ПО, который может обеспечивать функции НТТР-сервера, НТТР-клиента и контейнера javax.servlet. Хотя Jetty разрабатывался как веб-сервер, он также может служить платформой для межмашинных коммуникаций (М2М).
LiteSpeed имеет хорошую производительность и масштабируемость, широкий диапазон функций и простую в использовании консоль администратора. Это четвёртый по популярности веб-сервер, который, по состоянию на декабрь 2020 года, использовался для 8.1% веб-сайтов.
Наиболее популярные серверы приложений
Apache Tomcat – контейнер сервлетов с открытым исходным кодом на языке Java. Tomcat позволяет запускать веб-приложения и содержит ряд программ для автоматического конфигурирования и часто используется вместе с конфигурационным файлом Apache HTTPD (Apache Hypertext Transfer Protocol Server daemon). Tomcat может исполнять Java-сервлеты, доставлять клиентам страницы в кодах Java Server Page, и может обслуживать приложения Java EE (Java Enterprise Edition).
Сервер Oracle WebLogic – сервер для распределённых приложений с использованием стандартов Java EE. Он полностью интегрирован с продуктами и облачными сервисами Oracle.
Glassfish – сервер приложений с открытым кодом на Java EE, который поддерживает Java-сервлеты, а также спецификацию написания и поддержки серверных компонентов с бизнес-логикой EJB (Enterprise JavaBeans).
JBoss – сервер приложений с открытым кодом для создания, развёртывания и хостинга приложений на языке Java. JBoss может работать на разных платформах и в любой операционной системе с поддержкой Java.
Какой сервер приложений будет наиболее подходящим?
Знание различий между сервером приложений и веб-сервером помогает выбрать сервер для того или иного использования.
Другим подходом может быть добавление функционала в веб-сервер при помощи плагинов. В этом случает, веб-сервер может использовать технологию программирования на стороне сервера (server-side), такую как скрипты CGI, JSP, сервлеты, ASP (Active Server Pages) или JavaScript на стороне сервера.
Использование обоих типов сервера в одной системе
Часто и веб-сервер, и сервер приложений, развёртывают в одной системе. Это даёт возможность предоставлять клиентам как статический, так и динамический контент. В этом случае, веб-сервер становится подсистемой сервера приложений и все их сервисы работают на одной и той же программно-аппаратной платформе.
Преимуществом такого подхода является более высокая производительность системы. В каждом типе сервера максимально используются их преимущества. Простые веб-запросы будут сразу же обрабатываться веб-сервером и при этом не будет снижаться производительность сервера приложений.
Например, на сайте Интернет-магазина должна предоставляться информация о ценах в реальном времени. Обычно на сайте также есть форма для приобретения товара. Когда пользователь посылает запрос, веб-страница магазина ищет актуальную цену и выдаёт результат в виде HTML-страницы. Эту функциональность можно обеспечить как при помощи сервера приложений, так и при помощи веб-сервера с соответствующими плагинами. Возможно несколько сценариев.
Сценарий 1. Использование только веб-сервера с плагинами
Веб-сервер предоставляет функционал Интернет-магазина:
Сценарий 2. Использование как веб-сервера, так и сервера приложений
Сервер приложений хранит бизнес-логику для поиска цены. Веб-сервер делегирует ему генерацию ответа, скрипт вызывает сервис поиска в сервере приложений, и затем формулирует ответ HTML.
Размещение логики поиска цены в сервере приложений позволяет использовать её различными частями приложения. В первом сценарии сервис поиска цены не может повторно использоваться, поскольку данные встроены в HTML-страницу.
Рис. 3. Использование как веб-сервера, так и сервера приложений.
Заключение
Пересечение функций веб-сервера и сервера приложений означает, что каждый сценарий применения может иметь несколько решений. Можно применять веб-серверы и серверы приложений отдельно, а можно использовать их комбинацию.
Однако, не каждая конфигурация будет равноценной по параметрам работы и потреблению ресурсов, хотя и будет выполнять возложенные на неё функции. Знание различий между двумя типами серверов поможет сэкономить средства, облегчить масштабирование системы и повысить производительность.
Разворачиваем окружение для Java-приложения с помощью Ansible
За мной, за мной, читатель, и я проведу тебя в чарующий мир автоматизации разворачивания окружения на серверах под управлением Linux семейства RHEL.
Один из наших java-проектов вырос, стал совсем взрослым и сейчас занимает 4 контура:
Каждый контур содержит два одинаковых сервера с идентичным набором компонентов окружения для нашего приложения:
linux Oracle — операционная система,
jdk — комплект приложений Java,
haproxy — proxy сервер,
nginx — веб-сервер для отдачи статики,
mysql — субд.
Перед командой эксплуатации встал резонный вопрос: как настроить управление окружением на восьми серверах и сохранить оптимистичное отношение к жизни.
После краткого сравнения систем управления конфигурациями был выбран Ansible. В его пользу сыграли простота, гибкость и отсутствие агентов на управляемых серверах.
Теперь немного расскажем об архитектуре ролей Ansible для проекта.
Для установки и первоначальной настройки каждого компонента окружения написана отдельная роль. Последующая кастомизация настроек каждого компонента окружения также выделена в дополнительную роль. Это позволило нам избежать дублирования общих стандартных ролей для остальных проектов.
Playbook c последовательностью выполняемых ролей для подключения новой ноды в контур выглядит так:
А теперь расскажем о каждой роли поподробнее.
Роль rhel_install_new_server
Выполняет общую настройку операционной системы и установку системных утилит.
Первое знакомство с протоколом HTTP через написание простейшего Web сервера на Java
Думаю что не будет преувеличением утверждать, что знание и понимание сути протокола HTTP необходимо любому, кто решил сколь-нибудь серьезно заняться любым из направлений современной Web разработки. Мой личный опыт говорит о том, что понимание это приходит не сразу. Стыдно сказать, что были времена, когда слова GET и POST были для меня сродни магическим заклинаниям, а о существовании PUT, PATCH и DELETE я даже не подозревал.
Несколько месяцев назад помимо собственно разработки я занялся также преподаванием, и возник вопрос о том, как проще и понятнее рассказать о сути протокола HTTP будущим Java разработчикам. После нескольких дней возни и ряда неудачных попыток сделать презентацию возникла идея, а почему бы не написать простейший HTTP сервер на Java, потому как ни что так хорошо не объясняет суть протокола, как его простейшая, но работающая реализация.
Как оказалось сделать это совсем не сложно. Ниже привожу код, которого будет достаточно для корректного взаимодействия с любым браузером! Все что нам понадобится это ServerSocket и немного стандартного ввода-вывода.
Пробуем запустить этот код. Стоит отметить, что порт, для которого создается ServerSocket должен быть свободным. Если указанный порт занят, то нужно или его освободить, или использовать другой свободный порт.
Каждый раз, когда мы что-то вводим в адресную строку браузера и нажимаем Enter не происходит ничего иного, как отправка текста, начинающегося словом GET и заканчивающегося переводом строки. После слова GET через пробел следует путь к запрашиваемому документу на сервере. Попробуйте ввести в браузере http://localhost:8080/something и посмотреть, как изменится текст запроса в логе.
После того, как текст запроса полностью прочитан сервером, мы отправляем ему простейший ответ, структура которого довольно проста и аналогична структуре запроса. В первой строке версия протокола HTTP и код 200 OK, который сообщит браузеру о том, что запрос был успешно обработан (всем куда лучше знаком код 404, не правда ли 😉 ). Далее следует всего один заголовок Content-Type в котором передается информация о формате передаваемого документа (text/html) и его кодировке (charset=utf-8). После заголовка следует перевод строки (обязательное требование протокола HTTP) и собственно текст, который будет отображен в браузере.
На этом все! Разумеется это далеко не все, что нужно знать о протоколе HTTP и принципах разработки Web серверов, но мне бы не хотелось усложнять данный пример, т.к. главная его задача — продемонстрировать, простейшую коммуникацию по протоколу HTTP. В одном из следующих своих материалов постараюсь развить тему изучения протокола HTTP через его реализацию.
UPD. Гораздо более продвинутый пример подобного сервера можно найти в книге How Tomcat Works: A Guide to Developing Your Own Java Servlet Container by Paul Deck, Budi Kurniawan, глава 1 — Simple Web Server.