エンタープライズ向けJava標準化の歴史
エンタープライズ利用の道を開いた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がどのように再編成されていったのかを解説します。
