РАЗРАБОТКА СПЕЦИАЛИЗИРОВАННОЙ БИБЛИОТЕКИ ДЛЯ РЕАЛИЗАЦИИ СЕРВЕРНОГО ПРИЛОЖЕНИЯ НА ЯЗЫКЕ JAVA Текст научной статьи по специальности «Компьютерные и информационные науки»

УДК 004.4

РАЗРАБОТКА СПЕЦИАЛИЗИРОВАННОЙ БИБЛИОТЕКИ ДЛЯ РЕАЛИЗАЦИИ СЕРВЕРНОГО ПРИЛОЖЕНИЯ НА ЯЗЫКЕ JAVA

В.Ф. Барабанов1, Н.И. Гребенникова1, Д.С. Галамага1, С.Л. Кенин2

воронежский государственный технический университет, г. Воронеж, Россия

2Atos, г. Воронеж, Россия

Аннотация: дано общее описание технологии разработки крупных проектов, показано значение прототипиро-вания в целях минимизации потерь при использовании библиотек. Сокращение времени разработки прототипа и удешевление процесса разработки происходит с сохранением возможности доработки и замены любой составляющей без вмешательства в остальные части продукта без ограничения имеющегося функционала. Разработанная библиотека предназначена для написания серверного приложения с любыми требованиями в максимально короткие сроки. Рассмотрен состав библиотеки, представляющей собой набор сервисов и утилит, позволяющих организовать распределенную нагрузку, работу с файлами и базами данных, организовать взаимодействие различных частей приложения, мониторинг и логирование работы приложения, сериализацию и десериализацию объектов. Приведен пример работы с данной библиотекой, с этой целью создано серверное приложение, приведен алгоритм его работы. Структура разработанного серверного приложения позволяет использовать функции логирования и серверных метрик на всех этапах всеми функциональными частями. Приведены условия работы программы, порядок установки и настройки программного продукта, предложен конфигурационный файл, содержащий необходимые настройки. Рассмотренные последовательность и порядок настройки позволяют наиболее полно воспользоваться предлагаемыми возможностями библиотеки классов

Ключевые слова: разработка библиотеки классов, серверное приложение, мониторинг, логирование

Введение

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

Для минимизации потерь от таких проектов крупные компании постепенно переходят к концепции прототипирования: на начальных этапах одновременно разрабатывается несколько схожих приложений разными командами. Затем, в определенный момент, проводится оценка каждого разработанного приложения и сравнение его с остальными. В итоге, из нескольких схожих по функционалу прототипов выбирается один лучший по ключевым показателям и далее ведется разработка исключительно этого проекта [1,2].

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

© Барабанов В.Ф., Гребенникова Н.И., Галамага Д.С., Кенин С.Л., 2018

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

Основные требования, предъявляемые к серверным приложениям

Существуют современные решения для реализации серверных приложений:

ApacheTomcat, Nginx, JavaEnterpriseUser-Solution (JEUS) и др. ApacheTomcat - это контейнер, позволяющий использовать такие приложения, как сервлеты и серверные страницы [3]. Nginx— веб-сервер и почтовый прокси-сервер, работающий на Unix-подобных операционных системах. JavaEnterpriseUserSolution (JEUS) —сервер приложений, разрабатываемый TmaxSoft.

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

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

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

- простота использования;

- кроссплатформенность;

- возможность расширения функционала с помощью написания стандартизированных модулей;

- удобная система обмена сообщениями между различными узлами системы;

- реализованные системы серверных метрик, логирования, мониторинга производительности;

- возможность конфигурирования всех узлов системы;

- работа с любыми реляционными базами данных;

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

При разработке библиотеки классов должны быть решены следующие задачи:

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

- проведена стандартизация основных составляющих серверного приложения для возможности реализации замены одной части приложения независимо от остальных;

- реализован мониторинг состояния приложения: логирование, серверные метрики;

- простая и удобная работа с любой реляционной базой данных;

- организовано сетевое взаимодействие как микросервисов серверного приложения, так и серверного приложения с множествами клиентских приложений;

- простота установки, настройки и использования;

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

Программная реализация серверного приложения

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

приложению: распределение нагрузки, мониторинг, работа с базами данных и многое другое.

Полный состав библиотеки:

- мастер-сервис для организации распределенной нагрузки;

- сервис для работы с базами данных;

- сервис для работы с пользовательскими приложениями;

- сервис для реализации внутренней логики;

- утилита для обмена информацией между различными частями приложения;

- сервис для работы с метриками, телеметрией и аналитикой;

- утилита для работы с файловой системой;

- утилита для логирования событий;

- утилита для сериализации и десериали-зации объектов;

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

Возможная структура серверного приложения, использующего все возможности библиотек, представлена на рис. 1.

Сервис общения с клиентскими приложениями

Сервис метрик

Сервис баз данных

1 , „ 1

Мастер

1 т

Внутренняя логика

Рис. 1. Возможная структура серверного приложения

На рисунке видно, что в предполагаемой реализации приложения будет существовать множество различных сервисов, соединенных между собой одним отдельным мастер-сервисом. Такая архитектура позволяет [4]:

- дожидаться перехода всех необходимых частей приложения в рабочее состояние;

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

- отделить «транспортную» нагрузку от остальных частей приложения;

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

Несмотря на то, что представленная выше архитектура приложения имеет множество

плюсов, использование отдельного сервиса для распределения транспортной нагрузки может быть нецелесообразна. В таком случае в библиотеке предусмотрена организация прямого общения между различными частями приложения. В программе имеется возможность настраивать любые параметры, необходимые для работы приложения в удобном для чтения и изменения xml-формате. По умолчанию, например, необходимо задать сетевые порты для интересующих частей сервера. Для задания базовых параметров предусмотрена удобная работа с файловой системой и десериализация данных XML в объекты классов Java.

Для примера работы с данной библиотекой создано небольшое серверное приложение, использующее все имеющиеся функции: созданы мастер-сервис, сервис по работе с БД, два сервиса внутренней логики (лобби-сервис и простейший сервис, считающий секунды и отправляющий их клиентскому приложению) и сервис для обмена информацией с клиентским приложением (frontend). Предполагается следующая линейная работа приложения, приведенная ниже.

Пользователь отправляет свои данные на Frontend. Frontend отправляет запрос сервису работы с базами данных (DBService) через мастер-сервис. DBService производит поиск пользователя с переданными из Frontend данными входа. Если их нет - DBService отправляет информацию о неверно введенных данных на Frontend, который, в свою очередь, сообщает об ошибке пользовательскому приложению. Если сервис БД находит нужную запись, то он отправляет на Frontend информацию о найденном пользователе.

Получив информацию от сервиса БД, Frontend производит поиск по созданным клиентским сессиям. Если находит -перенаправляет новому известному клиенту данные с сервера mechanics (о нем будет написано позднее). Если Frontend не находит пользовательской сессии, то он создает новую сессию и перенаправляет информацию о пользователе на Lobby-сервис.

Lobby - промежуточный сервис, использующийся как временное хранилище пользователя до того, как будет произведена процедура перехода к сервису mechanics. Однако библиотека не ограничивает использование Lobby только как временного хранилища. Разработчик финального продукта может запрограммировать любой необходимый функционал. После успешного присоединения пользователя к Lob-by-сервису, последний отправляет на Frontend

информацию об этом, а frontend, в свою очередь, на клиентское приложение.

Алгоритм работы приложения представлен на рис. 2.

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

- логи одного запуска серверного приложения хранятся в одной уникальной директории. Логи разных запусков не смешиваются;

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

- в каждом событии логируется файл и строка, из которой осуществляется логирова-ние, а также точное время записи;

- для критичных событий логируется полный стек вызова;

- логируются все события, включая исключения времени выполнения.

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

Для нормальной работы программы на компьютере пользователя должен быть установлен пакет JavaSE версии 8.0 или выше.

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

Конфигурация серверного приложения

Настройка логирования осуществляется путем создания файла вclasspath проекта, соответствующего одному из возможных форматов:

log4j2.yaml или log4j2.yml - настройки задаются в формате Yaml;

log4j2.json или log4j2.jsn - настройки задаются в формате Json;

log4j2.xml - настройки задаются в формате

xml.

Клиентское приложение Frontend DBService Lobby Mechanics

Нажатие кнопки «Start» для начала работы

Отправка со Frontend О общения на готовности

1 1 X-к м\ Данн Не- N. ыми есть? ✓

1 Отправка клиентское г ошибки на приложен ие 1 i Отправка fron ошибки на tend

Отправка информации о новом пользователе на _Lobby

Отправка информации о

успешном входе на клиентское приложен ие

Отправка в Lobby команды о начале

Отправка данных пользователя на Frontend

Регистрация пользователя в Lobby

Отправка со успешной р общения об егистрации

-

Формирование пользовательских данных и передача их в mechanics

Создание пользовательской сессии

1

Передача данных сессии с заданным периодом времени

Рис. 2. Алгоритм работы приложения

Независимо от выбранного формата, конфигурационный файл должен иметь две главные категории: Appenders и Loggers. В категории Appenders настраивается поведение логге-ров: способ вывода (файл, консоль) и формат

записи. Loggers определяют, какие уровни ло-гирования в какие appenders будут выводиться [5]. Пример настроенного в формате XML лога представлен на рис. 3.

<?™i version="l.0" encodijig="DTF-8" ?.> ■iconFiguration moni.torInterval="3"> <Properties>

< Property name= "name " >Я et* : LOGNAME. ) </ Property > <Property name= " time " >i {et x : STàRTTIM:}</Property>

</Properties> <appenders>

■!File name="FILE" filename»"logs/${time}/?{name} .log" append»" true">

< PatternLay out pattern»"(d(ISOS601) [i-5p] (tF:*L) - imin"/> </File>

■iAsync name="Async">

<AppenderRef ref="FILE"/> i/Async>

iConsole name= " STDOOT " targe t=nSÏSTEHOCrT " >

-i PatternLay out pattern»"id{HH :inr.: ss . SSS} i-51evel %class{36}'4 - %m%ex%n"/> IE ::/Console:*

</appenders> <loggers>

croot level="info">

<appender- re Г re f = " STDODT "!> </root>

dogger name=" file" level="info">

<appender-ref ref="Async"/> </logger> </loggers> < / con figuration>

Рис. 3. Пример конфигурационного файла в формате XML

Для использования метрик в первую очередь необходимо настроить их использование в самом приложении. Это возможно двумя способами: использованием микросервиса MetricServicelmpl (для централизованного вывода метрик) либо использованием класса MetricsHelper (для возможности реализации вывода метрик отдельно для каждого микросервиса). Для настройки метрик необходимо установить бесплатные сторонние приложения Prometheusи Grafana.

Prometheus настраивается в конфигурационном файле prometheus.yml. В конфигурационном файле можно ссылаться на файлы правил. Правила помогают предварительно вычислять наиболее используемые или требующие затрат ресурсов параметры и сохранять их в виде новых временных рядов. Осуществлять поиск по предварительно рассчитанным параметрам значительно проще, чем при каждом запросе заново вычислять их значения. Это может оказаться полезным, например, при работе с дашбордами, которые запрашивают значения параметров при каждом обновлении. В общем виде синтаксис правил можно представить так [6,7]: <имя временного ряда>{метки} = <параметр для записи>

Prometheus сверяется с правилами с определённой периодичностью, указанной в конфигурационном файле в параметре evaluation_interval. После каждой сверки Prometheus пересчитывает значение параметра и сохраняет его под новым именем с текущей временной меткой.

В последнюю очередь необходимо настроить Grafana. Для этого нет необходимости в правках конфигурационных файлов, простейшие настройки можно производить напрямую из приложения. После запуска Графаны необходимо с помощью любого браузера зайти по адресу http://localhost:3000/ (в случае, если необходимо изменить это, настройки хранятся в файле conf/defaults.ini). В появившемся окне необходимо ввести «admin» в качестве логина и пароля (это значения по умолчанию, их можно изменить в настройках программы). Далее необходимо войти в существующий или создать новый Dashboard, настроить название и основные свойства отображения на вкладке «General».

Для конфигурации серверного приложения служит конфигурационный файл config.xml, находящийся в пакете configs модуля base. Данный файл является сериализованной версией объекта класса ServerConfigro пакета утилит (utils), но может быть заменен любым файлом, путь к которому указан в аргументах при запуске каждого отдельного микросервиса.

Файл содержит отдельные настройки для ip (ip) и портов (masterPort и secondPort) каждого из микросервисов, а также настройки для соединения с базой данных: databasePath- сетевой путь до базы данных, dbLogin и dbPass для данных авторизации к базе пользователя, от имени которого будут производиться операции с базой.

Структура серверного приложения

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

реализуют один общий интерфейс Node, содержащий следующие методы:

Main() - для запуска только этого сервиса отдельно от остальных;

getLog() - получить текущий логгер микросервиса;

run() - унаследованный от Runnable метод для запуска;

getAddress() - получение уникального адреса микросервиса;

setMasterReady(boolean) - установить значение готовности мастера;

getMasterService() - метод, возвращающий адрес мастер-сервиса, к которому подключен текущий микросервис (возвращает свой адрес).

Основной микросервис, реализованный в библиотеке - класс MasterServiceImpl. Это микросервис, служащий для синхронизации работы других сервисов и для передачи отдельных сообщений (рис. 4).

I 1 Mode

m getAddressO Address

m setM a sterlsReady [boolean) void 4 getMasterServiceO Socket

i 1 Serializable

V ъ MasterServLce

(m Ъ getNodesQ Map<Class< ? extends Node>, Liste Socket>>

|т Ъ getConnectorO Connector

1т Ъ ad d M essa g e(M ess a g е) void

|т Ъ sortMessagesQ void

Ъ Functional Interface

i Ъ Runnable m Ъ runO void

Powered by yFiles

f* Ъ MasterServicelmpl

m M a sterServl eel mpl(String)

main(String[]} void

m getLogO Logger

пп getNodesQ Map<Class<? extends Nodei, LisKSocket>>

nn ad d M essa g e[M essa g e] void

пп getConnectorQ Connector

пп Ъ sortMessagesQ void

пп Ъ гjnQ void

пп getAddressO Address

пп setM a sterl sRea dyfboolea n] void

пп g etM a sterServl ceQ Socket

Рис. 4. Диаграмма класса MasterServicelmpl

Для работы с базой данных реализован сервис HDBServicelmpl, использующий для своей работы стороннюю библиотеку Hibernate.

Frontend - это микросервис, полностью отвечающий за коммуникации с пользовательскими приложениями. Это также значит, что пользователи знают о существовании только этого сервиса.

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

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

Clientlmpl - демонстрационное клиентское приложение.

Клиентское приложение имеет два окна. Первое окно - окно авторизации. Данное окно имеет поля для ввода логина и пароля пользователя, поле для ввода адреса серверного при-

ложения и кнопки для авторизации и создания нового пользователя.

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

выбрать наиболее близкий по назначению существующий базовый модуль;

выделить утилиты и реализовать их в коде в специальном пакете (utils);

разработать и реализовать входящие и исходящие сообщения для микросервиса;

реализовать методы выбранного базового интерфейса и методы разрабатываемого сервиса;

настроить Gradle для правильной сборки нового модуля.

Выбор базового модуля производится среди реализованных интерфейсов в пакете base, однако есть возможность создания нового базового интерфейса модуля. Главным требованием к разработанному интерфейсу микромодуля является наследование его от интерфейса Node - родительского интерфейса всех микромодулей. Базовый функционал, необходимый в микромодуле (но в перспективе или уже в момент реализации

необходимый и в других модулях приложения), следует реализовывать отдельно в пакете utils. Примером такого функционала может являться работа с файлами или система сообщений между микросервисами. Для каждой отдельной утилиты следует создать свой пакет и интерфейс, содержащий все основные методы, в модуле base.

Все микромодули осуществляют обмен данными (через мастер-сервис или напрямую) с помощью единой системы сообщений. Каждое сообщение представляет собой класс, унаследованный от класса base.masterService.Message. Этот класс содержит уникальный идентификатор (адрес) отправителя, ссылку на класс получателя (конкретного адресата мастер-сервис выбирает сам по заданному алгоритму), конструктор и метод exec, выполняемый получателем сообщения.

Каждая встроенная утилита находится в отдельном пакете в модуле utils. Утилита может содержать как один класс, так и несколько различных классов. С целью упрощения процедуры замены утилиты со стандартной на уникальную, написанную разработчиком конечного приложения для каждого из основных классов утилит, предусмотрен интерфейс в модуле base. Ресурсная система (ResourceSystem) - одна из основных утилит библиотеки. Она позволяет конфигурировать объекты с различными особенностями путем изменения не исходного кода, а отдельных файлов любым текстовым редактором. Реализованная система работает с файлами в формате xml.

Для сериализации и десериализации (SerializerHelper) разработан отдельный класс -SerializerHelper. Он включает в себя все основные способы сериализации объектов: бинарную сериализацию и несколько видов файловой се-риализации [8].

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

Заключение

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

Установка эталонного времени выполнения TICK TIME MS

Ожидание команды на начало шага цикла

Сохранение текущего времени в отдельной переменной tickStart

Ожидание команды об окончании шага цикла

Ж

tickEnd = Время окончания шага tickTime = tickEnd-tickStart illis = TICK TIME MS - tickTime

1

Ожидание TICK_TIME_MS - Millis миллисекунд

l

Запись в лог о слишком долгом выполнении шага

Рис. 5. Алгоритм работы TickSleeper Литература

1. Интеграционные решения при построении корпоративных информационных систем / В.В. Сафронов и др. // Известия Самарского научного центра РАН. 2016. Т.18. № 4(3). С. 646-654.

2. Интеграционная модель распределённой информационной системы предприятия нефтехимической отрасли / В.В. Сафронов и др. // Химическое и нефтегазовое машиностроение. 2017. № 10. С. 34-39.

3. ApacheTomcat. Руководство по UbuntuServer [Электронный ресурс]. Режим доступа: https://help.ubuntu.com/lts/serverguide/tomcat.html

4. Эккель Б. Философия Java. Библиотека программиста. Изд. 4-е. СПб.: Питер, 2009. 640 с.

5. Конфигурация Log4j2 [Электронный ресурс] Режим доступа:

https://logging.apache.org/log4j/2.x/manual/configuration.html

6. Мониторинг сервисов с Prometheus [Электронный ресурс]. Режим доступа: https://blog.selectel.ru/monitoring-servisov-s-prometheus/

7. Кравец О.Я., Подвальный С.Л. Разработка компонент информационного обеспечения поддержки запросов к подсистеме выдачи результатов мониторинга // Системы управления и информационные технологии. 2011. Т. 45. № 3.1. С. 158-161.

8. Сериализация в Java [Электронный ресурс] Режим доступа : https://habr.com/post/60317/

Начало

Поступила 29.04.2018; принята к публикации 16.07.2018 Информация об авторах

Барабанов Владимир Федорович - д-р техн. наук, профессор, Воронежский государственный технический университет (394026, Россия, г Воронеж, Московский проспект, 14), e-mail: bvf@list.ru

Гребенникова Наталия Ивановна - канд. техн. наук, доцент, Воронежский государственный технический университет (394026, Россия, г. Воронеж, Московский проспект, 14), e-mail: g-naty@yandex.ru

Галамага Дмитрий Сергеевич - студент, Воронежский государственный технический университет (394026, Россия, г Воронеж, Московский проспект, 14), e-mail: graf2242@gmail.com

Кенин Сергей Леонидович - канд. техн. наук, руководитель проектов, Atos (IT Solutions end Services) (394026, Россия, г. Воронеж, пр. Труда, 65), e-mail: sergey.kenin@atos.net

DEVELOPMENT OF SPECIALIZED LIBRARIES FOR IMPLEMENTING SERVER APPLICATIONS IN JAVA

V.F. Barabanov1, N.I. Grebennikova1, D.S. Galamaga1, S.L. Kenin2

Voronezh State Technical University, Voronezh, Russia 2Atos, Voronezh, Russia

Abstract: the article gives a general description of the technology for the development of large projects, shows the importance of prototyping in order to minimize losses when using libraries. Reducing the development time of the prototype and reducing the cost of the development process occurs with the preservation of the possibility of finalizing and replacing any component without interfering with the rest of the product without limiting the available functionality. The developed library is intended for writing a server application with any requirements in the shortest possible time. The composition of the library, which is a set of services and utilities, allows organizing distributed load, working with files and databases, organizing interaction of various parts of the application, monitoring and logging of the application, serialization and deserialization of objects. An example of working with this library is given, for this purpose a server application was created, an algorithm for its operation is given. The structure of the developed server application allows to use the logging and server metrics functions at all stages by all the functional parts. The working conditions of the program, the order of installation and configuration of the program product are given, the configuration file containing the necessary settings is offered. The sequence and order of tuning described allows to make full use of the proposed features of the class library

Key words: class library development, server application, monitoring, logging

References

1. Safronov V.V. et al. "Integration solutions in the construction of corporate information systems", Proceedings of the Samara scientific center of RAS (Izvestiya Samarskogo nauchnogo tsentra RAN), 2016, vol. 18, no. 4 (3), pp. 646-654.

2. Safronov V.V. et al. "Integration model of distributed information system of petrochemical industry", Chemical and oil and gas engineering (Khimicheskoe i neftegazovoe mashinostroyenie), 2017, no. 10, pp. 34-39.

3. "ApacheTomcat. Guide to UbuntuServer", available at: https://help.ubuntu.com/lts/serverguide/tomcat.html

4. Eckel B. "The philosophy of Java. Programmer's library. Ed. 4th" ("Filosofiya Java. Biblioteka programmista. Izd. 4e"), St. Petersburg, Piter, 2009, 640 p.

5. "Log4j2 configuration", available at: https://logging.apache.org/log4j/2.x/manual/configuration.html

6. "Monitoring services with Prometheus", available at: https://blog.selectel.ru/monitoring-servisov-s-prometheus/

7. Kravets O.Ya., Podval'nyy S.L. "Development of information support components to support requests to the subsystem of monitoring results", Control systems and information technology (Sistemy upravleniya i informatsionnye tekhnologii), 2011, vol. 45, no. 3.1, pp. 158-161.

8. "Serialization in Java", available at: https://habr.com/post/60317/

Submitted 29.04.2018; revised 16.07.2018

Information about the authors

Vladimir F. Barabanov, Dr. Sc. (Technical), Professor, Voronezh State Technical University (14 Moskovskiy prospekt, Voronezh 394026, Russia), e-mail:bvf@list.ru

Natalia I. Grebennikova, Cand. Sc. (Technical), Associate Professor, Voronezh State Technical University (14 Moskovskiy prospekt, Voronezh 394026, Russia), e-mail:g-naty@yandex.ru

Dmitriy S. Galamaga, Student, Voronezh State Technical University (14 Moskovskiy prospekt, Voronezh 394026, Russia), e-mail: graf2242@gmail.com

Sergey L. Kenin, Cand. Sc. (Technical), Project Manager, Atos (65 Prospekt Truda, Voronezh 394026, Russia), e-mail: sergey.kenin@atos.net