WebSphere Integration Developer, Versión 6.2 Sistemas operativos: Linux, Windows


IBM WebSphere Integration Developer Versión 6.2

Guía de migración

Versión 6 Release 2

Nota

Antes de utilizar esta información y el producto que soporta, lea la información en el apartado Avisos.

Esta edición se aplica a la versión 6, release 2, de WebSphere Integration Developer.

Copyright International Business Machines Corporation 2005, 2009.

Contenido

Capítulo 1. Migrar a WebSphere Integration Developer
Capítulo 2. Migración de versiones anteriores de WebSphere Integration Developer
Consideraciones para el proceso de migración versión a versión
Niveles de versión de desarrollo y de despliegue
Capítulo 3. Migración a WebSphere Process Server desde WebSphere InterChange Server
Vías de acceso soportadas para la migración
Tareas de preparación para la migración de WebSphere InterChange Server
Migración desde WebSphere Business Integration Server Express (WBISX)
Casos de ejemplo de migración de WebSphere InterChange Server
Consideraciones para el proceso de migración de WebSphere InterChange Server
Consideraciones: desarrollo general
Consideraciones: programas de utilidad de código comunes
Consideraciones: agrupaciones de conexiones de base de datos
Consideraciones: objetos de negocio
Consideraciones: plantillas de colaboración
Consideraciones: correlaciones
Consideraciones: relaciones
Consideraciones: clientes de infraestructura de acceso
Consideraciones: prevención de colisiones de bases de datos
Consideraciones: Postmigración
Migrar artefactos de WebSphere InterChange Server utilizando el asistente de migración
Verificar la migración de WebSphere InterChange Server
Trabajar con los errores de migración de WebSphere InterChange Server
Artefactos de WebSphere InterChange Server manejados por las herramientas de migración
API de WebSphere InterChange Server soportadas
Correlacionar el DataObject de WebSphere Process Server desde el XML de WebSphere InterChange Server
Capítulo 4. Migrar a WebSphere Integration Developer desde WebSphere MQ Workflow
Tareas de preparación para la migración de WebSphere MQ Workflow
Migrar WebSphere MQ Workflow utilizando el asistente de migración
Optimizar los procesos de negocio migrados
Verificar la migración de WebSphere MQ Workflow
Limitaciones del proceso de migración (desde WebSphere MQ Workflow)
Capítulo 5. Migración desde WebSphere Studio Application Developer Integration Edition
Migrar el espacio de trabajo
Vías de migración soportadas para migrar artefactos origen
Preparar los artefactos origen para la migración
Consideraciones anteriores a la migración
Migrar espacios de trabajo utilizando el asistente de migración de WebSphere Integration Developer
Migrar espacios de trabajo mediante WSADIEWorkspaceMigration
Verificar la migración de artefactos origen
Trabajar con los errores de migración de artefactos origen
Limitaciones de la migración de artefactos origen
Información de migración adicional
Crear componentes SCA e Importaciones SCA para los servicios en la aplicación para volver a conectar
Migrar un servicio Java
Migrar un servicio EJB
Migrar un proceso de negocio a una invocación de servicio de proceso de negocio
Migrar un servicio Web (SOAP/JMS)
Migrar un servicio Web (SOAP/HTTP)
Migrar un servicio JMS
Migrar un servicio J2C-IMS
Migrar un servicio ECI J2C-CICS
Migrar un servicio EPI J2C-CICS
Migrar un servicio J2C-HOD
Migrar un servicio transformador
Escenario de consumo para la migración de servicios
Crear Exportaciones SCA para acceder al servicio migrado
Migrar los enlaces de EJB y de proceso EJB
Migrar los enlaces de JMS y de proceso JMS
Migrar el enlace de servicios Web de IBM (SOAP/JMS)
Migrar el enlace de servicios Web de IBM (SOAP/HTTP)
Migrar el enlace de servicios Web de Apache (SOAP/HTTP)
Migrar al modelo de programación de SCA
Migrar las llamadas de API WSIFMessage a las API SDO
Migrar el código de cliente de WebSphere Business Integration Server Foundation
Migrar los fragmentos de código BPEL Java de WebSphere Business Integration Server Foundation
Migrar interacciones con WebSphere Business Integration Adapters
Migrar interfaces WSDL que tienen tipos de matriz codificados para SOAP
Suprimir manualmente definiciones de WSIF (Infraestructura de invocación de servicios Web) 5.1
Avisos
Términos de uso

Capítulo 1. Migrar a WebSphere Integration Developer

WebSphere Integration Developer Versión 6.2 proporciona las herramientas necesarias para migrar el entorno actual.

Nota: Una vez que actualice a WebSphere Integration Developer 6.2, no podrá devolver los proyectos a WebSphere Integration Developer 6.1.x. Tampoco hay soporte disponible para un usuario de 6.2 que incorpora su código a un repositorio o exporta proyectos y luego los comparte con un usuario de WebSphere Integration Developer 6.1.x.

Los temas siguientes describen los conceptos, información de consulta e instrucciones pasos a paso para la migración de WebSphere Integration Developer:

Capítulo 2. Migración de versiones anteriores de WebSphere Integration Developer

Migración desde versiones anteriores de WebSphere Integration Developer a WebSphere Integration Developer 6.2. Esto se conoce como migración versión-a-versión.

Por qué y cuándo se efectúa esta tarea

La migración a WebSphere Integration Developer 6.2 conserva la estructura básica de la aplicación existente, con necesidades de reconfiguración mínimas. Tenga en cuenta que el proceso versión-a-versión no tiene un asistente de migración asociado a él.

Los temas siguientes proporcionan más instrucciones en el proceso de migración versión-a-versión de WebSphere Integration Developer:

Consideraciones para el proceso de migración versión a versión

Cuando migra desde una versión anterior de WebSphere Integration Developer a la versión 6.2, la mayor parte de la migración se realiza automáticamente. No obstante, hay una serie de consideraciones a tener en cuenta, que pueden precisar de configuración manual adicional.

Las consideraciones siguientes están pensadas para ayudar en el proceso de migración versión-a-versión:

Adaptadores
Aplicaciones que utilizan niveles anteriores de adaptador se pueden migrar rápidamente al nivel actual con un programa de utilidad. Para obtener más información, consulte el tema "Migración de aplicaciones utilizando niveles de adaptador previos" en la sección de enlace más abajo.

Eventos de CEI
Los modelos de supervisor de WebSphere Integration Developer no se pueden volver a crear, pero se pueden utilizar en WebSphere Integration Developer 6.2, si ya estaban creados.

Editor de definiciones de eventos
Este editor quedó en desuso en WebSphere Integration Developer 6.1.

Sincronización
La sincronización entre WebSphere Business Modeler y WebSphere Integration Developer sólo funcionará si el modelo se creó en WebSphere Business Modeler 6.1.2 o una versión posterior y se utiliza en WebSphere Integration Developer 6.1.2 o una versión posterior. La sincronización con Rational Asset Manager 7.1 sólo funciona con proyectos que se hayan migrado a WebSphere Integration Developer 6.2.

Niveles de versión de desarrollo y de despliegue

Su decisión sobre los niveles de versión necesarios en su entorno dependerán de los niveles de versión con los que se desarrollaron sus aplicaciones.

WebSphere Process Server 6.2 y WebSphere Integration Developer 6.2 son compatibles con releases anteriores según se indica:

Nota: Para sistemas i5/OS, no hay versiones previas instaladas.

Capítulo 3. Migración a WebSphere Process Server desde WebSphere InterChange Server

WebSphere Integration Developer proporciona las herramientas necesarias para migrar desde WebSphere InterChange Server.

Por qué y cuándo se efectúa esta tarea

La migración desde WebSphere InterChange Server a WebSphere Process Server está soportada mediante las siguientes funciones en WebSphere Integration Developer:

Nota: Consulte las notas del release para obtener información acerca de las limitaciones relacionadas con la migración en este release de WebSphere Process Server.

Aunque la migración de artefactos origen está soportada, es aconsejable realizar análisis y pruebas exhaustivas para determinar si las aplicaciones resultantes funcionarán según lo esperado en WebSphere Process Server, o si será necesario un rediseño de las mismas posterior a la migración. Esta recomendación se basa en las siguientes limitaciones de la paridad funcional entre WebSphere InterChange Server y esta versión de WebSphere Process Server. En esta versión de WebSphere Process Server no hay soporte equivalente a estas funciones de WebSphere InterChange Server:

Nota: WebSphere Business Integration Server Express (WBISX) incluye los mismos tipos de artefactos que WebSphere InterChange Server. Sólo dos características, Reglas de negocio (Business Rules) y Analizador de negocio (Business Probe), no están soportadas en la migración.

Vías de acceso soportadas para la migración

Las herramientas de migración de WebSphere Process Server tienen soporte para la migración desde WebSphere InterChange Server versión 4.3 o versiones posteriores o WebSphere Business Integration Server Express versión 4.4 o versiones posteriores.

Antes de la migración, tenga en cuenta los requisitos siguientes:

Nota:

Tareas de preparación para la migración de WebSphere InterChange Server

Antes de migrar a WebSphere Process Server desde WebSphere InterChange Server mediante WebSphere Integration Developer, primero debe asegurarse de que ha preparado correctamente el entorno.

Por qué y cuándo se efectúa esta tarea

Estas herramientas de migración se pueden invocar desde los elementos siguientes:

La entrada de las herramientas de migración es un archivo jar de depósito exportado desde WebSphere InterChange Server. Por tanto, antes de acceder a las herramientas de migración a través de cualquiera de estas opciones, primero debe realizar las tareas siguientes:

  1. Cerciorarse de que ejecuta una versión de WebSphere InterChange Server que puede migrarse a WebSphere Process Server. Consulte el tema "Vías de migración soportadas para WebSphere InterChange Server".
  2. Exportar los artefactos origen de WebSphere InterChange Server a un archivo jar de depósito mediante el mandato de WebSphere InterChange Server repos_copy tal como se describe en la documentación de WebSphere InterChange Server. El asistente precisa como entrada un archivo JAR del repositorio de WebSphere InterChange Server. Este archivo JAR debe ser una archivo autocontenido con respecto a las aplicaciones que se migran. Esto es, todos los artefactos a los que hacen referencia cualquiera de los artefactos del archivo JAR también deben estar incluidos en el archivo JAR. Para asegurar que el archivo JAR del repositorio que se generará sea autocontenido, ejecute el mandato repos_copy con la opción -vr antes de exportar el repositorio del servidor (así se valida el repositorio). Si el repositorio es válido, repos_copy graba la salida siguiente en la consola: Validation Succeeded. All Dependencies Resolved. (Validación correcta. Se han resuelto todas las dependencias.) Si el repositorio no es válido,repos_copy muestra una lista de dependencias que hay que resolver. Resuelva las dependencias antes de exportar el repositorio. Exporte los artefactos del repositorio y cree el archivo JAR de repositorio, utilizando el mandato repos_copy de WebSphere InterChange Server con la opción -o (para obtener más detalles, consulte la documentación de WebSphere InterChange Server 4.3, incluyendo cómo exportar componentes individuales).

Migración desde WebSphere Business Integration Server Express (WBISX)

Puede utilizar el asistente de migración de WebSphere Integration Developer para migrar los artefactos de WebSphere InterChange Server desde un entorno WebSphere Business Integration Server Express.

Por qué y cuándo se efectúa esta tarea

Para obtener más información acerca de la migración desde un entorno WebSphere Business Integration Server Express, consulte el tema Migración desde WebSphere InterChange Server o WebSphere Business Integration Server Express de WebSphere Process Server Information Center.

Si tiene instalada localmente la documentación de WebSphere Process Server o WebSphere ESB, puede encontrar esta información en Migración desde WebSphere InterChange Server o WebSphere Business Integration Server Express.

Para obtener información relativa a la descarga de documentación del servidor, consulte la sección Visualizar o descargar la documentación de WebSphere Process Server.

Casos de ejemplo de migración de WebSphere InterChange Server

Hay varios casos de ejemplo de migración de WebSphere InterChange Server soportados por WebSphere Integration Developer.

Los casos de ejemplo siguientes describen el proceso de migración de WebSphere InterChange Server:

Migrar un adaptador EJB de WebSphere Business Integration a un bean de sesión sin estado de WebSphere Process Server

El asistente de migración ofrece la opción de realizar la migración a un enlace JMS que se conecte al adaptador de WebSphere Business Integration existente o a un bean de sesión sin estado nuevo. La migración generará artefactos de esqueleto.

Migrar un adaptador HTTP de WebSphere Business Integration a un enlace nativo de WebSphere Process Server

Si el conector HTTP se ha configurado con un escucha de protocolo, será necesario modificar la aplicación cliente antes de conectarse al conector migrado. Por ejemplo, si el conector se denomina HTTPConnector, está a la escucha en el puerto 8080 y utiliza el URL /wbia/samples/webservices, al realizar la migración a WebSphere Process Server, el puerto será el 9080 (el puerto WC_defaulthost) y el URL pasará a ser /HTTPConnectorWeb/wbia/samples/http. En WebSphere InterChange Server, puede acceder a esta ubicación mediante http://localhost:8080/wbia/http/samples, mientras que en WebSphere Process Server será http://localhost:9080/HTTPConnectorWeb/wbia/http/samples .

El asistente de migración ofrece la opción de realizar la migración a un enlace JMS que se conecte al adaptador de WebSphere Business Integration existente o a un enlace HTTP nuevo. El asistente permitirá seleccionar un manejador de datos ICS predeterminado, crear un esqueleto de manejador de datos WPS o utilizar un manejador de datos personalizado. El manejador de datos predeterminado del asistente de migración es el manejador de datos XML.

Este escenario de migración también admite el direccionamiento dinámico de punto final.

Migrar un adaptador JMS de WebSphere Business Integration a un enlace nativo JMS o JMS genérico de WebSphere Process Server

El asistente de migración ofrece la opción de realizar la migración a un enlace JMS que se conecte al adaptador de WebSphere Business Integration existente o a un enlace JMS o JMS genérico nuevo. El asistente permitirá seleccionar un manejador de datos ICS predeterminado, crear un esqueleto de manejador de datos WPS o utilizar un manejador de datos personalizado. Si se elige la opción de manejador de datos predeterminado, se suministrará el CwDataHandler.

Si selecciona el enlace JMS, necesitará crear el JMS genérico, la fábrica de conexiones de cola, las colas JMS y los puertos de escucha JMS y también generar un archivo de enlaces nuevo que incluya entradas para las colas. Consulte WebSphere Process Server Information Center para obtener más información acerca del trabajo con enlaces JMS. Si tiene instalada localmente la documentación de WebSphere Process Server, puede encontrar esta información en Enlaces JMS. Para obtener información relativa a la descarga de documentación del servidor, consulte la sección Visualizar o descargar la documentación de WebSphere Process Server.

Si selecciona el enlace JMS genérico, necesitará crear el JMS genérico, la fábrica de conexiones de cola y las colas JMS y también generar un archivo de enlaces nuevo que incluya entradas para las colas. Los puertos de escucha se crean durante el despliegue. Consulte WebSphere Process Server Information Center para obtener más información acerca del trabajo con enlaces JMS genéricos. Si tiene instalada localmente la documentación de WebSphere Process Server, puede encontrar esta información en Enlaces JMS genéricos. Para obtener información relativa a la descarga de documentación del servidor, consulte la sección Visualizar o descargar la documentación de WebSphere Process Server.

JMS o JMS genérico admite el direccionamiento dinámico de punto final. Debido a ello, la cola de envío de la importación no se utiliza y la migración deja este valor en blanco. Deberá suministrar un valor para poder desplegar e iniciar el módulo.

Migrar un adaptador MQ de WebSphere Business Integration a un enlace nativo MQ o MQ JMS de WebSphere Process Server

El asistente de migración ofrece la opción de realizar la migración a un enlace JMS que se conecte al adaptador de WebSphere Business Integration existente o a un enlace MQ o MQ JMS nuevo.

MQ o MQ JMS admiten el direccionamiento dinámico de punto final. Debido a ello, la cola de petición no se utiliza y la migración deja este valor en blanco. Deberá suministrar una cola válida (pero se recomienda no utilizarlo en caso de problemas) para poder desplegar e iniciar el módulo. Suministre también una cola de respuesta válida para la exportación.

El asistente permitirá seleccionar un manejador de datos ICS predeterminado, crear un esqueleto de manejador de datos WPS o utilizar un manejador de datos personalizado. Si se elige la opción de manejador de datos predeterminado, se suministrará el CwDataHandler.

Si selecciona MQ JMS, deberá configurar adicionalmente la cola de destino y la fábrica de conexiones. Abra la correlación de salida de MFC y edite el URL en el Paso personalizado #3 para incluir el nombre de la fábrica de conexiones. Un URL de ejemplo es parecido al siguiente:

jms:/queue?destination=MQOUTPUT&connectionFactory=&targetService=Output

Especifique el valor entre connectionFactory= y el símbolo &. La serie final sería:

jms:/queue?destination=MQOUTPUT&connectionFactory=MYCONNECTIONFACTORY&targetService=Output

Migrar un adaptador de servicios web de WebSphere Business Integration a un enlace nativo HTTP de WebSphere Process Server

Si el conector WS se ha configurado con un escucha de protocolo, será necesario modificar la aplicación cliente antes de conectarse al conector migrado. Por ejemplo, si el conector se denomina WSConnector, está a la escucha en el puerto 8080 y utiliza el URL /wbia/samples/webservices, al realizar la migración a WebSphere Process Server, el puerto será el 9080 (el puerto WC_defaulthost) y el URL pasará a ser /WSConnectorWeb/wbia/samples/webservices.

Existen dos escenarios posibles para este tipo de migración:

  1. Si el adaptador de servicios Web utiliza el protocolo de transporte HTTP, el asistente de migración ofrecerá la opción de realizar la migración a un enlace JMS que se conecte al adaptador de WebSphere Business Integration existente o a un enlace HTTP nuevo.
  2. Si el adaptador de servicios Web utiliza el protocolo de transporte JMS, la única opción de migración será el enlace JMS que se conecte al adaptador de WebSphere Business Integration existente.

Tenga en cuenta que, en este tipo de migración, el asistente no permitirá seleccionar un manejador de datos personalizado.

Este escenario de migración también admite el direccionamiento dinámico de punto final.

Consideraciones para el proceso de migración de WebSphere InterChange Server

Las siguientes consideraciones están destinadas a ayudar en el desarrollo de artefactos de integración para WebSphere InterChange Server. Al ajustarse a estas directrices, facilitará la migración de artefactos de WebSphere InterChange Server a WebSphere Process Server.

Estas recomendaciones sólo deben utilizarse como guía. Puede haber casos en los que sea necesario desviarse de estas directrices. En estos casos, debe tener cuidado de limitar el ámbito de la desviación para minimizar la cantidad de trabajo que debe realizarse de nuevo para migrar los artefactos. Tenga en cuenta que las directrices indicadas aquí no son recomendaciones generales para el desarrollo de artefactos de WebSphere InterChange Server. Su ámbito está limitado a aquellas consideraciones que pueden afectar a la facilidad de los artefactos que pueden migrarse en el futuro.

Consideraciones: desarrollo general

Existen varias consideraciones que se aplican ampliamente a la mayoría de los artefactos de integración. En general, los artefactos que aprovechan los recursos suministrados por las herramientas y que se ajustan a los modelos de metadatos obligatorios en ellas se migrarán con mayor fluidez. También es probable que los artefactos con extensiones y dependencias externas significativas requieran más intervención manual durante la migración.

La lista siguiente resume las consideraciones para el desarrollo general de soluciones basadas en WebSphere InterChange Server para facilitar la migración futura:

Es importante que las soluciones de integración se ajusten al modelo de programación y a la arquitectura suministrados por WebSphere InterChange Server. Cada uno de los componentes de integración de WebSphere InterChange Server juega un papel bien definido dentro de la arquitectura. Desviaciones significativas con respecto a este modelo dificultarán la migración de contenido a los artefactos adecuados de WebSphere Process Server.

Otra práctica genérica que mejorará la correcta migración de proyectos futuros consiste en documentar el diseño del sistema. Asegúrese de capturar la arquitectura y el diseño de integración, incluyendo el diseño funcional y los requisitos de calidad del servicio, las interdependencias de los artefactos compartidos en los proyectos y también las decisiones de diseño tomadas durante el despliegue. Esto le ayudará en el análisis del sistema durante la migración y minimizará la necesidad de volver a realizar trabajos.

Para crear, configurar y modificar definiciones de artefactos, utilice sólo las herramientas de desarrollo suministradas. Evite la manipulación manual de metadatos de artefactos (por ejemplo, editar archivos XML directamente), que pueden dañar los artefactos para la migración.

Siga estas directrices al desarrollar código Java dentro de plantillas de colaboración, correlaciones, programas de utilidad de código habituales y otros componentes:

Utilice sólo las API publicadas en la documentación del producto WebSphere InterChange Server para los artefactos. Estas API se indican con detalle en las guías de desarrollo de WebSphere InterChange Server. Las API de compatibilidad se suministran en WebSphere Process Server para las API de WebSphere InterChange Server publicadas. Aunque WebSphere InterChange Server tiene muchas interfaces internas que puede utilizar, no se recomienda dicho método, ya que no se garantiza que estas interfaces tengan soporte en el futuro.

Cuando diseñe lógica de negocio y reglas de transformación en correlaciones y plantillas de colaboración, intente evitar bibliotecas de programas de utilidad de código común desarrolladas por campo, incluidas como archivadores Java (archivos *.jar) en la vía de acceso de clases de WebSphere InterChange Server, ya que deberá migrarlas manualmente.

Utilice la herramienta de edición de actividades siempre que sea posible. Con ello se asegurará de que la lógica se describa mediante metadatos que puedan convertirse más fácilmente a los artefactos nuevos.

En los fragmentos de código Java que deban desarrollarse, es aconsejable que el código sea lo más simple y atomizado posible. El nivel de sofisticación del código Java debe ir por orden de scripts, implicación de evaluaciones básicas, operaciones y cálculos, formateo de datos, conversiones de tipos, etc. Si es necesaria una lógica de aplicación más extensa o sofisticada, considere la posibilidad de utilizar EJB ejecutados en WebSphere Application Server para encapsular la lógica y utilizar llamadas de servicio Web para invocarla desde WebSphere InterChange Server. Utilice bibliotecas JDK estándar en lugar de bibliotecas externas o de terceros, que deberían migrarse por separado. Reúna también toda la lógica relacionada dentro de un solo fragmento de código, y evite utilizar lógica en la que los contextos de transacción y conexión estén divididos en varios fragmentos de código. En operaciones de base de datos, por ejemplo, el código relacionado con la obtención de una conexión, el inicio y finalización de una transacción y la liberación de la conexión debe estar en un solo fragmento de código.

En general, asegúrese de que el código diseñado para interactuar con un Enterprise Information System (EIS) esté colocado dentro de adaptadores, y no dentro de correlaciones o plantillas de colaboración. Este es generalmente un procedimiento recomendado para el diseño de la arquitectura. Esto también le ayudará a evitar los prerrequisitos de bibliotecas de terceros y las consideraciones relacionadas dentro del código, como por ejemplo la gestión de conexiones y las posibles implementaciones de JNDI (Java Native Interface).

Haga que el código sea lo más seguro posible utilizando el manejo de excepciones adecuado. Haga también que el código sea compatible para la ejecución dentro de un entorno de servidor de aplicaciones J2EE, aunque se esté ejecutando actualmente en un entorno J2SE. Respete los procedimientos de desarrollo de J2EE, como por ejemplo evitar variables estáticas, generación de hebras y E/S de disco. Estos son procedimientos recomendados que seguir en general, y pueden mejorar la portabilidad.

Consideraciones: programas de utilidad de código comunes

Si es posible, debe evitar el desarrollo de bibliotecas de programas de utilidad de código comunes para utilizarlas en los artefactos de integración dentro del entorno de WebSphere InterChange Server. Considere también la posibilidad de utilizar EJB ejecutados en WebSphere Application Server para encapsular la lógica y utilizar llamadas de servicio Web para invocarlos desde WebSphere InterChange Server.

Aunque es posible que algunas bibliotecas de programas de utilidad de código comunes puedan ejecutarse correctamente en WebSphere Process Server, el usuario será responsable de la migración de los programas de utilidad personalizados.

Consideraciones: agrupaciones de conexiones de base de datos

Una agrupación de conexiones de base de datos de WebSphere InterChange Server dentro de una correlación o plantilla de colaboración se representará como un recurso JDBC estándar en WebSphere Process Server. Sin embargo, la forma en que las conexiones y las transacciones están gestionadas puede diferir entre WebSphere InterChange Server y WebSphere Process Server. Por lo tanto, debe evitar mantener transacciones de base de datos activas entre fragmentos de código Java.

Las agrupaciones de conexiones de base de datos definidas por usuario son útiles en las correlaciones y plantillas de colaboración para búsquedas de datos simples y para la gestión de estados más sofisticados en las instancias de proceso. Una agrupación de conexiones de base de datos de WebSphere InterChange Server se representará como un recurso JDBC estándar en WebSphere Process Server y la función básica será la misma. No obstante, la forma en que se gestionan las conexiones y transacciones puede ser diferente.

Para maximizar la portabilidad futura, evite mantener activas las transacciones de base de datos en los nodos de fragmento de código Java dentro de una plantilla de colaboración o una correlación. Por ejemplo, el código relacionado con la obtención de una conexión, el inicio y finalización de una transacción y la liberación de la conexión debe estar en un solo fragmento de código.

Consideraciones: objetos de negocio

Para el desarrollo de objetos de negocio sólo debe utilizar las herramientas suministradas para configurar artefactos, utilizar tipos y longitudes de datos explícitos para los atributos de datos y utilizar sólo las API documentadas.

Los objetos de negocio de WebSphere Process Server se basan en SDO (Service Data Objects) que tienen atributos de datos fuertemente tipificados. En los objetos de negocio de WebSphere InterChange Server y adaptadores, los atributos de datos no están fuertemente tipificados y a veces se especifican tipos de datos serie (string) para atributos de datos no serie. Para evitar problemas en WebSphere Process Server, especifique los tipos de datos de forma específica.

Puesto que los objetos de negocio de WebSphere Process Server pueden serializarse en tiempo de ejecución a medida que se pasan entre componentes, es importante ser explícito con las longitudes necesarias para los atributos de datos para minimizar la utilización de recursos del sistema. Por esta razón, no utilice la longitud máxima de 255 caracteres para un atributo de tipo serie. Tampoco especifique atributos de longitud cero que actualmente tengan el valor por omisión de 255 caracteres. En lugar de ello, especifique la longitud exacta necesaria para los atributos.

Los nombres de atributos de objeto de negocio de WebSphere Process Server están sujetos a las normas de XSD NCName. Por lo tanto, no utilice espacios ni signos ":" en los nombres de atributos de objeto de negocio. Los nombres de atributo de objeto de negocio con espacios o signos ":" no son válidos en WebSphere Process Server. Redenomine los atributos de objetos de negocio antes de la migración.

Si utiliza una matriz en un objeto comercial, no puede basarse en el orden de la matriz al indexar en la matriz en correlaciones o relaciones. La construcción que se migra a WebSphere Process Server no garantiza el orden del índice, particularmente cuando se suprimen entradas.

Es importante utilizar sólo la herramienta Diseñador de objetos comerciales para editar definiciones de objeto comercial, y utilizar sólo las API publicadas para los objetos comerciales dentro de los artefactos de integración.

Consideraciones: plantillas de colaboración

Muchas de las directrices ya descritas se aplican al desarrollo de plantillas de colaboración.

Para asegurar que los procesos se describan adecuadamente con metadatos, utilice siempre la herramienta Diseñador de procesos para la creación y modificación de plantillas de colaboración, y evite editar directamente archivos de metadatos. Utilice la herramienta Editor de actividades siempre que sea posible para maximizar el uso de metadatos para describir la lógica necesaria.

Para minimizar la cantidad de trabajo manual que puede requerirse en la migración, utilice sólo las API documentadas en las plantillas de colaboración. Evite utilizar variables estáticas y en su lugar utilice variables no estáticas y propiedades de colaboración para satisfacer los requisitos de la lógica comercial. Evite el uso de calificadores Java finales, transitorios y nativos en fragmentos de código Java. Estos no pueden aplicarse en los fragmentos de código Java de BPEL resultantes de la migración de plantillas de colaboración.

Para maximizar la portabilidad futura, evite utilizar llamadas de liberación de conexión explícitas y corchetes de transacción explícitos (es decir, compromisos explícitos y retrotracciones explícitas) para agrupaciones de conexiones de base de datos definidas por usuario. En su lugar, utilice la limpieza de conexiones implícita gestionada por contenedor y los corchetes de transacción implícitos. Evite también mantener activas las conexiones de sistema y transacciones en los nodos de fragmento de código Java dentro de una plantilla de colaboración. Esto se aplica a cualquier conexión a un sistema externo, así como a agrupaciones de conexiones de base de datos definidas por usuario. Las operaciones con un EIS externo deben gestionarse dentro de un adaptador, y el código relacionado con la operación de base de datos debe encontrarse dentro de un fragmento de código. Esto puede ser necesario dentro de una colaboración que, cuando se representa como componente de proceso comercial BPEL, puede desplegarse selectivamente en forma de flujo interrumpible. En este caso, el proceso puede componerse de varias transacciones independientes, en la que se pasa sólo información de estado y de variable global entre las actividades. El contexto de cualquier conexión de sistema o transacción relacionada que abarque estas transacciones de proceso se perderá.

La propiedad de plantilla de colaboración de nombres asigna nombres que cumplen el convenio de denominación W3C XML NCName. WebSphere Process Server acepta nombres que cumplan dichos convenios. Los caracteres no permitidos no son válidos en los nombres de propiedad BPEL a los que se migrarán. Redenomine las propiedades para eliminar los caracteres no permitidos antes de la migración para evitar errores sintácticos en el BPEL generado por la migración.

No haga referencia a variables mediante "this." Por ejemplo, en lugar de "this.inputBusObj" utilice sólo "inputBusObj".

Utilice ámbitos a nivel de clase en variables en lugar de variables a nivel de ámbito. El ámbito a nivel de escenario no se conserva durante la migración.

Inicialice todas las variables declaradas en fragmentos de código Java con un valor predeterminado, por ejemplo "Object myObject = null;". Asegúrese de que todas las variables se inicialicen durante la declaración antes de la migración.

Asegúrese de que no haya sentencias de importación Java en las secciones modificables por el usuario de las plantillas de colaboración. En la definición de la plantilla de colaboración, utilice los campos de importación para especificar los paquetes Java que deben importarse.

No establezca que los valores de objeto de negocio de entrada se almacenen en la variable triggeringBusObj. En WebSphere InterChange Server, triggeringBusObj sólo es de lectura, y su valor no se puede sobrescribir, por lo que los valores de objetos de negocio entrantes no se salvarán. Si se utiliza triggeringBusObj como variable receptora para un objeto de negocio de entrada en una invocación de servicio de entrada, tras la migración, el comportamiento de la llamada de servicio de entrada será diferente: dentro del proceso BPEL, el valor de entrada de la llamada de servicio de entrada sobrescribirá el valor almacenado en triggeringBusObj.

Consideraciones: correlaciones

Muchas de las directrices descritas para las plantillas de colaboración se aplican también a las correlaciones.

Para asegurarse de que las correlaciones se describan adecuadamente con metadatos, utilice siempre la herramienta Diseñador de correlaciones para la creación y modificación de correlaciones, y evite editar directamente los archivos de metadatos. Utilice la herramienta de edición de actividades siempre que sea posible para maximizar el uso de metadatos para describir la lógica necesaria.

Al hacer referencia a objetos de negocio hijo en una correlación, utilice una subcorrelación para los objetos de negocio hijos.

Evite utilizar código Java como "valor" en SET, ya que no es válido en WebSphere Process Server. En lugar de ello, utilice constantes. Por ejemplo, si el valor de establecimiento es "xml version=" + "1.0" + " encoding=" + "UTF-8", no se validará en WebSphere Process Server. En su lugar, cámbielo por "xml version=1.0 encoding=UTF-8" antes de migrar.

Para minimizar la cantidad de trabajo manual que puede requerirse en la migración, utilice sólo las API documentadas en las correlaciones. Evite utilizar variables estáticas y en su lugar utilice variables no estáticas. Evite el uso de calificadores Java finales, transitorios y nativos en código personalizado de correlación.

Si utiliza una matriz en un objeto comercial, no se base en el orden de la matriz al indexar en la matriz en correlaciones. La construcción que se migra a WebSphere Process Server no garantiza el orden del índice, particularmente cuando se suprimen entradas.

Para maximizar la portabilidad futura, evite utilizar llamadas de liberación de conexión explícitas y corchetes de transacción explícitos (es decir, compromisos explícitos y retrotracciones explícitas) para agrupaciones de conexiones de base de datos definidas por usuario. En su lugar, utilice la limpieza de conexiones implícita gestionada por contenedor y los corchetes de transacción implícitos. Evite también mantener activas las conexiones de sistema y transacciones en pasos de correlación personalizados en los límites de nodo de la transformación. Esto se aplica a cualquier conexión a un sistema externo, así como a agrupaciones de conexiones de base de datos definidas por usuario. Las operaciones con un EIS externo deben gestionarse dentro de un adaptador, y el código relacionado con la operación de base de datos debe encontrarse dentro de un paso personalizado.

No utilice clases interiores en sus correlaciones. El mandato de migración (reposMigrate) no migra clases interiores y el usuario no recibirá errores si sus correlaciones las contienen. En un repositorio de WebSphere InterChange Server, una clase interior podría estar definida en un nodo y estar referenciada por otros nodos dentro de la misma plantilla de colaboración. En WebSphere Process Server, una clase interior definida en un componente BPEL no puede ser utilizada por otros componentes. Debido a esta limitación, las clases interiores no se traducen y hay que tratarlas manualmente. Entre los cambios recomendados, está el empaquetamiento del código de la clase interior en una biblioteca como una clase externa, o la eliminación de la declaración de clase interior, resolución de errores y colocación del código según sea necesario en todo BPEL.

Consideraciones: relaciones

En las relaciones, aunque las definiciones de relación podrán migrarse para utilizarlas en WebSphere Process Server, el esquema de tabla y los datos de instancia de relación pueden reutilizarse en WebSphere Process Server, y también se compartirán de forma concurrente entre WebSphere InterChange Server y WebSphere Process Server.

Utilice sólo las herramientas suministradas para configurar los componentes relacionados y utilice sólo las API publicadas para las relaciones dentro de los artefactos de integración.

Utilice sólo el editor de relaciones para editar definiciones de relación. Además, permita sólo a WebSphere InterChange Server configurar el esquema de relaciones, que se genera automáticamente al desplegar las definiciones de relación. No modifique el esquema de tabla de relaciones directamente con herramientas de base de datos o scripts SQL. Si debe modificar manualmente datos de instancia de relación dentro del esquema de tabla de relaciones, asegúrese de utilizar los recursos suministrados por el Gestor de relaciones.

Consideraciones: clientes de infraestructura de acceso

No desarrolle clientes nuevos que adopten las API de interfaz IDL CORBA. Esto no tendrá soporte en WebSphere Process Server.

Consideraciones: prevención de colisiones de bases de datos

Si una aplicación migrada hace que se produzcan muchos eventos a la vez para componentes de WebSphere Business Integration, podrían producirse colisiones o bloqueos de bases de datos. Estas tienen lugar cuando el planificador WebSphere Process Server Application Scheduler (AppScheduler) planifica varios eventos para que tengan lugar a la vez. Puede evitar que se produzcan colisiones de bases de datos planificando que los eventos tengan lugar en momentos diferentes.

Cuando se produce un bloqueo, el evento que lo ha provocado se retrotrae y se vuelve a intentar tan pronto como sea posible. Este ciclo continúa hasta que las hebras que intentan acceder a la base de datos la actualicen correctamente.

Por ejemplo:

AppScheduler E com.ibm.wbiserver.scheduler.AppSchedulerMB process CWLWS0021E: 
El método AppSchedulerMB.process ha generado una excepción.
WSRdbXaResour E DSRA0304E: Se ha producido la excepción XAException. El contenido y detalles de la excepción XAException es:
El mensaje de error de DB2 es: Error al ejecutar un XAResource.end(), retorno de
servidor
XA_RBDEADLOCK El código de error de DB2 es : -4203
El SQLState de DB2 es: null  

Para evitar que pase esto, planifique los eventos para que tengan lugar con un tiempo de separación, para que no se produzcan bloqueos. Planifique los eventos para que tengan lugar con al menos dos segundos de diferencia; no obstante, el tiempo que se necesita variará según otros factores del entorno que afecten al rendimiento, como el tamaño de base de datos, el hardware, la velocidad de conexión y otros factores.

Consideraciones: Postmigración

Cuando las aplicaciones se han migrado desde WebSphere InterChange Server a WebSphere Integration Developer o WebSphere Process Server, es necesario prestar especial atención a algunas áreas, para habilitar que las las aplicaciones migradas funcionen en WebSphere Integration Developer y WebSphere Process Server de forma consistente con lo que se espera de ellas, debido a las diferencias con la arquitectura WebSphere InterChange Server.

Para obtener más información sobre consideraciones referentes a después de la migración, consulte Consideraciones sobre postmigración.

Para obtener información relativa a la descarga de documentación del servidor, consulte la sección Visualizar o descargar la documentación de WebSphere Process Server.

Migrar artefactos de WebSphere InterChange Server utilizando el asistente de migración

Puede utilizar el asistente de migración de WebSphere Integration Developer para migrar los artefactos actuales de WebSphere InterChange Server.

Por qué y cuándo se efectúa esta tarea

El asistente realizará la migración en función de lo siguiente:

  1. Los adaptadores se migrarán a enlaces nativos si pueden soportarse como enlaces nativos; y
  2. Si se detecta que un adaptador tiene un conector JCA equivalente, se ofrecerá la opción de importar este último. Al importar el conector, se configura el entorno para migrarlo al adaptador JCA mediante el asistente de migración.

Para utilizar el asistente de migración a fin de migrar los artefactos de WebSphere InterChange Server, siga estos pasos:

  1. Invoque el asistente seleccionando Archivo -> Importar -> Integración de negocio -> Repositorio de WebSphere InterChange Server y pulse Siguiente. Nota: también puede abrir el asistente Migración desde la página de bienvenida pulsando el icono Usuarios existentes para abrir la página Usuarios existentes (siempre puede volver a la página de bienvenida pulsando AyudaBienvenida). Pulse Migración en el lado izquierdo de la página Usuarios existentes para abrir la página Migración y seleccione la opción Migrar un repositorio WebSphere ICS.
  2. Se abre el asistente de migración. Especifique la vía de acceso del repositorio WebSphere InterChange Server o pulse Examinar JAR para seleccionar el archivo JAR a utilizar en el proceso de migración.
  3. Especifique el nombre de una biblioteca de WebSphere Integration Developer nueva o existente.
  4. También puede añadir una plantilla de editor de ensamblado de WebSphere InterChange Server para cargarla y utilizarla para la conversión de XML a Java. Si se crean API personalizadas (Mi biblioteca) para utilizarlas en el editor de actividades, la herramienta de migración debe consultar la plantilla del editor de actividades personalizadas para determinar cómo debe migrar la API personalizada a Java. Estas plantillas se encuentran en el directorio raíz .wbiActEditorSettings ubicado en el directorio de espacio de trabajo (workspace) de WebSphere InterChange Server. Generalmente, los archivos de plantilla tienen la extensión de archivo .bbt. Asegúrese de cargar estas plantillas en el recuadro de plantillas. Si no añade una plantilla, se utilizará Standard Assembly Editor Template v4.3.3 para la conversión de XML a Java.
  5. Pulse Siguiente para configurar los valores de migración para cada conector. Desde esta página puede seleccionar el enlace destino y los manejadores de datos adecuados para la migración de cada conector. Seleccione el conector de la lista y elija un enlace destino y a continuación un archivo JAR de manejador de datos personalizado. Tenga en cuenta que el asistente de migración no permitirá que continúe el proceso de migración hasta que se establezcan todos los valores de conector.
  6. Pulse Siguiente. Se abre la página Opciones de conversión. Desde aquí puede aceptar o cambiar las opciones recomendadas o cambiarlas:
    Página de opciones de conversión de migración
    En la tabla siguiente se detallan las opciones de conversión de migración:
    Opción Descripción
    Los errores de análisis de Java encontrados en el proceso de migración deben tratarse del siguiente modo:
    Errores (recomendado)
    Todos los problemas de conversión de Java se tratan como errores y deberá revisar las anotaciones de error para obtener más detalles.
    Avisos
    Todos los problemas de conversión de Java se tratan sólo como avisos y el asistente Migración migrará el artefacto lo mejor posible.
    Al detectar un error, el proceso de migración debe:
    Continuar hasta el final (recomendado)
    El asistente Migración continuará procesando los artefactos restantes de un archivo JAR incluso aunque se produzca un error durante el proceso de un artefacto dado.
    Terminar inmediatamente
    El proceso de migración se detendrá tan pronto como se detecte un error. El artefacto con el error y todos los artefactos subsecuentes no se procesan.
    Secuenciación de eventos para todos los métodos WSDL asíncronos:
    Inhabilitar (recomendado)
    El proceso de migración no habilitará la secuenciación de eventos en ningún método WSDL.
    Habilitar
    El proceso de migración habilitará la secuenciación de eventos para todos los métodos WSDL síncronos.
  7. Pulse Siguiente. Se abrirá una página de resumen de migración similar a la del ejemplo siguiente:
    Página Resumen de migración
    .
  8. Una vez revisados los detalles del resumen, pulse Finalizar para iniciar el proceso de migración.

Qué hacer a continuación

Una barra de progreso en la parte inferior del diálogo de migración indica el progreso de la migración. Una vez finalizado el proceso, el diálogo desaparece y se abre la ventana Resultados de la migración:

Página Resultados de la migración

Pulse Cerrar para finalizar el proceso y construir el espacio de trabajo nuevo. Puede deseleccionar la opción Construir espacio de trabajo al cerrar si no desea que el espacio de trabajo se construya en este momento.

Verificar la migración de WebSphere InterChange Server

Si no se ha notificado ningún error durante la migración del archivo .jar de WebSphere InterChange Server, la migración de los artefactos ha sido satisfactoria. Si la migración no se ha realizado correctamente, se visualizará una lista de errores, avisos y mensajes informativos en la ventana Resultados de migración. Puede emplear estos mensajes para verificar la migración de WebSphere InterChange Server.

Por qué y cuándo se efectúa esta tarea

Nota: Debido a la complejidad que supone la migración desde WebSphere InterChange Server a WebSphere Process Server, es muy aconsejable probar por extenso las aplicaciones finales en ejecución en WebSphere Process Server con objeto de cerciorarse de que funcionan según las previsiones antes de ejecutarlas en el entorno de producción.

Si decide no detenerse en la primera anomalía, observará un icono de marca de selección de color verde en la ventana Resultados de migración, pero también puede haber letras X de color rojo en la lista. Por tanto, deberá revisarlas en la misma. Si decide detenerse en la primera anomalía y recibe una anomalía o un error, observará una X roja en la ventana Resultados de migración en lugar de una marca de selección de color verde, y deberá revisar las anomalías de la lista.

Trabajar con los errores de migración de WebSphere InterChange Server

Si el proceso de migración de WebSphere InterChange Server falla, existen dos métodos para manejar los errores.

Por qué y cuándo se efectúa esta tarea

Nota: Puede que prefiera la primera opción ya que inicialmente estará más familiarizado con WebSphere InterChange Server. Sin embargo, a medida que adquiera más experiencia con WebSphere Process Server y sus nuevos artefactos, puede optar por reparar los artefactos migrados en WebSphere Integration Developer.

  1. Si el tipo de error lo permite, puede ajustar los artefactos de WebSphere InterChange Server mediante el juego de herramientas de WebSphere InterChange Server, exportar el archivo jar nuevamente y volver a intentar la migración.
  2. Puede corregir los errores de los artefactos de WebSphere Process Server obtenidos editando los artefactos en WebSphere Integration Developer.

Artefactos de WebSphere InterChange Server manejados por las herramientas de migración

Las herramientas de migración pueden migrar automáticamente algunos de los artefactos de WebSphere InterChange Server.

Pueden migrarse los siguientes artefactos:

Las herramientas de migración crearán un script Jython que puede utilizarse con la herramienta de línea de mandatos wsadmin para configurar recursos en WebSphere Process Server para los siguientes artefactos/recursos de WebSphere InterChange Server:

Las herramientas de migración no manejan los siguientes artefactos de WebSphere InterChange Server:

API de WebSphere InterChange Server soportadas

Además de las herramientas de migración de artefactos origen de WebSphere InterChange Server suministradas en WebSphere Process Server y WebSphere Integration Developer, también existe soporte para muchas de las API suministradas en WebSphere InterChange Server. Las herramientas de migración funcionan en combinación con estas API de WebSphere InterChange Server conservando todo lo posible el código personalizado al realizar la migración.

Nota: Estas API sólo se suministran como soporte de las aplicaciones de WebSphere InterChange Server migradas hasta que puedan modificarse para utilizar nuevas API de servidor de procesos.

Las API de WebSphere InterChange Server soportadas en el servidor de procesos se listan más abajo. Estas API suministran funciones de WebSphere Process Server similares a las funciones que suministran en WebSphere InterChange Server. Consulte la documentación de WebSphere InterChange Server para obtener una descripción funcional de estas API.

CwBiDiEngine
AppSide_Connector/

JavaConnectorUtil
AppSide_Connector/

JavaConnectorUtilDH
datahandler/
wbi/
ibm/
com/

BusObj
Collaboration/

BusObjArray
Collaboration/

BaseDLM
DLM/

CwDBConnection
CwDBConnection/
CxCommon/

CwDBConstants
CwDBConnection/
CxCommon/

CwDBStoredProcedureParam
CwDBConnection/
CxCommon/

DataHandler (Clase abstracta)
DataHandlers/
crossworlds/
com/

NameHandler (Clase abstracta)
DataHandlers/
crossworlds/
com/

ConfigurationException (amplía java.lang.Exception)
Exceptions/
DataHandlers/
crossworlds/
com/

MalformedDataException (amplía java.lang.Exception)
Exceptions/
DataHandlers/
crossworlds/
com/

NotImplementedException (amplía java.lang.Exception)
Exceptions/
DataHandlers/
crossworlds/
com/

BusinessObjectInterface
CxCommon/

CxObjectAttr
CxCommon/

CxObjectContainerInterface
CxCommon/

DtpConnection
Dtp/
CxCommon/

DtpDataConversion
Dtp/
CxCommon/

DtpDate
Dtp/
CxCommon/

DtpMapService
Dtp/
CxCommon/

DtpSplitString
Dtp/
CxCommon/

DtpUtils
Dtp/
CxCommon/

BusObjInvalidVerbException (amplía InterchangeExceptions)
Exceptions/
CxCommon/

IdentityRelationship
relationship/
utilities/
crossworlds/
com/

MapExeContext
Dtp/
CxCommon/

Participant
RelationshipServices/
Server/

Relationship
RelationshipServices/
Server/

UserStoredProcedureParam
Dtp/
CxCommon/

BaseCollaboration
Collaboration/

CxExecutionContext
CxCommon/

CollaborationException
Collaboration/

Filter
crossworlds/
com/

Globals
crossworlds/
com/

SmartCollabService
crossworlds/
com/

StateManagement
crossworlds/
com/

EventKeyAttrDef
EventManagement/
CxCommon/

EventQueryDef
EventManagement/
CxCommon/

FailedEventInfo
EventManagement/
CxCommon/

Correlacionar el DataObject de WebSphere Process Server desde el XML de WebSphere InterChange Server

Si utiliza los Adaptadores de legado para conectarse a WebSphere Process Server, el algoritmo siguiente le permitirá una comprensión más profunda de cómo se ha creado el DataObject de WebSphere Process Server a partir del XML de WebSphere InterChange Server. Esta información muestra dónde se han colocado los valores de datos y también qué valores de datos se han elegido para sustituir a los utilizados en WebSphere InterChange Server.

General

Carga

La carga cargará un XML de tiempo de ejecución de WebSphere InterChange Server en una instancia de WebSphere Business Integration BusinessGraph AfterImage.

Guardado

El guardado guardará una instancia de WebSphere Business Integration BusinessGraph AfterImage en un XML de tiempo de ejecución de WebSphere InterChange Server. Se lanzará una excepción si el BusinessGraph de entrada no es AfterImage.

Proceso de atributos

Capítulo 4. Migrar a WebSphere Integration Developer desde WebSphere MQ Workflow

WebSphere Integration Developer ofrece las herramientas necesarias para migrar desde WebSphere MQ Workflow.

Por qué y cuándo se efectúa esta tarea

El asistente de migración convierte las definiciones FDL de los procesos de negocio que ha exportado del componente de tiempo de construcción de WebSphere MQ Workflow en los artefactos correspondientes de WebSphere Integration Developer. Los artefactos generados comprenden las definiciones de esquemas XML de los objetos de negocio, las definiciones WSDL, BPEL, definiciones de importaciones y componentes y las definiciones TEL.

La herramienta de conversión requiere una definición FDL semánticamente completa de un modelo de proceso exportado desde el entorno de construcción WebSphere MQ Workflow con la opción exportación profunda. Esta opción garantiza la inclusión de todas las especificaciones de datos, programas y subprocesos necesarias. Asimismo, asegúrese de que también se seleccionan todas las definiciones de servidores de ejecución de procesos definidos por el usuario (UPES) con referencias en el modelo de proceso de WebSphere MQ Workflow al exportar FDL desde el entorno de construcción WebSphere MQ Workflow.

Nota: El asistente de migración no cubre la migración de los elementos siguientes:

Para obtener más información acerca de la migración mediante la herramienta de conversión FDL2BPEL, consulte el sitio de soporte de WebSphere MQ Workflow.

Tareas de preparación para la migración de WebSphere MQ Workflow

Antes de migrar a WebSphere Integration Developer desde WebSphere MQ Workflow, primero debe asegurarse de que ha preparado correctamente el entorno.

Por qué y cuándo se efectúa esta tarea

El ámbito y la integridad de la correlación dependerán del seguimiento de las siguientes directrices sobre migración:

El asistente de migración generará construcciones del editor de procesos de negocio sintácticamente correctas incluso en el caso de las construcciones de WebSphere MQ Workflow que no se pueden migrar (actividades de programa PEA o PES, algunas asignaciones de personal dinámicas, etc.), que deberán adaptarse manualmente a los artefactos del editor de procesos de negocio ejecutables.

En la tabla siguiente figuran las reglas de correlación aplicadas:

Tabla 2. Reglas de correlación
WebSphere MQ Workflow WebSphere Integration Developer
Proceso Proceso con modalidad de ejecución: longRunning; enlaces de socio para interfaces de proceso entrantes y salientes
Origen y llegada Variables para la entrada y la salida de procesos; actividad de recepción y actividad de respuesta
Actividad de programa Actividad de invocación
Actividad de proceso Actividad de invocación
Actividad vacía Actividad FMCINTERNALNOOP
Bloque Ámbito con actividades BPEL incorporadas
Condición de salida de actividad Actividad while (delimitando la actividad)
Condición de inicio de actividad Condición de unión de actividad
Asignación de personal de actividad Actividad de tarea manual
Contenedor de entrada y contenedor de salida de actividad Variables empleadas para especificar la entrada/salida de la actividad de invocación
Conector de control; condición de transición Enlace; condición de transición
Conector de datos Actividad de asignación
Contenedor de datos global Variable
Nota: Inicialmente se recomienda probar el proceso de migración con proyectos pequeños, si es posible. El asistente de migración simplificará la conversión de los modelos de proceso de WebSphere MQ Workflow en los modelos de proceso del editor de procesos comerciales, pero tenga presente que los procesos no pueden correlacionarse de forma unívoca ya que se crea un nuevo modelo de programación. Los ámbitos semánticos de los lenguajes de especificación de procesos subyacentes (FDL y BPEL) comparten una área de intersección, pero no se solapan por completo. De lo contrario, no podría esperar ninguna ventaja adicional del editor de procesos de negocio. Los servicios web constituyen una nueva y prometedora tecnología que pretende sustituir las soluciones obsoletas por otras nuevas.

Como norma general, siempre deberá revisar y posiblemente modificar los artefactos generados. Puede que tenga que llevar a cabo algunas tareas adicionales para que la migración sea satisfactoria o logre completarse.

Migrar WebSphere MQ Workflow utilizando el asistente de migración

El asistente de migración permite convertir las definiciones FDL de los procesos de negocio que ha exportado del componente de tiempo de construcción de WebSphere MQ Workflow en los artefactos correspondientes de WebSphere Integration Developer. Los artefactos generados comprenden las definiciones de esquemas XML de los objetos de negocio, las definiciones WSDL, BPEL, definiciones de importaciones y componentes y las definiciones TEL.

Por qué y cuándo se efectúa esta tarea

Nota: El asistente de migración no cubre la migración de los elementos siguientes:

Para utilizar el asistente de migración a fin de migrar los artefactos de WebSphere MQ Workflow, siga estos pasos:

  1. Invoque el asistente seleccionando Archivo -> Importar -> Integración de negocio -> Archivo FDL de WebSphere MQ Workflow y pulse Siguiente. Nota: también puede abrir el asistente Migración desde la página Bienvenida pulsando el icono Usuarios existentes para abrir la página Usuarios existentes (siempre puede volver a la página Bienvenida pulsando AyudaBienvenida). Pulse Migración en el lado izquierdo de la página Usuarios existentes para abrir la página Migración y seleccione la opción Migrar un proceso WebSphere MQ Workflow.
  2. Se abre el asistente de migración. Especifique la vía de acceso absoluta y el nombre del archivo FDL en el campo Selección de origen o seleccione uno del sistema de archivos pulsando el botón Examinar y desplazándose hasta el archivo. También debe especificar un nombre de módulo antes de continuar. Pulse Siguiente:
    Asistente de migración de FDL con los nombres de archivo fuente y módulo indicados
  3. Se abrirá la página Opciones de migración de WebSphere MQ Workflow correspondiente a los valores de creación de artefactos. Puede aceptar los valores predeterminados de la migración o marcar un recuadro de selección para cambiar la opción. Si marca el recuadro de selección Tratar conflictos de nombres como errores, puede evitar la adición automática de sufijos que puede provocar errores de interoperatividad. El recuadro de selección Crear miembros de datos predefinidos añade nodos adicionales al proceso para inicializar los miembros de datos predefinidos:
    Página Opciones de migración de WebSphere MQ Workflow para los valores de creación de artefactos
  4. Pulse Siguiente. Se abrirá la página Opciones de migración de WebSphere MQ Workflow correspondiente a la optimización de los procesos de empresariales migrados:
    Opciones de migración de WebSphere MQ Workflow para optimizar los procesos empresariales migrados
    . Desde esta página puede establecer las opciones destinadas a optimizar los procesos empresariales migrados. Para obtener más información acerca de estas opciones, consulte el tema "Optimizar los procesos empresariales migrados" mediante los enlaces relacionados que figuran más abajo o pulse F1 al seleccionar o deseleccionar cada opción.
  5. Una vez que haya seleccionado y revisado las opciones de optimización, pulse Finalizar.

Qué hacer a continuación

Una barra de progreso en la parte inferior del diálogo de migración indica el progreso de la migración. Una vez finalizado el proceso de migración, el diálogo de migración desaparecerá y se abrirá la ventana Resultados de migración:

Página Resultados de migración de WebSphere MQ Workflow

. Para conservar todos los mensajes para consultas futuras, pulse el botón Generar tareas pendientes para crear una lista de tareas "Pendientes" en la vista de tareas o pulse el botón Guardar como para guardar los mensajes en un archivo de texto del sistema de archivos. Examine cada uno de los mensajes para ver si debe realizar alguna acción para corregir de inmediato un artefacto que no se ha migrado por completo. Para ver las Tareas pendientes generadas, pulse Ventana -> Mostrar vista -> Otras -> General -> Tareas y pulse Aceptar. La vista Tareas se abre con la lista de tareas pendientes generadas desde el proceso de migración.

Optimizar los procesos de negocio migrados

Durante la migración de procesos empresariales, existen diversas opciones de optimización que facilitan la eficiencia global, el rendimiento y la usabilidad del proceso empresarial migrado. Por ejemplo, puede reducir el número de fragmentos de código Java, eliminar elementos estructurales innecesarios y reducir el número de variables BPEL por medio de las opciones de optimización del asistente de migración.

La tabla siguiente detalla las opciones de optimización de la migración de WebSphere MQ Workflow y los resultados asociados a cada una de ellas:

Tabla 3. Opciones de optimización de la migración de WebSphere MQ Workflow
Opción Resultado
Fusionar fragmentos de código Java adyacentes Si marca este recuadro de selección, el proceso empresarial se optimizará combinando fragmentos de código Java siempre que sea posible (serie, paralelo o mixto). El proceso se ejecutará con mayor eficiencia, ya que las variables se compartirán en un fragmento de código Java y podrán eliminarse las partes de código duplicadas.

Si no marca este recuadro de selección, el proceso seguirá siendo válido, pero se generarán muchos fragmentos de código Java en el proceso BPEL.

Eliminar elementos estructurales innecesarios Si marca este recuadro de selección, el proceso empresarial se optimizará eliminando elementos estructurales. El anidamiento innecesario de actividades BPEL estructurales no es eficiente para el flujo del proceso.
Reducir el número de variables Si marca este recuadro de selección, el proceso empresarial se optimizará reduciendo el número de variables BPEL. Utilice la barra de desplazamiento para seleccionar el nivel de reducción. Al migrar un proceso FDL a BPEL, se crean muchas variables BPEL basadas en variables FDL. Puede suprimir todas, algunas o ninguna de las variables FDL que deben transferirse al proceso BPEL.
  • Nivel de reducción de variables 0: esta opción permite el compartimiento mínimo de variables. Las variables FDL correspondientes de los contenedores de entrada y de salida se fusionarán en una variable BPEL.
  • Nivel de reducción de variables 1: esta opción permite un compartimiento moderado de variables. Las variables FDL correspondientes de los contenedores de entrada y de salida se fusionarán en una variable BPEL. También se compartirán variables al tiempo que se toleran conflictos potenciales con el miembro de datos predefinido "Priority".
  • Nivel de reducción de variables 2: esta opción permite un compartimiento medio de variables. Las variables FDL correspondientes de los contenedores de entrada y de salida se fusionarán en una variable BPEL. También se compartirán variables al tiempo que se toleran conflictos potenciales con los miembros de datos predefinidos "Priority" y "Notification".
    Nota: En raras ocasiones, una variable BPEL se comparte incorrectamente. En tales casos, ejecute de nuevo la migración disminuyendo el nivel de optimización.
  • Nivel de reducción de variables 3: esta opción permite compartir casi todas las variables posibles. Las variables FDL correspondientes de los contenedores de entrada y de salida se fusionarán en una variable BPEL. También se compartirán variables al tiempo que se toleran conflictos potenciales con los miembros de datos predefinidos "Priority", "Notification" y "Staff".
    Nota: En raras ocasiones, una variable BPEL se comparte incorrectamente. En tales casos, ejecute de nuevo la migración disminuyendo el nivel de optimización.
  • Nivel de reducción de variables 4: esta opción permite compartir todas las variables posibles. Las variables FDL correspondientes de los contenedores de entrada y de salida se fusionarán en una variable BPEL. También se compartirán variables al tiempo que se toleran conflictos potenciales con los miembros de datos predefinidos "Priority", "Notification" y "Staff" y valores de datos predeterminados.
    Nota: En raras ocasiones, una variable BPEL se comparte incorrectamente. En tales casos, ejecute de nuevo la migración disminuyendo el nivel de optimización.

Para obtener más información acerca de las opciones de optimización, así como información relativa a la herramienta de línea de mandatos para la migración de MQ Workflow, consulte el sitio de soporte de WebSphere Process Server.

Verificar la migración de WebSphere MQ Workflow

Si la migración finaliza con una lista de errores, avisos o mensajes informativos, éstos se visualizarán en la ventana Resultados de migración. De lo contrario, la ventana del asistente se cerrará si la migración ha terminado correctamente.

Por qué y cuándo se efectúa esta tarea

La página siguiente se visualiza si se han generado mensajes durante el proceso de migración:

Ventana Resultados de la migración

En la ventana Resultados de la migración, puede ver los mensajes que se han generado durante el proceso de migración. Si selecciona un mensaje en la lista superior, Mensajes, obtendrá más información relativa a ese mensaje en la ventana inferior, Descripción del mensaje.

Para conservar todos los mensajes para consultas futuras, pulse el botón Generar tareas pendientes para crear una lista de tareas "Pendientes" en la vista de tareas o pulse el botón Guardar como para guardar los mensajes en un archivo de texto del sistema de archivos. Examine cada uno de los mensajes para ver si debe realizar alguna acción para corregir de inmediato un artefacto que no se ha migrado por completo. Para ver las Tareas pendientes generadas, pulse Ventana -> Mostrar vista -> Otras -> General -> Tareas y pulse Aceptar. La vista Tareas se abre con la lista de tareas pendientes generadas desde el proceso de migración.

Limitaciones del proceso de migración (desde WebSphere MQ Workflow)

Existe una serie de limitaciones en el proceso de migración de WebSphere MQ Workflow.

Capítulo 5. Migración desde WebSphere Studio Application Developer Integration Edition

Es posible migrar artefactos origen de proyectos WebSphere Business Integration Server Foundation (WBISF) 5.1 desde WebSphere Studio Application Developer Integration Edition a WebSphere Integration Developer. Al migrar los artefactos origen de una aplicación, estos se migran al nuevo modelo de programación de WebSphere Integration Developer para que se puedan utilizar las nuevas funciones y características. A continuación, la aplicación puede desplegarse de nuevo e instalarse en el servidor WebSphere Process Server.

Migrar el espacio de trabajo

En WebSphere Integration Developer 6.2, sólo puede migrar un espacio de trabajo válido (un espacio de trabajo que contenga como mínimo un proyecto de servicio). Esta sección ofrece información para migrar el espacio de trabajo de WebSphere Studio Application Developer Integration Edition.

Por qué y cuándo se efectúa esta tarea

Para migrar por completo un espacio de trabajo de WebSphere Studio Application Developer Integration Edition, deben realizarse tres tareas fundamentales:

  1. Preparar los artefactos origen para la migración. Es posible que estas acciones deban realizarse en WebSphere Studio Application Developer Integration Edition.
  2. Utilice el asistente Migración o el script de línea de mandatos WSADIEWorkspaceMigration para migrar el espacio de trabajo.
  3. Cuando sea necesario, utilice WebSphere Integration Developer para completar manualmente la migración. Esto implica el arreglo del código Java que no se haya podido migrar automáticamente y comprobar la conexión de los artefactos migrados. Puede encontrar más información para estas tareas en la sección "Información de migración adicional".

Qué hacer a continuación

Nota: La migración en tiempo de ejecución (vía de acceso de actualización) no se proporciona con WebSphere Process Server 6.x, por lo que esta vía de acceso de migración de artefactos origen será la única opción para migrar espacios de trabajo de WebSphere Studio Integration Edition en 6.x.

Vías de migración soportadas para migrar artefactos origen

Antes de migrar artefactos origen de WebSphere Studio Application Developer Integration Edition, asegúrese de que los espacios de trabajo de los proyectos de WebSphere Business Integration Server Foundation contienen uno o varios proyectos de servicio.

El asistente de migración permite migrar un espacio de trabajo de WebSphere Studio Application Developer Integration Edition Versión 5.1 (o posterior) cada vez.

El asistente de migración no migra binarios de aplicaciones; solamente migra los artefactos origen que se encuentran en un espacio de trabajo de WebSphere Studio Application Developer Integration Edition.

Preparar los artefactos origen para la migración

Antes de migrar los artefactos origen a WebSphere Integration Developer desde WebSphere Studio Application Developer Integration Edition, primero debe asegurarse de que ha preparado correctamente el entorno para el proceso de migración.

Por qué y cuándo se efectúa esta tarea

El procedimiento siguiente describe cómo preparar el entorno antes de migrar artefactos origen a WebSphere Integration Developer desde WebSphere Studio Application Developer Integration Edition:

  1. Asegúrese de tener una copia de seguridad de todo el área de trabajo de 5.1 antes de empezar la migración.
  2. Revise la sección Servicio Web del Centro de información de Rational Application Developer para obtener más información acerca de la función de servicio Web proporcionada por Rational Application Developer: Desarrollar servicios Web
  3. Asegúrese de tener todas las características adecuadas de WebSphere Integration Developer habilitadas. Si no tiene estas características habilitadas, las opciones de menú que se tratarán a continuación no serán visibles. Para habilitar las características importantes:
  4. Utilice un espacio de trabajo nuevo como espacio de trabajo destino de la migración.
  5. Por omisión, WebSphere Integration Developer genera el código de despliegue para los proyectos WEB, EJB y EAR de soporte para los módulos de WebSphere Integration Developer.
    Nota: El código de despliegue no se genera para otros proyectos (por ejemplo, J2EE).
  6. Para migrar completamente los archivos BPEL en un espacio de trabajo, debe asegurarse de que todos los archivos WSDL y XSD a los que hacen referencia los archivos BPEL pueden resolverse en un proyecto de integración de negocio en el espacio de trabajo nuevo:
Nota: WebSphere Integration Developer no da soporte a tipos XML-SOAP, según lo definido en el espacio de nombres http://xml.apache.org/xml-soap. Debe eliminar las referencias a estos tipos en WebSphere Studio Application Developer Integration Edition antes de realizar la migración para evitar una anomalía del proceso de migración.

Qué hacer a continuación

Ahora ya está preparado para iniciar el proceso de migración.

Consideraciones anteriores a la migración

Existe una serie de consideraciones para el proceso de migración de artefactos origen de WebSphere Studio Application Developer Integration Edition.

Las recomendaciones siguientes muestran cómo diseñar los servicios de WebSphere Studio Application Developer Integration Edition para asegurarse de que se migrarán correctamente al nuevo modelo de programación:

Migrar espacios de trabajo utilizando el asistente de migración de WebSphere Integration Developer

El asistente de migración de WebSphere Integration Developer permite migrar espacios de trabajo, incluyendo todos los proyectos.

Por qué y cuándo se efectúa esta tarea

Para la migración de proyectos de servicio en concreto, el asistente Migración lleva a cabo las tareas siguientes:

  1. Crea un módulo de integración de negocio nuevo (el nombre del módulo lo define usted)
  2. Migra las entradas de vía de acceso de clases del proyecto de servicio al nuevo módulo.
  3. Copia todos los artefactos origen de WebSphere Business Integration Server Foundation del proyecto origen seleccionado a este módulo.
  4. Migra las extensiones BPEL en archivos WSDL.
  5. Migra los procesos de negocio (archivos .bpel) de BPEL4WS, versión 1.1 al nivel nuevo soportado por el servidor de procesos de WebSphere que está incorporado en BPEL4WS, versión 1.1 con las prestaciones principales de la próxima especificación WS-BPEL, versión 2.0
  6. Crea un componente SCA para cada proceso BPEL.
  7. Genera un archivo .mon de supervisión para cada proceso BPEL a fin de conservar el procedimiento de supervisión predeterminado de WebSphere Studio Application Developer Integration Edition (si es necesario).
  8. Crea importaciones y exportaciones en función de las opciones de despliegue elegidas en WebSphere Studio Application Developer Integration Edition
  9. Conecta el componente BPEL a sus enlaces asociados (importaciones, exportaciones y componentes Java)

Nota: Utilice un espacio de trabajo nuevo de WebSphere Integration Developer como destino de migración.

Para migrar espacios de trabajo utilizando el asistente de migración de WebSphere Integration Developer, siga estos pasos:

  1. Invoque el asistente seleccionando Archivo -> Importar -> Integración de negocio -> WebSphere Studio Application Developer Integration Edition Workspace y pulse Siguiente. Nota: también puede abrir el asistente Migración desde la página Bienvenida pulsando el icono Usuarios existentes para abrir la página Usuarios existentes (tenga en cuenta que siempre puede volver a la página Bienvenida pulsando Ayuda -> Bienvenida ). Pulse Migración en el lado izquierdo de la página Usuarios existentes para abrir la página Migración y seleccione la opción Migrar un espacio de trabajo de Integration Edition 5.1.
  2. Se abre el asistente de migración. Especifique la vía de acceso para el espacio de trabajo a migrar o pulse Examinar para buscarla. Pulse Siguiente.
  3. En la página de opciones de migración, puede cambiar la opción para conservar los fragmentos de código Java BPEL originales en los comentarios.
  4. Pulse Finalizar para empezar el proceso de migración. Verá una barra de estado de migración en la parte inferior de la ventana del asistente Migración.
  5. Una vez finalizado el proceso verá el mensaje siguiente:
    Mensaje de migración de Rational Desktop que indica que se han detectado los proyectos y los datos que deben migrarse
    Pulse Siguiente para iniciar el proceso de validación de la migración.
  6. Seleccione los proyectos del espacio de trabajo a migrar:
    Lista de los proyectos del espacio de trabajo a migrar
    Pulse Siguiente.
  7. Los recursos de proyecto de proyecto que pueden verse afectados por el proceso de migración se muestran en la lista:
    Lista de recursos de proyecto a migrar
    Revise esta lista y pulse Siguiente.
  8. Cuando esté preparado, pulse Finalizar para empezar a migrar los proyectos que ha seleccionado.
  9. Una vez finalizado el proceso de validación de la migración verá el mensaje siguiente:
    Mensaje de validación de la migración
  10. Una vez finalizado el proceso, se abre la ventana Resultados de la migración:
    Ventana Resultados de la migración con una lista de resultados
    Se generará automáticamente un archivo de anotaciones que contenga estos mensajes de migración en la carpeta .metadata del área de trabajo de 6.x. El archivo de anotaciones tendrá una extensión .log.
  11. Para conservar todos los mensajes para consultas futuras, pulse el botón Generar tareas pendientes para crear una lista de tareas "Pendientes" en la vista de tareas o pulse el botón Guardar como... para guardar los mensajes en un archivo de texto del sistema de archivos. Examine cada uno de los mensajes para ver si debe realizar alguna acción para corregir de inmediato un artefacto que no se ha migrado por completo. Para ver las Tareas pendientes generadas, pulse Ventana -> Mostrar vista -> Otras -> General -> Tareas y pulse Aceptar. La vista Tareas se abre con la lista de tareas pendientes generadas desde el proceso de migración.

Qué hacer a continuación

Una vez finalizado el asistente Migración, construya el espacio de trabajo creado e intente resolver errores de construcción. Examine todos los archivos BPEL migrados y compruebe que se han migrado por completo y que se pueden abrir en el editor BPEL de WebSphere Integration Developer. Hay algunos fragmentos de código Java BPEL que no se pueden migrar automáticamente. Si aprecia errores en los fragmentos de código Java BPEL, consulte la sección "Migrar al modelo de programación de SCA" para conocer los pasos necesarios para corregir los errores. Asimismo, si ha utilizado el asistente de migración para migrar un proyecto de servicio a un espacio de trabajo, abra el editor de dependencias para asegurarse de que las dependencias se han establecido correctamente. Para ello, vaya a la perspectiva Integración de negocio y realice una doble pulsación en el proyecto de módulo de integración de negocio. En esta ubicación puede añadir dependencias a los proyectos de biblioteca de integración de negocio, proyectos Java y proyectos J2EE.

Migrar espacios de trabajo mediante WSADIEWorkspaceMigration

El mandato WSADIEWorkspaceMigration permite la migración de espacios de trabajo.

Por qué y cuándo se efectúa esta tarea

Para la migración de proyectos de servicio en concreto, el mandato de migración lleva a cabo las tareas siguientes:

Para ejecutar el script WSADIEWorkspaceMigration, siga estos pasos:

  1. Localice el script abriendo la carpeta compartida especificada durante la instalación de WebSphere Integration Developer. Por ejemplo, el script se encontrará en una vía de acceso de directorio similar a la siguiente: <directorio_raíz_wid>\wstools\eclipse\plugins\com.ibm.wbit.migration.wsadie_6.2.0.v20081112_0200
  2. Invoque el script de la manera siguiente: WSADIEWorkspaceMigration.bat -WIDstartup dir_eclipse -WIDworkspace espacio_de_trabajo_WID_destino -WSADIEworkspace source_WSADIE_Workspace_dir

    Definiciones de parámetros:

    -WIDstartup
    La ubicación de su carpeta de Eclipse (ejecutable de Eclipse).
    -WIDworkspace
    El espacio de trabajo nuevo en el que se creará el nuevo módulo de integración de negocio.
    -WSADIEworkspace
    La vía de acceso completa al espacio de trabajo de WebSphere Studio Application Developer Integration Edition 5.1.

    Por ejemplo:

    WSADIEWorkspaceMigration.bat -WIDstartup "C:\IBM\WID\eclipse" -WIDworkspace 
    "c:\WID Workspaces\myWIDWorkspace" -WSADIEworkspace "c:\wsadie workspaces\myWSADIEWorkspace"
  3. Una vez finalizada la ejecución del mandato, inicie el espacio de trabajo nuevo en WebSphere Integration Developer.
  4. Construya el espacio de trabajo creado e intente resolver los errores de construcción. Examine todos los archivos BPEL migrados y compruebe que se han migrado por completo y que se pueden abrir en el editor BPEL de WebSphere Integration Developer. Hay algunos fragmentos de código Java BPEL que no se pueden migrar automáticamente. Si aprecia errores en los fragmentos de código Java BPEL, consulte la sección "Migrar al modelo de programación de SCA" para conocer los pasos necesarios para corregir los errores.
  5. Abra el editor de dependencias para asegurarse de que las dependencias se han establecido correctamente. Para ello, vaya a la perspectiva Integración de negocio y realice una doble pulsación en el proyecto de módulo de integración de negocio. En esta ubicación puede añadir dependencias a los proyectos de biblioteca de integración de negocio, proyectos Java y proyectos J2EE.

Verificar la migración de artefactos origen

Si la migración finaliza con una lista de errores, avisos y mensajes informativos, éstos se visualizarán en la ventana Resultados de migración. De lo contrario, la ventana del asistente se cerrará si la migración ha terminado correctamente.

Por qué y cuándo se efectúa esta tarea

La página siguiente se visualiza si se han generado mensajes durante el proceso de migración:

Ventana Resultados de la migración

En la ventana Resultados de la migración, puede ver los mensajes que se han generado durante el proceso de migración. Si selecciona un mensaje en la lista superior, Mensajes, obtendrá más información relativa a ese mensaje en la ventana inferior, Descripción del mensaje.

Para conservar todos los mensajes para consultas futuras, pulse el botón Generar tareas pendientes para crear una lista de tareas "Pendientes" en la vista de tareas o pulse el botón Guardar como... para guardar los mensajes en un archivo de texto del sistema de archivos. Examine cada uno de los mensajes para ver si debe realizar alguna acción para corregir de inmediato un artefacto que no se ha migrado por completo. Para ver las Tareas pendientes generadas, pulse Ventana -> Mostrar vista -> Otras... -> General -> Tareas y pulse Aceptar. La vista Tareas se abre con la lista de tareas pendientes generadas desde el proceso de migración.

Para verificar que una parte de la migración está completa, vaya a la perspectiva Integración de negocio y asegúrese de que todos los procesos y las interfaces WSDL del anterior proyecto de servicio aparecen en el nuevo módulo. Construya el proyecto y corrija los errores que impidan su construcción.

Tras realizar los pasos manuales de migración necesarios para finalizar la migración de la aplicación de integración de negocio, exporte la aplicación como un archivo EAR e instálela en un servidor WebSphere Process Server, además de configurar los recursos adecuados.

Efectúe los pasos manuales de migración necesarios para migrar el código de cliente o generar nuevo código de cliente con WebSphere Integration Developer. Asegúrese de que el cliente puede acceder a la aplicación y que la aplicación presenta el mismo comportamiento que en el entorno de ejecución anterior.

Trabajar con los errores de migración de artefactos origen

Si se producen anomalías en la migración de artefactos origen de WebSphere Studio Application Developer Integration Edition, existen diversos métodos para manejar los errores.

Por qué y cuándo se efectúa esta tarea

Los ejemplos siguientes muestran algunos de los errores de migración de artefactos origen posibles:

Si el asistente de migración finaliza sin mostrar este mensaje, se visualizará una lista de mensajes informativos, de aviso y de error. Estos indican que alguna parte del proyecto de servicio no se ha podido migrar automáticamente y que deben realizarse cambios manuales para completar la migración.

Limitaciones de la migración de artefactos origen

Existe una serie de limitaciones en el proceso de migración de artefactos origen de WebSphere Studio Application Developer Integration Edition.

A continuación se indican las limitaciones del proceso de migración de artefactos origen:

Limitaciones generales

Limitaciones de la migración de proyectos EJB

Puede que encuentre un problema en la migración si el espacio de trabajo origen de WebSphere Studio Application Developer Integration Edition contiene un proyecto EJB sin un proyecto de cliente EJB. Si el proyecto EJB es una dependencia de uno o varios proyectos de servicio, el espacio de trabajo migrado se creará satisfactoriamente, pero no se desplegará correctamente. Esto ocurre porque WebSphere Integration Developer intenta desplegar el proyecto EJB como módulo J2EE y no como jar de programa de utilidad. Para resolver este problema, siga estos pasos:

  1. Migre el espacio de trabajo.
  2. En WebSphere Integration Developer, pulse con el botón derecho del ratón Proyecto EJB -> Herramientas J2EE -> Crear proyecto de cliente. Se creará un proyecto de cliente EJB.
  3. Sustituya todas las referencias al proyecto EJB en los módulos por el cliente EJB.

Limitaciones del modelo de programación SCA

Limitaciones técnicas del proceso de migración de BPEL

Información de migración adicional

Aunque la migración haya sido satisfactoria, puede que desee revisar las secciones siguientes para identificar las tareas necesarias para completar la migración del espacio de trabajo. La información de esta sección puede utilizarse para comprobar que la migración ha finalizado.

Por qué y cuándo se efectúa esta tarea

  1. Abra WebSphere Integration Developer y vaya a la perspectiva Integración de negocio. Verá los módulos que ha creado el asistente de migración (un módulo por proyecto de servicio migrado). El primer artefacto que aparece bajo el proyecto es el archivo de ensamblado del módulo (denominado igual que el módulo).
  2. Realice una doble pulsación en el archivo de ensamblaje para abrirlo en el editor de ensamblajes donde los componentes SCA se pueden crear y conectar entre sí para obtener funciones similares a las de la aplicación de la versión 5.1. Si había procesos BPEL en el espacio de trabajo de WebSphere Studio Application Developer Integration Edition, el asistente de migración habrá creado componentes SCA predeterminados para cada uno de esos procesos y estarán en el editor de ensamblajes.
  3. Seleccione un componente y vaya a la vista Propiedades donde aparecen y pueden editarse las propiedades de descripción, detalles e implementación.

Quizás sea necesario volver a conectar algo para algunos proyectos después de la migración para volver a conectar los servicios tal y como estaban en 5.1. La información siguiente describe con mayor detalle cómo volver a conectar manualmente la aplicación mediante las herramientas disponibles en WebSphere Integration Developer.

Crear componentes SCA e Importaciones SCA para los servicios en la aplicación para volver a conectar

Es necesario conectar todos los procesos de negocio a los socios de negocio. Es necesario crear un componente o una importación SCA para todos los demás tipos de servicio. Para los proyectos de servicio de WebSphere Studio Application Developer Integration Edition que interactúan con sistemas o entidades externas al proyecto, puede crearse una Importación SCA para que el proyecto migrado acceda a esas entidades como servicios de acuerdo con el modelo SCA.

Por qué y cuándo se efectúa esta tarea

Nota: El asistente Migración intenta hacerlo automáticamente, pero puede consultar la información siguiente para comprobar lo que ha hecho la herramienta.

Para los proyectos de servicio de WebSphere Studio Application Developer Integration Edition que interactúan con entidades en el proyecto (por ejemplo, un proceso de negocio, un servicio transformador o una clase Java), puede crearse una Importación SCA para que el proyecto migrado acceda a esas entidades como servicios de acuerdo con el modelo SCA.

Las secciones siguientes proporcionan detalles acerca de la Importación SCA o los Componentes SCA que hay que crear basándose en el tipo de servicio que debe migrarse:

Migrar un servicio Java

Puede migrar un servicio Java a un componente Java SCA.

Por qué y cuándo se efectúa esta tarea

En WebSphere Studio Application Developer Integration Edition al generar un nuevo servicio Java a partir de una clase Java existente, se proporcionaban las opciones siguientes:

Hay muchos componentes nuevos que ofrecen nuevas funciones como por ejemplo correlación de datos, mediación de interfaces, máquinas de estado de negocio, selectores, reglas de negocio y más. Primero debe determinar si uno de estos tipos de componente nuevos pueden sustituir el componente Java personalizado. Si eso no es posible, siga la vía de acceso de migración que se describe a continuación.

Utilizar el asistente Migración resultará en la creación de un módulo de integración de negocio con los mensajes, tipos de puerto, enlaces y servicios de WSDL generados en WebSphere Studio Application Developer Integration Edition.

En la perspectiva Integración de negocio, expanda el módulo para ver el contenido correspondiente. Abra el Editor de ensamblajes efectuando una doble pulsación sobre el primer elemento bajo el proyecto de módulo (tendrá el mismo nombre que el proyecto.)

Nota: Si el asistente Migración no migró completamente todos los proyectos de servicio, tendrá las opciones siguientes:

Crear el componente Java personalizado: opción 1

Si el asistente Migración no migró completamente todos los proyectos de servicio, puede utilizar el tipo de componente Java de WebSphere Integration Developer para representar el servicio Java como un componente SCA. Durante la migración, debe escribir código Java personalizado para convertir entre el estilo de interfaz Java SCA y el estilo de interfaz del componente Java existente.

Por qué y cuándo se efectúa esta tarea

Para crear el componente Java personalizado, siga estos pasos:

  1. En el proyecto del módulo, expanda Interfaces y seleccione la interfaz WSDL generada para esta clase Java en WebSphere Studio Application Developer Integration.
  2. Arrastre y suelte esta interfaz en el Editor de ensamblaje. Aparecerá un diálogo en el que se le pedirá que seleccione el tipo de componente a crear. Seleccione Componente sin tipo de implementación y pulse Aceptar.
  3. Aparecerá un componente en el diagrama de ensamblaje. Selecciónelo y vaya a la vista Propiedades.
  4. En la pestaña Descripción puede cambiar el nombre y el nombre de visualización del componente por algo más descriptivo.
  5. En la pestaña Detalles verá que este componente tiene una interfaz, la interfaz que arrastró y soltó en el Editor de ensamblaje.
  6. Asegúrese de que la clase Java a la que está intentando acceder está en la vía de acceso de clases del proyecto de servicio si no está contenida en el mismo proyecto de servicio.
  7. Pulse con el botón derecho sobre el proyecto del módulo y seleccione Abrir editor de dependencias.... Bajo la sección Java, asegúrese de que aparece el proyecto que contiene la clase Java antigua. Si no es así, añádala pulsando Añadir....
  8. En el editor de ensamblaje, pulse con el botón derecho el componente que acaba de crear y seleccione Generar implementación... -> Java. A continuación seleccione el paquete en el que se generará la implementación Java. Esto crea un servicio Java de esqueleto que se adhiere a la interfaz WSDL de acuerdo con el modelo de programación SCA, en el que los tipos complejos estás representados por un objeto que es un commonj.sdo.DataObject y los tipos simples están representados por los equivalentes de objeto Java.

Los ejemplos de código siguientes muestran:

  1. Definiciones relevantes de la interfaz WSDL 5.1
  2. Los métodos Java de WebSphere Studio Application Developer Integration Edition 5.1 correspondientes al WSDL
  3. Los métodos Java de WebSphere Integration Developer 6.x para el mismo WSDL

El código siguiente muestra las definiciones relevantes de la interfaz WSDL de 5.1:

<types>
	<schema xmlns="http://www.w3.org/2001/XMLSchema" 
    			attributeFormDefault="qualified" 
    			elementFormDefault="unqualified"    
    			targetNamespace="http://migr.practice.ibm.com/" 
    			xmlns:xsd1="http://migr.practice.ibm.com/">

			<complexType name="StockInfo">
				<all>
					<element name="index" type="int"/>
					<element name="price" type="double"/>
					<element name="symbol" nillable="true" 
							    type="string"/>

				</all>
			</complexType>
	</schema>
</types>

<message name="getStockInfoRequest">
	<part name="symbol" type="xsd:string"/>
</message>
<message name="getStockInfoResponse">
	<part name="result" type="xsd1:StockInfo"/>
</message>

	<operation name="getStockInfo" parameterOrder="symbol">
			<input message="tns:getStockInfoRequest" 
							name="getStockInfoRequest"/>
			<output message="tns:getStockInfoResponse" 
 			 				name="getStockInfoResponse"/>
        </operation>

El código siguiente muestra los métodos Java de WebSphere Studio Application Developer Integration Edition 5.1 correspondientes al WSDL:

public StockInfo getStockInfo(String symbol)
	{
		return new StockInfo();
	}

	public void setStockPrice(String symbol, float newPrice)
	{
		// establecer cosas
	}

El código siguiente muestra los métodos Java de WebSphere Integration Developer 6.x para el mismo WSDL:

public DataObject getStockInfo(String aString) {
		//TODO Hay que implementar.
		return null;
	}

	public void setStockPrice(String symbol, Float newPrice) {
		//TODO Hay que implementar.
	}

Ahora necesitará cumplimentar el código en el que verá los códigos "//TODO" en la clase de implementación Java generada. Hay dos opciones:

  1. Mueva la lógica de la clase Java original a esta clase, adaptándola para utilizar DataObjects
  2. Cree una instancia privada de la antigua clase Java dentro de esta clase Java generada y escriba código para:
    1. Convertir todos los parámetros de la clase de implementación Java generada en parámetros esperados por la clase Java antigua
    2. Invocar la instancia privada de la clase Java antigua con los parámetros convertidos
    3. Convertir el valor de retorno de la clase Java antigua en el tipo de valor de retorno declarado por el método de implementación Java generado
    4. Esta opción se recomienda para los casos de consumo en los que los componentes Java de estilo 6.x nuevos deben consumir proxys de servicio WSIF.

Una vez completada una de las opciones anteriores, debe volver a conectar el servicio Java. No debería haber referencias, por lo tanto, necesita volver a conectar la interfaz del componente Java:

Crear un servicio Web Java: opción 2

Si el asistente Migración no migró completamente todos los proyectos de servicio, una opción alternativa a tener en cuenta son las herramientas de servicios web de Rational Application Developer que permiten crear un servicio web alrededor de una clase Java.

Por qué y cuándo se efectúa esta tarea

Nota: Consulte la información del sitio siguiente antes de intentar migrar utilizando este método: Crear un servicio web a partir de un bean Java
Nota: Esta opción requiere configurar un tiempo de ejecución de servicio Web a través de WebSphere Integration Developer antes de invocar el asistente de servicio Web.

Si siguió un procedimiento de abajo arriba en WebSphere Studio Application Developer Integration Edition para generar WSDL alrededor de la clase Java, siga estos pasos:

  1. Cree un proyecto Web nuevo y copie la clase Java que desea construir como un servicio alrededor de la carpeta fuente Java de este proyecto Web.
  2. Pulse con el botón derecho del ratón sobre el proyecto de aplicación de empresa que es el contenedor de la clase Java alrededor de la cuál está creando un servicio.
  3. Seleccione Propiedades, vaya a las propiedades del Servidor y asegúrese de que Tiempo de ejecución destino esté establecido en WebSphere Process Server v6.1 y que Servidor por omisión esté establecido en el WebSphere Process Server v6.1 instalado.
  4. Inicie el servidor de prueba, despliegue esta aplicación en el servidor y asegúrese de que se inicia satisfactoriamente.
  5. A continuación, pulse con el botón derecho sobre la clase Java alrededor de la cuál desea crear un servicio y seleccione Servicios Web -> Crear servicio Web.
  6. Para Tipo de servicio Web seleccione Servicio Web de bean Java y quite la marca de la opciónIniciar servicio Web en el proyecto Web a menos que desee desplegar inmediatamente el servicio Web. También puede optar por generar un proxy de cliente. Pulse Siguiente.
  7. Se mostrará la clase Java que ha pulsado con el botón derecho, pulse Siguiente.
  8. Ahora debe configurar las opciones de despliegue de servicio. Pulse Editar.... Para el tipo de servidor, elija Servidor WPS v6.1 y para el tiempo de ejecución de servicio Web, elija IBM WebSphere y J2EE versión 1.4. Si no es capaz de seleccionar una combinación válida haciendo esto, consulte la sección "Prepararse para la migración" para obtener información acerca de cómo migrar los proyectos J2EE al nivel de v1.4. Pulse Aceptar.
  9. Para el proyecto de servicio, especifique el nombre del proyecto Web. Además, seleccione el proyecto EAR adecuado. Pulse Siguiente. Tenga en cuenta que posiblemente deberá esperar varios minutos.
  10. En el panel Identidad del bean Java del servicio Web, seleccione el archivo WSDL que contendrá las definiciones WSDL. Elija los métodos que desea exponer en el servicio Web y elija el estilo/la codificación adecuados (Documento/Literal, RPC/Literal o RPC/Codificado.) Seleccione la opción Definir correlación personalizada para paquete a espacio de nombres y seleccione un espacio de nombres que sea exclusivo de la clase Java migrada para todos los paquetes Java utilizados por esta interfaz de la clase Java (el espacio de nombres por omisión será exclusivo del nombre de paquete, lo que puede provocar conflictos si crea otro servicio Web que utilice las mismas clases Java). Cumplimente los demás parámetros si procede.
  11. Pulse Siguiente y, en el panel Correlación de paquete de servicio Web con espacio de nombres, pulse el botón Añadir y, en la fila que se crea, especifique el nombre del bean de Java y luego el espacio de nombres personalizado que identifica de forma exclusiva a la clase Java. Continúe añadiendo correlaciones para todos los paquetes Java utilizados por la interfaz JavaBeans.
  12. Pulse Siguiente. Tenga en cuenta que posiblemente deberá esperar varios minutos.
  13. Pulse Finalizar. Después de completar el asistente, debe copiar el archivo WSDL generado que describe el servicio Java para el proyecto de módulo de integración de negocio si el proyecto de servicio era un consumidor del servicio Java. Se encuentra en el proyecto Web de direccionador generado bajo la carpeta WebContent/WEB-INF/wsdl. Renovar/reconstruir el proyecto de módulo de integración de negocio.
  14. Pase a la perspectiva Integración de negocio, expanda el módulo y después la categoría lógica Puertos de servicio Web.
  15. Seleccione el puerto creado en los pasos anteriores, arrástrelo y suéltelo en el Editor de ensamblaje y seleccione crear una Importación con enlace de servicio Web. Seleccione la interfaz WSDL de la clase Java si se le solicita. Ahora, el componente SCA que consumía el componente Java en 5.1 puede conectarse a esta Importación para completar los pasos de migración de reconexión manual.

Tenga en cuenta que la interfaz puede ser ligeramente distinta de la interfaz de 5.1 y que puede ser necesario insertar un componente de mediación de interfaz entre el consumidor de 5.1 y la nueva Importación. Para hacerlo, pulse la herramienta de conexión del Editor de ensamblaje y conecte el componente origen de SCA con esta Importación con enlace de servicio Web. Como las interfaces son diferentes, se le indicará lo siguiente: Los nodos origen y destino no tienen interfaces coincidentes. Elija crear una correlación de interfaces entre el nodo destino y el origen. Efectúe una doble pulsación sobre el componente de correlación creado en el Editor de ensamblaje. Esto abrirá el editor de correlaciones. Consulte el Centro de información para obtener instrucciones acerca de cómo crear una correlación de interfaces.

Si siguió un procedimiento descendente en WebSphere Studio Application Developer Integration Edition, la generación de clases Java a partir de una definición WSDL, siga estos pasos:

  1. Cree un proyecto Web nuevo y copie el archivo WSDL a partir del cuál desea generar el esqueleto Java en esta carpeta fuente del proyecto Web.
  2. Pulse con el botón derecho del ratón el archivo WSDL que contiene el PortType a partir del cuál desea generar un esqueleto Java y seleccione Servicios Web -> Generar esqueleto de bean Java.
  3. Elija el tipo de servicio Web Servicio Web de bean Java de esqueleto y cumplimente el asistente.

Después de completar el asistente, debe tener clases Java que implementen la interfaz de servicio y no sean dependientes de las API de WSIF.

Ventajas e inconvenientes de las opciones de reconexión de servicios Java

Si el asistente Migración no migró completamente todos los proyectos de servicio y ha optado por hacerlo manualmente, tenga en cuenta que hay ventajas y desventajas para las opciones de reconexión de servicios Java.

La lista siguiente describe las opciones y las ventajas e inconvenientes de cada una:

Migrar un servicio EJB

Puede migrar un servicio EJB a una Importación SCA con enlace de bean de sesión sin estado.

Por qué y cuándo se efectúa esta tarea

Importe el espacio de trabajo utilizando el asistente Migración. Esto resultará en la creación de un módulo de integración de negocio con los mensajes, tipos de puerto, enlaces y servicios de WSDL generados en WebSphere Studio Application Developer Integration Edition.

En la perspectiva Integración de negocio, expanda el módulo para ver el contenido correspondiente. Abra el Editor de ensamblajes efectuando una doble pulsación sobre el primer elemento bajo el proyecto de módulo (tendrá el mismo nombre que el proyecto.)

Si el asistente Migración no migró completamente todos los proyectos de servicio, tendrá las opciones siguientes:

Crear el componente EJB personalizado: opción 1

Si el asistente Migración no migró completamente todos los proyectos de servicio, puede utilizar el tipo de importación con enlace de sesión sin estado de WebSphere que permite invocar un EJB de sesión sin estado como un componente SCA. Durante la migración, el código Java personalizado debe escribirse para convertirlo entre el estilo de interfaz Java SCA y el estilo de interfaz EJB existente.

Por qué y cuándo se efectúa esta tarea

Nota: Aunque la herramienta de migración maneja automáticamente esta operación, los cambios efectuados después de la migración en las interfaces y los tipos de datos (objetos de negocio) implicados en la interfaz EJB requerirán actualizaciones manuales del código de conversión mencionado anteriormente. es posible que se visualizan errores en WebSphere Integration Developer dependiendo del tipo de cambio efectuado.

Para crear el componente EJB personalizado, siga estos pasos:

  1. En el proyecto de módulo, expanda Interfaces y seleccione la interfaz WSDL generada para este EJB en WebSphere Studio Application Developer Integration.
  2. Arrastre y suelte esta interfaz en el Editor de ensamblaje. Aparecerá un diálogo en el que se le pedirá que seleccione el tipo de componente a crear. Seleccione Componente sin tipo de implementación y pulse Aceptar.
  3. Aparecerá un componente en el diagrama de ensamblaje. Selecciónelo y vaya a la vista Propiedades.
  4. En la pestaña Descripción puede cambiar el nombre y el nombre de visualización del componente por algo más descriptivo. Elija un nombre como el del EJB pero añada un sufijo como por ejemplo "JavaMed" ya que esto será un componente Java que medie entre la interfaz WSDL generada para el EJB en WebSphere Studio Application Developer Integration y la interfaz Java del EJB.
  5. En la pestaña Detalles verá que este componente tiene una interfaz, la interfaz que arrastró y soltó en el Editor de ensamblaje.
  6. En el editor de ensamblaje, pulse con el botón derecho el componente que acaba de crear y seleccione Generar implementación... -> Java. A continuación seleccione el paquete en el que se generará la implementación Java. Esto crea un servicio Java de esqueleto que se adhiere a la interfaz WSDL de acuerdo con el modelo de programación SCA, en el que los tipos complejos estás representados por un objeto que es un commonj.sdo.DataObject y los tipos simples están representados por los equivalentes de objeto Java.

Los ejemplos de código siguientes muestran:

  1. Definiciones relevantes de la interfaz WSDL 5.1
  2. Los métodos Java de WebSphere Studio Application Developer Integration Edition 5.1 correspondientes al WSDL
  3. Los métodos Java de WebSphere Integration Developer 6.x para el mismo WSDL

El código siguiente muestra las definiciones relevantes de la interfaz WSDL de 5.1:

<types>
	<schema xmlns="http://www.w3.org/2001/XMLSchema" 
    			attributeFormDefault="qualified" 
    			elementFormDefault="unqualified"    
    			targetNamespace="http://migr.practice.ibm.com/" 
    			xmlns:xsd1="http://migr.practice.ibm.com/">

			<complexType name="StockInfo">
				<all>
					<element name="index" type="int"/>
					<element name="price" type="double"/>
					<element name="symbol" nillable="true" 
							    type="string"/>

				</all>
			</complexType>
	</schema>
</types>

<message name="getStockInfoRequest">
	<part name="symbol" type="xsd:string"/>
</message>
<message name="getStockInfoResponse">
	<part name="result" type="xsd1:StockInfo"/>
</message>

	<operation name="getStockInfo" parameterOrder="symbol">
			<input message="tns:getStockInfoRequest" 
							name="getStockInfoRequest"/>
			<output message="tns:getStockInfoResponse" 
 			 				name="getStockInfoResponse"/>
        </operation>

El código siguiente muestra los métodos Java de WebSphere Studio Application Developer Integration Edition 5.1 correspondientes al WSDL:

public StockInfo getStockInfo(String symbol)
	{
		return new StockInfo();
	}

	public void setStockPrice(String symbol, float newPrice)
	{
		// establecer cosas
	}

El código siguiente muestra los métodos Java de WebSphere Integration Developer 6.x para el mismo WSDL:

public DataObject getStockInfo(String aString) {
		//TODO Hay que implementar.
		return null;
	}

	public void setStockPrice(String symbol, Float newPrice) {
		//TODO Hay que implementar.
	}

También deberá cumplimentar código real cuando vea códigos "//TODO" en la clase de implementación Java. Primero debe crear una referencia de este componente Java al EJB real para que pueda acceder al EJB de acuerdo con el modelo de programación SCA:

  1. Deje el editor de ensamblaje abierto y pase a la perspectiva J2EE. Busque el proyecto EJB que contiene el EJB para el que está creando un servicio.
  2. Expanda el elemento Descriptor de despliegue: <nombre-proyecto> y busque el EJB. Arrástrelo y suéltelo en el Editor de ensamblaje. Si recibe un aviso acerca de la necesidad de actualizar las dependencias de proyecto, marque el recuadro de selección Abrir el editor de dependencias de módulo y pulse Aceptar.
  3. Asegúrese de que el proyecto EJB aparece bajo la sección J2EE y si no es así, añádalo pulsando Añadir....
  4. Guarde las dependencias de módulo y cierre el editor. Verá que se creó una Importación nueva en el Editor de ensamblaje. Puede seleccionarlo e ir a la vista Propiedades en la pestaña Descripción para cambiar el nombre de la importación y el nombre de visualización por algo más significativo. En la pestaña Enlace verá que el tipo de importación se establece automáticamente en Enlace de bean de sesión sin estado y que el nombre JNDI del EJB ya se ha establecido adecuadamente.
  5. Seleccione la herramienta Conectar en la paleta, en el Editor de ensamblaje.
  6. Pulse el componente Java y suelte el ratón.
  7. A continuación pulse la Importación EJB y suelte el ratón.
  8. Cuando se le pregunte Se creará una referencia coincidente en el nodo origen. ¿Desea continuar?, pulse Aceptar. Esto crea una conexión entre los dos componentes.
  9. Seleccione el componente Java en el Editor de ensamblaje y en la vista Propiedades bajo la pestaña Detalles, expanda Referencias y seleccione la referencia al EJB recién creado. Puede actualizar el nombre de la referencia si el nombre generado no es muy descriptivo o adecuado. Recuerde el nombre de esta referencia para utilizarla en el futuro.
  10. Guarde el diagrama de ensamblaje.

Debe utilizar el modelo de programación SCA para invocar el EJB a partir de la clase Java generada. Abra la clase Java generada y siga estos pasos para escribir el código que invocará el servicio EJB. Para la clase de implementación Java generada:

  1. Cree una variable privada (cuyo tipo sea el de la interfaz EJB remota):
    private YourEJBInterface ejbService = null;
  2. Si hay tipos complejos en la interfaz EJB, cree también una variable privada para BOFactory:
    private BOFactory boFactory = (BOFactory) 
    	ServiceManager.INSTANCE.locateService("com/ibm/websphere/bo
    	/BOFactory");
  3. En el constructor de la clase de implementación Java, utilice las API SCA para resolver la referencia EJB (recuerde cumplimentar el nombre de la referencia EJB que anotó en un paso anterior) y establecer la variable privada igual a esta referencia:
    // Buscar el servicio EJB
    	this.ejbService = (YourEJBInterface) 
    	ServiceManager.INSTANCE.locateService("nombre-de-su-referencia-EJB");

Por cada "//TODO" de la clase de implementación Java generada:

  1. Convierta todos los parámetros en los tipos de parámetro esperados por el EJB.
  2. Invoque el método adecuado en la referencia EJB utilizando el modelo de programación SCA, enviando los parámetros convertidos.
  3. Convierta el valor de retorno del EJB en el tipo de valor de retorno declarado por el método de implementación Java generado
/**
	 * Método generado para soportar el tipo de puerto WSDL de implementación llamado
	 * "interface.MyBean".
	 */
	public DataObject getStockInfo(String aString) {
		DataObject boImpl = null;

		try {

			// invocar el método EJB
			StockInfo stockInfo = this.ejbService.getStockInfo(aString);

			// formular el objeto de datos SCA para retorno.
			boImpl = (DataObject) 
					this.boFactory.createByClass(StockInfo.class);

			// convertir manualmente todos los datos del tipo de retorno EJB en el 
			// objeto de datos SCA a retornar
			boImpl.setInt("index", stockInfo.getIndex());
			boImpl.setString("symbol", stockInfo.getSymbol());
			boImpl.setDouble("price", stockInfo.getPrice());
		} catch (RemoteException e) {
			e.printStackTrace();
		}
		return boImpl;
	}

	/**
	 * Método generado para soportar el tipo de puerto WSDL de implementación llamado
	 * "interface.MyBean".
	 */
	public void setStockPrice(String symbol, Float newPrice) {
		try {
			this.ejbService.setStockPrice(symbol, newPrice.floatValue());
		} catch (RemoteException e) {
			e.printStackTrace();
		}

	}
Crear un servicio Web EJB: opción 2

Si el asistente Migración no migró completamente todos los proyectos de servicio, una opción alternativa a tener en cuenta son las herramientas de servicios Web de Rational Application Developer que permiten crear un servicio Web alrededor de un EJB.

Por qué y cuándo se efectúa esta tarea

Nota: Consulte la información del sitio siguiente antes de intentar migrar utilizando este método: Crear un servicio Web desde un bean de empresa (EJB) utilizando el entorno de ejecución de WebSphere
Nota: Esta opción requiere configurar un tiempo de ejecución de servicio Web a través de WebSphere Integration Developer antes de invocar el asistente de servicio Web.

Para crear un servicio Web alrededor de un EJB, siga estos pasos:

  1. Pulse con el botón derecho del ratón sobre el proyecto de aplicación de empresa que es el contenedor del EJB alrededor del cuál está creando un servicio.
  2. Seleccione Propiedades, vaya a las propiedades del Servidor y asegúrese de que Tiempo de ejecución destino esté establecido en WebSphere Process Server v6.1 y que Servidor por omisión esté establecido en el WebSphere Process Server v6.1 instalado.
  3. Inicie el servidor de prueba, despliegue esta aplicación en el servidor y asegúrese de que se inicia satisfactoriamente.
  4. En la perspectiva J2EE, expanda el Proyecto EJB en la vista Explorador de proyectos. Expanda el Descriptor de despliegue y la categoría Beans de sesión. Seleccione el bean alrededor del cuál desea generar el servicio Web.
  5. Pulse con el botón derecho del ratón y seleccione Servicios Web -> Crear servicio Web.
  6. Para Tipo de servicio Web seleccione Servicio Web EJB y quite la marca de la opciónIniciar servicio Web en el proyecto Web a menos que desee desplegar inmediatamente el servicio Web. Pulse Siguiente.
  7. Asegúrese de que el EJB que pulsó con el botón derecho está seleccionado aquí y pulse Siguiente.
  8. Ahora debe configurar las opciones de despliegue del servicio. Pulse Editar.... Para el tipo de servidor, elija Servidor WPS v6.1 y para el tiempo de ejecución de servicio Web, elija IBM WebSphere y J2EE versión 1.4. Si no es capaz de seleccionar una combinación válida haciendo esto, consulte la sección "Prepararse para la migración" para obtener información acerca de cómo migrar los proyectos J2EE al nivel de v1.4. Pulse Aceptar.
  9. Para el proyecto de servicio, especifique el nombre del proyecto EJB que contiene el EJB. Además, seleccione el proyecto EAR adecuado. Pulse Siguiente. Tenga en cuenta que posiblemente deberá esperar varios minutos.
  10. En el panel Configuración EJB de servicio Web, seleccione el proyecto de direccionador adecuado a utilizar (elija el nombre del proyecto Web de direccionador que desearía crear y este proyecto se añadirá a la misma aplicación de empresa que el EJB original. Seleccione el transporte (SOAP sobre HTTP o SOAP sobre JMS). Pulse Siguiente.
  11. Seleccione el archivo WSDL que contendrá las definiciones WSDL. Elija los métodos que desea exponer en el servicio Web y elija el estilo/la codificación adecuados (Documento/Literal, RPC/Literal o RPC/Codificado.) Seleccione la opción Definir correlación personalizada para paquete a espacio de nombres y seleccione un espacio de nombres que sea exclusivo del EJB migrado para todos los paquetes Java utilizados por el EJB (el espacio de nombres por omisión será exclusivo del nombre de paquete, lo que puede provocar conflictos si crea otro servicio Web que utilice las mismas clases Java). Cumplimente los demás parámetros si procede. Hay limitaciones para cada combinación de estilo/codificación. Consulte las limitaciones para obtener más información: Limitaciones de los servicios Web
  12. Pulse Siguiente y, en el panel Correlación de paquete de servicio Web con espacio de nombres, pulse Añadir y, en la fila que se crea, especifique el nombre del paquete del EJB y luego el espacio de nombres personalizado que identifica de forma exclusiva a este EJB. Continúe añadiendo correlaciones para todos los paquetes Java utilizados por la interfaz EJB.
  13. Pulse Siguiente. Tenga en cuenta que posiblemente deberá esperar varios minutos.
  14. Pulse Finalizar. Después de completar el asistente, debe copiar el archivo WSDL generado que describe el servicio EJB para el proyecto de módulo de integración de negocio si el proyecto de servicio era un consumidor del servicio EJB. Se encuentra en el proyecto Web de direccionador generado bajo la carpeta WebContent/WEB-INF/wsdl. Renovar/reconstruir el proyecto de módulo de integración de negocio.
  15. Pase a la perspectiva Integración de negocio, expanda el módulo migrado y después la categoría lógica Puertos de servicio Web.
  16. Seleccione el puerto generado en los pasos anteriores, arrástrelo y suéltelo en el Editor de ensamblaje y seleccione crear una Importación con enlace de servicio Web. Seleccione la interfaz WSDL del EJB si se le solicita. Ahora, el componente SCA que consumía el EJB en 5.1 puede conectarse a esta Importación para completar los pasos de migración de reconexión manual.

Si siguió un procedimiento descendente en WebSphere Studio Application Developer Integration Edition, la generación de un esqueleto EJB a partir de una definición WSDL, siga estos pasos:

  1. Cree un proyecto Web y copie el archivo WSDL a partir del cuál desea generar el esqueleto EJB en esta carpeta origen del proyecto Web.
  2. Pulse el archivo WSDL que contiene el PortType a partir del cuál desea generar un esqueleto EJB y seleccione Servicios Web -> Generar esqueleto de bean Java.
  3. Elija el tipo de servicio Web Servicio Web EJB esqueleto y cumplimente el asistente.

Después de completar el asistente, debe tener un EJB que implemente la interfaz de servicio y que no sea dependiente de las API de WSIF.

Tenga en cuenta que la interfaz puede ser ligeramente distinta de la interfaz de 5.1 y que puede ser necesario insertar un componente de mediación de interfaz entre el consumidor de 5.1 y la nueva Importación. Para hacerlo, pulse la herramienta de conexión del Editor de ensamblaje y conecte el componente origen de SCA con esta Importación con enlace de servicio Web. Como las interfaces son diferentes, se le indicará lo siguiente: Los nodos origen y destino no tienen interfaces coincidentes. Elija crear una correlación de interfaces entre el nodo destino y el origen. Efectúe una doble pulsación sobre el componente de correlación creado en el Editor de ensamblaje. Esto abrirá el editor de correlaciones. Consulte el Centro de información para obtener instrucciones acerca de cómo crear una correlación de interfaces.

Una vez finalizado esto, debe volver a conectar el servicio EJB. No debería haber referencias, por lo tanto, necesita volver a conectar la interfaz del componente Java:

Ventajas y desventajas de las opciones de reconexión de servicios EJB

Si el asistente Migración no migró completamente todos los proyectos de servicio y ha optado por hacerlo manualmente, tenga en cuenta que hay ventajas y desventajas para las opciones de reconexión de servicios EJB.

La lista siguiente describe las opciones y las ventajas y desventajas de cada una:

Migrar un proceso de negocio a una invocación de servicio de proceso de negocio

Este escenario se aplica a un proceso de negocio que invoca otro proceso de negocio, donde el segundo proceso de negocio se invoca utilizando un enlace de proceso WSIF. En esta sección se muestra cómo migrar una invocación de BPEL a servicio BPEL utilizando una conexión o una Importación/Exportación con enlace SCA si el asistente Migración no migró completamente todos los proyectos de servicio.

Por qué y cuándo se efectúa esta tarea

Para migrar un proyecto de servicio de enlace de proceso (BPEL) para un servicio saliente, siga estos pasos:

  1. En la perspectiva Integración de negocio, expanda el módulo para ver el contenido correspondiente. Abra el Editor de ensamblajes efectuando una doble pulsación sobre el primer elemento bajo el proyecto de módulo (tendrá el mismo nombre que el proyecto.)
  2. Hay varios casos en los que un proceso BPEL puede invocar otro proceso BPEL. Identifique qué caso de los siguientes es aplicable a su aplicación:

Migrar un servicio Web (SOAP/JMS)

Si el asistente Migración no migró completamente todos los proyectos de servicio, puede migrar un servicio web (SOAP/JMS) a una Importación SCA con enlace de servicio web.

Por qué y cuándo se efectúa esta tarea

Para migrar un proyecto de servicio SOAP/JMS para una migración de servicio saliente, siga estos pasos:

  1. Importe el espacio de trabajo utilizando el asistente Migración. Con esta operación se creará un módulo de integración de negocio con los mensajes WSDL, los tipos de puerto, los enlaces y los servicios generados en WebSphere Studio Application Developer Integration Edition. Tenga en cuenta que si el servicio Web de IBM (SOAP/JMS) que invocará esta aplicación también es un servicio Web de WebSphere Studio Application Developer Integration Edition que se migrará, puede que haya habido actualizaciones en ese servicio Web durante la migración. En ese caso, utilice aquí los archivos WSDL migrados de ese servicio Web.
  2. En la perspectiva Integración de negocio, expanda el módulo para poder ver su contenido. Abra el Editor de ensamblajes efectuando una doble pulsación sobre el primer elemento bajo el proyecto de módulo (tendrá el mismo nombre que el proyecto.)
  3. Añada una Importación que permita a la aplicación interactuar con el servicio Web IBM (a través de SOAP/JMS) de acuerdo con el modelo de programación SCA. Asegúrese de que la interfaz, el enlace y las definiciones de servicio WSDL están presentes en el módulo migrado o en una biblioteca de la que depende el módulo migrado.
  4. En la perspectiva Integración de negocio, expanda el módulo migrado y abra el Diagrama de ensamblaje en el Editor de ensamblaje.
  5. Expanda la categoría lógica de Puertos de servicio Web y arrastre y suelte el puerto correspondiente al servicio que desea invocar en el Editor de ensamblaje.
  6. Elija crear una Importación con enlace de servicio Web.
  7. Después de crear la importación, selecciónela en el Editor de ensamblajes y vaya a la vista Propiedades. En la pestaña Enlace verá el puerto y el servicio a los que está enlazada la importación.
  8. Guarde el diagrama de ensamblaje.

Una vez que haya cumplimentado esto, debe volver a conectar el servicio:

Migrar un servicio Web (SOAP/HTTP)

Si el asistente Migración no migró completamente todos los proyectos de servicio, puede migrar un servicio web (SOAP/HTTP) a una Importación SCA con enlace de servicio web.

Por qué y cuándo se efectúa esta tarea

Para migrar un proyecto de servicio SOAP/HTTP para una migración de servicio saliente, siga estos pasos:

  1. Importe el espacio de trabajo utilizando el asistente Migración. Con esta operación se creará un módulo de integración de negocio con los mensajes WSDL, los tipos de puerto, los enlaces y los servicios generados en WebSphere Studio Application Developer Integration Edition. Tenga en cuenta que si el servicio Web de IBM (SOAP/HTTP) que invocará esta aplicación también es un servicio Web de WebSphere Studio Application Developer Integration Edition que se migrará, puede que haya habido actualizaciones en ese servicio Web durante la migración. En ese caso, utilice aquí los archivos WSDL migrados de ese servicio Web.
  2. En la perspectiva Integración de negocio, expanda el módulo para poder ver su contenido. Abra el Editor de ensamblajes efectuando una doble pulsación sobre el primer elemento bajo el proyecto de módulo (tendrá el mismo nombre que el proyecto.)
  3. Añada una Importación que permita a la aplicación interactuar con el servicio Web IBM (a través de SOAP/HTTP) de acuerdo con el modelo de programación SCA. Asegúrese de que la interfaz, el enlace y las definiciones de servicio WSDL están presentes en el módulo migrado o en una biblioteca de la que depende el módulo migrado.
  4. En la perspectiva Integración de negocio, expanda el módulo migrado y abra el Diagrama de ensamblaje en el Editor de ensamblaje.
  5. Expanda la categoría lógica de Puertos de servicio Web y arrastre y suelte el puerto correspondiente al servicio que desea invocar en el Editor de ensamblaje.
  6. Elija crear una Importación con enlace de servicio Web.
  7. Después de crear la importación, selecciónela en el Editor de ensamblajes y vaya a la vista Propiedades. En la pestaña Enlace verá el puerto y el servicio a los que está enlazada la importación.
  8. Guarde el diagrama de ensamblaje.

Una vez que haya cumplimentado esto, debe volver a conectar el servicio:

Migrar un servicio JMS

Si el asistente Migración no migró completamente todos los proyectos de servicio, puede migrar un servicio JMS a una Importación SCA con enlace JMS.

Por qué y cuándo se efectúa esta tarea

Nota: Si el mensaje JMS se envía a un WebSphere Business Integration Adapter, consulte la sección "Migrar interacciones con WebSphere Business Integration Adapter", a la que puede acceder mediante el enlace que figura más abajo.

Para migrar un proyecto de servicio JMS para una migración de servicio saliente, siga estos pasos:

  1. Importe el espacio de trabajo utilizando el asistente Migración. Con esta operación se creará un módulo de integración de negocio con los mensajes WSDL, los tipos de puerto, los enlaces y los servicios generados en WebSphere Studio Application Developer Integration Edition.
  2. En la perspectiva Integración de negocio, expanda el módulo para poder ver su contenido. Abra el Editor de ensamblajes efectuando una doble pulsación sobre el primer elemento bajo el proyecto de módulo (tendrá el mismo nombre que el proyecto.)
  3. Añada una Importación que permita a la aplicación interactuar con una cola JMS de acuerdo con el modelo de programación SCA.
  4. En el Editor de ensamblaje, expanda el proyecto de módulo migrado, expanda la categoría Interfaces y busque el PortType WSDL que describe el servicio Web que invocará la aplicación. Arrástrelo y suéltelo en el Editor de ensamblaje.
  5. Un diálogo Creación de componente permitirá seleccionar el tipo de componente a crear. Elija Importar sin enlaces.
  6. Verá que se habrá creado una Importación nueva en el Editor de ensamblaje y que si la selecciona y va a la vista Propiedades, en la pestaña Descripción podrá cambiar el nombre y el nombre de visualización de la importación por algo más significativo.
  7. Puede consultar los archivos WSDL de enlace y servicio 5.1 para encontrar detalles acerca del servicio JMS que está migrando y utilizarlos para cumplimentar los detalles de 6.x "Importar con enlace JMS". Localice los archivos WSDL de enlace y servicio JMS 5.1 dentro del proyecto de servicio 5.1 (generalmente se denominan *JMSBinding.wsdl y *JMSService.wsdl). Examine la información de enlace y servicio capturada allí. A partir del enlace, puede determinar se se han utilizado mensajes de texto u objeto y si se han utilizado enlaces de formato de datos de cliente . Si existen, debe considerar la posibilidad de escribir también un enlace de datos personalizado para la opción Exportar con enlace JMS de 6.x. Desde el servicio, puede buscar la fábrica de contexto inicial, el nombre de conexión JNDI, el nombre de destino JNDI y el estilo de destino (cola).
  8. Pulse la importación con el botón derecho del ratón, seleccione Generar enlace y después Enlace JMS. Se le solicitará que especifique los parámetros siguientes:
    Seleccione el dominio de mensajería JMS:
    • Punto a punto
    • Publicación-suscripción
    • Independiente del dominio
    Seleccione cómo se serializan los datos entre Objeto comercial y Mensaje JMS:
    • Texto
    • Objeto
    • Proporcionado por el usuario
    Si se selecciona Proporcionado por el usuario:
    Especifique el nombre completamente calificado de la clase de implementación com.ibm.websphere.sca.jms.data.JMSDataBinding. Deberá especificar un enlace de datos suministrado por usuario si la aplicación necesita establecer propiedades de cabecera JMS que no están generalmente disponibles en el enlace de importación JMS. En este caso, a puede crear una clase de enlace de datos personalizado que amplíe el enlace de datos JMS estándar "com.ibm.websphere.sca.jms.data.JMSDataBinding" y añadir código personalizado para acceder a JMSMessage directamente. Consulte los ejemplos de JMS de la sección "Crear y modificar enlaces para componentes de importación y exportación" cuyo enlace figura más abajo.
    La conectividad entrante utiliza la clase de selector de función JMS por omisión
    <selected> o <deselected>
  9. Seleccione la importación que acaba de crear. En la vista Propiedades, vaya a la pestaña Enlace. Puede cumplimentar manualmente toda la información de enlace que aparece allí con los mismos valores especificados anteriormente en WebSphere Studio Application Developer Integration Edition. La información de enlace que puede especificar es:

Una vez que haya cumplimentado esto, debe volver a conectar el servicio:

Migrar un servicio J2C-IMS

Si el asistente Migración no migró completamente todos los proyectos de servicio, puede migrar un servicio J2C-IMS a una Importación SCA con enlace EIS o a una Importación SCA con enlace de servicio Web.

Por qué y cuándo se efectúa esta tarea

No utilice ninguno de los artefactos de WebSphere Studio Application Developer Integration Edition generados para este servicio IMS. Necesitará crear el servicio utilizando los asistentes disponibles en WebSphere Integration Developer y volver a conectar manualmente la aplicación.

Nota: Active la construcción automática o construya el módulo manualmente.

Tiene las opciones siguientes:

Nota: Para ambas opciones, tenga en cuenta que si un servicio BPEL invoca este servicio IMS, el BPEL deberá cambiar ligeramente ya que la interfaz expuesta por el servicio EIS será ligeramente diferente a la interfaz 5.1 antigua. Para hacerlo, abra el editor BPEL y ajuste el enlace de socio correspondiente al servicio EIS y utilice la interfaz nueva (archivo WSDL) generada al realizar los pasos anteriores. Haga los cambios necesarios en las actividades de BPEL para la interfaz WSDL nueva del servicio EIS.

Creación de una Importación SCA para invocar el servicio IMS: opción 1

Puede crear una Importación SCA con enlace EIS que utilizará DataObjects para almacenar el mensaje/los datos para comunicarse con el sistema IMS.

Por qué y cuándo se efectúa esta tarea

Para crear una Importación SCA para invocar el servicio IMS, siga estos pasos:

  1. Cree un proyecto de módulo de integración de negocio nuevo para albergar este servicio IMS nuevo.
  2. Para crear el servicio EIS, vaya a Archivo -> Nuevo -> Otro -> Integración de negocio -> Servicio externo.
  3. Este asistente permite importar un servicio de un sistema EIS. Es muy parecido al asistente de WebSphere Studio Application Developer Integration Edition que creó el servicio EIS basado en WSIF en 5.1. Puede importar el adaptador de recursos IMS de J2C nuevo en este asistente. Debe situarse en el directorio en el que está instalado WebSphere Integration Developer y acceder a Resource Adapters -> ims15 -> imsico9102.rar.
    Nota: Consulte el Centro de información para obtener más información acerca de cómo completar las propiedades de guardado y los paneles de operaciones. Durante el asistente Servicio externo, cuando añada una operación, también podrá crear objetos de negocio para los tipo de datos de entrada o salida de la operación. Para ello es necesario tener el archivo fuente C o COBOL utilizado en el asistente de WebSphere Studio Application Developer Integration Edition. Estos archivos deben haberse copiado en el antiguo proyecto de servicio para que pueda señalar a los archivos origen que hay ahí. También puede importar los objetos de negocio utilizando el asistente Archivo -> Nuevo -> Otros -> Integración de negocio -> Datos externos.
  4. Una vez completado el asistente, abra la perspectiva Integración de negocio y expanda el módulo para poder ver el contenido correspondiente. Debe ver los objetos de negocio nuevos listados bajo los tipos de datos del módulo y las interfaces nuevas listadas bajo Interfaces.
  5. Abra el Editor de ensamblajes efectuando una doble pulsación sobre el primer elemento bajo el proyecto de módulo (tendrá el mismo nombre que el proyecto.) Debe ver que existe una Importación en el lienzo, esta Importación tiene un enlace EIS y representa el servicio que acaba de crear.

Ahora consulte la sección titulada "Crear exportaciones SCA para acceder al servicio migrado" para obtener instrucciones acerca de cómo exponer este servicio a los consumidores.

Creación de un servicio Web alrededor del servicio J2C: opción 2

Puede crear un servicio Web J2C y si el consumidor del servicio es un componente SCA, consuma el servicio como un Servicio Web IBM (SOAP/HTTP o SOAP/JMS).

Por qué y cuándo se efectúa esta tarea

Para crear un servicio Web alrededor del servicio J2C, siga estos pasos:

  1. Cree el bean Java J2C pulsando Archivo -> Nuevo -> J2C -> Bean Java J2C
  2. Elija la versión 1.5 de IMS Connector for Java y pulse Siguiente.
  3. Seleccione Conexión gestionada y especifique el nombre de búsqueda JNDI. Pulse Siguiente.
  4. Especifique el proyecto, el paquete y el nombre para el bean Java nuevo. El bean consta de una interfaz y una clase de implementación. Pulse Siguiente.
  5. Añada un método Java para cada función o servicio a la que desea acceder desde el EIS. Pueden añadirse métodos adicionales posteriormente en el editor fuente de Java a través de la vista Fragmentos de código. Cuando pulse el botón Añadir..., elija el nombre para el método y pulse Siguiente.
  6. Ahora puede elegir Examinar... para reutilizar tipos existentes o Nuevo... para lanzar el asistente Enlace de datos Java CICS/IMS (donde puede hacer referencia a un archivo fuente COBOL o C) para los tipos de datos de entrada y salida.
  7. Una vez haya terminado de crear los métodos Java, pulse Siguiente.
  8. Complete los pasos restantes de este asistente para crear el bean Java J2C.
  9. Cree el servicio Web pulsando Archivo -> Nuevo -> J2C -> Página Web, Servicio Web o EJB a partir de bean Java J2C para crear el servicio Web alrededor del bean Java J2C.
  10. Complete el asistente.

Los consumidores de este servicio ahora pueden utilizar el servicio WSDL generado por este asistente para invocar el servicio IMS.

Ventajas y desventajas de las opciones de reconexión de servicios J2C-IMS

Hay ventajas y desventajas para las opciones de reconexión de servicios J2C-IMS.

La lista siguiente describe las opciones y las ventajas y desventajas de cada una:

Migrar un servicio ECI J2C-CICS

Puede migrar un servicio ECI J2C-CICS a una Importación SCA con enlace EIS o a una Importación SCA con enlace de servicio Web.

Por qué y cuándo se efectúa esta tarea

Siga las instrucciones del tema "Migrar un servicio J2C-IMS", pero asegúrese de importar el archivo RAR siguiente en lugar del archivo RAR IMS:

Si sigue la segunda opción para crear un servicio Web J2C, elija el ECIResourceAdapter de la v1.5 en el segundo panel del asistente de creación de bean Java J2C.

Consulte también el tema "Migrar un servicio J2C-IMS".

Migrar un servicio EPI J2C-CICS

No hay soporte directo para el servicio EPI J2C-CICS en WebSphere Integration Developer. Para acceder a este servicio desde un módulo SCA, necesitará migrar utilizando el escenario de consumo.

Por qué y cuándo se efectúa esta tarea

Consulte el tema "Escenario de consumo para la migración de servicios" para obtener instrucciones acerca de cómo migrar este tipo de servicio a WebSphere Integration Developer.

Migrar un servicio J2C-HOD

No hay soporte directo para el servicio J2C-HOD en WebSphere Integration Developer. Para acceder a este servicio desde un módulo SCA, necesitará migrar utilizando el escenario de consumo.

Por qué y cuándo se efectúa esta tarea

Consulte el tema "Escenario de consumo para la migración de servicios" para obtener instrucciones acerca de cómo migrar este tipo de servicio a WebSphere Integration Developer.

Migrar un servicio transformador

Puede migrar un servicio transformador para una Correlación de datos y una Correlación de interfaces de SCA cuando sea posible. También puede utilizar el escenario de consumo para acceder a este servicio desde un módulo SCA.

Por qué y cuándo se efectúa esta tarea

Los componentes de correlación de datos y de correlación de interfaces ofrecen una función parecida al servicio transformador de 5.1 pero no tienen la posibilidad de transformación XSL completa. Si no puede sustituir el servicio transformador con uno de estos componentes, debe migrar utilizando el escenario de consumo ya que no hay soporte directo para el servicio transformador en WebSphere Integration Developer. Siga los pasos documentados en la sección "Escenario de consumo para migración de servicios" para acceder a este servicio desde un módulo SCA.

Escenario de consumo para la migración de servicios

En los casos en los que no hay una contrapartida directa para un tipo de servicio de WebSphere Studio Application Developer Integration Edition, se necesita un escenario de consumo para consumir el servicio antiguo de WebSphere Studio Application Developer Integration Edition tal cual al rediseñar la aplicación en WebSphere Integration Developer.

Por qué y cuándo se efectúa esta tarea

Estos son los pasos a seguir en WebSphere Studio Application Developer Integration Edition antes de invocar el asistente Migración:

  1. Cree un proyecto Java nuevo para albergar este código proxy de cliente. No coloque este código proxy de cliente en el proyecto de servicio, ya que el asistente de migración automática que migra los proyectos de servicio pasará por alto los mensajes generados de tipo 5.1 y las clases de bean Java.
  2. Abra WebSphere Studio Application Developer Integration Edition y pulse con el botón derecho sobre el archivo WSDL que contiene el servicio y el enlace de transformador y seleccione Servicios de empresa -> Generar proxy de servicio. Se le preguntará que tipo de proxy desea crear, pero la única opción disponible será Infraestructura de invocación de servicios Web (WSIF). Pulse Siguiente.
  3. Ahora puede especificar el paquete y el nombre de la clase Java del proxy de servicio que se va a crear (creará el proxy en el proyecto de servicio actual.) Pulse Siguiente.
  4. Ahora puede especificar el estilo del proxy, elija el Apéndice de cliente, seleccione las operaciones para incluir el proxy y pulse Finalizar. Esto crea una clase Java que expone los mismos métodos que el servicio de WebSphere Studio Application Developer Integration Edition, en los que los argumentos para los métodos Java son los componentes del mensaje WSDL origen.

Ahora puede migrar a WebSphere Integration Developer:

  1. Asegúrese de que el proyecto Java está en el espacio de trabajo antiguo (el proyecto Java lo migrará automáticamente el asistente Migración).
  2. Importe el proyecto de servicio utilizando el asistente Migración. Con esta operación se creará un módulo de integración de negocio con los mensajes WSDL, los tipos de puerto, los enlaces y los servicios generados en WebSphere Studio Application Developer Integration Edition.
  3. En la perspectiva Integración de negocio, expanda el módulo para poder ver su contenido. Abra el Editor de ensamblajes efectuando una doble pulsación sobre el primer elemento bajo el proyecto de módulo (tendrá el mismo nombre que el proyecto.)
  4. Para crear el componente Java personalizado, en el proyecto del módulo, expanda Interfaces y seleccione la interfaz WSDL generada para este servicio transformador en WebSphere Studio Application Developer Integration Edition.
  5. Arrastre y suelte esta interfaz en el Editor de ensamblaje. Aparecerá un diálogo en el que se le pedirá que seleccione el tipo de componente a crear. Seleccione Componente sin tipo de implementación y pulse Aceptar.
  6. Aparecerá un componente en el diagrama de ensamblaje. Selecciónelo y vaya a la vista Propiedades.
  7. En la pestaña Descripción, puede cambiar el nombre y el nombre de visualización del componente por algo más descriptivo (en est caso el nombre es algo como el nombre del EJB pero con un sufijo añadido como por ejemplo "JavaMed" ya que esto será un componente Java que medie entre la interfaz WSDL generada para el servicio transformador en WebSphere Studio Application Developer Integration Edition y la interfaz Java del proxy de cliente de transformador.)
  8. En la pestaña Detalles verá que este componente tiene una interfaz, la interfaz que arrastró y soltó en el Editor de ensamblaje.
  9. Vuelva a al editor de ensamblaje, pulse con el botón derecho el componente que acaba de crear y seleccione Generar implementación... -> Java. A continuación seleccione el paquete en el que se generará la implementación Java. Esto crea un servicio Java de esqueleto que se adhiere a la interfaz WSDL de acuerdo con el modelo de programación SCA, en el que los tipos complejos estás representados por un objeto que es un commonj.sdo.DataObject y los tipos simples están representados por los equivalentes de objeto Java.

Ahora necesitará cumplimentar el código en el que verá los códigos "//TODO" en la clase de implementación Java generada. Hay dos opciones:

  1. Mueva la lógica de la clase Java original a esta clase, adaptándola a la estructura de datos nueva.
  2. Cree una instancia privada de la antigua clase Java dentro de esta clase Java generada y escriba código para:
    1. Convertir todos los parámetros de la clase de implementación Java generada en parámetros esperados por la clase Java antigua
    2. Invocar la instancia privada de la clase Java antigua con los parámetros convertidos
    3. Convertir el valor de retorno de la clase Java antigua en el tipo de valor de retorno declarado por el método de implementación Java generado

Una vez completadas las opciones anteriores, debe volver a conectar el proxy de cliente. No debe haber "referencias", por lo tanto, simplemente debe volver a conectar la interfaz del componente Java:

Crear Exportaciones SCA para acceder al servicio migrado

Debe crearse una Exportación SCA para poner el servicio migrado a disposición de los consumidores externos de acuerdo con el modelo SCA para todos los servicios para los que se generó el código de despliegue en el proyecto de servicio WebSphere Studio Application Developer Integration Edition. Esto incluye todos los servicios invocados por los clientes externos para la aplicación. Nota: el asistente Migración crea las exportaciones automáticamente, sin embargo, puede hacer referencia a la información siguiente para ayudar a verificar lo que ha hecho la herramienta.

Por qué y cuándo se efectúa esta tarea

Si en WebSphere Studio Application Developer Integration Edition, pulsaba con el botón derecho el proceso BPEL u otro WSDL de servicio y seleccionaba Servicios de empresa -> Generar código de despliegue, debe realizar los pasos manuales de migración siguientes. Tenga en cuenta que WebSphere Integration Developer se diferencia de WebSphere Studio Application Developer Integration Edition en que almacena todas las opciones de despliegue. Cuando se construye el proyecto, el código de despliegue se actualiza automáticamente en el EJB generado y los proyectos Web de modo que ya no hay ninguna opción para ejecutar manualmente Generar código de despliegue.

En la sección de interfaces para socios del asistente Generar código de despliegue BPEL se proporcionaban cinco opciones de enlace. La siguiente información de migración de servicio BPEL entrante ofrece más detalles sobre el tipo de exportación y las propiedades que se crearán según el tipo de enlace de despliegue seleccionado en WebSphere Studio Application Developer Integration Edition:

Migrar los enlaces de EJB y de proceso EJB

Se puede migrar los enlaces de EJB y de proceso EJB a la construcción de SCA recomendada.

Por qué y cuándo se efectúa esta tarea

En WebSphere Studio Application Developer Integration Edition, este tipo de enlace permitía a los clientes comunicarse con un proceso BPEL u otro tipo de servicio invocando un EJB. Tenga presente que este tipo de enlace no era opcional para los microprocesos; siempre se seleccionaba ya que los demás tipos de enlace utilizaban internamente el EJB generado.

El nombre JNDI del EJB generado se generaba automáticamente como una combinación del nombre, el espacio de nombres destino y la indicación de la hora de inicio de validez del proceso BPEL. Por ejemplo, estos atributos se pueden encontrar examinando las propiedades del proceso BPEL en las pestañas de contenido Descripción y Servidor del editor BPEL:

Tabla 4. Espacio de nombres generado
Nombre de proceso MyService
Espacio de nombres destino http://www.example.com/process87787141/
Válido desde Ene 01 2003 02:03:04

El espacio de nombres generado en este ejemplo es com/example/www/process87787141/MyService20030101T020304.

En WebSphere Studio Application Developer Integration Edition, al seleccionar el enlace de EJB como tipo de despliegue, no se proporcionaba ninguna opción.

Existen cuatro opciones para migrar el enlace de proceso de WebSphere Studio Application Developer Integration Edition. El tipo de cliente que accede al servicio determina cuáles de las opciones de migración siguientes se llevan a cabo:

Nota: Una vez efectuados los pasos manuales de migración, el cliente también debe migrarse al nuevo modelo de programación. Consulte el tema pertinente para los tipos de cliente siguientes:

Tabla 5. Información adicional sobre la migración de clientes
Tipo de cliente Fuente de información adicional
Cliente EJB que invoca el bean de sesión generado. Este tipo de cliente invoca un método EJB correspondiente a la operación BPEL que se va a invocar. "Migrar el cliente EJB"
Cliente WSIF que utiliza el enlace de proceso de EJB "Migrar el cliente de enlace de proceso EJB"
API de EJB del coreógrafo de procesos comerciales genérica "Migrar el cliente de la API de EJB del coreógrafo de procesos de negocio genérica"
API de mensajería del coreógrafo de procesos comerciales genérica "Migrar el cliente de la API de mensajería del coreógrafo de procesos de negocio genérica"
Otro proceso BPEL del mismo módulo No disponible: conectar entre sí los componentes BPEL mediante el editor de ensamblajes
Otro proceso BPEL de otro módulo No disponible: crear una importación con enlace de SCA en el módulo de referencia y configurar su enlace de modo que apunte a la exportación con enlace de SCA que cree a continuación en la opción 1

Opción 1 de migración para EJB y el enlace de procesos EJB

La primera opción de migración del enlace de proceso de EJB de WebSphere Studio Application Developer Integration Edition permite a otro componente del mismo módulo acceder a los procesos comerciales.

Por qué y cuándo se efectúa esta tarea

En el editor de ensamblado, siga estos pasos para conectar este otro componente con el componente BPEL:

  1. Seleccione el elemento Conexión en la barra de herramientas.
  2. Pulse el otro componente para seleccionarlo como origen de la conexión.
  3. Pulse el componente BPEL SCA para seleccionarlo como destino de la conexión.
  4. Guarde el diagrama de ensamblaje.
Opción 2 de migración para EJB y el enlace de procesos EJB

La segunda opción de migración del enlace de proceso de EJB de WebSphere Studio Application Developer Integration Edition permite a otros clientes y módulos SCA acceder a los procesos comerciales.

Por qué y cuándo se efectúa esta tarea

Nota: Estos pasos son obligatorios si se utilizarán las API del coreógrafo de procesos de negocio genéricas para invocar el proceso de negocio.

La exportación con enlace de SCA hace que otros módulos SCA puedan acceder a un componente SCA. Para crear una exportación con un enlace de SCA, siga estos pasos:

  1. Abra el editor de ensamblajes para el módulo creado por el asistente de migración.
  2. Cree una exportación con enlace de SCA para cada interfaz de proceso BPEL para la que se haya generado un enlace de EJB en WebSphere Studio Application Developer Integration Edition:
    1. Pulse con el botón derecho en el componente BPEL del editor de ensamblajes.
    2. Seleccione Exportar....
    3. Seleccione Enlace de SCA.
    4. Si hay varias interfaces para el proceso, seleccione la que le permita exportar con este tipo de enlace.
    5. Una vez creada la exportación de SCA, seleccione la exportación en el editor de ensamblajes y en la vista de propiedades seleccione el panel de contenido Descripción. Se muestran el nombre y la descripción de la exportación, que pueden modificarse según convenga.
    6. Guarde el diagrama de ensamblaje.
Opción 3 de migración para EJB y el enlace de procesos EJB

La tercera opción de migración del enlace de proceso de EJB de WebSphere Studio Application Developer Integration Edition permite a una entidad no SCA (por ejemplo, un JSP o un cliente Java) acceder a los módulos.

Por qué y cuándo se efectúa esta tarea

La referencia autónoma hace que un cliente externo pueda acceder a un componente SCA. Para crear una referencia autónoma, siga estos pasos:

  1. Abra el editor de ensamblajes para el módulo creado por el asistente de migración.
  2. Cree una referencia autónoma para cada interfaz de proceso BPEL para la que se haya generado un enlace de EJB en WebSphere Studio Application Developer Integration Edition:
    1. Seleccione el elemento Referencias autónomas en la barra de herramientas.
    2. Pulse el lienzo del editor de ensamblajes para crear una entidad SCA de referencias autónomas.
    3. Seleccione el elemento Conexión en la barra de herramientas.
    4. Pulse la entidad Referencias autónomas para seleccionarla como origen de la conexión.
    5. Pulse el componente BPEL SCA para seleccionarlo como destino de la conexión.
    6. Verá una alerta Se creará una referencia coincidente en el nodo de origen. ¿Desea continuar?; pulse Aceptar.
    7. Seleccione la entidad Referencias autónomas que acaba de crear y seleccione el panel de contenido Descripción en la vista Propiedades.
    8. Expanda el enlace Referencias y seleccione la referencia que acaba de crear. Se muestran el nombre y la descripción de la exportación, que pueden modificarse según convenga.
    9. Si hay varias interfaces para el proceso, seleccione la que le permita exportar con este tipo de enlace.
    10. Guarde el diagrama de ensamblaje.
Opción 4 de migración para EJB y el enlace de procesos EJB

La cuarta opción de migración del enlace de proceso de EJB de WebSphere Studio Application Developer Integration Edition permite a un cliente de servicios Web acceder a los procesos comerciales.

Por qué y cuándo se efectúa esta tarea

La exportación con enlace de servicio Web hace que un cliente de servicios Web externo pueda acceder a un componente SCA. Para crear una exportación con un enlace de Servicio Web, siga estos pasos:

  1. Abra el editor de ensamblado para el módulo creado por el asistente de migración.
  2. Cree una exportación con enlace de SCA para cada interfaz de proceso BPEL para la que se haya generado un enlace de EJB en WebSphere Studio Application Developer Integration Edition:
    1. Pulse con el botón derecho en el componente BPEL del editor de ensamblajes.
    2. Seleccione Exportar... .
    3. Seleccione Enlace de servicio Web.
    4. Si hay varias interfaces para el proceso, seleccione la que le permita exportar con este tipo de enlace.
    5. Seleccione el transporte: soap/http o soap/jms.
    6. Una vez creada la exportación de servicios Web, seleccione la exportación en el editor de ensamblajes y en la vista de propiedades seleccione el panel de contenido Descripción. Se muestran el nombre y la descripción de la exportación, que pueden modificarse según convenga.
    7. Guarde el diagrama de ensamblaje.

Migrar los enlaces de JMS y de proceso JMS

Se puede migrar los enlaces de JMS y de proceso JMS a la construcción de SCA recomendada.

Por qué y cuándo se efectúa esta tarea

En WebSphere Studio Application Developer Integration Edition, este tipo de enlace permitía a los clientes comunicarse con un proceso BPEL u otro tipo de servicio enviando un mensaje a un MDB. Tenga presente que este tipo de enlace no era opcional para los procesos de larga ejecución y siempre se seleccionaba. En realidad, este tipo de enlace era el único permitido para las interfaces de petición-respuesta de los procesos de larga ejecución. Para los otros tipos de servicio, se generaría un MDB que invocaría el servicio adecuado.

El nombre JNDI empleado por el enlace de JMS era una combinación del nombre, el espacio de nombres destino y la indicación de la hora de inicio de validez del proceso BPEL.

En WebSphere Studio Application Developer Integration Edition, al seleccionar el enlace de JMS como tipo de despliegue para un proceso BPEL, se proporcionaban las opciones siguientes:

Existen cinco opciones para migrar el enlace de proceso de JMS de WebSphere Studio Application Developer Integration Edition. El tipo de cliente que accede al servicio determina cuáles de las opciones de migración siguientes se llevan a cabo:

Nota: Una vez efectuados los pasos manuales de migración, el cliente también debe migrarse al nuevo modelo de programación. Consulte el tema pertinente para los tipos de cliente siguientes:

Tabla 6. Información adicional sobre la migración de clientes
Tipo de cliente Fuente de información adicional
Cliente WSIF que utiliza el enlace de proceso de JMS "Migrar el cliente de la API de mensajería del coreógrafo de procesos de negocio genérica y el cliente de enlace de proceso JMS"
API de EJB del coreógrafo de procesos comerciales genérica "Migrar el cliente de la API de EJB del coreógrafo de procesos de negocio genérica"
API de mensajería del coreógrafo de procesos comerciales genérica Migrar el negocio "Migrar el cliente de la API de mensajería del coreógrafo de procesos de negocio genérica"
Otro proceso BPEL del mismo módulo No disponible: conectar entre sí los componentes BPEL mediante el editor de ensamblajes
Otro proceso BPEL de otro módulo No disponible: crear una importación con enlace de SCA en el módulo de referencia y configurar su enlace de modo que apunte a la exportación con enlace de SCA que cree a continuación en la opción 1.

Opción 1 de migración para JMS y el enlace de procesos JMS

La primera opción de migración del enlace de proceso de JMS de WebSphere Studio Application Developer Integration Edition permite a otro componente del mismo módulo acceder a los procesos de negocio.

Por qué y cuándo se efectúa esta tarea

En el editor de ensamblado, siga estos pasos para conectar este otro componente con el componente BPEL:

  1. Seleccione el elemento Conexión en la barra de herramientas.
  2. Pulse el otro componente para seleccionarlo como origen de la conexión.
  3. Pulse el componente BPEL SCA para seleccionarlo como destino de la conexión.
  4. Guarde el diagrama de ensamblaje.
Opción 2 de migración para JMS y el enlace de procesos JMS

La segunda opción de migración del enlace de proceso de JMS de WebSphere Studio Application Developer Integration Edition permite a otros clientes y módulos SCA acceder a los procesos comerciales.

Por qué y cuándo se efectúa esta tarea

La exportación con enlace de SCA hace que otros módulos SCA puedan acceder a un componente SCA. Para crear una exportación con un enlace de SCA, siga estos pasos:

  1. Abra el editor de ensamblajes para el módulo creado por el asistente de migración.
  2. Cree una exportación con enlace de SCA para cada interfaz de proceso BPEL para la que se haya generado un enlace de JMS en WebSphere Studio Application Developer Integration Edition:
    1. Pulse con el botón derecho en el componente BPEL del editor de ensamblajes.
    2. Seleccione Exportar....
    3. Seleccione Enlace de SCA.
    4. Si hay varias interfaces para el proceso, seleccione la que le permita exportar con este tipo de enlace.
    5. Una vez creada la exportación de SCA, seleccione la exportación en el editor de ensamblajes y en la vista de propiedades seleccione el panel de contenido Descripción. Se muestran el nombre y la descripción de la exportación, que pueden modificarse según convenga.
    6. Guarde el diagrama de ensamblaje.
Opción 3 de migración para JMS y el enlace de procesos JMS

La tercera opción de migración del enlace de proceso de JMS de WebSphere Studio Application Developer Integration Edition permite a una entidad no SCA (por ejemplo, un JSP o un cliente Java) acceder a los procesos de negocio.

Por qué y cuándo se efectúa esta tarea

La referencia autónoma hace que un cliente externo pueda acceder a un componente SCA. Para crear una referencia autónoma, siga estos pasos:

  1. Abra el editor de ensamblajes para el módulo creado por el asistente de migración.
  2. Cree una referencia autónoma para cada interfaz de proceso BPEL para la que se haya generado un enlace de JMS en WebSphere Studio Application Developer Integration Edition:
    1. Seleccione el elemento Referencias autónomas en la barra de herramientas.
    2. Pulse el lienzo del editor de ensamblajes para crear una entidad SCA de referencias autónomas.
    3. Seleccione el elemento Conexión en la barra de herramientas.
    4. Pulse la entidad Referencias autónomas para seleccionarla como origen de la conexión.
    5. Pulse el componente BPEL SCA para seleccionarlo como destino de la conexión.
    6. Verá una alerta Se creará una referencia coincidente en el nodo de origen. ¿Desea continuar?; pulse Aceptar.
    7. Seleccione la entidad Referencias autónomas que acaba de crear y seleccione el panel de contenido Descripción en la vista Propiedades.
    8. Expanda el enlace Referencias y seleccione la referencia que acaba de crear. Se muestran el nombre y la descripción de la exportación, que pueden modificarse según convenga.
    9. Si hay varias interfaces para el proceso, seleccione la que le permita exportar con este tipo de enlace.
    10. Guarde el diagrama de ensamblaje.
Opción 4 de migración para JMS y el enlace de procesos JMS

La cuarta opción de migración del enlace de proceso de JMS de WebSphere Studio Application Developer Integration Edition permite a un cliente de servicios Web acceder a los procesos de negocio.

Por qué y cuándo se efectúa esta tarea

La exportación con enlace de servicio Web hace que un cliente de servicios Web externo pueda acceder a un componente SCA. Para crear una exportación con un enlace de Servicio Web, siga estos pasos:

  1. Abra el editor de ensamblajes para el módulo creado por el asistente de migración.
  2. Cree una exportación con enlace de SCA para cada interfaz de proceso BPEL para la que se haya generado un enlace de JMS en WebSphere Studio Application Developer Integration Edition:
    1. Pulse con el botón derecho en el componente BPEL del editor de ensamblajes.
    2. Seleccione Exportar... .
    3. Seleccione Enlace de servicio Web.
    4. Si hay varias interfaces para el proceso, seleccione la que le permita exportar con este tipo de enlace.
    5. Seleccione el transporte: soap/http o soap/jms.
    6. Una vez creada la exportación de servicios Web, seleccione la exportación en el editor de ensamblajes y en la vista de propiedades seleccione el panel de contenido Descripción. Se muestran el nombre y la descripción de la exportación, que pueden modificarse según convenga.
    7. Guarde el diagrama de ensamblaje.
Opción 5 de migración para JMS y el enlace de procesos JMS

La quinta opción de migración del enlace de proceso de JMS de WebSphere Studio Application Developer Integration Edition permite a un cliente JMS acceder a los procesos de negocio.

Por qué y cuándo se efectúa esta tarea

La exportación con enlace de JMS hace que un cliente JMS externo pueda acceder a un componente SCA. Para crear una exportación con un enlace de JMS, siga estos pasos:

  1. Para servicios BPEL, deberá crear y referenciar nuevos recursos de colas, ya que el enlace de procesos 5.1 JMS era bastante diferente del enlace 5.1 JMS estándar. Para servicios no BPEL, puede encontrar los valores que ha seleccionado para el código de despliegue JMS en WebSphere Studio Application Developer Integration Edition 5.1 buscando el archivo WSDL denominado JMSBinding.wsdl y JMSService.wsdl en el paquete adecuado bajo de la carpeta ejbModule/META-INF del proyecto EJB generado e inspeccionando la información de enlace y servicio capturada allí. Desde el enlace, puede determinar se se han utilizado mensajes de texto u objeto y si se han utilizado enlaces de formato de datos de cliente . Si existen, debe considerar la posibilidad de escribir también un enlace de datos personalizado para la opción Exportar con enlace JMS de 6.x. Desde el servicio, puede buscar la fábrica de contexto inicial, el nombre de conexión JNDI, el nombre de destino JNDI y el estilo de destino (cola).
  2. Abra el editor de ensamblado para el módulo creado por el asistente de migración.
  3. Cree una exportación con enlace de JMS para cada interfaz de proceso BPEL para la que se haya generado un enlace de JMS en WebSphere Studio Application Developer Integration Edition pulsando con el botón derecho del ratón en el componente BPEL del editor de ensamblajes.
  4. Seleccione Exportar... .
  5. Seleccione Enlace de JMS.
  6. Si hay varias interfaces para el proceso, seleccione la que le permita exportar con este tipo de enlace.
  7. En el siguiente panel (atributos de enlace de exportación de JMS), seleccione Dominio de mensajería JMS. Defina este atributo como Punto a punto.
  8. Seleccione Cómo se serializan los datos entre Objeto comercial y Mensaje JMS y especifique los siguientes valores (es aconsejable seleccionar Texto en lugar de Objeto, ya que el texto, que generalmente es XML, es independiente del entorno de ejecución y permite la integración de servicios entre sistemas independientes):
    1. En Texto, seleccione Utilizar clase de selector de función JMS predeterminada o indique el nombre totalmente calificado de la clase de implementación FunctionSelector.
    2. En Objeto, seleccione Utilizar clase de selector de función JMS predeterminada o indique el nombre totalmente calificado de la clase de implementación FunctionSelector.
    3. En Proporcionado por el usuario, indique el nombre totalmente calificado de la clase de implementación JMSDataBinding. Deberá seleccionar Proporcionado por usuario si la aplicación necesita acceso a propiedades de cabecera JMS que aún no están disponibles en el enlace de importación JMS. En este caso, a continuación deberá crear una clase de enlace de datos de cliente que amplíe el enlace de datos JMS estándar com.ibm.websphere.sca.jms.data.JMSDataBinding y añadir código personalizado para acceder a JMSMessage directamente. A continuación, suministrará el nombre de la clase personalizada para este campo. Consulte los ejemplos de JMS de la sección "Crear y modificar enlaces para componentes de importación y exportación" cuyo enlace figura más abajo.
    4. En Proporcionado por el usuario, seleccione Utilizar clase de selector de función JMS predeterminada o indique el nombre totalmente calificado de la clase de implementación FunctionSelector.
  9. Una vez creada la exportación con enlace de JMS, seleccione la exportación en el editor de ensamblajes y en la vista de propiedades seleccione el panel de contenido Descripción. Se muestran el nombre y la descripción de la exportación, que pueden modificarse según convenga.
  10. Seleccione el panel de contenido Enlace para ver muchas más opciones.
  11. Guarde el diagrama de ensamblaje.

Migrar el enlace de servicios Web de IBM (SOAP/JMS)

Se puede migrar el enlace de servicios Web (SOAP/JMS) de IBM para procesos BPEL u otro tipo de servicio a la construcción SCA recomendada.

Por qué y cuándo se efectúa esta tarea

En WebSphere Studio Application Developer Integration Edition, este tipo de enlace permitía a los clientes comunicarse con un proceso BPEL invocando un servicio Web de IBM, en que el protocolo de comunicación era JMS y el mensaje seguía las reglas de codificación de SOAP.

El ejemplo siguiente muestra los convenios utilizados al generar un servicio web IBM (SOAP/JMS) para un servicio BPEL 5.1. El nombre JNDI del servicio Web de IBM generado era una combinación del nombre, el espacio de nombres destino y la indicación de la hora de inicio de validez del proceso BPEL, así como el nombre de la interfaz (tipo de puerto WSDL para el que se generó el código de despliegue). Por ejemplo, estos atributos se pueden encontrar examinando las propiedades del proceso BPEL en las pestañas de contenido Descripción y Servidor del editor BPEL:

Tabla 7. Espacio de nombres generado
Nombre de proceso MyService
Espacio de nombres destino http://www.example.com/process87787141/
Válido desde Ene 01 2003 02:03:04
Interfaz ProcessPortType

El espacio de nombres generado en este ejemplo será pues com/example/www/process87787141/MyService20030101T020304_ProcessPortTypePT.

En WebSphere Studio Application Developer Integration Edition, al seleccionar el enlace de servicios Web de IBM (SOAP/JMS) como tipo de despliegue para un proceso BPEL u otro tipo de servicio, se proporcionaban las opciones siguientes:

En el proyecto EJB generado, pero no en el propio proyecto de servicio, se crea un archivo WSDL con la especificación del enlace SOAP/JMS de servicios Web de IBM. Esto significa que es preciso localizar manualmente este archivo y copiarlo en el proyecto de módulo de integración de negocio si es importante que el código de cliente de servicios Web de IBM no cambie. Por omisión, este archivo WSDL se creaba en el proyecto EJB en ejbModule/META-INF/wsdl/<nombre proceso comercial>_<nombre de tipo de puerto de interfaz de proceso comercial>_JMS.wsdl

El tipo de puerto WSDL y los mensajes de la interfaz de proceso comercial se copian también en este archivo WSDL en lugar de hacer referencia al tipo de puerto WSDL y los mensajes definidos en el proyecto de servicio.

Si es importante que el código de cliente de servicios Web de IBM no se haya modificado tras la migración, la información de este archivo será necesaria para llevar a cabo los pasos manuales de migración.

Existen dos opciones para migrar el enlace de proceso de SOAP/JMS de WebSphere Studio Application Developer Integration Edition. Deberá elegirse entre migrar el cliente al modelo de programación de SCA o dejarlo como cliente de servicios Web:

Nota: Una vez efectuados los pasos manuales de migración, el cliente también debe migrarse al nuevo modelo de programación. Consulte el tema pertinente para los tipos de cliente siguientes:

Tabla 8. Información adicional sobre la migración de clientes
Tipo de cliente Fuente de información adicional
Cliente de servicios Web de IBM "Migrar el cliente de servicios Web de IBM (SOAP/JMS)"

Opción de migración 1 para el enlace de servicios Web (SOAP/JMS) de IBM

La primera opción de migración del enlace de proceso de SOAP/JMS de WebSphere Studio Application Developer Integration Edition permite a un cliente de servicios Web acceder al servicio.

Por qué y cuándo se efectúa esta tarea

La exportación con enlace de servicio Web hace que un cliente de servicios Web externo pueda acceder a un componente SCA. Para crear una exportación con un enlace de Servicio Web, siga estos pasos:

  1. Abra el editor de ensamblajes para el módulo creado por el asistente de migración.
  2. Cree una Exportación con enlace SCA para cada interfaz de servicio para la que se haya generado un enlace de servicio Web de IBM (SOAP/JMS) en WebSphere Studio Application Developer Integration Edition:
    1. Pulse con el botón derecho en el componente SCA del editor de ensamblajes.
    2. Seleccione Exportar....
    3. Seleccione Enlace de servicio Web.
    4. Si hay varias interfaces para el componente, seleccione la que le permita exportar con este tipo de enlace.
    5. Seleccione el transporte soap/jms.
  3. Una vez creada la exportación de servicios Web, seleccione la exportación en el editor de ensamblajes y en la vista de propiedades seleccione el panel de contenido Descripción. Se muestran el nombre y la descripción de la exportación, que pueden modificarse según convenga.
  4. Guarde el diagrama de ensamblaje.
  5. Seleccione el panel de contenido de enlace y verá que se ha generado directamente en la carpeta de proyecto del módulo un enlace y un servicio WSDL de servicio Web de IBM. Se denominará componente exportado Export nombre de tipo de puerto WSDL Jms_Service.wsdl. Si examina ese archivo encontrará que se utiliza de manera predeterminada el enlace con envoltura de documento/literal, ya que es el estilo preferido en 6.x. Es el WSDL que los clientes de servicios Web de IBM utilizarán para invocar el servicio.
  6. Siga estos pasos para generar un enlace de servicio web y un servicio nuevos si necesita preservar el código del cliente:
    1. Copie el archivo WSDL 5.1 del proyecto EJB generado en 5.1 situado en ejbModule/META-INF/wsdl/nombre de proceso comercial/nombre de tipo de puerto de interfaz de proceso comercialJMS.wsdl en el proyecto de módulo de integración de negocio.
    2. Después de copiar sobre el archivo y de volver a construir el módulo puede que visualice mensajes de error, ya que los tipos de esquema XML, los mensajes WSDL y los tipos de puerto WSDL utilizados por el servicio Web están duplicados en el archivo WSDL del servicio Web de IBM en 5.1. Para arreglar esto, suprima las definiciones duplicadas del enlace de servicio Web de IBM/WSDL de servicio y en su lugar añada una importación WSDL para el WSDL de interfaz real. Nota: es importante tener en cuenta que cuando WebSphere Studio Application Developer Integration Edition generó el código de despliegue de servicio Web de IBM modificó las definiciones de esquema en algunos casos. Esto puede originar incoherencias para los clientes existentes que utilizan el WSDL de servicio Web de IBM. Por ejemplo, el atributo del esquema "elementFormDefault" se estableció en "qualified" en el esquema incorporado generado en el WSDL de servicio Web de IBM incluso aunque la definición de esquema original no estuviera calificada. Esto generaría el error siguiente en tiempo de ejecución: WSWS3047E: Error: no se puede deserializar el elemento.
    3. Pulse con el botón derecho sobre el archivo WSDL que acaba de copiar en el módulo de integración de negocio, seleccione Abrir con y después Editor WSDL.
    4. Vaya a la pestaña Origen. Suprima todos los mensajes y tipos de puerto WSDL definidos en este archivo.
    5. Ahora verá el error: El tipo de puerto '<tipo_de_puerto>' especificado para el enlace '<enlace>' no está definido. Para arreglar esto, en el Editor WSDL de la pestaña Gráfico, pulse con el botón derecho en la sección Importaciones y seleccione Añadir importación.
    6. En la vista de propiedades de la pestaña General, pulse el botón ... situado a la derecha del campo Ubicación. Busque la interfaz WSDL en la que están ubicados el mensaje WSDL y las definiciones de tipo de puerto y pulse Aceptar para importar el WSDL de interfaz en el WSDL de servicio/enlace.
    7. Guarde el archivo WSDL.
    8. Renueve/reconstruya el proyecto. Pase a la perspectiva Integración de negocio. Abra el Diagrama de ensamblaje del módulo en el Editor de ensamblaje.
    9. En la vista del explorador de proyectos, expanda el módulo que está migrando y expanda la categoría lógica Puertos de servicio Web. Debe ver el puerto que existe en el WSDL de enlace/servicio listado. Arrástrelo y suéltelo en el Editor de ensamblaje.
    10. Elija crear una Exportación con enlace de servicio Web y seleccione el nombre de puerto adecuado. Esto creará la Exportación que utiliza el enlace/servicio antiguo de forma que los clientes de servicios Web existentes no tienen que cambiar. Si selecciona la exportación que acaba de crear en el Editor de ensamblaje y va a la vista propiedades, en la pestaña Enlace debe ver que los nombres de servicio y el puerto 5.1 están cumplimentados.
    11. Guarde todos los cambios.
    12. Justo después de desplegar la aplicación puede cambiar la configuración del proyecto Web generado para que coincida con la dirección de servicio 5.1 (deberá hacer estos cambios cada vez que haga cambios en el módulo SCA que impliquen la regeneración de este archivo.) Si mira en la definición Servicio de WSDL de servicio Web de IBM que está reutilizando de 5.1, verá la dirección de servicio en la que el cliente 5.1 está codificado:<wsdlsoap:address location="http://localhost:9080/MyServiceWeb/services/MyServicePort"/>
    13. Para que los artefactos de proyecto Web generados en 6.x coincidan con esta dirección de servicio antigua, debe modificar el descriptor de despliegue del proyecto Web generado. Abra el descriptor de despliegue en WebSphere Integration Developer y, en la pestaña Servlets, añada una Correlación URL adicional que sea muy parecida a la correlación URL existente para esa exportación, con el mismo nombre de servlet pero con un patrón de URL distinto.
    14. Además, si necesita modificar la raíz de contexto de este proyecto Web para que coincida con la raíz de contexto en la dirección de servicio original (en este ejemplo la raíz de contexto es "MyServiceWeb"), puede abrir el descriptor de despliegue para la Aplicación de empresa J2EE Enterprise en la que está este proyecto Web y cambiar la raíz de contexto de ese módulo Web para que coincida con la raíz de contexto de la antigua dirección de servicio. Puede aparecer el error siguiente que puede pasar por alto: CHKJ3017E: el proyecto Web <NOM PROY WEB> está correlacionado con una raíz de contexto no válida <RAÍZ CONTEXTO NUEVO> en el proyecto EAR <NOMBRE APL>.
Opción de migración 2 para el enlace de servicios Web (SOAP/JMS) de IBM

La segunda opción de migración del enlace de proceso de SOAP/JMS de WebSphere Studio Application Developer Integration Edition permite a una entidad no SCA (por ejemplo, un JSP o un cliente Java) acceder a los procesos de negocio.

Por qué y cuándo se efectúa esta tarea

La referencia autónoma hace que un cliente externo pueda acceder a un componente SCA. Para crear una referencia autónoma, siga estos pasos:

  1. Abra el editor de ensamblajes para el módulo creado por el asistente de migración.
  2. Cree una referencia autónoma para cada interfaz de proceso BPEL para la que se haya generado un enlace de servicio Web de IBM (SOAP/JMS) en WebSphere Studio Application Developer Integration Edition:
    1. Seleccione el elemento Referencias autónomas en la barra de herramientas.
    2. Pulse el lienzo del editor de ensamblajes para crear una entidad SCA de referencias autónomas.
    3. Seleccione el elemento Conexión en la barra de herramientas.
    4. Pulse la entidad Referencias autónomas para seleccionarla como origen de la conexión.
    5. Pulse el componente BPEL SCA para seleccionarlo como destino de la conexión.
    6. Verá una alerta Se creará una referencia coincidente en el nodo de origen. ¿Desea continuar?; pulse Aceptar.
    7. Seleccione la entidad Referencias autónomas que acaba de crear y seleccione el panel de contenido Descripción en la vista Propiedades.
    8. Expanda el enlace Referencias y seleccione la referencia que acaba de crear. Se muestran el nombre y la descripción de la exportación, que pueden modificarse según convenga.
    9. Si hay varias interfaces para el proceso, seleccione la que le permita exportar con este tipo de enlace.
    10. Guarde el diagrama de ensamblaje.

Migrar el enlace de servicios Web de IBM (SOAP/HTTP)

Se puede migrar el enlace de servicios Web (SOAP/HTTP) de IBM para procesos BPEL u otro tipo de servicio a la construcción SCA recomendada.

Por qué y cuándo se efectúa esta tarea

En WebSphere Studio Application Developer Integration Edition, este tipo de enlace permitía a los clientes comunicarse con un proceso BPEL invocando un servicio Web de IBM, en que el protocolo de comunicación era HTTP y el mensaje seguía las reglas de codificación de SOAP.

El ejemplo siguiente muestra los convenios utilizados al generar un servicio web IBM (SOAP/HTTP) para un servicio BPEL 5.1. El nombre JNDI del servicio Web de IBM generado era una combinación del nombre, el espacio de nombres destino y la indicación de la hora de inicio de validez del proceso BPEL, así como el nombre de la interfaz (tipo de puerto WSDL para el que se generó el código de despliegue). Por ejemplo, estos atributos se pueden encontrar examinando las propiedades del proceso BPEL en las pestañas de contenido Descripción y Servidor del editor BPEL:

Tabla 9. Espacio de nombres generado
Nombre de proceso MyService
Espacio de nombres destino http://www.example.com/process87787141/
Válido desde Ene 01 2003 02:03:04
Interfaz ProcessPortType

El espacio de nombres generado en este ejemplo será pues com/example/www/process87787141/MyService20030101T020304_ProcessPortTypePT.

En WebSphere Studio Application Developer Integration Edition, al seleccionar el enlace de servicios Web de IBM (SOAP/HTTP) como tipo de despliegue para un proceso BPEL u otro tipo de servicio, se proporcionaban las opciones siguientes:

En los proyectos Web y EJB generados, pero no en el propio proyecto de servicio, se crea un archivo WSDL con la especificación del enlace y el servicio SOAP/HTTP de servicios Web de IBM. Esto significa que es preciso localizar manualmente este archivo y copiarlo en el proyecto de módulo de integración de negocio si es importante que el código de cliente de servicios Web de IBM no cambie. Por omisión, este archivo WSDL se creaba en el proyecto Web en WebContent/WEB-INF/wsdl/<nombre proceso comercial>_<nombre de tipo de puerto de interfaz de proceso comercial>_HTTP.wsdl

El tipo de puerto WSDL y los mensajes de la interfaz de proceso comercial se copian también en este archivo WSDL en lugar de hacer referencia al tipo de puerto WSDL y los mensajes definidos en el proyecto de servicio.

Si es importante que el código de cliente de servicios Web de IBM no se haya modificado tras la migración, la información de este archivo será necesaria para llevar a cabo los pasos manuales de migración.

Existen dos opciones para migrar el enlace de proceso de SOAP/HTTP de WebSphere Studio Application Developer Integration Edition. Deberá elegirse entre migrar el cliente al modelo de programación de SCA o dejarlo como cliente de servicios Web:

Nota: Una vez efectuados los pasos manuales de migración, el cliente también debe migrarse al nuevo modelo de programación. Consulte el tema pertinente para los tipos de cliente siguientes:

Tabla 10. Información adicional sobre la migración de clientes
Tipo de cliente Fuente de información adicional
Cliente de servicios Web de IBM "Migrar el cliente de servicios Web de IBM (SOAP/HTTP)"

Opción de migración 1 para el enlace de servicios Web (SOAP/HTTP) de IBM

La primera opción de migración del enlace de proceso de SOAP/HTTP de WebSphere Studio Application Developer Integration Edition permite a un cliente de servicios Web acceder a los procesos de negocio.

Por qué y cuándo se efectúa esta tarea

La exportación con enlace de servicio Web hace que un cliente de servicios Web externo pueda acceder a un componente SCA. Para crear una exportación con un enlace de Servicio Web, siga estos pasos:

  1. Abra el editor de ensamblajes para el módulo creado por el asistente de migración.
  2. Cree una exportación con enlace de SCA para cada interfaz de proceso BPEL para la que se haya generado un enlace de servicio Web de IBM (SOAP/HTTP) en WebSphere Studio Application Developer Integration Edition pulsando con el botón derecho del ratón en el componente BPEL del editor de ensamblajes.
  3. Seleccione Exportar....
  4. Seleccione Enlace de servicio Web.
  5. Si hay varias interfaces para el componente, seleccione la que le permita exportar con este tipo de enlace.
  6. Seleccione el transporte soap/http.
  7. Una vez creada la exportación de servicios Web, seleccione la exportación en el editor de ensamblajes y en la vista de propiedades seleccione el panel de contenido Descripción. Se muestran el nombre y la descripción de la exportación, que pueden modificarse según convenga.
  8. Guarde el diagrama de ensamblaje.
  9. Siga estos pasos para generar un enlace de servicio Web y un servicio nuevos si necesita preservar el código del cliente:
    1. Copie el archivo WSDL 5.1 del proyecto EJB generado en 5.1 situado en ejbModule/META-INF/wsdl/nombre de proceso comercial/nombre de tipo de puerto de interfaz de proceso comercial_HTTP.wsdl en el proyecto de módulo de integración de negocio.
    2. Después de copiar sobre el archivo y de volver a construir el módulo puede que visualice mensajes de error, ya que los tipos de esquema XML, los mensajes WSDL y los tipos de puerto WSDL utilizados por el servicio Web están duplicados en el archivo WSDL del servicio Web de IBM en 5.1. Para arreglar esto, suprima las definiciones duplicadas del enlace de servicio Web de IBM/WSDL de servicio y en su lugar añada una importación WSDL para el WSDL de interfaz real. Nota: es importante tener en cuenta que cuando WebSphere Studio Application Developer Integration Edition generó el código de despliegue de servicio Web de IBM modificó las definiciones de esquema en algunos casos. Esto puede originar incoherencias para los clientes existentes que utilizan el WSDL de servicio Web de IBM. Por ejemplo, el atributo del esquema "elementFormDefault" se estableció en "qualified" en el esquema incorporado generado en el WSDL de servicio Web de IBM incluso aunque la definición de esquema original no estuviera calificada. Esto generaría el error siguiente en tiempo de ejecución: WSWS3047E: Error: no se puede deserializar el elemento.
    3. Pulse con el botón derecho sobre el archivo WSDL que acaba de copiar en el módulo de integración de negocio, seleccione Abrir con y después Editor WSDL.
    4. Vaya a la pestaña Origen. Suprima todos los mensajes y tipos de puerto WSDL definidos en este archivo.
    5. Ahora verá el error: El tipo de puerto '<tipo_de_puerto>' especificado para el enlace '<enlace>' no está definido. Para solucionar esto, en el Editor WSDL de la pestaña Gráfico, pulse con el botón derecho en la sección Importaciones y seleccione Añadir importación.
    6. En la vista de propiedades de la pestaña General, pulse el botón ... situado a la derecha del campo Ubicación. Busque la interfaz WSDL en la que están ubicados el mensaje WSDL y las definiciones de tipo de puerto y pulse Aceptar para importar el WSDL de interfaz en el WSDL de servicio/enlace.
    7. Guarde el archivo WSDL.
    8. Renueve/reconstruya el proyecto. Pase a la perspectiva Integración de negocio. Abra el Diagrama de ensamblaje del módulo en el Editor de ensamblaje.
    9. En la vista del explorador de proyectos, expanda el módulo que está migrando y expanda la categoría lógica Puertos de servicio Web. Debe ver el puerto que existe en el WSDL de enlace/servicio listado. Arrástrelo y suéltelo en el Editor de ensamblaje.
    10. Elija crear una Exportación con enlace de servicio Web y seleccione el nombre de puerto adecuado. Esto creará la Exportación que utiliza el enlace/servicio antiguo de forma que los clientes de servicios Web existentes no tienen que cambiar. Si selecciona la exportación que acaba de crear en el Editor de ensamblaje y va a la vista propiedades, en la pestaña Enlace debe ver que los nombres de servicio y el puerto 5.1 están cumplimentados.
    11. Guarde todos los cambios.
    12. Justo después de desplegar la aplicación puede cambiar la configuración del proyecto Web generado para que coincida con la dirección de servicio 5.1 (deberá hacer estos cambios cada vez que haga cambios en el módulo SCA que impliquen la regeneración de este archivo.) Si observa la definición de servicio de WSDL de servicio Web de IBM que está reutilizando de 5.1, verá la dirección de servicio en la que el cliente 5.1 está codificado: <wsdlsoap:address location="http://localhost:9080/MyServiceWeb/services/MyServicePort"/>
    13. Para que los artefactos de proyecto Web generados en 6.x coincidan con esta dirección de servicio antigua, debe modificar el descriptor de despliegue del proyecto Web generado. Abra el descriptor de despliegue en WebSphere Integration Developer y, en la pestaña Servlets, añada una Correlación URL adicional que sea muy parecida a la correlación URL existente para esa exportación, con el mismo nombre de servlet pero con un patrón de URL distinto.
    14. Además, si necesita modificar la raíz de contexto de este proyecto Web para que coincida con la raíz de contexto en la dirección de servicio original (en este ejemplo la raíz de contexto es "MyServiceWeb"), puede abrir el descriptor de despliegue para la Aplicación de empresa J2EE Enterprise en la que está este proyecto Web y cambiar la raíz de contexto de ese módulo Web para que coincida con la raíz de contexto de la antigua dirección de servicio. Puede aparecer el error siguiente que puede pasar por alto: CHKJ3017E: el proyecto Web <NOM PROY WEB> está correlacionado con una raíz de contexto no válida <RAÍZ CONTEXTO NUEVO> en el proyecto EAR <NOMBRE APL>.
Opción de migración 2 para el enlace de servicios Web (SOAP/HTTP) de IBM

La segunda opción de migración del enlace de proceso de SOAP/HTTP de WebSphere Studio Application Developer Integration Edition permite a una entidad no SCA (por ejemplo, un JSP o un cliente Java) acceder a los procesos comerciales.

Por qué y cuándo se efectúa esta tarea

La referencia autónoma hace que un cliente externo pueda acceder a un componente SCA. Para crear una referencia autónoma, siga estos pasos:

  1. Abra el editor de ensamblajes para el módulo creado por el asistente de migración.
  2. Cree una referencia autónoma para cada interfaz para la que se haya generado un enlace de servicio Web de IBM (SOAP/HTTP) en WebSphere Studio Application Developer Integration Edition:
    1. Seleccione el elemento Referencias autónomas en la barra de herramientas.
    2. Pulse el lienzo del editor de ensamblajes para crear una entidad SCA de referencias autónomas.
    3. Seleccione el elemento Conexión en la barra de herramientas.
    4. Pulse la entidad Referencias autónomas para seleccionarla como origen de la conexión.
    5. Pulse el componente SCA para seleccionarlo como destino de la conexión.
    6. Verá una alerta Se creará una referencia coincidente en el nodo de origen. ¿Desea continuar?; pulse Aceptar.
    7. Seleccione la entidad Referencias autónomas que acaba de crear y seleccione el panel de contenido Descripción en la vista Propiedades.
    8. Expanda el enlace Referencias y seleccione la referencia que acaba de crear. Se muestran el nombre y la descripción de la exportación, que pueden modificarse según convenga.
    9. Si hay varias interfaces para el proceso, seleccione la que le permita exportar con este tipo de enlace.
    10. Guarde el diagrama de ensamblaje.

Migrar el enlace de servicios Web de Apache (SOAP/HTTP)

Se puede migrar el enlace de servicios Web de Apache (SOAP/HTTP) para procesos BPEL u otro tipo de servicio a la construcción SCA recomendada.

Por qué y cuándo se efectúa esta tarea

En WebSphere Studio Application Developer Integration Edition, este tipo de enlace permitía a los clientes comunicarse con un proceso BPEL o con otro tipo de servicio invocando un servicio Web de Apache.

En WebSphere Studio Application Developer Integration Edition, al seleccionar el enlace de servicios Web de Apache como tipo de despliegue para un proceso BPEL u otro tipo de servicio, se proporcionaban las opciones siguientes:

En el proyecto de servicio se crea un archivo WSDL con la especificación del enlace y el servicio SOAP de Apache. Por omisión, se crea en el mismo directorio que el servicio al que envuelve con el nombre <nombre de proceso comercial>_<nombre de tipo de puerto de interfaz de proceso comercial> SOAP.wsdl. El enlace y el servicio utilizan directamente el tipo de puerto WSDL y los mensajes de la interfaz de proceso de negocio. Tras la migración, no debe utilizar este WSDL para ninguna otra tarea salvo tal vez utilizar los mismos nombres de espacio de nombres, puerto y servicio en el nuevo WSDL que se generará en la versión 6.x.

Existen dos opciones para migrar el enlace de proceso de servicios Web de WebSphere Studio Application Developer Integration Edition. Deberá elegirse entre migrar el cliente al modelo de programación de SCA o dejarlo según el modelo de programación de servicios Web de IBM. No hay ningún enlace que sea equivalente al tipo de enlace de servicios Web de Apache (SOAP/HTTP) en el modelo de programación de SCA de V6.

Debe migrar este servicio Web de Apache para utilizar el motor de servicios Web de IBM. Consulte el tema "Migrar el enlace (SOAP/HTTP) de Servicios Web de IBM" para obtener instrucciones acerca de cómo realizar esta migración y de cómo crear un servicio Web de IBM (SOAP/HTTP).

Migrar al modelo de programación de SCA

Para cualquier código Java de formato libre que interactúe con un servicio WebSphere Studio Application Developer Integration Edition, esta sección mostrará cómo llevar a cabo la migración del modelo de programación de WSIF al nuevo modelo de programación de SCA, en que los datos que fluyen por la aplicación se almacenan en objetos de datos de servicio (SDO) de Eclipse. En esta sección aprenderá a migrar manualmente los tipos de cliente más comunes al modelo de programación nuevo.

Por qué y cuándo se efectúa esta tarea

Para cualquier proceso BPEL que contenga fragmentos de código Java, en esta sección se describe cómo llevar a cabo la migración de la antigua API de fragmentos de código Java a la nueva API de fragmentos de código Java en que los datos que fluyen por la aplicación se almacenan en objetos de datos de servicio (SDO) de Eclipse. Siempre que sea posible, los fragmentos de código los migra automáticamente el asistente Migración pero hay algunos fragmentos de código que el asistente Migración no puede migrar totalmente, lo que significa que es necesario realizar pasos manuales para completar la migración.

A continuación se proporciona un resumen de los cambios en el modelo de programación:

Modelo de programación V5.1
  1. Basado en WSIF y WSDL
  2. Proxys generados para servicios
  3. Manejadores de formato y beans para tipos
Modelo de programación V6.x (más centrado en Java)
  1. Servicios SCA basados en SDO con códigos de doclet
  2. Enlaces de interfaz para servicios
  3. SDO y enlaces de datos para tipos

Migrar las llamadas de API WSIFMessage a las API SDO

En la sección siguiente se facilita información detallada sobre cómo realizar la migración del anterior modelo de programación de WebSphere Business Integration Server Foundation Versión 5.1, en que los datos que fluyen por la aplicación se representan como objetos WSIFMessage y se genera una interfaz muy tipificada, al nuevo modelo de programación de WebSphere Process Server, en que los datos se representan como objetos de datos de servicio (SDO) y no se genera una interfaz muy tipificada.

Por qué y cuándo se efectúa esta tarea

Tabla 11. Cambios y soluciones para migrar las llamadas de API WSIFMessage a las API SDO
Cambio Solución
Las clases de envoltura basadas en WSIFMessage ya no se generan para tipos de mensaje WSDL ni tampoco las clases de ayuda de bean Java para los tipos de esquema complejos. Al escribir código que interactúa con servicios SCA, las API de SDO genéricas deben utilizarse para manipular los mensajes de commonj.sdo.DataObject que albergan los datos que fluyen a través de la aplicación.

Las definiciones de mensaje WSDL que tienen un componente con tipo simple ahora estarán representadas por un tipo Java simple que representa directamente el componente en lugar de tener una envoltura alrededor de los datos reales. Si el componente de mensaje único es un tipo complejo, los datos se representan como un DataObject que se adhiere a la definición de tipo complejo.

Las definiciones de mensaje WSDL que tienen varios componentes se corresponden a un DataObject con propiedades para todos los componentes de mensaje, donde los complexTypes están representados como propiedades "reference-type" del DataObject padre, accesible a través de los métodos getDataObject y setDataObject.

No deben utilizarse los métodos de obtención rigurosos para los componentes WSIFMessage no los beans Java generados. Debe utilizarse una API SDO permisiva para obtener las propiedades DataObject.
Los métodos de establecimiento rigurosos para las variables BPEL ya no están disponibles. Debe utilizarse una API SDO permisiva para establecer las propiedades DataObject.
Ya no deben utilizarse los métodos de obtención permisivos para las propiedades WSIFMessage. Debe utilizarse una API SDO permisiva para establecer las propiedades DataObject.
Ya no deben utilizarse los métodos de establecimiento permisivos para las propiedades WSIFMessage. Debe utilizarse una API SDO permisiva para establecer las propiedades DataObject.
Todas las llamadas de API de WSIFMessage deben migrarse a la API de SDO si es posible. Migre la llamada a una llamada de API de SDO si es posible. Vuelva a diseñar la lógica si no es posible.

Migrar el código de cliente de WebSphere Business Integration Server Foundation

En esta sección se muestra cómo migrar los distintos tipos de cliente posibles para los tipos de servicio de WebSphere Business Integration Server Foundation 5.1.

Por qué y cuándo se efectúa esta tarea

Migrar el cliente EJB

Este tema muestra cómo migrar clientes que utilizan una interfaz genérica EJB para invocar un servicio.

Por qué y cuándo se efectúa esta tarea

  1. Arrastre la exportación con enlace de SCA del módulo migrado y suéltela en el editor de ensamblajes de este nuevo módulo. Se creará una importación con enlace de SCA. Para que un cliente pueda obtener una referencia a esta importación, debe crearse una referencia autónoma.
  2. En la paleta, seleccione el elemento Referencias autónomas. Pulse una vez sobre el lienzo del editor de ensamblajes a fin de crear una nueva referencia autónoma para este nuevo módulo.
  3. Seleccione la herramienta de conexión y pulse sobre la referencia de servicio; a continuación, pulse Importar.
  4. Pulse Aceptar cuando se le muestre una alerta que le indica que se creará una referencia coincidente en el nodo de origen.
  5. Se le preguntará: Es más sencillo para un cliente Java utilizar una interfaz Java con esta referencia. ¿Desea convertir la referencia WSDL en una referencia Java compatible?
    1. Responda si desea que el cliente busque este servicio y lo convierta temporalmente en una clase Java para invocarlo utilizando una interfaz Java. Esta nueva interfaz Java toma el nombre del tipo de puerto WSDL, en que el paquete de la interfaz se deriva del espacio de nombres del tipo de puerto WSDL. Hay un método definido para cada operación definida en el tipo de puerto WSDL, y cada componente de mensaje WSDL se representa como un argumento para los métodos de interfaz.
    2. Responda No si desea que el cliente busque este servicio y utilice la interfaz com.ibm.websphere.sca.Service genérica para invocarlo utilizando la operación de invocación como un servicio SCA genérico.
  6. Si lo desea, cambie el nombre de la referencia autónoma por otro más significativo seleccionando el componente Referencias autónomas en el editor de ensamblajes. Vaya a la vista Propiedades, acceda a la pestaña Detalles, desplácese por la información detallada, seleccione la referencia que acaba de crear y modifique el nombre. Recuerde el nombre elegido para esta referencia, porque el cliente necesitará utilizar este nombre al invocar el método locateService de la instancia com.ibm.websphere.sca.ServiceManager.
  7. Pulse Guardar para guardar el diagrama de ensamblaje.

El cliente debe tener este nuevo módulo en la vía de acceso de clases local para poder acceder al módulo EJB migrado en ejecución en el servidor.

A continuación se muestra el aspecto del código de cliente para un servicio de tipo "CustomerInfo":

// Crear un ServiceManager nuevo
ServiceManager serviceManager = ServiceManager.INSTANCE;

// Localizar el servicio CustomerInfo
CustomerInfo customerInfoService = (CustomerInfo) serviceManager.locateService 
("<nombre-de-la-referencia-autónoma-del-paso-anterior");

	// Invocar el servicio CustomerInfo
	System.out.println("	[getMyValue] getting customer info...");
	DataObject customer = customerInfoService.getCustomerInfo(customerID);

El cliente debe cambiar la construcción del mensaje. Los mensajes se basaban en la clase WSIFMessage, pero ahora deben basarse en la clase commonj.sdo.DataObject.

Migrar el cliente de enlace de proceso EJB

Este tema muestra cómo migrar clientes que utilizan el enlace de proceso EJB WSIF para acceder a un servicio BPEL.

Por qué y cuándo se efectúa esta tarea

Los clientes que utilizó el enlace de proceso EJB para invocar un proceso comercial deben utilizar ahora la API SCA para invocar el servicio (el proceso comercial migrado debe tener una Exportación con enlace SCA) o la API de cliente de servicio Web de IBM para invocar el servicio (el proceso comercial migrado debe tener una Exportación con enlace de servicio Web.)

Consulte los temas "Migrar el cliente EJB", "Migrar el cliente de servicios Web IBM (SOAP/JMS)" o "Migrar el cliente de servicios Web IBM (SOAP/HTTP)" para obtener más información acerca de cómo generar esos clientes.

Migrar el cliente de servicios Web de IBM (SOAP/JMS)

Este tema muestra cómo migrar clientes que utilizan las API de servicio Web (SOAP/JMS) para invocar un servicio.

Por qué y cuándo se efectúa esta tarea

No se necesita migración para los clientes existentes durante la migración. Tenga en cuenta que debe modificar manualmente el proyecto Web generado (crear una correlación de servlet) y que a veces tendrá que modificar la raíz de contexto del proyecto en el descriptor de despliegue de aplicaciones para publicar el servicio en la misma dirección en la que se publicó en WebSphere Business Integration Server Foundation. Consulte el tema "Migrar el enlace de servicios Web de IBM (SOAP/JMS)".

Es importante tener en cuenta que al contrario que en 5.1 donde se podía generar un proxy de cliente RPC o WSIF, en 6.x las herramientas solo soportan la generación de clientes RPC porque RPC es la API preferida por 6.x por encima de la API de WSIF.

Nota: para generar nuevos proxys de cliente desde WebSphere Integration Developer, debe tener instalado un WebSphere Process Server o WebSphere Application Server.

  1. Asegúrese de tener instalado un WebSphere Process Server o WebSphere Application Server.
  2. En la perspectiva Recursos o Java, localice el archivo WSDL correspondiente a la Exportación con enlace de servicio Web, pulse con el botón derecho y seleccione Servicios Web -> Generar cliente.
  3. Para el Tipo de proxy de cliente, elija Proxy Java y pulse Siguiente.
  4. La ubicación del archivo WSDL debería estar cumplimentada. Pulse Siguiente.
  5. A continuación debe seleccionar las opciones adecuadas para especificar la configuración del entorno de cliente incluyendo el servidor y el tiempo de ejecución del servicio Web, la versión J2EE, el tipo de cliente (Java, EJB, Web, Cliente de aplicaciones.) Pulse Siguiente.
  6. Concluya los pasos restantes para generar el proxy de cliente.
Migrar el cliente de servicios Web de IBM (SOAP/HTTP)

Este tema muestra cómo migrar clientes que utilizan las API de servicio Web (SOAP/HTTP) para invocar un servicio.

Por qué y cuándo se efectúa esta tarea

No se necesita migración para los clientes existentes durante la migración. Tenga en cuenta que debe modificar manualmente el proyecto Web generado (crear una correlación de servlet) y que a veces tendrá que modificar la raíz de contexto del proyecto en el descriptor de despliegue de aplicaciones para publicar el servicio en la misma dirección en la que se publicó en WebSphere Business Integration Server Foundation. Consulte el tema "Migrar el enlace de servicios Web de IBM (SOAP/HTTP)".

Si se han producido cambios en el diseño y desea generar un cliente proxy nuevo, los pasos siguientes le mostrarán cómo hacerlo. Es importante tener en cuenta que al contrario que en 5.1 donde se podía generar un proxy de cliente RPC o WSIF, en 6.x las herramientas solo soportan la generación de clientes RPC porque RPC es la API preferida por 6.x por encima de la API de WSIF.

Nota: para generar nuevos proxys de cliente desde WebSphere Integration Developer, debe tener instalado un WebSphere Process Server o WebSphere Application Server.

  1. Asegúrese de tener instalado un WebSphere Process Server o WebSphere Application Server.
  2. Seleccione el archivo WSDL correspondiente a la Exportación con enlace de servicio Web, pulse con el botón derecho y seleccione Servicios Web -> Generar cliente.
  3. Para el Tipo de proxy de cliente, elija Proxy Java y pulse Siguiente.
  4. La ubicación del archivo WSDL debería estar cumplimentada. Pulse Siguiente.
  5. A continuación debe seleccionar las opciones adecuadas para especificar la configuración del entorno de cliente incluyendo el servidor y el tiempo de ejecución del servicio Web, la versión J2EE, el tipo de cliente (Java, EJB, Web, Cliente de aplicaciones.) Pulse Siguiente.
  6. Concluya los pasos restantes para generar el proxy de cliente.

Migrar el cliente de servicios Web de Apache (SOAP/HTTP)

Las API de cliente de servicios Web de Apache no son apropiadas para invocar un servicio de WebSphere Integration Developer. Debe migrarse el código de cliente para utilizar las API de cliente de servicios Web de IBM (SOAP/HTTP).

Por qué y cuándo se efectúa esta tarea

Consulte el tema "Migrar el cliente de servicios Web de IBM (SOAP/HTTP)" para obtener más información.

En 5.1 si se generaba automáticamente un proxy de cliente, el proxy utilizaba las API de WSIF para interactuar con el servicio. En 6.x las herramientas solo soportan la generación de clientes RPC porque RPC es la API preferida por 6.x por encima de la API de WSIF.

Nota: para generar nuevos proxys de cliente desde WebSphere Integration Developer, debe tener instalado un WebSphere Process Server o WebSphere Application Server.

  1. Asegúrese de tener instalado un WebSphere Process Server o WebSphere Application Server.
  2. Seleccione el archivo WSDL correspondiente a la Exportación con enlace de servicio Web, pulse con el botón derecho y seleccione Servicios Web -> Generar cliente.
  3. Para el Tipo de proxy de cliente, elija Proxy Java y pulse Siguiente.
  4. La ubicación del archivo WSDL debería estar cumplimentada. Pulse Siguiente.
  5. A continuación debe seleccionar las opciones adecuadas para especificar la configuración del entorno de cliente incluyendo el servidor y el tiempo de ejecución del servicio Web, la versión J2EE, el tipo de cliente (Java, EJB, Web, Cliente de aplicaciones.) Pulse Siguiente.
  6. Concluya los pasos restantes para generar el proxy de cliente.

Migrar el cliente JMS

Los clientes que se comunicaban con un servicio 5.1 por medio de la API JMS (enviando un mensaje JMS a una cola) pueden requerir migración manual. Este tema muestra cómo migrar clientes que utilizan las API JMS (enviando un mensaje JMS a una cola) para invocar un servicio.

Por qué y cuándo se efectúa esta tarea

Debe asegurarse de que la opción Exportar con enlace JMS que ha creado en un paso anterior podrá aceptar este mensaje de texto u objeto sin cambios. Puede que sea necesario escribir un enlace de datos personalizado para conseguirlo. Consulte la sección "Migrar los enlaces de JMS y de proceso JMS" para obtener más información.

El cliente debe cambiar la construcción del mensaje. Antes los mensajes se basaban en la clase WSIFMessage, pero ahora deben basarse en la clase commonj.sdo.DataObject. Consulte la sección "Migrar llamadas API de WSIFMessage a de SDO" para obtener más detalles acerca de cómo realizar esta migración manual.

Migrar el cliente de la API de EJB del coreógrafo de procesos de negocio genérica

Este tema muestra cómo migrar clientes que utilizan la API genérica EJB del coreógrafo de procesos 5.1 para invocar un servicio BPEL.

Por qué y cuándo se efectúa esta tarea

Hay una nueva versión de la API de EJB genérica que utiliza DataObjects como formato de mensaje. El cliente debe cambiar la construcción del mensaje. Antes los mensajes se basaban en la clase WSIFMessage, pero ahora deben basarse en la clase commonj.sdo.DataObject. Tenga presente que la API de EJB genérica no ha cambiado de modo significativo, dado que ClientObjectWrapper sigue proporcionando una envoltura de mensaje en torno al formato de mensaje concreto.

Ejemplo: DataObject dobj = myClientObjectWrapper.getObject();
Serie resultante = dobj.getInt("resultInt");

El nombre JNDI del EJB genérico antiguo que toma objetos WSIFMessage es:

GenericProcessChoreographerEJB
Nombre JNDI: com/ibm/bpe/api/BusinessProcessHome
Interfaz: com.ibm.bpe.api.BusinessProcess

Hay dos EJB genéricos en los que las operaciones de tareas manuales están disponibles como EJB aparte. Los nombres JNDI de estos EJB genéricos son:

GenericBusinessFlowManagerEJB
Nombre JNDI: com/ibm/bpe/api/BusinessFlowManagerHome
Interfaz: com.ibm.bpe.api.BusinessFlowManager

HumanTaskManagerEJB
Nombre JNDI: com/ibm/task/api/TaskManagerHome
Interfaz: com.ibm.task.api.TaskManager
Migrar el cliente de la API de mensajería del coreógrafo de procesos de negocio genérica y el cliente de enlace de proceso JMS

Con respecto a la API de mensajería genérica en WebSphere Process Server, consulte el tema "Desarrollar aplicaciones cliente JMS" mediante el enlace que figura más abajo.

Por qué y cuándo se efectúa esta tarea

Desarrollar aplicaciones cliente JMS.

Migrar el cliente Web del coreógrafo de procesos de negocio

Este tema muestra cómo migrar los valores de cliente Web y los JSP personalizados del coreógrafo de procesos 5.1.

Por qué y cuándo se efectúa esta tarea

El asistente de migración conserva los valores de cliente Web 5.1 y, en el editor de tareas manuales, no puede editarlos. Debe crear nuevos valores de cliente Web y JSP mediante WebSphere Integration Developer 6.x.

Migrar modificaciones de cliente Web
En 5.1 el usuario podía modificar el aspecto del cliente Web basado en Struts modificando el JSP Header.jsp y la hoja de estilo dwc.css.

Puesto que el cliente Web 6.x (redenominado como Explorador de coreógrafo de procesos de negocio) está basado en Java Server Faces (JSF) en lugar de en Struts, no es posible migrar automáticamente las modificaciones del cliente Web. Por lo tanto, es recomendable consultar la documentación del "Explorador de coreógrafo de procesos de negocio" para conocer los detalles acerca de la personalización de la versión 6.x de esta aplicación.

Los JSP definidos por el usuario pueden definirse para procesos de negocio y para actividades de personal. El cliente Web utiliza estos JSP para visualizar los mensajes de entrada y de salida para el proceso y las actividades.

Estos JSP son particularmente útiles cuando:

  1. Los mensajes tienen componentes no primitivos para mejorar la capacidad de utilización de la estructura de datos del mensaje.
  2. Desea ampliar las posibilidades del cliente Web.

Hay más opciones diferentes disponibles al especificar los valores de cliente Web para un proceso 6.x por lo que deberá utilizar WebSphere Integration Developer para rediseñar los valores de cliente Web para los procesos y las actividades migrados:

  1. Seleccione el lienzo del proceso o una actividad del proceso.
  2. En la vista Propiedades, seleccione la pestaña Cliente para volver a diseñar los valores de cliente Web.
  3. Migrar manualmente los JSP definidos por el usuario:
    1. Consulte la sección "Migrar al modelo de programación SCA" para conocer los cambios en el modelo de programación.
    2. El cliente Web utiliza las API genéricas para interactuar con procesos de negocio. Consulte las secciones que muestran cómo migrar llamadas a estas API genéricas.
  4. Especifique el nombre del JSP nuevo en los valores de cliente Web 6.x para el proceso
Nota: La correlación de JSP no es necesaria con el Explorador de Coreógrafo de procesos de negocio (BPC) 6.x porque los DataObjects no necesitan ninguna correlación personalizada.

Migrar los fragmentos de código BPEL Java de WebSphere Business Integration Server Foundation

Para cualquier proceso BPEL que contenga fragmentos de código Java, en esta sección se describe cómo llevar a cabo la migración de la antigua API de fragmentos de código Java a la nueva API de fragmentos de código Java en que los datos que fluyen por la aplicación se almacenan como objetos de datos de servicio (SDO) de Eclipse.

Por qué y cuándo se efectúa esta tarea

Consulte la sección "Migrar desde las llamadas API de WSIFMessage a las API de SDO" para conocer los pasos de migración específicos de la transición de WSIFMessage a SDO a realizar.

Siempre que es posible el asistente de migración migra automáticamente los fragmentos de código, pero hay fragmentos de código que el asistente de migración no puede migrar por completo. Por consiguiente, es preciso realizar una serie de pasos manuales adicionales para completar la migración. Consulte el tema Limitaciones para conocer más detalles acerca de los tipos de fragmentos de código Java que deben migrarse manualmente. Siempre que se encuentre uno de estos fragmentos de código, el asistente Migración explicará por qué no puede migrarse automáticamente y emitirá un aviso o un mensaje de error.

En la tabla siguiente se detallan los cambios en el modelo de programación de fragmentos de código Java de BPEL y la API de la coreografía de procesos de la versión 5.1 a la 6.x:

Tabla 12. Cambios y soluciones para migrar fragmentos de código Java de BPEL de WebSphere Business Integration Server Foundation
Cambio Solución
Las clases de envoltura basadas en WSIFMessage ya no se generan para tipos de mensaje WSDL ni tampoco las clases de ayuda de bean Java para los tipos de esquema complejos. Es posible acceder a las variables de BPEL directamente por nombre. Tenga en cuenta que para las variables BPEL cuya definición de mensaje WSDL tenga un solo componente, ahora estas variables representarán directamente el componente en lugar de tener una envoltura alrededor de los datos reales. Las variables cuyo tipo de mensaje tenga varios componentes tendrán una envoltura DataObject alrededor de los componentes (donde la envoltura en WebSphere Application Developer Integration Edition era un WSIFMessage).

Puesto que las variables BPEL pueden utilizarse directamente en fragmentos de código de 6.x, son menos necesarias de lo que lo eran en 5.1.

Los métodos de obtención rigurosos para las variables BPEL inicializaban implícitamente el objeto de envoltura WSIFMessage alrededor de los componentes de mensaje. No hay ningún objeto de 'envoltura' para las variables BPEL cuya definición de mensaje WSDL tenga un solo componente: en este caso, las variables de BPEL representan directamente el componente. (en el caso en que el único componente sea un tipo simple XSD, la variable BPEL estará representada como el tipo de envoltura de objeto Java como por ejemplo java.lang.String, java.lang.Integer, etc.) Las variables BPEL con definiciones de mensaje WSDL de varios componentes se tratan de forma distinta: todavía hay una envoltura alrededor de los componentes y esta envoltura DataObject debe inicializarse explícitamente en el fragmento de código Java 6.x si es que no la ha establecido una operación anterior.

Si las variables locales de los fragmentos de código 5.1 tenían el mismo nombre que la variable BPEL, puede haber conflictos, de modo que intente remediar la situación si es posible.

Los objetos WSIFMessage ya no se utilizan para representar variables BPEL. Si las clases Java personalizadas invocadas desde los fragmentos de código Java tienen un parámetro WSIFMessage, será necesario migrarlo de forma que acepte/devuelva un DataObject.
Los métodos de obtención rigurosos para las variables BPEL ya no están disponibles. Es posible acceder a las variables directamente por nombre. Tenga en cuenta que para las variables BPEL cuya definición de mensaje WSDL tenga un solo componente, ahora directamente representará el componente en lugar de tener una envoltura alrededor de los datos reales. Las variables cuyo tipo de mensaje tenga varios componentes tendrán una envoltura DataObject alrededor de los componentes (donde la envoltura en WebSphere Application Developer Integration Edition era un WSIFMessage).
Los métodos de establecimiento rigurosos para las variables BPEL ya no están disponibles. Es posible acceder a las variables directamente por nombre. Tenga en cuenta que para las variables BPEL cuya definición de mensaje WSDL tenga un solo componente, ahora estas variables representarán directamente el componente en lugar de tener una envoltura alrededor de los datos reales. Las variables cuyo tipo de mensaje tenga varios componentes tendrán una envoltura DataObject alrededor de los componentes (donde la envoltura en WebSphere Application Developer Integration Edition era un WSIFMessage).
Los métodos de obtención permisivos para las variables de BPEL que devuelven un WSIFMessage ya no están disponibles. Es posible acceder a las variables directamente por nombre. Tenga en cuenta que para las variables BPEL cuya definición de mensaje WSDL tenga un solo componente, ahora estas variables representarán directamente el componente en lugar de tener una envoltura alrededor de los datos reales. Las variables cuyo tipo de mensaje tenga varios componentes tendrán una envoltura DataObject alrededor de los componentes (donde la envoltura en WebSphere Application Developer Integration Edition era un WSIFMessage).

Tenga en cuenta que había dos variaciones del método getVariableAsWSIFMessage:

getVariableAsWSIFMessage(String variableName)
getVariableAsWSIFMessage(String variableName, boolean forUpdate)

Para una actividad de fragmento de código Java, el acceso por omisión es de lectura-escritura. Puede cambiarlo a sólo lectura especificando @bpe.readOnlyVariables con la lista de nombres de las variables en un comentario en el fragmento de código. Por ejemplo, puede establecer las variables B y D a sólo lectura del siguiente modo:

variableB.setString("/x/y/z", variableA.getString("/a/b/c")); 
// @bpe.readOnlyVariables names="variableA"
variableD.setInt("/x/y/z", variableC.getInt("/a/b/c")); 
// @bpe.readOnlyVariables names="variableC"

Además, si tiene un fragmento de código Java en una condición, las variables son de sólo lectura por omisión, pero puede cambiarlas a lectura-escritura especificando @bpe.readWriteVariables...

Los métodos de establecimiento permisivos para las variables BPEL ya no están disponibles. Es posible acceder a las variables directamente por nombre. Tenga en cuenta que para las variables BPEL cuya definición de mensaje WSDL tenga un solo componente, ahora estas variables representarán directamente el componente en lugar de tener una envoltura alrededor de los datos reales. Las variables cuyo tipo de mensaje tenga varios componentes tendrán una envoltura DataObject alrededor de los componentes (donde la envoltura en WebSphere Application Developer Integration Edition era un WSIFMessage).
Los métodos de obtención permisivos para los componentes de mensaje de variables BPEL no son adecuados para los mensajes de un solo componente y se han cambiado por mensajes de varios componentes. Migre al método de obtención permisivos para las propiedades de las variables BPEL (de DataObject).

Tenga en cuenta que para las variables BPEL cuya definición de mensaje WSDL tenga un solo componente, la variable BPEL representa directamente el componente y debería accederse directamente a la variable sin utilizar un método de obtención.

Había dos variaciones del método getVariablePartAsObject:

getVariablePartAsObject(String variableName, String partName)
getVariablePartAsObject(String variableName, String partName,boolean 
forUpdate)

Para los mensajes de varios componentes, este método proporciona funcionalidad equivalente en 6.x:

getVariableProperty(String variableName, QName propertyName);  		

En 6.x no existe el concepto de utilización de una variable para el acceso solo de lectura (lo que sí existía en 5.1 para el primer método que figura más arriba, así como para el segundo método con forUpdate='false'). La variable se utiliza directamente en el fragmento de código 6.x y siempre puede actualizarse.

Los métodos de establecimiento permisivos para los componentes de mensaje de variables BPEL no son adecuados para los mensajes de un solo componente y se han cambiado por mensajes de varios componentes. Migre al método de establecimiento permisivo para las propiedades de las variables BPEL (de DataObject).

Tenga en cuenta que para las variables BPEL cuya definición de mensaje WSDL tenga un solo componente, la variable BPEL representa directamente el componente y debería accederse directamente a la variable sin utilizar un método de establecimiento.

Es necesario migrar las llamadas al método siguiente:

setVariableObjectPart(String variableName, String partName, 
Object data)  

Para los mensajes de varios componentes, este método proporciona funcionalidad equivalente en 6.x:

setVariableProperty(String variableName, QName propertyName,
Serializable value);
Los métodos de obtención rigurosos para los enlaces de socio de BPEL ya no están disponibles. Migre a los métodos de obtención permisivos para enlaces de socio de BPEL.
Los métodos de establecimiento rigurosos para los enlaces de socio de BPEL ya no están disponibles. Migre a los métodos de establecimiento permisivos para enlaces de socio de BPEL.
Los métodos de obtención rigurosos para los conjuntos de correlación de BPEL ya no están disponibles.
Fragmento de código V5.1:
String corrSetPropStr = 
getCorrelationSetCorrSetAPropertyCustomerName();
int corrSetPropInt = 
getCorrelationSetCorrSetBPropertyCustomerId();
Fragmento de código V6.x:
String corrSetPropStr = (String) getCorrelationSetProperty
("CorrSetA", new QName("CustomerName"));
int corrSetPropInt = ((Integer) getCorrelationSetProperty 
("CorrSetB", new QName("CustomerId"))).intValue();
Se necesita un parámetro adicional para los métodos de obtención con tipo difuminado para las propiedades personalizadas de actividad BPEL.
Fragmento de código V5.1:
String val = getActivityCustomProperty("propName");
Fragmento de código V6.x:
String val = getActivityCustomProperty
("name-of-current-activity", "propName");
Se necesita un parámetro adicional para los métodos de establecimiento con tipo difuminado para las propiedades personalizadas de actividad BPEL.
Fragmento de código V5.1:
String newVal = "new value";
setActivityCustomProperty("propName", newVal); 
Fragmento de código V6.x:
String newVal = "new value";
setActivityCustomProperty("name-of-current-activity", 
"propName", newVal);
El método raiseFault(QName faultQName, Serializable message) ya no existe. Migre raiseFault(QName faultQName, String variableName) cuando sea posible, de lo contrario migre al método raiseFault(QName faultQName) o cree una variable BPEL nueva para el objeto serializable.

Migrar interacciones con WebSphere Business Integration Adapters

Si el cliente JMS es un WebSphere Business Integration Adapter, necesitará utilizar las herramientas de Servicio externo para crear la Importación con enlace JMS. Esta Importación utiliza un enlace de datos especial para serializar el SDO con el formato exacto esperado por el WebSphere Business Integration Adapter.

Por qué y cuándo se efectúa esta tarea

Para acceder a las herramientas de servicio externo, siga estos pasos:

  1. Acceda a Archivo -> Nuevo -> Otro -> Integración de negocio y seleccione Servicio externo. Pulse Siguiente.
  2. Elija Adaptadores. Pulse Siguiente.
  3. Especifique la vía de acceso del archivo de configuración de WebSphere Business Integration Adapter (.cfg) y el directorio que contiene el esquema XML de los objetos de negocio que utiliza el adaptador. Pulse Siguiente.
  4. Examine la consulta generada y si es correcta, pulse Ejecutar consulta. En la lista Objetos descubiertos por consulta, seleccione los objetos que desea añadir (uno por uno) y pulse el botón >> Añadir.
  5. Acepte los parámetros de configuración para el objeto de negocio y pulse Aceptar.
  6. Repita el proceso para cada objeto de negocio.
  7. Pulse Siguiente.
  8. Como Formato de objeto de negocio de tiempo de ejecución, seleccione SDO. Como Proyecto destino, seleccione el módulo que acaba de migrar. Deje el campo Carpeta en blanco.
  9. Pulse Finalizar.

Qué hacer a continuación

Esta herramienta migrará los XSD antiguos al formato esperado por el enlace de datos especial, por lo que debe eliminar los XSD de WebSphere Business Integration Adapter antiguos y utilice los XSD nuevos. Si el módulo no recibirá mensajes del adaptador, suprima las exportaciones generadas por esta herramienta. Si el módulo no enviará mensajes al adaptador, suprima la Importación. Consulte el centro de información para obtener más información acerca de esta característica.

Migrar interfaces WSDL que tienen tipos de matriz codificados para SOAP

En esta sección se muestra cómo migrar o manejar esquemas XML que tienen tipos de matriz codificados para SOAP.

Por qué y cuándo se efectúa esta tarea

Los tipos de matriz codificados para Soap que tienen el estilo RPC se tratarán como secuencias no enlazadas de un tipo concreto en 6.x. No es recomendable crear tipos XSD que hagan referencia a los tipos soapend:Array de ninguna forma, ya que el modelo de programación se mueve hacia el estilo documento/literal acomodado en lugar de hacia el estilo RPC (aunque esto puede cambiar).

Habrá casos en los que una aplicación SCA deba invocar un servicio externo que utilice el tipo soapend:Array. No hay forma de evitar esto en algunos casos, así que el ejemplo siguiente muestra cómo manejar esta situación:

Código WSDL de ejemplo:

		<xsd:complexType name="Vendor">
			<xsd:all>
				<xsd:element name="name" type="xsd:string" />
				<xsd:element name="phoneNumber" type="xsd:string" />
			</xsd:all>
		</xsd:complexType>
	</xsd:schema>

		<xsd:complexType name="Vendors">
			<xsd:complexContent mixed="false">
				<xsd:restriction base="soapenc:Array">
					<xsd:attribute wsdl:arrayType="tns:Vendor[]" ref="soapenc:arrayType" 
					xmlnxsd:wsdl="http://schemas.xmlsoap.org/wsdl/" />
				</xsd:restriction>
		</xsd:complexContent>

		<xsd:complexType name="VendorsForProduct">
			<xsd:all>
				<xsd:element name="productId" type="xsd:string" />
				<xsd:element name="vendorList" type="tns:Vendors" />
			</xsd:all>
		</xsd:complexType>

		<xsd:complexType name="Product">
			<xsd:all>
				<xsd:element name="productId" type="xsd:string" />
				<xsd:element name="productName" type="xsd:string" />
			</xsd:all>
		</xsd:complexType>

	<message name="doFindVendorResponse">
		<part name="returnVal" type="tns:VendorsForProduct" />
	</message>

	<operation name="doFindVendor">
		<input message="tns:doFindVendor" />
		<output message="tns:doFindVendorResponse" />
	</operation>

Código de ejemplo para un cliente de este servicio Web:

  // Localizar el servicio de proveedor (vendor) y buscar la operación doFindVendor 

Service findVendor=(Service)ServiceManager.INSTANCE.locateService("vendorSearch");
OperationType doFindVendorOperationType=findVendor.getReference().getOperationType("doGoogleSearch");
            
 // Crear el DataObject de entrada
 DataObject doFindVendor=DataFactory.INSTANCE.create(doFindVendorOperationType.getInputType());
 doFindVendor.setString("productId", "12345");
 doFindVendor.setString("productName", "Refrigerator");

            // Invocar el servicio FindVendor
DataObject FindVendorResult = (DataObject)findVendor.invoke(doFindVendorOperationType, doFindVendor);
           
            // Visualizar el resultado
            int resultProductId=findVendorResult.getString("productId");
            
            DataObject resultElements=findVendorResult.getDataObject("vendorList");
            Sequence results=resultElements.getSequence(0);
            for (int i=0, n=results.size(); i
            for (int i=0, n=results.size(); i

A continuación se proporciona otro ejemplo en el que el tipo root del objeto de datos es soapenc:Array. Observe cómo se crea el DataObject sampleElements utilizando el segundo esquema listado anteriormente. Primero se obtiene el tipo del DataObject y, a continuación, la propiedad de sampleStructElement. En realidad se trata de una propiedad de sustitución y solo se utiliza para obtener una propiedad válida para utilizarla al añadir los DataObjects a la secuencia. En su caso puede utilizarse un patrón como este:

Código WSDL de ejemplo:

<s:schema elementFormDefault="qualified" targetNamespace="http://soapinterop.org/xsd">
			<s:import namespace="http://schemas.xmlsoap.org/soap/encoding/" />
			<s:import namespace="http://schemas.xmlsoap.org/wsdl/" />
			<s:complexType name="SOAPStruct">
				<s:sequence>
					<s:element minOccurs="1" maxOccurs="1" form="unqualified" name="varInt" type="s:int" />
					<s:element minOccurs="1" maxOccurs="1" form="unqualified" name="varString" type="s:string" />
					<s:element minOccurs="1" maxOccurs="1" form="unqualified" name="varFloat" type="s:float" />
				</s:sequence>
			</s:complexType>

			<s:complexType name="ArrayOfSOAPStruct">
				<s:complexContent mixed="false">
					<s:restriction base="soapenc:Array">
						<s:attribute wsdl:arrayType="s0:SOAPStruct[]" ref="soapenc:arrayType" />
					</s:restriction>
				</s:complexContent>
			</s:complexType>
		</s:schema>

	<wsdl:message name="echoStructArraySoapIn">
		<wsdl:part name="inputStructArray" type="s0:ArrayOfSOAPStruct" />
	</wsdl:message>
	<wsdl:message name="echoStructArraySoapOut">
		<wsdl:part name="return" type="s0:ArrayOfSOAPStruct" />
	</wsdl:message>

		<wsdl:operation name="echoStructArray">
			<wsdl:input message="tns:echoStructArraySoapIn" />
			<wsdl:output message="tns:echoStructArraySoapOut" />
		</wsdl:operation>

	<schema targetNamespace="http://sample/elements"
		xmlns="http://www.w3.org/2001/XMLSchema"
		xmlns:tns="http://sample/elements">

	<element name="sampleStringElement" type="string"/>
	
	<element name="sampleStructElement" type="any"/>

</schema>

Código de ejemplo para un cliente de este servicio Web:

//
Crear el DataObject de entrada y obtener la secuencia SDO para el elemento 
// any
DataFactory dataFactory=DataFactory.INSTANCE;
DataObject arrayOfStruct = dataFactory.create("http://soapinterop.org/xsd","ArrayOfSOAPStruct");
Sequence sequence=arrayOfStruct.getSequence("any");
            
// Obtener la propiedad SDO para el elemento sample que deseamos utilizar 
// aquí para llenar la secuencia
// Hemos definido este elemento en un archivo XSD, consulte SampleElements.xsd
DataObject sampleElements=dataFactory.create("http://sample/elements", 
"DocumentRoot");
Property property = sampleElements.getType().getProperty("sampleStructElement");
            
            // Añadir los elementos a la secuencia
DataObject item=dataFactory.create("http://soapinterop.org/xsd", "SOAPStruct");
item.setInt("varInt", 1);
item.setString("varString", "Hello");
item.setFloat("varFloat", 1.0f);
sequence.add(property, item);
item=dataFactory.create("http://soapinterop.org/xsd", "SOAPStruct");
item.setInt("varInt", 2);
item.setString("varString", "World");
item.setFloat("varFloat", 2.0f);
sequence.add(property, item);

// Invocar la operación echoStructArray
System.out.println("[client] invoking echoStructArray operation");
DataObject echoArrayOfStruct = (DataObject)interopTest.invoke("echoStructArray", arrayOfStruct);
            
// Visualizar el resultado
if (echoArrayOfStruct!=null) {
    sequence=echoArrayOfStruct.getSequence("any");
    for (int i=0, n=sequence.size(); i<n; i++) {
      item=(DataObject)sequence.getValue(i);
      System.out.println("[client] item varInt = "+ 
          item.getInt("varInt")+" 
          varString="+item.getString("varString")+" 
          varFloat="+item.getFloat("varFloat"));

Suprimir manualmente definiciones de WSIF (Infraestructura de invocación de servicios Web) 5.1

Una vez realizada la migración de los artefactos origen, debe suprimir todas las definiciones WSDL de enlace y servicio WSIF 5.1 de los proyectos 6.x que ya no se utilicen. El escenario de consumo de la migración de servicios es el único caso en que se seguirá utilizando un enlace o servicio WSIF.

Por qué y cuándo se efectúa esta tarea

Los siguientes espacios de nombres WSDL indican que una definición de enlace o servicio es un servicio WSIF 5.1 y que puede descartarse si ya no se utiliza:

Espacio de nombres WSIF EJB:
http://schemas.xmlsoap.org/wsdl/ejb/
Espacio de nombres WSIF Java:
http://schemas.xmlsoap.org/wsdl/java/
Espacio de nombres WSIF JMS:
http://schemas.xmlsoap.org/soap/jms/
Espacio de nombres WSIF de proceso comercial:
http://schemas.xmlsoap.org/wsdl/process/
Espacio de nombres WSIF de transformador:
http://schemas.xmlsoap.org/wsdl/transformer/
Espacio de nombres WSIF IMS:
http://schemas.xmlsoap.org/wsdl/ims/
Espacio de nombres WSIF CICS_ECI:
http://schemas.xmlsoap.org/wsdl/cicseci/
Espacio de nombres WSIF CICS-EPI:
http://schemas.xmlsoap.org/wsdl/cicsepi/
Espacio de nombres WSIF HOD:
http://schemas.xmlsoap.org/wsdl/hod3270/

Avisos

Esta información se ha desarrollado para productos y servicios ofrecidos en los EE.UU.

puede no ofrecer los productos, servicios o características tratados en este documento en otros países. Póngase en contacto con el representante local de IBM que le informará sobre los productos y servicios disponibles actualmente en su área. Las referencias hechas a productos, programas o servicio de IBM no pretenden afirmar ni dar a entender que únicamente puedan utilizarse dichos productos, programas o servicios de IBM. Puede utilizarse en su lugar cualquier otro producto, programa o servicio funcionalmente equivalente que no vulnere ninguno de los derechos de propiedad intelectual de IBM. No obstante, es responsabilidad del usuario evaluar y verificar el funcionamiento de cualquier producto, programa o servicio que no sea de IBM.

IBM puede tener patentes o solicitudes de patente pendientes de aprobación que cubran temas descritos en este documento. La posesión de esta documentación no le otorga ninguna licencia sobre dichas patentes. Puede enviar las consultas sobre licencias, por escrito, a la siguiente dirección:

IBM Director of Licensing
IBM Corporation
North Castle Drive
Armonk, NY 10504-1785
Estados Unidos de América

Para consultas sobre licencias relativas a la información de juego de caracteres doble byte (DBCS), póngase en contacto con el departamento de propiedad intelectual de IBM en su país o envíe las consultas, por escrito, a:

IBM World Trade Asia Corporation
Licensing
2-31 Roppongi 3-chome, Minato-ku
Tokyo 106-0032, Japón

El párrafo siguiente no se aplica al Reino Unido ni a ningún otro país en que dichas disposiciones entren en contradicción con las leyes locales: INTERNATIONAL BUSINESS MACHINES CORPORATION PROPORCIONA ESTA PUBLICACIÓN "TAL CUAL" SIN GARANTÍA DE NINGÚN TIPO, NI EXPLÍCITA NI IMPLÍCITA, INCLUYENDO, PERO NO LIMITÁNDOSE, A LAS GARANTÍAS IMPLÍCITAS DE NO VULNERABILIDAD, COMERCIALIZACIÓN O ADECUACIÓN A UN PROPÓSITO DETERMINADO. Algunas legislaciones no contemplan la declaración de limitación de garantías, ni implícitas ni explícitas, en determinadas transacciones, por lo que cabe la posibilidad de que esta declaración no se aplique en su caso.

Esta información puede contener imprecisiones técnicas o errores tipográficos. Periódicamente se efectúan cambios en la información incluida en este documento; estos cambios se incorporarán en nuevas ediciones de la publicación. IBM puede efectuar mejoras y/o cambios en los productos y/o programas descritos en esta publicación en cualquier momento y sin previo aviso.

Cualquier referencia incluida en esta información a sitios Web que no sean de IBM solo se proporciona para su comodidad y en ningún modo constituye una aprobación de dichos sitios Web. Los materiales de estos sitios web no forman parte de los materiales de IBM para este producto y el uso que se haga de estos sitios web es de la entera responsabilidad del usuario.

IBM puede utilizar o distribuir la información que usted le suministre del modo que IBM considere conveniente sin incurrir por ello en ninguna obligación para con usted.

Los licenciatarios de este programa que deseen obtener información acerca del mismo con el fin de: (i) intercambiar la información entre programas creados independientemente y otros programas (incluyendo este) y (ii) utilizar mutuamente la información que se ha intercambiado, deben ponerse en contacto con:

Intellectual Property Dept. for WebSphere Software
IBM Corporation
3600 Steeles Ave. East
Markham, Ontario
Canadá L3R 9Z7

Esta información puede estar disponible, sujeta a los términos y condiciones adecuados, incluyendo en algunos casos el pago de una tarifa.

El programa bajo licencia descrito en este documento y todo el material bajo licencia disponible para el mismo, lo proporciona IBM bajo los términos del Acuerdo de Cliente IBM, el Acuerdo de Licencia de Programa Internacional IBM o cualquier otro acuerdo equivalente entre ambas partes.

Los datos de rendimiento incluidos aquí se determinaron en un entorno controlado. Por lo tanto, los resultados que se obtengan en otros entornos operativos pueden variar significativamente. Tal vez se hayan realizado mediciones en sistemas que estén en fase de desarrollo y no existe ninguna garantía de que esas mediciones vayan a ser iguales en los sistemas disponibles en el mercado. Además, es posible que algunas mediciones se hayan estimado mediante extrapolación. Los resultados reales pueden variar. Los usuarios de este documento deben verificar los datos aplicables a su entorno específico.

La información concerniente a productos no IBM se ha obtenido de los suministradores de dichos productos, de sus anuncios publicados o de otras fuentes de información pública disponibles. IBM no ha comprobado dichos productos y no puede afirmar la exactitud en cuanto a rendimiento, compatibilidad u otras características relativas a productos no IBM. Las consultas acerca de las posibilidades de los productos no IBM deben dirigirse a las personas que los suministran.

Todas las declaraciones relativas a la dirección o la intención futura de IBM están sujetas a cambios o anulación sin previo aviso y tan solo representan metas y objetivos.

Todos los precios de IBM mostrados son precios de venta al detalle sugeridos por IBM, son actuales y están sujetos a cambio sin previo aviso. Los precios de los distribuidores pueden variar.

Esta información se proporciona solamente a efectos de planificación. La información contenida aquí está sujeta a cambios antes de que los productos descritos estén disponibles.

Esta información contiene ejemplos de datos e informes utilizados en operaciones comerciales diarias. Para ilustrarlas de la forma más completa posible, los ejemplos incluyen nombres de personas, empresas, marcas y productos. Todos estos nombres son ficticios y cualquier parecido con los nombres y direcciones utilizados por una empresa real es mera coincidencia.

LICENCIA DE COPYRIGHT:

Esta información contiene programas de aplicación de ejemplo en lenguaje fuente, que ilustran las técnicas de programación en diversas plataformas operativas. Puede copiar, modificar y distribuir estos programas de ejemplo de cualquier forma, sin pagar a IBM, por motivos de desarrollo, uso, marketing o distribución de programas de aplicación conforme a la interfaz de programación de aplicaciones para la plataforma operativa para la que están escritos los programas de ejemplo. Estos ejemplos no se han probado bajo todas las condiciones posibles. IBM, por lo tanto, no puede garantizar o implicar la fiabilidad, adecuación a un servicio o funcionalidad de estos programas.

Cada copia o cada parte de los programas de ejemplo o de los trabajos que se deriven de ellos debe incluir un aviso de copyright como se indica a continuación:

© (el nombre de su empresa) (año). Algunas partes de este código se derivan de programas de ejemplo de IBM Corp. © Copyright IBM Corp. _especifique el año o los años_. Reservados todos los derechos.

Si está viendo esta información en copia software, es posible que las fotografías y las ilustraciones en color no aparezcan.

Información de interfaces de programación

La información de las interfaces de programación, si se proporciona, está destinada a ayudarle a crear software de aplicaciones mediante este programa.

Las interfaces de programación de uso general le permiten escribir software de aplicaciones que obtengan los servicios de las herramientas de este programa.

Sin embargo, aquí también puede haber información de diagnóstico, modificación y ajuste. La información de diagnóstico, modificación y ajuste que se proporciona está destinada a ayudarle a depurar el software de las aplicaciones.

Aviso: no utilice la información de diagnóstico, modificación y ajuste como interfaz de programación porque está sujeta a cambios.

Marcas registradas y marcas de servicio

IBM, el logotipo de IBM e ibm.com son marcas registradas de International Business Machines Corporation en los Estados Unidos de América y/o en otros países. Si estos y otros términos de marcas registradas de IBM se marcan la primera vez que aparecen en esta información con un símbolo de marca registrada (® o ™), estos símbolos indican marcas registradas por derecho o registradas en los EE.UU. propiedad de IBM en el momento de publicar esta documentación. Tales marcas registradas también pueden ser marcas registradas por derecho o marcas registradas en otros países. Encontrará una lista actual de marcas registradas de IBM en el sitio web "Copyright and trademark information", en www.ibm.com/legal/copytrade.shtml.

Adobe, el logotipo de Adobe, PostScript y el logotipo de PostScript son marcas registradas de Adobe Systems Incorporated en los Estados Unidos de América y/o en otros países.

Java y todas las marcas registradas y logotipos basados en Java son marcas registradas de Sun Microsystems, Inc. en los Estados Unidos y/o en otros países.

Linux es una marca registrada de Linus Torvalds en Estados Unidos de América y/o en otros países.

Microsoft, Windows, Windows NT y el logotipo de Windows son marcas registradas de Microsoft Corporation en los Estados Unidos de América y/o en otros países.

Intel, el logotipo de Intel, Intel Inside, el logotipo de Intel Inside, Intel Centrino, el logotipo de Intel Centrino, Celeron, Intel Xeon, Intel SpeedStep, Itanium y Pentium son marcas registradas de Intel Corporation o de sus empresas subsidiarias en los Estados Unidos de América y/o en otros países.

UNIX es una marca registrada de The Open Group en los Estados Unidos de América y/o en otros países.

Otros nombres de empresas, productos o servicios pueden ser marcas registradas o marcas de servicio de otros.

Términos de uso

Los permisos para el uso de publicaciones se otorgan sujetos a los términos y condiciones siguientes.

Uso personal: puede reproducir estas publicaciones para su uso personal, no comercial, y sólo si se conservan todos los avisos de propiedad. No puede distribuir, mostrar o realizar trabajos derivados de estas publicaciones, ni de ninguna parte de las mismas, sin el consentimiento expreso de IBM.

Uso comercial: Puede reproducir, distribuir y mostrar estas publicaciones únicamente dentro de su empresa, y sólo si se conservan todos los avisos de propiedad. No puede reproducir, distribuir o realizar trabajos derivados de estas publicaciones ni de ninguna parte de las mismas fuera de la empresa, sin el consentimiento expreso de IBM.

Salvo los permisos que aquí se proporcionan de forma expresa, no se otorgan otros permisos, licencias o derechos, ni implícitos ni explícitos, sobre las publicaciones, ni información, datos, software u otra propiedad intelectual en ellas contenida.

IBM se reserva el derecho de retirar los permisos aquí concedidos, siempre que, bajo su criterio, el uso de las publicaciones vaya en detrimento del propio interés de IBM o las instrucciones anteriores no se sigan adecudamente.

No podrá descargar, exportar o re-exportar esta información salvo que cumpla plenamente con todas las leyes y normas aplicables, incluyendo las leyes y normas de exportación de Estados Unidos.

IBM NO GARANTIZA EL CONTENIDO DE ESTAS PUBLICACIONES. LA PUBLICACIÓN SE PROPORCIONA "TAL CUAL", SIN GARANTÍA DE NINGUNA CLASE, YA SEA EXPLÍCITA O IMPLÍCITA, INCLUIDAS, PERO SIN LIMITARSE A ELLAS, LAS GARANTÍAS IMPLÍCITAS DE COMERCIALIZACIÓN O IDONEIDAD PARA UN PROPÓSITO DETERMINADO.

© Copyright IBM Corporation 2005, 2008. Reservados todos los derechos.




Comentarios

(C) Copyright IBM Corporation 2005, 2009. Reservados todos los derechos.
Este Information Center está basado en tecnología Eclipse. (http://www.eclipse.org)