| Oracle® Fusion Middleware Oracle WebLogic Serverスタンドアロン・クライアントのプログラミング 11g リリース1(10.3.3) B61622-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebLogic Serverスタンドアロン・クライアントのプログラミング 11g リリース1(10.3.3) B61622-01 |
|
前 |
次 |
Java EEアプリケーション・クライアントはクライアント・マシン上で実行され、マークアップ言語で得られるよりも高度なユーザー・インタフェースを実現できます。アプリケーション・クライアントはビジネス層で実行されているエンタープライズBeanに直接アクセスし、必要に応じてWeb層で実行されているサーブレットとHTTPを介して通信します。一般に、アプリケーション・クライアントはサーバーからダウンロードされますが、クライアント・マシン上にインストールすることもできます。
以下の節では、Java EEクライアントの開発について説明します。
Java EEアプリケーション・クライアント(シン・クライアント)はJavaアプリケーションですが、Java EEコンポーネントであるため、スタンドアロンのJavaアプリケーション・クライアントとは異なります。したがって、他のJava EE準拠のサーバーへ移植できるという利点があり、Java EEサービスにアクセスできます。
以下のアプリケーション・クライアントJARファイルが用意されています。
Java EE機能を提供する標準クライアントJAR(wlclient.jar)。「シン・クライアントの開発方法」を参照してください。
JMSクライアントJAR(wljmsclient.jar)。これをwlclient.jarとともにデプロイすることで、Java EEおよびWebLogic JMSの機能を提供します。第6章「WebLogic JMSシン・クライアント」を参照してください。
JMS SAFクライアントJAR(wlsafclient.jar)。これをwljmsclient.jarおよびwlclient.jarとともにデプロイすることで、スタンドアロンのJMSクライアントは、サーバー側のJMS宛先に一時的にアクセスできない場合でも、メッセージを宛先に確実に送信できるようになります。送信メッセージは、クライアント上でローカルに格納され、宛先が使用可能になったときに転送されます。第7章「JMS SAFクライアントによる確実なメッセージ送信」を参照してください。
これらのアプリケーション・クライアントJARファイルは、WebLogic Serverのインストール・ディレクトリのWL_HOME/server/libサブディレクトリに格納されています。
シン・クライアントでは、RMI-IIOPプロトコル・スタックを使用し、J2SEの機能を活用します。また、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を使用して、別のセキュリティ・マネージャをインストールできます。アプレットでは、スタブのダウンロードを可能にする別のセキュリティ・マネージャが使用されます。
Java EEアプリケーション・クライアントをデプロイする際には、クライアントのファイル・システムにwlclient.jarファイルがインストールされていること、クライアントのCLASSPATHにwlclient.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;
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);
}
リモート・インタフェースと実装クラスをJavaコンパイラでコンパイルします。RMI-IIOPアプリケーションにおけるこれらのクラスの開発は、通常のRMIでの開発と同じです。RMIオブジェクトの開発の詳細は、『Oracle WebLogic Server RMIのプログラミング』を参照してください。
実装クラスに対してWebLogic RMIまたはEJBコンパイラを実行して、必要なIIOPスタブを生成します。スタブをダウンロードする場合は、rmicを実行する必要はありません。
$ java weblogic.rmic -iiop nameOfImplementationClass
デプロイ時にスタブを生成するには、-iiopおよび-clientJarオプションを付けてappcを実行し、シン・クライアントでの使用に適したクライアントJARを作成します。この手順を実行しない場合、WebLogic Serverで必要に応じて実行時にスタブが生成され、クライアントに提供されます。
スタブはリモート・オブジェクト用のクライアント側プロキシで、個々のWebLogic RMI呼出しを対応するサーバー側スケルトンに転送します。続いてサーバー側スケルトンが、その呼出しを実際のリモート・オブジェクト実装に転送します。
ここまでで作成したファイル、すなわち、リモート・インタフェース、それを実装するクラス、およびスタブがWebLogic ServerのCLASSPATHに含まれていることを確かめます。
初期コンテキストを取得します。
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()を使用するように修正する必要があります。
例5-1 ルックアップの実行:
.
.
.
/**
* RMI/IIOP clients should use this narrow function
*/
private Object narrow(Object ref, Class c) {
return PortableRemoteObject.narrow(ref, c);
}
/**
* Lookup the EJBs home in the JNDI tree
*/
private TraderHome lookupHome()
throws NamingException
{
// Lookup the beans home using JNDI
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;
}
}
/**
* Using a Properties object will work on JDK130
* and higher clients
*/
private Context getInitialContext() throws NamingException {
try {
// Get an 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";
次のようなコマンドでクライアントを実行することで、IIOPを通じてクライアントをサーバーに接続します。
$ 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>タグを使用して宣言します。『Oracle WebLogic Serverアプリケーションの開発』のエンタープライズ・アプリケーションのデプロイメント記述子の要素に関する項を参照してください。
|
注意: <java>タグを、サーバー側モジュールで使用できるJavaコードの宣言と混同しないよう注意してください。この<java>タグは、サーバー側コンテナの外で実行するクライアント側コードを宣言するために使用します。 |
クライアント・モジュールは、基本的にはMETA-INF/application-client.xmlという特別なデプロイメント記述子を含むJARファイルです。このクライアントJARファイルのMETA-INF/MANIFEST.MFファイルには、プログラムのエントリ・ポイントを指定するMain-Classエントリも含まれます。application-client.xmlファイルの詳細は、「Aクライアント・アプリケーションのデプロイメント記述子の要素」を参照してください。
WebLogic Serverは、クライアント・モジュールの使用を容易にするためのユーティリティを備えています。このようなユーティリティには以下の2つがあります。
weblogic.ClientDeployer - EARからクライアント・モジュールを展開し、これを実行するための準備を行います。
weblogic.j2eeclient.Main - クライアント・コードを実行します。
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つの操作も実行されます。
JARファイルにMETA-INF/application-client.xmlファイルが含まれていることを確認します。含まれていない場合は例外が送出されます。
myclient.runtime.xmlというファイルから読取りを行い、展開されたJARファイル内にweblogic-application-client.xmlファイルを作成します。このファイルは、weblogic.j2eeclient.Mainユーティリティで、クライアント・アプリケーションのコンポーネント環境(java:comp/env)を初期化するために使用します。runtime.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ファイルに指定された情報に基づいて、weblogic.j2eeclient.MainクラスはサーバーのグローバルJNDIツリーからjava:comp/envへのバインドが試行されます。
ejb-ref
javax.jms.QueueConnectionFactory
javax.jms.TopicConnectionFactory
javax.mail.Session
javax.sql.DataSource
ユーザー・トランザクションは、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 11g リリース1(10.3.1)とWebLogic Serverの旧リリースの互換性については、Oracle WebLogic Serverインフォメーション・ロードマップのWebLogic Serverの互換性に関する項を参照してください。
