Linked InのPrincipal Software EngineerであるYevgeniy Brikman氏が、Java webフレームワークである Play フレームワークについての評価のまとめを公表した。
私が一番驚いたのは、Playが非同期プログラミングをサポートしていることで、これは、多くのバックエンドサービスから並行にデータを持ってきたり、Cometスタイルのやりとりをサポートするのに、非常に役立ちます。
Playの意図しているのは非常に短いリクエストを処理すること で、このようなリクエストは任意の応答時間を持ち得る。Play は一時的に、繋がれたままのHTTPリクエストを「サスペンドする」。これには、特にプロセスがウエイト中の場合には最小限のリソースしか必要としない。Playは、ミニ－スレッド プールを動かすことができる（一般的にはマシンのプロセッサーの数プラス１）。これは、これまで普及してきた、「１リクエストにつき１スレッド」とは、非常に違う。
サーバーのロードプロファイルによって、イベントによるアプローチを使うほうが、スレッドモデルよりもずっと並列処理にうまく対処できます。Cometのような永続的な接続には、イベント モデルが採用すべき唯一の方法です。
Playは非同期のリクエストを扱うのに幾つものモデルを提供している。 “Promise”値（これは “waitall”命令文となり得る）を定義できる。この場合、全リクエストがリターンするまで、実行はサスペンドするが、例えば、複数のweb APIからデータを持ってくる必要がある時には、このほうが便利である。Playは、またJavaの無名インナークラスを使って、コールバックモデルをサポートしている。Playではまた、リクエストを指定時間後に処理させることもできる。
コミュニティは非常に活発で、宣伝通り、ホット 再ロードは機能しており、適度なDRYで、非同期I/OのサポートもこれまでJVMの世界で見てきた中では非常に良いです。少々まずい点もあります。文書／JavaDocはちょっと改善が必要ですが、我々は、Playが LinkedInエコシステムにちゃんと合うか更に評価していきます。
（モバイル）複合アプリケーションの台頭と Web APIで、（モバイル）クライアントと Web API間の調停役として薄い複合中間層が出現したようである。Play や Node.js のようなフレームワークは、モバイル ソリューション アーキテクチャにとって決定的なものと成るだろうか？あなたはどう見ますか？