CSC/ECE 517 Fall 2014/ch1a 1 sj

Play Framework is a high velocity web development framework for Java and Scala. It uses the Model-view-controller (MVC) architectural pattern for implementing user interfaces. Play is based on a lightweight, stateless and web-friendly architectue written in Scala. The prmary goal of Play framework is to provide a developer friendly development platform for web development.

The major advantage of Play over other Java EE frameworks is its ability to build highly scalable applications. Its reactive model (Reactive Manifesto), thanks to Iteratee IO provides nominal consumption of resources (CPU cores, memory), a major requirement for ascendable and asynchronous applications.

Some of the major names using Play framework are LinkedIn, Klout, TheGuardian, ZapTravel and GILT

Motivation

• To create a stateless web framework – Traditional web frameworks are stateful and because of this scalability becomes an issue after a while. The creators of the Play framework found that stateless frameworks are more stable when there is higher traffic since no overhead is incurred in tracking and maintaining user state information.

• To have an ‘evented’ web server architecture as opposed to a ‘threaded’ web server architecture – Since the Play framework is essentially stateless, an event driven web server architecture was more appropriate to base Play on than modelling it as threaded. Therefore, it was decided to base play on Netty – an event-driven client-server framework.

• To provide full-stack web framework – The creators of the framework wanted to provide developers with a single complete framework that was capable of model-persistence and which had template (view), controller and testing mechanisms. In Play, model and controller can be realized with Java and Scala, views are realized with a template syntax and Scala and model persistence is done with Ebean by default with the option to use any other persistence mechanism. JUnit, Selenium WebDriver and FluentLenium are mainly used as the testing tools for Play.

• To provide a developer friendly feature driven framework – One of the primary motivations of the Play framework was to make development as easy as possible for the developer. To do this features such as hot reload (mimicking interpreted languages), integration to JSON and integration of compilers for CoffeeScript, LESS etc. were provided. Development on Ruby on Rails and Django is fairly simple and the creators of Play wanted to mimick this and hence modelled Play on these frameworks. Play is also fully compiled, typesafe, RESTful by default and provides support for long living connections(WebSocket, Commet etc).

Features of Play Framework

• As mentioned before, Play is a stateless, light weight framework which is very flexible. The MVC architecture inherently provides flexibility but along with this there are many elements in Play which are pluggable, configurable or customizable.

• Play makes use of Akka which supports multiple programming models for message based asynchronous concurrency. As a result of this, even large scale applications built on Play consume minimum resources in terms of CPU, memory and threads.

• Another advantage that Akka provides to Play is predictable scalability. The asynchronous model of Akka coupled with the stateless, non-blocking I/O nature of Play ensures that there are no hiccups while scaling up.

• Development on Play is simple and straight forward. Owing to features such as hot reload, powerful console & build tools, type safety, built in testing tools and IDE support for Eclipse & IntelliJ IDEA all that is required for development would be a browser and a text editor. This enhances the productivity of developers dramatically.

• Play provides many features for modern web and mobile app development. Being RESTful by default, integration for JSON and compilers for CoffeeScript, Less etc., support for protocol technologies such as WebSocket & Comet and extensive NoSQL & Big Data support are just some of these features.

• The reactive nature of Play is another important feature. Apps developed based on a Service oriented architecture would require multiple parallel asynchronous requests to be sent out. Netty supports non - blocking I/O and hence it is not expensive to make such calls.

• Play is open source which allows for evaluation of the underlying code and also facilitates monitoring of the framework code. There is also a large user community who contribute libraries and help clarify the doubts of fellow users. But, even though play is open source, there is an option to receive commercial support.

• Play provides a developer friendly error handling mechanism where the error is directly mentioned in the browser itself with the file path, line number as well as the relevant code. This saves a lot of developer time and effort since he/she would not have to dig through and analyze large log files.

History

The early versions of Play framework can be traced back to early 2007 while it was being developed at Zenexity by software developer Guillaume Bort. The first full version of Play was in October 2009. Later in 2011, Sadek Drobi, co-creator of Play, joined the Play development wagon to release Play 2.0 in conjunction with Typesafe Stack 2.0.

Release History

Release Version	Date of Release	Features
Play 1.x	November 2010 - April 2011	Native Scala Support Migration from Apache MINA to JBoss Netty OAuth and HTTPS support
Play 2.0	March 2012	Native Support for Java and Scala Asynchronous programming support by inclusion of WebSockets and Comet Built-in relational database access libraries such as Ebean, JPA and Anorm
Play 2.1	Februrary 2013	Migration to Scala 2.10 API RequireJS support New Scala JSON API
Play 2.2	September 2013	Improved Java Promise API SBT 0.13 support Built in Gzip support
Play 2.3	May 2014	Introduced Activator command Support for Scala 2.11 Custom SSL Engine for HTTPS Upgrade to Netty 3.9.3

Architecture

MVC application model

Play follows a typical MVC architectural design pattern of web application development. This divides the application into two broad layers:

• The Model Layer: It handles the business logic of the actual domain problem.
• The Presentation Layer: This can be categorized into two sub parts.
  • The View: It handles the actual GUI of the application
  • The Controller: It maps the actions on the user interface to the concerned models.

The Model refers to the entities involved in the real world domains. It captures the actual data and applies the programming logic to it. The model operates on the raw data and adds "meaning" to it. Generally this data is stored in a persistent storage medium, like a database. Th model interacts with this data by means of a Data Access Layer which is encapsulated by it.

The View refers to the actual Graphical User Interface(GUI) displayed on the browser. This is the interface with which the user connects to the application. The data is inputted into the application using the interface provided by the view. It is usually displayed in the browser using HTML, CSS and JSON formats. It acts as the single point of access to the application for the end user.

The Controller maps the user actions (events) to the concerned models and invokes the required changes in them. It processes the events and affects the behavior of the underlying models. Typically, in a web application, the events generated are HTTP/HTTPS requests. The responsibility of the controller is to act as a filter for the HTTP requests, process them, extract relevant information and pass it to the concerned entities.

MVC architectural pttern.

In a Play application, these three components are placed in the app directory, each in a separate package.

app/controllers

These are the Java classes that receive the HTTP requests. They are extended form the play.mvc.Controller class. Each HTTP request is attached to a action method. This is a public and static method having the following signature:

public static void action_name(params...);

Various parameters can be defined as inputs to the action methods. Play automatically maps them from the corresponding HTTP request parameters. There is generally no limit on the number of parameters to be passed and they can also be sent as query strings.

app/models

These are the Java classes exhibiting typical Java behavior. Unlike the controllers, they follow the Java object oriented paradigm. This package contains the classes that represent the various actors in the use cases. All the corresponding operations pertaining to these actors are contained in the Model classes. The model classes access the data storage mediums to persist and update data.

app/views

This package contains special HTML, XML template files which are used to render the GUI on the user browser screen. The Play templating engine renders these views using special directives contained in these files. The Controller gets the data from the models and uses a template to decorate the views.

Standard Application Layout

The app directory

This directory contains a sub folder for each of the layer in the MVC pattern. This is the directory under which the developers can add their code as well as HTML pages. Apart from the above mentioned packages, developers can create their own packages.

The public directory

This directory contains the static resources which are not modified by the framework. their state remains the same after deployment. These contain the image files, CSS files, JavaScript files.

The conf directory

The conf directory is the directory that imparts the feature of configuration-over-convention to the framework. It contains all the configuration files required by the framework and the application. Two mandatory configuration files are:

• application.conf file: This file contains the standard configurations at time of application start up. Play provides a sophisticated API to read values from this file

Play.application().configuration().getString("key");
Play.application().configuration().getInt("number");

• routes file: This file contains the configurable URLs. The routes defined here are mapped to controller functions which accept HTTP requests, render views etc.

GET        /home                         Controllers.Application.index(Int ?= 2)
POST       /verifyuser                   Controllers.Login.verifyUser(String username)