Философия и цифровые технологии. Сборник статей. Александр Болдачев
Читать онлайн книгу.
align="center">
От DataFlow к EventFlow
Архитектуру EventFlow, по сути, следует рассматривать как событийный вариант шаблона DataFlow: соответствующие программы обычно представляются в виде направленного графа, в узлах которого расположены операторы, а ребра указывают на зависимости узлов по данным. Оператор очередного узла начинает выполняться сразу по получении всех необходимых данных от предшествующих узлов. Данные по ходу вычислений передаются от узла к узлу в виде токенов (рис. 1). Первые варианты DataFlow-компьютеров появились более полувека назад, но не получили широкого распространения из-за ряда нерешенных проблем, проявившихся как на уровне архитектуры, так и при создании языков программирования.
EventFlow наследует от DataFlow принцип асинхронной генерации новых данных по мере готовности результатов предшествующих операций, но в качестве данных выступают не числовые или строковые значения, а семантически определенные события: новое предметное событие генерируется по модельному событию при появлении всех обусловливающих событий (рис. 2). Иначе говоря, EventFlow-система ориентирована не на преобразование входных данных в выходные с передачей промежуточных результатов от оператора к оператору, а на реализацию бизнес-логики, которая прописана в семантических моделях. При этом генерируемые предметные события фиксируют в графе шаги выполнения алгоритма, а не промежуточные данные расчетов. Модели EventFlow – это программы на семантическом языке, исполняемые универсальным контроллером с использованием данных графа, а результатом исполнения моделей являются новые предметные события.
Важным отличием EventFlow является то, что модельные события, определяя семантику предметного события и условия его генерации, не содержат данных о последующих шагах бизнес-логики. То есть если узел графа DataFlow «знает», куда переслать токен с результатом вычислений, то модельные события в EventFlow задают только логическую обусловленность собственного выполнения, не предписывая условий для генерации последующих событий. Решение без токенов, с одной стороны, упрощает архитектуру, а с другой – соответствует бизнес-схеме, когда каждый актор выполняет свою операцию при получении всех необходимых для этого ресурсов и не осведомлен о том, кто воспользуется результатом его работы – ответственность за выполнение следующих шагов будет лежать уже на других акторах.
Такой способ реализации бизнес-логики позволяет обеспечить модификацию имеющихся моделей и введение новых без остановки выполнения бизнес-процессов. Добавленное модельное событие будет генерировать новые предметные события исходя из их обусловленности существующими событиями и не может повлиять на уже работающий алгоритм действия. Эта особенность EventFlow-архитектуры с учетом исходной семантической определенности данных не только упрощает согласование работы различных групп разработчиков моделей, но и позволяет реализовать