Coexistence : conservation ou migration d'une passerelle de Version 5.1
Les passerelles de services Web en cours d'exécution sur WebSphere Application Server Version 5.1 peuvent, avec certaines restrictions, coexister avec les instances de passerelle qui s'exécutent sur les Version 7.0 ou ultérieures serveurs d'applications,. Vous pouvez également migrer les passerelles et les serveurs d'applications Version 5.1 vers WebSphere Application Server Version 7.0 ou ultérieures. La présente rubrique vous aide à choisir entre la conservation des passerelles de Version 5.1 et leur migration en expliquant les restrictions relatives à la coexistence des passerelles et l'approche permettant leur migration.
Coexistence avec des passerelles de Version 5.1
- L'application de passerelle des services Web Version 5.1 n'est pas prise en charge sur les serveurs d'applications Version 7.0 ou ultérieures.
- Les applications de programme d'écoute de noeuds final des technologies d'intégration de services ne sont pas prises en charge si elles sont installées sur des serveurs d'applications de la Version 5.1.
- Pour modifier la configuration d'une passerelle en cours d'exécution sur un serveur d'applications Version 5.1, utilisez un navigateur Web plutôt que la console d'administration pour accéder à l'interface utilisateur de la passerelle Version 5.1.
Si le déploiement n'est pas affecté par ces restrictions et que les passerelles Version 5.1 s'exécutent sur des serveurs d'applications Version 5.1 autonomes, aucune intervention n'est requise.
Si votre déploiement n'est pas affecté par ces restrictions et que vos passerelles de Version 5.1 fonctionnent sur des serveurs d'application de Version 5.1 faisant partie de cellules WebSphere Application Server Network Deployment, vous pouvez continuer d'utiliser les passerelles et serveurs d'applications de Version 5.1 même si vous migrez les cellules de la Version 5.1 ou la Version 6 vers la Version 7.0 ou ultérieures. Toutefois, lorsque vous migrez une cellule, toutes les passerelles de Version 5.1 déjà configurées sur un serveur d'applications de cette cellule sont remplacées par une passerelle vide. Pour conserver et restaurer vos configurations de passerelle de Version 5.1, vous devez en premier lieu suivre les étapes figurant dans la rubrique Conservation d'une passerelle Version 5.1 lors de la migration d'une cellule.
Migration de passerelles de Version 5.1
- La migration peut se produire parallèlement à l'exécution de la passerelle d'origine et n'entraîne aucun dysfonctionnement de la configuration existante.
- Chaque exécution de la commande de migration agit sur une seule configuration de passerelle.
- Une configuration de passerelle est migrée dans une instance de passerelle, dans un bus d'intégration de services. Il est possible de migrer plusieurs passerelles dans le même bus, mais dans ce cas, les URI des espaces de nom de passerelle doivent être différents.
- Les modules d'écoute de noeud final de l'instance de passerelle se trouvent tous sur le même serveur d'applications ou cluster ; les emplacements des destinations de port pour les appels sortants se trouvent tous sur le même serveur d'applications ou cluster.
- Les noms des objets et destinations créés commencent tous par l'URI de l'espace de nom de la passerelle et sont concaténés avec un signe deux-points (":"). Par exemple, avec l'URI de l'espace de nom par défaut, une destination de réponse du service de passerelle est appelée : urn:ibmgateway:gatewayservicenameReply. Ce préfixe peut être remplacé par un paramètre dans la commande de migration.
- Tous les services cible sont migrés dans de nouveaux objets OutboundService. Les objets OutboundService existants ne peuvent pas être automatiquement réutilisés par la configuration migrée.
- Une liste de gestionnaires JAX-RPC est créée pour chaque combinaison service de passerelle/canal et service de passerelle/service cible/port. Ces listes ne sont pas partagées, même si elles contiennent les mêmes gestionnaires, dans le même ordre.
- Des objets de liaison et de configuration WS-Security (Draft 13) sont créés pour
chaque combinaison service de passerelle/service de passerelle et service cible.
Ces
objets ne sont pas partagés, même s'ils possèdent tous les mêmes valeurs d'attribut.
Les noms de tous les objets
créés sont définis en fonction du nom donné au service de communications entrantes ou sortantes créés par l'outil
de migration :
- Les configurations WS-Security créées pour chaque service ont le même nom que le service lui-même, le suffixe _Inbound ou _Outbound est ajouté.
- Les objets de configuration WS-Security créés en tant qu'enfants ont le même nom que le type d'objet, suivis des caractères _x, où x correspond au nombre d'objets créés par l'outil de migration pour le type de service. Par exemple, le premier objet d'intégrité requis pour un service donné est appelé RequiredIntegrity_1.
- Les liaisons WS-Security créées ont un nom constitué du nom du port suivi du suffixe _Req_Rec, _Req_Snd, _Res_Rec ou _Res_Snd.