Язык кинетических правил

Язык кинетических правил
Парадигма	действия при условии события Язык правила
Разработано	Филип Дж. Виндли
Разработчик	Кинеткс, Инк.
Впервые появился	2007
Дисциплина набора текста	динамичный , слабый
Лицензия	лицензия GPLv2
Веб-сайт	Документация КРЛ
Основные реализации
	КРЛ
Под влиянием
	JavaScript , Перл

Kinetic Rule Language (KRL) — это основанный на правилах язык программирования для создания приложений в Live Web. ^[1] Программы KRL или наборы правил включают ряд правил, которые реагируют на определенные события. KRL пропагандируется как язык для создания персональных облаков . ^[2]^[3]

KRL является частью проекта с открытым исходным кодом под названием KRE. ^[4] для Kinetic Rules Engine, разработанного Kynetx, Inc.

История

KRL был разработан Филом Уиндли из Kynetx, начиная с 2007 года. С тех пор разработка языка расширилась и теперь включает библиотеки и модули для различных веб-сервисов, включая Twitter , Facebook и Twilio .

Философия и дизайн

KRL основан на событиях со строгой оценкой , одиночным присваиванием и динамической типизацией . В программировании, управляемом событиями, события — уведомление о том, что что-то произошло, управляют потоком выполнения. KRL поддерживает модель программирования, основанную на трех ключевых идеях: ^[5]

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

Ориентация на сущность требует, чтобы среды выполнения KRL поддерживали понятие сущности. Наборы правил устанавливаются для каждой сущности.

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

События редко адресуются конкретному набору правил. Скорее, события вызываются от имени конкретного объекта, и, таким образом, любое правило, выбранное из установленных наборов правил объекта, выполняется от имени этого же объекта. Это понятие называется «выразительность». Событие является важным для данного объекта, если этот объект установил правило, которое прослушивает это событие.

Одно событие может активировать правила из нескольких наборов правил в среде выполнения объекта. Какие правила выбираются и выполняются, зависит от установленных наборов правил.

Постоянные значения данных . В KRL есть класс переменных, называемых «постоянные переменные» или просто «постоянные». Существует два типа персистентных данных: переменные приложения и переменные сущности. Оба закрыты для набора правил, в котором они находятся, а это означает, что они видны только коду, выполняющемуся внутри набора правил. Переменные приложения сохраняются для набора правил и доступны любому объекту, выполняющему набор правил. Значения переменных сущности видны только той сущности, для которой они были сохранены. Переменные приложения примерно аналогичны переменным класса . Переменные сущности подобны переменным экземпляра .

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

Событие-Условие-Действие

KRL называется действием условия события или языком правил ECA из-за ролей, которые играют эти три фундаментальные части правила:

События . События вызывают определенные события. События подобны спусковому крючку «пистолета» — правилу. Без события, вызывающего срабатывание правила, ничего не происходит.
Условия – Условия аналогичны безопасности оружия. Если условное выражение не возвращает true, правило не срабатывает. Точно так же, как ружье либо стреляет, либо не стреляет в зависимости от безопасности, больше нет никаких утверждений об условных обозначениях. Если вы хотите, чтобы правило сработало в противоположном случае, вы можете использовать постлюдию «Не сработало» для запуска другого события или создать правило с условием, которое проверяет противоположный случай.
Действия . Действия подобны пуле, вылетающей из пистолета; они являются конечным результатом правила. Правило может иметь несколько действий.

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

Базовая структура правила KRL следующая:

rule <name> {  select when <eventexpr>  pre {    <declarations>  }  if <expr> then    <action>  fired {    <effects>  } else {    <effects>  }}

Выражения событий в select Оператор объявляет условия, при которых правило будет выбрано. ^[6]
Объявления в прелюдии правила позволяют вычислять и сохранять значения для дальнейшего использования в правиле.
Условные выражения определяют, будет ли срабатывать выбранное правило.
Действия могут быть встроенными или определяемыми пользователем и указывать действие правила.
Утверждения в постлюдии к правилу ( fired...else...) влияют на постоянные переменные и вызывают дальнейшие события.

Генераторы событий

События KRL вызываются другими правилами генераторов событий, обычно называемых «конечными точками». События обычно вызываются через HTTP с использованием модели, соответствующей Evented API. ^[7] но KRL не зависит от транспорта. Например, события могут передаваться по электронной почте, SMS, MQTT или любой другой системе, поддерживающей push-уведомления. Поскольку Evented API является специализацией концепции веб-перехватчиков , любая система, поддерживающая веб-перехватчики, может создавать события для KRL.

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

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

Конечные точки отвечают за

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

Правила и исполнение правил

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

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

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

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

В следующем примере показано простое правило KRL:

rule good_morning {  select when pageview url #example.com#  if morning() then    notify(“Welcome!”, “Good morning!”)}

Это правило будет отправлять уведомление «доброе утро» посетителям любой страницы в архивах веб-сайта (как указано в URL-пути), если там, где находится пользователь, сейчас утро.

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

События — это уведомление об обнаруживаемом состоянии в компьютерной системе. Обнаруживаемое состояние обычно рассматривается как изменение состояния.

Это три обязательные части обнаружения и уведомления о событиях:

Изменение состояния
Процесс замечает изменение состояния
Процесс отправляет уведомление об изменении состояния

Уведомления — это передача данных, а не передача контроля исполнения. Это одна из отличительных черт событийных систем, которая отличает их от других типов систем. Системы вопросительного типа используют режим взаимодействия «запрос-ответ»: «Вы сделаете это?» Системы императивного стиля используют RPC режим взаимодействия : «Сделай это!» Напротив, взаимодействия событий являются декларативными, констатируя только то, что произошло конкретное изменение состояния: «Это произошло».

Поскольку уведомления о событиях являются декларативными, они навязывают семантику того, что означает событие, процессору, а не генератору. Генератор событий не знает, как данный процессор интерпретирует событие. Более того, от процессора событий даже не требуется никаких действий. Каждый процессор может интерпретировать событие независимо от других процессоров и генераторов в системе в соответствии со своим контекстом и конкретной целью.

Генератор событий «вызывает событие»; другими словами, он отправляет уведомление о том, что произошло изменение состояния. Обработчик событий «слушает» или «обрабатывает» эти события.

Ссылки

^ Уиндли, Филипп (2011). Живая сеть . Курс Технологии ПТР. п. 416. ИСБН 978-1133686682 .
^ Сирлс, Док. «Интернет меня и моих вещей» . Проверено 18 февраля 2013 г.
^ Кобб, Дженнифер (17 мая 2012 г.). «Обещание персонального облака» .
^ «Kinentic Rules Engine на GitHub» . Гитхаб . Проверено 18 февраля 2013 г.
^ Уиндли, Филипп. «Модель программирования для CloudOS» . Проверено 18 февраля 2013 г.
^ «Выражения событий KRL» . Проверено 18 февраля 2013 г.
^ Каррен, Сэм. «Спецификация событийного API» . Проверено 18 февраля 2013 г.

Внешние ссылки

Документация КРЛ
Kinetic Rules Engine , реализация с открытым исходным кодом, размещенная на GitHub.
Статьи о КРЛ в блоге Фила Уиндли

[1] Уиндли, Филипп (2011). Живая сеть . Курс Технологии ПТР. п. 416. ИСБН 978-1133686682 .

[2] Сирлс, Док. «Интернет меня и моих вещей» . Проверено 18 февраля 2013 г.

[3] Кобб, Дженнифер (17 мая 2012 г.). «Обещание персонального облака» .

[4] «Kinentic Rules Engine на GitHub» . Гитхаб . Проверено 18 февраля 2013 г.

[5] Уиндли, Филипп. «Модель программирования для CloudOS» . Проверено 18 февраля 2013 г.

[6] «Выражения событий KRL» . Проверено 18 февраля 2013 г.

[7] Каррен, Сэм. «Спецификация событийного API» . Проверено 18 февраля 2013 г.

[1]

[2]

[3]

[4]

[5]

[6]

[7]