第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)があります。このほかにも、deploy関連のファイルは存在します。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のトランザクション処理


連載記事一覧



@IT Special

- PR -

TechTargetジャパン

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

イベントカレンダー

PickUpイベント

- PR -

アクセスランキング

もっと見る

ホワイトペーパーTechTargetジャパン

注目のテーマ

Java Agile 記事ランキング

本日 月間
ソリューションFLASH