Play Framework 2.1 Architecture

Play 2 is completely different from the previous versions. When the team decided to change the framework I was frustrated just like the rest of the community.. “why would they change something so good” everyone was wondering! Anyway, I decided to follow the new version as I thought they would have a good reason for this radical change, and they did.

Asynchronous Web
Play 1.x  was following the steps of django and rails, too many request serving them as fast as possible. It was working on the assumption that all request will be short (just asking for some data, or sending a form) and for more time consuming requests a scheduled job could be used. The new architecture is based on the actor model, powered by akka. Actors are lightweight entities that processes messages asynchronously. In the new Play every request is considered to be a long lasting one and it seems that the best way to handle persistent connections is the event model.

Architecture Overview
Play 2.x still uses the MVC pattern. There is a Controller that handles the incoming request with the help of the Model and the View it will build and return the response. Model is of course the domain model with the data and logic and the View is the templating system that can be fed with model data to produce the response. What’s interesting about the Model is that it is completely agnostic of the view layer, well, after all that’s the point of mvc.

Just like the previous version Play 2.x comes with an embedded HTTP server which specifically is the jBoss Netty and it’s non-blocking IO server.  Netty is integrated into the framework and it’s completely transparent. The benefits of integrating a nonblocking IO server is that the framework provides an HTTP API that supports out of the box asynchronous web programming.  When an http request comes in Netty will handle it and forward the data to play framework, the framework will processes the data and generate some response which Netty will deliver back to the client.

Incoming Request
The following image illustrates how play handles the normal requests. A client makes a request for a resource in this example the request is the following http://www.example.com/delete/234. After the domain name follows the route which is mapped to an Action in this case it is mapped to the remove action in a Controller class. The Controller has access to the model class and its methods and performs a delete on the data. The model synchronises with the database and returns back to the controller the status of the deletion (success or fail). The controller then renders the view and sends the Response to the client.

play-architecture

Incoming Request Asynchronous Action
The following image illustrates how play handles requests in an asynchronous way. A client makes a request for a resource in this example the request is the following http://www.example.com/delete/234. After the domain name follows the route which is mapped to an Action in this case it is mapped to the remove action in a Controller class. So far nothing has changes from the previous method. The Controller has access to the model class and its methods and performs a delete on the data but in this case the operation last longer because a lot of business rules need to be checked before deletion. To avoid blocking the Controller sends back to the client a Future[Result] and it moves on with other possible requests. At this stage the client is waiting for the actual response. The model method completes and synchronises the state with the database and returns back to the controller the status of the deletion (success or fail). The controller then renders the view and sends the Response to the client fulfilling the future results.
PlayArchtectureAsyncRequest

You can learn a lot more about play framework at http://www.playframework.com/documentation/2.2.x/Home

Play framework

Excellent! This is how java web frameworks should had been from 2005. Play is a full stack framework and has so many features that putting them all on this post it will end up being an index list. But it’s not only the long list of features it has, it’s that everything works out of the box, there is no need to figure out how to do something. As I said the list is big, so I will only list those that I found more exciting… (I am using this framework on one of my current projects and it works very well on production environment, it’s not just another experiment).

Here they are:

  • Active Record style model, based on JPA annotations and backed by hibernate. This is probably the most missing feature form java frameworks, for some strange reason no other Java web framework (at least non that I am aware off) tackle this one and developers are stack with an anemic model – well this is probably a very controversial issue with pros and cons from both sides, anyway, this works fine for me and the fact that it removes the need for DAOs is a big win. Furthermore, just like POJOs you can transfer the model objects them from the service layer to the front-end and back again.
  • No need to compile the sources, just make a change and reload your browser.
  • Template engine, it uses Groovy as an expression language, I am not familiar with Groovy at all but I love this feature, it works just like the django templates, there is no need to know Groovy to use it.
  • Play is modular, there are already plenty of modules to use and it’s really easy to write yours. Standard distribution of Play comes with two optional modules, CRUD and Secure. I think all projects have a need for both modules. With CRUD you have a full web administration interface for all your model objects and it’s fully customizable. Secure is a simple module that helps you setup a basic authentication and authorization management, it’s also highly customizable.
  • Play also ships with an embedded application server, just type ”play run” and the world is ready for your next cool app, of course you can deploy your application on any application server. It’s really nice that the embedded application server is ready for production, it’s not just a subset to help you during development.
  • Testing the app is easier than ever.  It uses the JUnit for unit and functional testing, in your functional testing you can access directly your web controller objects. And there is a third kind of testing, Selenium for your views. But it does not stop there you can run your tests from your web page. In fact the tests are loaded only when you run Play in test mode “play test CoolApp”. Even more, with the Fixtures help class you can load your test data from a yaml file in no time. Do you want more! Continuous Integration to run your test auto-magically, just run Play with the auto-test command. I know what you think, you can do all these with any framework since they are not framework specific, but just imagine the time you need to set everything up, in Play they just work.
  • Ready for REST, it is easily scaled by running multiple instances of the same application on several servers.
  • IDE agnostic :) it comes with a command line tool that converts your project so it can be used in your favorite IDE.
  • And it’s really fast

There are a lot more cool things about this framework. It’s very different from the rest of the frameworks in a good way, just as Spring broke the rules of enterprise development years ago, Play does the same, it breaks the rules and takes an unconventional away of doing thing which is closer to the developer, with the usability and productivity in mind.

Give it a try http://www.playframework.org