|
|
Java EE アプリケーション クライアントはクライアント マシン上で実行され、マークアップ言語で得られるよりも高度なユーザ インタフェースを実現できます。アプリケーション クライアントはビジネス層で実行されているエンタープライズ Bean に直接アクセスし、必要に応じて Web 層で実行されているサーブレットと HTTP を介して通信します。一般に、アプリケーション クライアントはサーバからダウンロードされますが、クライアント マシン上にインストールすることもできます。
以下の節では、Java EE クライアントの開発について説明します。
Java EE アプリケーション クライアント (シン クライアント) は Java アプリケーションですが、Java EE コンポーネントであるため、スタンドアロンの Java アプリケーション クライアントとは異なります。したがって、他の Java EE 準拠のサーバへ移植できるという利点があり、Java EE サービスにアクセスできます。
以下の 2 つのアプリケーション クライアント JAR ファイルが用意されています。
wlclient.jar)。「シン クライアントの開発方法」を参照してください。wljmsclient.jar)。これを wlclient.jar とともにデプロイすることで、Java EE 機能と WebLogic JMS 機能を提供します。「WebLogic JMS シン クライアント」を参照してください。wlsafclient.jar)。これを wljmsclient.jar および wlclient.jar とともにデプロイすることで、一時的に送り先にアクセスできない場合でも、スタンドアロンの JMS クライアントはサーバサイドの JMS 送り先にメッセージを確実に送信できるようになります。送信メッセージは、クライアント上でローカルに格納され、送り先が使用可能になったときに転送されます。「JMS SAF クライアントによる確実なメッセージ送信」を参照してください。
これらのアプリケーション クライアント JAR ファイルは、WebLogic Server のインストール ディレクトリの WL_HOME/server/lib サブディレクトリに格納されています。
シン クライアントでは、RMI-IIOP プロトコル スタックを使用し、J2SE 1.4 の機能を活用します。また、JDK ORB のサポートも必要とします。RMI リクエストの作成は基本的に JDK で処理されるため、非常に小さいクライアントを実現できます。クライアントサイドの開発は、WebLogic Server API ではなく標準の Java EE API を使用して実行されます。
シン クライアント アプリケーションの開発プロセスは、他の Java EE アプリケーションにおけるプロセスと同じです。クライアントでは InitialContext、UserTransaction、EJB などの標準 Java EE アーティファクトを活用できます。WebLogic Server シン クライアントでは、URL のプロトコル部分の値として IIOP、IIOPS、HTTP、HTTPS、T3、および T3S がサポートされています。それぞれ、InitialContext で異なる URL を使うことで選択できます。URL に関係なく、IIOP は必ず使用されます。URL に T3 を指定すると IIOP が使用され、T3S を指定すると IIOPS が使用されます。HTTP は IIOP 上を、HTTPS は IIOPS 上をトンネリングされます。
サーバサイド コンポーネントは、通常の方法でデプロイされます。クライアント スタブは、デプロイ時または実行時に生成できます。デプロイ時にスタブを生成するには、-iiop および -basicClientJar オプションを付けて appc を実行し、シン クライアントでの使用に適したクライアント jar を作成します。この手順を実行しない場合、WebLogic Server で必要に応じて実行時にスタブが生成され、クライアントに提供されます。クライアントでスタブをダウンロードするには、適切なセキュリティ マネージャがインストールされている必要があります。シン クライアントでは、デフォルトで軽量セキュリティ マネージャが提供されます。強固なセキュリティが必要な場合は、コマンドライン オプションの -Djava.security.manager -Djava.security.policy==policyfile を使用して、別のセキュリティ マネージャをインストールできます。アプレットでは、スタブのダウンロードを可能にする別のセキュリティ マネージャが使用されます。
シン クライアント JAR では、wlfullclient.jar の一部のクラスが置き換えられています。完全 jar とシン クライアント jar の両方を CLASSPATH に指定する場合は、シン クライアント jar がパス内で先になるようにします。ただし、シン クライアントのサポートに wlfullclient.jar は必須ではありません。必要な場合は、次の構文を使用して明示的に CLASSPATH を指定して実行できます。
java -classpath "<WL_HOME>/lib/wlclient.jar;<CLIENT_CLASSES>" your.app.Main
| 注意 : | wljmsclient.jar は wlclient.jar を参照するので、クライアント CLASSPATH にはどちらか一方の jar を指定するだけでかまいません。wljmsclient.jar をサーバサイドの CLASSPATH に指定しないでください。 |
シン クライアント jar には、javax.ejb などの必要な Java EE インタフェース クラスが格納されるので、その他の jar ファイルはクライアントには必要ありません。
java.rmi.Remote を拡張するインタフェースに定義します。
このリモート インタフェースには、コードをあまり記述する必要がない場合もあります。必要なのは、リモート クラスで実装するメソッドのメソッド シグネチャだけです。次に例を示します。
public interface Pinger extends java.rmi.Remote {
public void ping() throws java.rmi.RemoteException;
public void pingRemote() throws java.rmi.RemoteException;
public void pingCallback(Pinger toPing) throws java.rmi.RemoteException;
}interfaceNameImpl というクラスにインタフェースを実装し、それを JNDI ツリー内にバインドしてクライアントから利用できるようにします。
このクラスには、記述済みのリモート インタフェースを実装する必要があります。これにより、インタフェースに含まれるメソッド シグネチャを実装したことになります。すべてのコード生成はこのクラス ファイルに依存します。通常は、実装クラスを WebLogic 起動クラスとしてコンフィグレーションし、そのオブジェクトを JNDI ツリー内にバインドする main メソッドをインクルードします。以下に、上記の Ping のサンプルを基に開発した実装クラスからの抜粋を示します。
public static void main(String args[]) throws Exception {
if (args.length > 0)
remoteDomain = args[0];Pinger obj = new PingImpl();
Context initialNamingContext = new InitialContext();
initialNamingContext.rebind(NAME,obj);
System.out.println("PingImpl created and bound to "+ NAME);
}
| 注意 : | スタブをダウンロードする場合は、rmic を実行する必要はありません。 |
$ java weblogic.rmic -iiop nameOfImplementationClass
デプロイ時にスタブを生成するには、-iiop および -clientJar オプションを付けて appc を実行し、シン クライアントでの使用に適したクライアント JAR を作成します。この手順を実行しない場合、WebLogic Server で必要に応じて実行時にスタブが生成され、クライアントに提供されます。
スタブはリモート オブジェクト用のクライアントサイド プロキシで、個々の WebLogic RMI 呼び出しを対応するサーバサイド スケルトンに転送します。続いてサーバサイド スケルトンが、その呼び出しを実際のリモート オブジェクト実装に転送します。
RMI クライアントでは、初期コンテキストを作成しリモート オブジェクトをルックアップして (次のステップを参照)、そのオブジェクトにアクセスします。続いて、このオブジェクトが適切な型にキャストされます。
初期コンテキストの取得では、JNDI コンテキスト ファクトリを定義する際に weblogic.jndi.WLInitialContextFactory を使用する必要があります。新しい InitialContext() にパラメータとして渡す「Context.INITIAL_CONTEXT_FACTORY」プロパティの値を設定する際には、このクラスを使用します。
javax.rmi.PortableRemoteObject.narrow() メソッドと組み合わせてルックアップを実行するように、クライアントのコードを修正します。
RMI over IIOP RMI クライアントが通常の RMI クライアントと異なるのは、初期コンテキストを取得する際にプロトコルとして IIOP が定義されるという点です。このため、ルックアップとキャストは、javax.rmi.PortableRemoteObject.narrow() メソッドと組み合わせて行われます。たとえば RMI クライアントは、初期コンテキストを作成し、EJBean ホームをルックアップして EJBean への参照を取得し、EJBean 上でメソッドを呼び出します。
通常ならオブジェクトを特定のクラス型へキャストするような状況ではすべて、javax.rmi.PortableRemoteObject.narrow() メソッドを使用する必要があります。CORBA クライアントからは、リモート インタフェースを実装しないオブジェクトが返されることがあります。そのため、リモート インタフェースを実装するようオブジェクトを変換するために ORB から narrow メソッドが提供されます。たとえば、EJBean ホームをルックアップして、その結果を Home オブジェクトにキャストするクライアント コードは、以下に示すように、javax.rmi.PortableRemoteObject.narrow() を使用するように修正する必要があります。
ルックアップの実行 :.
.
.
/**
* RMI/IIOP クライアントではこの narrow 関数を使用する必要がある
*/
private Object narrow(Object ref, Class c) {
return PortableRemoteObject.narrow(ref, c);
}
/**
* JNDI ツリーで EJB ホームをルックアップ
*/
private TraderHome lookupHome()
throws NamingException
{
// JNDI を使用して Bean ホームをルックアップ
Context ctx = getInitialContext();
try {
Object home = ctx.lookup(JNDI_NAME);
return (TraderHome) narrow(home, TraderHome.class);
} catch (NamingException ne) {
log("The client was unable to lookup the EJBHome. Please
make sure ");
log("that you have deployed the ejb with the JNDI name
"+JNDI_NAME+" on the WebLogic server at "+url);
throw ne;
}
}/**
* JDK1.3 以降のクライアントでは、次のように Properties オブジェクトを使用すると
* 機能する
*/
private Context getInitialContext() throws NamingException {
try {
// InitialContext を取得
Properties h = new Properties();
h.put(Context.INITIAL_CONTEXT_FACTORY,
"weblogic.jndi.WLInitialContextFactory");
h.put(Context.PROVIDER_URL, url);
return new InitialContext(h);
} catch (NamingException ne) {
log("We were unable to get a connection to the WebLogic
server at "+url);
log("Please make sure that the server is running.");
throw ne;
}
}
.
.
.
url では、プロトコル、ホスト名、WebLogic Server インスタンス用のリスン ポートを定義し、それらがコマンドライン引数として渡されます。
public static void main(String[] args) throws Exception { log("\nBeginning statelessSession.Client...\n");String url = "iiop://localhost:7001";
$ java -Djava.security.manager -Djava.security.policy=java.policy examples.iiop.ejb.stateless.rmiclient.Client iiop://localhost:7001
Java EE では、クライアント アプリケーション コード (クライアント モジュール) の標準を EAR ファイルで指定します。これにより、アプリケーションのクライアントサイドを他のモジュールとともにパッケージ化したアプリケーションを作成できます。
クライアント モジュールは、EAR の META-INF/application.xml ファイルで <java> タグを使用して宣言します。詳細については、『WebLogic Server アプリケーションの開発』の「エンタープライズ アプリケーションのデプロイメント記述子の要素」を参照してください。
| 注意 : | <java> タグを、サーバサイド モジュールで使用できる Java コードの宣言と混同しないよう注意してください。この <java> タグは、サーバサイド コンテナの外で実行するクライアントサイド コードを宣言するために使用します。 |
クライアント モジュールは、基本的には META-INF/application-client.xml という特別なデプロイメント記述子を含む JAR ファイルです。このクライアント JAR ファイルの META-INF/MANIFEST.MF ファイルには、プログラムのエントリ ポイントを指定する Main-Class エントリも含まれます。application-client.xml ファイルの詳細については、「クライアント アプリケーションのデプロイメント記述子の要素」を参照してください。
WebLogic Server は、クライアント モジュールの使用を容易にするためのユーティリティを備えています。このようなユーティリティには以下の 2 つがあります。
Java EE EAR ファイルからクライアントサイド JAR ファイルを展開して、デプロイ可能な JAR ファイルを作成するには、weblogic.ClientDeployer ユーティリティを使用します。weblogic.ClientDeployer クラスは、Java コマンドラインで次の構文を使用して実行します。
java weblogic.ClientDeployer ear-file client1 [client2 client3 ...]
ear-file 引数は、拡張子 .ear を持つ Java アーカイブ ファイルか、1 つまたは複数のクライアント アプリケーション JAR ファイルが格納されている展開されたディレクトリです。
client 引数には、展開するクライアントを指定します。weblogic.ClientDeployer ユーティリティは、ここに指定したクライアントごとに、指定した名前の JAR ファイル (拡張子 .jar を含む) を EAR ファイル内から検索します。
java weblogic.ClientDeployer app.ear myclient
このコマンドでは、app.ear から myclient.jar が展開されます。weblogic.ClientDeployer ユーティリティでは、展開時に他の 2 つの操作も実行されます。
weblogic-application-client.xml ファイルを作成する。このファイルは、weblogic.j2eeclient.Main ユーティリティで、クライアント アプリケーションのコンポーネント環境 (java:comp/env) を初期化するために使用します。runtime.xml ファイルの形式の詳細については、「weblogic-appclient.xml 記述子の要素」を参照してください。| 注意 : | モジュールの META-INF/application-client.xml デプロイメント記述子のエントリのバインディングを定義するには、クライアント プログラムの <client>.runtime.xml 記述子を作成します。 |
EAR ファイルからクライアントサイドの JAR ファイルを展開したら、weblogic.j2eeclient.Main ユーティリティを使用してクライアントサイド アプリケーションをブートストラップし、次のコマンドを使用して WebLogic Server インスタンスを指すようにします。
java weblogic.j2eeclient.Main clientjar URL [application args]
java weblogic.j2eeclient.Main myclient.jar t3://localhost:7001
weblogic.j2eeclient.Main ユーティリティによって、クライアント コード内の java:comp/env からアクセス可能なコンポーネント環境が作成されます。
application-client.xml 記述子に記述されているリソースが以下のいずれかに該当する場合、あらかじめ myclient.runtime.xml ファイルに指定された情報に基づいて、サーバのグローバル JNDI ツリーから java:comp/env へのバインドが試行されます。
ユーザ トランザクションは、java:comp/UserTransaction にバインドされます。
application.xml デプロイメント記述子の <res-auth> タグは、現時点では無視され、application と入力されます。現時点では、フォームベースの認証はサポートされていません。
残りのクライアント環境は、weblogic.ClientDeployer ユーティリティによって作成された weblogic-application-client.xml ファイルからバインドされます。
バインディングが見つからない場合や不完全な場合は、weblogic.j2eeclient.Main クラスからエラー メッセージが出力されます。
環境が初期化されると、weblogic.j2eeclient.Main ユーティリティが Main-Class エントリの JAR クライアントの JAR マニフェストを検索します。このクラスの main メソッドを呼び出すと、クライアント プログラムが起動します。URL 引数の後ろで weblogic.j2eeclient.Main ユーティリティに渡したすべての引数は、クライアント アプリケーションに渡されます。
アプリケーション用に作成した Java クラス、およびそのアプリケーションが依存するすべての Java クラス (WebLogic Server クラスを含む) は、クライアント JVM から使用できるようにしておく必要があります。クライアント アプリケーションをステージするには、クライアントで必要とするすべてのファイルを特定のディレクトリにコピーし、そのディレクトリを JAR ファイルにバンドルします。クライアント アプリケーション ディレクトリの最上位には、アプリケーションを起動するためのバッチ ファイルやスクリプトを格納できます。Java クラスと JAR ファイルを保持するクラスまたはサブディレクトリを作成し、起動スクリプトのクライアント クラスパスに追加します。
Java クライアント アプリケーションに JRE (Java Runtime Environment) をパッケージ化することもできます。
| 注意 : | クライアント モジュール JAR で使用するクラスパス マニフェスト エントリは移植できません。これは、Java EE 標準で未対応であるためです。 |
次の表に、WebLogic Server シン クライアント間の相互運用性を示します。
  
|
