Oracle Application Server から WebLogic Server …...Oracle Forms、Oracle Reports、Oracle Portal、Oracle Discoverer、Oracle B2Bなど）とその他の階層化製品のWebLogic

Oracle Application Server から

WebLogic Server へのカスタム

Java EE アプリケーションの

アップグレード

Oracle ホワイト・ペーパー 2009 年 7 月

Oracle Application Server から WebLogic Server へのカスタム Java EE アプリケーションのアップグレード

2

Oracle Corporation 発行「Upgrading Custom Java EE Applications from Oracle Application Server to WebLogic Server」の翻訳版です。

Oracle Application Server から Oracle WebLogic Server へのカスタム Java EEアプリケーションのアップグレード

1. はじめに ............................................................................................................................... 3 2. WebLogic Server へのアップグレードがもたらすメリット ........................................... 4 3. アップグレードの手法 ....................................................................................................... 5 4. OC4J ユーザーのための WebLogic Server の一般的な概念 ............................................ 7 5. WebLogic Server ベースの環境に向けた管理手順 ......................................................... 11 6. カスタム Java EE アプリケーションのアップグレード ............................................... 14 7. アップグレード済みアプリケーションのための

WebLogic Server ドメインの作成 .................................................................................... 19 8. Web 層 ................................................................................................................................. 25 9. クライアント・アプリケーションのアップグレード .................................................. 26 10. まとめ ................................................................................................................................. 31


3


Oracle Application Server から Oracle WebLogic Server へのカスタム Java EEアプリケーションのアップグレード

1. はじめに

2008 年 6 月 1 日の Web キャスト『BEA Welcome and Oracle Middleware Strategy』で概説されているとおり、Oracle Fusion Middleware 11g プラットフォームの戦略

的アプリケーション・サーバー・インフラストラクチャは、Oracle WebLogic Serverになりました。Oracle Internet Application Server の開発、保守、およびリリースは、

オラクルの標準ライフタイム・サポート・ポリシーに従って継続されます。長期

的に投資を保護し、シームレスなアップグレードを実現するために、Oracle Application Server（OracleAS）の主要コンポーネント（Oracle HTTP Server、Oracle Web Cache、Oracle Forms、Oracle Reports、Oracle Portal、Oracle Discoverer、Oracle B2B など）

とその他の階層化製品の WebLogic Server への集約と認定が行われました。

WebLogic Server の採用により、これらの製品のアップグレードに大きな影響が及

ばないように、Oracle Fusion Middleware 11g Release 1 では、アップグレード・ツー

ルが提供されています。下層レベルに関しては、OracleAS の基盤をなす Java サー

バー・ランタイムである Oracle Containers for J2EE（OC4J）の主要なテクノロジー

もまた、WebLogic Server に統合されています。

WebLogic Server にアップグレードし、OC4J から集約されたサーバー・インフラス

トラクチャへと、カスタム Java EE アプリケーションを再デプロイするには、アプ

リケーション・サーバーの新規メジャー・リリースへアップグレードする場合と同

じように、アップグレード計画を策定する必要があります。また、これらのアプリ

ケーションの実行に関連する管理手順の変更についても把握する必要があります。

この影響を最小限にとどめ、十分な理解を促すため、オラクルは、このプロセスを

推進するドキュメントとツールからなる包括的なセットを提供しています。

より具体的に言うと、WebLogic Server へのカスタム Java EE アプリケーションの

アップグレードを大幅に簡素化する WebLogic SmartUpgrade ツールの提供が計画

されています。また、Oracle Fusion Middleware 11g Release 1 には、『Oracle® Fusion Middleware Java EE アップグレード・ガイド』が含まれており、OC4J をベースと

した既存のカスタム Java EEアプリケーションとその環境をWebLogic Serverにアッ

プグレードするために必要な作業について、詳しい説明が提供されています。

WebLogic SmartUpgrade ツールと『Oracle® Fusion Middleware Upgrade Guide for Java EE』、そして関連するベスト・プラクティスや、該当するコンサルティング・サー

ビスおよび教育サービスを組み合わせて利用することで、WebLogic Server へのカ

スタム Java EEアプリケーションのアップグレードが体系的かつシームレスに実行

できるだけでなく、必要な管理手順の修正が簡素化されます。このホワイト・ペー

パーは、これらの導入部分としての役割を果たします。

このホワイト・ペーパーの対象読者は、OracleAS 10g Release 3 を使用しており、

カスタムの OC4J Java EE アプリケーションの開発、または OC4J 環境の保守を担


4


当している方々です。本書の目的は、OC4J ユーザーに対して WebLogic Server の概念を紹介するとともに、OC4J 10g Release 3 から WebLogic Server 11g（10.3.1）へ

と、カスタム Java EE アプリケーションをアップグレードする作業についての予備

知識を提供することにあります。主要な WebLogic Server 用語は、初出時にイタリッ

ク体で表記され、WebLogic Server ドキュメントの関連項目へリンクされています。

2. WebLogic Server へのアップグレードがもたらすメリット

Oracle WebLogic Server は、Oracle Fusion Middleware、BEA から新たに買収した製

品ライン、Oracle Applications ポートフォリオ、そして近日提供予定の Oracle Fusion Applications の戦略的ランタイムとなっただけでなく、Oracle Application Server で提供された機能を上回る多大な追加機能を提供します。次に、その例を挙げます。

1. ランタイム：コア・コンテナの領域において、WebLogic Server は Java EE 5.0 に対する完全な互換性に加え、数々の領域でランタイムを拡張してい

ます。例としては、Java Message Service（順序単位と作業単位を使用した

メッセージの順序付け、宛先分散によるスケールアウト、ストア・アン

ド・フォワード・インフラストラクチャ、C および.NET の JMS クライア

ント）、Web サービス（対話型 Web サービス、バッファリングされた

Web サービス、非同期 Web サービス、SOAP over JMS）、Oracle Tuxedo統合の組込み、ランタイム・チューニング（自己調整型ワーク・マネー

ジャ）があります。

2. 開発：開発機能の領域では、基本サーバーの機能に加えて、テスト/デバッ

グのサイクルを短縮する、サーバーの再起動を必要としない Java クラス

FastSwap 機能、緊密に統合された IDE 環境のための分割開発、AJAX ア

プリケーション向けの HTTP パブリッシュ・サブスクライブ・サーバー、

フィルタリング・クラス・ローダーによる複数バージョンのクラス・ラ

イブラリの処理、開発/デプロイ/構成を自動化する Ant タスク、Eclipse と

Oracle JDeveloper の緊密な統合などが提供されています。

3. 運用と管理：運用と管理の領域では、トランザクションおよびバッチの

構成、停止時間ゼロの再デプロイ、ドメイン・テンプレート・ビルダー

と構成ウィザードによるクローニングの簡素化、WebLogic Scripting Toolによる、すべてのサーバー構成で一貫したスクリプトおよびコマンドラ

イン・ツール、アプリケーションとコンテナに対する高度なライフサイ

クル管理、診断フレームワークをはじめとし、多くの領域で基本的なサー

バー機能が拡張されています。

4. 高可用性：高可用性の領域では、コア機能の他に、クラスタリング JNDI、Whole Server Migration、サービス移行、可用性の高いシングルトン・サー

WebLogic Server は、Oracle Application Server の機能を上

回る多大な付加価値を提供し

ます。


5


ビス（JMS、JTA、ユーザー定義）、パッチのローリング・アップグレード

などが実現されています。

3. アップグレードの手法

OC4J から WebLogic Server へとカスタム Java EE アプリケーションをアップグレー

ドする場合、通常のアプリケーション拡張プロジェクトとして実行する必要があ

ります。また、可能な限り、確立されたソフトウェア開発手法や適切なベスト・

プラクティスに従う必要があります。図 1に、アップグレード・プロジェクトの

ライフサイクル内で考慮すべきカテゴリと具体的なアップグレード・アクティビ

ティの流れを示します。

図 1 - プロジェクトのライフサイクルにおける OC4J から WebLogic Server へのアップグレード・アクティビティ

これらのアップグレード・アクティビティは、このホワイト・ペーパーの内容と

直接的な関係があります。表 1に、各アップグレード・アクティビティの説明と

関連する章へのリンクを示します。

表 1 - OC4J から WebLogic Server へのアップグレード・アクティビティ

アクティビティ説明章

プロジェクト計画のアクティビティ

OC4J と WebLogic Server の概念的相違点の把握

2 つのアプリケーション・サーバー・テクノロジーには多数の

類似点がありますが、中心にある概念的な違いも数多くあります。

これらの相違点については、アップグレード・プロジェクトを

開始する前に十分に理解しておく必要があります。

4

管理手順に対する必要な修正の評価

OC4J ベースの環境と WebLogic Server では、一般的な管理機能

に大きな違いはありません。ただし、2 つの管理モデルにはいく

5


6


らかの違いがあるため、アップグレードした後で管理手順を修

正しなければならない場合があります。影響範囲を把握し、適

切に修正計画を立てるため、必要な修正を評価する必要があり

ます。

プロジェクト開発のアクティビティ

アプリケーションのアップグレード

アプリケーションのアップグレードは、おもに 2 つのタスクで

構成されています。まず、OracleAS 固有の API が使用されてい

るかどうかについてアプリケーション・コードを解析し、使用

されている個所に対しては、WebLogic Server 環境で正しく機能

するように、推奨されるアクションを実施します。次に、OC4J固有のデプロイメント・ディスクリプタが使用されているかど

うかを解析し、その機能を関連する WebLogic Server の構成に

マップします。

6

ターゲット開発環境の構築

アップグレード・プロジェクトの開発作業中、アプリケーショ

ンをホストし、実行するため、ターゲットとなる WebLogic Server の開発ドメインを構築し、ソースの OC4J 開発環境の構

成を反映させる必要があります。

7

アプリケーション・クライアント

のアップグレードアップグレードされたアプリケーションに合わせるため、アッ

プグレード対象のアプリケーションのインタフェース・クライ

アントにも調整が必要になる場合があります。

8

プロジェクトの検証およびロールアウトのアクティビティ

ターゲットの品質保証（QA）環境の構築

アップグレード・プロジェクトの QA 作業中、アプリケーショ

ンをホストし、実行するため、ターゲットとなる WebLogic Server の QA ドメインを構築し、ソースである OC4J の QA 環境

の構成を反映させる必要があります。

7

ターゲットのステージング環境

と本番環境の構築アップグレードされたアプリケーションをホストし、実行する

ため、ターゲットとなる WebLogic Server のステージング・ドメ

インおよび（または）本番ドメインを構築し、ソースである OC4J環境をそれぞれに反映させる必要があります。

7


7


4. OC4J ユーザーのための WebLogic Server の一般的な概念

WebLogic Server テクノロジーと OC4J Java EE コンテナ・テクノロジーを比較する

場合、サーバー・インスタンスのレベルから始めると分かりやすいでしょう。

WebLogic において、WebLogic Server インスタンスとは、Oracle WebLogic Serverコンテナの構成コードを実行する Java VM プロセスを指します。WebLogic Serverコンテナは、Java EE 仕様で規定されたすべての API およびサービスに加えて、

WebLogic 固有の拡張機能を提供します。この点において、WebLogic Server イン

スタンスは、OC4J インスタンスに極めて似ていると考えられるでしょう。この類

似性を念頭に置きながら、ここでは、WebLogic Server と OC4J の間にあるもっと

も基本的な概念的相違点について説明します。

常に WebLogic Server ドメインに含まれる WebLogic Serverインスタンス

WebLogic Server には、スタンドアロンまたは OracleAS の OC4J 構成に相当する概

念はありません。その代わり、WebLogic Server インスタンスは、常にWebLogic Server ドメインのコンテキスト内で実行される必要があります。OC4J の概念のう

ち WebLogic Server ドメインにもっとも近いのは、1 つまたは複数の Oracle ホーム

で、Oracle Process Manager and Notification（OPMN）サービスの一部として構成さ

れた、一連の OC4J インスタンスです。ただし、ドメインは、管理上のグループ

化および構成の範囲設定を行うための、より一般的なメカニズムであり、一連の

サーバーおよび（または）クラスタを含みます。ドメインの構成は、ドメイン・

ディレクトリ内に保管されます。

管理サーバーにより管理、構成、監視される WebLogic Serverドメイン

クラスタ内の OC4J インスタンスは、Oracle Enterprise Manager Application Server Control と OPMN インフラストラクチャの組合せにより管理、構成、および監視さ

れますが、WebLogic Server ドメインは、ドメイン管理サーバーと呼ばれる、中央

の WebLogic Server インスタンスにより管理、構成、および監視されます。

管理サーバーは、以下の機能を持つ特殊なアプリケーション・セットで構成され

る点を除けば、その他すべての WebLogic Server インスタンスと同じです。

• ドメイン内のすべてのサーバーに対する構成情報のリポジトリを保持し、

この情報をドメイン・サーバーと自動的に同期する機能を提供します。

• ドメイン内のサーバーおよびクラスタからなる任意のサブセットに対して、

集中型のアプリケーション・デプロイ・サーバーとしての役割を果たします。


8


• OC4J における Oracle Enterprise Manager Application Server Control と同じよ

うな、ブラウザベースの管理コンソール・アプリケーションを提供します

が、ドメインを構成する複数のサーバーおよびクラスタを対象にできます。

1 台の管理サーバーを除く、ドメイン内のすべての WebLogic Server インスタンス

は、管理対象サーバーと呼ばれます。

また、管理サーバーのみ（管理対象サーバーなし）でドメインを構成し、Java EEアプリケーションのデプロイ・ターゲットとして使用することもできます。この

ようなシナリオは、スタンドアロンの OC4J 構成とよく似ています。

図 2では、類似した 2 つのサンプル・トポロジを使用して、これらの相違点を図

解します。

図 2 - OC4J と WebLogic Server インスタンスのトポロジ比較

単一 WebLogic Server インストールによる複数の

ドメインの構成

OC4J のインストールは一連の OC4J インスタンス構成と直接的に関連付けられて

おり、これらの構成はインストール・バイナリを含む ORACLE_HOME ディレクト


9


リのサブディレクトリに保管されています。また、ファイル・システムを通じて

直接関連付ける必要があるだけでなく、OC4J バイナリとインスタンス構成はイン

スタンス単位で関係を持つ必要があります。

対照的に、WebLogic Server では、インストールされたソフトウェアとその各種構

成インスタンスは明確に分離されています。この分離を可能にするのが、WebLogic Server ドメインです。単一の WebLogic Server インストールを使用して複数のドメ

インを作成する場合、ドメインごとに異なるサーバー・セットを指定することが

でき、ドメインの構成ディレクトリはファイル・システム内の任意の場所に保管

できます。WebLogic Server インスタンスをドメイン・ディレクトリから実行する

ために必要とされるのは、WebLogic Server のインストール・ディレクトリをアク

セス可能にすることだけです。また、WebLogic Server モデルでは、WebLogic Serverのバイナリとインスタンス構成はドメイン（インスタンス・セット）レベルで関

係を持ちます。

図 3 - OC4J と WebLogic Server におけるインストールと構成の比較


10


常に単一の Java VM プロセスに関連付けられる

WebLogic Server インスタンス

OPMN の numproc 設定を使用すると、複数の Java VM 上で OC4J インスタンス

の複数のコピー（構成とデプロイされたアプリケーションはまったく同じ）を実

行するよう設定できます。WebLogic Server インスタンスは常に単一の Java VM 上

で実行されるため、これに該当する WebLogic Server の設定はありません。ただし、

同一ホスト上で実行される複数の管理対象サーバーに対して、等しい構成を適用

すると、同じ結果が得られます。

すべてのアプリケーション・リクエストを同じポートで処理する

WebLogic Server インスタンス（デフォルト）

OC4J インスタンスは、リクエストを受け入れるプロトコルごとに異なるリスニン

グ・ポート・セットを使用します。たとえば、OC4J の"Web サイト"は、HTTP、HTTPS、AJP、または AJPS に対して、それぞれ OC4J インスタンスの特定ポート

（またはポート範囲）を設定するために使用されます。同様に、OC4J インスタン

スに、RMI および JMS トラフィック用の専用ポート（およびポート範囲）を設定

できます。これらのポートは、通常、OracleAS の Oracle ホーム内にある opmn.xml構成ファイルに設定されています。スタンドアロン OC4J を実行している場合は、

server.xml、rmi.xml、*-web-site.xml、および jms.xml ファイルに設定されています。

WebLogic Server と OC4J のリクエスト・ポートおよびプロトコル管理モデルには、

デフォルトで、2 つの重要な相違点があります。まず、WebLogic Server インスタ

ンスは、受信するアプリケーション・リクエストに対して、2 つのリスニング・

ポートのみを使用するよう設定されています。1 つは暗号化されていないプレー

ン･リクエストの受入れ用（設定は必須）であり、もう 1 つは SSL 暗号化リクエ

ストの受入れ用（任意）です。2 番目に、これらのポートは、特定のプロトコル

専用に指定されている OC4J インスタンスの場合と異なり、サポートされるすべ

てのリクエスト・プロトコルを受け入れるよう設定されています。

通常、このデフォルト・モデルは、大部分のユースケースにおいて十分であるこ

とが実証されていますが、ネットワーク・チャネルと呼ばれる WebLogic Server機能を利用すると、WebLogic Server インスタンスに追加のポートを設定し、特定

のプロトコル専用にすることができます。上記のような構成が必要とされる特別

なユースケースでは、この機能を使用できます。

常に HTTP リスナーが設定されており、AJP をサポートしない

WebLogic Server インスタンス

Oracle Application Serverでは、複数のOC4Jインスタンスの前面にOracle HTTP Serverを配置することも、OC4J インスタンスごとにローカルのインプロセス HTTP サー

バーを実行することもできます。顧客にとってもっとも一般的な構成は、組込み

の OC4J HTTP サーバーではなく Oracle HTTP Server を使用する方法です。Oracle HTTP Server 構成の場合、受信する HTTP トラフィックは、Oracle HTTP Server サー

バーと OC4J サーバー間で、最適なプロトコルである AJP に変換されます。


11


一方、WebLogic Server インスタンスは常に HTTP リクエストを受け入れなければ

ならず、AJP はサポートされていません。ただし、WebLogic Server ドメインの前

面に、セキュリティとスケーラビリティを目的とする Web 層を配置することは可

能であり、実際に数多く見受けられます。Oracle HTTP Server を含む多数の Webサーバーが、WebLogic Server ドメイン内のサーバーに対する Web 層として認定さ

れています。このような Web 層を WebLogic Server の前面に配置する場合、2 層間

で使用されるプロトコルは HTTP のままです。

5. WebLogic Server ベースの環境に向けた

管理手順

OC4J と WebLogic Server では、一般的な管理機能に大きな違いはありませんが、2つの管理モデルにはいくらかの重要な違いがあるため、WebLogic Server にアップ

グレードする場合、OC4J をベースとする既存の環境における管理手順を修正しな

ければならない場合があります。ここからは、これらの違いをさまざまな観点か

ら説明していきます。

環境の構築、保守、およびアプリケーションの

プロビジョニング

表 2に、おもな WebLogic Server 管理ツールの一覧を示します。各ツールの機能を

説明するとともに、OC4J ベースの同様のツールと比較します。

表 2 - おもな WebLogic Server 管理ツールと相当する OC4J ツール

WebLogic Server ツール説明および OC4J との比較

インストール・プログラムターゲット・ファイル・システム上に、WebLogic Server バイナリの物理イメー

ジを作成するには、WebLogic Server インストール・プログラムを使用します。

このツールは、OC4J を含む OracleAS 10g コンポーネントに対する Oracle Universal Installer パッケージと同様の役割を果たします。

WebLogic Server インストーラを実行する方法には、グラフィカル・モード（GUI）、コンソール・モード（コマンドライン）、およびサイレント・モード（パラメー

タとして入力ファイルを提供）があります。WebLogic Server インストール・プ

ログラムと OracleAS 10g の Oracle Universal Installer のおもな違いは、前者がサー

バー・インスタンスの構成に使用されるのに対して、後者は使用されないとい

う点にあります。また、WebLogic Server をインストールする場合、必ずこのイ

ンストール・プログラムを使用する必要があります。スタンドアロンの OC4J構成のように、zip ファイルを解凍してインストールできるものはありません。

構成ウィザード WebLogic Server 構成ウィザードは、WebLogic Server ドメインの作成プロセス

を簡素化するツールです。OC4J インスタンスにはドメインという概念が存在

しないため、OracleAS の構成ウィザードに相当するツールはありません。


12


WebLogic Server 構成ウィザードを実行する方法には、グラフィカル・モード

（GUI）とコンソール・モード（コマンドライン）があります。

管理コンソール WebLogic Server 管理コンソールは、ドメインの管理サーバー上にデプロイされ

た Web ベースのユーザー・インタフェースであり、WebLogic Server ドメイン

の管理に使用されます。このツールは、OC4J インスタンスに対する Oracle Enterprise Manager Application Server Control と同様の役割を果たします。

WebLogic Server 管理コンソールを使用して実行できる、おもなドメイン管理タ

スクには、サーバー・インスタンスの構成、起動、および停止、Java EE リソー

ス（JMS 宛先や JDBC データソースなど）の作成、ドメイン内の任意のサーバー

への Java EE アプリケーションのデプロイ、セキュリティの設定、サーバーと

そのパフォーマンスの監視があります。

WebLogic Scripting Tool （WLST）

WebLogic Scripting Tool（WLST）は、コマンドラインのスクリプティング・イ

ンタフェースであり、WebLogic Server ドメインの管理に使用できます。この

ツールは、WebLogic Server コンソールと同じ機能を提供しており、Oracle Application Server のコマンドライン・ユーティリティ（admin_client.jar、jazn.jar、opmnctl、および dcmctl）と同様の役割を果たします。

管理者は、WebLogic Server スクリプトを作成することで、WebLogic Server 環境のプロビジョニングと保守を自動化できます。WebLogic Server 環境は、Jythonをベースとしています。このため、管理者は、WebLogic Server コマンドにカス

タム Jython スクリプトを組み合わせるという柔軟性が得られ、WebLogic Server環境の管理が容易になります。OC4J では、上記に相当する単一のスクリプト

言語およびツールはありません。

weblogic.Deployer WebLogic Server では、パッケージ化されたデプロイ・ツールとして、weblogic.Deployerが提供されています。このツールは、ears、wars、rars、jars、およびその他のデ

プロイ・アーチファクトを WebLogic Server にデプロイするサービスを提供し

ます。weblogic.Deployer では、WebLogic のデプロイ API を使用して実装できる

デプロイ処理であれば、一部でも全部でも、すべてを実装できます。

このツールは、Java EE アーチファクトのデプロイにおける OC4J の admin_client.jarと同様の機能を提供します。以前の OC4J リリースでは、OC4J へのデプロイは

admin.jar および dcmctl ツールによって実行されていました。

Ant タスク WebLogic Server が提供する管理用 Ant タスクを使用すると、WebLogic Serverの管理プロセスを Apache Ant スクリプト内で実行できます。これらの Ant タス

クは、OC4J の Ant タスクと同様の役割を果たします。

アップグレードされたアプリケーションのホスティングに適したWebLogic Serverドメインを作成するため、カスタム Java EE アプリケーションのアップグレード

において、環境構築、保守、およびアプリケーション・プロビジョニングを行う


13


すべての既存プロセスを変更して、表 2の該当する WebLogic Server ツールを使用

する必要があります。

サーバーの起動と停止

各種の OracleAS 管理ツールを使用して、OC4J インスタンスを起動および停止で

きるのと同様に、ドメイン内の WebLogic Server インスタンスもまた、表 2に記載

した該当ツールを使用して起動と停止の操作を実行できます。また、WebLogic Server インスタンスは、ドメイン・ディレクトリの/bin サブディレクトリにある起

動スクリプト（管理サーバーの場合：startWebLogic.cmd|sh、管理対象サーバーの場

合：startManagedWebLogic.cmd|sh）を使用して起動することもできます。WebLogic Server インスタンスの起動と停止に関して取り得る方法とその影響について、詳

しくはWebLogic Server のドキュメント・ページを参照してください。

アプリケーションの診断とロギング

診断

WebLogic Server の診断機能を提供するのは、WebLogic Diagnostics Framework（WLDF）です。WLDF は、OracleAS Dynamic Monitoring Serviceと同等、またはそ

れ以上の機能を提供します。動的コード計測、イメージ・キャプチャ、監視、通

知を含むこれらの機能により、アプリケーション診断機能が拡張されるため、保

守対象の Java EE アプリケーションの総所有コストが大幅に削減されます。また、

WLDF コンソール拡張機能を利用すると、WebLogic Server 管理コンソール内のカ

スタム・ダッシュボードから WLDF 機能を使用できます。"カスタム Java EE アプ

リケーションのアップグレード"の章に説明されているとおり、OracleAS Dynamic Monitoring Service を現在使用しているアプリケーションでは、引き続き、Oracle Fusion Middleware 11g でもこの機能を使用できます。

さらに、WebLogic Server では、CA Wily Introscope や HP OpenView などのサード・

パーティ製のアプリケーション管理ツールに対して、幅広く手厚いサポートが提

供されています。したがって、通常、このようなツールに管理されている環境は、

容易に更新でき、WebLogic Server 上で実行されるアップグレード済みアプリケー

ションに対して、以前と同様に機能します。

ロギング

WebLogic ロギング・サービスは、OracleAS のあらゆるロギング機能に匹敵する、

包括的なロギング機能のセットを提供します。また、WebLogic Server には、Oracle Java Required Files（Oracle JRF）テンプレートを介して、Oracle Diagnostics Loggingフレームワークの機能も組み込まれています。このテンプレートは、"カスタム

Java EE アプリケーションのアップグレード"の章で説明されているとおり、Oracle Fusion Middleware 11g Release 1 から利用できます。したがって、アプリケーショ

ンが Oracle Diagnostics Logging フレームワークを直接使用してロギングを行って

いる場合、アップグレードのために変更を行う必要はありません。Oracle JRF と

Oracle Diagnostics Logging の WebLogic Server への統合の詳細は、以下のとおりです。


14


• Oracle Diagnostics Logging ログ・メッセージは、WebLogic Server ログ・ファ

イルとは別のファイル・システムに保管されているログ・ファイルに送信

されます（<ドメイン・ディレクトリ>/servers/<サーバー名>/logs/<サーバー

名>-diagnostic.log ファイル）。

• 重大なメッセージ（エラー）は、Oracle Diagnostics Logging および WebLogicドメインの両方のログ・ファイルに二重に記録されます。

• Oracle Diagnostics Logging のログ問合せと構成の JMX MBeans は、ドメイ

ンの WebLogic 管理サーバーにあります。

スレッド・プールのパフォーマンス・チューニング

OC4J サーバー・インスタンスには、目的別の各種スレッド・プールが含まれてい

ます（起動時のデフォルト・スレッド・プールは、system、http、jca）。それぞれ

のスレッド・プールのパラメータ（最大/最小スレッド・カウントなど）は個別に

調整できるため、特定の環境に合わせてアプリケーション・リクエストのスルー

プットを最適化できます。

WebLogic Server インスタンスのスレッド・プールはデフォルトで 1 つであり、そ

のスレッド・カウントは、全体のスループットを最大化するように自動的に調整

されます。すべてのリクエストは、到着次第すぐに共通キューにエンキューされ、

管理上設定された目標（アプリケーションの希望応答時間など）に従って、また

は利用可能なすべてのスレッドを他のアプリケーションとの間で公平に使用する

ように優先順位が付けられます。WebLogic ワーク・マネージャと呼ばれるこの機

能により、WebLogic Server インスタンスは、リクエスト処理を最適化するように

スレッド・カウントを自己調整できます。

6. カスタム Java EE アプリケーションのアップグレード

表 3に示すとおり、WebLogic Server 11gがサポートするおもな Java SE/EE標準は、

OC4J 10.1.3がサポートする標準と同等か、より新しいバージョンになっています。

このため、WebLogic Server へのデプロイのために、これらの標準に依存するコー

ド要素を変更する必要がないため、OC4J からアプリケーションをアップグレード

する作業が大幅に簡素化されます。

表 3 - OC4J と WebLogic Server における Java 標準サポート

Java 標準 WebLogic Server 11g のサポート OC4J 10.1.3 のサポート

Java SE 6.0 6.0

Java EE 5.0 1.4/5.0

JSP 1.1 から 2.1 1.1 から 2.0

JSF 1.1 および 1.2 1.1


15


サーブレット 2.2 から 2.5 2.2 から 2.5

EJB 2.1 および 3.0 2.1 および 3.0

JAX-WS 2.1 サポートなし

JAX-RPC 1.1 1.1

JMS 1.0.2b および 1.1 1.0.2b および 1.1

JNDI 1.2 1.2

JCA 1.5 1.5

JTA 1.1 1.1

JMX 1.2 1.2

Java EE Deployment

1.2 1.0

Java EE Management

1.1 1.0

JDBC 3.0 および 4.0 3.0

ただし、WebLogic Server ドメインにデプロイし、そこで実行できるように、OC4Jベースのアプリケーションをアップグレードするには、アプリケーションで使用

されている OracleAS の拡張 API を適切に処理するとともに、アプリケーションで

使用されている OC4J 固有のデプロイメント・ディスクリプタを、WebLogic Server固有のデプロイメント・ディスクリプタおよび（または）機能に正しくマップす

る必要があります。ここからは、これらのアップグレード・タスクについて詳し

く説明していきます。

Web サービスのアップグレード

一般に、OC4J から WebLogic へ Web サービスをアップグレードする場合、OC4Jの API に相当する JavaWeb サービス API（特に JAX-RPC）を WebLogic Server で使用することが顧客から期待されます。これには、多くの場合、WebLogic Serverの Web サービス・ツールを使用して、基盤となる同一の Java ビジネス・ロジック

に対して WebLogic Server で Java アーチファクトを再生成する必要があります。

Java EE に Web サービス標準が存在していない、旧リリースの OC4J を使用してい

る場合、WebLogic Server で、Java EE 5.0 標準である JAX-WS にアップグレードす

ることを推奨します。特定の OC4J Web サービス公開 API（その WSDL）に対し

て完全な忠実性を実現するために、OC4J の WSDL を使用して WebLogic Server でWeb サービスを再生成し、その結果の Web サービスを WebLogic Server にデプロ

イすることもできます。

同等のデプロイ可能な Web サービス・アーチファクトを WebLogic Server で生成

したら、2 番目の管理手順として、相当するサービス品質機能（WS-Security や

WS-ReliableMessaging など）を適用する必要があります。表 4に示すとおり、


16


WebLogic Server は、WS-Reliability を除いて、OC4J がサポートするすべての Webサービス標準および仕様をサポートしています。

また、WebLogic Server 11g では、データベース Web サービスのサポートが追加さ

れているため、OC4J ベースのデータベース Web サービスをシームレスにアップ

グレードできます。

表 4 - OC4J と WebLogic Server における Web サービス標準および仕様のサポート

Web サービス仕様 WebLogic Server 11g OC4J 10.1.3

SOAP 1.1 および 1.2

WSDL 1.1

WS-I 1.0 および 1.1

XML Signature

XML Encryption

SAML

WS-Addressing

WS-Security

WS-SecurePolicy

WS-Policy

WS-PolicyAttachment

WS-Trust

WS-SecureConversation

WS-ReliableMessaging

WS-Trust

WS-Conversation

WS-Reliability

Oracle Application Server 拡張 API の仕様

Oracle Java Required Files

Oracle Fusion Middleware 11g Release 1 には、Oracle Java Required Files（Oracle JRF）と呼ばれるWebLogic Server ドメイン・テンプレートが含まれています。これを利

用すると、OracleAS 10g の一部の機能を更新したものが設定された WebLogic Serverドメインを作成（または拡張）できます。Oracle JRF テンプレートがサポートす

る OracleAS 機能は、以下のとおりです。

• OracleAS Dynamic Monitoring Service


17


• OracleAS Diagnostics and Logging Framework

• OracleAS HTTP Client

• OracleAS Java Object Cache

• OracleAS XML

• OracleAS Security Developer Tools

• OracleAS Globalization Development Kit

上記 API を使用しているアプリケーションでは、Oracle JRF 拡張ドメインを利用

できるため、これらの API が更新された場合に必要な変更以外は必要ありません。

Oracle JAZN（Java Authorization）API

Oracle JRF レイヤーには、Oracle Platform Security Services APIと呼ばれる、Oracle JAZN API を更新したものが含まれています。現在、Oracle JAZN API を使用して

セキュリティ管理を行っているアプリケーションは、この API の Oracle Platform Security Services バージョンを使用するように更新することで、アップグレードの

一環として、Oracle JRF 拡張の WebLogic Server ドメインにデプロイできるように

なります。

その他の Oracle Application Server API

OracleAS の拡張 API をアプリケーションで使用している場合に、WebLogic Serverへアップグレードするための準備として、推奨される対処方法を表 5に示します。

表 5 - Oracle Application Server API 向けの推奨アップグレード方法

Oracle Application Server API

推奨されるアップグレード方法

Oracle TopLink ターゲットの WebLogic Server ドメインで JPA 永続性プロバイダとして使用するよ

うに設定することで、Oracle TopLink を引き続き使用できます。WebLogic Server 11gの現在の製品バージョンに対して、Oracle TopLink の完全サポートが認定されてい

ます。

Oracle JSP タグ・ライブラリ

アプリケーションで使用されるOracle JSPタグ・ライブラリに関連付けられたOracleAS 10g の TLD および JAR ファイルが、WEB-INF/tld ディレクトリおよび WEB-INF/libディレクトリに配置されている限り、Oracle JSP タグ・ライブラリを引き続き使用

できます。

Oracle Web Cache の無効化

WebLogic Server にデプロイされたアプリケーションから、適切な OracleAS 10g の

jar ファイルを使用できるようにすることで、Web Cache の無効化 API を引き続き

使用できます。Oracle Fusion Middleware 11g Release 1 では、この API の更新バー

ジョンで、下位互換性のあるものが提供されています。

OracleAS Web サービス OracleAS Web サービスを使用しているすべてのアプリケーションで、Oracle Fusion


18


Oracle Web サービス・プロキシ

Oracle Web サービス SOAP

Oracle Web サービス UDDI クライアント

Middleware または WebLogic Server における同等の API および機能を使用するよう

変更する必要があります。具体的には、以下に従います。

OracleAS Web サービス、Oracle Web サービス・プロキシ、および（または）Oracle Web サービス SOAP の API を使用しているアプリケーションは、WebLogic Serverの標準ベース（JAX-RPC または JAX-WS）Web サービス API を使用するように変

更します。

Oracle Web サービス UDDI クライアント API を使用しているアプリケーションは、

UDDI v1、v2、または v3 に準拠した Oracle Service Registry UDDI クライアント APIを使用するように変更します。

JSP 向けの OC4J サポート Oracle JSP 独自の拡張を使用しているすべてのアプリケーションは、WebLogic Serverの JSP インフラストラクチャを使用するように変更する必要があります。標準 JSPを使用している場合、WebLogic Server へ移行する際に変更を行う必要はありませ

ん。

OC4J JMX MBeans アプリケーションおよび環境を管理する目的で、OC4J JMX MBeans を直接使用し

ているすべてのアプリケーションは、相当する WebLogic Server JMX MBeans を使

用するように変更する必要があります。

OC4J 固有のデプロイメント・ディスクリプタの使用

デプロイメント・ディスクリプタのセキュリティ要素

"アップグレード済みアプリケーションのための WebLogic Server ドメインの作成"の章に説明されているとおりに、ターゲットの WebLogic Server ドメインのセキュ

リティが設定されている場合、標準 Java EE アプリケーションのデプロイメント・

ディスクリプタ（web.xml や ejb-jar.xml など）に含まれるセキュリティ設定（認証

方式、セキュリティ制約、EJB メソッド・パーミッションなど）を変更する必要

はなく、アップグレード後も引き続き機能します。OC4J 固有のディスクリプタに

指定されたセキュリティ設定（セキュリティ・ロール・マッピングなど）について

は、WebLogic Security のドキュメントを参照して、相当する WebLogic Server デプ

ロイメント・ディスクリプタ（表 6を参照）内の要素に各設定をマップする必要

があります。

その他のデプロイメント・ディスクリプタ要素

WebLogic Server にデプロイする準備として、すべてのアプリケーションで使用し

ている OC4J 固有のデプロイメント・ディスクリプタを削除し、相当する WebLogic Server 固有の設定で置き換える必要があります。これには、使用している各デプ

ロイメント・ディスクリプタの要素を調査し、以下の措置のうち適切なものを講

じる必要があります。

1. OC4J デプロイメント・ディスクリプタが提供する機能の中には、表 6に示す、相当する WebLogic Server 固有のデプロイメント・ディスクリプタ

内の機能に直接マップされるものもあります。このような場合は、デプ


19


ロイの前に、相当する WebLogic Server ディスクリプタの適切な要素と値

をアプリケーション内に作成します。

2. OC4J デプロイメント・ディスクリプタが提供する機能の中には、WebLogic Server ドメイン（サーバー・インスタンス、サーバー・リソースなどの任

意のレベル）の固有の設定を通じて実現されるものもあります。このよ

うな場合は、必要なドメイン設定について WebLogic Server のドキュメン

トを参照した上で、ターゲット・ドメインに必要な変更を加えます。

近日提供予定の Oracle WebLogic SmartUpgrade ツールでは、特定の OC4J デプロイ

メント・ディスクリプタ要素から相当する WebLogic Server 要素へのマッピング機

能が提供されます。また、『Oracle Fusion Middleware Java EE アップグレード・ガ

イド』では、OC4J固有のデプロイメント・ディスクリプタ要素からWebLogic Server設定へのマッピングがカテゴリごとに詳しく説明されています。

表 6 - OC4J および WebLogic Server 固有のデプロイメント・ディスクリプタ

OC4J デプロイメント・ディスクリプタ

WebLogic Server デプロイメント・ディスクリプタ

orion-application.xml weblogic-application.xml、application.xml

orion-web.xml weblogic.xml

orion-ejb-jar.xml weblogic-ejb-jar.xml、weblogic-cmp-jar.xml

orion-application-client.xml weblogic-appclient.xml

oc4j-ra.xml weblogic-ra.xml

oracle-webservices.xml weblogic-webservices.xml

デプロイメント・プラン

デプロイメント・プランは、Java EE サーバーの標準機能であり、WebLogic Serverと OC4J の両方でサポートされています。デプロイメント・プランはアプリケー

ション・サーバー間で移植可能ではありませんが、OC4J の場合と同様に、WebLogic Server においても、デプロイ・プロセスの一貫として容易に生成および保管でき

ます。また、weblogic.PlanGeneratorコマンドライン・ツールを使用して作成する

こともできます。

7. アップグレード済みアプリケーションのための WebLogic Server ドメインの作成

アップグレードしたアプリケーションをデプロイするターゲットとしての WebLogicドメインには、そのアプリケーションの OC4J ベースの環境（ここからは、ソー

スとなる OC4J 環境と呼びます）と同等のトポロジとリソース・セットが必要に

なります。WebLogic Server には、通常、OC4J 機能に一致する機能セットが備わっ


20


ているため、同等のトポロジを作成するには、OC4J 機能から WebLogic Server 機能へのマッピングを行います。

以降の項では、OC4J ベース環境の各種要素が、WebLogic Server で相当する概念

に対してどのようにマッピングされるかについて説明するとともに、同等のター

ゲット・ドメインを作成する方法について説明します。説明されるすべての手順

は、"WebLogic Server ベースの環境での管理手順"の章に記載された WebLogic Serverツールを使用して実行できます。

各手順には記載しませんが、ほとんどの場合、WebLogic Serverが提供する機能は、

該当する OC4J 機能を上回ることに注意してください。参照先の WebLogic Serverドキュメントを通じてこれらの機能を調査し、アップグレード・プロセスの一環

として、アプリケーション機能を拡張できるかどうかについて評価することを推

奨します。

OC4J インスタンス

一般的に、ターゲットの WebLogic Server ドメインには、ソース環境でアプリケー

ションがデプロイされた OC4J インスタンスごとに、1 つの管理対象サーバーが必

要になります。これらの OC4J インスタンスの中に、numprocを 1 より大きく設

定したものがある場合、その数字が 1 増えるごとに、同一マシン上に管理対象サー

バーを 1 つ追加する必要が出てきます。次に、ソース環境で OC4J インスタンス

にデプロイされた各アプリケーションをターゲットの WebLogic Server ドメイン内

の該当する管理対象サーバーにデプロイします。

OC4J クラスタ

OC4J ベース環境の場合と同様に、WebLogic Server クラスタも WebLogic Server インスタンスをグループ化したものであり、デプロイしたアプリケーションに対し

て負荷分散とフォルト・トレランス機能を提供します。

ソースとなる OC4J 環境のクラスタ構成をターゲット・ドメインにマップするに

は、ソースとなる OracleAS 環境内に構成されたクラスタごとに、1 つの WebLogic Serverクラスタをターゲット・ドメインに作成する必要があります。次に、OracleAS環境でクラスタにデプロイされた各アプリケーションを WebLogic Server ドメイン

内の該当するクラスタにデプロイします。

WebLogic Server のクラスタ化機能は OC4J のクラスタ化機能のスーパーセットで

あるため、通常、適切な機能を有効化すると、OC4J クラスタによるすべてのアプ

リケーション・メリットが、該当する WebLogic Server クラスタでも実現されます。


21


OC4J Web サイト

"OC4J ユーザーのための WebLogic Server の一般的概念"の章で説明したとおり、

WebLogic Server インスタンスには、明示的な Web サイト設定は必要ありません。

このため、ソースとなる OC4J 環境からターゲット・ドメインに対して、Web サ

イト設定をマップする必要はありません。複数のアプリケーションを同一のサー

バーにデプロイするために、明示的にポートおよびプロトコル設定を割り当てる

必要がある場合は、WebLogic Serverのネットワーク・チャネル機能を使用します。

JDBC データソースと接続プール

一般に、OC4J 環境のデータソース構成に相当するデータソース構成は、データ

ベース接続情報、プーリング要件、および JDBC ドライバに基づいて、WebLogic Server で簡単に作成できます。OC4J 向けのデータソースは、OC4J インスタンス・

レベルで定義することも、datasources.xml ファイルを使用して、エンタープライ

ズ・アプリケーションに含めることもできます。WebLogic Serverデータソースは、

通常、ドメイン・レベルで定義され、クラスタ全体に適用されるか、またはドメ

イン内の特定の管理対象サーバーに適用されます。また、WebLogic Server データ

ソースは、エンタープライズ・アプリケーション内の JDBC モジュールとしてパッ

ケージ化することができます。この場合、OC4J におけるアプリケーション・レベ

ルのデータソースに相当する機能が提供されます。

OC4J ベース環境の場合と同様に、WebLogic Server の JDBC データソースも環境の

JNDI コンテキストにバインドされたオブジェクトであり、JDBC 接続のプールを

介してデータベース接続を提供します。アプリケーションは、このプールからデー

タベース接続を使用するため、JNDI コンテキスト内でデータソースをルックアッ

プします。

ソースとなる OC4J 環境の JDBC データソース構成をターゲット・ドメインにマッ

プするには、ソースとなる OracleAS 環境内に構成された JDBC データソースごと

に、1 つの WebLogic Server JDBC データソースをターゲット・ドメインに作成し、

同じ JNDI 名を付ける必要があります。また、別の Oracle ホワイト・ペーパーに

説明されているとおり、WebLogic Server JDBC データソースの構成を通じて、Oracle Real Application Clusters（Oracle RAC）のメリットを活用することもできます。

OC4J と WebLogic Server では、JDBC データソースに次の 2 つの重要な違いがあ

ることに注意してください。第一に、WebLogic Server の JDBC データソースには

暗黙的な接続プールが関連付けられているため、OC4J 環境内の接続プールに合わ

せて、ドメイン内に明示的な接続プールを作成する必要はありません。第二に、

WebLogic Server の JDBC データソースは、常に、Orace マネージド・データソー

スと同様に機能するため、そのままで、OC4J のネイティブ・データソースに相当

するデータソースはありません。

JMS リソース

OC4J ベース環境には、インメモリ、ファイル・ベース、そして Oracle Databaseの Advanced Queuing（AQ）という 3 つの JMS プロバイダがあります。インメモリ

とファイル・ベースの JMS プロバイダに関しては、WebLogic Server において相当


22


するプロバイダが提供されています。また WebLogic Server 11g では、JMS AQ プ

ロバイダに対するサポートが追加されています。これにより、"クライアント・ア

プリケーションのアップグレード"の章で説明するとおり、OC4J アプリケーショ

ンに対し、シームレスなアップグレードを適用するだけで、この機能が利用でき

るようになります。

OC4J では、はじめに、JMS コネクション・ファクトリおよび宛先が個々の OC4Jインスタンスの JMS サーバーで構成され、次に、リソース・プロバイダおよび（ま

たは）JMS コネクションを使用してマップされます。WebLogic Server では、これ

らのプライマリ JMS リソースはWebLogic JMS モジュール内で作成されます。JMSモジュールのターゲットは、ドメイン内のWebLogic JMS サーバーです。WebLogic JMS サーバーは、ターゲットとなる JMS 宛先のメッセージ永続性、永続サブスク

ライバ、メッセージ・ページング、および割当て制限を一元設定するためのポイ

ントとなります。OC4J では、対照的に、メッセージ永続性は宛先ごとに設定され、

メッセージ・ページングの設定には OC4J 固有の JVM プロパティが使用され、永

続サブスクライバの設定には JMX MBeans が使用され、さらに、メッセージの割

当て制限はサポートされていません。

ソースとなる OC4J 環境の JMS 構成をターゲット・ドメインにマップするには、

まず、WebLogic JMS サーバーを作成し、OC4J 環境の JMS リソース・プロバイダ、

コネクタ、コネクション・ファクトリ、および宛先構成を反映する必要がありま

す。次に、JMS コネクション・ファクトリ、宛先、共通構成の各セットに対して、

WebLogic Server の JMS モジュールを 1 つ作成する必要があります。その後で、こ

のモジュールに、OracleAS 環境と同じ JNDI 名を持つ JMS コネクション・ファク

トリと宛先を生成します。最後に、ドメイン内の適切な WebLogic JMS サーバー

を JMS モジュールのターゲットとして設定します。

リモート JMS プロバイダ

OC4J のベース環境では、WebSphereMQ、Tibco、SonicMQ などのサード・パーティ

製の JMS プロバイダのリモート宛先およびコネクション・ファクトリは、JMS コ

ネクタ構成の一部として設定されます。一方、WebLogic Serverのリモート宛先は、

WebLogic Server 外部サーバー・リソースを介してアクセスされます。このリソー

スを利用すると、ドメインの JNDI ツリーと、JMS 宛先およびコネクション・ファ

クトリに対する外部のリモート JNDI 名とのマッピングが提供されるため、外部の

JMS プロバイダを WebLogic Server に統合できます。

ソースとなるOC4J環境の外部 JMSプロバイダ構成をターゲット・ドメインにマッ

プするには、外部サーバーを含む JMS モジュールを作成し、ドメインからアクセ

スする必要のあるリモート宛先へのプロキシの役割を果たす、外部コネクション・

ファクトリと外部宛先のセットを設定します。


23


起動クラスと停止クラス

WebLogic Server は、アプリケーション・ライフサイクル・イベント機能の一部と

して、起動および停止（SU/SD）クラス機能を提供します。ソースとなる OC4J環境に設定されているすべての SU/SD クラスは、まず、WebLogic Server の SU/SDクラスに変換する必要があります。次に、ターゲットとなる WebLogic Server ドメ

インに各クラスを設定し、ソース環境の OC4J インスタンスに相当する WebLogic Server インスタンスをターゲットとして指定します。

OC4J の SU/SD クラスとは異なり、WebLogic Server の SU/SD クラスでは、特定の

インタフェースを実装したり、preDeployメソッドや postDeployメソッドを

作成したりする必要はありません。その代わりに、クラスの標準 main()メソッド

内にカスタム・ロジックを実装します。起動クラスの場合、WebLogic Server は、

このロジックをデプロイの前後に実行できるようにするため、構成パラメータを

提供しています。このパラメータは、ドメインに起動クラスを設定する際に、適

宜設定します。以上から、OC4J の起動クラスを変換するには、2 つの WebLogic Server 起動クラスを作成する必要があります。1 つは元のクラスの preDeploy メ

ソッドのコードを含むクラスで、もう 1 つは postDeploly メソッドのコードを含む

クラスです。

WebLogic Server の SU/SD クラスの main()メソッドに対して、事前に設定された

パラメータを渡すことはできますが、WebLogic Server の起動クラスでは、OC4Jの起動クラスに渡される JNDI コンテキスト・パラメータや構成ハッシュ表パラ

メータと同様の引数へアクセスすることはできません。変換対象である起動クラ

スのカスタム・ロジックでこれらのパラメータが使用されている場合、ゼロから

JNDI コンテキストを取得し、WebLogic Server の JMX インタフェースを介して

サーバー構成にアクセスするように、このロジックを変更する必要があります。

セキュリティ設定

アップグレードされたアプリケーションのターゲットとなる WebLogic Server 環

境は、アプリケーションのソースである OC4J 環境と同様のセキュリティ設定を

提供しなければなりません。同等の結果を達成するために、OC4J 環境の各セキュ

リティ設定をどのように WebLogic Server 環境にマップすれば良いかを表 7に示し

ます。

表 7 - OC4J から WebLogic Server へのセキュリティ設定のマッピング

OC4J のセキュリティ設定 WebLogic Server 構成へのマッピング

ユーザーおよびグループに関する

情報は、デフォルトで、OC4J 環境

の system-jazn-data.xml ファイルに格

納されます。

WebLogic Server には、デフォルトで組込み LDAP サーバーが構成されて

おり、認証（ユーザーおよびグループを含む）、認可、資格証明マッピ

ング、ロール・マッピング・プロバイダに関する情報を格納するために

使用できます。system-jazn-data.xml ファイルに含まれるユーザーおよびグ

ループ情報は、組込み LDAP サーバーに移動する必要があります。

OC4J 環境には、外部 LDAP サーバー WebLogic Server LDAP 認証プロバイダを作成し、ソースとなる OC4J 環


24


が構成されています。境と同じ外部 LDAP サーバーをターゲット・ドメインに設定します。

OC4J 環境は、RDBMS データベース

に対してユーザーを認証するよう設

定されています。

WebLogic Server RDBMS 認証プロバイダを作成し、認証用の RDBMS デー

タベースをターゲット・ドメインに設定します。

OC4J 環境では、複数の OC4J サー

バー・インスタンス間に、Java シング

ル・サインオンおよび（または）サブ

ジェクト伝播が設定されています。

WebLogic Server のシングル・サインオンおよびサブジェクト伝播は、ド

メイン内のサーバーおよびクラスタ間で自動的に有効になるため、特別

な設定は必要ありません。

OC4J 環境には、カスタムの JAASログイン・モジュールが設定されて

います。

標準提供またはカスタムのWebLogic Server 認証プロバイダをターゲット・

ドメイン内に作成し、JAAS ログイン・モジュール機能をラップします。

OC4J 環境には、Oracle Access Managerが設定されています。

このドキュメントの説明に従って、ターゲットの WebLogic Server ドメイ

ンに Oracle Access Manager を設定します。

OC4J サーバー･インスタンスには、

SSL 暗号化が設定されています。ターゲットの WebLogic Server ドメインに対して、SSL 設定を行います。

OC4J 環境は、Oracle Wallet を使用し

てセキュリティ・キーを保管してい

ます。

セキュリティ・キーは、WebLogic Server ドメインで使用できるJKS キー・

ストア内に保管します。

クラスのローディング構成

ターゲットの WebLogic Server 環境を構築する際、クラスのローディング構成がア

プリケーションのソースとなる OC4J 環境と同様に正しく機能するよう、適切に

構築する必要があります。

OC4J と WebLogic Server 間でクラスのローディング・モデルに複雑な違いがある

ため、ターゲットの WebLogic Server 環境におけるクラスのローディング構成を設

定する前に、WebLogic Server アプリケーション・クラスのローディングについて

十分に理解しておくことが重要です。OC4J ベース環境でアプリケーション・クラ

スのローディングについて設定する場合のオプションに関する知識を持つユー

ザーが、この理解を深めることを目的として、表 8を記載します。ここでは、OC4Jで、アプリケーションからクラスを利用できるようにするためのおもなアプロー

チと、同様の結果を WebLogic Server 環境で得るために相当する方法のマッピング

概要を示します。

表 8 - OC4J から WebLogic Server へのクラス・ローダー設定のマッピング

OC4J でのアプローチ WebLogic Server での同等のアプローチ

アプリケーションのクラス・ローダー

は、デプロイメント・ディスクリプ

タ内にあるOracle固有の<library>

要素を介して、クラスを使用します。

アプリケーションの APP-INF/classes ディレクトリか APP-INF/lib ディレ

クトリ（WAR ファイルの場合は、WEB-INF/classes または WEB-INF）に、

クラスまたは JAR ファイルそれぞれを追加します。もしくは、WebLogic Server のインスタンスまたはクラスタに対して、JAR ファイルをWebLogic Server 共有ライブラリとしてデプロイします。


25


クラスは、OC4J 共有ライブラリと

して特定のアプリケーションに公

開されています。

WebLogic Server のインスタンスまたはクラスタに対して、JAR ファイル

をWebLogic Server 共有ライブラリとしてデプロイします。

OC4J と WebLogic では、共有ライブラリの概念に重要な違いがあること

に注意してください。

まず、WebLogic Server 共有ライブラリは、これらを使用するアプリケー

ションから常に参照されている必要があります。デプロイされたすべて

のアプリケーションで 1 つの共有ライブラリを使用することはできませ

ん（WebLogic Server ドメインでの具体的な実現方法については次を参照

してください）。

次に、この参照により、共有ライブラリのコンテンツは、アプリケーショ

ン・クラス・ローダーのクラスパスにエクスポートされます。OC4J の場

合とは違い、システム・クラス・ローダーの子として専用クラス・ローダー

内から使用できるようにはなりません。つまり、実行時には、各アプリ

ケーションがそれぞれ独自にクラスのインメモリ・コピーを持ちます。

最後に、WebLogic Server 共有ライブラリは、EAR、WAR、または JAR の

いずれのファイル形式を取ることもでき、アプリケーション内の包含範囲

は、参照元のデプロイメント・ディスクリプタ（weblogic-application.xmlまたは weblogic.xml）のスコープにより制御されます。

デフォルト・アプリケーションの

application.xml（ORACLE_HOME 内）

内の参照を使用するか、または

ORACLE_HOME の/applib ディレク

トリに JAR ファイルを配置するこ

とで、すべてのインスタンス上のす

べてのアプリケーションから、クラ

スが使用可能になります。

ドメイン・ディレクトリの/lib サブディレクトリ内に JAR ファイルを配

置します。これにより、このドメインに属する WebLogic Server インスタ

ンス上で実行されるすべてのアプリケーションから、JAR ファイルのク

ラスを（システム・レベルの別のクラス・ローダー内で）使用できるよ

うになります。

OC4J インスタンスのクラスパスに

クラスが追加されており、システ

ム・クラス・ローダーを通じてサー

バー・インスタンス全体から使用で

きるようになっています。

サーバーを起動する前に、POST_CLASSPATH また PRE_CLASSPATH 環

境変数を設定することで、WebLogic Server インスタンスでも同様の設定

を実現できます、

8. Web 層

OC4J サーバー・インスタンスの場合と同様に、WebLogic Server インスタンスの

前面に、セキュリティとスケーラビリティを目的とする Web 層を配置することが

可能です。また、実際に多くのケースで配置されています。この Web 層は、事実

上、アプリケーション・サーバー層にデプロイされた Web アプリケーションのク

ライアントとして機能します。


26


通常、OC4J の Web 層は、mod_oc4j モジュールを設定した Oracle HTTP Server のインスタンスで構成されています。WebLogic Server インスタンスの前面に配置す

る Web 層には、WebLogic Server Web サーバー・プラグインを設定する必要があり

ます。このプラグインは、Oracle HTTP Server、Apache HTTP Server、および Microsoft Internet Information Server に対応しています。mod_oc4j を設定された Oracle HTTP Server と、WebLogic Server Web サーバー・プラグインを設定された Web サーバー

において、違いのある領域は以下のとおりです。

• ロードバランシング：WebLogic Server Web サーバー・プラグインでサポー

トされるのは、単純なラウンド・ロビン方式のロードバランシングですが、

mod_oc4j を設定した Oracle HTTP Server では、その他多数のロードバラン

シング手法がサポートされます。サポートされるアルゴリズムには、メト

リック・ベース、重み付きラウンド・ロビン方式、ランダムなどがあり、

これらのアルゴリズムにローカル・アフィニティを組み合わせることで、

ローカル・マシン上のプロセスがリモート・プロセスに優先されるように

することもできます。アップグレード対象のアプリケーションが、mod_oc4jを使用したこれらのロードバランシング機能に依存している場合、場合に

よっては、同様の機能を持つロードバランシング・テクノロジーを WebLogic Server ドメインの Web 層の前面に配置する必要があります。

• 構成：mod_oc4j を設定した Oracle HTTP Server は、OC4J インスタンスと、

そこにデプロイされた Web アプリケーションを動的に検出します。一方、

WebLogic Server Web サーバー・プラグインの構成モデルはより静的であり、

すべてのWeb アプリケーションのURL が静的に設定されています。WebLogic Server Web サーバー・プラグインにも、WebLogic Server クラスタ内のコン

テナ・インスタンスを検出する機能がありますが、この機能を使用するに

は、クラスタ・メンバーに対するホストおよびポート接続情報が、最初に

ブートストラップから読み込まれている必要があります。この静的設定モ

デルの利点は、WebLogic Server のドメイン・コンポーネントに依存しない

ことで、Web 層と Web アプリケーション間での疎結合を実現していること

です。

• 転送プロトコル：WebLogic Server Web サーバー・プラグインでは、転送プ

ロトコルとして HTTP が使用されますが、mod_oc4j の設定された Oracle HTTP Server では、Apache JServ Protocol（AJP）が使用されます。したがっ

て、Web 層と Web アプリケーションの間にファイアウォールを設定した環

境では、これらの層の間で HTTP トラフィックを許可するよう変更する必

要があります。

9. クライアント・アプリケーションのアップグレード

OC4J から WebLogic Server へアップグレードすることで、Java EE アプリケーショ

ンが公開している外部インタフェースの特性に影響が及ぶ可能性があります。場

合によっては、この影響が動作変更につながり、クライアント・アプリケーション


27


を変更する必要が発生します。ここからは、考えられる影響と、それがアプリケー

ション・クライアントへもたらす結果について説明していきます。

Java Server Pages クライアントとサーブレット・クライアント

WebLogic Server へのアプリケーション・アップグレードが JSP クライアントと

サーブレット・クライアントにもたらすおもな影響は、WebLogic Server と OC4J間で、HTTP セッション・ステート・レプリケーション・モデルが異なることに

起因します。OC4J クラスタでは、HTTP セッション・ステートをレプリケートし

たインメモリ・コピーをいくつでも持つことができますが、WebLogic Server のイ

ンメモリ HTTP セッション・ステート・レプリケーションでサポートされるコ

ピー・モデルは、プライマリとセカンダリの 2 つのみです。ほとんどの場合、こ

の違いが JSP クライアントおよびサーブレット・クライアントに影響を与えるこ

とはありません。しかしながら、アプリケーションが 3 つ以上の HTTP セッショ

ン・ステート・コピーに明確に依存している珍しいケースでは、Oracle Coherenceベースのソリューションを検討する必要があります。

Java Naming and Directory Interface クライアント

アップグレード対象のアプリケーションのクライアントが、OC4J Java Naming and Directory Interface（JNDI）プロバイダを使用して、アプリケーションのインタフェー

スおよび（または）リソースをルックアップしている場合、WebLogic Server JNDIプロバイダを使用するように変更する必要があります。この変更は、以下のとおり、

アプリケーションの JNDI 初期コンテキストを作成するコードに対して行います。

• OC4J JNDI URLのすべてのインスタンスを特定します。OC4JのURLは通常、

次の形式で構成されています。<プリフィックス>://<ホスト>:<RMI または

OPMN リクエスト・ポート>:<oc4j インスタンス>/<アプリケーション名>。

OracleAS をフル・インストールしており、oc4j1 という名前の OC4J インス

タンスを持ち、myapplication という名前のアプリケーションがデプロイさ

れている場合、URL の例は、opmn:ormi://127.0.0.1:6003:oc4j1/myapplicationとなります。Oracle Application Server をフル・インストールしており、Oracle Process Management and Notification インフラストラクチャを使用している

場合、プリフィックスは opmn:ormi になり、スタンドアロンの OC4J イン

スタンスを使用している場合、ormi:のみになることに注意してください。

• t3 プロトコルを使用して、ターゲットの WebLogic Server ドメインの管理

サーバーを指すように、プロバイダの URL を変更します（例：t3://127.

0.0.1:7001）。

• 使用するセキュリティ資格証明は、ターゲットの WebLogic Server ドメイ

ン内で有効なものでなければなりません。

• 使用する初期コンテキスト・ファクトリを、WebLogic Server の WLInitial

ContextFactoryクラスに変更します。また、WebLogic Server クライア


28


ントの jar ファイルを使用して、クライアント・アプリケーションのクラ

ス・ローダーがこのクラスを使用できるようにします。

さらに、クライアントが OC4J サーバー・インスタンス内で実行される場合、同

じ OC4J インスタンス内で、複数の JNDI プロバイダを使用できるように、サーバー

の server.xml において、environment-naming-url-factory-enabled 属性

に true を設定する必要があります。

OC4J と WebLogic Server の JNDI プロバイダ間で、クライアント・アプリケーショ

ンに影響を及ぼす可能性のあるもう 1 つの相違点は、JNDI 名前空間のスコープで

す。OC4J JNDI オブジェクトには、明示的にアプリケーション・スコープを設定

できます。したがって、ルックアップを実行する場合、OC4J JNDI クライアント

は、特定の OC4J サーバー・インスタンスを指し、ターゲット・アプリケーショ

ンの名前を含む URL を使用できます。しかし、WebLogic Server の JNDI オブジェ

クトは、常に、グローバル名前空間を使用します。このため、WebLogic Server のJNDI クライアントがルックアップを実行する場合、URL を指定して、明示的に

ターゲット・アプリケーションを特定することはできません。つまり、WebLogic Server へアップグレードする際、属するアプリケーションに関わらず、同じ WebLogic Server ドメインにデプロイされるすべての JNDI リソースが一意の JNDI 名を持つ

ようにする必要があります。また、必要に応じて、ターゲット・オブジェクトの

一意の JNDI 名を使用するように JNDI クライアントを変更します。

Enterprise Java Bean クライアント

WebLogic Server へのアプリケーション・アップグレードにより、Enterprise Java Bean（EJB）クライアントに影響が及ぶケースは 2 つあります。1 つ目は、アップグレー

ドされる EJB で、スタンドアロンまたは OC4J サーバーにデプロイされたリモート・

クライアントが使用されているケースです。2 つ目は、アップグレードされるアプ

リケーションが、OC4JベースのEJBインタフェースをリモートで使用しているケー

スです。ここからは、それぞれのケースにおける対応について説明します。

アップグレード対象のアプリケーションのクライアント

アップグレード対象のアプリケーションの EJB インタフェースにリモート・クラ

イアントが使用されている場合、"Java Naming and Directory Interface クライアント

"の章で説明されているように、WebLogic Server の JNDI プロバイダを使用するよ

うに変更する必要があります。WebLogic Serverの JNDIプロバイダを使用すると、

クライアント・アプリケーションで WebLogic Server の EJB クライアント・スタ

ブが取得されるため、クライアント・アプリケーションに次の影響を与える可能

性があります。

• RMI プロトコル：クライアント・アプリケーションは、OC4J の RMI 転送

プロトコルである Oracle RMI ではなく、WebLogic Server RMI転送プロトコ

ルの 1 つを使用することになります。デフォルトで使用される WebLogic RMI 転送プロトコルは、WebLogic Server T3プロトコルですが、IIOP を使用

することもできます。

• ロードバランシング：OC4J では、JNDI オブジェクトの InitialContext

を使用することで、Context.lookup()を起動するたびに、OC4J クラス

タ全体でクライアントの EJB リクエストをロードバランシングするよう設

定できます。WebLogic Server では、EJB クライアント・リクエストのロー


29


ドバランシングは、リモート EJB クライアントのスタブによって自動的に

処理されます。これらのスタブによるロードバランシングは、WebLogic Server の weblogic-ejb-jar.xml デプロイメント・ディスクリプタ・レベルで

動作を設定することができ、InitialContext の作成時または EJB メソッドの

起動時に実行されます。

また、上記の考慮事項の対象は、スタンドアロン・クライアント、または現在 OC4Jサーバー・インスタンス内で実行されており、WebLogic Server インスタンス内で

実行するようアップグレードされるクライアントのみが対象となります。

スタンドアロン・アプリケーションではない EJB クライアントが、引き続き OC4Jサーバー・インスタンス内で実行され、アップグレードされた WebLogic Serverの EJB アプリケーションに対してリモート呼出しを行う場合、さらに次の 2 つの

影響について考慮する必要があります。まず、アプリケーションのセキュリティ・

コンテキストが自動的に伝播されなくなります。このセキュリティ伝播が必須で

ある場合、WebLogic Server の JNDI 初期コンテキストの作成時に、既存のセキュ

リティ･コンテキストの資格証明を明示的に使用するよう、クライアントに変更を

加える必要があります。次に、リモート EJB 呼出しのコンテキスト内で JTA トラ

ンザクション伝播および XA リカバリを実行することができなくなります。これ

らを必要とする場合、クライアント・アプリケーション自体をアップグレードす

る必要があります。

アップグレード対象のアプリケーション内の OC4J Enterprise Java Bean クライアント

アップグレード対象のアプリケーションを、引き続き OC4J サーバー内で実行される

EJB コンポーネントに対するリモート・クライアントとして機能させなければならな

い場合があります。このようなクライアントは、すでにそうしている場合を除いて、

OC4J の JNDI 初期コンテキスト・ファクトリである RMIInitialContextFactory

（oc4jclient.jar ファイル内にあります）を使用するように変更する必要があります。

さらに、"アップグレード済みアプリケーションのための WebLogic Server ドメイ

ンの作成"の章で説明されたメカニズムのいずれかを使用して、この jar ファイル

をアプリケーションの WebLogic Server クラス・ローダーから使用できるようにす

る必要があります。また、セキュリティ・コンテキストを伝播するには、ターゲッ

ト OC4J サーバー・インスタンスをWebLogic Server SSLクライアントとして設定す

る必要があります。リモート EJB 呼出しのコンテキスト内で JTA トランザクショ

ン伝播および XA リカバリを実行することはできなくなるため、これらを必要と

する場合、ターゲットの EJB アプリケーション自体をアップグレードする必要が

あります。

JMS クライアント

初めに、この項に含まれる情報は、Message Driven Bean（MDB）ではない JMS ク

ライアントを対象としていることに注意してください。通常、MDB は JMS プロ

バイダと緊密に結合されているため、常にこれらのリソースに合わせてアップグ

レードする必要があります。MDB アプリケーションをアップグレードする場合、

WebLogic Server MDBの機能および動作について考慮する必要があります。

WebLogic Server へのアプリケーション・アップグレードにより、JMS クライアン

トに影響が及ぶケースは 2 つあります。1 つ目は、JMS プロバイダ（および宛先


30


やコネクション・ファクトリなどの関連リソース）が WebLogic Server にアップグ

レードされ、アップグレードされたクライアント・アプリケーションとアップグ

レードされていない OC4J クライアント・アプリケーションの両方が、引き続き

OC4J サーバー内で実行されているため、調整が必要なケースです。2 つ目は、JMSプロバイダが OC4J インフラストラクチャ内に残り、WebLogic Server にアップグ

レードされるクライアント・アプリケーションの調整が必要なケースです。ここ

からは、それぞれのケースにおける対応について説明します。

WebLogic Server にアップグレードされる JMS プロバイダ

スタンドアロンの JMS クライアントまたは、現在 OC4J サーバー・インスタンス

で実行されており、WebLogic Server インスタンス内で実行されるようにアップグ

レードされる予定の JMS クライアントは、"Java Naming and Directory Interface ク

ライアント"の説明に従って、WebLogic Server の JNDI プロバイダを使用するよう

に変更する必要があります。WebLogic Server の JNDI プロバイダを使用すると、

クライアント・アプリケーションで WebLogic Server の JMS プロバイダから JMSリソースが取得されます。このため、クライアント・アプリケーションへの潜在

的な影響を踏まえて、OC4J と WebLogic 間における JMS プロバイダの動作および

機能の重要な違いについて考慮する必要があります。

• メッセージ順序：OC4J の JMS プロバイダと同様に、WebLogic Server も厳

密に順序付けされたメッセージ処理を保証する機能を提供します。さらに、

WebLogic Server の JMS 順序単位機能により、追加のメッセージ順序処理機

能が提供されます。

• 接続プーリング：OC4J の JMS プロバイダとは異なり、WebLogic Server のJMS プロバイダは、スタンドアロン・クライアントにプーリング機能を提

供していません。この機能が必要である場合、JMS リソースを明示的に再

利用することでこの機能を実装するよう、スタンドアロン・クライアント

を変更する必要があります。

• ネットワーク接続：WebLogic Server の JMS プロバイダを使用しているク

ライアントは、使用される JMS 接続オブジェクトの数に関わらず、クライ

アント仮想マシンごとに 1 つのネットワーク接続を使用します。これは、

OC4J における動作とはわずかに異なります。OC4J の JMS プロバイダは、

それぞれの JMS 接続オブジェクトに個別のネットワーク接続を関連付け

ます。

スタンドアロン・アプリケーションではない JMS クライアントが、引き続き OC4Jサーバー・インスタンス内で実行され、WebLogic Server 環境にある JMS リソース

を使用する場合、OC4J Oracle Enterprise Messaging Server の JMS コネクタ機能を

使用する必要があります。

OC4J 内にとどまる JMS プロバイダ

アップグレード対象のアプリケーションで、OC4J JMSプロバイダ内の JMSリソー

スを引き続き使用しなければならない場合があります。このようなアプリケーショ

ンでは、WebLogic Server にデプロイされた JMS クライアントから OC4J JMS リ

ソースにアクセスできるようにするため、OC4J JMS リソースをリモートの JMSプロバイダとして扱い、WebLogic Server 外部サーバーを使用する必要があります。


31


AQ JMS クライアント

WebLogic Server 11g では、AQ に対するサポートが追加されました。この機能を

使用すると、WebLogic Server 外部サーバーを AQ JMS プロバイダとして参照でき

ます。このメカニズムにより、AQ JMS クライアント・アプリケーションに変更

を加えなくても、WebLogic Server から Oracle Streams Advanced Queuing システム

へ直接アクセスできるようになります。

10. まとめ

Oracle Fusion Middleware は、実績と安定性に優れた WebLogic Server を戦略的アプ

リケーション・サーバー・ランタイムとして位置付けることで、次世代へと歩を

進めます。Oracle Application Server は、ライフタイム・サポート・ポリシーに基

づいて、新しいパッチセットや機能を提供し続けることで、オラクルの顧客によ

る Oracle Fusion Middleware への既存投資を保護します。このホワイト・ペーパー

では、Oracle Application ServerのOC4JからWebLogic Serverへと、カスタム Java EEアプリケーションをアップグレードするプロセスと作業について説明しました。

オラクルは、WebLogic Server へのカスタム Java EE アプリケーションのアップグ

レードを簡単にするため、より詳しいドキュメント、専用ツール、そして関連す

るベスト・プラクティスや、コンサルティング・サービスおよび教育サービスな

どを今後提供していく予定であり、本書はこれらの導入部分の役割を果たします。

注：上記に記載した計画は、提供を確約するものではなく戦略的な方向性であり、

予告なく変更される可能性があります。

日 Oracle Application Server から WebLogic Server へのカスタム Java EE アプリケーションのアップグレード 2009 年 7 月著者：Reza Shafii 共著者： Mike Lehmann Mark T. Nelson Vinay Shukla Frances Zhao Oracle USA, Inc. World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. 海外からのお問い合わせ窓口：電話：+1.650.506.7000 ファクシミリ：+1.650.506.7200 oracle.com Copyright © 2009, Oracle and/or its affiliates. All rights reserved. 本文書は情報提供のみを目的として提供されており、ここに記載される内容は

予告なく変更されることがあります。本文書は一切間違いがないことを保証するものではなく、さらに、口述による

明示または法律による黙示を問わず、特定の目的に対する商品性もしくは適合

性についての黙示的な保証を含み、いかなるほかの保証や条件も提供するもの

ではありません。オラクル社は本文書に関するいかなる法的責任も明確に否認

し、本文書によって直接的または間接的に確立される契約義務はないものとし

ます。本文書はオラクル社の書面による許可を前もって得ることなく、いかな

る目的のためにも、電子または印刷を含むいかなる形式や手段によっても再作

成または送信することはできません。 Oracle、JD Edwards、PeopleSoft、および Siebel は、米国 Oracle Corporationおよびその子会社、関連会社の登録商標です。その他の名称はそれぞれの会社

の商標です。

Documents

Oracle Application Server から WebLogic Server …...Oracle Forms、Oracle Reports、Oracle Portal、Oracle Discoverer、Oracle B2Bなど） とその他の階層化製品のWebLogic

Oracle Application Server から WebLogic Server …...Oracle Forms、Oracle Reports、Oracle Portal、Oracle Discoverer、Oracle B2Bなど）とその他の階層化製品のWebLogic