Livre Blanc - Migration WebSphere 6.1

Websphere propose de gérer la tenue en charge par une architecture de type « scalabilité horizontale » aussi appelée scale-out. Le principe de ces architectures est de mettre en cluster des serveurs de puissance limitée à faible coût plutôt que d'ajouter des ressources (CPU et RAM) à des serveurs complexes. Pour augmenter la puissance de traitement, il suffit d'ajouter un nouveau nœud au cluster. Les serveurs lames et les serveurs 1U sont particulièrement adaptés à ce type d'architecture.

Le mode de facturation de Websphere est particulièrement adapté aux serveurs lames (x86 et Power) pour lesquels IBM divise par deux le prix des licences (2). Par ailleurs, si les serveurs lames sont fréquemment utilisés avec Linux ou Windows(3), les Unix « historiques » sont aussi disponibles sous forme de lames(4). Il est aussi intéressant de noter que les architectures serveurs lames sont compatibles avec la virtualisation des ressources.

L'architecture On Demand de Websphere eXtended Deployment est l'approche scale-out la plus poussée de la gamme Websphere. Il faut toutefois garder en mémoire que Websphere XD est adapté à des besoins tant en termes de tenue à la charge qu'en disponibilité. La plupart des architectures Websphere se contenteront des versions Base et ND.

Pour aller plus loin :

• IBM Education : Websphere Application Server V6 - high Availability Overview - v6 : HA configuration (pdf)
• Redbook : Using WebSphere Extended Deployment V6.0 To Build an On Demand Production Environment

Le tableau suivant indique les versions logicielles minimum pour installer Websphere Application Server V6.1 :

Le stockage sous forme de fichiers de la configuration Websphere introduit avec la V4 permet l'utilisation de systèmes de sauvegarde incrémentale des fichiers. La fréquence de sauvegarde est adaptable suivant le type de fichier pour limiter l'impact des procédures de sauvegarde sur la performance des environnements :

Les systèmes génériques de sauvegarde et restauration tels que BrightStor ARCserve Backup, HP OpenView Storage Data Protector ou EMC Networker ne nécessitent pas de mise à jour. Les équipes d'exploitation doivent seulement configurer le système pour qu'il sauvegarde les nouvelles arborescences de répertoires (voir « Annexe 2 : Fichiers et répertoires à prendre en compte lors des sauvegardes »).

Les systèmes de sauvegarde et restauration spécialisés avec un plugin Websphere tels que IBM Tivoli Storage Manager for Application Servers doivent d'abord être mis à jour pour prendre en compte Websphere 6.1 (l'arborescence des répertoires à changé). Ensuite, les équipes d'exploitation doivent configurer le système pour qu'il sauvegarde l'application.

Les besoins d'exploitation et de supervision sont très différents selon les environnements. Les environnements de production et de préproduction nécessitent fiabilité et rigueur alors que les environnements de développement, d'intégration et de recette doivent faciliter les déploiements fréquents et le travail des équipes de développement.

Les procédures utilisées sur les environnements de production doivent être guidés par la rigueur et la fiabilité. Ce sont des environnements qui sont beaucoup plus à l'écoute des besoins des équipes de production que des besoins des équipes de développement.

Bien que celui puisse être contraignant, la même rigueur doit s'appliquer à l'environnement de pré production qui permet ainsi de valider les procédures destinées aux environnements de production.

A l'inverse, les environnements de développement (intégration, recette, tests …) doivent eux être au service des équipes projet. La productivité doit y être privilégiée pour apporter de l'agilité aux équipes projets. Les aspects d'auditabilité, de traçabilité et de fiabilité sont moins importants hors de la production.

Les environnements de production et préproduction devraient donc être :

• exploités par des scripts d'administration et des systèmes d'administration centralisés ;
• supervisés par des systèmes de supervision intégrés ;
• sécurisés avec des firewalls stricts et des mots de passe seulement connus des équipes d'exploitation.

Les autres environnements (développement, intégration, tests, etc.) devraient pour leur part être :

• exploités par la console d'administration de Websphere et des scripts ;
• supervisé avec parcimonie par un système centralisé de supervision (systèmes de fichier, CPU, mémoire) ;
• peu sécurisés avec des mots de passe connus des équipes de développement et des firewalls lâches (cloisonnant les environnements les uns des autres mais pas entre les développeurs et les serveurs).

Websphere expose ses données de performance (Performance Monitoring Infrastructure - PMI) au travers de la PerfServlet et du Connecteur JMX. La version 6.0 a introduit un nouveau format de données de performance qui repose sur J2EE 1.4 Performance Data Framework (un sous ensemble de JSR-77 : J2EE Management) ; ce nouveau format est incompatible avec le format des versions 5.x. Cependant, la PerfServlet supporte un mode compatible ascendant grâce à l'ajout du paramètre « version=5 » dans l'URL d'accès (voir Infocenter : PerfServlet output).

Les systèmes d'administration et de supervision qui reposaient sur la PerfServlet et le connecteur JMX supporteront sans difficulté Websphere 6.1. La plupart des outils de supervision pour Websphere supportent déjà la version 6.1. On retrouve notamment :

• BMC Performance Manager for Web Application Servers (anciennement BMC Patrol) (cf BMC Product Availability/Compatibility) ;
• HP OpenView Smart Plug-in for IBM WebSphere Application Server ;
• IBM Tivoli Composite Application Manager for WebSphere ;
• Mercury SiteScope Websphere Solution Template ;
• Hyperic HQ Agent plugin for Websphere.

IBM HTTP Server (IHS) est le serveur Web le mieux intégré aux architectures Websphere. La version 6.1 a introduit des fonctionnalités qui rendent IHS désormais beaucoup plus intéressant que Apache.

IHS peut désormais être intégralement administré (stop, start et configuration) au travers de la console wWb et du scripting Websphere. Cette nouvelle fonctionnalité améliore la fiabilité des déploiements et diminue les coûts d'exploitation (5).

L'architecture Websphere de référence est d'utiliser un répartiteur IP qui va indifféremment répartir les requêtes sur tous les serveurs Web et déléguer à ces derniers le routage vers les serveurs d'applications. Le répartiteur fournit la haute disponibilité et les serveurs Web fournissent la tenue à la charge et le routage.

Déléguer à un répartiteur IP le routage est sensiblement plus complexe que se reposer sur les serveurs Web, car il faut mettre à jour la configuration du répartiteur lors des installations/désinstallations d'applications (les équipes sont le plus souvent différentes et les technologies ne sont pas intégrées), alors que la propagation des configurations aux plugins des serveurs Web est elle transparente.

Voici les prérequis logiciels pour les différents serveurs Web supportés :

Source : List of supported software for WebSphere Application Server V6.1

L'accès aux bases de données depuis un serveur J2EE est maintenant complètement banalisé. Il est souhaitable d'utiliser des drivers JDBC de type 4 (100 % pure Java) pour accéder aux SGBD.

Concernant l'utilisation des DataSources, Websphere 6.1 incite plus fortement au respect de la norme J2EE en rendant deprecated les lookups JNDI directs(6). Il faut dorénavant déclarer une <resourceref> dans le fichier web.xml (ou ejb-jar.xml) et utiliser la syntaxe ctx.lookup(« java:comp/env/jdbc/my-data- source ») au lieu de l'ancienne syntaxe ctx.lookup(« jdbc/my-data-source »).

Voici les prérequis logiciels pour les principales bases de données :

Source : List of supported software for WebSphere Application Server V6.1

La sécurité Websphere permet l'utilisation d'un serveur LDAP pour stocker les profils utilisateurs. Les architectures hautement disponibles devraient utiliser le mécanisme de clustering LDAP introduit dans la version 6.0. Il n'est alors plus nécessaire d'utiliser une solution externe telle qu'un répartiteur IP pour mettre en place la haute disponibilité LDAP.

Voici les prérequis logiciels pour les principaux serveurs LDAP du marché :

Les API d'accès aux middlewares de messages (MOM) ont connu une évolution très similaire à celles des drivers JDBC. Les premiers connecteurs de MOM en Java reposaient sur des bibliothèques au style de programmation C qui faisaient appel aux bibliothèques natives (Websphere MQ Client …) ; cette situation était comparable aux premiers drivers JDBC de type 2 qui reposaient sur les bibliothèques natives des SGBD (Oracle Call Interface / OCI …).

Aujourd'hui, comme les drivers JDBC de type 4 remplacent leurs prédécesseurs de type 2, les connecteurs JMS d'accès à des MOM sont matures et vont remplacer les connecteurs historiques.

Il est de plus intéressant de noter que l'API JMS se répand au delà du monde Java et que les éditeurs de MOM développent des API similaires sur d'autres langages comme C++ ou .Net (en particulier Websphere MQ avec XMS(7) et Tibco EMS avec ses API .Net, C++ et Cobol).

Websphere offre désormais une forte intégration à JMS et les bénéfices de cette API sont nombreux pour les projets. En premier lieu, JMS offre tous les atouts d'un standard : découplage entre les éditeurs, qui se concentrent sur le développement du connecteur et les développeurs applicatifs, qui n'ont qu'une seule API à apprendre ; documentation pléthorique ; profusion des bibliothèques supportant le standard (en particulier le framework Spring) ; disponibilité de ressources formées sur le marché des développeurs Java. Il est d'ailleurs possible d'utiliser une implémentation JMS alternative lors des phases de développement afin de simplifier les tests unitaires (Apache ActiveMQ est à ce titre très intéressant). L'introduction dans JMS 1.1 d'une API unifiée pour les modèles point-à-point et publication-souscription améliore de surcroît l'évolutivité des applications.

Notons enfin que JMS est désormais intégré aux fonctionnalités d'administration et de supervision de Websphere, et qu'il est possible d'évoluer vers Embedded Messaging Engine de Websphere (SIBus) pour remplacer Websphere MQ.

Voici les prérequis logiciels pour l'intégration de Websphere MQ :

Websphere 6.1 propose désormais d'emblée la haute disponibilité pour tous les services critiques. Le seul service qui n'offre pas de reprise sur panne transparent est le Deployment Manager pour ses fonctions de modification de la configuration et de déploiement des applications ; ce service n'est cependant pas critique pour l'exécution des applications déjà déployées.

Websphere 6 a introduit le 'hot standby' et le 'peer failover' des services centraux critiques (routage WLM, moteur de Messages JMS, gestionnaire de transactions…). Le gestionnaire de haute disponibilité (High Availability Manager) exécute les services critiques (dont lui-même) sur un serveur disponible ; si ce serveur devient indisponible, le service est transféré automatiquement sur un autre serveur disponible.

Par ailleurs, la version 6 a introduit le support de la haute disponibilité transparente du serveur LDAP grâce à un mécanisme de clustering(8). Il n'est donc plus nécessaire de recourir à des systèmes de haute disponibilité avec un répartiteur IP comme c'était le cas sur les versions précédentes.

L'utilisation des transactions distribuées se répand avec l'essor des architectures SOA. Un scénario désormais fréquent est l'utilisation de transactions distribuées JDBC et JMS. Websphere 6 réduit grandement le temps de restauration des transactions distribuées en cas de panne d'un serveur grâce à l'introduction d'un nouveau mécanisme de 'failover' du Gestionnaire de Transaction basé sur un simple répertoire partagé(9).

WAS ND V6 High Availability - Transaction service high availability using NAS

Pour aller plus loin sur les aspects de haute disponibilité :

• IBM Education Assistant : IBM WebSphere Application Server Workload management and high availability ;
• IBM Redbook : WAS ND v6 High Availability.

La V6 a introduit la Websphere Installation Factory pour créer des packages d'installation de Websphere Application Server. Ces packages peuvent être composés des binaires avec des fixpacks, des paramètres de configuration et des EAR prédéployés. Cet outil devrait être utilisé sur les grandes topologies Websphere qui nécessitent des installations répétées de serveurs. Dans ces scénarios, Websphere Installation Factory offrira une productivité accrue et une plus grande fiabilité grâce à l'automatisation du processus et la diminution du risque de facteur humain inhérent aux procédures d'installation complexes.

La nouvelle console d'administration offre la même ergonomie que celle de la version 5.1 avec une apparence visuelle nouvelle liée à la modularité de la console. Cette modularité permet à la gamme des produits Websphere d'utiliser une console d'administration unifiée dans laquelle les middlewares (serveur d'application, ESB, portail…) s'intègrent sous forme de plugins.

Les opérations d'administration de Websphere peuvent être réalisées aussi bien par scripts que par la console d'administration.

Les scripts offrent de nombreux avantages :

• traçabilité : les scripts et leurs logs d'exécution peuvent être archivés ;
• répétabilité : les scripts peuvent être rejoués ;
• fiabilité : une fois les scripts validés (par exemple les scripts de déploiement d'applications), ils réduisent fortement le risque du facteur humain dans les procédures d'exploitation ;
• productivité : l'exécution de scripts est beaucoup plus efficace que de déléguer des tâches d'administration à faible valeur ajoutée à des humains. Ce gain est particulièrement sensible lors des processus de build/déploiement.

Jython remplace désormais JACL comme langage de scripting privilégié. Jython est le langage de scripting privilégié de Weblogic et Websphere. Ce langage est en général perçu comme beaucoup plus facile d'utilisation que JACL (dérivé de TCL)

Les objets AdminApp et AdminTask (AdminTask a été introduit en V6) sont les API privilégiées de scripting de Websphere. Elles offrent des commandes orientées tâches de haut niveau quand AdminConfig est une API de plus bas niveau par laquelle on manipule directement les documents de configuration de Websphere.

Websphere offre un haut niveau de compatibilité des scripts entre les versions 5.x et 6.1.

• compatibilité des langages de scripting :
  • JACL a été migré de la version 1.2.6 à la version 1.3.2. Cette nouvelle version introduit le support de la syntaxe d'expressions régulières de TCL qui n'est pas compatible ascendante avec les motifs d'expression régulières de la version 1.2.6 ;
  • Jython a été migré de la version 2.1a3 à la version 2.1. Cette migration est compatible ascendante ;
• changements des objets de configuration
  • l'attribut transactionLogDirectory a été déplacé de ApplicationServer.TransactionService à ServerEntry.recoveryLog. L'ancienne valeur reste disponible tant que la nouvelle valeur n'est pas modifiée
   

  Sélectionnez

  V5.x Jython syntax
  wsadmin> txService = AdminConfig.list('TransactionService', server1)
  wsadmin> txLogDirectory =
  AdminConfig.showAttribute(txService,'transactionLogDirectory')
  V6.1 Jython syntax
  wsadmin>serverEntry = AdminConfig.list('ServerEntry')
  ...
  wsadmin> recoveryLog = AdminConfig.showAttribute(serverEntry, 'recoveryLog')
  wsadmin> txLogDirectory = AdminConfig.showAttribute(recoveryLog, 'transactionLogDirectory')

• • l'attribut processDefinition de l'objet Server a été renommé en processDefinitions qui est devenu une liste d'ID séparés par des caractères espaces (e.g. « [id1 id2 … idx] »)

V5.x Jython syntax
wsadmin>javaProcessDef = AdminConfig.showAttribute(server, 'processDefinition')
V6.1 Jython syntax
wsadmin>javaProcessDefsAsString = AdminConfig.showAttribute(server,
'processDefinitions')
wsadmin>javaProcessDefs = javaProcessDefsAsString[1:len(javaProcessDefsAsString) -
1].split(' ')
wsadmin>javaProcessDef = javaProcessDef[0]

La principale évolution de la version 6.1 est la consolidation des outils de diagnostic et de résolution des incidents dans la console d'administration Web et dans le nouveau IBM Support Assistant. Les outils spécifiques Websphere sont dorénavant tous disponibles au travers de la console d'administration Web et les outils génériques java sont eux regroupés dans IBM Support Assistant.

Les outils de diagnostic disponibles dans la console sont les suivants :

• Fournisseurs de diagnostic
  Ces outils fournissent les informations de diagnostic de chacun des composants du serveur Websphere (données d'état, données de configuration et tests d'autodiagnostic). Le nombre de ces outils est amené à augmenter avec les versions de Websphere. Ces outils sont similaires aux Defaults Tests disponibles dans Websphere MQ 6.
• Tivoli Performance Viewer (TPV)
  Outil de visualisation des données de performances collectées par la l'infrastructure PMI (Performance Monitoring Infrastructure). TPV a migré d'un client lourd à une interface Web intégrée dans la console d'administration. Le gain est une facilité accrue d'utilisation (il n'est plus nécessaire d'installer l'application cliente et de gérer les problèmes de firewalls) ; cependant, l'ergonomie n'est pas encore au niveau de celle qu'offrait la version précédente qui était distribuée sous forme de client lourd (c'est particulièrement le cas lorsqu'on suit un nombre important d'indicateurs).
• Visionneuse de Classloader
  Cet outil permet de diagnostiquer les problèmes de classpath et de chargement de classe en affichant les .jar chargés par les classloaders hiérarchiques d'une application. La visionneuse de classloader optionnelle en V5 est désormais intégrée en standard à la version 6.

Les outils de diagnostic disponibles dans IBM Support Assistant sont les suivants :

• IBM Support Assistant (ISA) ISA est le nouveau socle basé sur Eclipse des outils de diagnostic et de support IBM ;
  • regroupe les outils de diagnostic (pour Websphere, DB2, Rational …) ;
  • offre un point d'entrée de recherche unifié pour les informations sur les produits IBM (fixes, technotes, infocenters …) ;
  • facilite la communication avec le support IBM grâce à un assistant de création de PMR ;
• IBM Heap Analyzer (aka Memory Dump Diagnostic for Java)
  Outil de diagnostic des fuites mémoire.
• IBM Pattern Modeling and Analysis Tool for Java Garbage Collector (PMAT)
  Outil d'aide au paramétrage de la Heap des JVM et de diagnostic des problèmes de fragmentation du Heap. PMAT va être remplacé par le nouveau Extensible Verbose GC Toolkit.
• IBM Thread and Monitor Dump Analyzer for Java Technology
  Outil de diagnostic des problèmes de threads des JVM (threads suspendus, interverrous, goulets d'étranglement…).
• Extensible Verbose GC Toolkit
  EVTK est le successeur de PMAT. EVTK a été conçu comme un plugin de ISA, il est donc parfaitement intégré et préfigure l'ergonomie qu'offriront les futurs outils de troubleshooting IBM.

Si Websphere 5.X était naturellement associé à WSAD, Websphere 6.1 nécessite d'utiliser un nouvel environnement de développement dont le choix est cette fois-ci ouvert.

Rational Application Developer (RAD) est le successeur naturel de Websphere Studio Application Developer (WSAD). Dans la lignée de WSAD, RAD est l'IDE qui offre tous les assistants pour exploiter les fonctionnalités spécifiques de Websphere (EJB, Portlet, JSF, SOAP …).

Cependant, la place de RAD est complètement différente aujourd'hui de celle que WSAD occupait à son époque. La banalisation des standards J2EE, le succès du lightweight J2EE (Struts/Spring/Hibernate) et l'essor d'Eclipse ont stimulé le marché des IDE qui n'est plus le domaine réservé des éditeurs haut de gamme et des produits coûteux.

Eclipse Web Tools Project est devenu un IDE mature qui répond aux besoins de beaucoup de projets lightweight J2EE (Struts/Spring/Hibernate). Il est reconnu pour sa simplicité d'utilisation, sa gratuité et sa popularité auprès des développeurs.

Pour répondre au succès d'Eclipse Web Tools Project, IBM a introduit Websphere Application Toolkit, un IDE intermédiaire entre Eclipse et le sophistiqué et onéreux RAD. Websphere AST peut être vu comme une Eclipse Web Tools Project avec les plugins spécifiques Websphere comme des éditeurs de fichiers de configuration spécifiques Websphere et environnement de scripting wsadmin (voir la matrice des fonctionnalités infra). Cependant, l'absence d'un Tomcat Test Environment diminue sensiblement l'intérêt de Websphere AST comme IDE principal d'une équipe de développement.

L'appropriation du nouvel IDE (RAD, AST ou Eclipse) par les équipes de développement sera facilité du fait qu'ils disposent tous de l'ergonomie proposée par le projet Eclipse.

La richesse et la complémentarité de ces IDE et l'omniprésence d'Eclipse permet aujourd'hui d'équiper les équipes de développement d'un mix d'Eclipse, de Websphere AST et de RAD qui seront utilisés en fonctions des tâches à accomplir.

Ainsi, les projets Lightweight J2EE (Struts/Spring/Hibernate) pourront utiliser majoritairement Eclipse Web Tools Project complété de quelques postes Websphere AST voire RAD pour les tâches spécifiques Websphere. Spring, Hibernate et Struts étant validés aussi bien sur Websphere que sur Tomcat, il est possible de développer sur Tomcat Test Environment et d'intégrer sur Websphere.

En revanche, les projets 100 % pure Websphere (Websphere-JSF, Websphere-SOAP, EJB …) utiliseront principalement RAD pour apporter un Websphere Test Environment à chaque développeur. Eclipse sera alors utilisé à la marge pour des tâches très ponctuelles.

Les serveurs d'applications J2EE assurent une très grande compatibilité ascendante et permettent de déployer des EAR de différentes versions (J2EE 1.3, J2EE 1.4 …) sur un même serveur.

WAS V6 - Migration Guide / 3.1 J2EE compatibility / 3.1.1 Incremental migration

Le point de vigilance concerne les bibliothèques embarquées par Websphere. Les applications devraient, en théorie, être qualifiées avec les nouvelles versions de bibliothèques embarquées par Websphere (Xalan, Xerces …). Cependant, ces bibliothèques sont très matures et une utilisation « dans leur esprit » ne devrait pas présenter de problème de compatibilité ascendante ; il est donc souvent suffisant de valider ces nouvelles bibliothèques lors du test de non régression globale de passage à la V6.1 sur l'environnement de recette/intégration.

La migration des scripts d'administration doit être réalisée avant l'installation du Deployment Manager sur lequel ces scripts sont utilisés.

La forte compatibilité ascendante des API d'administration diminue les risques liés à cette opération mais il est sécurisant d'anticiper l'éventuelle nécessité de recourir à des procédures d'exploitation manuelle en attendant la correction des derniers problèmes sur les scripts d'administration.

L'environnement de prototypage est particulièrement adapté à la validation des nouveaux scripts.

Ce scénario simplifié ne décrit pas les opérations de migration des outils de monitoring, de sauvegarde & restauration. C'est le scénario du cas simple d'un serveur non fédéré dans une cellule Websphere Network Deployment.

• installation des binaires de Websphere 6.1 à côté de ceux de la version existante ;
• application du dernier fixpack de Websphere 6.1 ;
• configuration des outils d'exploitation (sauvegarde & restauration, supervision…) ;
• utilisation le « Migration Wizard » pour configurer Websphere 6.1 ;
• arrêt de l'ancienne version de Websphere et démarrage de la version 6.1 ;
• activation des outils d'exploitation ;
• lorsque la nouvelle version est stable (plusieurs semaines), désinstaller l'ancienne version.

Une cellule Websphere est composée d'un Deployment Manager, d'un ou plusieurs nœuds, d'un ou plusieurs serveurs et éventuellement de serveurs Web.

• Big Bang
  Le scénario de migration par Big Bang mettant à jour tous les serveurs simultanément est fortement déconseillé, car cette approche est inutilement risquée. Websphere est conçu pour permettre une migration progressive avec la possibilité de faire coexister des serveurs 5.x et 6.x dans une cellule 6.1. De plus, il est possible de revenir en arrière sur la plupart des opérations de migration et de redémarrer le composant problématique en version 5.x.
• Migration progressive
  La migration progressive est le scénario privilégié. Il minimise les risques de régression et permet aux équipes d'avancer à leur rythme. Les grandes étapes d'une migration progressive sont :
  • migration du Deployment Manager ;
  • migration des plugins des serveurs Web ;
  • migration des serveurs avec une granularité au cluster (tous les serveurs d'un cluster simultanément, les clusters sont migrés les uns après les autres).

Websphere permettant de déployer des EAR des précédentes versions J2EE (1.2 et 1.3), la migration de l'IDE et des processus de développement n'est pas contrainte à être strictement en phase avec la migration de l'infrastructure.

La migration des IDE se déroule dans un processus classique de définition des besoins, suivie de l'évaluation et du prototypage, puis enfin du déploiement dans les équipes.

La mise à jour des API J2EE sera fera lors de l'évolution des applications si cette migration s'avère nécessaire. Il n'y a aucune urgence à procéder à cette évolution.

IBM fournit dans Websphere AST et dans RAD un J2EE Application Migration Wizard qui simplifiera la tâche des équipes de développement.

La migration vers Java 5 est essentiellement un projet de formation des équipes et d'accompagnement. Les grandes étapes en sont :

• déploiement des IDE « Java 5 ready » dans les équipes de développement. L'amélioration de l'ergonomie de ces IDE de dernière génération aura un impact fort sur la productivité et la satisfaction des équipes de développement ;
• formation à l'utilisation des nouvelles bibliothèques de Java 5 (util.concurrent…) sans utiliser encore les nouvelles syntaxes Java 5 ;
• enfin, formation aux nouvelles syntaxes Java 5 (génériques, annotations, types énumérés…). Les plus grands gains seront les annotations (Hibernate et Spring) et les génériques pour clarifier les listes (Hibernate).

Cette approche permettra d'accompagner les équipes de développement pour garantir la cohérence de l'utilisation de ces nouvelles fonctionnalités.

• Si nécessaire, mise à jour du serveur Web lui même (IHS devrait être migré en V6.1) :
  • installation des binaires du serveur Web V6.1.x ;
  • configuration du nouveau serveur ;
  • configuration des outils d'exploitation (sauvegarde & restauration, supervision…) du serveur Web v6.1 : mettre à jour les outils si nécessaire puis configurer ;
  • arrêt de l'ancien serveur Web ;
  • démarrage du serveur Web v6.1 ;
  • mise à jour du plugin du serveur Web ;
    • installer les plugins v6.1 sur les serveurs Web ;
    • configurer le serveur Web pour utiliser le plugin v6.1 ;
    • redémarrer le serveur Web pour qu'il utilise le nouveau plugin ;
    • la configuration des plugins des serveurs Web doit être regénérée et redéployée lors de la migration de chaque nœud.

• installation des binaires V6.1.x du Deployment Manager à côté de ceux de l'ancienne version ;
• configuration des outils d'exploitation (sauvegarde & restauration, supervision…) du Deployment Manager v6.1 : mettre à jour les outils si nécessaire puis configurer ;
• configuration du Deployment Manager v6.1 en important la configuration du Deployment Manager v5.x/6.0 avec le Websphere Migration Wizard ;
• vérification des logs de l'exécution du Websphere Migration Wizard ;
• arrêt du Deployment Manager V5.x/V6.0 ;
• démarrage du Deployment Manager v6.1 ;
• activation des outils d'exploitation du Deployment Manager (sauvegarde & restauration, supervision) ;
• regénération et redéploiement de la configuration des plugins des serveurs Web si le Deployment Manager est accédé au travers de serveurs Web ;
• tests.

• installer les binaires de la version 6.1.x à côté de ceux de l'ancienne version ;
• configuration des outils d'exploitation (sauvegarde & restauration…) du nœud et des serveurs d'application : mettre à jour les outils si nécessaire puis configurer ;
• configuration du nœud et des serveurs d'application v6.1 en important la configuration du nœud et des serveurs d'application v5.x/6.0 avec le Websphere Migration Wizard ;
• vérification des logs de l'exécution du Websphere Migration Wizard ;
• arrêt du nœud et des serveurs d'application V5.x/V6.0 ;
• démarrage du nœud et des serveurs d'application v6.1 ;
• activation des outils d'exploitation du Nœud (sauvegarde & restauration, supervision) ;
• regénération et redéploiement de la configuration des plugins des serveurs Web ;
• tests.