BT

JAX-RS 実装の比較

作者: Mark Little , 翻訳者 岡田 英久 投稿日 2008年10月23日 |

だれかがどこかで言っていたことだが(リンク)、バスにはへんなところがあって、一台を長いあいだ待っていると、いきなり三台同時にやってきたりする。そのことは JAX-RS 実装についても(参考記事・英語)言えるように思える。現在 JAX-RS には次のような実装が存在する。

  • CXF(リンク) - XFire (リンク)と Celtix(リンク) (オープンソースの ESB で、IONA の援助を受けて、ObjectWeb で公開された)をマージしたもの
  • Jersey (リンク)- Sun による JAX-RS のリファレンス実装
  • RESTEasy(リンク) - JBoss の JAX-RS プロジェクト
  • Restlet(リンク) - おそらく最初に作られた REST フレームワークで、JAX-RS が生まれる前から存在していた。

REST をとりまく(参考記事・英語)議論は色々あるが(参考記事・英語)、いずれにおいても、Java 言語に REST サポートが必要であり JAX-RS こそがそれなのだという議論はされない。もしあなたが初めて REST に触れるとしたら、これらの実装のうち、どれを使うのがよいのだろうか? そこで、Solomon Duskis 氏が、それらの議論に光をあてようとしている(リンク)。彼は dzone(リンク)で次のように指摘している。

私は、純粋な JAX-RS を越えて拡張されている JAX-RS 実装同士の以下のような側面を比べることに関心がある。

そこには次のようなものが含まれる。

  • 製品の成熟度
  • サーバサイドの統合戦略
  • Java Client API
  • コンフィギュレーションの充実
  • セキュリティ
  • パフォーマンス

Solomon 氏は、「Jersey はリファレンス実装で、RESTEasy は新しいアイデアを試す場所、CXF は IONA によってサポートされている企業向けバージョン、そして、Restlet プロジェクトは RESTful な API の選択肢を手にしたいという要望から生まれたもの」であると述べている。

ブログのコメントとしてではあるが、Bill Burke 氏がこれに反論している。

RESTEasy は単なる新しいアイデアを試す場所ではない。RESTEasy はまもなく JBoss 上での動作をサポートする予定だし(わたしが TCK に手をつけられるようになったらすぐだ)、それを期待している RESTEasy ユーザは大勢いる。

使いやすさに関しては、Solomon 氏はこれまでのところ次のように述べている。

あなたが直面している問題は、どの実装を選択するかだ。Bill [Burke] 氏は RESTEasy がシンプルだと主張するだろうが、わたしは Jersey が使いやすいと感じている。いずれも EJB と連携して動作可能としている。

Jersey をつかう場合、特に NetBeans を利用するのであれば、HelloWorldService を作成して実行するのにさほど長い時間はかからないだろう。わたしは初めて Jersey と NetBeans をつかったとき、ダウンロードとインストールとコードサーフィンも含めて、30 分以内に起動して実行することができた。

Sun の Folks 氏(リンク)は、Jersey を、人々がリファレンス実装についてもっている従来の考え方から遠ざけたがっている。

「製品の目的」のことをいうのなら、Jersey を production ready な製品だとみなしているということをはっきりさせてほしい(実を言うと、来月、GlassFish v 3 Prelude にバンドルされて配布されることになっている)。開発チームは Jersey をリファレンス実装から脱却させるためのテストとコードの効率アップにたくさんの時間を費やしたところだ。

 

Solomon 氏はそれらの側面それぞれについて調査を行い、ブログエントリのつづきを投稿するつもりだった。「JAX-RS と Spring の統合(リンク)」というエントリがすでにアップされている。

現在の四つの JAX-RS 実装は Spring との統合を提供している。JBoss の RESTEasy でさえもそうだ。

彼は Spring との統合についてかなり詳細な記述をつづけているが、Jersey について言えば、Paul 氏(リンク)が指摘しているとおり、古い情報を参照してしまっている。徹底的な比較の必要があるため、間違いがあったのは残念なことだ。Solomon 氏は次のように結論している。

 

4 つの実装は本当にファンタスティックな Spring/JAX-RS 能力を有しているが、わたしは CXF に一票を投じたい。それは CXF が JAX-RS 製品のなかで最高の Spring 統合能力をもっているからだ。

 

しかし、これは明らかに彼個人の意見であり、反対する者もいる。たとえば、Bill Burke 氏は次のように問いかける。

どうして CXF の Spring 統合がほかの実装よりもすぐれていると言えるのか、わたしにはわからない。Spring の XML ファイルに追加されている CXF 特有の XML 記述の必要性や存在理由もわからない。RESTEasy や Jersey が提供している Spring 統合は、CXF が要求するものに比べて押し付けがましさが少ない。わたしは間違ったことを言っているだろうか?

これに対して Solomon 氏は次のように応えている。

アノテーションをつかったアプローチは、クラスごとに使われているコンフィギュレーションがひとつだけであれば、うまく動作する。90 %以上のケースではそうだが、のこりの 10 %では、複数コンテキストにおいて、同じリソースに複数のコンフィギュレーションが要求される。わたしは、要求されていることや現在アップデートしている機能のデプロイを考えると、自分がその 10 %未満のソリューションを必要とするだろうことに気付いている。CXF は、ひとつのリソースにひとつの Spring .XML ファイルをつかって、複数の別々の設定(異なる JDBC ソースや異なるサービス実装など)でデプロイするための方法を提供してくれる。一般的にいって、アノテーションはほとんどの場合すばらしい働きをしてくれるが、別々の環境でメリットを得るには、時には外部でコンフィギュレーションを行うという選択肢に後戻りしなければならない。XML という選択肢はアノテーションほど魅力的ではないが、複雑なコンフィギュレーションを必要とするケースではうまく動作してくれる。

もっと詳細な比較をすれば何かが明らかになるだろうか?

 

原文はこちらです:http://www.infoq.com/news/2008/10/jaxrs-comparison

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには 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でリプライする

ディスカッション
サイト全般について
バグ
広告
記事
Marketing
InfoQ.com and all content copyright © 2006-2016 C4Media Inc. InfoQ.com and 株式会社豆蔵 InfoQ Japan hosted at Contegix, the best ISP we've ever worked with.
プライバシー
BT