Liberty: Architektur ohne Migration

Mit der Liberty-Architektur ohne Migration können Sie mit minimalen Auswirkungen auf Ihre aktuellen Anwendungen und Konfigurationen zur aktuellen Version von Liberty wechseln.

Architektur ohne Migration bedeutet, dass Sie vorhandene, unveränderte Konfigurations- und Anwendungsdateien mit einer aktualisierten Version der Liberty-Laufzeitumgebung ohne unerwünschte oder unerwartete Verhaltensänderungen verwenden können. Dank der folgenden zwei Architekturaspekte sind Änderungen so gut wie nie erforderlich:

Vollständige Kompatibilität zwischen Produktversionen
Sie können Liberty ohne Migration Ihrer Konfigurationsdateien aktualisieren.
Modular aufgebaute Features
Ihre vorhandenen APIs und Verhalten werden in neuen Produktversionen unterstützt und neue APIs und Verhalten werden in neuen Features hinzugefügt.

Benutzerkonfigurationsdateien

Die Liberty-Laufzeitumgebung ändert keine Benutzerkonfigurationsdateien, die zwischen Versionen vollständig kompatibel sind. Sie können eine einzige Version Ihrer Konfigurationsdateien in mehreren Versionen verwenden. Dateien, die Sie für eine Vorgängerversion von Liberty erstellt haben, können mit einer höheren Version verwendet werden. Dateien, die Sie für höhere Versionen erstellen, können mit Vorgängerversionen verwendet werden. Wenn alle konfigurierten Features installiert sind, können Sie daher einen einzigen Satz von Konfigurationsdateien in mehreren Versionen ohne Änderung verwenden. Konfigurationseinstellungen, die für eine bestimmte Version der Liberty-Laufzeitumgebung nicht gelten, werden ignoriert.

Benutzeranwendungen

Die Liberty-Laufzeitumgebung verwendet modular aufgebaute Features zur Unterstützung mehrerer Versionen einer API. Es wird beispielsweise sowohl die Spezifikation Servlet 3.0 als auch die Spezifikation 3.1 unterstützt. Änderungen am API-Verhalten finden nur in neuen Featureversionen statt. Daher können Sie die geeignete Featureversion für Ihre Anwendung auswählen. Diese versionsgesteuerten Features werden nach Aktualisierungen von Liberty weiterhin unterstützt. Wenn Sie dieselbe Featureversion weiterhin verwenden, müssen Sie Ihre Anwendung nicht migrieren.

Wenn Ihre Anwendung beispielsweise Servlet 3.0 verwendet, muss der Liberty-Server, in dem die Anwendung ausgeführt wird, das Feature servlet-3.0 haben. Sie können Liberty aktualisieren und das Feature servlet-3.0 unbegrenzt weiterverwenden, unabhängig davon, wie viele andere Servletspezifikationsstufen unterstützt werden. Sie müssen Ihre Anwendungen nur migrieren, wenn Sie das Feature servlet-3.1 verwenden möchten.

Eine Abbildung, die zeigt, wie Servlet-Features mit früheren und aktuellen Versionen des Produkts verwendet werden.

Wenn Sie APIs anderer Anbieter verwenden, müssen Sie beachten, dass diese bei einer Aktualisierung von Liberty unter Umständen geändert oder entfernt werden. APIs anderer Anbieter werden Anwendungen über Liberty-Features bereitgestellt. Die Kompatibilität mit einer früheren Version dieser APIs wird nicht von Liberty kontrolliert und wird nicht sichergestellt. Einige für Anwendungen verfügbare APIs werden nicht von Liberty-Features bereitgestellt und können die Vorteile dieses Konzepts nicht nutzen. Aus diesem Grund müssen Sie Ihren Anwendungscode möglicherweise ändern. Beispielsweise müssen Sie die Java™-APIs, die vom zugrunde liegenden Java SDK bereitgestellt werden, möglicherweise aktualisieren. Zuweilen müssen Sie die Version des Java SDK unter Umständen aktualisieren. Anstatt Informationen manuell zu sammeln und Ihre Anwendungen zu migrieren, können Sie Ihre Anwendungen mit Migration Toolkit for Application Binaries und WebSphere Application Server Migration Toolkit auf erforderliche Änderungen scannen. Im Artikel Migration auf WASdev können Sie das Toolkit herunterladen und weitere Informationen erhalten.

Neue Features verwenden

Wenn Sie ein neues Feature verwenden möchten, stellen Sie sich die folgenden Fragen:

Inwiefern wirkt sich ein neues Feature auf vorhandene Anwendungen aus?
Eine neue Version eines bereits verwendeten Features kann sich auf Ihre vorhandenen Anwendungen auswirken. Wenn Sie beispielsweise zurzeit Servlet 3.0 verwenden und Servlet 3.1 verwenden möchten, müssen Ihre vorhandenen Servletanwendungen möglicherweise geändert werden, damit sie ordnungsgemäß mit Servlet 3.1 funktionieren. Ändern Sie Ihre Anwendung so, dass sie mit der neuen Featureversion funktioniert, oder führen Sie Ihre Anwendungen in einem Server aus, der mit der ursprünglichen Featureversion, z. B. Servlet 3.0, konfiguriert ist, und erstellen Sie eine Serverkonfiguration mit der neuen Version für neue Anwendungen.
Ist das neue Feature mit vorhandenen Features kompatibel?
Das Produkt unterstützt die Kombination einiger Features in verschiedenen Versionen von Java EE. Es ist allerdings einfacher - sofern möglich - einer einzige Version der Java EE-Spezifikation zu verwenden. Einige Features interagieren eng mit anderen Features, wenn sie in demselben Server konfiguriert sind, und sie sind versionsabhängig. Viele Java EE-Features sind eng mit den Features für Contexts and Dependency Injection (CDI) verbunden und funktionieren nur mit einer bestimmten Version dieses Features. Wenn Sie Ihrer Konfiguration ein Feature hinzufügen, müssen Sie die Versionen anderer bereits verwendeter Features möglicherweise ändern. Weitere Informationen finden Sie unter Unterstützte Kombinationen der Features für Java EE 6 und 7.
Erfordert das neue Feature weitere Konfigurationsänderungen?
Einige Features erfordern bestimmte Versionen von Softwarevoraussetzungen, meist Java SDK. Java EE 7-Features erfordern beispielsweise mindestens Java Version 7. Aus diesem Grund müssen Sie beim Hinzufügen eines Java EE 7-Features zu Ihrer Serverkonfiguration möglicherweise ein Update auf Java SDK 7 oder höher durchführen.

Ausnahmen des Konzepts ohne Migration

In einigen seltenen Fällen kann das Konzept ohne Migration nicht verwendet werden. In den folgenden Szenarien müssen Sie Ihre Anwendung oder Konfiguration möglicherweise ändern.
Sicherheitsfixes
Wenn ein sicherheitsrelevanter Fix erforderlich ist, dieser aber unter Beibehaltung des vorhandenen Verhaltens nicht sicher umgesetzt werden kann, müssen Sie Ihre Anwendung oder Konfiguration möglicherweise ändern.
Voraussetzungen von APIs anderer Anbieter
Das Produkt steuert keine APIs aus der Konfiguration von Klassenladern anderer Anbieter. Daher kann die Kompatibilität mit einer früheren Version bei Updates von Komponenten anderer Anbieter nicht sichergestellt werden.
Entfernung der Unterstützung
Liberty unterstützt weiterhin Teile des Produkts, die sich auf Benutzerdaten auswirken. Es kann zuweilen aber erforderlich sein, ein Feature oder ein unterstütztes Softwareprodukt zurückzuziehen. In der Regel erhalten Benutzer mindestens zwei Jahre im Voraus Entfernungsbenachrichtigungen. Benachrichtigungen sind aber nicht zweckmäßig, wenn andere Softwareanbieter die Unterstützung für Ihr Produkt vor Liberty entfernen. Behalten Sie die Produkte anderer Anbieter, die Sie mit Ihrer Liberty-Installation verwenden, und ihre Lebenszyklusdaten im Auge. Informationen zu Elementen, die in zukünftigen Releases möglicherweise entfernt werden, finden Sie in den Entfernungsmitteilungen.

Symbol das den Typ des Artikels anzeigt. Konzeptartikel



Symbol für Zeitmarke Letzte Aktualisierung: 01.12.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cwlp_migration
Dateiname: cwlp_migration.html