Java EE 6への最終的な認定投票を経て、Sunは今日、Java EE 6 SDK、GlassFishバージョン3、NetBeans 6.8をリリースした。エンタープライズ分野のJava開発者にとってのEE 6の重要性や仕様策定の過程で学んだアーキテクチャの重要な点、そしてこの先、このプラットフォームがどこへ向かうのかについてInfoQは EE 6 の仕様策定者であるRoberto Chinnici氏に話を聞いた。
Java EE 6の仕様が初めて公開されたとき、この仕様は3つのテーマに要約できた。それはすなわち、拡張性の改善、Profileの追加、そして冗長なAPIの除外だ。EE 6が提供する機能はこの3つの分野にまとめられる。拡張性については、とりわけCDIポータブル拡張SPIによってJava EE環境と追加機能の統合が大幅に簡単になる。また、Profileの一般的な定義を策定し、Web ProfileというProfileを導入した。これによってサーブレット、 JPA、JTA、JSF、CDI、EJB LiteのようなWebアプリケーションの鍵となるコンポーネントを含むコンテナが提供される。そして、ほとんど活用されていない機能が除外された。例えば、EJB Entity BeansやJAX-RPC、JAXRそしてJava EEデプロイメントは未来のリリースでオプションのコンポーネントとなる可能性があるとされているが、今回のリリースでは除外されている。
同時にEE 6では、プラットフォームの主要点の総検査が行われ、Java EE 5と同じように開発の作業を簡単にしようとする試みがなされている。このプラットフォームが正式にローンチされたとき、私はSun Microsystems社のRoberto Chinnici氏に話を聞いた。氏はEE 6の仕様策定者のひとりである。まずは開発者の視点から上述したテーマの重要性について話を聞いた。
Chinnici: ほとんどの開発者にとって利益がある取り組みとしてWebの開発を簡単にする新しい方策とProfileの導入しています。"開発の簡単さ"について考えると、ほとんどの開発者はアンテーションベースのプログラミングモデルにその答えを見つけます。私たちはJava EE 6のサーブレットに対してこのようなアンテーションベースのプログラミングモデルを導入しました。またその他にもWebアプリケーション開発を単純にしてくれる多くの機能があります。例えば、JAX-RSのように強力で簡単に利用できるAPIが追加されたり、JSF 2.0のように改善されたものもあります。また、妥当性検証と依存性注入についても標準APIを導入しました。これらのAPIはWebだけでなくすべての層で利用できます。さらに、これも同じように重要なことなのですが、アプリケーションのパッケージングも単純化しています。例えば、EJBのコンポーネントをWebアプリケーションの内部に直接配置したり、記述子の省略も可能です。これらすべての新しい特徴を使うことで、アプリケーションのコード量は減少し、完璧なWebアプリケーションを作り上げるために必要な機能を提供する外部ライブラリの数も減るでしょう。
InfoQ: EE 6の新しいAPIやアップデートのなかで特に重要なのは何ですか。あなたが心の底から喜んでいる新機能は何かありますか。
Chinnici: あります。ちょっと多くなってしまいますが。APIについて言えば、JAX-RS、Bean Validation そして Contexts and Dependency Injection for Java EE (CDI)とったところでしょうか。加えて、EEの既存のAPIのうち主要なものはすべて新しくなっています。Servlet、EJB、JPA、コネクタそしてJAX-WSなどです。私はいくつかの新しいAPIのできばえに非常に満足しています。例えばJAX-RSです。強力なAPIを作り上げることとそのAPIを単純さを保つことの間の真ん中になんとか納めることができたと思っています。初心者から経験豊富な開発者まで、そして小規模なプロジェクトから複雑なプロジェクトまで、幅広く利用できるAPIを作ることができました。
私が多くの注意を払った要素のひとつに、プラットフォームのすべてのコンポーネントの連携方法があります。これに関して、Java EE 6ではAPIの間にあった多くの障壁を取り除くことができ、とても満足しています。それらの障壁のほとんどは過去の遺物なのです。また、未来のEEアプリケーションの共通基盤になりうCDIのような技術を導入しました。
InfoQ: web profileが成功するかどうかについてはどのように判断しますか。
Chinnici : 採用されるかどうかでしょう。もちろん、開発者が本当にweb profileを採用するのはベンダがweb profileを実装した製品を出荷するようになってからかもしれません。しかし私が思うに、web profile自体は新しいベンダにとって魅力的なはずです。web profileのすべてのAPIがオープンソースの実装を持ち、多くが複数の実装を持っていることを考慮すると、サーブレットコンテナのベンダはweb profileの製品を提供することはそれほど難しくないと思います。JavaのWeb開発者が普通のサーブレットコンテナの代わりに、web profileのような今まで以上にリッチなプラットフォームをターゲットにしてアプリケーション開発を行う日を楽しみにしています。
InfoQ: 後方互換性の必要性と既存機能の除外のバランスをどのようにとっていますか。
Chinnici: まず第一に、機能除外の過程によれば、どのような機能もオプションにされるまでには2回のリリースがあります。この間に開発者はある特定のAPIの利用を中止したほうがいいという事前警告を大量に受けます。そして、一度その機能が取り除かれてしまっても、その機能はまだ完全に定義されていて、除外される前のすべての互換性テストにも耐えられます。したがって、例えばあるベンダがそのような機能を出荷してしまっても互換性は間違いなく確保されています。
InfoQ: Java EE 6ではプラットフォームの中で、異なるコンポーネントやフレームワーク、言語を混ぜたり合わせたりするのをどのようにして簡単にしてくれますか。
Chinnici: 先に紹介した、Web分野の"開発の簡単さ"を推進する取り組みのひとつとして、Webアプリケーションのライブラリを自己登録をする方法を導入しました。この方法によってフレームワークを構成するための煩雑な作業を取り除けます。ほとんどの場合、私たちはこの自己登録をweb-fragment.xml記述子を使って宣言的に行おうとしますが、アプリケーションの起動時にプログラムをつかって登録を行うこともできます。これはスクリプト言語にとっては特に面白い方法です。この方法を使えばスクリプト言語は相当凝ったやり方でコンテナにアクセスできるからです。私たちはこの設計について、様々なフレームワークやライブラリ上でWebコンテナ内で着脱可能性の高さを検証しました。なので、数年のうちにこの方法が役に立つようになると信じています。あとはCDIにも強力な拡張機構があることも説明しなければなりません。フレームワークの作者はこの機構を利用できます。実際には"bean"の発想を抽象化し、CDI内のSPIとして形式化しました。これは拡張機能がbeansをどこからでも作成できるようにし、コンテナに登録できるようにするためです。これは、制約の全くない機構です。拡張機能を通してコンテナに価値ある振る舞いを追加できるようにすることで将来にわたって使い続けられるようにしているのです。
InfoQ: Java EEの主要なアーキテクトとして活動してきた中で学んだ、設計上の最も重要なことはなんですか。Java EEの設計上の最大の失敗点は何だと考えていますか。
Chinnici:それは、APIは"そのAPIが意味する通りに動作する"べきだということです。つまり、APIを設計しているときは、賢くやってはならないということ、とくに設計自体のために賢くやってはならないということです。今日、賢く作ってみたところで、2年もたってしまえばくたびれて見えるのは避けられません。それよりも物事の単純さを保ち、どんなAPIでも設計の意図が明確になっていることのほうが重要です。
EEの中から特定の最も大きな設計上の失敗を見つけるのは、私にとっては難しいです。嫌いなものがないという訳ではありません。例えば私は、最初のJNDIの利用方法は好きではありません。なぜ難しいかというと、何度も仕様策定にかかわったことで、すべての制約の中で優れた解決策を見つけるのが本当に難しいことだと理解したからです。例えば、私たちが批判することのほとんどは、同じ状況においてみればやはり同じ結論に達するのではないでしょうか。なので私は、どちらかと言えばプラットフォームに含まれたより良いことを識別するように心がけています。それらの良いことは、大抵は誰かが余計に働いてくれたおかげで生まれるのです。
InfoQ: オープンソーシングなJavaはJava EE の進化に影響を与えましたか。
Chinnici: もちろんです。Java EEのAPIには複数のオープンソース実装があります。そのおかげでとてもダイナミックな開発者や利用者のコミュニティが出来上がっています。彼らからのフィードバックのおかげで私たちもよいアイディアを選択することができますし、そのアイディアをプラットフォームの一部として標準化することもあります。また、オープンソースの実装の中に私たち自身のアイディアを提案することもあります。それは私たちの実装には移植できないアドオン機能であることもあります。その上で、フィードバックに基づいて対応するAPIをリリースするかどうかを決定します。例えば最近だと、JerseyのクライアントAPIがそうです。このAPIは次のバージョンのJAX-RSに含まれるでしょう。このケースはとても健全なオープソースコミュニティとの交流だと思います。
InfoQ: Java EEはこの先、どのような方向へ進んでいくと考えていますか。
Chinnici: 短期で考えると、profileのことで私たちはしばらく忙しいままでしょう。web profileは良いスタート地点だと思います。しかし、profileの可能性についてはまだまだ追求しきれているとは言えません。profileの定義はとてもとても一般的なものです。ほとんどのprofileの間でコードやスキルの再利用ができるようにするため、profileは互換性を保持しています。したがって、Java EEコミュニティはどのprofileを定義し、どんなコンテンツを利用するのかをとても自由に決定できます。また、Java SEをEEを形作る手助けをするものとして考えるのも大きな方針です。例えば、モジュール性や閉包性などです。私の考えではJava EEの開発者はまず第一にJavaの開発者であり、したがってJava EEプラットフォームはSEの新しい特徴を活用して、Java EE開発者の日々の体験をよりよいものにすべきだと思います。
そして最後に言えるのは、JavaプラットフォームがJava言語だけのものでなくなるのが次第にはっきりしてきているということです。 Java仮想マシン上で動作する数多くの言語が成熟してきています。例えば、Scala、Groovy そして JRubyです。Java EEとこれらの言語はこれからもっと親和的になるでしょう。結局のところ、これが古びないプラットフォームになるための最良の道のひとつなのです。
SunのGlassFishと同様、JBossもアプリケーションサーバをEE 6に対応させ、CDI、JSF 2 そして Bean Validation をサポートした AS 6.0.0のマイルストーンリリースを行った。IDEについてはJetBrains社が今週出荷したIntelliJ IDEA 9がエディタレベルでEJB 3.1、JPA 2.0、Servlet 3.0、JSF 2.0、CDI、Bean ValidationをサポートしGlassFish 3も統合されている。NetBeans 6.8がサポートするのはGlassFish 3を使った段階的なデプロイメントだ。また、JSF 2.0/Facelets、Java Persistence 2.0、Webアプリケーションでの利用も含んだEJB 3.1、そしてRESTfulWebサービスをエディタレベルでサポートしている。SunはEclipse用のプラグインも開発した。このプラグインを使えばGlassFish 3をサポートできる。ここからダウンロードできるツールもサポートしている。