エンタープライズ向けJava標準化の歴史
企業情報システムを支えるJava
JavaでWebアプリケーションを開発する際にフレームワークを利用することは、すでに当たり前になっています。JavaのWeb開発フレームワークは、細かい技術領域ごとに商用／オープンソースを問わず多数のプロダクトが入り乱れており、それらの特徴／メリットもさまざまです。そこで、プロジェクトの特性に応じたフレームワークをその都度選択して組み合わせて使うことが一般的になっています。
一方で、基幹系アプリケーションを含む大規模なシステムの構築をミッションとするユーザー企業の情報システム部などでは、限られた人材で品質と生産性を安定的に維持するために、「自社のすべてのアプリケーション開発を支える『共通基盤』を整備したい」というニーズが根強くあります。この場合は、JavaのWebアプリケーション開発のための基盤についてもその都度選択するのではなく、何らかの汎用的な標準を定めて体制や共通ライブラリなどの整備を行うことが求められます。
Javaの場合、汎用的な利用を想定した標準技術としては、企業情報システムの構築に必要なAPI仕様を公式の標準化プロセスによって定めた「Java EE」（Java Platform, Enterprise Edition）があります。しかし、これまでこのJava EEの標準機能だけでは開発に必要な機能がそろわず、上記のような『共通基盤』を検討するケースにおいても標準以外のフレームワークを別途ユーザー自身が選定することが一般的になっていました。とはいえ、Javaのフレームワークが非常に多様であるために、汎用性を維持しつつ全体最適な標準を定めることに課題を抱えているケースが多く見られました。
ところが、上記のようなJavaの技術環境は、ここ5年ほどで大きく変わってきています。公式の標準であるJava EEが、オープンソースの世界で発展してきた（非公式な）デファクト標準のフレームワーク技術を取り込んで標準規格化する、という構図が顕著になり、少なくとも従来のフレームワークが提供してきた主要な機能はJava EE標準のみで十分にカバーできる環境がすでに整っています。
こうした流れから、今後のJavaのフレームワークは、標準規格化されたフレームワーク技術の仕様に準拠して、汎用的な機能や設計ノウハウを提供することが一層求められていくと考えられます。前述のような『共通基盤』構築のケースでは、できる限りこうした公的な標準に準拠した技術を選択することで、「汎用的に長い間使える標準基盤」を整えることができるようになります。
本連載では、「企業情報システム開発の共通基盤」としての存在感を再び増してきているJava EEの動向と、その上で実際に企業向け情報システムを構築する際のノウハウを集約した野村総合研究所（NRI）の開発フレームワーク「ObjectWorks＋」について解説します。第1回の今回は、Java EEとその周辺のフレームワークの変遷について、技術仕様の標準化の観点から簡単に振り返ります（図1）。
Javaの仕様標準化プロセスの変遷
技術的な変遷を追う前に、まずJavaの標準化プロセスについて簡単に確認しておきましょう。
現在のJavaでは、APIの「仕様」と「実装」が明確に区別されています。仕様は実装とは独立して文書化されており、例えば、「Servlet」（サーブレット）の仕様に従ってアプリケーションを作れば、Java EE仕様に準拠して実装されたどのサーブレット・コンテナの上でも正しく動作することが期待できます。そして、Java EE仕様の対応製品を作ることが、ベンダーだけでなくオープンソース・コミュニティによっても認められており、米IBM、米Oracle、米Red Hat（JBoss）など複数のベンダーやコミュニティが、Java EE対応アプリケーション・サーバー製品をリリースしています。こうした「仕様と実装の分離」とそのオープン性はJavaの大きな特徴であり、現在のエンタープライズ分野での繁栄の一因ともなっていると考えられます。
こうしたJavaの標準化プロセスは、どのように発展してきたのでしょうか。
まず、1999年に標準化プロセスとして「JCP」（Java Community Process）が導入され、「JSR」（Java Specification Request）の提案をもとに、仕様の文書化と、そのお手本であるリファレンス実装（参照実装）を分けて開発する現在の仕組みが形作られました。またこの年、参照実装をオープンソース化する初の試みが行われ、サーブレット・コンテナの「Tomcat」が誕生します。その後、2002年に発表された「JCP 2.5」によってすべてのJSRのオープンソースによる実装が可能となりました。その後、2005年にはJava EEアプリケーション・サーバー全体をオープンソースで開発する「Project GlassFish」が始まり、仕様がリリースされるとともに、利用可能な参照実装がオープンソースで提供される流れが定着しました。
このように、Javaは当初から仕様策定と参照実装のオープン性を意識しており、コミュニティの知見を標準仕様へと反映させる体制を意識的に作り上げてきました。そして後で述べるように、オープンソース・コミュニティから生まれた多くの開発技術が標準仕様へ還元されつつあります。
それでは次ページから、Java EEとその周辺の開発フレームワークの技術的な変遷を見ていきましょう。
エンタープライズ利用の道を開いたMVCフレームワーク
サーバーサイドJavaの最も基本的な機能であるServletと「JSP」（Java Server Pages）は、「JDBC」（Java Database Connectivity）や「JTA」（Java Transaction API）といったほかの基本的なAPI群とともに1999年に「J2EE」（Java 2 Platform, Enterprise Edition） 1.2にまとめられました。これによって、Javaで企業システム向けWebアプリケーションを開発するための最低限の基盤が整いました。
しかし、この時点ではWebアプリケーション開発のための素材が提供されただけであり、こうしたシンプルなAPIを使って実際の開発をするにはノウハウが必要でした。そこで、アプリケーションに一定の構造的な枠組みを与え、汎用的な機能を部品化することで設計とコーディングを簡単化する「開発フレームワーク」が登場します。特に、プログラムをModel（モデル）、View（ビュー）、Controller（コントローラー）の役割に分割して並行開発を可能とするMVCフレームワーク（図2-1）がその中心となりました。
この時期に多くのベンダーがMVCフレームワーク製品を開発・提供しましたが、オープンソースの世界では2001年に「Struts」が登場します。画面アクションごとにフォーム格納クラスやアクション・クラスを作成するというシンプルな構造であり、その取り組みやすさや無償であることなどから爆発的に普及が進みました。この後しばらく、StrutsはオープンソースMVCフレームワークのデファクト標準として認知されるようになります。
これらの商用／オープンソースのMVCフレームワークは、Servlet＋JSPといった素のAPIだけでは難しかったWebアプリケーションの設計・開発を、一定のスキル・レベルでも安定して実施できるようにすることで、Javaのエンタープライズ利用への道を開いたと言えます。ですが、この後しばらく、いずれかのMVCフレームワークがJava EE標準として整理されることはありませんでした。
軽量フレームワークの台頭 ～J2EE without EJB～
MVCフレームワークによって企業システムにJavaが普及していくなか、Java EEは着々と企業システム開発に必要な機能を整備していきました。J2EE 1.3（2001年）やJ2EE 1.4（2003年）では、「EJB」（Enterprise JavaBeans）（2.0、2.1）によってトランザクション管理やデータベース・アクセスといった機能を大規模／分散環境に提供する基盤が整えられました。
しかし、EJBは早くから重厚で難解な仕様が問題とされ、EJBを隠ぺい化してアプリケーション開発者に意識させないようにするためのデザイン・パターンやフレームワークが開発されました。
一方で、EJBが提供するような重厚な機能群を必要としない開発現場では、より簡単にアプリケーションを作成するための技術の研究が進みました。そして登場したのが「Spring」や「Seasar2」に代表される「DIコンテナ」（図2-2）と、「Hibernate」や「TopLink」といった「O/R（Object/Rerational）マッピング・ツール」（図2-3）です。これらはいずれもオープンソースのプロダクトとして登場し、EJB 2.xが実現していたことをより簡単に実現できる環境を作りました。
DI（Dependency Injection）コンテナは、EJBのような重量級のコンポーネント管理の仕組みを使わずにコンポーネント間の依存関係をフレームワーク側から制御し、アプリケーションを「POJO」（Plain Old Java Object、特定のフレームワークやコンテナが提供する機能を継承／実装しないクラスのこと）として開発するスタイルを確立しました。また、このDIを応用して、ログ出力や認証などの横断的処理を外部から差し込む「AOP」（Aspect Oriented Programming、アスペクト指向プログラミング）機能も提供されました。こうした技術でEJBの重要な機能であった宣言的トランザクション管理なども容易に実現できるようになったことから、「EJBコンテナは不要」という考えが加速されました。
O/Rマッピング・ツールは、EJB 2.xが備えていたエンティティBeanによるJavaオブジェクトと関係データベースの自動マッピング機能を、やはりシンプルなPOJOベースで可能にし、データベース・アクセス処理の抽象化をよりスマートに実現しました。
フレームワークの組み合わせ利用が一般化
これらの軽量フレームワークが高い生産性を発揮したことから、2003年～2006年ごろには、MVC、DI×AOP、O/Rマッピングの各機能について、それぞれデファクト化したいくつかの選択肢からプロダクトを選定し、組み合わせて利用することが一般的になりました。特にStruts-Spring-Hibernateといった組み合わせが有名になり、EJBコンテナを持たないサーブレット・コンテナ上の軽量フレームワーク開発が広まりました。この時期は、公的な標準であるJava EE（J2EE）が相対的に影響力を弱めていたと言えるでしょう。
また、技術領域ごとに競争が促進されることで多数の優れたプロダクトが生み出される一方で、フレームワークの乱立による汎用的な標準基盤の整理の難しさという、冒頭で述べたような問題が顕在化してきたのもこのころと言って良いでしょう。
次ページでは、軽量フレームワークの影響を受けて、標準規格であるJava EEがどのように再編成されていったのかを解説します。
標準規格の再編成 ～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」について、特徴を詳しくご紹介します。
