Liberty のゼロ・マイグレーション・アーキテクチャー

Liberty のゼロ・マイグレーション・アーキテクチャーを使用すると、現行のアプリケーションおよび構成への影響を最小限に抑えながら、最新バージョンの Liberty に移行することができます。

Open Liberty ゼロ・マイグレーション・アーキテクチャーの資料は、 Open Liberty Web サイトで入手できます。

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

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

ユーザー構成ファイル

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

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

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

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

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

前の図は、新規および既存のユーザー構成とアプリケーションを介して、さまざまなバージョンの Servlet フィーチャーを異なるバージョンのランタイム内で有効にする方法を示しています。 旧バージョンのランタイムは最新バージョンのフィーチャーを無視することがありますが、最新バージョンのランタイムは旧バージョンのフィーチャーを無視することがあります。

サード・パーティー API を使用する場合は、 Libertyの更新時にそれらの API を変更または削除できることに注意してください。 サード・パーティー API は、 Liberty フィーチャーを介してアプリケーションに公開されます。 これらの API の旧バージョンとの互換性は、 Liberty によって制御されず、保証されません。 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の異なるバージョン間でのいくつかのフィーチャーの混合をサポートしていますが、可能であれば、 Java EE 仕様の 1 つのバージョン内にとどまる方が簡単です。 フィーチャーによっては、同じサーバー内に構成されている他のフィーチャーと密接に相互作用し、 それらのフィーチャーのバージョンに敏感なものがあります。 例えば、 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 インストール済み環境で使用しているサード・パーティー製品と、それらのライフサイクルの日付に注意してください。 将来の廃止に適格な項目について詳しくは、『削除通知』を参照してください。
文書化されていない構成プロパティー
Liberty コード・ベースは、 WebSphere® Application Server traditional コード・ベースと共通です。 したがって、 Liberty コード・ベースの一部の構成プロパティーは文書化されていない場合がありますが、指定すると Libertyの動作に影響する可能性があります。 これらの構成プロパティーは Liberty用に文書化されていないため、 Libertyではサポートされません。 これらは Liberty 用にテストされておらず、現在も将来も Liberty で確実に機能しない可能性があります。 これらのプロパティーは製品の外部として文書化されていないため、いつでも削除できます。
互換性のない Java の変更
歴史的に新しい Java SE バージョンでは、言語に対して互換性のない変更がほとんど行われていません。これは Java SE 9 で変更されました。 Liberty ランタイムは、これらの破壊的な変更がアプリケーションに与える影響を最小限に抑えようとしますが、これが常に可能であるとは限りません。