いまさら聞けないサーバーサイドJava 第1回 これだけは知っておきたいJ2EEの基本 (日経BP 日経ソフトウエア 2002年9月号より2003年4月号に「いまさら聞けないサーバーサイドJava」として連載された) (山本 啓二)

PDFはこちら

さまざまな API で構成するのが J2EE

最初に「J2EEとはいったい何なのか」を明らかにしておきましょう。J2EEは，米Sun Microsystemsが策定したJavaによる企業システム構築のための仕様です。現在のバージョンは2002年1月にリリースされた1.3.1（注2）。皆さんがアプレットやスタンドアロンのJavaアプリケーションを開発するときに使うJ2SE（Java2 Platform, Standard Edition）を，企業規模のシステムに対応するよう拡張した仕様という位置付けになります（図1）（注3）。

J2EEでは，ほとんど耳にタコができるほど聞かされてきたJavaの理念「Write once, Run anywhere（一度書けば，どこでも動く）」が生きています。J2SEにおいて「Anywhere」はOSやハードウエアを指すものでしたが，J2EEでは企業システム構築に必要なさまざまなミドルウエア（データベースなど）を指します。これらのミドルウエアを抽象化し，環境が異なっても統一したAPIを利用できるようにすること。それがJ2EEの役割なのです。そのためJ2EEには表1のようなさまざまなAPIが含まれています。

表1 J2EE1.3に含まれるAPIとその用途

※オプション・パッケージ

主なものから順番に説明しましょう。

JDBC 2.0オプション・パッケージは，データベースとJavaプログラムを接続するAPIです（注4）。J2SEに含まれているJDBCコアAPIでは，データベース・ドライバ，データベースのメタ情報（注5），接続，SQL（注6） 文，処理結果，SQL型のJavaオブジェクト・マッピングが提供されていますが，大規模システムでは力不足です。そこでオプション・パッケージとして，大量のクライアントに効率よくデータベース接続するための機能などが追加されているわけです。

EJB（Enterprise JavaBeans）は，ビジネス・ロジックのコンポーネント化を目的とした仕様です。トランザクション制御をサポートし，ビジネス・ロジックそのものを実装するオブジェクトとなるため，多層構造アプリケーションの中心となります。J2EEの中でも特に複雑な仕様と言っていいでしょう。EJBは，J2EEの他のAPIを利用する上位レイヤーの仕様なので，J2EEを理解することはEJBを理解することといっても過言ではないかもしれません。

サーブレット（Servlet）とJSP（JavaServer Pages）は，Perl/C/PHPなどを使ったCGIプログラム（注7）の代替となるように策定されたWebアプリケーション構築用のAPI群です。HTTPによるリクエストに対して（一般的に）HTMLを返す，ユーザー・インタフェースに一番近い層をつかさどります。サーブレットの実体はJava言語で記述される通常のクラスで，リクエストがあるたびにサーバーで起動します。一方JSPは，HTMLにJava言語を埋め込んだような独自の書式を採用したファイルです。そのため「HTMLはわかるけれどJavaプログラミングはちょっと…」といったWebデザイナでも理解しやすく，見た目だけを意識して書くことができるようになっています。実を言うとJSPは，実行前に自動的にサーブレットに変換されて動作するので，JSPとサーブレットは兄弟みたいなものと思えばいいでしょう。

JMS（Java Message Service）は，メッセージングを実現するためのAPIです。もちろんメッセージングといっても人間同士が音声やメモでやりとりするものではなく，システム同士がメッセージを送り合って連携することを指しています。JMSの特徴は，呼び出し側からは非同期に実行されることと信頼性が向上することです。信頼性とは，メッセージの紛失が発生しない，発行と到着の順序を保証するなどです。

JTA（Java Transaction API）は，分散トランザクション（注8）を管理するトランザクション・マネジャを利用するためのインタフェースです。複数の企業システムを連携させつつWebから利用する場合などに，このAPIは重要になります。

JavaMailは，Javaからメールの送受信，処理を行うためのインタフェースです。添付ファイルや日本語対応をはじめとした国際化にも対応しています。

JAF（JavaBeans Activation Framework）は，JavaBeans（注9）仕様の拡張として，さまざまにエンコードされた各種データ型を，対応するJavaBeansへマッピングして処理を自動化するフレームワークです。例えば前述のJavaMailは，JAFを利用してメールのボディ部分を処理し，MIMEタイプ（注10）に対応したJavaオブジェクトを生成しています。JAXP（Java API for XML Processing）は，JavaからXML（注11）を処理するためのAPIの一つです。DOM（注12）のレベル1とSAX（注13）1.0を利用できます。

最後のJAAS（Java Authentication and Authorization Service）は，Javaアプリケーションにおける認証と承認のフレームワークになります。アクセスしているユーザーを個別に見分けて本人であると認める「認証」，認証されたユーザーに許されている処理・サービスだけを提供する「承認」は，アプリケーションを安全なものにするための基盤となります。

以上，J2EE仕様に含まれるAPIをざっと概観してみましたがいかがでしたか？

おそらくその膨大さに驚いている方もいらっしゃるかと思います。でも，心配はいりません。この連載を通じて一つずつ理解を深めていきましょう。

J2EEアプリケーションは4階層で考えよう

表1に挙げたJ2EEのAPIは製品ではありません。あくまで「仕様」の話です。仕様というからには実装があるわけで，これが各ベンダーが出荷している「J2EEサーバー」になります。したがってJ2EEアプリケーションといった場合，J2EEサーバー上に構築するアプリケーションのことを意味します。
J2EEアプリケーションの全体構成を見てみましょう（図2）。

さまざまなコンポーネントがありますが，このうち開発者が記述しなくてはならないのは青色の長方形で表したコンポーネント（HTML，アプレット，サーブレットなど）になります。全体のボリュームから見ると，小さい範囲に絞られているのがわかりますね。システム全体は，細かく見るとクライアント層，Web層，ビジネス層，EIS（Enterprise Information Service）層の四つに分かれます。図2の一番左側に位置するのがユーザー・インタフェースとなるクライアント層です。多くはWebアプリケーションとして，Webブラウザを利用したHTMLあるいはアプレットがクライアントとなります。もちろん，独立して動作するクライアント・アプリケーションであることもあります。

次に位置するのがJ2EEサーバーです。J2EEサーバー内部は，Webコンテナ（Web層）とEJBコンテナ（ビジネス層）という二つのコンテナに大きく分かれます。コンテナというのは，コンポーネントの入れ物と考えてください。Web層には，前述のサーブレットやJSPのプログラムが含まれます。また，Web層というからにはWebサーバー（HTTPサーバー）機能が必要ですが，後述するJ2EE SDKは，WebコンテナとしてWebサーバーのTomcatを装備しています。しかし開発でTomcatを使ったとしても，運用時にTomcatを使うことはありません。一般的には，セキュリティやパフォーマンス面で優れているApacheまたはApacheをベースにした商用Webサーバーを使うことがほとんどです。この場合，Webブラウザからの要求はApacheが受けて，ApacheとJ2EEサーバーが通信し合うことになります。

ビジネス層では，ビジネス・ロジックを実現するコンポーネントを，SessionBean，EntityBean，MessageDrivenBeanの三つのEJBとして配置します（EJBについては連載の後半で解説します）。ビジネス・ロジックとは何かという定義は難しいですね。

ここでは「口座Aから引き落として口座Bに入金する」「サイト利用者に対して課金を行う」「会員数推移のサマリーを管理者に通知する」など，アプリケーションの中心となるロジックのことと考えておいてください。
最後に現れるのがEIS層です。これはJ2EEアプリケーションというより，既存の外部システムやデータベースが該当します。ここをなぜJ2EEアプリケーションと分けて考える必要があるかというと，J2EEアプリケーションとはライフサイクルが異なるからです。例えば，流通業の会社が新規に構築するEC（電子商取引）サイトであれば，既存の物流や決済のための社内システムと連携することが必要となります。また，企業においてデータベースは生命線です。ビジネスが変わればアプリケーションも再構築されますが，いったん蓄積したデータを捨て去ることは普通ありません。そこで，データベースを含めたこれらのシステムやサービスを，EIS層として明示的に切り分けて考えることが必要なわけです。

このようにJ2EE仕様は，多層構造のアーキテクチャ（注14）を前提としています。そのためアプリケーションを開発する場合も，常にこの構造を意識する必要があります。そこでこの多層構造アーキテクチャについて，もう少し深く見てみることにしましょう。

J2EEアプリケーションを配布（deploy）する方法

常に多層構造とMVCを意識するのがポイント

J2EEが多層構造のアーキテクチャを採用している理由の一つは，開発生産性を向上させるためです。

例えばクライアント層は見た目や使い勝手にかかわる部分なので，エンドユーザーの要望によって変更されたり，Webデザイナなど開発者とは異なる人によって設計されたりします。そのたびにビジネス・ロジックを記述したソースコードに手を入れるのは難儀ですね。それならば，ここを層として切り分けたほうがデザイナと開発者の間で仕事の切り分けが可能になり，生産性向上が期待できます。また，そのためにはJ2EEサーバー内部においても，クライアントに近い部分であるWeb層と，ビジネス・ロジックを記述するビジネス層に分けたほうが，メンテナンスの面からも都合がよいでしょう。そのため多層構造化が必要だったわけです。

多層構造のメリットはそれだけではありません。各層はネットワーク通信を行うので1台のマシンでJ2EEサーバーを動かす必要はなく，多層構造に分かれていると，各層を複数のノード（マシン）に分散しやすくなります。つまり大量アクセスがあった場合の負荷分散や，セキュリティといった面でメリットを享受できるのです。

このようにJ2EEが多層構造を採用したのには，深い意味があります。開発者は，これらのメリットを最大限に利用する方向でJ2EEを使うべきでしょう。ポイントは「ビジネス上の重要な機能はEJBに集中させ，JSP，サーブレット，アプレットなどには組み込まない」ということに尽きます。

ところでユーザー・インタフェースとロジックを分ける，とくれば，MVCというアーキテクチャをご存知だと思います。MVCはもともとSmalltalkにおいて多用されていたものですが，GUIアプリケーションの開発を効率よく行うものとして知名度を上げてきています。

MVCでは，アプリケーションの構成要素をM（Model），V（View），C（Controller）の3種類に分類します。Modelはアプリケーション・データとその扱いに責務を持ち，Viewはアプリケーション・データの表示と操作のためのインタフェースです。ControllerはViewに対するユーザーの操作やModelの変化を相互に通知する仕組みを持ちます。と言ってもわかりにくいと思うので，具体的な例を見てみましょう。図3は，株価情報を参照して株の売り買い注文を行うアプリケーションの例を表しています。

図3

Modelは，株価情報が更新されるとControllerに対して情報の更新を通知します(1)。Viewは前もってControllerに「この株価が変わったら教えてね」と登録してあるので，株価が変わったタイミングでユーザーにそれを提示します(2)。ユーザーが売り買いの注文をViewに対して行うと，ViewはControllerにアクセスして(3)，ControllerがModelにその注 文を依頼します(4)。

このように責務を切り分けるメリットは二つあります。一つはアプリケーションの見通しがよくなること。もう一つは，アプリケーションを利用するユーザーが増えてもViewの数が増えるだけで，一番複雑で重要なModelには影響がない，ということです。

ところが，Webアプリケーションの場合は厳密にはちょっと違います。というのもクライアント側でアプレットやプラグインなどを使わない限り，Webサーバー側からWebブラウザに対して更新を通知する方法がないからです。Web環境では，常にクライアント（Webブラウザ）からサーバー（Webサーバー）に対してリクエストを送り，サーバーがそれに応えるだけです。そのため，MVCの「ModelからViewへ変更を通知する」機能は実現できません。

そこで，現在多くのJ2EEアプリケーションで用いられているのが，MVCモデル2（筆者は「一方通行のMVC」と呼んでいます）の設計です。JSPをViewに置き，サーブレットをController，EJB/JavaBeansをModelとするのです。MVCとしては簡略化されたものになってしまっていますが，J2EEの構成と親和性が高いために，特に大規模なアプリケーションになるほど好んで採用されています（図4）。

図4

（注1）ASP（Active Server Pages）は，マイクロソフトのWebアプリケーション実行環境。

（注2）1.3では，1.2以前のバージョンに含まれていたJNDI（Java Naming and Directory Interface）が除外され，新たにJAXP（Java API for XML Processing）が追加された。

（注3）J2EEにとってWeb対応の仕組みというのは，クライアント配布の問題を解決するThin Client（特別なインストールを必要としない軽量クライアント）モデルの一つでしかない。しかし現実問題としてJ2EE＝Webアプリケーション開発のプラットフォームと考えて差し支えないだろう。

（注4）ODBC（Open Database Connectivity）と同様に，J2SE 1.2まではJDBCもJava Database Connectivityの略称とされていたが，現在のJDBCのページからは「Java Database Connectivity」の名称はなくなり，JDBCはただの固有名詞とされているようだ。

（注5）メタ情報とは，「もの自身に関する情報」という程度にとっておくといい。この場合，データベースのユーザーやそのアクセス権に関する情報を持つオブジェクトなどを意味する。 SQLは，リレーショナル・データベース（RDB）を操作するための言語。

（注6）SQLは，リレーショナル・データベース（RDB）を操作するための言語。

（注7）CGI（Common Gateway Interface）は，Webサーバーが他のプログラムを呼び出すためのインタフェース。一般にCGIに準拠して作成したプログラムをCGIまたはCGIプログラムと呼ぶことが多い。

（注8）分散トランザクションは，複数のデータベースなどに対して発行する更新トランザクションを全体で一つのトランザクションとして扱うこと。

（注9）JavaBeansは，Javaのプログラムから利用できるソフトウエア部品の仕様で，個々の部品をBeanと呼ぶ。

（注10）MIME（Multipurpose Internet Mail Extensions）タイプは，インターネットでさまざまなデータを送るための拡張仕様。

（注11）XML（Extensible Markup Language）は，SGMLの自由なタグ指定機能と，HTMLのインターネット機能を融合させたメタ言語。

（注12）DOM（Document Object Model）は，XML文書のノードやデータにアクセスするためのAPI。

（注13）SAX（Simple API for XML）は，XML文書にアクセスするためのAPI。

（注14）アーキテクチャというのはあいまいな言葉で，人によってイメージするところはさまざまだろう。 ここでの意味は「設計基本方針」くらいにとらえておくのが無難だ。ちなみにアーキテクチャについて深く考えるなら，以下のドキュメントが参考になるかもしれない。
http://www.ogis-ri.co.jp/otc/hiroba/technical/coal-ADD/index.html