プロファイルと拡張性 - Java EE 6の重要なリファクタリング

Java EE 6(JSR 316)の提案（source）が発行された。InfoQでは過去にJava EEの来るべきリリースに向けたコミュニティの構想について取り上げた（source）。リリースに向けての2つの重要なテーマは拡張性とプロファイルである。

...このリリースのための重要なテーマは、全体的なJava EEの展望の一部としてそれらの技術を採用してサポートするために、一方でより広範な開発者を対象としてより良いプラットフォームの簡素化を継続することです。 そのために私たちは、このリリースに向けて2つの目標 - 拡張性とプロファイル - を提案します。

拡張性

Webアプリケーションやエンタープライズアプリケーションの開発者が望むすべての興味深く便利な技術を含めるために、Java EEプラットフォームが際限なく成長することは適切ではないでしょう。私たちはそれよりも、Java EEアプリケーションサーバに対して、きれいにレイヤーを重ねたり機能を組み込んだりするためのより多くの技術を有効にすることが望ましいと信じています。より多くの拡張ポイントやサービスプロバイダーインタフェースを加えることによって、その他の技術はプラットフォームの実装に対して、きれいかつ効果的に機能を組み込むことができ、同時にプラットフォームに組み込まれた設備のように開発者にとって使いやすくなります。

プロファイル

Java EEプラットフォームの範囲はとても広くなり、最初の焦点のいくつかを失いました。Java EEプラットフォームの焦点を再び開発者とアプリケーションの特定のクラスに合わせるために、私たちはJava EEプラットフォームのプロファイルの導入を提案します。プロファイルではJCPプロセスで定義されているようにJava EEプラットフォームを参照します。またプロファイルにはJava EEプラットフォーム技術のサブセットとJava EEプラットフォーム基盤の一部ではない付加的なJCP技術の両方を含めることができます。Java EEプラットフォームの基盤を定義することに加えて、この仕様はJava EEのプロファイルでJava EEプラットフォーム技術を参照するための規則を定義します。

この専門家グループはまたJava EE Webのプロファイル - Webアプリケーションの開発を目的とするJava EEプラットフォームのサブセット - の最初のバージョンも定義します。このプロファイルはJava EEプラットフォームに対してより優しい導入方法を提供し、ほとんどのWebアプリケーションの開発者にとって必要な技術だけを、そのような開発者を時々混乱させるエンタープライズの技術なしで提供します...

提案は、増加の一途をたどるJava EEプラットフォームの規模を切り詰めるためにプロファイルを利用することを提唱する。Java SEの専門家グループよって利用されたプロセスはまた、Java EEのために利用されることも推奨されている。

1. プラットフォームのリリースNのための包括的専門家グループ(UEG:Umbrella Expert Group)は、特定の機能が除外されることについて提案することを決定します。そのリリースのための仕様は提案を文書化します。
2. リリースN+1のためのUEGはそのリリースから機能を除外するか、必要なコンポーネントとして保持するか、または次のUEGで決定するためにそれを「除外が提案された」状態に残すかどうかを決定します。

提案はJava EE 6に含めるための候補としてJSR-237 Work Manager for Application ServersやJSR-299 Web Beansなどの多くのJSRを記載する。これらにはサーブレット、EJB、およびJSFなどのすでに含まれている技術に加えて、JSR-168 Portlet Specification、JSR-170 Content Repository for Java technology API、およびJSR-225 XQuery API for Java(XQJ)などの多くのAPIが将来のリリースに含めるかについて検討されるために据え置かれている。

Interface21のCEOであるRod Johnson氏は、JSRのためのサポートまで宣言している、提案についての長い論評（source）を書いた。

Java EE(その歴史のほとんどはJ2EEとして知られている)はJavaミドルウェアのための市場の創造において重要な役割を果たしました。しかし、それらの10年の間に、重要な問題がプラットフォームに浮上しました。例えば、 

• Java EE準拠のサーバが、大部分の利用者にとって関心の薄い一連の機能性によって、肥大化することの必要性
• J2EEが構想されてからエンタープライズの要求が変化して「1つのサイズにすべてを適合させるモデル」が次第に適切ではなくなったという事実
• 開発者をより生産的にして、彼らの生産アプリケーションをより効率的かつ維持できるようにする(特にオープンソースの)フレームワークの出現によって、エンタープライズJavaが大いに強化されているという事実
• Ruby on Railsなどの新しい挑戦が、そして.NETまでもが、急速な変化と革新の時を迎えて、居心地の良い2～3年のリリース周期がプラットフォーム全体を危うくすることを示している

Java EE 6は、これらの問題のすべてを扱うための潜在能力がある、重要なプラットフォームの改訂です。それにはまた、別の問題を扱うための潜在能力があるかもしれません。もしEEのベンダーが、彼らの顧客のほとんどが決して利用することのない非常に広範な機能性に対して保証する必要があるなら、それは仕様に追従することが彼らにとって困難であることを意味します。それは安定したアップグレードを行うことへの挑戦です。そして重要なことはそれによってJava EE市場への新規参入者の可能性が無くなるということです。最後の問題に関して、実際にはそれは現職者にとって居心地の良い特権のためで、EEサーバの利用者のためではありません。新しいプラットフォームをリリースすることの難しさを確認するために、Java EE 5の仕様の最終リリースから何ヶ月も経つのに、現時点では、私の知る限り、BEAだけが市場のリーダーとしては唯一、Java EEに準拠しています。そして、JPAなどのJava EE 5において最も重要な新しい部分は、最終リリースの何ヶ月も前にWebLogicでは準備ができていたのに、おそらくほとんどのWebLogicの利用者が決して触れることのないいくつかの技術についての問題が解決されるまで、一般に利用可能(Generally Available:GA)な製品としてリリースすることができませんでした...私はエンタープライズJavaのコミュニティがJava EE 6を歓迎し、時代に即してエンタープライズJavaのプラットフォーム全体の強化を選択するSunの意欲を歓迎することを信じています。J2EE/Java EEには多くの良いところがあるのに、問題のいくつかがそれを覆い隠してしまいました。Java EE 6ではそれを変えるべきです!