| Oracle® Fusion Middleware Oracle WebLogic Serverアップグレード・ガイド 11g リリース1（10.3.3） B61642-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebLogic Serverアップグレード・ガイド 11g リリース1（10.3.3） B61642-01 |
|
前 |
次 |
この節では、WebLogic Server 10.3.3にアップグレードする前に検討する必要がある、互換性に関する重要な情報について説明します。
『Oracle WebLogic Serverインフォメーション・ロードマップ』のWebLogic Serverの互換性に関する項および『Oracle WebLogic Serverの新機能』も参照してください。
互換性に関する検討事項は、次のように分類されます。
WebLogic Server 10.3.3では、WebLogic ServerランタイムMBeanサーバーに対応するサーバー用のプラットフォームMXBeanが含まれるようにデフォルトで構成されています。ドメイン・ランタイムMBeanサーバーには、ドメイン内のすべてのサーバー用のプラットフォームMXBeanが含まれます。
ランタイムMBeanサーバー用のプラットフォームMBeanサーバーの使用は、JMX MBeanのPlatformMBeanServerUsed属性によって制御されます。前のリリースでは、PlatformMBeanServerUsed属性のデフォルト値はfalseでした。明示的に有効にしないかぎりプラットフォームMBeanサーバーは使用されません。WebLogic Server 10.3.3では、PlatformMBeanServerUsed属性のデフォルト値はバージョン10.3.3.0以降のドメインの場合はtrueです。詳細は、『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』のプラットフォームMBeanサーバーの使用に関する項を参照してください。
WebLogic Server 10.3.3から、WebLogicファイル・ストアのデフォルト・ファイル・ストアおよびカスタム・ファイル・ストアに対する動作およびチューニング方法が変更されました。ファイル・ストアは、JTAアプリケーション、JMSアプリケーション、WSアプリケーションなどで使用されている可能性がありますが、これらの変更はほとんどのユーザーにとって透過的です。
詳細は、『Oracle WebLogic Serverサーバー環境の構成』の同期書込みポリシーの構成ガイドラインに関する項を参照してください。
WebLogic Server 10.3.3以降では、WebLogic Serverインストール・プログラムの評価版データベースがPointBaseからApache Derbyに変更されています。「製品とコンポーネントの選択」画面の評価版データベース・オプションを選択すると、DerbyデータベースがWL_HOME\common\derbyディレクトリにインストールされます。「標準」インストールを選択すると、Derbyがデフォルトでインストールされます。
WebLogic Serverのサンプル・サーバーであるMedrecおよびMedrec-Springが変更されて、WebLogic Serverに含まれる評価版のDerbyデータベースが使用されるようになりました（次の節を参照してください）。また、Oracle TopLinkがJava Persistence Architecture（JPA）永続プロバイダとして使用されるようになりました（JPA永続プロバイダが使用されている場合）。
PointBaseに基づくドメインがあり、ドメインをWebLogic Server 10.3.3にアップグレードした後も引続きPointBaseを使用する場合は、PointBaseのライセンスをhttp://www.pointbase.comで入手する必要があります。（WebLogic Serverのアップグレード・インストーラを使用するとPointBaseインストール・ディレクトリが保存されますが、フル・インストーラでは保存されません。）PointBaseを使用するかわりに、ドメイン・データベースをDerbyに移行することができます。
詳細は、「評価版データベースを使用するドメインのアップグレード」を参照してください。
WebLogic Server 9.0では、JDK 5.0に含まれているJava Management Extensions（JMX）1.2実装が使用されています。9.0より前のリリースでは、JMX 1.0仕様をベースにした独自のJMX実装が使用されていました。
JMX 1.2参照実装の採用により、シリアライゼーションの互換性がなくなりました。参照実装においてシリアライゼーションの互換性はなくなりましたが、WebLogic Server 8.1用に作成されたJMXクライアントは、次のように9.2と10.3.3でも使用できます。
JMXクライアントがWebLogic Server MBeanのみにアクセスし、weblogic.management.MBeanHomeのみを使用する場合は、アップグレードしなくてもWebLogic Server 9.2、10.0、または10.3.3インスタンスで実行できます。
WebLogic Server 8.1クラスを使用するJMXクライアントは、次のすべての条件に該当すれば、9.2、10.0、または10.3.3 JMXエージェントと対話できます。
クライアントがWebLogic Server MBeanのみにアクセスします。
クライアントがweblogic.management.MBeanHomeのみを使用します（JDK MBeanServerインタフェースを使用しません）。
WebLogic Serverクラスが8.1 SP4または7.0 SP6で作成され、それに適切なパッチが適用されています。
JMXクライアントで、WebLogic Server MBeanとの対話またはカスタムMBeanの作成と使用に標準のJMX MBeanServerインタフェースが使用されている場合は、WebLogic Server 9.2、10.0、または10.3.3インスタンス用のJDK起動オプション-Djmx.serial.form=1.0を含める必要があります。
この起動オプションを含めると、JVMがオブジェクトをシリアライズするときにJMX 1.0のクラス記述が使用されるようになります。このオプションは、JMX 1.0クライアントが標準のJDKクラスを使用してJMX 1.2エージェントと通信する場合に必要です。
JMXクライアントがセキュリティ・プロバイダMBeanと対話する場合は、「セキュリティMBean」を参照してください。
JMXクライアントをWebLogic Server 10.3.3に準拠するよう更新することをお薦めします。9.0より前では、WebLogic ServerはJMXレイヤーに対して、型付きAPIレイヤーをサポートしていました。使用するJMXアプリケーション・クラスでは、WebLogic Server MBeanの型保障インタフェースをインポートしたり、weblogic.management.MBeanHomeインタフェースを介してMBeanの参照を取得したり、MBeanメソッドを直接呼び出すことができました。
MBeanHomeインタフェースは、9.0から非推奨となりました。このAPIのようなプログラミング・モデルを使用するかわりに、すべてのJMXアプリケーションで、標準のJMXプログラミング・モデルを使用してください。標準のJMX設計パターンでは、クライアントはjavax.management.MBeanServerConnectionインタフェースを使用して、実行時にMBean、属性、および属性タイプを検索します。このJMXモデルでは、クライアントはMBeanServerConnectionインタフェースを介して間接的にMBeanと対話します。
型保障インタフェース（weblogic.managementから使用可能）をインポートするクラスがある場合は、そのクラスを標準のJMXプログラミング・モデルを使用するよう更新することをお薦めします。詳細は、『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』のWebLogic Server MBeanに関する項を参照してください。
バージョン10.3.3.0以降のドメインでは、WebLogic ServerはランタイムMBeanをJVMのプラットフォームMBeanサーバーに登録します。デフォルトを変更して別のMBeanサーバーを使用する場合は、管理コンソールまたはWLSTを使用してJMX MBeanのPlatformMBeanServerUsed属性をfalseに変更します。詳細は、『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』のプラットフォームMBeanサーバーの使用に関する項を参照してください。
WebLogic Server 10.3.3では、WebLogic Server診断フレームワーク（WLDF）に次の新機能と機能の変更が導入されています。
WebLogic Serverでは、Oracle JRockitフライト・レコーダとの特定の統合ポイントが提供されています。WebLogic Serverのイベントはフライト・レコーダに伝播され、実行時またはインシデント後の分析用に共通のデータ・セットに格納されます。フライト記録のデータもWLDF診断イメージ・キャプチャに含まれるため、WLDFの監視ルールに基づいてフライト記録のスナップショットをキャプチャできます。この一連の機能により、実行中のJVMコンポーネントとFusion Middlewareコンポーネントの両方について、単一のビューで実行時システム情報をキャプチャおよび分析できます。
JRockitフライト・レコーダとのWLDF統合機能の詳細は、『Oracle WebLogic Server診断フレームワークの構成と使い方』のOracle JRockitフライト・レコードでのWLDFの使用に関する項を参照してください。
このリリースのWebLogic Serverでは、インストゥルメンテーション・イベントがジョインポイントへの入力引数またはジョインポイントからの戻り値をキャプチャするときに、アプリケーションの機密データが誤って送信されることを防ぐため、カスタム診断モニターで使用されるDisplayArgumentsActionの動作が変更されました。
この動作変更をオーバーライドする必要がある場合は、WLDFに追加された新しい演算子であるパーセント記号（%）を使用します。この演算子をポイントカット式に指定することで、静的でないクラスのインスタンス化、パラメータ、または戻り値を指定する値が機密情報を格納または公開しないように指定できます。
詳細は、『Oracle WebLogic Server診断フレームワークの構成と使い方』のカスタム・モニターのポイントカットの定義に関する項を参照してください。
WLDFコンソール拡張がWebLogic Server管理コンソールから削除され、次の機能に置き換えられました。
監視ダッシュボード - サーバーおよびサーバーで実行中のアプリケーションに関する診断データをグラフィカルに表示するためのビューとツールが用意されています。診断データを生成、取得、および存続させるための基になる機能は、WebLogic診断フレームワークによって提供されています。監視ダッシュボードには、様々な組込みビューやカスタム・ビューでデータを表示するための追加のツールも用意されています。詳細は、『Oracle WebLogic Server診断フレームワークの構成と使い方』の監視ダッシュボードの使用に関する項を参照してください。
診断リクエスト・パフォーマンス・ページ - WLDFのインストゥルメンテーション機能によってキャプチャされているメソッド・パフォーマンスのリアルタイム・ビューと履歴ビューに関する情報が表示されます。詳細は、『Oracle WebLogic Server診断フレームワークの構成と使い方』のリクエスト・パフォーマンス・データの作成に関する項を参照してください。
構成属性には、「動的なもの」と「動的でないもの」があります。
動的な構成属性への変更は、アクティブ化するとただちに有効になり、その変更の影響を受けるサーバーまたはシステム・リソースを再起動する必要はありません。この変更は、アクティブ化されると、サーバーおよび実行時階層で有効になります。
動的でない構成属性への変更は、ただちには有効になりません。動的でない構成属性への変更を適用するには、サーバーまたはシステム・リソースを再起動する必要があります。
WebLogic Server 9.0から導入された変更管理プロセスにより、構成の変更をドメイン全体にわたってセキュアで確実に適用できます。バッチ変更メカニズムにより、動的な変更と動的でない変更が混在する場合に、動的な変更の適用が制御されます。具体的には、構成されているサーバーまたはシステム・リソースが動的でない変更の影響を受ける場合、サーバーまたはシステム・リソースが再起動されるまで、現在または将来のバッチにおいても、他の変更（動的な変更も含む）は有効になりません。この場合、システムの整合性を維持し、将来の変更の適用を可能にするため、バッチ変更が完了すると同時にエンティティを再起動することをお薦めします。
構成スクリプトをテストして、動的でない変更が適用されているかどうか確認し、適用されている場合はサーバーを再起動する必要があります。変更が動的でなく、サーバーの再起動が必要かどうかを判断するには:
変更をアクティブ化する前に、次を行えます:
管理コンソールのチェンジ・センターに表示されている変更一覧を確認します。『Oracle WebLogic Serverの紹介』の動的な変更および動的でない変更に関する項を参照してください。
isRestartRequiredまたはshowChangesのどちらかのWLSTコマンドを使用します。詳細は、WebLogic Scripting Toolのコマンド・リファレンスを参照してください。
変更をアクティブ化した後、次を行えます:
サーバー・ログで変更が動的でない変更として分類されているかどうかを確認します。
必要に応じて、変更されたオブジェクトに関連付けられているRestartRequired属性またはPendingRestartSystemResources属性の値を確認します。
どのセキュリティ属性が動的であるか動的でないかを確認するには、『Oracle WebLogic Serverの保護』のセキュリティ構成MBeanに関する項を参照してください。
詳細は、Oracle WebLogic Serverのドメイン構成ガイドの構成変更の管理に関する項を参照してください。
WebLogic Server 10.3.3では、www.bea.comが含まれていたネームスペースURIとスキーマの場所がxmlns.oracle.comを参照するように変更されました。また、WebLogic Serverのバージョン番号（920、90）が削除されました。
Oracle WebLogic Serverスキーマのホーム（http://www.oracle.com/technology/weblogic/index.html）を参照してください。また、『Oracle WebLogic Serverアプリケーションの開発』のXMLデプロイメント記述子に関する項を参照してください。
JDBCの構成を簡素化し、構成エラーが発生する可能性を低くするため、WebLogic Server 9.0からは、使用するJDBCリソースのタイプが少なくなっています。JDBC接続プールを構成してから、その接続プールを指し、JNDIツリーにバインドされるデータ・ソースまたはトランザクション・データ・ソースを構成するかわりに、接続プールを包含するデータ・ソースを構成できるようになりました。WebLogic Server 9.0で導入された簡素化されたJDBCリソースの構成の詳細は、『Oracle WebLogic Server JDBCの構成と管理』の簡素化されたJDBCリソース構成に関する項（http://download.oracle.com/docs/cd/E13222_01/wls/docs90/jdbc_admin/jdbc_intro.html#simple_res_config）を参照してください。
次の節で説明するように、WebLogicアップグレード・ウィザードは、JDBCデータ・ソース、接続プール、マルチ・プール、およびデータ・ソース・ファクトリをWebLogic Server 10.3.3仕様に自動的に変換します。
|
注意: アップグレードしたそれぞれのJDBCモジュールに内部プロパティ・セクションがあります。WebLogic Serverでは、下位互換性に対応するため、データ・ソースの管理に内部プロパティが使用されます。また、従来の属性の一部は、JDBCデータ・ソース・ファイルのプロパティ属性でプロパティとして保持されています。内部プロパティを手動で編集しないでください。 |
WebLogic Server 9.0で非推奨になったJDBC機能、メソッド、インタフェース、およびMBeanの詳細は、『リリース・ノート』の非推奨になったJDBCの機能、メソッド、インタフェース、およびMBeanに関する項（http://download.oracle.com/docs/cd/E13222_01/wls/docs90/notes/new.html#deprecated_jdbc_features）を参照してください。
アップグレード・ウィザードは、従来のJDBCデータ・ソース/接続プールの組合せを2つのデータ・ソース・システム・リソース・モジュールに変換します（1つはデータ・ソース用、もう1つは接続プール用）。
既存のデータ・ソースまたはトランザクション・データ・ソースに置き換わるデータ・ソースは、データ・ソース・パラメータを定義し、その接続プールと関連属性を定義するもう1つのデータ・ソースを参照する
既存の接続プールに置き換わるデータ・ソースは、JDBCドライバ・パラメータ、接続プール・パラメータ、およびXAパラメータを定義する
|
注意: ドメインのアップグレードの1つのプロセスとして変換されるデータ・ソースのみが、その接続プールを定義するもう1つのデータ・ソースを参照することができます。それ以外のデータ・ソースは、それぞれ独自のデータベース接続プールを保有しています。 |
アップグレード時にアップグレード・ウィザードにより、データ・ソースのGlobalTransactionsProtocolパラメータが、変換されるデータ・ソースのタイプ（トランザクションまたは非トランザクション）と関連する接続プールで使用されるドライバのタイプに基づいて設定されます。これを表B-1に示します。
表B-1 グローバル・トランザクションのプロトコル・パラメータ設定
| 従来のデータ・ソース・タイプ | ドライバ・タイプ | 2フェーズ・コミットのエミュレーション | GlobalTransactionProtocol |
|---|---|---|---|
|
Txデータ・ソース |
XA |
N/A |
TwoPhaseCommit |
|
Txデータ・ソース |
非XA |
False |
|
|
Txデータ・ソース |
非XA |
True |
|
|
データ・ソース |
非XA |
N/A |
なし |
脚注1 使用する環境によっては、トランザクション処理にEmulateTwoPhaseCommitトランザクション・プロトコルではなくLoggingLastResource（LLR）トランザクション・プロトコルを使用するほうが、パフォーマンス上のメリットがあります。詳細は、『Oracle WebLogic Server JDBCの構成と管理』のロギング・ラスト・リソース・トランザクション・オプションに関する項を参照してください。
アップグレード・ウィザードは、マルチプールを、データ・ソース間のロード・バランシングとフェイルオーバーを実現するデータ・ソース・オブジェクトのもう1つのインスタンスであるマルチ・データ・ソースに変換します。
データ・ソース・ファクトリは、WebLogic Server 9.0より非推奨となっており、下位互換性の維持だけを目的として含まれています。データ・ソース・ファクトリの変換は不要です。
以降の節では、JDBCサポートの変更点について説明します。
新しいJDBC機能の詳細は、『Oracle WebLogic Serverの新機能』のJDBCに関する項を参照してください。
10.3以降のWebLogic Serverは、JDBC 4.0仕様に準拠しています。ただし、次の拡張と例外を含みます。
サーバー側では、SQLXMLが完全にサポートされています。RMIクライアント側では、SQLXMLを部分的にサポートしています。クライアント側で、API getSourceとsetResultを使用することはできません。
WebLogic Server JDBCでは、標準のラッパー・パターン機能がサポートされており、サーバー側の機能を拡張します。JDBC標準では、インタフェースにラッパー・オペレーションのサポートが必要になります。WebLogic Serverでは、サーバー側の具象クラスとインタフェースの両方でラッパー・オペレーションがサポートされます。
WebLogic Serverでは、次のようにステートメント・プール管理が拡張されます。
Statementインタフェースの場合:
isPoolable()呼出しは常にfalseを返します。
setPoolable()呼出しはプール可能状態を変更しません。
PreparedStatementおよびCallableStatementインタフェースの場合:
isPoolable()呼出しは現在のプール可能状態を返します。デフォルト値はtrueです。
setPoolable()呼出しはプール可能状態を変更します。
PreparedStatementまたはCallableStatementインタフェースの場合、close()メソッドを呼び出すと、次のことが起こります:
現在のプール可能状態がfalseの場合、PreparedStatementまたはCallableStatementが閉じられます。
現在のプール可能状態がtrueの場合、PreparedStatementまたはCallableStatementがステートメント・キャッシュに戻ります。
更新されたサード・パーティJDBCドライバ:
Oracle Thin Driverが10gから11gに更新された。
PointBaseデータベース・サーバーとドライバが5.1から5.7に更新された。
次のJDBCドライバは非推奨となりました。
Oracle用のWebLogicタイプ4 JDBCドライバ
このドライバは、WebLogic Server 10.3で非推奨になりました。WebLogic Serverの次のリリースでは削除される予定です。この非推奨のドライバのかわりに、WebLogic Serverにも付属しているOracle Thin Driverを使用してください。Oracle Thin Driverの詳細は、『Oracle WebLogic Serverタイプ4 JDBCドライバ』のWebLogic Serverでのサード・パーティJDBCドライバの使い方に関する項を参照してください。
Sybase Jconnect 5.5および6.0ドライバ。これらのドライバは、サンプル・コードのデフォルト・インストールに関するOracleセキュリティ・ポリシーに従ってWebLogic Server 10.3.3から削除されました。これらのドライバはSybaseからダウンロードできます。また、WebLogic Serverに付属しているOracleブランドのSybase用JDBCドライバを使用することもできます。
WebLogic Serverに付属しているWebLogic タイプ4 JDBCドライバは、DataDirectから提供されています。10.3においてDataDirectバージョン3.7に変更されました。これらのドライバの変更やJDBC 4.0のサポートの詳細は、WebLogic Server 10.3の『リリース・ノート』の「更新されたWebLogic タイプ4 JDBCドライバ」を参照してください。
WebLogic Server 10.3.3では、Oracle 11gおよび11g RAC（Real Application Clusters）がサポートされます。このリリースでは、データ・ソースおよびマルチ・データ・ソースをOracle RACノード上で実行されるサービスに接続するためのサポートも追加されました。
『Oracle WebLogic Server JDBCの構成と管理』のWebLogic ServerでのOracle RACの使い方に関する項を参照してください。
JDBCサブシステムでは、集中管理されたデバッグへのアクセスおよびロギングを行うために、システム全体を対象とした新しいWebLogic診断サービスを使用します。
『Oracle WebLogic Server診断フレームワーク・コンソール拡張の使い方』を参照してください。
WebLogic Server 10.3.3には次の機能が追加されています。
バルク・ロード - 大量のデータをデータベースにできるだけ短時間で挿入するように、現在の方法を改善および拡張します。
ステートメント・プールの凍結および解凍 - ステートメント・プールの状態を凍結できます。いったん凍結すると、接続が閉じるか、アプリケーションによってステートメント・プールの状態が解凍されるまで、ステートメント・プール内の重要なステートメントがプールに残り、置換されません。
新しいJDBC機能の詳細は、『Oracle WebLogic Serverの新機能』を参照してください。
JMSの次の変更に注意してください。
WebLogic Server 9.0からJMS構成はモジュールとして格納されています。これは、新しいweblogic-jmsmd.xsdスキーマに準拠するXMLドキュメントで定義されます。JMSリソースのモジュール式デプロイメントにより、アプリケーションとJMS構成を別の環境にプロモートできます。たとえば、アプリケーションとそれに必要なJMS構成を、EARファイルを開くことなく、またJMSを手動で再構成することなく、テスト環境から本番環境にプロモートできます。
詳細については、次を参照してください:
WebLogic JMSの構成と管理ガイドのこのリリースでのJMSの新機能と変更点に関する項（WebLogic Server 9.0版はhttp://download.oracle.com/docs/cd/E13222_01/wls/docs90/jms_admin/intro.html#WhatsNewJMS）
『Oracle WebLogic Server JMSの構成と管理』のJMSリソースの構成に関する項
『Oracle WebLogic Serverへのアプリケーションのデプロイ』のJDBC、JMS、およびWLDFアプリケーション・モジュールのデプロイに関する項
WebLogicアップグレード・ウィザードは、9.0より前のバージョンのJMSリソースを、ドメインのconfig\jmsディレクトリにコピーされるinterop-jms.xmlという名前のJMS Interopモジュール・ファイルに自動的に変換します。詳細は、『Oracle WebLogic Server JMSの構成と管理』のJMS Interopモジュールに関する項を参照してください。
JMS構成は次のように変更されています。
新しいJMSリソースを生成するとき、JMSモジュールですべての属性を定義する必要があります（つまり、9.0より前のバージョンの構成ファイルを使用しません）。
「永続ダウングレードを許可」オプションにより、永続ストアが構成されていないJMSサーバーにターゲット指定されている宛先に対して、永続メッセージを送信する場合に、JMSクライアントが例外を取得するかどうかを指定することができます。このオプションは、旧リリースとの下位互換性のために用意されています。
デフォルトでは、このオプションはfalseに設定されており、この場合、ストアが構成されていないJMSサーバーに永続メッセージを送信するときに、クライアントは例外を受け取ります。このオプションをtrueに設定した場合、永続メッセージは非永続メッセージに格下げされますが、送信処理は続行できます。このパラメータは、「ストアを有効化」パラメータが無効化されている場合（つまり、falseに設定されている場合）にのみ有効です。
詳細は、Oracle WebLogic Server MBeanリファレンスのJMSServerBeanのAllowsPersistentDowngradeに関する項を参照してください。
デフォルトで、JMSサーバーの「一時的なテンプレート」属性が作成されます。旧リリースでは、デフォルトのテンプレートは提供されていなかった。JMSサーバーの「一時的なテンプレート」属性を使用して一時的なテンプレートを構成することもできます。
「一時的な宛先をホスト」属性を設定して、一時的な宛先をホストするのにJMSサーバーを使用できるかどうかを指定することができます。旧リリースでは、一時的な宛先をホストするのにJMSサーバーを使用するには、「一時的なテンプレート」を設定する必要がありました。
分散宛先のJMSテンプレートは、WebLogic Server 9.0以降はサポートされず、無視されます。WebLogic Server 9.0以降、この機能は共通分散宛先に置き換えられます。詳細は、Oracle WebLogic ServerのJMSの管理と構成ガイドの共通分散宛先の作成に関する項を参照してください。
JMS接続ファクトリのAllowCloseInOnMessage属性は、デフォルトで有効化されています。詳細は、Oracle WebLogic Server MBeanリファレンスのClientParamsBeanに関する項を参照してください。
DeliveryFailureParamsBeanのgetExpirationLoggingPolicy属性は非推奨となりました。『Oracle WebLogic Server JMSの構成と管理』のメッセージ・ライフ・サイクルのロギングに関する項の説明に従って、メッセージのライフ・サイクル情報をロギングする機能を使用するようアプリケーションを更新することを推奨します。getExpirationLoggingPolicy属性により、アプリケーションに埋め込まれている先頭と末尾のスペースはすべて削除されることに注意する必要があります。
JMSメッセージIDの形式は、WebLogic Server 9.0で変更されています。既存のコンシューマ、プロデューサ、およびサーバーで使用されている9.0より前のバージョンの形式は、引続きサポートされます。たとえば、既存のJMSコンシューマは、新しいJMSプロデューサまたはJMSサーバーから送信されたメッセージであっても、引続き9.0より前のバージョンの形式で確認することができます。
WebLogic Server 9.0以降では、メッセージ負荷のピーク時にJVMヒープ・スペースを解放するメッセージ・ページング機能が、JMSサーバーでは常に有効に設定されています。また、ページ・アウトされたメッセージは、使用しているファイル・システムのディレクトリに格納できるため、管理者は専用のメッセージ・ページング・ストアを作成する必要はありません。ただし、最適なパフォーマンスを維持するには、メッセージのページング先のディレクトリをJMSサーバーの永久ストアが使用する以外のディレクトリに指定する必要があります。
Oracle WebLogic Serverのパフォーマンスおよびチューニング・ガイドのメッセージのページングによるメモリーの解放に関する項を参照してください。
WebLogic Server 10.3.3以降では、次のメッセージング機能が変更されています。
weblogic.jms.extensions.WLMessageインタフェースの次の内部メソッドが、Oracle WebLogic ServerのAPIリファレンス・ガイドから削除されています。
public void setSAFSequenceName(String safSequenceName); public String getSAFSequenceName(); public void setSAFSeqNumber(long seqNumber); public long getSAFSeqNumber();
アプリケーションでこれらの内部メソッドを使用しないでください。内部メソッドは、将来のリリースで予告なしに変更または削除される場合があります。
WebLogicファイル・ストアの動作とチューニング方法は、デフォルト・ファイル・ストアとカスタム・ファイル・ストアについて変更されています。詳細は、「WebLogic永続ストア」を参照してください。
WebLogic Server 10.3.3で提供されるバージョン1.1プラグインには次の新機能が含まれます。
Oracle HTTP ServerのためのApache Plug-inのサポート
単純な名前を使用するための標準暗号化強度のサポート
Oracle SSLツールキットの使用
Oracleセキュリティ・フレームワークの使用
IPv6のサポート
双方向SSLのサポート
これらの機能の詳細は、『Oracle WebLogic Serverの新機能』を参照してください。
スレッド管理にはワーク・マネージャの概念を使用することをお薦めします。実行キューは、WebLogic Server 9.0からデフォルトの方法ではなくなりました。アプリケーション用のルールと制約を定義するには、ワーク・マネージャを定義して、それをWebLogicドメインに対してグローバルに適用するか、特定のアプリケーション・コンポーネントに対して限定的に適用します。詳細は、『Oracle WebLogic Serverサーバー環境の構成』のワーク・マネージャを使用したスケジューリング済作業の最適化に関する項を参照してください。
WebLogic Server 8.1では、処理は複数の実行キュー内で実行されていました。パフォーマンスを向上させるために8.1で実行キューを使用していた場合は、アプリケーション・ドメインのアップグレード後にも実行キューを引続き使用できます。アップグレードしたアプリケーションでユーザー定義実行キューを引続き使用できるようにするために、use81-style-execute-queuesというフラグが用意されています。このフラグを使用すれば実行プールの自己チューニングが無効になり、この下位互換性が確保されます。下位互換性フラグの有効化と、実行キューの構成および監視に関する詳細は、Oracle WebLogic Serverのパフォーマンスおよびチューニング・ガイドのWebLogic 8.1スレッド・プール・モデルを有効にする方法に関する項を参照してください。
以降の節では、JTA機能の変更点について説明します。
WebLogic Server 10.3.1以降では、XAデータ・ソース構成のリソース登録名の動作が変更されました。以前のリリースでは、JTAの登録名はデータ・ソースの名前のみでした。今後は、データ・ソース名とドメインの組合せになります。
詳細は、『Oracle WebLogic Server JTAのプログラミング』のXAResourceのトランザクションへの参加の登録に関する項を参照してください。
ドメイン・レベルのJTA構成オプションはすべて従来の構成ファイルから保持されています。サーバー・レベルでのみ変更があります。WebLogic Server 9.0から、トランザクション・マネージャでは、デフォルトのWebLogic永続ストアを使用してトランザクション・ログ・レコードを保存します。アップグレード中、アップグレード・ウィザードは、トランザクション・ログ・レコードをデフォルト・ストアにコピーします。既存のサーバー構成に基づいて設定されるトランザクション・ログ・ファイルの接頭辞は、アップグレード中にトランザクション・ログ・ファイル（{.tlog）を検索する目的にのみ使用され、アップグレード後は保持されません。
ドメイン全体が1つのマシンにある場合、アップグレード・ウィザードは、初期ドメイン・アップグレードにおいて、すべての管理対象サーバーのアップグレードを処理します（トランザクション・ログ・レコードをデフォルト・ストアにコピーします）。管理対象サーバーが複数の異なるマシンにある場合は、「アプリケーション環境のアップグレード」の説明に従って、各管理対象サーバーを個別にアップグレードする必要があります。
次の点に注意する必要があります。
明示的なアップグレードが実行される場合（「ドメインのアップグレード」を参照）、トランザクション・リカバリはアップグレード・プロセス中には実行されませんが、サーバーを起動すると実行されます。
暗黙的なアップグレード（付録F「管理サーバー起動時におけるドメインのアップグレード（暗黙モード）」を参照）が実行される場合、トランザクション・リカバリはサーバー起動プロセスにおいて実行されます。
トランザクション・リカバリ・サービスの移行の準備においてトランザクション・ログ・ファイルをネットワーク・ストレージに配置した場合、アップグレード後、ログ・ファイルの場所は保持されません。このリリースでは、WebLogic Serverトランザクション・マネージャは、デフォルトのWebLogic永続ストアを使用してトランザクション・ログ・ファイルを保存します。デフォルトのWebLogic永続ストアの場所をネットワーク上の場所に移動することによっても、同じ結果が得られます。DATファイルを現在のデフォルト・ストアのデフォルトの場所からデフォルト・ストアの新しい場所に手動でコピーする必要があることに注意してください。
トランザクションが複数のドメインにまたがる場合は、ドメイン間トランザクションが可能なようにドメインを構成する必要があります。詳細は、『Oracle WebLogic Server JTAのプログラミング』のドメイン間トランザクションに対するドメインの構成に関する項を参照してください。
このリリースでは、EJB 3.0アプリケーションでOracle TopLinkの機能を活用できます。Oracle TopLinkは、高度なオブジェクト永続性およびオブジェクト変換フレームワークであり、開発と保守にかかる労力を削減して、エンタープライズ・アプリケーションの機能性を高める開発ツールと実行時機能を提供します。詳細については、『Oracle Fusion Middleware Developer's Guide for Oracle TopLink』を参照してください。
|
注意: Oracle Kodoは、WebLogic Server 10.3.1において非推奨となりました。 |
WebLogic Server 10.3.1では、BEAホーム・ディレクトリがMiddlewareホームに変更されました。このディレクトリのデフォルト・パスは<drive:>Oracle/Middlewareです。この変更がWebLogic Serverに及ぼす影響は次のとおりです。
10.3.1の複数のWebLogicスクリプトに、Middlewareホームを表すための新しい環境変数MW_HOMEが導入されています。この変数が設定されているディレクトリは通常はBEA_HOMEと同じで、これまでどおりWebLogic Serverスクリプトで使用できます。
インストール時のデフォルトでは、WebLogic Serverのインストール・ディレクトリのルートとして<drive:>Oracle/Middlewareが選択されます。ただし、既存のWebLogic Serverが検出された場合は、デフォルトでそのインストール・ディレクトリが選択されます。
現在、WebLogic Server 10.3.1のドキュメントでは、BEAホームではなくMiddlewareホームという用語を使用します。ただし、この変更は用語のみに適用されます。WebLogicソフトウェア、カスタム・ドメインまたはアプリケーションの移動や、それらの場所を表す既存の環境変数の変更は必要ありません。
この変更によって、マシン上の既存のWebLogic Serverインストール、カスタム・ドメイン、アプリケーションまたはスクリプトが影響を受けることはありません。従来どおりBEA_HOME環境変数を使用し続けることができます。
次の節では、セキュリティ機能に関する変更点について説明します。
WebLogic Server 10.3.3では、Weblogic ServerのCerticom SSL実装がJava Secure Socket Extension（JSSE）ベースのSSL実装に置き換えられています。JSSEは、SSLおよびTLS用のJava標準フレームワークで、ブロッキングIO API、ノンブロッキングIO API、および複数の信頼性のあるCAを含む参照実装が含まれています。
次の点にも注意してください。
Certicom SSL実装のサポートはWebLogic Server 10.3.3で非推奨になり、今後削除されます。このため、このリリースのWebLogic Serverでは、RSA Cert-Jバージョン2.1.1およびCrypto-Jバージョン3.5と同様に、Certicom SSLPlus Javaバージョン4.0 SSLの実装も引き続きサポートされます。
SSLMBeanは、JSSEアダプタを有効化または無効化する機能など追加のSSL構成機能をサポートするようにこのリリースで変更されています。
JSSE SSL実装がWebLogicシステム・プロパティを扱う方法の相違点の一覧は、『Oracle WebLogic Serverの保護』のJSSE SSL実装とCerticom SSL実装のシステム・プロパティの相違に関する項を参照してください。
WebLogic ServerでのSSLサポートの詳細は、『Oracle WebLogic Serverセキュリティの理解』のSecure Sockets Layer（SSL）に関する項を参照してください。
WebLogic Server 10.3.3には、スレッド・セーフなデプロイ可能認可プロバイダおよびロール・マッピング・プロバイダのデプロイメント・パフォーマンス拡張が含まれます。Weblogic Server 10.3.3以降ではデフォルトで、アプリケーションおよびモジュールのデプロイメント中にセキュリティ・ポリシーおよびロールに対してスレッド・セーフな並列変更を実行できます。このため、セキュリティ・レルムに構成されているデプロイ可能な認可プロバイダおよびロール・マッピング・プロバイダでは、並列呼出しがサポートされている必要があります。WebLogicのデプロイ可能なXACML認可プロバイダおよびロール・マッピング・プロバイダは、この要件を満たしています。
ただし、カスタムのデプロイ可能な認可プロバイダまたはロール・マッピング・プロバイダで並列呼出しがサポートされていない場合は、セキュリティ・ポリシーとロールの並列変更を無効にし、かわりに同期メカニズムを強制的に使用する必要があります。この場合、各アプリケーションとモジュールはキューに入り、順番にデプロイされます。この同期強制メカニズムは、管理コンソールおよびRealmMBeanのDeployableProviderSynchronizationEnabled属性とDeployableProviderSynchronizationTimeout属性から有効にできます。
詳細は、『Oracle WebLogic Serverの保護』のデプロイ時のセキュリティ・ポリシーとロール変更での同期の有効化に関する項を参照してください。
Windows NT認証プロバイダは、WebLogic Server 10.0以降では非推奨となっています。かわりに、それ以外のサポート対象の1つまたは複数の認証プロバイダを使用してください。
WebLogic Server 9.1には、XACML認可プロバイダおよびXACMLロール・マッピング・プロバイダという2つの新しいセキュリティ・プロバイダが含まれています。WebLogic Serverの以前のリリースでは、独自のセキュリティ・ポリシー言語に基づいた認可プロバイダとロール・マッピング・プロバイダを使用していました。これらのXACMLセキュリティ・プロバイダでは、OASISの標準規格XACML（eXtensible Access Control Markup Language）2.0をサポートしています。これらのプロバイダでは、標準のXACML 2.0関数、属性、スキーマ要素で表現されたポリシーを、インポート、エクスポート、永続化および実行できます。
WebLogic Server 9.1以降を使用して作成したWebLogicドメインには、XACMLプロバイダがデフォルトで含まれています。これら新しいXACMLプロバイダは、WebLogic認可プロバイダ（DefaultAuthorizer）およびWebLogicロール・マッピング・プロバイダ（DefaultRoleMapper）で作成したポリシーやロールに対して完全な互換性があります。既存のWebLogicドメインを10.3.3にアップグレードして、現在指定されている認可プロバイダおよびロール・マッピング・プロバイダ（サード・パーティ・パートナのプロバイダ、オリジナルのWebLogic認可プロバイダおよびロール・マッピング・プロバイダなど）を引続き使用できます。WebLogic Server独自のプロバイダを使用している既存ドメインを、必要に応じてXACMLプロバイダに移行することもできます（既存ポリシーのバルク・インポートも含む）。詳細は、『Oracle WebLogic Serverインフォメーション・ロードマップ』のセキュリティに関する項を参照してください。
WebLogic Server 9.2では、SAML 1.1をサポートするため、SAML資格マッピング・プロバイダおよびSAML IDアサーション・プロバイダの新バージョンが追加されました。SAML資格マッピングV1プロバイダおよびSAML IDアサーションV1プロバイダは非推奨となったため、SAML資格マッピング・プロバイダおよびSAML IDアサーション・プロバイダの各V2バージョンを使用してください。
各プロバイダのバージョン番号は加算されてV2になっていますが、新しいSAMLセキュリティ・プロバイダにも、V1プロバイダと同じSAML 1.1標準が実装されています。
|
注意: Webシングル・サインオンに関して、この節で説明しているSAML 1.1プロバイダは、SAML 2.0サービスが構成されているWebLogic Serverインスタンスとは互換性がありません。 |
WebLogic Server 10.3では、SAML 2.0をサポートするため、SAML 2.0資格マッピング・プロバイダおよびSAML 2.0 IDアサーション・プロバイダが追加されました。これらの新しいプロバイダはそれぞれ、次を利用する場合にSAML 2.0アサーションの生成および消費に使用することができます。
SAML 2.0 Webシングル・サインオン（SSO）プロファイル
WS-Security SAMLトークン・プロファイル・バージョン1.1
SAML 2.0 Web SSOでは、SAML 2.0資格マッピング・プロバイダで生成されるアサーションを消費できるのは、SAML 2.0 IDアサーション・プロバイダのみです。これらはSAML 1.1アサーションと互換性がありません。
SAML Token Profile 1.1は、リリース10.3のWebLogic Server Webサービスからサポートされるようになりました。この機能は、SAML 2.0とSAML 1.1アサーションをサポートし、SAML Token Profile 1.0と下位互換性があります。SAMLトークンは、WS-SecurityPolicyアサーションを適切に使用することでWebサービスで構成されます。
|
注意: SAML Token Profile 1.1はWS-SecurityPolicyを通じてのみサポートされます。以前の「WebLogic Server 9.2セキュリティ・ポリシー」では、SAML Token Profile 1.0/SAML 1.1のみがサポートされます。 |
Oracle Internet Directory認証プロバイダとOracle Virtual Directory認証プロバイダという2つの新しいLDAP認証プロバイダがWebLogic Serverに追加されました。これらの認証プロバイダは、Oracle Internet Directory LDAPサーバーとOracle Virtual Directory LDAPサーバーにユーザーとグループを格納したり、両サーバーからユーザーとグループを読み取ることができます。
これらの新しいセキュリティ・プロバイダの構成と使用の詳細は、『Oracle WebLogic Serverの保護』のLDAP認証プロバイダの構成に関する項を参照してください。
WebLogic Server 10.3では、次のセキュリティ・プロバイダで使用されるデータ・ストアとして、外部RDBMSを使用できるようになりました。
XACML認可プロバイダ
XACMLロール・マッピング・プロバイダ
SAML 1.1の次のプロバイダ
SAML IDアサーション・プロバイダV2
SAML資格マッピング・プロバイダV2
SAML 2.0の次のプロバイダ
SAML 2.0 IDアサーション・プロバイダ
SAML 2.0資格マッピング・プロバイダ
WebLogic資格マッピング・プロバイダ
PKI資格マッピング・プロバイダ
証明書レジストリ
このデータストアはRDBMSセキュリティ・ストアと呼ばれ、クラスタ内など、ドメイン内に複数のWebLogic Serverインスタンスがある環境でSAML 2.0サービスを使用する際に使用することをお薦めします。ドメイン内にRDBMSセキュリティ・ストアが構成されている場合、セキュリティ・レルム内に作成されている上記のいずれかのセキュリティ・プロバイダのインスタンスは、自動的にRDBMSセキュリティ・ストアのみをデータストアとして使用し、組込みLDAPサーバーは使用しません。ドメイン内に構成されている上記のリスト以外のWebLogicセキュリティ・プロバイダは、それぞれのデフォルト・ストアを使用します。たとえば、WebLogic認証プロバイダは組込みLDAPサーバーを使用します。
RDBMSセキュリティ・ストアを使用するには、まず、ドメインを作成して外部RDBMSサーバーを構成します。ドメインを起動する前に、RDBMSセキュリティ・ストアで必要になる表をデータストア内に作成します。WebLogic Serverインストール・ディレクトリには、サポート対象のデータベースごとに、これらの表を作成する一連のSQLスクリプトが含まれています。
RDBMSセキュリティ・ストアを使用したいドメインが作成済であっても、新しいドメインを作成し、そのドメインに既存のセキュリティ・レルムを移行してください。既存のドメインにはRDBMSセキュリティ・ストアを組み込まないでください。詳細は、『Oracle WebLogic Serverの保護』のRDBMSセキュリティ・ストアの管理に関する項を参照してください。
パスワード検証プロバイダは、WebLogic Server 10.3で追加されました。次のいずれかの認証プロバイダで構成し、構成可能なパスワードの構成ルール・セットを適用できます。
WebLogic認証プロバイダ
SQL認証プロバイダ
LDAP認証プロバイダ
Active Directory認証プロバイダ
iPlanet認証プロバイダ
Novell認証プロバイダ
Open LDAP認証プロバイダ
パスワード検証プロバイダで構成されている認証プロバイダを使用してパスワードを作成または変更する場合、パスワードは構成ルール・セットと照合されて自動的に検証されます。パスワード構成ルールは構成可能であり、最小パスワード長、必要な英数字の最小文字数、必要な英数字以外の文字数などを制御することができます。
表B-2に、WebLogic Server 9.0におけるセキュリティMBeanの変更点を示します。
表B-2 WebLogic Server 9.0におけるセキュリティMBeanの変更点
| セキュリティMBeanのタイプ | 説明 |
|---|---|
|
すべてのセキュリティMBean |
WebLogic Server 8.1では、セキュリティMBean属性を更新すると、値はセキュリティ構成と管理階層ではただちに有効になり、セキュリティ実行時階層ではサーバーを再起動すると有効になりました。 WebLogic Server 9.0からは、セキュリティMBean属性の変更が構成、管理、および実行時階層でただちに有効になるか、サーバーを再起動すると有効になるかについては、この属性を動的な属性として設定するか動的でない属性として設定するかによって制御されます。詳細については、「動的構成管理」を参照してください。 |
|
|
セキュリティ・プロバイダMBeansの場合（のみ）
|
|
すべてのカスタム・セキュリティ・プロバイダMBean |
|
権限のないアクセスからパスワードなどの重要なデータを保護するために、構成MBeanのいくつかの属性は暗号化されます。属性の値は、ドメインの構成ファイルに暗号化された文字列として保持されます。メモリー内の値が暗号化されたバイト配列として保存されるため、パスワードがメモリーから盗用されるリスクが軽減され、セキュリティがさらに強化されます。
9.0より前のリリースでは、クリア・テキスト形式または暗号化形式で、パスワードなどの暗号化する属性をconfig.xmlファイルで指定することができました。この場合、WebLogic Serverは、次に起動され、そのファイルに書き込むときに情報を暗号化します。
WebLogic Server 9.0から、本番モードのときは、パスワードなどの暗号化する属性は構成ファイルで暗号化されなければなりません。開発モードのときは、パスワードなどの暗号化する属性はクリア・テキスト形式または暗号化形式のどちらでもかまいません。
次のように、weblogic.security.Encryptコマンド・ライン・ユーティリティを使用してパスワードを暗号化することができます。
java weblogic.security.Encrypt
ここで、パスワードを入力するよう求められます。パスワードを入力すると、暗号化されたバージョンが返されます。次に、暗号化されたパスワードを適切なファイルにコピーします。
このユーティリティの対象は、構成ファイルのパスワードだけではありません。これは、記述子ファイル（JDBCまたはJMS記述子など）およびデプロイメント・プランでパスワードを暗号化する場合にも使用できます。詳細は、Oracle WebLogic Serverのコマンド・リファレンスのencryptに関する項を参照してください。
WebLogic Server 10.3.1のインスタンスがHTTPリクエストに応答するとき、HTTPレスポンス・ヘッダーにはデフォルトで、WebLogic Serverのサーバー名およびバージョン番号は含まれません。この動作は、WebLogic Server 9.0より前のリリースとは異なります。
HTTPリクエストに応答するときにサーバー名とバージョン番号をHTTPレスポンス・ヘッダーに含めるには、管理コンソールでWebLogic Serverインスタンスの「サーバー・ヘッダーの送信」属性を有効にします。この属性は、「サーバー」→「サーバー名」→プロトコル→「HTTP」タブの詳細オプション・セクションにあります。この機能を有効にすると、攻撃者がWebLogic Serverの特定のバージョンの脆弱性についての知識がある場合、これによりセキュリティ・リスクが発生する可能性があります。
セキュリティを確保する方法の詳細は、『Oracle WebLogic Server本番環境の保護』の本番環境の保護に関する項を参照してください。
9.0より前のリリースのWebLogic Serverでは、MBeanHomeへの匿名アクセスがデフォルトで可能でした。WebLogic Server 9.0以降では、セキュリティが強化されているため、MBeanHomeへの匿名アクセスはできなくなりました。
これは推奨されませんが、サーバーを起動するときに次のフラグを指定することにより、匿名アクセスを再び有効にすることができます。
-Dweblogic.management.anonymousAdminLookupEnabled
WebLogic Server 9.0から、Webサービスにおけるメッセージ・レベルのセキュリティが強化され、標準ベースのWeb Services Policy Framework（WS-Policy）を使用するようになりました。WS-Policyでは、XML Webサービス・ベースのシステム内にあるエンティティについての機能、要件、一般的な特性を表現する、柔軟で拡張性のある文法を使用できます。WS-Policyの詳細は、『Webサービスのためのセキュリティおよび管理者ガイド』のWS-SecurityPolicy 1.2ポリシー・ファイルの使用に関する項を参照してください。
8.1における実装は、Web Services Security（WSS）標準のOASISによる実装がベースとなっていました。この実装は9.0以降でも下位互換性のためにサポートされていますが、非推奨となっています。詳細については、http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wssを参照してください。
WebLogic Server 10.3.3以降では、WebLogic SCAで次の新機能がサポートされています。
Webサービス・バインドでの拡張データ・バインドのサポート
TopLink/EclipseLink JAXBバインドでのSOAP添付。SOAP Message Transmission Optimization Mechanism（MTOM）とSOAP Messages with Attachments（SwA）の両方がサポートされます。
TopLink/EclipseLink JAXBバインドでのJavaコレクション・オブジェクト。
EJBサービス・バインドのディスパッチ・ポリシー
WebLogic SCAの詳細は、『Oracle WebLogic Server WebLogic SCAアプリケーションの開発』を参照してください。
WebLogic Server 8.1 Webサービスは10.3.3でも実行できますが、8.1 Webサービスの実行時エンジンは9.0以降では非推奨となっています。
Webサービスを9.2から10.0へ、または10.0から10.3または10.3.3へアップグレードする必要はありません。
WebLogic Server 7.0 Webサービスは、10.3.3で実行するには、少なくとも8.1にアップグレードする必要があります。詳細は、WebLogic Webサービスのプログラミング・ガイドのWebLogic Webサービスのアップグレードに関する項（http://download.oracle.com/docs/cd/E13222_01/wls/docs81/webserv/migrate.html）を参照してください。
8.1にアップグレードされた7.0 Webサービスを含む、すべての8.1 Webサービスを10.3.3にアップグレードすることをお薦めします。
既存の8.1 Webサービスの10.3.3へのアップグレードについては、『Oracle WebLogic Server JAX-RPC Webサービス・スタート・ガイド』のWebLogic Webサービスの旧リリースから10gリリース3へのアップグレードに関する項を参照してください。
WebLogic Server 10.3.3には次の新機能が追加されました。
Webサービスの原子性トランザクションのサポート。WebLogic Webサービスは、WebSphere、JBoss、Microsoft .NETなどの外部トランザクション処理システムとの相互運用性を実現します。
クラスタ環境でのWebサービスの拡張サポート
Webサービスおよびクライアントの監視の拡張
Fusion Middleware Controlを使用するWebLogic WebサービスへのOracle WSMポリシーの添付
リレーショナル・データベースにアクセスするための宣言Webサービス・ソリューションのEclipseLink DBWSサポート
メソッドレベルのポリシー添付動作の変更: WebLogic Server 10.3.3より前のリリースでは、管理コンソールを使用してWebサービスのメソッドにポリシーを添付すると、そのポリシーはモジュール内のすべてのWebサービスで同じ名前を持つメソッドにも添付されていた。WebLogic Server 10.3.3では、ポリシーは適切なWebサービスのメソッドのみに添付されます。
OWSMポリシー名からのpolicy:接頭辞の削除
Webサービスの「WSDL」タブの削除。WebLogic Server 10.3.3よりも前には、「構成」→「WSDL」タブを選択すると、現在のWebサービスのWSDLを表示できました。「WSDL」タブはWebLogic Server 10.3.3以降では削除されています。
新しい開発ツール。Oracle JDeveloperおよびOracle Enterprise Pack for Eclipse（OEPE）。
Oracle Enterprise Manager Fusion Middleware Controlとの統合
Oracle WebLogic Services Manager（WSM）セキュリティ・ポリシーのサポート
JAX-WSでのWS-SecureConversation 1.3、およびJAX-WSでのWS-SecurityによるMTOMのサポート
詳細は、『Oracle WebLogic Serverの新機能』のWebサービスに関する項を参照してください。
次の節では、WebLogic Server 10.3.3におけるWebアプリケーション、JSP、およびサーブレットの重要な互換性に関する情報について説明します。
WebLogic Server 10.3.3以降では、WebLogic ServerにデプロイされているアプリケーションでのCoherenceデータ・キャッシュの使用が容易になり、セッション管理用のCoherence*WebとTopLink Gridをobject-to-relational永続フレームワークとしてシームレスに取り込めるようになりました。これらの機能の総称がActiveCacheです。
ActiveCacheでは、レプリケートおよび分散されたデータ管理とキャッシングのサービスが提供されており、このサービスを使用することで、アプリケーションのオブジェクトとデータをCoherenceクラスタ内のすべてのサーバーに対して利用可能にすることができます。
詳細は、ActiveCacheの使用方法に関する項を参照してください。
WebLogic Server10.3.3でクラス・キャッシュを有効にできるようになりました。クラス・キャッシュを使用する利点を次に示します。
サーバーの起動時間が短縮されます。
パッケージ・レベルの索引により、すべてのクラスとリソースの検索時間が短縮されます。
クラス・キャッシュが開発モードでサポートされるのは、startWebLogicスクリプトを使用してサーバーを起動したときです。クラス・キャッシュはデフォルトでは無効になっており、本番モードではサポートされません。起動時間の短縮の程度は様々なJREベンダーによって異なります。詳細は、『Oracle WebLogic Serverアプリケーションの開発』のクラス・キャッシュの構成に関する項を参照してください。
WebLogic Server 10.3.3から非推奨またはサポート対象外となったWebアプリケーション機能については、『Oracle Fusion Middleware Oracle WebLogic Serverの新機能』の次のトピックを参照してください。
非推奨になった機能（WebLogic Server 10.3.3）
非推奨になった機能（WebLogic Server 10.3）
WebLogic Serverバージョン9.2以降では、対象リソースにおいてアクセス制御が有効になっていない場合でも、HTTP BASIC認証を使用するクライアント・リクエストはWebLogic Server認証を通過しなければなりません。
この動作は、セキュリティ構成MBeanフラグ"enforce-valid-basic-auth-credentials"で指定します。（DomainMBeanを使用すると、そのドメインの新しいセキュリティ構成MBeanを取得できます。）このフラグは、非セキュアなリソースへのアクセスにおいて、無効なHTTP BASIC認証資格によるリクエストを許可するかどうかを指定します。
|
注意: セキュリティ構成MBeanは、ドメイン全体のセキュリティ構成情報を提供します。enforce-valid-basic-auth-credentialsフラグは、ドメイン全体に影響します。 |
enforce-valid-basic-auth-credentialsフラグはデフォルトでtrueに設定されており、WebLogic Server認証が実行されます。認証に失敗すると、リクエストは拒否されます。したがって、ユーザーおよびパスワードの情報がWebLogic Serverに保持されている必要があります。
詳細は、『Oracle WebLogic Serverセキュリティのプログラミング』のリソースが非セキュアな場合のBASIC認証に関する項を参照してください。
WebLogic Server 10.3.3では、この節および『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のjsp-descriptorに関する項で説明されているように、WebLogic Server 9.2以前のバージョンに対する下位互換性がjsp-descriptor要素内のbackward-compatible要素を通じてサポートされます。
JSP 2.1はWebLogic Server 10.0からサポートされています。Webアプリケーションのバージョン（バージョン2.4または2.5）とbackward-compatible要素の設定に応じて、WebLogic Server 10.3.3ではJSP 2.0もサポートされます。
バッファの接尾辞の設定およびサーブレット2.5パッケージの暗黙的なインポートについては、『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』の下位互換性フラグに関する項を参照してください。
「下位互換性フラグ」で説明されているように、JSP 2.0はWebLogic Server 9.0以降でサポートされています。JSP 2.0のサポートに応じて、JSPの動作は次のように変更されています。
JSPがセッションに参加していない場合（またはJSPが参加しているセッションが無効な場合）、次のコマンドが実行されると、IllegalStateExceptionがスローされます。
PageContext.getAttribute(name, PageContext.SESSION_SCOPE)
この例外は、このようなエラーが重要な問題でない場合は、捕捉して無視することができます。
JspWriterImplがprintline関数ごとに\nをSystem.getProperty（"line.separator"）に置き換えるようになりました。この置換により、以下に該当するJSPで問題が発生します。
新しい行に表示される複数のpageディレクティブを含みます。例:
<%@ page import="com.foo.bar.*" %> <%@ page import="com.foo.xyz.*" %> ...
XML形式で出力を生成します。
pageディレクティブに続いてXML宣言を生成します。
Windowsシステムからサービスを受けています。この場合、pageディレクティブごとに\r\nが出力されます。
Internet Explorerを使用して表示されます。
Internet Explorerで表示される場合、各pageディレクティブが空の\r\nを出力し、XML宣言（<?xml version="1.0" encoding="iso-8859-1"?>）が新しい行の後ろに表示されます。Internet Explorerは、宣言が検出されず、ページはコンパイルできるが表示できないことを通知するエラー・メッセージを表示します。
JspWriterImplに対する変更により生じた問題を解決するには、次のタスクのどちらかまたは両方を実行します。
ページの最上部でXML宣言を定義します。
次のように、pageディレクティブを1つの宣言にグループ化します。
<%@ page import="com.foo.bar.*, com.foo.baz.*" contentType="text/html" pageEncoding="UTF-8" errorPage="Error.jsp" %>
JSP <param name>タグで実行時の式の値を使用できなくなりました。例:
<jsp:param name="<%= AdminActions.RETURN_LINK %>" value="<%= returnlink %>" />
「表5-1アップグレード・オプションの選択」の「アップグレード・オプションの選択」で説明されているように、ドメインのアップグレード中に「下位互換性フラグを設定しない」アップグレード・オプションを無効にするか、次のようにweblogic.xmlファイルでbackwardCompatibleフラグを有効にすることで、引続きこの機能をサポートすることができます。
<jsp-descriptor> <jsp-param> <param-name>backwardCompatible</param-name> <param-value>true</param-value> </jsp-param> </jsp-descriptor>
Sun Microsystemsのサーブレット2.3仕様（http://java.sun.com/products/servlet/download.html#specsでダウンロード可能）では、マッピングの定義に次の構文を使用します。
/（フォワード・スラッシュ）文字だけが含まれるサーブレット・パス文字列は、アプリケーションのデフォルト・サーブレットを表します。サーブレット・パスは、リクエストURIからコンテキスト・パスを削除したパス（この場合はnull）に解決されます。
1個の*（アスタリスク）で始まる文字列は、拡張子マッピングを指定します。
これらの変更により、次のHttpServletRequestメソッドの動作に変化が生じます。
getPathInfo
getServletPath
動作の変更を説明するために、例として/abc/def.htmlというリクエストがServletAに解決される場合を考えます。
/がServletAにマップされると、servletPath="abc/def.html"およびpathInfo=nullになります。
/*がServletAにマップされると、servletPath=""およびpathInfo="abc/def.html"になります。
確実にnullでないパス情報が返されるようにするには、/（フォワード・スラッシュ）のサーブレット・マッピング文字列が出現するすべての箇所を/*に置換します。
WebLogic Server 9.0からは、XMLのサポートが次のように変更されています。
デフォルトのXMLパーサーは、Sun Java 2 JDK付属のXMLパーサーになりました。以前のデフォルトXMLパーサー、Apache Xercesパーサー（weblogic.apache.xerces.*）は9.0より非推奨となりました。
デフォルトで使用されるXMLパーサーを管理コンソールで修正することができます。XMLパーサーの構成については、Oracle WebLogic ServerのXMLプログラミング・ガイドのWebLogic Serverバージョン8.1と9.1のデフォルト・パーサーの違いに関する項を参照してください。
WebLogic Server 9.0からは、Java Community Processの標準仕様であるStreaming API for XML（StAX）がサポートされています。これにより、XMLドキュメントを簡単に、直感的に解析および生成できます。また、StAXでは、9.0から非推奨となっているWebLogic XML Streaming APIよりも的確にXML解析を行うことができます。StAXの使用については、Oracle WebLogic ServerのXMLプログラミング・ガイドのStreaming API for XML（StAX）の使い方に関する項を参照してください。
所定の事前準備設定を行うことなしにsetAttributeメソッドとgetAttributeメソッドを使用してサーブレット内からXMLドキュメントを解析することができなくなりました。具体的には、9.0以降、weblogic.servlet.XMLParsingHelperと呼ばれるWebLogic Serverのサーブレット・フィルタ（デフォルトではすべてのWebLogic Serverインスタンスにデプロイされる）をWebアプリケーションの一部として構成する必要があります。詳細は、Oracle WebLogic ServerのXMLプログラミング・ガイドのサーブレットでのXMLドキュメントの解析に関する項を参照してください。
WebLogic Server 9.0から、XMLBean実装は内部BEAライブラリ（com.bea.xml）からApacheオープン・ソース・プロジェクト（org.apache.xmlbeans）に移動されています。
WebLogic Server 8.1のアプリケーションでXMLBeansを使用していた場合は、次の手順を実行する必要があります。
XMLBeansにより使用されているパッケージ名をcom.bea.xmlからorg.apache.xmlbeansに更新します。
XMLBeanスキーマを再コンパイルして、スキーマ・メタデータ・ファイル（.xsb）と生成されているコードを更新します。
WebLogic Server 9.0以降のXMLQuery（XQuery）実装は、次の仕様に準拠しています。
「XQuery 1.0 and XPath 2.0 Data Model - W3C Working Draft 23 July 2004」（http://www.w3.org/TR/2004/WD-xpath-datamodel-20040723）
「XQuery 1.0: An XML Query Language - W3C Working Draft 23 July 2004」（http://www.w3.org/TR/2004/WD-xquery-20040723）
WebLogic Server 8.1では、XQuery実装は「XQuery 1.0 and XPath 2.0 Functions and Operators - W3C Working Draft 16 August 2002」（http://www.w3.org/TR/2002/WD-xquery-operators-20020816）に準拠していました。この2002 XQuery実装は、9.0以降では非推奨となっています。
ほとんどの場合、9.0より前のバージョンのコードに含まれる簡単なXQueryおよびXPathは、10.0でも同じように動作します。XQueryおよびXPathの処理が意図したとおりの結果になるように、次のいずれかの方法で、XMLObject.selectPath()およびXMLObject.execQuery()のメソッド呼出しを必要に応じて確認および変更してください。
8.1と同様の動作を確実にするには、既存のメソッド呼出しを変更し、新しい2004 XQueryエンジンではなく2002 XQueryエンジンを使用することを指定する新しいパラメータを含めるようにします。例:
import org.apache.xmlbeans.impl.store.Path;
XmlObject xo = ?
xo.selectPath(".//c", (new XmlOptions()).put(Path._forceXqr12002ForXpathXQuery));
|
注意: 2002 XQueryエンジンは、WebLogic Server 9.0以降では非推奨ですが、下位互換性のために残されています。このパラメータを指定した場合のみ2002 XQueryエンジンが使用され、それ以外の場合は2004 XQueryエンジンがデフォルトで使用されます。 |
2004 XQueryエンジンへの適合を確実にするには、9.0より前のスクリプトを確認し、メソッド呼出しに渡されているXQuery文字列の構文やセマンティクスに関して変更が必要になると考えられる点をすべて特定して、メソッドに適切な変更を加えます。
9.0から、XMLCursor.moveXML()の動作が変更されています。8.1では、移動されたフラグメント内にあったカーソルは、元のドキュメントに残ります。9.0以降では、カーソルはフラグメントと共に移動します。
MBeanの階層構造に加えられた変更により、9.2より前の構成および管理スクリプト（WLST、wlconfig、weblogic.Admin、Antなど）が10.3.3で動作する保証はなくなりました。WebLogic Server 10.3.3からの新しい機能を利用するようスクリプトを更新することをお薦めします。MBean階層構造の新機能と変更点の詳細は、次のトピックを参照してください。
WebLogic Server 10.3.3の場合は「WebLogic Serverの新機能」
WebLogic Server 10.3の場合は「WebLogic Serverの新機能」
アプリケーション・インフラストラクチャのアップグレードと非推奨となったスクリプト・ツールの詳細は、「ステップ1: アプリケーション・インフラストラクチャのアップグレード」を参照してください。
この節では、リリース9.0より変更されたWebLogic Server環境におけるデプロイメント記述子の使用方法について説明します。
デプロイメント記述子の検証は、9.0リリース以降のEJBGenツールとejbcツールでは、より厳密に行われるようになりました。たとえば、@ejbgen:relationでcmr-fieldが定義されている場合に、@ejbgen:cmr-fieldというタグの付いたメソッドがBeanクラスになければ、エラーが返されます。
|
注意: ejbcはWebLogic Server 9.0から非推奨となりました。かわりにappcを使用してください。詳細は、『Oracle WebLogic Server Enterprise JavaBeansのプログラミング』のappcリファレンスに関する項を参照してください。 |
9.0より前のバージョンのWebLogic Serverでは、次の構成ファイルからの抜粋が示すように、複数のモジュールを定義するアプリケーションは、META-INF\application.xmlデプロイメント記述子がアプリケーションの一部として定義されているかどうかに関係なく、正常にデプロイされます。
<Application Deployed="true" Name="SessionBeanLifeCycleBean"
Path="C:\bea\weblogic70\tools\deployment\ejb" TwoPhase="false">
<EJBComponent Name="CMFinderTestBean" Targets="myserver" URI="CMFinderTestBean.jar"/>
<EJBComponent Name="SessionBeanLifeCycleBean" Targets="myserver"
URI="SessionBeanLifeCycleBean.jar"/>
</Application>
9.0からは、デプロイされたアプリケーションが複数のモジュールを定義する場合は、META-INF\application.xmlデプロイメント記述子が必要です。このタイプのデプロイメント記述子が提供されなければ、アップグレードは正常に実行されず、次のようなエラー・メッセージが表示されます。
[J2EE Deployment SPI:260089]Unable to determine type of application at path 'C:\bea\weblogic70\tools\deployment\ejb' and upgrade will not succeed.
ドメインをアップグレードするとき、デプロイされたアプリケーションが適切なJava EEアプリケーション形式に準拠していることを確認してください。たとえば、必要に応じて、アプリケーションがMETA-INF\application.xmlデプロイメント記述子とMETA-INF\weblogic-application.xmlデプロイメント記述子の両方またはどちらかを定義していることを確認してください。
TLOGの詳細は、『Oracle WebLogic Serverアプリケーションの開発』のエンタープライズ・アプリケーションのデプロイメント記述子の要素に関する項を参照してください。
アプリケーションが最新のJava EE仕様およびWebLogic Serverリリースの機能を活用できるよう、アプリケーションをWebLogic Serverの新リリースにアップグレードするときに、デプロイメント記述子をアップグレードすることを推奨します。詳細は、『Oracle WebLogic Serverアプリケーションの開発』の以前のリリースのJ2EEおよびWebLogic Serverのデプロイメント記述子のアップグレードに関する項を参照してください。
アプリケーション・スコープの起動クラスと停止クラスは、WebLogic Server 9.0から非推奨となり、かわりにアプリケーションはアプリケーション・ライフサイクル・イベントに応答するようになりました。ドメイン・レベルのアプリケーション・スコープの起動クラスと停止クラスのかわりにライフサイクル・イベントを使用するようアプリケーション環境を更新することをお薦めします。詳細は、『Oracle WebLogic Serverアプリケーションの開発』のアプリケーション・ライフサイクル・イベントのプログラミングに関する項を参照してください。
以降の節では、管理コンソールに対する変更点について説明します。
WebLogic Server 10.3で管理コンソールの動作を構成するためのオプションが追加され、次のことを実行できるようになりました。
編集セッション中に他のアカウントによって変更されずに、構成を変更できるように、ドメイン構成をロックする
管理コンソール、UDDI、およびUDDIエクスプローラなどの内部アプリケーションを、サーバーの起動時ではなく、必要に応じて（最初のアクセス時に）デプロイするかどうかを指定する
バナー・ツールバー領域に新たに追加された検索機能を利用して、この検索で指定した文字列が名前に含まれるWebLogic Server構成MBeanを検索する
障害が発生したサーバーやサービスを別のサーバーへ自動的に移行する追加機能を利用する
Service Component Architecture（SCA）をデプロイおよび制御する
Springアプリケーションを検査する
詳細については、WebLogic Server 10.3の『リリース・ノート』の「WebLogic Serverの新機能」を参照してください。
WebLogic Serverバージョン9.0の管理コンソールは、WebLogic Portalのフレームワークに基づいて構築されているため、よりオープンで拡張性の高い設計になっています。アーキテクチャが新しくなったため、管理コンソールを拡張する手順も新しくなりました。9.0よりも前のWebLogic Serverのリリース用に構築されたWebLogic Serverコンソールの拡張は、新しいインフラストラクチャでは機能しません。
WebLogic Server 10.3.3では次の機能が追加されました。
サンプルのルック・アンド・フィールが提供されています。サンプルを変更して、WebLogic Server管理コンソールのカスタムのルック・アンド・フィールを作成できます。
オンライン・ヘルプは作成し、console拡張に関連付けることができます。
WebLogic Server管理コンソールの拡張の詳細は、Oracle WebLogic Serverの管理コンソール拡張ガイドを参照してください。
WebLogic Serverバージョン9.2では、コンソール拡張が次のように変更されています。
このリリース以前の管理コンソール拡張機能では、サード・パーティJSPタグ・ライブラリへのパス名を指定することにより、それらのライブラリのインポートが可能であった。たとえば、次のようになります。
<%@ taglib uri="/WEB-INF/beehive-netui-tags-template.tld" prefix="beehive-template" %>
WebLogic Serverインストールからサード・パーティJSPタグ・ライブラリを使用する管理コンソール拡張機能では、10.0より、タグ・ライブラリを指定する定義済みの絶対URIを使用する必要があります。例:
<%@ taglib uri="http://beehive.apache.org/netui/tags-template-1.0" prefix="beehive-template" %>
管理コンソールのweb.xmlファイルが、WebLogic Serverインストール内部のタグ・ライブラリにURIをマップします。このマッピング機能によって、ユーザーがJSPを変更しなくても、タグ・ライブラリのインストール・ディレクトリが認識されます。
古いパス名構文を使用してApache Struts、Apache Beehive、またはJSTLタグ・ライブラリをインポートするすべての管理コンソール拡張機能では、パス名をすべて新しいURIに更新する必要があります。
WebLogic Serverのコンソール拡張機能タグ・ライブラリ（console-html.tld）のURIは変更されていません（/WEB-INF/console-html.tld）。
詳細は、Oracle WebLogic Serverの管理コンソール拡張ガイドのJSPテンプレートとタグ・ライブラリに関する項を参照してください。
規則により、ポータル・インクルード・ファイル（.pinc）はポータル・ブック・ファイル（.book）という名前に変更された。
WebLogic Portalでは、すべての明示的なスケルトンURI参照を、Webアプリケーションを基準として完全修飾する必要があります。ただし、ドキュメントや一部のコンソール拡張例では、これらのスケルトンを基準とした相対参照が使用されていることがあります。次の不適切な例について検討します。
<netuix:singleLevelMenu markupType="Menu" markupName="singleLevelMenu" skeletonUri="singlelevelmenu_children2.jsp"/>
この例を正しく指定するには、次のようにします。
<netuix:singleLevelMenu markupType="Menu" markupName="singleLevelMenu" skeletonUri="/framework/skeletons/default/singlelevelmenu_children2.jsp"/>
このリリースでは、相対スケルトンURI参照を引続き使用できます。ただし、今後のリリースではこれらの相対参照は正しく機能しない可能性があるため、自分で記述したすべてのコンソール拡張は、完全修飾スケルトンURIを使用するように更新する必要があります。
表B-3に、非推奨またはサポート対象外となったリソース・アダプタの構成設定を示します。新機能および変更点については、『Oracle Fusion Middleware Oracle WebLogic Serverの新機能』を参照してください。
表B-3 非推奨またはサポート対象外となったリソース・アダプタの構成設定
| 要素 | WebLogic Server 9.0の時点... |
|---|---|
|
Link-Refメカニズム |
この要素は非推奨となっており、新しいJava EEライブラリ機能に置き換えられています。Java EEライブラリの詳細は、『Oracle WebLogic Serverアプリケーションの開発』の共有Java EEライブラリおよびオプション・パッケージの作成に関する項を参照してください。 Link-Refメカニズムは、J2CA 1.0仕様に準拠して開発されたリソース・アダプタの場合は、このリリースでもサポートされています。1.0リソース・アダプタでのLink-Refメカニズムの使用の詳細は、『Oracle WebLogic Serverリソース・アダプタのプログラミング』の「weblogic-ra.xmlファイルの構成」、（非推奨）Link-Refメカニズムの構成に関する項を参照してください。 |
<shrink-period-minutes> |
この要素は、非推奨となっており、
|
<connection-maxidle-time> |
この要素は、非推奨となっており、
|
<security-principal-map> |
この要素はサポートされなくなりました。セキュリティ・プリンシパル・マップは管理コンソールを使用して構成されます。 weblogic-ra.xmlファイルから |
<connection-cleanup-frequency> |
この要素はサポートされなくなり、デプロイメントにおいて無視されます。 |
<connection-duration-time> |
この要素はサポートされなくなり、デプロイメントにおいて無視されます。 |
WLECは、WebLogic Server 8.1で非推奨となりました。WLECユーザーは、『Oracle WebLogic Server WLECのためのWebLogic Tuxedo Connector移行ガイド』の説明に従って、アプリケーションをWebLogic Tuxedo Connectorに移行する必要があります。
WebLogic Server 10.0では、SNMPAgentMBean MBeanのMibDataRefreshInterval属性とServerStatusCheckIntervalFactor属性は非推奨となったため無視されます。
表B-4の構成フラグは、ドメインをアップグレードするときに下位互換性をサポートするために使用することができます。これらのフラグは、「ドメインのグラフィカル・モードでのアップグレード」で説明されているように、アップグレード中に「下位互換性フラグを設定しない」オプションを選択して無効にしないかぎり、下位互換性をサポートするためデフォルトで設定されます。
表B-4 下位互換性フラグ
| カテゴリ | 下位互換性フラグ | 詳細については、次を参照... |
|---|---|---|
|
セキュリティ |
|
|
|
Webアプリケーション |
|
WebAppContainerMBeanに関する項 |
WebLogic Server 10.3.3の非推奨になった機能に関する情報は、My Oracle Support（https://support.oracle.com/）で入手できます。WebLogic Server 10.3で非推奨になった機能については、『Oracle WebLogic Serverの新機能』の非推奨機能（WebLogic Server 10.3）に関する項を参照してください。
