JAX-RS 2.0に関する取り組みが始まった

作者 Mark Little , 翻訳者 能仁 信亮 投稿日 2010年11月17日

セクション

エンタープライズ・アーキテクチャ,

設計/アーキテクチャ,

デベロップメント

トピック

Java EE ,

Java ,

SOA ,

言語 ,

REST ,

エンタープライズアーキテクチャ ,

Architecture ,

プログラミング ,

標準化

共有 |

原文(投稿日：2010/11/14)へのリンク

ここ数年で、Web以外でも、インテグレーション・アーキテクチャとしてRESTが採用されることが増えてきた。その結果として、JavaとJava EEに適切な標準を策定することが避けられなくなり、JSR 311(もしくはJAX-RSと呼ばれることの方が多い)が策定された。この仕様は2008年に最終仕様となり、Java EE6の一部となった。 そこからの間に、欠かすことのできないリファレンス実装を含む、様々な実装が生み出された。多くのJava開発者にとってJAX-RSは有用なものであった。しかしながら、もちろんのことJAX-RS はRESTfulなのかどうかという避けられない議論が行われてきた。

しかし、他のもっとも優れた仕様同様に、実装の経験がJAX-RSにフィードバックされてきており、Oracle(元Sun)のRoberto Chinnici氏が最近次のような発表を行っている...

下にJAX-RS 2.0 JSRのドラフトがある。JAX-RS 1.1の仕様策定が完了して以来、コミュニティの方々の多くとカンファレンスや様々なフォーラムを通してやりとりをしてきた。従ってドラフトのなかに驚くような項目はないだろうと信じている。これから2-3週間のうちに、コメントや示唆を私たちに送ってもらいたい。それと平行して、私たちはスケジュールおよび取引条件を含む未定となっている残りの部分に取り組む予定だ。希望としては、年末の休暇前にJCP Exective Committeeから承認を得られるように、12月上旬にJSRを提出したいと考えている。

提案の主要なポイントには以下のようなものが含まれる。

• JAX-RS 2.0にもっとも広く求められていた機能は、Client APIだ。すべてではないにしろ多くのJAX-RS実装はある程度のClient APIのサポートを行っている。このJSRでは2つのClient APIを定義している。双方ともRESTスタイルに沿ったものだ。ひとつはBuilderパターンを利用したローレベルAPIであり、ハイレベルAPIの方は、前者を活用している。
• Model-View-Controller (MVC)は、Webフレームワークで一般的なパターンであり、ほとんどの場合はHTMLベースのアプリケーションで利用されている。MVCの用語を利用すると、JAX-RSリソースクラスは、コントローラに相当する。このJSRでは、MVCアーキテクチャをJAX-RSプログラミングモデルに従う形で示す。Java Server Pagesはビューの一つとして示される。FreeMarkerやStringTemplateなどの他のビューの技術を組み込むこともできる。
• JAX-RS 1.1は、JSR-330が仕様策定される前のものであり、結果として@InjectのようなJSR-330のアノテーションを本来あるべき姿で有効に利用できていない。このJSRでは、JSR-330 アノテーションとのより密接な連携を策定する。その結果として、@ContextのようなJAX-RSの既存のアノテーションが非推奨になったり、重複したものになる可能性がある。
• JAX-RS 1.1は、サーバ側での同期型のリクエスト・レスポンスモデルを定義していた。このJSRでは、レスポンスをリクエストとは非同期で返すことを可能にするようなシンプルな非同期リクエスト処理モデルを定義している。Servlet 3.0を利用すれば、このようなモデルのサポートは可能だが、実装によっては、その他のコンテナ固有のAPIを代わりに利用することもあるだろう。

Stefan Tilkov氏はこの新しい提案に賛意を表明している。Restlet Frameworkのリード開発者であるJerome Louvel氏は 同様に賛成はしているもののTCK(互換試験キット)に関して懸念を表明している。

私がもっとも懸念しているのは、Restlet Framework (http://www.restlet.org)のようなオープンソースプロジェクトのTCKへのアクセスについてだ。なんども要望(JCP scholarship program経由も含む)しているにも関わらず、私たちはTCKにアクセスできたことがない。JAX-RS 2.0の実装をオープンソースで配布する際の取引条件およびライセンス条項を事前に明確にしてもらえないだろうか。

元々の専門家グループのメンバの一人であるBill de hÓra氏も賛意を表明しており、次の内容を含むほとんどのフィードバックを提供している。

実際に私が見てきた現実的な問題の一つは、システムがクライアントが求める形式で常にエラーを返すとは限らないことだ。単純な例としては、TomcatやJettyがHTMLのエラーページを返すことがあげられる。これはサーバのまつわる品質の問題だということもできるが、この問題が発生してエンティティバインディングが失敗すると、クライアントにとっては厄介な問題となるのだ。JAX-RSのサーバ側で例外マッパをまねたものがあるとよいと思う。他の可能性としては、レスポンスコードに対してハンドラを割り当てることが考えられる。

Roberto氏は、比較的早めにコメントや示唆を送るように求めている。なぜなら彼がいうように「JCP Executive Committeeによる承認を年度末の休暇前にとれるように、JSRを12月初旬には提出したい」からだ。JAX-RS 2.0に関して他に考慮が必要なことはあるだろうか。