The Play! Framework internals are based on very light and trivial concepts. One of them is that the application should be separated from the Web by a single thin layer—its API.
This framework helps in solving a fundamental problem in web-based applications: the reactivity of a web server within a distributed environment. In the following sections, we'll see which points are critical to building a sustainable and relevant solution.
A Play! 2 application is completely stateless, that is, no state can be stored on the server to cover multi-request workflows. This fact will oblige applications to use different patterns or to use specific tools to deal with a state—such as a caching system.
For responsiveness, they took the opportunity to distribute a dedicated server as part of the stack, which is the non-blocking JBoss Netty server. This server is different from others because of its behavior. Indeed, rather than dealing with threads for every single request that is coming, it uses an event-based architecture where events are created when a request is effectively asking something or sending something to the server. That will help the server not to wait for a request to finish before switching to another, or in other words, to block a thread until the request has something to do.
This kind of behavior is contrary to the "one user, one thread" concept, which leads the server to only serve as many users as the number of threads it can deal with, no matter what they are doing.
But the responsiveness is not yet accomplished if we only tackle it in the core, because a developer could block a thread on an external working process, such as a web service call.
In order to avoid developers doing that, Play! Framework 2 can declare a process to be asynchronous and leaves the server to choose when to process it or when to come back on it. For example, if a process is running on an external machine, but the local thread is simply waiting for an answer, this thread can be retrieved for other tasks until the remote call has returned.
However, that's still not enough, thanks to the Scala language and its ability to use functions as objects. Play! 2 uses Iteratee to add some responsiveness to handle request bodies themselves. So the body to be processed as an XML or a JSON is no more blocking the server because an Iteratee can pause its work until the server, which is responsive in itself, has some data.
Furthermore, it's composable, which adds a new value to the framework, because it prevents a body (that could be large) to be processed several times for transformation purposes (bytes to string to JSON, for instance).