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

П. П. Кейно, преподаватель кафедры «Системное моделирование и инженерная графика» ФГБОУ ВО «Московский авиационный институт (национальный исследовательский университет)»,

г. Москва, science@blockset.ru

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

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

Ключевые слова: Web, серверное программирование, высоконагруженные системы, системное программирование, межпроцессное взаимодействие, сокеты, сервера, базы данных, интерпретатор, синхронизатор, декларативное программирование, BML, BiockSet, XML, BSON.

Введение

Декларативному программированию на серверной стороне Web-приложения посвящены труды многих ученых. Профессор Илко Виссер предложил язык WebDSL на базе Java [1]. Профессор Майкл Ханус разработал «Spicey» — инструмент, являющийся надстройкой над «Curry» — встраиваемым языком программирования поверх языка Haskell [2]. Конечно, все эти языки работают в совершенно различных средах. В проекте BlockSet применена похожая методология, однако практическая реализация значительно отличается от схожих инструментариев. Если рассмотренные инструменты функционируют в составе уже имеющихся языков программирования,

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

В статьях [3; 4] определены основные понятия методологии. Напомним, что практической реализацией BlockSet является язык BML (англ. BlockSet Modeling Language) и его интерпретатор. Декларативный язык BML основан на XML-подобном синтаксисе. Выделяются четыре базовые сущности методологии, продублированные в языке: модель, локация, набор, блок. Набор представляет собой коллекцию данных различного типа. В качестве элементов коллекции высту-

[ 65 ]

пают блоки. Блок — это атомарный элемент, определяющий тип данных. Отличием блоков от типов данных в классических языках программирования является тот факт, что помимо стандартных конструкций (строка, целое, число с плавающей запятой и т. д.) в блоках могут присутствовать и более специфичные данные, такие как файлы, изображения, сложные строки и др. Кроме того, блок выполняет роль валидатора вводимых данных.

В модели определяется общая структура проекта, взаимосвязи наборов с блоками, а также другими наборами. Данные, хранящиеся в наборах, называются экземплярами набора. Модель является уникальным для одного проекта элементом и может быть задана только один раз. Кроме того, в модели определяются начальные атрибуты (по умолчанию) блоков и наборов, которые, в свою очередь, могут быть переопределены в локациях. Локация характеризует представление одной динамической страницы. Наборы и блоки также указываются в локации, но не все возможные, как в модели, а только необходимые этой локации в рамках своих функций. Здесь переопределяются некоторые атрибуты наборов и блоков, определенные в модели. Локация сопоставляется между шаблоном и запрошенным адресом URL. При совпадении шаблона с адресом выполняется логика работы совпавшей локации.

Логика работы языка BML хранится в файлах в специализированной директории и исполняется интерпретатором языка. Со структурами данных BML могут быть связаны многочисленные таблицы с достаточно сложными связями. Если разработчик пожелает поменять структуру BML, это может повлечь значительные изменения во внутренних архитектурах, в том числе и в структуре базы данных. Их перестроение может занимать продолжительное время. Таким образом, если интерпретируемая логика и процесс перестроения будут выполняться линейно, это повлечет за собой серьезные задержки в выполнении пользовательского запроса.

Для решения поставленной задачи были разделены механизмы перестроения внутренних структур и непосредственной обработки пользовательских запросов. Перестроение асинхронно во времени выполняет синхронизатор. Задача синхронизатора — обеспечить безболезненный переход от одной логики к другой, в то время, как интерпретатор хранит в оперативной памяти старые данные, загруженные до обновления, и исполняет логику на их основе до полного перестроения. После прохождения обновления интерпретатор может начать исполнять логику немедленно, согласно изменениям разработчика, не беспокоясь при этом, что возникнут ошибки при использовании обновленных структур.

Общий алгоритм работы

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

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

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

изменения даты и времени у файлов. Если изменение произошло, осуществляется подсчет контрольной суммы файла по алгоритму CRC32 [5]. При несовпадении полученного значения и ранее сохраненного в оперативной памяти либо если количество элементов массива не совпадает с количеством файлов, считается, что структура проекта была изменена. В таком случае происходит полное перестроение логической структуры кода BML в памяти путем последовательного считывания каждого файла и синтаксического анализа их содержимого. На рис. 1 показан общий алгоритм работы синхронизатора.

Межпроцессное взаимодействие

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

Алгоритм перестроения базы данных в проекте выделен в дочерний процесс, который создается системным вызовом fork() (см. рис. 1) и отделен от основной логики синхронизации. В родительском процессе сохраняется PID дочернего. Идентификатор сбрасывается, как только дочерний процесс завершается.

Для проверки факта завершения вызывается системный вызов waitpid() с опцией «WHOHANG», позволяющей не дожидаться окончания процесса, а только получить его состояние [6]. Признак завершения процесса — нулевой код возврата системного вызова. Также данный системный вызов возвращает код статуса завершения дочернего процесса. Сообществом разработчиков принято правило, согласно которому нулевой код возврата обозначает успешное завершение про-

цесса. Подпроцесс перестроения БД выполняется по такому же принципу. В случае возникновения ошибок возвращается число, отличное от нуля. К ошибкам подобного рода, к примеру, могут относиться неполадки работы СУБД или неудачная авторизация.

Важной особенностью также является то, что синхронизатор сохраняет логику BML в двух структурах: «A» и «B». Из структуры «A» считываются данные, передающиеся впоследствии клиентскому приложению (интерпретатору), а в структуру «B» — новые данные при обнаружении изменений в исходных файлах. После записи происходит проверка полученной структуры и сопоставление ее с базой данных, которая перестраивается согласно полученным изменениям (рис. 3). В процессе перестроения всем новым объектам присваивается постфикс «$modified». После получения системным вызовом waitpid() информации о завершении дочернего процесса структуры «A» и «B» меняются местами. Стоит обратить внимание, что присвоение постфикса «$deleted» устаревшим объектам и удаление постфикса «$modified» у новых происходит уже в родительском процессе, также после получения информации о завершенном дочернем. В отличие от громоздкого алгоритма копирования и перестроения данных, который был вынесен в отдельный процесс, процедура переименования сущностей имеет гораздо меньшие накладные расходы и может работать синхронно с основной логикой. Это единственная часть алгоритма взаимодействия с базой данных в родительском процессе. Такая архитектура обусловлена «мягким» переходом между конфигурациями, что гарантирует доступность данных на основе старой логики, пока выстраивается обновленная структура.

Сетевое взаимодействие

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

[ 67 ]

fork

*

Рис. 1. Общая архитектура синхронизатора

Fig. 1. Synchronizer's general architecture

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

Многие архитектуры клиент-серверных приложений используют отдельный процесс, порождаемый системным вызовом fork() для обработки входящих подключений. Дочерний процесс обрабатывает подключение синхронно, шаг за шагом. Подключение описанным способом блокирует исполнение остальной части программы [7]. Это означает, что процесс не завершится до тех пор, пока не будет разорвано подключение через сокет. К достоинствам такого подхода относится простота его реализации: нет необходимости введения дополнительных циклов и усложненных алгоритмических конструкций. Безусловно, это порождает недостаток, заключающийся в невозможности использовать подобный способ организации сетевого взаимодействия на высоконагруженных системах: поскольку на одно подключение выделяется один системный процесс, лимит на количество порождаемых процессов в системе с большим числом клиентов быстро исчерпается, поэтому часть из них будет находиться в режиме ожидания. В то же самое время использование неблокирующих соке-тов позволит обслужить множество клиентов, используя лишь один системный про-

цесс [8]. Тем не менее данная технология имеет другой недостаток — более трудоемкая процедура разработки, так как асинхронная природа неблокирующих сокетов требует более детального алгоритмического описания.

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

На рис. 2 показана общая схема сетевого взаимодействия FastCGI-процесса интерпретатора с синхронизатором. Особенность FastCGI, как уже было сказано, в том, что ее порожденный процесс не завершается после обслуживания клиентского запроса, а остается в памяти и ожидает нового подключения [9]. Это позволяет синхронизатору в принципе не закрывать соединение, а продолжать работу, ожидая новую порцию данных, что, в свою очередь, еще больше снижает накладные расходы, так как не требуется затрачивать системные ресурсы на установку очередного подключения. Конечно, подобная организация требует периодической отправки специализированного пакета от процесса FastCGI, в противном случае синхронизатор решит, что интерпретатор за-

Процесс синхронизатора

А

V /

V

А

V

Неблокирующий сокет

Данные BSON

Неблокирующий сокет

Данные BSON

Неблокирующий сокет

Данные BSON

Процесс FastCGI

Процесс FastCGI

Процесс FastCGI

Документ , в браузере 'клиента

Документ , в браузере 'клиента

Документ в браузере 'клиента

Рис. 2. Сетевое взаимодействие синхронизатора с процессом FastCGI

Fig. 2. Networking between synchronizer and FastCGI process

вершил работу и закроет соединение с ним по истечении периода ожидания.

Итак, основная задача синхронизатора, как было сказано в начале, — обеспечивать своевременную отправку актуальной информации о логических структурах BML интерпретатору, работающему с клиентами. То есть синхронизатор является своего рода сервером данных. В методологии BlockSet в целом и языке BML в частности существует разделение на модель и локации. Свойства, хранящиеся в модели, делятся на две группы: 1) отвечающие за глобальную архитектуру проекта (например, у блоков — тип данных, у наборов — отношения друг с другом); 2) свойства, устанавливаемые для локаций по умолчанию. Подобное деление обусловлено исключительно удобством разработчиков, использующих представленный язык. В локациях же значения свойств модели из второй группы будут полностью переопределены, а свойства первой группы идентичны для всех локаций. Особенность в том, что интерпретатор в один момент времени работает только с одной локацией, конечные свойства которой определяются слиянием свойств этой локации и модели. Таким образом, с технической точки зрения не имеет никакого смысла делить на две сущности единое целое.

Передачу данных инициирует интерпретатор (процесс FastCGI) при запросе клиента. Он запрашивает свойства локации, идентифицируемой по URI, передавая переменную окружения REQUEST_URI. Синхронизатор просматривает список локаций, выбирает подходящую под запрошенный критерий и формирует новую структуру на основе модели и найденной локации. Структура кодируется в формат BSON (двоичный JSON) и передается интерпретатору.

Выигрыш от использования такого подхода наблюдается во всех аспектах: объем данных сокращается, а работа с ними производится с максимальной производительностью, так как практически не затрачивается время на синтаксический анализ [10].

Нагрузочное тестирование

Как уже было сказано, для межпроцессного взаимодействия в проекте используются сетевые сокеты. Однако прежде чем сделать выбор в пользу данной технологии, был проведен ряд исследований. Для начала необходимо понять, каким комплексом технологий мы располагаем для решения поставленной задачи. К наиболее распространенным технологиям межпроцессного взаимодействия относятся: канал, разделяемая память и сетевые сокеты. Достоинство канала (англ. pipe) — в простоте реализации: достаточно осуществить его открытие и производить чтение и запись так, как это происходит с обычными файлами. Другой способ — разделяемая память (англ. shared memory). К основному ее достоинству относится наивысшая быстрота обмена данными по сравнению с другими методиками. Тем не менее такое преимущество соседствует с серьезными недостатками: это и сложности в реализации, и низкая безопасность, и отсутствие всякой кроссплатформенности.

Сетевые сокеты (англ. Network Sockets), на первый взгляд, являются наиболее громоздким способом организации межпроцессного взаимодействия. Но у этой технологии есть ряд значительных преимуществ. Во-первых, сокеты универсальны, что дает возможность их использования на любых операционных системах — сохраняется кроссплат-форменность разрабатываемых решений. Во-вторых, сетевые сокеты могут использоваться не только внутри одной системы, но и взаимодействовать с другими системами удаленно, что позволит в будущем обеспечить горизонтальное масштабирование архитектуры.

Тем не менее скорость обмена данными у сокетов одна из самых низких [11], поэтому при разработке возникло опасение, что связь между синхронизатором и интерпретатором будет образовывать «бутылочное горлышко» — уязвимое место в архитектуре, ограничивающее поток данных в системе. Для проверки данного предположения было проведено нагрузочное тестирование, результаты которого показаны на рис. 3.

Комплексное тестирование архитектуры, включающее клиента и синхронизатор, осуществлялось на рабочем сервере с процессором Intel Xeon E5640 с тактовой частотой 2,66 ГГц объемом ОЗУ 16 Гб и объемом жесткого диска 500 Гб. Испытания проводились для различных величин пакетов, порядок которых выбирался согласно примерному подсчету требуемого объема данных в реальном проекте, передаваемых на один запрос одного клиента: от 128 байт до 10 Кб. В качестве основных точек отсчета было взято различное количество клиентов — от 10 до 500. Стоит также отметить, что соединение при окончании обработки каждого клиента не закрывалось за счет использования неблокирующих сокетов.

Результаты испытаний показали, что наименьшее суммарное время обработки десяти клиентов при величине пакета 128 байт

не превышает 1 микросекунды, в то же время самый длительный цикл обработки пятисот клиентов при величине пакета 10 Кб занимает 107 мкс. На графике видно, что передача малых порций данных от 128 байт до 1 Кб занимает практически одинаковое количество времени, а со значительным возрастанием объема время, при прочих равных, начинает увеличиваться.

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

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

Исходя из этого, несмотря на то, что сокеты являются одной из самых медленных технологий межпроцессного взаимодействия, порядок величин затрачиваемого времени является

120

100

80

I 60

40 20 0

128 Б 512 Б 1 Кб 5 Кб 10 Кб

10

500

50 100 300

Количество клиентов Рис. 3. Результаты тестирования неблокирующих сокетов

Fig. 3. Non-blocking sockets performance testing results

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

Структура базы данных и ее перестроение

Имя набора ассоциируется с таблицей в базе данных, содержащей постфикс "$set" на конце. Имя блока по аналогии ассоциируется с полем таблицы и имеет постфикс "$blk". При необходимости структура базы данных перестраивается синхронизатором наряду со структурой исходных файлов.

Структура БД должна загружаться синхронизатором при запуске процедуры проверки соответствия базы данных с исходным кодом BML путем исполнения соответствующего запроса к СУБД. После этого осуществляется анализ BML на предмет наличия следующих факторов: добавление/переименование/удаление блока или набора, изменение типа блока.

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

Для предотвращения таких неопределенностей предлагается у наборов и блоков использовать атрибут oldname (старое имя) внутри модели наряду со стандартным атрибутом name, обозначающим уникальное имя, по которому идентифицируется объект. Общий алгоритм описанного преобразования представлен на рис. 4, где показана обобщенная схема перестроения таблиц наборов и полей блоков в базе данных. Здесь эти сущности объединены общим понятием «объект», а ана-

логичные сущности в понятиях синтаксиса BML — понятием «элемент».

При удалении объекта и наличии в нем данных (экземпляров наборов или блоков) соответствующее поле или таблица не удаляются физически из базы данных, а переименовываются, добавляя к своему имени постфикс "$deleted". Окончательное удаление объекта может произойти по прошествии определенного времени. Это сделано для того, чтобы избежать случайного удаления данных вследствие небольших изменений или опечаток в коде BML. Когда используется имя, задействованное ранее, и существует удаленный объект (таблица или поле), связанный с этим именем, то объект восстанавливается.

При изменении типа блока изменяется и тип в базе данных. При этом тип приводится согласно используемой СУБД. Изначально программный комплекс BlockSet использует MySQL, но существуют и технологические заделы под другие системы. В файле настроек синхронизатора существует опция, задающая его поведение при изменении типа, называемая «type_cast» и имеющая следующие значения: On (тип приводится всегда, предупреждение не выводится), Warning (тип приводится, но если в результате приведения происходит потеря данных, в файл журнала пишется предупреждение об этом), Off (приведение типа выключено, в журнал пишется предупреждение о несанкционированном изменении типа).

Синхронизация отношений таблиц и наборов

Синтаксис BML позволяет задать отношения между наборами. Наборы взаимосвязаны атрибутом «relation», устанавливающим, какой тип связи они имеют. Если у экземпляра родительского набора может быть множество экземпляров дочернего, то родительский набор имеет значение «parent» (например, у одной категории форума может быть множество

ПРИКЛАДНАЯ ИНФОРМАТИКА / JOURNAL OF APPLIED INFORMATICS

_ [ Том 11. № 2 (62). 2016 ]

Рис. 4. Алгоритм перестроения структуры базы данных

Fig. 4. Database structure changeover algorithm

Рис. 5. Специфика работы с конкретным объектом

Fig. 5. Procession scheme of the specific object

тем). При обратной ситуации устанавливается атрибут «child». Атрибут задает главенствующий набор: основной (родительский) или вложенный (дочерний). Если наборы состоят в равных правах, когда у них обоих может быть множество экземпляров друг друга, то устанавливается значение «multi» (множественная связь [12]). На рис. 1 представлен вызов внешнего процесса проверки специфики объекта. Более подробно этот процесс представлен на рис. 5. На нем схематично обозначен алгоритм работы со спецификой

набора и блока: перестроение ключей и приведение типа соответственно.

Каждая таблица, сопоставляемая с набором, имеет первичный ключ (идентификатор), название которого генерируется по следующему шаблону: набор_{&, где «набор» — имя набора. Вторичный ключ генерируется таким же образом, но в качестве имени набора указывается тот, с которым родитель состоит в отношениях. Для наборов, между которыми установлена множественная связь, необходимо создать связующую таблицу с именем

вида: набор1 _набор2 $multi, где «набор1», «набор2» — имена связанных между собой наборов, при этом в начале находится тот, чье имя расположено первым по алфавиту.

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

Анализ проблемы минимизации потерь предлагается начать с рассмотрения вариантов изменения связей. Всего их получается шесть:

1) multi ^ parent;

2) multi ^ child;

3) parent ^ multi;

4) child ^ multi;

5) parent ^ child;

6) child ^ parent.

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

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

Варианты 1, 2 подразумевают отказ от связующей таблицы, так как связь между таблицами меняется с «многие ко многим» на «один ко многим». После преобразования связующая таблица не используется, но сохраняется, как было сказано выше. У вариантов 5, 6 связующей таблицы нет изначально. Во всех четырех случаях, если существует вторичный ключ у ведомой таблицы (при устанавливаемом значении «parent» это таблица дочернего набора, при «child» — родительского), это означает, что преобразование не первично и что атрибут «parent» или «child» при соответствующих преобразованиях уже использовался. Точно так же для вариантов 3 и 4 существование связующей таблицы свидетельствует о повторной установке соответствующей связи.

После первичной смены отношения набора возникает закономерный вопрос пере-

Листинг 1. Запросы к СУБД, выполняющие функции переноса ключей Listing 1. Database queries with key migration features

/* Преобразование в "multi" из "parent" или "child" */ INSERT INTO NHa6op1_Ha6op2$multiNpHa6op1_id\ NHa6op2_idN) (SELECT NHa6op1_id\ NHa6op2_idN FROM хглавный_наборх);

/* Преобразование в "parent" или "child" из "multi" */ UPDATE "набор1"

LEFT JOIN 'чнабор1_набор2$multiN

ON набор1.набор1_id=набор1_набор2$multi.набор1_id SET набор1.набор2_id=набор1_набор2$multi.набор2_id,•

/* Преобразование из "parent" в "child" и наоборот */ UPDATE "набор2" RIGHT JOIN "набор1"

ON набор1.набор2_id=набор2.набор2_id SET набор2.набор1_id=набор1.набор1_id

носа ключей. Для случаев 3 и 4 перенос ключей осуществляется безболезненно. По сути, это всего лишь расширение возможностей набора. После создания связующей таблицы в нее переносятся один к одному все ключи из главного набора. Это преобразование самое безопасное. Остальные случаи подразумевают потерю части ключей. В общем виде запросы, переносящие ключи, представлены в листинге 1. Выбор присоединения справа или слева зависит от того, какая из двух таблиц наборов модифицируется.

Режим переноса ключей регулируется опцией «relationcast» в конфигурационном файле. Опция имеет следующие атрибуты: new (по умолчанию, ключи переносятся лишь в том случае, если новая связь устанавливается впервые), rewrite (ключи переносятся всегда, даже если существовали связующие таблицы и вторичные ключи, они будут перезаписаны, не рекомендуется), none (ключи не переносятся, при этом уже существующие связи остаются нетронутыми).

Заключение

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

Список литературы

1. Visser E. WebDSL: A Case Study in Domain-Specific

Language. Berlin; Heidelberg: Springer, 2008.

2. HanusM., Koschnicke S. An ER-based framework for declarative web programming // Practical Aspects of Declarative Languages. 2010. Р. 201-216.

3. Кейно П. П., Силуянов А. В. Автоматизированная разработка динамических Web-узлов средствами декларативного языка программирования // Прикладная информатика. 2014. №. 6 (54). С. 70-78.

4. Кейно П. П. Предпосылки формирования новой методологии разработки веб-узлов BlockSet и декларативного языка BML // Современные информационные технологии и ИТ-образование. 2015. Т. 2. № 11. С. 78-84.

5. Мыцко Е. А., Мальчуков А. Н. Исследование программных реализаций алгоритмов вычисления CRC, совместимых с PKZIP, WinRAR, Ethernet // Известия Томского политехнического университета. 2013. Т. 322. № 5. С. 170-175.

6. Stevens W. R., Rago S. A. Advanced programming in the UNIX environment. Vol. 3. Addison-Wesley, 2013.

7. Zhang Y. The Design of Linux-Based E-Mail System // Advanced Technology in Teaching-Proceedings of the 2009 3rd International Conference on Teaching and Computational Science (WTCS 2009). 2012. Р. 63-70.

8. Щапов В. А., Масич Г. Ф. Программная платформа передачи интенсивных потоков данных на удаленные компьютеры // Труды международной конференции. Суперкомпьютерный консорциум университетов России, Федеральное агентство научных организаций России. Sep 2015. С. 720-731.

9. Accepting Transport Connections // FastCGI Specification. URL: http://www.fastcgi.com/drupal/node/6? q=node/22 (дата обращения: 12.03.2016).

10. Creative Commons. [BSON] // Binary JSON. URL: http://bsonspec.org/ (дата обращения: 12.03.2016).

11. Smith S. et al. Draft: Have you checked your IPC performance lately?

12. Letkowski J. Doing database design with MySQL // Journal of Technology Research. 2016. Vol. 6. Р. 1-15.

References

1. Visser E. WebDSL: A Case Study in Domain-Specific Language. Berlin; Heidelberg Publ., Springer, 2008.

2. Hanus M., Koschnicke S. An ER-based framework for declarative web programming. Practical Aspects of Declarative Languages, 2010, pp. 201-216.

3. Keyno P. P., Siluyanov A. V. Automated Development of Dynamic Websites by Using Declarative Programming Language. Prikladnaya Informatika — Journal of Applied Informatics, 2014, vol. 9, no. 6 (54), pp. 70-78 (in Russian).

4. Keyno P. P. Predposylki formirovanija novoj metodolo-gii razrabotki web-uzlov BlockSet i deklarativnogo ja-zyka BML [Formation of a new web-development

methodology BlockSet and declarative language BML]. Sovremennye Informacionnye Tehnologii i IT-obra-zovanie, 2015, vol. 2, no. 11, pp. 78-84.

5. Mytsko E. A., Mal'chukov A. N. Issledovanie pro-grammnyh realizacij algoritmov vychislenija CRC, sovmestimyh s PKZIP, WinRAR, Ethernet [Survey of software implementation of calculating CRC algorithm compatible with PKZIP, WinRAR, Ethernet]. Izvesti-ja Tomskogo Politehnicheskogo Universiteta, 2013, vol. 322, no. 5, pp. 170-175.

6. Stevens W. R., Rago S. A. Advanced programming in the UNIX environment. Vol 3. Publ. Addison-Wesley, 2013.

7. Zhang Y. The Design of Linux-Based E-Mail System, Advanced Technology in Teaching-Proceedings of the 2009 3rd International Conference on Teaching and Computational Science (WTCS 2009), 2012, pp. 63-70.

8. Shhhapov V. A., Masich G. F. Programmnaja platfor-ma peredachi intensivnyh potokov dannyh na udalen-nye komp'jutery [Software platform of intensive stream data transfer on remote PCs]. Trudy mezhdunarodnoj konferencii. Superkomp'juternyj konsorcium univer-sitetov Rossii, Federal'noe agentstvo nauchnyh orga-nizacij Rossii, Sep 2015, pp. 720-731.

9. Accepting Transport Connections. FastCGI Specification. Available at: http://www.fastcgi.com/drupal/ node/6? q=node/22 (accessed: 12.03.2016).

10. BSON. Binary JSON. Available at: http://bsonspec.org/ (accessed: 12.03.2016).

11. Smith S. et al. Draft: Have you checked your IPC performance lately? Publ. Citeseer.

12. Letkowski J. Doing database design with MySQL. Journal of Technology Research, 2016, vol. 6, pp. 1-15.

P. Keyno, Moscow Aviation Institute (National Research University), Moscow, Russia, science@blockset.ru

Software architecture of synchronizer as part of declarative Web-application modeling language interpreter

The main line of work is developing of specific low-level software for synchronizing data structures between file system and clients. The data represents the logic of BML that also developed by author. The language stores their logic in the XML-like structure that has elements and properties. One of the elements is «Set» that associates with a table in a relational database. And element «Block» associates with a field of some data. The main difference is in the extended nature of elements. So, Block can have specific data type and Set can have relations between other sets. When BML developer modifies the source code it causes problems with database rebuilding. The modified project can produce a high load in the system. So, that process should be distributed by the child process. On the other hand, there is second problem related with constant reading of filesystem data. So, synchronizer should perform also file caching function. Synchronizer through the specified interval checks any modified properties like date or checksum of files in the working directory with BML and totally reloads logic structure data when such changes will be. Author also proposes using of non-blocking sockets for interaction with clients. Necessary data transmits through BSON (Binary JSON) and they should be interpreted by each client that receives it. In the article author made a complex architecture of low-level software and proposes some non-standard solutions.

Keywords: Web, backend, server programming, highload, system programming, sockets, servers, databases, interpreter, synchronizer, inter-process communication, IPC, declarative programming, BML, BlockSet, XML, BSON.

About author: P. Keyno, Lecturer, Department of System Modeling and Engineering Graphics

For citation: Keyno P. Software Architecture of synchronizer as part of declarative web-application modeling language interpreter. Prikladnaya Informatika — Journal of Applied Informatics, 2016, vol. 11, no. 2 (62), pp. 65-77 (in Russian).