J2EE入門
1章：J2EE

[索引]  J2EEとは |  HTTP |  サーバサイドシステムの動作 |  Webシステムの構成 |  アプリ階層構造 

1.1 J2EEとは

J2EE

J2EEは、Javaの標準機能セットであるJ2SEに企業の業務システムなどの開発に使われるサーバ用APIを付加したセットです。 J2EEで付加されたAPIには多くのものがありますが、その代表格はServlet、JSP、EJBです。 これらについては、この後の章で詳しく説明します。 ここではそれ以外のAPIについて簡単にご紹介します。

JDBC（Java Database Connectivity）

JDBCはJavaアプリケーションからデータベースを操作するAPIです。 JDBCを使うと簡単な操作でRDBを扱うことができます。

JNDI（Java Naming and Directory Interface）

Javaでネーミングサービスおよびディレクトリサービスの機能を利用できるようにするAPIです。 ネーミングサービスを使うと、名前から、そのプログラムの格納位置を知ることができます。 ディレクトリサービスでは、機能などの属性から欲しいリソースを探すことができます。 例えば「A3用紙にカラーで印刷できるプリンタは?」といった問いに答えて、そのIPアドレスを返します。

JMS（Java Message Service）

処理に時間がかかる場合に、起動だけしておいて、後からメールで結果をもらうような、いわゆる非同期処理を行うときに使うAPIです。 1対1の通信だけでなく、1対nの通信も行うことができます。 また起動後のシステムダウンに備えて状態をDBに格納しておくといった機能も備えています。

JavaMail

プログラムからメールを出したり、受け取ったメールを処理したりすることが簡単にできます。

JSF（Java Server Faces）

Servletと同じようにブラウザとサーバ間で対話処理を行える機構です。 サーブレットに比べてユーザーインターフェースが豊富で操作性のよいシステムを簡単に作ることができます。 JSFは2004年3月にリリースされたばかりの新しいコンポーネントです。 まだ実績は少ないですが、ServletやAppletを押しのけて、今後のJ2EEの中核となる可能性を持つ技術です。

1.2 HTTP

HTTP（HyperText Transfer Protocol）

インターネットのホームページにアクセスしたことがある方はHTTPと言う言葉になじみがあると思います。 ホームページのアドレスであるURLは必ず「http://～」で始まっていますが、これはHTTPと言う通信規約（プロトコル）を使って通信することを表しています。 HTTPはWebで通信するときの、代表的なプロトコルであり、J2EEの代表であるサーブレットやJSPもHTTPを使ってやりとりされています。

HTTPではHTML文書や、文書に関連付けられている画像、音声、動画などのファイルを、表現形式などの情報を含めてやり取りできます。 サーブレットやJSPなどのJ2EEの仕組みを理解するには、まずHTTPを知らなくてはなりません。 ここではHTTPを使ってWebブラウザがサーバから情報を送ってもらう様子を示します。

クライアントとサーバの動作

（1） クライアント（Webブラウザ）側からサーバに対して受け取りたい情報のURLを送ります。 URLは使用するプロトコル名である http:// の後に、サーバ名/ディレクトリ名/ファイル名を記述した構造になっています。

（2） サーバ名から指定されたサーバを探し出します。 実際の識別にはIPアドレスという全世界のインターネットで重複しないように管理されたアドレスが使われます。 これを探す仕組みもなかなか面白いのですが、ここでは省略します。

（3） 指定サーバに到着すると、ディレクトリ群の中から指定のディレクトリの指定ファイルを探します。

（4） 指定ファイル（index.html）をHTTPプロトコルにしたがって送信します。

（5） Webブラウザは受信したファイルのHTML文を画面に表示します。 HTML文はタグと呼ばれる制御の仕組みを使って、文字のサイズや色などを指定することができます。 これらはブラウザが解釈して表示します。

（6） 受信したHTML文にイメージの指定があれば、ブラウザはさらに処理を続けます。

（7） まず画面にはイメージの仮表示をしておきます。

（8） そしてそのイメージを先程のサーバに要求します。

（9） サーバは、要求が来るとそのイメージを送信します。

（10） ブラウザは受け取ったイメージを表示します。

サーバの動作

以上を見ると、サーバの動作はとても単純であることがわかります。 複数のブラウザから次々に要求が来ますが、とにかく指定されたファイルを要求元に送る、それだけです。 送り終わると、どこに送ったか、何を送ったかなどはいっさい覚えていません。 この例では同一のブラウザからテキストとイメージの要求がありますが、サーバはその時々の要求元に送っただけで、それが同じだということは意識していません。 このような通信をステートレス通信と言います。

Webブラウザの動作

これに比べWebブラウザの動作はもう少し複雑です。 HTML文書が来ると、それを解釈して実行（表示）しますが、その他に、イメージデータのように格納アドレスが書かれた情報があると、そのアドレスを指定して再度同一サーバに取りに行きます。 サーバから送られてくると画面に表示すると同時に、一時格納（キャッシュ）メモリに格納しておきます。 そして次回からは同じ名前のイメージが指定されたら、サーバには取りに行かずにそれを表示します。

HTTPはインターネットの基礎技術

HTTPプロトコルは、このようにサーバの動作が単純なため、比較的安価に大量の処理をこなすことができ、急速に普及しました。 そして今日のようなインターネットの全盛の時代を迎えることとなったわけです。

1.3 サーバサイドシステムの動作

動的画面表示

しかし、指定されたファイルの内容を送っているだけでは、いつも固定的な画面しか見せることができません。 そのために、要求に応じて異なる内容を動的に表示する仕組みが工夫されました。 すなわち静的なファイルを送る代わりにプログラムを動かし、要求に応じた動的な画面を返すようにしたわけです。 この代表例がサーブレットです。 サーブレットのようにサーバ側でプログラムを動作させる仕組みをサーバサイドWebシステム（略してサーバサイドシステム）と言います。 これに対し、後述のアプレットのようにクライアント側で動作させる仕組みをクライアントサイドシステムと言います。

サーバサイドシステムの動作

サーバサイドWebシステムは次のようにして動きます。 Webブラウザからの指定ファイルがHTML文書ではなくプログラムであると、サーバはそのプログラムを起動させます。 ただし、このときにはサーバ側でプログラムを動作させる仕組み（サーブレットの場合はサーブレットコンテナと言います）が動作していなければなりません。 プログラムは、HTML書式のデータを出力するように作っておきます。

するとその出力がブラウザ側に送られ画面に表示されます。 このデータは通常のHTML文なので、ブラウザの表示プログラムはURLでHTML文書を指定したときと同じように動作すれば良いことになります。

端末としてのブラウザ

これまでは、コンピュータと接続してプログラムを動作させようとすると、専用の端末が必要であり、各システムごとに端末を用意して使用者に配付しなければなりませんでした。 しかし、このサーバサイドシステムでは、インターネットにより大量に普及したブラウザをそのまま使用することができます。 サーバサイドシステムを使う限りシステムの構築者、無償で端末を手に入れたことになります。 これもサーバサイドシステム全盛の大きな理由と言えるでしょう。

1.4 Webシステムの構成

Webシステムの構成

サーブレット、JSP、アプレット、およびEJBのWebシステムにおける位置を確認しておきます。

前述のように、Webシステムにはサーバ側でプログラムが動作するサーバサイドシステムと、クライアント側で動作するクライアントサイドシステムとがあります。 サーブレットとJSPは前者、アプレットは後者に属します。

アプリ階層構造

この図ではサーバ側はWebサーバとアプリケーション（AP）サーバおよびデータベース（DB）サーバで構成（3階層アプリ方式）されていますが、サーバ側の処理が軽いシステムはWebサーバとDBサーバだけで構成（2階層アプリ方式）されることもあります。 APサーバではEJBやCOBOLプログラムが動作します。 COBOLはもちろんJ2EEではありませんが、最近のWebシステムでは、このようにJ2EEフロントと組み合わせて使われることが多くなっています。

1.5 アプリ階層構造

JSP／サーブレットを使うシステムを例にして、アプリ階層構造について補足しておきます。

2階層方式

2階層方式ではJSPとサーブレットで画面アプリを構築し、サーブレットで業務アプリを構築します。 中小規模向けにおいて主流となる方式で、3層に比べて構築が容易です。 処理量が多い場合は、Webサーバの増設で対処します。 3層方式に比べ、画面アプリの変更が業務アプリに影響する可能性が高いと言えます。

3階層方式

3階層方式は大規模向けの方式で以下のような利点があります。 しかし2階層方式に比べるとサーバ間通信のオーバーヘッドが発生する、インフラ設計、環境構築、および維持が複雑になるという問題があります。

1. 配置の自由度
   • セキュリティ要件により、WebサーバをDMZ（注）にAPサーバを内部に配置するといった対応が可能です。
   • イントラネットや携帯端末などに対して、Webサーバのみにて対処するなど入力の多様性が図れます。
2. フロントと業務ロジックを分離
   • 画面アプリと業務アプリの機能を明確にして開発を分業することができます。
   • WebサーバとAPサーバを負荷に応じて独立に増設できます。
   • 業務アプリごとに、インスタンス数やタイムアウト時間を設定できます。

選定指針

• 大規模ではなく、短期の開発を求められている場合はアプリ2階層を選択します。
• きめ細かな性能設定、拡張性、ポータビリティを要求されるシステムは、アプリ3階層（EJB）を選定します。
• DBアクセスが多発するなど、性能要件が非常に厳しい場合はアプリ3階層（COBOL）を選定します。

ハードウェアの構成例

ここでいうアプリ階層とは、サーバ上のソフトの階層を意味しています。 ハードウェアとしてのサーバの台数を指しているのではありません。 参考までにアプリ2階層と3階層を構成するハードウェア構成の例を示します。

 1    2    3    4    5   次へ