The SQL-based All-Declarative FORWARD Web ApplicationDevelopment Framework ∗ †

Yupeng FuUC San Diego

yupeng@cs.ucsd.edu

Kian Win Ongapp2you Inc.

kianwin@app2you.comYannis Papakonstantinouapp2you Inc. / UC San Diego

yannis@cs.ucsd.edu

Michalis PetropoulosSUNY Buffalo / UC San Diego

mpetropo@buffalo.edu

1. INTRODUCTIONThe vast majority of database-driven web applications

perform, at a logical level, fundamentally simple INSERT/ UPDATE / DELETE commands. In response to a useraction on the browser, the web application executes a pro-gram that transitions the old state to a new state. Thestate is primarily persistent and often captured in a singledatabase. Additional state, which is transient, is maintainedin the session (e.g., the identity of the currently logged-inuser, her shopping cart, etc.) and the pages. The programsperform a series of simple SQL queries and updates, and de-cide the next step using simple if-then-else conditions overthe state. The changes made on the transient state, thoughtechnically not expressed in SQL, are also computationallyas simple as basic SQL updates.

Despite their fundamental simplicity, creating web appli-cations takes a disproportionate amount of time, which is ex-pended in mundane data integration and coordination acrossthe three layers of the application: (a) the visual layer onthe browser, (b) the application logic layer on the server,and (c) the data layer in the database.Challenge 1: Language heterogeneities. Each layeruses different and heterogeneous languages. The visual layeris coded in HTML / JavaScript; the application logic layerutilizes Java (or some other language, such as PHP); andthe data layer utilizes SQL. Even for pure server-side /pure HTML-based applications, the heterogeneities causeimpedance mismatch between the layers. They are resolvedby mundane code that translates the SQL data into Javaobjects and then into HTML. When the front end issues a

∗Supported by NSF awards IIS 1018961, IIS 0917379 and aGoogle gift.†The license grant at the bottom of the first column doesnot confer by implication, estoppel or otherwise any licenseor rights under any patents of authors or The Regents of theUniversity of California.

This article is published under a Creative Commons Attribution License(http://creativecommons.org/licenses/by/3.0/), which permits distributionand reproduction in any medium as well allowing derivative works, pro-vided that you attribute the original work to the author(s) and CIDR 2011.5th Biennial Conference on Innovative Data Systems Research (CIDR ’11)January 9-12, 2011, Asilomar, California, USA.

request, code is again needed to combine memory-residingobjects of the session and the request with database data.Consequently, developers write a lot of “plumbing” code.

As a data point, in a UCSD web development class taughtby the authors, the students built a web application of theirchoice. A class project averages 4700 lines of code and con-figuration, but for 1 line of SQL, there is a modest 1.5 linesof Java used for business logic, and 61 lines of Java usedfor plumbing.1 That is a lot of plumbing code to write forthe computationally simple functionality that is typicallyrequired by the majority of web applications!Challenge 2: Updating Ajax pages with event-drivenimperative code. Since 2005, Ajax led to a new genera-tion of web applications characterized by user experiencecommensurate to desktop applications. The heavy usage ofJavaScript code for browser-side computation and browser /server communication leads to superior user experience overpure server-side applications, comprising

• performance gains through partial updates of the page

• more responsive user interfaces through asynchronousrequests, and

• rich functionality through various JavaScript compo-nent libraries, such as maps, calendars and tabbed di-alogs.

For example, consider the web application page of Figure1, where each user submits proposal reviews, reads the re-views provided by the other reviewers and also views a barchart of the average grades for each proposal. In a pureserver-side model, submitting a review for a single proposalwill cause the entire page to be recomputed. Indeed, querieswill be issued for the reviews and average grades of all pro-posals, not only for the reviewed proposal. Furthermore,the browser will block synchronously and blank out while

1We count as business logic Java lines that decide the controlflow of the application. We count as plumbing the Java linesresponsible for binding SQL to Java and Javascript and viceversa, plus all code responsible for managing language anddata structure heterogeneities.A contributing factor to the huge plumbing to business logicratio is the best practice usage of MVC frameworks such asStruts, which is encouraged by the class and promotes codemodularity and reuse by separating the data model, businesslogic and user interface, but in turn creates more layers tocopy data between.

Figure 1: The review page of the running example

it waits for the new page from the server. Finally, vari-ous aspects of the browser state, including the data of non-submitted form elements, cursor positions, scroll bar posi-tions and the state of JavaScript components will be lostand re-drawn, thus disorienting the user.

For an Ajax page, however, a developer will typically op-timize his code to realize the benefits of Ajax and solve thepure server-side problems listed in the previous paragraph.The same user action (e.g., the review submission) causesthe browser to run an event handling JavaScript functioncollecting data from the page’s components relevant to theaction (i.e. the proposal id, the review text and grades), andsend an asynchronous Xml Http Request (XHR) with a re-sponse handler callback function specified. On the server,the developer implements queries that only compute thechanged data (i.e. the newly inserted review and the av-erage grade of the corresponding proposal), to take advan-tage of more efficient queries, as well as to conserve memoryand bandwidth. While the asynchronous request is beingprocessed, the browser keeps showing the old page insteadof blanking out, and even allows additional user actions andconsequent requests to be issued. When the browser receivesthe response, the response handler uses it to partially updatethe page’s state. The partial update retains non-submittedforms, scroll bar positions, etc, therefore allowing the userto retain his visual anchors on the page.

The page state primarily consists of the browser DOM,which captures the state of HTML form components such astext boxes and radio buttons, and the state of the JavaScriptvariables, which are often parts of third-party JavaScriptcomponents. Therefore, the developer implements the re-sponse handler by writing imperative code that navigatesthe DOM and JavaScript components, and invokes JavaScriptmethods causing the DOM and components to incrementallyrender to the browser.

The Ajax optimizations demand a serious amount of ad-ditional development effort. For one, realizing the benefitsof partial update requires the developer to program custom

logic for each action that partially updates the page, whichwas not the case in pure server-side programming. In par-ticular, in a pure server-side implementation, the developerneeds to write code for the effect of each individual actionon the database, but writes only one piece of code that gen-erates the page according to the database state and sessionstate. For example, suppose that the page of Figure 1 alsoprovides a “Delete” (Review) button. The developer willhave to write two pieces of code that modify the databasewhen “Submit” is clicked and when “Delete” is clicked, re-spectively. The former issues an INSERT or UPDATE com-mand while the latter issues a DELETE. Both of them sharethe same piece of code that generates the page showing thelist of proposals, their reviews and the average grades. Thispiece of code is independent of what user action caused there-generation of the page.

In contrast, in an Ajax application, each user action needsits own code to partially update the page. This piece of codeconsists of server-side code that retrieves a subset of the dataneeded for the page update, and browser-side JavaScriptcode that receives the data and rerenders a sub-region ofthe page. In the running example of Figure 1, a differentpiece of code would be needed for the “Submit” and the“Delete” (Review) buttons.

Such event-driven programming (which also occurs in Flashetc.) is well-known to be both error-prone and laborious[12], since it requires the developer to correctly assess thedata flow dependencies on the page, and write code that cor-rectly transitions the application from one consistent stateto another. Moreover, in a time-sensitive collaborative ap-plication (similar to Google Spreadsheet) where many userswork concurrently, these dependencies may extend beyondthe page of the reviewer who submitted the review, andinto the pages of other reviewers who are viewing the sameproposal on their browsers. For example, if the developerhad issued a query for Average Grade, but not Reviews,the page will display inconsistent data if another review hadbeen concurrently inserted into the database.

Further compounding the custom logic required for eachaction is the amount of imperative code that needs to be im-plemented on the browser. Whereas the developer of a pureserver-side application needs to understand only HTML, thedeveloper of an Ajax application needs to integrate JavaScriptas yet another language, understand the DOM in order toupdate the displayed HTML, and write code that refreshesthe JavaScript components’ state based on the nature ofeach partial update. Since there is no standardization be-tween the component interfaces between different third-partylibraries, the developer is left to manually integrate acrossthese disparate component interfaces.Challenge 3: Distributed computations over bothbrowser-side and server-side state. In response to auser action, the browser sends a HTTP request to the serverand activates a program, which needs access to relevant dataon the page in order to perform computations that involvesuch page data and the database. Writing code that involvesboth page data and server-side data was already mundaneand time consuming in pure server-side applications and be-came even more so in Ajax and Flash.

In a pure server-side application, the browser is essen-tially stateless since all state is lost when the new page isloaded. Using HTML markup such as <input type="text"

name="review" />, the developer declaratively specifies thevalue collected by the textbox will appear as the parameterreview in the HTTP request. The good news about pureserver-side programming is that when a user action causesan HTTP request, the browser is responsible for navigatingthe DOM, and marshalling the request parameters accord-ing to the HTML specification. The bad news is that, onthe server-side, the application first unmarshalls the requestparameters by using Java (or PHP, etc.), and then typicallyissues SQL queries where the request parameters become pa-rameters of an SQL statement. Overall, lines of Java codeare expended in such trivial “extract parameter from therequest, plug it in the query” tasks. With Ajax it gets muchworse, as discussed next, since the marshalling of requestparameters is no longer automatic.

In particular, in an Ajax application the browser main-tains state across HTTP requests. Consequently, the state ofthe web application becomes distributed between the browserand the server. The developer is responsible for defining acustom marshalling format for the XHR request, typicallyin XML or JSON, and for writing imperative code to navi-gate over the DOM and marshall the relevant page data thatmust be sent to the server along with each HTTP request.The usage of JavaScript components (calendars, etc.) onthe page further complicates the issue by requiring customcode that converts between the state of the component andthe marshalling format. On the server-side, the developerwrites custom code to unmarshall the request parameters,and then continues along the usual path, plugging such pa-rameters into SQL statements.

A select few web application frameworks, such as Echo2[7] and Microsoft’s ASP.NET [2], mitigate the issue of dis-tributed application state by automatically maintaining amirror of the browser state on the server. Such synchro-nization can occur efficiently, using reduced bandwidth, byhaving the server send to the browser only the differencebetween the previous page state and the new page state.Yet, mirroring is only a half-solution, since the mirror madeavailable on the server contains the exact and full state of

the browser, despite the fact that each request cares abouta different subset of page data. For example, the submis-sion of a review for the first proposal of Figure 1 requiresthe data collected by the top editor and sliders, while thesubmission of a review for the second proposal requires thedata of the bottom editor and sliders. Furthermore, the mir-rored browser state include visual styling details, which donot matter when form data are collected, yet they troublecollection. For example, to read the values of the three slid-ers Depth, Impact and Overall in Figure 1, using a mirror-based Ajax framework, the developer will need to navigatethrough its ancestor <div> and <table> HTML elementsthat are used purely to specify visual layout. The net effectof these issues is that the developer’s code includes manymundane lines that navigate around the extraneous infor-mation in order to obtain the relevant data for the request.

1.1 FORWARD’s Declarative SolutionThe data management field has recently applied with suc-

cess and great promise declarative data-centric techniquesin network management and games. In a similar fashion,FORWARD adopts an SQL-based, declarative approach toAjax web application implementations, going beyond priorapproaches such as Strudel [8] and WebML [3] that focusedon pure server-side data publishing applications. In par-ticular, FORWARD removes the great amount of Java andJavaScript code, which is written to address the challengesabove, and replaces them with the use of SQL-based lan-guages to facilitate integration and enable automatic opti-mization. The objective is to “make easy things easy anddifficult things possible”.2

FORWARD is a rapid web application development frame-work. The web application’s pages are declaratively speci-fied using page configurations. The programs that run whena request is issued are also declaratively specified, using pro-gram configurations. Both page configurations and programconfigurations are based on a minimally enhanced versionof SQL, called SQL++, which provides access to the unifiedapplication state virtual database that, besides the persis-tent database of the application, includes transient memory-based data (notably session data and the page’s data). Theapplication runs in a continuous program / page cycle: AnHTTP request triggers the FORWARD interpreter to exe-cute a program specification. The program reads and writesthe application’s unified state and possibly invokes servicesthat have side effects beyond the unified application state.(e.g., send an email). The program typically ends by identi-fying which page will be displayed next. FORWARD’s inter-preter creates a new page according to the respective pageconfiguration. The page specification also specifies programsthat are invoked upon specified user events. The invocationof a program restarts the program / page cycle.

The key contributions of FORWARD are:

• The use of SQL++ allows unified access to browserdata and server-side data, including both the databaseand application server main memory (e.g., session). Inconventional web application programming, such ac-cess would require Java and Javascript. FORWARD

2This objective is not followed by today’s web applicationdevelopment frameworks. Paradoxically, powerful Turing-complete low-level imperative languages (such as Java andPHP) accomplish tasks that can be easily accomplished byappropriate SQL-based declarative languages.

eliminates Java and JavaScript from the majority ofweb applications, therefore resolving Challenges 1 and 3,in the same spirit as Hilda [13].

• The page configurations are essentially rendered viewsthat visualize dynamic data generated by SQL++ andare automatically kept up-to-date by FORWARD. Thespecifications enable Ajax pages that feature arbitraryHTML and (pre-packaged) Ajax / JavaScript visualunits (e.g. maps, calendars, tabbed windows), simplyby tagging the data with tags such as <map>, calendar,etc. The AJAX pages are automatically and efficientlyupdated by the FORWARD interpreter by appropri-ately extended use of incremental view maintenance.The FORWARD developer need not worry about coor-dinating data from the server to the page’s Ajax com-ponents, which resolves a “Challenge 2” problem.

• The business logic layer is specified by program config-urations, where business logic decisions and the trans-fer of data between the database and services are ex-pressed in SQL++, or, even simpler, in mappings,which are translated to SQL++. The program config-urations have easy unified access to both the browserdata and the database, because FORWARD guaran-tees that the browser’s page data are correctly reflectedinto the unified application state’s page data beforethey are used by the programs. The automatic reflec-tion resolves Challenge 3.

• The page and program configurations have unified ac-cess to the persisted database, the page and the ses-sion via a single language (SQL++), therefore resolv-ing Challenge 1. JavaScript needs to be written onlyif one needs to create a custom visual unit. Java needsto be written only for computations not easily express-ible in SQL. For example, one can build the entire Mi-crosoft CMT in the SQL++ based page and programconfigurations, except for the reviewer/paper match-ing step, which requires a Java-coded stable matchingalgorithm to assign papers to reviewers according totheir bids.

We argue for the effectiveness of the approach by provid-ing a demo that shows an order of magnitude lines-of-codereduction. Furthermore, Section 5 describes ongoing andfuture work that will further push the advantages of declar-ative computation by automating optimizations.

The FORWARD project was recently licensed by app2youInc, which is a provider of a Do-It-Yourself (DIY) platform[11]. App2you’s DIY platform is being refactored so that itproduces FORWARD code as the user builds pages with theDIY tool. In the meantime, app2you Inc has recently de-ployed earlier versions of FORWARD in three human-centricbusiness process management applications and is currentlyin the process of deploying the presently-described FOR-WARD version in (a) an analytics-oriented large-scale busi-ness intelligence application in the pharmaceutical area, and(b) a business process management application involvinghundreds of pages collecting data via smart forms.

2. RUNNING EXAMPLEThe running example, which is also the accompanying

CIDR demo, is a proposal reviewing Ajax application. The

paper focuses on its review page (see Figure 1), where thereviewers submit reviews that consist of a comment collectedusing a web-based text editor, and depth, impact and over-all grades collected using slider Javascript components. Theeditor appears either in edit mode (e.g. first proposal ofFigure 1) or in display mode (e.g. second proposal). Thepage reports the titles of the proposals as hyperlinks thatlead to the proposals’ pdf, the full set of reviews using aJavascript component with the familar “More” and “Less”buttons, and a bar chart with the average grades.

The full version of the reviewing application is availableonline at demo.forward.ucsd.edu/reviewing, where instruc-tions are provided on how to use it in any of the threeroles it supports (namely, “applicant”, “reviewer”, “chair”).The application’s FORWARD specification is available atdemo.forward.ucsd.edu/reviewing/code. Online instruc-tions on demo.forward.ucsd.edu also teach how to createyour own FORWARD application.

The implementation of the discussed review page required102 lines of FORWARD page specification and the imple-mentation of review submission required 42 lines of FOR-WARD action specification. Building the same required1,642 lines of HTML, Java, Javascript and SQL code in a“quick-and-dirty” Ajax application where the code is com-pact, often against the principles of good MVC coding, whichrequires separation of the control flow part of the code fromthe visual/interactive part of the code. In a disciplinedMVC-based implementation it would take even more.3

3. CREATING AN APPLICATIONA developer creates an application by providing to the

FORWARD interpreter source configurations, schema defi-nitions, page configurations and program configurations.

3.1 Sources, Objects and SchemasThe source configurations dictate the type of the sources

(e.g., relational database, LDAP server, spreadsheet) andhow to connect to them. As a convenience for the devel-opment of cloud-based applications and databases, FOR-WARD implicitly provides to each application an SQL++database source named db. In the running example, db pro-vides the full persistent data storage of the application.

A FORWARD application’s programs and pages also haveaccess to the request, window and session main memory-based sources, which in the spirit of the session-scoped at-tributes provided by application servers, have limited life-times and there may be more than one instances of them atany time. For example, the session source lives for the du-ration of a session. All the pages of a browser session and allthe programs initiated by http requests of the browser ses-sion have access to the same instance of the session source,while pages and actions of other browser sessions have theirown session instances. Similarly the request source livesfor the duration of processing an http request by a program(as discussed in Section 3.2) and each in-progress programhas its own request instance. A window source lives for the

3 Note that current MVC frameworks interact very poorlywith Ajax due to their literal adherence to the program-pagecycle. In light of the MVC frameworks’ mismatch to Ajaxfunctionalities we did not attempt measuring how many linesof Struts or Spring would be required to build the runningexample.

!"#$%&'())*#+,-."'/0,0%'1,++%22#3*%'4#,'/56778'

!"#$%#&'()*+,-,+*+,'

9:.;2%:'/0,0%'<=>6'?@>'

A,4,/+:#)0'B.C)."%"02'

D%:2#20%"0'?,0,3,2%'/0,0%'

/%22#."'/0,0%'

D,E%'B."$EF:,-."'

GH0C*I'''J'''G./)0*1*234+I'''''G.5*6*1.7,'KF%:LMNO89:9;<JPNI'''''''G0:I'''''''''J'''''''''G./)0*132,=>2,*I'''''''''''G.5*6*1.7,'KF%:LMNO89:9;<J'

D:.E:,C'

D:.E:,C'''''''''''''''''''''''''''52?+@,+?0+A'

D:.E:,C'?,0,'

B.:%'?,0,'

Q%KF%20'?,0,'

:%)*,+%'&,0,'

&%R,F*0'L%2'

%::.:' H.C%'

%C,#*'

2%"0'

2F++%22'R,#*F:%'

:%4#%;'

*,20':%4#%;'

Figure 2: The FORWARD interpreter hosts applicationsthat consist of pages and programs

duration of a browser window and becomes available to allpages and programs of such window.

Each source stores one or more objects. Each object has aname, schema and data. The schema may be explicitly cre-ated with the Data Definition Language (DDL) of SQL++or may be imported from the source. For example, theschema of a relational database source is imported from itscatalog tables. The DDL of SQL++ is a minimal extensionof SQL’s DDL.

3.2 Operation: The Program/Page CycleIn the spirit of MVC-based frameworks such as Struts and

Spring, a FORWARD application’s operation is explained byprogram-page cycles. (In that sense FORWARD’s programscorrespond to Struts’ actions.) An http request triggers theinterpreter to run the program configuration that is associ-ated with the request’s URL. The program reads and writesthe application’s unified state (i.e., database, request data,session data) and possibly invokes services that have sideeffects beyond the application’s state (e.g., sends an email).The program’s run typically ends with identifying whichpage p will be displayed next. Conceptually, FORWARD’sintepreter creates a new page according to p’s page configu-ration, which may be thought of as a rendered SQL++ viewdefinition, and displays it on the browser. A displayed pagetypically catches browser events (such as the user clickingon a button, mousing over an area, etc; or a browser-sidetimer leading to polling) that lead to action invocations (viahttp runs) therefore continuing the program-page cycle.

Notice that FORWARD enforces the full separation of theController functionality from the View functionality, whichcurrent MVC frameworks only encourage but do not enforce:The page configurations are literally views, unable to sideeffect the application state.

3.3 The Page ConfigurationA page configuration is an XHTML file with added:

1. FORWARD units, which are specified as XML ele-

ments in the configuration and are rendered as maps,calendars, tabbed windows and other Javascript-basedcomponents. Internally FORWARD units use compo-nents from Yahoo UI, Google Visualization and otherlibraries and wrap them so that they can participatein FORWARD’s pages without any Javascript code re-quired from the developer.

2. SQL-based inlined expressions and for and switch

statements, which are responsible for dynamic datageneration.

Figure 3 provides the page configuration of the review

page. Figure 3 excludes a few parts, which are marked by<!-- in demo --> and can be found on the online demo.The complete page configuration’s size is 102 lines.

Lines 2-6 of the page configuration list the HTML thatgenerates the top of the page and contains the FORWARDunit funit:table.4 Notice that a unit may contain otherunits; e.g., the funit:table (line 6) contains the funit:bar chart

(line 19), the funit:editor (line 33) and the funit:slider

(line 55). A unit may also contain XHTML, which may, inturn, contain other units.

A fstmt:for statement evaluates its query and for eachtuple in the result (conceptually) outputs an instance of itsbody configuration, i.e., of the XHTML within the openingand closing fstmt:for tags. For example, the fstmt:for

on line 11 outputs for each proposal one instance of the tr

element on line 15 and its content.The syntax and semantics of the fstmt:for and fstmt:switch

statements are deliberately similar to the forEach and choose

core tags of the popular JSP Standard Tag Library (JSTL)[10]. The same applies for FORWARD expressions andJSTL expressions. However, FORWARD’s fstmt:for iter-ates directly over a query, whereas JSTL’s forEach iteratesover vectors generated by the Java layer, which are in turnproduced by iterating over query results. Besides the obvi-ous code reduction resulting from removing the Java mid-dleware, we will see many more important benefits that aredelivered because FORWARD analyzes the queries behindthe dynamic data of the page.

FORWARD’s page configurations enable nested, corre-lated structures on the pages. In particular, the query ofa fstmt:for statement found within the body configura-tion of an enclosing fstmt:for may use attributes from theoutput of the query of the enclosing fstmt:for. For exam-ple, the table reviews has a foreign key proposal. For each“proposal” instance the correlated query on line 20 producesa tuple with the average grades of its reviews by using theproposal id attribute of its enclosing query. Furthermore,the page configurations allow variability (e.g., the currentuser’s review appears either in edit mode or in display mode)utilizing the fstmt:switch statement (line 34).

Expressions, which are enclosed in { }, can reference at-tributes of the query’s output. Furthermore, an expressionmay be itself a query. In the interest of flexibility, which hasbeen the norm in tools and languages for web page creation,5

FORWARD coerces the types produced by the expressionsto the types required by the FORWARD units or XHTML,

4Its syntax is identical to the standard HTML table but,unlike the HTML table, it aligns the columns of its nestedtables.5For example, JSP pages convert JSP expressions intostrings whenever possible.

!  "#$%&'()*+,-./0!120').3-4,.5/06789:0#;'<  "=>%&'$%&.+?@A.,>/0=BC?DD@-*EF*41A3+41)4ADA.,>+0'G  '''''''''''$%&.+?@+>%>/0=BC?DD@-*EF*41A3+41)4AD+>F>)%).>+0;'H  ''''"I99',.'4)%-?'=>%&'@-*'3++J',%F5)+J'=)F4)*+J'@-->)*+99;''K  ''''L)&&-'M!"!!#$%&'!"(NI'O  ''''")'%#*+*,-.";'P  ''''''''">=;'"I99'>FQ&)'=)F4)*+'99;':  ''''''''''''">4;7,>&)"D>4;'R  ''''''''''''"I99',.'4)%-?'*)+>'-@'>=)'=)F4)*+'99;'!2  ''''''''"D>=;'!!  ''''''''")!*/*+)$('.F%)/0C*-C-+F&+0'!<  '''''''''''''''''''''''''''SA)*T/0M0121345#657058($8$!,.9#6:5;*.":586)9.#%<5!G  '''''''''''''''''''''''''''''''''''''''''''=>?@56-&8($8$!,.!5!H  '''''''''''''''''''''''''''''''''''''''''''?>A1>5BC58($8$!,.9#6N0;'!K  ''''''''''''">*;'!O  ''''''''''''''''">4;"F'=*)@/0M86)9.#%<N0;M;*."N"DF;"D>4;'!P  ''''''''''''''''"I99',.'4)%-?'3-%%).>+'F.4'*)(,)E)*+'99;'!:  ''''''''''''''''">4;'"I99'QF*'3=F*>'+=-E,.5'F()*F5)'5*F4)+'99;'!R  ''''''''''''''''''''")'%#*+-,(9DE,(*;'<2  ''''''''''''''''''''''''")!*/*+)$('SA)*T/0M01213457FGH6"8*EI5705,JK96"8*E:5<!  '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''7FGH#/8,D*I5705,JK9#/8,D*:5<<  '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''7FGH$J"(,..I5705,JK9$J"(,..5<G  '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''=>?@56-&("J#"L!55<H  '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''MN1>158($8$!,.5O58($8$!,.9#6NU;'<K  ''<O  ''''''''''''''''''''''''''''"QF*'QF*V(F&A)/0M,JK96"8*EN0'3-&-*/0*)40D;'<P  ''''''''''''''''''''''''''''"QF*'QF*V(F&A)/0M,JK9#/8,D*N0'3-&-*/0Q&A)0D;'<:  ''''''''''''''''''''''''''''"QF*'QF*V(F&A)/0M,JK9$J"(,..N'0'3-&-*/05*)).0D;'<R  ''''''''''''''''''''''''"D@+>%>?@-*;'G2  ''''''''''''''''''''"D@A.,>?QF*V3=F*>;'G!  ''''''''''''''''"D>4;'G<  ''''''''''''''''">4;'GG  ''''''''''''''''''''")'%#*+"6#*$('.F%)/0%TV*)(,)E0;'GH  ''''''''''''''''''''''''")!*/*+!L#*DE;'GK  ''''''''''''''''''''''''''''")!*/*+D,!"'3-.4,W-./0M1PQ0405H5GO  ''''''''''''''''''''''''''''''''''''0121345R5=>?@56-&("J#"L!5GP  ''''''''''''''''''''''''''''''''''''MN1>15("J#"L"(5O5!"!!#$%&'!"(5G:  ''''''''''''''''''''''''''''''''''''7SA58($8$!,.5O58($8$!,.9#6INU;'GR  ''''''''''''''''''''''''''''''''">)$>;M0121345D$//"%*5=>?@56-&("J#"L!5H2  '''''''''''''''''''''''''''''''''''''''''''''MN1>15("J#"L"(5O5!"!!#$%&'!"(5H!  '''''''''''''''''''''''''''''''''''''''''''''7SA58($8$!,.5O58($8$!,.9#6N"D>)$>;'H<  ''''''''''''''''''''''''''''''''"+>F>);4,+C&FT"D+>F>);'HG  ''''''''''''''''''''''''''''"D@+>%>?3F+);'HH  ''''''''''''''''''''''''''''")!*/*+".!";'HK  ''''''''''''''''''''''''''''''''">)$>;7TC)'T-A*'3-%%).>'=)*)"D>)$>;'HO  ''''''''''''''''''''''''''''''''"+>F>);)4,>"D+>F>);'HP  ''''''''''''''''''''''''''''"D@+>%>?)&+);'H:  ''''''''''''''''''''''''"D@+>%>?+E,>3=;'HR  ''''''''''''''''''''"D@A.,>?)4,>-*;'K2  ''''''''''''''''"D>4;'K!  ''''''''''''''''">4;'"I99'+&,4)*+'99;'K<  ''''''''''''''''''''")'%#*+*,-.";'KG  ''''''''''''''''''''''''">*;'KH  ''''''''''''''''''''''''''''">4;'KK  ''''''''''''''''''''''''''''''''")'%#*+!.#6"('%,./0!0'%F$/0K0'.F%)/04)C>=0'KO  '''''''''''''''''''''''''''''''''''''''''''''''''''''''(F&A)/0M01213456"8*E5=>?@56-&("J#"L!5KP  ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''MN1>15("J#"L"(5O5!"!!#$%&'!"(5K:  ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''7SA58($8$!,.5O58($8$!,.9#6N0D;'KR  ''''''''''''''''''''''''''''"D>4;'O2  ''''''''''''''''''''''''"D>*;'O!  ''''''''''''''''''''''''"I99',.'4)%-?'+&,4)*+'@-*',%CF3>'F.4'-()*F&&'5*F4)+'!'O<  ''''''''''''''''''''''''")'%#*+-'T$%'-.3&,3X/0+F()V*)(,)E0;YAQ%,>"D@A.,>?QAB-.;'OG  "I99',.'4)%-?'+)()*F&'3&-+,.5'>F5+'99;'

Figure 3: The page configuration of review

depending on where the expression appears. Therefore, thedeveloper need not worry about fine discrepancies betweenthe types used in the database (which are dictated by thebusiness logic and are often constrained) and the types usedfor rendering, which are often as general as they can be.For example, the expression that feeds the value attribute

of the funit:slider on line 56 is a tuple that has a singleinteger attribute. However, it is coerced into a float, whichis the type of argument that the funit:slider expects.The page as an automatically updated rendered viewConceptually, the page configuration is evaluated after ev-ery program execution. While such an explanation is simpleto understand, it is only conceptual. If the page that is dis-played on the browser window before and after a program’sexecution is the same, then FORWARD will incrementallyupdate only the parts of it that changed, therefore achiev-ing the user-friendliness and efficient performance of Ajaxpages, where the page does not leave the user’s screen (andtherefore avoids the annoying blanking out while waitingfor the page to reload) but rather incrementally re-rendersin response to changes. [9] explains how FORWARD utilizesincremental view maintenance in order to efficiently and au-tomatically achieve pages as incrementally rendered views.To XQuery or not to XQuery The page configurationsyntax and semantics of FORWARD closely resemble thoseof XQuery, as they both enable nesting, order, variabil-ity and coercions. Indeed, FORWARD allows similarity toXQuery to become even more obvious by allowing omissionof the SELECT clause of the queries, which is tantamountto an automatic SELECT *. We have chosen SQL for threereasons:

1. The typical query input is the application’s database,which is almost always relational and therefore we donot need to complicate the query language semanticswith conventions on how the relational database iswrapped into XML. In that sense, the page configu-ration language is close to the SQL/XML relationalinput and XML output approach.

2. A main audience of our approach are SQL developerswho feel frustrated by how hard it is to create a ren-dered view. There is no significant number of XQueryWeb developers yet.

3. Numerous processing, optimization and consistency check-ing algorithms around the page configuration are amenableto cleaner reductions to respective SQL problems, with-out subtle complications that XQuery’s semantics in-troduce.

Nevertheless, a limited XQuery implementation is also inthe plans, as XQuery provides high power in certain cases,such as XQuery-Text.Summary The page configuration is essentially an SQLview embedded into a visual template, consisting of HTMLand funit tags. Therefore the page configuration resolvesChallenge 1, since it enables the production of pages with-out requiring Java and javascript code in addition to SQL.Furthermore, it is implemented as an Ajax page that is au-tomatically updated to reflect the database state, thereforeresolving Challenge 2 of Ajax application programming.

3.4 Unified Application StateThe FORWARD unified application state, in addition to

the conventional persistent data that an application has, alsoincludes transient application data, such as an automatically-created logical-level representation of page data, which areheavily used in web application programming.

Structurally, the unified application state consists of theset of all sources, such as the session, db and core, which

are described by an SQL++ schema. In order to accom-modate the needs of pages, of session data and of otherdata typically occurring in web application programming,SQL++ is a minimal extension of SQL, whereas each schemais a tuple. An attribute of the tuple may be either a scalartype or a table, whose tuples have attributes that may re-cursively contain nested tables. Notice that standard SQLcorresponds to the case where a schema is simply a tuple oftables (think of SQL’s table names as being the attributenames of the top level tuple) and each table’s tuples mayonly have scalars (as opposed to nested tables). In order toallow variability in the spirit of XQuery and OQL, SQL++also supports an OQL-like union construct.

An example of a schema that uses the extra features ofSQL++ is the session, which in the running example is sim-ply a tuple containing only the standard scalar attributessession id, user and role that are set by FORWARD’ssession management and authentication/authorization util-ities (not shown). The expression {session.user} on line 5is a SQL++ query accessing the attribute user of the tupleof the session schema. A key integration contribution ofFORWARD, which attacks Challenges 1 and 3, is the abilityof SQL++ to combine persistent data with transient datausing just a single SQL++ query. For example, consider thequeries on lines 36 and 39 that combine the session.user

with the table reviews of the persistent schema db to pro-duce the reviews of the currently logged-in user in just threelines of SQL. More integration contributions are made by thecore schema and data, discussed next.

The core schema captures in an SQL++ schema the subsetof page data that have been named by the developer, usingthe special tag name, in the page configuration. Thereforethe core enables the developer to resolve part of Challenge 3,by enabling him to create a data structure encompassingthe data of interest to the programs as opposed to, say, vi-sual details. FORWARD infers the core schema by inspec-tion of the page configuration. In the running example, thecore schema, which happens to fall within standard SQL,is a table of the proposals that appear on the screen alongwith their reviews and grades. In particular, it is a tablenamed proposals (due to the fstmt:for on line 11) with astring attribute named my review (due to line 33) and floatattributes depth, impact and overall due to the sliders(the last two not shown in Figure 3). The table proposals

also has the key attribute proposal id so that one can as-sociate the data collected by the multiple instances of theeditor and the sliders with proposals. Mechanically, FOR-WARD infers this attribute to be the key of the query thatfeeds proposals using a straightforward key inference algo-rithm. Notice that such inference relies on the underlyingdb.proposals table having a known key, which is an un-avoidable assumption of the running example, no matterwhat technologies one uses to implement it.

Notice that the algorithm that infers the core schema uti-lizes statements and queries of the page configuration, i.e.the page’s logical aspects, while it mostly ignores the unitstructure and XHTML (the visual aspects). The only unitaspect that matters is the types of data collected by theuser, i.e., string from the funit:editor and floats from thefunit:sliders. This is a key advantage over page mirror-based frameworks, such as Microsoft’s ASP.NET, that of-fer to the developer a server-side mirror of the page data,so that the developer does not have to code in Javascript.

Unfortunately, the structure of the mirror follows the (typ-ically very busy) visual structure of the page, as opposedto the data structure that best fits the database (a typi-cal “Challenge 3” problem). In the running example, hadwe followed ASP.NET’s approach, instead of having threeattributes names named depth, impact and overall, cor-responding to the three sliders, we would have a hard-to-use nested table whose first tuple would be implicitly as-sumed to contain the depth, its second tuple to contain theimpact, etc. The fact that FORWARD’s page configurationenables extracting the core data is testimony of the powerof a declarative approach fueled by logical statements andqueries.

An important piece of data in the core is informationabout which program was invoked. In the running exam-ple, the page invokes the program save review (line 62),and therefore it is important to know upon invocation whichone of the many instances of the save review was invoked.There are as many instances as proposals on the page. Thecore identifies the proposal id for the invoked save review.

FORWARD guarantees that the core data is automati-cally up-to-date when a program starts its execution. Thisis a key contribution towards resolving Challenge 3. In aconventional Ajax application, Javascript and Java code hasto be written to establish a copy of relevant page data onthe server, in a way that they can be subsequently combinedwith the database.

The name attribute convention is reminiscent of the HTMLstandard’s convention to allow a name to be associated witheach form element and consequently generate request pa-rameters with the provided names. Drawing further thesimilarities to HTML’s request parameters, the request ob-jects keep only the tuple of the core that correspond to theinvoked program.

Mappings (Section 3.5) raise the level of programmingeven higher by allowing the developer to select, project andcombine data utilizing a mapping interface.

3.5 The Program ConfigurationA program configuration is a composition of synchronous

services in an acyclic structure with a single starting ser-vice, which is where the program’s execution starts. Forexample, Figure 2 shows the graphical representation of thesave review program configuration, which is composing ser-vices replace data and email, among others.

Services input data from the unified application state. Forexample, the starting service replace data takes as inputdata indicated by the mapping of Figure 4. The invocationof a service has one or more possible outcomes, and each out-come (1) generates a corresponding service output, whichbecomes part of the unified application state, and (2) leadsto the invocation of a consequent service or the end of theprogram. The replace data service has a success outcomeand a failure one. The former adds the replaced tuple

to the unified application state and the latter adds a failuremessage in order to facilitate the invocation of the conse-quent email service, which will email the failure message tothe application administrator.

FORWARD offers a special service called page (depictedby the page icon in Figure 2) that programs use to instructthe FORWARD interpreter of which page to display next.

The transactional semantics of services differentiate theones that have side effects from the ones that do not. A

!"#$%&'()"*(

"++,+( -,."(

".$/&(

*"0'(

*%11"**(#$/&%+"(

+"2/"3(

&$*'(+"2/"3(

40/5"!(677&/1$8,0(9'$'"(:$11"**/;&"(2/$(9<=>>($0!(?$77/0@*A(

!"#

$%$$&'(#

)*'+*,-#

.'*%#

*%/0%$1#

7+,7,*$&(

+"2/"3"+(

B(

*%2&%3$#

7+,7,*$&C/!(

8'&"(

B(

.)C+"2/"3(

!"7'-(

B(

)*')'$,4$#

%*"+(

B(

+"7&$1"(!$'$(

*1-".$C7$'-(

7+,7,*$&(

1,.."0'(

+"2/"3"+(

B(

&()01#

7+,7,*$&(

B(

$0..%$$#

."**$@"(5,&40*%#

B(

Figure 4: Building the save review program configuration

service has side effects if it makes changes observable by theoutside world, be it by updating the unified application stateor by invoking an external service, such as sending an emailor charging a credit card. The replace data and email areexamples of services having side effects and are graphicallydepicted by a rectangle in Figure 2. A service with no sideeffects is depicted by a rhombus and merely chooses whatservice will be invoked next. For example, if the outcome ofreplace data is success, then the program will invoke thelast review service, which simply checks if the review justsaved was the last one to be submitted, and hence does nothave any side effects. If so, another page service will set thenext page to be the home page of the application. Otherwise,the next page will be the same as the current review page.

Building a program configuration is greatly simplified bySQL++ access to the unified application state. It is furthersimplified bythe FORWARD mapping language. In princi-ple, the service input data can be generated by a SQL++query. In practice though, the developer rarely does so sincethe input data of services can be specified much easier usingmappings. Figure 4 demonstrates how mappings are visuallydesigned inside FORWARD’s development environment be-tween the unified application state and the input schema ofthe replace data service. Notice that the developer seam-lessly draws mappings from the persistent database state db,the request data and the session data to the input schemaof the service. For consequent services, the developer is alsoable to draw mappings from the program data generated byprevious services invocations.

3.6 The Scope of FORWARD ApplicationsThe SQL++ based program and page configurations have

limitations, when compared against programs and pageswritten using combinations of Java, Javascript and SQL. We

argue that these limitations are within the spirit of “makeeasy things easy and difficult things possible”: Still everyapplication is doable, while common applications are mucheasier to write.

In the case of programs, notice that a program is an acyclicgraph.Therefore programs comprise (1) sequencing of ser-vices, most of which are plain SQL statements, and (2)if-then-else control. However, programs lack explicit loopstructures. The restriction is much less severe than it ini-tially appears to be because there are implicit loops in theservice implementations. For example, the email service ofthe example sends an email to each of the many recipients.Nevertheless, the limitation raises three key questions:

First, what percentage of applications do not require ex-plicit loops? Database theorists had introduced the rela-tional transducer [1], which described the program executedafter a user interaction by a plain sequence of SQL com-mands, and essentially conjectured that the business processof most web applications is describable within the expres-sive power of SQL (notably without recursion). Later, theWAVE project showed that this conjecture applies to well-known web applications, such as dell.com [5]. The authorshave collected an interesting piece of evidence pointing inthe same direction: Two of the authors have given a webapplication development class, at SUNY Buffalo and UCSDrespectively, asking students to specify and build a web ap-plication of their choice as a class project. The vast majorityof student applications avoid the limitation. For example,in the Winter 2010 UCSD offering of the class, all studentprojects avoided the limitation.

The next question is how can the limitation be overcomewhen explicit loops are truly needed in a program? In suchcases the developer may write a service in Java and enjoythe full power of Java. Indeed, the developer may write thewhole program in Java.

Finally, what are the benefits of the no-loops limitation?The lack of explicit loops simplifies the semantics of ser-vice compositions to the point that a program is simplyplugging together services via mapping a service’s outputto other services’ input. The practical failure of prior visualprogramming tools and business process languages that at-tempted to capture the full extent of programming makesus believe that visual programming should be limited to thesimple cases, while Java provides the “bail-out”.

4. INTERNAL ARCHITECTUREThe internal architecture of the FORWARD interpreter

is illustrated in Figure 5, which displays internal modules(labelled with red numbers) in association with developer-visible concepts of Figure 2. For efficiency of storage andcommunications, FORWARD maintains a visual page state,which provides an abstraction over the browser state by in-cluding the externally visible state of visual units, but ex-cluding their implementation details. Two copies of the vi-sual page state lazily mirrored between the browser and theserver.

When the user performs interactions such as typing in atext box, the HTML DOM and the JavaScript variables ofvisual components change in the browser state. The respec-tive state collectors of each FORWARD unit synchronize theappropriate part of the browser state with the correspond-ing part of the browser-side visual page state. When theuser eventually triggers an event that leads to invoking a

!"#$%&'())*#+,-."'/0,0%'1,++%22#3*%'4#,'/56778'

/%94%9:/#&%'

;#2<,*'=,>%'/0,0%'

!"#$%#&'()*+,-,+*+,' =9.>9,?'

@9.A2%9'/0,0%'

=,>%'B."$><9,-."'

CDE6'FGE'

H,4,/+9#)0'B.?)."%"02'

/0,0%'B.**%+0.92'.'

=9.>9,?'I"4.J%9'/'

I"+9%?%"0,*'K%"&%9%92'

0'

@9.A2%9:/#&%'

;#2<,*'=,>%'/0,0%'

=%92#20%"0'F,0,3,2%'/0,0%'

/%22#."'/0,0%'

B.9%'F,0,'

K%L<%20'F,0,'

E.&#$+,-."'6.>'1'

I"+9%?%"0,*';#%A'E,#"0%","+%'

2'

3'

3'

Figure 5: Internal FORWARD Architecture

program, such as clicking the submit button of Figure 1,the program invoker guarantees that the browser-side vi-sual page state has been fully mirrored onto the server-sidebefore the program executes. This guarantee is efficientlyimplemented via incremental writes to the prior visual pagestate.

Using the program invocation context and page configu-ration, the interpreter calculates (1) the core data, by pro-jecting only the named attributes of the visual page state,and (2) the request data. As services within the programread from and write to the unified application state, the sys-tem also uses a modification log to intercept all changes tothe unified application state. By using the modification login combination with the unified application state, the inter-preter employs incremental view maintenance optimizationsto incrementally maintain the current visual page state tothe next visual page state [9]. The current implementationuses an off-the-shelf relational database without modifica-tion to the database engine. It intercepts changes by instru-menting database-related services. By storing the modifica-tion log as well as transient parts of the unified applicationstate in memory-resident tables of the RDBMS, the currentimplementation issues incremental queries that are more ef-ficient than the original queries in the page configuration,since they retrieve data primarily from the memory-residenttables. As illustrated in [9], incremental view maintenancecan speed up the evaluation of page queries by more thanan order of magnitude.

Finally, the interpreter uses data diffs to efficiently reflectchanges back to the browser-side visual page state. Thesame data diffs are also provided to the respective incremen-tal renderers of each visual unit, which, in turn, program-matically translates the data diff of the visual page state intoupdates of the underlying DOM elements or method calls ofthe underlying JavaScript components. Essentially, the in-cremental renderers modularize and encapsulate the partialupdate logic necessary to utilize Javascript components, so

that developers do not have to provide such custom logic foreach page. Also illustrated in [9], in addition to performancegains due to less DOM elements / JavaScript componentsbeing initialized, incremental rendering also delivers a betteruser experience by reducing flicker and preserving unsavedbrowser state such as focus and scroll positions.

To convert between the different schemas of the core dataand the visual page state, the compilation of the page con-figuration automatically produces a mapping between thesetwo schemas. For example, as discussed in Section 3.2, thecore data comprises three (flat) attributes depth, impact

and overall, whereas the visual page state represents thecorresponding sliders nested within a table unit, thus themapping language mitigates such structural differences in-cluding extraneous attributes (by projection) and nested tu-ples (by flattening). Mappings are also used to produce typecoercions, such as automatically converting an integer at-tribute in the core data to a float attribute in the visualpage state, and vice versa.

5. FUTURE WORK ON OPTIMIZATIONSAs the history of SQL-based systems has shown, a key

benefit of declarative approaches is the enablement of (i)automatic optimizations and (ii) static analysis that canimprove the operation of the system or detect possible er-roneous behaviors. As discussed in Section 4, the efficientincremental maintenance of the Ajax pages is a derivative ofthe declarative SQL-based approach. FORWARD ongoingand future work will extend the benefits of the declarativeapproach towards the following optimizations and function-alities, which would otherwise require programmer effortsto be accomplished. Notice that the declarative approachreduces each of the following problems into an extension orspecialization of respective problems where the data man-agement community has delivered automatic optimizationtechniques.Page query optimization The obvious (according to thesemantics) way to collect the data needed by a page config-uration is not necessarily the most efficient. For example,the data needed for the page of the running example can becollected by running the outer query of Lines 12-14, whichreturns proposals, and then, for every proposal tuple, in-stantiate the proposal id and run the query of Lines 20to 24, which returns their grades. A more efficient way tocollect proposals and grades is by sending a single query.Research in OQL and XQuery has ran into similar issuesand has provided a list of rewritings that can be employedfor performance gains in such situations.Pub-sub optimizations for updating myriads of openpages Consider a popular application where there are myr-iads of pages open at any point in time. When the databasedata change, these pages have to be correspondingly up-dated. For example, when a Facebook user changes his sta-tus, the currently open pages of his friends must be updated.FORWARD’s reduction of the data reported by a page intoessentially a rendered view, opens the gate to leveragingdatabase work (e.g., [4, 6]) for the rapid update of only therelevant open pages.Location transparency, browser side operation andmobility The SQL++ queries over the unified applicationstate are location transparent in the sense that they donot dictate whether they are executed fully at the serveror whether they are executed partially at the server and

partially at the browser. While the current version of FOR-WARD mirrors the browser data on the server and runsSQL++ fully on the server, alternate methods are also pos-sible. A possibility that is beneficial to mobile applicationsis to create caches of the parts of the application state onthe browser. Then certain queries and programs will be ableto operate on a disconnected browser.

6. ACKNOWLEDGEMENTSWe thank Kevin Zhao for his worthy-of-authorship contri-

butions. Kevin does not appear in the author list since he isthe author of another CIDR 2011 paper. We thank FernandoGutierrez, Ryan Mourey, Sam Wood and Erick Zamora forthe contribution of multiple FORWARD units. We thankAlin Deutsch for many discussions on FORWARD.

7. REFERENCES[1] S. Abiteboul, V. Vianu, B. Fordham, and Y. Yesha.

Relational transducers for electronic commerce. InPODS ’98: Proceedings of the seventeenth ACMSIGACT-SIGMOD-SIGART symposium on Principlesof database systems, pages 179–187, New York, NY,USA, 1998. ACM.

[2] Asp.net, 2009. http://www.asp.net/.

[3] S. Ceri, P. Fraternali, and A. Bongio. Web modelinglanguage (webml): a modeling language for designingweb sites. Computer Networks, 33(1-6):137–157, 2000.

[4] J. Chen, D. J. DeWitt, F. Tian, and Y. Wang.Niagaracq: A scalable continuous query system forinternet databases. In SIGMOD Conference, pages379–390, 2000.

[5] A. Deutsch, M. Marcus, L. Sui, V. Vianu, andD. Zhou. A verifier for interactive, data-driven webapplications. In SIGMOD Conference, pages 539–550,2005.

[6] Y. Diao and M. J. Franklin. Query processing forhigh-volume xml message brokering. In VLDB, pages261–272, 2003.

[7] Echo web framework, 2009.http://echo.nextapp.com/site/.

[8] M. F. Fernandez, D. Florescu, A. Y. Levy, andD. Suciu. Declarative specification of web sites withstrudel. VLDB J., 9(1):38–55, 2000.

[9] Y. Fu, K. Kowalczykowski, K. W. Ong, K. K. Zhao,and Y. Papakonstantinou. Ajax-based report pages asincrementally rendered views. In SIGMOD Conference(to appear), 2010.

[10] Javaserver pages standard tag library, 2010.http://java.sun.com/products/jsp/jstl/.

[11] K. Kowalczykowski, K. W. Ong, K. K. Zhao,A. Deutsch, Y. Papakonstantinou, andM. Petropoulos. Do-it-yourself custom forms-drivenworkflow applications. In CIDR, 2009.

[12] S. Miro. Who moved my state? Dr. Dobb’s, 2003.

[13] F. Yang, J. Shanmugasundaram, M. Riedewald, andJ. Gehrke. Hilda: A high-level language fordata-drivenweb applications. In ICDE, page 32, 2006.