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.
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.
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.
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.
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.
You can learn a lot more about play framework at http://www.playframework.com/documentation/2.2.x/Home