1　軽量言語によるWebアプリケーション･フレームワークの登場

Web2.0アプリケーションの開発に大きな転換をもたらした存在のひとつとして、Ruby on Railsをはずすことはできない。

Ruby on Railsが登場するまでは、Webアプリケーションの大きな潮流は、重量級のJavaと軽量級のPHPに二分されていたといってもいいだろう。JavaによるWeb開発は、初期の学習コストが高い代わりに、大規模システムの開発においては結局低コスト･高品質をもたらす存在であった。一方、PHPによる開発は、非常に手軽にスタートできるものであったが、システムの規模が大きくなるについて混乱しがちなものであったといえる。

Ruby on Railsは、この両者のいいところをうまくミックスしたものだといえる。手軽に開発をスタートできるにもかかわらず、Rubyという言語とそのコ ミュニティのもつ整合性が、大規模開発においても比較的混乱しにくいという特徴をもたらしている。Ruby on Railsは、Rubyという言語の持つ「動的」であるという特徴を、高生産性と整合性を両立させるために生かしている。

Ruby on Railsに代表される軽量言語に基づくフレームワークがWeb2.0アプリケーションの開発に与えた影響の分析は、3.6 なぜ"Ruby on Rails"がエンタープライズ、Web 2.0向きか？を参照されたい。本稿では、もうひとつの軽量言語、Pythonに基づくフレームワークについて述べる。

2　軽量言語Python

PythonはRubyによく似た機能を持つ言語である。言語としての歴史はRubyよりもはるかに長く、初期のバージョンは1991年にGuido van Rossumによってリリースされている。現在のバージョンは2.5で、Google社に所属するGuido van Rossumを中心に開発が続けられている。

Pythonは早い時期からマルチプラットフォームで稼動し、それぞれのプラットフォームに対応したライブラリも充実していることから、複数のシステムをつなぐ「接着剤（Glue）言語｣として広く使われてきた。特にLinuxにおいては、Redhat Linuxがシステムツールの記述言語としてPythonを広く使ってきた（たとえば、Redhat Linuxのインストーラ"anaconda"もPythonで書かれている）こともあり、欧米を中心に多くの使用実績がある。

Web用のフレームワークとしては、Zopeが実績を持っている。Zopeはバックエンドのオブジェクト･データベースから管理用のUIまですべてがPythonで書かれており、WebのためにPythonを使うといえばZopeのことをさす、という状況が長く続いた。

しかし、Ruby on Railsの登場に刺激を受け、同様の特徴を持つPythonのフレームワークが次々に登場してきた。もともとPythonはRuby同様に動的な言語であり、ネットワーク系のライブラリが充実していたこともあって、現在ではDjango/TurboGears/Pylonｓといったフレームワークがそれぞれに競争しながら発展してきている状況にある。

3 PythonのWebフレームワークとApache

Web アプリケーションの開発において、Apacheの存在を欠かすことはできない。JavaにせよRubyにせよPythonにせよ、その言語系の上で動作するWebサーバの実装系は存在するものの、特にエンタープライズ･レベルのアプリケーションを構築するなら、現状では信頼性やパフォーマンスの点でそのまま使用するには難があると考えるべきだろう。

Pythonにおいては、Apacheなどの外部のWebサーバと連携するための標準技術としてWeb Server Gateway Interface（以下WSGI）という仕様が標準の地位を占めつつある。WSGIは、CGIやJavaにおけるARJと同様、WebサーバとPythonベースのWebアプリケーションが通信するための仕様を決定したものである。

このWSGIに対応したWebフレームワークとしては、Django・TurboGears・Pylonsなどが普及している。それぞれの特徴を以下に示す。

Django	PythonベースのWebアプリケーション･フレームワークとしては、世界規模で見て最も普及している。 ほぼすべての機能がDjangoプロジェクト内で開発されているため、統一性が取れていることが最大のメリットである。 Ajax対応機能は統合されていない。
TurboGears	Webフレームワークの各構成要素として既存のPythonの優秀なライブラリを採用し、全体としてひとつのフレームワークに統合している。 それぞれの構成要素に実績があることが最大のメリット。日本国内での情報量が多いこともメリットである。 現在バージョン1から2に向けて開発が進んでいるが、使用するライブラリがかなり変化している点には注意が必要。
Pylons	もっとも後発のフレームワーク。TurboGears同様、既存のライブラリをひとつのフレームワークとしてまとめあげたもの。 WSGIへの対応は最も進んでいる。現時点では日本語での情報が少ない。

以降、本稿ではTurboGearsを取り上げていく（筆者が主に使用しているのがTurboGearsである、というのが選択の理由）。

4　TurboGears

多くのWebアプリケーションのフレームワークは、Ruby on Railsと同様の構成要素からなっている。すなわち、MVC + Ajaxライブラリである。前述の通りTurboGearsで特徴的なのは、それぞれの要素についてPythonの実績あるライブラリを採用し、ひとつの＜メガ･フレームワーク＞としてまとめあげているということだ。

Model(O/Rマッパー)	SQLObject / SQLAlchemy
View（テンプレートエンジン）	Kid / Genshi
Controller（HTTPフレームワーク）	CherryPy
Ajaxライブラリ	Mochikit

興味深いのは、TurboGearsのバージョンアップにともない、標準とされるライブラリが変化してきていることである。この変化の背景には、RoRをいわば始祖とするWebアプリケーション･フレームワークに求められる進化の姿が見え隠れしている。

それぞれの要素について、もう少し掘り下げていこう。

・Model(O/Rマッパー)・・SQLObject / SQLAlchemy

データベースとPythonオブジェクトの橋渡しをする部分である。開発当初からTurboGears1.0まではSQLObjectが採用されていたが、今後はSQLAlchemyがデフォルトになっていく。

SQLObjectは、特にデータベースに不慣れな開発者から見た場合に使いやすいライブラリで、SQLを意識する必要がほとんど無い。Pythonのオブジェクトを扱う立場からすると非常にわかりやすいが、逆にデータベース側から見た場合には、データベースの持つ性能をフルに発揮することができない。

図4-1 SQLObjectのコーディング例

比較的単純なWebアプリケーションの場合（たとえば掲示板システムのような)、SQLObjectのようなオブジェクトよりのO/Rマッパーは非常に使いやすく、性能面でも問題にはなりにくい。

一 方、より性能や柔軟性が重要視されるエンタープライズ･アプリケーションにおいては、よりSQLそのものに近い処理を記述できるO/Rマッパーが求められる。TurboGearsの標準O/RマッパーになるSQLAlchemyでは、Pythonのコードの中にSQLのWhere節などにきわめて近い記述を含めることや、テーブル同士の結合に当たる操作を記述することもできる。

図4-2 SQLAlchemyのコーディング例

SQLObjectからSQLAlchemyへの移行は、TurboGearsのユーザーが本格的なエンタープライズ･アプリケーションに取り組み始めたことによって促されたと考えてよいだろう。TurboGearsユーザーのメーリングリストの議論でも、複雑なアプリケーションの開発におけるSQLObjectの限界を指摘する意見が多く見られた。

もともとRuby on RailsやTurboGearsは、「データベースアプリケーションが非常に簡単に開発できる｣ことをアピールすることで普及促進を図り、その一環として非常にシンプルで簡単に使えるO/Rマッパーの存在を前面に打ち出していた。しかし、これらのフレームワークがエンタープライズ・アプリケーションの開発者たちにも認知されてきた現在、過度のシンプルさがもたらすマイナス面をカバーする動きが出てきている。SQLAlchemyのような、やや最初の敷居が高くとも、エンタープライズ・アプリケーションにも使えるようなライブラリの登場によって、こうしたフレームワークのエンタープライズ領域への普及に弾みがつくことが期待できるだろう。

・View（テンプレートエンジン）・・・Kid / Genshi

テンプレートエンジンにおいても、KidからGenshiへの移行がアナウンスされている。KidとGenshiは共にXMLをベースとするテンプレートエ ンジンで、基本的にはXMLで書かれたテンプレートにPythonから値を渡し、結果のviewを生成する(典型的にはXHTMLやHTMLを生成することになるだろう)。

KidからGenshiへの移行を促したのは、デバッグのしやすさである。KidはテンプレートをいったんPythonのコードへと変換し、その上で結果のviewを生成する。この過程において例外が生じた場合に、もともとのテンプレートのどの行が例外の引き金になったのかがわからなくなってしまう。

この移行も、本格的なエンタープライズ･アプリケーションへのTurboGearsの適用可能性を広げるものと考えられる。

・Controller（HTTPフレームワーク）・・・CherryPy

CherryPy はHTTPベースのアプリケーションを作成するためのフレームワークである。基本的なアイデアは、PythonオブジェクトのメソッドをそのままWebサーバのURLにマップするというものだ。HTTPリクエストのパラメータを自動的にメソッドに引数に変換したり、Pythonの関数デコレータによってURLへのアクセス権制御を宣言的に書くことができる。

図4-3 宣言的なアクセス権制御

Webアプリケーションを書くための軽量言語の代表であるPHPと比較すると、CherryPyではきわめて見通しよく、安全にアプリケーションを設計していくことができる。

初期のPHPはHTTPリクエスト中に置かれたパラメータが自動的にスクリプト内で変数に変換されてしまったり、標準的なアクセス制御の仕組みを持たなかったり（手続き的に書かれたアクセス制御機構は、セキュリティ･ホールを生みやすい）と、潜在していたセキュリティの問題が露呈していなかった時代背景の中で設計されている。対してCherryPyでは、メソッドで宣言されていないパラメータがHTTPリクエスト中に含まれていた場合、デフォルトで例外を発生させる。あるいは、アクセス権制御は、メソッドの内部の処理とは独立して、メソッドそのものの性質として宣言的に書くことができる。

CherryPyのもうひとつの長所として、フィルタ機能を触れておこう。これは、URLにマップされたメソッドの返値を、どのようなフォーマットで返すかを関数デコレータで指定する機能である。メソッド内のロジックを一切修正することなく、HTTPのレスポンスの内容をHTMLにしたり、XMLにしたり、JSONにしたりすることができる。これは特にAjax開発時に便利で、サーバサイドにおいてはそれが通常のHTTPレスポンスを返すメソッドなのか、あるいはAjax用のメソッドなのかをほとんど意識することなく実装を進めることができる。

・Ajaxライブラリ・・・Mochikit

Ajax用のJavaScriptライブラリとしてはprototype.jsがスタンダードといってもよいほど普及しているが、TurboGearsではMochiKitを採用している。MochiKitのドキュメントやテストが充実していることと、非同期動作がPythonの有名なネットワーク・フレームワークのTwisted（Linuxの仮想化ツール・Xenで採用されている）によく似た構成で実装されていることが採用の理由だ。MochiKitの実装は、全体にPythonプログラマにはとっつきやすいものになっているといえるだろう。

Ajaxライブラリとテンプレートシステムの両方にまたがるトピックとして、GUIの部品化を進める動きがある。もともとTurboGearsではGUI部品をWidgetと呼び、再利用可能な形でライブラリ化する機能を持っていた。このWidgetの機能が整理され、TurboGearsとは独立したToscaWidgetsプロジェクトとして開発がスタートしている。まだスタートしたばかりのプロジェクトではあるが、注目に値する動きといえる。

5　Webフレームワークの薦め

Ruby on RailsやTuboGearsといったWeb開発フレームワークは、Javaを中心とする重量級のフレームワークに対するアンチテーゼとして誕生･発展してきた。軽量なWebアプリケーション開発ツールとしてはPHPなどが普及しているが、これらの「軽量すぎる」開発ツールは大規模開発に対応するために、つぎはぎ感のある拡張を繰り返してきた。Ruby on RailsやTuboGearsは、軽量級でありながら整合性の高い開発を実現できるという点で際だっている。

普及促進という観点から見たとき、Ruby on RailsやTurboGearsが大きな成功を収めた要因のひとつは、WebCastを使ったきわめてインパクトの強いチュートリアルを大量に用意したことだろう。数十分の間に、目の前でスクラッチからひとつのWebアプリケーションができていく様子を見せつけたことが、これまで重量級開発フレームワークで、「鶏を割くのに牛刀を使っている」ような苦労をしてきた開発者たちを強烈に魅了したことは間違いない。

一方、そうしたマーケティング的な成功の結果として、（おそらくは当初の開発者たちの思惑をも超えて）これらのフレームワークがエンタープライズ・アプリケーションの開発ツールとして真剣に使用され始めている。TurboGearsをはじめとするPythonベースのフレームワーク群において現在急ピッチ で改善が進んでいるのは、これらのフレームワークでも軽量化が行き過ぎた部分、たとえばSQLObjectがSQLAlchemyに置き換えられていって いるような部分だ。

総合的に見て、いよいよエンタープライズ・アプリケーション開発にTurboGears等のフレームワークの適用を検討する時期に来ているといえるだろう。 特に今後は、エンタープライズレベルの開発にとって有効な機能拡張が進むことが期待できる。技術動向を注意深く見守ることも忘れてはならないだろう。