Kinetic Rule Language (KRL) is a rule-based programming language for creating applications on the Live Web. KRL programs, or rulesets, comprise a number of rules that respond to particular events. KRL has been promoted as language for building personal clouds. KRL is part of an open-source project called KRE, for Kinetic Rules Engine, developed by Kynetx, Inc.
History KRL was designed by Phil Windley at Kynetx, beginning in 2007. Development of the language has since expanded to include libraries and modules for a variety of web services, including Twitter, Facebook, and Twilio.
Philosophy and design KRL is event-based with strict evaluation, single assignment, and dynamic typing. In event-driven programming, events, a notification that something happened, control the flow of execution. KRL supports a programming model based on three key ideas: Entity orientation – The programming model of KRL has identity as a core feature. KRL programs execute on behalf of a particular entity. The idea of entity is built into the underlying semantics of the language. The entity orientation of KRL is supported by the underlying KRE (Kynetx Rules Engine) and so is usable by any program running in the engine—even one not written in KRL. The next two features illustrate why identity is crucial to the programming model. Entity orientation requires that KRL execution environments support the notion of entity. Rulesets are installed for each entity. Event binding – rules in KRL bind event patterns to actions. Event patterns are specified using event expressions. Events and actions are both extensible so that programmers are free to define events and actions that are relevant to their problem space. Events are rarely addressed to a specific ruleset. Rather events are raised on behalf of a particular entity and thus any rule selected from the entity's installed rulesets runs on behalf of that same entity. This concept is called “salience.” An event is salient for a given entity if that entity has installed a rule that listens for that event. A single event can fire rules from multiple rulesets within the entity's execution environment. Which rules are selected and run depends on the rulesets installed. Persistent data values – KRL has a class of variables called “persistent variables” or just “persistents”. There are two kinds of persistents: application variables and entity variables. Both are closed over the ruleset they are in, meaning that they are only visible to code executing within the ruleset. Application variables are stored for the ruleset and are available to any entity executing the ruleset. Entity variable values are only visible to the entity for whom they were stored. Application variables are roughly analogous to class variables. Entity variables are like instance variables. Entity variables, in particular, are a very powerful concept since they provide KRL programmers with the ability to store persistent values without the headache of configuring, linking, and using a database for most things. Because a ruleset represents a closure over its entity variables, every ruleset potentially represents a persistent data object.
Event-Condition-Action KRL is called an event condition action or ECA rule language because of the roles that those three fundamental parts of a rule play:
Events – Events trigger specific things to occur. Events are like the trigger of the "gun"—the rule. Without the event to trigger the rule, nothing happens. Conditions – Conditions are similar to the safety of a gun. If the conditional expression does not return true, the rule does not fire. Just as a gun either shoots or doesn't shoot based upon the safety, there is no else statement on conditionals. If you want a rule to fire in the opposite case, you can use the not fired postlude to trigger another event, or you can have a rule with a conditional which tests for the opposite case. Actions – Actions are like the bullet coming out of the gun; they are the final result of the rule. A rule may have multiple actions. Besides a collection of rules, KRL rulesets also contain a meta section for specifying information about the ruleset, a dispatch section for providing clues about event salience, and a global section for global definitions. Each rule conforms to the pattern for ECA rule languages given above with some significant additions. The basic structure of a KRL rule is as follows:
rule <name> { select when <eventexpr> pre { <declarations> } if <expr> then <action> fired { <effects> } else { <effects> } }
Event expressions in the select statement declare the conditions under which the rule will be selected. Declarations in the rule prelude allow values to be calculated and store for use later in the rule Conditional expressions determine whether a selected rule fires. Actions can be either built-in or user defined and specify the action of the rule Statements in the rule's postlude (fired...else...) affect persistent variables and raise further events.
Event generators KRL events are raised by other rules of event generators commonly referred to as "endpoints". Events are commonly raised over HTTP using a model that conforms to the Evented API, but KRL is transport agnostic. For example, events could be transported by email, SMS, MQTT, or any other system supporting push-style notifications. Because the Evented API is a specialization of the webhook concept, any system that supports webhooks can raise events for KRL. KRL uses event channels to identify the entity for which the event is raised. An entity can have any number of event channels. Event channels are encoded in the URL for events transported over HTTP. An endpoint that generates an event may be observing some activity directly and reporting salient state changes or it might just be reporting or transforming event data from another source (e.g., a webhook). Endpoints are responsible for
raising relevant events to the event processor, responding to directives from the event processor, and maintaining state to link separate interactions with the event processor together in meaningful ways to create context.
… excerpt ends here. Continue reading the full article.
