| Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド 11gリリース1 (11.1.1.7.0) B52028-05 |
|
 前 |
 次 |
| Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド 11gリリース1 (11.1.1.7.0) B52028-05 |
|
前 |
次 |
この章では、ターゲット・アプリケーション・サーバーにADFアプリケーションをデプロイする方法を説明します。デプロイメント・プロファイルを作成する方法、デプロイメント・ディスクリプタを作成する方法、およびADFランタイム・ライブラリをロードする方法も説明します。アプリケーションを統合WebLogic Serverを使用してJDeveloperで実行する手順およびスタンドアロンOracle WebLogic ServerまたはIBM WebSphere Application Serverにデプロイする手順についても説明します。
この章の内容は次のとおりです。
デプロイは、アプリケーション・ファイルをアーカイブ・ファイルとしてパッケージ化し、ターゲット・アプリケーション・サーバーに転送するプロセスです。JDeveloperを使用して、ADFアプリケーションをアプリケーション・サーバー(Oracle WebLogic ServerやIBM WebSphere Application Serverなど)に直接デプロイすることも、または間接的に、つまりアーカイブ・ファイルをデプロイメント・ターゲットにしてまずそれにデプロイし、そのアーカイブ・ファイルを後からターゲット・サーバーにインストールすることもできます。アプリケーション開発の際には、JDeveloperを使用して、統合WebLogic Serverでアプリケーションを実行することもできます。JDeveloperは、サーバー・クラスタへのデプロイをサポートしています。JDeveloperを使用して、クラスタ内の個々の管理対象サーバーにデプロイすることはできません。
図36-1に、デプロイ処理全体を説明したフロー・ダイアグラムを示します。ADFランタイムをインストールしてターゲット・アプリケーション・サーバーをデプロイ用に準備する手順は、『Oracle Fusion Middleware Oracle Application Development Framework管理者ガイド』で説明されています。
次のダイアグラムには、クリック可能なリンクが含まれています。
|
注意: 通常、JDeveloperは開発やテストの目的でアプリケーションをデプロイする場合に使用します。ADFアプリケーションを本番用にデプロイする場合は、Enterprise Managerまたはスクリプトを使用して、本番レベルのアプリケーション・サーバーにデプロイできます。 後期テスト環境や本番環境へのデプロイの詳細は、Oracle Fusion Middleware Oracle Application Development Framework管理者ガイドを参照してください。 |
ADF Java EEアプリケーションは、標準化されたモジュール型コンポーネントに基づいており、次のアプリケーション・サーバーにデプロイできます。
Oracle WebLogic Server
Oracle WebLogic Serverは、そうしたモジュール用のサービス一式を備えており、細かいアプリケーション動作の多くを自動的に処理するため、プログラミングは必要ありません。JDeveloperと互換性のあるOracle WebLogic Serverのバージョンについては、認定情報のWebサイト(http://www.oracle.com/technetwork/developer-tools/jdev/documentation/index.html)を参照してください。
IBM WebSphereアプリケーション・サーバー
互換性のあるIBM WebSphereのバージョンについては、Oracle Fusion Middlewareサードパーティ・アプリケーション・サーバー・ガイドを参照してください。
Fusion Webアプリケーションのデプロイは、標準的なJava EEアプリケーションのデプロイとは多少異なります。ADF Facesコンポーネントを含むJSFアプリケーションには、次の追加デプロイ要件があります。
ADF Facesには、SunのJSF Reference Implementation 1.2およびMyFaces 1.0.8(またはそれ以降)が必要です。
JDeveloperを使用して、次の作業を実行できます。
統合WebLogic Serverでのアプリケーションの実行
統合WebLogic Serverを使用してアプリケーションを実行およびデバッグし、その後スタンドアロンのWebLogic ServerまたはWebSphereにデプロイできます。
統合IBM WebSphere Application Serverは、このリリースではサポートされていません。
スタンドアロン・アプリケーション・サーバーへの直接デプロイ
アプリケーションをスタンドアロン・アプリケーション・サーバーに直接デプロイするには、サーバーへの接続を作成し、そのサーバーの名前をデプロイメント・ターゲットとして選択します。
アーカイブ・ファイルへのデプロイ
デプロイメント・ターゲットとしてEARファイルを選択することによって、間接的にアプリケーションをデプロイすることができます。アーカイブ・ファイルは、ターゲット・アプリケーション・サーバーに後でインストールできます。
Fusion Order DemoアプリケーションのStoreFrontモジュールに、Fusion Webアプリケーション・テクノロジ・スタックを使用してトランザクション・ベースのWebアプリケーションを作成する方法が示されています。Fusion Order DemoアプリケーションのStoreFrontモジュールは、統合WebLogic Serverを使用してJDeveloperで実行できます。Fusion Order DemoモジュールをJDeveloperで実行することはできません。Fusion Order DemoアプリケーションをSOA対応のOracle WebLogic Serverにデプロイする必要があります。StoreFrontモジュールとFusion Order Demoアプリケーションの詳細は、2.3項「Fusion Order DemoアプリケーションStoreFrontモジュールの実行」を参照してください。
JDeveloperでアプリケーションを開発していて、統合WebLogic Serverでアプリケーションを実行する場合、Oracle WebLogic Serverに直接、またはアーカイブ・ファイルにデプロイするために必要なタスクを実行する必要はありません。JDeveloperには統合WebLogic Serverへのデフォルトの接続があるため、デプロイメント・プロファイルやデプロイメント・ディスクリプタは不要です。統合WebLogic Serverには、ADFアプリケーションの実行に必要なADFライブラリを含む事前構成済ドメイン、および-Djps.app.credential.overwrite.allowed=trueの設定が用意されています。JDeveloperのメイン・メニューから「実行」を選択すれば、アプリケーションを実行できます。
第31章「ADFコンポーネントのテストとデバッグ」で説明した機能を使用して、アプリケーションをデバッグできます。
通常、スタンドアロン・サーバーにデプロイするためには、統合WebLogic Serverでアプリケーションを実行してテストと開発を行います。その後、アプリケーションをテスト対象のOracle WebLogic Server(開発モード)やIBM WebSphere Application Serverにデプロイして本番環境をさらに厳密にシミュレートし、アプリケーションのテストをさらに実施できます。
一般にJDeveloperでは、次の作業を行って、デプロイに向けてアプリケーションまたはプロジェクトを準備します。
ターゲット・アプリケーション・サーバーへの接続の作成
デプロイメント・プロファイルを作成(必要な場合)
デプロイメント・ディスクリプタを作成(必要な場合、およびアプリケーション・サーバーに固有の場合)
application.xmlとweb.xmlを更新してアプリケーションとの互換性を確保(必要な場合)
web.xmlでアプリケーションをReal User Experience Insight (RUEI)に対して有効化(希望する場合)
アプリケーションレベルのセキュリティ・ポリシー・データをドメインレベルのセキュリティ・ポリシー・ストアに移行
Oracle Single Sign-On (Oracle SSO)を使用してWebアプリケーションを実行する場合は、ドメインのjps-config.xmlファイルでOracle SSOのサービスおよびプロパティを構成
アプリケーション・サーバーがすでにインストールされている必要があります。Oracle WebLogic Serverの場合は、Oracle 11g InstallerまたはOracle Fusion Middleware 11g Application Developer Installerを使用してインストールできます。他のアプリケーション・サーバーについては、対象アプリケーション・サーバーのドキュメントの説明に従ってサーバーを取得し、インストールしてください。
また、ADFアプリケーションのデプロイに向けてアプリケーション・サーバーを準備する必要もあります。詳細は、『Oracle Fusion Middleware Oracle Application Development Framework管理者ガイド』のデプロイに向けたスタンドアロン・アプリケーション・サーバーの準備に関する項を参照してください。
アプリケーション・サーバー・インストール先にADFランタイムをインストール:
WebLogic Serverの場合
Oracle 11g Installer for JDeveloperを使用して、Oracle WebLogic ServerをJDeveloperとともにインストールした場合、ADFランタイムはすでにインストールされています。
ADFランタイムがインストールされていない場合に、Oracle Enterprise Managerを使用してスタンドアロンのADFアプリケーション(Oracle SOA SuiteやOracle WebCenter Portalのコンポーネントを使用しないアプリケーション)を管理するには、Oracle Fusion Middleware 11g Application Developer Installerを使用します。このインストーラでは、必要なOracle Enterprise ManagerコンポーネントがOracle WebLogicのインストール先にインストールされます。
ADFランタイムがインストールされておらず、Enterprise Managerをインストールする必要がない場合は、Oracle 11g Installer for JDeveloperを使用します。
WebSphereの場合
Oracle Fusion Middleware 11g Application Developer Installerを使用して、ADFランタイムおよびOracle Enterprise Managerの必要なコンポーネントをWebSphereのインストール先にインストールします。WebSphereのインストールの詳細は、Oracle Fusion Middlewareサードパーティ・アプリケーション・サーバー・ガイドを参照してください。
ADFランタイムを使用して、Oracle WebLogic ServerドメインまたはWebSphereセルをADF互換に拡張
WebLogicの場合は、必要に応じて、Oracle WebLogic Server資格証明ストアの上書きを設定(-Djps.app.credential.overwrite.allowed=true設定)
データ・ソースへの接続を必要とするアプリケーションのためのグローバルなJDBCデータ・ソースの作成
アプリケーションとアプリケーション・サーバーの準備が完了したら、次の作業を行うことができます。
JDeveloperを使用する作業:
デプロイメント・プロファイルとアプリケーション・サーバー接続を使用して、アプリケーション・サーバーに直接デプロイします。
デプロイメント・プロファイルを使用して、EARファイルにデプロイします。ADFアプリケーションの場合、WARファイルとMARファイルはEARファイルの一部としてのみデプロイできます。
Enterprise Manager、スクリプト、またはアプリケーションの管理ツールを使用して、JDeveloperで作成したEARファイルをデプロイします。詳細は、Oracle Fusion Middleware Oracle Application Development Framework管理者ガイドを参照してください。
JDeveloperは、統合WebLogic Serverとともにインストールされますが、この統合WebLogic Serverをアプリケーションのテストと開発に使用できます。開発目的では、統合WebLogic Serverで十分なことがほとんどです。アプリケーションをテストする準備が整ったら、実行ターゲットを選び、メイン・メニューから「実行」コマンドを選択します。
|
注意: アプリケーションを統合WebLogic Serverで初めて実行する際、「デフォルト・ドメインの構成」ダイアログが表示され、新しいドメインの管理者パスワードを定義する必要があります。 |
アプリケーション・ターゲットを実行すると、プロジェクトとワークスペースのアーティファクトに基づいて、デプロイするJava EEモジュールのタイプが自動的に検出されます。次に、アプリケーションを統合WebLogic Serverにデプロイするためのメモリー内デプロイメント・プロファイルが作成されます。プロジェクトとアプリケーション・ワークスペースのファイルは、展開EARディレクトリ構造にコピーされます。このファイル構造は、アプリケーションをEARファイルにデプロイする場合のEARファイル構造を忠実に模したものです。続いて、標準のデプロイ手順に従って、展開EARファイルが統合WebLogic Serverに登録およびデプロイされます。展開EAR方式を取ることで、実際のEARファイルのパッケージ化とパッケージ化解除によって生じるパフォーマンス・オーバーヘッドが軽減されます。
要約すれば、実行ターゲットを選択して統合WebLogic Serverでアプリケーションを実行すると、JDeveloperによって次のことが行われます。
プロジェクトとアプリケーションのアーティファクトに基づいて、デプロイするJava EEモジュールのタイプを検出
メモリー内にデプロイメント・プロファイルを作成
プロジェクトとアプリケーションのファイルを、アプリケーションの展開EARファイルをシミュレートしたファイル構造を持つ作業ディレクトリにコピー
模擬EARを統合WebLogic Serverに登録およびデプロイするためのデプロイ・タスクを実行
アイデンティティ、資格証明およびポリシーを自動的に移行
後で、スタンドアロンのWebLogic Serverインスタンスにアプリケーションをデプロイする予定がある場合は、このセキュリティ情報の移行が必要になります。詳細は、36.3.4項「ADFセキュリティを有効にしてアプリケーションをデプロイする方法」を参照してください。
|
注意: 統合WebLogic Serverでアプリケーションを実行する際、アプリケーションに対して作成されたデプロイメント・プロファイルは無視されます。 |
アプリケーションは、統合WebLogic Serverの基本ドメインで実行されます。この基本ドメインは、スタンドアロンのWebLogic Serverインスタンスの基本ドメインと同じ構成になっています。つまり、この基本ドメインは、Oracle Fusion Middleware構成ウィザードを使用して、スタンドアロンのWebLogic Serverインスタンスにデフォルト・オプションで基本ドメインを作成した場合と同一です。
JDeveloperでは、JDeveloperテクノロジ拡張に基づいて、この基本ドメインが必要なドメイン拡張テンプレートで拡張されます。たとえば、JDeveloper Studioをインストールした場合、統合WebLogic Server環境がADFランタイム・テンプレート(JRF Fusion Middlewareランタイム・ドメイン拡張テンプレート)で自動的に構成されます。
統合WebLogic Serverのデフォルト・ドメインを明示的に作成することもできます。このデフォルト・ドメインを使用して、アプリケーションを実行およびテストできます。アプリケーション・サーバー・ナビゲータを開き、「IntegratedWebLogicServer」を右クリックして、「デフォルト・ドメインの作成」を選択します。
アプリケーションを統合WebLogic Serverで実行して、テストすることができます。ブレークポイントを設定して、ADF宣言デバッガでアプリケーションを実行することも可能です。
統合WebLogic Serverでアプリケーションを実行するには:
アプリケーション・ナビゲータで、プロジェクト、無制限タスク・フロー、JSFページ、ファイルのいずれかを実行ターゲットとして選択します。
実行ターゲットを右クリックして、「実行」または「デバッグ」を選択します。
アプリケーションを初めて実行し、新しいドメインを統合WebLogic Serverで開始する際に、「デフォルト・ドメインの構成」ダイアログが表示されます。ダイアログを使用して新しいドメインの管理者パスワードを定義します。入力するパスワードは8文字以上で、数字が含まれている必要があります。
アプリケーションが統合WebLogic Serverで実行されている場合、メタデータ・アーカイブ(MAR)プロファイルそのものはリポジトリにデプロイされませんが、MARに含まれるメタデータ情報を反映した模擬MDSリポジトリがアプリケーション用に構成されます。このメタデータ情報はシミュレートされ、ソース・コントロール内のこの場所を基準にアプリケーションが実行されます。
アプリケーションによって作成されたカスタマイズ内容やドキュメントのうち、他のMDSリポジトリに格納するよう構成されていないものは、この模擬MDSリポジトリのディレクトリに書き込まれます。たとえば、オブジェクトをカスタマイズした場合、その内容は模擬MDSリポジトリに書き込まれます。新しいメタデータ・オブジェクトを作成するコードを実行した場合、この新しいメタデータ・オブジェクトも模擬MDSリポジトリの同じ場所に書き込まれます。このディレクトリは、デフォルトの場所(ORACLE_HOME\jdeveloper\systemXX.XX\o.mds.dt\adrs\Application\AutoGeneratedMar\mds_adrs_writedir)をそのまま使用することも、別のディレクトリに設定することも可能です。アプリケーションが複数回実行される間、このディレクトリをずっと保持するか、それとも各実行の前に削除するかも選択できます。
ワークスペースに異なるワーキング・セットがある場合、ワーキング・セットとその依存オブジェクトで定義されたプロジェクトのメタデータのみがMARに組み込まれます。アプリケーション・ナビゲータでプロジェクトを右クリックして「プロジェクト・プロパティ」を選択し、「依存性」を選択すると、プロジェクトの依存性の表示または変更が行えます。たとえば、アプリケーションに複数のプロジェクトがあるが、workingsetAはviewcontroller2およびviewcontroller5として定義され、viewcontroller5はmodelproject1に依存しているとします。workingsetAを実行またはデバッグすると、viewcontroller2、viewcontroller5およびmodelproject1のメタデータのみがデプロイ用のMARに組み込まれます。
作業を始める前に、次のようにします。
MARプロファイルを用意しておく必要があります。これは、JDeveloperで自動的に生成されたものでも、ユーザーが手動で生成したものでもかまいません。
MARプロファイルを統合WebLogic Serverにデプロイするには:
アプリケーション・ナビゲータで、アプリケーションを右クリックし、「アプリケーションのプロパティ」を選択します。
「アプリケーションのプロパティ」ダイアログで、「実行」を展開して「MDS」を選択します。
「MDSの実行」ページで次の作業を行います。
「MARプロファイル」ドロップダウン・リストからMARプロファイルを選択します。
模擬MDSリポジトリの場所をカスタマイズする場合は、「オーバーライド場所」にディレクトリ・パスを入力します。
「ディレクトリ・コンテンツ」オプションを選択します。アプリケーションが複数回実行される間、カスタマイズ内容を維持するか、それとも各実行の前にカスタマイズ内容を削除するかを選択できます。
「MARプロファイル」ドロップダウン・リストからMARプロファイルを選択します。図36-2は、MARプロファイルとして「Demometadata1」を選択したところを示しています。
ADFアプリケーションをスタンドアロン・アプリケーション・サーバーにデプロイする前に、JDeveloperで必須のタスクを実行し、デプロイに向けてアプリケーションを準備する必要があります。
図36-3に、アプリケーションをデプロイ用に準備する場合のプロセス・フローを示します。『Oracle Fusion Middleware Oracle Application Development Framework管理者ガイド』で説明されているようにアプリケーションが準備され、アプリケーション・サーバーが準備された後、36.4項「アプリケーションのデプロイ」の説明に従ってアプリケーションをデプロイできます。
次のダイアグラムには、クリック可能なリンクが含まれています。
JDeveloperアプリケーション・サーバー接続を介して、アプリケーション・サーバーにアプリケーションをデプロイできます。
アプリケーションにMDSを使用したカスタマイズが加えられている場合は、MDSリポジトリをアプリケーション・サーバーに登録してください。
WebLogicの場合: MDSをWebLogicドメインに登録
WebSphereでのMDSの登録の詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。
WebSphereの場合: MDSをWebSphereセルに登録
WebSphereでのMDSの登録の詳細は、Oracle Fusion Middlewareサードパーティ・アプリケーション・サーバー・ガイドを参照してください。
アプリケーション・サーバーへの接続の作成方法:
アプリケーション・サーバー接続ウィザードを起動します。
次のいずれかを実行します。
アプリケーション・サーバー・ナビゲータで、「アプリケーション・サーバー」を右クリックして、「アプリケーション・サーバー接続の作成」を選択します。
「新規ギャラリ」の「General」を展開し、「接続」→「アプリケーション・サーバー接続」の順に選択し、「OK」をクリックします。
リソース・パレットで、「新規」→「接続の作成」→「アプリケーション・サーバー」を選択します。
「AppServer接続の作成」ダイアログの「使用方法」ページで、「スタンドアロン・サーバー」を選択します。
「名前とタイプ」ページで、接続名を入力します。
「接続タイプ」ドロップダウン・リストで、次を選択します。
Oracle WebLogic Serverへの接続を作成する場合は「WebLogic 10.3」
IBM WebSphere Serverへの接続を作成する場合は「WebSphere Server 7.x」
「次へ」をクリックします。
「認証」ページで、アプリケーション・サーバーへのアクセスを認可された管理ユーザーのユーザー名とパスワードを入力します。
「次へ」をクリックします。
「構成」ページで、次のサーバー情報を入力します。
WebLogicの場合:
Oracle WebLogicホスト名は、アプリケーション(.jar、.war、.ear)がデプロイされるTCP/IP DNSを含む、WebLogic Serverインスタンスの名前です。
「ポート」フィールドに、アプリケーション(.jar、.war、.ear)がデプロイされるOracle WebLogic Serverインスタンスのポート番号を入力します。
ポートを指定しない場合、ポート番号はデフォルトの7001になります。
「SSLポート」フィールドに、アプリケーション(.jar、.war、.ear)がデプロイされるOracle WebLogic ServerインスタンスのSSLポート番号を入力します。
SSLポートの指定はオプションです。デプロイメント時に確実にセキュア接続にする場合にのみ必要です。
ポートを指定しない場合、SSLポート番号はデフォルトの7002になります。
SSLポートを使用してOracle WebLogic Serverインスタンスに接続するために、「常にSSLを使用」を選択します。
オプションで、Oracle WebLogic Serverが管理権限のないサーバー・ノードを名前で識別するように構成されている場合のみ、WebLogicドメインを入力します。
WebSphereの場合:
「ホスト名」フィールドに、Java EEアプリケーション(.jar、.war、.ear)がデプロイされる、TCP/IP DNSを含むWebSphereサーバーの名前を入力します。名前を入力しない場合は、デフォルトのlocalhostになります。
「SOAPコネクタのポート」フィールドに、ポート番号を入力します。このホスト名とポートが、デプロイ用にサーバーへの接続に使用されます。デフォルトのSOAP接続ポートは8879です。
「サーバー名」フィールドに、この接続のターゲット・アプリケーション・サーバーに割り当てられた名前を入力します。
「ターゲット・ノード」フィールドに、この接続のターゲット・ノード名を入力します。ノードとは、管理対象サーバーのグループです。デフォルトはmachineNode01で、この場合のmachineはノードが常駐するマシンの名前です。
「ターゲット・セル」フィールドに、この接続のターゲット・セルの名前を入力します。セルとは、ランタイム・コンポーネントをホストするプロセスのグループです。デフォルトはmachineNode01Cellで、この場合のmachineはノードが常駐するマシンの名前です。
「WS管理スクリプト・ファイルの場所」フィールドに、IBM WebSphereアプリケーション・サーバー接続のシステム・ログイン構成を定義するために使用するwsadminスクリプト・ファイルの場所を入力するか、参照して指定します。ORACLE_HOME/oracle_common/common/binディレクトリにあるwsadminファイルは正しいバージョンではないため、使用できません。デフォルトの場所は、Unix/Linuxの場合はwebsphere-home/bin/wsadmin.sh、Windowsの場合はwebsphere-home/bin/wsadmin.batです。
「次へ」をクリックします。
WebSphereを選択した場合は、「JMX」ページが表示されます。「JMX」ページで、JMXの情報を入力します(オプション)。
|
注意: JMXの構成はオプションで、WebSphere Application Serverへの接続には必要ありません。 |
「この接続のJMXの有効化」を選択してJMXを有効にします。
「RMIポート」フィールドに、WebSphereのRMI接続ポートのポート番号を入力します。デフォルトは2809です。
「WebSphereランタイムJARの場所」フィールドに、WebSphereランタイムJARの場所を入力するか、参照して指定します。
「WebSphereプロパティの場所(セキュアなMBeanアクセス用)」フィールドに、セキュリティ構成および有効なMBeanのプロパティを含むファイルの場所を入力するか、参照して指定します。このフィールドはオプションです。
「次へ」をクリックします。
「SSL署名者交換」ダイアログが表示される場合は、「Y」をクリックします。
テスト・ページで、「接続のテスト」をクリックして、接続をテストします。
JDeveloperにより、数種類の接続テストが実行されます。アプリケーションをデプロイできるためには、JSR-88テストに合格する必要があります。テストに不合格だった場合は、ウィザードの前のページに戻って、構成を修正します。
「終了」をクリックします。
デプロイメント・プロファイルでは、ターゲット環境にデプロイされるアーカイブにアプリケーションがパッケージ化される方法が定義されています。デプロイメント・プロファイルには、次の役割があります。
作成されるアーカイブ・ファイルのフォーマットと内容を指定します。
パッケージ対象となるソース・ファイル、デプロイメント・ディスクリプタ、およびその他の補助ファイルをリストします。
作成されるアーカイブ・ファイルのタイプおよび名前を記述します。
依存情報、プラットフォーム固有の指示、およびその他の情報を示します。
アプリケーションにデプロイするWebビュー・コントローラ・プロジェクトごとに、WARデプロイメント・プロファイルが必要です。シード・カスタマイズをパッケージ化する場合や、ベース・メタデータをMDSリポジトリに保存する場合は、アプリケーションレベルのメタデータ・アーカイブ(MAR)・デプロイメント・プロファイルも必要になります。シード・カスタマイズの詳細は、第34章「MDSによるアプリケーションのカスタマイズ」を参照してください。アプリケーションにカスタマイズ・クラスがある場合は、そのクラスを格納するJARファイルが必要であり、EARファイルの作成時にそのJARを追加する必要があります。さらに、アプリケーションレベルのEARデプロイメント・プロファイルも必要です。WARプロファイルやMARプロファイル、カスタマイズ・クラスのJARファイルなど、その中に組み込むプロジェクトをリストから選択する必要があります。アプリケーションがデプロイされるとき、EARファイルは、デプロイメント・プロファイルで選択されたすべてのプロジェクトを組み込みます。
|
注意: Fusion Web Application (ADF)テンプレートを使用してプロジェクトまたはアプリケーションを作成する場合、JDeveloperによりデフォルトのWAR、EAR、MARおよびJARデプロイメント・プロファイルが自動的に作成されます。通常、デプロイメント・プロファイルを手動で編集または作成する必要はありません。 |
ADFアプリケーションの場合、アプリケーションはEARファイルとしてのみデプロイできます。デプロイメント・プロファイルを作成する際に、アプリケーションの一部となるWARファイルとMARファイルをEARファイルに組み込む必要があります。
|
注意: デプロイするビジネス・サービスがADFアプリケーションにある場合は、ビジネス・コンポーネント・サービス・インタフェース・デプロイメント・プロファイルを作成してデプロイする必要があります。ビジネス・サービスの詳細は、11.2.20項「Oracle WebLogic ServerへのWebサービスのデプロイ方法」を参照してください。 |
アプリケーションにカスタマイズ・クラスがある場合は、そのカスタマイズ・クラスのみを格納するJARを作成します。このJARは、EARを作成する際にEARアセンブリに追加できます。WebプロジェクトのWARプロファイルを作成する場合は、このプロファイルにカスタマイズ・クラスのJARを組み込まないようにする必要があります。
作業を始める前に、次のようにします。
プロジェクトにカスタマイズ・クラスがあることを確認します。アプリケーションにカスタマイズ・クラスがない場合、この手順を実行する必要はありません。カスタマイズ・クラスの詳細は、34.2.1項「カスタマイズ・クラスの作成方法」を参照してください。
JARにカスタマイズ・クラスを追加するには:
「アプリケーション・ナビゲータ」で、JARを作成するカスタマイズ・クラスを含むデータ・モデル・プロジェクトを右クリックし、「新規」を選択します。
「新規ギャラリ」で、「一般」を展開し、「デプロイメント・プロファイル」、「JARファイル」の順に選択して、「OK」をクリックします。
または、共有ライブラリを作成する場合は、プロファイル・タイプのリストから「共有ライブラリJARファイル」を選択し、「OK」をクリックします。
|
注意: 「カテゴリ」ツリーに「デプロイメント・プロファイル」が表示されない場合は、「すべてのテクノロジ」タブをクリックします。 |
「デプロイメント・プロファイルの作成 -- JARファイル」ダイアログで、プロジェクト・デプロイメント・プロファイルの名前(CCArchiveなど)を入力して、「OK」をクリックします。
「JARデプロイメント・プロファイルのプロパティの編集」ダイアログで、「JARオプション」を選択します。
JARファイルの場所を入力します。
「ファイル・グループ」→「プロジェクトの出力」→「フィルタ」を展開します。
「ファイル」タブで、JARファイルに追加するカスタマイズ・クラスを選択します。customization.propertiesファイルを使用する場合は、このファイルがJARファイルと同じクラス・ローダーにあることが必要です。customization.propertiesファイルを選択して、カスタマイズ・クラスとともに同じJARにパッケージ化することができます。
「OK」をクリックして、「JARデプロイメント・プロファイルのプロパティの編集」ダイアログを終了します。
「OK」を再度クリックして、プロジェクト・プロパティのダイアログを終了します。
アプリケーション・ナビゲータで、JARデプロイメント・プロファイルを含むプロジェクトを右クリックし、「デプロイ」→「deployment profile」→「JARファイルへ」を選択します。
|
注意: デプロイメント・プロファイルからJARに初めてデプロイする場合は、ウィザードで「デプロイ」→「デプロイメント・プロファイル」を選択し、「JARにデプロイ」を選択します。 |
アプリケーションにパッケージ化するWebベースのプロジェクトごとに、WARデプロイメント・プロファイルを作成する必要があります。通常、WARプロファイルには必要な依存モデル・プロジェクトが組み込まれます。
作業を始める前に、次のようにします。
Webベースのプロジェクトを作成します。Fusion Web Application (ADF)テンプレートを使用した場合は、すでにデフォルトのWARデプロイメント・ファイルが存在します。
アプリケーションのWARデプロイメント・プロファイルを作成するには:
アプリケーション・ナビゲータで、デプロイするWebプロジェクトを右クリックし、「新規」を選択します。
各WebプロジェクトのWARプロファイルを作成します。
「新規ギャラリ」で、「一般」を展開し、「デプロイメント・プロファイル」→「WARファイル」を選択して、「OK」をクリックします。
「カテゴリ」ツリーに「デプロイメント・プロファイル」が表示されない場合は、「すべてのテクノロジ」タブをクリックします。
「デプロイメント・プロファイルの作成 -- WARファイル 」ダイアログで、プロジェクト・デプロイメント・プロファイルの名前を入力して、「OK」をクリックします。
「WARデプロイメント・プロファイルのプロパティの編集」ダイアログの左ペインで項目を選択すると、右ペインにダイアログ・ページが表示されます。ダイアログのページでプロパティ値を設定して、プロファイルを構成します。
アプリケーションにカスタマイズ・クラスがある場合は、カスタマイズ・クラスを、WARからではなくEARレベルのアプリケーション・クラス・ローダーからロードする必要があります。このカスタマイズ・クラスは後でEARに追加します。
デフォルトでは、カスタマイズ・クラスはモデル・プロジェクトのWARクラス・パスに追加されます。したがって、WARごとにカスタマイズ・クラスを除外する必要があります。
カスタマイズ・クラスをアプリケーションの拡張プロジェクトで作成した場合は、ビュー・コントローラ・プロジェクトごとにWARデプロイメント・プロファイルの「ライブラリの依存性」ページで、カスタマイズ・クラスのアーカイブの選択をすべて解除してください。
カスタマイズ・クラスをアプリケーションのモデル・プロジェクトで作成した場合は、ビュー・コントローラ・プロジェクトごとにWARデプロイメント・プロファイルの「ファイル・グループ」→「WEB-INF/classes」→「フィルタ」ページで、カスタマイズ・クラスの選択をすべて解除してください。customization.propertiesファイルを使用する場合は、それも選択解除します。
Java EE Webコンテキストのルート設定を変更することもできます(左側のペインで「一般」を選択)。
デフォルトでは、「プロジェクトのJava EE Webコンテキスト・ルートを使用」が選択されている場合、関連付けられている値は、Application1-Project1-context-rootのようにプロジェクト名に設定されています。ユーザーに違う名前でアプリケーションにアクセスさせる場合は、この名前を変更する必要があります。
JAZNを使用した認証でカスタムのJAAS LoginModuleを使用している場合は、コンテキスト・ルート名によって、JAAS LoginModuleの検索に使用されるアプリケーション名も定義されます。
「OK」をクリックして、デプロイメント・プロファイル・プロパティのダイアログを終了します。
「OK」を再度クリックして、プロジェクト・プロパティのダイアログを終了します。
デプロイするすべてのWebプロジェクトに対して、手順1から7を繰り返します。
MDSリポジトリに保存するシード・カスタマイズやベース・メタデータがある場合は、MARデプロイメント・プロファイルを作成する必要があります。
adf-config.xmlファイルの<mds-config>におけるMARコンテンツのネームスペース構成は、「MARデプロイメント・プロファイルのプロパティ」ダイアログでの選択内容に基づいて生成されます。
まれなことですが、1つのエンタープライズ・アプリケーション(1つのEARにパッケージ化)に複数のWebアプリケーション・プロジェクト(複数のWARにパッケージ化)が含まれている場合があります。しかし、このようなWebアプリケーションのメタデータはすべて、単一のメタデータ・アーカイブ(MAR)にパッケージ化されます。個々のWebアプリケーションのメタデータには、グローバル(すべてのWebアプリケーションで使用可能)なものと、特定のWebアプリケーション専用のローカルなものがあります。グローバル・スコープを持つメタデータの名前が競合するのを避けるため、すべてのメタデータ・オブジェクトおよび要素に、エンタープライズ・アプリケーションを構成するWebアプリケーション・プロジェクト全体で一意の名前を付けてください。名前の競合を避け、特定のWebアプリケーションのメタデータをそのアプリケーション専用のローカル・メタデータのまま保持するには、Webアプリケーション・プロジェクトに対してweb-app-rootを定義します。web-app-rootは、Webアプリケーション・プロジェクトのadf-settings.xmlファイルの要素です。adf-settings.xmlファイルは、Webプロジェクトのpublic_htmlディレクトリの下にあるMETA-INFディレクトリに保存してください。例36-1に、サンプルのadf-settings.xmlファイルの内容を示します。
例36-1 adf-settings.xmlファイルのweb-app-root要素
<?xml version="1.0" encoding="UTF-8" ?>
<adf-settings xmlns="http://xmlns.oracle.com/adf/settings"
xmlns:wap="http://xmlns.oracle.com/adf/share/http/config">
<wap:adf-web-config xmlns="http://xmlns.oracle.com/adf/share/http/config">
<web-app-root rootName="order"/>
</wap:adf-web-config>
</adf-settings>
この例では、adf-settings.xmlファイルに、rootNameをorderとして定義するweb-app-root要素があります。エンタープライズ・アプリケーションにWebアプリケーション・プロジェクトが1つしかない場合、web-app-root要素の定義は不要です。エンタープライズ・アプリケーションにWebアプリケーション・プロジェクトが複数ある場合は、1つを除くすべてのWebアプリケーションに対してweb-app-rootを定義する必要があります。これを行わないと、デプロイは失敗します。たとえば、web-application1、web-application2およびweb-application3がある場合、名前の競合を防ぐには、これらのWebアプリケーション・プロジェクトのうち2つに対してweb-app-rootを定義する必要があります。
「プロジェクト・プロパティ」ダイアログの「ADFビュー」ページで「ユーザー・カスタマイズの有効化」オプションと「MDSを使用したセッション間」オプションを選択した場合、またはadf-config.xmlファイルにデプロイメント・ターゲット・ディレクトリを明示的に指定した場合は、自動生成MARが作成されます。
作業を始める前に、次のようにします。
MARデプロイメント・プロファイルを使用してメタデータをデプロイするために、カスタマイズ要件を考慮したMDSリポジトリを作成します。Fusion Web Application (ADF)テンプレートを使用した場合は、すでにデフォルトのMARデプロイメント・ファイルが存在します。
MARデプロイメント・プロファイルを作成するには:
アプリケーション・ナビゲータで、アプリケーションを右クリックし、「新規」を選択します。
カスタマイズ内容を組み込む場合は、MARプロファイルを作成します。
「新規ギャラリ」で、「一般」を展開し、「デプロイメント・プロファイル」→「MARファイル」を選択して、「OK」をクリックします。
「カテゴリ」ツリーに「デプロイメント・プロファイル」が表示されない場合は、「すべてのテクノロジ」タブをクリックします。
「デプロイメント・プロファイルの作成 -- MARファイル」ダイアログで、MARデプロイメント・プロファイルの名前を入力して、「OK」をクリックします。
「MARデプロイメント・プロファイルのプロパティの編集」ダイアログの左ペインで項目を選択すると、右ペインにダイアログ・ページが表示されます。
図36-4に、サンプルの「ユーザー・メタデータ」ディレクトリ・ツリーを示します。
次の重要な点に注意してください。
すべてのカスタマイズ内容を組み込む場合は、目的のディレクトリを含むファイル・グループを作成するだけで済みます。
ADFモデルとADFビューのディレクトリはデフォルトで追加されます。ADFモデルとADFビューのカスタマイズ内容をMARにパッケージ化するために必要な作業はこれだけです。ADFビューの内容はHTMLルート・ディレクトリに追加され、ADFモデルとビジネス・コンポーネントの内容はユーザー・メタデータに追加されます。
MDSリポジトリにベース・メタデータを組み込む場合は、対象となるディレクトリをダイアログで明示的に選択する必要があります。
MARに組み込むベース・ドキュメントを選択する際に、個々のパッケージも選択します。パッケージを1つ選択すると、そのパッケージの下にあるすべてのドキュメント(サブパッケージを含む)が使用されます。パッケージを選択したときに、その下の個々の項目を選択解除することはできません。
ADFモデルとADFビュー以外のファイルを組み込む場合は、目的のディレクトリを含む「ユーザー・メタデータ」の下に新しいファイル・グループを作成し、「ディレクトリ」ページで必要なコンテンツを明示的に選択する必要があります。
プロジェクトの依存ADFライブラリJARにシード・カスタマイズが含まれている場合、そのシード・カスタマイズはMARのパッケージ化中にMARに自動的に追加されます。MARプロファイルには表示されません。
ADFライブラリのカスタマイズ内容が使用側プロジェクトのコンテキストで作成された場合、そのカスタマイズ内容はMARプロファイルのダイアログにデフォルトで表示されます。
「OK」をクリックして、デプロイメント・プロファイル・プロパティのダイアログを終了します。
「OK」を再度クリックして、アプリケーション・プロパティのダイアログを終了します。
EARファイルには、アプリケーション・サーバーでアプリケーションを実行するために必要なアプリケーション・アーティファクトがすべて含まれています。EARファイルの詳細は、36.4.3項「EARファイルとパッケージ化について」を参照してください。
作業を始める前に、次のようにします。
36.3.2.1項「JARへのカスタマイズ・クラスの追加」の説明に従って、JARファイルにクラスを追加します。36.3.2.2項「WARデプロイメント・プロファイルの作成」の説明に従って、WARデプロイメント・プロファイルを作成します。
Fusion Web Application (ADF)テンプレートを使用した場合は、すでにデフォルトのEARデプロイメント・ファイルが存在します。
アプリケーションのEARデプロイメント・プロファイルを作成するには:
アプリケーション・ナビゲータで、アプリケーションを右クリックし、「新規」を選択します。
アプリケーションのEARプロファイルを作成します。
「新規ギャラリ」で、「一般」を展開し、「デプロイメント・プロファイル」→「EARファイル」を選択して、「OK」をクリックします。
「カテゴリ」ツリーにデプロイメント・プロファイルが表示されない場合、「すべてのテクノロジ」タブをクリックします。
「デプロイメント・プロファイルの作成 -- EARファイル」ダイアログで、アプリケーション・デプロイメント・プロファイルの名前を入力して、「OK」をクリックします。
「EARデプロイメント・プロファイルのプロパティの編集」ダイアログの左ペインで項目を選択すると、右ペインにダイアログ・ページが表示されます。ダイアログのページでプロパティ値を設定して、プロファイルを構成します。
次の手順を必ず実行してください。
「アプリケーション・アセンブリ」を選択し、続いて「Java EEモジュール」リストで、デプロイメントに組み込むすべてのプロジェクト・プロファイルを選択します(WARまたはMARプロファイルを含む)。
「プラットフォーム」を選択し、デプロイ先となるアプリケーション・サーバーを選択した後、「ターゲット接続」ドロップダウン・リストから、ターゲット・アプリケーション接続を選択します。
|
注意: JAZNを使用した認証でカスタムのJAAS LoginModuleを使用している場合は、コンテキスト・ルート名によって、JAAS LoginModuleの検索に使用されるアプリケーション名も定義されます。 |
アプリケーションにカスタマイズ・クラスがある場合は、そのクラスがEARレベルのアプリケーション・クラス・ローダーからロードされるように構成する必要があります。
「EARデプロイメント・プロファイルのプロパティの編集」ダイアログで、「アプリケーション・アセンブリ」を選択します。
カスタマイズ・クラスを含むJARデプロイメント・プロファイルを選択して、ダイアログの一番下にある「EARのパス」フィールドにlibを入力します。
カスタマイズ・クラスを含むJARファイルが、EARファイルのlibディレクトリに追加されます。
|
注意: アプリケーションにカスタマイズ・クラスがある場合は、カスタマイズ・クラスがWARからロードされないようにする必要があります。デフォルトでは、モデル・プロジェクトのライブラリおよびクラスパスに追加されるカスタマイズ・クラスは、WARクラス・パスにパッケージ化されます。 拡張プロジェクトで作成したカスタマイズ・クラスがWARにも重複して存在するのを避けるため、WARの「ライブラリの依存性」ページでカスタマイズ・クラスのアーカイブの選択をすべて解除してください。 カスタマイズ・クラスをコンシューミング・アプリケーションのモデル・プロジェクトで作成した場合は、WARの「ファイル・グループ」→「WEB-INF/classes」→「フィルタ」ページでカスタマイズ・クラスの選択をすべて解除します。 |
「OK」をクリックして、デプロイメント・プロファイル・プロパティのダイアログを終了します。
「OK」を再度クリックして、アプリケーション・プロパティのダイアログを終了します。
|
注意: カスタマイズ・クラスがEARクラス・パスに正しく追加されていることを検証するには、EARプロファイルをファイル・システムにデプロイします。その後、EARを調べ、カスタマイズ・クラスJARがEARクラス・パス( |
36.3.2.4項「アプリケーションレベルのEARデプロイメント・プロファイルの作成」に記載されているように、カスタマイズ・クラスをEARに追加する別の方法として、カスタマイズ・クラスを共有ライブラリとしてコンシューミング・アプリケーションに追加することもできます。
作業を始める前に、次のようにします。
カスタマイズ・クラスを含むアプリケーションをJDeveloperのデフォルトのロールで開き、36.3.2.1項「JARへのカスタマイズ・クラスの追加」に記載されている手順を使用して、作成するアーカイブのタイプとして「共有ライブラリJARファイル」を選択します。
|
注意: この手順では、Oracle Weblogic Serverにデプロイする場合の、共有ライブラリの作成および使用方法について説明します。 |
カスタマイズ・クラスの共有ライブラリを作成および使用するには:
「アプリケーション・ナビゲータ」で、カスタマイズ・クラス・プロジェクトを右クリックし、「デプロイ」→「deployment-profile」を選択します。
「デプロイ」ウィザードで、WebLogic Application Serverにデプロイを選択し、「次へ」をクリックします。
適切なアプリケーション・サーバーを選択し、「終了」をクリックします。
これにより、共有ライブラリがアプリケーション・サーバーで使用できるようになります。次に、コンシューミング・アプリケーションから共有ライブラリへの参照を追加する必要があります。
JDeveloperのデフォルトのロールで、カスタマイズするアプリケーションを開きます。
アプリケーション・ナビゲータの「アプリケーション・リソース」パネルで、weblogic-application.xmlファイルをダブルクリックして開きます。
「概要エディタ」で、「ライブラリ」タブをクリックします。
「共有ライブラリ参照」セクションで、追加アイコンをクリックします。
「共有ライブラリ参照」表に新たに作成された行の「ライブラリ名」フィールドに、デプロイしたカスタマイズ・クラスの共有ライブラリの名前を入力し、変更を保存します。
デプロイメント・プロファイルを作成したら、そのプロパティを表示および変更できます。
プロジェクトのデプロイメント・プロファイルを作成、編集、または削除するには:
アプリケーション・ナビゲータで、プロジェクトを右クリックし、「プロジェクト・プロパティ」を選択します。
「プロジェクト・プロパティ」ダイアログで、「デプロイ」をクリックします。
「デプロイメント・プロファイル」リストには、現在プロジェクトに定義されているすべてのプロファイルが表示されます。
リストから、デプロイメント・プロファイルを1つ選択します。
「編集」または「削除」をクリックして、デプロイメント・プロファイルを編集または削除します。
デプロイメント・ディスクリプタは、アプリケーションのデプロイ構成を定義するサーバー構成ファイルで、必要に応じてJava EEアプリケーションとともにデプロイされます。プロジェクトに必要なデプロイメント・ディスクリプタは、プロジェクトが使用しているテクノロジとターゲット・アプリケーション・サーバーのタイプによって異なります。デプロイメント・ディスクリプタは、ソース・ファイルとして作成および編集できるXMLファイルですが、JDeveloperは、ほとんどのディスクリプタ・タイプについて、プロパティの表示と設定に使用できるダイアログまたは概要エディタを備えています。これらのファイルを宣言的に編集できない場合、JDeveloperはその内容を編集するためにソースエディタでXMLファイルを開きます。
標準のJava EEデプロイメント・ディスクリプタ(application.xml、およびweb.xmlなど)に加えて、ターゲット・アプリケーション・サーバーに固有のデプロイメント・ディスクリプタも使用できます。たとえば、Oracle WebLogic Serverにデプロイする場合、weblogic.xml、weblogic-application.xmlおよびweblogic-ejb-jar.xmlを使用できます。
WebLogic Serverの場合は、アプリケーションのEARファイルに、adf.oracle.domainへの参照を含むweblogic-application.xmlファイルが組み込まれていること、そしてデプロイ作業とアンデプロイ作業の間にアプリケーション・リソースをクリーンアップするためのADFApplicationStateListenerが組み込まれていることを確認してください。例36-2に、サンプルのweblogic-application.xmlファイルを示します。
例36-2 サンプルのweblogic-application.xml
<weblogic-application xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.bea.com/ns/weblogic/weblogic-application.xsd"
xmlns="http://www.bea.com/ns/weblogic/weblogic-application">
<listener>
<listener-class>oracle.adf.share.weblogic.listeners.
ADFApplicationStateListener</listener-class>
</listener>
<listener>
<listener-class>oracle.mds.lcm.weblogic.WLLifecycleListener</listener-class>
</listener>
<library-ref>
<library-name>adf.oracle.domain</library-name>
</library-ref>
</weblogic-application>
Webサービスをデプロイする場合は、11.2.20項「Oracle WebLogic ServerへのWebサービスのデプロイ方法」の説明に従って、weblogic-application.xmlファイルとweb.xmlファイルを変更する必要が生じることがあります。
アプリケーションに対してReal User Experience Insight (RUEI)による監視を行えるようにするには、36.3.3.5項「Real User Experience Insightに対するアプリケーションの有効化」の説明に従って、web.xmlファイルにパラメータを追加する必要があります。
WebLogicへのデプロイ時には、アプリケーションとともにEARファイルにデプロイされるweblogic-application.xmlファイルに、アプリケーションのセキュリティ・プロパティが書き込まれます。詳細は、30.8.2項「セキュリティ・デプロイメント・オプション構成時の処理」を参照してください。
アプリケーション・サーバーはJava EE 5上で動作するため、application.xmlファイルとweb.xmlファイルを変更してアプリケーション・サーバーと互換性を持たせることが必要になる場合があります。
IBM WebSphereの場合は、デプロイメント・ディスクリプタが実行時に作成されますが、これを編集することはできません。一部の関連するディスクリプタを表36-1に示します。
表36-1 IBM WebSphereのデプロイメント・ディスクリプタ
| WebSphere | アクション |
|---|---|
|
|
|
|
|
標準のJava EEデプロイメント・ディスクリプションですが、valid-usersロール(ADFセキュリティの使用時に |
|
|
|
|
|
|
必要なデプロイメント・ディスクリプタの多くは、自動的に作成されます。必要なデプロイメント・ディスクリプタが存在しない場合や、追加のディスクリプタを作成する必要がある場合は、JDeveloperを使用して作成できます。
作業を始める前に、次のようにします。
デプロイメント・ディスクリプタがすでに生成されているかどうかを確認します。
デプロイメント・ディスクリプタの作成方法:
アプリケーション・ナビゲータで、ディスクリプタを作成するプロジェクトを右クリックし、「新規」を選択します。
「新規ギャラリ」で、「一般」を展開し、「デプロイメント・ディスクリプタ」、ディスクリプタ・タイプの順に選択して、「OK」をクリックします。
目的の項目が見つからない場合は、正しいプロジェクトが選択されていることを確認してから「すべてのテクノロジ」タブを選択するか、「検索」フィールドを使用してディスクリプタを検索します。項目が有効になっていない場合は、そのタイプのディスクリプタがプロジェクトにまだ存在しないことを確認します。1つのプロジェクトで使用できるディスクリプタのインスタンスは1つのみです。
デプロイメント・ディスクリプタの作成ウィザードが起動し、選択したデプロイメント・ディスクリプタのタイプに応じて、概要エディタまたはソース・エディタでファイルが開きます。
|
注意: EARファイルの場合は、1つのアプリケーションまたはワークスペースに同じタイプの複数のデプロイメント・ディスクリプタを作成しないでください。これらのファイルはプロジェクトに割当て可能ですが、アプリケーション・ワークスペース・スコープがあります。アプリケーションの複数のプロジェクトが同じデプロイメント・ディスクリプタを使用すると、起動されたプロジェクトに属するディスクリプタが他のディスクリプタより優先されます。この制約は、 アプリケーションレベル・ディスクリプタを作成するために最適な場所は、アプリケーション・ナビゲータの「アプリケーション・リソース」パネルの「ディスクリプタ」ノードです。アプリケーションは、確実に、正しいディスクリプタとともに作成されます。 プロジェクトで作成されたアプリケーションレベル・ディスクリプタは、実行時に無視されます。EARレベルで生成されたアプリケーション・リソース・ディスクリプタのみが実行時に使用されます。 |
デプロイメント・ディスクリプタを作成したら、JDeveloperの各種ダイアログを使用するか、ソース・エディタでファイルを編集することで、そのプロパティを変更できます。デプロイメント・ディスクリプタは、通常「アプリケーション・ソース」ノードにあるXMLファイル(application.xmlなど)です。
デプロイメント・ディスクリプタのプロパティの表示または変更方法:
アプリケーション・ナビゲータまたは「アプリケーション・リソース」パネルで、デプロイメント・ディスクリプタをダブルクリックします。
概要エディタで、「概要」タブまたは「ソース」タブを選択し、プロパティ値を設定してディスクリプタを構成します。
概要エディタが使用できない場合は、ソース・エディタでファイルが開きます。
Java EE 5に準拠するようにapplication.xmlファイルを構成しなければならないことがあります。
|
注意: 通常、プロジェクトには互換性のある |
application.xmlファイルを構成するには:
アプリケーション・ナビゲータで、アプリケーションを右クリックし、「新規」を選択します。
「新規ギャラリ」で、一般を展開し、「デプロイメント・ディスクリプタ」→「Java EEデプロイメント・ディスクリプタ」を選択して、「OK」をクリックします。
「Java EEデプロイメント・ディスクリプタの作成」ダイアログの「ディスクリプタの選択」ページで、「application.xml」を選択して、「次へ」をクリックします。
「バージョンを選択」ページで「5.0」を選択し、「次へ」をクリックします。
サマリー・ページで「終了」をクリックします。
application.xmlファイルを適切な値で編集します。
Java EE 5 (Servlet 2.5およびJSP 1.2に対応)に準拠するようにweb.xmlファイルを構成しなければならないことがあります。詳細は、A.13項「web.xml」を参照してください。
|
注意: 通常、プロジェクトには互換性のある アプリケーションでADFセキュリティが使用され、WebSphereにデプロイされる場合は、 |
web.xmlファイルを構成するには:
アプリケーション・ナビゲータで、プロジェクトを右クリックして「新規」を選択します。
「新規ギャラリ」で、「一般」を展開し、「デプロイメント・ディスクリプタ」→「Java EEデプロイメント・ディスクリプタ・ウィザード」を選択して、「OK」をクリックします。
「Java EEデプロイメント・ディスクリプタの作成」ダイアログの「ディスクリプタの選択」ページで、「web.xml」を選択して、「次へ」をクリックします。
「バージョンを選択」ページで「2.5」を選択し、「次へ」をクリックします。
サマリー・ページで「終了」をクリックします。
Real User Experience Insight (RUEI)はWebベースのユーティリティで、ネットワークからリクエストされる、またはネットワークで生成される実際のユーザーのトラフィックに対してレポートを作成します。ネットワーク・インフラストラクチャの最も重要となるポイントで、ページやトランザクションのレスポンス時間を測定します。セッション診断情報を使用すれば、根本原因分析を実行できます。
RUEIでは、実際のユーザー体験に基づいてサーバーおよびネットワーク時間を表示し、キー・パフォーマンス・インディケータ(KPI)とサービス・レベル合意(SLA)を監視し、定義済のターゲットに違反するインシデントが発生した場合にアラート通知をトリガーすることが可能です。ページ・コンテンツ、サイト・エラー、およびトランザクションの機能要件に関するチェックを実施できます。この情報を使用することで、業務面、技術面から運用を検証できます。RUEIで認識されるすべての項目の可用性、スループットおよびトラフィックに関して、カスタム・アラートを設定することもできます。
RUEIの詳細は、Oracle Real User Experience Insightのユーザーズ・ガイド(http://download.oracle.com/docs/cd/E16339_01/doc.60/e16359/toc.htm)を参照してください。
例36-3に示すように、次のcontext-paramタグをweb.xmlファイルに追加して、アプリケーションをRUEIに対して有効にする必要があります。
例36-3 web.xmlでのアプリケーションのRUEI監視の有効化
<context-param>
<description>This parameter notifies ADF Faces that the
ExecutionContextProvider service provider is enabled.
When enabled, this will start monitoring and aggregating
user activity information for the client initiated
requests. By default this param is not set or is false.
</description>
<param-name>
oracle.adf.view.faces.context.ENABLE_ADF_EXECUTION_CONTEXT_PROVIDER
</param-name>
<param-value>true</param-value>
</context-param>
統合WebLogic Serverを使用してJDeveloperでアプリケーションを開発する場合、アプリケーション・セキュリティ・デプロイメント・プロパティがデフォルトで構成されます。つまり、開発目的で再デプロイするたびに、アプリケーションとセキュリティの資格証明およびポリシーが上書きされることになります。デフォルト動作は、30.8.1項「セキュアなアプリケーションをJDeveloperで構成、デプロイおよび実行する方法」で説明されているように「アプリケーション・プロパティ」ダイアログで変更できます。
ADFセキュリティを有効にしたWebアプリケーションを、アプリケーション・サーバーにデプロイして実行するには、ターゲット・サーバーの管理者がOracle Access Manager (OAM)セキュリティ・プロバイダのドメインレベルのjps-config.xmlファイルを構成する必要があります。この構成タスクを実行するため、JDeveloperにはOracle WebLogic Scripting Tool (WLST)スクリプトが付属しています。このコマンドを使用して、WebSphereをOAM用に構成することもできます。WLST(コマンドaddOAMSSOProvider(loginuri, logouturi, autologinuri)を使用)の実行の詳細は、『Oracle Fusion Middlewareセキュリティ・ガイド』で、ADFセキュリティ、OAM SSOおよびOPSS SSOを使用したWebアプリケーションに対してOracle WebLogic Serverを構成する手順を参照してください。
addOAMSSOProvider()コマンドを実行することで、ADFセキュリティ・フレームワークが確実にOAMサービス・プロバイダに従って、SSO Cookieトークンをクリアするようになります。OAMでは、このトークンを使用して認証済ユーザーのアイデンティティが保存されるため、ログアウト中にトークンがクリアされないかぎり、ユーザーはログアウトできません。
システム管理者がターゲット・サーバーに対してスクリプトを実行すると、ドメインのjps-config.xmlファイルに、ADFセキュリティ固有の次のセキュリティ・プロバイダ定義が追加されます。
<propertySet name="props.auth.uri">
<property name="login.url.FORM" value="/${app.context}/adfAuthentication"/>
<property name="logout.url" value=""/>
</propertySet>
また、SSOに必要な認証タイプはCLIENT-CERTです。デプロイ済アプリケーションのweb.xml認証構成に、<auth-method>要素を次のいずれかのCLIENT-CERTタイプとして指定する必要があります。
WebLogicでは、次の2種類の認証方式をサポートしています。
FORMタイプの認証方式の場合、次のような要素を指定します。
<login-config>
<auth-method>CLIENT-CERT,FORM</auth-method>
<realm-name>myrealm</realm-name>
<form-login-config>
<form-login-page>/login.html</form-login-page>
<form-error-page>/error.html</form-error-page>
</form-login-config>
</login-config>
BASICタイプの認証方式の場合、次のような要素を指定します。
<login-config> <auth-method>CLIENT-CERT,BASIC</auth-method> <realm-name>myrealm</realm-name> </login-config>
WebSphereでは、次の1種類の認証方式をサポートしています。次のように要素を指定します。
<login-config>
<auth-method>CLIENT-CERT</auth-method>
<realm-name>myrealm</realm-name>
<form-login-config>
<form-login-page>/login.html</form-login-page>
<form-error-page>/error.html</form-error-page>
</form-login-config>
</login-config>
web.xmlファイルは、Webアプリケーションをデプロイする前でも後でも構成可能です。シングル・サインオンの認証方式を設定する方法の詳細は、『Oracle Fusion Middlewareセキュリティ・ガイド』を参照してください。
開発環境では、サーバーが開発モードに設定されている場合にのみ、アプリケーションレベルの資格証明、アイデンティティおよびポリシーがスタンドアロンWebLogic Serverインスタンスへ自動的に移行されます。統合WebLogic Serverはデフォルトで開発モードに設定されています。Oracle WebLogic Serverドメインの作成時に、Oracle Fusion Middleware構成ウィザードを使用して、スタンドアロンWebLogic Serverを開発モードに設定できます。Oracle WebLogic Serverドメインの構成の詳細は、『Oracle Fusion Middleware構成ウィザードによるドメインの作成』を参照してください。
本番モードでは、アプリケーションレベルのセキュリティ資格証明はWebLogic Server設定に移行されません。本番環境では一般に、管理者はEnterprise ManagerまたはWLSTを使用してアプリケーション(セキュリティ要件を含む)をデプロイします。
アプリケーションをWebLogic Serverにデプロイすると、資格証明(cwallet.ssoおよびjazn-data.xmlファイルに含まれる)は、WebLogic Serverのドメインレベルの資格情報ストアを上書きするか、これらとマージされます。上書きとマージのどちらが行われるかは、weblogic-application.xmlがOVERWRITEまたはMERGEのいずれに設定されているかによって決まります。本番モードのWebLogic Serverでは、セキュリティ・リスクを回避するため、MERGEしか使用できません。開発モードのWebLogic Serverでは、モードをOVERWRITEに設定して、ユーザー名とパスワードをテストできます。プロパティを設定するには、setDomainEnv.cmdまたはsetDomainEnv.shを実行します。その際、コマンド(通常はORACLE_HOME/user_projects/domains/MyDomain/binにあります)に次のオプションを追加します。
setDomainEnv.cmdの場合:
set EXTRA_JAVA_PROPERTIES=-Djps.app.credential.overwrite.allowed=true
%EXTRA_JAVA_PROPERTIES%
setDomainEnv.shの場合:
EXTRA_JAVA_PROPERTIES="-Djps.app.credential.overwrite.allowed=true
${EXTRA_JAVA_PROPERTIES}"
export EXTRA_JAVA_PROPERTIES
管理サーバーがすでに稼働している場合、この設定を有効にするにはサーバーを再起動する必要があります。
WebLogic Serverが本番モードかどうかをチェックするには、Oracle WebLogic Server管理コンソールを使用するか、WebLogic Serverのconfig.xmlファイルで次の行を確認します。
<production-mode-enabled>true</production-mode-enabled>
デフォルトでは、アプリケーションの資格証明、アイデンティティおよびポリシーはOVERWRITEに設定されます。つまり、「アプリケーションのプロパティ」ダイアログの「デプロイメント」ページで、「アプリケーション・ポリシー」、「資格証明」、「ユーザーとグループ」の各オプションがデフォルトで選択されます。ただし、アプリケーションの資格証明が移行されるのは、ターゲットとなるWebLogic Serverインスタンスが-Djps.app.credential.overwrite.allowed=trueの指定によって開発モードに設定されている場合のみです。
アプリケーションを本番環境にデプロイする準備ができたら、jazn-data.xmlファイルからアイデンティティを削除するか、「アプリケーションのプロパティ」ダイアログで「ユーザーとグループ」を選択解除して、アイデンティティの移行を無効にしてください。アプリケーションの資格証明は、JDeveloperの外部で、手動で移行する必要があります。
|
注意:
|
アプリケーションの資格証明とjazn-dataポリシーの移行の詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』を参照してください。
アプリケーションにJDBC URL接続を使用するコンポーネントがある場合、接続のユーザー名とパスワードもアプリケーションレベルの資格証明およびポリシー・ストアに格納されます。デプロイされたアプリケーションがJDBC URLを使用してデータベースに接続できるようにする場合は、これらの資格証明とポリシーを移行する必要があります。すなわち、WebLogic Serverが本番モードの場合、システム管理者はこのセキュリティ情報を移行する必要があります。WebLogic Serverが開発モードの場合は、ドメインレベルの資格証明とポリシー・ストアをOVERWRITEに設定して、セキュリティ情報の移行を許可する必要があります。
jazn-data.xmlファイルおよびcwallet.ssoファイルに資格証明とポリシーを含むアプリケーションがWebSphereに移行されることがあります。この場合、WebSphereで追加のタスクを実行する必要があります。WebSphereへのデプロイを意図したアプリケーションのEARファイルには、opss-application.xmlファイルが含まれないことに注意してください。
|
注意:
|
資格証明とポリシーを受け入れるためのWebSphereの設定の詳細は、Oracle Fusion Middlewareサードパーティ・アプリケーション・サーバー・ガイドを参照してください。
アプリケーションにJDBC URL接続を使用するコンポーネントがある場合、接続のユーザー名とパスワードもアプリケーションレベルの資格証明およびポリシー・ストアに格納されます。デプロイされたアプリケーションがJDBC URLを使用してデータベースに接続できるようにする場合は、OPSS移行を有効にする必要があります。
アプリケーションがパスワード・インダイレクション機能を持つアプリケーションレベルのJDBCデータソースを使用して、データベース接続を行う場合、WebSphereでJDBCデータソースを作成する必要があります。詳細は、IBM WebSphereのドキュメントを参照してください。
WebアプリケーションのADFセキュリティを有効にすると、web.xmlファイルにJava EEセキュリティ制約のallPagesが格納され、Java EEのアプリケーション・ルートが保護されます。デフォルトでは、Oracle WebLogic Serverへのデプロイをサポートするために、JDeveloperでセキュリティ制約のURLパターンが/(バックスラッシュ)に指定されます。アプリケーションをIBM WebSphereにデプロイする場合、正しいURLパターンは/*(バックスラッシュとアスタリスク)になります。アプリケーションをWebSphereにデプロイする前に、アプリケーションのweb.xmlファイルを手動で編集し、allPagesセキュリティ制約を次のように変更します。
<security-constraint>
<web-resource-collection>
<web-resource-name>allPages</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
. . .
</security-constraint>
クラスタ環境での実行を想定したアプリケーションをデプロイする場合、存続期間が1つのリクエストより長いマネージドBeanがすべてシリアライズ可能であること、そしてADFフレームワークがADFスコープ(ビュー・スコープとページ・フロー・スコープ)に格納されるマネージドBeanへの変更を認識することを確認する必要があります。
詳細は、20.4.3項「サーバー/クラスタ環境でのマネージドBeanメモリー・スコープの設定方法」を参照してください。
ADFアプリケーションでは、多くのXMLファイルを使用して構成情報が設定されています。これらの3つの構成ファイルには、アプリケーションとともにデプロイされ、構成ファイルと同じ役割を果すADF MBeanがあります。アプリケーションがデプロイされたら、Enterprise Manager Fusion Middleware ControlのMBeanブラウザを使用してADF MBeanにアクセスし、構成プロパティを変更することができます。
ADF MBeanを有効にするには、web.xmlファイルに登録する必要があります。例36-4に、接続、構成およびビジネス・コンポーネントのリスナー・エントリを含むweb.xmlファイルを示します。
例36-4 web.xmlファイルでのADF MBeanの有効化
<listener>
<listener-class>
oracle.adf.mbean.share.connection.ADFConnectionLifeCycleCallBack
</listener-class>
</listener>
<listener>
<listener-class>
oracle.adf.mbean.share.config.ADFConfigLifeCycleCallBack</listener-class>
</listener>
<listener>
<listener-class>
oracle.bc4j.mbean.BC4JConfigLifeCycleCallBack</listener-class>
</listener>
また、ADF接続MBeanを使用したconnections.xmlのデプロイメント後の構成、およびADFビジネス・コンポーネントMBeanを使用したbc4j.xcfgのデプロイメント後の構成を有効にするために、書込み可能なMDSリポジトリを構成する必要があります。
データベース・ベースのMDSを使用する場合のadf-config.xmlファイルのMDS構成エントリを例36-5に示します。MDSの構成の詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。
例36-5 adf-config.xmlファイルのMDS構成エントリ
<adf-mds-config xmlns="http://xmlns.oracle.com/adf/mds/config">
<mds-config xmlns="http://xmlns.oracle.com/mds/config" version="11.1.1.000">
<persistence-config>
<metadata-store-usages>
<metadata-store-usage
default-cust-store="true" deploy-target="true" id="myStore">
</metadata-store-usage>
</metadata-store-usages>
</persistence-config>
</mds-config>
</adf-mds-config>
本番環境では、データベースを使用するMDSリポジトリが必要です。JDeveloper、Enterprise Manager Fusion Middleware Control、WLST/wsadminコマンドのいずれかを使用して、ファイルベースのリポジトリからデータベースのMDSリポジトリに切り替えることができます。
また、複数のアプリケーションが同じMDS構成を共有している場合は、adf-config.xmlファイルでadf:adf-properties-childプロパティを定義して、各アプリケーションに異なるカスタマイズ・レイヤーを持たせることができます。このエントリは、アプリケーションの作成時に自動的に生成されます。adf-config.xmlファイルにこのエントリがない場合は、例36-6に示すようなコードを使用してファイルに追加できます。
例36-6 adf-config.xmlファイルへのMDSパーティション・コードの追加
<adf:adf-properties-child xmlns="http://xmlns.oracle.com/adf/config/properties">
<adf-property name="adfAppUID" value="Application3-4434"/>
<adf-property name="partition_customizations_by_application_id"
value="true"/>
</adf:adf-properties-child>
value属性は、JDeveloperで自動的に生成するか、アプリケーションのデプロイ先となるサーバー・ファーム内で一意の識別子に設定します。この値は、adfAppUIDプロパティのvalue属性に設定できます。
adf-property nameをadfAppUidに設定した場合は、対応するvalueプロパティをアプリケーションの名前に設定する必要があります。デフォルトでは、valueプロパティはアプリケーションのパッケージ名を使用して生成されます。パッケージ名を指定していない場合、valueプロパティはワークスペース名と4桁の乱数を使用して生成されます。
ADF MBeanを使用したADFアプリケーションの構成の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework管理者ガイド』を参照してください。
ADFアプリケーションでは、データベース接続にJDBCデータ・ソースとJDBC URLのいずれかを使用することができます。JDBCデータ・ソースを構成するには、Oracle WebLogic Server管理コンソールを使用します。データベース・アクセスの詳細は、9.3項「アプリケーション・モジュールのデータベース接続の構成」を参照してください。
|
ベスト・プラクティス: Fusion Webアプリケーションは、JDBC XAドライバで定義されたデータ・ソースと互換性がありません。Oracle WebLogic Serverでデータ・ソースを作成する場合、忘れずにFusion Webアプリケーション・データ・ソースのJDBCドライバをOracleのドライバ(Thin XA)からOracleのドライバ(Thin)に変更してください。XAデータ・ソースはコミット時にすべてのカーソルをクローズするため、XAデータ・ソースを使用してFusion Webアプリケーションを実行すると、ランダムにJBO-27122エラーおよび文のクローズ・エラーが発生することがあります。 |
データ・モデル・プロジェクトのADFアプリケーション・モジュールは、JDBC URL接続タイプ、JDBCデータ・ソース接続タイプまたはこの2つのタイプの組合せを使用するように構成できます。デフォルトでは、ADFアプリケーション・モジュールはJDBC URL接続を使用します。JDBC URLを使用するコンポーネントは、JDBC URLを使ってデータベースへの直接接続を試みて、WebLogic Serverで使用可能なJDBCデータ・ソース(グローバルまたはアプリケーションレベル)を無視します。アプリケーションからWebLogic ServerへのJDBC URLセキュリティ情報(ユーザー名とパスワード)の移行の詳細は、36.3.4項「ADFセキュリティを有効にしてアプリケーションをデプロイする方法」を参照してください。
ADFアプリケーションでは、データベースへの接続にJDBCデータ・ソースを使用できます。JDBCデータ・ソースには、グローバル、アプリケーションレベル、パスワード・インダイレクション機能を持つアプリケーションレベルの3種類があります。通常、グローバルなJDBCデータ・ソースはWebLogic Serverで設定します。データベースにアクセスする必要のあるアプリケーションは、そのJDBCデータ・ソースを使用できます。アプリケーションには、アプリケーションレベルのJDBCデータ・ソースを組み込むこともできます。アプリケーションをデプロイメント用にパッケージ化する際に、「デプロイ中にweblogic-jdbc.xmlディスクリプタを自動生成および同期化」オプションを選択すると、定義した接続ごとにconnection_name-jdbc.xmlファイルが作成されます。各接続の情報は、対応するconnection_name-jdbc.xmlファイルに書き込まれます(weblogic-application.xmlとweb.xmlのエントリも変更されます)。アプリケーションがWebLogic Serverにデプロイされると、サーバーはグローバル・データ・ソースを検索する前に、アプリケーションレベルのデータ・ソース情報を検索します。
パスワード・インダイレクションをtrueに設定してアプリケーションをデプロイすると、WebLogic Serverは、connection_name-jdbc.xmlファイルを探してユーザー名情報を確認し、そのユーザー名に対応するアプリケーションレベルの資格証明マップを特定してパスワードを入手しようとします。JDeveloperを使用してアプリケーションをWebLogic Serverに直接デプロイする場合は、資格証明マップが自動的に作成され、MBeanコールを介してサーバーに組み込まれます。
ただし、EARファイルをデプロイする場合は、JDeveloperでWebLogic ServerへのMBeanコールを行えません。Oracle WebLogic管理コンソールを使用して、資格証明マップを設定する必要があります。グローバルなJDBCデータ・ソースを設定した場合でも、資格証明マッピングを設定していなければ、WebLogic Serverは資格証明をパスワードにマップできず、接続は失敗します。JDBCデータ・ソース、パスワード・インダイレクション、およびアプリケーション資格証明マッピングの設定方法の詳細は、JDeveloperオンライン・ヘルプの「アプリケーションのデプロイ」の「JDBCデータ・ソース」を参照してください。
データ・ソースがOracle WebLogic Serverで作成されたら、アプリケーション・モジュールで使用できます。詳細は、『Oracle Fusion Middleware Oracle Application Development Framework管理者ガイド』のデプロイに向けたスタンドアロン・アプリケーション・サーバーの準備に関する項を参照してください。
ADFアプリケーションは、JDeveloperを使用してスタンドアロン・アプリケーション・サーバーに直接デプロイすることも、アーカイブ・ファイルを作成し、他のツールを使用してアプリケーション・サーバーにデプロイすることもできます。
|
注意: Oracle ADFを使用するアプリケーションをスタンドアロン・アプリケーション・サーバーにデプロイし始める前に、ADFランタイムのインストール、およびドメインまたはセルの作成や拡張といったタスクを実行して、アプリケーション・サーバー環境を準備しておく必要があります。詳細は、『Oracle Fusion Middleware Oracle Application Development Framework管理者ガイド』のデプロイに向けたスタンドアロン・アプリケーション・サーバーの準備に関する項を参照してください。 |
図36-5に、ターゲット・スタンドアロン・アプリケーション・サーバーへのアプリケーションのデプロイとカスタマイズのデプロイのプロセス・フローを示します。
次のダイアグラムには、クリック可能なリンクが含まれています。
表36-2に、アプリケーションのデプロイおよびデプロイ・サイクル中に使用できる一般的なデプロイ方法を示します。開発環境でのデプロイから本番環境のデプロイまでの順序でデプロイ方法をリストしています。本番環境では、システム管理者がEnterprise Manager Fusion Middleware Controlまたはスクリプトを使用してアプリケーションをデプロイします。
表36-2 開発環境または本番環境でのデプロイ方法
| デプロイ方法 | 環境 | 使用するとき |
|---|---|---|
|
JDeveloperから直接実行 |
テストまたは開発 |
この方法は、アプリケーションの開発中に使用します。編集プロセスとデプロイ・プロセスを何度も繰り返す必要があるからです。 JDeveloperには統合WebLogic Serverが含まれています。この統合WebLogic Serverでアプリケーションを実行してテストできます。 |
|
JDeveloperを使用してターゲット・アプリケーション・サーバーに直接デプロイ |
テストまたは開発 |
この方法は、テスト環境のアプリケーション・サーバーにアプリケーションをデプロイしてテストする準備ができている場合に使用します。 テスト用サーバーでは、開発用サーバーで使用できない機能(LDAPやOracle Single Sign-Onなど)をテストできます。 テスト環境を使用して、Antなどでデプロイメント・スクリプトを開発することもできます。 |
|
JDeveloperを使用してEARファイルにデプロイし、ターゲット・アプリケーション・サーバーのデプロイ用ツールを使用 |
テストまたは開発 |
この方法は、テスト環境のアプリケーション・サーバーにアプリケーションをデプロイしてテストする準備ができている場合に使用します。JDeveloperから直接デプロイするかわりに、EARファイルにデプロイしてから、他のツールを使用してアプリケーション・サーバーにデプロイすることができます。 テスト用サーバーでは、開発用サーバーで使用できない機能(LDAPやOracle Single Sign-Onなど)をテストできます。 テスト環境を使用して、Antなどでデプロイメント・スクリプトを開発することもできます。 |
|
Enterprise ManagerまたはWLSTを使用してアプリケーションをデプロイ |
本番 |
アプリケーションがテスト環境と本番環境にある場合です。本番環境では、システム管理者がEnterprise Managerを使用するか、スクリプトを実行して、アプリケーションをデプロイするのが一般的です。 |
必要なMDSリポジトリをすべてアプリケーション・サーバーに登録する必要があります。MDSリポジトリがデータベースの場合、リポジトリはMDS固有の要件を備えたデータソースにマップされます。
アプリケーションをOracle WebLogic Serverにデプロイする前に、このデータソースのターゲットをWebLogic管理サーバー、およびアプリケーションのデプロイ先となるすべての管理対象サーバーに設定する必要があります。MDSの登録の詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。
adf-config.xmlのMDSリポジトリ構成を必要とするEARファイルとしてパッケージ化されたアプリケーションを、アプリケーション・サーバーの管理コンソールまたはスクリプトを使用してデプロイする場合は、EARファイルをデプロイする前に、getMDSArchiveConfigコマンドを実行してMDSを構成する必要があります。MDS構成は、EARファイルにMARファイルが含まれる場合、またはアプリケーションがDT@RT (Design Time At Run Time)に対して有効化されている場合に必要です。
WLSTコマンドの詳細は、Oracle Fusion Middlewareコア・コンポーネントWLSTコマンド・リファレンスを参照してください。wsadminコマンドの詳細は、Oracle Fusion Middlewareサードパーティ・アプリケーション・サーバー・ガイドおよびOracle Fusion Middleware IBM WebSphere Application Server構成ガイドを参照してください。
|
注意: IBM WebSphere Application Serverの場合、アプリケーションのデプロイ後にサーバーの起動などの追加作業を実行する必要があります。 IBM WebSphere Application Server、wsadminコマンドおよびWebSphere管理コンソールの使用の詳細は、Oracle Fusion Middlewareサードパーティ・アプリケーション・サーバー・ガイドを参照してください。 ADF固有のwsadminコマンドについて、およびADFランタイムのIBM WebSphere Application Serverへのインストールの詳細は、『Oracle Fusion Middleware Oracle Application Development Framework管理者ガイド』を参照してください。 |
アプリケーションのデプロイ後に、ADF MBeanを使用してADF接続情報、ADFビジネス・コンポーネント情報またはadf-config.xmlを構成する予定の場合は、アプリケーションがMDSを使用するように構成されていること、およびweb.xmlファイルでMBeanリスナーが有効になっていることを確認してください。詳細は、36.3.6項「アプリケーションをADF MBeanに対して有効化する方法」を参照してください。
|
注意: WebLogic Serverにデプロイするビジネス・サービスがADFアプリケーションにある場合は、11.2.20項「Oracle WebLogic ServerへのWebサービスのデプロイ方法」を参照してください。 |
作業を始める前に、次のようにします。
EARファイルにデプロイするアプリケーションレベルのデプロイメント・プロファイルを作成します。
|
注意: JDeveloperからOracle WebLogic Serverにデプロイする場合は、Oracle WebLogic Server管理コンソールで、HTTPトンネリング・プロパティが有効になっていることを確認してください。このプロパティは、「サーバー」→「ServerName」→「プロトコル」の下にあります。ServerNameは、Oracle WebLogic Serverの名前です。 |
|
注意: WebLogic Serverに対して、JDeveloperは、クラスタに属する個々の管理対象サーバーへのアプリケーションのデプロイをサポートしていません。Oracle WebLogic Server管理コンソールやその他のOracle WebLogicツールを使用してクラスタ内の1つ以上の管理対象サーバーをターゲットに設定することは可能ですが、クラスタに悪影響を及ぼす可能性があります。Oracle WebLogic Serverクラスタへのデプロイの詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。 |
JDeveloperからターゲット・アプリケーション・サーバーにデプロイする方法:
アプリケーション・ナビゲータで、アプリケーションを右クリックし、「デプロイ」→「deployment profile」を選択します。
デプロイ・ウィザードの「デプロイメント・アクション」ページで、「アプリケーション・サーバーへのデプロイ」を選択し、「次へ」をクリックします。
「サーバーの選択」ページで、目的のアプリケーション・サーバー接続を選択し、「次へ」をクリックします。
WebLogic Serverインスタンスにデプロイしている場合は、「WebLogicオプション」ページが表示されます。デプロイ・オプションを選択し、「次へ」をクリックします。
|
注意: ADFアプリケーションをデプロイしている場合は、「ドメイン内の全インスタンスへのデプロイ」オプションは使用しないでください。 |
「終了」をクリックします。
デプロイ中は、処理ステップがデプロイメント・ログ・ウィンドウに表示されます。作成中のモジュールの内容(アーカイブまたは展開EAR)を確認するには、ログ・ウィンドウに表示されたリンクをクリックします。アーカイブ・ファイルまたは展開EARファイルが該当するエディタまたはディレクトリ・ウィンドウで開き、確認できるようになります。
EARファイル内のadf-config.xmlファイルにMDSリポジトリ構成が必要な場合は、図36-6に示す「デプロイメント構成」ダイアログが表示されるので、そこでターゲット・メタデータ・リポジトリまたは共有メタデータ・リポジトリを選択します。「リポジトリ名」ドロップダウン・リストでは、管理サーバーに登録されているメタデータ・リポジトリのリストからターゲット・メタデータ・リポジトリを選択できます。「パーティション名」ドロップダウン・リストでは、デプロイ中にアプリケーションのメタデータがインポートされるメタデータ・リポジトリ・パーティションを選択できます。Oracle WebLogic Scripting Tool (WLST)またはwsadminコマンドおよびOracle WebLogic Server管理ツールまたはWebSphere管理ツールのいずれかを使用して、MDSを構成および登録できます。MDSリポジトリの管理の詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。
|
注意: Java EEアプリケーションをデプロイする場合は、アプリケーション・ナビゲータ内でJava EEアプリケーションの隣にあるアプリケーション・メニューをクリックします。 |
アプリケーション・サーバー接続の作成の詳細は、36.3.1項「ターゲット・アプリケーション・サーバーへの接続の作成方法」を参照してください。
デプロイメント・プロファイルを使用してアーカイブ・ファイル(EARファイル)を作成することもできます。作成したアーカイブ・ファイルは、Enterprise Manager、Oracle WebLogic Scripting Tool (WLST)/WebSphereのwsadminツール、Oracle WebLogic Server管理コンソール/WebSphere管理コンソールのいずれかを使用してデプロイできます。
ADFアプリケーションはEARファイル(通常はWAR、MAR、JARのコンポーネントを含む)にカプセル化されますが、部分的にEARではデプロイされないことがあります。たとえば、ADFビジネス・サービスはJARとしてデプロイできます。ビジネス・サービスの詳細は、11.2.20項「Oracle WebLogic ServerへのWebサービスのデプロイ方法」を参照してください。
EARアーカイブ・ファイルを作成するには:
アプリケーション・ナビゲータで、デプロイメント・プロファイルを含むアプリケーションを右クリックし、「デプロイ」→「deployment profile」→「EARファイルへ」を選択します。
EARファイルがアプリケーションレベルでデプロイされ、そのEARファイルにデータ・モデル・プロジェクトのJARファイルとビュー・コントローラ・プロジェクトのWARファイルへの依存性が存在する場合、各ファイルはデフォルトで次のディレクトリに保存されます。
ApplicationDirectory/deploy/EARdeploymentprofile.EAR
ApplicationDirectory/ModelProject/deploy/JARdeploymentprofile.JAR
ApplicationDirectory/ViewControllerProject/deploy/WARdeploymentprofile.WAR
|
ヒント: 「表示」→「ログ」を選択し、アーカイブ・ファイルの作成時に生成されたメッセージを表示します。 |
ADFアプリケーションをEARファイルにパッケージ化する場合、EARファイルには次のものを組み込むことができます。
WARファイル: Webベースのビュー・コントローラ・プロジェクトはそれぞれWARファイルにパッケージ化します。
MARファイル: アプリケーションとともにデプロイするカスタマイズ内容がある場合、カスタマイズ内容はMARにパッケージ化します。
ADFライブラリJARファイル: アプリケーションでADFライブラリJARが使用される場合、そのJARファイルはEARにパッケージ化できます。
その他のJARファイル: アプリケーションに必要な依存JARファイルが他にもある場合があります。それらはEARにパッケージ化できます。
コマンドを使用してアプリケーションをデプロイし、そのコマンドをスクリプトに記述してプロセスを自動化することができます。ojdeployコマンドを使用すると、JDeveloperなしでアプリケーションをデプロイできます。Antスクリプトを使用してアプリケーションをデプロイすることもできます。JDeveloperには、Antスクリプトの作成に役立つ機能が用意されています。要件によっては、通常のスクリプトをAntスクリプトと組み合せることも可能です。
アプリケーション・サーバー・コマンドもデプロイメントに使用できます。WebLogic ServerにはWLSTコマンド、IBM WebSphere Application Serverにはwsadminコマンドを使用できます。
WLSTおよびwsadminコマンド、スクリプトおよびAntの詳細は、『Oracle Fusion Middleware Oracle Application Development Framework管理者ガイド』を参照してください。
ADFライブラリ用に新しいカスタマイズを作成した場合は、MARプロファイルを使用して、このカスタマイズをADFライブラリを使用する任意のデプロイ済アプリケーションにデプロイできます。たとえば、ADFLibraryBを使用するapplicationAはスタンドアロン・アプリケーション・サーバーにデプロイされました。その後、新しいカスタマイズがADFLibraryBに追加された場合は、この更新されたカスタマイズをapplicationAにデプロイするだけで済みます。アプリケーション全体を再パッケージ化したり再デプロイする必要はありません。また、MDSリポジトリに手動でパッチを適用する必要もありません。
|
注意: この手順は、ADFライブラリのカスタマイズ変更を、スタンドアロン・アプリケーション・サーバーのデプロイ済アプリケーションに適用するためのものです。カスタマイズを初めてMARにパッケージ化し、最終的にEARの一部とするための手順ではありません。MARを使用したカスタマイズの初回パッケージ化の詳細は、36.3.2.3項「MARデプロイメント・プロファイルの作成」を参照してください。 |
ADFライブラリのカスタマイズをデプロイするには、デプロイするカスタマイズのみを格納した新しいMARプロファイルを作成し、JDeveloperを使用して次を実行します。
カスタマイズをスタンドアロン・アプリケーション・サーバーのMDSリポジトリに直接デプロイします。
カスタマイズをJARにデプロイします。次に、Fusion Middleware Controlなどのツールを使用して、JARをMDSリポジトリにインポートします。
カスタマイズは、JDeveloperからスタンドアロン・アプリケーション・サーバーのデプロイ済アプリケーションのMDSリポジトリに直接エクスポートできます。
作業を始める前に、次のようにします。
JDeveloperで「カスタマイズ開発者」ロールを使用して、新しいカスタマイズをADFライブラリに作成します。
カスタマイズをアプリケーション・サーバーに直接エクスポートするには:
アプリケーション・ナビゲータで、アプリケーションを右クリックし、「デプロイ」→「メタデータ」を選択します。
「デプロイメント・アクション」ページの「メタデータのデプロイ」ダイアログで、「デプロイ済アプリケーションへのエクスポート」を選択し、「次へ」をクリックします。
MARプロファイルがアプリケーションのEARプロファイルに格納されると、「デプロイ済アプリケーションへのエクスポート」がグレー表示されて無効化されます。
「アプリケーション・サーバー」ページで、目的のアプリケーション・サーバー接続を選択し、「次へ」をクリックします。
WebLogic Serverの場合は、「サーバー・インスタンス」ページが表示されます。このページで、デプロイ済アプリケーションを含むサーバー・インスタンスを選択し、「次へ」をクリックします。
「デプロイ済アプリケーション」ページで、カスタマイズを適用するアプリケーションを選択し、「次へ」をクリックします。
サンドボックスにデプロイする場合は、「サンドボックス・インスタンス」ページで、「関連するサンドボックスにデプロイ」を選択し、「次へ」をクリックします。
「サマリー」ページで、内容を確認して「終了」をクリックします。
ADFライブラリのカスタマイズをJARにデプロイする場合は、MARプロファイルに定義されているとおりにコンテンツをパッケージ化します。
作業を始める前に、次のようにします。
JDeveloperで「カスタマイズ開発者」ロールを使用して、新しいカスタマイズをADFライブラリに作成します。
カスタマイズをJARとしてデプロイする手順:
アプリケーション・ナビゲータで、アプリケーションを右クリックし、「デプロイ」→「メタデータ」を選択します。
「デプロイメント・アクション」ページの「メタデータのデプロイ」ダイアログで、「MARにデプロイ」を選択します。
サマリー・ページで「終了」をクリックします。
Enterprise Manager Fusion Middleware Controlまたはアプリケーション・サーバーの管理ツールを使用して、JARをMDSリポジトリにインポートします。
ADFライブラリは、ADFコンポーネント(ADFタスク・フロー、ページ、アプリケーション・モジュールなど)に対して登録されたJARサービスを含むJARファイルです。プロジェクトのADFコンポーネントを再利用する場合は、プロジェクトのADFライブラリ・デプロイメント・プロファイルを作成してから、そのプロファイルに基づいたADFライブラリJARを作成します。
リソース・パレットを使用するか、手動でライブラリのクラスパスに追加する方法でADFライブラリJARを追加すると、アプリケーションまたはプロジェクトでそのADFライブラリJARを使用できるようになります。「デフォルトでデプロイ済」オプションが選択されている場合、プロジェクトに追加されたADFライブラリJARは、プロジェクトのWARファイルに組み込まれます。
詳細は、第33章「アプリケーション・コンポーネントの再利用」を参照してください。
ADFモデルを使用せずにADF Facesのみを使用するアプリケーションを開発できます。この場合、ADF Faces JARをアプリケーションとともにアプリケーション・サーバーにデプロイできます。
作業を始める前に、次のようにします。
Webベースのプロジェクトを使用してアプリケーションを作成します。Fusion Web Application (ADF)テンプレートを使用した場合は、すでにデフォルトのWARデプロイメント・ファイルが存在します。
ADF Faces JARをアプリケーションの一部としてデプロイするには:
アプリケーション・ナビゲータで、デプロイするWebプロジェクトを右クリックして、「プロジェクト・プロパティ」を選択します。
「プロジェクト・プロパティ」ダイアログで「デプロイ」を選択してからデプロイメント・プロファイルを選択し、「編集」をクリックします。
プロジェクトにWARデプロイメント・プロファイルがない場合は、36.3.2.2項「WARデプロイメント・プロファイルの作成」の手順1から3に従って、新しいWARデプロイメント・プロファイルを作成します。
「ファイル・グループ」→「WEB-INF/lib」→「コントリビュータ」を選択し、ADF Facesランタイム11を選択します。
「OK」をクリックして、デプロイメント・プロファイル・プロパティのダイアログを終了します。
「OK」を再度クリックして、プロジェクト・プロパティのダイアログを終了します。
この章で説明したように、JDeveloperを使用して直接、あるいはEARを作成してEnterprise Manager Fusion Middleware Control、Oracle WebLogic Server管理コンソールまたはその他の方法を使用してデプロイすることにより、アプリケーションをデプロイします。
36.3.2.4項「アプリケーションレベルのEARデプロイメント・プロファイルの作成」で説明しているように、アプリケーションレベルのEARにWARファイルが含まれていることを確認します。
アプリケーションをデプロイすると、必要なライブラリの一部がアプリケーションとともに組み込まれます。JDeveloperランタイム・ライブラリとしてすでにWebLogic Serverにロードされている共有ライブラリも必要になる場合があります。どのJDeveloperライブラリがどのWebLogic Server共有ライブラリにパッケージ化されているかを知っておくと便利です。JDeveloperランタイム・ライブラリの内容の一覧は、『Oracle Fusion Middleware Oracle Application Development Framework管理者ガイド』を参照してください。
アプリケーションをWebLogic Serverにデプロイしたら、構成タスクを実行できます。
ADFアプリケーションをあるアプリケーション・サーバーから別のアプリケーション・サーバーに移行する場合は、初回のデプロイの際と同じステップの一部を実行する必要があります。
一般に、アプリケーションを移行する際には、次の作業を行います。
ターゲットとなるアプリケーション・サーバーにADFランタイムをロードします(まだインストールされていない場合)。詳細は、『Oracle Fusion Middleware Oracle Application Development Framework管理者ガイド』のデプロイに向けたスタンドアロン・アプリケーション・サーバーの準備に関する項を参照してください。
ターゲットとなるアプリケーション・サーバーを正しいデータベース接続情報またはURL接続情報で構成します。
セキュリティ情報をソースからターゲットに移行します。詳細は、36.3.4項「ADFセキュリティを有効にしたアプリケーションのデプロイ方法」を参照してください。
Enterprise Manager、管理コンソール、スクリプトのいずれかを使用してアプリケーションをデプロイします。詳細は、Oracle Fusion Middleware Oracle Application Development Framework管理者ガイドを参照してください。
ADF MBeanが有効化され、デプロイ済アプリケーションとともにパッケージ化されている場合、Enterprise ManagerのMBeanブラウザを使用してADFプロパティを構成できます。アプリケーションをMBeanに対して有効化する手順は、36.3.6項「アプリケーションをADF MBeanに対して有効化する方法」を参照してください。
ADF MBeanを使用したADFアプリケーションの構成方法の詳細は、Oracle Fusion Middleware Oracle Application Development Framework管理者ガイドを参照してください。
アプリケーションは、デプロイが完了したら、Oracle WebLogic Serverからテストすることができます。ADFアプリケーションをテストするには、ブラウザ・ウィンドウを開き、次のURLを入力します。
Faces以外のページの場合: http://<host>:port/<context root>/<page>
Facesページの場合: http://<host>:port/<context root>/faces/<view_id>
<view_id>は、ADFタスク・フローにおけるビュー・アクティビティのビューIDです。
|
ヒント: アプリケーションのコンテキスト・ルートは、ビュー・コントローラ・プロジェクト設定に、デフォルトで |
|
注意: FacesページのURLには、 |
