DESIGNING OF DATA REPLICATION METHOD IN MULTIUSER REAL-TIME WEB APPLICATION BASED ON WEBSOCKET PROTOCOL

Full Text

Введение На ранних этапах создания интернета перед разработчиками протокола HTTP не стояла сделать его интерактивным, так как протокол был изначально разработан именно для передачи HTML и незначительного количества сопутствующих внедрений [11-12]. В связи с этим определилась стабильная архитектура построения веб-приложений, основанная на использования в основном только методов GET и POST. За последнее десятилетие с бурным развитием интернета многие пришли к пониманию о необходимости разработки и внедрения концепции интернет приложений реального времени. Были предприняты попытки построения концепций таких приложений на базе уже имеющегося HTTP протокола. Они получили общее название «Comet» - модель построения веб-приложений, которая позволяет веб-серверу отправлять данные клиенту без дополнительных запросов. Данный подход, в основном, базируется на «long polling» механизме запросов - таких HTTP-запросов, ответ на которые дается не сразу, а только по некоторому событию. На практике «long polling» запросы для предотвращения проблем с соединением, например, из-за прокси-серверов, часто ограничивают по времени. Одним из примеров использования данного подхода в построении веб-приложения является использование Bayeux-протокола, позволяющего обмениваться асинхронными сообщениями по протоколу HTTP. Использование данного протокола, например, в SaleForce Streaming API [1], позволяет оформить подписку на конкретные события, а также отменить её, если необходимо. Кроме уже упомянутой проблемы с ограничением long-polling запросов по времени, что кроме этого ведет к увеличению трафика (в случае активного использования весьма значительного), данные подходы не позволяют реализовать полнодуплексное соединение, так как действия, происходящие между запросами, могут быть «потеряны» для пользователя. Для устранения недостатков данных подходов был предложен протокол WebSocket - асинхронный протокол поверх TCP-соединения, специально предназначенный для передачи сообщений в режиме реального времени. Данный протокол быстро получил популярность, приобрел множество реализаций, предоставляющих удобное API для взаимодействия серверной и клиентской стороны. Одной из наиболее популярных реализаций является библиотека Socket.IO [2], написанная на JavaScript и Node.JS. Также популярность набирает реализация WebSocket для Spring Framework [7-8]. Построение приложения на базе протокола WebSocket связано с определенными трудностями на этапе проектирования его архитектуры [6]. Рассмотрим основные особенности архитектуры приложений, понимание которых необходимо для построения системы реального времени. Приложение можно представить, как подчиняющийся бизнес логике процесс управления базой данных через интерфейс пользователя. Другими словами, можно выделить три основные составляющие приложения: базу данных, бизнес-логику и интерфейс пользователя. В последние годы активное развитие приобрели технологии NoSQL баз данных [9-10], вызванное, не в последнюю очередь, увеличением количества данных, обрабатываемых в сети «Интернет». Несмотря на это, реляционный подход к построению баз данных нисколько не утратил актуальность: простое для пользователя представление информации в виде отношений, развитый математический аппарат их представления, удобство и простота сопровождения делают данный подход идеальным при построении систем с малым и средним объемом обрабатываемых данных. Интерфейс пользователя можно представить, как совокупность представлений (view) данных из нескольких таблиц (выборки), отображаемых посредством графических элементов. В конкретный момент времени пользователь может работать сразу с несколькими представлениями, которые, в том числе, могут использовать одни и те же данные, относящиеся к одной таблице, но входящие в разные выборки. При построении веб-приложения реального времени это означает, что должна быть возможность «подписаться» на события изменения отображаемых данных так, что при изменении одного отображения, данные которого участвуют в другом, изменения должны отобразить оба. Это приводит к основным концепциям предлагаемого подхода: - должны фиксироваться изменения конкретных данных; - изменение данных должно порождать информирующие события; - пользовательские представления (view) должны иметь возможность подписываться на события, порождаемые изменением данных; - использование протокола WebSocket при реализации. Модель представлений данных Формализуем предложенные концепции относительно реляционных баз данных. Рассмотрим структуру реляционной базы данных с точки зрения теории множеств. Пусть R - реляционная база данных, состоящая из k отношений , i = 1…k: . (1) В свою очередь каждое отношение представляет собой совокупность атрибутов , где : . (2) Любое отношение может содержать от до ключей: - первичных ; - внешних , где . На каждом отношении можно определить выборку - кортеж над отношением , отобранный по некому предикату С: . Внешние ключи задают связь между двумя отношениями, то есть если между отношениями задан внешний ключ, то существует отображение атрибутов из отношения в отношение такое, что и . (3) При этом у пары , должны совпадать типы данных у соответствующих пар атрибутов, а в рамках двух записей должны совпадать значения этих атрибутов. Множество ключей таблицы может включать в себя уникальные ключи - ключи, однозначно идентифицирующие записи отношения: . (4) На каждом отношении можно задать конечное количество: . (5) Рассмотрим структуру отображения базы данных у пользователя. Пользователь получает доступ к базе через пользовательский интерфейс - совокупность элементов интерфейса (панели, DataGrid (сетка данных), всплывающих уведомлений и т.д.): , (6) где . Каждый из элементов интерфейса отображает данные некой совокупности выборок из одного или более отношений: (7) Модель взаимодействия клиента В упрощенном виде сценарий поведения пользователя можно представить с помощью двух функций - отображения интерфейса пользователя на базу данных , и обратного к нему отображения: . Так как передача данных в реальных системах может выполниться неверно или вообще не выполниться, например, из-за сбоя соединения, процессы обновления пользовательских интерфейсов, описываемые данными отображения, должны выполняться парой. Тогда выполнение пользователем действия с интерфейсом можно записать как с помощью следующей функции: . (8) При стандартном подходе к проектированию веб-приложений данные отображения выглядят довольно тривиально: совокупность (объединение) выборок из одного или нескольких отображений служат для формирования элементов интерфейса пользователя . Воздействие пользователя на базу данных происходит в обратном направлении - на основании данных из графического интерфейса заполняются соответствующие подмножества атрибутов отношений и происходит их обновление, и, в зависимости от удачного или неудачного изменения данных в базе, интерфейс пользователя обновляется к новым данным или откатывается к предыдущей версии. И, так как в сессии обновления данных участвует лишь один пользователь, изменения базы затрагивает лишь графические элементы . Модель многопользовательского доступа к данным Данная система усложняется с введением в нее нескольких пользователей. Пусть задано множество пользователей U вида . (9) Рассмотрим сначала простой случай, когда все пользователи используют один элемент интерфейса (например, редактируемая сетка). Хотя у каждого i-го пользователя одна и та же форма-представление, объекты выборок могут различаться (так как каждый пользователь может запрашивать свои данные): , (10) где - форма представление для пользователя , - выборка из отношения для пользователя Теперь при выполнении отображения f интерфейсы пользователей, участвующих в отображении измененяемых данных, связанные с обновляемыми данными, также должны обновиться. Таким образом, появляется новое отображение, затрагивающее связанные с выборками данные: . (11) Тогда функция (8) записывается в виде: (12) где . Рассмотрим теперь случай с двумя пользовательскими элементами интерфейса, изменение одного из которых влечет изменение другого: и , с выборками, имеющими пересечение, то есть . (13) Нетрудно заметить, что в данном случае, помимо отображения , задающего преобразование данных из одной выборки, присутствует также отображение, задающее преобразование данных между двумя различными выборками. Пусть при воздействии из элемента интерфейса на базу R при помощи отображения f затрагиваются выборки . Непустое подмножество данных выборок используется в форме : . Тогда существуют множества такие, что , . Таким образом имеем структурное отображение: . (14) Это значит, что по имеющемуся подмножеству Q отображение vs может восстанавливать - разницу, между и Q. Теперь с помощью vs необходимо построить отображение, восстанавливающее данные пользователя i по подмножеству измененных данных пользователя j. Пусть для i-го пользователя известна подвыборка , по которой нужно найти недостающее подмножество . Без дополнительной информации о существует различных выборок, которых можно восстановить по известному , где - количество картежей в выборке для пользователя . В случае, если известны уникальные ключи , однозначно идентифицирующие кортежи , количество вариантов восстанавливаемых сокращается до одного. Таким образом по имеющимся и можно сделать выборку из базы, восстанавливающую , которая задается отображением вида . (15) Общий случай выглядит следующим образом: . (16) Функция (2) преобразуется к виду: (17) где . Для завершения данной модели нужно ввести несколько вспомогательных преобразований. Элемент интерфейса задается совокупностью атрибутов отношений, присутствующих в выборках . Для отображения данный элемента в конкретные атрибуты отношений базы данных необходимо ввести отображение из в подвыборку каждого отношения, участвующего в представлении: . (18) Обратное преобразование выполняется не полностью на , а на подмножество элементов , учувствовавших в преобразовании fv: . (19) Архитектура приложения Рассмотрим пример построения архитектуры веб-приложения на базе рассмотренного подхода. На рисунке 1 представлена схема архитектуры веб-приложения, построенного на базе шаблона MVVM (Model-View-ViewModel) [3]. Пусть пользователь пытается изменить базу данных, взаимодействуя с представлением (view). При этом происходит его «подписка» на события изменения отображаемых у него данных. Его действия запускают функцию , передавая команды манипулирования данными в слой бизнес-логики приложения. Далее ViewModel разделяет присланные пользователем данные на подвыборки, заполняет ими соответствующие модели (model), и через специальный программный слой (evented tables) происходит их обновление в базе данных (преобразование fv). На этом функция f завершает работу, возвращая текущее состояние базы данных. Рисунок 1. Схема архитектуры веб-приложения реального времени: UI -интерфейс пользователя; R - база данных; F - приложение обеспечивающее бизнес логику Если функция f успешно завершила работу, слой evented tables «поджигает» события об изменении таблиц, передавая в качестве параметров измененные данные. ViewModel реагирует на данные события, восстанавливая модели, которые в текущий момент используют пользователи (преобразование ). Это возможно благодаря уникальным ключам моделей, задействованных пользователями. Так как протокол WebSocket асинхронный, приложение отсылает пользователям затронутые изменениями данные и завершается преобразование G. Заключение Хотя предлагаемый подход не лишен недостатков, например, таких, как сложность реализации слоя бизнес логики или проблематичность интеграции данного решения в уже работающие проекты (в основном из-за необходимости отслеживания изменений моделей), он может хорошо зарекомендовать себя в случаях, где критически важно иметь полное представление о событиях в динамической системе, не налагая дополнительных условий на соединение [4-5].

About the authors

Ivan Vladimirovich Sinitsin

Bryansk State Technical University

Email: joker.n7@gmail.com

Evgeny Alekseyevich Leonov

Bryansk State Technical University

Email: johnelonov@gmail.com

Andrey Vladimirovich Averchenkov

Bryansk State Technical University

Email: mahar@mail.ru

Sergey Aleksandrovich Sheptunov

Institute for Design and Technological Informatics of RAS

Email: ship@ikti.org.ru

References

Supplementary files