test

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

第 6 章 Application Server 6.x/7.x からの移行

この章では、J2EE アプリケーションを Application Server Enterprise Edition 8.2 製品ラインに移行するときに必要な注意点と方針について説明します。

以降のセクションでは、一般的な J2EE アプリケーションの主要なコンポーネントを Application Server 6.x/7.x から Application Server Enterprise Edition 8.2 に移行する間に発生する問題について説明します。

この章の内容は次のとおりです。

この章で説明する移行の問題は、擬似的なオンラインバンキングサービスである iBank という J2EE アプリケーションに関して実際に行った Application Server 6.x/7.x から Sun Java System Application Server 8.2 への移行に基づいています。このアプリケーションは、従来の J2EE アプリケーションのすべての側面を反映しています。

iBank アプリケーションでは、J2EE 仕様の次の領域が網羅されています。

Application Server 6.x からの配備記述子の移行

配備記述子には、標準配備記述子と実行時配備記述子の 2 種類があります。標準配備記述子は、J2EE プラットフォームのバージョン間やベンダー間で移植性があり、変更を必要としません。現時点では、標準規格の解釈による例外があります。次の表は、そのような配備記述子の一覧です。

ソース配備記述子 

ターゲット配備記述子 

ejb-jar.xml - 1.1

ejb-jar.xml - 2.0

web.xml

web.xml

application.xml

application.xml

J2EE の標準配備記述子 ejb-jar.xml、web.xml、および application.xml には、大幅な変更はありません。ただし、アプリケーションを Sun Java System Application Server 8.2 上に配備できるようにするため、ejb-jar.xml 配備記述子は EJB 2.0 仕様に準拠するように変更されています。

実行時配備記述子は、ベンダーおよび製品に固有のものであり、その形式が異なるため、アプリケーションサーバー間で移植性がありません。このため、配備記述子の移行が必要です。この節では、実行時配備記述子を手動で作成し、関連する情報を移行する方法について説明します。

次の表に、配備記述子の移行マッピングの概要を示します。

ソース配備記述子 

ターゲット配備記述子 

ias-ejb-jar.xml

sun-ejb-jar.xml

<bean-name>-ias-cmp.xml

sun-cmp-mappings.xml

ias-web.xml

sun-web.xml

Application Server 8.2 に移行するときは、DTD が適合しないため、Application Server 6.x の標準配備記述子を変更する必要があります。

sun-ejb-jar.xml と sun-web.xml を作成するために必要な情報の大部分は、それぞれ ias-ejb-jar.xml と ias-web.xml に由来します。ただし、移行する sun-ejb-jar.xml に宣言がある場合は、一部の必要な情報が CMP エンティティー Bean のホームインタフェース (.java ファイル) から抽出されます。これは、その CMP エンティティー Bean のホームインタフェース内の情報を必要とする sun-ejb-jar.xml 内の <query-filter> コンストラクトを構築するために必要な条件です。移行時にこのソースファイルが見つからない場合は、移行された sun-ejb-jar.xml に <query-filter> コンストラクトが作成されますが、情報は設定されず、「REPLACE ME」の形で表されます。

さらに、ias-ejb-jar.xml に <message-driven> 要素が含まれている場合は、この要素内の情報が取得され、ejb-jar.xml と sun-ejb-jar.xml の両方に情報を設定するために使用されます。また、ias-ejb-jar.xml の <message-driven> 要素内には、MDB が待機するトピックまたはキューの JNDI 名を保持する <destination-name> 要素があります。Application Server 6.5 では、この JNDI 名の命名規則は cn=<SOME_NAME> です。この名前を持つ JMS トピックまたはキューは Application Server に配備できないため、アプリケーションサーバーはこれを <SOME_NAME> に変更し、この情報を sun-ejb-jar.xml に挿入します。この変更を、すべての有効な入力ファイル (すべての .java ファイル、.jsp ファイル、および .xml ファイル) に反映してください。このため、この JNDI 名の変更はアプリケーション全体に伝達されます。この JNDI 名への参照を含むソースファイルがあり、それらを使用できない場合、管理者はアプリケーションを配備できるように手動で変更してください。

Application Server 6.x からの Web アプリケーションの移行

Application Server 6.x は、サーブレット (Servlet API 2.2) および JSP (JSP 1.1) をサポートします。Sun Java System Application Server 8.2 は、Servlet API 2.4 と JSP 2.0 をサポートします。

これらの環境内では、アプリケーションの各種コンポーネント (サーブレット、JSP、HTML ページ、その他のリソース) をまとめて 1 つのアーカイブファイル (J2EE 標準の Web アプリケーションモジュール) にグループ化し、それをアプリケーションサーバーに配備することが不可欠です。

J2EE 仕様によれば、Web アプリケーションは次のような構造を持つアーカイブファイル (WAR ファイル) です。

Java Server Pages (JSP) と JSP カスタムタグライブラリの移行

Application Server 6.x は JSP 1.1 仕様に準拠し、Application Server 8.2 は JSP 2.0 仕様に準拠します。

JSP 2.0 仕様には、多くの新機能に加えて、JSP 1.1 仕様の更新が含まれています。

これらの変更は機能拡張であり、JSP ページの JSP 1.1 から 2.0 への移行には必要ありません。

Application Server 6.x の JSP カスタムタグライブラリの実装は、J2EE 仕様に準拠します。その結果、JSP カスタムタグライブラリの Application Server Enterprise Edition 8.2 への移行では、特に問題は発生せず、変更も必要ありません。

サーブレットの移行

Application Server 6.x は、Servlet 2.2 API をサポートします。Sun Java System Application Server 8.2 は、Servlet 2.4 API をサポートします。

Servlet API 2.4 では、サーブレットのコアはあまり変更されていません。ほとんどの変更は、コアの外部に追加された新機能に関係しています。

もっとも重要な機能を次に示します。

これらの変更は機能拡張であり、サーブレットを Servlet API 2.2 から 2.4 に移行する場合には必要ありません。

ただし、アプリケーション内のサーブレットが JNDI を使用して J2EE アプリケーション内のリソース (データソースや EJB など) にアクセスする場合は、ソースファイルや配備記述子にいくつかの変更が必要になることがあります。

これらの変更の詳細については、次の節で説明します。

最後のシナリオとして、サーブレットコードの変更が必要になる場合があります。JSP ページに既存の Java クラスと同じ名前が存在する場合は、Application Server 6.x で名前の競合が発生する可能性があります。このような場合は、JSP ページ内の該当する名前を変更することによって、競合を解決してください。さらに、場合によっては、この JSP ページを呼び出すサーブレットのコードも編集する必要があります。この問題は、新しいクラスローダー階層を使用する Application Server では解決されています。新しいバージョンのアプリケーションサーバーでは、特定のアプリケーションに関して、1 つのクラスローダーがすべての EJB モジュールを読み込み、別のクラスローダーが Web モジュールを読み込みます。これら 2 つのローダーどうしは通信しないため、名前の競合は発生しません。

JNDI コンテキストからのデータソースの取得

JNDI コンテキストにバインドされたデータソースへの参照を取得するには、初期コンテキストオブジェクトからデータソースの JNDI 名を検索します。次に、このようにして取得されたオブジェクトを次のように DataSource タイプのオブジェクトとしてキャストします。

ds = (DataSource)ctx.lookup(JndiDataSourceName);

詳細は、「JDBC コードの移行」を参照してください。

JNDI コンテキストでの EJB の宣言

第 4 章「EJB 1.1 から EJB 2.0 への移行」の 「JNDI コンテキストにおける EJB の宣言」を参照してください。

サーブレットおよび JSP の移行に関する潜在的な問題

サーブレットまたは JSP アプリケーションのコンポーネントを実際に Application Server 6.x から Application Server 8.2 に移行するときは、コンポーネントのコードを変更する必要はありません。

Web アプリケーションがデータソースなどのサーバーリソースを使用する場合、Application Server ではそのリソースを web.xml ファイル内で宣言し、sun-web.xml ファイル内でも同様に宣言する必要があります。jdbc/iBank という名前のデータソースを宣言する場合は、web.xml ファイルの <resource-ref> タグは次のようになります。

<resource-ref>
   <res-ref-name>jdbc/iBank</res-ref-name>
   <res-type>javax.sql.XADataSource</res-type>
   <res-auth>Container</res-auth>
   <res-sharing-scope>Shareable</res-sharing-scope>
</resource-ref>

これに対応する sun-web.xml ファイル内の宣言は、次のようになります。

<?xml version="1.0" encoding="UTF-8"?>
<! DOCTYPE FIX ME: need confirmation on the DTD to be used for this file
<sun-web-app>
   <resource-ref>
      <res-ref-name>jdbc/iBank</res-ref-name>
      <jndi-name>jdbc/iBank</jndi-name>
   </resource-ref>
 </sun-web-app>

Web アプリケーションモジュールの移行

アプリケーションを Application Server 6.x から Sun Java System Application Server 8.2 に移行するときは、Java コードや Java Server Pages を変更する必要はありません。ただし、次のファイルは変更する必要があります。

Application Server は J2EE 1.4 標準規格に準拠しているため、WAR ファイル内の web.xml ファイルは改訂された DTD (http://java.sun.com/dtd/web-app_2_3.dtd) に従う必要があります。この DTD は旧バージョンの DTD のスーパーセットなので、移行する web.xml ファイル内の <! DOCTYPE 定義を変更するだけで済みます。変更された <! DOCTYPE 宣言は、次のようになります。

<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.// 
                        DTD Web Application 2.3//EN" 
                        "http://java.sun.com/dtd/web-app_2_3.dtd">

Application Server Enterprise Edition 8.2 では、このファイルの名前が sun-web.xml に変更されます。

この XML ファイルでは、Web アプリケーションに必要な Application Server 固有のプロパティーとリソースを宣言する必要があります。

このファイルに追加すべき重要な内容については、「サーブレットおよび JSP の移行に関する潜在的な問題」を参照してください。

Application Server 6.5 アプリケーションの ias-web.xml が存在し、Application Server 6.5 固有のプロパティーが宣言されている場合は、このファイルを Application Server の標準規格に移行する必要があります。DTD のファイル名は、sun-web.xml に変更してください。詳細は、URL http://wwws.sun.com/software/dtd/appserver/sun-web-app_2_4-1.dtd を参照してください。

web.xml ファイルと ias-web.xml ファイルにこれらの変更を行ったあとは、Application Server の配備ツール GUI インタフェースまたは asadmin コマンド行ユーティリティーから Web アプリケーション (WAR ファイル) を配備できます。配備コマンドでは、アプリケーションのタイプを Web として指定してください。

asadmin コマンド行ユーティリティーを起動するには、Application Server の bin ディレクトリで asadmin.bat ファイルまたは asadmin.sh スクリプトを実行します。

asadmin プロンプトで入力するコマンドを次に示します。

asadmin deploy -u username -w password
-H hostname 
-p adminport 
--type web 
[--contextroot contextroot] 
[--force=true] 
[--name component-name] 
[--upload=true] filepath

Application Server 6.x からのエンタープライズ EJB モジュールの移行

Application Server 6.x は EJB 1.1 をサポートし、Application Server は EJB 2.0 をサポートします。このため、どちらも次のものをサポートできます。

ただし、EJB 2.0 には MDB と呼ばれる新しいタイプのエンタープライズ Bean が導入されています。

J2EE 1.4 仕様によれば、EJB の各種コンポーネントは次のような構造を持つ JAR ファイルにグループ化する必要があります。

Application Server 6.x では、このアーカイブ構造が使用されます。ただし、EJB 1.1 仕様では、各 EJB コンテナベンダーに対して、彼らが次のような特定のものを適当と見なした場合には実装させる余地を残しています。

EJB の移行

第 3 章「J2EE アプリケーションの移行」で説明したように、Application Server 6.x は EJB 1.1 仕様をサポートするのに対し、Application Server は EJB 2.0 仕様もサポートします。EJB 2.0 仕様では、次のような新機能がアーキテクチャーに導入されています。

Application Server でも EJB 1.1 仕様は引き続きサポートされますが、EJB 2.0 の拡張機能を利用できるように、EJB 2.0 アーキテクチャーの使用をお勧めします。

EJB 1.1 から EJB 2.0 への移行の詳細については、第 4 章「EJB 1.1 から EJB 2.0 への移行」を参照してください。

Application Server Platform Edition 8.2 固有の EJB の変更

Application Server 6.x から Application Server 8.2 に EJB を移行するときは、EJB のコードを変更する必要はありません。ただし、次のような DTD の変更が必要です。

セッション Bean

注 –

アプリケーション内の JNDI 名が変更されるのを防ぐため、EJB の JNDI 名を <jndi-name> タグ内で ejb/<ejb-name> として宣言してください。

SFSB フェイルオーバーをサポートする EJB アプリケーションの移行

Sun ONE Application Server 6.5 は、ステートフルセッション Bean のフェイルオーバーをサポートします。6.5 で SFSB フェイルオーバーを利用するには、フェイルオーバーと DSync (Distributed Store) を使用してセッションを設定する必要があります。DSync 機構は、実行中のセッション Bean の対話状態を保存するために使用されます。

注 –

Sun ONE Application Server 6.5 は、RMI/IIOP パス上のリッチクライアントに関して、ステートフルセッション Bean のフェイルオーバーをサポートしません。このようなアプリケーションは、Sun Java System Application Server 8.2 の RMI/IIOP パス上の SFSB フェイルオーバーを利用できます。SFSB フェイルオーバーの設定の詳細については、『Sun Java System Application Server Enterprise Edition 8.2 高可用性 (HA) 管理ガイド』の「ステートフルセッション Bean のフェイルオーバー」を参照してください。

Sun Java System Application Server 8.2, Enterprise Edition は、ステートフルセッション Bean のフェイルオーバーをサポートします。Application Server 8.2 は、セッションデータの格納に高可用性データベース (HADB) を使用します。SFSB フェイルオーバーのサポートで順守される原則は、SFSB の対話状態をそのライフサイクルのあらかじめ定義された時点で持続的ストアに保存することです。この機構は、チェックポイントと呼ばれます。サーバーがクラッシュした場合は、SFSB のチェックポイント化された状態を持続的ストアから取得できます。セッションデータの格納に HADB を使用するには、HADB を永続的ストアとして設定してください。HTTP セッションとステートフルセッション Bean の基本となるストアは同じであり、永続的ストアの設定はセッションストアの設定とほぼ同じです。

セッションフェイルオーバーのための HADB の設定については、『Sun Java System Application Server Enterprise Edition 8.2 高可用性 (HA) 管理ガイド』の第 9 章「高可用性 (HA) セッション持続性とフェイルオーバーの設定」を参照してください。

Sun ONE Application Server 6.5 に配備されたステートフルセッション Bean を Sun Java System Application Server 8.2 に移行するときは、EJB のコードを変更する必要はありません。ただし、次の手順を実行する必要があります。

エンティティー Bean

メッセージ駆動型 Bean

Application Server はメッセージ駆動をシームレスにサポートします。このサポートは、Sun Java System Message Queue と Application Server を密接に統合し、ネイティブの組み込み型 JMS サービスを提供することによって実現されます。

Message Queue をインストールすると、任意の数の Application Server インスタンスをサポートする JMS メッセージングシステムが Application Server に提供されます。各サーバーインスタンスには、デフォルトで、そのインスタンスで実行中のすべての JMS クライアントをサポートする組み込み型 JMS サービスが関連付けられています。

『Enterprise JavaBeans Specification, v2.0』で定義されたコンテナ管理トランザクションと Bean 管理トランザクションの両方がサポートされます。

iPlanet Application Server のメッセージ駆動型 Beans サポートは、開発者に限定されており、古い専用 API を多用していました。メッセージングサービスは、iPlanet Message Queue for Java 2.0 によって提供されていました。Queue Connection Factory オブジェクトを設定するには、iPlanet Application Server の下に LDAP ディレクトリも必要でした。

現在は、QueueConnectionFactory と Application Server 内でメッセージ駆動型 Beans を設定するために必要なその他の要素を ejb-jar.xml ファイルに指定する必要があります。

配備記述子の変更の詳細については、「Application Server 6.x からの配備記述子の移行」を参照してください。メッセージ駆動型 Bean については、『Sun Java System Application Server Enterprise Edition 8.2 Developer’s Guide』の「Using Message-Driven Beans」を参照してください。

Application Server 6.x からのエンタープライズアプリケーションの移行

J2EE 仕様によれば、エンタープライズアプリケーションは次のような構造を必要とする EAR ファイルです。

アプリケーション配備記述子では、エンタープライズアプリケーションと Web アプリケーションのコンテキストルートを構成するモジュールが定義されます。

Application server 6.x と Application Server 8.2 は、主に J2EE モデルをサポートします。このモデルでは、アプリケーションがエンタープライズアーカイブ (EAR) ファイル (拡張子は .ear) の形式でパッケージ化されます。アプリケーションはさらに J2EE モジュールの集まりに分割され、EJB 用の Java アーカイブ (拡張子が .jar の JAR ファイル) とサーブレットおよび JSP 用の Web アーカイブ (拡張子が .war の WAR ファイル) にパッケージ化されます。

エンタープライズアプリケーションを配備する前に、次に示す手順を実行することが不可欠です。

ProcedureEAR ファイルを構築する

  1. EJB を 1 つ以上の EJB モジュールにパッケージ化します。

  2. Web アプリケーションのコンポーネントを Web モジュールにパッケージ化します。

  3. EJB モジュールと Web モジュールを組み合わせて 1 つのエンタープライズアプリケーションモジュールを作成します。

  4. エンタープライズアプリケーションのルートコンテキストの名前を定義します。これによって、アプリケーションにアクセスするための URL が決まります。

    Application Server では、Application Server 6.x にはなかった新しいクラスローダ階層が使用されます。この新しい方式では、特定のアプリケーションについて、1 つのクラスローダーがすべての EJB モジュールを読み込み、別のクラスローダーが Web モジュールを読み込みます。これら 2 つのモジュールは親子の階層関係を持っており、JAR モジュールクラスローダが WAR モジュールクラスローダの親モジュールになります。JAR クラスローダによって読み込まれたクラスはすべて WAR モジュールでも使用またはアクセスできますが、逆 (WAR クラスローダによって読み込まれたクラスを JAR モジュールで使用またはアクセスすること) はできません。あるクラスが JAR ファイルだけでなく WAR ファイルでも必要な場合は、そのクラスを JAR モジュール内だけでパッケージ化してください。この指針に従わない場合、クラス競合が発生する可能性があります。

アプリケーションルートコンテキストとアクセス URL

Application Server 6.x と Application Server8.2 では、アプリケーションのアクセス URL (アプリケーションの Web モジュールのルートコンテキスト) に関して大きな違いがあります。hostname という名前のサーバー上に配備されたアプリケーションのルートコンテキストの名前が AppName である場合、このアプリケーションのアクセス URL は、次のように使用されるアプリケーションサーバーによって異なります。

Application Server 8.2 がデフォルトで使用する TCP ポートは、ポート番号 8080 です。

Application Server 6.x と Application Server のアクセス URL の違いはわずかなものに見えますが、絶対 URL 参照を使用するアプリケーションを移行するときに問題になる可能性があります。このような場合は、Application Server 6.x 用の Web サーバープラグインで使用される固有のマーカーが付加されないように、コードを編集して絶対 URL 参照を更新する必要があります。

フォームベース認証を使用するアプリケーション

Application Server 6.5 で開発され、フォームベース認証を使用するアプリケーションは、認証フォームまたはログインページに要求パラメータを渡すことができます。入力パラメータに基づいて認証パラメータを表示するようにログインページをカスタマイズすることもできます。

次に例を示します。

http://gatekeeper.uk.sun.com:8690/NASApp/test/secured/page.jsp?arg1=test&arg2=m

Application Server 8.2 は、ログインページ表示中の要求パラメータの引き渡しをサポートしません。フォームベース認証を使用し、要求パラメータを渡すアプリケーションは、Application Server8.2 に移行できません。このようなアプリケーションを Application Server8.2 に移植するには、コードの大幅な変更が必要です。代わりに、要求パラメータの情報をセッションに格納して、それをログインページの表示中に取得できます。

次に、この問題を解決するコード例を示します。

変更前の 6.5 のコードは次のとおりです。

---------index-65.jsp -----------
<%@page contentType="text/html"%>
<html>
<head><title>JSP Page</title></head>
<body>
go to the <a href="secured/page.htm">secured a rea</a>
</body>
</html>
----------login-65.jsp--------------
<%@page contentType="text/html"%>
<html>
<head> </head>
<body>
<!-- Print login form -->
<h3>Parameters</h3><br>
out.println("arg1 is " + request.getParameter("arg1"));
out.println("arg2 is " + request.getParameter("arg2"));
</body>
</html>

変更後の Application Server8.2 のコードは次のとおりです。

---------index-81.jsp -----------
<%@page contentType="text/html"%>
<html>
<head><title>JSP Page</title></head>
<body>
<%session.setAttribute("arg1","test"); %>
<%session.setAttribute("arg2","me"); %>
go to the <a href="secured/page.htm">secured area</a>
</body>
</html>

index-81.jsp は、セッションの要求パラメータの格納方法を示しています。

----------login-81.jsp--------------
<%@page contentType="text/html"%>
<html>
<head> </head>
<body>
<!-- Print login form -->
<h3>Parameters</h3><br>
<!--retrieving the parameters from the session -->
out.println("arg1 is"+(String)session.getAttribute("arg1"));
out.println("arg2 is” + (String)session.getAttribute("arg2"));
</body>
</html>

Application Server 6.x からの固有の拡張の移行

Application Server 6.x 環境独自の多数のクラスがアプリケーション内で使用されている場合があります。Application Server 6.x で使用される固有のパッケージの一部を次に示します。

これらの API は、Application Server8.2 ではサポートされません。前述のパッケージに属するクラスを使用するアプリケーションは、標準の J2EE API を使用するように作成し直す必要があります。また、カスタム JSP タグや UIF フレームワークを使用するアプリケーションも、標準の J2EE API を使用するように作成し直す必要があります。

Application Server 6.x からの UIF の移行

Application Server 8.2 は、アプリケーションの UIF (Unified Integration Framework) API をサポートしません。代わりに、アプリケーションを統合する JCA (J2EE Connector Adapter) の使用をサポートします。しかし、Application Server 6.5 で開発されたアプリケーションには UIF が使用されています。このようなアプリケーションを Application Server8.2 に配備するには、UIF を J2EE コネクタアーキテクチャーに移行する必要があります。この節では、UIF を使用してアプリケーションを Application Server に移行するための必要条件と手順について説明します。

アプリケーションを移行する前に、Application Server 6.5 に UIF がインストールされていることを確認します。インストールされているかどうかをチェックするには、次のいずれかの方法に従います。

レジストリファイルのチェック

UIF は、アプリケーションサーバーの拡張セットとしてインストールされます。これらは、インストール時にアプリケーションサーバーのレジストリに登録されます。UIF がインストールされているかどうかをチェックするには、レジストリ内で次の文字列を検索します。

拡張名セット:

Solaris オペレーティング環境のレジストリファイルは、次の場所にあります。

AS_HOME/AS/registry/reg.dat

インストールディレクトリの UIF バイナリのチェック

UIF インストーラは、アプリケーションサーバーインストールに特定のバイナリファイルをコピーします。次に示すファイルが見つかった場合は、UIF がインストールされています。

Solaris および Windows でのファイルの場所は次のとおりです。

AS_HOME/AS/APPS/bin

Solaris で検索するファイルのリスト:

Windows で検索するファイルのリスト:

UIF を Application Server8.2 に移行する前に、アプリケーション内で UIF API が使用されていることを確認してください。使用されているかどうかは、次のようにして確認します。

Application Server8.2 への UIF の移行については、appserver-migration@sun.com に問い合わせてください。

Application Server 6.x からの JDBC コードの移行

JDBC API を使用したデータベースアクセスには、次の 2 つの方法があります。

注 –

Application Server8.2 は、Application Server 6.x に含まれている Native Type 2 JDBC ドライバをサポートしません。Type 2 のドライバを使用して他社製の JDBC ドライバにアクセスするコードは、手動で移行する必要があります。

DriverManager インタフェースを介した接続の確立

このデータベースアクセス方法は古くてあまり効率がよくないため推奨されていませんが、まだこの方法を使用しているアプリケーションが存在する可能性があります。

その場合、アクセスコードは次のようになります。

public static final String driver = "oracle.jdbc.driver.OracleDriver";
public static final String url = 
  "jdbc:oracle:thin:tmb_user/tmb_user@iben:1521:tmbank";
Class.forName(driver).newInstance();
Properties props = new Properties();
props.setProperty("user", "tmb_user");
props.setProperty("password", "tmb_user");
Connection conn = DriverManager.getConnection(url, props);

このコードは、Application Server 6.x から Application Server8.2 に完全に移植できます。ただし、Application Server8.2 が適切な JDBC ドライバを読み込むのに必要なクラスを特定できることが条件です。必要なクラスが Application Server に配備されたアプリケーションにアクセスできるようにするには、Application Server のインストールディレクトリの /lib ディレクトリにドライバ実装用のアーカイブ (JAR または ZIP) を置きます。

管理コンソールの GUI を使用してドライバのパスを設定することにより、CLASSPATH を変更します。

JDBC 2.0 データソースの使用

データベースへのアクセスに JDBC 2.0 データソースを使用すると、パフォーマンス上の利点 (透過的な接続プーリングなど) が得られるとともに、コードや実装が単純化することで生産性が向上し、コードの移植性が高まります。

Application Server 6.x アプリケーション上に xyz と言う名前のデータソースがあり、JNDI 検索コードに影響を与えたくない場合は、Application Server8.2 のために作成するデータソースの名前に必ず「JDBC」を付けてください。次に例を示します。jdbc/xyz。

JDBC データソースの設定については、『Sun Java System Application Server Enterprise Edition 8.2 管理ガイド』の第 3 章「JDBC リソース」を参照してください。

JNDI 経由でデータソースを検索して接続を取得する

データソースから接続を取得するには、次の手順に従います。

Procedureデータソースに接続する

  1. 初期 JNDI コンテキストを取得します。

    異なる環境間での移植性を保証するには、(サーブレット、JSP ページ、または EJB 内にある) InitialContext オブジェクトを取得するためのコードを次のようにします。

    InitialContext ctx = new InitialContext();

  2. JNDI 検索を使用してデータソースへの参照を取得します。

    JNDI コンテキストにバインドされたデータソースへの参照を取得するには、初期コンテキストオブジェクトからデータソースの JNDI 名を検索します。この方法で検索されたオブジェクトを次のように DataSource タイプオブジェクトとしてキャストします。

    ds = (DataSource)ctx.lookup(JndiDataSourceName);

  3. データソースへの参照を使用して接続を取得します。

    この操作には、次のようなコード行が必要です。

    conn = ds.getConnection();

    Application Server 6.x と Application Server は、どちらもこれらの方法に従ってデータソースから接続を取得します。

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 負荷分散の設定」を参照してください。

Application Server 6.x からの HTTP フェイルオーバーをサポートするアプリケーションの移行

Application Server, Enterprise Edition 8.2 は、ロードバランスと HTTP セッション持続をサポートします。ロードバランスの主な目標は、作業負荷を複数のサーバーインスタンスに分散することによって、システムの全体的なスループットを向上させることです。

HTTP セッションフェイルオーバーの設定については、『Sun Java System Application Server Enterprise Edition 8.2 高可用性 (HA) 管理ガイド』の「HTTP セッションフェイルオーバー」を参照してください。

6.x の HTTP アプリケーションを Application Server 8.2 EE 環境に移行してロードバランス機能を有効にするには、次の手順を実行します。アプリケーション内のコードを変更する必要はありません。

Procedure移行してロードバランスを有効にする

  1. 少なくとも 2 つのアプリケーションサーバーインスタンスが作成および設定されていることを確認します。

  2. ias-web-app.xml の名前を sun-web.xml に変更します。

    配備記述子の移行の詳細については、「Application Server 6.x からの配備記述子の移行」を参照してください。

  3. <DOCTYPE 定義を次のコードで更新します。

    <!DOCTYPE web-app PUBLIC 
’-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN’ 
’http://java.sun.com/j2ee/dtds/web-app_2_3-1.dtd’>

  4. Sun ONE Application Server 6.5 では、HTTP アプリケーションのフェイルオーバーは Dsync 機構に基づいて行われていました。HTTP フェイルオーバーの設定は ias-web-app.xml ファイルで行われていました。

    <servlet-info> 要素の下に定義された <server-info> 要素は、サーブレットの保存先となるサーバーが有効になっているかどうかを指定します。

    <session-info> 要素は、次の情報を定義します。

    • dsync-type: この要素は、値として dsync-distributed または dsync-local を取ります。

      dsync-distributed は、セッションが分散され、すべての設定済みサーバーで使用可能であることを示します。

      dsync-local は、セッションがその作成元のサーバー上でのみ使用可能であることを示します。

      • impl: この要素は、値として distributed または lite を取ります。

        distributed は、セッションが分散されていることを示します。

        lite は、セッションがその作成元である Java エンジンに対してローカルであることを示します。この値が設定されている場合、dsync-type の設定値は無視されます。

        Sun Java System Application Server 8.2 で HTTP ルート上のアプリケーションのフェイルオーバーを有効にするには、Sun 固有の Web アプリケーション配備記述子ファイルである sun-web.xml に次のプロパティーを定義します。

      • persistence-store - このプロパティーは、値として memory、file、または ha を取ります。ただし、6.5 ではメモリーベースの持続性ストアのみがサポートされていました。

      • persistence-scope - 持続性のスコープを定義します。

        • session - すべてのセッションで、セッション情報が保存されます。

        • modified-session - 変更されたセッションデータのみが格納されます。

        • modified-attribute - 変更された属性データのみが格納されます。6.5 では、modified-attribute スコープのみがサポートされていました。

        persistenceFrequency - 頻度を Web メソッド単位または時間ベースに設定できます。6.5 では、web-method のみがサポートされていました。

        • web-method - セッション状態は、各 Web 要求の終了時に、クライアントに応答を返信する前に格納されます。このモードでは、障害発生時にセッション状態を完全に更新するための最良の保証が得られます。

        • time-based - セッション状態は、指定された頻度でバックグラウンドで格納されます。このモードでは、セッション状態が必ずしも完全に更新される保証は得られません。ただし、各要求後に状態が格納されないので、パフォーマンスが大幅に向上します。

          sun-web.xml ファイルの例を次に示します。

          <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE 
sun-web-app PUBLIC '-//Sun Microsystems, Inc.//
            DTD Sun ONE Application Server 7.1 Servlet 2.3//EN' 
"http://www.sun.com/software/sunone/appserver/dtds/sun-web-app_2_3-1.dtd'>
  <sun-web-app>
    <session-config>
      <seession-manager>
        <manager-properties>
          <property name="persistence-type" value "ha'>
          <property name="persistenceFrequency" value ="web-based">
        </manager-properties>
        <store-properties>
          <property name="persistenceScope" value="session">
        </store-properties>
      </session-manager>
    </session-config>
</sun-web-app>

          sun-web.xml 設定ファイルの詳細については、『Sun Java System Application Server Enterprise Edition 8.2 Developer’s Guide』の「The sun-web.xml File」を参照してください。

  5. Sun Java System Application Server 8.2 で HTTP 要求の負荷を分散し、障害発生時に要求をクラスタ内の使用可能なサーバーインスタンスに継続するには、ロードバランサプラグインをインストールして設定する必要があります。

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

  6. load-balancer.xml ファイルで、web-module enabled 要素が true に設定されていることを確認します。

    <loadbalancer>
  <cluster name=cluster1>
  ...
    <web-module context-root="abc" enabled=true>
  </cluster>
  <property name="https-routing" value="true"/>
</loadbalancer>

    enabled=true は、要求の負荷分散先となる Web モジュールがアクティブである (有効になっている) ことを示します。

  7. https-routing プロパティーを定義し、その値を true に設定します。

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

    ロードバランスに参加しているすべてのサーバーインスタンスにアプリケーションを配備します。

Application Server 7 から Application Server 8.2 へのアプリケーションの移行

7 PE/SE から 8.2 EE へのリッチクライアントの移行

Application Server 7 PE/SE に配備されたリッチクライアントを Application Server 8.2 に移行するのは比較的簡単です。Application Server 7 で使用していた配備記述子は、Application Server 8.2 でもそのまま使用できます。ただし、クライアントアプリケーションでロードバランス機能とフェイルオーバー機能を有効にする場合は、配備記述子でロードバランス機能とフェイルオーバー機能を設定する必要があります。

Procedureリッチクライアントを移行する

  1. 以前にインストールされたコンポーネントを特定します。

  2. asadmin コマンドまたはディレクトリの一覧表示を使用して、サーバーインスタンスを見つけます。

    asadmin コマンドを使用する場合は、管理インスタンスが実行されている必要があります。一方、ディレクトリの一覧表示を使用してインスタンスを特定する場合は、管理インスタンスが実行されている必要はありません。

  3. RMI/IIOP フェイルオーバー機能を有効にするため、server.xml ファイルの jvm-config 要素の下に次の jvm-option を追加します。

    <jvm-config java-home=path...server-classpath=path>
  <jvm-option>
    Dorg.omg.PortableInterceptor.ORBInitializerClass.
com.sun.appserv.ee.iiop.EEORBInitializer
  </jvm-option>
  <jvm-option>
    Dorg.omg.PortableInterceptor.ORBInitializerClass.
com.sun.appserv.ee.iiop.EEIORInterceptorInitializer 
  </jvm-option>
  <jvm-option>
    Dcom.sun.CORBA.connection.ORBSocketFactoryClass=
com.sun.appserv.enterprise.iiop.EEIIOPSocketFactory 
  </jvm-option>
</jvm-config>

  4. availability-service 要素を更新して availability-enabled フラグを true に設定します。


    <availability-service availability-enabled="true">
  <persistence-store>
    <property-name="store-pool-jndi-name" value="" />
    <property-name="cluster-id" value="cluster1" />
  </persistence-store>
</availability-service>

  5. java-config 要素の下のサーバークラスパスエントリを変更して次のパスを追加します。

    install_dir/SUNWhads/ 4.2.2-17/lib/hadbjdbc.jar;

    install_dir/lib/appserv-rt-ee.jar

  6. java-config 要素の下に次の jvm-option を追加します。


    <jvm-option>

    Dcom.sun.aas.hadbRoot=install-dir/ SUNWhadb/4.2.2-17 


    </jvm-option>

  7. 次の新しいロードバランスプロパティーを使用して sun-acc.xml を更新します。

    <property-name="com.sun.appserv.iiop.loadbalancingpolicy" 
                    value="ic-based" />
<property name="com.sun.appserv.iiop.endpoints" value=<host>:<port>" />

7 EE から 8.2 EE へのリッチクライアントの移行

7 EE のアプリケーションを 8.2 EE に移行するには、次の手順に従います。

Procedure7 EE から 8.2 EE にリッチクライアントを移行する

  1. RMI/IIOP フェイルオーバー機能を有効にするため、java-config 要素の下に次の jvm-option 要素を追加します。次の jvm-option 要素のクラス名は、ページ幅に合わせて 2 行に分けて表示しています。プロジェクトに追加するときは、このように 2 行に分けないでください。

    <jvm-config java-home=path...server-classpath=path>
  <jvm-option>
    Dorg.omg.PortableInterceptor.ORBInitializerClass.
          com.sun.appserv.ee.iiop.EEORBInitializer
  </jvm-option>
  <jvm-option>
    Dorg.omg.PortableInterceptor.ORBInitializerClass.
          com.sun.appserv.ee.iiop.EEIORInterceptorInitializer 
  </jvm-option>
  <jvm-option>
    Dcom.sun.CORBA.connection.ORBSocketFactoryClass=
          com.sun.appserv.enterprise.iiop.EEIIOPSocketFactory 
  </jvm-option>
</jvm-config>

  2. iiop-cluster を設定するため、server.xml に次のエントリを追加します。


    <iiop-cluster>
     <iiop-server-instance name=<server-name>>
         <iiop-endpoint id=orb-listener-id, 
                        host=hostname, 
                        port=orb-listener-port/>
    </iiop-server-instance>
</iiop-cluster>

  3. 次の新しいエントリを使用して sun-acc.xml を更新します。

    <property-name=¨com.sun.appserv.iiop.loadbalancingpolicy" 
                    value="ic-based" />
<property name="com.sun.appserv.iiop.endpoints" 
          value="hostname:port" />

SFSB フェイルオーバーをサポートする EJB アプリケーションの移行

Application Server 7 は、ステートフルセッション Bean (SFSB) のフェイルオーバーをサポートしません。Application Server Enterprise Edition 8.2 は、HTTP および RMI/IIOP パス上のステートフルセッション Bean のフェイルオーバーをサポートします。この節では、SFSB 状態のフェイルオーバーをサポートする EJB アプリケーションを Application Server 7 SE/PE/EE から Application Server 8.2 EE に移行する手順について説明します。

7 SE/PE/EE から 8.2 EE への EJB アプリケーションの移行

ステートフルセッション Bean を使用してデータを持続する EJB アプリケーションの高可用性を実現するには、アプリケーションサーバーのクラスタごとに持続的ストアを設定し、個々のアプリケーションサーバーインスタンスの潜在的障害に対してクライアントセッションの情報を管理できるようにする必要があります。また、クラスタ内の各サーバーインスタンスの availability-enabled フラグを有効にする必要があります。

Application Server 8.2 EE は、ステートフルセッション Bean のフェイルオーバーをサポートします。Application Server 8.2 EE に配備された EJB アプリケーションでこの機能を有効にするには、次の手順に従います。

以前にリリースされた Sun の Application Server からエンティティー Bean を移行するには、「エンティティー Bean」で説明した手順に従います。

SFSB フェイルオーバーは、同じアプリケーションサーバープロセスで実行されているアプリケーション内の EJB、サーブレット、または Java Server Pages から SFSB にアクセスする場合にサポートされます。SFSB には、ローカルインタフェースまたはリモートインタフェース経由でアクセスできます。

SFSB 状態のフェイルオーバーを利用するために、コードを編集する必要はありません。ただし、SFSB のチェックポイント化に必要なすべての設定パラメータを Sun 固有の配備記述子 (sun-ejb-jar.xml) またはサーバー設定ファイルに指定する必要があります。

SFSB フェイルオーバーの詳細については、『Sun Java System Application Server Enterprise Edition 8.2 高可用性 (HA) 管理ガイド』の「ステートフルセッション Bean のフェイルオーバー」を参照してください。