Архитектура на основе событийной семантики

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

Базовая EventFlow-архитектура включает в себя язык событийно-семантического описания элементов предметной области и действий, выполняемых с ними ее участниками, а также программный движок, исполняющий семантические модели. Прототип такого движка успешно прошел серию испытаний применительно к задаче управления безопасностью ИТ-систем, а в Лаборатории институционального проектного инжиниринга (ipe-lab.com) создается пилотная версия системы сквозного моделирования бизнес-процессов на базе EventFlow-архитектуры.

Подход EventFlow основан на достаточно простом утверждении: любая деятельность может быть представлена в виде потока событий, различаемых и совершаемых ее участниками (акторами). В виде событий записываются не только акты управления, но и все фиксируемые свойства элементов деятельности, что позволяет унифицировать хранение и обработку данных [1]. Соответствующая архитектура объединяет три подхода к проектированию информационных систем: шаблон Event Sourcing [2], ориентированный на управление состоянием системы с помощью упорядоченного потока событий; семантическое представление данных (Linked Data и др., ru.wikipedia.org/wiki/Linked_data); подход DataFlow (ru.wikipedia.org/wiki/Dataflow_architecture). Для унификации и стандартизации взаимодействия различных программных модулей и независимых приложений используется семантический (совмещающий данные и метаданные) формат записи: события создаются по моделям и обладают семантическим содержанием, которое не зависит ни от программных элементов, ни от структуры хранилища данных. Все события EventFlow-системы, как и в Event Sourcing, сохраняются в виде временных последовательностей, что дает возможность использовать хранилище событий как брокер сообщений, обеспечивающий асинхронное взаимодействие элементов системы.

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

Подход EventFlow-можно представить следующим образом: все данные предметной области создаются и хранятся в виде событий, фиксирующих наличие или изменение свойств объектов; события записываются в семантическом формате (содержат не только значения свойств, но и метаданные); в формат события включено логическое выражение, задающее условие его выполнения, что позволяет реализовать подход DataFlow к исполнению алгоритмов.

Событийная семантика

Традиционные ИТ-архитектуры основаны на однозначном разделении данных и метаданных. Данные обычно хранятся в виде числовых и строковых значений в СУБД, а метаданные, описывающие содержательную сторону предметной области (отношения объектов и бизнес-логику), задаются структурой хранилищ и встраиваются в программу. При семантическом подходе смысловая составляющая предметной области отделяется от структуры приложения (кода программ и схем баз данных). Это достигается за счет использования специальных форматов записи, совмещающих данные и метаданные, — форматов, в которых значения свойств и стандартизированные с помощью общих словарей текстовые обозначения свойств сохраняются в едином кортеже данных. Из сгруппированных таким образом данных формируются семантические сети, или онтологии, фиксирующие отношения сущностей предметных областей, что позволяет делать инструменты обработки данных независимыми. Такое отделение семантики от кода призвано унифицировать алгоритмы информационных систем, стандартизировать обмен данными между независимыми приложениями и обеспечивает возможность модификации структуры данных (добавление новых сущностей и свойств) без изменения алгоритмов. Кроме того, появляется возможность реализовать логический вывод неявных фактов и семантический поиск (например, «выявить всех сотрудников, принимавших участие в проекте `Х` и имевших доступ к оборудованию `Y`, а затем уволившихся в 2021 году»).

Наиболее продвинутой реализацией семантической технологии на данный момент считается набор стандартов W3C для Semantic Web [3]. Основу стандартов составляют: спецификация записи данных (Resource Description Framework, RDF), язык описания онтологий (Web Ontology Language, OWL) и язык запросов SPARQL. Семантические инструменты широко применяются при создании больших хранилищ семантически связанных данных, таких как DBpedia и Freebase, позже влившихся в Google Knowledge Graph, а также для реализации отраслевых и корпоративных баз знаний.

Однако семантические сети (графы знаний) традиционно содержат только актуальные данные, фиксирующие статичное состояние предметной области. Это связано с тем, что спецификации RDF/OWL/SPARQL и другие подобные семантические инструменты не содержат представления о времени, а следовательно, не поддерживают работу с темпорально распределенными, причинно-зависимыми, организованными во временные последовательности данными. Делаются попытки преодолеть это ограничение с помощью разнообразных расширений (TOQL, SOWL, T-SPARQL, OWL-Time и др.), предусматривающих внедрение в объектные семантики механизмов отслеживания изменений во времени. Для этого используются разные способы: добавление специального временного предиката, операторов «до», «всегда», «позже» и др.; задание интервалов, на которых фиксируется истинность утверждений; введение четырехмерного представления объекта, включающего время его жизненного цикла (по типу 4D-онтологии инженерного стандарта ISO 15926); отслеживание временных версий графа. Однако подобные расширения решают лишь задачу привязки изменений свойств объектов к конкретным моментам времени и не содержат инструментов для семантического связывания последовательностей событий в процессы. Именно для решения этой проблемы и была разработана событийная семантика.

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

В формате события его семантическое содержание записывается кортежем . Семантическое содержание такого триплета трактуется как фиксация значения Value, имеющего тип ValueType (свойство или акт), на сущности, определенной событием BasicEvent. Поскольку все данные в EventFlow записываются в виде событий, то следует говорить, что любое событие (и приписывание значения свойства, и совершение акта) фиксируется на некотором предшествующем событии. Например, все свойства индивида (сотрудника компании) записываются как события фиксации их значений в предметной области.

Принципиальное отличие событийной семантики от объектной (в том числе имеющей темпоральные расширения) — введение между событиями обусловливающих связей, задающих отношения логического или причинного следования. События A и B считаются обусловливающими для события C, если констатируется обязательность их существования для выполнения C. Обусловливающие связи записываются в специальном поле формата события Condition, содержащем идентификаторы событий, послуживших условиями для совершения текущего события (C, Condition: A and B). Таким образом, онтология деятельности представляется в событийной семантике не только графом, устанавливающим связи между индивидами сущностей и значениями их свойств, но и темпоральным ориентированным ациклическим графом, фиксирующим временные последовательности обусловливающих друг друга событий.

Другим отличием событийной семантики от объектной является ее субъектность — обязательность указания актора, зафиксировавшего событие. В общем случае событием считается не изменение как таковое, а исключительно факт различения этого изменения участником деятельности — актором, в качестве которого может выступать человек, программный агент, датчик. Это требование важно не только с точки зрения смысла, вкладываемого в событие актором, но и с технологической точки зрения, поскольку значение события Value фиксируется конкретным актором (человеком или датчиком), а следовательно, зависит от состояния актора. Включение актора в формат события позволяет учитывать несогласованные, а порой и противоречивые утверждения, отражающие различные точки зрения, что существенно во многих предметных областях. Кроме того, наличие в формате события ссылки на актора позволяет одним запросом к событийному графу получать полное описание актора как участника конкретной деятельности.

Событийный граф содержит два типа событий: модельные события (описывающие семантическую и темпоральную связанность сущностей и актов) и предметные события, фиксирующие конкретные значения свойств индивидов и акты их изменения. Модельное событие можно представлять как шаблон, декларирующий наличие свойства у сущности или возможное действие актора с этой сущностью, а предметное событие — как результат «заполнения» этого шаблона конкретным значением в ходе какой-либо деятельности. К примеру, по модельному событию может быть создано поле экранной формы, в результате заполнения которого в граф будет добавлено новое предметное событие со значением, введенным актором. Модельные события, задающие фиксированное множество свойств некоторой сущности или действия, группируются в модели. В событийной семантике устанавливается правило, согласно которому предметное событие может быть создано только по конкретной модели. То есть каждое новое событие проверяется не только на выполнимость (наличие обусловливающих событий), но и на соответствие конкретной модели, в которой, помимо семантического содержания события и условия его выполнимости, задаются и особые ограничивающие свойства, устанавливающие, например, количество допустимых для индивида предметных событий, область возможных значений, права доступа и др.

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

От DataFlow к EventFlow

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

Рис. 1. Пример выполнения алгоритма по DataFlow

EventFlow наследует от DataFlow принцип асинхронной генерации новых данных по мере готовности результатов предшествующих операций, но в качестве данных выступают не числовые или строковые значения, а семантически определенные события: новое предметное событие генерируется по модельному событию при появлении всех обусловливающих событий (рис. 2). Иначе говоря, EventFlow-система ориентирована не на преобразование входных данных в выходные с передачей промежуточных результатов от оператора к оператору, а на реализацию бизнес-логики, которая прописана в семантических моделях. При этом генерируемые предметные события фиксируют в графе шаги выполнения алгоритма, а не промежуточные данные расчетов. Модели EventFlow — это программы на семантическом языке, исполняемые универсальным контроллером с использованием данных графа, а результатом исполнения моделей являются новые предметные события.

Рис. 2. Исполнение алгоритмов по EventFlow

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

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

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

EventFlow на практике

В качестве основного применения субъектно-событийного подхода [1, 4] предполагалось создание онтологий предметных областей, в которых принципиально важным является сохранение исторических данных (например, событий историй болезней). Исполняемые событийные модели на основе подхода DataFlow расширили потенциальную область применения этого подхода, а EventFlow добавил инструменты алгоритмической обработки потоков данных из любых источников с сохранением результата в виде семантического темпорального графа, информация из которого используется в работе исполняемых моделей. Существенными преимуществами EventFlow по сравнению с решениями Workflow являются скорость создания и модификации исполняемых моделей на том же языке, что используется для семантического описания данных, а также параллельность исполнения модельных событий согласно DataFlow. Архитектура EventFlow найдет применение в сфере автоматизации технологических и бизнес-процессов с возможностью гибкой и перманентной настройки схем данных, включая модели действий.

***

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

Литература

1. Александр Болдачев. Субъектно-событийный подход к моделированию сложных систем, 2015. URL: https://habr.com/ru/post/256509 (дата обращения: 22.09.2021).

2. Martin Fowler. Event Sourcing, 2005. URL: https://martinfowler.com/eaaDev/EventSourcing.html (дата обращения: 22.09.2021).

3. Сергей Горшков. Единая точка доступа к данным предприятия // Открытые системы.СУБД. — 2018. — № 4. — С. 33–35. URL: https://www.osp.ru/os/2018/04/13054596 (дата обращения: 21.09.2021).

4. Александр Болдачев. Темпоральность и философия абсолютного релятивизма. — М.: Ленанд, 2011. URL: http://philosophystorm.org/books/aleksandr-boldachev-temporalnost-i-filosofiya-absolyutnogo-relyativizma (дата обращения: 21.09.2021).

Александр Болдачев (boldachev@gmail.com) — системный аналитик, лаборатория ИПИ (Москва).