BT

Java EE 6 スペックリードがWeb Profileオプションに関してコミュニティからのフィードバックを求める

| 作者: Ryan Slobojan フォローする 0 人のフォロワー , 翻訳者 編集部 フォローする 0 人のフォロワー 投稿日 2008年2月29日. 推定読書時間: 6 分 |

最近投稿されたブログ(ブログ・英語)で、Java EE 6 (JSR 316)(source)仕様の共同リードであるRoberto Chinnici氏(ブログ・英語)がJava EE 6 Web Profileの有力な2つの対象を提示し、その2つの選択肢のうちJSR 316 Expert Groupはそのどちらとやっていくべきかということに関して、コミュニティにフィードバックを求めた。この機会を利用しInfoQは、 Web Profileのオプションそれぞれについてかなり細かく分析することにした。

Java EE 6に伴う新しい考えの1つには、プロファイルの考えがある。それに関しては、こちらのInfoQの記事(参考記事)で詳述されている。時間の制約およびリソースの制約 が主な原因で、Java EE 6は1つのプロファイルしか持たず、それはWeb Profileである。Chinnici氏は、これを利点として説明している。

プロファイルをめぐる主力な考えの1つは、プラットフォームのデリバリー用のビックバン模型から脱皮することであり、さらに小さく、定義したコンテキスト において集中的なコミュニティが前進するのを可能にしている。そこで自分自身のスケジュールで完了できるようにするために、最初からできる限り分離して、 プロフィルを別々のJSRに置くことは当然である。

もともとは、Web ProfileをJava EE 6 JSRの一部として定義することを提案した。というのは、(1)プロファイルの概念を展開するときに、ユースケースを真空とは対照的にむしろ手近に置くこ とが便利であり、(2)市場やコミュニティ内で、EEプラットフォームのWeb集中のプロファイルに対する興味があると信じているからである。ついでなが ら、Web Profileが生成したEGメールの量および深度は、1点目を裕に証明した。

Chinnici氏は、コンポーネントテクノロジーを並べてリストしつつ各Web Profileオプションを提示し、完全なJava EE 6テクノロジーのスタックが比較のためリストアップされた。

(A) (B) Full platform
Servlet 3.0
JSP 2.2
JSR-45
EL 1.2
JSTL 1.2
JSR-250
Servlet 3.0
JSP 2.2
JSR-45
EL 1.2
JSTL 1.2
JSR-250
Servlet 3.0
JSP 2.2
JSR-45
EL 1.2
JSTL 1.2
JSR-250
  EJB 3.1 (Lite)
JTA 1.1
JPA 2.0
JSF 2.0 *
Web Beans 1.0 *
EJB 3.1
JTA 1.1
JPA 2.0
JSF 2.0
Web Beans 1.0
    JAX-RS 1.0
Connectors 1.6
JAX-WS 2.2
JAXB 2.2
JSR-109 1.2
JSR-181 1.1
JMS 1.1
JAF 1.1
JavaMail 1.4
JSR-115
JSR-196
JSR-88 1.2
JSR-77 1.1
JAX-RPC1.1
JAXR 1.0

またChinnici氏は提案Bにある * で示された2つのテクノロジーのを含めるのは、意見の分かれるところであり、EJB 3.1の機能の提案されたサブセットは、「EJB 3.1 Lite」を参照しており、依然としてEJB 3.1 (JSR 318) Expert Groupで承認される必要があると述べた。

Web Profileの議論で重要な役割を果たすJava EE 6のもうひとつの機能は、拡張性である。

Web層では、拡張性は非常に簡易化されたプログラミングモデルを持った、第三者のフレームワークを利用する機能のことを指す。デベロッパは手動で web.xml記述子を編集し、 Webフレームワークによって指定される命令ごとにコンテキストリスナー、フィルタ、サーブレットおよびサーブレットマッピングを追加する必要がない。そ れどころか、第三者のjarをWebアプリケーションに追加するとデベロッパ介入なく、これらすべてのエレメントの追加の原因となる。この機能がJSF、 StrutsおよびSpring MVC、JRuby on RailsおよびGrailsのようなスクリプトソリューション、 JAX-WS 2.0またはJSR-109モデルおよび JAX-RS 1.0に書き込まれるRESTful Webサービスに従ったWS-*Webサービスなどの主要なWebフレームワークの要求に応えるものと期待している。ここで述べておくべき重要な点の1つ は、テクノロジーがJCP規格に基づいているかどうかは、拡張性には無関係だということである。

またChinnici氏は、Web Profileは基礎となる仕様を目的としており、テクノロジーの総合的なリストではない。ベンダーは新たな拡張可能なコンポーネントを自由にWeb Profile準拠のJava EE 6実装に追加することが可能で、それはアプリケーションサーバがモジュールのインフラストラクチャーを提供するという最近の試みを補完することを意図して いると指摘した。Chinnici氏は、何人かのベンダーがJava EE 6のテクノロジーをWeb Profileの基礎と掛け合わせたり、競わせて市場をテストし、その機能が人気をはくし次回のJava EE 6のプロファイルの基礎を形成することを期待している。

現在のテクノロジーの対話に関する要求もまた、すべてのコンポーネントテクノロジーを含むプロファイル向けのJava EE 6 仕様で維持される予定である。たとえば、JTAとサーブレット間の対話は、Web ProfileオプションBに適用されるが、Web ProfileオプションAには適用されない。その理由はJTAがオプションAの一部ではないからである。Chinnici氏によると、その理由は以下の とおりである。

[...] Java EEの命令に準拠した方法でJTAを実装する多くのサーブレットコンテナーによって証明されているように、Java EEの要求が独立型テクノロジーに重要な意味をもたらしていると考える一方で、要求の呼び出しはプロファイルをターゲットとするアプリケーションがフルプ ラットフォームで動作することを確実にするのに役立つ。全般的に見れば、これによってプロファイルは単に個別にテストされたテクノロジーの集合体にとどま らない。なぜならば、このテクノロジーは興味深い方法で結びつき、個々でするよりもさらに豊富な機能を提供するからである。

最後に互換性の質問が持ち上がったが、Chinnici氏はWeb Profileに加えてその他のJava EE 6コンポーネント(たとえばJAXB 2.2)を必要とするアプリケーションはすべて、プレーンなWeb Profileでは実行できないと指摘した。これに対するソリューションは、Java EE 6テクノロジーのサブセットで実行するすべてのアプリケーションは、テクノロジーの完全なセットでも同様に実行するという考えのもと、全Java EE 6プロファイルとして提供されている。

どちらのWeb Profileを選択するか?オプションAか、それともオプションBか?

原文はこちらです:http://www.infoq.com/news/2008/02/java-ee-6-web-profiles

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには 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