Liberty: ゼロ・マイグレーション方式

Liberty のゼロ・マイグレーション方式によって、 現行のアプリケーションおよび構成に与える影響を最小限にして最新バージョンの Liberty に移行することができます。

ゼロ・マイグレーション方式とは、既存の構成およびアプリケーションを、変更を加えることなく、更新バージョンの Liberty ランタイム環境で、望まない動作変更や予期しない動作変更を起こさずに使用できることを意味します。この方式の以下の 2 つの特徴により、変更が必要になることはほとんどありません。

製品バージョン間での完全な互換性
構成ファイルをマイグレーションすることなく Liberty を更新できます。
プラグ可能フィーチャー
既存の API および動作は新しい製品バージョンでもサポートされ、新しい API および動作は新規フィーチャーで追加されます。

ユーザー構成ファイル

Liberty ランタイム環境がユーザー構成ファイルを変更することはなく、ユーザー構成ファイルはバージョン間で完全に互換です。 単一の版の構成ファイルを複数のバージョンにわたって使用できます。旧バージョンの Liberty 用に作成したファイルを新しいバージョンで使用できます。新しいバージョン用に作成したファイルを以前のバージョンで使用することもできます。結果的に、 構成されたすべてのフィーチャーがインストールされている場合、構成ファイルの単一セットを、変更せずに複数のバージョンにわたって使用することが可能です。特定のバージョンの Liberty ランタイム環境に適用されない構成設定がある場合、それらは無視されます。

ユーザー・アプリケーション

Liberty ランタイム環境は、 1 つの API の複数のバージョンをサポートできるよう、プラグ可能フィーチャーを使用します。例えば、Servlet 3.0 および 3.1 の両方の仕様がサポートされます。API 動作の変更は新しいフィーチャー・バージョンでのみ発生するため、ご使用のアプリケーションに合った適切なフィーチャー・バージョンを選択できます。このようなバージョン管理されたフィーチャーは、 Liberty の更新があっても引き続きサポートされます。同じフィーチャー・バージョンを使用し続ける場合、 アプリケーションをマイグレーションする必要はまったくありません。

例えば、アプリケーションが Servlet 3.0 を使用する場合、 そのアプリケーションを実行する Liberty サーバーは servlet-3.0 フィーチャーを備えている必要があります。他にいくつの Servlet 仕様レベルがサポートされているかに関係なく、Liberty を更新し、 servlet-3.0 フィーチャーを無期限に使用し続けることができます。アプリケーションのマイグレーションが必要になるのは、 代わりに servlet-3.1 フィーチャーを使用することを選択した場合のみです。

製品の旧バージョンおよび最近のバージョンで Servlet フィーチャーがどのように使用されるのかを示す図。

サード・パーティー API を使用している場合、 Liberty を更新するとそれらの API は変更または削除される可能性があることに注意してください。サード・パーティー API は、 Liberty フィーチャーを介してアプリケーションに公開されます。Liberty では、これらの API の前のバージョンとの互換性は制御されず、保証されていません。 API によっては、アプリケーションで使用可能であっても Liberty フィーチャーによって提供されないものがあり、この設計の恩恵を受けないため、アプリケーション・コードの変更が必要になる可能性があります。例えば、基礎にある Java™ SDK によって提供される Java API は、 更新が必要になることがあります。場合によっては、 Java SDK のバージョンを更新することが必要になることがあります。情報を手動で収集してアプリケーションをマイグレーションする代わりに、 Migration Toolkit for Application Binaries と WebSphere Application Server Migration Toolkit を使用してアプリケーションをスキャンして、必要な変更があるかどうかを確認します。このツールキットのダウンロードと詳しい説明については、WASdev の「マイグレーション」を参照してください。

新規フィーチャーの使用

新規フィーチャーを使用したい場合、以下の設問を検討してください。

新規フィーチャーが既存アプリケーションに及ぼす影響はどのようなものですか?
既に使用しているフィーチャーの新バージョンは、既存アプリケーションに影響を及ぼす可能性があります。 例えば、現在は Servlet 3.0 を使用していて、Servlet 3.1 を使用するようにしたい場合、 既存のサーブレット・アプリケーションを Servlet 3.1 で正しく機能するように変更する必要があることがあります。新しいフィーチャー・バージョンで機能するようにアプリケーションを変更するか、 または、元のフィーチャー・バージョン (例えば Servlet 3.0) を使用して構成されたサーバーで既存アプリケーションを保持し、新しいアプリケーション用に新バージョンを使用したサーバー構成を作成します。
新規フィーチャーは既存フィーチャーと互換ですか?
当製品では、一部のフィーチャーについては、複数バージョンの Java EE にまたがった混合がサポートされていますが、 可能であれば 1 つのバージョンの Java EE 仕様にとどめておくほうが簡単です。フィーチャーによっては、同じサーバー内に構成されている他のフィーチャーと密接に相互作用し、 それらのフィーチャーのバージョンに敏感なものがあります。 例えば、Java EE フィーチャーの多くは、 Contexts and Dependency Injection (CDI) 用のフィーチャーと密接に関連していて、そのフィーチャーの特定のバージョンとのみ連動して機能します。構成にフィーチャーを追加する場合、 既に使用している他のフィーチャーのバージョンを変更することが必要になる可能性があります。詳しくは、 『サポートされる Java EE 6 と 7 フィーチャーの組み合わせ』を参照してください。
新規フィーチャーは他の構成変更を必要としますか?
フィーチャーによっては、特定のバージョンの前提ソフトウェア (最も一般的なものは Java SDK) を必要とします。例えば、Java EE 7 フィーチャーは、最低限 Java バージョン 7 を必要とします。 したがって、サーバー構成に Java EE 7 フィーチャーを追加すると、 Java SDK 7 以降に移行することが必要になる可能性があります。

ゼロ・マイグレーションの例外

まれにしかないことですが、ゼロ・マイグレーションの概念に従わない場合があります。以下のシナリオでは、アプリケーションまたは構成の変更が必要な場合があります。
セキュリティー・フィックス
セキュリティー関連フィックスが必要だが、既存の動作を保持したままでは安全に行うことができない場合は、アプリケーションまたは構成の変更が必要になる可能性があります。
サード・パーティー API の要件
当製品は、サード・パーティーのクラス・ローダー構成からの API を制御しません。結果として、サード・パーティー製コンポーネントに対する更新には、旧バージョンとの互換性は保証されません。
サポート廃止
Liberty は、ユーザー・データに影響する製品部分を引き続きサポートしますが、 フィーチャーまたはサポートされるソフトウェア製品の廃止が必要になることもあります。通常、お客様は最低 2 年前までに廃止の通知を受け取ります。ただし、そういった通知は、 他のソフトウェア供給業者が自社製品のサポートを Liberty よりも早く廃止する場合には実用的ではありません。Liberty インストール済み環境で使用しているサード・パーティー製品と、 それらの製品のライフサイクル日付に留意してください。将来の廃止に適格な項目について詳しくは、『削除通知』を参照してください。

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



タイム・スタンプ・アイコン 最終更新: Monday, 5 December 2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-libcore-mp&topic=cwlp_migration
ファイル名: cwlp_migration.html