Multitier Programming

Multitier programming (or tierless programming) is a programming paradigm for distributed software, which typically follows a multitier architecture, physically separating different functional aspects of the software into different ''tiers'' (e.g., the client, the server and the database in a Web application). Multitier programming allows functionalities that span multiple of such tiers to be developed in a single compilation unit using a single programming language. Without multitier programming, tiers are developed using different languages, e.g., JavaScript for the Web client, PHP for the Web server and SQL for the database. Multitier programming is often integrated into general-purpose languages by extending them with support for distribution.

Concepts from multitier programming were pioneered by the Hop and Links languages
and have found industrial adoption in solutions such as Ocsigen, Opa,Rajchenbach-Teller, D., & Sinot, Franois-Régis. (2010). Opa: Language support for a sane, safe and secure web. ''Proceedings of the OWASP AppSec Research'', ''2010''(1). WebSharper, Meteor or GWT.

Multitier programming provides a ''global view'' on the distributed system. This aspect has been shown similar to other programming paradigms such as choreographic programming, macroprogramming, and aggregate computing.

Context

The code of the different tiers can be executed in a distributed manner on different networked computers. For instance, in a three-tier architecture, a system is divided into three main layers – typically the presentation, business, and data tiers. This approach has the benefit that by dividing a system into layers, the functionality implemented in one of the layers can be changed independently of the other layers. On the other hand, this architectural decision scatters a cross-cutting functionality belonging to several tiers over several compilation units.

In multitier programming, the different tiers are implemented using a single programming language. Different compilation backends take into account the destination tier (e.g., Java for a server and JavaScript for a web browser). Consequently, a functionality that is spread over tiers can be implemented in a single compilation unit of a multitier program.

Example

At their core, multitier languages allow developers to define for different pieces of code the tiers to which the code belongs. The language features that enable this definition are quite diverse between different multitier languages, ranging from staging to annotations to types. The following example shows an Echo client–server application that illustrates different approaches. In the example, the client sends a message to the server and the server returns the same message to the client, where it is appended to a list of received messages.

Echo application in Hop.js

service echo()

var wss = new WebSocketServer("ws")
wss.onconnection = function(event)

Hop uses staging to embed code that is to be run on the client into a server-side program: Using the ~ notation, the code for the onload (Line 4) and onclick (Line 10) handlers is not immediately executed but the server generates the code for later execution on the client. On the other hand, the $ notation escapes one level of program generation. The expressions hop.port (Line 5), event.data (Line 6) and input (Line 9 and 10) are evaluated by the outer server program and the values to which they evaluate are injected into the generated client program. Hop supports full stage programming, i.e., ~ expressions can be arbitrarily nested such that not only server-side programs can generate client-side programs but also client-side programs are able to generate other client-side programs.

HTML can be embedded directly in Hop code. HTML generated on the server (Line 2–14) is passed to the client. HTML generated on the client can be added to the page using the standard DOM API (Line 6). Hop supports bidirectional communication between a running server and a running client instance through its standard library. The client connects to the WebSocket server through the standard HTML5 API (Line 5) and sends the current input value (Line 10). The server opens a WebSocket server (Line 17) that returns the value back to the client (Line 20). So-called services, which are executed on the server and produce a value that is returned to the client that invoked the service. For example, the echo service (Line 1) produces the HTML page served to the web client of the Echo application. Thus, the code in a service block is executed on the server.

Echo application in Links

fun echo(item) server

fun main() server

main()

Links uses annotations on functions to specify whether they run on the client or on the server (Line 1 and 5). Upon request from the client, the server executes the main function (Line 18), which constructs the code that is sent to the client. Links allows embedding XML code (Line 7–15). XML attributes with the l: prefix are treated specially. The l:name attribute (Line 10) declares an identifier to which the value of the input field is bound. The identifier can be used elsewhere (Line 9). The code to be executed for the l:onsubmit handler (Line 9) is not immediately executed but compiled to JavaScript for client-side execution. Curly braces indicate Links code embedded into XML. The l:onsubmit handler sends the current input value item to the server by calling echo. The item is returned by the server and appended to the list of received items using standard DOM APIs. The call to the server (Line 9) does not block the client. Instead, the continuation on the client is invoked when the result of the call is available. Client–server interaction is based on resumption passing style: Using continuation passing style transformation and defunctionalization, remote calls are implemented by passing the name of a function for the continuation and the data needed to continue the computation.

Echo application in ScalaLoci

@multitier object Application

ScalaLoci is a language that targets generic distributed systems rather than the Web only, i.e., it is not restricted to a client–server architecture. To this end, ScalaLoci supports peer types to encode the different tiers at the type level. Placement types are used to assign locations to data and computations. ScalaLoci supports multitier reactives – language abstractions for reactive programming that are placed on specific locations – for composing data flows cross different peers.

The application first defines an input field (Line 11) using the ScalaTags library. The value of this field is used in the click event handler of a button (Line 15) to fire the message event with the current value of the input field. The value is then propagated to the server (Line 6) and back to the client (Line 9). On the client, the value of the event are accumulated using the list function and mapped to an HTML list (Line 10). This list is then used in the HTML (Line 16) to display the previous inputs.

List of multitier programming languages

* Hop/Hop.js
* Links
*Ur/Web
*Eliom/Ocsigen
*ScalaLoci
*StiP.js
*Scala Multi-Tier FRP
*OpaRajchenbach-Teller, D., & Sinot, Franois-Régis. (2010). Opa: Language support for a sane, safe and secure web. ''Proceedings of the OWASP AppSec Research'', ''2010''(1).
*AmbientTalk/R
*ML5
*WebSharper
*Haste
*Fun
*Koka
*Multi-Tier Calculus
*Swift
*Volta
*GWT
*Meteor
*J-Orchestra
*Hiphop
*Distributed Orc
*Jif/split
*Fission
*SIF
*WebDSL
*Acute
*Mobl
*High-Level Abstractions for Web Programming

References

{{Programming paradigms navbox

Programming paradigms