WebSphere Enterprise Service Bus, Version 6.2.0 Systèmes d'exploitation: AIX, HP-UX, i5/OS, Linux, Solaris, Windows


Gestion des versions d'applications de service

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 : 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).

concept Rubrique concept

Conditions d'utilisation | Commentaires en retour


Icône d'horodatage Dernière mise à jour: 07 juillet 2010


http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/topic//com.ibm.websphere.wesb620.doc/doc/cadm_versioningsca.html
Copyright IBM Corporation 2005, 2010. All Rights Reserved.
Ce centre d'information est mis en service par la technologie Eclipse (http://www.eclipse.org).