Fusion Middleware Java EEアップグレード・ガイド

11gリリース1（11.1.1）

B55925-03(原本部品番号:E10126-04)

目次

タイトルおよび著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

1 Java EEのアップグレード・プロセスの概要

- 1.1 Java EEのアップグレード・プロセスのフロー・チャート

- 1.2 Java EEのアップグレード・プロセスの手順を示す表

第I部 Java EEのアップグレードの準備

2 Java EEをアップグレードする際のサポートされる開始点

3 OC4JユーザーのためのOracle WebLogic Serverの概要説明

- 3.1 OC4JユーザーのためのOracle WebLogic Serverの主な概念

- 3.1.1 OC4JとOracle WebLogic Serverのアーキテクチャの比較

- 3.1.1.1 スタンドアロンのOC4JおよびスタンドアロンのOracle WebLogic Server

- 3.1.1.2 Webサーバーと統合されたOC4JおよびOracle WebLogic Server

- 3.1.1.3 OC4JおよびOracle WebLogic Serverのクラスタリング機能

- 3.1.2 OC4JとOracle WebLogic Serverのディレクトリ構造の比較

- 3.1.3 OC4JユーザーのためのOracle WebLogic Serverドメインの理解

- 3.1.3.1 ドメインの基本的なコンテンツと編成

- 3.1.3.2 Oracle WebLogic Serverドメインに関するその他の情報

- 3.1.3.2.1 WebLogic Serverのインストールを使用した複数のドメインの構成

- 3.1.3.2.2 常に単一のJava仮想マシン・プロセスに関連付けられるWebLogic Serverインスタンス

- 3.1.3.2.3 すべてのアプリケーション・リクエストを同じポート上で処理するWebLogic Serverインスタンス（デフォルト）

- 3.1.3.2.4 常にHTTPリスナーが組み込まれ、AJPはサポートしていないWebLogic Serverインスタンスの構成

- 3.2 OC4JユーザーのためのOracle WebLogic Serverのインストールおよび構成ツール

- 3.3 OC4JユーザーのためのOracle WebLogic Serverの管理ツール

- 3.3.1 OC4JおよびOracle WebLogic Serverの管理ツールの比較

- 3.3.2 OC4Jユーザーのための一般的なOracle WebLogic Serverの管理タスク

- 3.3.2.1 サーバーの起動と停止

- 3.3.2.2 ドメインの診断の実行

- 3.3.2.3 ドメインのログ・ファイルの表示

- 3.3.2.4 スレッド・プールの構成とチューニング

- 3.4 OC4JおよびOracle WebLogic Serverの標準のサポート

第II部 Java EEのアプリケーションと環境のアップグレード

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

- 4.1 タスク1: アプリケーションがOC4Jに正常にデプロイされ動作していることの確認

- 4.2 タスク2: 開発ツールの選択

- 4.2.1 開発ツールを選択する場合の一般的なガイドライン

- 4.2.2 SmartUpgrade Oracle JDeveloper拡張機能およびコマンドライン・ツールの使用

- 4.3 タスク3: アプリケーションでJava Development Kit（JDK）6がサポートされていることの確認

- 4.4 タスク4: アプリケーション・デプロイメント・ディスクリプタのアップグレード

- 4.4.1 OC4JおよびOracle WebLogic Serverのデプロイメント・ディスクリプタの比較

- 4.4.2 Oracle WebLogic Serverのデプロイメント・ディスクリプタのアップグレードに関するガイドラインおよびリソース

- 4.4.3 デプロイメント・ディスクリプタ・ファイルのセキュリティ要素について

- 4.4.4 デプロイメント・プランのアップグレード

- 4.5 タスク5: Oracle WebLogic Server APIのサポートの確認

- 4.5.1 Java Required Files（JRF）ドメイン・テンプレートで使用可能なAPI

- 4.5.2 その他のOracle WebLogic Server APIの要件

- 4.6 タスク6: アプリケーションのWebサービスのアップグレード

- 4.6.1 Oracle WebLogic ServerのJAX-RPCおよびJAX-WS Webサービスにアップグレードする場合の一般的なガイドライン

- 4.6.2 OC4J WSDLからのOracle WebLogic ServerのWebサービスの生成

- 4.6.3 OC4JおよびOracle WebLogic ServerでサポートされているWebサービスの仕様

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

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

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

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

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

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

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

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

- 5.1.4 Java Required Files（JRF）ドメイン・テンプレートの使用

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- 6.1 Java Server Pagesクライアントおよびサーブレット・クライアントに対するアップグレードの影響

- 6.2 Java Naming and Directory Interfaceクライアントに対するアップグレードの影響

- 6.2.1 Oracle WebLogic Server JNDIプロバイダを使用するためのクライアントの変更

- 6.2.2 Oracle WebLogic Server JNDIネームスペースのスコープの理解

- 6.3 Enterprise Java Beanクライアントに対するアップグレードの影響

- 6.3.1 リモート・スタンドアロンEJBクライアントへの影響

- 6.3.2 OC4JベースのEJBインタフェースを使用するクライアントへの影響

- 6.4 JMSクライアントに対するアップグレードの影響

- 6.4.1 JMSプロバイダをWebLogic Serverにアップグレードする場合に必要な変更

- 6.4.2 JMSプロバイダがOC4Jにそのまま残る場合に必要な変更

7 Java EEおよびWebサーバー環境のアップグレード

- 7.1 タスク1: Oracle HTTP ServerおよびOC4Jを使用した場合と、Oracle HTTP ServerおよびOracle WebLogic Serverを使用した場合の相違点の理解

- 7.1.1 Oracle WebLogic ServerにおけるWebサイトおよびAJP接続の構成

- 7.1.2 Oracle WebLogic Server向けのOracle HTTP Serverのインストールおよび構成

- 7.1.2.1 Oracle HTTP ServerのOC4J向けの構成方法

- 7.1.2.2 Oracle HTTP ServerのOracle WebLogic Server向けの構成方法

- 7.1.3 Oracle HTTP Server以外のWebサーバーとOracle WebLogic Serverの使用

- 7.1.4 Oracle Fusion Middleware 11gにアップグレードする場合のOracle HTTP Serverの相互運用性の問題の理解

- 7.2 タスク2: Oracle Fusion MiddlewareのWeb層のインストールおよび構成

- 7.2.1 Web層コンポーネントの場所の決定

- 7.2.2 Oracle WebLogic ServerドメインへのWeb層コンポーネントの関連付け

- 7.2.3 Web層のインストールと構成に関するドキュメントの参照

- 7.3 タスク3: Oracle Application Server 10g Web層コンポーネントのOracle Fusion Middleware 11g へのアップグレード

- 7.3.1 タスク3a: Web層をアップグレードするためのUpgrade Assistantの起動

- 7.3.2 タスク3b: Upgrade Assistantを使用したWeb層コンポーネントのアップグレード

- 7.3.2.1 Web層コンポーネントのアップグレード

- 7.3.2.2 アップグレード先OracleインスタンスでソースOracleホーム・ポートを使用する際の重要な注意事項

- 7.4 タスク4: リクエストをOracle Fusion Middleware環境にルーティングするためのWeb層の構成

- 7.5 タスク5: アップグレード後に必要な、Web層コンポーネントに対するタスクの実行

- 7.5.1 アップグレード後のOracle HTTP ServerおよびOracle Web Cacheウォレットの場所の確認

- 7.5.2 アップグレード後のOracle HTTP ServerおよびOracle Web Cacheポートの確認と更新

- 7.6 タスク6: Web層のアップグレードの確認

A orion-web.xmlおよびorion-ejb-jar.xmlのアップグレード・リファレンス

- orion-web.xml

- <classpath>

- <contextParamMappingFinding>

- <mimeMappings>

- <virtual-directory>

- <access-mask>

- <servlet-chaining>

- <request-tracker>

- <session-tracking>

- <session-tracker>

- <resource-ref-mapping>

- <lookup-context>

- <resource-env-ref-mapping>

- <env-entry-mapping>

- <ejb-ref-mapping>

- <service-ref-mapping>

- <expiration-setting>

- <jazn-web-app>

- <security-role-mapping>

- <web-app-class-loader>

- search-local-classes-first

- include-war-manifest-class-path

- autojoin-session

- default-buffer-size

- default-charset

- default-mime-type

- development

- directory-browsing

- enable-jsp-dispatcher-shortcut

- file-modification-check-interval

- jsp-cache-directory

- jsp-cache-tlds

- jsp-print-null

- jsp-taglib-locations

- jsp-timeout

- persistence-path

- schema-major-version

- schema-minor-version

- servlet-webdir

- simple-jsp-mapping

- source-directory

- temporary-directory

- orion-ejb-jar.xml

- <session-deployment>

- copy-by-value

- idletime

- min-instances

- max-instances

- max-instances-threshold

- max-tx-retries

- resource-check-interval

- passivate-count

- persistence-filename

- pool-cache-timeout

- timeout

- transaction-timeout

- <ejb-ref-mapping>

- <resource-ref-mapping>

- <resource-env-ref-mapping>

- <message-destination-ref-mapping>

- <session-type>Stateful</session-type>

- <message-driven-deployment>

- connection-factory-location

- dequeue-retry-count

- dequeue-retry-interval

- destination-location

- listener-threads

- max-delivery-count

- resource-adapter

- subscription-name

- wrapper-class

- <config-property>

Oracle® Fusion Middleware

Java EEアップグレード・ガイド

11gリリース1（11.1.1）

B55925-03(原本部品番号:E10126-04)

2011年1月

Oracle Fusion Middleware Java EEアップグレード・ガイド, 11g リリース1（11.1.1）

B55925-03

Copyright © 2010, 2011 Oracle and/or its affiliates.All rights reserved.

原本著者: Peter LaQuerre

原本協力者: Reza Shafii

協力者: Janga Aliminati、Pyounguk Cho、Paul Dickson、Robert Donat、Shail Goel、William Norcott、Michael Rubino、Robert St. Jean、Gavin Steyn、Sitaraman Swaminathan、Suresh Srinivasan、Zhong Xu、Lixin Zheng

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントが、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供される場合は、次のNoticeが適用されます。

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007).Oracle USA, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

このソフトウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアは、危険が伴うアプリケーション（人的傷害を発生させる可能性があるアプリケーションを含む）への用途を目的として開発されていません。このソフトウェアを危険が伴うアプリケーションで使用する際、このソフトウェアを安全に使用するために、適切な安全装置、バックアップ、冗長性（redundancy）、その他の対策を講じることは使用者の責任となります。このソフトウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

このソフトウェアおよびドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

はじめに

ここでは、次の内容について説明します。

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

対象読者

このマニュアルは、Java EEアプリケーションを開発するOracle Fusion Middlewareアプリケーション開発者と、そのアプリケーションをデプロイしOracle Fusion Middlewareのインストールを管理する管理者を対象としています。このマニュアルの読者は、次の知識があることを前提としています。

- Oracle Fusion Middlewareシステムの管理および構成

- アップグレード対象のシステムの構成および予測される動作

- Java EEの開発およびベスト・プラクティス

ドキュメントのアクセシビリティについて

オラクル社は、障害のあるお客様にもオラクル社の製品、サービスおよびサポート・ドキュメントを簡単にご利用いただけることを目標としています。オラクル社のドキュメントには、ユーザーが障害支援技術を使用して情報を利用できる機能が組み込まれています。HTML形式のドキュメントで用意されており、障害のあるお客様が簡単にアクセスできるようにマークアップされています。標準規格は改善されつつあります。オラクル社はドキュメントをすべてのお客様がご利用できるように、市場をリードする他の技術ベンダーと積極的に連携して技術的な問題に対応しています。オラクル社のアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/accessibility/を参照してください。

ドキュメント内のサンプル・コードのアクセシビリティについて

スクリーン・リーダーは、ドキュメント内のサンプル・コードを正確に読めない場合があります。コード表記規則では閉じ括弧だけを行に記述する必要があります。しかしJAWSは括弧だけの行を読まない場合があります。

外部Webサイトのドキュメントのアクセシビリティについて

このドキュメントにはオラクル社およびその関連会社が所有または管理しないWebサイトへのリンクが含まれている場合があります。オラクル社およびその関連会社は、それらのWebサイトのアクセシビリティに関しての評価や言及は行っておりません。

Oracleサポートへのアクセス

お客様は、My Oracle Supportから電子サポートにアクセスできます。詳細は、http://www.oracle.com/support/contact.htmlを参照してください。聴覚障害のあるお客様は、http://www.oracle.com/accessibility/support.htmlを参照してください。

関連ドキュメント

詳細は、Oracle Fusion Middleware 11g ドキュメント・ライブラリにある次の関連ドキュメントを参照してください。

- アップグレードに関するドキュメント

- 『Oracle Fusion Middlewareアップグレード・プランニング・ガイド』

- 『Oracle Fusion Middleware Oracle SOA Suite, WebCenterおよびADFアップグレード・ガイド』

- 『Oracle Fusion Middleware Oracle Portal, Forms, Reports and Discovererアップグレード・ガイド』

- 『Oracle Fusion Middleware Oracle Identity Managementアップグレード・ガイド』

- 『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』

- 『Oracle Fusion Middleware管理者ガイド』

表記規則

このマニュアルでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック体

イタリックは、ドキュメントのタイトル、強調またはユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

1 Java EEのアップグレード・プロセスの概要

この章では、Java EEの環境とデプロイ済アプリケーションを、Oracle Application Server 10g とOracle Containers for Java EE（OC4J）からOracle Fusion Middleware 11g とOracle WebLogic Serverにアップグレードする方法の概要を説明します。

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

- Java EEのアップグレード・プロセスのフロー・チャート

- Java EEのアップグレード・プロセスの手順を示す表

1.1 Java EEのアップグレード・プロセスのフロー・チャート

図1-1は、Java EEのアップグレード・プロセスのフロー・チャートを示しています。この図を参照して、実行する必要のあるタスクを理解してください。

図1-1 Java EEのアップグレード・プロセスのフロー・チャート

「図1-1 Java EEのアップグレード・プロセスのフロー・チャート」の説明

1.2 Java EEのアップグレード・プロセスの手順を示す表

表1-1は、アップグレード・プロセスのフロー・チャート（図1-1を参照）に示されている各手順について説明しています。この表には、プロセスの各手順について、詳細情報の参照先も示されています。

表1-1 Java EEのアップグレード・プロセスの手順を示す表

手順

説明

詳細情報

アップグレードの準備

Java EEアプリケーションとJava EE環境のOC4JからOracle WebLogic Serverへのアップグレードを開始する前に、次の準備を行います。

- Oracle WebLogic Serverの主な概念およびOC4Jとの相違点を確認します。

- Oracle WebLogic Serverに必要なインストール・タスクおよび構成タスクの違いを理解します。

- Oracle WebLogic Server環境で使用する必要のある管理ツールと管理プロセスを確認します。

第I部「Java EEのアップグレードの準備」

デプロイ済アプリケーションのアップグレード

Oracle WebLogic Server上で正常にデプロイと実行が行われるように、必要に応じてアプリケーションを変更します。

SmartUpgradeコマンドライン・ツールおよびOracle JDeveloper拡張機能は、アプリケーションのアップグレードに必要なタスクを特定する際に役立ちます。また、アプリケーションを変更するための具体的なアーティファクトの生成に役立つ場合もあります。

第4章「Java EEアプリケーションのアップグレード」

『Oracle Fusion Middleware SmartUpgradeユーザーズ・ガイド』

Oracle WebLogic Server環境の設定

アプリケーション・ソース・コードをアップグレードしたら、アプリケーション用のOracle WebLogic Server環境をインストールして構成します。

Oracle WebLogic Serverドメインの構成時に、アプリケーションに必要なリソースも構成できます。

SmartUpgradeコマンドライン・ツールおよびOracle JDeveloper拡張機能は、Oracle WebLogic Serverでのアプリケーションに必要なリソースの構成方法を特定する際に役立ちます。

第5章「Java EE環境のアップグレード」

『Oracle Fusion Middleware SmartUpgradeユーザーズ・ガイド』

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

Oracle WebLogic Serverにアップグレードしたアプリケーションに依存するクライアント・アプリケーションをアップグレードします。

第6章「アプリケーション・クライアントのアップグレード」

Web層の構成

必要に応じて、Web層をインストールして構成し、リクエストをテスト環境や本番環境にルーティングします。

Oracle Application Server 10g でOracle HTTP ServerまたはOracle Web Cacheを使用していた場合は、Oracle Fusion Middleware Upgrade Assistantを使用してOracle HTTP ServerとOracle Web Cacheの構成をアップグレードできます。

第7章「Java EEおよびWebサーバー環境のアップグレード」

第I部

Java EEのアップグレードの準備

第I部の内容は次のとおりです。

- 第2章「Java EEをアップグレードする際のサポートされる開始点」

- 第3章「OC4JユーザーのためのOracle WebLogic Serverの概要説明」

2 Java EEをアップグレードする際のサポートされる開始点

このマニュアルでは、Java EEのアプリケーションと環境をOracle Application Server 10g リリース3（10.1.3.1.0）からOracle Fusion Middleware 11g にアップグレードする手順について説明します。

Oracle Application Server 10g リリース3（10.1.3）ソフトウェアについて、次の点に注意してください。

- Oracle Application Server 10g リリース3（10.1.3.1.0）には、Oracle SOA Suiteのコンポーネントが含まれますが、OC4JのみのインストールまたはOC4JとOracle HTTP Serverのみのインストールを行うオプションもあります。このマニュアルでは、これらのスタンドアロンのOC4Jインスタンス、および統合されたWebサーバーとOC4J中間層のトポロジに焦点を当てて説明します。
SOA環境とSOAアプリケーションのアップグレードについては、『Oracle Fusion Middleware Oracle SOA Suite、WebCenterおよびADFアップグレード・ガイド』を参照してください。

- アップグレード・プロセスを開始する前に、Oracle Application Server 10gリリース3（10.1.3）の最新のパッチ・セットが適用済であることを確認する必要があります。
10.1.3.4パッチ・セットは、このマニュアルの公開時点で最新の入手可能なパッチ・セットです。

インストールに使用可能な最新のパッチ・セットのリストは、次のMy Oracle Support（旧OracleMetaLink）を参照してください。

http://support.oracle.com

注意:
現在Oracle Fusion Middleware 11gを実行している場合は、Oracle Fusion Middlewareの最新パッチの適用に関する情報が提供されている『Oracle Fusion Middlewareパッチ適用ガイド』を参照してください。
このマニュアルおよびOracle Fusion Middleware 11gドキュメント・ライブラリにあるその他のアップグレード・ガイドには、Oracle Application Server 10gから最新のOracle Fusion Middleware 11gリリースにアップグレードする手順が記述されています。

3 OC4JユーザーのためのOracle WebLogic Serverの概要説明

過去のリリースでは、Oracle Application ServerにOracle Containers for Java EE（OC4J）が含まれており、OC4JがJava EEアプリケーションの開発、デプロイおよび管理に使用する業界標準のコンテナを提供していました。

Oracle Fusion Middleware 11g では、OC4JがOracle WebLogic Serverに置き換えられました。

そのため、Oracle Fusion Middlewareの中核となるアーキテクチャは、1つの管理サーバーと1つ以上の管理対象サーバーで構成されるWebLogic Serverドメインを中心として構築されています。

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

- OC4JユーザーのためのOracle WebLogic Serverの主な概念

- OC4JユーザーのためのOracle WebLogic Serverのインストールおよび構成ツール

- OC4JユーザーのためのOracle WebLogic Serverの管理ツール

- OC4JおよびOracle WebLogic Serverの標準のサポート

3.1 OC4JユーザーのためのOracle WebLogic Serverの主な概念

次の項では、OC4JユーザーがOracle WebLogic Serverへのアップグレードを準備する際に知っておく必要のある主な概念について説明します。

- OC4JとOracle WebLogic Serverのアーキテクチャの比較

- OC4JとOracle WebLogic Serverのディレクトリ構造の比較

- OC4JユーザーのためのOracle WebLogic Serverドメインの理解

3.1.1 OC4JとOracle WebLogic Serverのアーキテクチャの比較

OC4JとOracle WebLogic Serverのトポロジを比較する場合は、次の2つの基本的なトポロジを検討できます。

- スタンドアロンのOC4JおよびスタンドアロンのOracle WebLogic Server

- Webサーバーと統合されたOC4JおよびOracle WebLogic Server

- OC4JおよびOracle WebLogic Serverのクラスタリング機能

3.1.1.1 スタンドアロンのOC4JおよびスタンドアロンのOracle WebLogic Server

図3-1は、一般的なスタンドアロンのOC4JインスタンスとスタンドアロンのOracle WebLogic Serverドメインの比較を示しています。いずれの場合も、インスタンスやドメインへのHTTPリクエストは組込みHTTPリスナーによって処理されます。

Oracle WebLogic Serverの管理対象サーバーは、Oracle Application Server 10g で構成したOC4Jインスタンスに似ています。ただし、Oracle WebLogic Serverでは、Oracle WebLogic Server管理コンソールをホストする専用の管理サーバーが常に提供されます。管理コンソールでは、OC4Jの管理に使用するApplication Server Controlに似た、Oracle WebLogic Server用のWebベースの管理ツールが提供されます。

管理対象サーバーのない単純なOracle WebLogic Server開発ドメインも構成できます。このような環境では、アプリケーションは管理サーバーにデプロイします。ただし、通常、管理サーバーは管理コンソールのホスト専用であり、アプリケーションはドメイン内の1つ以上の管理対象サーバーにデプロイします。

図3-1 Oracle WebLogic ServerとOC4Jのスタンドアロン・アーキテクチャの比較

「図3-1 Oracle WebLogic ServerとOC4Jのスタンドアロン・アーキテクチャの比較」の説明

3.1.1.2Webサーバーと統合されたOC4JおよびOracle WebLogic Server

図3-2は、一般的なOracle Application Server 10g リリース2（10.1.2）の統合されたWebサーバーおよびOC4J中間層インストールと、Oracle Fusion Middleware 11g における同様のトポロジとの比較を示しています。

Oracle Fusion Middlewareでは、Web層とユーティリティのCD-ROMに格納されているインストールおよび構成ツールを使用して、個別のWeb層インストールをインストールして構成する必要があります。

図3-2 フロントエンドWebサーバーを使用したOracle WebLogic ServerとOC4Jの比較

「図3-2 フロントエンドWebサーバーを使用したOracle WebLogic ServerとOC4Jの比較」の説明

3.1.1.3 OC4JおよびOracle WebLogic Serverのクラスタリング機能

Oracle Application Server 10g リリース3（10.1.3）では、クラスタリングに関する次の概念を導入しています。

- Oracle Application Serverのクラスタ・トポロジ: 1つのアクティブなOracle Enterprise Manager Application Server Controlから複数のOracle Application Serverインスタンスを管理可能にします。
Application Server Controlの「クラスタ・トポロジ」ページから、クラスタ・トポロジ内の複数のOracle Application Serverインスタンスを表示し、これらのインスタンスに対して管理タスクを実行できます。クラスタ・トポロジ内の異なるインスタンス間の通信は、Oracle Notification Service（ONS）を使用して行います。

- OC4Jグループ: クラスタ・トポロジ内のOC4Jインスタンスをグループ化し、OC4Jインスタンスに対してグループ全体のタスクを一度に実行するメカニズムを提供します。
たとえば、OC4Jインスタンスのグループを作成した後、そのグループにアプリケーションをデプロイしたり、そのグループのデータソースを変更することができます。ただし、重要な制限が1つあり、グループ内の各OC4Jの構成がグループ内の他のOC4Jインスタンスと同一である必要があります。

- OC4Jアプリケーション・クラスタリング: クラスタ・トポロジ内の異なるOC4Jインスタンスにデプロイされたアプリケーション間で状態情報を交換可能にする機能です。

これらのOC4J機能とOracle WebLogic Serverの相違点の詳細は、次を参照してください。

- 表3-1は、OC4Jのクラスタリング機能とOracle WebLogic Serverで使用可能なクラスタリング機能の比較を示しています。

- 図3-3は、OC4JとOracle WebLogic Serverのクラスタリングの相違点を示しています。

表3-1 OC4Jのクラスタリング機能とOracle WebLogic Serverの比較

OC4Jの機能

Oracle WebLogic Serverにおける同等の機能

詳細情報

Oracle Application Serverのクラスタ・トポロジ

Oracle WebLogic Serverドメイン

"Oracle Fusion MiddlewareのOracle WebLogic Serverドメイン構成に関するドキュメントのWebLogic Serverドメインの理解に関する項

OC4Jグループ

Oracle WebLogic Serverクラスタ

"『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使い方』のWebLogic Serverのクラスタリングの理解に関する項およびクラスタ・アーキテクチャに関する項

OC4Jアプリケーション・クラスタリング

Oracle WebLogic ServerのHTTPセッション・ステート・レプリケーション

"『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使い方』のHTTPセッション・ステート・レプリケーションに関する項

図3-3 OC4JグループとOracle WebLogic Serverクラスタの比較

「図3-3 OC4JグループとOracle WebLogic Serverクラスタの比較」の説明

3.1.2 OC4JとOracle WebLogic Serverのディレクトリ構造の比較

一般的なOracle WebLogic Serverドメインのディレクトリ構造は、Oracle Application Server 10g インスタンスのディレクトリ構造といくつかの点で異なります。

Oracle Application Server 10g をインストールする場合は、j2eeディレクトリを含む単一のOracleホームを作成します。OC4J固有の構成ファイルとログ・ファイルはj2eeディレクトリ内に格納されます。

Oracle WebLogic Serverでは、インストールはMiddlewareホーム内のみで行われます。Middlewareホーム内で、インストーラによりOracle WebLogic Serverホーム・ディレクトリが作成されます。ドメインを構成する場合は、Oracle WebLogic Server構成ウィザードを使用してuser_projectsディレクトリ内に新規ドメインを作成します。

図3-4は、Oracle WebLogic ServerとOC4Jのディレクトリ構造の違いを示しています。

図3-4 Oracle WebLogic ServerとOC4Jのディレクトリ構造の比較

「図3-4 Oracle WebLogic ServerとOC4Jのディレクトリ構造の比較」の説明

3.1.3 OC4JユーザーのためのOracle WebLogic Serverドメインの理解

次の項は、OC4JユーザーがOracle WebLogic Serverドメインの機能を学習するために役立ちます。

- ドメインの基本的なコンテンツと編成

- Oracle WebLogic Serverドメインに関するその他の情報

3.1.3.1 ドメインの基本的なコンテンツと編成

10g リリース2（10.1.2）または10g リリース3（10.1.3）のどちらを使用してるかに応じて、Oracle Application Server 10g 環境を次の2つの方法のうちいずれかで編成します。

- Oracle Application Server 10g リリース3（10.1.3）では、クラスタ・トポロジにアプリケーション・サーバーとOC4Jインスタンスを編成します。

- Oracle Application Server 10g リリース2（10.1.2）では、複数のOracle Application Serverインスタンスをファームに、OC4JインスタンスをOracle Application Serverクラスタに追加できます。

Oracle Fusion Middleware 11g では、まったく異なるメカニズムを使用して環境を編成します。Oracle WebLogic Server環境は、ドメインと呼ばれる論理グループに分類されます。これらのドメインは、次のもので構成されます。

- 単一の管理サーバー: ドメインの管理に使用します。

- 1つ以上の管理対象サーバー: Oracle Fusion MiddlewareのJavaコンポーネントおよびカスタムJava EEアプリケーションのデプロイに使用します。

以前のバージョンのOracle Application Server 10gでは、OC4Jインスタンスと、OC4Jインスタンスごとに1つ以上のJava仮想マシン（JVM）をインストール、作成および構成しました。

Oracle Fusion Middleware 11g では、1つの管理サーバーと1つ以上の管理対象サーバーを含むOracle WebLogic Serverドメインを構成して、Java EEアプリケーションをデプロイします。

3.1.3.2 Oracle WebLogic Serverドメインに関するその他の情報

次の項では、OC4J環境からOracle WebLogic Server環境に移行する際に役立つOracle WebLogic Serverドメインの詳細を説明します。

- WebLogic Serverのインストールを使用した複数のドメインの構成

- 常に単一のJava仮想マシン・プロセスに関連付けられるWebLogic Serverインスタンス

- すべてのアプリケーション・リクエストを同じポート上で処理するWebLogic Serverインスタンス（デフォルト）

- 常にHTTPリスナーが組み込まれ、AJPはサポートしていないWebLogic Serverインスタンスの構成

3.1.3.2.1 WebLogic Serverのインストールを使用した複数のドメインの構成

図3-4に示すように、作成したOC4Jインスタンスに関連付けられているバイナリ・ファイルと構成ファイルは、Oracle Application Server 10g のOracleホーム（j2eeディレクトリ構造）内のサブディレクトリ構造に格納されます。このような直接的なファイル・システムの関連付けが必要なだけではなく、OC4Jのバイナリとインスタンス構成との間の関係がインスタンスごとのレベルになります。

対照的に、Oracle WebLogic Serverでは、インストールされたソフトウェアとその各種構成インスタンスが明確に分離されています。単一のOracle WebLogic Serverのインストールを使用して、それぞれが異なる一連のサーバーで構成された複数のドメインを作成できます。

デフォルトでは、Oracle WebLogic Server構成ウィザードは、各ドメインの構成ファイルがuser_projects/domainsディレクトリ内に配置されることを前提としています。ただし、ドメインに関連付けられたファイルはファイル・システム内のどこにでも配置できます。WebLogic Serverインスタンスをドメイン・ディレクトリから実行する場合の唯一の要件は、Oracle WebLogic Serverディレクトリがアクセス可能であることです。

また、WebLogic Serverモデルでは、WebLogic Serverのバイナリとインスタンス構成の間の関係は、ドメイン（一連のインスタンス）レベルとなります。

3.1.3.2.2 常に単一のJava仮想マシン・プロセスに関連付けられるWebLogic Serverインスタンス

OC4Jは、標準のJava Development Kit（JDK）のJava仮想マシン（JVM）上で実行されます。デフォルトでは、OC4Jインスタンスごとに1つのJVMを使用します。ただし、1つのOC4Jインスタンスを複数のJVMで実行するように構成することもできます。このようにOC4Jインスタンスを構成するには、numprocプロパティを使用するか、またはApplication Server Controlコンソールを使用します。

OC4Jインスタンスを複数のJVMで実行するように構成すると、そのOC4Jインスタンスは基本的に複数のプロセスで実行されます。これによって、パフォーマンスが向上し、デプロイ済アプリケーションのフォルト・トレランスのレベルが高まります。ただし、複数のJVMを使用すると、効率的な実行のために追加のハードウェア・リソースが必要になります。

Oracle WebLogic Serverには、これと同等の設定または機能はありません。かわりに、各サーバーが常に単一のJava仮想マシン上で実行されます。ただし、ドメイン内の同じホスト上で実行される管理対象サーバーの数を増やすことで、OC4Jのnumproc設定と同じ機能が得られます。

3.1.3.2.3 すべてのアプリケーション・リクエストを同じポート上で処理するWebLogic Serverインスタンス（デフォルト）

OC4Jインスタンスでは、リクエストの受入れが可能なプロトコルごとに異なる一連のリスニング・ポートを使用します。OC4Jでは、OC4J Webサイトの概念を使用して、OC4Jインスタンスごとに特定のHTTP、HTTPS、AJPまたはAJPSポート（またはポート範囲）を構成します。同様に、OC4JインスタンスではRMIおよびJMSトラフィック用の専用ポート（およびポート範囲）を構成できます。

デフォルトでは、WebLogic Serverのリクエスト・ポートおよびプロトコル管理モデルは、次の2つの重要な点でOC4Jと異なります。

- 最初に、Oracle WebLogic Serverインスタンスは受信アプリケーション・リクエストに対して2つのリスニング・ポートのみを使用するように構成されています。1つは暗号化されていないリクエスト用（必ず設定）、もう1つはSSL暗号化リクエスト用（任意）です。

- 次に、これらのポートは、ポートが特定のプロトコル専用となるOC4Jインスタンスのケースとは対照的に、サポートされているすべてのプロトコルのリクエストを受け入れるように構成されます。

通常は、このデフォルトのリスニング・ポート・モデルでほとんどのユースケースに対応できますが、Oracle WebLogic Serverではネットワーク・チャネルと呼ばれる機能を提供しています。この機能を使用すると、特定のプロトコル専用のポートを追加してWebLogic Serverインスタンスを構成できます。この機能は、このような構成を必要とする特別なユースケースに使用できます。

3.1.3.2.4 常にHTTPリスナーが組み込まれ、AJPはサポートしていないWebLogic Serverインスタンスの構成

サポートされているOC4J構成の1つに、フロントエンドWebサーバー（ほとんどの場合、Oracle HTTP Server）が受信HTTPリクエストを受信するように構成されているトポロジがあります。受信リクエストは次に、AJPプロトコルを介してOracle HTTP Serverから適切なOC4Jインスタンスへとルーティングされます。この構成では、OC4Jインスタンスは直接HTTPリクエストを受信せず、OC4JインスタンスでHTTPリスナーは構成されていません。

対照的に、Oracle WebLogic Serverインスタンスでは常にHTTPリクエストを受け入れますが、AJPをサポートしていません。ただし、セキュリティとスケーラビリティを確保するために、WebLogic Serverドメインの前面にWeb層を配置できます（多くの場合は配置されています）。Oracle HTTP Serverを含む多くのWebサーバーは、WebLogic Serverドメイン内のサーバーに対するWeb層として機能することが保証されています。

詳細は、第7章「Java EEおよびWebサーバー環境のアップグレード」を参照してください。

3.2 OC4JユーザーのためのOracle WebLogic Serverのインストールおよび構成ツール

Oracle Application Server 10g とは異なり、Oracle WebLogic Serverでは、環境のインストール・タスクと構成タスクを分離しています。

Oracle Application Server 10g では、Oracle Universal Installerを使用してOracle Application Server環境（その環境内のOC4Jインスタンスを含む）のインストールと構成を行います。

Oracle WebLogic Serverでは、次の2つの個別ツールを使用して環境のインストールと構成を行います。

- Oracle WebLogic Serverインストーラ: Oracle WebLogic Serverドメインを構成する準備として、ディスク上にMiddlewareホームを作成し、必要なOracle WebLogic Serverファイルを配置するために使用します。

- Oracle WebLogic Server構成ウィザード: Oracle WebLogic Serverドメインの作成と構成に使用します。

このようにインストール・タスクと構成タスクを分離することにより、3.1.3.2.1項で説明されているように、単一のOracle WebLogic Serverインスタンスから複数のドメインを作成できます。

3.3 OC4JユーザーのためのOracle WebLogic Serverの管理ツール

次の項では、OC4JとOracle WebLogic Serverの管理に使用できる管理ツールの比較に加えて、Oracle WebLogic Serverの一般的な管理タスクの実行方法の概要も説明します。

- OC4JおよびOracle WebLogic Serverの管理ツールの比較

- OC4Jユーザーのための一般的なOracle WebLogic Serverの管理タスク

3.3.1 OC4JおよびOracle WebLogic Serverの管理ツールの比較

Oracle WebLogic Serverドメインの管理に使用するツールは、OC4Jベースの環境の管理に使用するツールとは次の点で異なります。

- 表3-2に、2つの製品で使用されている同等の管理ツールの比較を示します。

- 表3-3は、OC4Jでは使用できないその他の管理ツールについて説明しています。

Oracle WebLogic Serverの管理ツールの完全なリストについては、Oracle WebLogic Serverの紹介に関するドキュメントのシステムの管理ツールとAPIの概要に関する項を参照してください。

表3-2 OC4JおよびOracle WebLogic Serverの管理ツールの比較

10g リリース3（10.1.3）の管理ツール

Oracle WebLogic Serverの同等の管理ツール

詳細情報

Oracle Enterprise Manager Application Server Control

Oracle WebLogic Server管理コンソール

その他にOracle Enterprise Manager Fusion Middleware Controlと呼ばれるWebベースの管理ツールも使用できます。Fusion Middleware Controlは、ファームと、そのファームのOPMN管理コンポーネントを管理するために使用されます。

"『Oracle Fusion Middleware管理者ガイド』のOracle Fusion Middlewareの管理ツールの概要に関する項

admin_client.jar

WLST（Oracle WebLogic Serverのコマンドライン・スクリプト作成ツール）

"『Oracle Fusion Middleware管理者ガイド』のOracle WebLogicスクリプト作成ツール（WLST）の使用の開始に関する項

opmnctl

opmnctl

OPMNはOracle Fusion Middleware 11g でサポートされていますが、特定のOracle Fusion Middlewareシステム・コンポーネントを管理するためのみに使用されることに注意してください。

ドメイン内の管理対象サーバーの管理など、Oracle Fusion Middleware 11g のその他の構成タスクについては、WLSTを使用します。

"『Oracle Fusion Middleware Oracle Process Manager and Notification Server管理者ガイド』のOracle Process Manager and Notification Serverの使用の開始に関する項

表3-3 その他のOracle WebLogic Serverの管理ツール

管理ツール

説明

weblogic.Deployer

Oracle WebLogic Serverにはweblogic.Deployerというパッケージ化されたデプロイメント・ツールが用意されており、このツールを使用してears、wars、rars、jarsなどのデプロイメント・アーティファクトに対するWebLogic Serverのデプロイメント・サービスを実行します。WebLogicデプロイメントAPIを使用して実装可能なデプロイメント操作の一部またはすべてがweblogic.Deployerによって実装されます。

このツールを使用すると、同様にOC4J admin_client.jarでJava EEアーティファクト・デプロイメントを実行できます。以前のOC4Jリリースでは、OC4Jへのデプロイはadmin.jarとdcmctlのツールを使用して行われていました。

Antタスク

Oracle WebLogic Serverには、Apache Antスクリプト内でWebLogic Serverの管理プロセスを実行できるようにする一連の管理Antタスクが用意されています。これらのAntタスクは、OC4JのAntタスクと同様のタイプの機能を実行します。

3.3.2 OC4Jユーザーのための一般的なOracle WebLogic Serverの管理タスク

次の項では、一般的な管理タスクについて説明しており、これらのタスクはOracle WebLogic Serverで実行します。

- サーバーの起動と停止

- ドメインの診断の実行

- スレッド・プールの構成とチューニング

3.3.2.1 サーバーの起動と停止

OC4Jインスタンスの起動と停止は、Application Server ControlまたはOPMNコマンドライン（opmnctl）を使用して行います。同様に、WebLogic Serverインスタンスの起動と停止は、Oracle WebLogic Server管理コンソールまたはWebLogicのスクリプト作成ツール（WLST）を使用して行います。

また、WebLogic Serverインスタンスは、ドメイン・ディレクトリのbinディレクトリで使用可能な起動スクリプトを介して起動することもできます。これらのスクリプトには、管理サーバーを起動するstartWebLogicスクリプトおよびドメイン内の管理対象サーバーを起動するstartManagedWebLogicスクリプトが含まれています。

詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverサーバーの起動と停止の管理』を参照してください。

3.3.2.2 ドメインの診断の実行

Oracle WebLogic Serverの診断機能は、Weblogic診断フレームワーク（WLDF）を介して提供されます。

Oracle Fusion Middleware 11gでは、WLFDは、ご使用のOracle Fusion Middleware環境において診断を監視および実行するために使用可能な様々なツールおよびプロセスの中にあります。これらのツールおよびプロセスには、Dynamic Monitoring Service（DMS）およびOracle Fusion Middleware診断フレームワークが含まれます。現在DMSを使用しているアプリケーションは、Oracle Fusion Middleware 11g でも引き続きDMSを使用できます。

関連項目:
"『Oracle Fusion Middleware管理者ガイド』の診断フレームワークの理解に関する説明
"『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』のOracle Dynamic Monitoring Serviceに関する説明

Oracle WebLogic ServerのWLDF機能には、動的コード・インスツルメンテーション、イメージ・キャプチャ、監視および通知が含まれます。これらの機能によって、Java EEアプリケーションの管理に関する総所有コストの大幅な削減を可能にする拡張アプリケーション診断機能が実現されます。

また、WLDFの機能は、WLDFコンソール拡張機能を介してOracle WebLogic Server管理コンソール内のカスタム・ダッシュボードとして公開できます。

詳細は、『Oracle Fusion Middleware Oracle WebLogic Server診断フレームワークの構成と使い方』を参照してください。

サード・パーティのアプリケーション管理ツールを使用している場合は、通常、そのサード・パーティのツールを更新すれば、Oracle WebLogic Server上で実行されているアップグレード済アプリケーションに対して引き続きそのツールを使用できます。

3.3.2.3 ドメインのログ・ファイルの表示

Oracle WebLogic Serverのロギング・サービスでは、Oracle Application Server 10g のロギング機能に似た、包括的な一連のロギング機能を提供します。また、Oracle Diagnostics Logging（ODL）フレームワークの機能は、Oracle Fusion Middleware 11gで使用できるJava Required Files（JRF）テンプレートを利用してOracle WebLogic Serverに統合することもできます。

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

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

- ODLログ・メッセージは、ファイル・システム上でOracle WebLogic Serverのログ・ファイルとは個別に格納されているログ・ファイルに送信されます。これらのログ・ファイルは次の場所に格納されています。

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

- 重大なメッセージ（エラー）は、ODLとOracle WebLogic Serverドメイン・ログ・ファイルの両方に記録されます。

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

3.3.2.4 スレッド・プールの構成とチューニング

OC4J Serverインスタンスでは、目的ごとに異なるスレッド・プールを使用します（system、HTTPおよびJCAはデフォルトで起動時に作成されるスレッド・プールです）。各スレッド・プールのパラメータ（スレッド数の最大値や最小値など）は、個別にチューニングできるため、特定の環境に応じた最適なアプリケーション・リクエスト・スループットを実現できます。

Oracle WebLogic Serverインスタンスにはデフォルトで1つのスレッド・プールが作成され、全体的なスループットを最大にするためにスレッド数が自動的にチューニングされます。すべてのリクエストは、着信時に共通キューにエンキューされ、管理構成された目標（アプリケーションで必要とされるレスポンス時間や、他のアプリケーションとの相対的なフェアシェアによる全スレッドの割当てなど）に応じて優先度が決定されます。

WebLogicワーク・マネージャと呼ばれるこのOracle WebLogic Server機能により、Oracle WebLogic Serverインスタンスでは最適なリクエスト処理を実現するためにスレッド数を自己チューニングできます。

詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverサーバー環境の構成』のワーク・マネージャを使用したスケジュール済作業の最適化に関する項を参照してください。

3.4 OC4JおよびOracle WebLogic Serverの標準のサポート

表3-4は、OC4JおよびOracle WebLogic ServerでサポートされているJava標準の比較を示しています。

この表は、比較目的でのみ提供されています。Oracle WebLogic Serverでサポートされている標準の最新情報については、Oracle WebLogic ServerのドキュメントおよびOracle Technology Network（OTN）から入手可能なOracle WebLogic Server情報を参照してください。

表3-4 OC4JおよびOracle WebLogic ServerでサポートされているJava標準の比較

標準

OC4Jでサポートされているバージョン

Oracle WebLogic Serverでサポートされているバージョン

Java SE

6.0

6.0

Java EE

1.4/5.0

5.0

JSP

1.1から2.0

1.1から2.1

JSF

1.1

1.1および1.2

サーブレット

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.0

1.2

Java EE Management

1.0

1.1

JDBC

3.0

3.0

第II部

Java EEのアプリケーションと環境のアップグレード

第II部の内容は次のとおりです。

- 第4章「Java EEアプリケーションのアップグレード」

- 第5章「Java EE環境のアップグレード」

- 第6章「アプリケーション・クライアントのアップグレード」

- 第7章「Java EEおよびWebサーバー環境のアップグレード」

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

この章では、OC4Jアプリケーションをアップグレードし、Oracle WebLogic Serverに再デプロイする場合に実行が必要になる可能性が高い一般的なタスクについて簡単に説明します。

この章の内容は次のとおりです。

- タスク1: アプリケーションがOC4Jに正常にデプロイされ動作していることの確認

- タスク2: 開発ツールの選択

- タスク3: アプリケーションでJava Development Kit（JDK）6がサポートされていることの確認

- タスク4: アプリケーション・デプロイメント・ディスクリプタのアップグレード

- タスク5: Oracle WebLogic Server APIのサポートの確認

- タスク6: アプリケーションのWebサービスのアップグレード

4.1 タスク1: アプリケーションがOC4Jに正常にデプロイされ動作していることの確認

Oracle Application Server 10gアプリケーションをOracle Fusion Middleware 11gにアップグレードする前に、まず、現時点でアプリケーションがOracle Application Server 10gに正常にデプロイされ実行中であることを確認する必要があります。

また、アプリケーションをデプロイしたOC4Jインスタンスに対して行ったアプリケーション固有の構成変更を記録しておきます。たとえば、アプリケーションに特定のデータソース、JMSサーバーまたは他のリソースが必要な場合は、この章で後から説明するようにOracle WebLogic Serverドメインに対して同様の構成変更を行う必要があります。

4.2 タスク2: 開発ツールの選択

Oracle WebLogic ServerおよびOracle Fusion Middlewareプラットフォーム用のJava EEアプリケーションを開発するための最適なツールを選択する際に役立つ情報については、次の項を参照してください。

- 開発ツールを選択する場合の一般的なガイドライン

- SmartUpgrade Oracle JDeveloper拡張機能およびコマンドライン・ツールの使用

4.2.1 開発ツールを選択する場合の一般的なガイドライン

Oracle Application Development Framework（ADF）、Oracle Metadata Services（MDS）、Oracle SOA Suite、Oracle WebCenterなどのOracleテクノロジを利用していないJava EEアプリケーションの場合は、使い慣れた開発ツールを使用してコード変更を行うことができます。

ただし、Oracleテクノロジを利用する場合は、統合開発環境（IDE）であるOracle JDeveloperの使用をお薦めします。Oracle JDeveloperを使用すると、Oracle Fusion Middleware向けのADF、SOAおよびWebCenterアプリケーションの開発、テストおよびデプロイを大幅に簡単かつ効率的に行うことができます。

4.2.2 SmartUpgrade Oracle JDeveloper拡張機能およびコマンドライン・ツールの使用

Oracle ADF、Oracle SOA、Oracle WebCenterなどのOracleテクノロジを利用するアプリケーションを容易に作成する機能の提供の他に、Oracle JDeveloperには、OC4JアプリケーションをOracle WebLogic Serverにアップグレードするための拡張機能もあります。

SmartUpgrade拡張機能を使用すると、Oracle JDeveloperを使用して既存のエンタープライズ・アーカイブ（EAR）ファイルを分析し、一連の分析結果を順に確認するSmartUpgradeレポートを生成できます。それぞれの分析結果は、アプリケーションをどのように修正するとOracle WebLogic Serverに正しくデプロイできるかを示すアドバイスになります。

詳細は、『Oracle Fusion Middleware SmartUpgradeユーザーズ・ガイド』を参照してください。

4.3 タスク3: アプリケーションでJava Development Kit（JDK）6がサポートされていることの確認

Oracle Fusion Middleware 11g ではJDK SE 6をサポートしています。アプリケーションをOracle WebLogic Serverに再デプロイする前に、アプリケーションのJavaソース・コードとJDK 6に互換性があることを確認します。

詳細は、次のSun社Webサイトで提供されているリソースを参照してください。

http://java.sun.com/javase/6/

4.4 タスク4: アプリケーション・デプロイメント・ディスクリプタのアップグレード

OC4JおよびOracle WebLogic Serverはどちらも、Java EE標準のデプロイメント・ディスクリプタだけでなく、対応する専用ディスクリプタもサポートしています。ただし、OC4JアプリケーションをOracle WebLogic Serverに再デプロイする場合は、Oracle WebLogic Serverの要件に準拠するようにapplication.xml、web.xmlなどのアプリケーション・ディスクリプタを変更する必要があります。

アプリケーション・デプロイメント・ディスクリプタのアップグレードについて詳しく学習するには、次の項を参照してください。

- OC4JおよびOracle WebLogic Serverのデプロイメント・ディスクリプタの比較

- Oracle WebLogic Serverのデプロイメント・ディスクリプタのアップグレードに関するガイドラインおよびリソース

4.4.1 OC4JおよびOracle WebLogic Serverのデプロイメント・ディスクリプタの比較

標準のデプロイメント・ディスクリプタとOC4J固有のディスクリプタについて理解している場合は、表4-1を参照して、Oracle WebLogic Server環境での同等のデプロイメント・ディスクリプタ・ファイルを確認できます。

表4-1 J2EE、OC4JおよびWebLogic Serverのデプロイメント・ディスクリプタ

J2EE標準ディスクリプタ

OC4J専用ディスクリプタ

WebLogic専用ディスクリプタ

application.xml

orion-application.xml

weblogic-application.xml

web.xml

orion-web.xml

weblogic.xml

ejb-jar.xml

orion-ejb-jar.xml

weblogic-ejb-jar.xml

application-client.xml

orion-application-client.xml

weblogic-appclient.xml

ra.xml

oc4j-ra.xml

weblogic-ra.xml

webservices.xml

oracle-webservices.xml

weblogic-webservices.xml

4.4.2 Oracle WebLogic Serverのデプロイメント・ディスクリプタのアップグレードに関するガイドラインおよびリソース

WebLogic Serverにデプロイできるようにアプリケーションを準備するには、OC4J固有のデプロイメント・ディスクリプタを削除し、WebLogic Server固有の同等の設定に置き換える必要があります。

デプロイを正常に行うには、各デプロイメント・ディスクリプタを調べ、アプリケーションで使用されるデプロイメント・ディスクリプタ機能ごとに次のいずれかの操作を実行します。

- OC4Jのデプロイメント・ディスクリプタ機能が、WebLogic Server固有の同等のデプロイメント・ディスクリプタ内に直接マップされている場合は、同等のWebLogic Serverディスクリプタに適切な要素と値を指定して使用します。

- OC4Jのデプロイメント・ディスクリプタ機能が直接マップされていない場合は、適切なOracle WebLogic Serverドキュメントを確認します。
Oracle WebLogic Serverのデプロイメント・ディスクリプタに直接マップされていない機能は、多くの場合、WebLogicドメインを適宜構成することによって使用できるようになります。

表4-2に、デプロイメント・ディスクリプタをOracle WebLogic Serverへアップグレードする場合に役立つドキュメント・リソースのリストを示します。

表4-2 デプロイメント・ディスクリプタをOracle WebLogic Serverにアップグレードする場合のドキュメント・リソース

アップグレード先となるWebLogic固有のデプロイメント・ディスクリプタ

参照先ドキュメント・リソース

weblogic-application.xml

"『Oracle Fusion Middleware Oracle WebLogic Serverアプリケーションの開発』のエンタープライズ・アプリケーション・デプロイメント・ディスクリプタ要素に関する項

weblogic.xml

付録A「orion-web.xmlおよびorion-ejb-jar.xmlのアップグレード・リファレンス」。orion-web.xmlファイルとorion-ejb.jar.xmlファイルの各デプロイメント・ディスクリプタ要素についてアップグレードの際のアドバイスを示しています。

weblogic-ejb-jar.xml

付録A「orion-web.xmlおよびorion-ejb-jar.xmlのアップグレード・リファレンス」。orion-web.xmlファイルとorion-ejb.jar.xmlファイルの各デプロイメント・ディスクリプタ要素についてアップグレードの際のアドバイスを示しています。

weblogic-appclient.xml

"『Oracle Fusion Middleware Oracle WebLogic Serverスタンドアロン・クライアントのプログラミング』のクライアント・アプリケーション・デプロイメント・ディスクリプタ要素に関する項

weblogic-ra.xml

"『Oracle Fusion Middleware Oracle WebLogic Serverリソース・アダプタのプログラミング』のweblogic-ra.xmlファイルの構成に関する項

weblogic-webservices.xml

"『Oracle Fusion Middleware Oracle WebLogic Server WebLogic Webサービス・リファレンス』のWeblogic Webサービス・デプロイメント・ディスクリプタ要素に関する項

4.4.3 デプロイメント・ディスクリプタ・ファイルのセキュリティ要素について

5.3.6項「Oracle WebLogic Server上でのセキュリティの構成」で推奨されている手順を使用する場合、web.xmlやejb-jar.xmlなどの標準のJava EEアプリケーション・デプロイメント・ディスクリプタに格納されているセキュリティの構成（認証方法、セキュリティ制約、EJBメソッドの権限など）は、そのままアップグレードに使用することができ、アプリケーションがOracle WebLogic Serverにデプロイされても引き続き機能します。

OC4J固有のディスクリプタで指定されているセキュリティ構成（セキュリティ・ロール・マッピングなど）については、WebLogic Server Securityドキュメントを参照して、4.4.1項「OC4JおよびOracle WebLogic Serverのデプロイメント・ディスクリプタの比較」で説明されている同等のOracle WebLogic Serverデプロイメント・ディスクリプタ内の要素に各構成をマップしてください。

4.4.4 デプロイメント・プランのアップグレード

デプロイメント・プランは、Oracle WebLogic ServerとOC4Jの両方でサポートされている標準のJava EEサーバー機能です。ただし、デプロイメント・プランはアプリケーション・サーバー間で移植できません。OC4JからOracle WebLogic Serverにアップグレードする場合は、デプロイメント・プロセスの一部としてOracle WebLogic Serverに保存されるアプリケーションのデプロイメント・プランを再生成して保存する必要があります。また、weblogic.PlanGeneratorコマンドライン・ツールを使用して、新しいデプロイメント・プランを構築することもできます。

詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverへのアプリケーションのデプロイ』のweblogic.PlanGeneratorの概要に関する項を参照してください。

4.5 タスク5: Oracle WebLogic Server APIのサポートの確認

Oracle Application Server 10g アプリケーションをOracle WebLogic Serverに再デプロイする前に、アプリケーションを確認し、ソース・コードが参照するアプリケーション・プログラミング・インタフェースを特定する必要があります。

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

- Java Required Files（JRF）ドメイン・テンプレートで使用可能なAPI

- その他のOracle WebLogic Server APIの要件

4.5.1 Java Required Files（JRF）ドメイン・テンプレートで使用可能なAPI

Oracle Fusion Middleware11g には、Oracle Java Required Files（JRF）テンプレートと呼ばれるOracle WebLogic Serverドメイン・テンプレートが用意されています。このテンプレートを使用して、Oracle WebLogic Serverドメインを作成（または拡張）できます。作成または拡張されたドメインには、Oracle Application Server 10g の主要機能の一部の更新済バージョンが格納されます。

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

特に、JRFテンプレートを使用すると、Oracle Fusion Middleware 11g で次のOracle Application Server機能をサポートできます。

- Dynamic Monitoring System（DMS）

- Diagnostics Loggingフレームワーク（ODL）

- Oracle HTTPクライアント

- Oracle Java Object Cache

- Oracle XML

- Oracle Security Developer Tools

- Oracle Platform Security Services（OPSS）

- Oracle Globalization Development Kit

これらのAPIを使用するアプリケーションは、JRFで拡張されたドメインを使用できるので、そのAPIへの更新の結果として必要になる変更以外に変更は必要ありません。

詳細は、第5章「Java EE環境のアップグレード」を参照してください。

4.5.2 その他のOracle WebLogic Server APIの要件

表4-3に、その他のOracle Application Server 10g のAPIの概要と、これらがOracle Fusion Middleware 11g へのアップグレードによって受ける影響の概要を示します。

表4-3 Oracle Fusion Middleware 11g へのアップグレード時に必要なその他のAPIの変更

API

説明および必要な操作

詳細情報

Oracle JAZN（Java Authorization）

Oracle Fusion Middleware 11g で用意されているJRFドメイン・テンプレートでは、Oracle Platform Security Services（OPSS）APIが提供する機能セットと同等の更新済の機能セットが提供されます。

現在Oracle JAZN APIを使用してセキュリティ管理を行っているアプリケーションは、アップグレードの一環としてOPSSを使用するように更新を行い、これらのアプリケーションをJRFで拡張されたOracle WebLogic Serverドメインにデプロイできるようにする必要があります。

"『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のOracle Platform Security Servicesの概要に関する説明

Oracle TopLink

引き続きOracle Toplinkを使用するには、対象となるOracle WebLogic ServerドメインがJPA永続性プロバイダとしてOracle TopLinkを使用するように構成されている必要があります。

Oracle WebLogic ServerではOracle TopLinkの完全なサポートを保証しています。

『Oracle Fusion Middleware Oracle TopLink開発者ガイド』のTopLinkとOracle WebLogic Serverの統合に関する項

Oracle JSPタグ・ライブラリ（ojsputil.jar、jstl.jar）

引き続きこれらのタグ・ライブラリを使用するには、Oracle JSPタグ・ライブラリに関連付けられているOracle Application Server 10g のTLDファイルとJARファイルが、次のWARファイルのディレクトリに存在するようにしてください（このディレクトリにない場合は配置します）。

- WEB-INF/tld

- WEB-INF/lib

該当なし

Oracle Web Cacheの無効化

Web Cacheの無効化APIを引き続き使用するには、WebLogic Serverへのデプロイ時にアプリケーションでOracleAS 10g の適切なjarファイルが使用できるようにします。

また、このAPIの完全な下位互換性を持つ更新済バージョンもJRFドメイン・テンプレートの一部として提供されています。

4.5.1項「Java Required Files（JRF）ドメイン・テンプレートで使用可能なAPI」

OracleAS Web Services

Oracle Web Servicesプロキシ

Oracle Web Services SOAP

Oracle Web Services UDDIクライアント

OracleAS Web Servicesを使用するアプリケーションでは、Oracle Fusion MiddlewareまたはWebLogic ServerのAPIおよび機能と同等のセットを使用するために変更が必要です。具体的には次のようになります。

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

- Oracle Web Services UDDIクライアントAPIを使用しているアプリケーションは、UDDI v1、v2またはv3に準拠したOracle Service Registry UDDIクライアントAPIを使用するように変更する必要があります。

『Oracle Fusion Middleware Oracle WebLogic Server WebLogic Webサービスの紹介』

OC4J Job Scheduler

OC4J Job Schedulerに対してはOracle Fusion Middleware Enterprise Scheduler（ESS）へのアップグレードおよび移行パスが提供されています。

Oracle Technology Network（OTN）で提供されているOracle Ultra Search vs Oracle Secure Enterprise Search, Frequently Asked Questionsに関するマニュアル（PDF形式）

OC4J Support for JSP

このAPIを使用するアプリケーションは、Java Standard Tag Library（JSTL）タグの同等のセットを使用するように変更する必要があります。

『Oracle Fusion Middleware Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』

OC4J JMX MBean

アプリケーションおよび環境の管理を目的としてOC4J JMX MBeanを直接使用しているアプリケーションは、WebLogic Server JMX MBeanの同等のセットを使用するように変更する必要があります。

『Oracle Fusion Middleware Developing Manageable Applications With JMX for Oracle WebLogic Server』

4.6 タスク6: アプリケーションのWebサービスのアップグレード

WebサービスをOC4JからOracle WebLogic Serverにアップグレードするには、次の項を参照してください。

- Oracle WebLogic ServerのJAX-RPCおよびJAX-WS Webサービスにアップグレードする場合の一般的なガイドライン

- OC4J WSDLからのOracle WebLogic ServerのWebサービスの生成

- OC4JおよびOracle WebLogic ServerでサポートされているWebサービスの仕様

4.6.1 Oracle WebLogic ServerのJAX-RPCおよびJAX-WS Webサービスにアップグレードする場合の一般的なガイドライン

一般的に、WebサービスをOC4JからOracle WebLogic Serverにアップグレードする場合は、アプリケーションをアップグレードしてWebLogic Serverで同等のJava WebサービスAPIを使用できるようにする必要があります。

- ほとんどのOC4J Webアプリケーションにとって、これはOC4J JAX-RPC WebサービスからOracle WebLogic Server JAX-RPC Webサービスへのアップグレードを意味します。通常、JAX-RPCのアップグレード・プロセスでは、Oracle WebLogic ServerのWebサービス・ツールを使用して、Oracle WebLogic Server上のJavaアーティファクトを、基礎となる同じJavaビジネス・ロジックに再生成します。

- 古いリリースのOC4Jを使用している場合は、Java EE内にWebサービスの標準が存在しないため、Oracle WebLogic ServerでJava EE 5.0の標準仕様であるJAX-WSにアップグレードすることをお薦めします。

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

- "『Oracle Fusion Middleware Oracle WebLogic Server WebLogic Webサービスの紹介』のJAX-WSまたはJAX-RPCの選択方法に関する項

4.6.2 OC4J WSDLからのOracle WebLogic ServerのWebサービスの生成

特定のOC4J WebサービスのパブリックAPI（WDSL）に完全に準拠するには、WebLogic ServerのWebサービスをOC4J WSDLから再生成し、生成されたWebサービスをWebLogic Serverにデプロイします。このプロセスは、Webサービス開発のトップダウン方式と呼ばれます。

Oracle WebLogic Serverでデプロイ可能な同等のWebサービス・アーティファクトを作成した後は、次の管理操作として、WS-SecurityやWS-ReliableMessagingなど、同等のサービス品質（QOS）機能を適用します。

4.6.3 OC4JおよびOracle WebLogic ServerでサポートされているWebサービスの仕様

表4-4は、OC4JおよびOracle WebLogic ServerでサポートされているWebサービス標準の仕様の比較を示しています。Oracle WebLogic Serverでは、WS-Reliabilityを除き、OC4JがサポートするすべてのWebサービスの標準と仕様をサポートしています。

この表は、比較目的でのみ提供されています。Oracle WebLogic Serverでサポートされている標準の最新情報については、Oracle WebLogic ServerのドキュメントおよびOracle Technology Network（OTN）から入手可能なOracle WebLogic Server情報を参照してください。

表4-4 OC4JおよびOracle WebLogic ServerでサポートされているWebサービスの仕様

Webサービスの仕様

OC4Jのサポート

Oracle WebLogic Serverのサポート

SOAP 1.1および1.2

はい

はい

WSDL 1.1

はい

はい

WS-I 1.0および1.1

はい

はい

XML署名

はい

はい

XML暗号化

はい

はい

SAML

はい

はい

WS-Addressing

はい

はい

WS-Security

はい

はい

WS-Reliability

はい

いいえ

WS-SecurePolicy

いいえ

はい

WS-Policy

いいえ

はい

WS-PolicyAttachment

いいえ

はい

WS-Trust

いいえ

はい

WS-Conversation

いいえ

はい

WS-SecureConversation

いいえ

はい

WS-ReliableMessaging

いいえ

はい

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

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

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

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

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

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

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

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

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

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

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

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

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

- Java Required Files（JRF）ドメイン・テンプレートの使用

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

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

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

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

- 開発環境で作成するOracle WebLogic Serverドメインは、開発モードで構成できます。このモードでは、ドメインのリソースを構成したり、コード変更のテストでアプリケーションをデプロイおよび再デプロイする処理を素早く簡単に実行できます。開発モードまたは本番モードの選択は、Oracle WebLogic Server構成ウィザードを使用してドメインを作成するときに行います。
詳細は、『Oracle Fusion Middleware構成ウィザードを使用したドメインの作成』のサーバー起動モードおよびJDKの構成に関する説明を参照してください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4. Oracle Fusion Middleware構成ウィザードを使用して、ドメインを構成します。
ウィザードを使用しているときに、Oracle ADFおよびEnterprise Managerテンプレートが選択されていることを確認してください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- Oracle JDeveloper 11g インストーラを使用して、開発ドメインをインストールし、構成します。
このドメインは、JRFテンプレートにより自動的に作成されます。

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

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

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

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

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

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

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

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

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

- Application Developer、Oracle SOA SuiteまたはOracle WebCenterのOracleホームからOracle WebLogic Server構成ウィザードを実行します。
ドメインを拡張するオプションを選択し、使用可能なテンプレートのリストが表示されたらJRFテンプレートを選択します。

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

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

- Fusion Middleware ControlまたはApplyJRF WebLogic Scripting Tool（WLST）コマンドを使用して、JRFテンプレートを既存のWebLogicサーバー・インスタンスに適用します。
詳細は、『Oracle Fusion Middleware管理者ガイド』の管理対象のサーバーまたはクラスタへのJava Required Filesの適用に関する項を参照してください。

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

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

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

http://node_name.domain.com:7001/console

2. コンソールの左ペインで「環境」を選択してから「サーバー」を選択します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- インメモリー

- ファイルベース

- Oracle DB Advanced Queuing（AQ）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

OC4Jでの方法

Oracle WebLogic Serverでの同等な方法

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- もう1つには、postdeploy（またはpostUndeploy）メソッドのコードを入れます。

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

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

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

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

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

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

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

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

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

OC4Jのセキュリティ機能

Oracle WebLogic Serverで実行するタスク

詳細情報

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

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

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

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

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

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

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

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

- SQLオーセンティケータ

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

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

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

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

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

該当なし

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- Apache Ant

- WLST（Oracle WebLogic Serverのスクリプト作成ツール）

- Oracle WebLogic管理コンソール

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

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

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

- Oracle WebLogic管理コンソールにログインし、ドメインでデプロイメントを確認します。また、コンソールからは様々な監視タスクとデプロイメント後のタスクを実行できます。

- ブラウザでアプリケーションのURLに移動し、アプリケーションの機能が、この手順の前半にOC4Jで確認したときと同じように動作することを確認します。

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

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

Java EEアプリケーションをOracle WebLogic ServerおよびOracle Fusion Middleware 11g にアップグレードすると、そのアプリケーションによって公開されている外部インタフェースに影響する場合があります。その結果、そのインタフェースに依存しているクライアント・アプリケーションが影響を受ける場合があります。

次の項では、アップグレードがアプリケーション・クライアントに及ぼす影響、およびそれに起因するクライアントの問題に対処する際のガイドラインについて説明します。

- Java Server Pagesクライアントおよびサーブレット・クライアントに対するアップグレードの影響

- Java Naming and Directory Interfaceクライアントに対するアップグレードの影響

- Enterprise Java Beanクライアントに対するアップグレードの影響

- JMSクライアントに対するアップグレードの影響

6.1 Java Server Pagesクライアントおよびサーブレット・クライアントに対するアップグレードの影響

アプリケーションをWebLogic Serverにアップグレードする場合、HTTPセッション・ステートのレプリケーション・モデルがOracle WebLogic ServerとOC4Jで異なるために、JSPクライアントおよびサーブレット・クライアントが影響を受ける場合があります。

OC4Jクラスタの場合はHTTPセッション・ステートのインメモリーの複製コピー数に制限はありませんが、Oracle WebLogic ServerのインメモリーHTTPセッション・ステートのレプリケーションは、OC4Jクラスタとは異なり、プライマリとセカンダリの2コピー・モデルのみをサポートしています。

ほとんどの場合は、このような違いがJSPクライアントおよびサーブレット・クライアントに影響することはありませんが、特殊なケースでHTTPセッション・ステートの3つ以上のコピーがアプリケーションのクライアントから使用可能なことがそのアプリケーションの明示的な前提となっている場合は、Oracle Coherenceの使用を検討してください。

詳細は、Oracle Technology Network（OTN）のOracle Coherenceに関する情報を参照してください。

6.2 Java Naming and Directory Interfaceクライアントに対するアップグレードの影響

次の項では、アップグレードするアプリケーションのクライアントがOC4J Java Naming and Directory Interface（JNDI）プロバイダを使用する場合の考慮事項について説明します。

- Oracle WebLogic Server JNDIプロバイダを使用するためのクライアントの変更

- Oracle WebLogic Server JNDIネームスペースのスコープの理解

6.2.1 Oracle WebLogic Server JNDIプロバイダを使用するためのクライアントの変更

アップグレードするアプリケーションのクライアントの中でOC4J Java Naming and Directory Interface（JNDI）プロバイダを使用してアプリケーションのインタフェースやリソースをルックアップするものがある場合は、かわりにOracle WebLogic Server JNDIプロバイダを使用するようにそのクライアントを変更する必要があります。

アプリケーションのJNDI初期コンテキスト作成コードは、次のようにして変更できます。

1. クライアント・コードでOC4J JNDI URLが使用されているインスタンスをすべて特定します。
一般に、OC4J URLの構成フォーマットは次のとおりです。

prefix://host:RMI_or_OPMN_request_port:oc4j_instance/application-name

たとえば、OC4Jインスタンスの名前がoc4j1、デプロイされているアプリケーション名がmyapplicationであれば、Oracle Application Server 10g インストールのURLは、次のようになります。

opmn:ormi://127.0.0.1:6003:oc4j1/myapplication

Oracle Process Management and Notificationインフラストラクチャを使用する完全なOracle Application Serverインストールの場合、接頭辞はopmn:ormiのように指定できます。スタンドアロンのOC4Jインストールを使用する場合は、単にormi:と指定できます。

2. t3プロトコルを使用して、ターゲットのWebLogic Serverドメインの管理サーバーを指すようにプロバイダのURLを変更します。
たとえば、次のようにします。

t3://127.0.0.1:7001

3. ターゲットのOracle WebLogic Serverドメイン内でセキュリティ資格証明が有効であることを確認します。

4. 初期コンテキスト・ファクトリをOracle WebLogic ServerのWLInitialContextFactoryクラスに変更します。
このクラスは、クライアント・アプリケーションのクラスローダーから使用できるようにする必要もありますが、その処理にはOracle WebLogic Serverクライアントjarファイルを使用します。クライアントjarファイル（wlfullclient.jar）は、WebLogic JarBuilderツールを使用して作成します。

詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverスタンドアロン・クライアントのプログラミング』の次の項を参照してください。

- "WebLogicフルクライアントに関する項

- "WebLogic JarBuilderツールの使用に関する項

クライアント自体がOC4Jサーバー・インスタンス内で実行されている場合は、サーバーのserver.xmlに記述されたenvironment-naming-url-factory-enabled属性をtrueに設定し、同じOC4Jインスタンスで複数のJNDIプロバイダを使用できるようにすることが必要な場合もあります。

6.2.2 Oracle WebLogic Server JNDIネームスペースのスコープの理解

OC4JとOracle WebLogic Server JNDIのプロバイダの重要な相違点で、クライアント・アプリケーションに影響する可能性があるものとしては、JNDIネームスペースのスコープもあげられます。

OC4J JNDIオブジェクトには、明示的なアプリケーション・スコープを設定できます。したがって、OC4J JNDIクライアントがルックアップを実行するときは、特定のOC4Jサーバー・インスタンスを識別してターゲット・アプリケーションの名前を含めるURLを使用することができます。

一方、Oracle WebLogic Server JNDIオブジェクトのネームスペースは常にグローバルです。したがって、ルックアップを実行するOracle WebLogic Server JNDIクライアントの場合、ターゲット・アプリケーションを明示的に識別するURLは指定できません。

このため、WebLogic Serverにアップグレードするときは、その作業の一環として、同じWebLogic ServerドメインにデプロイされるすべてのJNDIリソースについて、そのリソースがどのアプリケーションに所属するかにかかわらず、JNDI名が一意であることを確認する必要があります。必要であれば、ターゲット・オブジェクトの一意なJNDI名を使用するようにJNDIクライアントを変更してください。

6.3 Enterprise Java Beanクライアントに対するアップグレードの影響

アプリケーションをOracle WebLogic Serverにアップグレードしたときに、EJBクライアント・アプリケーションに影響する可能性がある次の2つの場合があります。詳細は、次の項を参照してください。

- リモート・スタンドアロンEJBクライアントへの影響

- OC4JベースのEJBインタフェースを使用するクライアントへの影響

6.3.1 リモート・スタンドアロンEJBクライアントへの影響

このカテゴリのEJBクライアントは、スタンドアロンであるか、OC4Jサーバーにデプロイされています。

このカテゴリのEJBクライアントの場合は、Oracle WebLogic Server JNDIプロバイダを使用するようにクライアントを変更する必要があります（6.2.1項「Oracle WebLogic Server JNDIプロバイダを使用するためのクライアントの変更」の説明を参照）。

WebLogic Server JNDIプロバイダを使用すると、クライアント・アプリケーションがWebLogic Server EJBクライアント・スタブを取得することになり、その結果、クライアント・アプリケーションに対して次のような影響が発生する可能性があります。

- RMIプロトコル: クライアント・アプリケーションは、OC4J RMI転送プロトコル（ORMI）ではなく、いずれかのOracle WebLogic Server RMI転送プロトコルを使用する必要があります。
WebLogic RMIのデフォルトの転送プロトコルはOracle WebLogic Server T3プロトコルですが、IIOPも使用できます。

- ロード・バランシング: OC4Jでは、クライアントEJBリクエストは、Context.lookup()を起動するたびに、InitialContext JNDIオブジェクトを介して（ランダムまたはスティッキーに）OC4Jクラスタ全体でロード・バランシングされるように構成できます。
Oracle WebLogic Serverの場合、EJBクライアント・リクエストのロード・バランシングはリモートEJBクライアント・スタブによって自動的に処理されます。このスタブのロード・バランシング動作は、weblogic-ejb-jar.xmlデプロイメント・ディスクリプタで構成し、InitialContextの作成時またはEJBメソッドの起動時に実行するように設定できます。

ここで述べる考慮事項は、スタンドアロンのクライアントおよび現在OC4Jサーバー・インスタンス内で実行中のクライアントの両方に適用されます。また、WebLogic Serverインスタンス内で実行するようにアップグレードされるクライアントにも適用されます。

スタンドアロン・アプリケーションとしてデプロイされていないEJBクライアントで、引き続きOC4Jサーバー・インスタンス内で実行し、アップグレードされたWebLogic Server EJBアプリケーションに対してリモート起動を行うクライアントの場合は、アップグレードの影響として次の2つの点も追加して考慮する必要があります。

- まず、アプリケーションのセキュリティ・コンテキストは、自動的に伝播されません。このセキュリティ伝播が必要な場合は、WebLogic Server JNDI初期コンテキストの作成時に既存のセキュリティ・コンテキストの資格証明を明示的に使用するように、クライアントを変更する必要があります。

- 次に、リモートEJBを起動するコンテキスト内でのJTAトランザクションの伝播およびXAのリカバリができなくなります。必要な場合は、クライアント・アプリケーション自体のアップグレードが必要になります。

6.3.2 OC4JベースのEJBインタフェースを使用するクライアントへの影響

アップグレードするアプリケーションが、OC4Jサーバー内で引き続き実行するEJBコンポーネントへのリモート・クライアントのように動作することがあります。このカテゴリのクライアントは、oc4jclient.jarファイルにあるOC4J RMIInitialContextFactory JNDI初期コンテキスト・ファクトリを使用するように変更する必要があります。

oc4jclient.jarファイルは、アプリケーションのOracle WebLogic Serverクラスローダーから使用できることが必要です。詳細は、5.3.4項「Oracle WebLogic Server上での共有ライブラリおよびクラスロードの使用」を参照してください。

セキュリティ・コンテキストを伝播するには、ターゲットOC4Jサーバー・インスタンスをOracle WebLogic Server SSLクライアントとして構成する必要があります。また、リモートEJBを起動するコンテキスト内でのJTAトランザクションの伝播およびXAのリカバリはできなくなります。これらの機能が必要な場合は、ターゲットのEJBアプリケーションをアップグレードする必要があります。

6.4 JMSクライアントに対するアップグレードの影響

まず、この項に記載した情報は、メッセージドリブンBean（MDB）以外のJMSクライアントに関する情報であることに注意してください。MDBは、通常はJMSプロバイダのリソースと緊密に結合しているため、常にそのリソースとともにアップグレードする必要があります。MDBアプリケーションのアップグレード時には、WebLogic Server MDBに特有な機能と動作を考慮してください。次の項では、Oracle WebLogic ServerへのアプリケーションのアップグレードがJMSクライアントに影響する可能性がある2つの場合について説明します。

- JMSプロバイダをWebLogic Serverにアップグレードする場合に必要な変更

- JMSプロバイダがOC4Jにそのまま残る場合に必要な変更

6.4.1 JMSプロバイダをWebLogic Serverにアップグレードする場合に必要な変更

この場合は、JMSプロバイダおよびその関連リソース（宛先、コネクション・ファクトリなど）がOracle WebLogic Serverにアップグレードされます。アップグレードするクライアント・アプリケーションと、そのままOC4Jサーバー内で実行する既存のOC4Jクライアント・アプリケーションの両方を変更する必要があります。

具体的には、WebLogic Server JNDIプロバイダを使用するようにクライアント・アプリケーションを変更する必要があります（6.2.1項「Oracle WebLogic Server JNDIプロバイダを使用するためのクライアントの変更」の説明を参照）。

Oracle WebLogic Server JNDIプロバイダを使用するようにクライアントを変更すると、クライアント・アプリケーションはOracle WebLogic Server JMSプロバイダからJMSリソースを取得します。その場合は、クライアント・アプリケーションに影響を与えることがあるため、次の点を考慮してください。

- メッセージの順序付け: Oracle WebLogic Serverには、OC4J JMSプロバイダと同様に、メッセージを厳密な順序で処理することを保証する機能があります。さらに、WebLogic Server JMSの順序単位機能は、追加のメッセージ順序処理機能に対応しています。詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JMSのプログラミング』のメッセージ順序単位の使用に関する項を参照してください。

- 接続プーリング: Oracle WebLogic Server JMSプロバイダには、OC4J JMSプロバイダとは異なり、スタンドアロン・クライアントに対するプーリング機能がありません。この機能が必要な場合は、スタンドアロン・クライアントを変更し、JMSリソースを明示的に再利用することで、この機能を実装する必要があります。

- ネットワーク接続: WebLogic Server JMSプロバイダを使用するクライアントは、クライアント仮想マシン当たり1つのネットワーク接続を使用します（使用されるJMS接続オブジェクトの数には関係しません）。この動作は、JMS接続オブジェクトごとに別々のネットワーク接続を関連付けるOC4J JMSプロバイダとは若干異なります。

スタンドアロン・アプリケーションでないJMSクライアントで、OC4Jサーバー・インスタンス内での実行を続けながらWebLogic Server環境内のJMSリソースを使用するクライアントは、OC4J Oracle Enterprise Messaging Server JMSコネクタ機能を使用する必要があります。

6.4.2 JMSプロバイダがOC4Jにそのまま残る場合に必要な変更

この場合は、JMSプロバイダがOC4Jインフラストラクチャ内にそのまま残っており、Oracle WebLogic Serverにアップグレードするクライアント・アプリケーションは調整が必要です。このタイプのクライアント・アプリケーションは、WebLogic ServerにデプロイされたJMSクライアントがOC4J JMSリソースにアクセスできるようにするために、OC4J JMSリソースをリモートJMSプロバイダとして扱い、Oracle WebLogic Serverの外部サーバー機能を使用する必要があります。

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

7 Java EEおよびWebサーバー環境のアップグレード

この章では、Oracle HTTP Serverをインストールし、Oracle Application Server 10g リリース3（10.1.3.1.0）OC4Jインスタンスと統合したユーザー向けの情報を提供します。

特に、デプロイされたアプリケーションに対するフロントエンドとしてOracle HTTP ServerまたはOracle Web Cacheを使用している場合は、次の項の説明に従って、これらのコンポーネントをOracle Fusion Middleware 11g Web層スイートにアップグレードします。

- タスク1: Oracle HTTP ServerおよびOC4Jを使用した場合と、Oracle HTTP ServerおよびOracle WebLogic Serverを使用した場合の相違点の理解

- タスク2: Oracle Fusion MiddlewareのWeb層のインストールおよび構成

- タスク3: Oracle Application Server 10g Web層コンポーネントのOracle Fusion Middleware 11g へのアップグレード

- タスク4: リクエストをOracle Fusion Middleware環境にルーティングするためのWeb層の構成

- タスク5: アップグレード後に必要な、Web層コンポーネントに対するタスクの実行

- タスク6: Web層のアップグレードの確認

7.1 タスク1: Oracle HTTP ServerおよびOC4Jを使用した場合と、Oracle HTTP ServerおよびOracle WebLogic Serverを使用した場合の相違点の理解

ここでは、WebサーバーおよびOC4Jを使用した場合と、WebサーバーおよびOracle WebLogic Serverを使用した場合の相違点について説明します。

- Oracle WebLogic ServerにおけるWebサイトおよびAJP接続の構成

- Oracle WebLogic Server向けのOracle HTTP Serverのインストールおよび構成

- Oracle HTTP Server以外のWebサーバーとOracle WebLogic Serverの使用

- Oracle Fusion Middleware 11gにアップグレードする場合のOracle HTTP Serverの相互運用性の問題の理解

7.1.1 Oracle WebLogic ServerにおけるWebサイトおよびAJP接続の構成

OC4Jでは、OC4Jインスタンスごとに複数のWebサイトを定義できます。つまり、固有のポートおよびプロトコルを持つ一意のリスナーを定義できます。OC4Jインスタンスにデプロイされた各Webアプリケーションは、特定のOC4J Webサイトにバインドできます。OC4J Webサイトでは、この特定のポートおよびプロトコルに対するリクエストが目的のアプリケーションに送られます。

デフォルトでは、すべてのOC4Jインスタンスで、default-web-site.xml構成ファイルによって事前構成されているデフォルトのWebサイトが提供されます。さらに、デフォルトのWebサイト構成を変更したり、特定のアプリケーション用の追加のWebサイトを定義できます。

Oracle WebLogic Serverでは、Webサイトの概念をサポートしていません。かわりに、Oracle WebLogic Serverの各管理対象サーバーには、一意のリスニング・ポートが割り当てられます。このリスニング・ポートは変更できますが、HTTP、HTTPS、RMIなど、サポートされているすべてのプロトコルに対してリスニングが常に行われます。また、管理対象サーバーごとに2つ目のセキュアな（SSL）ポートを構成することもできます。

ただし、OC4Jとは異なり、Oracle WebLogic ServerではAJPまたはAJPSプロトコルはサポートされていません。このプロトコルは、フロントエンドWebサーバーとOC4Jインスタンス間の通信のためにOC4J環境で使用されます。詳細は、7.1.2項「Oracle WebLogic Server向けのOracle HTTP Serverのインストールおよび構成」を参照してください。

Oracle WebLogic Serverに複数のリスナーを構成する場合は、次のいずれかを実行できます。

- Oracle WebLogic Serverの複数の管理対象サーバーを作成し、それぞれが一意のポートでリスニングするように構成します。その後、アプリケーションを各サーバーにデプロイできます。各アプリケーションは、そのホストの管理対象サーバーに割り当てられたリスニング・ポートでリスニングを行います。

- 管理対象サーバーごとに複数のネットワーク・チャネルを構成します。Oracle WebLogic Serverのネットワーク・チャネルは構成可能なリソースであり、管理対象サーバーへのネットワーク接続の属性を定義します。ネットワーク・チャネルごとに、OC4J Webサイトで提供される属性と類似する一連の属性を構成できます。
詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverサーバー環境の構成』のネットワーク・リソースの構成に関する項を参照してください。

7.1.2 Oracle WebLogic Server向けのOracle HTTP Serverのインストールおよび構成

ここでは、Oracle WebLogic ServerをWebサーバーとともに使用する場合について、次のことを説明します。

- Oracle HTTP ServerのOC4J向けの構成方法

- Oracle HTTP ServerのOracle WebLogic Server向けの構成方法

7.1.2.1 Oracle HTTP ServerのOC4J向けの構成方法

以前のバージョンのOracle Application Serverでは、フロントエンドWebサーバーを使用して環境を構成することが一般的でした（この構成が推奨される場合もありました）。Webサーバーはユーザー・リクエストを受信し、URLのコンテキスト・ルートに基づいて、OC4Jサーバーにデプロイされたアプリケーションに特定のリクエストをルーティングします。

ほとんどのOC4Jユーザーは、Java EEサーバー環境に対するフロントエンドとしてOracle HTTP Serverを構成します。Oracle HTTP Serverは、Oracle Fusion Middleware製品セットのコンポーネントです。Oracle Application Server 10g リリース3（10.1.3）の拡張インストール・オプションでは、OC4Jサーバーに対するフロントエンドとして機能するようにOracle HTTP Serverが自動的に構成されます。

Oracle HTTP ServerとOC4Jとの接続は、Oracle HTTP Serverソフトウェアに付属するmod_oc4jモジュールで管理され、転送はAJPプロトコルで行われます。

7.1.2.2 Oracle HTTP ServerのOracle WebLogic Server向けの構成方法

Oracle WebLogic Serverの場合も同じトポロジを構成できます。ただし、Oracle Fusion Middleware 11g の場合は、Oracle HTTP Serverのインストールを、Oracle WebLogic Serverとは別に、Oracle Fusion Middleware Web層のインストールの一部として行います。また、Web層インストールには、Web層におけるパフォーマンスとキャッシュ機能を向上させるOracle Web Cacheを含めることができます。

Web層インストールの一部としてOracle HTTP Serverをインストールした後は、新しいmod_wl_ohsモジュールを構成できます。これにより、Oracle HTTP ServerからOracle WebLogic Serverにリクエストをプロキシ処理することができます。mod_wl_ohsモジュールは、mod_oc4JがOC4Jに提供する機能とほぼ同等の機能をOracle WebLogic Serverに提供します。

詳細は、『Oracle Fusion Middleware Oracle HTTP Server管理者ガイド』のmod_wl_ohsに関する項を参照してください。

Oracle HTTP Serverは、Webサーバーが必要な一定のOracle Fusion Middleware 11g コンポーネント向けに自動的にインストールされ、構成されます。たとえば、Oracle HTTP Serverは次のOracle Fusion Middlewareコンポーネントとともに自動的にインストールされ、構成されます。

- Oracle Identity Managementソフトウェア・スイートのOracle Identity Federation

- Oracle Portal、Forms、ReportsおよびDiscovererスイートのOracle PortalおよびOracle Business Intelligence Discoverer

ただし、このマニュアルで説明したようなJava EE環境の場合は、Oracle HTTP ServerをOracle WebLogic Serverとは別にインストールし、構成する必要があります。

7.1.3 Oracle HTTP Server以外のWebサーバーとOracle WebLogic Serverの使用

Oracle WebLogic Serverでは、Oracle HTTP Serverと同様に他のWebサーバーもサポートされています。

詳細は、『Oracle Fusion Middleware Oracle WebLogic ServerにおけるWebサーバー・プラグインの使い方』を参照してください。

7.1.4 Oracle Fusion Middleware 11gにアップグレードする場合のOracle HTTP Serverの相互運用性の問題の理解

Oracle HTTP Serverのアップグレードに進む前に、『Oracle Fusion Middlewareアップグレード・プランニング・ガイド』のアップグレード中のOracle HTTP Serverの相互運用性に関する項を確認してください。

7.2 タスク2: Oracle Fusion MiddlewareのWeb層のインストールおよび構成

次の項では、アップグレードしたOracle WebLogic Server環境のフロント・エンドとしてWeb層環境をインストール、構成およびアップグレードする際のオプションについて説明します。

- Web層コンポーネントの場所の決定

- Oracle WebLogic ServerドメインへのWeb層コンポーネントの関連付け

- Web層のインストールと構成に関するドキュメントの参照

7.2.1 Web層コンポーネントの場所の決定

Oracle HTTP ServerをWeb層インストールの一部としてインストールして構成する前に、Oracle HTTP Serverをインストールする場所を検討してください。Upgrade Assistantを使用して、以前のバージョンのOracle HTTP Serverの構成設定をアップグレードすることを予定している場合は、Oracle Application Server 10g Oracle HTTP ServerのOracleホームと同じホスト上にOracle HTTP Serverをインストールする必要があります。

現在の環境で構成をアップグレードする必要がない場合は、別のホスト上にOracle HTTP Serverをインストールし、構成した後で、HTTPリクエストをOracle WebLogic Serverドメインに送信するように構成できます。

詳細は、「タスク4: リクエストをOracle Fusion Middleware環境にルーティングするためのWeb層の構成」を参照してください。

7.2.2 Oracle WebLogic ServerドメインへのWeb層コンポーネントの関連付け

Oracle HTTP ServerをWeb層インストールの一部としてインストールする場合は、Web層コンポーネントをOracle WebLogic Serverドメインに関連付けるかどうかを選択できます。実現可能な次のトポロジについて検討してください。

- Web層コンポーネントをOracle WebLogic Serverドメインの一部として構成します。
このオプションでは、Oracle HTTP ServerおよびOracle Web Cache（オプション）を既存のドメインに追加できます。

たとえば、Java EEアプリケーションのデプロイに使用するOracle SOA Suite、WebCenterまたはApplication DeveloperドメインにWeb層コンポーネントを追加できます。

これがメリットがあるのは、続いて、デプロイしたアプリケーションに対するフロント・エンドとしてWeb層コンポーネントを簡単に構成し、Oracle Enterprise Manager Fusion Middleware Controlを使用して、ドメインとドメイン上にデプロイするアプリケーションを管理できる点です。

注意:
Web層コンポーネントと、Oracle JDeveloperで作成された開発ドメインとの関連付けはサポートされていません。詳細は、5.1項「タスク1: Oracle WebLogic Server開発ドメインのインストールと構成」を参照してください。

- Web層コンポーネントをドメインなしで構成します。
このオプションの場合、Oracle HTTP ServerおよびOracle Web Cacheインスタンス（オプション）は別のOracleホームにスタンドアロンとしてインストールされ、ドメインには関連付けられません。

このトポロジは、Web層コンポーネントを別のホスト上にインストールし、これまでのOracle Application Server 10g の構成設定をアップグレードする予定がなく、Web層コンポーネントをOracle Enterprise Manager Fusion Middleware Controlで管理する予定がない場合に検討してください。

7.2.3 Web層のインストールと構成に関するドキュメントの参照

Oracle HTTP ServerとOracle Web Cache（オプション）をインストールし、構成する準備ができたら、『Oracle Fusion Middleware Oracle Web Tierインストレーション・ガイド』にある詳細な手順を参照してください。

Web層コンポーネントをOracle WebLogic Serverドメインに関連付ける予定がない場合は、『Oracle Fusion Middleware Oracle Web Tierクイック・インストレーション・ガイド』を参照することもできます。

7.3タスク3: Oracle Application Server 10g Web層コンポーネントのOracle Fusion Middleware 11g へのアップグレード

これまでOracle HTTP Serverを使用していた場合は、Oracle Fusion Middleware Upgrade Assistantを使用して、Oracle Application Server 10g リリース3（10.1.3）の特定のOracle HTTP Server構成設定を新しいOracle Fusion Middleware 11g Oracle HTTP Serverインスタンスにアップグレードできます。

また、Oracle HTTP Server以外のWebサーバーを使用している場合や、Oracle Application Server 10g リリース3（10.1.3）の環境が存在するホストとは別のホストにOracle HTTP Serverをインストールした場合は、新しいOracle Fusion Middleware環境を手動で再構成する必要があります。

Oracle Fusion Middleware Upgrade Assistantを使用して、Oracle HTTP Server構成を11g にアップグレードする方法については、次の項を参照してください。

- タスク3a: Web層をアップグレードするためのUpgrade Assistantの起動

- タスク3b: Upgrade Assistantを使用したWeb層コンポーネントのアップグレード

7.3.1 タスク3a: Web層をアップグレードするためのUpgrade Assistantの起動

グラフィカル・ユーザー・インタフェースを使用してUpgrade Assistantを起動するには、次の手順を実行します。

注意:
Oracle Application Server 10g Oracleホームのアップグレードには、Upgrade Assistantコマンドライン・インタフェースを使用することもできます。詳細は、『Oracle Fusion Middlewareアップグレード・プランニング・ガイド』のUpgrade Assistantコマンドライン・インタフェースの使用方法に関する項を参照してください。

1. ディレクトリをOracle Fusion MiddlewareインストールのORACLE_HOME/binディレクトリに変更します。

2. 次のコマンドを入力してUpgrade Assistantを起動します。
UNIXシステムの場合:

./ua

Windowsシステムの場合:

ua.bat

Upgrade Assistantに、「ようこそ」画面（図7-2）が表示されます。

図7-1 Upgrade Assistantの「ようこそ」画面

「図7-1 Upgrade Assistantの「ようこそ」画面」の説明

3. 「次へ」をクリックして「操作の指定」画面（図7-2）を表示します。
Upgrade Assistantで使用可能なオプションは、起動元のOracleホームによって異なります。たとえば、Web層のOracleホームからUpgrade Assistantを起動すると、通常のWeb層のOracleホームのコンポーネントに対して有効なオプションが「操作の指定」画面に表示されます。

図7-2 Web層のインストールをアップグレードする場合の「操作の指定」画面

「図7-2 Web層のインストールをアップグレードする場合の「操作の指定」画面」の説明

7.3.2 タスク3b: Upgrade Assistantを使用したWeb層コンポーネントのアップグレード

次の項では、Oracle HTTP ServerをOracle Fusion Middleware 11g にアップグレードする処理について説明します。

- Web層コンポーネントのアップグレード

- アップグレード先OracleインスタンスでソースOracleホーム・ポートを使用する際の重要な注意事項

7.3.2.1 Web層コンポーネントのアップグレード

Web層コンポーネントをOracle Fusion Middleware 11g にアップグレードするには、次の手順を実行します。

1. 「Task 3a: Web層をアップグレードするためのUpgrade Assistantの起動」の説明に従って、Upgrade Assistantを起動します。

2. 「操作の指定」画面（図7-2）で「中間層インスタンス」を選択します。

3. 中間層インスタンスのアップグレード時に入力が必要なUpgrade Assistant画面および各画面のオプションについては、表7-1を参照してください。
Upgrade Assistantでは、次のタスクが実行され、各タスクの進捗が示されます。

- アップグレードするコンポーネントおよびスキーマを調べ、正常にアップグレードできることが確認されます。

- 目的のコンポーネントおよびスキーマがUpgrade Assistantでアップグレードされていることを確認できるように、アップグレードするコンポーネントのサマリーが表示されます。

- アップグレードの進捗に合わせてアップグレードのステータスを確認できるように、進捗画面が表示されます。

- アップグレード時にエラーまたは問題が発生した場合にアラートが通知されます。

関連項目:
Upgrade Assistantの実行時に発生する問題のトラブルシューティングについては、『Oracle Fusion Middlewareアップグレード・プランニング・ガイド』のUpgrade Assistantの問題のトラブルシューティングに関する項を参照してください。

- 「アップグレードの終了」画面が表示されます。これによって、アップグレードが完了したことを確認できます。

表7-1 中間層インスタンスのアップグレード時に入力が必要なUpgrade Assistant画面

Upgrade Assistant画面

説明

ソース・ホームの指定

10g リリース2（10.1.2）または10g（10.1.4）のIdentity ManagementインスタンスのソースOracleホームを選択します。

アップグレード対象のOracleホームがドロップダウン・リストに表示されない場合は、『Oracle Fusion Middlewareアップグレード・プランニング・ガイド』のOracleAS Upgrade Assistantで表示されないソースOracleホームに関する項を参照してください。

アップグレード先インスタンスの指定

11g のOracleインスタンスへの完全なパスを入力するか、または「参照」をクリックしてインスタンスのディレクトリを指定します。

WebLogic Serverの指定

「タスク2: Oracle Fusion MiddlewareのWeb層のインストールおよび構成」で構成したOracle WebLogic ServerのホストとAdministration Serverポートを入力します。

アップグレード・オプションの指定

Oracle Portal、Forms、ReportsおよびDiscovererのアップグレードに適用するアップグレード・オプションを選択します。次のアップグレード・オプションがあります。

- アップグレード先でソースOracleホーム・ポートを使用: Oracle Application Server 10gのOracleホームで使用しているポートの割当てをOracle Fusion Middlewareの新しいOracleインスタンスに移行する場合に指定します。
詳細は、7.3.2.2項「アップグレード先OracleインスタンスでソースOracleホーム・ポートを使用する際の重要な注意事項」を参照してください。

このオプションを選択せずにOracle Web Cacheをアップグレードする場合は、7.5.2項「アップグレード後のOracle HTTP ServerおよびOracle Web Cacheポートの確認と更新」を参照してください。

- アップグレード前にソース・コンポーネントを停止: このチェック・ボックスはデフォルトで選択されており、アップグレード・プロセスを開始する前にソースOracleホームのすべてのコンポーネントが停止されます。ソース・コンポーネントを停止するのは、「アップグレード先でソースOracleホーム・ポートを使用」オプションを選択した場合にポートの競合を避けるためです。

- アップグレード完了後にアップグレード先コンポーネントを起動: アップグレードの完了後にUpgrade Assistantによってアップグレード先Oracleホームのコンポーネントを自動的に起動する場合に指定します。このオプションを選択しない場合は、アップグレード後にアップグレード先のインスタンスを手動で起動する必要があります。

この画面のアップグレード・オプションの詳細を表示するには、「ヘルプ」をクリックします。

7.3.2.2 アップグレード先OracleインスタンスでソースOracleホーム・ポートを使用する際の重要な注意事項

Oracle Fusion Middleware Upgrade Assistantで、アップグレード先でソースOracleホーム・ポートを使用するオプションを選択する場合は、次の点に注意してください。

- このオプションを選択した場合、10g と11g の中間層を同時に実行することができなくなります。同時に実行すると、ポートの競合が発生します。

- 特定のOracle Fusion Middleware 11g コンポーネントの複数のインスタンスをアップグレードする場合、このオプションを選択できるのは、アップグレード先のホストのコンポーネントごとに1度のみです。それ以外の状態では、ポートの競合が発生します。
たとえば、MYHOST1の1つのOracleインスタンスでOracle HTTP Serverをアップグレードするとします。

MYHOST1の別のOracleインスタンスにある別のOracle HTTP Serverインスタンスをアップグレードしている間に、このオプションを再度使用すると、同じリスニング・ポートが2番目のOracle HTTP Serverインスタンスに割り当てられます。同じホストにあるOracle HTTP Serverの2つのインスタンスは、同じリスニング・ポートを使用できません。

- Oracle Web CacheとOracle HTTP Server 11g の両方を、Web層とユーティリティのインストールの一部としてインストールし、構成するときに、このオプションを使用してアップグレードする10g OracleホームにインストールされているのがOracle HTTP Serverのみの場合は、アップグレード後にOracle Web Cacheインスタンスを変更する必要があります。
具体的には、現在使用しているのが10g ポートであるため、Web層とユーティリティのインストールと構成で割り当てられたOracle HTTP Serverのリスニング・ポートではなく、10g で使用していたポートにリクエストを送信するようにOracle Web Cacheインスタンスを変更する必要があります。

詳細は、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』を参照してください。

7.4 タスク4: リクエストをOracle Fusion Middleware環境にルーティングするためのWeb層の構成

リクエストをOracle WebLogic ServerにルーティングするようにOracle HTTP Serverを構成するには、『Oracle Fusion Middleware Oracle HTTP Server管理者ガイド』の手順に従ってください。

特に、『Oracle Fusion Middleware Oracle HTTP Server管理者ガイド』の次の項を参照してください。

- "Oracle HTTP Serverモジュールの理解に関する項

- "mod_wl_ohsモジュールの構成に関する項

7.5 タスク5: アップグレード後に必要な、Web層コンポーネントに対するタスクの実行

次の項では、Web層コンポーネントを11g にアップグレードした後で必要になる可能性がある構成タスクについて説明します。

- アップグレード後のOracle HTTP ServerおよびOracle Web Cacheウォレットの場所の確認

- アップグレード後のOracle HTTP ServerおよびOracle Web Cacheポートの確認と更新

注意:
Oracle HTTP ServerおよびOracle Web CacheをOracle Single Sign-Onとともに構成した場合は、アップグレード後に追加タスクが必要です。
詳細は、『Oracle Fusion Middleware Oracle Portal, Forms, Reports and Discovererアップグレード・ガイド』のOracle Single Sign-Onを使用した場合のWeb層コンポーネントに対するアップグレード後のタスクに関する項を参照してください。

7.5.1 アップグレード後のOracle HTTP ServerおよびOracle Web Cacheウォレットの場所の確認

Oracle Web Cache 10g に対してSecure Socket Layer（SSL）ウォレットを構成していた場合は、Oracle Web Cacheのアップグレード処理について次の点を考慮してください。

- ウォレットを格納していたのがOracle Web Cache 10g のOracleホーム内のディレクトリだった場合は、アップグレード時に、そのディレクトリ内のウォレット・ファイルがOracle Fusion Middleware 11g インスタンスのホームにある次の新しいディレクトリに移動されます。

ORACLE_INSTANCE/config/WebCache/component_name/keystores/wallet_dir_name10g

次に例を示します。

ORACLE_INSTANCE/config/WebCache/webcache1/keystores/wc_wallets10g

- ウォレットを格納していたのがOracle Web Cache 10g のOracleホーム外のディレクトリだった場合は、Oracle Web Cache 11g にアップグレードした後も、アップグレード前の元の場所をそのまま使用できます。

Oracle HTTP Server 10gに対してSSLウォレットを構成していた場合は、Upgrade AssistantによってOracle HTTP Server 10gウォレットが新しい11g形式にアップグレードされます。Oracle HTTP Server 11gのウォレットは、11g Oracleインスタンス・ディレクトリの次の場所に保存されます。

ORACLE_INSTANCE/config/OHS/component_name/keystores/default/

ユーザーごとに固有のウォレットを定義していた場合は、キーストア・ディレクトリのサブディレクトリにウォレットが保存されます。このディレクトリの名前は、10gのウォレットを保存していたディレクトリの名前に基づきます。

たとえば、10gのウォレットを/home/jones/security/mywallets/というディレクトリに保存していた場合、アップグレードされたウォレットは次のディレクトリにあります。

ORACLE_INSTANCE/config/OHS/component_name/keystores/security_mywallets/

7.5.2 アップグレード後のOracle HTTP ServerおよびOracle Web Cacheポートの確認と更新

Upgrade Assistantの「アップグレード・オプションの指定」画面で「アップグレード先でソースOracleホーム・ポートを使用」を選択しなかった場合は、Web層コンポーネントのアップグレード後に、アップグレードされたOracle HTTP ServerおよびOracle Web Cache 11g インスタンスで使用されるポートを確認する必要があります。

具体的には、リスニング・ポート、元のサーバー、サイト定義、およびサイトからサーバーへのマッピング設定を確認し、適宜変更を加える必要があります。

Oracle HTTP ServerおよびOracle Web Cacheコンポーネントが同じインスタンス内にあり、それらのコンポーネントをまとめてアップグレードする場合は、変更する必要がありません。

ただし、次の状況では、Oracle HTTP ServerおよびOracle Web Cacheインスタンス間のポートおよび接続を再構成する必要があります。

- Oracle HTTP ServerおよびOracle Web Cacheインスタンスを別々にアップグレードした場合、たとえば、あるホスト上のOracle HTTP Serverをアップグレードし、後で、それに関連付けられたOracle Web Cacheインスタンスを別のホスト上でアップグレードした場合。

- Oracle Application Server 10g環境でインストール時にOracle HTTP Serverのみを使用し、現在はOracle Fusion Middleware 11g環境でOracle HTTP ServerとOracle Web Cacheの両方を使用している場合。

- Oracle Web Cacheクラスタを使用している場合（一般的には、複数のOracle HTTP Serverインスタンスへの複数のOracle Web Cacheインスタンス・ルーティングを構成している場合）。

Oracle HTTP ServerとOracle Web Cache間の接続の構成の詳細は、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』を参照してください。

7.6 タスク6: Web層のアップグレードの確認

Web層が正しくアップグレードできたことを確認するには、次の手順を実行します。

1. Upgrade Assistantを再度実行し、「操作の指定」ページの「インスタンスの検証」を選択します。
特定のOracle Fusion Middlewareコンポーネントが稼働しているかどうかの検証方法については、画面の指示に従ってください。

2. Web層をOracle WebLogic Serverドメインに関連付け、Oracle Enterprise Managerテンプレートがそのドメインに適用された場合は、Fusion Middleware Controlを使用して、Web層コンポーネントが稼働していることを確認します。
詳細は、『Oracle Fusion Middleware管理者ガイド』のOracle Enterprise Manager Fusion Middleware Controlの使用の開始に関する項を参照してください。

A orion-web.xmlおよびorion-ejb-jar.xmlのアップグレード・リファレンス

この付録には、Oracle Application Server 10g アプリケーションをOracle WebLogic Serverに再デプロイできるよう準備する際のリファレンス情報が含まれています。

次の項を参照して、それぞれのOC4Jデプロイメント・ディスクリプタの要素のアップグレードに関する詳細を確認してください。

- orion-web.xml

- orion-ejb-jar.xml

orion-web.xml

OC4J固有のアプリケーションレベルのWebディスクリプタであるorion-web.xmlは、WARファイルの/WEB-INFディレクトリに格納されて配布されます。このディスクリプタは、OC4J固有の設定を追加したり、web.xmlの設定を上書きするために使用します。

Oracle WebLogic Serverでは、同等のベンダー固有のデプロイメント・ディスクリプタはweblogic.xmlと呼ばれ、Webモジュールの/WEB-INFディレクトリ内にあります。

10g アプリケーションをOracle WebLogic Serverに再デプロイする場合は、Webモジュールで設定した特定のOC4J設定を、すべてweblogic.xmlファイル内の同等の設定でWebLogic Server用に変換する必要があります。詳細は、この付録に記載された、orion-web.xmlファイルの各要素に関する情報を参照してください。

<classpath>

OC4Jでの定義

Webアプリケーションのスコープ内またはスコープ外にあるコード・ソース（JARファイル、ZIPファイルなど）をOC4J Webアプリケーションが参照できるようにします。この場所にある有効なコード・ソースは、実行時にWebアプリケーションのクラスローダーに追加されます。

対応するweblogic.xmlエントリ

なし。

アップグレードのアドバイス

次の2つのオプションがあります。

- 参照されるJARファイルをWebアプリケーションのWEB-INF/libディレクトリにコピーします。
または

- クラスをJARファイルにパッケージし、そのJARファイルをOracle WebLogic Serverの共有ライブラリとしてデプロイします。このライブラリは、アプリケーションのweblogic-application.xmlデプロイメント・ディスクリプタの<library-ref>要素を介してアプリケーションから参照されます。

詳細情報

"『Oracle Fusion Middleware Oracle WebLogic Serverアプリケーションの開発』の共有Java EEライブラリおよびオプション・パッケージの作成に関する項

<contextParamMappingFinding>

OC4Jでの定義

サーブレット・コンテキスト・パラメータ用に、web.xml内の対応する<context-param>要素によって指定された値を上書きします。

対応するweblogic.xmlエントリ

なし。

アップグレードのアドバイス

Oracle WebLogic Serverには、直接対応するものがありません。ただし、任意のサーブレットまたはフィルタから、次のようにしてコンテキスト・パラメータを上書きすることは可能です。

getServletContext().getInitParameter("ContextParam")

詳細情報

"Webサイトjava.sun.comにある「Java 2 Platform, Enterprise Edition, v 1.3 API Specification」のServletConfig Javaサーブレット・インタフェース

<mimeMappings>

OC4Jでの定義

MIMEマッピングを含むファイルへのパスを定義します。

対応するweblogic.xmlエントリ

なし。

アップグレードのアドバイス

Oracle WebLogic Serverには、直接対応するものがありません。ただし、web.xmlの対応する<mime-mapping>要素によって、<mimeMappings>要素に指定された値を上書きすることは可能です。

詳細情報

"『Oracle Fusion Middleware Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のweb.xmlデプロイメント・ディスクリプタの要素に関する項

<virtual-directory>

OC4Jでの定義

静的コンテンツのための仮想ディレクトリ・マッピングを追加します。これは、UNIXシステムのシンボリック・リンクと概念的に類似した方法で機能します。

仮想ディレクトリを使用すると、WebアプリケーションのWARファイルに物理的に存在していなくても、ドキュメントの実際のルート・ディレクトリの内容をアプリケーションから利用できるようになります。たとえば、複数のWARファイルからエンタープライズ全体のエラー・ページにリンクするような場合に役立ちます。

対応するweblogic.xmlエントリ

<virtual-directory-mapping>

アップグレードのアドバイス

同等な<virtual-directory-mapping>エントリをweblogic.xmlに作成します。

詳細情報

"『Oracle Fusion Middleware Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のweblogic.xmlデプロイメント・ディスクリプタの要素に関する項

<access-mask>

OC4Jでの定義

アプリケーション用のオプションのアクセス・マスクを指定します。ホスト名またはホスト・ドメインを使用してクライアントをフィルタするか、またはIPアドレスおよびサブネットを使用してクライアントをフィルタするか、あるいはその両方を使用できます。

対応するweblogic.xmlエントリ

なし。

アップグレードのアドバイス

使用可能な場合は、ネットワーク・ファイアウォールまたはアプリケーション・ロードバランサのいずれかに、同じフィルタを作成します。その他に、Oracle WebLogic Serverネットワーク接続フィルタを使用して、Oracle WebLogic Serverドメインにフィルタを設定することも検討してください。

ただし、Oracle WebLogic Serverネットワーク接続フィルタはドメイン全体のみに対して機能し、アプリケーションごとには設定できないことに十分注意してください。

詳細情報

"『Oracle Fusion Middleware Oracle WebLogic Serverセキュリティのプログラミング』のネットワーク接続フィルタの使用に関する項

<servlet-chaining>

OC4Jでの定義

現在のサーブレットのレスポンスに特定のMIMEタイプが設定されているときにコールするサーブレットを指定します。

指定したサーブレットは、現在のサーブレットの後にコールされます。これは、特定の種類の出力をフィルタまたは変換するために使用します。

対応するweblogic.xmlエントリ

なし。

アップグレードのアドバイス

同じ機能を実現する標準フィルタを作成します。OC4Jサーブレット・チェーンは旧式の専用メカニズムで、バージョン2.3のサーブレット仕様で導入された標準のサーブレット・フィルタリングとほぼ同じ機能を持ちます。

詳細情報

"Webサイトjava.sun.comの「The Essentials of Filters」

<request-tracker>

OC4Jでの定義

リクエスト・トラッカとして使用するサーブレットを指定します。このサーブレットは、ブラウザからサーバーに送信されるリクエストごとに、対応するレスポンスがコミットされるのと同じタイミングで（レスポンスが実際に送信される直前に）起動されます。

リクエスト・トラッカは、情報のロギングに役立ちます。

対応するweblogic.xmlエントリ

なし。

アップグレードのアドバイス

リクエスト・トラッカ・サーブレットの機能を持つ標準のサーブレット・リクエスト・リスナーを作成します。

OC4Jサーブレット・リクエスト・トラッカは旧式の専用メカニズムで、バージョン2.4のサーブレット仕様で導入された標準のリクエスト・リスナーとほぼ同じ機能を持ちます。

詳細情報

"Webサイトjava.sun.comの「Servlet Life Cycle」

<session-tracking>

OC4Jでの定義

このアプリケーションのセッション・トラッキング設定を指定します。

セッション・トラッキングはCookieによって実現されるので、ブラウザでCookieを有効にしていることを前提とします。

対応するweblogic.xmlエントリ

<session-descriptor>

アップグレードのアドバイス

weblogic.xmlで<session-descriptor>要素を使用します。

詳細情報

"『Oracle Fusion Middleware Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のweblogic.xmlデプロイメント・ディスクリプタの要素に関する項

<session-tracker>

OC4Jでの定義

<session-tracking>のこのサブ要素は、セッション・トラッカとして使用するサーブレットを指定します。

セッション・トラッカは、セッションが作成されるとすぐに起動されます。具体的にはHTTPセッション・リスナー（javax.servlet.http.HttpSessionListenerインスタンスを実装するクラスのインスタンス）のsessionCreated()メソッドの起動と同時に起動されます。

セッション・トラッカは、情報のロギングなどに役立ちます。

対応するweblogic.xmlエントリ

なし。

アップグレードのアドバイス

セッション・トラッカ・サーブレットの機能を持つ標準のHttpSessionListenerを作成します。

詳細情報

"Webサイトjava.sun.comの「Servlet Life Cycle」

<resource-ref-mapping>

OC4Jでの定義

データソース、JMSキュー、メール・セッションなどの外部リソースのためのJNDIロケーションを宣言します。これは、リソースを宣言する、web.xmlファイル内の対応する<resource-ref>要素とともに使用します。

対応するweblogic.xmlエントリ

<resource-description>

アップグレードのアドバイス

weblogic.xmlで<resource-description>要素を使用します。

詳細情報

"『Oracle Fusion Middleware Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のweblogic.xmlデプロイメント・ディスクリプタの要素に関する項

<lookup-context>

OC4Jでの定義

この要素は、そのlocation属性によって、親の<resource-ref-mapping>要素でマップされたリソースのルックアップでデフォルトのコンテキストのかわりに使用されるオプションのJNDIコンテキストを指定します。

これは、サード・パーティのモジュール（サード・パーティのJMSサーバーなど）に接続する場合に役立ちます。

対応するweblogic.xmlエントリ

なし。

アップグレードのアドバイス

Oracle WebLogic Serverでは、JNDI名のルックアップにデフォルトのモジュール・コンテキストを使用します。ただし、サード・パーティのJNDIモジュールがJMSサーバーで、関連するコネクション・ファクトリと宛先を使用することがその目的の場合は、WebLogic JMSを使用して、ローカルWebLogic Server JNDIツリー内のサード・パーティのJMSプロバイダを参照できます。

詳細情報

"『Oracle Fusion Middleware Oracle WebLogic Server JMSの構成と管理』のサード・パーティのJMSプロバイダにアクセスするための外部サーバー・リソースの構成に関する項

<resource-env-ref-mapping>

OC4Jでの定義

環境リソースのためのJNDIロケーションを宣言します。これは、リソースを宣言する、web.xmlファイル内の対応する<resource-env-ref>要素とともに使用します。

対応するweblogic.xmlエントリ

<resource-env-description>

アップグレードのアドバイス

weblogic.xmlで<resource-env-description>要素を使用します。

詳細情報

"『Oracle Fusion Middleware Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のweblogic.xmlデプロイメント・ディスクリプタの要素に関する項

<env-entry-mapping>

OC4Jでの定義

環境エントリ用に、web.xmlの対応する<env-entry>要素によって指定された値を上書きします。

対応するweblogic.xmlエントリ

なし。

アップグレードのアドバイス

Oracle WebLogic Serverには、直接対応するものがありません。ただし、web.xmlの対応する<env-entry>要素に指定された値を上書きすることは可能です。

詳細情報

"『Oracle Fusion Middleware Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のweb.xmlデプロイメント・ディスクリプタの要素に関する項

<ejb-ref-mapping>

OC4Jでの定義

EJBのためのJNDIロケーションを宣言します。これは、EJBを宣言する、web.xmlファイルの対応する<ejb-ref>または<ejb-local-ref>要素とともに使用します。

対応するweblogic.xmlエントリ

<ejb-reference-description>

アップグレードのアドバイス

weblogic.xmlで<ejb-reference-description>要素を使用します。

詳細情報

"『Oracle Fusion Middleware Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のweblogic.xmlデプロイメント・ディスクリプタの要素に関する項

<service-ref-mapping>

OC4Jでの定義

この要素は、Webサービスを宣言する、web.xmlファイルの<service-ref>要素とともに使用します。

対応するweblogic.xmlエントリ

<service-ref-description>

アップグレードのアドバイス

weblogic.xmlで<service-ref-description>要素を使用します。

詳細情報

"『Oracle Fusion Middleware Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のweblogic.xmlデプロイメント・ディスクリプタの要素に関する項

<expiration-setting>

OC4Jでの定義

所定の一連のリソースの有効期限、つまりブラウザでそのリソースが期限切れになるまでの時間を指定します。（ブラウザは、期限切れになったリソースが次に要求された際、そのリソースを再ロードします。）

これは、ドキュメントと同じ頻度では画像を再ロードしないなどのキャッシング・ポリシーに役立ちます。

対応するweblogic.xmlエントリ

なし。

アップグレードのアドバイス

これは、特定のリクエストをキャッシュするようブラウザに要求してサーバーへのリクエストを減少させるという点で、OC4Jサーブレット・コンテナのパフォーマンス機能といえます。

Oracle WebLogic Serverには、同等の機能がありません。

詳細情報

なし。

<jazn-web-app>

OC4Jでの定義

OracleAS JAAS Providerおよびシングル・サインオン（SSO）のプロパティをサーブレット実行用に構成します。特定のセキュリティ対応の権限下でサーブレットを起動するには、これらの機能を適切に設定する必要があります。

対応するweblogic.xmlエントリ

なし。

アップグレードのアドバイス

Oracle WebLogic Serverでは、セキュリティ・サブジェクトの伝播は同じドメイン内で自動的にサポートされます。

ただし、複数のドメイン間でIDを伝播する場合は、クロスドメイン・セキュリティまたはグローバル信頼が有効になっている必要があります。

詳細情報

『Oracle Fusion Middleware Oracle WebLogic Serverセキュリティについて』

Oracle WebLogic Server管理コンソールのオンライン・ヘルプの、ドメイン間のクロスドメイン・セキュリティの有効化に関する項

<security-role-mapping>

OC4Jでの定義

この要素は、指定するユーザーおよびグループまたは全ユーザーにセキュリティ・ロールをマップします。これでマップされるのは、web.xmlファイルの<security-role>要素によって指定されている名前と同じ名前のセキュリティ・ロールです。impliesAll属性または適切なサブ要素の組合せ（<group>または<user>、あるいはその両方）のいずれかを使用します。

対応するweblogic.xmlエントリ

<security-role-assignment>

アップグレードのアドバイス

weblogic.xmlで<security-role-assignment>要素を使用します。セキュリティ・ロール名は宛先のOracle WebLogic Serverドメインで作成する必要があります。

詳細情報

"『Oracle Fusion Middleware Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のweblogic.xmlデプロイメント・ディスクリプタの要素に関する項

<web-app-class-loader>

この項では、orion-web.xmlデプロイメント・ディスクリプタのOC4J <web-app-class-loader>要素によってサポートされる属性について説明します。

search-local-classes-first

OC4Jでの定義

この属性をtrueに設定すると、システム・クラスの前にWARファイルのクラスが検索され、ロードされます。デフォルトでは、最初にシステム・クラスが検索され、ロードされます。

対応するweblogic.xmlエントリ

なし。

アップグレードのアドバイス

アプリケーションのweblogic-application.xmlに<prefer-application-package>要素を追加することで、フィルタリング・クラスローダーを構成します。この要素には、アプリケーションから明示的にロードするパッケージをリストし、アプリケーション共有ライブラリを使用する方法か、アプリケーションのAPP-INF/libまたはWEB-INF/libディレクトリにJARファイルをバンドルする方法のいずれかによって、必要なバージョンのJARファイルをアプリケーションで確実に使用できるようになります。

OC4Jの場合とは異なり、WebLogic Serverのフィルタ済クラスがアプリケーションのクラスローダーで解決できない場合でも、Oracle WebLogic Serverによってそのクラスが親のクラスローダーからロードされることはありません。そのため、weblogic-application.xmlの<prefer-application-packages>要素内にリストされたパッケージ名が正しいことを必ず確認してください。

詳細情報

"『Oracle Fusion Middleware Oracle WebLogic Serverアプリケーションの開発』のフィルタリング・クラスローダーの使用に関する項

"『Oracle Fusion Middleware Oracle WebLogic Serverアプリケーションの開発』の共有Java EEライブラリおよびオプション・パッケージの作成に関する項

include-war-manifest-class-path

OC4Jでの定義

この属性をfalseに設定すると、WARファイルからクラスを検索してロードするときに、（search-local-classes-firstの設定とは関係なく）WARファイルのマニフェストのClass-Path属性に指定されたクラスパスは無視されません。falseに設定しない場合は、WARファイルのマニフェストのクラスパスが含まれます。

対応するweblogic.xmlエントリ

なし。

アップグレードのアドバイス

WebLogic Serverは、WARファイルのマニフェストで指定されたクラスパスを読み取りません。ただし、アプリケーションのWEB-INF/libディレクトリの一部としてクラスをバンドルすることは可能です。

詳細情報

"『Oracle Fusion Middleware Oracle WebLogic Serverアプリケーションの開発』の共有Java EEライブラリおよびオプション・パッケージの作成に関する項

autojoin-session

OC4Jでの定義

ユーザーがアプリケーションにログインすると同時に、そのユーザーにセッションを割り当てるかどうかを指定します。

対応するweblogic.xmlエントリ

なし。

アップグレードのアドバイス

WebLogic Serverでは、ユーザーがアプリケーションにログインすると同時に、そのユーザーにセッションが自動的に割り当てられます。OC4Jとは異なり、この動作はデプロイメント・ディスクリプタの要素で無効にすることはできません。

詳細情報

なし。

default-buffer-size

OC4Jでの定義

サーブレット・レスポンス用の出力バッファのデフォルトのサイズをバイト単位で指定します。

対応するweblogic.xmlエントリ

なし。

アップグレードのアドバイス

Oracle WebLogic Serverには、この構成要素に直接対応するものはありません。ただし、任意のサーブレットからレスポンス・オブジェクトを使用して、setBufferSize()をコールすることは可能です。バッファ・サイズ・ディレクティブの<%@ page buffer%>をJSPページに含めることもできます。

詳細情報

なし。

default-charset

OC4Jでの定義

OC4J 10g リリース（10.1.3.1.0）では、この属性はJSPページおよびサーブレット・コンテナに対してデフォルトで使用するISOキャラクタ・セットを指定します。

一般に、JSP 2.0を使用する場合は、かわりに（JSP 2.0仕様に準拠し、web.xmlの<jsp-config>要素の下にある）標準の<page-encoding>機能を使用して、URLパターンに基づくキャラクタ・セットを指定することをお薦めします。

ただし、（特に複数のアプリケーションにわたって）多数のJSPページがある場合は、EARファイルで多くの変更を加える必要をなくすためにdefault-charsetが役立つ場合があります。

また、default-charsetを使用してベース・デフォルトを設定してから、<page-encoding>機能を使用して特定のURLパターンのデフォルトを上書きすることもできます。

対応するweblogic.xmlエントリ

jsp-descriptor/encoding

アップグレードのアドバイス

weblogic.xmlでjsp-descriptor/encoding構成を使用します。

詳細情報

"『Oracle Fusion Middleware Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のweblogic.xmlデプロイメント・ディスクリプタの要素に関する項

default-mime-type

OC4Jでの定義

setContentType()メソッドがサーブレット実装からコールされない状況での、サーブレット・レスポンスのデフォルトのコンテンツ・タイプを指定します。

default-mime-typeを指定しない場合、デフォルトのコンテンツ・タイプはありません。

対応するweblogic.xmlエントリ

container-descriptor /default-mime-type

アップグレードのアドバイス

weblogic.xmlでcontainer-descriptor/default-mime-type構成を使用します。

詳細情報

"『Oracle Fusion Middleware Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のweblogic.xmlデプロイメント・ディスクリプタの要素に関する項

development

OC4Jでの定義

このOC4J固有のフラグは開発時に使用します。このフラグは、特定のディレクトリについて、サーブレット・ソース・ファイルが更新されているかどうかを確認するようOC4Jサーバーに指示します。

対応するweblogic.xmlエントリ

なし。

アップグレードのアドバイス

Oracle WebLogic Serverで、javaソースの自動コンパイルは行われません。ただし、次の処理は可能です。

- JSPファイルについて動的なクラスロードを有効にするには、weblogic.xmlでjsp-descriptor/page-check-secondsを構成します。

- サーブレットについて動的なクラスロードを有効にするには、weblogic.xmlでcontainer-descriptor/servlet-reload-check-secsを構成します。

開発モードでは、この両方のフラグがデフォルト値の1秒に設定されます。本番環境では、これらのフラグは無効であり、明示的に設定する必要があります。

詳細情報

"『Oracle Fusion Middleware Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のweblogic.xmlデプロイメント・ディスクリプタの要素に関する項

directory-browsing

OC4Jでの定義

この属性は、URLが「/」で終わるときにディレクトリの参照を許可するかどうかを指定します。

対応するweblogic.xmlエントリ

container-descriptor /index-directory-enabled

アップグレードのアドバイス

weblogic.xmlでcontainer-descriptor/index-directory-enabled構成を使用します。

詳細情報

"『Oracle Fusion Middleware Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のweblogic.xmlデプロイメント・ディスクリプタの要素に関する項

enable-jsp-dispatcher-shortcut

OC4Jでの定義

このOC4J固有のフラグは、パフォーマンス・チューニング用のフラグで、simple-jsp-mappingattribute属性のtrue設定とともに使用します。

対応するweblogic.xmlエントリ

なし。

アップグレードのアドバイス

Oracle WebLogic Serverには、同等なものがありません。

詳細情報

なし。

file-modification-check-interval

OC4Jでの定義

HTMLファイルなどの静的ファイルをいつチェックして、タイムスタンプが変更されているかどうかと、そのためにファイル・システムから再ロードする必要があるかどうかを確認するかを指定します。

対応するweblogic.xmlエントリ

container-descriptor /index-directory-enabled

アップグレードのアドバイス

weblogic.xmlでcontainer-descriptor/resource-reload-check-sec要素を使用します。

関連する次のweblogic.xml設定も検討してください。

- JSPに同様の設定を使用するには、jsp-descriptor/page-check-secondsを使用します。

- サーブレットに同様の設定を指定するには、container-descriptor/servlet-reload-check-secsを使用します。

詳細情報

"『Oracle Fusion Middleware Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のweblogic.xmlデプロイメント・ディスクリプタの要素に関する項

jsp-cache-directory

OC4Jでの定義

JSPトランスレータからの出力ファイルのベース・ディレクトリとして使用される、JSPのキャッシュ・ディレクトリを指定します。

対応するweblogic.xmlエントリ

jsp-descriptor/workingDir

アップグレードのアドバイス

weblogic.xmlで<jsp-descriptor>要素のworkingDir属性を使用します。

ただし、OC4Jのjsp-cache-directory構成とは異なり、このディレクトリはTLDには関係しません。

詳細情報

"『Oracle Fusion Middleware Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のweblogic.xmlデプロイメント・ディスクリプタの要素に関する項

jsp-cache-tlds

OC4Jでの定義

永続TLDキャッシングがJSPページに対して有効かどうかを示します。

対応するweblogic.xmlエントリ

なし。

アップグレードのアドバイス

Oracle WebLogic ServerはTLDキャッシングをサポートしており、TLDキャッシングはデフォルトで有効になっているため、この構成はアップグレードの必要がありません。

OC4Jとは異なり、TLDキャッシングはデプロイメント・ディスクリプタの要素で無効にすることはできません。

詳細情報

なし。

jsp-print-null

OC4Jでの定義

このフラグを「false」に設定すると、JSPページからのNULL出力に対して、デフォルトの「NULL」文字列ではなく空の文字列が出力されます。

対応するweblogic.xmlエントリ

jsp-descriptor/print-nulls

アップグレードのアドバイス

weblogic.xmlで<jsp-descriptor>要素のprint-nulls属性を使用します。

詳細情報

"『Oracle Fusion Middleware Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のweblogic.xmlデプロイメント・ディスクリプタの要素に関する項

jsp-taglib-locations

OC4Jでの定義

JSPページで（jsp-cache-tlds属性によって）永続TLDキャッシングが有効になっている場合に、この属性を使用すると、既知の場所として使用する1つ以上のディレクトリをセミコロンで区切ったリストで指定できます。

対応するweblogic.xmlエントリ

なし。

アップグレードのアドバイス

Oracle WebLogic ServerはTLDキャッシングをサポートしており、TLDキャッシングはデフォルトで有効になっているため、この構成はアップグレードの必要がありません。

詳細情報

"『Oracle Fusion Middleware Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のweblogic.xmlデプロイメント・ディスクリプタの要素に関する項

jsp-timeout

OC4Jでの定義

指定した時間が経過した後も要求がなければ、JSPページはメモリーから削除されます。

対応するweblogic.xmlエントリ

なし。

アップグレードのアドバイス

この機能は、メモリーの効率的な使用が重要視されるアプリケーションに影響します。コールされる頻度が低いJSPページがある場合は、これによってリソースが解放されます。

この機能はアップグレードの必要がありません。

詳細情報

なし。

persistence-path

OC4Jでの定義

サーバーの再起動後またはアプリケーションの再デプロイ後も永続的に保持される、サーブレットのHttpSessionオブジェクトの格納場所を示します。

この機能を有効にするには、セッション・オブジェクトをシリアライズ可能にする（直接的または間接的にjava.io.Serializableインタフェースを実装する）か、またはリモート対応にする（直接的または間接的にjava.rmi.Remoteインタフェースを実装する）必要があります。

対応するweblogic.xmlエントリ

- session-descriptor要素のpersistent-store-type属性

- container-descriptor要素のsave-sesssions-enables属性

アップグレードのアドバイス

weblogic.xmlで、session-descriptor要素のpersistent-store-type属性をmemoryに設定し、container-descriptor要素のsave-sessions-enabled属性をtrueに設定します。

これによって、アプリケーションの再デプロイメント後やサーバーの再起動後も、セッションがディスクに確実にシリアライズされます。

詳細情報

"『Oracle Fusion Middleware Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のweblogic.xmlデプロイメント・ディスクリプタの要素に関する項

schema-major-version

OC4Jでの定義

orion-web.xml XSDのメジャー・バージョン番号です。

対応するweblogic.xmlエントリ

なし。

アップグレードのアドバイス

Oracle WebLogic Serverでは必要ありません。

詳細情報

なし。

schema-minor-version

OC4Jでの定義

orion-web.xml XSDのマイナー・バージョン番号です。

対応するweblogic.xmlエントリ

なし。

アップグレードのアドバイス

なし。

詳細情報

なし。

servlet-webdir

OC4Jでの定義

OC4Jのシステム・プロパティのhttp.webdir.enableがtrueに設定されている場合は、この属性を使用して、スタンドアロンOC4Jでのクラス名によるサーブレットの起動を有効にします。

このシステム・プロパティを設定すると、スラッシュ（/）で始まるすべてのservlet-webdir設定によって、この機能が有効になるとともに、OC4Jにクラス名でサーブレットを起動させるために、コンテキスト・パスの後に挿入される特別なURL部分が指定されます。URL内のこのパス以降に記述されている部分は、すべてクラス名とみなされます（パッケージも含みます）。

この機能は、通常、開発時とテスト時にOC4Jスタンドアロン環境で使用します。これにはセキュリティ上の重大なリスクが伴うので、本番環境では使用しないでください。

対応するweblogic.xmlエントリ

なし。

アップグレードのアドバイス

サーブレット仕様の標準サーブレットおよびサーブレット・マッピング宣言を構成して、weblogic.servlet.ServletServletを構成します。

詳細情報

"『Oracle Fusion Middleware Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のサーブレットの作成と構成に関する項

simple-jsp-mapping

OC4Jでの定義

*.jspがoracle.jsp.runtimev2.JspServletフロントエンドJSPサーブレットのみにマップされている場合は、trueに設定します。

これは、アプリケーションに影響を与える任意のWebディスクリプタ（global-web-application.xml、web.xmlおよびorion-web.xml）の<servlet>要素で指定されます。

この属性を有効にすると、JSPページのパフォーマンスが向上します。

対応するweblogic.xmlエントリ

なし。

アップグレードのアドバイス

これはOC4J JSPコンテナのパフォーマンス・チューニング・フラグなので、WebLogic Serverでは不要です。

詳細情報

なし。

source-directory

OC4Jでの定義

development属性がtrueに設定されている場合は、source-directory設定で指定する場所で、自動コンパイルの対象となるサーブレット・ソース・ファイルが検索されます。

デフォルトの場所を使用する場合、OC4Jは、デプロイメント後にアプリケーションの/WEB-INFディレクトリの場所を追跡し続けます。修正されたソース・ファイルは、パッケージ名に基づいて、source-directoryディレクトリの任意の場所で検出されることに注意してください。

対応するweblogic.xmlエントリ

- jsp-descriptor要素のpage-check-seconds属性

- container-descriptor要素のservlet-reload-check-secs属性

アップグレードのアドバイス

WebLogic Serverで、javaソースの自動コンパイルは行われません。

- JSPファイルについて動的なクラスロードを有効にするには、jsp-descriptor要素のpage-check-seconds属性を構成します。

- サーブレットについて動的なクラスロードを有効にするには、container-descriptor要素のservlet-reload-check-secs属性を構成します。

開発モードでは、この両方のフラグがデフォルト値の1秒に設定されます。本番環境では、これらのフラグは無効であり、明示的に設定する必要があります。

詳細情報

"『Oracle Fusion Middleware Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のweblogic.xmlデプロイメント・ディスクリプタの要素に関する項

temporary-directory

OC4Jでの定義

これは、サーブレットおよびJSPページがスクラッチ・ファイル用に使用する一時ディレクトリのパスです。このパスは、絶対パスまたはデプロイメント・ディレクトリからの相対パスのいずれかで指定できます。

対応するweblogic.xmlエントリ

なし。

アップグレードのアドバイス

サーブレット仕様のjavax.servlet.context.tempdir属性を構成します。

サーブレットや他のクラスが情報の格納に使用できる一時作業ディレクトリを使用すると、アプリケーションが正しく動作しない場合があります。

詳細情報

"Webサイトjava.sun.comにある「Java 2 Platform, Enterprise Edition, v 1.3 API Specification」のServletContext Javaサーブレット・インタフェース

orion-ejb-jar.xml

OC4J固有のアプリケーションレベルのEJBディスクリプタであるorion-ejb.xmlは、WARファイルの/WEB-INFディレクトリに格納されて配布されます。このディスクリプタは、OC4J固有の設定を追加したり、ejb-jar.xmlの設定を上書きするために使用します。

Oracle WebLogic Serverでは、同等のベンダー固有のデプロイメント・ディスクリプタはweblogic-ejb-jar.xmlと呼ばれ、Webモジュールの/WEB-INFディレクトリ内にあります。

10g アプリケーションをOracle WebLogic Serverに再デプロイする場合は、EJBモジュールで設定した特定のOC4J設定を、すべてweblogic-ejb-jar.xmlファイル内の同等の設定でWebLogic Server用に変換する必要があります。詳細は、この付録に記載された、orion-ejb.xmlファイルの主要な要素および要素属性に関する情報を参照してください。

<session-deployment>

OC4Jでの定義

このJARファイル内でデプロイされたセッションBeanの追加のカスタマイズ済デプロイメント情報を提供します。この要素が存在するということは、セッションBeanのカスタマイズされたデプロイメント設定がアプリケーションに含まれていることを示します。

weblogic-ejb-jar.xmlでの同等なエントリ

- stateless-session-descriptor

- stateful-session-descriptor

アップグレードのアドバイス

Oracle WebLogic ServerでのセッションBeanのカスタマイズは、stateless-session-descriptor要素およびstateful-session-descriptor要素を使用して行います。

詳細情報

"『Oracle Fusion Middleware Oracle WebLogic Server Enterprise JavaBeansのプログラミング』のstateless-session-descriptorに関する項およびstateful-session-descriptorに関する項

copy-by-value

OC4Jでの定義

<session-deployment>要素のこの属性は、EJBコールにおけるすべての受信および送信パラメータをコピー（クローン作成）するかどうかを示します。アプリケーションを高速化するために、copy-by-valueセマンティクスを前提としないことが確実な場合は、この値をfalseに設定します。デフォルト値はtrueです。

weblogic-ejb-jar.xmlでの同等なエントリ

enable-call-by-reference

アップグレードのアドバイス

enable-call-by-reference要素を使用して、copy-by-valueセマンティクスをweblogic-ejb-jar.xmlで指定します。

詳細情報

"『Oracle Fusion Middleware Oracle WebLogic Server Enterprise JavaBeansのプログラミング』のenable-call-by-referenceに関する項

idletime

OC4Jでの定義

<session-deployment>要素のこの属性は、各Beanのアイドル・タイムアウトを設定するために使用します。このタイムアウト時間が経過すると、非アクティブ化が行われます。この属性には、適切な秒数を設定します。デフォルトは300秒（5分）です。無効にするには、任意の負の数を指定します。

weblogic-ejb-jar.xmlでの同等なエントリ

stateful-session-cache/idle-timeout-seconds

アップグレードのアドバイス

stateful-session-descriptorのstateful-session-cache/idle-timeout-seconds要素を使用して、weblogic-ejb-jar.xmlでアイドル・タイムアウトを設定します。

詳細情報

"『Oracle Fusion Middleware Oracle WebLogic Server Enterprise JavaBeansのプログラミング』のstateful-session-cacheに関する項

min-instances

OC4Jでの定義

<session-deployment>要素のこの属性は、インスタンス化またはプールされた状態で維持されるBean実装インスタンスの最小数です。デフォルトは0（ゼロ）です。この設定が有効なのは、ステートレス・セッションBeanのみです。

この要素が存在するということは、Beanのカスタマイズされたプーリング設定がアプリケーションに含まれていることを示します。

weblogic-ejb-jar.xmlでの同等なエントリ

initial-beans-in-free-pool

アップグレードのアドバイス

initial-beans-in-free-pool要素を使用して、Beanプールの最小サイズをweblogic-ejb-jar.xmlで設定します。

詳細情報

"『Oracle Fusion Middleware Oracle WebLogic Server Enterprise JavaBeansのプログラミング』のステートレス・セッションEJBのプーリングに関する項

max-instances

OC4Jでの定義

<session-deployment>要素のこの属性が存在するということは、Beanのカスタマイズされたプーリング設定がアプリケーションに含まれていることを示します。

weblogic-ejb-jar.xmlでの同等なエントリ

max-beans-in-free-pool

アップグレードのアドバイス

max-beans-in-free-pool要素を使用して、Beanプールの最大サイズをweblogic-ejb-jar.xmlで設定します。

詳細情報

"『Oracle Fusion Middleware Oracle WebLogic Server Enterprise JavaBeansのプログラミング』のステートレス・セッションEJBのプーリングに関する項

max-instances-threshold

OC4Jでの定義

<session-deployment>要素のこの属性は、非アクティブ化が行われるまでにメモリー内に存在できるBean数のmax-instances数に対する割合を設定するために使用します。

weblogic-ejb-jar.xmlでの同等なエントリ

max-beans-in-cache

アップグレードのアドバイス

stateful-session-descriptorのstateful-session-cache/max-beans-in-cache要素を使用して、weblogic-ejb-jar.xmlでアイドル・タイムアウトを設定します。

詳細情報

"『Oracle Fusion Middleware Oracle WebLogic Server Enterprise JavaBeansのプログラミング』のstateful-session-cacheに関する項

max-tx-retries

OC4Jでの定義

<session-deployment>要素のこの属性は、システムレベルの障害によってロールバックされたトランザクションの再試行回数を指定します。デフォルトは0（ゼロ）です。

ステートフル・セッションBeanでは、RuntimeException、ErrorまたはRemoteExceptionがスローされてもOC4Jは再試行しません。

weblogic-ejb-jar.xmlでの同等なエントリ

retry-methods-on-a-rollback/retry-count

アップグレードのアドバイス

weblogic-ejb-jar.xmlのEJBモジュール内のすべてのBeanに対して再試行を有効にするには、retry-methods-on-rollback/retry-count要素を使用します。

ただし、OC4JとOracle WebLogic Serverとでは動作が異なることに注意してください。OC4JではEJBごとに再試行を指定し、WebLogic ServerではEJBモジュールごとに再試行を構成します。

詳細情報

"『Oracle Fusion Middleware Oracle WebLogic Server Enterprise JavaBeansのプログラミング』のretry-methods-on-rollbackに関する項

resource-check-interval

OC4Jでの定義

<session-deployment>要素のこの属性は、すべてのリソースをこの時間間隔でチェックするために使用します。この時点でいずれかのしきい値に達している場合は、非アクティブ化が行われます。デフォルトは180秒（3分）です。

無効にするには、任意の負の数を指定します。

weblogic-ejb-jar.xmlでの同等なエントリ

なし。

アップグレードのアドバイス

Oracle WebLogic Serverではサポートされていません。

詳細情報

該当なし

passivate-count

OC4Jでの定義

<session-deployment>要素のこの属性は、いずれかのリソースしきい値に達した場合に非アクティブ化するBeanの数を定義するために使用します。

Beanの非アクティブ化は、最低使用頻度アルゴリズムを使用して実行されます。デフォルトは、max-instances属性の1/3です。この属性を無効にするには、カウントを0（ゼロ）または負の数に設定します。

weblogic-ejb-jar.xmlでの同等なエントリ

なし。

アップグレードのアドバイス

Oracle WebLogic Serverではサポートされていません。

詳細情報

該当なし

persistence-filename

OC4Jでの定義

<session-deployment>要素のこの属性は、再起動のたびにセッションが保存されるファイルへのパスを定義するために使用します。

weblogic-ejb-jar.xmlでの同等なエントリ

なし。

アップグレードのアドバイス

これは、Oracle WebLogic Serverでサポートされていません。ただし、Oracle WebLogic Serverのカスタム永続ストアを使用できる場合があります。

詳細情報

"『Oracle Fusion Middleware Oracle WebLogic Server Enterprise JavaBeansのプログラミング』の非アクティブ化Beanに対する永続ストア・ディレクトリの指定に関する項

pool-cache-timeout

OC4Jでの定義

<session-deployment>要素のこの属性は、プールにキャッシュされたステートレス・セッションを維持する期間を指定します。

ステートレス・セッションBeanの場合、pool-cache-timeoutを指定すると、pool-cache-timeoutの時間間隔で、プール内の対応するBeanタイプのBeanがすべて削除されます。0（ゼロ）または負の値を指定すると、pool-cache-timeoutが無効になり、Beanはプールから削除されません。

weblogic-ejb-jar.xmlでの同等なエントリ

idle-timeout-seconds

アップグレードのアドバイス

idle-timeout-seconds要素を使用して、Beanプールのタイムアウト値をweblogic-ejb-jar.xmlで設定します。

詳細情報

"『Oracle Fusion Middleware Oracle WebLogic Server Enterprise JavaBeansのプログラミング』のステートレス・セッションEJBのプーリングに関する項

timeout

OC4Jでの定義

<session-deployment>要素のこの属性は、ステートフル・セッションBeanがプールのクリーンアップの対象となるまでに非アクティブ状態を継続できる最大秒数を設定するために使用します。値が0（ゼロ）または負の数の場合、すべてのタイムアウトが無効になります。

プール・クリーンアップ・ロジックは、30秒ごとに起動されます。プール・クリーンアップ・ロジックの実行中に、タイムアウト値を渡すことによって削除されるのは、タイムアウトしたセッションのみです。

weblogic-ejb-jar.xmlでの同等なエントリ

stateful-session-cache

アップグレードのアドバイス

stateful-session-descriptorのstateful-session-cache/session-timeout-seconds要素を使用して、weblogic-ejb-jar.xmlでセッション・タイムアウトを設定します。

詳細情報

"『Oracle Fusion Middleware Oracle WebLogic Server Enterprise JavaBeansのプログラミング』のstateful-session-cacheに関する項

transaction-timeout

OC4Jでの定義

<session-deployment>要素のこの属性は、このステートレスまたはステートフルのセッションBeanによって開始されたトランザクションがコミットまたはロールバックされるのをOC4Jが待機する最大秒数を示します。値が0（ゼロ）または負の数の場合、タイムアウトは無効になります。

weblogic-ejb-jar.xmlでの同等なエントリ

transaction-descriptor要素とそのtrans-timeout-seconds子要素

アップグレードのアドバイス

transaction-descriptor/trans-timeout-seconds要素および子要素を使用して、EJBのトランザクション・タイムアウト値をweblogic-ejb-jar.xmlで設定します。

詳細情報

"『Oracle Fusion Middleware Oracle WebLogic Server Enterprise JavaBeansのプログラミング』のtransaction-descriptorに関する項

<ejb-ref-mapping>

OC4Jでの定義

この要素は、あらゆるEJB参照をJNDI名にマップします。

クライアントのロールで動作している1つのエンタープライズBean（ソース・エンタープライズBeanと呼ぶ）が別のエンタープライズBean（ターゲット・エンタープライズBeanと呼ぶ）にアクセスするには、その前にソース・エンタープライズBeanのデプロイメント・ディスクリプタでターゲット・エンタープライズBeanへのEJB参照を定義する必要があります。

weblogic-ejb-jar.xmlでの同等なエントリ

ejb-reference-description

アップグレードのアドバイス

weblogic-ejb-jar.xmlのejb-reference-description要素を使用して、EJB参照のJNDIロケーション・マッピングを設定します。

詳細情報

"『Oracle Fusion Middleware Oracle WebLogic Server Enterprise JavaBeansのプログラミング』のejb-reference-descriptionに関する項

<resource-ref-mapping>

OC4Jでの定義

この要素は、あらゆるEJB参照をJNDI名にマップします。

JDBCデータソース、JMSトピックまたはキュー、JavaMail、HTTP URLなどのサービスへの接続を提供するリソース・マネージャ・コネクション・ファクトリへの環境参照を定義できます。これらの参照は、OC4Jが提供する実際のリソース・マネージャ・コネクション・ファクトリに、OC4Jがデプロイメント時にバインドする論理名です。

weblogic-ejb-jar.xmlでの同等なエントリ

resource-description

アップグレードのアドバイス

weblogic-ejb-jar.xmlのresource-description要素を使用して、リソース参照のJNDIロケーション・マッピングを設定します。

詳細情報

"『Oracle Fusion Middleware Oracle WebLogic Server Enterprise JavaBeansのプログラミング』のresource-descriptionに関する項

<resource-env-ref-mapping>

OC4Jでの定義

<resource-env-ref-mapping>要素は、リソースの管理オブジェクトをマップするために使用されます。

たとえば、JMSを使用するためには、BeanはJMSファクトリ・オブジェクトと宛先オブジェクトの両方を取得する必要があります。これらのオブジェクトは、JNDIから同時に取得されます。<resource-ref>要素でJMSファクトリを宣言し、<resource-env-ref>要素を使用して宛先を宣言します。したがって、<resource-env-ref-mapping>要素は宛先オブジェクトをマップします。

weblogic-ejb-jar.xmlでの同等なエントリ

resource-env-description

アップグレードのアドバイス

weblogic-ejb-jar.xmlのresource-env-description要素を使用して、リソース環境参照のJNDIロケーション・マッピングを設定します。

詳細情報

"『Oracle Fusion Middleware Oracle WebLogic Server Enterprise JavaBeansのプログラミング』のresource-env-descriptionに関する項

<message-destination-ref-mapping>

OC4Jでの定義

<message-destination-ref-mapping>要素は、JMS 1.1を使用している場合にのみ使用します。

この要素を使用して、クライアント・デプロイメント・ディスクリプタのmessage-destination-ref-nameをOC4J環境で使用できる別の場所にマップします。これにより、メッセージのコンシューマとプロデューサを1つ以上の共通の論理的な宛先にリンクする手段が提供されます。

weblogic-ejb-jar.xmlでの同等なエントリ

message-destination-descriptor

アップグレードのアドバイス

weblogic-ejb-jar.xmlのmessage-destination-descriptor要素を使用して、メッセージ宛先マッピングのJNDIロケーション・マッピングを設定します。

詳細情報

"『Oracle Fusion Middleware Oracle WebLogic Server Enterprise JavaBeansのプログラミング』のmessage-destination-descriptorに関する項

<session-type>Stateful</session-type>

OC4Jでの定義

session-type要素のこの値は、アプリケーションにステートフル・セッションBeanが含まれていることを示します。

weblogic-ejb-jar.xmlでの同等なエントリ

stateful-session-cache/cache-type

アップグレードのアドバイス

ステートフル・セッションBeanを非アクティブ化するデフォルトの方法は、OC4JとWebLogic Serverで異なります。

WebLogic Serverの場合、デフォルトでは、NRU（Not Recently Used）の非アクティブ化モデルが使用され、リソースの限度に達したときにのみ非アクティブ化が行われます。OC4Jの場合は、Beanのアイドル・タイムアウトに達すると同時に非アクティブ化が行われるLRU（Least Recently Used）モデルに厳密に従います。

非アクティブ化を頻繁に行うセマンティクスが必要な場合は、weblogic-ejb-jar.xmlのstateful-session-descriptorでstateful-session-cache/cache-type要素をLRUに設定し、OC4Jセマンティクスを維持します。

詳細情報

"『Oracle Fusion Middleware Oracle WebLogic Server Enterprise JavaBeansのプログラミング』のステートフル・セッションEJBの非アクティブ化に関する項

<message-driven-deployment>

OC4Jでの定義

orion-ejb-jar.xmlのこのセクションでは、このJARファイル内でデプロイされたメッセージドリブンBeanの追加のデプロイメント情報を提供します。

この要素が存在するということは、メッセージドリブンBeanのカスタマイズされたデプロイメント設定がアプリケーションに含まれていることを示します。

weblogic-ejb-jar.xmlでの同等なエントリ

message-driven-descriptor

アップグレードのアドバイス

weblogic-ejb-jar.xmlのmessage-driven-descriptor要素を使用します。

詳細情報

"『Oracle Fusion Middleware Oracle WebLogic Server Enterprise JavaBeansのプログラミング』のmessage-driven-descriptorに関する項

connection-factory-location

OC4Jでの定義

<message-driven-deployment>要素のこの属性は、使用するコネクション・ファクトリのJNDIロケーションを定義するために使用します。JMSの宛先コネクション・ファクトリは、この属性で指定されます。構文は、java:comp/resource + リソース・プロバイダ名 + TopicConnectionFactoriesまたはQueueConnectionFactories + ユーザー定義名です。nnnConnectionFactoriesは、定義するファクトリのタイプを指定します。

weblogic-ejb-jar.xmlでの同等なエントリ

connection-factory-jndi-name

アップグレードのアドバイス

weblogic-ejb-jar.xmlでmessage-driven-descriptor要素のconnection-factory-jndi-nameを使用します。

詳細情報

"『Oracle Fusion Middleware Oracle WebLogic Server Enterprise JavaBeansのプログラミング』のmessage-driven-descriptorに関する項

dequeue-retry-count

OC4Jでの定義

<message-driven-deployment>要素のこの属性は、データベース・フェイルオーバーの発生後、リスナー・スレッドによって試行されるJMSセッションの再取得頻度を指定するために使用します。これは、MDB内のコンテナ管理トランザクションに対してのみ適用されます。

weblogic-ejb-jar.xmlでの同等なエントリ

なし。

アップグレードのアドバイス

dequeue-retry-countはMDBに対して指定し、宛先が停止していることをOC4Jが検出したときに、宛先に対するリスナー・スレッドの再起動を試行する回数を構成します。

Oracle WebLogic Serverには、直接対応するものがありません。この機能は、Oracle AQに対するフェイルオーバーのサポートを目的としており、Oracle WebLogic Serverでリソース・アダプタに固有な設定になります。

詳細情報

該当なし

dequeue-retry-interval

OC4Jでの定義

<message-driven-deployment>要素のこの属性は、再試行の間隔を指定するために使用します。

weblogic-ejb-jar.xmlでの同等なエントリ

なし。

アップグレードのアドバイス

dequeue-retry-intervalはMDBに対して指定し、宛先が停止していることをOC4Jが検出したときに、宛先に対するリスナー・スレッドの再起動を試行する時間間隔を構成します。

Oracle WebLogic Serverには、直接対応するものがありません。この機能は、Oracle AQに対するフェイルオーバーのサポートを目的としており、Oracle WebLogic Serverでリソース・アダプタに固有な設定になります。

詳細情報

該当なし

destination-location

OC4Jでの定義

<message-driven-deployment>要素のこの属性は、使用する宛先（キューまたはトピック）のJNDIロケーションを定義するために使用します。

JMS宛先は、destination-location属性で指定されます。構文は、java:comp/resource + リソース・プロバイダ名 + トピックまたはキュー + 宛先名です。トピックまたはキューは、定義する宛先のタイプを指定します。宛先名は、データベースで定義された実際のキュー名またはトピック名です。

weblogic-ejb-jar.xmlでの同等なエントリ

destination-jndi-name

アップグレードのアドバイス

weblogic-ejb-jar.xmlでmessage-driven-descriptorのdestination-jndi-name要素を使用します。

詳細情報

"『Oracle Fusion Middleware Oracle WebLogic Server Enterprise JavaBeansのプログラミング』のmessage-driven-descriptorに関する項

listener-threads

OC4Jでの定義

<message-driven-deployment>要素のこの属性は、複数のJMSメッセージを同時にコンシュームするために使用します。デフォルトは1スレッドです。トピックには、1スレッドのみを指定できます。キューには複数のスレッドを設定できます。

weblogic-ejb-jar.xmlでの同等なエントリ

max-beans-in-free-pool

アップグレードのアドバイス

Oracle WebLogic Serverでは、使用するリソース・アダプタに応じた様々な方法でスレッド管理を制御できます。

詳細情報

"『Oracle Fusion Middleware Oracle WebLogic Server Enterprise JavaBeansのプログラミング』のステートフル・セッションBeanへの同時アクセスの構成に関する説明

max-delivery-count

OC4Jでの定義

<message-driven-deployment>要素のこの属性は、メッセージドリブンBeanのonMessageメソッドがエラーを戻した場合（確認応答操作の起動に失敗した場合、例外をスローした場合、またはその両方の場合）にOC4Jがこのメソッドにメッセージの即時再配信を試行する最大回数を設定するために使用します。

この回数の再配信が行われると、メッセージは配信不能とみなされ、メッセージ・サービス・プロバイダのポリシーに従って処理されます。たとえば、OEMS JMSはその例外キュー（jms/Oc4jJmsExceptionQueue）にメッセージを挿入します。

weblogic-ejb-jar.xmlでの同等なエントリ

なし。

アップグレードのアドバイス

max-delivery-countはMDBに対して指定され、障害が発生したときに同じメッセージの配信を試行する最大回数を設定します。Oracle WebLogic Serverでは、このオプションをMDBごとに設定することはサポートされていません。

詳細情報

『Oracle Fusion Middleware Oracle WebLogic Server JMSのプログラミング』

resource-adapter

OC4Jでの定義

<message-driven-deployment>要素のこの属性は、このMDBが使用するリソース・アダプタ・インスタンスの名前を定義するために使用します。このMDBがJ2CAメッセージ・サービス・プロバイダを使用している場合にのみ適用されます。リソース・アダプタにより受信されたメッセージでMDBをアクティブにするには、MDBとリソース・アダプタを接続する必要があります。

weblogic-ejb-jar.xmlでの同等なエントリ

resource-adapter-jndi-name

アップグレードのアドバイス

weblogic-ejb-jar.xmlでmessage-destination-descriptor要素のresource-adapter-jndi-nameを使用します。

詳細情報

"『Oracle Fusion Middleware Oracle WebLogic Server Enterprise JavaBeansのプログラミング』のmessage-driven-descriptorに関する項

subscription-name

OC4Jでの定義

<message-driven-deployment>要素のこの属性は、このメッセージドリブンBeanがサブスクライブするトピックの名前を定義するために使用します。

weblogic-ejb-jar.xmlでの同等なエントリ

なし。

アップグレードのアドバイス

リソース・アダプタを使用し、そのリソース・アダプタがsubscription-nameプロパティをサポートしている場合は、ejb-jar.xmlのactivation-config-property要素を使用してそのリソース・アダプタを指定する必要があります。Oracle WebLogic Serverでは、このプロパティをweblogic-ejb-jar.xmlで設定することはできません。

詳細情報

該当なし

wrapper-class

OC4Jでの定義

<message-driven-deployment>要素のこの属性を使用します。

weblogic-ejb-jar.xmlでの同等なエントリ

アップグレードのアドバイス

dequeue-retry-countはMDBに対して指定し、宛先が停止していることをOC4Jが検出したときに、宛先に対するリスナー・スレッドの再起動を試行する回数を構成します。

Oracle WebLogic Serverには、直接対応するものがありません。この機能は、Oracle AQに対するフェイルオーバーのサポートを目的としており、Oracle WebLogic Serverでリソース・アダプタに固有な設定になります。

詳細情報

該当なし

<config-property>

OC4Jでの定義

<config-property>要素は、J2CAメッセージ・サービス・プロバイダを使用している場合にのみ使用します。この要素を使用して、J2CAリソース・アダプタ構成プロパティを設定します。J2CAメッセージ・サービス・プロバイダを使用するように構成されているMDBをOC4Jがデプロイする場合、OC4Jはリソース・アダプタにMDBのアクティブ化仕様を提供します。この仕様には、<config-property>要素で設定したプロパティが含まれます。

別の方法として、EJB 3.0のメッセージドリブンBeanでは、@MessageDrivenの属性configPropertyおよび@ActivationConfigアノテーションを使用して、J2CAリソース・アダプタ構成プロパティを設定できます。

orion-ejb-jar.xmlファイルの<config-property>構成を使用すると、@MessageDriven構成を上書きできます。

weblogic-ejb-jar.xmlでの同等なエントリ

なし。

アップグレードのアドバイス

Oracle WebLogic Serverでは、アクティブ化の構成プロパティをweblogic-ejb-jar.xmlで上書きすることはサポートされていません。これらの設定は、ejb-jar.xmlファイルにある通常のアクティブ化構成プロパティとマージする必要があります。

詳細情報

該当なし

Copyright © 2010, 2011, Oracle and/or its affiliates. All rights reserved.