Кинетический язык правил - Kinetic Rule Language

Не путать с KRL (язык программирования).
Кинетический язык правил
ПарадигмаДействие условия события язык правил
РазработаноФилип Дж. Уиндли
РазработчикKynetx, Inc
Впервые появился2007
Печатная дисциплинадинамичный, слабый
ЛицензияGPLv2
Интернет сайтДокументация KRL
Основной реализации
KRL
Под влиянием
JavaScript, Perl

Кинетический язык правил (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 из-за ролей, которые играют эти три фундаментальные части правила:

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

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

Основная структура правила KRL выглядит следующим образом:

rule  {выберите, когда  pre {} if  then  fired {} else {}}
  • Выражения событий в Выбрать оператор объявляет условия, при которых будет выбрано правило.[6]
  • Объявления в прелюдии к правилу позволяют вычислять и сохранять значения для последующего использования в правиле.
  • Условные выражения определяют, срабатывает ли выбранное правило.
  • Действия могут быть встроенными или определяемыми пользователем и определять действие правила.
  • Заявления в постлюдии правила (уволен ... еще ...) влияют на постоянные переменные и вызывают дальнейшие события.

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

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

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

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

Конечные точки несут ответственность за

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

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

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

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

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

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

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

rule good_morning {выберите, когда url просмотра страницы # example.com # if morning () then notify («Добро пожаловать!», «Доброе утро!»)}

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

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

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

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

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

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

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

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

Рекомендации

  1. ^ Виндли, Филипп (2011). Живая сеть. Курс Технологии PTR. п. 416. ISBN  1133686680.
  2. ^ Searls, док. «Интернет меня и моих вещей». Получено 18 февраля 2013.
  3. ^ Кобб, Дженнифер (17 мая 2012 г.). «Обещание Personal Cloud».
  4. ^ "Kinentic Rules Engine на GitHub". Получено 18 февраля 2013.
  5. ^ Виндли, Филипп. «Модель программирования для CloudOS». Получено 18 февраля 2013.
  6. ^ "Выражения событий KRL". Получено 18 февраля 2013.
  7. ^ Каррен, Сэм. «Спецификация API Evented». Получено 18 февраля 2013.

внешняя ссылка