最近投稿されたブログ(ブログ・英語)で、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-250Servlet 3.0
JSP 2.2
JSR-45
EL 1.2
JSTL 1.2
JSR-250Servlet 3.0
JSP 2.2
JSR-45
EL 1.2
JSTL 1.2
JSR-250EJB 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.0JAX-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