共存: バージョン 5.1 ゲートウェイの保存またはマイグレーション

WebSphere® Application Server バージョン 5.1 で実行されている Web サービス・ゲートウェイは、バージョン 7.0 以降 アプリケーション・サーバーで実行されるゲートウェイ・インスタンスと共存可能です (ただし、一定の制約事項があります)。. あるいは、バージョン 5.1 のゲートウェイおよびアプリケーション・サーバーを WebSphere Application Server バージョン 7.0 以降 にマイグレーションすることもできます。. バージョン 5.1 ゲートウェイを保存するのか、マイグレーションするのかを容易に選択できるように、このトピックでは、ゲートウェイの共存での制限と、ゲートウェイのマイグレーションで取られる方法を説明します。

注: WebSphere Application Server バージョン 5.0 はサポート対象ではなくなりました。 このため、バージョン 5.0 アプリケーション・サーバーで実行しているすべての既存ゲートウェイをマイグレーションし、この製品の現行レベルのアプリケーション・サーバーで実行する必要があります。

バージョン 5.1 ゲートウェイとの共存

バージョン 5.1 Web サービス・ゲートウェイは、バージョン 7.0 以降のゲートウェイと共存でき、次の制限に従います。
  • バージョン 5.1 の Web サービス・ゲートウェイ・アプリケーションは、バージョン 7.0 以降のアプリケーション・サーバーではサポートされていません。
  • サービス統合テクノロジーのエンドポイント・リスナー・アプリケーションは、バージョン 5.1 のアプリケーション・サーバー上にインストールされてもサポートされません。
  • バージョン 5.1 アプリケーション・サーバーで実行されているゲートウェイの構成を変更するには、管理コンソールではなく、Web ブラウザーを使用して、バージョン 5.1 ゲートウェイ・ユーザー・インターフェースにアクセスします。

デプロイメントがこれらの制限事項の影響を受けず、ご使用のバージョン 5.1 ゲートウェイがスタンドアロンのバージョン 5.1 アプリケーション・サーバーで実行されている場合は、これ以上のアクションは不要です。

デプロイメントがこれらの制限事項の影響を受けず、ご使用のバージョン 5.1 ゲートウェイが WebSphere Application Server Network Deployment セルの一部であるバージョン 5.1 アプリケーション・サーバーで実行されている場合は、セルをバージョン 5.1 または バージョン 6 からバージョン 7.0 以降 にマイグレーションしても、バージョン 5.1 のゲートウェイおよびアプリケーション・サーバーを引き続き使用することができます。ただし、セルをマイグレーションすると、セル内のアプリケーション・サーバーで 以前に構成されたバージョン 5.1 ゲートウェイは、空のゲートウェイに置き換えられます。バージョン 5.1 ゲートウェイ構成を保存および復元するには、最初にセルのマイグレーション時のバージョン 5.1 ゲートウェイの保存に示す手順を行う必要があります。

バージョン 5.1 ゲートウェイのマイグレーション

バージョン 5.1 アプリケーション・サーバーで実行するバージョン 5.1 ゲートウェイを、バージョン 7.0 以降 アプリケーション・サーバーで実行するバージョン 7.0 以降 ゲートウェイへマイグレーションすることができます。これを行うには、バージョン 5.1 ゲートウェイ構成をエクスポートし、スクリプトを実行して、エクスポートされた構成を既存バージョン 7.0 以降 のアプリケーション・サーバーの新規ゲートウェイ・インスタンスにマイグレーションします。このタスクの詳細な手順は、バージョン 5.1 Web サービス・ゲートウェイ構成のマイグレーションで説明されています。マイグレーション・プロセスの基礎となる基本ルールは、次のとおりです。
  • マイグレーションは引き続き稼働するオリジナル・ゲートウェイと 並行して行うことができ、既存の構成が損なわれることはありません。
  • マイグレーション・コマンドのそれぞれの実行は、単一のゲートウェ イ構成に対して作用します。
  • ゲートウェイ構成は、サービス統合バス内のゲートウェイ・インスタ ンスにマイグレーションされます。複数のゲートウェイを同一のバスに マイグレーションすることも可能ですが、この場合、ゲートウェイ名前空間 URI が異なっていなければなりません。
  • ゲートウェイ・インスタンスのエンドポイント・リスナーはすべて、 同一のアプリケーション・サーバーまたはクラスター上に配置されます。 アウトバウンド呼び出し用のポート宛先のローカリゼーションもすべて、 同一のアプリケーション・サーバーまたはクラスター上に配置されます。
  • 作成されたすべてのオブジェクトおよび宛先は、各自の名前にプレフィ ックスとしてゲートウェイ名前空間 URI が指定され、 これはコロン (":") を用いて連結されます。例えば、デフォルトの 名前空間 URI では、ゲートウェイ・サービスの応答宛先 は urn:ibmgateway:gatewayservicenameReply になります。 このプレフィックスは、マイグレーション・コマンドのパラメーターで オーバーライドすることができます。
  • ターゲット・サービスはすべて、新規の OutboundService オ ブジェクトにマイグレーションされます。既存の OutboundService オブジェクトは、 マイグレーションされた構成で自動的に再使用することはできません。
  • JAX-RPC ハンドラー・リストが、すべてのゲートウェイ・サービス/チ ャネルとゲートウェイ・サービス/ターゲット・サービス/ポートの組み合わせ に対して作成されます。同じハンドラーが同じ順序で含まれている場合でも、これらは共有されません。
  • WS-Security (ドラフト 13) 構成オブジェクトおよびバインディング・オブジェクトが、すべてのゲートウェイ・サービス/ゲートウェイ・サービスと ターゲット・サービスの組み合わせに対して作成されます。すべて同じ属性値を持っている場合でも、これらは共有されません。 作成されたオブジェクトはすべて、マイグレーション・ツールにより作成された インバウンド/アウトバウンド・サービスによる名前に応じて名前が付けられます。
    • 各サービスに作成された WS-Security 構成には、サービスと同じ名前が付けられ、接尾部に _Inbound または _Outbound が付けられます。
    • 子として作成された WS-Security 構成オブジェクトには、オブジェクトのタイプと同じ名前が付けられ、_x が続きます。 x は、マイグレーション・ツールがそのサービスのタイプで作成したオブジェクトの数です。 例えば、あるサービスに作成された最初の Required Integrity オブジェクトの名前は、RequiredIntegrity_1 になります。
    • 作成された WS-Security バインディングには、ポート名からなる名前が付けられ、接尾部にバインディングのタイプが付きます (_Req_Rec_Req_Snd_Res_Rec、および _Res_Snd のいずれか)。

トピックのタイプを示すアイコン 概念トピック



タイム・スタンプ・アイコン 最終更新: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cwsg_coex_migrate
ファイル名:cwsg_coex_migrate.html