WebSphere Application Server Version 6.1 Feature Pack for Web Services   
             オペレーティング・システム: AIX , HP-UX, i5/OS, Linux, Solaris, Windows, Windows Vista, z/OS

             目次と検索結果のパーソナライズ化

製品構成のマイグレーション時の構成マッピング

製品構成のマイグレーション時には、さまざまな構成がマップされます。

[AIX HP-UX Linux Solaris Windows] マイグレーションでは、常に単一のプロファイルを、 同一マシン上または別のマシン上の別の単一プロファイルにマイグレーションします。 例えば、WebSphere Application Server バージョン 6.0.x デプロイメント・マネージャーを、 バージョン 6.1 デプロイメント・マネージャー・プロファイルにマイグレーションして、 バージョン 6.0.x アプリケーション・サーバーを、 バージョン 6.1 スタンドアロン・アプリケーション・サーバー・プロファイルに マイグレーションします。

[z/OS] マイグレーションでは、 WebSphere Application Server 製品の旧リリースから新リリースに構成がコピーされます。

[i5/OS] マイグレーションでは、常に単一のプロファイルを、 同一の iSeries サーバー上の別の単一プロファイルにマイグレーションします。 マイグレーション・ツールは、マイグレーション元のバージョンまたは WebSphere Application Server 内に存在するオブジェクトと属性を、 バージョン 6.1 環境内の対応するオブジェクトと属性にマップします。

多くのマイグレーション・シナリオが考えられます。 マイグレーション・ツールは、マイグレーション元のバージョン内に存在するオブジェクトと属性を、 バージョン 6.1 環境内の対応するオブジェクトと属性にマップします。

ブートストラップ・ポート

マイグレーション・ツールは、デフォルト以外の値を直接バージョン 6.1 環境にマップします。

[AIX HP-UX Linux Solaris Windows] [i5/OS] ただし、 WASPostUpgrade への呼び出し中に -portBlock パラメーターが指定された場合は、 バージョン 6.1 にマイグレーションされる各アプリケーション・サーバーに新しいポート値が指定されます。

コマンド行パラメーター

マイグレーション・ツールは、サーバー・プロセス定義において、 該当するコマンド行パラメーターを Java 仮想マシン (JVM) 設定に変換します。 ほとんどの設定は、直接マップされます。 一部の設定は、マイグレーションされません。 これは、その役割が WebSphere Application Server バージョン 6.1 構成にないか、 バージョン 6.1 では意味が異なるか、有効範囲が異なるためです。

プロセス定義設定の変更方法について詳しくは、プロセス定義設定 を参照してください。 Java 仮想マシン設定の変更方法について詳しくは、Java 仮想マシン設定 を参照してください。

汎用サーバー
WebSphere Application Server バージョン 5.1.x では、 汎用サーバーは外部リソースを管理するために適した APPLICATION_SERVER です。 バージョン 6.0.x 以降では、 GENERIC_SERVER と呼ばれる独自のタイプを持ちます。 マイグレーションによりこの変換が実行されますが、 汎用サーバーが参照する外部リソースは正確にマイグレーションされません。 汎用サーバー設定のマイグレーションが完了後、追加のタスクを実行する必要があります。 汎用サーバーが管理している古いリソースが古い WebSphere Application Server インストールにある場合は、 以下のタスクを実行します。
  1. 関連したファイルを新規インストールにコピーします。
  2. 必要なセットアップを実行して、外部アプリケーションを有効な作動状態に戻します。

    このリソースを新規 WebSphere Application Server ディレクトリーに再インストールすることが最善の方法です。 いずれを選択し実行した場合でも、最終ステップでは、アプリケーションの新規ロケーションへの参照をリセットします。

汎用サーバーが管理している古いリソースが、古い WebSphere Application Server インストールにインストールされていない場合は、 その他に必要なことはありません。

EAR ファイルのマイグレーションに必要な Java ヒープ・サイズ [AIX HP-UX Linux Solaris Windows]

wsadmin ツールを使用して WebSphere Application Server バージョン 5.x または 6.0.x EAR ファイルをすべてバージョン 6.1 にマイグレーションする場合、 WASPostUpgrade ツールは、 Java のデフォルトの最大ヒープ・サイズ値の 64 MB を使用して EAR ファイルをインストールします。

Java ヒープ・サイズの大きさが不十分なため、 マイグレーション中にバージョン 5.x または 6.0.x EAR ファイルがインストールに失敗する場合は、 次のようなメッセージが表示されます。
java.lang.OutOfMemoryError JVMXE006:OutOfMemoryError 

Java の最大ヒープ・サイズを増やし、以下の例に従ってアプリケーションをインストールしてください。

WebSphere Application Server バージョン 6.1 へのアプリケーションのインストールの例

以下のことを前提とします。
インストール・ルート
C:¥WebSphere¥AppServer
番号記号 (###)
最大ヒープ・サイズ値
EAR_file_name
EAR ファイルの名前
app_name
アプリケーションの名前
server_name
EAR ファイルをインストールするサーバーの名前
node_name
サーバーを構成するノードの名前
コマンドは、 わかりやすくするために複数の行に分けて表示しています。
wsadmin -conntype NONE
        -javaoption 
        -Xmx###m 
        -c "$AdminApp install 
               C:¥¥WebSphere¥¥AppServer¥¥installableApps¥¥
                  EAR_file_name
        {-nodeployejb 
         -appname app_name
         -server server_name
         -node node_name}"

WebSphere Application Server Network Deployment バージョン 6.1 へのアプリケーションのインストールの例

以下のことを前提とします。
インストール・ルート
C:¥WebSphere¥DeploymentManager
番号記号 (###)
最大ヒープ・サイズ値
EAR_file_name
EAR ファイルの名前
app_name
アプリケーションの名前
cluster_name
EAR ファイルをインストールしなければならないクラスターの名前
コマンドは、 わかりやすくするために複数の行に分けて表示しています。
wsadmin -conntype NONE
        -javaoption 
        -Xmx###m 
        -c "$AdminApp install 
            C:¥¥WebSphere¥¥DeploymentManager¥¥installableApps¥¥
                   EAR_file_name>
        {-nodeployejb 
         -appname app_name 
         -cluster cluster_name}"
JMS サーバー [AIX HP-UX Linux Solaris Windows]

JMS サーバーは、WebSphere Application Server バージョン 6.0.x では、 タイプ MESSAGE_BROKER からタイプ APPLICATION_SERVER に変更されました。 これが所有したキューまたはトピックは、 サービス統合テクノロジーに基づく、デフォルト・メッセージング・プロバイダーにマイグレーションされました。 バージョン 5.x 以前では、 Network Deployment 環境で、jmsserver は独自の MESSAGE_BROKER サーバーでした。 Base 環境では、APPLICATION_SERVER タイプ内に含まれていました。

JMS リソースはすべてそのままであり、変更しなくても動作します。 これらのリソースのさらなるマイグレーションは、 バージョン 6.1 のデフォルト・メッセージング・プロバイダーによって提供されるスクリプトまたは bat を実行することによって行うことができます。

JMS リソースについて詳しくは、メッセージング・リソースについての学習 を参照してください。

バージョン 5.x または 6.0.x ノードのバージョン 6.1 ノードへのマイグレーション

セルに所属する WebSphere Application Server バージョン 5.x または 6.0.x ノードは、 セルからノードを除去せずにマイグレーションできます。

最初にデプロイメント・マネージャーをマイグレーションしてから、 セル内の他の基本ノードをマイグレーションします。

Network Deployment をバージョン 5.x または 6.0.x からバージョン 6.1 にマイグレーションする場合は、 同じセル名を使用してください。 別のセル名を使用すると、 統合ノードが Network Deployment バージョン 6.1 セルに正常にマイグレーションできません。

セル内にある WebSphere Application Server の基本ノードをバージョン 6.1 にマイグレーションすると、 ノード・エージェントもバージョン 6.1 にマイグレーションされます。 セル内で、バージョン 6.1 ノードが存在し、同時にバージョン 5.x または 6.0.x レベルの別のノードが 存在してもかまいません。 混合リリース・セルの使用制限について詳しくは、共存サポート を参照してください。

ポリシー・ファイル
WebSphere Application Server バージョン 6.1 では、 設定をバージョン 6.1 ポリシー・ファイルにマージすることにより、 バージョン 5.x または 6.0.x にインストールされたすべてのポリシー・ファイルがマイグレーションされます。以下の ような特性があります。
  • バージョン 6.1 ポリシー・ファイルにあるコメントは保存されます。 バージョン 5.x または 6.0.x のポリシー・ファイルにあるコメントは、 バージョン 6.1 ファイルには組み込まれません。
  • マイグレーションでは、許可または認可はマージされません。 厳密には、追加タイプのマイグレーションです。 許可または認可がバージョン 6.1 ポリシー・ファイルにない場合、マイグレーションにより引き渡されます。
  • セキュリティーは重要なコンポーネントです。 このため、マイグレーションにより、コメント「MIGR0372I: マイグレーション済みの権限は次のとおりです。」の直後の元の.policy ファイルの最後に追加が行われます。 これによって、マイグレーションによって行われたポリシー・ファイルの変更を、管理者が確認しやすくなります。 
プロパティーおよび lib/app ディレクトリー [AIX HP-UX Linux Solaris Windows] [z/OS]

マイグレーションにより、 ファイルが旧バージョンのディレクトリーから WebSphere Application Server バージョン 6.1 構成にコピーされます。

プロパティー、クラス、および lib/app ディレクトリー [i5/OS]

マイグレーションにより、 ファイルが旧バージョンのディレクトリーから WebSphere Application Server バージョン 6.1 構成にコピーされます。

プロパティー・ファイル
WebSphere Application Server バージョン 6.1 では、 設定をバージョン 6.1 プロパティー・ファイルにマージすることにより、 バージョン 5.x または 6.0.x でインストールされたすべてのプロパティー・ファイルがマイグレーションされま す。 ただし、以下のバージョン 5.x ファイルを除きます。
  • j2c.properties (resources.xml ファイルにマイグレーションされます)
  • samples.properties

マイグレーションでは、プロパティー・ファイルはオーバーレイされません。

J2C リソースによって参照されるリソース・アダプター・アーカイブ (RAR)

J2C リソースによって参照される RAR が古い WebSphere Application Server インストールにある場合、これらの RAR はマイグレーションされます。この場合、RAR は、新しい WebSphere Application Server インストールの対応するロケーションにコピーされます。関係リソース・アダプター RAR はマイグレーションされません。

クラスター・レベルのリソースのマイグレーション:
WebSphere Application Server バージョン 6.0 では、 クラスター・レベルのリソースの概念が導入されました。 これらのリソースは、クラスター・ディレクトリーの下の resourcexxx.xml ファイルに構成されます。 以下に例を示します。
<resources.j2c:J2CResourceAdapter xmi:id="J2CResourceAdapter_1112808424172" 
  name="ims" archivePath="${WAS_INSTALL_ROOT}¥installedConnectors¥x2.rar">
  ...
</resources.j2c:J2CResourceAdapter>

クラスター・レベルのリソースがある場合、 このリソースは、各クラスター・メンバー (ノード) 上の同じ場所に置く必要があります。 したがって、前述の例を使用すると、各クラスター・メンバーでは、 ${WAS_INSTALL_ROOT}¥installedConnectors¥x2.rar という場所に RAR ファイルをインストールしておく必要があります。 ${WAS_INSTALL_ROOT} は、正確な場所を得るために各クラスター・メンバーで解決されます。

デプロイメント・マネージャーのマイグレーションでは、 ツールによって、resourcexxx.xml ファイルなど、デプロイメント・ マネージャー上のクラスター・ファイルがマイグレーションされます。

管理対象ノードのマイグレーションでは、ツールによって各 J2C アダプターが処理されます。 RAR ファイルなどのファイルは、バージョン 5.x からバージョン 6.x へのマイグレーションであるか、 バージョン 6.0.x からバージョン 6.1 へのマイグレーションであるかによって、マイグレーション方法が異なります。

  • バージョン 5.x からバージョン 6.x へのマイグレーション

    バージョン 6.0 ではプロファイル構造が変更されているため、 バージョン 5.x からバージョン 6.0.x へのマイグレーションによって、 RAR ファイルなどのファイルが、WAS_INSTALL_ROOT 変数用に設定された場所から USER_INSTALL_ROOT 変数用に設定された場所にコピーされ、 これらの変更内容を反映するようにパスが変更されます。

  • バージョン 6.0.x からバージョン 6.1 へのマイグレーション

    バージョン 6.0.x からバージョン 6.1 へのマイグレーションによって、 RAR ファイルなどのファイルが、WAS_INSTALL_ROOT から WAS_INSTALL_ROOT に、 および USER_INSTALL_ROOT から USER_INSTALL_ROOT にコピーされます。

    例えば、バージョン 6.0.x の WAS_INSTALL_ROOT に RAR ファイルがある場合、バージョン 5.x からバージョ ン 6.x へのマイグレーションの場合とは異なり、マイグレーション・ツールが自動的に WAS_INSTALL_ROOT から USER_INSTALL_ROOT にファイルをコピーすることはありません。 これにより、クラスター・レベルの J2C リソースの保全性が保たれます。

    Limitation: しかし、バージョン 6.0.x の RAR ファイルへのパス (例えば archivePath="C:/WAS/installedConnectors/x2.rar") をハードコーディングした場合、 バージョン 6.1 のマイグレーション・ツールは、この内容を反映するように archivePath 属性を変更することはできません。 これは、それによってマイグレーションされていない他のクラスター・メンバーのすべてが壊れるためです。
サンプル

デプロイメント・マネージャーのマイグレーション時にマイグレーションされるのは、 統合されたノードの WebSphere Application Server バージョン 5.x サンプルだけです。 その他すべてのバージョン 5.x とバージョン 6.0.x のサンプルに対して、同等のバージョン 6.1 サンプルを使用することができます。

セキュリティー

WebSphere Application Server バージョン 6.1 でセキュリティーを使用可能にする場合、 デフォルトで Java 2 セキュリティーが使用可能です。 Java 2 セキュリティーでは、セキュリティー許可を明示的に付与する必要があります。

[AIX HP-UX Linux Solaris Windows] [i5/OS] バージョン 6.1 でさまざまなレベルの Java 2 セキュリティーを定義する場合に、 使用できる技法がいくつかあります。 1 つは、was.policy ファイルをアプリケーションの一部として作成し、 すべてのセキュリティー許可を使用可能にすることです。 マイグレーション・ツールは、マイグレーション中に wsadmin コマンドを呼び出して、 バージョン 6.1 の properties ディレクトリーにある既存の was.policy ファイルをエンタープライズ・アプリケーションに追加します。

WebSphere Application Server バージョン 6.1 にマイグレーションする際に、 スクリプトの互換性をサポートするマイグレーションを行うかどうかの選択によって、 以下の 2 つの異なる結果のうちいずれかになります。
  • スクリプトの互換性をサポートするマイグレーションを行う選択をすると、 セキュリティー構成は変更されず、バージョン 6.1 でもそのままです。

    これはデフォルトです。

  • スクリプトの互換性をサポートするマイグレーションをしない選択をすると、 セキュリティー構成は、WebSphere Application Server バージョン 6.1 のデフォルトの構成に変換されます。 バージョン 6.1 のデフォルトのセキュリティー構成は、 前のバージョンとほぼ同じように機能しますが、変更されている点もあります。

    例えば、既存の鍵ファイルとトラスト・ファイルは、SSLConfig レパートリーから移動され、 新しい鍵ストアおよびトラストストア・オブジェクトが作成されます。

    [z/OS] System Secure Sockets Layer (SSSL) タイプの SSL 構成レパートリーは、 デーモンに属するものを除き、すべて Java Secure Socket Extension (JSSE) タイプに変換されます。

セキュリティー構成のバージョン 6.1 へのマイグレーションについて詳しくは、 マイグレーション、共存、および相互運用 - セキュリティーに関する考慮事項 を参照してください。

Stdin、stdout、stderr、passivation、および作業ディレクトリー

[AIX HP-UX Linux Solaris Windows] 通常、これらのディレクトリーは、 前のバージョンのインストール・ディレクトリーにあります。 デフォルトでは、stdinstdout、 および stderr は、 WebSphere Application Server バージョン 6.1 のインストール・ルートの logs ディレクトリーにあります。

[z/OS] WebSphere Application Server for z/OS では、 stdinstdout、 および stderr の出力は、デフォルトで SYSOUT に送信されます。 これらの出力が前のバージョンの構成ディレクトリーにリダイレクトされた場合は、 これをバージョン 6.1 の JCL で変更する必要があります。

[i5/OS] これらのディレクトリーの場所は通常、 WebSphere Application Server プロファイル・ディレクトリーの下の logs ディレクトリーです。 WebSphere Application Server バージョン 6.1 の場合、 stdinstdout、 および stderr ファイルのデフォルトのロケーションは logs ディレクトリーです。 これは、WebSphere Application Server プロファイル・ディレクトリーの下にあります。 例えば、デフォルト・プロファイルの logs ディレクトリーは /QIBM/UserData/WebSphere/AppServer/V61/Base/profiles/default/logs です。

マイグレーション・ツールは、既存の passivation ディレクトリーと作業デ ィレクトリーのマイグレーションを試行します。 そうでない場合、該当するバージョン 6.1 のデフォルトが使用されます。

非活性化ディレクトリーについて詳しくは、 EJB コンテナー設定 を参照してください。 作業ディレクトリーについて詳しくは、プロセス定義設定 を参照してください。

[z/OS] WebSphere Application Server for z/OS のユーザー ID のホーム・ディレクトリーが、 前のバージョンの構成ディレクトリー内にある場合は、 マイグレーションする前に、それらを更新して別の場所に置く必要があります。

共存シナリオでは、バージョン間で共通のディレクトリーを使用すると、問題が生じる可能性があります。

トランスポート・ポート

マイグレーション・ツールは、すべてのポートをマイグレーションします。 ポートがすでに構成に定義されている場合、ツールは、ポート競合の警告を記録します。 サーバーを同時に実行する前に、ポートの競合を解決する必要があります。

[AIX HP-UX Linux Solaris Windows] [i5/OS] WASPostUpgrade コマンドに -portBlock パラメーターが指定されている場合、 マイグレーションされる各トランスポートに新しい値が割り当てられます。 WebSphere Application Server バージョン 5.x からマイグレーションしている場合、 -scriptCompatibility="true" を選択するか、または -scriptCompatibility="false" を選択するかによって、 以下のような、トランスポート・ポートに関する 2 つの異なる結果が得られます。
  • -scriptCompatibility="true"

    この場合、トランスポート・ポートはそのままです。 これはデフォルトです。

  • -scriptCompatibility="false"

    この場合、トランスポート・ポートはチャネルとチェーンの実装に変換されます。 外部アプリケーション使用の観点からは、これらは依然として同じように動作しますが、 TransportChannelService に移動されています。

[AIX HP-UX Linux Solaris Windows] [i5/OS] WASPostUpgrade コマンドについて詳しくは、 WASPostUpgrade コマンド を参照してください。

[AIX HP-UX Linux Solaris Windows] [i5/OS] トランスポート・チェーンとチャネルについて詳しくは、 トランスポート・チェーン を参照してください。

各ポートの仮想ホスト別名項目を、手動で追加する必要があります。 詳しくは、仮想ホストの構成 を参照してください。

Web モジュール

WebSphere Application Server バージョン 6.0.x で実装される Java 2 Platform, Enterprise Edition (J2EE) の仕様レベルでは、 コンテンツ・タイプを設定する場合、Web コンテナーの振る舞いの変更が必要でした。 デフォルト・サーブレットの書き込み機能によってコンテンツ・タイプが設定されない場合、 Web コンテナーのデフォルトがその値にデフォルト設定されなくなるばかりでなく、 Web コンテナーは呼び出しを「ヌル」として戻します。 この場合、一部のブラウザーで、Web コンテナーのタグが正しく表示されないことがあります。 この問題を回避するため、エンタープライズ・アプリケーションをマイグレーションする際に、 autoResponseEncoding IBM 拡張が Web モジュールに対して「true」に設定されます。




関連タスク
マイグレーションと共存
製品構成のマイグレーション
タスクの概説: アプリケーションでのエンタープライズ Bean の使用
概念トピック    

ご利用条件 | フィードバック

最終更新: Jan 21, 2008 4:10:06 PM EST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.wsfep.multiplatform.doc/info/ae/ae/cmig_configmap.html