第3回　J2EEアプリケーションと配置

丸山不二夫
稚内北星学園大学学長
(http://www.wakhok.ac.jp/)
2001/5/26
今回の内容

J2EE利用の基本パターンと「配置」
配置は「永続」する
J2EEアプリケーション=EARファイル
petstore.earファイルを「解凍」してみる
J2EEアプリケーションファイルの構成

　前回、Java Pet Storeのサンプルを紹介しましたが、皆さんうまく動かすことができましたでしょうか？ サンプル・デモといっても、J2EEを動かすうえでの、基本的な利用パターンはすべて含まれていますので、ぜひ、動くまで頑張ってみてください。

　マシンの余裕があれば、データベース、J2EEサーバ、Webブラウザの3者をネットワーク上の別々のマシンに割り当てて、Java Pet Storeデモを動かすことに挑戦してみてください。

　

 J2EE利用の基本パターンと
  「配置（deployment）」 

　もう一度、J2EEを利用する手順を振り返ってみましょう。前回は、J2EEのインストールや環境設定、Java Pet Storeデモの設定などの具体的な手順の中で語ってきましたので、今回は、それらの中から、J2EE利用の基本的なパターンを抜き出してみましょう。少し大まかにいえば、J2EEを利用するには、一般的に次の4つのステップが必要です。

1.まず、データベースを立ち上げます
　J2EEの典型的なシナリオでは、データベースとの接続はJ2EEの最も重要な構成要素の1つですが、データベースを使わないJ2EEアプリケーションもありえます。

2.J2EEサーバを立ち上げます
　J2EEを利用する以上、これは当然のことですね。

3.J2EEサーバに、J2EEアプリケーションを「配置（deployment）」します
　「配置」といっても「配備」といっても同じことです。小論では、「配置」という用語を使うことにします。この配置のために、専用のツール「deploytool」が用意されています。この手順は、必須です。

4.Webのブラウザを立ち上げて、J2EEサーバ上のURLを指定します。
　J2EEの典型的なシナリオでは、WebブラウザがJ2EEクライアントとして想定されています。Webブラウザ以外のJ2EEアプリケーション・クライアントが利用されることもあります。いずれにせよ、J2EEにJ2EEクライアントは必須です。

　一般的な3ティアのアプリケーション・モデルが3つの階層を持つことを考えると、こうしたJ2EE利用の手順（1、2、4）は、自然なものだと分かると思います。その意味では、上記の3.の「配置」の手順が、J2EE特有の手順だということになるのかもしれません。もっとも、サーバ・サイドのアプリケーションをサーバ上で動かすためには、それなりの手順が必要だと思えば、配置の操作も自然なものに見えてくるかもしれませんね。SOAPでも、J2EEと比べるととても単純なものですが、配置をします。

　

 配置は「永続」する

　J2EEにおける配置の見かけ上の複雑さは、アプリケーション自体を変更することなく、できるだけ柔軟に現実の環境にアプリケーションを適応させようとすることから生まれたものです。

　J2EEでは、J2EEシステムの「管理者」と並んで、“deployer”という仕事が想定されているほどです。「配置屋さん」というわけですね。Java Pet Storeのデモを立ち上げる仕事では、「管理者」＝「配置者」＝「利用者」という、1人3役の仕事をしているわけです。このことの説明は別の機会に譲るとして、J2EEアプリケーションの「利用者」として、配置については、当面、次の2つのことに注意しておいてください。

　1つは、アプリケーションが与えられていれば、細かな設定をしなくてもdeploytoolでただちに配置の作業をすることは可能だということです。前回のJava Pet Storeデモでも、deployのボタンは押しましたが、deploytool上のさまざまなタブを開いて、細かなパラメータのチューニングを行ったわけではありませんでしたね。

　もう1つは、J2EEのサーバを立ち上げるたびに、配置の操作が必要なわけではないということです。J2EEサーバは、いったん配置されたアプリケーションを記憶します。ですから、前回、Java Pet StoreデモでJ2EEサーバへの配置が成功しているのなら、もしももう一度あのデモを動かそうと思ったら、今度は、配置のステップを省略できるのです。配置の手順を省いて、単にJ2EEサーバを立ち上げるだけで、Java Pet Storeデモ・アプリケーションが配置された状態が復活します。Cloudscapeデータベースへのテーブルの作成・データの初期設定についても同じことがいえます。いったん作成されたデータベースは、マシンの電源を落として再び立ち上げても、以前のデータベースの状態に戻らなくてはなりません。J2EEサーバへのアプリケーションの配置も、同じ性質を持つのです。配置は、データベース上のデータ同様「永続」するのです。

　

 J2EEアプリケーション ＝ EARファイル

　J2EEでのアプリケーションの配置については、読者の皆さんに少し考えてもらいたい問題が幾つかあります。

　第1は、「J2EEアプリケーションをJ2EEサーバに配置する」と簡単にいってきましたが、それでは、「配置される前」のJ2EEアプリケーションとはどんなものかという問題です。

　これについては以前にも簡単に説明したように、J2EEでは、配置前のアプリケーションは、実体としては*.earという名前を持つ1つのファイル（EARファイル）にほかなりません。例えばJava Pet Storeデモは、petstore.earという名前の1つのファイルにまとめられています。

　Java Pet Storeデモは、実際にはJSPファイル、Servletのクラス、EJBのJavaクラス、画像データ・ファイルなどなどの、たくさんのファイルから構成されています。deploytoolは、petstore.earという名前を持つ1つのファイルからたくさんのファイルを取り出して、J2EEサーバ上に配置しているわけです。逆に、どんなに複雑で多数の構成要素からなるアプリケーションも、こうして、たった1つのファイルにまとめ上げられるというのは、結構面白いことです。スタティックな実体としてのearファイルに配置という操作をすると、サーバ上でダイナミックにアプリケーションが走り出すという図式は、なかなか魅力的です。

　第2は、deploytoolにはたくさんのタブがあってさまざまなパラメータを設定できるのですが、deploytoolは、なぜ何の設定なしでもアプリケーション・ファイルから取り出されたファイルを、J2EEサーバ上に正しく配置できるのかという問題です。

　それは、J2EEアプリケーション・ファイル自身に、アプリケーションをJ2EEサーバ上に配置するための情報が組み込まれているからです。J2EEサーバ上では、配置情報はDeployment Descriptorというオブジェクトに収納されています。これらの情報は、実はXMLファイルの形式でEARファイルに含まれています。先に見たpetstore.earには、次のようなファイル(application.xml)があります。このほかにも、ｄeploy関連のファイルは存在します。deploytoolは、まず、これらのDeployment Descriptorファイル（以下DDファイル）を、EARファイルから取り出して、その情報に従って配置を行います。

<?xml version="1.0" encoding="ISO8859_1"?>

<!DOCTYPE application PUBLIC '-//Sun Microsystems, Inc.//DTD J2EE Application 1.2//EN'
'http://java.sun.com/j2ee/dtds/application_1_2.dtd'>

<application>
  <display-name>petstore</display-name>
  <description>Application description</description>
  <module>
    <ejb>inventoryEjb.jar</ejb>
  </module>
  <module>
    <ejb>customerEjb.jar</ejb>
  </module>
  <module>
    <ejb>shoppingcartEjb.jar</ejb>
  </module>
  <module>
    <ejb>mailerEjb.jar</ejb>
  </module>
  <module>
    <web>
      <web-uri>petstore.war</web-uri>
      <context-root>estore</context-root>
    </web>
  </module>
  <module>
    <ejb>petstoreEjb.jar</ejb>
  </module>
  <security-role>
    <description>the gold customer role</description>
    <role-name>gold_customer</role-name>
  </security-role>
  <security-role>
    <description>the customer role</description>
    <role-name>customer</role-name>
  </security-role>
  <security-role>
    <role-name>administrator</role-name>
  </security-role>
</application>
リスト1　application.xml

　では、だれがこのDDファイルを作ったのでしょうか？ J2EEでのアプリケーションの配置で、読者の皆さんに考えてもらいたい3つ目の問題は、実はこの疑問と結びついています。開発者はどのようにしたらさまざまのファイルを結び合わせて、deploytoolで配置可能な、*.ear形式のJ2EEアプリケーション・ファイルを作ることができるのでしょう？

　これへの答えは簡単です。deploytoolは、J2EEアプリケーションの利用者が、それをJ2EEサーバに配置するためのツールであると同時に、J2EEアプリケーションの開発者が、それを利用してJ2EEアプリケーション・ファイルを生成するための「開発ツール」でもあります。

　deploytoolで配置可能なファイルはdeploytool自身で作られるのです。DDファイルも、その際、deploytoolによって自動的に生成されます。

　先に見たDDファイルを、開発者が直接コードする必要はありません。開発者にとっては、deploytoolは、J2EEアプリケーションがJ2EEサーバに正確に渡さなければならないDeployment Descriptorの情報をキチンと作ってくれるツールとして、とても便利なものなのです。

　

 petstore.earファイルを「解凍」してみる

　本当に、J2EEアプリケーション・ファイルにDeployment Descriptorの情報が含まれているかを確認してみましょう。

　*.earの識別子を持つJ2EEアプリケーション・EARファイルは、JavaのJarファイルと同じデータ形式を持っています。JavaのJarファイルは、PCの世界ではよく利用されているZIP形式の圧縮ファイルですから、識別子は違っていてもJ2EEアプリケーション・ファイルは、ZIP解凍ツールでも解凍できるはずです。今回は、petstore.earファイルを「解凍」してみます。皆さんも、ぜひpetstore.earを解凍してみてください。

　実は、deploytoolの[Tools]メニューで[Descriptor Viewer...]を開けば、指定したコンポーネントのDeployment Descriptorの情報は、簡単に取り出せるのです（画面1）。

画面1　deploytoolを使ってDeployment Descriptorの情報を取り出す（クリックすると拡大します）

　自分の手でJ2EEアプリケーションを「分解」するわけですが、こうした、いわば「実験」的なアプローチは、対象をよく理解するうえではとても役に立つものです。時間がなければ、「マニュアルに書いてあるからそうなっているはずだ」と考えてもよいのですが、マニュアルに書いてあっても実際にそうなっていなかったり、マニュアルには書かれていないことも結構たくさんあるものです。

　次のリストは解凍ツールではなく、コマンドラインから、jarコマンドを使って、petstore.earの中身を確認してみたものです。

C:\java\j2sdkee1.3\jps1.1.1> jar tvf petstore.ear

 9752   Tue Nov 14 00:29:44 JST 2000 inventoryEjb.jar
51963  Tue Nov 14 00:29:46 JST 2000 customerEjb.jar
20564  Tue Nov 14 00:29:46 JST 2000 shoppingcartEjb.jar
6810   Tue Nov 14 00:29:46 JST 2000 mailerEjb.jar
259526 Tue Nov 14 00:29:50 JST 2000 petstoreEjb.jar
532305 Tue Nov 14 00:29:58 JST 2000 petstore.war
2      Tue Nov 14 00:30:00 JST 2000 META-INF/MANIFEST.MF
1037   Tue Nov 14 00:30:00 JST 2000 META-INF/application.xml
6022   Tue Nov 14 00:30:00 JST 2000 META-INF/sun-j2ee-ri.xml

　このリストを見ると、このpetstore.earファイルには、*Ejb.jarという名前のファイルが5つ、petstore.warという識別子が*.war型のファイルが1つ、含まれていることが分かります。先に見たapplication.xmlも、ちゃんとMETA-INFというディレクトリの下にあることが分かりますね。

　今度は、先のapplication.xmlのリストとこのリストとを、比較してみてください。

<application>....</application>の中に、

  <module>
     <ejb>inventoryEjb.jar</ejb>
  </module>

という形で、*Ejb.jarファイルが、さらに、

  <module>
    <web>
      <web-uri>petstore.war</web-uri>
      <context-root>estore</context-root>
    </web>
  </module>

　という形で、*.warファイルが含まれていますね。このように、application.xmlの記述は、きれいにJ2EEアプリケーション・ファイル「petstore.ear」の構成に対応していることが分かると思います。こうしたアプリケーションの構成の情報は、deploytoolの左側のカラムで表示されています（画面2）。

画面2　アプリケーション構成の情報は、deploytoolの左側のカラムに表示される （クリックすると拡大します）

　

 J2EEアプリケーション・ファイルの構成

　J2EEアプリケーション・ファイルの構成をまとめておきましょう。*.earという形のJ2EEアプリケーション・ファイルは、主要に、*Ejb.jarという形のEJBコンポーネントと、*.warという形のWebコンポーネントという2つのタイプのファイルから構成されています。J2EEアプリケーションが、Webブラウザ以外のクライアントを利用するときには、このクライアントもJ2EEアプリケーション・ファイルに含まれます。また、データベースへの接続などの条件を記述するRARファイルも、新しいバージョンのJ2EEでは追加されましたが、これについては今回は説明を割愛します。もちろんEARファイルには、このアプリケーションの配置情報も、XMLファイルの形式で含まれなければなりません。

J2EE アプリケーション・ファイル *.ear
  EJB コンポーネント・ファイル
*Ejb.jar
Web コンポーネント・ファイル
*.war
リソース・アダプタ・ファイル
 *.rar
J2EE アプリケーション・クライアント・ファイル *.jar
  <J2EE アプリケーション Deployment Descriptor> *.xml

　もう少し、強い言い方をしてみましょう。すべてのJ2EEアプリケーションは、*.earの形のJ2EEアプリケーション・ファイルの形でまとめられていなければなりません。サーバ・サイドのアプリケーションとしてJ2EEが動くためには、*.earの形のファイルが存在して、それが、サーバ上に配置されなければなりません。J2EEアプリケーションのEARファイルは、内部に必ず、EJBコンポーネント・ファイルかWebコンポーネント・ファイルを含まなければなりません。

　EARファイルの内部に含まれる、これらのファイルの構造については、次回に見ることにしましょう。

連載内容
J2EEの基礎
　 第1回　Java Pet Storeで、J2EEを体験する(1)
　 第2回　Java Pet Storeで、J2EEを体験する(2)

第3回　J2EEアプリケーションと配置（deployment）

　 第4回　J2EEアプリケーションを構成するコンポーネント
　 第5回　データベースのブラウザを作る
　 第6回　EJBにおけるコンテナとコンポーネント
　 第7回　J2EEのセキュリティのキホンを知る
　 第8回　J2EEのトランザクション処理


連載記事一覧




Java Agile フォーラム 新着記事
＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）

注目のテーマ

Java Agile 記事ランキング

本日 月間
＠IT