Reactors: A Data-Oriented Synchronous/Asynchronous Programming Model for Distributed Applications

Transcription

1 Reactors: A Data-Orented Synchronous/Asynchronous Programmng Model for Dstrbuted Applcatons John Feld 1, Mara-Crstna Marnescu 1, and Chrstan Stefansen 2 1 IBM T.J. Watson Research Center {jfeld,maracm@us.bm.com 2 Department of Computer Scence, Unversty of Copenhagen cstef@dku.dk Abstract. Our am s to defne the kernel of a smple and unform programmng model the reactor model sutable for buldng and evolvng nternet-scale programs. A reactor conssts of two prncpal components: mutable state, n the form of a fxed collecton of relatons, and code, n the form of a fxed collecton of rules n the style of datalog. A reactor s code s executed n response to an external stmulus, whch takes the form of an attempted update to the reactor s state. As n classcal process calcul, the reactor model accommodates collectons of dstrbuted, concurrently executng processes. However, unlke classcal process calcul, our observable behavors are sequences of states, rather than sequences of messages. Smlarly, the nterface to a reactor s smply ts state, rather than a collecton of message channels, ports, or methods. One novel feature of our model s the ablty to compose behavors both synchronously and asynchronously. Also, our use of datalog-style rules allows aspect-lke composton of separately-specfed functonal concerns n a natural way. 1 Introducton In modern web applcatons, the tradtonal boundares between browser-sde presentaton logc, server-sde busness logc, and logc for persstent data access and query are rapdly blurrng. Ths s partcularly true for so-called web mash-ups, whch brng a varety of data sources and presentaton components together n a browser, often usng asynchronous ( AJAX ) logc. Such applcatons must currently be programmed usng an agglomeraton of data access languages, server-sde programmng models, and clent-sde scrptng models; as a consequence, programs have to be entrely rewrtten or sgnfcantly updated to be shfted between ters. The large varety of languages nvolved also means that components do not compose well wthout panful amounts of scaffoldng. Our ultmate goal s thus to desgn a unform programmng language for web applcatons, other human-drven dstrbuted applcatons, and dstrbuted busness processes or web servces whch can express applcaton logc, user nteracton, and applcaton logc usng the same basc programmng constructs. Ideally, such a language should also smplfy composton, evoluton, and mantenance of dstrbuted applcatons. In ths paper, we defne a kernel programmng model whch s ntended to address these ssues and serve as a foundaton for future work on programmng languages for nternet applcatons. A.L. Murphy and J. Vtek (Eds.): COORDINATION 2007, LNCS 4467, pp , c Sprnger-Verlag Berln Hedelberg 2007

2 Reactors: A Data-Orented Synchronous/Asynchronous Programmng Model 77 The reactor model s a synthess and extenson of key deas from three lngustc foundatons: synchronous languages [2, 4, 7], datalog [15], and the actor model [1]. From datalog, we get an expressve, declaratve, and readly composable language for data query. From synchronous languages, we get a well-defned noton of "event" and atomc event handlng. From actors, we get a smple model for dynamc creaton of processes and asynchronous process nteracton. A reactor conssts of two prncpal components: mutable state, n the form of a fxed collecton of relatons, and code, n the form of a fxed collecton of rules n the style of datalog [15]. A reactor s code s executed n response to an external stmulus, whch takes the form of an attempted update to the reactor s state. When a stmulus occurs, the reactor s rules are appled concurrently and atomcally n a reacton to yeld a response state, whch becomes the ntal state for the next reacton. In addton to determnng the response state, evaluaton of rules n a reacton may spawn new reactors, or generate new stmul for the currently executng reactor or for other reactors. Importantly, newlygenerated stmul are processed asynchronously, n later reactons. However, we provde a smple mechansm to allow collectons of reactors to react together as a unt when approprate, thus provdng a form of dstrbuted atomc transacton. As n classcal process calcul, e.g., p [12], the reactor model accommodates collectons of dstrbuted, concurrently executng processes. However, unlke classcal process calcul, our observable behavors are sequences of states, rather than sequences of messages. Smlarly, the nterface to a reactor s smply ts state ( REST style [6]), rather than a collecton of message channels, ports, or methods. We accommodate nformaton hdng by preventng certan relatons n a reactor s state from beng externally accessble, and by allowng the publc relatons to serve as abstractons of more detaled prvate state (as n database vews). A sgnfcant advantage of usng data as the nterface to a component, and datalog as a bass for defnng program logc, s that the combnaton s hghly declaratve : t allows separately-specfed state updates (wrtten as rules) to be composed wth mnmal concern for control- and data-dependence or evaluaton order. Contrbutons. We beleve that the reactor model s unque n combnng the followng attrbutes harmonously n a sngle language: (1) data, rather than ports or channels as the nterface to a component; (2) synchronous and asynchronous nteracton n the same model, wth the ablty to generate processes dynamcally; (3) expressve data query and transformaton constructs; (4) the ablty to specfy constrants/assertons as a natural part of the core language; (5) dstrbuted atomc transactons; and (6) declaratve, compostonal specfcaton of functonalty n an aspect-lke manner. 2 Reactor Bascs A reactor conssts of a collecton of relatons and rules, whch together consttute a reactve, atomc, stateful unt of dstrbuton. The full reactor syntax s gven n Fg. 2. Consder the declaraton for OrderEntryA n Fg. 1. OrderEntryA defnes a class of reactors that are ntended to log orders say, for an on-lne catalog applcaton. Reactor nstances are created dynamcally, usng a mechansm we wll descrbe shortly.

3 78 J. Feld, M.-C. Marnescu, and C. Stefansen def OrderEntryA = { (* orders: d, temd, qty *) publc orders: (nt, nt, nt). (* log: d, temd, qty *) log: (nt, nt, nt). log(d, temd, qty) <- orders(d, temd, qty). def OrderEntryA = { (*... same as OrderEntryA... *) not log(d, temd, qty) <- not orders(d, temd, qty). def OrderEntryB = { (*... same as OrderEntryA... *) (* orderisnew s true f order has not prevously been logged *) ephemeral orderisnew: (). orderisnew() <- orders(d, temd, qty), not -log(d, temd, qty) def OrderEntryC = { (*... same as OrderEntryB... *) (* delete any new order whose d s duplcate of a prev. logged d *) not orders(d, temd, qty) <- ^orders(d, temd, qty), not -log(d, temd, qty), -log(d, _, _). Fg. 1. Order entry: varatons Relatons. The state of a reactor s emboded n a fxed collecton of persstent relatons. Relatons are sets of (τ 1,..., τ n ) tuples, where each τ s one of the types nt, strng, enum-type-name,orref reactor-type-name. The prmtve types have the usual meanngs. Enumeratons ntroduce a new type rangng over a fnte set of constants. Reactor references, of the form ref reactor-type-name, are descrbed n Secton 4. Relatons are empty when a reactor s nstantated. In addton to persstent relatons, whose values persst between reactons, a reactor can declareephemeral relatons. These relatons can be wrtten and read n the same manner as persstent relatons, but they are re-ntalzed wth every reacton. In the case of OrderEntryA, ts state conssts of two persstent relatons, orders and log, each of whch s a collecton of 3-tuples of nteger values. Relaton orders has access annotaton publc, whch means that the contents of orders may be read or updated by any clent. By update, we smply mean that tuples may be added to or deleted from orders; no other form of update s possble. Relaton log, lackng any access annotaton, s prvate, the default, and may thus only be read or updated by the reactor that contans log. REACTOR ::= def reactor-type-name = { {DECL.* ENUM ::= enum enum-type-name = { {atom-name,+ DECL ::= ( RELATION-DECL RULE-DECL ). RELATION-DECL ::= [publc publc wrte publac read][ephemeral] rel-name : ( {TYPE,* ) RULE-DECL ::= HEAD-CLAUSE <- BODY BODY ::= {BODY-CLAUSE,+ HEAD-CLAUSE ::= [not][var-name.]rel-name[ˆ] ( {(_ var-name new reactor-name),* ) BODY-CLAUSE ::= [not][var-name.][ˆ -]rel-name ( {(_ var-name),* ) BASIC-PREDICATE BASIC-PREDICATE ::= EXP (< > <> =) EXP TYPE ::= nt strng enum-type-name ref reactor-type-name EXP ::= var-name NUMERIC-LITERAL STRING-LITERAL EXP (+ - * / %) EXP self Fg. 2. Reactor syntax

4 Reactors: A Data-Orented Synchronous/Asynchronous Programmng Model 79 The reacton process. A reacton begns when a reactor receves an update bundle from an external source. An update bundle s a total map from the set of relatons of the recpent to pars of sets (Δ +,Δ ),whereδ + and Δ are sets of tuples to be added and deleted, respectvely, from the target relaton, and Δ + Δ =. An update bundle should contan at least one non-empty set,.e. completely empty update bundles are not well-formed. In the examples that follow, an update bundle wll typcally contan an update to a sngle relaton, usually addng or deletng only a sngle tuple. However, an update bundle can n general update any of the publc relatons of a reactor, and add and delete arbtrary number of tuples at a tme. The state of a reactor before an update bundle s receved s called ts pre-state. A reacton begns when an update bundle s appled atomcally to the pre-state of a reactor, yeldng ts stmulus state. The stmulus state of a reacton s (conceptually) a copy of each relaton of the reactor wth the correspondng updates from the update bundle appled. So, for example, n the case of OrderEntryA, f relaton orders contaned the sngle tuple (0, 1234, 3) pror to a reacton, and a reacton s ntated by applyng an update bundle wth Δ + = {(1, 5667, 2) and Δ =, then the stmulus value of orders at the begnnng of the reacton wll be the relaton {(0, 1234, 3), (1, 5667, 2). We wll refer to the value of relaton r n the stmulus state and the stmulus value of r nterchangeably. If a reactor contans no rules, the state of ts relatons at the end of a reacton ts response state s the same as the stmulus state, and the reacton stores the stmulus values back to the correspondng persstent relatons. Hence n ts smplest form, a reacton s smply a state update. However, most nterestng reactors have one or more rules whch compute a response state dstnct from the reactor s stmulus state (Secton 3). Rule evaluaton can also defne sets of addtons and deletons to/from the future state of ether local relatons or va reactor references relatons of other reactors. These sets form the update bundles one bundle per reactor nstance referenced n a reacton that ntate subsequent reactons n the same or other reactors. Update bundles thus play a role smlar to messages n message-passng models of asynchronous computaton. It s mportant to note that from the pont of vew of an external observer, a reacton occurs atomcally, that s, no ntermedate states of the evaluaton process are externally observable, and no addtonal update bundles may be appled to a reactor untl the current reacton s complete. Fg. 3 llustrates the lfe cycle of a typcal collecton of reactors, both from the pont of vew of an external observer (the top half of the fgure) and nternally (the bottom half of the fgure schematcally depcts reactor M durng reacton ). The pre-state of reactor M durng reacton s labeled -S, ts stmulus state s labeled ^S, ts future state s labeled S^, and ts response state s labeled S. The terms pre-state, stmulus state, response state, and future state are meanngful only relatve to a partcular reacton, because one reacton s response state becomes the next reacton s pre-state, and references to a reactor s future state are used (along wth the pre-state) to defne the stmulus state for a subsequent reacton. The only true state, whch perssts between reactons, s the response state. An external observer therefore sees only a sequence of response states (more specfcally, the response values of publc relatons). Each rule of a reactor can refer programmatcally to relaton values n all four states: t can read the

5 80 J. Feld, M.-C. Marnescu, and C. Stefansen pre-state of a relaton (schematcally depcted as -r n Fg. 3), the stmulus state (^r), and the response state (r); t can wrte the response state and the future state (r^). 3 Rules Bascruleevaluaton.Reactor rules (Fg. 2) are wrtten n the style of datalog [15, 14]. ThesngleruleofOrderEntryA can be read as ensure that log contans whatever tuples are n orders. The rght-hand sde, or body of a reactor rule conssts of one or more bodyclauses.inorderentrya, there s only one body clause, a match predcate of the form orders(d, temd, qty). A match predcate s a pattern whch bnds nstances of elements of tuples n the relaton named by the pattern (here, orders) to varables (here, d, temd, andqty). As usual, we use _ torepresent a unque, anonymous varable. Evaluaton of the rule causes the body clause to be matched to each tuple of orders and bnds varables to correspondng tuple elements. Snce the head clause on the left sde of the rule contans the same varables as the body clause, t ensures that log wll contan every tuple n orders. In general, a RULE-DECL can be read for every combnaton of tuples that satsfy BODY, ensure that the HEAD-CLAUSE s satsfed (by addng or deletng tuples to the relaton n HEAD-CLAUSE). The semantcs of datalog rule evaluaton ensures that no change s made to any relaton unless necessary to satsfy a rule, and for our chosen semantcs that rule evaluaton yelds a unque fxpont result n whch all rules are satsfed. Although our rule evaluaton semantcs s consstent wth standard datalog semantcs, we have made several sgnfcant extensons, ncludng head negaton, reference creaton, and the ablty to refer to remote reactor relatons va reactor references. Returnng to reactor OrderEntryA, let us consder the case where the pre-state values of orders and log are, respectvely, {(0, 1234, 3) and{(0, 1234, 3), and an update bundle has Δ + = {(1, 5667, 2) and Δ =. Then the stmulus value of orders wll be equal to {(0, 1234, 3), (1, 5667, 2). No rule affects the value of orders, so the response value of orders wll be the same as the stmulus value. In the case of log, rule evaluaton yelds the response state {(0, 1234, 3), (1, 5667, 2),.e., the least change to log consstent wth the rule. Now, startng wth the result of the prevous OrderEntryA reacton descrbed above, consder the effect of applyng another update bundle such that Δ + = and Δ = {(0, 1234, 3). Ths reacton wll begn by deletng (0, 1234, 3) from orders, yeldng the stmulus state orders = {(1, 5667, 2), log = {(0, 1234, 3), (1, 5667, 2). Evaluatng the rule after the deleton has no net effect on log (snce the only remanng tuple n orders s already n log), hence we get the response state orders = {(0, 1234, 3) and log = {(0, 1234, 3), (1, 5667, 2).We thus see that the effect of ths rule s to ensure that log contans every orderd ever seen n orders. If we wanted to ensure that log s mantaned as an exact copy of the current value of orders (whch would mean that t s no longer a log at all), we could add the addtonal negatve rule depcted n defnton OrderEntryA n Fg. 1. The negatve rule of OrderEntryA has the effect of ensurng that f an orderd s not present n orders, twllalso beabsentfromlog;.e., tencodestupledeleton. Whlenegaton s commonly allowed n body clauses for most datalog dalects, negaton on the head of a rule s much less common (though not unheard of, see, e.g., [16]).

6 Reactors: A Data-Orented Synchronous/Asynchronous Programmng Model 81 M-1 M M+1 M S -1 S S +1 N P M next reacton nbox remove APPLY -S ^S Rules -r ^r r r^ reacton done S S^ dspatch bundle add nb k network nb n add Fg. 3. Reacton schematc Pre-state value and stmulus values of relatons. Reactor defntons OrderEntryB and OrderEntryC of Fg. 1 add addtonal rules that further refne the behavor of OrderEntryA, usng references to both pre-state and stmulus values of relatons. OrderEntryB defnes an ephemeral nullary relaton orderisnew, whch functons as a boolean varable, ntally false. The new rule n OrderEntryB sets orderis- New to true (.e., adds a nullary tuple) f orders contans a value not found n log pror to the reacton (.e., n log s pre-state value). The defnton of OrderEntryC further refnes OrderEntryB by causng any new order whose orderd s a duplcate of a prevously logged orderd to be deleted. The new rule n OrderEntryC must dstngush the stmulus value of orders,.e., ^orders from ts response value,.e., orders, snce the rule defnes the response value to be somethng dfferent from the stmulus value n the case where a duplcate order d s present. It s mportant to note that the result of rule evaluaton s oblvous to the order n whch rules are declared. We beleve ths feature makes t much easer to update the functonalty of a reactor by changng the rule set wthout concern for control- or data-dependences. We see ths feature demonstrated n the progresson of examples depcted n Fg. 1, where rules can be mxed and matched lberally to yeld updated functonalty. Thus rules allow orthogonal functonal concerns to be specfed n an aspect-lke fashon [10]. Intalzaton, constants, and reacton falure. Consder the par of rules r(x) <- s(x) and not r(x) <- s(x). These rules are nherently contradctory, snce they requre that x be both present and absent from relaton r. In such cases, a conflct results. Because rules are condtonally evaluated, conflcts cannot n general be detected statcally and must be detected durng rule evaluaton. If such a conflct occurs, the reacton fals: the reactor rolls back to ts pre-state and no update bundles are dspatched. Consder the reactor defnton Cell depcted n Fg. 4. Each nstance of a Cell s ntended to hold exactly one value. Instances of Cell contan two relatons: a publc unary relaton val contanng the publcly-accessble value of the cell, and a prvate

7 82 J. Feld, M.-C. Marnescu, and C. Stefansen def Cell = { publc val:(nt). lve:(). (* ntalzatons *) (*1*) lve() <-. (*2*) val(0) <- not -lve(). (* sngleton constrant: f not satsfed, reacton fals; reactor rolls back *) (*3*) not lve() <- val(x), val(y), x <> y. Fg. 4. Cell nullary (.e., boolean) relaton lve. Recall that a reactor s relatons are ntally empty when the reactor s nstantated. Rules (1) and (2) together defne an dom whch wll allow us to ntalze relatons to non-empty values. Frst, consder rule (1). Rule (1) s an uncondtonal rule, and s an nstance of the shorthand notaton depcted n Fg. 5(b). Rule (1) defnes lve to be a a constant, snce ts response value evaluates to nonempty (.e., true ) at the end of every reacton. Because of rule (1), -lve n rule (2) s nonemptyonly durngthe frst reactonn whch the Cell s nstantated. Hence val wll be ntalzed to 0 only once, n the reacton n whch Cell s created. Thereafter, -lve wll be non-null, and the ntalzaton wll not recur, allowng val to be freely updated to arbtrary values. Fnally, consder rule (3) of Cell. The three clauses n ts body collectvely check to see whether val contans more than one value,.e., whether t s a sngleton. If not, the rule requres that ts goal clause (left-hand sde) be satsfed,.e., that lve be set to empty (false). However, any such attempt s nconsstent wth the asserton n rule (1) that lve s non-empty (true), hence any attempt to update Cell wthout mantanng the sngleton nvarant wll result n a conflct and reacton falure. We thus see that the reactor model allows assertons and ntegrty constrants n the style of databases to be expressed n precsely the same form as rules that express state updates. When some asserton fals, the reacton rolls back. Fg. 5(d) depcts a notatonal conventon that wll allow us to use FAIL to defne rules that represent assertons. 4 Asynchronous Reactor Composton Up to ths pont, we have not explaned how update bundles are generated, only how reactors react when an update bundle s appled. In ths secton, we show how updates are generated, and explan how ths s ntmately connected to asynchronous nteracton. Sngle-reactor asynchrony. Consder the reactor defnton Fbonacc n Fg. 6, whch computes successve values of a Fbonacc seres. The relaton seres contans pars whose frst element s the ordnal poston of the sequence value, and whose secondelements thecorrespondngvalueofthesequence. Thevalueofseres s ntalzed usng notatonal conventons (e) and (f) of Fg. 5. To compute the next element of the seres, we need to frst dentfy the last two elements of the seres computed thus far. Unversal quantfcaton s requred to determne the maxmum element of a seres; however, the body of a datalog rule can essentally encode only exstental propertes. To compute unversal propertes, we typcally requre auxlary relatons, thus, e.g., n Fbonacc, we use the ephemeral relaton notlargest to contan all the ndces of elements of seres whch are less than the maxmum ndex.

8 Reactors: A Data-Orented Synchronous/Asynchronous Programmng Model 83 Notaton Translaton Comments a r1(exp 0 ) <-...r(exp )... r1(x0) <-...r(x)..., x0 = exp 0,..., x = exp. Expressons exp are nstances of nontermnal EXP n Fg. 2; the x are fresh varables. b head <-. head <- 0 = 0. c r(x1,...xn) := body. r(x1,...xn) <- body. not r(x1,...xn ) <- body, -r(x1,...xn ), x1 <> x1.... not r(x1,...xn ) <- body, -r(x1,...xn ), xn <> xn. d FAIL <-... not lve() <-... Assumes the followng defntons exst: lve: (). lve() <- not -lve(). e body 0 :{ head 1 <- body 1. head n <- body n. head 1 <- body 1, body 0. head n <- body n, body 0. f INIT not -lve() Assumes same defntons as (d). g head 1,, head n <- body. head 1 <- body. head n <- body. Fg. 5. Notatonal conventons def Fbonacc = { (* complete seres thus far: 1st elt. s ndex, 2nd elt. s value *) publc read seres: (nt, nt). (* must be true for reactor to run *) publc wrte run: (). (* holds ndces n the sequence less than the maxmum *) ephemeral notlargest: (nt). INIT: { seres(1,0), seres(2,1) <-. run() <-. (* ndces n seres less than max *) (*1*) notlargest(n) <- seres(n, _), seres(n, _), n > n. (* compute next seres value *) (*2*) seres^(n, x1+x2) <- not notlargest(n), seres(n-1, x1), seres(n, x2). (* halts f "run" set to false *) (*3*) FAIL <- not -run(), not ^run(). Fg. 6. Self-Reactng Fbonacc Note that the relaton n the head of rule (2) computng the next value of the Fbonacc sequence has the form seres^. A relaton name of ths form refers to the future state of the relaton. The future state defnes the contents of an update bundle whch s processed after the current reacton ends, n a subsequent reacton. One can thus thnk of the future value of a relaton as defnng an asynchronous update or dspatchng a message. As a result, successve values of the seres are separately vsble to external observers as they are added to the lst. Rule (3) results n falure f both the pre-state and the stmulus values of run are false, thus preventng further updates to the seres from beng generated. Instances of Fbonacc can react to two dstnct classes of update bundles: nternally generated update bundles contanng only new values of the seres, and clent-generated update bundles whch only affect the value of run. A clent cannot update seres snce seres s not publc. The Fbonacc reactor does not produce update bundles affectng the value of run, snce t has no rules referrng to the future value of run.

9 84 J. Feld, M.-C. Marnescu, and C. Stefansen In general, dstnct reactors operate concurrently and ndependently. Gven ths fact, t s possble for an update bundle to be generated by a clent attemptng to update the value of run whle a prevous reacton by the same nstance s n progress. Snce reactons take place atomcally, we must enqueue pendng clent updates untl the current reacton s complete. To ths end, every reactor has an assocated nbox queue contanng a multset of pendng update bundles. When a reacton s complete, the reactor checks for a new update bundle n the queue. If t exsts, the reactor dequeues t and uses t to ntate a reacton. If no update bundle s present, the reactor performs no further computaton untl a new update arrves. We make no assumptons about the order n whch nbox tems are processed, except that they must be processed farly. Fg. 3 llustrates ths process. Reactor references and mult-reactor asynchrony. Untl now, our examples have only consdered a sngle reactor type. Consder now the defntons for reactors Sample, Sensor, andnonce depcted n Fg. 7. Reactor types Sample and Sensor def Sample = { (* rsensor: ref. to sensor; assumed to be ntalzed by clent *) publc rsensor: (ref Sensor). (* samples collected thus far; nonces dstngush sample nstances *) publc log: (ref Nonce, nt). (* pulse: set to collect sample *) publc wrte ephemeral pulse: (). (* response: holds sensor response *) publc wrte ephemeral response: (nt). (* request sample when pulse set *) (*1*) s.req^(self) <- pulse(), rsensor(s). (* process response: add sample to log *) (*2*) log(new Nonce, r) <- response(r). def Sensor = { (* set when sample s to be collected; value s ref. to sample reactor *) publc wrte ephemeral req: (ref Sample). (* val: current sensor value *) publc val:(nt). (* send resp. when clent sets req *) r.response^(v) <- val(v), req(r). (* sensor value s a sngleton *) FAIL <- val(x), val(y), x <> y. def Nonce = { Fg. 7. Asynchronous query/response encode a classcal asynchronous request/response nteracton. To enable two reactor nstances to communcate, we use reactor references such as those stored n relaton rsensor. Rule (1) of Sample has the effect of dspatchng an asynchronous request for the sensor value (mantaned a Sensor reactor) whenever a clent of Sample updates pulse. The expresson s.req^(self) n Rule (1) contans an ndrect reference to relaton rsensor: after the reactor reference stored n relaton rsensor s bound to varable s, we refer to relaton req of the sensor nstance ndrectly usng the expresson s.req. Snce we refer to the future value of s.req, an asynchronous update bundle s dspatched to the Sensor nstance. The update bundle contans a self-reference to the requestng Sample nstance, whch s generated by the self construct.

10 Reactors: A Data-Orented Synchronous/Asynchronous Programmng Model 85 A Sensor nstance responds to a request (n the form of an update to relaton req) by dspatchng the current value of the sensor back to the correspondng Sample nstance. It does so by by settng the Sample s response relaton va the reactor reference sent by the requester. The response s asynchronous, snce r.response^ refers to a future value. The requester processes the response from the Sensor nstance by updatng ts log relaton wth the value of the response. There are two ways of ntroducng references to reactors. The keyword self evaluates to a reference to the enclosng reactor. An expresson of the form new reactortype-name nstantates a new nstance of the gven reactor type. Instantaton expressons may only appear n the head of a rule. Rule (2) of Sample creates nstances of the trval reactor Nonce. A reactor reference s globally unque, hence trval reactors such as Nonce can be used as sources of keys for relatons. In partcular, Sample uses nstances of Nonce to dstngush multple nstances of the same sensor value. Whle Nonces contan no rules, n general, when a reactor s nstantated n a reacton, ts rules are evaluated along wth the rules of the parent reactor, as we shall see n Secton 5. In order to nstantate and connect Sample and Sensor nstances together, another reactor must contan rules of the form s.rsensor(new Sensor) <- thesampler(s) and thesampler(new Sample) <-. A request-response cycle between Sample and Sensor nstances requres three dstnct reactons: the reacton n whch a Sample clent sets pulse (whch dspatches the request to the sensor), the reacton n whch the sensor responds to the request, and the reacton n whch the requester updates the value of log. 5 Synchronous Reactor Composton In the example n Fg. 8, an nstance of MnBank receves asynchronous requests to transfer money between accounts. As wth the example n Fg. 7, we use references to plumb the reactors together. However, unlke the prevous example, the remote references n Fg. 8 refer to response values of relatons, not future values. Ths means that f a reacton s ntated by an update bundle contanng a new req tuple at an nstance of MnBank, the scope of the reacton wll extrude to nclude both of the account reactors (referred to by varables to and from, respectvely). Ths results n a composte, synchronous, atomc reacton nvolvng three reactor nstances. Scope extruson s def Acct = { (* account balance *) publc balance: (nt). (* balance s a sngleton *) FAIL <- balance(x), balance(y), x <> y. (* negatve balances not allowed *) FAIL <- balance(x), x < 0. def Mnbank = { (* transfer request:transfer amount, to account, from accout *) publc wrte ephemeral transferreq: (nt, ref Acct, ref Acct). to.balance(x+amt) := ^transferreq(amt, to, _). from.balance(y-amt) := ^transferreq(amt, _, from). Fg. 8. Classc Transacton

11 86 J. Feld, M.-C. Marnescu, and C. Stefansen an nherently dynamc process, smlar to a dstrbuted transacton see Secton 6 for detals. MnBank uses the notaton of Fg. 5(c) to defne assgnments to sngleton relatons. Note that the rules n Acct encode constrants on the allowable values of balance. In a composte reacton, all of the rules of all of the nvolved reactors must be satsfable n order for the reacton to succeed. If any of the rules fals, the composte reacton fals, and all of the reactors revert to ther pre-reacton states. A composte reacton s always ntated at a sngle reactor nstance at whch some asynchronously-generated update bundle s processed n the case of the example n Fg. 8, reactor nstance MnBank. The example n Fg. 9 shows how multple user nterface components can be nstantated dynamcally based on the current contents of an assocated database. Ths mmcs the process of buldng dynamc, data-drven user nterface components. The basc dea of DataDsplay s that a button and an output feld are generated for each tem n a database. ButtonWdget and OutputWdget are reusable user nterface components representng the button and output feld generated for each tem n relaton db. The buttons thus generated are actve : pushng them causes the assocated data to be updated, whch n turn results n updates to the UI. For example, rule (8) wres together correspondng button and database tems such that when a button s pressed, the correspondng data tem s decremented. Rule (7) sets the value of the output feld to the value of the quantty currently mantaned n the database. The rules for newly-created reactors are evaluated as part of the parent reactor that created them. 6 Synchronous Reactons: Scope Extruson and Lockng Detals Scope Extruson. In response to an update bundle, a reactor evaluates all ts rules and whle dong so t may extrude the scope of the reacton to nclude other reactors. Extruson can happen n two ways: Frst, when a new reactor s nstantated t s ncluded n the scope of the reacton that caused t to be nstantated. Second, when the response state of any relaton (local or remote) s wrtten, the reactor that contans that relaton and all reactors contanng rules readng that relaton are ncluded n the scope of the ongong reacton. We say a relaton s wrtten whenever a rule produces a response-state update for that relaton regardless f ths results n a state change or not (e.g. addng an tuple that already exsts consttutes a wrte). One mportant excepton s the passve read. A passve read s a read from the pre-state of a remote relaton. It dffers from other remote reads n that wrtes to the remote relaton n tself wll not cause the reacton to extrude to the reader. A reacton s complete when all reactors ncluded n the reacton have reached a state that satsfes ther rules. If one or more nvolved reactors cannot reach a state that satsfes ther rules, there has been a conflct and all nvolved reactors roll back to ther pre-state,.e. the state they were n before the update bundle occurred or before they were ncluded n the reacton. If dfferent reactors nvolved n the same composte reacton separately defne future values for relatons of the same target reactor nstance, the updates are combned nto a sngle update bundle, whch wll be dspatched at the end of the composte reacton to the target reactor. In case the reacton rolls back, no update bundles are produced. In ths sense, from the pont of vew of an external observer, a

12 Reactors: A Data-Orented Synchronous/Asynchronous Programmng Model 87 def ButtonWdget = { publc label: (strng). publc wrte ephemeral pressed: (). def OutputWdget = { publc label: (strng). publc val: (strng). def DataDsplay = { (* database: temd, quantty *) publc db: (nt, nt). (* lst of button / output wdget pars,ndexed by temd *) wdgets: (nt, ref ButtonWdget, ref OutputWdget). (* labels of wdgets are constants *) (*1*) o.label("inventory: ") <- wdgets(_, _, o). (*2*) b.label("clck to decr") <- wdgets(_, b, _). (* projecton of relns. on temds *) ephemeral olddsplayitems: (nt). ephemeral currdbitems: (nt). (*3*) olddsplayitems() <- -wdgets(, _, _). (*4*) currdbtems() <- db(, _). (* create new chld wdgets when new tem added to db *) (*5*) wdgets(, new ButtonWdget, new OutputWdget) <- db(, _), not olddsplayitems(). (* delete wdgets f corresp. tems removed from db *) (*6*) not wdgets(, _, _) <- -wdgets(, _, _), not currdbitems(). (* output val set to qty of corresp. tem *) {*7*) o.val(tostrng(q)) := wdgets(, _, o), db(, q). (* button decrements qty. of corresp. tem *) (*8*) db(, q-1) := wdgets(, b, _), b.pressed(). Fg. 9. Data-Drven UI composte reacton has the same atomcty propertes as a reacton nvolvng a sngle reactor. If a reacton updates the future state of (local or remote relatons n) reactors C 1,...,C n, t produces n dfferent update bundles one per target reactor and each C wll have a separate and ndependent reacton to ts own update bundle. Even f the scope of C s reacton should happen to expand to nclude some other C j, C j s update bundle wll not be processed (or even vsble) n that reacton. Lockng. Conceptually a rule reads all relatons that appear n the body as well as any relaton that appears n negated form n the head. Thus a rule s need for read access can be determned statcally. Whether a rule wll wrte the head relaton when evaluated can generally only be determned at runtme, because the read has to match a non-empty set of facts that satsfy the body for a wrte to occur 1. For ths reason we wll use the term read to refer to the statc property, regardless of any optmzaton that mght avod unnecessary reads. The term wrte, on the other hand, wll be strctly reserved for the dynamc property,.e. a head relaton s consdered to be wrtten only f the body yelds at least one match when evaluated. When a reacton extends to nclude several reactors, the composte reacton should reman atomc. The followng lockng conventons ensure ths property. A reactor locks when t agrees to react to an update bundle and remans locked for the duraton of the reacton untl ether a quescent response state s found and commtted or a conflct causes the reactor to roll back to ts pre-state. When a reactor s locked, t denes any 1 When a tuple t s present n a relaton r, we say that r t s a fact.

13 88 J. Feld, M.-C. Marnescu, and C. Stefansen { no conflct all n reacton commt, dspatch update bundles, and release all locks { conflct all n reacton roll back and release all locks { -R = ^R = R quescent { update bundle b avalable start reacton r { ^R = apply(-r,b) { reacton requests lock release release lock { reacton requests read accept request from r { reacton requests wrte to response state jon reacton { -R = ^R = R { -R = ^R = R read locked on r { reactng on r nstantated by reacton r { -R = ^R = R = Ø { non-exstng START Fg. 10. Reactor state machne. Transtons are wrtten {precondtonactvty{postcondton. States are wrtten {nvarantstate. nteracton (read-access, wrte-access, and begnnng to react to other update bundles) wth reactors that are not part of the same reacton. Refer to Fg. 10 for an overvew. Intutvely, reacton scope extends to nclude all reactors ownng or (non-passvely) readng relatons beng wrtten, whle lock dynamcally extends to nclude all reactors ownng relatons beng read (as well as all reactors n the reacton scope). When a remote reactor s read, an exclusve lock on the reactor s acqured and held for the entre duraton of the reacton. Should the same remote reactor need to be wrtten later n the same reacton, ths defensve lockng strategy guarantees that references to the remote reactor s pre-state and response state wll n fact refer to two consecutve states of that reactor because t has not been free to serve any other reactons n the meantme. The problem of deadlock naturally arses n ths settng; a reactor mplementaton would requre that standard deadlock detecton, avodance, or recovery technques (e.g., optmstc concurrency control) be used. 7 Advanced Semantc Issues The rule evaluaton model for reactors extends standard datalog wth head clause negaton (to express deleton) and reactor references. In ths secton, we revew key aspects of standard datalog semantcs and defne our extensons. We evaluate the rules by forward dervaton (also called bottom-up dervaton). Ths strategy apples all rules on the facts to produce all possble consequences the approprate approach for our purpose of creatng a completely defned new state. 7.1 Head Clause Negaton: Semantcs Va Translaton We handle negaton n head clauses by transformng reactor rules to normal datalog rules. Frst, we treat each of the four states of a gven relaton as dstnct relatons from the pont of standard datalog semantcs. The goal of reactor rule evaluaton s to determne a unque, mnmal soluton for the response and future values of local and remote relatons. Let r represent the response or future value of a local relaton we wsh to compute (we wll consder reactor references shortly). Let r P 1,...rP n denote the contents of the persstent relatons mmedately pror to a reacton; f the reactor has just been created the relatons are empty by default. Let ^r Δ+, ^r Δ be the addton

14 Reactors: A Data-Orented Synchronous/Asynchronous Programmng Model 89 and the deleton sets of the update bundle appled to the reactor. The basc dea for determnng the soluton to r s as follows: (1) ntroduce a par of auxlary relatons (r Δ+,r Δ ) whch contans the sets of tuples that wll be added to and deleted from r ; (2) elmnate negaton n head clauses by transformng the program to a normal datalog program contanng references to r Δ+ and r Δ ; (3) evaluate the transformed program usng standard datalog semantcs; (4) for r a response state overwrte r P to nclude r Δ+ and exclude r Δ ;forr a future state copy (r Δ+,r Δ )nto(^r Δ+,^r Δ ). We now descrbe our program transformaton n detal. Gven a reactor C wth persstent relatons r and ephemeral relatons t, let us redefne ^r Δ+, ^r Δ, ^t Δ+ and ^t Δ to be the addton and the deleton sets of the update bundle appled to reactor C. We can assume that ^r Δ+ ^r Δ = and ^t Δ+ ^t Δ = because ths property s checked by the orgnatng reactor before creatng new update bundles. Let -r denote the pre-, ^r the stmulus, r the response, and r^ the future state of the reacton. Rewrte rules. Fg. 11 shows how our rewrtng technque transforms a program wth negaton n the head clauses to a program wthout them. Let us redefne r Δ+, r Δ, t Δ+ and t Δ the sets of addtons/deletons to the response state of the persstent and ephemeral relatons, correspondngly. Rewrte: r <- body as: r Δ+ <- body (I) Rewrte: not r <- body as: r Δ <- r, body (II) Rewrte: head <- r, body as: head <- r, not r Δ, body (III) Rewrte: head <- not r, body as: head <- r Δ, body head <- not r, body (IV) Rewrte: r^ <- body as: r^δ+ <- body (VII) Rewrte: notr^ <- body as: r^δ <- body (VIII) Add: r <- ^r (V) Add: r <- r Δ+ (VI) Fg. 11. Rewrte rules defnng the semantcs of reactor rule evaluaton n terms of normal datalog Rewrte rule (I) computes the set of tuples to be added to r as the set of tuples that the body clauses resolve to. Rule (II) computes the deleton set very smlarly; the only dfference s addng a body clause whch makes sure that a tuple gets deleted from a relaton only f t was already there. The extra clause ensures that ths rewrtng rule does not ntroduce doman dependence see further n ths secton for detals. Rule (VI) adds the new addton sets to the response state as soon as they are computed; ths ensures that the most current tuple addtons are vsble and propagatng to the rest of the reactor rules. We would lke to smlarly account for the deleton sets but to reflect that n the response state we have to express t as negaton n the rule head exactly what the program transformaton technque s tryng to elmnate. Therefore the deleton sets must be accounted for and propagated va the reactor rules. As a result, rule (III) restrcts the matchng for the tuples n r to the ones that are not n the deleton set; conversely, rule (IV) allows matchng on tuples n the deleton set. The rest of the

15 90 J. Feld, M.-C. Marnescu, and C. Stefansen rules are trval. For t rules (I) to (VI) apply unchanged; rules (VII) and (VIII) do not apply because ephemeral relatons do not have a future state. State updates. At the begnnng of a reacton the followng assgnments take place: -r ::= r P, ^r ::= ^r Δ+ -r \ ^r Δ, ^t ::= ^t Δ+ where ::= should be read as relaton overwrtng. Intutvely the frst assgnment overwrtes the pre-state of the current reacton s persstent relatons wth the contents of the relatons pror to the reacton. The next assgnments then apply the correspondng update bundles to the pre-state to obtan the stmulus state. Note that the deleton set of the update bundle ^t Δ for ephemeral relatons has no effect. All assgnments are done outsde datalog and have the effect of keepng a snapshot copy of the pre-state and the stmulus state n case the rules need to read them or the reacton rolls back. After the assgnments take effect we can apply standard datalog technques to evaluate the program rules up to a fxpont. If at any pont durng the evaluaton ether r Δ+ t^δ r Δ, r^δ+ r^δ, t Δ+ t Δ, or the evaluaton stops and the reacton rolls back. If we reach the t^δ+ fxpont (wthout ether of the checks falng) we update r P deleton sets: r P (r^δ+,r^δ ::= r \ r Δ )and(t^δ+ to take nto account the. Before quescng, the reacton forms the update bundles ) for other reactors and for tself, f applcable.,t^δ 7.2 Semantcs of Normal Datalog Programs: Stratfcaton and Safety As a result of applyng our rewrte technque, we are left wth a normal datalog program contanng negaton n body clauses only. Snce t s possble to use negaton to encode logcal paradoxes, we wsh to apply a syntactc constrant to rules that wll ensure that a unque soluton to collecton of rules exsts, wthout unduly affectng expressveness. We adopt the stratfcaton semantcs for normal programs wth negaton [15]. The man dea behnd stratfcaton s to partton the program along negaton such that for any relaton we fully compute ts content before applyng the negaton operator on t. For example, a program consstng of the rules q(x) <- p(x,y), not q(y) and p(1,2) <- s not stratfed because t contans recurson through negaton. Another desrable property of a datalog program s doman ndependence: a soluton should depend only on the known facts and not on the unversal set of all facts. We would also lke to ensure fnteness, or at least weak fnteness: that the evaluaton of a rule from a fnte set of facts yelds a fnte set of results, but nfnte results caused by nfnte recurson cannot be ruled out. To ensure doman ndependence and weak fnteness, we adopt the syntactc safety condton of Topor [14], whch supports arthmetc expressons and negaton. Brefly, a rule s safe f all of ts varables are lmted. A varable s lmted f t occurs n a non-negated clause n the body, f s occurs n a negated clause n the body and s not used elsewhere, or f t occurs n an expresson where a unque value of the varable can be computed gven all the lmted varables of the expresson. A program s safe f all of ts rules are safe.

16 Reactors: A Data-Orented Synchronous/Asynchronous Programmng Model Remote Reactor References In a nave approach, every tme a set of synchronously executng reactors C tres to extrude ts scope to a new reactor C whch s executng, C (1) wats for C to quesce and accept the scope extruson request, then (2) rolls back and restarts executon wthn the new scope expanded to nclude C. A less nave approach wll frst statcally compute the transtve closure of all the synchronously executng reactors based on the type nformaton. The goal s to coordnate the order of rule evaluaton wth the order of lockng see Secton 6. The algorthm wll therefore compute the global stratfcaton for the statcally computed reactor closure; any tme there s a choce of rules to evaluate next, the algorthm wll choose the one that s consstent wth the global stratfcaton. Ths wll make sure that postve nformaton n relatons s fully computed before evaluatng ts negaton. The program obtaned by puttng together the rules of all reactors C k n a reacton wll contan remote references to relatons n C k. To make all remote references local we defne the followng transformaton. For every relaton r n a reactor, the reactor defnes a shadow copy r~ and an mplct rule of the form r~(self,x) <- r(x). Every remote reference c.r(x) to relaton r can then be transformed nto a local access to r~(c,x). At ths pont the statcally computed set of rules only contans local references and t s treated as a sngle program to whch we can apply the transformaton n Fg Reactor Instantaton Detals The semantcs of reactor nstantaton must be defned wth some care to ensure that the number of reactors nstantated n a reacton s unambguous. Consder a rule whose head has the form r(x 1,..., x, new M, x +1,..., x n ),wherems a reactor type name and x k,k [1...n] are varables bound n the rule body. Then a tuple v 1,..., v,α,v +1,..., v n s a satsfyng soluton for the rule f and only f (1) α s a reference to a reactor of type M, (2)α s globally unque, (3) α dd not exst pror to the current reacton, (4) u 1,..., u j,α,u j+1,..., u m does not satsfy any rule wth a head of the form s(y 1,..., y j, new M, y j+1,..., y m ),and(5) u 1,..., u,α,u +1,..., u n does not satsfy any rule wth a head of the form r(x 1,..., x, new M, x +1,..., x n ), unless u k = v k for all k [1...n]. The basc dea behnd ths defnton s that n each reacton, for each nstance of new n a rule head, a new, globally unque reactor reference s generated for each satsfyng combnaton of values bound to varables n the rule. The generalzaton of ths semantcs to rules contanng multple nstances of new s straghtforward. Consder the rules [1] r(new Foo, ) <- t(), [2] s(y) <- r(y, _), and [3] s(new Foo) <-. If relaton t ntally contans three tuples, then followng the nstantaton semantcs above, rule [1] causes threenew reactors to be nstantated. Smlarly, rule [3] wll generateonenewreactor, dstnctfromthosegeneratedby rule [1]. If relaton s s ntally empty, t wll contan four dstnct reactor references at the end of the reacton: three from the reactors nstantated by rule [1], and one from the reactor nstantated by rule [3]. If we were to duplcate any of rules [1]-[3],the result of the reacton would reman the same, snce the nstantaton behavor of rules s dependent on ther semantcs, not ther syntactc form.

17 92 J. Feld, M.-C. Marnescu, and C. Stefansen Note that although the nstantaton semantcs dstngushes between new expressons and varables n rule heads, t does not dstngush reference-bound varables from other varables. Consder, e.g., the rules [4] t(new Bar, ) <- r() and [5] s(new Bar, b) <- t(b, j). Rule[5] requres that there exst a unque, newly generatedreference for each b satsfyng t(b, j). If r ntally contans two tuples, then rules [4] and [5] each nstantate two new reactors. It wll be convenent to assume that reactor references generated by the same reactor are totally ordered, whch allows them to be used as a source of ordered but otherwse unnterpreted keys. The Nonce reactors used n Fg. 7 serve ths purpose. 8 Extended Example: Three-Ter Web Applcaton Fg. 12 depcts an extended example whch follows the structure of a conventonal threeter web applcaton for catalog orderng (note that ths example makes extensve use of the notatonal abbrevatons of Fg. 5). Unlke the example n Fg. 9, whch combned clent and server functonalty n a sngle component, the example n Fg. 12 explctly models a database (DB), web server (WebServer), and browser (Browser) as dstnct components. The browser and web server communcate entrely asynchronously, whle the web server and database communcate synchronously (.e., transactonally). Page content n the browser s modeled by the ComposteWdget reactor type, whch s nstantated wth varous prmtve wdget reactors (OutputWdget and ButtonWdget from Fg. 9 and a new FormWdget), dependng on the type of page beng dsplayed. Instances of ComposteWdget perform local (.e., browser-sde ) computaton whch performs basc form valdaton. Such functonalty could easly be replaced wth more elaborate browser-based wdgets, e.g., wth AJAX-style asynchronous behavor. One lmtaton of our current model s that all reactor references must be strongly typed, whch makes t dffcult to model a web browser reactor that can render arbtrary pages, also represented as reactors. In the future, we wll consder more flexble type systems as well as weaker stratfcaton requrements, whch would allow a completely generc browser to be defned. 9 Related and Future Work Related Work. Fundamentally, reactors are reactve systems [8], combnng and extendng features from several, largely unrelated areas of research: synchronous languages, datalog [15], and the actor model [1]. Esterel [2], Lustre [4], Sgnal [7], and Argos [11] are promnent synchronous languages. In synchronous languages, the term causalty refers to dependences, and all have restrctons on cyclc dependences. Esterel only admts a program f all sgnals can be nferred to be ether present or absent (as opposed to unknown); ths s referred to as constructveness. Esterel adopts a strct nterleavng semantcs,.e. t assumes that reactons cannot overlap temporally. In Esterel sgnals are broadcast nstantaneously so that all receptors of the sgnal wll see t n the same nstant and the sgnal wll only exst n that reacton. The reactor model, on the other hand, supports both synchronous and asynchronous broadcasts (readers can react when a relaton s changed) as well as