第 3 章
Sun ONE Application Server 6.x から Sun ONE Application Server 7 への移行

この章では、Sun ONE Application Server 6.0 または 6.5 から Sun ONE Application Server 7 製品ラインに、J2EE アプリケーションを移行する場合の注意事項と方針について説明します。

この節では、コンポーネントレベルでの特定の移行作業についても説明します。

次の項目について説明します。

Sun ONE Application Server 6.0/6.5 について
Sun ONE Application Server 6.x から 7 への移行に関する問題
J2EE コンポーネントの移行
Web アプリケーションの移行
エンタープライズ EJB モジュールの移行
エンタープライズアプリケーションの移行
固有の拡張子の移行
UIF の移行

---

Sun ONE Application Server 6.0/6.5 について

Sun ONE Application Server 6.0 は、J2EE 1.2 仕様を全面的にベースにしたマルチプラットフォームのアプリケーションサーバーです。Windows NT/2000、Solaris、AIX、HP-UX などのプラットフォームがサポートされています。

また、Sun ONE Application Server 6.0 は、付属の専用 Web コネクタプラグインによって、多数の Web サーバーを統合化します。これらのコネクタによって、Sun ONE Web Server、Microsoft IIS、Apache などの Web サーバーと連携して動作することが可能になります。

次の図は、Sun ONE Application Server 6.0/6.5 のアーキテクチャを示しています。

図 3-1 Sun ONE Application Server 6.0/6.5 のアーキテクチャ

上の図に示されるように、一般的にエンジンまたはプロセスと呼ばれる 4 つの内部サーバーが存在します。これらのプロセスが、Sun ONE Application Server でのすべての処理を実行します。Sun ONE Application Server 6.0/6.5 の 4 つの内部サーバーには、次のようなものがあります。

実行サーバー: ほとんどのシステムサービスを提供する (一部のサービスは、「管理サーバー」によって管理される)

管理サーバー: Sun ONE Application Server の管理および障害復旧用のシステムサービスを提供する

Java サーバー: Java アプリケーションのサービスを提供する

C++ サーバー: C++ で作成されたコンポーネントは、「C++ サーバー」で動作する

Web サーバーが Sun ONE Application Server 6.0/6.5 に要求を転送すると、要求はまず「実行サーバー」プロセス (KXS) によって受信されます。KXS プロセスは、その要求を「Java サーバー」プロセス (KJS) または「C++ サーバー」プロセス (KCS) のどちらかに転送します。KJS プロセスが Java プログラミングロジックを実行するのに対し、KCS プロセスは C++ プログラミングロジックを実行します。KJS プロセスと KCS プロセスはそれぞれ、特定数のスレッドを管理し、それらのスレッドでプログラミングロジックを最後まで実行します。結果は Web サーバーに返されてから、クライアントブラウザに送信されます。

---

配備記述子の移行

次の表は、配備記述子の対応関係をまとめたものです。

ソース配備記述子	ターゲット配備記述子
ejb-jar.xml - 1.1	ejb-jar.xml -2.0
ias-ejb-jar.xml	sun-ejb-jar.xml
<bean-name>-ias-cmp.xml	sun-cmp-mappings.xml
web.xml	web.xml
ias-web.xml	sun-web.xml
application.xml	application.xml

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

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> コンストラクトを構築するために必要な条件です。移行時にこのソースファイルが見つからない場合、<query-filter> コンストラクトが作成されますが、多くの情報が失われます (移行後の sun-ejb-jar.xml 内の "REPLACE ME" で示される部分)。

さらに、ias-ejb-jar.xml に <message-driven> 要素が含まれる場合、この要素の内部の情報が ejb-jar.xml と sun-ejb-jar.xml の内部に取り込まれます。また、ias-ejb-jar.xml の <message-driven> 要素の内部には <destination-name> という要素があり、MDB が待機するトピックまたはキューの JNDI 名はここに格納されます。Sun ONE Application Server 6.5 の場合、この JNDI 名の命名規則は "cn=<SOME_NAME>" のようになります。この名前の JMS トピックまたはキューは Sun ONE Application Server 7 EE に配備できません。そこで、これを "<SOME_NAME>" という名前に変更し、この情報を sun-ejb-jar.xml に追加します。すべての有効な入力ファイル (.java ファイル、.jsp ファイル、および .xml ファイル) で、この変更を適用する必要があります。JNDI 名の変更は、アプリケーション全体にグローバルに影響を及ぼします。この JNDI 名を参照するソースファイルがあり、使用できない状態になっている場合は、該当ソースファイルに手動で変更を加え、アプリケーションを配備できるようにする必要があります。

---

Sun ONE Application Server 6.x から 7 への移行に関する問題

この節では、Sun ONE Application 6.0 または 6.5 から Sun ONE Application Server 7 に、標準的な J2EE アプリケーションの主要コンポーネントを移行する場合に生じる可能性のある問題について説明します。

この節で説明する移行時の問題点は、オンラインバンキングサービスをシミュレートする iBank という名前の J2EE アプリケーションを Sun ONE Application Server 6.0 または 6.5 から Sun ONE Application Server 7 に、実際に移行したときのプロセスに基づいています。このアプリケーションは、通常の J2EE アプリケーションを構成するすべての要素を反映しています。

iBank アプリケーションに適用される J2EE 仕様の重要なポイントとして、次のようなものが挙げられます。

サーブレット、特に JSP ページへの切り替えを行うサーブレット (model-view-controller アーキテクチャ)
JSP ページ、特に静的および動的なページの取り込みを含む JSP ページ
JSP カスタムタグライブラリ
HTTP セッションの作成および管理
JDBC API 経由のデータベースアクセス
Enterprise JavaBeans: ステートフル、またはステートレスなセッション Beans、CMP、および BMP エンティティ Beans
J2EE アプリケーションの標準パッケージ化メソッドに対応したアセンブリおよび配備

iBank アプリケーションの詳細については、付録 A 「iBank アプリケーションの仕様」を参照してください。

---

J2EE コンポーネントの移行

この節では次の移行プロセスについて説明します。

JDBC コードの移行
Java Server Pages および JSP カスタムタグライブラリの移行
サーブレットの移行
JNDI コンテキストからのデータソースの取得
EJB の移行
Sun ONE Application Server 7 に対応した EJB の変更

JDBC コードの移行

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

DriverManager インタフェース経由の接続の確立

(JDBC 1.0 API)。特定のドライバを読み込み、接続 URL を提供します。この方法は、IBM の WebSphere 4.0 のような他のアプリケーションサーバーで使用されます。

JDBC 2.0 データソースの使用方法

データソースインタフェース (JDBC 2.0 API) は、設定可能な接続プールを介して使用できます。J2EE 1.2 に従って、データソースは JNDI ネーミングサービス経由でアクセスされます。

注	Sun ONE Application Server 7 は、Sun ONE 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);

このコードは、Sun ONE Application Server 6.0/6.5 から Sun ONE Application Server 7 に完全に移植できます。ただし、Sun ONE Application Server が適切な JDBC ドライバを読み込むのに必要なクラスを検出できることが前提になります。Sun ONE Application Server 7 に配備されたアプリケーションにアクセスできる、必要なクラスを作成するには、次のいずれかの方法を実行します。

Sun ONE Application Server 7 のインストールディレクトリ内の /lib ディレクトリに、ドライバ実装用のアーカイブ (JAR または ZIP) を置きます。

管理サーバーの GUI を介して、ドライバのパスを設定し、CLASSPATH を修正します。サーバーインスタンス「server1」をクリックした後、右側のペインの「JVM Settings (JVM 設定)」タブをクリックします。次に、「Path Settings (パス設定)」オプションをクリックし、テキスト入力ボックスの「Classpath Suffix (クラスパスのサフィックス)」にパスを追加します。設定変更を行ったら、「Save (保存)」をクリックして、新しい設定を適用します。サーバーを再起動すると、設定ファイル server.xml が変更されます。

JDBC 2.0 データソースの使用方法

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

アプリケーション内のデータソースを使用するには、初期設定のフェーズを実行する必要があります。その後で、アプリケーションサーバーの JNDI ネーミングコンテキスト内でデータソースを登録します。データソースを登録すると、アプリケーションでは、JNDI コンテキストから対応する DataSource オブジェクトを取り出すことによって、データベースへの接続を簡単に取得できます。これらの作業については、次の項目で説明します。

データソースの設定
JNDI 経由でのデータソースの検索および接続の取得

データソースの設定

Sun ONE Application Server 6.0 では、データソースとそれに対応する JDBC ドライバを、サーバーのグラフィック管理コンソールから設定します。接続プールは、アプリケーションサーバーによって自動的に管理され、その管理ツールはプロパティの設定に使用できます。組み込まれている Type 2 の JDBC ドライバを使用すると、接続プールのプロパティは、ドライバごとに定義され、そのドライバを使用するすべてのデータソースで共有されます。

一方、サードパーティの JDBC ドライバを使用した場合、接続プールのプロパティは、データソースごとに定義されます。サードパーティの JDBC ドライバは、管理ツールから、または別のユーティリティ (Sun Solaris では db_setup.sh、Windows NT/2000 では jdbcsetup) から設定できます。さらに、コマンド行ユーティリティ iasdeploy を使用すると、プロパティを記述している XML ファイルからデータソースを設定できます。これらのユーティリティはすべて、Sun ONE Application Server のインストールルートディレクトリ内のサブディレクトリ /bin/ に格納されています。

Sun ONE Application Server 7 では、サーバーのグラフィック管理コンソールまたはコマンド行ユーティリティ asadmin を使用して、データソースを設定できます。コマンド行ユーティリティ asadmin を起動するには、Solaris の asadmin ファイルを実行します。このファイルは、Sun ONE Application Server 7 のインストールディレクトリ内の bin ディレクトリに格納されています。asadmin プロンプトから次のコマンドを入力すると、接続プールと JNDI リソースが作成されます。

asadmin ユーティリティを起動して、接続プールを作成するための構文は、次のとおりです。

asadmin>create-jdbc-connection-pool -u username -w password -H hostname -p adminport [-s] [--instance instancename] --datasourceclassname classname [--steadypoolsize=8] [--maxpoolsize=32] [--maxwait=60000] [--poolresize=2] [--idletimeout=300] [--isconnectvalidatereq=false] [--validationmethod=auto-commit] [--validationtable tablename] [--failconnection=false] [--description text] [--property (name=value)[:name=value]*] connectionpoolid

次に例を示します。

asadmin>create-jdbc-connection-pool -u admin -w password -H cl1 -p 4848 instance server1 --datasourceclassname oracle.jdbc.pool.OracleConnectionPoolDataSource --property (user-name=ibank_user):(password=ibank_user) oraclepool

この場合、Oracle データベース用の JDBC 接続プール「oraclepool」は、「ibank_user」というユーザー名と「ibank_user」というパスワードを持つデータベーススキーマを使用して作成されます。

JDBC リソースを作成する構文は、次のとおりです。

asadmin>create-jdbc-resource -u username -w password -H hostname -p adminport [-s] [--instance instancename] --connectionpoolid id [--enabled=true] [--description text] [--property (name=value)[:name=value]*] jndiname

次に例を示します。

asadmin>create-jdbc-resource -u admin -w password -H cl1 -p 4848 --instance server1 --connectionpoolid oraclepool jdbc/IBANK

この場合、上記の「jdbc/IBANK」という JNDI 名で作成された接続プールに対して、JDBC リソースが作成されます。

グラフィカルインタフェースを使用して、Sun ONE Application Server 7 にデータソースを登録する場合の実行手順は以下のとおりです。

データソースのクラス名を登録します。
Sun ONE Application Server 7 のインストールディレクトリ内の /lib ディレクトリに、データソースのクラス実装用のアーカイブ (JAR または ZIP) を置きます。
管理サーバーの GUI を介して、ドライバのパスを設定し、CLASSPATH を修正します。サーバーインスタンス「server1」をクリックした後、「JVM Settings (JVM 設定)」タブをクリックします。次に、「Path Settings (パス設定)」をクリックして、「Classpath Suffix (クラスパスのサフィックス)」にパスを追加します。設定変更を行ったら、変更内容を保存して、新しい設定を適用します。サーバーを再起動すると、設定ファイル server.xml が変更されます。
データソースを登録します。

Sun ONE Application Server 7 では、データソースとそれに対応する JDBC ドライバを、サーバーのグラフィック管理インタフェースから設定します。

左側のペインには、Sun ONE Application Server で設定できるすべての項目がツリー表示されます。左側のペインにある「Connection Pool (接続プール)」をクリックすると、関連するエントリを指定できるページが右側のペインに表示されます。

図 3-2 GUI を使用した接続プールの設定

同様に、「Data Source (データソース)」をクリックすると、データソースのセットアップに必要なエントリが右側のペインに表示されます。

Sun ONE Application Server 7 固有の配備記述子 sun-web.xml は、それに応じて変更する必要があります。

たとえば、iBank アプリケーションに新しいデータソースを設定する場合、sun-web.xml は次のようなエントリを保持します。

<!DOCTYPE web-app PUBLIC '-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN' 'Http://localhost:8000/sun-web-app_2_3.dtd'>

<sun-web-app>

   <resource-ref>

      <res-ref-name>jdbc/iBank</res-ref-name>

      <jndi-name>jdbc/iBank</jndi-name>

      <default-resource-principal>

          <name>ibank_user</name>

          <password>ibank_user</password>

      </default-resource-principal>

   </resource-ref>

</sun-web-app>

JNDI 経由でのデータソースの検索および接続の取得

データソースから接続を取得するためのプロセスは、以下のようになります。

初期 JNDI コンテキストを取得する
JNDI 検索を使用して、データソースへの参照を取得する
この参照を使用して、接続を取得する
初期 JNDI コンテキストを取得する

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

InitialContext ctx = new InitialContext();

データソースへの参照を取得する

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

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

接続を取得する

この操作は非常に単純なもので、次のようなコード行を指定する必要があります。

conn = ds.getConnection();

Sun ONE Application Server 6.0/6.5 および 7 はどちらも上記の技術に従って、データソースから接続を取得します。つまり、移行を行うときにコードを変更する必要はありません。

Java Server Pages および JSP カスタムタグライブラリの移行

Sun ONE Application Server 6.0/6.5 が JSP 1.1 仕様に準拠しているのに対し、Sun ONE Application Server 7 は JSP 1.2 仕様に準拠しています。

JSP 1.2 仕様には、多数の新機能に加えて、JSP 1.1 仕様ではあまり適切ではなかった部分の修正および説明が含まれています。

最も重要な変更点を以下に示します。

JSP 1.2 は、サーブレット 2.3 および Java 2 に基づいている。JSP 1.2 アプリケーションは、JDK 1.1 だけをサポートするプラットフォームでは動作しない。JSP 1.2 は、JSP 1.1 との下位互換性があるため、JSP 1.1 アプリケーションは JSP 1.2 に準拠するコンテナを調整しなくても動作する
JSP ページ用の XML 構文の定義が確定している。このため、JSP 1.2 に準拠するコンテナは、JSP 1.1 形式と JSP Document と呼ばれる新しい XML 形式の両方のファイルを受け入れる必要がある
タグライブラリでは、サーブレット 2.3 のイベントリスナーを利用できる
タグライブラリに、JSP ページを検証する新しいタイプの検証が追加されている
タグライブラリの配布および配備用の新しいオプションが追加されている

基本的に、これらの変更は機能の拡張なので、JSP ページを JSP API 1.1 から 1.2 に移行する場合には必要ありません。

Sun ONE Application Server 6.0 または 6.5 の JSP カスタムタグライブラリの実装は、J2EE 仕様に準拠します。このため、JSP カスタムタグライブラリを Sun ONE Application Server 7 に移行する場合に、特別な問題が生じたり、修正が必要になることはありません。

サーブレットの移行

Sun ONE Application Server 6.0 および 6.5 で、サーブレット 2.2 API がサポートされているのに対し、Sun ONE Application Server 7 では、サーブレット 2.3 API がサポートされます。

サーブレット API 2.3 では、サーブレットのコアは比較的変更を受けずに残されており、ほとんどの変更は、コアの外側に追加された新しい機能に関係しています。

最も重要な機能を以下に示します。

サーブレットには JDK 1.2 以降が必要
フィルタメカニズムを新たに作成
アプリケーションライフサイクルイベントを追加
新しい国際化サポートを追加
新しいエラーおよびセキュリティ属性を追加
HttpUtils クラスを廃止
複数の DTD 動作を拡張、明確化

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

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

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

JNDI コンテキストからのデータソースの取得
JNDI コンテキスト内での EJB の宣言

最後のケースとして、JSP ページが既存の Java クラスと同じ名前を持つ場合に、Sun ONE Application Server で命名の競合が発生するため、サーブレットのコード修正が必要になることがあります。この場合、競合は問題の生じている JSP ページの名前を修正することで解決します。また、さらに、この JSP ページを呼び出すサーブレットのコードを編集する必要があります。Sun ONE Application Server 6.0/6.5 と比べて、Sun ONE Application Server 7 では新しいクラスローダ階層が採用されているため、この問題は解決しています。この新しい方式では、特定のアプリケーションについて、1 つのクラスローダがすべての EJB モジュールを読み込み、別のクラスローダが Web モジュールを読み込みます。これらの 2 つのローダ同士は通信しないため、命名の競合が発生することはありません。

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

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

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

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

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

「Enterprise Java Beans 1.1 仕様から Enterprise Java Beans 2.0 仕様への移行」の「JNDI コンテキスト内での EJB の宣言」の節を参照してください。

EJB の移行

「Sun ONE Application Server 7, Enterprise Edition の概要」で説明したように、Sun ONE Application Server 6.0 および 6.5 で EJB 1.1 仕様がサポートされているのに対し、Sun ONE Application Server 7 では EJB 2.0 仕様もサポートされます。EJB 2.0 仕様は、次のような新機能をアーキテクチャに導入しています。

メッセージ駆動型 Beans (MDB)
コンテナ管理による持続性 (CMP) の向上
CMP によるエンティティ Beans のコンテナ管理関係
ローカルインタフェース
EJB クエリ言語 (EJB QL)

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

EJB 1.1 から EJB 2.0 への移行については、付録 C 「Enterprise Java Beans 1.1 仕様から Enterprise Java Beans 2.0 仕様への移行」を参照してください。

Sun ONE Application Server 7 に対応した EJB の変更

Sun ONE Application Server 6.0/6.5 から Sun ONE Application Server 7 に EJB を移行する場合、EJB のコード自体を変更する必要はありません。ただし、次のような DTD の変更が必要となります。

セッション Beans

ejb-jar.xml など、J2EE 標準 DD を持つ最新の DTD を示すように、<!DOCTYPE> 定義を変更します。
ias-ejb-jar.xml ファイルを、DD に従って手動で作成した sun-ejb-jar.xml という名前の修正バージョンのファイルに置き換えます。詳細については、http://www.sun.com/software/sunone/appserver/dtds/sun-ejb-jar_2_0-0.dtd を参照してください。
sun-ejb-jar.xml の場合、すべての EJB の JNDI 名は ejb/ で開始する必要があります。これは Sun ONE Application Server 6.5 の場合に必要です。EJB の JNDI 名には、ejb/<ejb-name> しか指定できません。<ejb-name> には、ejb-jar.xml 内で宣言した EJB の名前が入ります。

Sun ONE Application Server 7 では、EJB の JNDI 名を宣言できる新しいタグが sun-ejb-jar.xml 内に導入されました。

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

エンティティ Beans

ejb-jar.xml など、J2EE 標準 DD を持つ最新の DTD を示すように、<!DOCTYPE> 定義を変更します。
ejb-jar.xml のすべての CMP に対して、1.1 の値を指定した <cmp-version> タグを挿入します。
すべての <ejb-name>-ias-cmp.xml ファイルを、手動で作成した sun-cmp-mappings.xml ファイルに置き換えます。詳細については、http://www.sun.com/software/sunone/appserver/dtds/sun-cmp_mapping_1_0.dtd を参照してください。
Sun ONE Application Server 7 のインストールディレクトリ内の bin ディレクトリに格納されている capture-schema ユーティリティを使用して dbschema を生成し、エンティティ Beans 用の META-INF フォルダより上位に置きます。
ias-ejb-jar.xml を、Sun ONE Application Server 7 で sun-ejb.jar.xml という名前に変更された新しいバージョンのファイルに置き換えます。
Sun ONE Application Server 6.5 では、ファインダ sql が <ejb-name>-ias-cmp.xml に直接組み込まれていました。Sun ONE Application Server 7 では、数学式を使用して、さまざまな検索メソッド用の <query-filter> を宣言するように変更されています。

メッセージ駆動型 Beans

Sun ONE Application Server 7, Enterprise Edition は、メッセージ駆動をシームレスにサポートします。このサポートは、Sun ONE Application Server 7, Enterprise Edition と Sun ONE Message Queue の緊密な統合によって実現されています。これにより、ネイティブの組み込み型 JMS サービスが提供されます。

MQ をインストールすると、Sun ONE Application Server に、任意の数の Sun ONE Application Server インスタンスをサポートする JMS メッセージングシステムが提供されます。各サーバーインスタンスには、デフォルトで、そのインスタンスで実行中のすべての 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 ディレクトリも必要でした。

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

配備記述子の変更の詳細については、「配備記述子の移行」を参照してください。Sun ONE Application Server 7 のメッセージ駆動型 Beans の実装については、『Sun ONE Application Server 7, Enterprise Edition, Developer's Guide to Enterprise Java Bean Technology』を参照してください。

---

Web アプリケーションの移行

Sun ONE Application Server 6.0 と 6.5 は、Servlet API 2.2 と JSP 1.1 をサポートします。一方、Sun ONE Application Server 7 は、Servlet API 2.3 と JSP 1.2 をサポートします。

これらの環境内では、異なるアプリケーションコンポーネント (サーブレット、JSP、HTML ページ、およびその他のリソース) を 1 つのアーカイブファイル (J2EE 標準 Web アプリケーションモジュール) にまとめてから、そのアーカイブファイルをアプリケーションサーバー上に配備する必要があります。

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

HTML ページ、JSP、画像、およびその他の「静的な」アプリケーションのリソースを含むルートディレクトリ
使用している SDK のバージョン情報、およびアーカイブに含まれるファイルのリスト (オプション) などが入ったアーカイブマニフェストファイル (MANIFEST.MF) を含む META-INF/ ディレクトリ
アプリケーション配備記述子 (web.xml ファイル)、およびアプリケーションで使用されるすべての Java クラスとライブラリを含む WEB-INF/ ディレクトリ。次のように構成される
サブディレクトリ classes/ には、アプリケーションのコンパイル済みのクラス (サーブレット、補助クラスなど) がツリー構造で格納され、パッケージに編成される
lib/ ディレクトリには、アプリケーションによって使用される任意の Java ライブラリ (.jar ファイル) が含まれる

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

Sun ONE Application Server 6.0/6.5 から Sun ONE Application Server 7 にアプリケーションを移行する場合、Java/JSP のコードを変更する必要はありません。ただし、次のような変更が必要となります。

web.xml

Sun ONE Application Server 7 は J2EE 1.3 標準に準拠しているため、WAR 内の web.xml ファイルは、改訂された DTD に従う必要があります。この改訂版 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">

ias-web.xml

Sun ONE Application Server 7 では、このファイルの名前は sun-web.xml に変更されています。

この XML ファイルは、Web アプリケーションで必要な Sun ONE Application Server 7 固有のプロパティまたはリソースを宣言するときに使用します。

注 : このファイルの内容については、次の節を参照してください。

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

前述した方法で web.xml と ias-web.xml を移行すると、管理サーバーの Sun ONE Application Server 7 の GUI インタフェース、またはコマンド行ユーティリティ asadmin を使用して、Web アプリケーション (.WAR アーカイブ) を配備することができます。配備コマンドでは、アプリケーションのタイプを web として指定する必要があります。

コマンド行ユーティリティ asadmin を起動するには、Sun ONE Application Server 7 のインストールディレクトリ内の bin ディレクトリに格納されている asadmin.bat ファイルを実行します。

asadmin プロンプトから入力するコマンドは、次のようになります。

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

「Sun ONE Application Server 7 でのアプリケーションの配備」に記載されるように、配備は Sun ONE Studio 開発環境からでも行うことができます。

サーブレットおよび JSP の移行時の特定の障害

Sun ONE Application Server 6.0/6.5 から Sun ONE Application Server 7 に、サーブレット/JSP アプリケーションのコンポーネントを実際に移行する場合、コンポーネントのコードを修正する必要はありません。

Web アプリケーションがデータソースなどのサーバーリソースを使用している場合、Sun ONE Application Server 7 では、このリソースを 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>

---

エンタープライズ EJB モジュールの移行

Sun ONE Application Server 6.0 および 6.5 で、EJB 1.1 API がサポートされているのに対し、Sun ONE Application Server 7 では、EJB 2.0 API がサポートされます。その結果、どちらも以下のものをサポートできます。

ステートフル、またはステートレスなセッション Beans
Bean 管理による持続性 (BMP)、またはコンテナ管理による持続性 (CMP) を持つエンティティ Beans

ただし、EJB 2.0 API では、セッション Beans およびエンティティ Beans に加えて、メッセージ駆動型 Beans と呼ばれる新しいタイプの Enterprise Java Beans が導入されています。

J2EE 1.3 仕様によると、EJB のさまざまなコンポーネントは、次のような構造を持った JAR ファイルにまとめる必要があります。

ejb-jar.xml という名前の XML 配備記述子を持つ META-INF/ ディレクトリ
パッケージ内のホームインタフェースおよびリモートインタフェース、Bean の実装クラスおよび補助クラスに対応する .class ファイル

Sun ONE Application Server では、このアーカイブ構造を維持します。ただし、EJB 1.1 仕様では、各 EJB コンテナベンダーに、適切であると思われる次のような機能を実装する余地を残しています。

CMP EJB のデータベースの持続性 (特に、データベース表内の Bean の CMP フィールドとカラム間でのマッピング設定)
CMP Beans 用カスタムファインダメソッドのロジックの実装

予期されていたように、Sun ONE Application Server 6.0 または 6.5 と Sun ONE Application Server 7 では、異なる点がいくつか存在するため、アプリケーションを移行する場合に、特別な留意が必要な部分があります。以下のように、いくつかの XML ファイルを修正する必要があります。

ejb-jar.xml のような J2EE 標準 DD に備えて、最新の DTD URL を示すように、<!DOCTYPE 定義を変更します。
ias-ejb-jar.xml ファイルを、DTD に従って手動で作成した sun-ejb-jar.xml という名前の修正バージョンのファイルに置き換えます。詳細については、http://www.sun.com/software/sunone/appserver/dtds/sun-ejb-jar_2_0-0.dtd を参照してください。
すべての <ejb-name>-ias-cmp.xml ファイルを、手動で作成した 1 つの sun-cmp-mappings.xml ファイルに置き換えます。詳細については、http://www.sun.com/software/sunone/appserver/dtds/sun-cmp_mapping_1_0.dtd を参照してください。
CMP エンティティ Beans のみ: Sun ONE Application Server 7 のインストールディレクトリ内の bin ディレクトリに格納されている capture-schema ユーティリティを使用して dbschema を生成し、エンティティ Beans 用の META-INF フォルダより上位に置きます。

---

エンタープライズアプリケーションの移行

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

application.xml という名前の J2EE アプリケーションの XML 配備記述子を持つ META-INF/ ディレクトリ
エンタープライズアプリケーションの EJB モジュール用の .JAR アーカイブファイルと Web モジュール用の .WAR アーカイブファイル

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

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

このため、エンタープライズアプリケーションを配備する前に、以下の手順を実行する必要があります。

EJB を 1 つ以上の EJB モジュールにパッケージ化します。
Web アプリケーションのコンポーネントを Web モジュールにパッケージ化します。
EJB モジュールと Web モジュールをエンタープライズアプリケーションモジュールにアセンブルします。
エンタープライズアプリケーションのルートコンテキスト名を定義します。これによって、アプリケーションにアクセスするための URL を特定します。

注 : Sun ONE Application Server 7 では、Sun ONE Application Server 6.0/6.5 にはなかった新しいクラスローダ階層を使用しています。この新しい方式では、特定のアプリケーションについて、1 つのクラスローダがすべての EJB モジュールを読み込み、別のクラスローダが Web モジュールを読み込みます。これら 2 つには、親子階層の関係があり、JAR モジュールクラスローダが WAR モジュールクラスローダの親モジュールになります。このため、JAR クラスローダによって読み込まれたクラスはすべて、WAR モジュールでも使用可能またはアクセス可能ですが、反対にWAR クラスローダによって読み込まれたクラスを JAR モジュールからアクセスすることはできません。したがって、JAR ばかりでなく WAR が必要とするクラスが存在する場合、そのクラスは JAR モジュール内だけでパッケージ化します。この指針に従わない場合、クラス競合が発生する可能性があります。

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

アプリケーションのアクセス URL (アプリケーションの Web モジュールのルートコンテキスト) に関して、Sun ONE Application Server 6.0/6.5 と Sun ONE Application Server 7 では、特別な違いが 1 つあります。

hostname という名前のサーバー上に配備されたアプリケーションのルートコンテキスト名が AppName である場合、このアプリケーションのアクセス URL は、使用されるアプリケーションサーバーによって異なります。

Sun ONE Application Server 6.0 または 6.5 の場合、常に Web フロントエンドと連携して使用されるので、アプリケーションのアクセス URL は、次のような形式になる (Web サーバーは、標準の HTTP ポート番号 80 で設定されているものとする)

http://hostname/NASApp/AppName/

Sun ONE Application Server 7 の場合、URL は次のような形式になる

http://hostname:port/AppName/

Sun ONE Application Server 7 がデフォルトで使用する TCP ポートは、ポート番号 80 です。

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

---

固有の拡張子の移行

Sun ONE Application Server 6.0/6.5 環境独自の多数のクラスが、アプリケーションで使用されている可能性があります。Sun ONE Application Server 6.x で使用される独自の Sun ONE パッケージの一部を以下に示します。

com.iplanet.server.servlet.extension
com.kivasoft.dlm
com.iplanetiplanet.server.jdbc
com.kivasoft.util
com.netscape.server.servlet.extension
com.kivasoft
com.netscape.server

これらの API は、Sun ONE Application Server 7 ではサポートされていません。上記のパッケージに属するクラスを使用するアプリケーションの場合、アプリケーションが標準 J2EE API を使用するように作成し直す必要があります。また、カスタム JSP タグと UIF フレームワークを使用するアプリケーションについても、標準 J2EE API を使用するように作成し直す必要があります。

iBank アプリケーションを使用した移行手順の例は、第 5 章「iBank アプリケーションの移行手順」を参照してください。

---

UIF の移行

Sun ONE Application Server 7.0 EE は、アプリケーションの UIF (Unified Integration Framework) API の使用をサポートしません。その代わりに、アプリケーションを統合する JCA (J2EE Connector Adapter) の使用をサポートします。ただし、Sun ONE Application Server 6.5 で開発されたアプリケーションは UIF を使用します。こうしたアプリケーションを Sun ONE Application Server 7.0 EE に配備するには、UIF を JCA に移行する必要があります。この節では、UIF を使ってアプリケーションを Sun ONE Application Server 7.0 EE へ移行する際の必要条件と手順を示します。

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

方法 1: レジストリファイルのチェック

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

拡張名セット

Extension DataObjectExt-cDataObject
Extension RepositoryExt-cLDAPRepository
Extension MetadataService-cMetadataService
Extension RepoValidator-cRepoValidator
Extension BSPRuntime-cBSPRuntime
Extension BSPErrorLogExt-cErrorLogMgr
Extension BSPUserMap-cBSPUserMap

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

AS_HOME/AS/registry/reg.dat

方法 2: インストールディレクトリの UIF バイナリをチェック

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

Solaris、Windows でのファイルの場所は次のとおりです。AS_HOME/AS/APPS/bin

Solaris 環境の検索対象ファイル

libcBSPRlop.so
libcBSPRuntime.so
libcBSPUserMap.so
libcDataObject.so
libcErrorLogMgr.so
libcLDAPRepository.so
libcMetadataService.so
libcRepoValidator.so
libjx2cBSPRuntime.so
libjx2cDataObject.so
libjx2cLDAPRepository.so
libjx2cMetadataService.so

Windows 環境の検索対象ファイル

cBSPRlop.dll
cBSPRuntime.dll
cBSPUserMap.dll
cDataObject.dll
ErrorLogMgr.dll
cLDAPRepository.dll
cMetadataService.dll
cRepoValidator.dll
jx2cBSPRuntime.dll
jx2cDataObject.dll
jx2cLDAPRepository.dll
jx2cMetadataService.dll

UIF を Sun ONE Application Server 7 EE に移行する前に、アプリケーションが UIF API を使用していることを確認してください。

確認方法

java ソースに netscape.bsp というパッケージ名があるか確認する
java ソースに access_cBSPRuntime.getcBSPRuntime というメソッド名があるか確認する。UIF ランタイムを取得する際、このメソッドを呼び出す必要がある

移行プロセス

UIF の移行には、Sun ONE Connector Builder ツールを使用できます。Sun ONE Studio には、このツールも統合済みです。このため、UIF ベースのアプリケーションを JCA ベースのアプリケーションに移行する際は、Sun ONE Studio を使用することができます。Sun ONE Connector Builder ツールの主要機能は次のとおりです。

コネクタコードの生成
テストとデバッグ
配備
コネクタ配備記述子の作成
配備用コネクタのアセンブル
管理フック
監視フック
環境のカスタマイズ

注 : Sun ONE Application Server 6.5 の UIF ベースのアプリケーションを移行する際、コードに変更を加える必要はありません。

Sun ONE Connector Builder ツールの詳細は、次の URL に記載されています。

http://docs.sun.com/db/coll/s1.conbldr

リッチクライアントの移行

この節では、iPlanet Application Server 6.x で開発された RMI/IIOP クライアントや ACC クライアントを Sun ONE Application Server 7 EE へ移行する手順を示します。

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

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

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

7 SE/EE のクライアントの認証

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

JAAS による認証方法の詳細は、『Sun ONE Application Server 7 Developer's Guide to Clients』を参照してください。

6.x と 7 EE での ACC の使用

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

6.x アプリケーションでは、スタンドアロンクライアントは、JNDI ルックアップで EJB の絶対名を使用します。つまり、ACC 外では、JNDI ルックアップは次のように行われます。

initial.lookup("ejb/ejb-name");
initial.lookup("ejb/module-name/ejb-name");

6.5 SP3 で開発されたアプリケーションの場合、絶対参照を使ってルックアップを行う際、プレフィックス "java:comp/env/ejb/" を使用します。

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

Sun ONE Application Server 7 では、JNDI ルックアップは EJB の jndi-name 名で行います。EJB の絶対名は使用しないでください。また、バージョン 7 では、プレフィックス java:comp/env/ejb はサポートされていません。クラスパス内の次の jar ファイルを appserv-ext.jar で置き換えてください。

iasclient.jar、iasacc.jar、または javax.jar

バージョン 7 では、アプリケーションのロードバランス機能は、クライアントサイドのコンテキストファクトリとして 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 とともに使用する場合、ラウンドロビンアルゴリズムは提供されたすべての値をラウンドロビンします。ただし、コード内の環境オブジェクトにホスト名とポート番号を含めた場合、その値がシステムプロパティ設定の値をオーバーライドします。

6.5 でクライアントが接続するプロバイダ URL は、CORBA Executive Engine (CXS エンジン) の IIOP ホストとポートになります。Application Server 7 の場合、クライアントは、インスタンスの IIOP リスナーホストおよびポート番号を指定する必要があります。Application Server 7 では、別途 CXS エンジンは用意されていません。

Application Server 7 のデフォルトの IIOP ポートは 3700 です。実際の IIOP ポートの値は、server.xml 設定ファイルに記載されています。

前へ      目次      索引      次へ

---

Copyright 2003 Sun Microsystems, Inc. All rights reserved.