| Oracle Application Server WebLogicからの移行 10gリリース3（10.1.3.1.0） B31844-01 |
|
 戻る |
 次へ |
この章では、Enterprise JavaBeansコンポーネントをWebLogic ServerからOracle Application Serverに移行する場合に必要な情報について説明します。具体的には、セッションEJBとエンティティEJBの移行、およびEARファイル形式または展開ディレクトリ形式でのJ2EE Webアプリケーションの移行について説明します。
ここで説明する内容は次のとおりです。
WebLogic ServerからOracle Application ServerへのEnterprise JavaBeans（EJB）の移行は簡単であり、移行するEJBのコードを変更する必要はほとんどありません。まったくない場合もあります。いずれのアプリケーション・サーバーもEJB 2.0仕様に準拠しており、OC4JはEJB 2.1およびEJB 3.0早期ドラフト版にも対応しています。
EJB 2.0仕様に準拠して記述および設計されたすべてのEJBは、正常に動作し、最小限の作業で移行できます。主な作業は、新しい環境でのアプリケーションの構成およびデプロイです。独自の拡張機能が使用されている場合にのみ、移行作業が複雑になります。
この章では、EARファイル形式または展開ディレクトリ形式でデプロイされたEJBの移行について説明します。
WebLogic Server 8.1ではEJB 2.0が、Oracle Containers for J2EE（OC4J）ではEJB 2.1およびEJB 3.0早期ドラフト版がサポートされているため、これら2つの実装にはいくつかの違いがあります。次の表に、両方のアプリケーション・サーバーで使用できるEJB機能のサマリーを示します。
表5-1 EJB機能の比較
| 機能 | Oracle Application Server 10g（10.1.3.1.0） | WebLogic Server 7.0 |
WebLogic Server 8.1 |
|---|---|---|---|
|
セッションBean |
使用可能 |
使用可能 |
使用可能 |
|
コンテナ管理の永続性（CMP）を備えたエンティティBean |
使用可能 |
使用可能 |
使用可能 |
|
Bean管理の永続性（BMP）を備えたエンティティBean |
使用可能 |
使用可能 |
使用可能 |
|
メッセージドリブンBean |
使用可能 |
使用可能 |
使用可能 |
|
JTAトランザクション |
使用可能 |
使用可能 |
使用可能 |
|
JCAエンタープライズ接続性 |
使用可能 |
使用可能 |
使用可能 |
|
IMSメッセージ |
使用可能 |
使用可能 |
使用可能 |
|
EJBスタブの動的生成 |
使用可能 |
使用可能 |
使用可能 |
|
完全にEARファイル・ベースのデプロイ |
使用可能 |
使用可能 |
使用可能 |
|
EJBアプリケーションのオート・デプロイ |
使用可能 |
使用可能 |
使用可能 |
|
ステートレスEJBおよびステートフルEJBのクラスタリング |
使用可能 |
使用可能 |
使用可能 |
|
Enterprise JavaBeans用のローカル・インタフェース |
使用可能 |
使用可能（MDBを除く） |
使用可能（MDBを除く） |
|
EJB Query Language（EJB-QL） - コードの自動生成 - OracleおよびOracle以外のデータベースのサポート |
使用可能 |
使用可能（WebLogic QLによる拡張） |
使用可能（WebLogic QLによる拡張） |
|
RMI-over-IIOPのサポート |
使用可能 |
使用可能 |
使用可能 |
|
関連性を備えたCMP |
使用可能 |
使用可能 |
使用可能 |
|
並行処理制御 - 読取り専用ロック - 即時ロック - コミット時ロック |
使用可能 |
使用可能 |
使用可能 |
次の2つの点から、OC4Jのコンテナ管理の永続性（CMP）の実装を使用すると、WebLogic Serverの実装に比べて、パフォーマンス上のメリットが大きいことがわかります。
変更されたEJBの自動検出: CMPを使用すると、Oracle Application ServerのJ2EEコンテナで、EJBが変更されたかどうかを自動的に検出し、EJBの状態をデータベースに書き込むことができます。ejbStoreは、必要な場合にのみ起動されます。WebLogic Serverには、このような自動検出機能がないため、ejbStore操作を実行するかどうかを判断する場合にWebLogic Serverコンテナで使用されるis-modifiedメソッドをユーザーが記述する必要があります。
CMPの単純なデータベース・マッピングと複雑なデータベース・マッピング: Oracle Application ServerのJ2EEコンテナでは、データベース・フィールドの単純なマッピング（1対1、1対多）および複雑なマッピング（多対多）の両方が効率的にサポートされています。対照的に、WebLogic Serverでは、CMPデータベース・フィールドの単純なマッピング（1対多）の基本的なサポートのみが提供されています。また、WebLogic Serverでは、where句の文字列を限定すると、不要な全表スキャンが実行されます。
他社製品と比較した場合、Oracle Application ServerのJ2EEコンテナでは次のクラスタリング機能が提供されています。
サーブレットのクラスタリング: Oracle Application Serverには、ユーザーのアプリケーションを変更することなく、サーブレットをクラスタリングする機能があります。変更が行われる場合はデプロイメント構成に対して行われますが、これらの変更はJ2EEアプリケーションに対して透過的です。
クラスタリング・アーキテクチャの簡易性: Oracle Application ServerのJ2EEコンテナの重要な特長として、様々なインスタンスを簡単にクラスタリングできること、およびクラスタリングで使用されるアーキテクチャが堅牢であることがあげられます。具体的には、Oracle Application Serverでは、様々なOracle Application Serverインスタンスを単一のクラスタに属するように構成する場合に変更が必要なXMLファイル（Application Server Controlコンソールを介して変更可能）は１つのみです。それらのOracle Application Serverインスタンスが、単一のマシンにロード・バランシング機能が備えられた複数のサーバーであるか、複数のマシンにロード・バランシング機能が備えられた複数のサーバーであるかは関係ありません。
対照的に、ロード・バランシング機能を備えたWebLogic Serverクラスタを構成する作業は、複数のインスタンスが単一マシン上にある場合も複数マシン上にある場合も複雑です。たとえば、クラスタでEJBを使用することにした場合、appcを使用してEJBスタブを作成する際にそのことを指定する必要があります。appcによって、デプロイに使用される特殊なクラスタ対応クラスが作成されます。 Oracle Application ServerのJ2EEコンテナは、他のOracle Application Serverコンポーネントと組み合せることで、全体として、より堅牢で使いやすいクラスタリング・アーキテクチャとなります。
ステートフル・セッションBeanおよびステートフル・エンティティBeanのクラスタリング: Oracle Application Serverでは、ステートフル・セッションBeanおよびステートフル・エンティティBeanのクラスタリングがサポートされています。設計上の要点は次のとおりです。
クラスタリング時のパフォーマンス: WebLogic Serverなどで使用されている既存のクラスタリング機能では、ステートフルな形式のインスタンスをクラスタリング環境で実行すると、パフォーマンスが大幅に低下します。そのため、ほとんどのアプリケーション開発者は、中間層を完全にステートレスのままにし、それらの状態をデータベースなどの永続ストアに書き込むことを選択します。 デフォルトでは、OC4Jのクラスタリング実装は、パフォーマンスを低下させないように最適化されています。
プログラムの簡易性: 固有のセッション境界（状態をフェイルオーバーさせる場所）を持つサーブレットとは異なり、EJBにはこのような明確な境界がありません。そのため、Oracle Application Serverでは、開発者がアプリケーションを変更することなくEJBクラスタリングを使用できるように、簡単なプログラム化された機能が提供されています。
|
関連項目:
|
エンティティBeanのスケーラビリティ: Oracle Application Serverでは、主キー値ごとにBeanのラッパー・インスタンスの構成可能なプールを使用して、複数のクライアントが同じエンティティBeanインスタンスのメソッドを同時に検索および起動できるようにすることで、エンティティBeanのスケーラビリティが拡張されています。
適切な並行処理制御: Oracle Application Serverでは、大規模なJ2EEアプリケーションのスケーラビリティおよびパフォーマンスを向上する目的で、多くの新しい並行処理制御オプションが導入されています。
読取り専用ロック: データベースを更新しない読取り専用Beanに対して、Bean開発者は、ejbStore()をコールまたは生成しないようにOC4Jコンテナに指示できます。Beanの状態を外部システム（SQLを使用するEJB以外のアプリケーションなど）で更新できるかどうかに応じて、適切な分離モードが選択されます。
即時ロック: Oracle Application Serverでは、決定的なタイムアウトおよびデッドロックの検出のために各クライアントに独自のBeanインスタンスを提供し、Beanの状態へのアクセスをシリアライズすることができます。
コミット時ロック: Oracle Application Serverでは、別のロック・スキームもサポートされています。このスキームでは行ロックが使用されないため、データの整合性は、Beanの分離モード（「非リピータブル・リード」または「シリアライズ可能」）およびクライアントによる行の更新順序によって異なります。
WebLogic Serverでも、同様の機能が提供されています。
実際には、WebLogic ServerからOracle Application ServerにEJBを移行するプロセスに大きな問題はありません。通常、コードを変更する必要はほとんどありません。まったくない場合もあります。変更が行われる場合、よく行われる変更はJNDIの移植性の問題に関連する変更です。この問題は、JNDI初期コンテキストのインスタンス化と、データソースおよびEJBのホーム・インタフェースとリモート・インタフェースに使用するJNDIルックアップ名に関連しています。
したがって、移行作業では、コンテナ・クラスの生成、オブジェクト・リレーショナル（O-R）・マッピングの定義、および（必要に応じて）デプロイ・プロパティのカスタマイズに対応する実装固有の適用タスクを実行します。
EJB導入の目的の1つは、異なる環境間でのコンポーネントの移植をソース・コード・レベルのみでなく、バイナリ・レベルでも可能にすることです。もう1つの目的は、統一仕様に基づいてパッケージされたコンパイル済コンポーネントの移植性を確保することです。
EJBには移植性がありますが、多くの移植不可能な実装固有の側面もあります。これらには、実装間でコンポーネントを移行する際に対処する必要があります。通常、EJBコンポーネントでは、コンテナとの低レベルのインタフェースが必要です。このインタフェースは、スタブ・クラスおよびスケルトン・クラスという形式で、これらのクラスは実装固有の状態にしておく必要があります。実際、EJBコンポーネントの移植可能な要素と移植不可能な要素は、次のように明確に区別できます。
移植可能なEJB要素には、次のものがあります。
実際のコンポーネントの実装クラスおよびインタフェース（Beanクラス、リモート・インタフェース、ホーム・インタフェース）。
JNDI名やトランザクション属性などの汎用コンポーネント・プロパティを記述するアセンブリ・ディスクリプタおよびデプロイメント・ディスクリプタ。
セキュリティ属性。
実装固有の要素には、次のものがあります。
ホスト・コンテナとのインタフェースとして機能する低レベルのヘルパー実装クラス（スタブおよびスケルトン）。
CMPエンティティBeanのO-Rマッピング定義（各プラットフォーム独自の実装固有の形式で宣言されたカスタム・ファインダ・メソッド用の検索ロジックなど）。
すべてのコンポーネントに、デプロイ時に系統立てて構成する必要がある一連のプロパティが備えられています。たとえば、EJBコンポーネントに宣言されているセキュリティ・ロールを実際のユーザーおよびグループにマップするタスクは、そのマッピングを事前に確認できないため、デプロイ時に系統立てて実行します。また、このマッピングは、ターゲット・デプロイ・サーバー上のユーザー・ディレクトリの構造および要素によって異なる可能性があります。
EJB（またはJNDIルックアップを実行する他の任意のオブジェクト）をWebLogic ServerからOC4Jに移行する際に、そのEJBで独自リソース以外の他のアプリケーション・リソースに対してJNDIルックアップを実行する場合は、OC4JのグローバルJNDIルックアップを有効にする必要があります。JNDIルックアップは、WebLogic Serverではグローバル・コンテキストで実行されますが、OC4Jのデフォルト構成ではアプリケーション・スコープ内でのみ実行されます。したがって、デフォルト構成のままOC4Jで別のアプリケーションに対してルックアップを実行すると、NameNotFoundExceptionがスローされます。
OC4JインスタンスでグローバルJNDIルックアップを有効にするには、server.xmlの<application-server>要素に含まれているglobal-jndi-lookup-enabled属性をtrueに設定します。JNDI名がバインド・クラスに適切に解決されるようにするには、ルックアップを試行するアプリケーションのクラスパスにターゲット・アプリケーションのクラスが含まれている必要があります。これを行うには、次のいずれかのタスクを実行します。
ターゲット・アプリケーションのJARアーカイブを$ORACLE_HOME/j2ee/home/applib共通クラス・ディレクトリに配置します。
ターゲット・アプリケーションのJARアーカイブを共有ライブラリの場所に配置します。 共有ライブラリは、server.xmlの<shared-library>要素で定義できます。 この要素の詳細は、『Oracle Containers for J2EE構成および管理ガイド』を参照してください。
Oracle Application ServerのJNDIの詳細は、『Oracle Containers for J2EEサービス・ガイド』を参照してください。
WebLogic ServerのEJB実装に関するその他の注意事項を次に示します。
BMPセキュリティのWebLogic Server実装は、J2EE仕様に完全には準拠していません。仕様によると、BMPセキュリティのロール権限に違反がある場合、例外がスローされる必要があります。OC4Jでは仕様に従って例外がスローされますが、WebLogic Serverではスローされません。
WebLogic Serverとは異なり、OC4Jを使用する開発者は、EJBのデプロイ用にweblogic-ejb-jar.xmlなどの独自のXMLファイルを作成する必要はありません。OC4Jでは、内部使用の目的でorion-ejb-jar.xmlというファイルがOC4Jコンテナによって作成されます。開発者は、必要に応じてこのファイルを変更して独自のEJB構成データを指定できますが、このファイルを明示的に作成する必要はありません。weblogic-ejb-jar.xmlおよびweblogic-cmp-rdbms-jar.xmlファイル内のカスタムEJB構成情報は、XSLTまたはOracle JDeveloper Migration Assistantを使用してorion-ejb-jar.xmlに移行できます。詳細は、5.2.3.1を参照してください。
この項では、EJBの移行方法の概要を示します。注意が必要な永続性レベルの問題が存在しないため、セッションEJBの移行はエンティティEJBの移行より簡単です。標準のJ2EEコンポーネントおよびデプロイメント・ディスクリプタ（ejb-jar.xml）は、ほとんど変更する必要がありません。
実装固有の依存性は、セッションEJBおよびエンティティEJBの両方で変更する必要があります。前述のとおり、これらの変更には次のものが含まれます。
ハードコードされたJNDIコンテキストのアクセスおよびルックアップ
データソースのJNDI名およびルックアップ
O-Rマッピング、コンテナ・クラスの生成、およびデプロイ・プロパティのカスタマイズに対応する実装固有の適用
EJBアーカイブ・ファイル（JAR）の変更および再生成
セッションBeanの移行作業では、EJBを移行する際の一般的な手順を実行します。 標準セットに含まれているファイルは次とおりです。
適切なコード変更を次のように実行します。
すべての独自のAPIとフラグを削除および置換します。
ハードコードされた実装固有のJNDIおよびJDBC参照を削除します。
デプロイ・プロパティを次のように調整します。
必要に応じて、XMLデプロイメント・ディスクリプタを再作成します。詳細は、5.2.3を参照してください。
OC4J環境のランタイム・プロパティをカスタマイズします。
必要に応じて、EJBのJNDI名を再マップします。
更新済のEJBアーカイブ・ファイル（.jarおよび.ear）を保存します。
アーカイブ・ファイルをOC4Jにデプロイします。
エンティティEJBの移行作業では、セッションEJBを移行する場合の一般的な手順（5.2.1）、およびエンティティEJBを移行する場合に固有の次の手順を実行します。
実装固有のJNDIルックアップまたはデータソース・ルックアップを削除および置換します。
固有のデータベース・デプロイメント・ディスクリプタを次のように記述しなおします。
weblogic-ejb-jar.xmlおよびweblogic-cmp-rdbms-jar.xml（コンテナ管理の永続性用）をorion-ejb-jar.xmlに移行します。
トランザクション管理、ロックおよびキャッシュ用のすべての独自のAPIとフラグを削除および置換します。
前述の手順以外に、コンテナごとにサポートされるEJB仕様レベルが異なることにも注意してください。仕様が異なる場合は、コード変更が必要になる可能性があります。たとえば、EJB 1.1（WebLogic Server 7.0でのサポート対象）の場合、ローカル・エンティティEJBのejbRemove()メソッドではjavax.rmi.RemoteExceptionがスローされる必要があります。対照的に、EJB 2.0（Oracle Application Serverのサポート対象）の場合、ejbRemove()ではjavax.ejb.EJBExceptionのみがスローされる必要があります。 ejbRemove()によってスローされる例外を変更せずに、ローカル・エンティティEJBをWebLogic Server 7.0からOracle Application Server 10g リリース3（10.1.3.1.0）に移行すると、EJBのデプロイ時にコンパイル例外が発生します。
BMPを備えたEJBを移行する手順は次のとおりです。
固有のJNDI参照を含むコードを確認します。
必要に応じて、各JNDI名を再マップします。
エンティティBeanクラスのコード全体を参照して、データ・アクセス・コードに実装固有の依存性（ハードコードされたJNDI環境プロパティなど）または実装依存の問題（データソースJNDI名など）が存在していないかどうかを確認します。必要に応じて、コードとEJBアーカイブ・ファイルを変更および再生成します。
必要に応じて、デプロイ・プロパティを調整します。
Oracle JDeveloperを使用している場合は、EJBアーカイブをEJBコンフィギュレータにインポートします。その後、次の操作を実行します。
必要に応じて、デプロイ・プロパティを調整します。
更新済のEJBアーカイブ・ファイルを保存します。
OC4Jにデプロイします。
EJBのJNDI名を再マップします。
OC4J用の低レベルのコンテナ・クラスを生成します。
必要に応じて、EJBのデプロイ時プロパティをカスタマイズします。
注意が必要な手順は、主にJNDIコンテキストへのアクセスおよびデータソースのルックアップの手順です。そのため、次の操作を実行することをお薦めします。
JNDIコンテキストを取得するコードによって、InitialContextクラスのコンストラクタに実装固有のプロパティが渡されていないことを確認します。
このEJBに固有の環境エントリをルックアップして間接的にデータソースJNDI名を取得できるように、ハードコードされた参照がデータソースJNDI名に対して使用されているコードを変更します。 これによって、後で必要に応じて、EJBのデプロイメント・ディスクリプタに含まれるデータソースJNDI名を間単に修正できるようになります。
CMPエンティティBeanでは、EJBコンテナによってオブジェクトの永続状態が管理されます。これには、永続化が必要なオブジェクトの属性と、そのオブジェクトの属性値を保持するデータベース表の対応列間のO-Rマッピングが使用されます。
ただし、EJB仕様にはO-Rマッピングを定義する標準的な方法は規定されていません。そのため、マッピング情報は、各EJBコンテナ・ベンダー独自の仕様に基づいてEJBアーカイブ・ファイルに格納されています。
したがって、EJBアーカイブ・ファイルに格納されているO-Rマッピング定義には、EJBベンダー間の互換性がありません。マッピング情報は、移行プロセスの一環として再生成する必要があります。
CMPを備えたEJBを移行するタスクの概要は次のとおりです。
O-Rマッピング定義はベンダー依存であるため、weblogic-ejb-jar.xmlおよびweblogic-cmp-rdbms-jar.xmlのマッピング定義は、orion-ejb-jar.xmlで再作成する必要があります。手順については、5.2.3「デプロイメント・ディスクリプタの移行」を参照してください。
コンテナ管理の関連性（CMR）マッピングの差異を解決します。
永続性を実現するためにOC4Jのデータソースを構成します。
WebLogic Server固有のコンテナのスタブ・クラスおよびスケルトン・クラスを削除し、OC4Jで同等のスタブ・クラスおよびスケルトン・クラスを生成します。
EJBの構成およびデプロイには、2つのデプロイメント・ディスクリプタが使用されます。1つ目のデプロイメント・ディスクリプタejb-jar.xmlは、EJB仕様で定義されていて、EJBアプリケーションを記述する場合の標準化された形式を提供しています。2つ目のデプロイメント・ディスクリプタは、ベンダー固有のデプロイメント・ディスクリプタで、ejb-jar.xmlファイルに定義されているリソースをアプリケーション・サーバーのリソースにマップします。また、EJBの動作、キャッシュ処理、ベンダー固有の機能などのEJBコンテナのその他の側面の定義にも使用されます。
WebLogic Server固有のデプロイメント・ディスクリプタはweblogic-ejb-jar.xmlおよびweblogic-cmp-rdbms-jar.xmlで、OC4J固有のデプロイメント・ディスクリプタはorion-ejb-jar.xmlです。
J2EEアプリケーションの通常のディレクトリ構造は次のようになります。
WebLogic Server固有のデプロイメント・ディスクリプタweblogic-ejb-jar.xmlによって、WebLogic Server固有のEJBデプロイメント・ディスクリプタのDTDが定義されます。weblogic-ejb-jar.xmlのDTDには、ステートフル・セッションEJBのレプリケーションの有効化、エンティティEJBのロック動作の構成、およびメッセージドリブンBeanにJMSのキュー名とトピック名の割当てを行うための要素が含まれています。
EJBのweblogic-ejb-jar.xmlに構成されている要素は次のとおりです。
weblogic-enterprise-bean
ejb-name
entity-descriptor
stateless-session-descriptor
stateful-session-descriptor
message-driven-descriptor
transaction-descriptor
reference-descriptor
enable-call-by-reference
jndi-name
Security-role-assignment
transaction-isolation
WebLogic Server固有のデプロイメント・ディスクリプタweblogic-cmp-rdbms-jar.xmlによって、WebLogic ServerのRDBMSベースの永続性サービスを使用するエンティティEJBのデプロイ・プロパティが定義されます。
各weblogic-cmp-rdbms-jar.xmlによって、次の永続性オプションが定義されます。
CMP用のEJB接続プールまたはデータソース
関連性用の外部キー・マッピング
問合せ用のWebLogic Server固有のデプロイメント・ディスクリプタ
OC4J固有のデプロイメント・ディスクリプタorion-ejb-jar.xmlには、セッションBean、エンティティBean、メッセージドリブンBeanおよびセキュリティに関する拡張デプロイ情報が含まれています。
エンティティEJBでは、その状態をトランザクション型または非トランザクション型の永続記憶域に保存する（Bean管理の永続性）か、または一時的でないインスタンス変数をコンテナで自動的に保存する（コンテナ管理の永続性）ことができます。WebLogic ServerおよびOC4Jでは、これら2つの管理方法のいずれも選択でき、併用することも可能です。
コンテナ管理の永続性を使用するEJBの場合は、weblogic-ejb-jar.xmlまたはorion-ejb-jar.xmlデプロイメント・ディスクリプタ・ファイルによって、EJBが使用する永続性サービスのタイプが指定されます。WebLogic Serverの場合は、自動永続性サービスを使用する際に、追加のデプロイメント・ファイルを使用してデプロイメント・ディスクリプタを指定し、エンティティEJBのファインダ・メソッドを定義する必要があります。WebLogic ServerのRDBMSベースの永続性サービスでは、Beanのweblogic-cmp-rdbms-jar.xmlファイルを使用して、特定のBeanからデプロイメント・ディスクリプタおよびファインダ定義が取得されます。この構成ファイルは、weblogic-ejb-jar.xmlファイルで参照されている必要があります。OC4Jの場合、永続性サービスのタイプおよびRDBMSベースの永続性サービスの詳細は、1つのデプロイメント・ディスクリプタ（orion-ejb-jar.xml）を使用して構成および取得されます。
ejb-jar.xmlに含まれている標準のJ2EEディスクリプタは、変更の必要がほとんどなく、簡単に移行できます。次のファイルに含まれている実装固有のJ2EEディスクリプタは、変更する必要があります。
weblogic-ejb-jar.xml
CMP EJBの場合、weblogic-cmp-rdbms-jar.xmlに含まれているディスクリプタをOC4J固有のorion-ejb-jar.xmlに移植する必要があります。
OC4J固有のXMLディスクリプタの定義については、『Oracle Containers for J2EE Enterprise JavaBeans開発者ガイド』またはオンラインのDTDファイルを参照してください。これらのファイルは次の場所にあります。
http://xmlns.oracle.com/ias/dtds/orion-application.dtd http://xmlns.oracle.com/ias/dtds/orion-application.dtd http://xmlns.oracle.com/ias/dtds/orion-ejb-jar.dtd http://xmlns.oracle.com/ias/dtds/orion-web.dtd http://xmlns.oracle.com/ias/dtds/orion-application.dtd
デプロイメント・ディスクリプタは、次のいずれかの方法を使用して移行できます。
任意のテキスト・エディタを使用して、プラットフォーム固有のデプロイメント・ディスクリプタ・ファイルを手動で作成します。
Extensible Stylesheet Language Transformation（XSLT）: Oracleでは、BEA、JBossおよびBorlandが提供されています。 OracleのXSLTトランスフォーマはサンプル・コードであるため、出力結果を多少変更する必要があります。
Oracle JDeveloperを使用すると、デプロイメント・ディスクリプタを簡単に編集できます。Oracle JDeveloperで、移行するアプリケーションのリバース・エンジニアリングを行います。Oracle JDeveloperによって適切なディスクリプタが自動的に生成されます。
|
注意: JBuilder用に、OC4Jのデプロイメント・ディスクリプタを生成するアドインが提供されています。 |
weblogic-ejb-jar.xmlをorion-ejb-jar.xmlに変換する手順次の手順によって、weblogic-ejb-jar.xmlおよびweblogic-cmp-rdbms-jar.xml内のほとんどのディスクリプタ要素を変換できます。
「ファイル」メニューの「インポート」を選択し、移行するWebLogic ServerのEJBが含まれているEARファイルを指定します。
インポート操作を正常に完了した後、weblogic-ejb-jar.xmlを右クリックして「OC4Jにエクスポート」を選択します。
生成されたorion-ejb-jar.xmlを右クリックして「プロパティ」を選択します。
必要に応じて、マッピングを編集します。
接続ナビゲータを使用してOC4Jインスタンスへの接続を作成します。（「表示」メニューの「接続ナビゲータ」を選択します。）
EJBデプロイメント・プロファイルを作成します。アプリケーション・ナビゲータで、ejb-jar.xmlを右クリックして「EJBデプロイメント・プロファイルの作成」を選択します。
EJBをOC4Jインスタンスにデプロイします。手順6で作成したデプロイメント・プロファイルを右クリックし、アプリケーション・サーバー接続を選択します。
|
注意: weblogic-cmp-rdbms-jar.xmlの変換には、前述の手順と同様の手順を使用します。WebLogic Serverの両方のディスクリプタ・ファイルに対して同じorion-ejb-jar.xmlファイルが生成されます。 |
weblogic-cmp-rdbms-jar.xmlからtoplink-ejb-jar.xmlに変換する方法TopLink移行ツールでは、次のファイルを入力として使用します。
weblogic-ejb-jar.xml
weblogic-cmp-rdbms-jar.xml
このツールによって、WebLogic Server固有の永続性構成が新しいtoplink-ejb-jar.xmlファイルに可能なかぎり移行され、指定したターゲット・ディレクトリに次の新しいファイルが出力されます。
orion-ejb-jar.xml
toplink-ejb-jar.xml
TopLink Workbenchプロジェクト・ファイル（TLCmpProject.mwp）
入力に使用するBEA WebLogicファイルは、EAR、JAR、またはスタンドアロンのXMLファイルです。EARファイルまたはJARファイルからではなく、複数のスタンドアロンのXMLファイルから移行を行う場合は、ドメイン・クラスにアクセス可能であること、およびそれらのクラスがクラスパスに含まれていることを確認してください。
TopLink移行ツールによって、新しいorion-ejb-jar.xmlおよびtoplink-ejb-jar.xmlファイルが、指定したターゲット・ディレクトリに元のファイルと同じ形式で出力されます。 たとえば、入力としてEARファイルを指定した場合、TopLink移行ツールでは、新しいEARファイルがステージングおよび作成されます。このファイルは、新しいorion-ejb-jar.xmlファイルおよび新しいtoplink-ejb-jar.xmlファイルの両方を含むという点以外は元のEARファイルと同じです。
TopLink Workbenchのプロジェクト・ファイルは、常に個別ファイルとして出力されます。
|
注意: TopLink移行ツールを使用する前に、weblogic-ejb-jar.xml、weblogic-cmp-rdbms-jar.xmlおよびtoplink-ejb-jar.xmlファイルのバックアップ・コピーを作成することをお薦めします。 |
TopLink移行ツールの実行時には、出力ディレクトリにあるwls_migration.logというログ・ファイルにすべてのエラー情報および診断情報が記録されます。 TopLink WorkbenchからTopLink移行ツールを使用している場合は、ホーム・ディレクトリ（Windows環境ではC:\Documents and Settings\<username>など）にあるTopLink Workbenchのログ・ファイルoracle.toplink.workbench.logも参照してください。
TopLink移行ツールによって、入力ファイルのディスクリプタ情報、マッピング情報および問合せ情報が次のように処理されます。
エンティティBeanごとにTopLinkディスクリプタ・オブジェクトが構築され、マップされた表、主キー、CMPフィールドおよびCMRフィールドのマッピングなどのネイティブ永続性メタデータが移行されます。
エンティティBeanのすべてのCMPおよびCMRフィールドに対してTopLinkマッピング・オブジェクトが構築され、外部キー参照などのネイティブ永続性メタデータが移行されます。
エンティティBeananのファインダまたはejbSelectごとにTopLink問合せオブジェクトが構築され、カスタマイズされた問合せ文などの永続性メタデータが移行されます。
|
関連項目: TopLink WorkbenchからTopLink移行ツールを使用する手順については、『Oracle TopLink開発者ガイド』を参照してください。 |
EJBクラスをコンパイルし、必要なXMLデプロイメント・ディスクリプタ（J2EEデプロイメント・ディスクリプタおよびベンダー固有のデプロイメント・ディスクリプタ）を追加した後、EJBへのアクセスに使用するコンテナ・クラスを生成します。コンテナ・クラスには、クライアントがEJBの内部表現として使用する外部インタフェース（ホームおよびリモート）およびアプリケーション・サーバーがEJBの内部表現として使用するクラスの実装が含まれています。
WebLogic Serverの場合、appcコンパイラを使用して、WebLogic Server固有のXMLデプロイメント・ファイルに指定されたデプロイ・プロパティに従ってコンテナ・クラスを生成します。たとえば、クラスタでEJBを使用することにした場合は、appcによってデプロイに使用する特殊なクラスタ対応クラスを作成します。また、appcは、必要なオプションおよび引数を指定してコマンドラインから直接使用することもできます。
コンテナ・クラスを生成した後、それらのクラスをJARファイルまたはEARファイルにパッケージし、コンソールのGUIを使用してデプロイする必要があります。
WebLogic ServerにデプロイされたEJBが含まれているEARファイルおよびJARファイルは、Oracle Application Serverに移行できます。ただし、EARファイルは、その内容が完全で、XMLディスクリプタに適切なエントリが含まれていることを確認するために、解凍してアーカイブしなおす必要があります（Oracle JDeveloperを使用する方法もあります）。ガイドラインとして次の点に注意してください。
EJBクライアントのXMLディスクリプタによってEJBスタブのJNDI名が指定されていることを確認します。クライアントがWebアプリケーションの場合、JNDI名はweb.xmlに指定されています。クライアントがスタンドアロン・アプリケーションの場合、JNDI名はapplication-client.xmlに指定されています。
EJBクライアントがスタンドアロン・アプリケーションの場合、クライアント・クラスおよびXMLディスクリプタ・ファイルapplication-client.jarをJARファイルにアーカイブし、次にそのJARファイルをEJBが含まれているEARファイルにアーカイブします。
WebLogic Serverから移行するEJBがJARファイルに存在する場合、EJBをEARのapplication.xmlとともにEARファイルにパッケージしなおす必要があります。
Application Server Controlコンソールを使用して、EARファイルをOracle Application Serverにデプロイします。
appcやrmicなどの機能を使用してEJBスタブをクライアント・アプリケーションにプリコンパイルする必要はありません。EJBスタブは、OC4JのEJBコンテナによってオンデマンドで生成されます。
EJBアプリケーションは、J2EE仕様で定義されている標準のディレクトリ構造を使用するファイルのコレクションとしてデプロイすることもできます。このタイプのデプロイでは、展開ディレクトリ形式でアプリケーションがデプロイされます。展開ディレクトリ形式によるEJBアプリケーションのデプロイは、通常、アプリケーションの開発時にスタンドアロンOC4Jインスタンスに対してのみ行われます。開発者がソース・ファイルの変更およびアプリケーションのテストを迅速に行うには、展開ディレクトリ形式のほうが適しているためです。ただし、Oracle Application Serverの本番環境では、アプリケーションをEARファイルにパッケージし、Application Server Controlコンソールを使用してデプロイする必要があります。
展開ディレクトリ構造をWebLogic Serverにデプロイする場合は、展開ディレクトリ形式のEJBアプリケーションが含まれている最上位のディレクトリを、WebLogic Server環境のmydomain/config/applications/ディレクトリ（mydomainはWebLogic Serverドメインの名前）にコピーします。コピーの完了後、WebLogic ServerによってEJBアプリケーションが自動的にデプロイされます。
OC4Jの場合は、展開ディレクトリ形式のEJBアプリケーションが含まれている最上位のディレクトリをOC4Jインストール環境の次のディレクトリにコピーします。
UNIXの場合: <ORACLE_HOME>/j2ee/home/applications/
Windowsの場合: <ORACLE_HOME>\j2ee\home\applications\
次に、EJBモジュールが含まれるように、<ORACLE_HOME>/j2ee/home/config/ディレクトリ（UNIXの場合）または<ORACLE_HOME>\j2ee\home\config\ディレクトリ（Windowsの場合）にあるデフォルトのJ2EEアプリケーション・デプロイメント・ディスクリプタ（server.xml）を変更します。
WebLogic Serverでは、管理コンソール（またはその他の方法）を使用してファイルを変更した場合、更新された構成を取得する前にサーバーを再起動する必要があります。OC4Jでは、server.xmlのタイムスタンプが変更されると、XMLファイルにそれらの変更が反映されます。
WebLogic Serverでは、RDBMSの永続性を使用するEJBに対して、動的ファインダを作成する方法が提供されています。EJBプロバイダによって、ファインダのメソッド・シグネチャがEJBHomeインタフェースに記述され、そのファインダの問合せ式がejb-jar.xmlデプロイメント・ファイルに定義されます。appcコンパイラによって、ejb-jar.xml内の問合せに基づいて、デプロイ時にファインダ・メソッドの実装が作成されます。
RDBMSの永続性に対するファインダには、次の主要コンポーネントがあります。
EJBHomeのファインダ・メソッド・シグネチャ
ejb-jar.xml内に定義されているqueryスタンザ
weblogic-cmp-rdbms-jar.xml内のオプションのWebLogic Serverのqueryスタンザ
OC4Jでは、ファインダ・メソッドが自動生成されることによって、プロセス全体が簡略化されています。
OC4Jでは、findByPrimaryKeyメソッドを簡単に指定できます。単純な主キーまたは複合主キーを定義するためのすべてのフィールドは、ejb-jar.xmlデプロイメント・ディスクリプタ内に指定します。CMPエンティティBeanのその他のファインダ・メソッドを定義するには、次の手順を実行します。
ファインダ・メソッドを移行する場合の注意事項は次のとおりです。
OC4Jでは、標準のファインダ・メソッドが自動的に生成されます。ファインダ・メソッドを再生成する必要はありません。
WebLogic Server 5.1および6.0のファインダ・メソッドでは、WLQL（WebLogic Query Language）が使用されます。WLQLは、選択条件を指定する独自の問合せ言語です。この部分は記述しなおす必要があります。
OC4Jでは、選択条件の指定に標準SQLのWHERE句、またはEJB Query Language（EJB-QL）が使用されます。
WebLogic Serverによって拡張されたすべてのEJB-QLの機能を記述しなおす必要があります。
カスタム・ファインダ・メソッド（データベースの要素を検索するためにEJB内で使用されるロジック）の詳細に関するEJB 1.1仕様の記述は完全ではありません。この仕様では、このようなメソッドはfind…()またはfindBy…()で始まる名前を使用してホーム・インタフェースおよびBeanクラス内で宣言するように規定されていますが、基礎となる検索ロジックを宣言するための正式な構文は提供されていません。つまり、カスタム・ファインダ用の問合せを宣言する方法は、標準化されていないため、EJBコンテナに依存しています。また、カスタム・ファインダ・メソッドでは、必要な機能に応じて、単一のエンティティBeanが戻される場合またはエンティティBeanのコレクションが戻される場合があります。
WebLogic Serverの検索ロジックは、LISPとよく似た構文を持つWLQLを使用して表現されます。問合せの演算子およびオペランドは、次の形式で表現されます。
(operator operand1 operand2)
WebLogic Serverでの検索ロジック
この言語では、複数の選択条件（SQLのWHERE句に相当）を指定して問合せを定義できます。また、ソート句（SQLのORDER BY句に相当）を指定して問い合わせを定義することもできます。
Oracle Application Serverでの検索ロジック
対照的に、Oracle Application Serverの検索ロジックは、複数の選択条件を指定できる標準SQLのWHERE句を使用して表現されます。
入力パラメータおよびORDER BY句を指定してLIKE演算子を使用する場合は、EJB 2.1がサポートされているTopLink CMPとともにOracle Application Server 10g リリース3（10.1.3.1.0）を使用します。 TopLinkを使用しない場合は、orion-ejb-jar.xmlに含まれているquery=""内のSQLを変更する方法を使用できます。
WebLogic Server 5.1および6.0では、weblogic-cmp-rdbms-jar.xmlファイルの各ファインダのqueryスタンザに、EJBを戻すための問合せを定義するWLQL文字列を含める必要がありました。これらのリリースのWebLogic ServerにはEJB 1.1コンテナが実装されており、標準のEJB-QLはサポートされていませんでした。
EJB 2.0仕様に基づく標準のEJB Query Languageの登場に伴い、WLQLの使用は非推奨となっています。WebLogic Server 7.0および8.1のEJBコンテナは、EJB 2.0に準拠しており、EJB-QLがサポートされています。これらのEJBコンテナでは、EJB-QLに対するWLQL拡張機能も追加で提供されています。この拡張機能は、WebLogic Serverに固有のものです。
Oracle Application Serverでは、次の機能を含むEJB-QLが完全にサポートされています。
コードの自動生成: EJB-QLの問合せは、エンティティBeanのデプロイメント・ディスクリプタに定義されています。EJBをOracle Application Serverにデプロイすると、コンテナによってこれらの問合せがターゲット・データ・ストアのSQL言語に自動的に変換されます。この変換によって、コンテナ管理の永続性を備えたエンティティBeanが移植可能になります。エンティティBeanのコードは、特定のタイプのデータ・ストアには関連付けられていません。
SQLコードの生成の最適化: Oracle Application Serverでは、SQLコードの生成時に、データベースに効率的にアクセスするためのバルクSQLや文の一括ディスパッチの使用などの最適化が行われます。
OracleおよびOracle以外のデータベースのサポート: Oracle Application Serverでは、EJB-QLを任意のデータベース（Oracle、MS SQL-Server、IBM DB/2、Informix、Sybaseなど）に対して実行できます。
関連性を備えたCMP: Oracle Application Serverでは、単一のエンティティBeanおよび関連性を備えたエンティティBeanに対してEJB-QLがサポートされています。また、任意のタイプの多様性および方向性がサポートされています。
Oracle Application ServerのEJB-QLの詳細は、『Oracle Containers for J2EE Enterprise JavaBeans開発者ガイド』を参照してください。
WebLogic Serverでは、メッセージドリブンBeanをWebLogic Serverの実際の宛先に関連付けるために、ejb-jar.xmlの新しい要素の他に１つの新しいmessage-driven-descriptorスタンザのみがweblogic-ejb-jar.xmlファイルに含まれています。このXML要素は、destination-jndi-nameです。
OC4JでメッセージドリブンBeanを作成するには、次の手順を実行します。
EJB仕様の定義に従ってメッセージドリブンBeanを実装します。
メッセージドリブンBeanのデプロイメント・ディスクリプタを作成します。
OC4JのJMS XMLファイル（jms.xml）で、JMSのDestinationタイプ（キューまたはトピック）を構成します。
JMSのDestinationタイプを、OC4J固有のデプロイメント・ディスクリプタ（orion-ejb-jar.xml）のメッセージドリブンBeanにマップします。
データベースがメッセージドリブンBeanアプリケーションと関連している場合は、データベースを表すデータソースをdata-sources.xmlで構成します。
Beanおよびデプロイメント・ディスクリプタが含まれているEJB JARファイルを作成します。作成後、application.xmlファイルを構成し、EARファイルを作成してEJBをOC4Jにデプロイします。
