Liberty : architecture zéro migration

Avec l'architecture zéro migration de Liberty, vous pouvez passer à la version la plus récente de Liberty avec un impact minime sur vos applications et configurations actuelles.

L'architecture zéro migration vous permet d'utiliser des fichiers de configuration et d'application existants sans modification avec une version actualisée de l'environnement d'exécution de Liberty sans changement de comportement inattendu ou indésirable. Grâce aux deux caractéristiques suivantes de l'architecture, vous n'avez pratiquement jamais à apporter des modifications :

Compatibilité totale entre versions de produit
Vous pouvez mettre à jour votre version de Liberty sans migrer vos fichiers de configuration.
Fonctions connectables
Vos API et comportements existants sont pris en charge dans les nouvelles versions du produit et les nouvelles API et les nouveaux comportements sont ajoutés dans de nouvelles fonctions.

Fichiers de configuration utilisateur

L'environnement d'exécution de Liberty ne modifie jamais les fichiers de configuration utilisateur, lesquels sont totalement compatibles entre versions. Vous pouvez utiliser une même version de vos fichiers de configuration dans plusieurs versions. Les fichiers que vous avez créés pour une version antérieure de Liberty peuvent être utilisés avec une version plus récente. Les fichiers que vous créez pour des versions plus récentes peuvent être utilisés avec les anciennes versions. Par conséquent, si toutes les fonctions configurées ont été installées, vous pouvez utiliser un seul jeu de fichiers de configurations entre plusieurs versions sans avoir à les modifier. Les paramètres de configuration ne s'appliquant pas à une version spécifique de l'environnement d'exécution de Liberty sont ignorés.

Applications utilisateur

L'environnement d'exécution de Liberty utilise des fonctions connectables pour prendre en charge les différentes versions d'une API. Par exemple, les spécifications Servlet 3.0 et 3.1 sont toutes deux prises en charge. Les modifications du comportement d'API ne peuvent intervenir que dans les nouvelles versions des fonctions, et vous pouvez donc choisir la version de fonction appropriée pour votre application. Ces fonctions versionnées continuent à être prises en charge dans les mises à jour de Liberty. Si vous continuez à utiliser la même version de fonction, vous n'avez jamais besoin de migrer votre application.

Par exemple, si votre application utilise Servlet 3.0, le serveur Liberty exécutant cette application doit disposer de la fonction servlet-3.0. Vous pouvez mettre à jour Liberty et continuer à utiliser indéfiniment la fonction servlet-3.0, quel que soit le nombre d'autres niveaux de spécification Servlet pris en charge. Vous n'avez à migrer vos applications que si vous décider d'utiliser à la place la fonction servlet-3.1.

Diagramme illustrant comment les fonctions Servlet sont utilisées avec les versons antérieures et les versions récentes du produit.

Si vous utilisez des API d'éditeurs tiers, sachez qu'elles peuvent être modifiées ou supprimées lorsque vous mettez à jour Liberty. Ces API sont exposées aux applications via des fonctions Liberty. La compatibilité avec une version antérieure de ces API n'est pas régie par Liberty et n'est pas garantie. Ces API disponibles pour les applications n'étant pas fournies par des fonctions Liberty et ne bénéficiant pas de cette conception, vous devrez donc éventuellement modifier votre code d'application. Par exemple, vous devrez éventuellement mettre à jour les API Java™ fournies par votre SDK Java sous-jacent. Parfois, vous devrez mettre à jour la version du SDK Java. Au lieu de collecter manuellement des informations et de migrer vos applications, vous pouvez analyser vos applications à l'aide des outils Toolkit for Application Binaries et WebSphere Application Server Migration Toolkit pour détecter les modifications éventuelles qui s'imposent . Pour télécharger le kit d'outils et obtenir des informations complémentaires, veuillez vous reporter à l'article Migration du site WASdev.

Utilisation de nouvelles fonctions

Si vous désirez utiliser une nouvelle fonction, prenez en compte les questions suivantes :

Comment la nouvelle fonction affecte-t-elle les applications existantes ?
Une nouvelle version d'une fonction que vous utilisez déjà peut avoir une incidence sur vos applications existantes. Par exemple, si vous utilisez actuellement Servlet 3.0 et désirez adopter Servlet 3.1, vos applications de servlet existantes peuvent devoir être modifiées pour fonctionner correctement avec Servlet 3.1. Modifiez votre application pour qu'elle fonctionne avec la nouvelle version de la fonction ou conservez vos applications dans un serveur configuré avec la version d'origine de la fonction, par exemple Servlet 3.0, et créez une nouvelle configuration serveur avec la nouvelle version pour les nouvelles applications.
La nouvelle fonction est-elle compatible avec les fonctions existantes ?
Le produit prend en charge la coexistence de certaines fonctions entre différentes versions de Java EE, mails il est plus simple de se cantonner à une seule version de la spécification Java EE, si possible. Certaines fonctions interagissent étroitement avec d'autres lorsqu'elles sont configurées dans le même serveur et sont sensibles à leurs versions. Par exemple, de nombreuses fonctions Java EE sont étroitement associées à celles de CDI (Contexts and Dependency Injection) et ne fonctionnent qu'avec une version spécifique de cette fonction. Si vous ajoutez une fonction dans votre configuration, vous devrez peut-être changer les versions d'autres fonctions que vous utilisez déjà. Pour plus d'informations, voir Combinaisons de fonctions Java EE 6 et 7 prises en charge.
La nouvelle fonction requiert-elle d'autres changements de configuration ?
Certaines fonctions nécessitent des versions spécifiques de logiciels prérequis, notamment du SDK Java. Les fonctions Java EE 7, par exemple, exigent au minimum Java version 7. Par conséquent, l'ajout d'une fonction Java EE 7 à votre configuration de serveur peut imposer le passage à Java SDK 7 ou une version ultérieure.

Exceptions affectant la migration zéro

Dans de rares cas, le concept de migration zéro n'est pas mis en oeuvre. Dans les scénarios suivants, vous devrez éventuellement modifier votre application ou votre configuration :
Correctifs de sécurité
Si un correctif de sécurité est requis, mais que cette opération ne peut pas être effectuée en garantissant la préservation du comportement existant, vous devrez peut-être modifier votre application ou votre configuration.
Exigences des API tierces
Le produit ne régit pas les API de configuration de chargeur de classes d'éditeurs tiers. Par conséquent la comptabilité des mises à jour de composants tiers avec une version antérieure n'est pas garantie.
Suppression de la prise en charge
Liberty continue à prendre en charge les éléments du produit qui affectent les données utilisateur, mais il s'avère parfois nécessaire de retirer une fonction ou la prise en charge d'un progiciel. Généralement, les utilisateurs sont notifiés de ce retrait au moins deux années à l'avance. Toutefois, ces notifications ne sont pas aussi pratiques lorsque d'autres éditeurs de logiciels cessent la prise en charge de leur produit plus tôt que Liberty. Soyez attentifs aux produits tiers que vous utilisez avec votre installation Liberty et aux dates de leur cycle de vie. Pour plus d'informations sur les éléments éligibles pour un retrait futur, voir Avis de suppression.

Icône indiquant le type de rubrique Rubrique de concept

Nom du fichier : cwlp_migration.html