Geronimo用のクライアント・アプリケーションを作る

ページオプション JavaScript を要するドキュメントオプションは表示されません サンプルコード 原文はこちら

レベル: 中級

Sing Li (westmakaha@yahoo.com), Author, Wrox Press

2005年 6月 07日

Geronimoはサーバー側の力持ちであり、JSPやサーブレット、EJB、データベース、キューイングを実行し、さらに他のサービスも行います。一方クライアント側では、Geronimoはクライアント・アプリケーション・コンテナーを提供するため、これを利用すると、クライアント・アプリケーションの設計やコーディングが容易になります。この記事では、このコンテナーの詳細を調べ、Geronimoクライアント（コンテナー・サポートを持つものと、持たないもの）の作り方を解説します。

Geronimoアプリケーションは、通常、Webベースです。Geronimoの一部であるJettyとTomcatエンジンは、JavaServer PageやJavaServer Face、サーブレット、その他のテンプレート技術やフレームワークによって作成された、Webベースのユーザー・インターフェースをサポートしています。ユーザーは通常、標準的なWebブラウザーを使ってアプリケーションにアクセスします。ブラウザーからアクセスされるWebアプリケーションは、よくシン・クライアント・ソリューション（thin-client solutions）と呼ばれます。

ところが多くの場合、Webベースのユーザー・インターフェースでは不適当なことがあります。こうした場合には、クライアント側のGUIライブラリー（例えばAWTやSwing、SWTなど）を使ってコードが作られます。こうしたクライアント・アプリケーションは、よくファット・クライアント・ソリューション（fat-client solutions）と呼ばれますが、このソリューションもシン・クライアント・ソリューションと同じように、Geronimoがホストするビジネス階層EJBやEIS階層サービスにアクセスします。

この記事では、J2EE 1.4コンポーネントであるGeronimoクライアント・アプリケーション・コンテナーを紹介します。これを使うことによって、ファット・クライアント・ソリューションを作る複雑さを大きく減少させることができるのです。ここでは、Geronimoのアーキテクチャーの中にある、クライアント・アプリケーション・コンテナーの役割について学びます。ここで挙げる実例を見れば、コンテナーを使ってクライアント・アプリケーションを作成、デプロイする方法が分かるでしょう。さらにこの記事では、クライアント・コンテナーを使わずにGeronimoのホストするEJBにアクセスする、スタンドアローンのアプリケーションの可能性についても探ります。

クライアント・アプリケーション・コンテナーの役割

Geronimoクライアント・アプリケーション・コンテナーは、クライアント側アプリケーション・コードに対して、標準のJ2EE環境を提供します。このクライアント側プログラミング環境は、サーバー側の環境と似ています。しかし、Geronimoサーバー内の管理された環境で実行するサーバー側J2EEモジュールとは異なり、クライアント・アプリケーションは、管理されない環境で独立に実行されます。クライアント・アプリケーション・コンテナーは、クライアント・アプリケーションで使えるようにJ2EEのAPIやサービスの一部を拡張していますが、コンポーネントの管理やホストのための機構は何ら提供していません。図1は、クライアント・アプリケーション・コンテナーが動作している様子を示しています。

図1は、アプリケーションを持った2台のクライアント・マシンが、1台のGeronimoサーバーにアクセスしている様子を示しています。こうしたマシンのユーザーは、ホストされているWebアプリケーションに対して、標準的なWebブラウザーを使ってアクセスすることができます。また、各クライアント・マシンでは、クライアント・アプリケーション・コンテナー内部でGeronimoファット・クライアント・アプリケーションが実行しています。こうしたファット・クライアント・アプリケーションは、単純なコマンドラインのユーザー・インターフェースを提供することもできますが、通常は、一般的なクライアント側GUI技術を利用して作られた、表現力豊かなユーザー・インターフェースを持っています。こうしたアプリケーションは、アプリケーション独自のHTTP接続を使ってサーバーに接続し、Web階層にアクセスしたり、あるいはGeronimoクライアント・アプリケーション・コンテナーの助けを借りて、ビジネス階層やEIS階層のオブジェクトにアクセスしたりすることができます。

• 物理的にGeronimoサーバーから分離している
• サーバーからは独立のJava? VM（あるいは物理的マシン）の中で実行している
• クライアント・アプリケーションの周りにラッパーを提供している
• ネットワークを通してGeronimoサーバーと通信している
• サーバーと密接な関係を保って動作し、クライアント・アプリケーションにとって透明な、参照解決やマッピング、依存性管理などを提供している

J2EEクライアント・ソリューションの世界に含まれる可能性のあるものとしては、シン・クライアントやファット・クライアントの他、それらに代わるクライアント側アクセス技術などがあります。この記事では、ファット・クライアント・ソリューションのみに焦点を当てます。他のソリューションに関しては、囲み記事、その他のクライアント側アクセス技術を参照してください。

その他のクライアント側アクセス技術 当然のことですが、表現力豊かなGUIを持つJavaクライアントの他にも、クライアント・アプリケーションでのユーザー・インターフェース実装に関して、他の技術が存在しています。例えばWebブラウザーは、サーバー・リソースにアクセスするJavaアプレット・ベースのユーザー・インターフェースを表示することができます。あるいは、Java Web Startは、1つのURLから完全なクライアント・アプリケーションをダウンロードし、実行することができます。Geronimoは、標準のプロトコル、例えばHTTPやHTTPS、CORBA、RMIなどを使って、こうした実装をサポートしています。クライアント・アプリケーション・コンテナーは、こうした代替ソリューションにおいては、何ら役割を演じることはありません。

クライアント側Javaアプリケーションを書く際にGeronimoクライアント・アプリケーション・コンテナーを使うと、任意のビジネス階層オブジェクトを、あたかもサーバー上でコーディングしているかのように単純に参照することができます。例えば、あたかもWebアプリケーションをサーバー側でコーディングしているかのように、同じJNDIコンテキストを使って、サーバー上でホストされているEJBを参照することができます（デプロイヤーがデプロイメント・ディスクリプターの同じ名前にEJBをマップしている限り）。Geronimoクライアント・アプリケーション・コンテナーはEJB参照を解決し、ユーザーに透明な形で、リモートからEJBにアクセスします。図2は、クライアント・アプリケーションのコーディングが、クライアント・アプリケーション・コンテナーによって、いかに単純になるかを示しています。

他のコンテナー・サービス クアイアント・コンテナーは、サーバーと共に、クライアント・アプリケーションに対して様々なサービスを提供します。（図2の中の、破線で囲んだOther servicesを見てください。）こうしたサービスの中には、ログインや認証などのセキュリティー・サービス、サーバー側での依存性管理、メッセージ駆動Beanに対するアクティベーション・サービス、Webサービスのルックアップなどがあります。こうしたサービスや詳細は、この記事の範囲外ですが、今後の記事では取り上げるかも知れません。

図2で、クライアント・アプリケーション・コンテナーはJNDIによって、参照解決(reference resolution)とマッピング階層(mapping layer)を提供しています。この階層によって、EJBのようなサーバー側オブジェクトに対して、継ぎ目なくアクセスできるようになります。その下では、サポートされている任意のプロトコルとトランスポート（JRMPやIIOP）を使って、クライアント・アプリケーション・コンテナーがサーバーと通信します。コンテナー内でホストされているクライアント・アプリケーションは、こうした詳細に注意を払う必要はありません。実際、アプリケーション・デプロイヤーは、JNDI名前マッピングやクライアント/サーバー通信の詳細をデプロイ時に変更することができ、しかもそうした変更をすべて、アプリケーションを変更することなく行えるのです。

EJBマッピングに加えて、クライアント・アプリケーション・コンテナーは、クライアント・アプリケーションに対して他のサービスも提供します。これについては囲み記事、他のクライアント・コンテナー・サービスで少し詳しく説明しましたので、見てください。

上に戻る

クライアント・アプリケーションのパッケージング

サーブレットやJSPはWARファイル（Web ARchive files）にパッケージされており、EJBはEJB JARファイルにパッケージされていますが、J2EEクライアント・アプリケーションはクライアント・アプリケーションのJARファイルにパッケージされています。便利なことに、クアイアント・アプリケーションのJARファイルは、同じ企業アプリケーション用の関連WARファイルやEJB JARファイル、RARファイルと共に、同じEARファイル（Enterprise ARchive file）内に置くことができます。1つのEARファイルの中には、複数のクライアント・アプリケーションJARファイルを入れることができます。すべてのものを1つのEARファイルに入れられることで、配布やデプロイ、維持管理が単純になります。例えば、EARをサーバー上にデプロイして全てのEJBやWeb層のコンポーネントを起動し、その後で、クライアント・アプリケーション・コンテナー上で同じEARをデプロイしてから、起動すべきクライアント・アプリケーションを選択することができます。図3は、EAR内にクライアント・アプリケーションJARファイルをパッケージする場合を示しています。

上に戻る

クライアント・デプロイメント・ディスクリプターとデプロイメント計画

developerWorksの記事、「Geronimo! Part 2: Tame this J2EE 1.4 bronco」（developerWorks, 2005年5月）では、Geronimo中でデプロイされたWARファイルやEJB JARファイルは、関連のJ2EE標準デプロイメント・ディスクリプターと、オプションとして、Geronimo特有のデプロイメント計画を含む必要があることを明らかにしています。クライアント・アプリケーション・コンテナーを使ってのクライアント・アプリケーション・アーカイブのデプロイも、この一般的なパターンに従います。表1は、必要なデプロイメント・ディスクリプターとオプションのデプロイメント計画を表しています。

表1にある通り、アーカイブの中にgeronimo-application-client.xmlを含まない場合には、Geronimoはデフォルトを使います。特別なサーバー側依存性やセキュリティー、リソース・アダプター要求などが無い限り、デフォルトでも大部分の場合は問題ありません。

上に戻る

スタンドアローンのGeronimoクライアント

Geronimoクライアント・アプリケーション・コンテナーは多くの用途に利用できますが、これを使うことが望ましくない場合もあります。例えば実際のクライアント・アプリケーションは既存の大規模なレガシー・システムであり、簡単に分離してアーカイブできない一体構造かも知れません。そうした場合には、クライアント・コンテナーの助けを借りずにクライアント・アプリケーションを作る必要があるかも知れません。これはGeronimoを使うと、ごく簡単に行うことができます。

図4は、クライアント・アプリケーション・コンテナー無しで動作する、スタンドアローンのGeronimoクライアント・アプリケーションの動作を説明しています。

クライアント・コンテナーの助けが無い場合には、スタンドアローンのJavaアプリケーションはJNDIトランスポートと通信プロトコルを明示的に設定し、Geronimoサーバー・インスタンスが使うトランスポートや通信プロトコルと一致させる必要があります。サーバーの設定が変更された場合には、このアプリケーションのコードも変更する必要があります。アプリケーションはEJBやGeronimoの通信プロトコルにアクセスする必要があるため、サポート・クラスを含むライブラリーを含める必要があります。クライアント・アプリケーション・コンテナーは無いため、アプリケーションは、コンテナーが提供する追加的なサービスを利用できません。これはクライアントの作り方としては望ましくありませんが、スタンドアローンのクライアントが唯一可能なソリューション、という場合はよくあるのです。

次の実際的な例を見ると、アプリケーション・クライアントのコード方法が分かるでしょう。最初はGeronimoクライアント・アプリケーション・コンテナーを使った方法、その後が、スタンドアローンのアプリケーション・クライアントとして作った場合です。

上に戻る

GUIクライアントの例

この例は、「Geronimo! Part 2: Tame this J2EE 1.4 bronco」で使った、Really Big Pet Storeの例から取ったものです。ここでは企業アプリケーションに対して、単純なGUIクライアントを追加します。この単純なSwingベースのGUIクライアント・アプリケーションは、ビジネス階層にあるCMP2実体EJBにアクセスし、ペット・ショップの製品カテゴリーすべてを表示します。

CategoryBeanと呼ばれる実体EJBは、製品カテゴリーを表します。対応するカテゴリー・データはEIS階層にあるRDBMSに保存されています。JDBCコネクターやRDBMSの設定方法に関しては、元の記事を見てください。図5は、この記事でのReally Big Pet Storeアプリケーションの下で何が行われているかを示しています。

図5に示した通り、CatClient と呼ばれるGUIクライアントは、クライアント・アプリケーション・コンテナーの中にあります。これは、サーバーにあるCategoryBean CMP2 EJBにアクセスし、そのfindAll()メソッドを呼んで製品カテゴリー・リストを取得します。注意して欲しいのですが、Web階層のJettyがホストするオリジナルのReally Big Pet Store WebアプリケーションからのStoreControllerサーブレットは、CategoriesBeanという名前のステートレス・セッション・ローカルEJBを通して、CategoryBean EJBにもアクセスします。

このクライアント・アプリケーションには、2つのバージョンがあります。

1. 最初のバージョンは、Geronimoクライアント・アプリケーション・コンテナー内部で実行し、そのEJBマッピング機構（図5に示しています）を利用します。
2. 2番目のバージョンは、同じアプリケーションのスタンドアローン版です。これはGeronimoサーバーに直接アクセスし、クライアント・アプリケーション・コンテナーは使用しません。

上に戻る

GUIクライアントをコーディングする

最初のバージョンは、コード・ディストリビューションのdistディレクトリーにある、reallybigpet.earという名前のEARファイルの中にアーカイブされています。このEARをデプロイする前に、必ず元の記事（参考文献）とREADMEファイルを見て、必要なJDBCコネクターとRDBMSテーブルを設定してください。

CatClientクライアント・アプリケーションは、独自のJARファイル（bigpetstore-clientapp.jarという名前で）の中にパッケージされています。このJARファイルは、EARファイルの一部です。このクライアント・アーカイブに対する標準J2EEデプロイメント・ディスクリプターは、リスト1に示すapplication-client.xmlです。このディスクリプターは、JARファイルのMETA-INFディレクトリーの中に置かれます。

                
<?xml version="1.0"?> 
<!--DOCTYPE application-client PUBLIC 
    "-//Sun Microsystems, Inc.//DTD J2EE Application Client 1.2//EN" 
    "http://java.sun.com/j2ee/dtds/application-client_1_2.dtd"--> 
<application-client xmlns="http://java.sun.com/xml/ns/j2ee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee 
    http://java.sun.com/xml/ns/j2ee/application-client_1_4.xsd"
    version="1.4">

    <display-name>dW Geronimo Application Client Example</display-name>
    <ejb-ref>
        <ejb-ref-name>ejb/CategoryEntityBean</ejb-ref-name>
        <ejb-ref-type>Entity</ejb-ref-type>
        <home>com.ibm.dw.reallybigpet.ejb.cmp.CategoryHome</home>
        <remote>com.ibm.dw.reallybigpet.ejb.cmp.CategoryRemote</remote>
    </ejb-ref>
</application-client>

リスト1では、サーバー側の実体EJBへの参照は、デプロイメント・ディスクリプターで規定されています。Geronimoサーバーは実際のEJBを、ホームとリモートのインターフェースと、規定されたEJBタイプに基づいて探します。このEJBに対する参照名はejb/CategoryEntityBeanにマップされます。このマッピングは、デプロイ時に、デプロイヤーによって設定されます。この、追加レベルでのマッピングがあるため、固定参照名を使ってクライアント・アプリケーションを開発することができ、またデプロイ時には実際のEJBに柔軟にマップすることができます。

クライアント・アプリケーション・コンテナーは、クライアント・アプリケーションJARにある、どのクラスが起動すべきクラスなのかを知る必要があります。従ってクライアント・アプリケーションJARファイルのマニフェストに、mainクラス、entryがあることを確認する必要があります。この場合、META-INF/MANIFEST.MFファイルで規定されるmainクラスは、com.ibm.dw.reallybigpet.client.CatClientです。

Main-Class: com.ibm.dw.reallybigpet.client.CatClient

bigpetstore-clientapp.jarは、Geronimo特有のデプロイメント計画は含んでいません（クライアント・アプリケーションには必要ありません）。Geronimoが提供するデフォルト計画で問題無いのです。

クライアント・アプリケーション・コンテナーを使ったリモートEJBへのJNDIアクセス

1. クライアント・アプリケーション・コンテナーが提供するJNDIの初期コンテキストを取得する。
2. コンテキストjava:comp/envを参照し、次にエントリーejb/CategoryEntityBeanを参照する（このエントリーは、リスト1でのマップ名、ejb/CategoryEntityBeanに対応することに注意してください）。
3. PortableRemoteObject.narrow()メソッドを使って、返されたリモート・オブジェクトをEJBホーム・インターフェースのタイプに絞り込む。
4. EJBホーム・インターフェースを使って、サーバー側EJBプログラミングの場合と同様に、EJBのインスタンスを作るか、あるいはフェッチする。

リスト2は、CatClient.javaのコードを示しています。このクラスはSwingベースのGUIを持っており、このGUIはReally Big Pet Storeで使用できる製品カテゴリーを全て表示します。EJBルックアップ・コードは、リスト2のCatClient.javaにあるgetCats()メソッドの中にあります。

                
package com.ibm.dw.reallybigpet.client;
import java.util.Collection;
import java.util.Iterator;
import java.util.Vector;
import com.ibm.dw.reallybigpet.ejb.cmp.CategoryHome;
import com.ibm.dw.reallybigpet.ejb.cmp.CategoryRemote;
import javax.naming.InitialContext;
import javax.naming.Context;
import javax.rmi.PortableRemoteObject;
import java.awt.BorderLayout;
import javax.swing.JFrame;
import javax.swing.JList;
import javax.swing.JPanel;
public class CatClient extends JFrame {
  public CatClient(String title) {
    super(title);
  }
  public void init() {
    JList catList = new JList(getCats());    
    JPanel pane = new JPanel();
    pane.setLayout(new BorderLayout());
    pane.add(catList, BorderLayout.CENTER);
    this.getContentPane().add(pane);
            setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
  }
  private Vector getCats() {
    Vector cats = new Vector();
    Collection coll = null;
    CategoryRemote cr = null;
    try {
      Context ic = new InitialContext();
      Object o = ic.lookup("java:comp/env/ejb/CategoryEntityBean");
      CategoryHome home = (CategoryHome) PortableRemoteObject.narrow(o,
          CategoryHome.class);
      coll = home.findAll();
      Iterator it = coll.iterator();
      while (it.hasNext()) {
        cr = (CategoryRemote) it.next();
        cats.add("Cat id= " + cr.getId() + ";  Name= " + cr.getName());
      } // of while
    } catch (Exception ex) {
      ex.printStackTrace();
    }
    return cats;
  }
  public static void main(String[] args) {
    CatClient lc = new CatClient("Really Big Pet Store Categories");
    lc.init();
    lc.setSize(350, 150);
    lc.setVisible(true);
  }
}

リスト2では、getCats()メソッドはEJBホーム・インターフェース上のfindAll()メソッドを呼び出し、返されたCategoryRemoteリモート・インスタンスまで繰り返して、リモート・インスタンスのidsとnamesを取得します。この情報はVectorの中に置かれます。このVectorはinit()メソッドの中で使われ、GUIに対するSwing JListを初期化します。このJListは、カテゴリー情報をエンドユーザーに対して表示します。

クライアント・アプリケーションのコンフィギュレーションを作る

これで、クライアント・アプリケーション・コンテナーを使って、CatClientを存分に試すことができます。サーバーが実行している状態で、前にサンプルを実行した時のreallybigpetコンフィギュレーションをすべてアンデプロイしたことを確認します（デプロイされたコンフィギュレーションを見るには、デプロイヤーのlist-modulesコマンドを使います）。また、PetsDBコンフィギュレーション（JDBCコネクター）もデプロイされ、実行していることを確認します。

サーバー側EJBとクライアント・アプリケーションJARを含んだreallybigpet.earファイルを、次のコマンドを使ってデプロイします。

java -jar bin\deployer.jar  deploy reallybigpet.ear

デプロイヤー・ツールは、ユーザー名とパスワードを入力するように促します。ユーザー名にはsystemを、パスワードにはmanagerを使います。

現在デプロイされているコンフィギュレーションを見るには、デプロイヤーのlist-moduleコマンドを使います。

java -jar bin\deployer.jarlist-modules

そうすると、サーバー側のreallybigpetコンフィギュレーションとクライアント・アプリケーションのコンフィギュレーションと共に、システムのコンフィギュレーションが見えるはずです。これを下記に示します。下記では、クライアント・アプリケーションのコンフィギュレーションを太字で示しています。

Found 22 modules
    org/apache/geronimo/Tomcat
    org/apache/geronimo/ActiveMQServer
    org/apache/geronimo/J2EEDeployer
    org/apache/geronimo/DefaultDatabase
    org/apache/geronimo/SpringDeployer
    org/apache/geronimo/Secure
    org/apache/geronimo/DebugConsole
    org/apache/geronimo/Server
    org/apache/geronimo/DeployerSystem
    org/apache/geronimo/ClientSystem
    org/apache/geronimo/SystemDatabase
    org/apache/geronimo/Client
    org/apache/geronimo/Demo
    org/apache/geronimo/SpringRuntime
    PetsDB
    org/apache/geronimo/InteropServer
    org/apache/geronimo/SystemJMS
reallybigpet/bigpetstore-clientapp
    reallybigpet
    org/apache/geronimo/RuntimeDeployer
    org/apache/geronimo/System
    org/apache/geronimo/RemoteClassLoadingDeployer

Geronimo特有のデプロイメント計画はクライアント・アプリケーションJARファイルに含まれていないので、Geronimoはクライアントのコンフィギュレーションに対して、デフォルト名を使っています。この名前は、クライアント・アプリケーションJARファイルの名前を取りまとめて作られた、デプロイされたEARファイルの名前を使って作られています。この場合では、クライアント・コンフィギュレーションにはreallybigpet/bigpetstore-clientappという名前が付いています。

クライアント・アプリケーション・コンテナーを実行する

クライアント・アプリケーション・コンテナー用のコードはbin/client.jarの中にあります。コンテナーを使ってCatClientアプリケーションをデプロイするには、クライアント・コンフィフィギュレーションの名前を引数として、クライアント・アプリケーション・コンテナーを起動します。

java -jar bin/client.jar reallybigpet/bigpetstore-clientapp

CatClientアプリケーションを実行すると、Swing GUIに、Really Big Pet Storeの全カテゴリーを表示したリストが見えるはずです（図6）。

図6で、Swing JListは製品カテゴリーの名前を、その製品カテゴリーIDのところで表示します。例えばハイライトされたカテゴリー、id 2は、Clearanceカテゴリーです。もし皆さんがお望みであれば、RDBMSのpetcatsテーブルを更新し、アプリケーションを再起動した時に、その更新がJListに現れるようにすることもできます。

上に戻る

スタンドアローン・クライアントのコーディング

クライアント・アプリケーション・コンテナーのサポートがない場合には、スタンドアローンのクライアントはサーバー側実体EJBに対して、自分でJNDIルックアップを実行する必要があります。リスト3は、スタンドアローンのクライアント、CatClientStandalone.javaのgetCats()メソッドを示しています

                
  private Vector getCats() {
    Vector cats = new Vector();
    Collection coll = null;
    CategoryRemote cr = null;
Properties props = new Properties();
    props.put("java.naming.factory.initial",
        "org.openejb.client.RemoteInitialContextFactory");
    props.put("java.naming.provider.url", "127.0.0.1:4201");
    props.put("java.naming.security.principal", "testuser");
    props.put("java.naming.security.credentials", "testpassword");
try {
      
      Context ic = new InitialContext(props);
      Object o = ic.lookup("CategoryBean");
CategoryHome home = (CategoryHome) PortableRemoteObject.narrow(o,
        CategoryHome.class);
      coll = home.findAll();
      Iterator it = coll.iterator();
      while (it.hasNext()) {
        cr = (CategoryRemote) it.next();
        cats.add("Cat id= " + cr.getId() + ";  Name= " + cr.getName());
      } // of while
    } catch (Exception ex) {
      ex.printStackTrace();
    }
    return cats;
  }

リスト3で、JNDI初期コンテキストは、org.openejb.client.RemoteInitialContextFactoryと呼ばれるカスタムのコンテキスト・ファクトリー（OpenEJB特有のラッパー）を使って組み立てられています。URLは、EJBネットワーク・サーバーのポートであるポート4201でローカル・マシンに接続します（開発ビルドに関する制限については、囲み記事、Geronimoの開発ビルドについてを見てください）。現在のビルドに関するデフォルトの認証情報は、それぞれtestuser:testpasswordです。

Geronimoの開発ビルドについて この記事で使っている例は、最新の不安定ビルドでも動作します。またSVNビルド179212 (05/31/05) と169186でもテストされています。最新の不安定ビルドの主な目的は、開発やテストを容易にするためです。従って、JNDIに対するプロバイダーURL情報は、（テストが容易なように）ローカル・マシンのみしかアクセスできないように設定されています。デフォルトのセキュリティー・ポリシーも、ローカル・マシンからのEJBプロトコル接続しか受け付けません。そのため（サーバーを再設定し、再ビルドしない限り）、クライアントのテストはループバック設定のみに制限されます。今後のGeronimoリリースでは、この制限が無くなるかも知れません。

クライアント・アプリケーション・コンテナー無しに済ます

クライアント・アプリケーション・コンテナーが無いので、java:comp/envコンテキストに対する設定は実行されません。また、参照マッピング階層が無いため、リモートEJBに対して、生のJNDI名を規定する必要があります。リスト3でのEJBに対するJNDI名はCategoryBeanです。サーバー上のGeronimoで使われている生のJNDI名は、EJBに対する要素を規定することによって設定することができます。この要素は、実体EJBに対するGeronimo特有のopenejb-jar.xmlデプロイメント計画の中にある、<enterprise-beans>要素の<entity>サブ要素の中で規定されます。

クライアント・アプリケーション・コンテナーのサポートが無いため、直接あるいは間接に参照される任意のGeronimoあるいはEJBクラスを、明示的に含む必要があります。このリストは、非常に大きなものになります。CatClientStandaloneクライアントに対して必要なライブラリーJARファイルには、次のようなものがあります。

• openejb-core-2.0-SNAPSHOT.jar
• geronimo-spec-j2ee-1.4-rc4.jar
• geronimo-kernel-1.0-SNAPSHOT.jar
• geronimo-security-1.0-SNAPSHOT.jar
• cglib-nodep-2.1.jar

Geronimoのリポジトリーとlibディレクトリーにある、上記のJARファイル全てに加えて、CategoryHomeやCategoryRemoteなどのEJBインターフェース・クラスも必要になります。ソースコード・ディストリビューション（参考文献）には、スタンドアローンのclientapp.jarファイルを作る、sajarと呼ばれるantターゲットがあり、スタンドアローンのクライアント・アプリケーションとEJBインターフェースをバンドルします。また、standaloneサブディレクトリーにはrun.batバッチ・ファイルもあり、従属ライブラリーJARファイルにアクセスするためのclasspathを設定します。このバッチ・ファイルは、次のようなものを含んでいます。

java -cp ./standalone-clientapp.jar;lib/openejb-core-2.0-SNAPSHOT.jar;
lib/geronimo-spec-j2ee-1.4-rc4.jar;lib/geronimo-kernel-1.0-SNAPSHOT.jar;
lib/cglib-nodep-2.1.jar;lib/geronimo-security-1.0-SNAPSHOT.jar
 com.ibm.dw.reallybigpet.client.CatClientStandalone

このバッチ・ファイルは、com.ibm.dw.reallybigpet.client.CatClientStandaloneクラスを直接起動し、bin\client.jarクライアント・アプリケーション・コンテナーは呼び出しません。

スタンドアローンのクライアント・アプリケーションをテストする

このバッチ・ファイルが正しく動作するためには、最初に全ての従属JARファイルがstandalone\libディレクトリーにコピーされていることを確認する必要があります。

スタンドアローンのクライアントを試すためには、run.batファイルを使います。これによってクライアントが起動し、実体EJBからの製品カテゴリーが表示されます。表示結果は図6と同じになります。

上に戻る

まとめ

Geronimoクライアント・アプリケーション・コンテナーは、J2EEアプリケーション開発環境を、クライアント側アプリケーションにまで拡張します。Geronimoを使うことによって、開発努力を大幅に節約でき、J2EE 1.4コンテナーのデプロイ時間を柔軟に制御できるようになります。クライアント・アプリケーション・コンテナーが使えない状況であっても、Geronimoライブラリーを使ってスタンドアローンのクライアント・アプリケーションをコーディングし、Geronimoサーバー上にあるビジネス階層オブジェクトにアクセスすることができます。

上に戻る

ダウンロード

	ダウンロード形式について

参考文献

• Geronimoに関する2回シリーズの記事を見てください。第1回「The J2EE 1.4 engine that could」（developerWorks, 2005年5月）は、Geronimoの概念についての概要紹介です。第2回「Tame this J2EE 1.4 bronco」（developerWorks, 2005年5月）は、Geronimoのコンフィギュレーションやデプロイ、管理を解説し、実際的な例としてWebアプリケーションとEJBのデプロイを取り上げています。
  
  
• developerWorksのApache Geronimoプロジェクトの領域では、Geronimo開発者のための資料を提供しています。
  
  
• Geronimo projectに関する公式サイトには、最新のソースコードやバイナリーがあり、またメーリング・リストやwikiなど、活発なコミュニティーもあります。
  
  
• Gluecode SEについて学び、またダウンロードしてください。Gluecode SEはApache Geronimoアプリケーション・サーバー上に構築され、Java認証された、製品グレードのプラットフォームです。
  
  
• JettyはGeronimoと統合された、デフォルトのサーブレットとJSPコンテナーです。詳しくは、Jettyの公式サイトを見てください。
  
  
• Tomcatは、Geronimoの代替となるサーブレットとJSPコンテナーです。詳しくは、Tomcatの公式Webサイトを見てください。
  
  
• GeronimoにあるEJBコンテナーはOpenEJBです。その機能の詳細については、OpenEJB projectを調べてください。
  
  
• Geronimoに対するデフォルトのリレーショナル・データベース・サービスとJDBCプロバイダーが、Derbyプロジェクトです。Derbyのマニュアルやソースコード、メーリング・リストに関する活発なユーザー・コミュニティーなどについては、DerbyプロジェクトのWebサイトを見てください。
  
  
• developerWorks blogsに参加して、developerWorksのコミュニティーに加わってください。
  

著者について

		Sing LiはWrox Pressから出版されている多数の本の著者で、Professional Apache Tomcat 、Early Adopter JXTA 、Professional Jini などを執筆しています。技術雑誌に頻繁に寄稿しており、P2P発展に関する熱心なエバンジェリスト（伝道者）でもあります。コンサルタント兼ライターであるSingの連絡先はwestmakaha@yahoo.comです。

記事の評価

サイト改善のため、ご意見をお寄せください。こちらのフォームからお願いいたします。 この情報はお客様が目的を達成するうえで役に立ちましたか？ はい いいえ わからない   お気軽にご意見・ご感想をお寄せください。   この記事は役に立ちましたか？ 1 2 3 4 5 不充分・不完全である 大変素晴らしい

この記事を共有する はてなブックマーク livedoorクリップ del.icio.us Buzzurl（バザール） Choix！ Saafブックマーク FC2ブックマーク MM/memo ニフティクリップ Yahoo!ブックマーク CZブックマーク newsing

上に戻る