Разработка веб-приложения для интерактивных занятий со студентами

Jetty начиная с версии 7 поддерживает спецификацию Servlet 2.5 API. Поддержка ServletAPI 3.0 добавлена в Jetty 8.

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

В простейшем случае сервер во время старта просматривает директорию $JETTY_HOME/webapps в поисках веб-приложений, которые могут представлять собой:

ѕ Некоторый файл foo.war, коорый будет опублекован в контексте /foo

ѕ Директория foo/ будет опубликована в контексте /foo. Если директория имеет поддиректорию WEB-INF, то она будет считаться динамическим приложением, в противном случае будет обслуживаться только статическое содержание.

Веб-приложения на java обычно упаковываются в архивы строго определённой структуры - Web application archives. Эти архивы содержат:

ѕ Код, выполняемый на сервере - классы java

ѕ Статические файлы (HTML, изображения, звуки и т.д.).

ѕ Код, выполняемый на стороне клиента (например, апплеты).

Архив WAR имеет строго определённую структуру директорий. Директория верхнего уровня считается коневой директорияе веб-приложения. В ней хранятся файлы JSP, классы и архивы апплетов, статические части веб-страниц. Поддиректория WEB-INF в свою очередь содержит:

ѕ файл web.xml - конфигурация данного веб-приложения

ѕ Файлы - дескрипторы библиотек тегов

ѕ директория classes, в которой хранятся основные классы приложения: сервленты и вспомогательные классы, компоненты JavaBeans

ѕ директория lib, в которой хранятся архивы JAR с библиотечными классами.

Допускается создавать отдельный директории для каждого приложения (т.е. фактически пакеты java) или в корневой директории сервера или в директории WEB-INF/classes. Следует обратить внимание, что если добавляются классы java в архив WAR, то архиватор автоматически добавляет их именно в директорию WEB-INF/classes. Это правильно, если есть намерение использовать их на стороне сервера, но не подходит если нужно использовать классы на стороне клиента. Чтобы классы были доступны, например, апплетам, их файлы должны находится в корневой директории веб-документов. Для этого нужно просто переместить файлы классов внутри архива.

Обычно среда разработки уже содержит инструмент для создания таких архивов, но можно создать архив WAR и с помощью архиватора JAR из стандартной поставки JDK:

jarcvfarchiveName.war

Чтобы запустить jetty, нужно перейти в директорию, в которую инсталлирован сервер и выполните команду:

java -jar start.jar etc/jetty.xml

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

http://localhost:8080/test

Конфигурация Jetty:

Аргументы команды запуска - пути к файлам конфигурации. Файл etc/jetty.xml - это конфигурция по умолчанию, которая сожержит детальное описание настроек сервера. Можно просто раскомментировать фрагменты, чтобы задать необходимые параметры. Для удобства начальная конфигурация приказывает серверу запускать все приложения из директории webapps.

Остановка сервера jetty:

Можно остановить jetty с помощью клавиш ctrl+c или использовать для старта команду:

java -DSTOP.PORT=8079 -DSTOP.KEY=secret -jar start.jar

Адляостановки - команду:

java -DSTOP.PORT=8079 -DSTOP.KEY=secret -jar start.jar --stop

Параметры STOP.PORT и STOP.KEY произвольны.

Embedded-сервер Jetty находится в классе org.eclipse.jetty.server.Server. И конструктор может содержать либо адрес сервера, либо номер порта:

Serverjetty = newServer(8082);

Далее нужно добавить в jetty нужные handlerы и запустить его. Запускается и останавливается jetty методами без параметров start() и stop() соответственно. А handler надо написать свой, создав новый класс. Чтобы у был handler для обработки соединений по протоколу WebSocket, нужно его наследовать от org.eclipse.jetty.websocket.WebSocketHandler:

public class ChatWebSocketHandler extends WebSocketHandler {

}

Укласса WebSocketHandler естьодинабстрактныйметод doWebSocketConnect(). Он и вызывается, когда браузер открывает новое соединение с jetty, и возвращает объект WebSocketа.

Класс WebSocket тоже следует определить свой, и наследовать его нужно от интерфейса org.eclipse.jetty.websocket.WebSocket.OnTextMessage -- этот интерфейс работает с данными, проходящими через протокол WebSocket, как с текстовыми данными. Интерфейс org.eclipse.jetty.websocket.WebSocket.OnTextMessage содержит три метода:

ѕ onOpen() - вызывается после открытия сокета;

ѕ onClose() - вызывается перед закрытием сокета;

ѕ onMessage() - вызывается когда приходит сообщение от клиента.

3.5 Сетевая библиотекаNetty для работы с JavaNIO2

Фреймворк Netty появился относительно недавно, но с каждым годом он только набирает популярность. В 2011 году проект |был удостоен награды Duke'sChoice за инновации в сетевом программировании.

Cегодня его используют в своих разработках такие гиганты, как Apple, Twitter, Facebook, Google и Instagram. На базе Netty построены многие известные проекты с открытым кодом: Infinispan, HornetQ, Vert.x, ApacheCassandra и Elasticsearch.

Изначально в Java использовалисьтолько блокирующие сокеты. Это значит, что функция чтения из сокета ожидает до тех пор, пока не считается хотя бы один байт или не произошел разрыв соединения. Функция записи в сокет ожидает, пока все данные не будут переданы. Чтобы обработать несколько клиентов, требуется выделять по потоку на клиента. Чем больше клиентов, тем больше потоков. Но переключение между потоками занимает значительную часть процессорного времени, а потоки большую часть времени просто простаивают. Так что переключаться приходится часто, нагрузка на систему растет и чем больше клиентов подключается, тем медленнее они получают ответ сервера.

Но сокеты можно настроить таким образом, чтобы сразу узнавать, есть там данные или нет, при чтении и не ждать передачи всех данных при записи. Это так называемые неблокирующие сокеты. Они позволяют одному потоку взаимодействовать с несколькими клиентами. В Java поддержка неблокирующих сокетов появилась только в версии 1.4 в виде JavaNIO. JavaNIO первоначально расшифровывалось как New 10, но теперь оно уже никакое не новое, поэтому и называется Non-blocking Ю.

JavaNIO состоит из трех главных компонентов: каналов, буферов и селекторов.

Каналы похожи на потоки ввода/вывода (stream) с небольшими отличиями. Они обеспечивают двухстороннюю передачу данных, в один канал можно и писать, и читать. Чтение из канала и запись данных происходит асинхронно. Каналы всегда читают данные из буфера и пишут в буфер. Основные реализации каналов: FileChannel, DatagramChannel, SocketChannel, ServerSocketChannel.

Буфер представляет собой блок данных в памяти ограниченного размера и набор методов, облегчающих работу с ним. Буфер можно переключать в режим чтения и в режим записи. Один канал может работать с несколькими буферами, что позволяет не копировать данные на разных уровнях обработки. Если нужно, к примеру, добавить к данным заголовок, достаточно просто создать отдельный буфер для него, не копируя при этом сами данные. Основные классы буферов: ByteBuffer, MappedByteBuffer, CharBuffer, DoubleBuffer и другие.

Селектор -- это компонент, который работает с каналами. В одном селекторе можно зарегистрировать несколько каналов, указав, какие именно события нужно отслеживать. Бывает четыре вида событий: «соединение с сервером установлено», «входящее соединение принято», «можно читать данные», «можно писать данные». Метод select блокирует выполнение кода, пока хотя бы в одном из каналов не произойдет интересующее селектор событие. Есть также и неблокирующий аналог метода select.

В Java 7 появилось расширение NIO под названием NIO2. В нем архитектура взаимодействия с каналами была немного изменена. Теперь стало возможным получать и отправлять данные асинхронно. Больше не нужно постоянно проверять, не появилось ли новое событие канала. Достаточно запустить операцию и зарегистрировать слушателя, который узнает о ее выполнении. Либо можно воспользоваться классом Future. Объект Future моделирует выполняемую операцию. С его помощью можно проверить, выполнена ли операция или заблокировать выполнение потока, пока не будет получен результат.

Таким образом, в Java существует три способа работы с сетевыми клиентами. Netty умеет работать со всеми тремя. Кроме того, Netty успешно борется с некоторыми проблемами NIO и NIO2. Например, NIO может работать немного по-разному на разных платформах, так как NIO реализован на низком уровне. И если какие-то тесты работают в Linux, нет стопроцентной гарантии, что они будут работать в Windows. NIO2 поддерживается только с седьмой версии Java. Так что для пользователей шестой Java придется писать свою версию сервера. Netty же предоставляет единый интерфейс работы с NIO, NIO2 и даже блокирующими сокетами -- просто нужно указать, какой из фреймворков нужен.

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

Еще один недостаток может подстерегать пользователей Linux-систем. Согласно документации, селектор должен ожидать появления события, но из-за ошибки в системе уведомлений epoll может возникать ситуация, когда селектор выходит из блокировки, даже если событий канала нет. В результате он начинает проверять каналы в цикле и нагружает процессор на 100%. Netty справляется с этой и другими проблемами.

Netty также избавляет от сложностей асинхронного кода. Рассмотрим, к примеру, селектор. Метод select может вернуть разнообразные события (можно писать в канал, можно читать, «клиент присоединился»), чтобы разобраться, придется писать if-else конструкцию, поддерживать которую -- дорого по времени и ресурсам. Поэтому в Netty используется паттерн реактор. Каждому событию можно назначить свой обработчик. В Netty этот паттерн получил дальнейшее развитие. Каждому событию можно назначить цепочку обработчиков, выходное значение первого обработчика служит входным значением второго обработчика и так далее. Это облегчает последовательную обработку информации. К примеру, если клиент присылает сжатые зашифрованные данные, то первый обработчик разархивирует данные, второй расшифровывает, а третий уже непосредственно их обрабатывает. Если потребуется еще какая-то дополнительная обработка данных, то достаточно просто вставить новый обработчик в эту цепочку.

Приложение Netty начинается с классов Bootstrap и ServerBootstrapBootstrap занимается инициализацией и конфигурацией инфраструктуры клиента, ServerBootstrap инициализирует сервер.

За обработку данных отвечают экземпляры ChannelHandler. Обработчики переводят объекты в бинарные данные и наоборот, а также предоставляют метод обработки ошибок, которые возникают в процессе. Таким образом, вся бизнес-логика происходит в обработчике. Обработчики разделяются на два типа: ChannellnboundHandler и ChannelOutboundHandler. Первый тип для работы с входящими данными, второй -- с исходящими.

Когда Netty подключается к серверу или принимает соединение от клиента, он должен знать, как обрабатывать данные, которые принимаются и отсылаются. Инициализацией и конфигурацией обработчиков данных занимается Channellnitializer. Он добавляет реализации ChannelHandler к ChannelPipeline. ChannelPipeline передает данные на обработку всем обработчикам в порядке, в котором они были добавлены. Каждому последующему обработчику передаются данные, уже обработанные в предыдущем.

Все операции ввода-вывода для канала выполняются в цикле событий EventLoop. Несколько циклов событий объединяются в группу EventLoopGroup. Bootstrap клиента создает один экземпляр EventLoopGroup. ServerBootstrap для сервера создает два экземпляра EventLoopGroup. Один экземпляр только принимает соединения от клиентов, второй обрабатывает остальные события: чтение/запись данных и так далее. Это помогает избежать тайм-аута при подключении к серверу новых клиентов.

Когда канал регистрируется, он привязывается к определенному циклу событий на все время своего существования. Цикл событий всегда выполняется в одном и том же потоке, поэтому не нужно заботиться о синхронизации операций ввода-вывода канала. Поскольку обычно один EventLoop работает с несколькими каналами, важно не выполнять никаких блокирующих операций в ChannelHandler. Но если это все же требуется, то Netty предоставляет возможность указать EventExecutorGroup при регистрации канала, EventExecutor которого будет выполнять все методы ChannelHandler в отдельном потоке, не нагружая EventLoop канала.

Все операции в Netty выполняются асинхронно. Это значит, что операция будет выполнена не сразу, а через некоторое время. Чтобы понять, выполнилась операция или нет, Netty предоставляет Future и ChannelFuture. Future позволяет зарегистрировать слушателя, который будет уведомлен о выполнении операции. ChannelFuture может блокировать выполнение потока до окончания выполнения операции.

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

Netty позволяет передавать данные через TCP или UDP, поддерживает множество протоколов, таких как HTTP, FTP, SMTP, WebSockets, SSL/TLC, SPDY.

3.6 Проектирование и реализациявеб-приложения

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

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

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

Рис 3.2 - Диаграмма проекта

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

Рис. 3.4 - Диаграмма пакета converter



Пакет data содержит пакеты классы для работы с информацией, разрабатываемой, получаемой, обрабатываемой в процессе занятий на конференциях, досках, передаваемых файлах и т.д., а также передачи информации в БД.

Рис. 3.5 - Диаграмма пакета data

Пакет documentsсодержит классы, реализующие логику работы с документами: загрузки и выгрузки презентаций, генерации PDF-документов, графиков и т.д.

Рис. 3.6 - Диаграмма пакета documents



Пакет ldap определяет реализацию работы клиента и сервера с помощью протокола LDAP.

Рис. 3.7 - Диаграмма пакета ldap

Пакет mail служит для формирования различных уведомлений и рассылок посредством электронной почты и sms.

Рис. 3.8 - Диаграмма пакета mail

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

Рис. 3.9 - Диаграмма пакета remote



Пакет rssреализует RSS-канал.

Рис. 3.10 - Диаграмма пакета rss

Пакет sessionотвечает за работу с сессиями пользователей и конференций. Работа реализована при помощи библиотеки Netty.

Рис. 3.11 - Диаграмма пакета session

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

Рис. 3.12 - Диаграмма пакета util



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

Следует отметить также и следующее. Как было сказано, разработка подчиняется некоторым стандартам Java, один из которых - JavaCodeConventions. Стандарт определяет правила написания кода: отступы, количество строк в методах, переносы, а также правила именования методов, классов, полей. Подразумевается, что именование должно однозначно говорить, каккую логику реализует метод, для чего нужно поле, что представляет из себя класс. По этой причине отсутствует явная необходимость пояснять каждый метод и класс в отдельности, т.к. из названий становится понятно, какой класс за что отвечает, какими свойствами и поведением обладает: достаточно только привести диаграмму с имеющимися полями и методами.

Для обеспечения гарантии, что код будет написан в соответствии с конвенциями, был применен специальный плагин для системы сборки Maven: maven-checkstyle-plugin.

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

Из наиболее часто используемых и простых проверок:

ѕ Наличие комментариев

ѕ Размер класса не более N строк

ѕ В конструкции в try-catch, блок catch не пустой.

ѕ Не используется System.out.println(.. вместо LOG.error(..

Подключить плагин довольно просто:

<plugins>

<plugin>

<groupId>org.apache.maven.plugins</groupId>

<artifactId>maven-checkstyle-plugin</artifactId>

<version>2.7</version>

</plugin>

Послеэтогоможнозапуститьпроверкукода:mvn checkstyle: check

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

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

Внутри jar плагина есть примеры конфигурационных файлов:

ѕ config/sun_checks.xml - от Sun Microsystems. Используются по умолчанию.

ѕ config/maven_checks.xml - от Maven.

ѕ config/turbine_checks.xml -от Turbine.

ѕ config/avalon_checks.xml - от Avalon.

Если вкаком-то месте кода появляется ошибка, но по объективным причинам код такой и должен быть, можно подавить вывод ошбки используя модуль SuppressionCommentFilter или SuppressionFilter

Итак, в результате указанные выше пакеты и классы были реализованы в соответствии с теми требованиями которые были предъявлены. Нецелесообразно приводить все классы и методы в них, рассмотрим с небольшими пояснениями лишь некоторые.

Отметим, что для ознакомления с полным перечнем классов, пакетов и методов был сгенерирован Javadocпо всему проекту.

Ниже на рис.3.9 - 3.20 приведены UML-диаграммы классов с реализованными методами.

Класс SessionManager реализует логику по настройке сессий и работе с ними.

Рис 3.13 -Диаграмма класса SessionManager.

Класс MainServiceлогику работы с пользователями, конференциями, «комнатами» и т.д.

Рис 3.14 - Диаграмма классаMainService

Класс UserService реализует работу с профилями пользователей в конференциях и чатах, задействует фреймворк Spring.

Рис 3.15 - Диаграмма классаUserService

Класс MailHandler облегчает процесс работы с рассылкой электронной почты.

Рис 3.16 - Диаграмма классаMailHandler

В проекта содержится пакет для работыс документами, диаграмма которого уже была приведена. Работа с документами, в целом, построена по одному принципу, сводится к загрузке и выгрузке документов, а также генерации PDF.

Рис 3.17 - Диаграмма класса GeneratePDF

Рис 3.18 - Диаграмма класса LoadLibraryPresentation

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

Рис 3.19 - Диаграмма WhiteboardObjectSyncManager

Класс RoomManager создан для управления комнатами, чатами и конференциями.



Рис 3.20 - Диаграмма классаRoomManager

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

Рис 3.21 - Диаграмма WebSocketHelper



Класс DatabaseStore служит для обращения к БД, загрузке данных из нее и сохранению.

Рис 3.22 - Диаграмма классаDatabaseStore

На этом рассмотрение классов и пакетов, описание разработки и инструментов завершено.

В результате разработки был получен прототипвеб-приложения для проведения интерактивных занятий со студентами. Система построена в виде веб-приложения с трехзвенной архитектурой, имеет веб-интерфейс и была протестирована с помощью Unit-тестов. Скриншот интерфейса запущенного веб-приложения приведен на рис 3.23-25.

Рис 3.23 - Скриншот окна с доступными интерактивными занятиями



Рис 3.24 - Скриншот окна с доской для рисования

Рис 3.25 - Скриншот окна профиля пользователя



Заключение

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

Были выполнены описанные требования:

ѕ Спроектировать архитектуру приложения;

ѕ Выбрать инструменты и методы реализации на языке Java;

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

ѕ Приложение не должно обладать другими избыточными функциями;

ѕ Приложение должно быть легко масштабируемо и дополняемо;

ѕ Код должен быть снабжен документацией и комментариями;

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

ѕ Реализовать веб-интерфейс приложения

ѕ Реализовать приложение в формате трехзвенной архитектуры

ѕ Работу клиента и сервера производить через специальный протокол

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

ѕ Хранение объектов в БД

ѕ Загрузка объектов из БД при запуске приложения

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

ѕ Возможность проведения видеоконференций и вебинаров

ѕ Функция чата и рассылок

ѕ Возможность общего доступа к используемым документам в при проведении занятий

ѕ Сохранение видео с занятий

ѕ Иные возможности на усмотрение разработчика;

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

Написанное приложение соответствует поставленным требованиям, выполнено в соответствии со стандартами разработки на языке Java, с соблюдением правил написания кода и стандартов именования объектов.

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

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

Размещено на Allbest.ru

...