WebSphere Enterprise Service Bus, Versión 6.2.0 Sistemas operativos: AIX, HP-UX, i5/OS, Linux, Solaris, Windows


Configuración de la correlación durante la migración de la configuración del producto

Durante la migración de la configuración del producto se correlacionan diversas configuraciones.

La migración siempre incluye la migración de un perfil individual a otro perfil individual en la misma estación de trabajo o en una estación de trabajo distinta. Los ejemplos incluyen un gestor de despliegue de WebSphere ESB versión 6.1 que se migra a un perfil de gestor de despliegue de la versión 6.2 y un servidor autónomo de la versión 6.1 que se migra a un perfil de servidor autónomo de versión 6.2.
Nota: Sólo un perfil de servidor autónomo se puede migrar a una estación de trabajo distinta

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.

Puerto de programa de arranque
Las herramientas de migración correlacionan directamente un valor que no es por omisión con el entorno de la versión 6.2. Al migrar desde versión 6.0.2.x, si se especifica el parámetro -portBlock durante la llamada a WBIPostUpgrade, se da un valor de puerto nuevo a cada servidor que se migra a versión 6.2.
Parámetros de línea de mandatos

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.

Tamaño de almacenamiento dinámico Java para migrar archivos EAR

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.

Si un archivo EAR no se puede instalar durante la migración porque el tamaño de almacenamiento dinámico Java no es suficientemente grande, verá un mensaje similar al siguiente:
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

Suponga que:
Directorio raíz de instalación
C:\WebSphere\DeploymentManager
Símbolos de número (###)
Valor del tamaño de almacenamiento dinámico máximo
<nombre_archivo_EAR>
Nombre del archivo EAR
nombre_aplic
Nombre de la aplicación
nombre_clúster
Nombre del clúster en el que se debe instalar el archivo EAR
Para una mayor claridad, el mandato se visualiza en más de una línea.
wsadmin -conntype NONE
        -javaoption 
        -Xmx###m 
        -c "$AdminApp install 
            C:\\WebSphere\\ProcServer
                   <nombre_archivo_EAR> 
        {-nodeployejb 
         -appname nombre_aplic 
         -cluster nombre_clúster}"
Migración de un nodo de la versión 6.0.x o 6.1.x a uno de la versión 6.2

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.

Una célula puede tener nodos combinados, lo que quiere decir que puede contener algunos nodos de versión 6.2 y algunos nodos de versión 6.1.x.
Nota: Los nodos combinados no están soportados si se migra desde versión 6.0.2.x.
Archivo de política
WebSphere ESB versión 6.2 migra todos los archivos de política que se instalan con los archivos de política de la versión 6.0.x o 6.1.x con las siguientes características:
  • Se conservarán todos los comentarios que hay en el archivo de política de la versión 6.2. En la versión 6.2 no se incluirá ninguno de los comentarios del archivo de política de la versión 6.0.x o 6.1.x.
  • La migración no intentará fusionar permisos ni concesiones, es estrictamente una migración de tipo add. Si el permiso o concesión no se encuentra en el archivo de la versión 6.2, la migración la transportará.
  • La seguridad es un componente crítico; por lo tanto, la migración realiza sus adiciones al final del archivo .policy original justo después del comentario MIGR0372I: A continuación se indican permisos concedidos migrados. Esto se hace para ayudar a los administradores a verificar todos los cambios que la migración ha realizado en el archivo de política.
Propiedades y directorios lib/app

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.

Archivos de propiedades

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.

Archivadores de adaptador de recursos (RAR) referenciados por recursos J2C

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

Los recursos de nivel de clúster se configuran en los archivos resourcexxx.xml bajo los directorios de clúster. Por ejemplo:
<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.

En la migración de un nodo gestionado, las herramientas procesan cada adaptador J2C. Los archivos como archivos RAR se migran como se indica a continuación de la versión 6.0.x o 6.1.x a la versión 6.2:
  • Migración de la versión 6.0.2.x a la versión 6.2: la migración copia los archivos, como los archivos RAR, de WAS_INSTALL_ROOT en WAS_INSTALL_ROOT y de USER_INSTALL_ROOT en USER_INSTALL_ROOT
  • Migración de versión 6.1.x a versión 6.2: la migración copia los archivos de configuración de la manera siguiente:
    • Si instala RAR o JAR como parte de la instalación de WebSphere ESB, los archivos de configuración se migran al perfil de destino de migración y se actualizan para apuntar a la nueva versión de los archivos RAR y JAR.
    • Si instala los archivos RAR o JAR después de la instalación de WebSphere ESB, se producirá lo siguiente
      • Si instala los archivos RAR o JAR bajo la instalación anterior de WebSphere ESB, sólo se migran los archivos de configuración y tiene que copiar o instalar esos archivos RAR o JAR en el perfil de destino de migración y asegurarse de que la configuración sea correcta antes de iniciar el servidor.
      • Si instala los archivos RAR o JAR fuera de la instalación anterior de WebSphere ESB (lo que se recomienda), los archivos de configuración se migran y no es necesario que realice ninguna acción después de la migración.

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.

Ejemplos

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.

Seguridad
Nota: La siguiente información de seguridad sólo se aplica si migra desde versión 6.0.2.x

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.

Al migrar de WebSphere ESB versión 6.0.2.x a la versión 6.2, la decisión que tome sobre si migrar o no migrar el soporte a la compatibilidad de scripts hará que obtenga uno de los dos resultados siguientes.
  • Si opta por migrar el soporte a la compatibilidad de scripts, la configuración de seguridad se transporta a la versión 6.2 sin ningún cambio.

    Éste es el valor por omisión.

  • Si elige no migrar para soportar la compatibilidad de script, la configuración de seguridad se convierten en la configuración por omisión para WebSphere ESB versión 6.2. La configuración de seguridad de la versión 6.2 por omisión actúa casi igual que en las versiones anteriores, pero hay algunos cambios.

    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.

Directorios de entrada estándar, salida estándar, error estándar, pasivación y trabajo

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.

Puertos de transporte

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.

Módulos Web

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.


concept Tema de concepto

Condiciones de uso | Comentarios


Icono de indicación de la hora Última actualización: 05 julio 2010


http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/topic//com.ibm.websphere.wesb620.doc/doc/cmig_vtv_configmap.html
Copyright IBM Corporation 2005, 2010. Reservados todos los derechos.
Este centro de información está basado en tecnología Eclipse (http://www.eclipse.org).