JavaEEの誕生

本頁では、2017年7月時点のJavaEEプラットフォームに関して、サーバーサイドJavaの歴史的背景を学ぶことにより、 サーバーサイドJava及びJavaEEプラットフォームに関する用語を正しく理解し易くなることを目的とします。

本頁の読者は、[課題1]Javaの基本知識の解答を一読されている方を対象とします。

2017年サーバーサイドJava

サーバーサイドJavaのカテゴリー

2017年7月時点のサーバーサイドJavaの開発手法を分類分けをすると上記図のような大分類になります。

  1. オンプレミス
    1. JavaEE (only)
      JavaEEとフルJ2EEアプリケーションサーバ(GlassFish、 JBoss、 Oracle Internet Application Server等)のみでシステムを構築します。
      JavaEEのAPI体系に表現されたフレームワークのみ利用可能とします。
    2. Spring
      JavaEEのWebコンテナ(JSP/Servletなど)とそれに対応するアプリケーションサーバー(tomcatなど)に DIコンテナ用フレームワーク(Spring)を組みあせてシステムを構築します。
    3. その他
      過去、2017年7月時点を含め上記２つ以外アーキテクチャでシステムを構築します。
  2. クラウド
    2017年7月時点クラウドサービスにおけるJavaは、クラウドサービスの形態(SaaS,laaS,PaaS)によって異なります。
    クラウドサービスを展開している企業がクラウドサービスにおけるJavaの扱いに関して、
    それぞれデファクトスタンダードを目指した正当性を展開しています。
    そのため、現時点でクラウドにおけるJavaのデファクトスタンダードなアーキテクチャが何であるか断言できません。

本書では、オンプレミスにおけるサーバーサイドJavaを対象範囲として説明します。

サーバーサイドJavaのアーキテクチャを考える

サーバーサイドJavaの多階層モデル

上記図は、サーバサイドのJavaの３階層アーキテクチャの概念図です。
ハードウェアやミドルウェアの構成図を示したものでは無く、大きな役割を示した図としてご理解下さい。

  1. プレゼンテーション層
    • クライアントから送信されたHTTPリクエスト(JSON含む)を受信します。
    • 指定されたURIに対するコントローラクラスを実行します。
    • コントローラクラスでは受信したリクエストの妥当性チェックを行います。
    • 利用者が要求した処理に対するビジネスロジックを定義したサービスを実行します。
    • サービスの実行結果をチェックして、対象のView(JSP,JSFなど)に出力するデータを引き渡し、実行します。
    • 対象のView(JSP,JSFなど)は、HTMLファイルを出力し、レスポンスとしてクライアントに返信します。
  2. サービス層
    • サービス層は、ビジネスロジック層とも呼びます。
    • 画面に依存しない共通化された一意の機能(ビジネスロジック)をサービスと呼びます。
    • サービスはビジネスロジックを実現するためデータ層のDaoに対してデータの収集、加工を依頼します。
    • データを加工するサービスでは、正常時にデータの最終確定ためトランザクションをコミットします。
    • データを加工するサービスでは、異常時にはデータの反映をキャンセルするためトランザクションをロールバックします。
    • データ層のDaoに対する実行結果を判定し、サービスの実行結果データを作成しプレゼンテーション層に結果として返します。
  3. データ層
    • データ層では、データベースのテーブルに対してSQLを発行します。
    • データベースからの実行結果をJavaのオブジェクトに変換し、サービス側に返却します。
    • データ層では、データベースのテーブルの構造に基づいてDaoを各サービスから利用できるように共通化します。

細かい関係性は、Web多階層アーキテクチャの図もご参照下さい。

サーバーサイトJavaの草創期(1997年⁓1999年)

JavaEEプレゼンテーション層歴史

Java言語が誕生する1996年以前のオープン系システム開発は、企業内で閉ざされたネットワーク内で データーベース(主にOracle)をサーバーとして、クライアントの画面をVB(Microsoft Visual Basic),VC++(Microsoft Visual C++),Delphi等を利用して開発していました。

そのシステム形態は、クライアントサーバシステム(略称クラサバ又はC/S)と呼びます。

1995年頃のWebは、まだWebサーバであるIISやApacheHttpdServerとWebブラウザ(IE)がリリースされていない時代です。 Webを利用する環境は、WebサーバにNCSA HTTPdを WebブラウザにNetScapeを利用していました。
Webは、主に静的コンテンツであるHTMLファイルを表示することや簡易の動的コンテンツをCGIで作成していた程度で、 今のような大規模な基幹システムや世界に公開するWebサービスのようなシステム形態とはかけ離れていました。

1996年1月23日にサン・マイクロシステムズ(現Oracle社に吸収される)がJDK1.0を正式リリースしました。
1.0のバージョンでは、国際化対応(日本語の利用)が対応されていなかったり、Webブラウザへの実装(Appletの実行)がされていない状態でした。

Java(JDK)がリリースされた当初は、プラットフォームに依存しない設計思想「Write once, run anywhere」と、 プログラムの開発に高額なGUIやプラットフォームを購入する必要性が無く、オープンに公開されたされた言語仕様は、一部の企業、メーカ、研究所、大学で高く評価されていました。

当時のJavaアプリケーション開発は、Eclipseのような統合開発環境(IDE)は無く、次のような手順を実行していました。

  1. プロジェクトディレクトリの初期階層を構築する。
  2. 要件に従ったJavaソースファイルをテキストエディタで作成する。
  3. JavaAPI及びJava言語仕様、社内で開発に長けた人のソースファイルを参考資料として利用していました。
  4. javacコマンドをコマンドプロンプトから実行し、クラスファイルを作成する。
  5. javacで発生した文法上のエラーが無くなるまで前３項を繰り返します。
  6. バッチファイルにjavaコマンドと引数となる起動用クラス、クラスパスを記述します。
  7. バッチファイルを起動し、Javaを実行します。

1997年2月19日にJDK1.1がリリースされ国際化対応、Jarコマンド、JavaBeans、JDBC、RMI、リフレクションなどの重要な機能がリリースされました。

JDK1.1時代のJavaの実行形態は、以下のようなものでした。(前手順6.7が異なります。)

  1. javacで発生した文法上のエラーが無くなるまでエディタによる製造とコマンドプロンプトからjavacを繰り返します。
  2. jarコマンドを実行し、jarファイルを作成する。
  3. デスクトップアプリケーションとして、クライアントPCに配備して実行する。
  4. 又はJavaAppletとして、Webサーバーにjarファイルを管理し、htmlファイルからobjectタグでAppletを起動する。

デスクトップアプリケーションにしてもWebブラウザに表示したAppletでもこの当時のJavaは一時的に開発者からの評価を下げました。 当時のクライアントのPCスペックは、CPUが200～400Mz,メモリが良くて128MBというハードウェアリソースが貧弱な時代で、 Javaを動作させた瞬間にWebブラウザが固まる、JavaアプリケーションがOutOfMemmory(OOM)で中断することが続発していました。

不遇な状況にサン・マイクロシステムズは、動的なhtmlファイルを出力するサーバーサイドJavaの骨格であるServletAPIをJDKの開発と並行して実装してきました。

1999年12月12日ServletAPI2.2を梱包したJ2EE1.2(現JavaEE)を正式リリースしました。 同時期にJ2EE1.2の実装したApacheTomcat3.0(initial relase)系もリリースされました。オープンソースのWebアプリケーションサーバーの誕生です。

このWebアプリケーションサーバーTomcatの誕生により、以下の課題点が解消されました。

  • サーバー(ハードウェア)構成の自由な選択
  • OS(Windows,Linux,Unix)の事由な選択
  • 1.項及び2.項の複数の組み合わせがあってもプログラムのソースコードは１種類
  • 全て無料
  • 全ての情報が公開(オープンソース)
  • Fatなクライアントアプリケーションから軽量に

まさに「Write once, run anywhere」の設計指向が時流とマッチした瞬間です。この時期からサーバーサイドJavaが市場で急激に普及しだしました。