Les applications de service prennent en charge la gestion des versions. Vous pouvez créer
et déployer une ou plusieurs versions d'un module et ses artefacts dans
l'environnement d'exécution afin qu'elles soient utilisées par des clients spécifiques.
Quel type de liaison peut-être versionné ?
Un module peut comporter un numéro de version, tout comme les liaisons d'importation
et d'exportation SCA. Les liaisons SCA héritent de leurs informations de version
du module auquel ils sont associés.
Remarque : À ce jour, seules les liaisons de type SCA
peuvent être versionnées.
La gestion des versions
est disponible en option pour les modules 6.2.x. Les modules créés et déployés avec
WebSphere Integration Developer et
WebSphere ESB 6.1.x
ne possèdent pas de versions et continuent de fonctionner selon le même principe.
Pour plus d'informations, reportez-vous aux rubriques relatives à la migration.
Les bibliothèques peuvent également être versionnées. Les modules qui utilisent une bibliothèque
possèdent une dépendance sur une version spécifique de cette dernière, et les bibliothèques
peuvent également avoir des dépendances sur de certaines versions d'autres bibliothèques.
Pour des informations détaillées sur la gestion des versions des bibliothèques, consultez le WebSphere Integration Developer centre de
documentation.
Aspects à prendre en compte lors du déploiement de modules versionnés
Vous pouvez déployer un module versionné durant la phase d'exécution 6.2.x et l'administrer
à partir des pages Modules SCA de la console d'administration.
WebSphere ESB prend en charge les scénarios de déploiement versionnés suivants :
- Installation d'un module versionné sur un serveur ou un cluster d'une cellule
- Installation de la même version d'un module unique sur un ou plusieurs serveurs ou clusters d'une cellule
- Installation de différentes versions d'un module sur le même serveur ou cluster
Le déploiement d'une nouvelle version d'un module ne remplace aucune version précédente du module. Les versions précédentes d'artefacts d'application délimités par une cellule
(dans ce cas, règles métier) sont remplacées.
Si vous souhaitez mettre une application à jour (par exemple, pour
apporter des corrections ou des améliorations mineures) sans modifier la version, cette
application mise à jour et ses artefacts remplaceront l'application et les artefacts existants,
à l'exception de toutes les stratégies de sécurité définies.
Tous les artefacts de stratégie de sécurité sont conservés durant la mise à jour
d'une application.
Pour conserver les informations de gestion des versions, le processus d'installation
modifie automatiquement le nom du module (via la commande
serviceDeploy ou
createVersionedSCAModuled)
pour s'assurer que ce dernier est unique au sein de la cellule. Ce changement est effectué
en ajoutant le numéro de version, un ID de cellule unique (ou les deux) au nom du
module d'origine.
nomModule_vvaleurVersion_idCelluleUnique
Aspects à prendre en compte lors de la liaison de modules versionnés
Après avoir déployé plusieurs versions d'un module sur un serveur
ou plusieurs instances d'un module sur des clusters, réfléchissez à la méthode
que vous allez employer pour lier des versions spécifiques de modules à des clients (susceptibles d'être ou non
versionnés).
- Liaison statique : pour ce type de liaison, utilisez simplement les outils
d'administration existants pour lier un module versionné à un client.
Vous devez spécifier le numéro de version du module dans la liaison statique.
- Liaison dynamique : dans le cas d'une liaison dynamique à des modules versionnés,
utilisez un composant de flux de médiation incluant les métadonnées de version du module (versionValue et versionProvider) et une fonction de routage adapté à la version du service.
Notez que pour utiliser le routage adapté à la version du service afin de lier des modules
versionnés de façon dynamique, tous les modules doivent être enregistrés auprès de WebSphere
Service Registry and Repository (WSRR).