test

Sun Java System Application Server Enterprise Edition 8.2 アップグレードと移行

Application Server 6.x からのリッチクライアントの移行

この節では、iPlanet Application Server 6.x で開発された RMI/IIOP クライアントや ACC クライアントを Application Server8.2 に移行する手順について説明します。

Application Server 6.x でのクライアントの認証

Application Server 6.x は、アプリケーションがユーザーからユーザー名やパスワードなどの認証データを収集できるようにするクライアント側のコールバック機構を備えています。iPlanet CORBA インフラストラクチャーによって収集された認証データは、IIOP 経由で Application Server に伝達されます。

RMI/IIOP の ORB として ORBIX 2000 を使用している場合は、移植性のあるインターセプタが要求/応答シーケンス内の段階を定義するフック (中断ポイント) を提供することによってセキュリティーを実装します。

Sun Java System Application Server 8.2 でのクライアントの認証

認証は、JAAS (Java Authorization and Authentication System API) に基づいて行われます。クライアントが CallbackHandler を提供しない場合、ACC は LoginModule と呼ばれるデフォルトの CallbackHandler を使用して認証データを取得します。

認証に JAAS を使用する手順の詳細については、『Sun Java System Application Server Enterprise Edition 8.2 管理ガイド』の第 9 章「セキュリティーの設定」を参照してください。

Application Server 6.x および Sun Java System Application Server 8.2 での ACC の使用

Application Server 6.x では、独立した appclient スクリプトは提供されません。クラスパスに iascleint.jar ファイルではなく iasacc.jar ファイルを配置する必要があります。6.x で ACC を使用してアプリケーションクライアントをパッケージ化する唯一の利点は、クライアントアプリケーションに指定された JNDI 名が EJB の絶対 JNDI 名に間接的にマップされる点です。

Application Server 6.x アプリケーションでは、スタンドアロンクライアントは JNDI 検索で EJB の絶対名を使用します。つまり、ACC 外では次のような方法で JNDI が検索されます。

initial.lookup(“ejb/ejb-name”);
initial.lookup(“ejb/module-name/ejb-name”);

Application Server 6.5 SP3 を使用してアプリケーションを開発した場合は、絶対参照を使用して検索を行うときにプレフィックス java:comp/env/ejb/ を使用しました。

initial.lookup("java:comp/env/ejb/ejb-name");

Sun Java System Application Server 8.2 では、EJB の jndi-name に対して JNDI 検索を行います。EJB の絶対名を使用しないでください。また、Sun Java System Application Server 8.2 ではプレフィックス java:comp/env/ejb はサポートされません。クラスパス内の iasclient.jar、iasacc.jar、または javax.jar の各 JAR ファイルを appserv-ext.jar に置き換えてください。

Sun Java System Application Server 8.2 でアプリケーションがロードバランス機能を提供する場合は、クライアント側のコンテキストファクトリである S1ASCTXFactory の形式でのみロードバランス機能がサポートされます。このため、com.sun.appserv.iiop.loadbalancingpolicy システムプロパティーを次のように設定することにより、クラスタ内の代替のホストとポートを指定します。

com.sun.appserv.iiop.loadbalancingpolicy=

roundrobin,host1:port1,host2:port2,...,

このプロパティーは、ORB をラウンドロビンさせるためのホストとポートの組み合わせのリストを提供します。これらのホスト名を複数の IP アドレスにマップすることもできます。このプロパティーをシステムプロパティーとして org.omg.CORBA.ORBInitialHost および org.omg.CORBA.ORBInitialPort とともに使用した場合、ラウンドロビンアルゴリズムは提供されたすべての値をラウンドロビンします。しかし、コード内の環境オブジェクトにホスト名とポート番号を指定した場合は、その値がシステムプロパティーの設定値をオーバーライドします。

Application Server 6.5 でクライアントが接続するプロバイダ URL は、CORBA Executive Engine (CXS エンジン) の IIOP ホストおよびポートになります。Sun Java System Application Server 8.2 の場合は、クライアントがインスタンスの IIOP リスナーホストおよびポート番号を指定する必要があります。Sun Java System Application Server 8.2 には、独立した CXS エンジンは存在しません。

Sun Java System Application Server 8.2 のデフォルトの IIOP ポートは 3700 です。実際の IIOP ポートの値は、domain.xml 設定ファイルに指定されています。

ACC クライアントのロードバランス機能とフェイルオーバー機能 (Enterprise Edition)

Sun ONE Application Server 6.5 では、CXS エンジンが登録されている Java エンジンの数に応じてロードバランス機能を暗黙的に処理します。Application Server 8.2 Enterprise Edition でこの機能を使用するには、クライアントの明示的な設定の詳細が必要です。

配備記述子を 6.x から 8.2 に移行したら、ACC クライアントのフェイルオーバー機能を有効にするため、sun-acc.xml ファイルに設定の詳細を指定します。配備記述子の移行については、「Application Server 6.x からの配備記述子の移行」を参照してください。

可用性の高い ACC クライアントを提供するには、sun-acc.xml ファイルにロードバランスプロパティーを定義します。これらのプロパティーは、sun-acc.xml ファイル内のプロパティー要素として定義されます。

次に例を示します。

<client-container>
   <target-server name="qasol-e1" address="qasol-e1" port="3700">
   <property name="com.sun.appserv.iiop.loadbalancingpolicy" 
             value="ic-based" />
   <property name="com.sun.appserv.iiop.endpoints" 
             value="qasol-e1:3700,qasol-e1:3800" />
</client-container>

RMI/IIOP パス上で ACC クライアントをフェイルオーバーするには、RMI/IIOP 要求を継続できるクラスタ内のすべてのエンドポイントに関する情報が使用可能である必要があります。IIOP エンドポイントは、domain.xml ファイルで定義されている必要があります。availability-service 要素の下にある iiop-cluster 要素が IIOP エンドポイントを定義します。

詳細は、『Sun Java System Application Server Enterprise Edition 8.2 高可用性 (HA) 管理ガイド』の第 5 章「HTTP 負荷分散の設定」を参照してください。