BT

Restlet 1.1.0:柔軟性と仕様サポートが向上

| 作者: R.J. Lorimer フォローする 0 人のフォロワー , 翻訳者 編集部 フォローする 0 人のフォロワー 投稿日 2008年11月15日. 推定読書時間: 9 分 |

RESTfulな(リンク)アプリケーションを作成するためのJavaフレームワーク、Restletは先日、2007年4月以来のメジャーリリースとなる1.1.0がリリースされ、新段階に入った。

Noelios Technologies社のウェブログ(リンク)で詳しく説明されているように、リリース1.1.0には多数の重要な変更がある。

  • 部分的ダウンロードや再開可能なアップロード、コンテンツの完全性検証といった、広くて深いHTTPサポート。
  • 業界随一のWADL仕様のサポートにより、REST APIのドキュメンテーションを自動的かつ常時同期させておくことが可能。WADL文書はXMLで生成するか、あるいはYahoo!で人気のスタイルシートを使って即座にHTMLに変換可能。
  • アノテーション指向のアプローチを好む人々のために用意された、新しいJAX-RS 1.0仕様の実装では先がけ的存在であり、実装の完全度も最高。
  • 新しいRestlet-GWTモジュールを提供し、クライアント側のRestlet APIを評判のGoogle Web Toolkit 1.5 JavaScriptプラットフォームにポートすることにより、Webブラウザから直接RESTfulなアプリケーションを呼び出し可能。
  • 新しい機能拡張により、JAXB 2.1、JiBX 1.1、Spring 2.5、OAuth、OSGi、Oracle XDB、SSL技術との統合が容易。
  • Atom配信XMLフォーマットおよびAtom出版プロトコル向けのサポートを改善。今ではフォーマット化とパースの両方を利用可能。
  • JavaMailベースの新しいPOP3コネクタでRESTfullに遠隔地のメールボックスにアクセス。
  • 新しいGrizzly HTTPサーバーコネクタは、Restlet APIでNIOサポートを完全活用するものとしては初めてのものであり、新しいレベルのスケーラビリティとパフォーマンスをもたらす。
  • HTTPクライアントとサーバーの新しい内部コネクタが開発段階を単純化し(コンフィギュレーション不要)、非常に小さなデプロイメント・フットプリントが可能に。

RestletフレームワークはあらゆるJavaサーブレットコンテナ内から(RestletServletを介して)、もしくはスタンドアロンのJavaアプリケーションとして起動できるため、デプロイメントとコンフィギュレーションでは多数のオプションが利用可能になる。

Restlet 1.1に付属する前述のNIO HTTP サーバーコネクタは、RestletのスタンドアロンJavaバージョンを対象としており、GlassFishで(リンク)使われているGrizzly NIOフレームワーク(リンク)に基づいている。

先月リリースされたJSR-311(リンク)は、JAX-RS 1.0仕様を定義している。上で明らかにしたように、Restletはこの仕様をサポートしており、Restlet開発リーダーのJérome Louvel氏はJSRの専門家グループの一員を務めた。

InfoQは今回のリリースについてRestletプロジェクトのリーダー、Jérôme Louvel氏と話す機会を得た。まず、JSR 311のサポートについて尋ねた。

私たちはJSR 311の専門家グループの一員として、スペックリーダーに重要なフィードバックを提供できました。専門家グループの取り組みの間、Restlet APIは刺激を与える重要な供給源としても機能しました。Java向けとしては初のRESTフレームワークを提供した私たちには長い経験があり(パブリック版のリリースは2005年末)、 RestletユーザーにJAX-RSのサポートを提供する上で最高の立場にあったのです。

その結果、最新版のRestlet 1.1版でJAX-RS 1.0(JSR 311定義によるAPI)完全実装のリリースを発表できることをうれしく思います。Stephan Koops氏の努力の賜物ですが、背景には同氏の修士論文がありました。氏はさらにRestletコミュニティと協力し、実装の開発を続けています。

Koops氏の次の目標はJCP奨学金プログラム経由でTCKにアクセスすること、また、Restletの認定を受けたものにJAX-RSの拡張を与えることです。しかし、私たちは実装の現状にすでにかなり満足しており、現時点で、全コネクタ(Jetty、Grizzly、Simpleなど)やRestletサービス(URIのファイル拡張子からHTTPの適切なコンテントネゴシエーション・ヘッダーへの変換など)の可用性といった、Restlet APIの機能多数を活用できます。

次に、JAX-RSを始める時期としてはいつがよく、ネイティブのRestlet APIを始める頃合いとしてはいつを勧めるか、Louvel氏に聞いた。

この件の決定に際しては、考えるべきことがいくつかあります。
  • まず、手元には根本的に異なる設計が2つあります。コアRestlet APIでは、Servlet API開発者が馴染み深いと思うような、伝統的なクラス指向の設計に従いました。基本的に、RESTとHTTPの重要概念にはすべて、対応するJavaクラスがAPIに存在するため、理論やプロトコルからRestletの機能に至るまでのマッピングを、頭の中できわめて直観的に行うことができます。

    これにより、コンパクトで、再利用可能、拡大可能なフレームワークができあがります。たとえばRestletアプリケーションを、ServletコンテナやOSGiカーネル、SpringおよびGuice IoCのコンテナ、スタンドアロンのJVM、Groovy、Scala、JAIN/SLEEなど、多種多様な環境にデプロイできます。Restlet APIのGWT 1.5(Google Web Toolkit)へのポートさえ行ったので、WebブラウザはあらゆるRESTfulのバックエンドとうまく相互作用できることになり、これはデフォルトのGWT-RPCソリューションを使用した場合とは対照的です。次期バージョンの1.2では、Restlet APIのGoogle Androidへのポートも計画しています!


    他方JAX-RSは、どちらかといえば新しいアノテーション指向型の設計に従ってきました。考え方としては、ドメインオブジェクト(POJOs)から始めて、ドメインオブジェクトをアノテートしてREST APIをどのように公開すべきか記述します。理論上は、同じPOJOsにJAXB向けのアノテーションも付けて、XMLやJSONにいかにして直列化するかを記述できます。


    しかし、現実のRESTアプリケーションでは、既存のドメインオブジェクトをアノテートするには不十分であるとすぐに気づくでしょう。Web アプリケーションを考え、設計する上で、RESTは根本的に新しい方法を暗示します。私たちがリソース指向パラダイムと呼ぶものです。オブジェクト指向パラダイムに若干似ていますが、保護カプセル化に代わって状態のオープンな表現になり、識別はURIベースになり、インターフェースは(HTTPメソッドに基づいて)統一されます。最も重要なことは、RESTレイヤとサポートするドメインオブジェクト間では粒度が異なり、リソースクラスの新しいセットに定義が必要になる点です。こうしたリソースクラスをアノテートするよりも、ベースとなるRestletのResourceクラスから継承させた方が、簡単かつ強力になると思います。
        # さて、JAX-RSはJCPの承認を受けた標準ですから、新プロジェクトの必要条件になることもあるでしょうし、今度のJEE 6標準ではその一部となるので、特にその傾向が強まるでしょう。JAX-RS APIには、ひとつのJAX-RS実装から別の実装へとコードをポートする能力がありますから、そのおかげでベンダーロックインから保護されている感覚になり、企業の中にはJAX-RS APIの方がとにかく快適と感じるところもあります。
     
  • さて、JAX-RSはJCPの承認を受けた標準ですから、新プロジェクトの必要条件になることもあるでしょうし、今度のJEE 6標準ではその一部となるので、特にその傾向が強まるでしょう。JAX-RS APIには、ひとつのJAX-RS実装から別の実装へとコードをポートする能力がありますから、そのおかげでベンダーロックインから保護されている感覚になり、企業の中にはJAX-RS APIの方がとにかく快適と感じるところもあります。

    しかし、JEEが初めて定義された所有ソフトウェアの時代と比べて、オープンソース時代における重要性はずっと低くなりました。SpringやHibernate、GroovyがJavaの世界を一変させている様子を考えてください。それに実際には、標準では利用できない機能を各ベンダーは使わせようとしてきます。たとえばクライアント側のサポートといったJAX-RS 1.0には入っていないような機能であり、そうやってある程度のベンダーロックインを再導入しているのです。
  • 最後になりますが、Restlet APIの機能の範囲はJAX-RSをはるかに上回ります。私たちはクライアント側、サーバー側両方のアプリケーションをサポートし、HTTPセマンティクスへのクリーンなマッピングを使って複数のプロトコル用コネクタ(HTTP、SMTP、POP3、FILE、JDBCなど)をサポートしていますが、そのすべてに使用しているのは統一された単一のAPIです。また、Servlet APIに対する完全な代替物も提供しており、それにはより動的で柔軟なURIマッピング、コネクタ向けのプログラマチックなサポート、認証ホストとバーチャルホストがついています。
Restlet APIはまた、静的ファイルのディレクトリの役割を果たすクラスを提供し、自動的なコンテントネゴシエーションとリモートアップデートもサポートされています。また、リバースプロキシのセットアップに必要なものすべてを提供し、サンドボックス化されたWebブラウザアプリケーションから外部のREST APIへのアクセスを提供します。
結局のところ、プロジェクトでJCP標準のサポートが必要な場合や、プログラミングのスタイルとしてアノテーションの方が好みなら、私たちが提供するJAX-RSを使うようお勧めします。他のケースでは、コアRestlet APIをあくまでも使い続けるように勧めるでしょう。そうすれば、より包括的で直感的なREST/HTTPのサポートが手に入り、より多数のデプロイメントオプションを残しておけます。

最後に、Restletコミュニティについて尋ねた。

Restletコードベースに取り組んでいるコミッターは8人います。コアコミッター2人については、このプロジェクトを推進しているNoelios Technologies社が資金を提供しています。両人はRestletのコア(APIとエンジン)、多数の機能拡張、ビルドプロセス、外部からの貢献の統合を担当しています。最初のリリース以来、当プロジェクトには約160人の貢献者がいます!

JAX-RSやGWT、XDB(Oracle)のような特定の機能拡張を担当する、機能拡張コミッターも6人います。こうしたコミッターは、Solertiumやマンチェスター大学など、他のパートナー組織から資金提供を受けている個人、もしくは開発者のどちらかです。
何よりも重要なことですが、Restletはユーザーとコントリビューターの活気に溢れたコミュニティであり、お互いをサポートしながら、プロジェクトの必要性に最も適した方向へ、団結してRestlet プロジェクトを進めているのです。

原文はこちらです:http://www.infoq.com/news/2008/11/restlet_1_1

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

あなたの意見をお聞かせください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする
コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

ディスカッション

InfoQにログインし新機能を利用する


パスワードを忘れた方はこちらへ

Follow

お気に入りのトピックや著者をフォローする

業界やサイト内で一番重要な見出しを閲覧する

Like

より多いシグナル、より少ないノイズ

お気に入りのトピックと著者を選択して自分のフィードを作る

Notifications

最新情報をすぐ手に入れるようにしよう

通知設定をして、お気に入りコンテンツを見逃さないようにしよう!

BT