エンタープライズ向けJava標準化の歴史
標準規格の再編成 ～Java EE5～
軽量フレームワークによる開発が一般的になっていた2006年、Java EE 5がリリースされました。それまでのバージョン呼称（J2EE 1.x）を改めたこのリリースは、J2EE時代から大きな変化を遂げていました。特に、企業システム開発における技術標準の整理の観点から見ると、2つの点が重要であったと筆者は考えています。1つは、デファクト標準化した優れたオープンソースの技術をJava EEへ迅速に取り込む構図を作った点、もう1つは、MVCフレームワークの標準規格を定めた点です。
1つ目のポイントについては、オープン性を指向するJava本来の標準化プロセスがうまく機能した結果と言えると思います。EJB3の仕様策定グループは、J2EE不要を唱（とな）えてデファクト化していたDIコンテナの技術を大幅に取り込むとともに、オープンソースO/Rマッピング・ツール「Hibernate」の作者・Gavin King氏をメンバーに加えることでそのノウハウを標準規格として整理しました。
その結果、Java EE 5に含まれるEJB 3.0は、EJBコンテナ自体にDI×AOP機能を備え、従来複雑だったEJBコンポーネントをPOJOで開発できる軽量フレームワークとして刷新されました。また、POJOベースのO/Rマッピング仕様である「JPA」（Java Persistence API）も策定され、Java EEの主要機能が軽量フレームワークと同じ容易さで利用できるようになりました。こうした、デファクト標準と密接に連携した標準化体制は、後述するJava EE 6の策定でもそのまま生かされています。
2つ目のポイントは、一見地味ですが、企業システム開発の標準基盤の整備に向けて大きな意味を持っていたと考えています。Java EE 5では標準MVCフレームワークとして「JSF」（JavaServer Faces）が選定されました。標準規格になれば、Java EE対応のアプリケーション・サーバー製品はJSFの機能を内蔵することになります。すなわち、ユーザーは自分で何らかのMVCフレームワークを選定する必要がなくなるということです。
従来、スキル・レベルの統一が難しい企業のシステム開発では、MVCフレームワークが、開発を標準化／統制するための最も重要な技術要素でした。Servletを中心にView側とModel側とでそれぞれ開発対象を定義し、それを軸に設計書や設計手順を標準化して、自社用の開発標準を構築していたのです。この部分が標準規格として整備されることは、冒頭で述べたような、企業におけるシステム開発の『共通基盤』の選択肢として、汎用的でライフ・タイムの長い技術を提供してもらえることを意味します。
これらの観点から見たJava EE 5は、単なる開発技術の進歩というだけではなく、Java EEがデファクト標準の成果をもとに、アプリケーションの作り方に標準的な枠組みを与える方向へレイヤーを拡大していく（図3-1）という、今後のJava標準基盤の方向性を指し示してくれるものだったと言えると思います。
ただし、Java EE 5の時点では、まだ標準化が不十分な領域が残されていました。それを補完するための試みは、Java EE 5のリリース時点ですでに始められていました。それが次に紹介する「JBoss Seam」です。
フレームワークの統合とその標準化の流れ
Java EE 5では、JSF、EJB3、JPAという技術領域ごとの標準仕様が規定されました。しかし、JSFとEJB3（JPA含む）はもともと設計の土台が異なっており、それぞれ別のコンポーネント・モデルを持っています。こうした別々のフレームワークを併用するには、フレームワーク同士を結びつけるための手続きが必要です。
前述のStruts-Spring-Hibernateでは、選定してきたこれらのフレームワークをつなぎ合わせる役割は主にDIコンテナのSpringが果たしていました。しかし、こうした組み合わせの技術は当然、標準化されたものではありません。違うフレームワークを選定した場合は、その仕様に応じて組み合わせ方を再検討する必要があります。こうした「フレームワークの組み合わせにかかるコスト」に対する問題意識は強く、すべてのフレームワーク機能を統一的にサポートするフルスタックのフレームワークの必要性が意識されるようになってきていました。
そこで、Java EEにおいてフルスタック・フレームワークを実現するために登場したのが「JBoss Seam」（以下、Seamと略す）です。Seamは、JSFとEJB3のコンポーネントに統一的なアノテーションを付与することで、それらをすべて「Seamコンポーネント」として一元管理し、相互にDIを実行する機能を提供します。
Seamは「縫い合わせる」という名前の通り、フレームワーク間に統一的なDI×AOPの機能を提供することで、フレームワークを統合する役割を担っています。SeamはJava EE 5標準フレームワーク群を統合するというその趣旨から、早くからJava EE 6での標準仕様化が検討されていました。Seamの具体的な機能は第2回で解説しますが、このほかにも「コンテキスト」と呼ばれるコンポーネントのライフ・サイクル管理機能などが今後の標準仕様の中核になると予想されていました。
NRIでは2006年ごろからJava EEの拡大と統合の動きを見据えて次世代のWeb開発フレームワークの開発に取り組み、「ObjectWorks＋ R1.0」のJava EE 5対応版としてリリースしています。これは、Java EE 5をサポートするアプリケーション・サーバー上でSeamを使ってJava EE 6と同様の構成を作り、その上で企業システム開発向けに必要な部品群と開発ノウハウを提供するフレームワークです。これについては、第3回、第4回で詳しく解説します。
そしてJava EE 6へ
最後に、Java EEをめぐる直近の動きを見ておきましょう。
ちょうど先月（2009年12月）、Java EE 6の仕様が最終リリースされました。その最大の特徴の1つが、Java EEの標準規格となったフレームワーク群全体にわたる統一DI仕様を定めたことです（図3-2）。このDI仕様は「JSR-299：Context and Dependency Injection for Java EE Platform」（以下CDIと略す）と呼ばれ、SeamのコンテキストとDIの仕様が元になっています。これにより、Servlet, JSF, EJB3, JPA, JMS（Java Message Service）, JAX-WS（Java API for XML-Based Web Services), JAX-RS（同 RESTful Web Services）といったJava EEのコンポーネントがすべて、ひとつのDI仕様のもとで統合できるようになりました。
同時に、「JSR-330： Dependency Injection for Java」でDIに用いるアノテーションの仕様が標準化されました。JSR-330の策定には、「J2EE without EJB」時代にデファクト化したDIコンテナのSpringとGoogle Guiceのコミュニティが携わっており、これらのDIコンテナとCDIとは、JSR-330で定めた同じアノテーション仕様を共有しています。
CDIは、当初は「Web Beans」という名称で参照実装が開発されていましたが、最終的には「Weld」（溶接する）という名称になりました。WeldはJava EE 6の参照実装アプリケーション・サーバーであるGlassFish v3にも搭載されています。
米Sun MicrosystemsのWebサイトでは、GlassFish v3を同梱（どうこん）した統合開発環境の「NetBeans 6.8」や「GlassFish Tools Bundle for Eclispe」が配布されており、実際にJava EE 6を使ったアプリケーション開発を簡単に試してみることができます。
紹介した各種フレームワークが標準で搭載されていますので、フレームワーク・ライブラリを別途用意したりする必要はなく、例えばシンプルなWebアプリケーション開発プロジェクトにbeans.xml（CDIの設定ファイル）を配置するだけで標準DI×AOP機能を利用することができるようになります。これこそ、フレームワークの標準仕様化の恩恵といえます。
また本記事では詳しく触れませんが、EJB 3.1ではEARファイルではなくWARファイル内にEJBコンポーネントを格納できるなど、より簡単にJava EEアプリケーションを開発できる工夫が詰め込まれており、実際に試してみるとその手軽さに驚かれると思います。ぜひ試してみてください。
ここまで、Java EEがデファクト標準の技術を基にフレームワーク全体を統合して、より軽量にアプリケーションを開発できる仕組みとして再編したことを、これまでの流れを振り返りながら解説してきました。Java EE 6はリリースされましたが、主要なアプリケーション・サーバー製品の対応が出そろうには、もう少し時間がかかるものと思われます。現時点では、「Java EE 5対応サーバー＋JBoss Seam」で構成された、Java EE 6と同様のフレームワークが、企業システムでの実績を積み重ねている段階です。
次回は、この「JBoss Seam」について、特徴を詳しくご紹介します。
