ヘッダーをスキップ
Oracle® Fusion Middleware Java EEアップグレード・ガイド
11g リリース1(11.1.1)
B55925-03
  ドキュメント・ライブラリへ
ライブラリ
製品リストへ
製品
目次
目次

戻る
戻る
 
次へ
次へ
 

5 Java EE環境のアップグレード

この章では、基本的なJava EE環境をアップグレードする方法について説明します。また、ここで示す手順を使用してアップグレード・プロセスの理解を深めたり、ここでの知識を他のアップグレード・シナリオの計画に適用することもできます。

基本的なJava EE環境のアップグレードには、次の主要なタスクがあります。

5.1 タスク1: Oracle WebLogic Server開発ドメインのインストールと構成

アップグレードしたJava EEアプリケーションをテストして検証するには、Oracle WebLogic Serverをインストールする必要があります。次の項では、Oracle WebLogic Serverのインストールと構成について説明します。

5.1.1 開発環境とテスト環境または本番環境との相違点

Java EEアプリケーションの開発とアップグレードを行う場合、通常は、アプリケーションを短時間で効率よくテストするために、基本的なOracle WebLogic Server環境をインストールします。そうすることで、必要なコード変更を行ったときに、アプリケーションを頻繁にデプロイしてテストする作業が容易になります。

この環境は、次の点でテストまたは本番の環境と異なります。

  • 開発環境は、一般に単一ノードの環境です。ロード・バランシングや高可用性を提供するWeb層やクラスタ機能は必要ありません。ただし、開発作業には、開発中のアプリケーションをサポートするために必要な様々なリソース(JDBCデータソース、JMSプロバイダ、データベース・インスタンスなど)も含める必要があります。

    この章の手順に従って、開発環境を構成してください。

  • 開発環境で作成するOracle WebLogic Serverドメインは、開発モードで構成できます。このモードでは、ドメインのリソースを構成したり、コード変更のテストでアプリケーションをデプロイおよび再デプロイする処理を素早く簡単に実行できます。開発モードまたは本番モードの選択は、Oracle WebLogic Server構成ウィザードを使用してドメインを作成するときに行います。

    詳細は、『Oracle Fusion Middleware構成ウィザードを使用したドメインの作成』のサーバー起動モードおよびJDKの構成に関する説明を参照してください。

    Oracle WebLogic Serverのデフォルトのチューニング・パラメータは、構成するのが開発ドメインか本番ドメインかによって異なります。詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverパフォーマンスおよびチューニング』の開発モードと本番モードのデフォルトのチューニング値に関する項を参照してください。

5.1.2 Oracle JDeveloperを使用する場合の開発ドメインのインストールと構成

Oracle WebLogic Serverは、Oracle JDeveloper Studioの一部として使用できます。そのため、Oracle JDeveloper Studioを統合開発環境(IDE)として使用する場合は、Oracle WebLogic Server開発ドメインをOracle JDeveloperインストールの一部としてすばやく簡単にインストールし構成できます。

Oracle JDeveloperで作成するOracle WebLogic Serverドメインは、アプリケーションをすばやく簡単にテストするローカルの開発環境として便利な場合があります。この開発ドメインにJava Required Files(JRF)テンプレートを適用することもできます。これにより、Oracle Application Development FrameworkなどのOracleテクノロジを利用するアプリケーションを開発しテストできるようになります。

ただし、Oracle JDeveloperインストーラで作成するOracle WebLogic Serverドメインにはいくつかの制限があります。次に例を示します。

  • Oracle Fusion Middleware Web層コンポーネントと関連付けるようには設計されていません。

  • Oracle Enterprise Manager Fusion Middleware Controlを含むように構成することはできません。

Oracle WebLogic ServerをOracle JDeveloper Studioとともに使用する場合のインストールと構成の詳細は、『Oracle Fusion Middleware Oracle JDeveloperインストレーション・ガイド』のOracle JDeveloper Studio Editionのインストールに関する項を参照してください。

5.1.3 Oracle SOA Suite、WebCenterまたはApplication Developerを使用する場合の開発ドメインのインストールと構成

Oracle WebLogic ServerをOracle JDeveloperインストールの一部としてインストールして構成するかわりに、Oracle WebLogic Server CD-ROMからOracle WebLogic Serverをインストールできます。このCD-ROMは、Oracle Fusion Middleware 11g メディア・パックに含まれています。また、Oracle Technology Network(OTN)からOracle WebLogic Serverをダウンロードすることもできます。

詳細は、次の項を参照してください。

5.1.3.1 Oracle SOA Suite、WebCenterまたはApplication Developer開発環境をインストールすることの利点

この代替手段を使用すると、次のことが可能になります。

  • テスト環境を別のホストにインストールしてから、Oracle JDeveloperのローカル・コピーをリモート環境に接続しデプロイするように構成できます。

  • Oracle Application Development Frameworkランタイム・ソフトウェアをテスト・ドメインで確実に使用できます。

  • Oracle Enterprise Manager Fusion Middleware Controlを利用できます。これは、Oracle JDeveloperで構成されたドメインの一部としては使用できません。

  • Oracle JDeveloper以外にも他の統合開発環境を使用して、アプリケーションを構築しテストできます。

5.1.3.2 Oracle Fusion Middlewareソフトウェア・スイートの選択

デプロイする予定のアプリケーションの種類に応じて、様々なランタイム環境を提供する複数の異なるOracle Fusion Middlewareソフトウェア・スイートから選択できます。

具体的には、次のOracle Fusion Middlewareソフトウェア・スイートから選択できます。

  • Application Developer。これを使用すると、Oracle Application Development Framework(Oracle ADF)およびOracle Enterprise Manager Fusion Middleware Controlを利用するOracle WebLogic Serverドメインをインストールし構成できます。

  • Oracle SOA Suite。Oracle JDeveloperで開発するOracle SOA Suiteアプリケーションのサポートに必要なランタイム・テクノロジと、Oracle ADFおよびFusion Middleware Controlが提供されます。

  • Oracle WebCenter。Oracle JDeveloperで開発するWebCenterアプリケーションのためのランタイム・テクノロジと、Oracle ADFおよびFusion Middleware Controlが提供されます。

5.1.3.3 Oracle SOA Suite、WebCenterまたはApplication Developerドメインのインストールと構成に必要な手順

ドメインをインストールして構成する手順の概要は、次のようになります。

この項で説明する手順は、Oracle WebLogic Serverの最新バージョンがダウンロード済であることを前提としています。詳細は、『Oracle Fusion Middlewareアップグレード・プランニング・ガイド』のOracle WebLogic ServerおよびOracle Fusion Middleware 11gの最新のソフトウェアの取得についての説明を参照してください。

  1. Oracle WebLogic Serverインストーラを使用して、ディスクにOracle WebLogic Serverソフトウェアをインストールし、Middlewareホームを作成します。

  2. Oracle SOA Suite、WebCenterまたはApplication DeveloperのOracleホームをMiddlewareホームの中にインストールします。

  3. 必要なパッチをOracle WebLogic ServerホームまたはOracle Fusion Middlewareホームに適用します。

  4. Oracle Fusion Middleware構成ウィザードを使用して、ドメインを構成します。

    ウィザードを使用しているときに、Oracle ADFおよびEnterprise Managerテンプレートが選択されていることを確認してください。

  5. ドメインを起動します。

Oracle SOA Suite、WebCenterまたはApplication Development環境のインストールと構成の詳細は、次のいずれかのインストレーション・ガイドを参照してください。

  • 『Oracle Fusion Middleware Oracle SOA Suite and Oracle Business Process Management Suiteインストレーション・ガイド』

  • Oracle Fusion MiddlewareのOracle WebCenterインストレーション・ガイド

  • 『Oracle Fusion Middleware Application Developerインストレーション・ガイド』

5.1.4 Java Required Files(JRF)ドメイン・テンプレートの使用

Oracle WebLogic Serverを構成するときは、各ドメインをドメイン・テンプレートで構成します。Oracle Fusion Middleware 11g で使用できるドメイン・テンプレートには、Java Required Files(JRF)テンプレートなどがあります。

JRFテンプレートは、多くのOC4Jアプリケーションが依存する新バージョンのAPIをサポートするOracleライブラリなどの重要な機能を提供します。

JRFテンプレートにあり、アップグレードしたOC4Jアプリケーションにとって重要なAPIの種類については、4.5.1項「Java Required Files(JRF)ドメイン・テンプレートで使用可能なAPI」を参照してください。

JRFテンプレートを使用してドメインを作成または拡張するには、次の項を参照してください。

5.1.4.1 JRFテンプレートによる新規ドメインの作成

JRFテンプレートを使用して新規ドメインを作成するには、次の2つの方法があります。

  • Oracle JDeveloper 11g インストーラを使用して、開発ドメインをインストールし、構成します。

    このドメインは、JRFテンプレートにより自動的に作成されます。


    注意:

    Oracle JDeveloperで作成したOracle WebLogic Serverドメイン内にOracle Enterprise Manager Fusion Middleware Controlを構成することはできません。

  • Application Developer、Oracle SOA SuiteまたはOracle WebCenterドメインをインストールし構成します。

    Oracle Fusion Middlewareソフトウェア・スイートを構成する場合は、構成ツールを実行しているときにJRFテンプレートを選択することもできます。

    Oracle Enterprise Managerテンプレートを選択するオプションもあります。このオプションでは、Oracle Enterprise Manager Fusion Middleware Controlでドメインを管理できます。

    詳細は、該当するOracle Fusion Middlewareのインストレーション・ガイドを参照してください。

5.1.4.2 JRFテンプレートによる既存ドメインの拡張

既存のドメインをJRFテンプレートで拡張するには、次のいずれかのオプションを使用します。

  • Oracle JDeveloper 11g インストーラを使用します。

    Oracle JDeveloperインストーラで、カスタム・インストールを選択し、ADFランタイム・コンポーネントを選択します。この手順で、ADFランタイムjarファイルおよびドメイン・テンプレートをサーバー環境にインストールできます。


    注意:

    Oracle JDeveloperを使用して、Oracle WebLogic Serverドメインのインストールと構成、およびJRFテンプレートの適用を実行する場合は、Oracle Enterprise Manager Fusion Middleware Controlをドメイン内に構成できません。

    詳細は、Oracle Fusion MiddlewareのOracle JDeveloperインストレーション・ガイドを参照してください。

  • Application Developer、Oracle SOA SuiteまたはOracle WebCenterのOracleホームからOracle WebLogic Server構成ウィザードを実行します。

    ドメインを拡張するオプションを選択し、使用可能なテンプレートのリストが表示されたらJRFテンプレートを選択します。

    Oracle Enterprise Managerテンプレートを適用するよう選択することもできます。その場合は、Fusion Middleware Controlを使用してドメインを管理できます。

    詳細は、該当するOracle Fusion Middlewareのインストレーション・ガイドを参照してください。

  • Fusion Middleware ControlまたはApplyJRF WebLogic Scripting Tool(WLST)コマンドを使用して、JRFテンプレートを既存のWebLogicサーバー・インスタンスに適用します。

    詳細は、『Oracle Fusion Middleware管理者ガイド』の管理対象のサーバーまたはクラスタへのJava Required Filesの適用に関する項を参照してください。

5.2 タスク2: 新しいOracle Fusion Middleware 11g 環境の確認

新しいOracle Fusion Middleware環境がインストールおよび構成され、使用できることを確認するには、次の手順を実行します。

  1. 次のURLと、構成時に指定したWeblogic管理資格証明を使用して、Oracle WebLogic管理コンソールにログインします。

    http://node_name.domain.com:7001/console
    
  2. コンソールの左ペインで「環境」を選択してから「サーバー」を選択します。

  3. ドメインの一部として作成されているサーバーを確認し、サーバーが稼働していることを確認します。

5.3 タスク3: アプリケーションをサポートするOracle WebLogic Serverリソースの構成

アプリケーションを変更したら、アプリケーションに必要なサービスがOracle WebLogic Serverドメイン上に構成されていることを確認する必要があります。

次の項では、Oracle Application Server 10g からアップグレードするアプリケーションをデプロイする前に、実行する必要のあるOracle WebLogic Serverの一般的な管理タスクについて説明します。

5.3.1 Oracle WebLogic Server上でのJDBCデータソースの構成

次の項では、OC4J JDBCデータソースをOracle WebLogic Serverにアップグレードする処理について説明します。

5.3.1.1 OC4JおよびOracle WebLogic Serverのデータソースの定義に関する一般情報

一般に、WebLogic Server上には、データベース接続情報、プーリング要件およびJDBCドライバに基づいて、同等なOC4Jデータソース構成を作成できます。

OC4Jにデプロイされるアプリケーションのデータソースを作成する場合、そのデータソースは次の2つのいずれかの方法で定義できます。

  • アプリケーションがデプロイされるOC4JインスタンスまたはOC4Jグループに対して定義

  • データソース定義をアプリケーション・アーカイブの一部としてdata-sources.xmlというファイルにパッケージ

Oracle WebLogic Serverではこの両方の方法がサポートされていますが、使用する方法に応じて、Oracle WebLogic Serverドメイン上またはアプリケーション内のいずれかで構成タスクを実行する必要があります。

OC4Jの場合と同様に、WebLogic Server JDBCデータソースは、JDBC接続のプールを使用してデータベース接続を提供するJNDIコンテキストにバインドされたオブジェクトです。アプリケーションは、このプールのデータベース接続を使用するために、JNDIコンテキストのデータソースをルックアップします。

5.3.1.2 アプリケーションレベルのOC4Jデータソースのアップグレード

Oracle WebLogic Serverデータソースは一般にドメイン・レベルで定義され、クラスタ全体またはドメイン内の特定の管理対象サーバーに適用されます。ただし、OC4Jデータソースの定義を、OC4Jでサポートするアプリケーション・アーカイブのdata-sources.xmlファイルで行った場合は、同様の構成をOracle WebLogic Serverに実装できます。

Oracle WebLogic Serverの場合は、アプリケーション内のJDBCモジュールとしてデータソースをパッケージできます。これにより、OC4Jのアプリケーションレベルのデータソースと同等の機能が得られます。

詳細は、Oracle Fusion Middleware Oracle WebLogic Server JDBCデータソースの構成と管理に関するマニュアルのデプロイメント用のJDBCアプリケーション・モジュールの構成に関する説明を参照してください。

5.3.1.3 インスタンスレベルおよびグループレベルのOC4Jデータソースのアップグレード

データソースをOC4Jのインスタンスまたはグループに対して定義している場合は、同等のデータソース・セットを新しいOracle WebLogic Serverドメインに定義する必要があります。

OC4J環境内に構成された各JDBCデータソースについて、新しいOracle WebLogic Server JDBCデータソースを同じJNDI名でターゲット・ドメイン内に作成してください。

詳細は、Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCデータソースの作成に関する説明を参照してください。

Oracle WebLogic Server JDBCデータソースは、Oracle Real Application Clusters(RAC)を利用するように構成できます。詳細は、『Oracle Fusion Middleware高可用性ガイド』を参照してください。

5.3.1.4 OC4JおよびOracle WebLogic ServerのJDBC接続プールおよび管理対象データソース

OC4JとOracle WebLogic Server JDBCのデータソース接続プーリングには、大きな違いが2点あります。

  • Oracle WebLogic Server JDBCデータソースでは接続プールが暗黙的に関連付けられるため、OC4J環境の場合とは異なり、接続プールをドメイン内に明示的に作成する必要がありません。

  • Oracle WebLogic Server JDBCデータソースは常に、管理対象のOracleデータソースのように動作します。OC4Jネイティブ・データソースと同等なものはありません。

5.3.2 Oracle WebLogic Server上でのOC4J JMSリソースの構成

次の項では、OC4J JMSリソースをOracle WebLogic Serverにアップグレードする処理について説明します。

5.3.2.1 OC4JおよびOracle WebLogic ServerでのJMSサポートの概要

OC4Jでは、Oracle Enterprise Messaging Service(OEMS)という一連のサービスを通じてJMSをサポートしていました。

OEMSは、分散アプリケーションを構築および統合するためのメッセージ・プラットフォームです。OEMSにより、Oracleメッセージ機能とメッセージ統合ソリューションのフレームワークが提供されます。OEMSは、Java Message Service(JMS)、J2EE Connector Architecture(J2CA)などの業界標準をベースにしています。

OEMSは、JMSプロバイダの3種類の永続性モデルをサポートしています。

  • インメモリー

  • ファイルベース

  • Oracle DB Advanced Queuing(AQ)

Oracle WebLogic Serverには、インメモリーおよびファイルベースのJMSプロバイダに対して直接対応するものがあります。

詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JMSの構成と管理』のJMSおよびWebLogic Serverの概要に関する項を参照してください。

5.3.2.2 OC4JおよびOracle WebLogic ServerでのJMSリソースの作成と管理

OC4Jでは、JMSコネクション・ファクトリおよびJMSサーバーの宛先を個々のOC4Jインスタンス上に構成します。コネクション・ファクトリと宛先は、その後でリソース・プロバイダまたはJMSコネクタにマップされます。

WebLogic Serverの場合は、JMSリソースをWebLogic JMSモジュール内に作成します。JMSモジュールのターゲットは、ドメイン内のWebLogic JMS Serverに設定されます。WebLogic JMSサーバーは、メッセージの永続性、永続サブスクライバ、メッセージ・ページング、およびそれらのターゲットとなるJMS宛先への割当てを構成するための中心になります。

OC4J環境のJMS構成をOracle WebLogic Serverにアップグレードするには、次の手順を実行します。

  1. OC4J環境のJMSリソース・プロバイダ、コネクタ、コネクション・ファクトリおよび宛先の構成を反映した構成を持つ一連のWebLogic JMSサーバーを作成します。

  2. 共通の構成を持つJMSコネクション・ファクトリおよび宛先のセットごとに、WebLogic Server JMSモジュールを作成します。

  3. モジュールに、OC4Jでの対応バージョンと同じJNDI名を持つJMSコネクション・ファクトリおよび宛先を移入します。

  4. 最後に、JMSモジュールのターゲットをドメイン内の適切なWebLogic JMSサーバーに設定します。

詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JMSの構成と管理』を参照してください。

5.3.3 Oracle WebLogic Server上でのOC4JリモートJMSリソースの構成

OC4Jでは、JMSコネクタの構成処理の一環として、WebSphereMQ、Tibco、SonicMQなどのサード・パーティのJMSプロバイダ用のリモート宛先とコネクション・ファクトリを構成します。

Oracle WebLogic Serverの場合、リモート宛先へのアクセスはWebLogic Server外部サーバーのリソースを使用して行うため、外部JMSプロバイダとWebLogic Serverを統合できます。この外部サーバー・リソースは、ドメインのJNDIツリーと、JMS宛先およびコネクション・ファクトリの外部リモートJNDI名とのマッピングを提供します。

OC4Jの外部JMSプロバイダ構成をOracle WebLogic Serverドメインにアップグレードするには、外部サーバーを含むJMSモジュールを作成します。次に、ドメインからのアクセスが必要なリモート宛先のプロキシとして動作できるように、一連の外部コネクション・ファクトリおよび外部宛先を作成します。

詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JMSの構成と管理』のサード・パーティのJMSプロバイダにアクセスするための外部サーバー・リソースの構成に関する項を参照してください。

5.3.4 Oracle WebLogic Server上での共有ライブラリおよびクラスロードの使用

Oracle WebLogic Serverにアップグレードする際は、OC4Jソース環境で使用しているクラスロード構成に類似したクラスロード構成を使用するOracle WebLogic Serverターゲット環境を構築できます。

ただし、OC4JとOracle WebLogic Serverのクラスロード・モデルには違いがあるため、Oracle WebLogic Serverアプリケーションのクラスロードをよく理解してから、ターゲットのOracle WebLogic Server構成を設定することが重要です。

表5-1に、OC4J環境のクラスロード構成を使用していたアプリケーション開発者が、Oracle WebLogic Serverで利用できるオプションの概要を示します。この表には、OC4Jでクラスをアプリケーションから使用できるようにする主な方法と、WebLogic Server環境で同じ結果が得られるようにするための最も類似した方法について、その概略が対応して示されています。

詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverアプリケーションの開発』の共有Java EEライブラリおよびオプション・パッケージの作成に関する項を参照してください。

表5-1 OC4JおよびOracle WebLogic Serverのクラスロード・モデルの比較

OC4Jでの方法 Oracle WebLogic Serverでの同等な方法

クラスは、デプロイメント・ディスクリプタのOracle固有の<library>要素によって、アプリケーションのクラスローダーで使用できるようになります。

クラス・ファイルまたはJARファイルをアプリケーションのAPP-INF/classesまたはAPP-INF/libディレクトリにそれぞれ追加します。

Webアプリケーションでは、クラス・ファイルまたはJARファイルをアプリケーションのWEB-INF/classesまたはWEB-INFディレクトリにそれぞれ追加します。

クラスは、OC4J共有ライブラリとして特定のアプリケーションに公開されます。

JARファイルをOracle WebLogic ServerインスタンスまたはクラスタにWebLogic Server共有ライブラリとしてデプロイします。

OC4JとWebLogicでは、共有ライブラリの概念に重要な違いがあります。

  • まず、WebLogic Server共有ライブラリは、そのライブラリを使用するアプリケーションから参照される必要がありますが、デプロイされたすべてのアプリケーションに対して、共有ライブラリの使用を強制する方法はありません。(これをOracle WebLogic Serverドメインで実現する方法については、次の説明を参照してください。)

  • 次に、この参照処理では、OC4Jの場合のように共有ライブラリが(システム・クラスローダーの子として)専用のクラスローダー内で使用可能になるのではなく、基本的に共有ライブラリの内容がアプリケーションのクラスローダーのクラスパスにエクスポートされます。

  • 最後に、WebLogic Server共有ライブラリは、EAR、WARまたはJARファイルにすることが可能で、アプリケーション内に含むスコープは、そのアーカイブを参照するデプロイメント・ディスクリプタ(weblogic-application.xmlまたはweblogic.xml)のスコープによって制御されます。

クラスは、Oracleホームにあるデフォルト・アプリケーションのapplication.xml内のクラスを参照するか、ORACLE_HOME/applibディレクトリにJARファイルをドロップすることで、すべてのOC4Jインスタンス上のすべてのアプリケーションに公開されます。

ドメイン・ディレクトリの/libサブディレクトリにJARファイルを配置します。これによって、JARファイルのクラスは、ドメイン内のWebLogic Serverインスタンスで実行するすべてのアプリケーションで(別のシステム・レベルのクラスローダー内から)使用できるようになります。

クラスは、OC4Jインスタンスのクラスパスに追加され、システム・クラスローダーを介してサーバー・インスタンス全体で使用できるようになります。

サーバーの起動前にPOST_CLASSPATHまたはPRE_CLASSPATHのいずれかの環境変数が設定されるように、Oracle WebLogic Serverインスタンスを構成します。


5.3.5 起動クラスと停止クラスの構成

ソースのOC4J環境内に起動クラスまたは停止クラスが構成されている場合は、Oracle WebLogic Serverの一連の起動クラスまたは停止クラスに変換してください。次に、その各クラスをターゲットのOracle WebLogic Serverドメイン内で構成し、関連付けられているソース環境のOC4Jインスタンスに対応するOracle WebLogic Serverインスタンスをターゲットに設定する必要があります。Oracle WebLogic Serverの起動クラスおよび停止クラスは、OC4Jの起動クラスおよび停止クラスとは異なり、特定のインタフェースは必要ありません。また、デプロイメント前とデプロイメント後のメソッドも用意されていません。かわりに、クラスの標準のmain()メソッドにユーザーがカスタム・ロジックを実装します。

WebLogic Serverでは、このロジックをデプロイメント前とデプロイメント後に実行できます。その機能は、構成パラメータによって提供されますが、起動クラスまたは停止クラスがあるドメインを構成する場合には、その動作を行うように設定しておく必要があります。

したがって、OC4Jの起動クラスまたは停止クラスを変換するには、WebLogic Serverの起動クラスおよび停止クラスを2つ作成することが必要な場合があります。

  • その1つには、元のクラスのpredeploy(またはpreUndeploy)メソッドのコードを入れます。

  • もう1つには、postdeploy(またはpostUndeploy)メソッドのコードを入れます。

事前構成済のパラメータをOracle WebLogic Serverの起動クラスまたは停止クラスのmain()メソッドに渡すことはできますが、JNDIコンテキストおよび構成ハッシュテーブル・パラメータをOC4Jの起動クラスに渡す方法で、Oracle WebLogic Serverの起動クラスから引数にアクセスすることはできません。

これらのパラメータを起動クラス内のカスタム・ロジックで使用する場合は、JNDIコンテキストを最初から取得して、Oracle WebLogic Server JMXインタフェースでサーバー構成にアクセスするようにロジックを変更する必要があります。

詳細は、次を参照してください。

  • "『Oracle Fusion Middleware Oracle WebLogic Serverアプリケーションの開発』のアプリケーションのライフ・サイクル・イベントのプログラミングに関する項

  • Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・オンライン・ヘルプの起動クラスの構成に関する説明および停止クラスの構成に関する説明

5.3.6 Oracle WebLogic Server上でのセキュリティの構成

アプリケーションのセキュリティ要件をサポートするには、OC4Jのセキュリティ機能をOracle WebLogic Serverの同等なセキュリティ機能にマップする必要があります。

表5-2に、OC4Jの特定のセキュリティ構成をWebLogic Server環境にマップする際の対応を示します。

表5-2 OC4JおよびOracle WebLogic Serverのセキュリティ機能の比較

OC4Jのセキュリティ機能 Oracle WebLogic Serverで実行するタスク 詳細情報

ユーザーとグループがsystem-jazn-data.xmlファイルに格納されています。

system-jazn-data.xmlファイルに含まれるユーザーおよびグループの情報を組込みLDAPサーバーに移動する必要があります。

"『Oracle Fusion Middleware Oracle WebLogic Serverの保護』の組込みLDAPサーバーの管理に関する項

OC4Jは、外部のLDAPプロバイダを使用するように構成されています。

OC4Jで使用していたのと同じLDAPサーバーでOracle WebLogic Serverドメインを構成します。

"『Oracle Fusion Middleware Oracle WebLogic Serverの保護』のLDAP認証プロバイダの構成に関する項

ユーザーの認証がデータベースに基づいて行われます。

RDBMS認証プロバイダ(次の3種類のいずれか)を構成します。

  • SQLオーセンティケータ

  • 読取り専用SQLオーセンティケータ

  • カスタムRDBMSオーセンティケータ

"『Oracle Fusion Middleware Oracle WebLogic Serverの保護』のRDBMS認証プロバイダの構成に関する項

OC4J環境は、複数のOC4Jサーバー・インスタンス間でのJavaシングル・サインオンまたはサブジェクトの伝播を使用して構成されています。

WebLogic Serverのシングル・サインオンとサブジェクトの伝播は、ドメイン内の全体のサーバーおよびクラスタで自動的に行われます。したがって、構成処理は特に必要ありません。

該当なし

OC4J環境は、カスタムJAASログイン・モジュールを使用して構成されています。

ターゲット・ドメイン内にOracle WebLogic Server認証プロバイダ(デフォルトのプロバイダまたはJAASログイン・モジュール機能をラップするカスタム・プロバイダのいずれか)を作成します。

"『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のJavaSEアプリケーションでサポートされるログイン・モジュールの説明

"『Oracle Fusion Middleware Oracle WebLogic Serverの保護』の認証プロバイダの構成に関する項

OC4J環境は、Oracle Access Managerを使用して構成されています。

Oracle Access Managerを使用するようにOracle WebLogic Serverドメインを構成します。

『Oracle Access Manager統合ガイド』のWebLogic SSPIに対するセキュリティ・プロバイダの統合に関する項(このマニュアルは、Oracle Technology Network (OTN)のOracle Identity Management 10g(10.1.4)のIdentity Managementインスタンス・ドキュメント・ライブラリにあります)

OC4Jサーバー・インスタンスは、SSL暗号化を使用して構成されています。

SSLを使用するようにOracle WebLogic Serverドメインを構成します。

"『Oracle Fusion Middleware Oracle WebLogic Serverの保護』のSSLの構成に関する項

OC4J環境では、Oracle Walletを使用してセキュリティ・キーを格納します。

セキュリティ・キーをWebLogic ServerドメインのJKSキー・ストアに格納します。

"『Oracle Fusion Middleware Oracle WebLogic Serverの保護』のIDおよび信頼の構成に関する項


5.3.7Oracle WebLogic Server上でのロギングの構成

WebLogicロギング・サービスには包括的な一連のロギング機能が用意されており、これはOC4Jと同等な機能を持っています。OC4Jと同様に、Oracle Diagnostics Logging(ODL)フレームワークは、Oracle Java Required Files(JRF)ドメイン・テンプレートを使用して、Oracle WebLogic Serverに統合することができます。

詳細は、5.1.4項「Java Required Files(JRF)ドメイン・テンプレートの使用」を参照してください。

このため、アプリケーションでODLフレームワークを使用してロギングを行っている場合は、Oracle WebLogic Serverにデプロイするときに変更を加える必要がありません。JRF ODLをOracle WebLogic Serverに統合すると、次のようになります。

  • ODLログ・メッセージは、次に示すようにファイル・システム上の既知の場所に保存された別のログ・ファイルに送信されます。

    domain_directory/servers/server_name/logs/server_name-diagnostic.log

  • 重要なメッセージ(エラー)は、ODLとWebLogicドメイン・ログ・ファイルの両方に二重に記録されます。

  • ODLのログの問合せおよびJMX MBeanの構成は、ドメインのWebLogic管理サーバーで実行できます。

詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverログ・ファイルの構成とログ・メッセージのフィルタ処理』を参照してください。

5.4 タスク4: Oracle WebLogic Serverへのアプリケーションの再デプロイ

アプリケーションが正常にコンパイルされたら、前の手順でインストールおよび構成したOracle WebLogic Server環境にそのアプリケーションをデプロイできます。

次に示す一般的なツールを使用して、Java EEアプリケーションを再デプロイできます。

詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverへのアプリケーションのデプロイ』を参照してください。

5.5 タスク5: 再デプロイしたアプリケーションの確認

Java EEアプリケーションをOracle WebLogic Serverにデプロイした後は、次の手順を実行してアプリケーションを確認できます。

アプリケーションに問題が見つかった場合は、ドメイン・ログ・ファイルを確認して問題を診断します。詳細は、Oracle WebLogic Serverドキュメント・ライブラリのログ・ファイルの構成とログ・メッセージのフィルタ処理に関するドキュメントを参照してください。