ScalatraはScalaはウェブフレームワークであり、RubyのフレームワークであるSinatraの原則を踏襲している。このフレームワークは元はStepという名で知られていたフレームワークであり、LinkedIn Signalで使われているRESTfulなサービス基盤の背後にあるフレームワークでもある。
Sinatraに似た他のフレームワークと同じように、Scalatraでも開発者はマッチングルートとそれを処理するコードを定義する。
package org.scalatra class ScalatraExample extends ScalatraServlet { // send a text/html content type back each time before { contentType = "text/html" } // parse matching requests, saving things prefixed with ':' as params get("/date/:year/:month/:day") { <ul> <li>Year: {params("year")}</li> <li>Month: {params("month")}</li> <li>Day: {params("day")}</li> </ul> } // produce a simple HTML form get("/form") { <form action='/post' method='POST'> Post something: <input name='submission' type='text'/> <input type='submit'/> </form> } // handle POSTs from the form generated above post("/post") { <h1>You posted: {params("submission")}</h1> } // respond to '/' with a greeting get("/") { <h1>Hello world!</h1> } // send redirect headers get("/see_ya") { redirect("http://google.com") } // set a session var get("/set/:session_val") { session("val") = params("session_val") <h1>Session var set</h1> } // see session var get("/see") { session("val") match { case Some(v:String) => v case _ => "No session var set" } } // Actions that return byte arrays render a binary response get("/report.pdf") { contentType = "application/pdf" val pdf = generatePdf() pdf.toBytes } notFound { response.setStatus(404) "Not found" } }
InfoQは共同開発者の一人であるRoss Baker氏このScalatraプロジェクトについて話を聞いた。
InfoQ: SinatraはRubyの人気のフレームワークであり、いくつかの言語に移植されていますね。このフレームワークの一番良い機能は何ですか。また、どんな部分が気に入りましたか。
Ross: Sinatraから生まれたフレームワークがとても面白いのは、最小の機能しか持っていないフレームワークだからです。対象となる言語とHTTPの基本を知っていれば、これらのフレームワークを使ってすぐに生産的な仕事ができます。
InfoQ: Scalaを選んだのはなぜですか。
Ross: 私は4年間学校で関数型言語の優雅さについて勉強しました。そして、次の10年間はJavaを学びました。Javaについては言語そのものよりもたくさんのライブラリに感銘を受けました。Scalaは関数型言語とJavaのたくさんのライブラリがきちんと融合しています。私にとってはScalaを利用することに全く抵抗はありませんでした。
InfoQ: Liftのような他のScalaのフレームワークを選ばなかったのはなぜですか。
Ross: Liftはフレームワークもコミュニティも素晴らしいです。しかし私はLiftが前提としているいくつかの部分に苦労させられました。とりわけ、Liftはセッションステートを取り入れ、HTTPを隠蔽しますが、私はHTTPを取り入れてセッションステートは敬遠したいのです。どちらがいいか悪いかを決めるということではありません。LiftでRESTfulなアプリケーションを作ることもできますし、Scalatraでステートフルなアプリケーションを作ることもできます。しかし、このふたつのフレームワークはそれぞれ別の種別のアプリケーションのために調節されています。このふたつのフレームワークがあることはうれしいことです。
InfoQ: Scalatraを使ったアプリケーションのさまざまな部分について全体像を簡単に教えてくれませんか。
Ross: ScalatraはシンプルなDSLです。単一のクラスだけでアプリケーション全体を記述することもできます(もちろん実際にそうすることが適切かどうかは実装するアプリケーションの大きさによります)。そしてweb.xmlにいくつかの行を追加すれば、Scalatraアプリケーションとして十分に機能します。
InfoQ: JavaのウェブフレームワークからScalatraへ移行しようと考えているチームになにかアドバイスはありますか。気をつけるべき誰もが陥りがちな穴は何でしょう。どんな方法で移行すればよいでしょうか。
Ross: Javaアプリケーションからの移行するためには、移行対象のアプリケーションの中にScalatraFilterを宣言するのがいいと思います。こうすることで一回でページの移行が行えます。こうしておけば、Scalatraがマッチングルートを見つければ、そこで処理がされますし、見つからなければリクエストはレガシサーブレットに受け渡されます。
また、JavaとScalaの双方向の互換性についても念頭に置く必要があります。互換性があるということは、層毎に厳密に移行をする必要がないということです。移行に必要なコードの固まりだけを移植すればよく、要求が変わらない限りJavaのよくテストされたコードを捨てることを恐れる必要はありません。
InfoQ: 最近、LinkedInはLinkedIn SignalでScalatraを利用していることを発表しました。他に利用例を知っていますか。
Ross: LinkedInに加えて、Scalatraの利用に成功している例としてChaChaの内部APIと管理アプリケーションがあります。彼らはテンプレート処理として一緒にScalateを利用するのを好んでいます。また、スタートアップが現在、Scalatraの大きなプロジェクトを進行している事例を少なくともふたつ知っています。将来発表されるのがとても楽しみです。また、RESTfulなAPIはScalatraアプリケーションではとても一般的です。
Scalaがスケーラブルな言語であるのと同じように、Scalatraもスケーラブルなフレームワークです。インラインでHTMLとビジネスロジックを書けば素早くプロトタイプを作れます。そして、プロジェクトが成熟するにつれ、コンパイラとテストフレームワークに頼りながらリファクタリングすることでN層の企業アプリケーションに育てられます。もちろん、こういう方法を採らなくてもよいです。アーキテクチャは実装者次第で決められます。
InfoQ: 8月にM1がリリースされましたが、最終リリースはいつを予定していますか。プロジェクトのロードマップとこれからのリリースで盛り込む予定の機能について教えてください。
Ross: 近い将来に予定しているのはコメットのサポート、JRebelでの再読み込みを簡単にするためのサーブレット/フィルタとDSLの分離です。また、きちんとしたウェブサイトも準備しています。もちろん、このサイトはScalatraを使っています。また、OSGiのサポート、入れ子ルータ、ルーティングのマッチングのオプションを拡張することにも興味があります。Scalate1.3のリリースに伴う他のマイルストーンも期待していますし、2.0.0-finalのタグをつける前の、APIに矛盾がないことを確認するためのレビューもする予定です。
Scalatraは自由に利用できる。また、ダウンロードにもさまざまな選択肢がある。
Scalaでさらに詳しい情報が得られる。InfoQでもウェブフレームワークのページを作成した。