ビジネスロジック層におけるJavaEEの歴史

前頁に続き、サーバーサイドJavaであるJavaEEのビジネスロジック層の歴史について説明します。

ビジネスロジック層の歴史２

図中グレー部分は、でJavaEEの歴史の暗黒期を象徴したEJBのバージョンを示しています。
※.2017年時点のEJB3.1系はデータ層のフレームワークの１つとして大きな改善がされています。

ビジネスロジック層開拓期・暗黒期(1999年⁓2003年)

ビジネスロジック層の歴史２

プレゼンテーション層とデータ層のフレームワークの骨格ができた1999年⁓2003年に 分散処理システムとしてEnterPrise JavaBeans 通称EJB APIをリリースしました。EJB及びJ2EEコンテナが 目指す一番の設計指向は、アクセスが集中するデーターベースの分散を目的として分散処理システムを目指していました。

Webアプリケーションサーバーに内蔵したEJBコンテナがデータベースのデータ反映タイミングやデータの永続性を制御していました。

EJBが暗黒時期を作ったのは、以下の理由です。

  • アーキテクチャが複雑すぎた
  • 製造物(EJBCleint,EJB,XMLなど)が多すぎて手間がかかる
  • データの永続性に関して数々のデータの不整合などの多数トラブルが発生
  • WebコンテナとORMパターンよりスループットが悪すぎる
  • 習熟するのに時間がかかる(教育コスト)
  • 指導者(理解者)の欠如

ビジネスロジック層DIコンテナ開拓期(2003年⁓2009年)

このJ2EE(EJB)に対する辟易とした状態に対して、 2002年10月にRod Johnsonが「Expert One-on-One J2EE Design and Development」を発表しました。 この論文を具体的に実装したフレームワークSpring1.0が 2004年3月にリリースされました。

現在のJavaEE(CDI関係)にも引き継がれている骨格となる主な機能は以下です。

  • 依存性の注入(DI: Dependency injection)
  • アスペクト指向プログラミング(AOP: Aspect Oriented Programming)
  • データ層との連携
  • トランザクションの制御
  • プレゼンテーション層との連携
ビジネスロジック層のアーキテクチャ

Springフレームワークの登場により、開発現場の仕事の方法もかなり変化しました。

  • 作ることから使いこなす事へ
  • テクロノジー要件からビジネス要件に集中
  • 開発から運用へ

JavaEE反映期(2006年⁓2009年)

各層のフレームワークはそれぞれJ2EEの言語体系とは別に発展してきました。 その当時は、それぞれの層の一番評判の良いフレームワークを連結して、WebコンテナだけのTomcatに搭載させて、実装していました。

各層のフレームワークの連携作業は、非常に経験とノウハウを必要とされます。 また、１つの層のメージャーバージョンが上がったときの検証や動作保証も大変労力がいります。

この流れから、今まで市場で利用された優良なアーキテクチャをAPI化することで、 JavaEE言語１つとフルJavaEEのWebアプリケーションサーバー(GlassFish,JBossなど)だけで、開発者は設定やフレームワークの組み合わせを気にすることなく システム開発ができることを目指しています。

  • ORM→JPA
  • DI→CDIなど
  • MVC2→JavaEE8予定。

JavaEE言語体系の特徴(2009年⁓2017年)

JavaEEを学ぶエンジニアやJavaEEで大規模システムを開発するエンジニアが理解して置く大切な事があります。

年表にあるようにJavaEE言語APIは、先に出現した技術を法律のように制定するために、 リリース時の各層の整合性などや安定性はあるものの、最先端の技術から１年以上常に遅れている点です。

IT業界のアーキテクチャにおける集中と分散の歴史は繰り繰り返しています。
現在はJavaEEに寄せる「集中」の年ですが、並行して各層のフレームワークの先行的な進化が起きています。
JavaEEのリリース速度を鑑みるとJavaEE only形態が５年以上先も継続しているかは微妙な所です。
私が思うのは、アーキテクチャの進化は日々起きているのでトレンドが変化するのは当たり前だと考えます。
その上で、日々多く接する技術を自分の強み(バックボーン)として、新しい事を学習して取り入れていく姿勢が大切だと思っています。