Kinetic Rule Language (KRL) es un lenguaje de programación basado en reglas para crear aplicaciones en la Web en vivo. [1] Los programas KRL, o conjuntos de reglas, comprenden una serie de reglas que responden a eventos particulares. KRL se ha promocionado como lenguaje para crear nubes personales . [2] [3]
KRL es parte de un proyecto de código abierto llamado KRE, [4] para Kinetic Rules Engine, desarrollado por Kynetx, Inc.
KRL fue diseñado por Phil Windley en Kynetx, a principios de 2007. Desde entonces, el desarrollo del lenguaje se ha expandido para incluir bibliotecas y módulos para una variedad de servicios web, incluidos Twitter , Facebook y Twilio .
KRL se basa en eventos con evaluación estricta , asignación única y tipado dinámico . En la programación basada en eventos , los eventos, una notificación de que algo sucedió, controlan el flujo de ejecución. KRL admite un modelo de programación basado en tres ideas clave: [5]
Orientación a entidades : el modelo de programación de KRL tiene la identidad como característica principal. Los programas de KRL se ejecutan en nombre de una entidad en particular. La idea de entidad está incorporada en la semántica subyacente del lenguaje. La orientación a entidades de KRL está respaldada por el motor de reglas de Kynetx (KRE) subyacente y, por lo tanto, puede ser utilizada por cualquier programa que se ejecute en el motor, incluso uno que no esté escrito en KRL. Las siguientes dos características ilustran por qué la identidad es crucial para el modelo de programación.
La orientación a entidades requiere que los entornos de ejecución de KRL admitan la noción de entidad. Se instalan conjuntos de reglas para cada entidad.
Vinculación de eventos : las reglas de KRL vinculan patrones de eventos a acciones. Los patrones de eventos se especifican mediante expresiones de eventos. Tanto los eventos como las acciones son extensibles, de modo que los programadores tienen la libertad de definir eventos y acciones que sean relevantes para su espacio de problemas.
Los eventos rara vez están dirigidos a un conjunto de reglas específico. En cambio, los eventos se generan en nombre de una entidad en particular y, por lo tanto, cualquier regla seleccionada de los conjuntos de reglas instalados de la entidad se ejecuta en nombre de esa misma entidad. Este concepto se denomina "prominencia". Un evento es prominente para una entidad determinada si esa entidad ha instalado una regla que escucha ese evento.
Un único evento puede activar reglas de varios conjuntos de reglas dentro del entorno de ejecución de la entidad. Las reglas que se seleccionan y ejecutan dependen de los conjuntos de reglas instalados.
Valores de datos persistentes : KRL tiene una clase de variables llamadas “variables persistentes” o simplemente “persistentes”. Hay dos tipos de persistentes: variables de aplicación y variables de entidad. Ambas están cerradas respecto del conjunto de reglas en el que se encuentran, lo que significa que solo son visibles para el código que se ejecuta dentro del conjunto de reglas. Las variables de aplicación se almacenan para el conjunto de reglas y están disponibles para cualquier entidad que ejecute el conjunto de reglas. Los valores de las variables de entidad solo son visibles para la entidad para la que se almacenaron. Las variables de aplicación son aproximadamente análogas a las variables de clase . Las variables de entidad son como las variables de instancia .
Las variables de entidad, en particular, son un concepto muy poderoso, ya que brindan a los programadores de KRL la capacidad de almacenar valores persistentes sin el dolor de cabeza que supone configurar, vincular y utilizar una base de datos para la mayoría de las cosas. Debido a que un conjunto de reglas representa un cierre sobre sus variables de entidad, cada conjunto de reglas representa potencialmente un objeto de datos persistente.
KRL se denomina lenguaje de reglas ECA o de acción de condición de evento debido a los roles que desempeñan esas tres partes fundamentales de una regla:
Además de una colección de reglas, los conjuntos de reglas de KRL también contienen una sección meta para especificar información sobre el conjunto de reglas, una sección de envío para proporcionar pistas sobre la relevancia de los eventos y una sección global para definiciones globales. Cada regla se ajusta al patrón de los lenguajes de reglas de ECA indicado anteriormente con algunas adiciones significativas.
La estructura básica de una regla KRL es la siguiente:
regla <nombre> { seleccionar cuando <eventexpr> pre { <declaraciones> } Si <expr> entonces <acción> despedido { <efectos> } demás { <efectos> }}selectdeclaración declaran las condiciones bajo las cuales se seleccionará la regla. [6]fired...else...) afectan variables persistentes y generan eventos adicionales.Los eventos KRL se generan mediante otras reglas de generadores de eventos, comúnmente denominados "puntos finales". Los eventos se generan comúnmente a través de HTTP utilizando un modelo que se ajusta a la API Evented, [7] pero KRL es independiente del transporte. Por ejemplo, los eventos se pueden transportar por correo electrónico, SMS, MQTT o cualquier otro sistema que admita notificaciones de estilo push. Debido a que la API Evented es una especialización del concepto de webhook , cualquier sistema que admita webhooks puede generar eventos para KRL.
KRL utiliza canales de eventos para identificar la entidad para la que se genera el evento. Una entidad puede tener cualquier cantidad de canales de eventos. Los canales de eventos se codifican en la URL de los eventos transportados a través de HTTP.
Un punto final que genera un evento puede estar observando alguna actividad directamente e informando cambios de estado destacados o puede simplemente estar informando o transformando datos de eventos de otra fuente (por ejemplo, un webhook).
Los puntos finales son responsables de
KRL es un lenguaje de reglas determinista. Esto significa que los programas KRL consisten en un conjunto de reglas que realizan una acción cuando se activan. Así como los lenguajes funcionales , orientados a objetos e imperativos son todos diferentes, los lenguajes de reglas también requieren una forma de pensar diferente. En consecuencia, escribir un conjunto de reglas KRL no es una tarea de programación tradicional.
En su forma más simple, una regla es una acción condicional. La acción puede ser cualquier cosa que sea apropiada para el dominio. Para ampliar páginas web, las acciones son modificadores de página. En otros dominios, la acción puede ser cualquier cosa que el punto final pueda consumir. Cuando se realiza la acción de una regla, decimos que la regla se "activó". Tenga en cuenta que la acción es condicional: la acción se realiza solo cuando se selecciona la regla y su premisa es verdadera.
En la primera etapa, la regla se selecciona o no, según el patrón de evento en la expresión de evento. La expresión de evento de una regla sigue a la palabra clave select en la regla. Por ejemplo, en el dominio web, esto suele consistir en una expresión regular que coincide con la URL de la página que se está ampliando. Por lo tanto, en la primera etapa, la regla se selecciona solo para determinadas páginas web.
La segunda etapa de la ejecución condicional de la regla es la prueba de su premisa, que consiste en un predicado que se utiliza para probar el contexto en el que se evalúa la regla. Esta comprobación se realiza después de la sección de preludio de la regla, donde se declaran los valores, de modo que tenga el beneficio de cualquier cálculo necesario para crear o manipular el contexto. El predicado de la condicional es opcional, por lo que es posible escribir una regla que siempre se ejecute porque su selector siempre selecciona. Sin embargo, la mayoría de los conjuntos de reglas interesantes contendrán reglas que solo se ejecuten en determinadas circunstancias.
El siguiente ejemplo muestra una regla KRL simple:
regla buenos_dias { seleccionar cuando la página vista url es #example.com# Si es de mañana() entonces notificar(“¡Bienvenido!”, “¡Buenos días!”)}Esta regla enviaría una notificación de “buenos días” a los visitantes de cualquier página en los archivos de un sitio web (como lo indica la ruta URL) si es de mañana en el lugar donde se encuentra el usuario.
Los eventos son la notificación de una condición detectable en un sistema informático. La condición detectable normalmente se verá como un cambio de estado.
Estas son tres partes necesarias para la detección y notificación de eventos:
Las notificaciones son transferencias de datos, no transferencias de control de ejecución. Esta es una de las características distintivas de los sistemas basados en eventos que los distingue de otros tipos de sistemas. Los sistemas de estilo interrogativo utilizan un modo de interacción de solicitud-respuesta: “¿Harías esto?”. Los sistemas de estilo imperativo utilizan un modo de interacción de RPC : “¡Haz esto!”. En cambio, las interacciones de eventos son declarativas y solo indican que se produjo un cambio de estado específico: “Esto sucedió”.
Debido a que son declarativas, las notificaciones de eventos imponen la semántica de lo que significa un evento al procesador en lugar de al generador. El generador de eventos no sabe cómo interpretará el evento un procesador determinado. Es más, ni siquiera es necesario que un procesador de eventos realice ninguna acción. Cada procesador es libre de interpretar el evento independientemente de otros procesadores y generadores del sistema según su contexto y propósito particular.
El generador de eventos “genera un evento”, es decir, envía una notificación de que se produjo un cambio de estado. El procesador de eventos “escucha” o “gestiona” estos eventos.