数日前に承認された、Enterprise Java の最新版は、機能に基づいたプロファイルにより能力を特徴付ける。最初に公開されたプロファイルは、Web 開発者向けの Web Profile であるが、あまりに多くの魅力的な提案で、現場におけるプラットフォームの採用を加速するのに十分であるかは定かではない。
Web Profile の最終ドラフトに述べられているように、理論的根拠は、最新の Web アプリケーションの開発者が提供している、手頃で完全なスタックを目指すことである。その一方で Web コンテナのリソース占有量への制限を、物理的および概念的な条件の両方とも設定することでもある。
完全性に関して、Web Profile は、プレゼンテーションと状態管理を扱う技術(JavaServer Faces、JavaServer Pages)、コア Web コンテナ機能(Servlet)、ビジネスロジック(Enterprise JavaBeans Lite)、トランザクション(Java Transaction API)、永続性(Java Persistence API)、その他、と完全なスタックを提供しています。
簡潔性に関しては、Java EE プラットフォームの一部であるエンタープライズバックエンド API の多くは省略されます。それはまた、アプリケーションが Servlet コンテナを最小限の設定の負荷で拡張するライブラリを使えるようにする Servlet 仕様(例えばドキュメントの 8.2 節をご覧ください)の中の新しい取り外し可能な機能に依存しています。例えば、Java API fro Restful Web Services (JAX-RS) のような標準技術は、完全な Java EE プラットフォームの一部分ですが、Web Profile には含まれていません。web.xml 記述子を変更すること無く Web コンテナに “装着” することができます。
オプションのコンポーネントは無く、Web Profile に準拠するソリューションでは、次の技術が完全に実装されていなければならないことは、言及しておく価値がある。
- Servlet 3.0
- JavaServer Pages (JSP) 2.2
- Expression Language (EL) 2.2
- Debugging Support for Other Languages (JSR-45) 1.0
- Standard Tag Library for JavaServer Pages (JSTL) 1.2
- JavaServer Faces (JSF) 2.0
- Common Annotations for Java Platform (JSR-250) 1.1
- Enterprise JavaBeans (EJB) 3.1 Lite
- Java Transaction API (JTA) 1.1
- Java Persistence API (JPA) 2.0
- Bean Validation 1.0
- Managed Beans 1.0
- Interceptors 1.1
- Java Contexts and Dependency Injection (JSR-299) 1.0
- Dependency Injection for Java (JSR-330) 1.0
Java EE と SE が直面している問題は、プラットフォームを“開放”する計画について Sun がコミュニティを納得させることができないことである。これは、Oracle による継続中の買収に付随した不確実性により、さらに切迫してきている。JCP プロセス中に提起された投票のログが示すように、このような懸念により、組織がプラットフォームの戦略的な投資を行うことを禁止している可能性がある。事実、このことが Apache Software Foundation が Java EE 6 仕様に “反対” を投票した理由だった。
RedHat:
EE6 仕様の仕様リードは、EE6 TCK は"使用分野の制限"を含まないことを承認しました。これは、他の JSR (すなわち SE TCK ライセンシング) で最初 Apache により、提起されたものです。それは素晴らしいことです。けれども、そのような使用分野の制限を禁じている、JSPA(Java Specification Participation Agreement) ルールの明らかな欠如において、同様の問題が、いつ、どこかの JSR で再燃するかもしれないと心配しているままでしょう。その結果として、将来、提出された JSR (Sun Microsystems からであろうとなかろうと)では、特に、仕様リードがその側面の明確な情報を提供し、私たちが投票する時の根拠の答えを得られることを期待します。
Intel Corp.:
EE 6 JSR が最終投票になるまでに、、EE 6 TCK ライセンスは仕様分野の制限をしない、仕様それ自身(仕様の実装を妨げる"付加価値"で無い) で必要とされること以外に何か他のものを実装することを必要としない、JCP 仕様の使用分野を制限する他のライセンスを必要としないという声明を私たちは期待します。
Apache Software Foundation:
Java SE TCK ライセンスについて、私たちは、仕様リード - Sun Microsystems - は JSPA に従っていないと強く主張するので、Apache は JSR-316 への"反対"を悔やんで投票しなければなりません。私たちは、公式文書と統制するルールの精神に従わない JCP のメンバは JSR を率いることは許されないと信じています。これは、技術的功績あるいは今日まで Expert Group が行ってきた作業の品質についての述べているわけではありませんので、Sun による未解決の不服従が無ければ、Apache はおそらく"賛成"を投票していたでしょう。
また、どのベンダがいつ Web Profile を実装しようとしているのか、現時点ではあまり明らかでない。Springsource を通じて、VMWare は最終的にはそうするかもしれない。- 彼らは確かに dm Server の問題追跡の中で話題にしていた、しかし彼らは Web Profile について否定的なコメントも公式に表明していた。例えば、JürgenHöller、Spring framework の共同創立者、は Spring と Java EE 6 についての QCon プレゼンテーションの中で、否定的だった。
このプロファイルを実装することは、あまり魅力的じゃありません。私はまだ完全なプロファイルじゃなくこのプロファイルを実装しようとしているベンダを見たことがありません。
JBoss AS プロジェクトリーダである、Similarly Dimitris Andreadis は、“事前定義された Web 構成”を持つことの目的についての彼の関心事を述べた。
ご存知のように、実際に必要とするサービスのセットへと JBoss AS 構成をスリム化することができます。これは JBoss ではいつでも可能性です。今、事前定義された Web 構成を持つこと、これは現時点では、技術視点よりもむしろマーケティング決定に近いように見えます。能力や機能を削除することは、新しいものを追加することよりも簡単です。差し当たり、私たちは、JBoss ESB、JBoss jBPM と JBoss Rules といった機能性を JBoss EAP の頂点に追加する、JBoss Enterprise SOA Platform を導入することで連鎖をより高い位置に移動することに焦点を当ててきました。しかし、市場の需要が真実ならば、あるいは Java EE 6 プロファイルが前進するならば、私たちはおそらく作成するでしょうし、Web プラットフォームへのバンドルもサポートするでしょう。
事実 JBoss は、彼らのアプリケーションサーバ用の Web Profile のプロトタイプが動作していることを公表した。けれども彼らの現在の提供している、JBoss Enterprise Web Platform は、“エンタプライズ機能で Java EE Web Profile を強化する”。
一方 Hibernate の作者である、Gavin King は、Web Profile の作成は Java プラットフォームにとって良かったことであり、今まで機能の欠けた生のサーブレットコンテナか完全な EE スタックを選定することのオーバヘッドのどちらかを選ぶことを強制させられていた Web 開発者を支援するだろうと肯定的である。
Java EE Web Profile は、たいていの開発者が本当に必要とする技術、Servlet、JTA、CDI、EJB Lite、だけで"より小さな"コンテナを定義します。それは EE をより実装しやすくし、より多くの実装とより短いリリースサイクルで、より活気のある市場となるかもしれません。これは確実に、多くの開発者が Java EE を採用していない主な理由を削除します。
とて素晴らしいことに、CDI ポータブル拡張 SPI によって、より簡単に Java EE 環境へ技術を統合することができます。そして、いくつかの CDI 実装は Tomcat のような生のサーブレットコンテナでも動作します。CDI は、これらの環境へ技術を統合するための基盤として使うこともできます。
同様に、JBoss 前 CTO の Sacha Labourey は、Web Profile の可能性について非常に楽観的である。
JCP EC が Weld と EE6 の最終的な投票を承認したことを知ったときは大きな喜びでした!
これで本当に EE5 で開始した作業を終了します。そして EE6 を一番強力だけれども一番簡単に使える Java 実行環境に明確に位置づけます。明らかに Spring とその XML 設定の多さに勝っています。さらに、強力な Web Profile の定義は、いくつかの大部分のレガシーな EE 仕様(IIOP 誰か?)ように煩わしいことなく、自身の巨大な Tomcat を構築している(そして保守しようとしている)、あまりに多くの IT チームへ新鮮な空気を与えます。
Web Profile について、あなたはどう思うだろうか? それは Java プラットフォームを Web 開発者にとって魅力的なソリューションにするのに役立つだろうか?