Vengono associate diverse configurazioni durante la migrazione della configurazione del prodotto.
Sono possibili diversi scenari di migrazione. Lo strumento di migrazione associa oggetti e attributi esistenti nella versione da cui si sta eseguendo la migrazione ai corrispondenti oggetti e attributi nell'ambiente della nuova versione.
Gli strumenti di migrazione convertono i parametri di riga comandi appropriati a impostazioni della JVM (Java™ Virtual Machine) nella definizione del processo server. La maggior parte delle impostazioni viene associata direttamente. Alcune impostazioni non vengono migrate in quanto i loro ruoli nella configurazione di WebSphere ESB versione 6.2 non esistono, hanno significati diversi o hanno ambiti diversi.
Per avere informazioni su come cambiare le impostazioni di definizione del processo, consultare Impostazioni di definizione del processo nel centro informazioni di WebSphere Application Server Network Deployment, Versione 6.1. Per informazioni su come modificare le impostazioni della JVM (Java Virtual Machine), consultare Impostazioni JVM ( Java Virtual Machine) nel Centro informazioni di WebSphere Application Server Network Deployment, Versione 6.1.
Quando si esegue la migrazione di tutti i file EAR di WebSphere ESB a versione 6.2 mediante lo strumento wsadmin, lo strumento WBIPostUpgrade usa il valore predefinito per le dimensioni massime dell'heap Java, ovvero 64 MB, per installare i file EAR.
java.lang.OutOfMemoryError JVMXE006:OutOfMemoryError
Aumentare le dimensioni massime dell'heap Java e attenersi all'esempio seguente per installare l'applicazione.
Esempio di installazione di un'applicazione su WebSphere ESB versione 6.2
wsadmin -conntype NONE -javaoption -Xmx###m -c "$AdminApp install C:\\WebSphere\\ProcServer <nome_EAR_file> {-nodeployejb -appname nome_app -cluster nome_cluster}"
È possibile migrare un WebSphere ESB versione 6.0.x o 6.1.x nodo appartenente ad una cella verso WebSphere ESB versione 6.2 senza rimuovere il nodo dalla cella.
Eseguire per prima cosa la migrazione del gestore distribuzione, prima della migrazione dei nodi base della cella.
Utilizzare lo stesso nome di cella quando si migra da versione 6.0.x o 6.1.x a versione 6.2 . Se si utilizza un nome di cella differente, non sarà possibile eseguire correttamente la migrazione dei nodi federati alla cella WebSphere ESB versione 6.2.
La migrazione di un nodo di WebSphere ESB di base che si trova all'interno di una cella, a versione 6.2, migra anche l'agent del nodo a versione 6.2.
La migrazione copia directory dalla versione precedente alla configurazione di WebSphere ESB versione 6.2.
WebSphere migra tutti i file delle proprietà installati con versione 6.0.x o 6.1.x unendo le impostazioni nei file delle proprietà di versione 6.2.
La migrazione non esegue sovrapposizioni dei file delle proprietà.
La migrazione dei RAR e dei JAR a cui fanno riferimento le risorse J2C viene eseguita nel seguente modo:
Migrazione delle risorse a livello di cluster
<resources.j2c:J2CResourceAdapter xmi:id="J2CResourceAdapter_1112808424172" name="ims" archivePath="${WAS_INSTALL_ROOT}\installedConnectors\x2.rar"> ... </resources.j2c:J2CResourceAdapter>
Se si dispone di una risorsa a livello di cluster, tale risorsa deve essere nella stessa ubicazione in ciascun membro del cluster (nodo). Facendo riferimento all'esempio precedente, perciò, ciascun membro del cluster deve avere il file RAR installato nell'ubicazione ${WAS_INSTALL_ROOT}\installedConnectors\x2.rar. ${WAS_INSTALL_ROOT} viene risolto per ciascun membro del cluster per ottenere l'ubicazione esatta.
Nella migrazione di un gestore distribuzione, gli strumenti migrano i file del cluster sul gestore distribuzione, compresi i file resourcexxx.xml.
Se è stato inserito esplicitamente nel codice un percorso a un file RAR (archivePath="C:/WAS/installedConnectors/x2.rar" per esempio) in versione 6.0.x o 6.1.x, tuttavia, gli strumenti di migrazione di versione 6.2 non possono cambiare il valore dell'attributo archivePath di conseguenza in quanto questo interromperebbe la connessione a tutti gli altri membri del cluster non ancora migrati.
Durante la migrazione di un profilo autonomo, non viene migrato alcun esempio di WebSphere ESB. Esempi di versione 6.2 equivalenti sono disponibili per tutti gli esempi di versione 6.2
La sicurezza Java 2 viene abilitata per impostazione predefinita quando si abilita la sicurezza in WebSphere ESB versione 6.2. La sicurezza Java 2 richiede che le autorizzazioni di sicurezza vengano concesse esplicitamente.
Vi sono diverse tecniche che possono essere utilizzate per definire diversi livelli di sicurezza Java 2 in versione 6.2. Una di queste è creare un file was.policy all'interno dell'applicazione per abilitare tutte le autorizzazioni di sicurezza. Gli strumenti di migrazione richiamano il comando wsadmin per aggiungere un file was.policy esistente nella directory versione 6.2 properties alle applicazioni enterprise durante la loro migrazione.
Questa è l'impostazione predefinita.
Per esempio i keyfile e trustfile esistenti vengono estratti dal repertorio SSLConfig e vengono creati nuovi oggetti keystore e truststore.
Per poter mantenere le stesse impostazioni di sicurezza, è necessario migrare le impostazioni di sicurezza di WebSphere Application Server eventualmente impostate per la versione 6.0.2.x. Per maggiori informazioni sulla migrazione delle configurazioni di sicurezza alla versione 6.2, consultare Migrazione, coesistenza e interoperabilità - Considerazioni di sicurezza nel centro informazioni di WebSphere Application Server Network Deployment, Versione 6.1.
L'ubicazione di queste directory è tipicamente all'interno della directory di installazione di una versione precedente. L'ubicazione predefinita di stdin, stdout e stderr è la directory logs della root di installazione di WebSphere ESB versione 6.2.
Gli strumenti di lavoro tentano di migrare le directory passivation e di lavoro esistenti. Altrimenti verranno utilizzati i valori predefiniti di versione 6.2 del caso.
Per maggiori informazioni sulle directory passivation, consultare Impostazioni EJB container. Per maggiori informazioni sulle directory di lavoro, consultare Impostazioni di definizione del processo.
In uno scenario di coesistenza, l'uso di directory comuni a diverse versioni può creare problemi.
Gli strumenti di migrazione migrano tutte le porte. Gli strumenti registrano un avviso di conflitto di porta se è già definita una porta nella configurazione. È necessario risolvere tutti i conflitti di porta prima di poter eseguire i server contemporaneamente.
Se viene specificato il parametro -portBlock nel comando WBIPostUpgrade, viene assegnato un nuovo valore a ciascun trasporto migrato.
Per ulteriori informazioni sul comando WBIPostUpgrade, consultare Utilità di riga comandi WBIPostUpgrade.
Per ulteriori informazioni su canali e catene di trasporto, consultare Catene di trasporto.
È necessario aggiungere voci alias di host virtuale per ciascuna porta. Per ulteriori informazioni, consultare Configurazione degli host virtuali.
Il livello di specifica di J2EE (Java 2 Platform, Enterprise Edition) implementato in WebSphere ESB versione 6.0.x o 6.1.x ha richiesto modifiche comportamentali nel contenitore Web per l'impostazione del tipo di contenuto. Se un servlet writer predefinito non imposta il tipo di contenuto, il contenitore Web non solo non assegna un valore predefinito ma restituisce la chiamata come "null". Questa situazione può fare sì che alcuni browser visualizzino le tag di contenitore Web in modo non corretto. Per prevenire l'insorgere di questo problema, la migrazione imposta l'estensione IBM® autoResponseEncoding a "true" per i moduli Web durante la migrazione delle applicazioni enterprise.