Migración de una configuración de pasarela de servicios web para Versión 5.1

En WebSphere Application Server Versión 5.1, la pasarela de servicios web era un componente independiente con su propia interfaz de usuario. En las versiones posteriores del producto, la pasarela se integra en los servicios web habilitados para el bus de integración de servicios, y se vuelven a implementar como un mecanismo para ampliar y enlazar los servicios de entrada y salida.Utilice un script de mandatos wsadmin para migrar una configuración de pasarela existente desde un servidor de aplicaciones de Versión 5.1 a un servidor de aplicaciones o clúster en una versión posterior.

Antes de empezar

Considere si tiene que migrar las pasarelas existentes:
  • WebSphere Application Server Versión 5.0 ya no está soportado, por lo que debe migrar cualquier pasarela existente que se ejecute en los servidores de aplicaciones Versión 5.0 para ejecutarse en servidores de aplicaciones en el nivel actual del producto.
  • Las pasarelas de servicios web que se ejecutan en WebSphere Application Server Versión 5.1 pueden, sujetas a determinadas restricciones, coexistir con instancias de pasarela que se ejecutan en servidores de aplicaciones Versión 7.0 o posterior .
  • Una célula de Versión 7.0 o posterior puede contener los servidores de aplicaciones Versión 5.1, Versión 6 y Versión 7.0 o posterior. .
Para obtener más información, consulte Coexistencia: conservar o migrar una pasarela de Versión 5.1.

Puede migrar una pasarela de la Versión 5.1 que se esté utilizando para producción sin detener la pasarela; a continuación, las aplicaciones solicitantes pueden pasar a utilizar la nueva configuración de pasarela mientras la pasarela de la Versión 5.1 existente se sigue ejecutando.

Acerca de esta tarea

El proceso de migración toma una aplicación de pasarela de Versión 5.1 cuya configuración se haya exportado a un archivo XML y utiliza el archivo XML exportado para configurar las mismas funciones de pasarela en un solo servidor de aplicaciones o clúster en la versión posterior. Para ello, exporte la configuración de pasarela de Versión 5.1 y, a continuación, ejecute un script para migrar la configuración exportada a una nueva instancia de pasarela de un servidor de aplicaciones o clúster ya existente en la versión posterior.

La configuración de la Versión 5.1 se migra como se indica a continuación:
  • Como parte del proceso de migración, se creará automáticamente una instancia de pasarela.
  • Los servicios Gateway, los servicios de destino y las referencias UDDI se migran directamente.
  • También se migran las definiciones que hay en la pasarela de manejadores y listas de manejadores JAX-RPC. Debe asegurarse de que las clases de manejadores subyacentes estén disponibles durante la ejecución.
  • Las asignaciones de servicios Gateway a canales específicos se sustituyen por asignaciones equivalentes a pares de escucha de punto final y puerto de entrada específico (ya que en versiones posteriores la funcionalidad de un canal se comparte entre un escucha de punto final y un puerto de entrada). Cualquier uso de una canal SOAP de Apache se migra a un escucha de punto final SOAP sobre HTTP y un puerto de entrada.
  • Los filtros existentes no se migran. El uso de filtros está en desuso en Versión 5.1.1 y el soporte de los filtros se eliminó en la versión 7. El rol desempeñado anteriormente por los filtros lo lleva a cabo ahora una combinación de manejadores JAX-RPC y mediaciones de bus de integración de servicios.
  • Los clientes de servicios Web que se generan a partir del WSDL para el servicio de destino, no para el servicio Gateway, se marcan de forma predeterminada en versiones posteriores como si fueran un error.
  • Si utilizó el WSDL del servicio Gateway Versión 5.1 para generar los clientes de servicios Gateway y su enlace WSDL y estilo de codificación no es documento literal, después de la migración a una versión posterior debe volver a generar los apéndices de cliente utilizando el nuevo WSDL de servicio Gateway.
  • Los enlaces de WS-Security se migran como enlaces que cumplen la especificación WS-Security Draft 13. No obstante:
    • La versión final (1.0) de la especificación WS-Security (implementada en WebSphere Application Server Versión 6) no es compatible con la versión Draft 13 y, por consiguiente, WS-Security Draft 13 se ha dejado de utilizar en WebSphere Application Server Versión 6. El uso de la especificación del borrador 13 de WS-Security está en desuso y sólo debe utilizarla para permitir el uso continuado de una aplicación cliente de servicios web existente que se ha escrito en la especificación del borrador 13 de WS-Security.
    • Los objetos de enlace de WS-Security sólo se migran si el proceso de migración se ejecuta en la máquina en que funciona el servidor de destino en caso de un servidor autónomo, o en la máquina en que se ejecuta el gestor de despliegue en una configuración de Network Deployment.
    • Sólo se migran los objetos de enlace de WS-Security utilizados por una configuración WS-Security de servicio Gateway o servicio de destino. Cualquier objeto de enlace que se haya creado pero que no se utilice, no se migrará. Por ejemplo: si tiene una configuración de WS-Security que hace referencia a un objeto Información de firma, y éste hace referencia a un Ancla de confianza, los objetos Información de firma y Ancla de confianza se migrarán junto con la configuración de WS-Security que hace referencia a los mismos.
Nota:
  • La migración da por supuesto que las direcciones web externas para los servicios migrados no se modificarán. Esta suposición se basa en la expectativa de que estas direcciones están asociadas con un servidor web en vez de estarlo con la máquina en que está alojada la pasarela, y que, por lo tanto, el nombre de host y el número de puerto para estas direcciones no se ven afectados. Si en su configuración las direcciones web externas apuntan a la máquina de pasarela, modifique la configuración de escucha de punto final después de haber completado el proceso de migración.
  • Puede utilizar WebSphere Application Server Network Deployment para migrar a un único servidor que se ejecute bajo uno de los perfiles de configuración (servidor autónomo o gestor de despliegue). Sin embargo, es recomendable migrar a un solo servidor que se ejecute bajo un perfil de gestor de despliegue. Si migra a un perfil de servidor autónomo, no podrá utilizar la consola administrativa para modificar posteriormente la configuración de pasarela.
  • Los servicios web habilitados para bus de integración de servicios validan los mensajes de servicio web de forma más exhaustiva que en WebSphere Application Server Versión 5.1. Como consecuencia, algunas aplicaciones cliente que utilizan solicitudes o respuestas con formato defectuoso (donde las partes del mensaje reciben nombres erróneos), y que funcionan cuando se utiliza Versión 5.1, se identifican ahora como mensajes de formato defectuoso. Para ver los pasos que deben seguirse para resolver el problema, consulte Servicios web habilitados para bus: Limitaciones conocidas.

Para migrar una configuración de pasarela existente de un servidor de aplicaciones de la Versión 5.1 a la función de pasarela de un servidor de aplicaciones o clúster de una versión posterior, siga estos pasos:

Procedimiento

  1. Opcional: Elimine todos los filtros de la pasarela de la Versión 5.1.
    Puede migrar una pasarela que contiene filtros. Si embargo, los filtros no funcionan en versiones posteriores, por lo que es posible que prefiera eliminarlos de la configuración antes de realizar la migración efectuando los pasos siguientes:
    1. Compruebe si la pasarela de Versión 5.1 utiliza filtros. Si desea más información, consulte el tema WebSphere Application Server Versión 5.1: Listado y gestión de filtros desplegados en la pasarela.
    2. Elimine todos los filtros. Para obtener más información, consulte el tema de WebSphere Application Server Versión 5.1 : Eliminación de filtros de la pasarela de servicios web.
    Después de la migración, puede volver a crear la funcionalidad de los filtros utilizando una combinación de manejadores JAX-RPC y mediaciones de bus de integración de servicios. Si migra una pasarela de servicios web que incluye un filtro de direccionamiento, puede volver a crear las funciones de filtro.
  2. Elija un clúster o servidor de destino que sea un clúster o servidor único en la versión posterior y forme parte de una célula de Network Deployment.
  3. Configure el clúster o servidor de destino como miembro de un bus de integración de servicios.
  4. Configure un repositorio de SDO (Service Data Objects) en el ámbito de célula para el servidor o clúster de destino.
  5. Si migra enlaces EJB y desea que sigan utilizando un enlace codificado por RPC o cualquier enlace distinto al documento literal, añada un enlace del tipo correcto al WSDL de enlace EJB. Este paso es necesario porque el enlace predeterminado de pasarela de la Versión 5.1 está codificado con RPC, mientras que, en versiones posteriores, el enlace predeterminado es documento literal.
  6. Asegúrese de que el servidor de aplicaciones de origen (Versión 5.1) está ejecutándose y utilice la interfaz de usuario de pasarela de la Versión 5.1 para hacer una copia de seguridad de la configuración de pasarela del servidor de aplicaciones de la Versión 5.1 como configuración privada. Para obtener más información, consulte el tema de WebSphere Application Server Versión 5.1: Copia de seguridad de una configuración de pasarela.
  7. Opcional: Detenga el servidor de aplicaciones de la Versión 5.1.
    Nota: Si migra una pasarela que está en uso de producción, mantenga la pasarela de la Versión 5.1 en ejecución hasta que se complete la configuración de pasarela en la versión posterior y, a continuación, cambie las aplicaciones solicitantes a utilizar la nueva configuración de pasarela mientras la pasarela de la Versión 5.1 existente se sigue ejecutando. Sin embargo, no es necesario que ambas versiones de la pasarela se ejecuten al mismo tiempo, y es posible que tenga que detener el servidor Versión 5.1 antes de iniciar el servidor o clúster en la versión posterior (por ejemplo, si va a instalar el servidor o clúster en la versión posterior como una sustitución directa para el servidor Versión 5.1, en la misma máquina y utilizando los mismos números de puerto).
  8. Inicie el clúster o servidor de aplicaciones de destino en la versión posterior, y para un servidor o clúster único dentro de una célula gestionada, el gestor de despliegue de la célula de destino.
  9. Compruebe que todos los documentos WSDL que se han utilizado para definir los servicios de destino del servidor de aplicaciones de la Versión 5.1 estén disponibles en las ubicaciones proporcionadas. Si la ubicación WSDL es una referencia de UDDI, compruebe que el registro de UDDI referenciado está disponible.
  10. Opcional: Si la pasarela que se va a migrar utiliza manejadores JAX-RPC y listas de manejadores, asegúrese de que las clases de manejadores subyacentes estén disponibles durante la ejecución.
  11. Para migrar la configuración exportada a una nueva instancia de pasarela en el servidor de aplicaciones o clúster en la versión posterior, efectúe los pasos siguientes:
    1. Abra un indicador de mandatos y vaya al directorio raíz_servidor_aplicaciones/util.
    2. Ejecute el mandato siguiente:
      [IBM i]Nota: [IBM i]El cliente de scripts wsadmin se ejecuta desde Qshell. [IBM i]Para obtener más información, consulte Configuración de Qshell para ejecutar scripts de WebSphere mediante el script wsadmin.
      migratewsgw[AIX Solaris HP-UX Linux Windows][z/OS].ext -C=nombre_célula [-S=nombre_serviodr -N=nombre_nodo] 
                          [-X=nombre_clúster] -B=nombre_bus 
                           -G=nombre_archivo_configuración_pasarela_v5 
                          [-H=nombre_host_administración] [-A=puerto_administración] 
                          [-U=nombre_instancia_pasarela] [-P=prefijo_objeto] 
                          [-username=ID_usuario_WAS -password=contraseña_WAS]
      donde:
      • [AIX Solaris HP-UX Linux Windows][z/OS].ext es la extensión de archivo .bat para un sistema Windows o .sh para un sistema Unix o Linux.
      • Los corchetes ("[ ]") indican que un parámetro o conjunto de parámetros es opcional en determinadas circunstancias.
      • nombre_servidor y nombre_nodo juntos (para un solo servidor), o bien, nombre_clúster (para un clúster) definen el servidor o clúster al que se migra la configuración de pasarela.
      • nombre_célula, nombre_servidor y nombre_nodo (o nombre_clúster), nombre_host_administración y puerto_administración definen juntos la conexión con el servidor de aplicaciones (o clúster) en la versión posterior. nombre_servidor o nombre_clúster especifica el nombre del clúster o el servidor de aplicaciones de destino en el que se crean los escuchas de punto final y los destinos de puerto de salida. Si migra a un servidor o clúster que forma parte de una célula gestionada, nombre_host_administración y puerto_administración definen el nombre de host y el número de puerto de la administración de SOAP del gestor de despliegue. Si migra a un servidor que no forma parte de una célula gestionada, nombre_host_administración y puerto_administración definen el nombre de host y el número de puerto del servidor autónomo y son opcionales. Si se omiten, el mandato da por supuesto que los valores previstos son localhost:8880 (es decir, los valores predeterminados de WebSphere Application Server para un servidor autónomo).
        [IBM i]Nota: nombre_host_administración es obligatorio para la plataforma IBM i.
      • nombre_archivo_configuración_pasarela_v5 es la vía de acceso completa y el nombre de archivo del archivo de configuración XML de pasarela privado de la Versión 5.1 que se ha exportado.
      • nombre_bus y nombre_instancia_pasarela juntos definen la instancia de pasarela que va a crear dentro de este bus. El nombre_instancia_pasarela sólo es necesario si desea crear más de una instancia de pasarela en este bus. Si omite este parámetro opcional, a continuación, se asigna el nombre predeterminado.
      • prefijo_objeto es una serie que se utiliza como prefijo para los nombres de los objetos definidos por el proceso de migración. Si se omite, se utiliza el URI del espacio de nombres (el valor predeterminado urn:ibmwsgw) para los servicios migrados.
      • ID_usuario_WAS y contraseña_WAS son necesarios si el servidor de aplicaciones de destino o el clúster están protegidos por contraseña.
  12. Opcional: Si el proceso de migración cambia las direcciones web externas para los servicios migrados, modifique la configuración del escucha de punto final de modo que actualice estas direcciones. Debe hacerlo si las direcciones web externas apuntan a la máquina de pasarela en vez de hacerlo a un servidor web y ha migrado la pasarela a una máquina o un puerto diferentes de la misma máquina.

Qué hacer a continuación

Nota:
  • Si la pasarela de Versión 5.1 utilizaba filtros, vuelva a crear las funciones de filtro utilizando una combinación de manejadores JAX-RPC y mediaciones de bus de integración de servicios.
  • Si la configuración de pasarela incluye servicios Gateway que tengan varios servicios de destino, la configuración de la Versión 5.1 podría haber utilizado un filtro de direccionamiento para elegir un servicio de destino en particular. Si este es el caso, deberá configurar la pasarela migrada para elegir un servicio y puerto de destino a través de una mediación de direccionamiento.
  • Web Services Gateway en una versión posterior utiliza más memoria para procesar un mensaje, por lo que, si pasa un archivo adjunto grande a través de la pasarela migrada, podría recibir un error de memoria agotada en la máquina virtual Java. Para solucionar este problema, aumente el tamaño de almacenamiento dinámico JVM.

Icon that indicates the type of topic Task topic



Timestamp icon Last updated: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=twsg_coex_migrate
File name: twsg_coex_migrate.html