|
|
アプリケーションのデプロイメントとは、WebLogic Server ドメインでクライアント リクエストの処理にアプリケーションやモジュールを利用できるようにすることです。この章では、WebLogic Portal アプリケーションおよび共有ライブラリをサーバにデプロイする場合の推奨手順とベスト プラクティスについて説明します。
| 注意 : | WebLogic Portal では、現時点では WebLogic Server の機能であるプロダクションの再デプロイメントと並列バージョン管理がサポートされていません。この WebLogic Server の機能については、「再デプロイメント方式の概要」を参照してください。 |
| ヒント : | この手順を進める前に、WebLogic Server ドキュメントの「WebLogic Server ドメインについて」の内容を確認しておくことをお勧めします。 |
WebLogic Portal アプリケーションをデプロイする前に、送り先ドメインをコンフィグレーションする必要があります。ドメインのコンフィグレーションの詳細については、「クラスタ ドメインの作成」を参照してください。
WebLogic Portal 8.1 以前のバージョンでは、WebLogic Portal コンポーネント (キャッシュ、キャンペーン、行動追跡、コンテンツ管理など) のコンフィグレーションに META-INF/application-config.xml という名前のアプリケーション コンフィグレーション ファイルが使用されていました。
WebLogic Portal 9.2 では、このコンフィグレーション ファイルが削除されており、コンフィグレーションの内容はスキーマ準拠の新しい記述子のコレクションに移行されています。これらの新しい記述子は、単一サービスまたは関連するサービス グループに特化されています。WebLogic Workshop のアプリケーションで使用する一連の記述子ファイルを確認する場合は、マージ済みプロジェクト ビューを選択します。
これらのファイルは、WebLogic Server ですべての J2EE 記述子 (application.xml または web.xml など) の処理に使用されるのと同じインフラストラクチャを使って処理されます。これらの記述子は、J2EE 共有ライブラリからのマージをサポートしています。また、デプロイメント計画もサポートしています (マージの詳細については、「記述子のマージ」を参照)。WebLogic Portal 記述子はデフォルト設定を使用してインストールされます。このデフォルト設定は、アプリケーションにコピーして編集することによってオーバーライドできます。このコンフィグレーションの大きな利点は、プロジェクトの EAR ファイルの内容が WebLogic Portal 製品コードではなく、プロジェクトに限定されることです。
サーバはデプロイメント記述子を処理する際に、これらの記述子をマージします。アプリケーションで参照されるアプリケーションおよび共有ライブラリのすべての記述子がマージされます。個々のデプロイメント記述子に対して、マージされた「仮想」記述子が作成されます。仮想記述子は、アプリケーションをデプロイする際にサーバで使用できます。記述子のマージを規定するルールについては、「優先に関する共有ライブラリ ルール」を参照してください。参照ライブラリからインポートされる設定は、参照元アプリケーションとそのデプロイメント計画によって常にオーバーライドされます。
アプリケーションをデプロイせずにマージ結果を確認する場合は、weblogic.appmerge という WebLogic Server ユーティリティを使用します。このユーティリティは共有ライブラリを参照するアプリケーションを取得して、マージされたコンテンツやマージされた記述子を含む J2EE アプリケーションを作成します。このユーティリティはデバッグに有効です。詳細については、WebLogic Server ドキュメントの「weblogic.appmerge を使用したライブラリの結合」を参照してください。
Workshop for WebLogic では、共有ライブラリ (ライブラリ モジュールとも呼ばれる) に関する情報が利用できます。Workshop for WebLogic を使用すると、共有ライブラリのファイルをアプリケーションにコピーできます。この場合、コピーされたファイルは後から変更できます。それ以降は、ローカル コピーがライブラリ モジュールのコピーよりも優先されます。[パッケージ・エクスプローラ] ビューを使用すると、共有ライブラリの内容を表示および参照できます。
WebLogic Portal のインストールには、ddbrowser という別のユーティリティも含まれています。このユーティリティはアプリケーションを検査して、「マージ可能」なすべての記述子を表示します。アプリケーション内の各記述子については、マージされた記述子だけでなく、各ライブラリの関与も確認できます。
ddbrowser を使用するには、WL_HOME 環境変数で weblogic92 ディレクトリを参照するように設定してから、以下のコマンドを入力します。
java -jar $WL_HOME/common/p13n/lib/ddbrowser.jar
ポータル Web アプリケーションには、複数のデプロイメント記述子が含まれています。デフォルトで、これらの記述子は Web プロジェクトの WebContent/WEB-INF ディレクトリにあります。表 4-1 にデプロイメント記述子を示します。
| ヒント : | WebLogic Server ベースのアプリケーションに関連するデプロイメント記述子の完全なリストと詳細については、WebLogic Server ドキュメントの「WebLogic Server アプリケーション開発の概要」を参照してください。 |
J2EE 仕様では、J2EE モジュールおよびアプリケーションに対応する、移植可能で標準的なデプロイメント記述子が定義されています。BEA では、WebLogic Server 環境でモジュールやアプリケーションをデプロイするための WebLogic 固有のその他のデプロイメント記述子が定義されています。WebLogic Portal のエンタープライズ アプリケーション (EAR プロジェクトとも呼ばれる) には、表 4-2 に記載されたデプロイメント記述子が含まれています。デフォルトで、これらのファイルは EAR プロジェクトの EarContent/META-INF ディレクトリにあります。
| ヒント : | WebLogic Server ベースのアプリケーションに関連するデプロイメント記述子の完全なリストと詳細については、WebLogic Server ドキュメントの「WebLogic Server アプリケーション開発の概要」を参照してください。 |
表 4-3 は、Web アプリケーションのコンフィグレーション ファイルを示しています。これらのファイルは記述子ファイルではありません (これらのファイルはデプロイメント計画で使用できず、マージされることもありません)。
WEB-INF/wsrp-producer-registry.xml で <enable-local-proxy> を true に設定することによって、ローカル プロキシ サポートを有効にできる。WSRP アプリケーションの詳細については、『連合ポータル ガイド』を参照。
|
|
デプロイメント計画を使用すると、アプリケーション EAR ファイルの記述子を実際に変更することなく、アプリケーションのデプロイメント記述子をデプロイメントごとに容易にチューニングできます。たとえば、ステージング環境向けに記述子を調整する場合やプロダクション環境向けに調整する場合に、それぞれ個別のデプロイメント計画を使用できます。通常、開発者は記述子の初期基準値を設定します。
| ヒント : | 「アプリケーション チューニングのヒント」も参照してください。 |
デプロイメント記述子は、デプロイメント時におけるアプリケーションやモジュールの J2EE 動作や WebLogic Server コンフィグレーションを定義する XML ドキュメントです。デプロイメント計画は、アプリケーションのアーカイブ ファイルの外部にある XML ドキュメントで、アプリケーションの既存の WebLogic Server デプロイメント記述子に格納されているデプロイメント プロパティに変更を加えることができます。
デプロイメント計画の詳細については、WebLogic Server ドキュメントの「プロダクション デプロイメントのためのアプリケーションのコンフィグレーション」を参照してください。このドキュメントには、デプロイメント計画の詳細、デプロイメント計画の XML スキーマ、およびデプロイメント計画の作成、編集、および使用手順に関する説明が記載されています。
| 注意 : | WebLogic Portal Administration Console では、デプロイメント計画を使用してデプロイメント記述子の値に対する実行時の変更を保存します。 |
アプリケーション スコープ JDBC を使用すると、WebLogic Portal ドメインで複数のデータベースを使用できます。これにより、ドメインにデプロイされた各アプリケーションで独自のデータベースを利用することが可能になります。JDBC プールのスコープをアプリケーション レベルに設定できるようにすると、WebLogic Server でこの機能が利用できるようになります。
| 注意 : | デフォルトで、JDBC プールのスコープはドメイン レベルです。JDBC プールのスコープをアプリケーション レベルに設定する場合は、コンフィグレーションが必要になります。 |
エンタープライズ アプリケーションをパッケージ化する場合、JDBC モジュールを EAR にパッケージ化し、該当するすべての記述子ファイルに JDBC モジュールへの参照を追加すると、JDBC リソースをアプリケーションに組み込むことができます。アプリケーションをデプロイする際には、JDBC リソースもデプロイされます。アプリケーションでデプロイされる JDBC データ ソースは、JDBC モジュールのコンフィグレーション方法に基づいて、コンテナ アプリケーションによる利用に限定されるか (アプリケーション スコープ モジュール)、またはすべてのアプリケーションとクライアントで利用できるようになります (グローバル スコープ モジュール)。
アプリケーション スコープ JDBC のコンフィグレーションの詳細については、WebLogic Server ドキュメントの「JDBC アプリケーション モジュールのデプロイメントのコンフィグレーション」を参照してください。
この節では、Workshop for WebLogic またはコマンドラインを使用してポータル アプリケーションをビルドする手順および EAR ファイルを作成する手順について説明します。この節では、EAR ファイルと非圧縮 EAR の両方を使用した作成手順について説明します。
ポータル アプリケーションをプロダクション環境にデプロイするには、まず Workshop for WebLogic でそのアプリケーションをビルドして、ポータル アプリケーション内の必要なクラスをコンパイルし、デプロイ可能な EAR ファイルを作成する必要があります。EAR は、圧縮 (EAR ファイル) または非圧縮 (非圧縮 EAR ディレクトリ) のいずれでも使用できます。
Workshop for WebLogic でのアプリケーションのビルドの詳細については、Workshop for WebLogic のドキュメント「ビルド プロセスについて」を参照してください。
非圧縮 EAR ディレクトリを作成するには、最初に EAR ファイルをビルドし、次に Java の jar xf コマンドを使用してファイルを非圧縮にします。
| ヒント : | 非圧縮 EAR の作成後、アプリケーション ディレクトリの名前に .ear 拡張子を付けて変更することができます。たとえば、アプリケーション ディレクトリの名前が myPortalApp である場合は、ディレクトリ名を myPortalApp.ear に変更します。.ear を追加すると、圧縮および非圧縮デプロイメント用のコンフィグレーションを共通化できますが、必須ではありません。 |
Workshop for WebLogic を使用すると、プロジェクトの Ant ビルド ファイルをエクスポートできます。詳細については、WebLogic Workshop のドキュメント「アプリケーションのカスタム Ant ビルド ファイルの作成」を参照してください。
この節では、ポータル アプリケーションのデプロイメントの手順について説明します。
| 注意 : | WebLogic Portal バージョン 9.2 より前のバージョンでは、WebLogic Portal アプリケーションの管理サーバへのデプロイが必須でしたが、バージョン 9.2 では必須ではなくなったため、ここでは特に説明しません。 |
| ヒント : | WebLogic Server ドキュメントには、デプロイメント手順と複数のデプロイメント例の詳細な説明が記載されています。この手順を進める前に、WebLogic Server ドキュメントの「WebLogic Server アプリケーションのデプロイメント」の内容を確認しておくことをお勧めします。WLST による自動デプロイメント タスクについては、WebLogic Server ドキュメントの『WebLogic Scripting Tool ガイド』を参照してください。 |
一般的な開発環境では、開発者は Workshop for WebLogic を使用してポータル コンポーネントの開発を行います。通常、開発者は開発モードでコンフィグレーションされたローカル サーバ ドメインに対してデプロイおよび実行します。管理対象サーバは使用されません。Workshop for WebLogic を使用してアプリケーションのデプロイ (公開) とテストを行うのがベスト プラクティスです。
ドメインが 1 つの管理サーバと 1 つの管理対象サーバまたはクラスタ構成の複数の管理対象サーバで構成される場合には、ポータル EAR ファイルを管理対象サーバまたはクラスタにデプロイすることを強くお勧めします。管理サーバにはデプロイしないでください。このように管理サーバを管理機能用に確保しておくと、管理サーバのヒープを小さくすることができます。また、管理サーバ上で管理機能をファイアウォール保護することもできます。
ステージング サーバおよびプロダクション サーバは、開発モードではなくプロダクション モードでコンフィグレーションするのがベスト プラクティスです。
アプリケーションを管理対象サーバに直接デプロイできる WebLogic Server の機能は、MSI (管理対象サーバ独立) モードと呼ばれます。MSI についての詳細と MSI の制限事項については、WebLogic Server ドキュメントの「管理対象サーバ独立モードについて」を参照してください。最も重要な制限事項は、管理サーバがダウンするとセキュリティ プロバイダ データを修正できないことです。さらに、もう 1 つの制限事項として、管理サーバがダウンすると、永続化のためにデプロイメント計画に書き込む必要のある WebLogic Portal コンフィグレーションが機能しません。
再デプロイとは、既存/稼働中/デプロイ済みのアプリケーションの新バージョンをデプロイすることを意味します。ポータル アプリケーションをステージングまたはプロダクション環境に再デプロイする場合には、前の節で説明したデプロイ手順と同じ手順を使用します。ただし、再デプロイする際には、伝播ツールを使用して個別の操作として、datasync やその他の WebLogic Portal 資産を目的のデータベースに伝播する必要があります。再デプロイの詳細については、「一般的な伝播のシナリオ」を参照してください。
J2EE 共有ライブラリを参照すると、WebLogic Portal の製品コードがアプリケーションに組み込まれます。これらのライブラリは、WebLogic Portal のインストールの一部になります。また、アプリケーション コードを含む独自の共有ライブラリを開発することもできます。J2EE 共有ライブラリを使用すると、アプリケーションのさまざまな部分の開発ライフサイクルを分離できます。これらのライブラリのバージョン管理やデプロイは個別に行うことができます。このため、単一の大きな EAR ファイルではなく、各ライブラリを個別に開発して配布することが可能です。
| ヒント : | J2EE 共有ライブラリの詳細については、WebLogic Server ドキュメントの「共有 J2EE ライブラリおよびオプション パッケージの作成」を参照してください。また、「チーム環境での J2EE 共有ライブラリの使用」および『WebLogic のポータル開発ガイド』も参照してください。 |
この節では、共有ライブラリに関する次の内容について説明します。
コード リスト 4-1 は、エンタープライズ アプリケーションのサンプル (myApp.ear) を示しています。記述子 weblogic-application.xml には、p13n-app-lib というライブラリに対する参照 (太字で表記) が含まれています。p13n-app-lib という名前以外に、ライブラリに関する情報は記載されていません。
エンタープライズ アプリケーションはこのライブラリを検索します。これは、<library-ref> 要素によって、サーバが同じ名前を持つデプロイ済みのライブラリを実行時に検索するためです。<library-ref> 要素ではバージョン情報が指定されていないため、サーバは利用可能な最新の (最も大きな) バージョン番号を検索します。共有ライブラリの名前とバージョン番号は、ライブラリそのもの (META-INF/MANIFEST.MF ファイル) に含まれています。次に例を示す。
META-INF/MANIFEST.MF
Extension-Name: p13n-app-lib
Specification-Version: 9.2.0
Implementation-Version: 9.2.0
詳細については、「ライブラリ バージョン」を参照してください。ポータル Web アプリケーションの WEB-INF/weblogic.xml ファイルには同じパターンが適用されます。
サーバで検索するには、共有ライブラリをライブラリとしてデプロイする必要があります。このデプロイメントは、実行可能なアプリケーションのデプロイメントとは異なります。ライブラリをライブラリとしてデプロイすると、ライブラリ ファイルがサーバに登録されて、参照元アプリケーションで利用できるようになります。
ライブラリをデプロイするには、WebLogic Server Console、weblogic.Deployer コマンド、wldeploy Ant タスク、または WLST スクリプトを使用します。これらのメソッドについては、WebLogic Server ドキュメントの「WebLogic Server Administration Console」、「weblogic.Deployer コマンドライン リファレンス」、「wldeploy Ant タスクのリファレンス」、および「WLST コマンドおよび変数リファレンス」を参照してください。
たとえば、WebLogic Server Console を使用すると、アプリケーションのデプロイとまったく同じ方法で共有ライブラリをデプロイできます (共有ライブラリと実行可能なアプリケーションを区別するチェックボックスが利用できる点を除く)。
コード リスト 4-2 は、コード リスト 4-1 のアプリケーションで参照される共有ライブラリに対応した、サーバ ドメインの config/config.xml ファイルのエントリを示しています。
<library>
<name>p13n-app-lib#9.2.0@9.2.0</name>
<target>myServer</target>
<module-type>ear</module-type>
<source-path>/bea/weblogic92/deployable-libraries/p13n-app-lib.ear
</source-path>
<security-dd-model>DDOnly</security-dd-model>
</library>
ライブラリ名が同じで異なるバージョン番号を持つ複数のライブラリをデプロイできます。アプリケーションで使用されるバージョン番号は、アプリケーションのコンフィグレーション ファイル META-INF/weblogic-application.xml または Web アプリケーションの weblogic.xml で指定されます。コード リスト 4-3 のようにバージョン番号が指定されない場合には、サーバで最も大きなバージョン番号を持つ p13n-app-lib という名前のデプロイ済みライブラリが選択されます。
<library-ref>
<library-name>p13n-app-lib</library-name>
</library-ref>
これに対して、アプリケーションで p13n-app-lib のバージョン 9.2.0 が使用できず、バージョン 9.2.1 以降が必要な場合には、コード リスト 4-4 のようにライブラリを参照できます。
<library-ref>
<library-name>p13n-app-lib</library-name>
<specification-version>9.2.1</specification-version>
</library-ref>
特定のバージョンのみを使用する必要がある場合には、コード リスト 4-5 のように <exact-match> 要素を指定できます。
<library-ref>
<library-name>p13n-app-lib</library-name>
<specification-version>9.2.0</specification-version>
<exact-match>true</exact-match>
</library-ref>
コンテンツ リポジトリを使用している場合には、送り先サーバ上に 1 つまたは複数のリポジトリを作成する必要があります。これを行うには、WebLogic Portal Administration Console を使用します (『コンテンツ管理ガイド』の説明を参照)。これは、ルート リポジトリのみを作成し、コンテンツの項目やタイプは作成しないことを意味します。環境の間で項目やタイプを移動するには、WebLogic Portal の伝播ツールを使用します。伝播ツールの詳細については、「伝播方針の開発」を参照してください。
また、コンフィグレーション ファイル META-INF/content-config.xml で、エンタープライズ アプリケーションのデフォルト コンテンツ リポジトリを指定することもできます。詳細については、「エンタープライズ アプリケーションのデプロイメント記述子」を参照してください。
単一クラスタ ドメインで複数のエンタープライズ アプリケーションを作成および実行できます。図 4-1 に示すように、単一のドメインで複数のエンタープライズ アプリケーション (EAR) をホストできます。各 EAR デプロイメントで複数の Web アプリケーションをホストでき、Web アプリケーションに応じて任意の数のデスクトップを作成できます。1 つのエンタープライズ アプリケーション (EAR) に関連付けられている Web アプリケーションおよびデスクトップは、別のエンタープライズ アプリケーションにある (切り離されている) Web アプリケーションおよびデスクトップに依存しません。
単一ドメインに複数のエンタープライズ アプリケーションをコンフィグレーションする場合、次の制限が適用されます。
| 注意 : | 各エンタープライズ アプリケーションは、それぞれの WebLogic Portal Administration Console を通じて管理する必要があります。ユーザ、グループなどの一部のドメインレベルのリソースは、エンタープライズ アプリケーションに関係なく、単一の WebLogic Portal Administration Console から表示および管理できますが、アプリケーションのデータはキャッシュされていることがあり、そのデータに対して別のアプリケーションの WebLogic Portal Administration Console から行われた更新は即時に表示されない場合があることに注意してください。 |
| 注意 : | 各エンタープライズ アプリケーションのコンテンツは、それぞれの WebLogic Portal Administration Console と仮想コンテンツ リポジトリを通じて管理されます。仮想コンテンツ リポジトリ (および WebLogic Portal Administration Console) は、各アプリケーションに対してユニークであり、共有できません。 |
ペスト プラクティスは、アプリケーションをデプロイする前にデプロイメント計画を使用して記述子の値を変更しておくことです。「デプロイメント計画の使用」を参照してください。また、WebLogic Server ドキュメントの「WebLogic Server のパフォーマンスとチューニング」関する説明も参照してください。
WebLogic Portal には、JSR-168 WAR ファイルにパッケージされた JSR 168 ポートレットを自動的にデプロイするユーティリティが用意されています。このユーティリティでは、JSR-168 ポートレットを格納した JSR-168 WAR をインポートして、WSRP プロデューサでポートレットを公開できます。
この節では、インポート ユーティリティの使い方を説明します。次のトピックが含まれています。
http://servername:port/earProjectNameAdmin
ここで、servername は管理サーバの IP 名、port はポート番号、earProject はサーバにデプロイされたポータル エンタープライズ アプリケーションの名前です。次に例を示す。
http://localhost:7001/myEarProjectAdmin
http://servername:port/earProjectAdmin/jsr168/jsr168import.jsp
ここで、servername は管理サーバの IP 名、port はポート番号、earProject はサーバにデプロイされたポータル エンタープライズ アプリケーションの名前です。次に例を示す。
http://localhost:7001/myEarProjectAdmin/jsr168/jsr168import.jsp
図 4-1 にユーティリティを示します。
この節では、インポート ユーティリティを使用して JSR-168 WAR ファイルをエンタープライズ アプリケーションにインポートする方法について説明します。
| ヒント : | [参照] ボタンを使用して WAR ファイルを見つけるか、[Add JSR-168 compliant .war] テキスト フィールドに直接パスを入力します。テキスト フィールドにパスを入力する場合は、〔Tab〕を押してパスを受け入れます。 |
startWebLogic.cmd または startWebLogic.sh を実行したディレクトリ) に配置されます。単一のサーバ環境の場合は、サーバの起動ディレクトリはドメイン ディレクトリです。管理対象サーバの場合は、サーバの起動ディレクトリは管理対象サーバのディレクトリです。
新しい EAR ファイルがデプロイされたら、インポートした WAR ファイルに格納されたポートレットをアプリケーションに追加できます。これを行うには、Web アプリケーションを WSRP プロデューサとして追加する必要があります。Web アプリケーションがプロデューサとして追加されたら、WebLogic Portal Administration Console を使用して WSRP プロデューサで行ったように、アプリケーションのポートレットを組み込むことができます。詳細については、『連合ポータル ガイド』を参照してください。
  
|
