Durante la migración de la configuración del producto se correlacionan diversas configuraciones.
Hay muchos casos de migración posibles. Las herramientas de migración correlacionan los objetos y atributos existentes en la versión de la que está migrando a los objetos y atributos correspondientes en el entorno de la nueva versión.
Las herramientas de migración convierten los parámetros de línea de mandatos apropiados en valores JVM (Java™ Virtual Machine) en la definición de proceso de servidor. La mayoría de los valores se correlacionan directamente. Algunos valores no se migran porque sus roles en la configuración de WebSphere ESB versión 6.2 no existen, tienen distintos significados o ámbitos diferentes.
Para obtener información sobre cómo cambiar los valores de definición de proceso, consulte Valores de definición de proceso en el centro de información de WebSphere Application Server Network Deployment, versión 6.1. Para obtener información sobre cómo cambiar los valores de Java Virtual Machine, consulte Valores de Java Virtual Machine en el centro de información de WebSphere Application Server Network Deployment, versión 6.1.
Al migrar todos los archivos EAR de WebSphere ESB a la versión 6.2 utilizando la herramienta wsadmin, la herramienta WBIPostUpgrade utiliza el valor de tamaño máximo por omisión de almacenamiento dinámico Java de 64 MB para instalar los archivos EAR.
java.lang.OutOfMemoryError JVMXE006:OutOfMemoryError
Aumente el tamaño máximo de almacenamiento dinámico Java y siga el ejemplo siguiente para instalar la aplicación.
Ejemplo de instalación de la aplicación en WebSphere ESB versión 6.2
wsadmin -conntype NONE -javaoption -Xmx###m -c "$AdminApp install C:\\WebSphere\\ProcServer <nombre_archivo_EAR> {-nodeployejb -appname nombre_aplic -cluster nombre_clúster}"
Puede migrar un nodo de WebSphere ESB versión 6.0.x o 6.1.x que pertenezca a una célula a la WebSphere ESB versión 6.2 sin eliminar el nodo de la célula.
Migre primero el gestor de despliegue, antes de migrar todos los nodos base de la célula.
Utilice el mismo nombre de célula al migrar de la versión 6.0.x o 6.1.x a la versión 6.2. Si utiliza un nombre de célula distinto, la migración de los nodos federados a la célula de la WebSphere ESB versión 6.2 no se podrá realizar satisfactoriamente.
Al hacer la migración de un nodo WebSphere ESB de base que está dentro de una célula a la versión 6.2 también se migrará el agente de nodo a la versión 6.2.
La migración copia los archivos de los directorios de la versión anterior en la configuración de WebSphere ESB versión 6.2.
WebSphere migra todos los archivos de propiedades que se han instalado con versión 6.0.x o 6.1.x fusionando los valores en los archivos de propiedades de versión 6.2.
La migración no sobrescribe los archivos de propiedades.
Los RAR y JAR a los que hacen referencia los recursos J2C se migran de la manera siguiente:
Migración de recursos a nivel de clúster
<resources.j2c:J2CResourceAdapter xmi:id="J2CResourceAdapter_1112808424172" name="ims" archivePath="${WAS_INSTALL_ROOT}\installedConnectors\x2.rar"> ... </resources.j2c:J2CResourceAdapter>
Si tiene un recurso a nivel de clúster, este recurso debe estar en la misma ubicación en cada miembro del clúster (nodo). Por consiguiente, utilizando el ejemplo anterior, cada miembro de clúster debe tener instalado el archivo RAR en la ubicación ${WAS_INSTALL_ROOT}\installedConnectors\x2.rar. ${WAS_INSTALL_ROOT} se resuelve en cada miembro del clúster para obtener la ubicación exacta.
En la migración de un gestor de despliegue, las herramientas migran los archivos de clúster del gestor de despliegue, incluidos los archivos resourcexxx.xml.
Sin embargo, si ha codificado una vía de acceso para un archivo RAR (por ejemplo, archivePath="C:/WAS/installedConnectors/x2.rar") en versión 6.0.x o 6.1.x, las herramientas de migración de la versión 6.2 no pueden cambiar el atributo archivePath de modo que lo refleje porque esto afectaría a los demás miembros del clúster que no se han migrado.
Durante la migración de un perfil autónomo, no se migra ningún ejemplo de WebSphere ESB. Hay disponibles ejemplos equivalentes de la versión 6.2 para todos los ejemplos de la versión 6.2.
La seguridad de Java 2 se habilita por omisión cuando se habilita la seguridad en WebSphere ESB versión 6.2. La seguridad de Java 2 requiere que se otorguen de forma explícita los permisos de seguridad.
Existen varias técnicas que puede utilizar para definir diferentes niveles de seguridad de Java 2 en la versión 6.2. Una es crear un archivo was.policy como parte de la aplicación para habilitar todos los permisos de seguridad. Las herramientas de migración llaman al mandato wsadmin para añadir un archivo was.policy existente en el directorio properties de la versión 6.2 a las aplicaciones de empresa a medida que se migran.
Éste es el valor por omisión.
Por ejemplo, los archivos de claves y los archivos de confianza se retiran del repertorio SSLConfig y se crean nuevos objetos del almacén de claves y almacén de confianza.
Si desea mantener los mismos valores de seguridad, necesitará migrar los valores de seguridad de WebSphere Application Server que se hayan podido establecer para la versión 6.0.2.x. Para obtener más información sobre cómo migrar las configuraciones de seguridad a la versión 6.2, consulte Migración, coexistencia e interoperatividad - Consideraciones de seguridad en el centro de información de WebSphere Application Server Network Deployment, versión 6.1.
La ubicación de estos directorios normalmente está dentro del directorio de instalación de una versión anterior. La ubicación por omisión de stdin, stdout, y stderr es el directorio logs del directorio raíz de instalación de WebSphere ESB versión 6.2.
Las herramientas de migración intentan migrar directorios de pasivación y trabajo existentes. De lo contrario, se utilizan los valores por omisión adecuados de la versión 6.2.
Para obtener más información sobre los directorios de pasivación, consulte Valores de contenedor EJB. Para obtener más información sobre los directorios de trabajo, consulte la publicación Valores de definición de proceso.
En una situación de coexistencia, si se utilizan directorios comunes entre versiones pueden surgir problemas.
Las herramientas de migración migran todos los puertos. Las herramientas registran cronológicamente un aviso de conflicto entre puertos si ya hay un puerto definido en la configuración. Debe resolver todos los conflictos entre puertos para poder ejecutar servidores simultáneamente.
Si se especifica el parámetro -portBlock en el mandato WBIPostUpgrade, se asigna un nuevo valor a cada transporte que se migra.
Para obtener más información sobre el mandato WBIPostUpgrade, consulte el apartado Programa de utilidad de línea de mandatos WBIPostUpgrade.
Si desea más información sobre los canales y las cadenas de transporte, consulte Cadenas de transporte.
Debe añadir manualmente entradas de alias de sistema principal virtual para cada puerto. Para obtener más información, consulte Configuración de sistemas principales virtuales.
El nivel de especificación de J2EE (Java 2 Platform, Enterprise Edition) implementado en WebSphere ESB versión 6.0.x o 6.1.x necesitaba cambios de comportamiento en el contenedor Web para establecer el tipo de contenido. Si un servlet por omisión no establece el tipo de contenido, no sólo el contenedor Web no lo tomará como valor por omisión sino que devolverá la llamada como valor "null". Esta situación puede hacer que algunos navegador muestren incorrectamente los códigos del contenedor Web resultantes. Para evitar que se produzca este problema, la migración establece la extensión autoResponseEncoding IBM® en "true" para los módulos Web cuando migra las aplicaciones de empresa.