Play is a very interesting web framework on the block. It’s interesting because it moves away from the traditional servlet-based web applications running on the JVM. It’s very interesting because it can be built using Scala and Java. In the first of the part of the series of articles on Play, I introduce you to Play framework, its architecture, the core building blocks and create a HelloWorld application using the Scala language.
Web applications with Servlets
Let me jog your memories about web development in Java. We create a servlets/JSPs and surround it with beans, configuration files etc. The servlets are deployed in a container. When you send a request to the servlet, the instance processes the request and gives you a response. Each request creates a thread that acts upon the servlet instance as shown in Figure 1.0.
Figure 1.0: Servlet, Thread-per-request.
(Ref:http://www.exforsys.com/images/vbnet/sourecode/J2EE/2-Servlet%20Basics/servlet-lifecycle.jpg)
The Thread-per-request model has its own share of advantages and disadvantages. It’s pretty easy to work with this model compared to creating processes per request. But creating multiple threads can get really complicated when the number of requests increase. It carries a significant memory cost and results in an overhead. If your servlet performs a time consuming job, it’s going to hold other threads(requests) in waiting. In other words an expensive operation blocks I/O. J2SE 1.4 introduced a new I/O API called NIO. NIO is also popularly referred to as Non-blocking I/O. The servlet 3.0 specification came up with NIO concepts incorporated. So we could now create non-blocking or asynchronous web applications with the servlets. The Tomcat7 and Jetty8 are popular servlet containers that support servlet 3.0. However, you still have backward compatibility issues.
Servlets over the years, have become heavyweight, thanks to several layers in the name of frameworks built around them. You have Struts, JSF etc. adding extra flab around it. So debugging, building a simple RESTful style URLs etc. are painful.
On the other hand, with servlets and containers evolving, there has been a steady growth of new solutions like Node JS. So here’s a set of questions we would like to ask.
- Isn’t there a simple way of developing high productive, non-blocking, asynchronous web applications on the JVM without having to be dependent on servlets?
- Should we still be dependent on a heavyweight container to manage the lifecycle etc.?
- Wouldn’t be good if we can write concise code and develop web applications on the JVM?
- Can we get rid of the heavyweight JEE stack?
Enter Play framework.
Play Framework
Play framework (http://www.playframework.com) is an open source web framework, lead by Typesafe(https://typesafe.com/). It is used for building asynchronous, high-productive web applications in Java and Scala. To quote the official site, “Play is based on a lightweight, stateless, web-friendly architecture. Built on Akka, Play provides predictable and minimal resource consumption (CPU, memory, threads) for highly-scalable applications.”
Play is implemented to follow asynchronous and non-blocking styles. Play is built on top of Netty server(http://netty.io) as shown in Figure 2.0. Netty uses NIO2 API for non-blocking IO. It is event-based and not threaded like the servlet containers. It makes concurrent requests a breeze. Play framework integrates very well with Akka API.
Play framework was originally written in Java, then moved to Scala. It’s written in Rails style, with high developer productivity in mind. If you need to build applications that have to scale, Play is a fantastic choice.
Figure 2.0: Play Architecture (Ref: Play with Scala, Manning)
Play framework with Scala brings the functional style to web development. So the API is expressive and concise. It has a full-fledged eco-system with builds, test specs, maven repositories etc. The current stable version of Play Framework is 2.x.
Components of Play
Play framework bascially follows the MVC(Model-View-Controller) pattern. The application is segregated into Models, Views and Controllers. Figure 3.0 shows the architecture of a Play application.
Figure 3.0: Components of Play (Ref:https://www.playframework.com/documentation/1.3.x/main)
The heart of a Play Application is the Controller. The Controller class contains collection of Action methods. Each Action method accepts a request and returns a result. The result contains information about the View pages. The View pages are html files with a special template syntax to access Scala objects and write some Scala code. The request from the client is routed to the controller’s action methods using routes. The models are companion objects that are used to access the persistent storage. The HTTP requests are processed asynchronously.
The components of a Play application are very similar to the Rails/Grails application. We’ll talk more about it in the next post.