Date: Fri, 29 Mar 2024 15:28:24 +0000 (UTC) Message-ID: <274808736.5.1711726104530@e4349de20251> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_4_423809265.1711726104529" ------=_Part_4_423809265.1711726104529 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Consider the following example adapted from a Scientific American article on the Semantic Web:
The entertainment system was belting out = the Beatles' "We Can Work It Out" when the phone rang. When Pete answered, = his phone broadcast a message to all local devices indicating it had receiv= ed a call. His stereo responded by turning down the volume. ...
The message that Pete's phone sends is an event. That event--let's call =
it phone:inbound_call
--doesn't say what should hap=
pen. Rather, the event processors that happen to be listening for that even=
t make that determination. They react to the event.
Event processors take the form of rules. Rules are a natural way to buil=
d reactive systems because they allow behavior to be layered. In the stereo=
example, two rules--one for the stereo and one for the DVR--could be liste=
ning for the phone:inbound_call
event and tak=
e what action is appropriate in their context. Adding another listener simp=
ly means adding another rule. The rule defines what should happen when a pa=
rticular event pattern occurs. The rules determine the response.
The basic pattern for a rule is shown in the following pseudocode:
when an event =
occurs
if some condition is true
then take some action
This pattern is called the event-condition-action, or ECA, pattern. Many= rule languages use this pattern. The ECA pattern is typical for most busin= ess rule systems. Rule languages based on this pattern are a widely accepte= d way to build reactive systems.
Separating events from conditions is a key concept in ECA rule languages=
. As you've seen, events represent a state transition. Conditions, on the o=
ther hand, are used to determine if the current state has specific properti=
es. For example, the phone:inbound_call
event=
signals that the phone system has detected a phone call (i.e., the state c=
hanged from one in which no phone call was happening to one in which a phon=
e call was happening). Conditions can be used to check properties of the ne=
w state, such as "is the call from the 801 area code?" "Is it after 5 p.m.?=
" or "Does the user's Google calendar show that she's busy right now?" The =
separation of events from conditions provides a clear distinction between w=
hen (event), what (condition), and how (action).
The Kinetic Rule Language (KRL) is an ECA rule language. KRL is a progra= mming language for creating applications on the Live Web. KRL programs, or = rule sets, comprise a number of rules that respond to particular events.&nb= sp;
Besides a collection of rules, KRL rule sets also contain a m=
eta
section for specifying information about the rule set, a&nb=
sp;dispatch
section for providing clues about event salie=
nce, and a global
section for global definitions.&nb=
sp;
Each rule conforms to the aforementioned pattern for ECA rule languages = with some significant additions. The basic structure of a KRL rule is as fo= llows:
r= ule <name> { select when <eventex> pre { <declarations> } if <expr> then <action> fired { <effects> } else { <effects> } }
Only the name and eventex are required, so most rules are simpler than t= his template. (Obviously, a rule with only a name and eventex wouldn't acco= mplish anything, so meaningful rules include at least an action or a postlu= de in addition to the required components.) The prelude contains a list of = variable declarations that allow computation of values for the condition an= d action based on global values and event attributes. Later, this chapter w= ill discuss the KRL expression language in greater detail.
Actions specify the reaction that the rule makes to the event. Actions t= ake two general forms:
The section after the action is called the postlude. It allows for effec= ts. Effects are an important addition to the ECA pattern. Effects differ fr= om actions in that they do not result in directive documents being sent to = the endpoint. Instead, they cause side effects on the KRE system. Examples = of effects include the following:
last
stat=
ement causes the execution of the ruleset to terminate after the current ru=
le.