BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ アーティクル インタビュー:Jérome Louvel氏にRestletについて聞く

インタビュー:Jérome Louvel氏にRestletについて聞く

InfoQのStefan Tilkovは、Java Restletフレームワーク(サイト・英語)の中心的な開発者であるJérome Louvel氏と話す機会を得ました。Restletはバージョン1.0がリリース(source)されたばかりです。Restletの存在理由、Java ウェブサービスフレームワークおよびRuby on RailsにおけるRESTサポート、JSR 311への期待、Restletの今後の計画といった内容について話を伺いました。

InfoQ: Restletは何のためにあるのか、簡単に説明してください。

Jérome Louvel (JL): Restlet(サイト・英語)はJava向けの軽量REST(source)フレームワークです。Restletは、ウェブのアーキテクチャスタイルであるRESTを採用していますので、ウェブサイトとウェブサービスが明瞭に区別されていないウェブアプリケーションを構築することができます。すべての主要なREST概念には該当するJavaクラスがあるので、RESTfulなウェブ設計とコードを頭の中でマッピングするのは簡単です。

Restletは、CDDLライセンスまたはGPLライセンス(クラスパス例外を含む)のもとで配布される、オープンソースプロジェクトです。プロジェクトはRestlet API、参照実装(Noelious Restlet エンジン)、および拡張セットから構成されます。

InfoQ: どうして別のフレームワークを作る必要があると感じたのですか?サーブレットAPIで“十分”ではないですか?

JL: サーブレットAPIは1998年にリリースされ、そのコアデザインはそのときから大きく変わっていません。最も成功したJava EE APIのうちの一つですが、いくつかの設計フローと制限が悩みの種でした。例えば、URIパターンとハンドラの間のマッピングは限定され、1つの設定ファイルで集中管理されます。また、アプリケーションの開発者が直接ソケットストリームを制御するので、NIO機能を十分に利用するようなサーブレットコンテナが、何らかのIOの最適化を行うことができません。結局、キャッシング、コンテンツネゴシエーション、コンテンツの圧縮といったHTTP機能を十分にサポートしないため、結果として開発者が非常に苦しむことになり、アプリケーション固有のコードに集中することができません。

もう一つの主要な懸案事項は、Java EEスタックに最新の HTTPクライアントAPIが欠落していたことです。JDKのHttpURLConnectionクラスは使うのが難しく、またコンテンツネゴシエーションのためにクライアントプレファレンスを伝達するといったHTTP機能が、数多くサポートされないまま残っています。

これらの制限が回避するために、サードパーティのHTTPクライアントAPIに頼るといったがよくありました。また、HttpURLConnectionはNIOをサポートできないかもしれません。

2005年に、これらの制限すべてを乗り越え、REST原理に照らして斬新なAPIを設計する好機を見出しました。初めて、クライアント側とサーバ側のウェブアプリケーションを一元管理するAPI、NIOを完全にサポートするAPI、そしてXML記述子に常に依存する必要なく、開発者がプログラムによってコンテナ、コネクタ、デプロイされたアプリケーションを制御できるAPIが手に入るのです。

InfoQ: 他のフレームワーク(Axis2(source)やCXF/XFire(source))がRESTをサポートすることについてどう思いますか?

JL: これらは使えますが、かなり限定されていると思います。私が抱えている主要な課題は、これらのプロジェクトがWS-*/SOAPスタックとして設計されており、全く新しいパラダイムであるRESTの世界にうまく合わないということです。RESTはリモートメソッド呼び出しとは対照的に、リソース指向設計を定義しています。

Axis2を例に挙げますと、サポートするのはGETとPOSTメソッドだけですし、URIパラメータとして渡すためにリモートメソッドが必要です。これはあきらかにRESTでは許されないことですし、RESTfulと銘打つべきでさえありません。

XFire 1.2はRESTをサポートしていませんが、POJOをRESTfulなウェブサービスにマッピングするプロジェクトを公表しています。それは最近JSR-311(source)が追求しているアプローチに似たものになるでしょう。JSR-311は、一連のアノテーションとヘルパークラスをベースに、そういったマッピングを標準化することを目的としています。

InfoQ: あなたはJSR 311 エキスパートグループ(source)の一員ですが、JSRに何を期待していますか?

JL: 私が期待するのは、RESTリソースとPOJOドメインオブジェクトとの間に良いマッピングを作ることです。JPAがRDBMSデータベースとPOJOの間で成し得たことができるといいと思っています。RESTlet APIには、RESTリソースとPOJOをマッピングするのに、既にクラスを中心としたAPIがありますが、アノテーション中心のAPIがRestlet APIに完全に相補的になるといいと思っています。

また、これらのアノテーションをAxis2やXfireといったプロジェクトでも実装することができたので、このJSRがRESTとWS-* 陣営の折り合いをつける良い機会となると思っています。

InfoQ: Restletを利用するいくつかのプロジェクトについて何か話してください。

JL: いくつかのアプリケーションが、様々な規模の組織において既にデプロイされて稼動中です。その中には、格安でブランド商品を販売するインターネット大手のOverstock.com社があります。Restletプロジェクトはまた、RESTアーキテクチャスタイルをカバーする様々なソフトウェアアーキテクチャクラスをサポートする技術として使われます。例えば、カリフォルニア大学アーバイン校や、インサ工科大学ルーアン校といったところで使われています。

また、われわれのウェブサイトはすべて自社製品を使い、自社のRestletエンジンで運営しています。サービス妨害による攻撃を受けた量を考えると、拡張性には自信をもっています。最近、性能品質を示す公式なベンチマーク(source)も公表しました。人気のあるサーブレットコンテナと同レベルですが、Glassfishの Grizzly NIO フレームワーク(source)に基づくNIO最適化コネクタを完全にサポートする次のリリースでは、その上を行くと期待しています。

InfoQ: RESTfulなアプリケーションを構築するという点において、他の言語と比べるとJavaについてどう思いますか?

JL: RailsやDjango(サイト・英語)といった有名なRESTfulなオルタナティブを経験することで、Java/Restletのオルタナティブは、RESTfulなアプリケーションをより良く、より高性能でサポートすることを提案していると思うようになりました。RailsやDjangoはRESTを念頭に入れて設計されたわけではなく、これらの概念は後から付け加えられたものでした。その結果、Restletより不自然なコードになってしまいました。Djangoを例に挙げると、元はURIとリソースをマップするURIテンプレートをサポートしていません。RailsはRDMS CRUDパラダイムとREST/HTTPメソッドの不自然なマッピングを無理に押し進め、不満足な結果になってしまいました。結局、多くの制約を回避しなくてはならず、リソース指向の設計をRailsの世界観に合うように変えなければならないのです。一方、Restletは持続的技術を課すことは一切なく、リソース、リソースの表現、およびドメインオブジェクトやデータベースとのマップ方法を自由に定義できます。

InfoQ: この点について、Railsの批判をもう少し詳しく説明してくださいませんか? あなたの意見では、CRUDマッピングの何が不自然なのですか?

JL: GETおよびDELETE HTTPメソッドは、SQL SELECTおよびDELETE文にうまくマップされていますが、「作成」するのにRailsのPOSTメソッドを使ったのはちょっと残念だと思います。RESTにおいて「作成」に一番良いメソッドは、更新にも使うPUTです。PUTがPOSTより良いところは、操作が失敗した場合にPUTは支障なく繰り返すことができますが、POSTはそうではないという点です。

また、リソースのリストはテーブル名および数字の列IDを基にマップされますが、それが実際にいつもうまくいくとは限りません。アプリケーションのユーザーインターフェースの一部であり、RESTの最も肝心な概念であるURIの制御がきかないなんて、誰も望まないでしょう? RestletではURIに何ら制約を課すことがなく、馴染みのある持続的技術(JPAの注釈付きPOJO、そのままのJDBC呼び出し、オブジェクトデータベースなど)を何でも使ってリソースや表現を自由にマップできます。

もう一つ、小さい批判ですが、リソースとしてウェブページにアクセスするのにRailsは場違いな“;edit”サフィックスを使うことを勧めています。これはちょっと誤解を招く恐れがあります。RESTはURIパラメータを渡すのに、複数の方法を指定することを勧めていないからです。むしろ、ブラウザがGETした後でPOSTまたはPUTする別々のウェブフォームリソースを使うべきなのです。

InfoQ: Restletにかなりの時間を費やしたようですね。この“趣味の”プロジェクトはいくらかかったのですか?そして、会社は商業的成功をどれほど期待しているのですか?

JL: このプロジェクトは、当初から趣味などでは決してありません。他の重要なプライベートプロジェクトを構築した際に必要性を感じたのですが、それに対する答えなのです。プロフェッショナルなオープンソースを信じていますし、Noelios Consultingが提供するプロフェッショナルサービス(サポート計画、コンサルティング)によって、今までに費やしてきた時間と同じくらいは投資し続けることができると期待しています。

InfoQ: この最初のバージョンの後の計画はどのようなものですか?

JL: バグ修正リリースである1.0系の保守バージョンの他に、間もなく1.1系を開始します。今考えているいくつかの追加機能は、WAR パッケージングのサポート(XML記述子を必要としない)、管理者の仕事を助けられるような、XML記述子を通してRestletコンポーネント(ポータブルアプリケーションおよび仮想ホストのコンテナ)を設定するオプションなどです。また、完成しなければならないコネクタのプロトタイプがいくつかあります。一つはGrizzly NIOフレームワークコアに基づいたHTTPサーバコネクタで、これによってさらなる拡張性と応答性が得られるはずです。あとは2つのHTTPコネクタですが、JXTA仮想ソケット(1つはクライアント、1つはサーバ)に基づいています。

私たちはまた、コンテンツ範囲、Digest および WSSE 認証といったHTTP機能のサポートを引き続き深めたいと思っています。2008年にはRestlet APIをJCPに提出する計画もあります。これは、サーブレットAPIをだんだんと廃止していくための良い機会になるかもしれません。

InfoQ: お時間を頂きましてありがとうございました!


Jérome Louvel氏はソフトウェアアーキテクトで、Noelios Consulting社(サイト・英語)の創立者です。ヨーロッパおよび北アメリカにおいて8年以上のソフトウェアの作成とコンサルティングの経験があります。氏はJava、REST、セマンティックウェブ、およびビジネスプロセス統合に特に関心を寄せています。

原文はこちらです:http://www.infoq.com/articles/restlet-louvel-interview
(このArticleは2007年4月17日に原文が掲載されました)

この記事に星をつける

おすすめ度
スタイル

BT