Разработка метода репликации данных между клиентами в многопользовательских веб-приложениях реального времени, построенных на базе протокола Websocket

На ранних этапах создания Internet перед разработчиками протокола HTTP не стояла задача сделать его интерактивным, так как протокол был изначально разработан именно для передачи HTML и незначительного количества сопутствующих внедрений [11-12]. В связи с этим определилась стабильная архитектура построения веб-приложений, основанная на использования в основном только методов GET и POST.

За последнее десятилетие с бурным развитием Internet многие пришли к пониманию необходимости разработки и внедрения концепции интер-нет-приложений реального времени. Были предприняты попытки построения концепций таких приложений на базе уже имеющегося 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], вызванное, не в последнюю очередь, увеличением количества данных, обрабатываемых в Internet. Несмотря на это, реляционный подход к построению баз данных нисколько не утратил актуальность: простое для пользователя представление информации в виде отношений, развитый математический аппарат их представления, удобство и простота сопровождения делают данный подход идеальным при построении систем с малым и средним объемом обрабатываемых данных.

Интерфейс пользователя можно представить, как совокупность представлений (view) данных из нескольких таблиц (выборки), отображаемых посредством графических элементов. В конкретный момент времени пользователь может работать сразу с несколькими представлениями, которые, в том числе, могут использовать одни и те же данные, относящиеся к одной таблице, но входящие в разные выборки. При построении веб-приложения реального времени это означает, что должна быть возможность «подписаться» на события изменения отображаемых данных так, что при изменении одного отображения, данные которого участвуют в другом, изменения должны отобразить оба. Это приводит к основным концепциям предлагаемого подхода:

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

– изменение данных должно порождать информирующие события;

– пользовательские представления (view) должны иметь возможность подписываться на события, порождаемые изменением данных;

– использование протокола WebSocket при реализации.

Модель представлений данных

Формализуем предложенные концепции относительно реляционных баз данных. Рассмотрим структуру реляционной базы данных с точки зрения теории множеств. Пусть R – реляционная база данных, состоящая из k отношений T,,i= L..k;

R = {T_l,T₂,...,T_j,...,T_k}.            (1)

В свою очередь каждое отношение представляет собой совокупность атрибутов

/ J i где LT,^:

Tj j 67| , ^2 ,. . ., Cl-,. . ., ^£7;

Любое отношение 77 может содержать от 0 до n _T ключей:

– первичных Pk = {a_x,a₂,...,a_i,...,a^}-,

– внешних Рк₆=^а_х a_v. а_р...,а^, где LPk = \Pk_}\,LFk = \Fk].

На каждом отношении можно определить выборку ^^ – кортеж над отношением Tj т отобранный по некому предикату С :

При этом у пары Fkp, Sk^¹’ должны совпадать типы данных у соответствующих пар атрибутов, а в рамках двух записей должны совпадать значения этих атрибутов.

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

UkTt ePkTk \jFkTk .

На каждом отношении можно задать конечное количество:

S^T- = \s^TV ,S^T^ ,...,8^ТС ,...,8^ТД.       (5)

Рассмотрим структуру отображения базы данных у пользователя. Пользователь получает доступ к базе через пользовательский интерфейс – совокупность элементов интерфейса Vj (панели, DataGrid (сетка данных), всплывающих уведомлений и т.д.):

ствует лишь один пользователь, изменения базы затрагивает лишь графические элементы V ■

и^К^.-.у^.-УшА,    (6)

Модель многопользовательского доступа к данным

Данная система усложняется с введением в нее нескольких пользователей. Пусть задано множество пользователей U вида

где LUI = \UI\. Каждый из элементов интерфейса отображает данные некой совокупности выборок из одного или более отношений:

U = { гц,гц,. ..,и,,. ..,u„} •

V — ^^т\     V⁷! V^r2 ^^Tl Q^Tk ) —

Г/-^! ^ --’^ ?31 ’•••’DJ2 ?---?°./A. j —

{ sp I T^k e R^ .

Модель взаимодействия клиента

В упрощенном виде сценарий поведения пользователя можно представить с помощью двух функций – отображения интерфейса пользователя на базу данных f'-UI—> R ,

Рассмотрим сначала простой случай, когда все пользователи используют один элемент интерфейса Vj (например, редактируемая сетка). Хотя у каждого i -го пользователя одна и та же форма-представление, объекты выборок могут различаться (так как каждый пользователь может запрашивать свои данные):

V; e Vj ~ {s^ }g ^ },        (10)

и обратного к нему отображения: g = F' :R^UI.

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

<₈ЯаЫМФ4 (8)

где v"' – форма представление IF для пользователя U_f, s**'^ – выборка s. из отношения T_k для пользователя u_t. Теперь при выполнении отображения f интерфейсы пользователей, участвующих в отображении измененяемых данных, связанные с обновляемыми данными, также должны обновиться. Таким образом, появляется новое отображение, затрагивающее связанные с выборками данные:

u

Тогда функция (8) записывается в виде:

F^f,g’\3,ur\R^

g\f(ui\R\[)MUr>}

При стандартном подходе к проектированию веб-приложений данные отображения выглядят довольно тривиально: совокупность (объединение) выборок из одного или нескольких отображений U j^°.i служит для формирования элементов интерфейса пользователя ^ • Воздействие пользователя на базу данных происходит в обратном направлении – на основании данных из графического интерфейса заполняются соответствующие подмножества атрибутов отношений и происходит их обновление, и, в зависимости от удачного или неудачного изменения данных в базе, интерфейс пользователя обновляется к новым данным или откатывается к предыдущей версии. И, так как в сессии обновления данных уча-

где Up U j, иI G U .

Рассмотрим теперь случай с двумя пользовательскими элементами интерфейса, изменение одного из которых влечет изменение другого: vf' и v2z, с выборками, имеющими пересечение, то есть

к .Fl ^ ^^⁵ ^1 ^~ ^2 ’     (13)

Нетрудно заметить, что в данном случае, помимо отображения g' ’ задающего преобразование данных из одной выборки, присутствует также отображение, задающее преобразование данных между двумя различными выборками. Пусть при воздействии из элемента интерфейса У_А на базу R при помощи отображения f затра-

гиваются выборки Непустое подмножество данных выборок используется в форме к₂~{^^}_: ^ГЖ^Цз^У То гда сущест вуют множества v₂=v₂\q,y_x=v_x\q такие, что v_x№=0, ужж_х=0. Таким образом имеем структурное отображение:

Функция (2) преобразуется к виду:

руг,о,и,иг\^

С^^уГуК^идГ'У

vs-.V^V.-V^Q^V^Q.  (14)

Это значит, что по имеющемуся подмножеству Q отображение vs может восстанавливать ^2 – разницу, между V. и Q . Теперь с помощью vs необходимо построить отображение, восстанавливающее данные пользователя i по подмножеству измененных данных пользователя j . Пусть для i -го пользователя известна подвыборка q¹*' G Q , по которой нужно найти недостающее

подмножество ^v2 e y₂ . Без дополнительной ин-

формации о ^V2 существует

различ-

где Uj,UJ,и, g U .

Для завершения данной модели нужно ввести несколько вспомогательных преобразований. Элемент интерфейса У₍ задается совокупностью атрибутов отношений, присутствующих в выборках Um^~u,.^- Для отображения данный элемента в конкретные атрибуты отношений базы данных необходимо ввести отображение из Vj в подвыборку ^^Tj^k каждого отношения, участвующего в представлении:

fv-.v^s^ Л-Х...^. (18)

Обратное преобразование выполняется не полностью на Vj, а на подмножество элементов JZ ti< учувствовавших в преобразовании fv :

ных выборок, которых можно восстановить по

известному q^lli

где

– количество

жей в выборке s^Tj для пользователя Uj .

корте-

В случае, если известны уникальные ключи uk^u,'^T', однозначно идентифицирующие кортежи s^ll"^Ti, количество вариантов восстанавлива-

емых ^V2' сокращается до одного. Таким образом, по имеющимся q¹¹' и uk₂ можно сделать выборку из базы, восстанавливающую vy , которая задается отображением вида

g" : vf' ^ Vk ~ ^q^Ui ,ик₂‘ ,R^ -> v₂' . (15)

Общий случай выглядит следующим образом:

Uwk’<'^}- (16)

К=_§У:8^т^У'\к = 1...И. (19)

Архитектура приложения

Рассмотрим пример построения архитектуры веб-приложения на базе рассмотренного подхода. На рисунке 1 представлена схема архитектуры вебприложения, построенного на базе шаблона MVVM (Model-View-ViewModel) [3]. Пусть пользователь пытается изменить базу данных, взаимодействуя с представлением (view). При этом происходит его «подписка» на события изменения отображаемых у него данных. Его действия запускают функцию №lkY передавая команды манипулирования данными в слой бизнес-логики приложения.

Рисунок 1. Схема архитектуры веб-приложения реального времени:

UI -интерфейс пользователя; R - база данных; F - приложение, обеспечивающее бизнес-логику

Далее ViewModel разделяет присланные пользователем данные на подвыборки, заполняет ими соответствующие модели ( model ) и через специальный программный слой ( evented tables ) происходит их обновление в базе данных (преобразование fv ). На этом функция f завершает работу, возвращая текущее состояние базы данных.

Если функция f успешно завершила работу, слой evented tables «поджигает» события об изменении таблиц, передавая в качестве параметров измененные данные. ViewModel реагирует на данные события, восстанавливая модели, которые в текущий момент используют пользователи (преобразование fv ¹). Это возможно благодаря уникальным ключам моделей, задействованных пользователями. Так как протокол WebSocket асинхронный, приложение отсылает пользователям затронутые изменениями данные и завершается преобразование G.

Заключение

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