ナビゲーションをスキップ

WebLogic および AquaLogic 環境のアップグレードのロードマップ

次の節では、アプリケーション環境を以前のリリースから次に示す各リリースにアップグレードするための手順を示します。

注意 : 現在プロダクション環境にデプロイされているアプリケーション環境をアップグレードすることはお勧めしません。開発中またはテスト中のアプリケーション環境をアップグレードし、アップグレードした環境をプロダクション環境にプロモートする前に、標準的な品質保証およびパフォーマンス チューニングを行うことをお勧めします。


 

WebLogic Server 9.1

次の表に、WebLogic Server 9.1 へのアップグレード手順の概要を示します。


アップグレード前の環境

アップグレード先のリリース

WebLogic Server 9.0

手順 1: 次に説明する方法のいずれかによってアプリケーション環境を更新し、WebLogic Server 9.1 インストール先を参照するようにする。

新しい 9.1 ドメインを作成する

ドメインを作成およびカスタマイズするプロセスがすでに自動化されている場合には、この方法が便利。

  1. WebLogic Server 9.1 ソフトウェアをインストールする。
  2. 9.1 で提供されているデフォルトのドメイン テンプレートを使用し、新しいドメインを作成する。

    注意 : WebLogic Server 9.0 から 9.1 へのアップグレードでは、カスタム 9.0 テンプレートを使用して新しい 9.1 ドメインを作成することも可能。

    この手順は、コンフィグレーション ウィザードを使用して実行するか、または WLST などの WebLogic スクリプト ツールで作成した自動化スクリプトを使用して実行できる。

    9.1 ドメイン テンプレートを参照したり、9.1 リリースで提供される新機能を実装したりするために、自動化スクリプトには適宜変更を加える必要がある。

    たとえば、『BEA WebLogic Server 9.1 セキュリティ』で説明されているように、9.1 ではデフォルトのセキュリティ プロバイダが XACML ベースになっている。必要に応じて、WebLogic Server 9.0 デフォルト セキュリティ プロバイダのサポートを追加するか、新しいプロバイダを使用するように適切な変更を加えること。

  3. 既存の WebLogic Server 9.0 アプリケーションを、新しい 9.1 ドメインにデプロイする。

    注意 : 手順 2 でカスタム 9.0 テンプレートを使用した場合、すでに 9.0 アプリケーションがデプロイされていることがある。


既存のドメインを更新する

ドメインの作成が自動化されていない場合、テスト ドメイン内のカスタマイズ情報を維持するには、この方法が便利。

  1. WebLogic Server 9.1 ソフトウェアをインストールする。
  2. ドメイン ディレクトリ、アプリケーション、ドメイン外のアプリケーション データ、およびログ ファイル (必要な場合) など、既存のアプリケーション環境をバックアップする。
  3. WebLogic Server 9.1 のインストール先を参照するようドメインのスクリプト ファイルを更新する。たとえば、BEA_HOMEBEA_JAVA_HOMEJAVA_HOME、および WL_HOME に適切な値を設定する。
  4. CLASSPATH を更新して、不要になったパス情報 (9.1 より前のリリースに適用されるパッチ ファイル情報など) を削除する。

手順 2: 9.0 で開発した Beehive アプリケーションがある場合は、『Beehive Integration in WebLogic Server 9.1』の「Upgrading From 9.0」の説明に従って、それらのアプリケーションをアップグレードする必要がある。

WebLogic Server 6.0、7.1、8.1

アップグレード手順の詳細については、『WebLogic のアプリケーション環境のアップグレード』を参照。



 

AquaLogic Service Bus 2.1

AquaLogic Service Bus 2.0 ドメインを 2.1 にアップグレードするには、次の手順を実行します。


  1. AquaLogic Service Bus Console を使用し、AquaLogic Service Bus Console オンライン ヘルプの「システム管理」の説明に従って、アップグレードする AquaLogic Service Bus 2.0 ドメインのコンフィグレーション データをエクスポートします。

    注意 : 多くの場合、WebLogic Server リソース (JMS リソース、ワーク マネージャ定義など) はエクスポートできません。それらのオブジェクトは、手順 6 の説明に従って新しい AquaLogic Service Bus 2.1 ドメイン内に作成し直す必要があります。
  2. WebLogic Administration Console を使用し、『WebLogic Server のセキュリティ』の「セキュリティ データの移行」の説明に従って、アップグレードする AquaLogic Service Bus 2.0 ドメインのセキュリティ コンフィグレーションをエクスポートします。

    次の表に、セキュリティ コンフィグレーション オブジェクトおよびそれらの格納先であるセキュリティ プロバイダの概要を示します。


    セキュリティ オブジェクト

    セキュリティ プロバイダ

    ユーザ アカウント

    認証プロバイダ

    グループ定義

    認証プロバイダ

    ロール定義

    ロール マッピング プロバイダ

    ユーザ名/パスワード資格マップ エントリ*

    ユーザ名/パスワード資格マッピング プロバイダ

    PKI 資格マップ エントリ*

    PKI 資格マッピング プロバイダ

    * 注意 : ユーザ名/パスワード資格マップは、サービス アカウントにユーザ名とパスワードを割り当てると作成されます。ユーザ名/パスワード資格マップのインポートおよびエクスポートは、ユーザ名/パスワード資格マッピング プロバイダによって管理されます。PKI キーペア資格は、プロキシ サービス アカウントにキーペア資格を割り当てると作成されます。PKI キーペア資格のインポートおよびエクスポートは、PKI 資格マッピング プロバイダによって管理されます。

    前の表に示したセキュリティ コンフィグレーション オブジェクトは、WebLogic Administration Console のセキュリティ [移行] 画面を使用してインポートおよびエクスポートできます。セキュリティ コンフィグレーションのインポートおよびエクスポートは、セキュリティ レルム全体から実行することも (資格マップに関する下の注意を参照)、セキュリティ プロバイダごとに個別に実行することもできます。

    注意 : WebLogic ユーザ名/パスワード資格マッピング プロバイダおよび WebLogic PKI 資格マッピング プロバイダから資格マップをエクスポートする際、資格に対するパスワードは必ずクリア テキスト形式でエクスポートするようにしてください。パスワードの暗号化に使用されるアルゴリズムは WebLogic Server ドメインごとに異なるため、別の WebLogic Server ドメインで使用できるようにするには、パスワードをクリア テキスト形式でエクスポートする必要があります。

    パスワードをクリア テキスト形式でエクスポートするには、WebLogic Administration Console を使用して、該当するセキュリティ プロバイダの [移行] から直接にユーザ名/パスワードおよび PKI 資格をエクスポートし、[エクスポート制約] テキスト ボックスに passwords=cleartext と入力します。詳細については、WebLogic Server Administration Console オンライン ヘルプの「セキュリティ プロバイダからのデータのエクスポート」を参照してください。

    警告 :

    • クリア テキスト形式でエクスポートした資格マップの格納先のディレクトリおよびファイルについては、保護に十分な注意を払ってください。アップグレード プロセスの実行中は、機密データがシステム上でアクセス可能な状態になります。新しい WebLogic Server ドメインの WebLogic 資格マッピング プロバイダに資格マップをインポートすると、パスワードは暗号化されます。アップグレードの完了後は、クリア テキスト形式のパスワードを含んだファイルを安全な方法で破棄することをお勧めします。
    • セキュリティ レルム全体をエクスポートすると、資格マップ内のパスワード情報は暗号化された形式でエクスポートされます。この場合、暗号化されたパスワード情報を含んだ DefaultCredentialMapper.dat および PKICredentialMapper.dat ファイルを 2.1 ドメインにインポートしてはなりません。
  3. インストール ガイド』の説明に従って、AquaLogic Service Bus 2.1 ソフトウェアをインストールします。
  4. 『オフライン コンフィグレーション ツールの使用』の「ドメインの作成および拡張」の説明に従って、新しい AquaLogic Service Bus 2.1 ドメインを作成します。
  5. 必要に応じて、新しいドメインのセキュリティ レルムをコンフィグレーションします。適切なセキュリティ プロバイダ、サーバ キーストア、および SSL を確実にコンフィグレーションする必要があります。詳細については、『BEA WebLogic Server 9.1 セキュリティ』、および『AquaLogic Service Bus Console の使用』の「セキュリティ コンフィグレーション」を参照してください。

    PKI 資格マッパーが必要な場合は、必ずキーストアを新しいドメインにコピーし、それに合わせて PKI 資格マッパーをコンフィグレーションします。

  6. 手順 1 でエクスポートできなかった次の WebLogic Server オブジェクトを作成し直します。
    • JMS リソース (接続ファクトリ、キューおよびトピックなど)
    • ワーク マネージャ定義

    WebLogic Server ドメイン リソースのコンフィグレーションの詳細については、『WebLogic Server および WebLogic Express の紹介』の「WebLogic Server システム管理の概要」を参照してください。

  7. AquaLogic Service Bus WebServiceSecurityMBean トークン ハンドラに関して何らかの設定がカスタマイズされている場合は (UseX509ForIdentity の値など)、カスタマイズ内容を再設定する必要があります。トークン ハンドラのコンフィグレーションは、WebLogic Administration Console または WLST を使用して実行できます。
  8. WebLogic Administration Console を使用し、『WebLogic Server のセキュリティ』の「セキュリティ データの移行」の説明に従って、2.0 のセキュリティ情報 (手順 2) を新しい 2.1 ドメインにインポートします。

    各セキュリティ プロバイダごとに、セキュリティ情報を個別にインポートします。

    2.1 には、WebLogic デフォルト認可プロバイダ (2.0 認可プロバイダと同じもの) および新しい WebLogic XACML 認可プロバイダという、2 種類の認可プロバイダがデフォルトで含まれています。新しい 2.1 ドメインを作成すると、デフォルトで XACML プロバイダが作成されます。2.1 ではこのプロバイダを使用することが推奨されています。アクセス制御ポリシーを XACML 認可プロバイダにインポートする場合は、[インポート フォーマット] ドロップダウン リストで必ず [DefaultAtn] を選択してください。

    2.1 には、WebLogic デフォルト ロール マッパー プロバイダ (2.0 ロール マッピング プロバイダと同じもの) および新しい WebLogic ロール マッピング プロバイダという、2 種類のロール マッピング プロバイダがデフォルトで含まれています。新しい 2.1 ドメインを作成すると、デフォルトで XACML プロバイダが作成されます。2.1 ではこのプロバイダを使用することが推奨されています。ロール定義を XACML ロール マッピング プロバイダにインポートする場合は、[インポート フォーマット] ドロップダウン リストで必ず [DefaultRoles] を選択してください。

  9. AquaLogic Service Bus Console オンライン ヘルプの「システム管理」の説明に従って、2.0 のコンフィグレーション データ (手順 1) を新しい 2.1 ドメインにインポートします。
  10. AquaLogic ドメイン コンフィグレーションの変更点の一部は、自動的に反映できないため手動で実装する必要があります。次の表に示すアップグレード時の考慮事項を参照し、どのような場合に影響が生じる可能性があるかを確認してください。

    アップグレード時の考慮事項

    解決策

    いずれかのデフォルト AquaLogic Service Bus グループ (IntegrationAdministrators、IntegrationOperators、IntegrationMonitors、IntegrationDeployers など) またはデフォルト WebLogic Server グループ (Administrators、Operators、Monitors、Deployers など) について何らかのグループ メンバシップ プロパティがカスタマイズされているセキュリティ コンフィグレーションをインポートする場合、それらのグループ メンバシップのカスタマイズ内容は、アップグレードしたドメインに反映されない。

    グループ メンバシップのカスタマイズを適用し直す。たとえば、IT_personnel という新しいグループを作成し、グループのメンバーとして IntegrationDeployers を割り当てていた場合は、このグループを IT_personnel のメンバーとして割り当て直す。

    wsp:PolicyURI 属性構文によるポリシー参照 (この wspWS-Policy ネームスペースを表す) が使用されている WSDL をインポートする場合、次の検証エラーが発生することがある。

    このリソースは、管理 API の外部で手動で更新されていて、依存関係のセットが同期されていません。

    このエラーは、ポリシー URI が policy:policy-id という形式のカスタム ポリシーへの参照であるか、または URL への参照である (つまり、policy: スキームを使用していない) 場合に発生する。

    Web サービス ポリシーの定義の詳細については、『AquaLogic Service Bus ユーザーズ ガイド』の「着信メッセージおよび発信メッセージの保護」にある「Web サービス ポリシー」を参照。

    ポリシー URI が policy:policy-id という形式のカスタム ポリシーへの参照である場合は、リソース ブラウザで WSDL を選択して編集、保存し、WSDL をコミットして、policy-id を解決する。詳細については、AquaLogic Service Bus Console オンライン ヘルプの「WSDL」にある「WSDL の詳細の表示と変更」を参照。

    ポリシー URI が URL への参照である場合は、AquaLogic Service Bus Console オンライン ヘルプの「WSDL」にある「未解決の WSDL 参照の解決」の説明に従って、WSDL ファイル内のポリシー参照を解決する。

    AquaLogic Service Bus 2.1 では、サービスレベルのアクセス制御ポリシーに関して次の点が変更されている。

    • サービスレベルのアクセス制御ポリシーは、WS-Policy が正常に処理された後、その WS-Policy で ID アサーションが指定されているかどうかに関係なく呼び出される。2.0 では、アクセス制御ポリシーは WS-Policy で ID アサーションが指定されている場合に限り呼び出されるようになっていた。
    • サービスレベルのアクセス制御ポリシーのデフォルト動作では、すべてのユーザにアクセスが許可される。2.0 では、アクセス拒否がデフォルトの動作となっていた。

    ユーザ アクセスの設定が適切になるように、サービスレベルのアクセス制御ポリシーを更新する。詳細については、『AquaLogic Service Bus ユーザーズ ガイド』の「着信メッセージおよび発信メッセージの保護」にある「アクセス制御セキュリティ」を参照。

    AquaLogic Service Bus 2.1 では、ネームスペースと xsi:type の整合性を維持するために、RPC ベースの WS-Callout に変更が加えられた。この実装変更により、特定の場合において RPC ベースの WS-Callout の動作が変更される。

    アプリケーションで RPC ベースの WS-Callout を使用しており、次の条件に該当する場合は、下の説明に従って対応する。

    • 応答に単純なタイプが使用されている
    • 応答が String であることに依存した XQuery がパイプラインで使用されている

    この場合、要素ラッパーを除去するように XQuery を変更 (たとえば、fn:string() 関数を使用) する必要がある。

    時間ベースの資格ポリシー (次の日時より前にアクセスが発生次の日時より後にアクセスが発生 など) を定義した認可プロバイダが使用されているセキュリティ コンフィグレーションをインポートした場合、それらのポリシーは正常に機能しない。

    XACML 認可プロバイダを使用する場合、時間ベースの資格ポリシーをサポートするには、ソフトウェア パッチ(CR255866 用) の適用が必要。詳細については、カスタマサポート担当者までお問い合わせください。

    注意 : このパッチへのアクセス方法についてカスタマサポートから連絡を受けた後は、Smart Update を使用してパッチをダウンロードおよび適用する。Smart Update の詳細については、『メンテナンス更新ファイルおよびサービス パックのインストール』を参照。