IBM WebSphere WebSphere Integration Developer
Versión 6.1
Guía de migración
Version 6 Release 1
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 1, de WebSphere Integration Developer.
Copyright International Business Machines Corporation 2005, 2007. Reservados todos los derechos.
Capítulo 1. Migrar a
WebSphere
Integration Developer
WebSphere
Integration Developer Versión 6.1 proporciona las herramientas necesarias para migrar el
entorno actual.
Nota: Los proyectos de WebSphere
Integration Developer 6.0.2 y 6.1 no se pueden utilizar en
WebSphere Integration Developer 6.0.1.
Una vez que actualice a WebSphere
Integration Developer 6.0.2 ó 6.1, no podrá devolver los proyectos a WebSphere Integration Developer 6.0.1.x.
Tampoco hay soporte disponible para un usuario de 6.0.2 ó 6.1 que incorpora su código en un
repositorio o exporta proyectos y luego los comparte con un usuario de
WebSphere
Integration Developer 6.0.1.
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
Hay soporte para la migración desde versiones anteriores de WebSphere Integration Developer a WebSphere Integration Developer 6.1. Ésto se conoce como
migración versión-a-versión.
La migración a WebSphere Integration Developer 6.1 conserva la estructura básica de su 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 V6.1, 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 6.0.2 no se pueden crear nuevamente, pero se pueden utilizar en
WebSphere Integration
Developer 6.1, si ya estaban creados.
- Editor de definición de evento
- Este editor está en desuso en
WebSphere Integration Developer 6.1.
- Federación XSD
- La federación XSD (esto es, generación de xsd-includes) se ha eliminado en WebSphere Integration
Developer 6.1. Así, los PI antiguos deben tener los xsd-includes necesarios
ya incluidos en el PI. Esto sucede automáticamente para los PI exportados en
WebSphere Integration
Developer 6.0.2.x. No obstante, para exportar PI desde 6.0.1.2, debe habilitar
explícitamente el recuadro de selección Incluir archivos derivados
cuando realice la exportación.
- Primitivos de transformación XSL
- En WebSphere Integration
Developer 6.1, el primitivo de Transformación XSL tiene un editor de correlación nuevo.
Las correlaciones XML que se construyeron en una versión anterior se deben migrar
al formato nuevo para poder editarlas. Para obtener más información,
consulte el tema "Migración de un primitivo de transformación XSL" en la
sección de enlace más abajo.
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.1 y WebSphere Integration
Developer 6.1 son compatibles con releases anteriores según se indica:
Nota: Para sistemas i5/OS, no hay versiones previas instaladas.
- El desarrollo desde WebSphere Integration Developer 6.0.x.x (donde
6.0.x.x hace referencia a 6.0.1.x o 6.0.2.x) a WebSphere Process
Server 6.1 tiene soporte.
- Las aplicaciones creadas y generadas utilizando WebSphere Integration Developer 6.0.x.x se pueden publicar en servidores de
WebSphere Process Server 6.1.
- Las aplicaciones creadas, generadas y exportadas desde WebSphere Integration Developer 6.0.x.x se pueden instalar en servidores de
WebSphere Process Server 6.1.
- La ejecución de artefactos de WebSphere Process Server 6.1 en WebSphere Process Server 6.0.x.x no tiene soporte.
- Las aplicaciones creadas con
WebSphere Integration Developer 6.1
no se pueden publicar o instalar en servidores WebSphere Process Server 6.0.x.x (cualquier versión anterior). Dicho contenido no se ejecutará correctamente en
WebSphere Process
Server 6.0.x.x, y los cambios en la generación de código harán que
las aplicaciones no se ejecuten correctamente en WebSphere Process Server 6.0.x.x.
- Las aplicaciones creadas con WebSphere Integration Developer 6.0.x.x y generadas con WebSphere Integration Developer 6.1
no se pueden publicar o instalar en servidores WebSphere Process Server 6.0.x.x. Los cambios en la generación de código harán que
las aplicaciones no se ejecuten correctamente en WebSphere Process Server 6.0.x.x.
- Las aplicaciones generadas utilizando serviceDeploy desde un servidor
WebSphere Process Server 6.1 no se pueden instalar en un servidor WebSphere Process Server 6.0.x.x.
Los cambios en la generación de código harán que
las aplicaciones no se ejecuten correctamente en WebSphere Process Server 6.0.x.x.
Capítulo 3. Migrar a
WebSphere
Process Server desde
WebSphere
InterChange Server
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.
- Migración automática de artefactos origen mediante herramientas de migración que
pueden invocarse desde los siguientes elementos:
- Menú Archivo -> Importar -> Integración de negocio de
WebSphere
Integration Developer
- Página de bienvenida de
WebSphere
Integration Developer
- El programa de utilidad de línea de mandatos reposMigrate
- Soporte nativo en el entorno de ejecución de muchas API de WebSphere InterChange Server
- Soporte para la tecnología actual de
WebSphere
Business Integration Adapter, mediante el cual los adaptadores existentes serán
compatibles con
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 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:
- Soporte de grupos
- Despliegue en caliente/actualización dinámica
- Planificador - Operación en pausa
- Seguridad - Auditoría
- Seguridad - RBAC de grano fino
- Los descriptores de seguridad no se migran
Vías de migración soportadas para
WebSphere
InterChange Server
Las herramientas de migración de WebSphere Process
Server tienen soporte para la migración desde versiones de WebSphere InterChange Server versiones
4.2.2 o posteriores.
Las versiones de
WebSphere
InterChange Server anteriores a la 4.2.2 deberán migrarse a la versión 4.2.2 ó 4.3
antes de efectuar la migración a
WebSphere
Process Server.
Antes de migrar a
WebSphere
Process Server desde
WebSphere
InterChange Server, primero debe asegurarse de que ha preparado correctamente el entorno. WebSphere
Process Server ofrece las herramientas necesarias para migrar desde
WebSphere
InterChange Server.
Estas herramientas de migración se pueden invocar desde los elementos siguientes:
- Menú Archivo -> Importar -> Integración de negocio de
WebSphere
Integration Developer
- Página de bienvenida de
WebSphere
Integration Developer
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:
- 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".
- 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).
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:
- Documentar el diseño del sistema y los componentes
- Utilizar las herramientas de desarrollo para editar los artefactos de integración
- Aprovechar las sugerencias de definición de normas con las herramientas y
fragmentos de código Java
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.
- Utilice el editor de actividades.
- Utilice adaptadores para acceder a EIS.
- Evite dependencias externas en el fragmento de código Java.
- Respete los procedimientos de desarrollo de J2EE con respecto a la portabilidad.
- No genere hebras ni utilice primitivos de sincronización de hebras. Si necesita hacerlo,
deberá reconvertirlas para utilizar beans asíncronos al realizar la migración.
- No realice operaciones de E/S de disco mediante java.io.* Utilice JDBC para
almacenar los datos.
- No ejecute funciones que puedan estar reservadas para un contenedor EJB, como por
ejemplo E/S de socket, carga de clases, carga de bibliotecas nativas, etc. Si debe
hacerlo, estos fragmentos de código necesitarán conversión manual para utilizar funciones
de contenedor EJB al realizar la migración.
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 podría querer 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 Editor 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. Para las operaciones que desee reutilizar en las
herramientas, utilice la característica "Mis colecciones" del Editor de actividades
siempre que sea posible.
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
Es aconsejable 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. Cuando sea necesario reutilizar código en los artefactos de integración, es
aconsejable utilizar la característica "Mis colecciones" de la herramienta Editor de
actividades. 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 funcionar 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. No obstante,
la forma en que se gestionan las conexiones y transacciones podría ser distinta entre
WebSphere InterChange
Server y WebSphere Process
Server, evitando mantener transacciones de base de datos activas en fragmentos de código
de 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 utilice sólo las herramientas suministradas para
configurar artefactos, utilice tipos y longitudes de datos explícitos para los atributos
de datos y utilice sólo las API documentadas.
Los objetos de negocio de WebSphere Process
Server se basan en SDO (Service Data Objects). Los SDO
utilizan 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 los usuarios especifican a veces
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.
Dado 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, por
ejemplo, 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 y/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 el uso de variables estáticas. 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 por omisión: "Object myObject = null;", por ejemplo. 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 Editor 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 lugar de ello, cámbielo por "xml version=1.0 encoding=UTF-8"
antes de la migración.
Para minimizar la cantidad de trabajo manual que puede requerirse en la migración,
utilice sólo las API documentadas en las correlaciones. Evite el uso de variables estáticas. 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, recuerde que, 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.
En relaciones, 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.
Use sólo la herramienta Diseñador 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.
Utilice sólo las API
publicadas para las relaciones dentro de los artefactos de
integración.
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
Puede evitar que se produzcan colisiones de bases de datos mediante la planificación
para que los eventos tengan lugar con dos segundos de diferencia.
Si una aplicación migrada hace que se produzcan muchos eventos a la vez para componentes
de WebSphere Business
Integration components, 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. 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.
Migrar
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.
Para utilizar el asistente de migración a fin de migrar los artefactos de
WebSphere
InterChange Server, siga estos pasos:
- Invoque el asistente seleccionando Archivo -> Importar -> Integración de negocio -> Archivo JAR de WebSphere
InterChange Server y pulse Siguiente:
O también puede abrir el asistente de migración
desde la página de bienvenida pulsando el icono Usuarios de vuelta
para abrir la página Usuarios de vuelta (tenga en cuenta
que siempre puede volver a la página de bienvenida pulsando en Ayuda -> Bienvenida ):
Pulse Migración en la parte izquierda de la página Usuarios de vuelta para abrir
la página Migración. En la página Migración, seleccione la opción
Migrar un repositorio de WebSphere ICS
.
- Se abre el asistente de migración. Especifique el nombre del archivo origen en el
campo Selección de origen pulsando el botón
Examinar y desplazándose hasta el archivo. Especifique el nombre
de la biblioteca en el campo correspondiente. Si la biblioteca compartida no existe actualmente
en el espacio de trabajo, se debe crear pulsando Nueva.... Pulse
Siguiente:
- Se abre la ventana Opciones de migración. Aquí puede aceptar los valores predeterminados
de la migración o marcar un recuadro de selección para cambiar la opción:

La tabla siguiente muestra por encima las opciones de migración
disponibles:
Opción |
Descripción |
Avisar en caso de errores de análisis de Java |
(Opcional)
De forma predeterminada, la migración de un artefacto individual será errónea si se encuentra
un problema de conversión de Java. Si se establece esta opción, todos los problemas de conversión de
Java se tratarán sólo como avisos, y el artefacto se migrará si fuera posible. |
Detener la migración a la primera anomalía |
(Opcional)
De forma predeterminada, si se produjera un error durante el proceso de un artefacto
concreto, el asistente de Migración seguirá el proceso de los artefactos
restantes en el archivo JAR.
Si se establece esta opción, el procesamiento se detendrá tan pronto como se detecte un error.
El artefacto con el error y todos los artefactos subsecuentes no se procesan. |
Utilizar desenmarañamiento de bucle de plantilla de colaboración |
(Opcional)
Solicita que se mantengan todos los bucles presentes en una Plantilla de colaboración.
Si esta opción no está presente, el valor predeterminado para la migración es que utilice
desenmarañamiento de bucle. |
Habilitar secuenciación de eventos |
(Opcional) Solicita que se habilite la secuenciación de eventos para
todos los métodos WSDL asíncronos. Si esta opción no está presente, el valor predeterminado para la migración es no utilizar la secuenciación de eventos en ningún método de WSDL. |
Utilizar plantilla predeterminada |
(Opcional) Solicita que todas las plantillas del
editor de ensamblaje en el directorio especificado se carguen y utilicen
para la conversión de XML a Java. El valor predeterminado para esta propiedad
es que se utilice sólo la Plantilla del editor de ensamblaje estándar v4.3.3 para las
conversiones de XML a Java. |
- Pulse Finalizar.
Una barra de progreso en la parte inferior del diálogo de migración indica
el progreso de la migración. Una vez que éste haya terminado, el diálogo de migración
desaparece y se abre la ventana Resultado de la migración.
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 es correcta. Si la migración no se ha realizado
correctamente, se visualizará una lista de errores, avisos y/o mensajes informativos. Puede emplear estos mensajes para verificar la migración de
WebSphere
InterChange Server.
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.
La página siguiente se visualiza si se han generado mensajes
durante el proceso de 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 y/o pulse el botón Guardar como... para guardar los
mensajes en un archivo de texto del sistema de archivos. 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.
Trabajar con los errores de migración de
WebSphere
InterChange Server
Si se producen anomalías en la migración de
WebSphere
InterChange Server, existen dos métodos para manejar los errores.
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.
- 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.
- 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:
- Los objetos comerciales pasan a ser objetos comerciales de WebSphere Process Server
- Las correlaciones pasan a ser correlaciones de WebSphere Process Server
- Las relaciones pasan a ser relaciones y cometidos de WebSphere Process Server
- Las plantillas de colaboración pasan a ser BPEL y WSDL de WebSphere Process Server
- Los objetos de colaboración pasan a ser módulos de WebSphere Process
Server que contienen enlace de componente SCA para el BPEL de plantilla de colaboración y
todas las conexiones SCA necesarias
- Las definiciones de conector pasan a ser módulos de WebSphere Process
Server que contienen importaciones y exportaciones SCA para permitir la comunicación con Adaptadores heredados, Artefactos administrativos de adaptadores heredados y
todas las conexiones SCA necesarias
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:
- Agrupaciones de conexiones de BD
- Relaciones
- Entradas del planificador
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/
- BiDiBOTransformation(BusinessObject, String, String, boolean):BusinessObj
- BiDiBusObjTransformation(BusObj, String, String, boolean):BusObj
- BiDiStringTransformation(String, String, String):String
JavaConnectorUtil
AppSide_Connector/
- INFRASTRUCTURE_MESSAGE_FILE
- CONNECTOR_MESSAGE_FILE
- XRD_WARNING
- XRD_TRACE
- XRD_INFO
- XRD_ERROR
- XRD_FATAL
- LEVEL1
- LEVEL2
- LEVEL3
- LEVEL4
- LEVEL5
- createBusinessObject(String):BusinesObjectInterface
- createBusinessObject(String, Locale):BusinesObjectInterface
- createBusinessObject(String, String):BusinesObjectInterface
- createContainer(String):CxObjectContainerInterface
- generateMsg(int, int, int, int, int, Vector):String
- generateMsg(int, int, int, int, Vector):String
- getBlankValue():String
- getEncoding():String
- getIgnoreValue():String
- getLocale():String
- getSDOFromString(String inputString, String sdoName, String metaObjectName,
String mimeType)
- getStringFromSDO(DataObject sdo, String metaObjectName, String mimeType)
- isBlankValue(Object):boolean
- isIgnoreValue(Object):boolean
- isTraceEnabled(int):boolean
- logMsg(String)
- logMsg(String, int)
- traceWrite(int, String)
JavaConnectorUtilDH
datahandler/
wbi/
ibm/
com/
- getSDOFromString(String inputString, String sdoName, String metaObjectName,
String mimeType)
- getStringFromSDO(DataObject sdo, String metaObjectName, String mimeType)
BusObj
Collaboration/
- BusObj(DataObject)
- BusObj(String)
- BusObj(String, Locale)
- copy(BusObj)
- duplicate():BusObj
- equalKeys(BusObj):boolean
- equals(Object):boolean
- equalsShallow(BusObj):boolean
- exists(String):boolean
- get(int):Object
- get(String):Object
- getBoolean(String):boolean
- getBusObj(String):BusObj
- getBusObjArray(String):BusObjArray
- getCount(String):int
- getDouble(String):double
- getFloat(String):float
- getInt(String):int
- getKeys():String
- getLocale():java.util.Locale
- getLong(String):long
- getLongText(String):String
- getString(String):String
- getType():String
- getValues():String
- getVerb():String
- isBlank(String):boolean
- isKey(String):boolean
- isNull(String):boolean
- isRequired(String):boolean
- keysToString():String
- set(BusObj)
- set(int, Object)
- set(String, boolean)
- set(String, double)
- set(String, float)
- set(String, int)
- set(String, long)
- set(String, Object)
- set(String, String)
- setContent(BusObj)
- setDefaultAttrValues()
- setKeys(BusObj)
- setLocale(java.util.Locale)
- setVerb(String)
- setVerbWithCreate(String, String)
- setWithCreate(String, boolean)
- setWithCreate(String, BusObj)
- setWithCreate(String, BusObjArray)
- setWithCreate(String, double)
- setWithCreate(String, float)
- setWithCreate(String, int)
- setWithCreate(String, long):
- setWithCreate(String, Object)
- setWithCreate(String, String)
- toString():String
- validData(String, boolean):boolean
- validData(String, BusObj):boolean
- validData(String, BusObjArray):boolean
- validData(String, double):boolean
- validData(String, float):boolean
- validData(String, int):boolean
- validData(String, long):boolean
- validData(String, Object):boolean
- validData(String, String):boolean
BusObjArray
Collaboration/
- addElement(BusObj)
- duplicate():BusObjArray
- elementAt(int):BusObj
- equals(BusObjArray):boolean
- getElements():BusObj[]
- getLastIndex():int
- max(String):String
- maxBusObjArray(String):BusObjArray
- maxBusObjs(String):BusObj[]
- min(String):String
- minBusObjArray(String):BusObjArray
- minBusObjs(String):BusObj[]
- removeAllElements()
- removeElement(BusObj)
- removeElementAt(int)
- setElementAt(int, BusObj)
- size():int
- sum(String):double
- swap(int, int)
- toString():String
BaseDLM
DLM/
- BaseDLM(BaseMap)
- getDBConnection(String):CwDBConnection
- getDBConnection(String, boolean):CwDBConnection
- getName():String
- getRelConnection(String):DtpConnection
- implicitDBTransactionBracketing():boolean
- isTraceEnabled(int):boolean
- logError(int)
- logError(int, Object[])
- logError(int, String)
- logError(int, String, String)
- logError(int, String, String, String)
- logError(int, String, String, String, String)
- logError(int, String, String, String, String, String)
- logError(String)
- logInfo(int)
- logInfo(int, Object[])
- logInfo(int, String)
- logInfo(int, String, String)
- logInfo(int, String, String, String)
- logInfo(int, String, String, String, String)
- logInfo(int, String, String, String, String, String)
- logInfo(String)
- logWarning(int)
- logWarning(int, Object[])
- logWarning(int, String)
- logWarning(int, String, String)
- logWarning(int, String, String, String)
- logWarning(int, String, String, String, String)
- logWarning(int, String, String, String, String, String)
- logWarning(String)
- raiseException(RunTimeEntityException)
- raiseException(String, int)
- raiseException(String, int, Object[])
- raiseException(String, int, String)
- raiseException(String, int, String, String)
- raiseException(String, int, String, String, String)
- raiseException(String, int, String, String, String, String)
- raiseException(String, int, String, String, String, String, String)
- raiseException(String, String)
- releaseRelConnection(boolean)
- trace(int, int)
- trace(int, int, Object[])
- trace(int, int, String)
- trace(int, int, String, String)
- trace(int, int, String, String, String)
- trace(int, int, String, String, String, String)
- trace(int, int, String, String, String, String, String)
- trace(int, String)
- trace(String)
CwDBConnection
CwDBConnection/
CxCommon/
- beginTransaction()
- commit()
- executePreparedSQL(String)
- executePreparedSQL(String, Vector)
- executeSQL(String)
- executeSQL(String, Vector)
- executeStoredProcedure(String, Vector)
- getUpdateCount():int
- hasMoreRows():boolean
- inTransaction():boolean
- isActive():boolean
- nextRow():Vector
- release()
- rollback()
CwDBConstants
CwDBConnection/
CxCommon/
- PARAM_IN - 0
- PARAM_INOUT - 1
- PARAM_OUT - 2
CwDBStoredProcedureParam
CwDBConnection/
CxCommon/
- CwDBStoredProcedureParam(int, Array)
- CwDBStoredProcedureParam(int, BigDecimal)
- CwDBStoredProcedureParam(int, boolean)
- CwDBStoredProcedureParam(int, Boolean)
- CwDBStoredProcedureParam(int, byte[])
- CwDBStoredProcedureParam(int, double)
- CwDBStoredProcedureParam(int, Double)
- CwDBStoredProcedureParam(int, float)
- CwDBStoredProcedureParam(int, Float)
- CwDBStoredProcedureParam(int, int)
- CwDBStoredProcedureParam(int, Integer)
- CwDBStoredProcedureParam(int, java.sql.Blob)
- CwDBStoredProcedureParam(int, java.sql.Clob)
- CwDBStoredProcedureParam(int, java.sql.Date)
- CwDBStoredProcedureParam(int, java.sql.Struct)
- CwDBStoredProcedureParam(int, java.sql.Time)
- CwDBStoredProcedureParam(int, java.sql.Timestamp)
- CwDBStoredProcedureParam(int, Long)
- CwDBStoredProcedureParam(int, String)
- CwDBStoredProcedureParam(int, String, Object)
- getParamType():int getValue():Object
DataHandler (Clase abstracta)
DataHandlers/
crossworlds/
com/
- createHandler(String, String, String):DataHandler
- getBO(InputStream, Object):BusinessObjectInterface
- getBO(Object, BusinessObjectInterface, Object)
- getBO(Object, Object):BusinessObjectInterface
- getBO(Reader, BusinessObjectInterface, Object) (Método abstracto)
- getBO(Reader, Object):BusinessObjectInterface (Método abstracto)
- getBO(String, Object):BusinessObjectInterface
- getBOName(InputStream):String
- getBOName(Reader):String
- getBOName(String):String
- getBooleanOption(String):boolean
- getEncoding():String
- getLocale():Locale
- getOption(String):String
- getStreamFromBO(BusinessObjectInterface, Object):InputStream (Método abstracto)
- getStringFromBO(BusinessObjectInterface, Object):String (Método abstracto)
- setConfigMOName(String)
- setEncoding(String)
- setLocale(Locale)
- setOption(String, String)
- traceWrite(String, int)
NameHandler (Clase abstracta)
DataHandlers/
crossworlds/
com/
- getBOName(Reader, String):String) (Método abstracto)
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/
- clone():Object
- dump():String
- getAppText():String
- getAttrCount():int
- getAttrDesc(int):CxObjectAttr
- getAttrDesc(String):CxObjectAttr
- getAttribute(String):Object
- getAttributeIndex(String):int
- getAttributeType(int):int
- getAttributeType(String):int
- getAttrName(int):String
- getAttrValue(int):Object
- getAttrValue(String):Object
- getBusinessObjectVersion():String
- getDefaultAttrValue(int):String
- getDefaultAttrValue(String):String
- getLocale():String
- getName():String
- getParentBusinessObject():BusinessObjectInterface
- getVerb():String
- getVerbAppText(String):String
- isBlank(int):boolean
- isBlank(String):boolean
- isIgnore(int):boolean
- isIgnore(String):boolean
- isVerbSupported(String):boolean
- makeNewAttrObject(int):Object
- makeNewAttrObject(String):Object
- setAttributeWithCreate(String, Object)
- setAttrValue(int, Object)
- setAttrValue(String, Object)
- setDefaultAttrValues()
- setLocale(Locale)
- setLocale(String)
- setVerb(String)
CxObjectAttr
CxCommon/
- BOOLEAN
- BOOLSTRING
- DATE
- DATESTRING
- DOUBLE
- DOUBSTRING
- FLOAT
- FLTSTRING
- INTEGER
- INTSTRING
- INVALID_TYPE_NUM
- INVALID_TYPE_STRING
- LONGTEXT
- LONGTEXTSTRING
- MULTIPLECARDSTRING
- OBJECT
- SINGLECARDSTRING
- STRING
- STRSTRING
- equals(Object):boolean
- getAppText():String
- getCardinality():String
- getDefault():String
- getMaxLength():int
- getName():String
- getRelationType():String
- getTypeName():String
- getTypeNum():String
- hasCardinality(String):boolean
- hasName(String):boolean
- hasType(String):boolean
- isForeignKeyAttr():boolean
- isKeyAttr():boolean
- isMultipleCard():boolean
- isObjectType():boolean
- isRequiredAttr():boolean
- isType(Object):boolean
CxObjectContainerInterface
CxCommon/
- getBusinessObject(int):BusinessObjectInterface
- getObjectCount():int
- insertBusinessObject(BusinessObjectInterface)
- removeAllObjects()
- removeBusinessObjectAt(int)
- setBusinessObject(int, BusinessObjectInterface)
DtpConnection
Dtp/
CxCommon/
- beginTran()
- commit()
- executeSQL(String)
- executeSQL(String, Vector)
- executeStoredProcedure(String, Vector)
- getUpdateCount():int
- hasMoreRows():boolean
- inTransaction():boolean
- isActive():boolean
- nextRow():Vector
- rollback()
DtpDataConversion
Dtp/
CxCommon/
- BOOL_TYPE - 4
- CANNOTCONVERT - 2
- DATE_TYPE - 5
- DOUBLE_TYPE - 3
- FLOAT_TYPE - 2
- INTEGER_TYPE - 0
- LONGTEXT_TYPE - 6
- OKTOCONVERT - 0
- POTENTIALDATALOSS - 1
- STRING_TYPE - 1
- UNKNOWN_TYPE - 999
- getType(double):int
- getType(float):int
- getType(int):int
- getType(Object):int
- isOKToConvert(int, int):int
- isOKToConvert(String, String):int
- toBoolean(boolean):Boolean
- toBoolean(Object):Boolean
- toDouble(double):Double
- toDouble(float):Double
- toDouble(int):Double
- toDouble(Object):Double
- toFloat(double):Float
- toFloat(float):Float
- toFloat(int):Float
- toFloat(Object):Float
- toInteger(double):Integer
- toInteger(float):Integer
- toInteger(int):Integer
- toInteger(Object):Integer
- toPrimitiveBoolean(Object):boolean
- toPrimitiveDouble(float):double
- toPrimitiveDouble(int):double
- toPrimitiveDouble(Object):double
- toPrimitiveFloat(double):float
- toPrimitiveFloat(int):float
- toPrimitiveFloat(Object):float
- toPrimitiveInt(double):int
- toPrimitiveInt(float):int
- toPrimitiveInt(Object):int
- toString(double):String
- toString(float):String
- toString(int):String
- toString(Object):String
DtpDate
Dtp/
CxCommon/
- DtpDate()
- DtpDate(long, boolean)
- DtpDate(String, String)
- DtpDate(String, String, String[], String[])
- addDays(int):DtpDate
- addMonths(int):DtpDate
- addWeekdays(int):DtpDate
- addYears(int):DtpDate
- after(DtpDate):boolean
- before(DtpDate):boolean
- calcDays(DtpDate):int
- calcWeekdays(DtpDate):int
- get12MonthNames():String[]
- get12ShortMonthNames():String[]
- get7DayNames():String[]
- getCWDate():String
- getDayOfMonth():String
- getDayOfWeek():String
- getHours():String
- getIntDay():int
- getIntDayOfWeek():int
- getIntHours():int
- getIntMilliSeconds():int
- getIntMinutes():int
- getIntMonth():int
- getIntSeconds():int
- getIntYear():int
- getMaxDate(BusObjArray, String, String):DtpDate
- getMaxDateBO(BusObj[], String, String):BusObj[]
- getMaxDateBO(BusObjArray, String, String):BusObj[]
- getMinDate(BusObjArray, String, String):DtpDate
- getMinDateBO(BusObj[], String, String):BusObj[]
- getMinDateBO(BusObjArray, String, String):BusObj[]
- getMinutes():String
- getMonth():String
- getMSSince1970():long
- getNumericMonth():String
- getSeconds():String
- getShortMonth():String
- getYear():String
- set12MonthNames(String[], boolean)
- set12MonthNamesToDefault()
- set12ShortMonthNames(String[])
- set12ShortMonthNamesToDefault()
- set7DayNames(String[])
- set7DayNamesToDefault()
- toString():String
- toString(String):String
- toString(String, boolean):String
DtpMapService
Dtp/
CxCommon/
- runMap(String, String, BusObj[], CxExecutionContext):BusObj[]
DtpSplitString
Dtp/
CxCommon/
- DtpSplitString(String, String)
- elementAt(int):String
- firstElement():String
- getElementCount():int
- getEnumeration():Enumeration
- lastElement():String
- nextElement():String
- prevElement():String
- reset()
DtpUtils
Dtp/
CxCommon/
- padLeft(String, char, int):String
- padRight(String, char, int):String
- stringReplace(String, String, String):String
- truncate(double):int
- truncate(double, int):double
- truncate(float):int
- truncate(float, int):double
- truncate(Object):int
- truncate(Object, int):double
BusObjInvalidVerbException (amplía InterchangeExceptions)
Exceptions/
CxCommon/
IdentityRelationship
relationship/
utilities/
crossworlds/
com/
- addMyChildren(String, String, BusObj, String, Object, CxExecutionContext)
- deleteMyChildren(String, String, BusObj, String, CxExecutionContext)
- deleteMyChildren(String, String, BusObj, String, Object, CxExecutionContext)
- foreignKeyLookup(String, String, BusObj, String, BusObj, String, CxExecutionContext)
- foreignKeyXref(String, String, String, BusObj, String, BusObj, String,
CxExecutionContext)
- maintainChildVerb(String, String, String, BusObj, String, BusObj, String,
CxExecutionContext, boolean, boolean)
- maintainCompositeRelationship(String, String, BusObj, Object, CxExecutionContext)
- maintainSimpleIdentityRelationship(String, String, BusObj, BusObj, CxExecutionContext)
- updateMyChildren(String, String, BusObj, String, String, String, String,
CxExecutionContext)
MapExeContext
Dtp/
CxCommon/
- ACCESS_REQUEST - "SUBSCRIPTION_DELIVERY"
- ACCESS_RESPONSE - "ACCESS_RETURN_REQUEST"
- EVENT_DELIVERY - "SUBSCRIPTION_DELIVERY"
- SERVICE_CALL_FAILURE - "CONSUME_FAILED"
- SERVICE_CALL_REQUEST - "CONSUME"
- SERVICE_CALL_RESPONSE - "DELIVERBUSOBJ"
- getConnName():String
- getGenericBO():BusObj
- getInitiator():String
- getLocale():java.util.Locale
- getOriginalRequestBO():BusObj
- setConnName(String)
- setInitiator(String)
- setLocale(java.util.Locale)
Participant
RelationshipServices/
Server/
- Participant(String, String, int, BusObj)
- Participant(String, String, int, String)
- Participant(String, String, int, long)
- Participant(String, String, int, int)
- Participant(String, String, int, double)
- Participant(String, String, int, float)
- Participant(String, String, int, boolean)
- Participant(String, String, BusObj)
- Participant(String, String, String)
- Participant(String, String, long)
- Participant(String, String, int)
- Participant(String, String, double)
- Participant(String, String, float)
- Participant(String, String, boolean)
- getBoolean():boolean
- getBusObj():BusObj
- getDouble():double
- getFloat():float
- getInstanceId():int
- getInt():int
- getLong():long
- getParticipantDefinition():String
- getRelationshipDefinition():String
- getString():String INVALID_INSTANCE_ID
- set(boolean)
- set(BusObj)
- set(double)
- set(float)
- set(int)
- set(long)
- set(String)
- setInstanceId(int)
- setParticipantDefinition(String)
- setRelationshipDefinition(String)
- setParticipantDefinition(String)
- setRelationshipDefinition(String)
Relationship
RelationshipServices/
Server/
- addMyChildren(String, String, BusObj, String, Object, CxExecutionContext)
- addParticipant(Participant):int
- addParticipant(String, String, boolean):int
- addParticipant(String, String, BusObj):int
- addParticipant(String, String, double):int
- addParticipant(String, String, float):int
- addParticipant(String, String, int):int
- addParticipant(String, String, int, boolean):int
- addParticipant(String, String, int, BusObj):int
- addParticipant(String, String, int, double):int
- addParticipant(String, String, int, float):int
- addParticipant(String, String, int, int):int
- addParticipant(String, String, int, long):int
- addParticipant(String, String, int, String):int
- addParticipant(String, String, long):int
- addParticipant(String, String, String):int
- create(Participant):int
- create(String, String, boolean):int
- create(String, String, BusObj):int
- create(String, String, double):int
- create(String, String, float):int
- create(String, String, int):int
- create(String, String, long):int
- create(String, String, String):int
- deactivateParticipant(Participant)
- deactivateParticipant(String, String, boolean)
- deactivateParticipant(String, String, BusObj)
- deactivateParticipant(String, String, double)
- deactivateParticipant(String, String, float)
- deactivateParticipant(String, String, int)
- deactivateParticipant(String, String, long)
- deactivateParticipant(String, String, String)
- deactivateParticipantByInstance(String, String, int)
- deactivateParticipantByInstance(String, String, int, boolean)
- deactivateParticipantByInstance(String, String, int, BusObj)
- deactivateParticipantByInstance(String, String, int, double)
- deactivateParticipantByInstance(String, String, int, float)
- deactivateParticipantByInstance(String, String, int, int)
- deactivateParticipantByInstance(String, String, int, long)
- deactivateParticipantByInstance(String, String, int, String)
- deleteMyChildren(String, String, BusObj, String, CxExecutionContext)
- deleteMyChildren(String, String, BusObj, String, Object, CxExecutionContext)
- deleteParticipant(Participant)
- deleteParticipant(String, String, boolean)
- deleteParticipant(String, String, BusObj)
- deleteParticipant(String, String, double)
- deleteParticipant(String, String, float)
- deleteParticipant(String, String, int)
- deleteParticipant(String, String, long)
- deleteParticipant(String, String, String)
- deleteParticipantByInstance(String, String, int)
- deleteParticipantByInstance(String, String, int, boolean)
- deleteParticipantByInstance(String, String, int, BusObj)
- deleteParticipantByInstance(String, String, int, double)
- deleteParticipantByInstance(String, String, int, float)
- deleteParticipantByInstance(String, String, int, int)
- deleteParticipantByInstance(String, String, int, long)
- deleteParticipantByInstance(String, String, int, String)
- getNewID(String):int
- maintainCompositeRelationship(String, String, BusObj, Object, CxExecutionContext)
- maintainSimpleIdentityRelationship(String, String, BusObj, BusObj, CxExecutionContext)
- retrieveInstances(String, boolean):int[]
- retrieveInstances(String, BusObj):int[]
- retrieveInstances(String, double):int[]
- retrieveInstances(String, float):int[]
- retrieveInstances(String, int):int[]
- retrieveInstances(String, long):int[]
- retrieveInstances(String, String):int[]
- retrieveInstances(String, String, boolean):int[]
- retrieveInstances(String, String, BusObj):int[]
- retrieveInstances(String, String, double):int[]
- retrieveInstances(String, String, float):int[]
- retrieveInstances(String, String, int):int[]
- retrieveInstances(String, String, long):int[]
- retrieveInstances(String, String, String):int[]
- retrieveInstances(String, String[], boolean):int[]
- retrieveInstances(String, String[], BusObj):int[]
- retrieveInstances(String, String[], double):int[]
- retrieveInstances(String, String[], float):int[]
- retrieveInstances(String, String[], int):int[]
- retrieveInstances(String, String[], long):int[]
- retrieveInstances(String, String[], String):int[]
- retrieveParticipants(String):Participant[]
- retrieveParticipants(String, String):Participant[]
- retrieveParticipants(String, String[]):Participant[]
- retrieveParticipants(String, int):Participant[]
- retrieveParticipants(String, String, int):Participant[]
- retrieveParticipants(String, String[], int):Participant[]
- updateMyChildren(String, String, BusObj, String, String, String, String,
CxExecutionContext)
- updateParticipant(String, String, BusObj)
- updateParticipantByInstance(Participant)
- updateParticipantByInstance(String, String, int)
- updateParticipantByInstance(String, String, int, BusObj)
UserStoredProcedureParam
Dtp/
CxCommon/
- UserStoredProcedureParam(int, String, Object, String, String)
- getParamDataTypeJavaObj():String
- getParamDataTypeJDBC():int
- getParamIndex():int
- getParamIOType():String
- getParamName():String
- getParamValue():Object
- setParamDataTypeJavaObj(String)
- setParamDataTypeJDBC(int)
- setParamIndex(int)
- setParamIOType(String)
- setParamName(String)
- setParamValue(Object)
- PARAM_TYPE_IN - "IN"
- PARAM_TYPE_OUT - "OUT"
- PARAM_TYPE_INOUT - "INOUT"
- DATA_TYPE_STRING - "String"
- DATA_TYPE_INTEGER - "Integer"
- DATA_TYPE_DOUBLE - "Double"
- DATA_TYPE_FLOAT - "Float"
- DATA_TYPE_BOOLEAN - "Boolean"
- DATA_TYPE_TIME - "java.sql.Time"
- DATA_TYPE_DATE - "java.sql.Date"
- DATA_TYPE_TIMESTAMP - "java.sql.Timestamp"
- DATA_TYPE_BIG_DECIMAL - "java.math.BigDecimal"
- DATA_TYPE_LONG_INTEGER - "Long"
- DATA_TYPE_BINARY - "byte[]"
- DATA_TYPE_CLOB - "Clob"
- DATA_TYPE_BLOB - "Blob"
- DATA_TYPE_ARRAY - "Array"
- DATA_TYPE_STRUCT - "Struct"
- DATA_TYPE_REF - "Ref"
BaseCollaboration
Collaboration/
- BaseCollaboration(com.ibm.bpe.api.ProcessInstanceData)
- AnyException - "AnyException"
- AppBusObjDoesNotExist - "BusObjDoesNotExist"
- AppLogOnFailure - "AppLogOnFailure"
- AppMultipleHits - "AppMultipleHits"
- AppRequestNotYetSent - "AppRequestNotYetSent"
- AppRetrieveByContentFailed - "AppRetrieveByContent"
- AppTimeOut - "AppTimeOut"
- AppUnknown - "AppUnknown"
- AttributeException - "AttributeException"
- existsConfigProperty(String):boolean
- getConfigProperty(String):String
- getConfigPropertyArray(String):String[]
- getCurrentLoopIndex():int
- getDBConnection(String):CwDBConnection
- getDBConnection(String, boolean):CwDBConnection getLocale():java.util.Locale
- getMessage(int):String
- getMessage(int, Object[]):String
- getName():String
- implicitDBTransactionBracketing():boolean
- isCallerInRole(String):boolean
- isTraceEnabled(int):boolean
- JavaException - "JavaException"
- logError(int)
- logError(int, Object[])
- logError(int, String)
- logError(int, String, String)
- logError(int, String, String, String)
- logError(int, String, String, String, String)
- logError(int, String, String, String, String, String)
- logError(String)
- logInfo(int)
- logInfo(int, Object[])
- logInfo(int, String)
- logInfo(int, String, String)
- logInfo(int, String, String, String)
- logInfo(int, String, String, String, String)
- logInfo(int, String, String, String, String, String)
- logInfo(String)
- logWarning(int)
- logWarning(int, Object[])
- logWarning(int, String)
- logWarning(int, String, String)
- logWarning(int, String, String, String)
- logWarning(int, String, String, String, String)
- logWarning(int, String, String, String, String, String)
- logWarning(String)
- not(boolean):boolean ObjectException - "ObjectException"
- OperationException - "OperationException"
- raiseException(CollaborationException)
- raiseException(String, int)
- raiseException(String, int, Object[])
- raiseException(String, int, String)
- raiseException(String, int, String, String)
- raiseException(String, int, String, String, String)
- raiseException(String, int, String, String, String, String)
- raiseException(String, int, String, String, String, String, String)
- raiseException(String, String)
- ServiceCallException - "ConsumerException"
- ServiceCallTransportException - "ServiceCallTransportException"
- SystemException - "SystemException"
- trace(int, int)
- trace(int, int, Object[])
- trace(int, int, String)
- trace(int, int, String, String)
- trace(int, int, String, String, String)
- trace(int, int, String, String, String, String)
- trace(int, int, String, String, String, String, String)
- trace(int, String)
- trace(String)
- TransactionException - "TransactionException"
CxExecutionContext
CxCommon/
- CxExecutionContext()
- getContext(String):Object
- MAPCONTEXT - "MAPCONTEXT"
- setContext(String, Object)
CollaborationException
Collaboration/
- getMessage():String
- getMsgNumber():int
- getSubType():String
- getText():String
- getType():String
- toString():String
Filter
crossworlds/
com/
- Filter(BaseCollaboration)
- filterExcludes(String, String):boolean
- filterIncludes(String, String):boolean
- recurseFilter(BusObj, String, boolean, String, String):boolean
- recursePreReqs(String, Vector):int
Globals
crossworlds/
com/
- Globals(BaseCollaboration)
- callMap(String, BusObj):BusObj
SmartCollabService
crossworlds/
com/
- SmartCollabService()
- SmartCollabService(BaseCollaboration)
- doAgg(BusObj, String, String, String):BusObj
- doMergeHash(Vector, String, String):Vector
- doRecursiveAgg(BusObj, String, String, String):BusObj
- doRecursiveSplit(BusObj, String):Vector
- doRecursiveSplit(BusObj, String, boolean):Vector
- getKeyValues(BusObj, String):String
- merge(Vector, String):BusObj
- merge(Vector, String, BusObj):BusObj
- split(BusObj, String):Vector
StateManagement
crossworlds/
com/
- StateManagement()
- beginTransaction()
- commit()
- deleteBO(String, String, String)
- deleteState(String, String, String, int)
- persistBO(String, String, String, String, BusObj)
- recoverBO(String, String, String):BusObj
- releaseDBConnection()
- resetData()
- retrieveState(String, String, String, int):int
- saveState(String, String, String, String, int, int, double)
- setDBConnection(CwDBConnection)
- updateBO(String, String, String, String, BusObj)
- updateState(String, String, String, String, int, int)
EventKeyAttrDef
EventManagement/
CxCommon/
- EventKeyAttrDef()
- EventKeyAttrDef(String, String)
- public String keyName
- public String keyValue
EventQueryDef
EventManagement/
CxCommon/
- EventQueryDef()
- EventQueryDef(String, String, String, String, int)
- public String nameConnector
- public String nameCollaboration
- public String nameBusObj
- public String verb
- public int ownerType
FailedEventInfo
EventManagement/
CxCommon/
- FailedEventInfo()
- FailedEventInfo(String x6, int, EventKeyAttrDef[], int, int, String, String,
int)
- public String nameOwner
- public String nameConnector
- public String nameBusObj
- public String nameVerb
- public String strTime
- public String strMessage
- public int wipIndex
- public EventKeyAttrDef[] strbusObjKeys
- public int nKeys
- public int eventStatus
- public String expirationTime
- public String scenarioName
- public int scenarioState
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
- Para establecer el verbo de ChangeSummary, todos los valores se establecerán con las
API markCreate/Update/Delete.
- Para establecer el verbo de ChangeSummary/EventSummary,
los verbos Create, Update y Delete se establecerán en ChangeSummary,
mientras que todos los demás verbos se establecerán en EventSummary.
- Para obtener el verbo de ChangeSummary:
- Para evitar que un DataObject se identifique como Create
en lugar de un Update esperado, si la anotación está habilitada, debe:
- Suspender la anotación durante la creación del DataObject.
- Reanudar la anotación para la actualización (update) del DataObject (o utilizar la
API markUpdated).
Carga
La carga cargará un XML de tiempo de ejecución
de WebSphere InterChange
Server en una instancia de WebSphere Business Integration BusinessGraph AfterImage.
- Se creará una instancia del BusinessGraph adecuado.
- Se activará la anotación de ChangeSummary, a fin de que su activación posterior no
borre las entradas.
- La anotación de ChangeSummary quedará en pausa para evitar que entre información no
deseada en ChangeSummary.
- Los atributos del BusinessObject de nivel superior se crearán en el DataObject
(consulte la sección "Proceso de atributos" que figura más adelante).
- Si el BusinessObject de nivel superior tiene BusinessObjects hijos, estos se
procesarán recursivamente.
- Los atributos de estos BusinessObjects hijos se crearán en el
DataObject
(consulte la sección "Proceso de atributos" que figura más adelante).
- El verbo del BusinessObject de nivel superior se establecerá en el verbo de
nivel superior del BusinessGraph y se establecerá en los resúmenes.
- El verbo de los BusinessObjects hijos se establecerá en los resúmenes.
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
- Todos los valores no indicados a continuación serán ASIS cargados/guardados.
- ObjectEventId se cargará en/guardará desde EventSummary.
- Para CxBlank y CxIgnore:
- En el lado del BusinessObject de WebSphere Business
Integration de la conversión, CxBlank y CxIgnore se establecerán/identificarán del
siguiente modo:
- CxIgnore - desestablecer o establecer con el valor Java null
- CxBlank - valor dependiente del tipo, como se muestra en la tabla que figura
más adelante
- En el lado del XML de
WebSphere
InterChange Server de la conversión, CxBlank y CxIgnore se
establecerán/identificarán del siguiente modo:
Tabla 1. Establecer CxBlank y CxIgnore
Tipo |
CxIgnore |
CxBlank |
Int |
Integer.MIN_VALUE |
Integer.MAX_VALUE |
Float |
Float.MIN_VALUE |
Float.MAX_VALUE |
Double |
Double.MIN_VALUE |
Double.MAX_VALUE |
String/date/longtext |
"CxIgnore" |
"" |
BusinessObjects hijos |
(elemento vacío) |
N/A |
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.
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.
La herramienta de conversión requiere una
definición FDL semánticamente completa de un modelo de proceso exportado desde
en
entorno
de
construcción WebSphere
MQ Workflow con la opción export deep. 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:
- Instancias de tiempo de ejecución de
WebSphere
MQ Workflow
- Aplicaciones de programa invocadas por un agente de ejecución de programas (PEA) de
WebSphere
MQ Workflow o un servidor de ejecución de programas (PES para
z/OS) de
WebSphere
MQ Workflow
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.
Antes de migrar a
WebSphere
Integration Developer desde
WebSphere
MQ Workflow, primero debe asegurarse de que ha preparado correctamente el entorno.
El ámbito y la integridad de la correlación dependerán del seguimiento de
las siguientes directrices sobre migración:
- Compruebe que las actividades de programa FDL están asociadas a un servidor de
ejecución de programas definido por el usuario (UPES) si no son actividades de
personal puras.
- Asegúrese de que las asignaciones de personal de las actividades de programa de
WebSphere
MQ Workflow se ajusten a los verbos de
personal predeterminados de TEL.
- Utilice nombres cortos y sencillos para facilitar la lectura de los modelos de procesos
migrados. Tenga presente que los nombres FDL pueden ser nombres BPEL no permitidos. El
asistente de migración convierte automáticamente los nombres FDL en nombres
BPEL válidos.
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.
Nota: El asistente de migración no cubre la migración de los elementos
siguientes:
- Instancias de tiempo de ejecución de
WebSphere
MQ Workflow
- Aplicaciones de programa invocadas por un agente de ejecución de programas (PEA) de
WebSphere
MQ Workflow o un servidor de ejecución de programas (PES para
z/OS) de
WebSphere
MQ Workflow
Para utilizar el asistente de migración a fin de
migrar los artefactos de
WebSphere
MQ Workflow, siga estos pasos:
- Invoque el asistente seleccionando Archivo -> Importar -> Integración de negocio -> Archivo FDL de WebSphere
MQ Workflow y pulse Siguiente:
O también puede abrir el asistente de migración
desde la página de bienvenida pulsando el icono Usuarios de vuelta
para abrir la página Usuarios de vuelta (tenga en cuenta
que siempre puede volver a la página de bienvenida pulsando en Ayuda -> Bienvenida ):
Pulse Migración en la parte izquierda de la página Usuarios de vuelta para abrir
la página Migración. En la página Migración, seleccione la opción Migrar un proceso
de WebSphere MQ Workflow
.
- 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. Especifique
el nombre de módulo en el campo adecuado (debe especificar un nombre de módulo en el
campo Nombre de módulo para poder continuar). Pulse
Siguiente:
- Se abre la página Opciones de migración. 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 Inicializar miembros de datos
predefinidos añade nodos adicionales al proceso para inicializar los miembros
de datos predefinidos:
- Pulse Finalizar.
Una barra de progreso en la parte inferior del diálogo de migración indica
el progreso de la migración. Una vez que éste haya terminado, el diálogo de migración
desaparece y se abre la ventana Resultado de la migración:
Verificar la migración de WebSphere MQ Workflow
Si la migración finaliza con una lista de errores, avisos y/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.
La página siguiente se visualiza si se han generado mensajes durante el proceso
de 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 y/o pulse el botón Guardar como... para guardar los
mensajes en un archivo de texto del sistema de archivos. 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.
- La migración de FDL generará actividades de invocación para actividades de UPES y los
WSDL correspondientes. Sin embargo, el entorno de ejecución difiere
significativamente entre
IBM
WebSphere
MQ Workflow y
IBM
WebSphere
Process Server en términos de las técnicas utilizadas para correlacionar los mensajes de
invocación y sus respuestas.
- Los motores de entorno de ejecución de
IBM
WebSphere
MQ Workflow e IBM
WebSphere
Process Server manejan los datos no inicializados de forma diferente. Mientras que en
IBM
WebSphere
MQ Workflow esto no provocaba errores,
IBM
WebSphere
Process Server maneja esta situación con una excepción y detiene la ejecución del
proceso. Para ejecutar correctamente las aplicaciones migradas en
IBM
WebSphere
Process Server, asegúrese de que todas las variables y subestructuras se inicializan
antes de utilizarlas con actividades Asignar, Invocar, Personal y Respuesta.
Capítulo 5. Migrar artefactos origen a WebSphere Integration Developer desde WebSphere Studio
Application Developer Integration Edition
Es posible migrar artefactos origen de 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.
Muchas características disponibles en
WebSphere
Business Integration Server Foundation 5.1 han pasado a la base
WebSphere
Application Server 6.x.
Consulte este tema para obtener consejos acerca de la migración de dichas
características:
Consejos
para la migración de extensiones de modelo de programación.
Para migrar por
completo un proyecto de servicio de
WebSphere
Studio Application Developer Integration Edition, deben realizarse tres tareas
fundamentales:
- Preparar los artefactos origen para la migración. Es posible que estas acciones
deban realizarse en WebSphere Studio
Application Developer Integration Edition.
- Utilizar el asistente Migración o el script de línea de mandatos WSADIEServiceProjectMigration para migrar automáticamente los artefactos al proyecto de Módulo de
Integración empresarial.
- Utilizar 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.
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 proyectos de servicio de
WebSphere
Studio Integration Edition en 6.x.
Antes de empezar a migrar artefactos origen de
WebSphere
Studio Application Developer Integration Edition, examine las vías de migración que admite
WebSphere
Integration Developer.
El asistente de migración permite migrar un proyecto de servicio de
WebSphere
Studio Application Developer Integration Edition Versión 5.1 (o posterior) cada vez. No
migrará toda una área de trabajo.
El asistente de migración no migra binarios de aplicaciones; solamente migra los artefactos
origen que se encuentran en un proyecto de servicio de
WebSphere
Studio Application Developer Integration Edition.
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.
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:
- Asegúrese de tener una copia de seguridad de todo el área de trabajo de 5.1 antes de empezar la
migración.
- Revise la sección de migración del Centro de información de
Rational
Application Developer para determinar la mejor forma de migrar los proyectos no
específicos de WBI que haya en el área de trabajo:
Migrar
desde WebSphere
Studio V5.1, 5.1.1 o 5.1.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
- Asegúrese de tener todas las características adecuadas de
WebSphere
Integration Developer habilitadas. Si no tiene estas características habilitadas, no verá las
opciones de menú que se tratarán a continuación. Para habilitar las características importantes:
- En
WebSphere
Integration Developer, vaya al elemento de menú Ventana y seleccione
Preferencias.
- Vaya a Entorno de trabajo y seleccione la categoría Posibilidades.
- Seleccione todas las características situadas bajo las categorías siguientes:
- J2EE avanzado
- Java
de empresa
- Desarrollador de integración
- Desarrollador Java
- Desarrollador Web (típico)
- Desarrollador de servicios Web
- Desarrollador XML
- Pulse Aceptar.
- Utilice un nuevo directorio de área de trabajo para WebSphere Integration Developer. No se recomienda
abrir
WebSphere
Integration Developer en una antigua área de trabajo de
WebSphere
Studio Application Developer Integration Edition que contenga proyectos de servicio, ya que
esos proyectos primero deben migrarse a un formato legible por
WebSphere
Integration Developer. A continuación se indica el procedimiento recomendado para ello:
- Copie todos los proyectos que no son de servicio de la antigua área de trabajo en
la nueva.
No copie los proyectos EJB, Web y EAR 5.1 creados al generarse el código de
despliegue para un proyecto de servicio 5.1. El nuevo código de despliegue de 6.x se volverá a
generar automáticamente al construir el módulo de integración empresarial.
- Abra
WebSphere
Integration Developer en el área de trabajo en blanco e importe todos los proyectos que no son de
servicio pulsando en Archivo -> Importar -> General -> Proyecto existente en área de trabajo y seleccione los proyectos que ha copiado en la nueva área de trabajo.
- Si el
proyecto es un proyecto J2EE, debe migrarlo al nivel 1.4 utilizando el asistente Migración de
Rational
Application Developer:
- Pulse el proyecto con el botón derecho y seleccione Migración -> Asistente Migración de J2EE....
- Revise los avisos de la primera
página y, si no se le indica lo contrario, pulse
Siguiente.
- Asegúrese de que el Proyecto J2EE está seleccionado en la lista
Proyectos. Deje seleccionados Migrar estructura de proyecto y
Migrar nivel de especificación J2EE. Elija J2EE Versión
1.4 y Servidor destino WebSphere Process Server v6.1.
- Seleccione cualesquiera otras opciones que puedan ser adecuadas para el proyecto J2EE y pulse
Finalizar. Si este paso se lleva a cabo adecuadamente, verá un mensaje
indicando que La migración ha finalizado satisfactoriamente.
- Si hay errores en el proyecto J2EE después de la migración, debe eliminar todas las entradas de
vía de acceso de clases que hagan referencia a los archivos v5 .jar o a las bibliotecas y añadir
las bibliotecas Biblioteca del sistema JRE y Destino del servidor
WPS a la vía de acceso de clases en su lugar (se trata a continuación.) Esto debe
resolver la mayoría, si no todos los errores.
- Para los proyectos EJB de
WebSphere
Business Integration con Mensajería ampliada (CMM) o Persistencia contenida por
contenedor sobre cualquier cosa (CMP/A), los archivos de descriptor de Extensión Jar de
EJB de IBM
deben migrarse después de importar el proyecto 5.1 en el espacio de trabajo 6.x.
Consulte "Migrar proyectos EJB de
WebSphere
Business Integration" para obtener más información.
- Corrija la vía de acceso de clases para cada uno de los proyectos que no son
de servicio importados en el área de trabajo.
Para añadir las bibliotecas JRE y WebSphere Process Server a la vía de acceso de clases, pulse con el botón
derecho en el proyecto importado y seleccione Propiedades.
Vaya a la entrada Vía de
construcción Java y seleccione la pestaña Bibliotecas.
Después, haga lo siguiente:
- Seleccione Añadir biblioteca -> Biblioteca del
sistema JRE -> JRE alterno - JRE de Servidor WPS v6.1 -> Finalizar.
- A continuación, seleccione Añadir biblioteca -> Destino del servidor WPS -> Configurar vía de acceso de clases del
servidor wps -> Finalizar.
- Por omisión, WebSphere Integration
Developer genera el código de despliegue durante la construcción.
- Para migrar por completo los archivos .bpel dentro de un proyecto de servicio,
debe comprobar que todos los archivos .wsdl y .xsd a los que hacen referencia los archivos
.bpel se pueden resolver en un proyecto de integración empresarial de la nueva área de
trabajo:
- Si los archivos .wsdl o .xsd están en el mismo proyecto de servicio que el
archivo .bpel, no es precisa ninguna acción adicional.
- Si los
archivos .wsdl y/o .xsd están en un proyecto de servicio distinto del que está migrando, los artefactos 5.1 deben
reorganizarse utilizando
WebSphere
Studio Application Developer Integration Edition antes de la migración. La razón de esto es que los
proyectos de módulo de integración empresarial no pueden compartir artefactos.
Estas son las dos opciones para reorganizar los artefactos 5.1:
- En
WebSphere
Studio Application Developer Integration Edition, cree un proyecto
Java
nuevo que albergará todos los artefactos comunes. Ponga todos los archivos .wsdl y .xsd compartidos por más de un
proyecto de servicio en este proyecto
Java
nuevo.
Añada una dependencia de este proyecto
Java
nuevo para todos los proyectos de servicio que utilicen estos artefactos comunes. En
WebSphere
Integration Developer, cree un proyecto de biblioteca de integración empresarial con el mismo nombre que el proyecto
Java
compartido 5.1 antes de migrar cualquiera de los proyectos de servicio. Copie manualmente los archivos .wsdl y .xsd
antiguos del proyecto
Java
compartido de 5.1 en esta carpeta de proyecto de biblioteca BI. Esto debe hacerse antes de migrar
los proyectos de servicio de BPEL.
- Otra opción consiste en guardar una copia local de estos artefactos .wsdl y .xsd compartidos en
cada proyecto de servicio de modo que no haya dependencias entre proyectos de servicio.
- Si los archivos .wsdl o .xsd están en cualquier otro tipo de proyecto (normalmente
otros proyectos
Java),
debe crear un proyecto de biblioteca de integración empresarial con el mismo nombre que
el del proyecto 5.1. También debe configurar la vía de acceso de clases del proyecto de
biblioteca nuevo añadiendo las entradas del proyecto
Java
5.1 si existen. Este tipo de proyecto resulta de utilidad para almacenar artefactos
compartidos.
Ahora ya está preparado para iniciar el proceso de migración.
Consideraciones para el proceso de migración de artefactos origen
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:
- Intente utilizar la actividad Asignar en todas las
operaciones posibles (en lugar del servicio de transformador, que sólo es necesario cuando
se precisa una transformación avanzada). Debe utilizar este procedimiento porque es necesario
construir componentes intermedios para que un módulo SCA invoque un servicio de transformador. Además, no hay soporte de herramientas especiales en
WebSphere
Integration Developer para los servicios de transformador creados en 5.1 (debe utilizar el editor
WSDL o XML para modificar el XSLT incorporado en el archivo WSDL si necesita cambiar el
comportamiento del servicio de transformador.)
- Especifique un componente por mensaje WSDL igual que por la especificación de interoperatividad
de servicios Web (WS-I) y el estilo preferido en 6.x.
- Utilice el estilo de literal de documentos WSDL ya que es el estilo preferido en 6.x.
- Asegúrese de dar un nombre a todos los tipos complejos y de que cada tipo complejo
pueda identificarse de forma exclusiva por su espacio de nombres destino y su nombre. A
continuación se muestra el modo recomendado de definir tipos complejos y elementos de ese
tipo (definición del tipo complejo seguida de una definición de elemento que la utiliza):
<schema attributeFormDefault="qualified"
elementFormDefault="unqualified"
targetNamespace="http://util.claimshandling.bpe.samples.websphere.ibm.com"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:tns="http://util.claimshandling.bpe.samples.websphere.ibm.com">
<complexType name="Duration">
<all>
<element name="hours" type="int"/>
<element name="minutes" type="int"/>
<element name="days" type="int"/>
</all>
</complexType>
<element name="DurationElement" type="tns:Duration"/>
</schema>
El ejemplo siguiente representa un tipo complejo anónimo que debe
evitarse, ya que puede provocar problemas cuando se serializa un SDO en XML (elemento que
contiene una definición de tipo complejo anónimo):
<schema attributeFormDefault="qualified"
elementFormDefault="unqualified"
targetNamespace="http://util.claimshandling.bpe.samples.websphere.ibm.com"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:tns="http://util.claimshandling.bpe.samples.websphere.ibm.com">
<element name="DurationElement">
<complexType>
<all>
<element name="hours" type="int"/>
<element name="minutes" type="int"/>
<element name="days" type="int"/>
</all>
</complexType>
</element>
</schema>
- Si publica un servicio para consumidores externos, genere el código de despliegue del servicio
utilizando los servicios Web de
IBM (en lugar de
emplear Apache SOAP/HTTP) ya que los servicios Web de
IBM reciben soporte
directo en 6.x y los servicios Web de Apache no.
- Hay dos modos de organizar los archivos WSDL y XSD en 5.1 para minimizar la cantidad de
reorganización necesaria durante la migración. En 6.x, los artefactos compartidos como, por
ejemplo, archivos WSDL y XSD deben localizarse en proyectos de integración empresarial
(módulos y bibliotecas de integración empresarial) para que un servicio de
integración empresarial les haga referencia:
- Guarde todos los archivos WSDL compartidos por varios proyectos de servicio en un proyecto
Java
al que los proyectos de servicio puedan hacer referencia. Durante la migración a 6.x creará una
biblioteca de Integración empresarial nueva con el mismo nombre que el proyecto
Java
compartido de 5.1.
Copie todos los artefactos del proyecto Java compartido 5.1 en la biblioteca para que
el asistente para la migración pueda resolverlos cuando migre los proyectos de servicio
que utilizan esos artefactos
- Guarde una copia local de todos los archivos WSDL/XSD a los que hace referencia un
proyecto de servicio en el propio proyecto de servicio. Los proyectos de servicio de
WebSphere
Studio Application Developer Integration Edition se migrarán a un módulo de integración de negocio en
WebSphere
Integration Developer y un módulo no puede tener dependencias sobre otros módulos (un proyecto de servicio con dependencias sobre otro proyecto de servicio para compartir archivos WSDL o XSD no se
migrará correctamente).
- Evite utilizar la API de mensajería genérica (Generic MDB) del coreógrafo de procesos de
negocio (BPC) ya que no se proporcionará en 6.x. En 6.x no habrá disponible una interfaz
MDB de enlace tardío.
- Utilice la API de EJB genérica Business Process Choreographer en lugar de invocar los
beans de sesión
generados que son específicos de una versión determinada de un proceso. Estos beans de
sesión no se generarán en 6.x.
- Si tiene un proceso de negocio con varias respuestas para la misma operación, asegúrese de que
si cualquiera de ellas tiene valores de cliente, todas las respuestas para esa operación tengan los
mismos valores de cliente ya que en 6.x solo se da soporte un conjunto de valores de cliente por respuesta de operación.
- Diseñe fragmentos de código Java BPEL según las directrices siguientes:
- Evite enviar parámetros WSIFMessage a clases Java personalizadas;
intente no depender del formato de datos WSIFMessage en la medida de lo posible.
- Evite utilizar las API de metadatos WSIF si es posible.
- En lo posible, evite crear servicios
Java
o EJB de arriba abajo ya que el esqueleto Java/EJB que se genera a partir de los
mensajes/tipos de puerto de WSDL dependerá de las clases WSIF (por ejemplo:
WSIFFormatPartImpl). En su lugar, cree primero las interfaces Java/EJB y
genere un servicio alrededor de la clase
Java
o el EJB (procedimiento de abajo arriba.)
- Evite crear o utilizar interfaces WSDL que hagan referencia al tipo soapenc:Array porque este
tipo de interfaz no está soportado de forma nativa en el modelo de programación SCA
- Evite crear tipos de mensajes cuyo elemento de alto nivel sea un tipo de matriz (el atributo
maxOccurs es mayor que uno) porque este tipo de interfaz no está soportado de forma nativa en el
modelos de programación SCA.
- Defina las interfaces WSDL de forma precisa; en lo posible, evite complexTypes de XSD que
tengan referencias al tipo xsd:anyType.
- Para cualquier WSDL y los XSD que genere a partir de un bean EJB o
Java,
asegúrese de que el espacio de nombres destino sea exclusivo (el nombre de clase y de paquete
Java
están representados por el espacio de nombres de destino) para evitar colisiones al migrar a
WebSphere Process Server 6.x. En WebSphere
Process Server 6.x, no se permiten dos definiciones WSDL/XSD distintas
que tengan el mismo nombre y espacio de nombres de destino.
Esta situación se produce con frecuencia cuando se utilizan el asistente
Servicio Web o el mandato Java2WSDL sin especificar explícitamente el espacio de nombres destino (éste será exclusivo
con respecto al nombre de paquete del bean EJB o
Java,
pero no con respecto a la propia clase, por lo que se producirán problemas cuando se genere un servicio Web para dos o
más beans EJB o
Java
en el mismo paquete). La solución consiste en especificar un paquete personalizado para
la correlación de espacio de nombres en el asistente Servicio Web o utilizar la opción de
línea de mandatos -namespace de Java2WSDL
para asegurarse de que el espacio de nombres de los archivos generados sea exclusivo para
la clase dada.
- Utilice espacios de nombres exclusivos para cada archivo WSDL siempre que sea
posible. Existen limitaciones con respecto a la importación de dos archivos WSDL
diferentes con el mismo espacio de nombres de acuerdo con la especificación WSDL 1.1, y
en WebSphere
Integration Developer 6.x estas limitaciones deben cumplirse estrictamente.
Migrar proyectos de servicio utilizando el asistente de migración de
WebSphere
Integration Developer
El asistente de migración de
WebSphere
Integration Developer permite migrar proyectos de servicio.
Nota:
- Debe migrar los proyectos de servicio por su orden de dependencia. Por ejemplo, si un
BPEL del proyecto de servicio A realiza una llamada de proceso a proceso a un BPEL
del proyecto de servicio B, el proyecto de servicio B debe migrarse antes que el
proyecto de servicio A. De lo contrario, la llamada de proceso a proceso no podrá
configurarse correctamente.
- No es necesario inhabilitar la construcción automática en
WebSphere
Integration Developer Migration 6.0.2 y posteriores, ya que ésta se desactiva
automáticamente durante el proceso de migración.
El asistente de migración lleva a cabo las acciones siguientes:
- Crea un módulo de integración de negocio nuevo (el nombre del módulo lo define usted)
- Migra las entradas de vía de acceso de clases del proyecto de servicio al nuevo módulo.
- Copia todos los artefactos origen de
WebSphere
Business Integration Server Foundation del proyecto origen seleccionado a este módulo.
- Migra las extensiones BPEL en archivos WSDL.
- 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
- Crea un componente SCA para cada proceso .bpel.
- 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).
- Crea importaciones y exportaciones en función de las opciones de despliegue elegidas
en
WebSphere
Studio Application Developer Integration Edition
- Conecta el componente BPEL a sus enlaces asociados (importaciones, exportaciones y
componentes
Java)
Para migrar proyectos de servicio utilizando el
asistente de migración de
WebSphere
Integration Developer, siga estos pasos:
- Invoque el asistente seleccionando
Archivo -> Importar -> Integración de
negocio -> Proyecto de servicio de WebSphere
Studio Application Developer Integration Edition y pulse
Siguiente:
O también
puede abrir el asistente Migración desde la página de bienvenida pulsando el icono
Usuarios de vuelta
para abrir la página Usuarios de vuelta (tenga en cuenta que
siempre puede volver a la página de bienvenida pulsando
Ayuda -> Bienvenida ):
Pulse Migración en la
parte izquierda de la página Usuarios de vuelta para abrir la página Migración. En la página
Migración, seleccione la opción Migrar un proyecto de servicio de Integration Edition 5.1
.
- Se abre el asistente de migración. Especifique la vía de acceso para la Selección origen
o pulse el botón Examinar para buscarla. Especifique también el nombre de
Módulo de la ubicación del Proyecto de servicio de
WebSphere
Studio Application Developer Integration Edition a
migrar:
Nota: se recomienda seleccionar el nombre del proyecto de
servicio como nombre de módulo ya que si hay otros proyectos en el área de trabajo de
WebSphere
Studio Application Developer Integration Edition que dependen de este proyecto, no será necesario
actualizar las vías de acceso de clases de los proyectos dependientes tras importarlos en
WebSphere
Integration Developer.
- En las opciones de migración, marque el recuadro de selección Preservar fragmentos
de código
Java
BPEL originales:
Pulse Finalizar.
- Una vez finalizado el proceso de migración, se abre la ventana Resultados de la
migración:
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
se llamará ".log".
Una vez finalizado el asistente de migración, construya el módulo de integración
empresarial que se ha creado e intente resolver los errores de construcción que se
produzcan. Examine todos los archivos .bpel migrados: 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 módulo de
integración empresarial, abra el editor de dependencias de módulos para asegurarse de que las
dependencias se han establecido correctamente. Para ello, vaya a la perspectiva Integración
empresarial y pulse dos veces 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 empresarial, proyectos
Java
y proyectos J2EE.
Migración de proyectos de servicio utilizando WSADIEServiceProjectMigration
El mandato WSADIEServiceProjectMigration permite la migración de proyectos de servicio.
El mandato de migración lleva a cabo las acciones siguientes:
- Crea un módulo de integración de negocio nuevo (el nombre del módulo lo define usted)
- Migra las entradas de vía de acceso de clases del proyecto de servicio al nuevo módulo.
- Copia todos los artefactos origen de
WebSphere
Business Integration Server Foundation del proyecto origen seleccionado a este módulo.
- Migra las extensiones BPEL en archivos WSDL.
- 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
- Crea un componente SCA para cada proceso .bpel.
- 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).
- Crea importaciones y exportaciones en función de las opciones de despliegue elegidas
en
WebSphere
Studio Application Developer Integration Edition
- Conecta el componente BPEL a sus enlaces asociados (importaciones, exportaciones y
componentes
Java)
Nota: Debe migrar los proyectos de servicio por su orden de dependencia. Por ejemplo, si un
BPEL del proyecto de servicio A realiza una llamada de proceso a proceso a un BPEL
del proyecto de servicio B, el proyecto de servicio B debe migrarse antes que el
proyecto de servicio A. De lo contrario, la llamada de proceso a proceso no podrá
configurarse correctamente.
Para ejecutar el script WSADIEServiceProjectMigration, siga estos pasos:
- Localice el script abriendo la carpeta compartida especificada durante la instalación
de WebSphere Integration
Developer. Por ejemplo, el script se encontrará bajo: SHARED_FOLDER_HOME/plugins/com.ibm.wbit.migration.wsadie_6.1.0
- Invoque el script de la siguiente manera: WSADIEServiceProjectMigration
-e dir_eclipse -s dir_proyecto_origen -d espacio_trabajo [-t nombre_proyecto_destino]
[-preserveSnippets true|false] [-debug]
Definiciones de parámetros:
- -e dir_eclipse
- La ubicación de su carpeta de Eclipse (ejecutable de Eclipse).
- -s dir_proyecto_origen
- La vía de acceso completa al proyecto de servicio de
WebSphere Studio Application Developer Integration
Edition 5.1.
- -d espacio_trabajo
- El espacio de trabajo en que se creará el nuevo módulo de integración de negocio.
- -t nombre_proyecto_destino
- El nombre del nuevo módulo de integración de negocio a crear. El valor predeterminado es
el mismo que el proyecto de WebSphere Studio Application Developer Integration
Edition 5.1 que se migra.
- distintivo -preserveSnippets
- Habilita o inhabilita la conservación de los fragmentos de código
Java de BPEL existentes como comentarios. El valor predeterminado es true.
- Distintivo -debug
- Habilita la salida de depuración.
Por ejemplo:
WSADIEServiceProjectMigration -e WID_HOME\eclipse" -d "\miEspacioTrabajoWID" -s "\\MiProyectoServicio" -t "MiNombreMóduloBI" -preserveSnippets false -debug
- Tras completar el mandato, inicie el espacio de trabajo nuevo en WebSphere Integration
Developer.
- Construya el módulo de Integración de negocio que se ha creado e intente
resolver errores de construcción que puedan producirse. Examine todos los archivos .bpel migrados: 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 ve errores en los fragmentos de código Java de BPEL, consulte "Migración al modelo de programación SCA" para ver los pasos necesarios para la solución de
los errores.
- Abra el editor de dependencias de módulos para asegurarse de que las
dependencias se han establecido correctamente. Para ello, vaya a la perspectiva Integración
de negocio y pulse dos veces 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 empresarial, proyectos
Java
y proyectos J2EE.
Completar la migración de la aplicación
Una vez que el asistente de migración ha migrado correctamente los artefactos al
nuevo módulo de integración empresarial, los artefactos deben conectarse entre sí para crear
una aplicación conforme al modelo de SCA. Tenga en cuenta que, aunque el asistente de
migración intenta migrar correctamente los artefactos, siempre debe realizarse una
comprobación manual. La información de esta sección puede utilizarse para comprobar que
la migración ha sido correcta.
- Abra WebSphere Integration
Developer y vaya a la perspectiva Integración empresarial. 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 de módulo es el archivo de ensamblaje del módulo (denominado
igual que el módulo).
- Pulse dos veces 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 proyecto de servicio 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.
- 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.
Nota: El programa de utilidad de 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.
Si el proyecto de servicio
WebSphere
Studio Application Developer Integration Edition era dependiente de otros proyectos
Java,
copie los proyectos existentes en el directorio nuevo de área de trabajo e impórtelos en
WebSphere
Integration Developer utilizando el asistente
Archivo -> Importar -> General -> Proyectos
existentes en el espacio de trabajo.
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:
- Crear esquemas XSD para tipos de datos complejos:
- Dentro del archivo WSDL de interfaz
- Como un nuevo archivo para cada tipos de datos
- Dar soporte a la función de manejo de errores:
- Generar falta
- No generar falta
- Otros detalles sobre el servicio por generar como los nombres de enlace y servicio
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.
Importe el proyecto de servicio 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 empresarial, 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.)
Tiene las opciones siguientes:
Crear el componente
Java
personalizado: opción 1
La técnica de migración recomendada consiste en utilizar el tipo de componente
Java
de WebSphere
Integration Developer
que permite 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.
Para crear el componente
Java
personalizado, siga estos pasos:
- En el proyecto del módulo, expanda
Interfaces y seleccione la interfaz WSDL
generada para esta clase
Java
en
WebSphere
Studio Application Developer Integration.
- 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.
- Aparecerá un componente en el diagrama de ensamblaje. Selecciónelo y vaya a la vista
Propiedades.
- En la pestaña Descripción puede cambiar el nombre y el nombre de
visualización del componente por algo más descriptivo.
- En la pestaña Detalles verá que este componente tiene una interfaz, la
interfaz que arrastró y soltó en el Editor de ensamblaje.
- 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.
- 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....
- 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:
- Definiciones relevantes de la interfaz WSDL 5.1
- Los métodos
Java
de
WebSphere
Studio Application Developer Integration Edition 5.1 correspondientes al WSDL
- 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:
- Mueva la lógica de la
clase
Java
original a esta clase, adaptándola para utilizar DataObjects
- Esta es la opción recomendada si ha elegido el procedimiento de arriba abajo en
WebSphere
Studio Application Developer Integration Edition y desea que el componente
Java
trabaje con parámetros de DataObject. Esto es necesario porque las clases
Java
generadas a partir de definiciones WSDL en
WebSphere
Studio Application Developer Integration Edition tienen dependencias WSIF que deben eliminarse.
- Cree
una instancia privada de la antigua clase
Java
dentro de esta clase
Java
generada y escriba código para:
- Convertir todos los
parámetros de la clase de implementación
Java
generada en parámetros esperados por la clase
Java
antigua
- Invocar la instancia privada de la clase Java antigua con los parámetros convertidos
- 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
- 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:
- Si un proceso de negocio invoca este servicio en el mismo módulo, se crea una conexión desde la referencia de proceso
de negocio adecuada a esta interfaz del componente
Java.
- Si un proceso comercial invoca este servicio en otro módulo, cree una Exportación
con enlace SCA y desde el otro módulo, arrastre y suelte esta exportación en el Editor
de ensamblaje de ese módulo para crear la Importación con enlace SCA
correspondiente. Conecte la referencia de proceso de negocio adecuada a esa Importación.
- Si este servicio se publicó en
WebSphere
Studio Application Developer Integration Edition para exponerlo externamente, consulte la
sección "Crear exportaciones SCA para acceder al servicio migrado" para obtener
instrucciones acerca de cómo volver a publicar el servicio.
Crear un servicio Web Java: opción 2
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.
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:
- 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.
- 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.
- 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.
- Inicie el servidor de prueba, despliegue esta aplicación en el servidor y asegúrese de que se
inicia satisfactoriamente.
- 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.
- 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.
- Se mostrará la clase
Java
que ha pulsado con el botón derecho, pulse
Siguiente.
- 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.
- 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.
- 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.
- 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 de bean Java.
- Pulse Siguiente. Tenga en cuenta que posiblemente deberá esperar varios minutos.
- 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.
- Pase a la perspectiva Integración de negocio, expanda el módulo y después la categoría lógica
Puertos de servicio Web.
- 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 de arriba abajo en
WebSphere
Studio Application Developer Integration Edition, la generación de clases
Java
a partir de una definición WSDL, siga estos pasos:
- 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.
- 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.
- 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
Hay ventajas e inconvenientes para las opciones de reconexión de servicios
Java.
La lista siguiente describe las opciones y las ventajas e inconvenientes de cada una:
- La primera opción proporciona un mejor rendimiento en tiempo de ejecución porque invocar un servicio Web es más lento
que invocar un componente
Java.
- La primera opción puede propagar el contexto mientras que una invocación de servicio Web no
propaga el contexto de la misma forma.
- La segunda opción no implica la creación de código personalizado.
- La segunda opción no es aplicable para algunas definiciones de interfaz
Java ya
que la generación de un servicio
Java tiene
limitaciones. Consulte la documentación de
Rational
Application Developer en esta ubicación:
Limitaciones
de servicios Web
- La segunda opción puede implicar un cambio de interfaz y por lo tanto un cambio para el
consumidor de SCA.
- La segunda opción requiere la instalación de un servidor
WebSphere
Process Server 6.x y se ha configurado para trabajar con
WebSphere
Integration Developer. Para ver los tiempos de ejecución instalados que están configurados para trabajar con
WebSphere
Integration Developer, vaya a
Ventana -> Preferencias -> Server -> Tiempos
de ejecución instalados, seleccione la entrada
WebSphere Process Server v6.1 si es que
existe y asegúrese de que señala la ubicación en la que está instalado el producto.
Asegúrese de que esta entrada está marcada si el servidor existe y de que no lo está si
el servidor no está instalado. También puede pulsar en Añadir... para
añadir otro servidor.
- Si el componente
Java se
construyó en
WebSphere
Studio Application Developer Integration Edition utilizando el procedimiento de arriba abajo en el
que se genera el esqueleto
Java a
partir de un WSDL, los parámetros in y out de esta clase
Java serán
probablemente una subclase de WSIFFormatPartImpl. En este caso, elija la opción 1 para generar un esqueleto
Java
de estilo SCA nuevo del WSDL/XSD original o la opción 2 para generar un esqueleto
Java
genérico nuevo (no dependiente de las API WSIF o DataObject) de la interfaz WSDL original .
Migrar un servicio EJB
Puede migrar un servicio EJB a una Importación SCA con enlace de bean de sesión sin estado.
Si el proyecto de servicio de
WebSphere
Studio Application Developer Integration Edition dependía de otro EJB, cliente EJB o proyecto
Java,
importe esos proyectos utilizando el asistente
Archivo -> Importar -> General -> Proyecto existente en espacio de trabajo .
Este caso se daba
habitualmente cuando se hacía referencia a un EJB desde un proyecto de servicio.
Si los
archivos WSDL o XSD a los que se hace referencia desde el proyecto de servicio se encuentran
en otro tipo de proyecto, cree una nueva biblioteca de integración empresarial con el mismo
nombre que el antiguo proyecto que no era de servicio y copie todos estos artefactos en la
biblioteca.
Importe el proyecto de servicio 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 empresarial, 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.)
Tiene las
opciones siguientes:
Crear el componente EJB personalizado: opción 1
La técnica de migración recomendada consiste en utilizar el tipo de Importación con
enlace de sesión sin estado de
WebSphere
Integration Developer 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.
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:
- En el proyecto de módulo, expanda
Interfaces y seleccione la interfaz WSDL
generada para este EJB en
WebSphere
Studio Application Developer Integration.
- 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.
- Aparecerá un componente en el diagrama de ensamblaje. Selecciónelo y vaya a la vista
Propiedades.
- 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.
- En la pestaña Detalles verá que este componente tiene una interfaz, la
interfaz que arrastró y soltó en el Editor de ensamblaje.
- 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:
- Definiciones relevantes de la interfaz WSDL 5.1
- Los métodos
Java
de
WebSphere
Studio Application Developer Integration Edition 5.1 correspondientes al WSDL
- 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:
- 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.
- 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.
- Asegúrese de que el proyecto EJB aparece bajo la sección J2EE y si no es así, añádalo
pulsando Añadir....
- 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.
- Seleccione la herramienta Conectar en la paleta, en el Editor de ensamblaje.
- Pulse el componente Java y suelte el ratón.
- A continuación pulse la Importación EJB y suelte el ratón.
- 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.
- 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.
- 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:
- Cree una variable privada (cuyo tipo sea el de la interfaz EJB remota):
private YourEJBInterface ejbService = null;
- 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");
- 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:
- Convierta todos los parámetros en los tipos de parámetro esperados por el EJB.
- Invoque el método adecuado en la referencia EJB utilizando el modelo de programación SCA,
enviando los parámetros convertidos.
- 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
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.
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:
- 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.
- 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.
- Inicie el servidor de prueba, despliegue esta aplicación en el servidor y asegúrese de que se
inicia satisfactoriamente.
- 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.
- Pulse con el botón derecho del ratón y seleccione
Servicios
Web -> Crear servicio
Web.
- 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.
- Asegúrese de que el EJB que pulsó con el botón derecho está seleccionado aquí y pulse
Siguiente.
- 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.
- 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.
- 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 deseado
(SOAP sobre HTTP o SOAP sobre JMS). Pulse Siguiente.
- 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
- 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.
- Pulse Siguiente. Tenga en cuenta que posiblemente deberá esperar varios minutos.
- 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.
- 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.
- 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 de arriba abajo en
WebSphere
Studio Application Developer Integration Edition, la generación de un esqueleto EJB a partir de una definición WSDL,
siga estos pasos:
- 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.
- 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.
- 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:
- Si este servicio lo invoca un proceso de negocio en el mismo módulo, cree una conexión a partir
de la referencia de proceso de negocio adecuada a este componente EJB.
- Si un proceso comercial invoca este servicio en otro módulo, cree una Exportación
con enlace SCA y desde el otro módulo, arrastre y suelte esta exportación en el Editor
de ensamblaje de ese módulo para crear la Importación con enlace SCA
correspondiente. Conecte la referencia de proceso de negocio adecuada a esa Importación.
- Si este servicio se publicó en
WebSphere
Studio Application Developer Integration Edition para exponerlo externamente, consulte la
sección "Crear exportaciones SCA para acceder al servicio migrado" para obtener
instrucciones acerca de cómo volver a publicar el servicio.
Ventajas y desventajas de las opciones de reconexión de servicios EJB
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:
- La primera opción proporciona un mejor rendimiento en tiempo de ejecución porque invocar un
servicio Web es más lento que invocar un EJB.
- La primera opción puede propagar el contexto mientras que una invocación de servicio Web no
propaga el contexto de la misma forma.
- La segunda opción no implica la creación de código personalizado.
- La segunda opción no es aplicable para algunas definiciones de interfaz EJB ya que la
generación de un servicio EJB tiene limitaciones. Consulte la documentación de
Rational
Application Developer en esta ubicación:
Limitaciones
de servicios Web
- La segunda opción puede implicar un cambio de interfaz y por lo tanto un cambio para el
consumidor de SCA.
- La segunda opción requiere la instalación de un servidor
WebSphere
Process Server 6.x y se ha configurado para trabajar con
WebSphere
Integration Developer. Para ver los tiempos de ejecución instalados que están configurados para trabajar con
WebSphere
Integration Developer, vaya a
Ventana -> Preferencias -> Server -> Tiempos
de ejecución instalados, seleccione la entrada
WebSphere Process Server v6.1 si es que
existe y asegúrese de que señala la ubicación en la que está instalado el producto.
Asegúrese de que esta entrada está marcada si el servidor existe y de que no lo está si
el servidor no está instalado. También puede pulsar en Añadir... para
añadir otro servidor.
- Si el componente
Java se
construyó en
WebSphere
Studio Application Developer Integration Edition utilizando el procedimiento de arriba abajo en el
que se genera el esqueleto EJB a partir de un WSDL, los parámetros in y out de esta clase
Java serán
probablemente una subclase de WSIFFormatPartImpl. En este caso, elija la opción 2 para generar un
esqueleto EJB genérico (no dependiente del WSIF ni de de las API de DataObject) de la interfaz WSDL
original.
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.
Para migrar un proyecto de servicio de enlace de proceso (BPEL) para un servicio saliente,
siga estos pasos:
- En la perspectiva Integración empresarial, 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.)
- 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:
- Si el BPEL que se invoca está en el mismo módulo, cree una conexión desde la referencia
adecuada del primer componente BPEL a la interfaz
adecuada del componente BPEL destino.
- Si el BPEL que se invoca está en otro módulo (siendo el otro módulo un
proyecto de
servicio migrado):
- Cree una Exportación con enlace SCA para el segundo proceso comercial
en el diagrama de ensamblaje de módulo correspondiente.
- Expanda el segundo icono de ensamblaje de módulo en el navegador en la vista Integración
empresarial. Debe ver la exportación que acaba de crear.
- Arrastre y suelte la exportación de la vista Integración empresarial bajo el segundo módulo en
el editor de ensamblaje abierto del primer módulo. Con esto se creará una Importación con enlace SCA
en el primer módulo. Si este servicio se publicó en
WebSphere
Studio Application Developer Integration Edition para exponerlo externamente, consulte la
sección "Crear Exportaciones SCA para para acceder al servicio migrado".
- Conecte la referencia adecuada en el primer proceso de negocio con la importación que acaba de
crear en ese módulo.
- Guarde el diagrama de ensamblaje.
- Para obtener un enlace tardío al invocar el segundo proceso comercial:
- Deje la referencia del primer componente de proceso comercial sin conectar. Abra el
primer proceso en el editor de BPEL y, bajo la sección Asociados de
referencia, seleccione el asociado que corresponda al segundo proceso
BPEL
para invocarlo mediante enlace tardío.
- En la vista Propiedades de la pestaña Descripción, especifique
el nombre del segundo proceso comercial en el campo Plantilla de
proceso.
- Guarde el proceso comercial. Ha finalizado la configuración de la invocación de
enlace tardío.
Migrar un servicio Web (SOAP/JMS)
Puede migrar un servicio Web (SOAP/JMS) a una Importación SCA con enlace de servicio Web.
Para migrar un proyecto de servicio SOAP/JMS para una migración de servicio saliente, siga
estos pasos:
- En primer lugar, debe importar el proyecto de servicio utilizando el asistente Migración. Con esta operación se creará un módulo de integración empresarial 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.
- En la perspectiva Integración empresarial,
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.)
- A continuación, 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.
- En la perspectiva Integración empresarial, expanda el módulo migrado y abra el Diagrama de
ensamblaje en el Editor de ensamblaje.
- 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.
- Elija crear una Importación con enlace de servicio Web.
- 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.
- Guarde el diagrama de ensamblaje.
Una vez que haya cumplimentado esto, debe volver a conectar el servicio:
- Si un proceso de negocio invoca este servicio en el mismo módulo, cree una conexión de la
referencia de proceso de negocio adecuada a esta Importación.
- Si un proceso comercial invoca este servicio en otro módulo, cree una Exportación
con enlace SCA y desde el otro módulo, arrastre y suelte esta exportación en el Editor
de ensamblaje de ese módulo para crear la Importación con enlace SCA
correspondiente. Conecte la referencia de proceso de negocio adecuada a esa Importación.
- Guarde el diagrama de ensamblaje.
Migrar un servicio Web (SOAP/HTTP)
Puede migrar un servicio Web (SOAP/HTTP) a una Importación SCA con enlace de servicio
Web.
Para migrar un proyecto de servicio SOAP/HTTP para una migración de servicio saliente,
siga estos pasos:
- En primer lugar, debe importar el proyecto de servicio utilizando el asistente Migración. Con esta operación se creará un módulo de integración empresarial 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.
- En la perspectiva Integración empresarial,
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.)
- A continuación, 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.
- En la perspectiva Integración empresarial, expanda el módulo migrado y abra el Diagrama de
ensamblaje en el Editor de ensamblaje.
- 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.
- Elija crear una Importación con enlace de servicio Web.
- 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.
- Guarde el diagrama de ensamblaje.
Una vez que haya cumplimentado esto, debe volver a conectar el servicio:
- Si un proceso de negocio invoca este servicio en el mismo módulo, cree una conexión de la
referencia de proceso de negocio adecuada a esta Importación.
- Si un proceso comercial invoca este servicio en otro módulo, cree una Exportación
con enlace SCA y desde el otro módulo, arrastre y suelte esta exportación en el Editor
de ensamblaje de ese módulo para crear la Importación con enlace SCA
correspondiente. Conecte la referencia de proceso de negocio adecuada a esa Importación.
- Guarde el diagrama de ensamblaje.
Migrar un servicio JMS
Puede migrar un servicio JMS a una Importación SCA con enlace JMS.
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:
- En primer lugar, debe importar 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.
- En la perspectiva Integración empresarial,
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.)
- A continuación, 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.
- 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.
- Un diálogo Creación de componente permitirá seleccionar el tipo de
componente a crear. Elija Importar sin enlaces.
- 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.
- 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).
- 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>
- 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:
- Enlace de importación JMS (esto es lo más importante)
- Conexión
- Adaptador de recursos
- Destinos JMS
- Enlaces de método
Una vez que haya cumplimentado esto, debe volver a conectar el servicio:
- Si un proceso de negocio invoca este servicio en el mismo módulo, cree una conexión de la
referencia de proceso de negocio adecuada a esta Importación.
- Si un proceso comercial invoca este servicio en otro módulo, cree una Exportación
con enlace SCA y desde el otro módulo, arrastre y suelte esta exportación en el Editor
de ensamblaje de ese módulo para crear la Importación con enlace SCA
correspondiente. Conecte la referencia de proceso de negocio adecuada a esa Importación.
- Guarde el diagrama de ensamblaje.
Migrar un servicio J2C-IMS
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.
No utilice ninguno de los artefactos de
WebSphere
Studio Application Developer Integration Edition generados para este servicio
IMS. Necesitará recrear 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.
Para crear una Importación SCA para invocar el servicio
IMS,
siga estos pasos:
- Cree un proyecto de módulo de integración de negocio nuevo para albergar este servicio
IMS nuevo.
- Para volver a crear el servicio EIS, vaya a Archivo -> Nuevo -> Otro -> Integración
empresarial -> Servicio externo.
- 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.
- 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.
- 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).
Para crear un servicio Web alrededor del servicio J2C, siga estos pasos:
- Cree el bean
Java
J2C pulsando
Archivo -> Nuevo -> J2C -> Bean
Java J2C
- Elija la versión 1.5 de IMS Connector for Java y pulse
Siguiente.
- Marque Conexión gestionada y especifique el nombre de búsqueda JNDI. Pulse Siguiente.
- 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.
- 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 pulsa el botón
Añadir..., elija el nombre para el método y pulse
Siguiente.
- 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.
- Una vez haya terminado de crear los métodos
Java,
pulse Siguiente.
- Complete los pasos restantes de este asistente para crear el bean
Java J2C.
- 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.
- 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:
- La primera opción utiliza los componentes SCA estándar para invocar el servicio
IMS.
- La primera opción tiene algunas limitaciones:
- La API de especificación de SDO versión 1 no proporciona acceso a la matriz de bytes COBOL o C,
lo que afectará a los clientes que trabaje con segmentos múltiples de
IMS.
- La especificación de SDO versión 1 para la serialización no soporta redefiniciones COBOL ni
uniones C.
- La segunda opción utiliza el procedimiento JSR 109 estándar para conectar con el servicio
IMS.
Esta funcionalidad está disponible como parte de
Rational
Application Developer.
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.
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:
- Sitúese en el directorio de instalación de
WebSphere
Integration Developer y vaya a
Resource
Adapters -> cics15 -> cicseci.rar.
Si sigue la segunda opción para crear un servicio Web J2C, elija el
ECIResourceAdapter de 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.
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.
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.
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.
Los componentes de correlación de datos y de correlación de interfaces son nuevos en la versión 6.0.
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 de
WebSphere
Studio Application Developer Integration Edition tal cual al rediseñar la aplicación en
WebSphere
Integration Developer.
Estos son los pasos a seguir en WebSphere Studio Application Developer
Integration Edition antes de invocar el asistente Migración:
- 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.
- 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.
- 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.
- Ahora puede especificar el estilo del proxy, elija el Apéndice de
cliente, seleccione las operaciones deseadas 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:
- Copie el proyecto Java de proxy de cliente en el área de trabajo nueva e impórtela
con Archivo -> Importar -> Proyecto existente en el área de trabajo.
- Importe el proyecto de servicio utilizando el asistente Migración. Con esta operación se
creará un módulo de integración empresarial con los mensajes WSDL, los tipos de puerto, los enlaces
y los servicios generados en
WebSphere
Studio Application Developer Integration Edition.
- En la perspectiva Integración empresarial,
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.)
- 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.
- 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.
- Aparecerá un componente en el diagrama de ensamblaje. Selecciónelo y vaya a la vista
Propiedades.
- 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.)
- En la pestaña Detalles verá que este componente tiene una interfaz, la
interfaz que arrastró y soltó en el Editor de ensamblaje.
- 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.
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:
- Mueva la lógica de la
clase
Java
original a esta clase, adaptándola a la estructura de datos nueva.
- Cree
una instancia privada de la antigua clase
Java
dentro de esta clase
Java
generada y escriba código para:
- Convertir todos los
parámetros de la clase de implementación
Java
generada en parámetros esperados por la clase
Java
antigua
- Invocar la instancia privada de la clase Java antigua con los parámetros convertidos
- 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:
- Si un proceso de negocio invoca este servicio en el mismo módulo, se crea una conexión desde la referencia de proceso
de negocio adecuada a esta interfaz del componente
Java.
- Si un proceso comercial invoca este servicio en otro módulo, cree una Exportación
con enlace SCA y desde el otro módulo, arrastre y suelte esta exportación en el Editor
de ensamblaje de ese módulo para crear la Importación con enlace SCA
correspondiente. Conecte la referencia de proceso de negocio adecuada a esa Importación.
- Si este servicio se publicó en
WebSphere
Studio Application Developer Integration Edition para exponerlo externamente, consulte la
sección "Crear exportaciones SCA para acceder al servicio migrado" para obtener
instrucciones acerca de cómo volver a publicar el servicio.
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 programa de
utilidad de migración intenta hacerlo automáticamente, pero puede consultar la
información siguiente para comprobar lo que ha hecho la herramienta.
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:
- EJB
- Servicio Web de
IBM (SOAP/JMS)
- Servicio Web de
IBM (SOAP/HTTP)
- Servicio Web de Apache (SOAP/HTTP)
- JMS
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.
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 3. 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 4. 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.
En el editor de ensamblado, siga estos pasos para conectar este otro
componente con el componente
BPEL:
- Seleccione el elemento Conexión en la barra de herramientas.
- Pulse el otro componente para seleccionarlo como origen de la conexión.
- Pulse el componente BPEL SCA para seleccionarlo como
destino de la conexión.
- 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.
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:
- Abra el editor de ensamblajes para el módulo creado por el asistente de migración.
- 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:
- Pulse con el botón derecho en el componente BPEL del editor de ensamblajes.
- Seleccione Exportar....
- Seleccione Enlace de SCA.
- Si hay varias interfaces para el proceso, seleccione la que le permita exportar
con este tipo de enlace.
- 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.
- 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.
La referencia autónoma hace que un cliente externo pueda acceder a un componente SCA.
Para crear una referencia autónoma, siga estos pasos:
- Abra el editor de ensamblajes para el módulo creado por el asistente de migración.
- 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:
- Seleccione el elemento Referencias autónomas en la barra
de herramientas.
- Pulse el lienzo del editor de ensamblajes para crear una entidad SCA de
referencias autónomas.
- Seleccione el elemento Conexión en la barra de
herramientas.
- Pulse la entidad Referencias autónomas para seleccionarla
como origen de la conexión.
- Pulse el componente BPEL SCA para seleccionarlo como
destino de la conexión.
- Verá una alerta Se creará una referencia coincidente en el nodo de
origen. ¿Desea continuar?; pulse Aceptar.
- Seleccione la entidad Referencias autónomas que acaba de
crear y seleccione el panel de contenido Descripción en la vista
Propiedades.
- Expanda el enlace Referencias y seleccione la referencia
que acaba de crear. Se muestran el nombre y la descripción de la referencia, que pueden
modificarse según convenga.
- Si hay varias interfaces para el proceso, seleccione la que le permita exportar
con este tipo de enlace.
- 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.
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:
- Abra el editor de ensamblado para el módulo creado por el asistente de migración.
- 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:
- Pulse con el botón derecho en el componente BPEL del editor de ensamblajes.
- Seleccione Exportar... .
- Seleccione Enlace de servicio Web.
- Si hay varias interfaces para el proceso, seleccione la que le permita exportar
con este tipo de enlace.
- Seleccione el transporte: soap/http o
soap/jms.
- 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.
- 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.
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:
- Fábrica de conexiones JNDI: el valor predeterminado es
jms/BPECF (este es el nombre JNDI de la fábrica de conexiones de cola del contenedor de
procesos de negocio de destino).
- Cola de destino JNDI: el valor predeterminado es
jms/BPEIntQueue (este es el nombre JNDI de la cola interna del contenedor de procesos de
negocio de destino).
- URL de proveedor JNDI: proporcionado por el servidor o
personalizado: especifique una dirección. El valor predeterminado es
iiop://localhost:2809.
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 5. 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.
En el editor de ensamblado, siga estos pasos para conectar este otro componente
con el componente BPEL:
- Seleccione el elemento Conexión en la barra de herramientas.
- Pulse el otro componente para seleccionarlo como origen de la conexión.
- Pulse el componente BPEL SCA para seleccionarlo como
destino de la conexión.
- 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.
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:
- Abra el editor de ensamblajes para el módulo creado por el asistente de migración.
- 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:
- Pulse con el botón derecho en el componente BPEL del editor de ensamblajes.
- Seleccione Exportar....
- Seleccione Enlace de SCA.
- Si hay varias interfaces para el proceso, seleccione la que le permita exportar
con este tipo de enlace.
- 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.
- 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.
La referencia autónoma hace que un cliente externo pueda acceder a un componente SCA.
Para crear una referencia autónoma, siga estos pasos:
- Abra el editor de ensamblajes para el módulo creado por el asistente de migración.
- 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:
- Seleccione el elemento Referencias autónomas en la barra
de herramientas.
- Pulse el lienzo del editor de ensamblajes para crear una entidad SCA de
referencias autónomas.
- Seleccione el elemento Conexión en la barra de
herramientas.
- Pulse la entidad Referencias autónomas para seleccionarla
como origen de la conexión.
- Pulse el componente BPEL SCA para seleccionarlo como
destino de la conexión.
- Verá una alerta Se creará una referencia coincidente en el nodo de
origen. ¿Desea continuar?; pulse Aceptar.
- Seleccione la entidad Referencias autónomas que acaba de
crear y seleccione el panel de contenido Descripción en la vista
Propiedades.
- Expanda el enlace Referencias y seleccione la referencia
que acaba de crear. Se muestran el nombre y la descripción de la referencia, que pueden
modificarse según convenga.
- Si hay varias interfaces para el proceso, seleccione la que le permita exportar
con este tipo de enlace.
- 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.
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:
- Abra el editor de ensamblajes para el módulo creado por el asistente de migración.
- 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:
- Pulse con el botón derecho en el componente BPEL del editor de ensamblajes.
- Seleccione Exportar... .
- Seleccione Enlace de servicio Web.
- Si hay varias interfaces para el proceso, seleccione la que le permita exportar
con este tipo de enlace.
- Seleccione el transporte: soap/http o
soap/jms.
- 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.
- 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.
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:
- 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).
- Abra el editor de ensamblajes para el módulo creado por el asistente de migración.
- 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.
- Seleccione Exportar... .
- Seleccione Enlace de JMS.
- Si hay varias interfaces para el proceso, seleccione la que le permita exportar con
este tipo de enlace.
- 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.
- 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):
- 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.
- 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.
- 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.
- 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.
- 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.
- Seleccione el panel de contenido Enlace para ver muchas más opciones.
- 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.
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.
A continuación figura un ejemplo de los convenios utilizados al generar
un servicio Web de
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 6. 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:
- El valor predeterminado de estilo de documento era DOCUMENT / otra opción:
RPC.
- El valor predeterminado de uso de documento era LITERAL / otra opción:
ENCODED.
- El valor de URL de proveedor JNDI era Proporcionado por el
servidor o Personalizado (debe especificarse una
dirección, siendo el valor predeterminado iiop://localhost:2809)
- El valor predeterminado de estilo de destino era queue / otra opción:
topic.
- El valor predeterminado de fábrica de conexiones JNDI era jms/qcf
(este es el nombre JNDI de la fábrica de conexiones de cola de la cola MDB generada).
- El valor predeterminado de cola de destino JNDI era jms/queue (este
es el nombre JNDI de la cola MDB generada).
- El valor predeterminado de puerto de escucha MDB era <nombre de proyecto de
servicio>MdbListenerPort.
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 empresarial 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 7. 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.
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:
- Abra el editor de ensamblajes para el módulo creado por el asistente de migración.
- 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:
- Pulse con el botón derecho en el componente SCA del editor de ensamblajes.
- Seleccione Exportar....
- Seleccione Enlace de servicio Web.
- Si hay varias interfaces para el componente, seleccione la que le permita exportar
con este tipo de enlace.
- Seleccione el transporte soap/jms.
- 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.
- Guarde el diagrama de ensamblaje.
- 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.
- Siga estos pasos para generar un enlace de servicio Web y un servicio nuevos si desea
preservar el código del cliente:
- 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.
- 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 en línea
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.
- 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.
- Vaya a la pestaña Origen. Suprima todos los
mensajes y tipos de puerto WSDL definidos en este archivo.
- 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.
- 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.
- Guarde el archivo WSDL.
- Renueve/reconstruya el proyecto. Pase a la perspectiva Integración empresarial. Abra
el Diagrama de ensamblaje en el Editor de ensamblaje.
- 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.
- 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.
- Guarde todos los cambios.
- 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"/>
- 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.
- 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.
La referencia autónoma hace que un cliente externo pueda acceder a un componente SCA.
Para crear una referencia autónoma, siga estos pasos:
- Abra el editor de ensamblajes para el módulo creado por el asistente de migración.
- 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:
- Seleccione el elemento Referencias autónomas en la barra
de herramientas.
- Pulse el lienzo del editor de ensamblajes para crear una entidad SCA de
referencias autónomas.
- Seleccione el elemento Conexión en la barra de
herramientas.
- Pulse la entidad Referencias autónomas para seleccionarla
como origen de la conexión.
- Pulse el componente BPEL SCA para seleccionarlo como
destino de la conexión.
- Verá una alerta Se creará una referencia coincidente en el nodo de
origen. ¿Desea continuar?; pulse Aceptar.
- Seleccione la entidad Referencias autónomas que acaba de
crear y seleccione el panel de contenido Descripción en la vista
Propiedades.
- Expanda el enlace Referencias y seleccione la referencia
que acaba de crear. Se muestran el nombre y la descripción de la referencia, que pueden
modificarse según convenga.
- Si hay varias interfaces para el proceso, seleccione la que le permita exportar
con este tipo de enlace.
- 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.
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.
A continuación figura un ejemplo de los convenios utilizados al generar un
servicio Web de 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 8. 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:
- El valor predeterminado de estilo de documento era RPC / otra opción:
DOCUMENT.
- El valor predeterminado de uso de documento era ENCODED / otra opción:
LITERAL.
- Para Router Address, el valor predeterminado era http://localhost:9080
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 empresarial 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 9. 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.
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:
- Abra el editor de ensamblajes para el módulo creado por el asistente de migración.
- 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.
- Seleccione Exportar....
- Seleccione Enlace de servicio Web.
- Si hay varias interfaces para el componente, seleccione la que le permita exportar
con
este tipo de enlace.
- Seleccione el transporte soap/http.
- 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.
- Guarde el diagrama de ensamblaje.
- Siga estos pasos para generar un enlace de servicio Web y un servicio nuevos si desea
preservar el código del cliente:
- 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.
- 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 en línea
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.
- 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.
- Vaya a la pestaña Origen. Suprima todos los
mensajes y tipos de puerto WSDL definidos en este archivo.
- 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.
- 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.
- Guarde el archivo WSDL.
- Renueve/reconstruya el proyecto. Pase a la perspectiva Integración empresarial. Abra
el Diagrama de ensamblaje en el Editor de ensamblaje.
- 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.
- 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.
- Guarde todos los cambios.
- 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"/>
- 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.
- 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.
La referencia autónoma hace que un cliente externo pueda acceder a un componente SCA.
Para crear una referencia autónoma, siga estos pasos:
- Abra el editor de ensamblajes para el módulo creado por el asistente de migración.
- 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:
- Seleccione el elemento Referencias autónomas en la barra
de herramientas.
- Pulse el lienzo del editor de ensamblajes para crear una entidad SCA de
referencias autónomas.
- Seleccione el elemento Conexión en la barra de
herramientas.
- Pulse la entidad Referencias autónomas para seleccionarla
como origen de la conexión.
- Pulse el componente SCA para seleccionarlo como
destino de la conexión.
- Verá una alerta Se creará una referencia coincidente en el nodo de
origen. ¿Desea continuar?; pulse Aceptar.
- Seleccione la entidad Referencias autónomas que acaba de
crear y seleccione el panel de contenido Descripción en la vista
Propiedades.
- Expanda el enlace Referencias y seleccione la referencia
que acaba de crear. Se muestran el nombre y la descripción de la referencia, que pueden
modificarse según convenga.
- Si hay varias interfaces para el proceso, seleccione la que le permita exportar
con este tipo de enlace.
- 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.
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:
- El valor de estilo de documento era RPC (única
opción disponible).
- El valor de acción SOAP era URN:nombre de tipo de puerto WSDL.
- El valor de dirección era http://localhost:9080/nombre de proyecto de
servicioWeb/servlet/rpcrouter.
- El valor predeterminado de uso de codificación era yes (al
establecerse yes, el valor de estilo de codificación era
http://schemas.xmlsoap.org/soap/encoding/).
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).
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.
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 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, con lo que es preciso realizar una serie de 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
-
- Basado en WSIF y WSDL
- Proxys generados para servicios
- Manejadores de formato y beans para tipos
- Modelo de programación V6.x (más centrado en Java)
-
- Servicios SCA basados en SDO con códigos de doclet
- Enlaces de interfaz para servicios
- 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.
Tabla 10. 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.
Migrar el cliente EJB
Este tema muestra cómo migrar clientes que utilizan una interfaz
genérica EJB
para invocar un servicio.
- 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.
- 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.
- Seleccione la herramienta de conexión y pulse sobre la referencia de servicio; a
continuación, pulse Importar.
- Pulse Aceptar cuando se le muestre una alerta que le indica que se
creará una referencia coincidente en el nodo de origen.
- 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?
- Responda
Sí 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.
- 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.
- 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.
- 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 ("<name-of-standalone-reference-from-previous-step");
// 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.
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.
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.
- Asegúrese de tener instalado un
WebSphere
Process Server o
WebSphere
Application Server.
- 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 (fíjese en que este asistente
es muy parecido al asistente de la versión 5.1.)
- Para el Tipo de proxy de cliente, elija Proxy Java y pulse
Siguiente.
- La ubicación del archivo WSDL debería estar cumplimentada. Pulse Siguiente.
- 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.
- 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.
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.
- Asegúrese de tener instalado un
WebSphere
Process Server o
WebSphere
Application Server.
- 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 (fíjese en que este asistente es
muy parecido al asistente de la versión 5.1.)
- Para el Tipo de proxy de cliente, elija Proxy Java y pulse
Siguiente.
- La ubicación del archivo WSDL debería estar cumplimentada. Pulse Siguiente.
- 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.
- 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).
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.
- Asegúrese de tener instalado un
WebSphere
Process Server o
WebSphere
Application Server.
- 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 (fíjese en que este asistente es
muy parecido al asistente de la versión 5.1.)
- Para el Tipo de proxy de cliente, elija Proxy Java y pulse
Siguiente.
- La ubicación del archivo WSDL debería estar cumplimentada. Pulse Siguiente.
- 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.
- 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.
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.
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 6.0 ya que las operaciones de tareas manuales están
ahora disponibles como EJB aparte. Los nombres JNDI 6.0 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
No existe ninguna API de mensajería genérica en WebSphere Process Server. Consulte la sección
"Migrar el JMS y los enlaces de proceso JMS" para elegir un modo diferente de exponer los
procesos comerciales a los clientes y reescribir el cliente de acuerdo con el enlace
elegido.
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.
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:
- Los mensajes tienen componentes no primitivos para mejorar la capacidad de utilización de la
estructura de datos del mensaje.
- 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:
- Seleccione el lienzo del proceso o una actividad del proceso.
- En la vista Propiedades, seleccione la pestaña Cliente para
volver a diseñar los
valores de cliente Web.
- Migrar manualmente los JSP definidos por el usuario:
- Consulte la sección "Migrar al modelo de programación SCA" para conocer los cambios
en el modelo de programación.
- 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.
- 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 Java
BPEL 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.
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 11. 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.
Para acceder a las herramientas de servicio externo, siga estos pasos:
- Acceda a Archivo -> Nuevo -> Otro -> Integración de negocio y seleccione Servicio externo. Pulse Siguiente.
- Elija Adaptadores. Pulse Siguiente.
- 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.
- 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.
- Acepte los parámetros de configuración para el objeto de negocio y pulse
Aceptar.
- Repita el proceso para cada objeto de negocio.
- Pulse Siguiente.
- 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.
- Pulse Finalizar.
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.
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 esta
es la manera de 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"));
Migrar proyectos EJB de
WebSphere
Business Integration
En
WebSphere
Application Developer Integration Edition, los proyectos EJB pueden tener características
especiales de
WebSphere
Business Integration como por ejemplo Mensajería ampliada (CMM) y CMP/A (persistencia
gestionada por componentes en cualquier parte.) Los descriptores de despliegue para esos proyectos deben
migrarse y esta sección muestra cómo realizar esa migración.
Para realizar esta migración, siga estos pasos:
- Copie el proyecto EJB de
WebSphere
Business Integration en el área de trabajo nueva e impórtela de
WebSphere
Integration Developer utilizando el asistente
Archivo -> Importar -> Proyecto
existente en el área de trabajo.
También puede ejecutar el asistente Migración de J2EE.
- Cierre todas las instancias de
WebSphere
Integration Developer que estén ejecutándose en el área de trabajo 6.x.
- Ejecute el script siguiente que migrará los descriptores de despliegue de Integración empresarial de
WebSphere
en el proyecto EJB:
- En Windows:
-
SHARED_FOLDER_HOME/plugins/com.ibm.wbit.migration.wsadie_6.1.0/WSADIEEJBProjectMigration.bat
- En Linux:
-
SHARED_FOLDER_HOME/plugins/com.ibm.wbit.migration.wsadie_6.1.0/WSADIEEJBProjectMigration.sh
Los parámetros siguientes están soportados; el área de trabajo y el nombre de
proyecto son obligatorios:
Uso: WSADIEEJBProjectMigration.bat
[-e eclipse-folder] -d workspace -p project
carpeta-eclipse: La ubicación de la carpeta eclipse; normalmente es el 'eclipse'
que se encuentra bajo la carpeta de instalación del producto.
área_trabajo: El área de trabajo que contiene el proyecto WSADIE EJB a migrar.
proyecto: El nombre del proyecto a migrar.
Por ejemplo,
WSADIEEJBProjectMigration.bat -e "C:\IBM\WID6\eclipse" -d "d:\my60workspace" -p "MyWBIEJBProject"
- Cuando abra
WebSphere
Integration Developer deberá renovar el proyecto EJB para obtener los archivos actualizados.
- Busque el archivo ibm-web-ext.xmi en el proyecto EJB. Si encuentra uno,
asegúrese de que la línea siguiente figure en el archivo bajo el elemento:
<webappext:WebAppExtension> element:
<webApp href="WEB-INF/web.xml#WebApp"/>
- Elimine el código de despliegue antiguo generado en 5.1. Vuelva a generar el código de despliegue siguiendo las directrices de
WebSphere
Application Server.
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.
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/
Verificar la migración de artefactos origen
Si la migración finaliza con una lista de errores, avisos y/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.
La página
siguiente se visualiza si se
han generado mensajes durante el proceso
de 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 y/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
empresarial 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 empresarial, 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.
A continuación se 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 del proceso de migración (para 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
- WebSphere Studio
Application Developer Integration Edition no aplicaba estrictamente la coherencia entre
los WSDL y otros artefactos de los proyectos.
WebSphere
Integration Developer es mucho más estricto y notificará incoherencias que no notificaba
WebSphere
Studio Application Developer Integration Edition (y también las que se ejecutaban en el
entorno de ejecución de
WebSphere
Business Integration Server Foundation sin ningún problema).
- Aunque
WebSphere
Studio Application Developer Integration Edition permitía varias definiciones idénticas
de Enlace y servicio de servicios Web (nombre y espacio de nombres),
WebSphere
Integration Developer no lo hace. Debe resolver estas duplicaciones
manualmente antes de la migración (en
WebSphere
Studio Application Developer Integration Edition) o después de la migración (en
WebSphere
Integration Developer). Por ejemplo, en
WebSphere
Studio Application Developer Integration Edition, todas las definiciones de servicio
generadas en los archivos WSDL con nombres diferentes (que terminan en _EJB, _JMS,
etc.) tenían este formato:
<service name="OrderProcessIntfcService">
Para
solucionar la duplicación, simplemente añada el tipo de enlace al atributo name. En el
caso del archivo *_EJB.wsdl, cambiaría a
<service name="OrderProcessIntfcServiceEJB">
Para el archivo *_JMS.wsdl, cambiaría a
<service name="OrderProcessIntfcServiceJMS">
Sin embargo, una vez cambiado este nombre, la exportación generada en
WebSphere
Integration Developer para utilizar este servicio también deberá cambiarse para que
utilice el nombre correcto.
- Este asistente de migración no puede manejar espacios de trabajo enteros de
WebSphere
Studio Application Developer Integration Edition. Está pensado para migrar un proyecto de servicio de
WebSphere
Studio Application Developer Integration Edition cada vez.
- El asistente
de migración no migra binarios de aplicaciones; solamente migra los artefactos origen que se encuentran en un proyecto
de servicio de
WebSphere
Studio Application Developer Integration Edition.
- Los beans de reglas de
negocio están obsoletos en
WebSphere
Process Server 6.x pero hay una opción durante la instalación de
WebSphere
Process Server para instalar el soporte de beans de reglas de negocio obsoletos Business Rule Beans de forma que se
ejecutarán "tal cual" en un servidor
WebSphere
Process Server 6.x. No hay soporte de herramientas para los beans de reglas de negocio
antiguos, y si desea que los artefactos de bean de reglas de negocio se compilen en las
herramientas, debe seguir la documentación de
WebSphere
Integration Developer para instalar las características obsoletas sobre el servidor de
pruebas WebSphere Process
Server 6.x incorporado y después añadir manualmente los archivo jar obsoletos
a la vía de acceso de clases del proyecto como jar externos. Debe utilizar las
herramientas de reglas comerciales nuevas disponibles en
WebSphere
Integration Developer para volver a crear las reglas de negocio nuevas correspondientes
de acuerdo a la especificación 6.x.
- El soporte de Mensajería ampliada está obsoleto en
WebSphere
Process Server 6.x, pero hay una opción durante la instalación de
WebSphere
Process Server para instalar el soporte para la Mensajería ampliada obsoleta de forma que
se ejecute "tal cual" en un servidor
WebSphere
Process Server 6.x. No hay soporte de herramientas para las funciones de Mensajería
ampliada antigua,
y si desea que los artefactos de la Mensajería ampliada antigua se
compilen en las herramientas, debe seguir la documentación de
WebSphere
Integration Developer para instalar las características obsoletas sobre el servidor de
pruebas
WebSphere
Process Server 6.x incorporado y después añadir manualmente los archivo jar obsoletos a
la vía de acceso de clases del proyecto como jar externos.
- El enlace de datos JMS estándar suministrado no proporciona acceso a propiedades de
cabecera JMS personalizadas. Debe escribirse un enlace de datos personalizado para que
los servicios SCA obtengan acceso a las propiedades de cabecera JMS personalizadas.
Limitaciones del modelo de programación SCA
- La especificación de SDO versión 1 no proporciona acceso a la matriz de bytes COBOL o C; esto
afectará a los que trabajan con segmentos múltiples de
IMS.
- La especificación de SDO versión 1 para la serialización no soporta redefiniciones COBOL ni
uniones C.
- Al rediseñar los artefactos origen de acuerdo con el modelo de programación SCA, tenga en
cuenta que el estilo WSDL de documento/literal acomodado (que es el estilo predeterminado para los
artefactos nuevos creados utilizando las herramientas de
WebSphere
Integration Developer) no soporta la sobrecarga de métodos. Los otros estilos WSDL todavía están
soportados por lo que es recomendable utilizar otro estilo/codificación de WSDL que no sea
documento/literal acomodado para estos casos.
- El soporte nativo para las matrices es limitado. Para invocar un servicio externo que
expone una interfaz WSDL con tipos soapenc:Array, debe crear una interfaz WSDL que defina
un elemento cuyo atributo "maxOccurs" sea mayor que uno (este es el procedimiento
recomendado para diseñar un tipo de matriz.)
Limitaciones técnicas del proceso de migración de BPEL
- Varias respuestas para una operación BPEL: en WebSphere Business
Integration Server Foundation un proceso de negocio podía tener una actividad de
recepción y varias actividades de respuesta para la misma operación. Si tiene un proceso de negocio con varias respuestas para la misma operación, asegúrese de que
si cualquiera de ellas tiene valores de cliente, todas las respuestas para esa operación tengan los
mismos valores de cliente ya que en 6.x solo se da soporte un conjunto de valores de cliente por respuesta de operación.
- Limitaciones de la migración de fragmentos de código Java
BPEL: el modelo de programación ha cambiado de modo significativo de
WebSphere
Studio Application Developer Integration Edition a
WebSphere
Integration Developer y no todas las API de
WebSphere
Studio Application Developer Integration Edition soportadas se pueden migrar directamente a las API de
WebSphere
Integration Developer correspondientes. Los fragmentos de código
Java
BPEL pueden contener cualquier lógica
Java
por lo que tal vez la herramienta de migración automática no pueda convertir todos los fragmentos de código
Java
al nuevo modelo de programación. La mayoría de las llamadas de API de fragmentos de código estándar
se migrarán automáticamente del modelo de programación de los fragmentos de código
Java de la
5.1 al modelo de programación de los fragmentos de código
Java de la
6.x. Las llamadas de API WSIF se migran a llamadas de API DataObject cuando es
posible. Las clases
Java
personalizadas que aceptan objetos WSIFMessage deberán migrarse manualmente para que acepten y
devuelvan objetos commonj.sdo.DataObject:
- API de metadatos WSIFMessage - Puede ser necesaria la
migración manual para algunos de los metadatos WSIFMessage y otras API de WSIF.
- API de EndpointReference/EndpointReferenceType: estas clases no se
migran automáticamente. Se necesita la migración manual ya que los métodos de
obtención/establecimiento de enlace de socio utilizan objetos commonj.sdo.DataObject en lugar de
los objetos com.ibm.websphere.srm.bpel.wsaddressing.EndpointReferenceType de 5.1.
- Tipos complejos con nombres duplicados: si una aplicación declara
tipos complejos (en WSDL o XSD) con espacios de nombres y nombres locales idénticos, o
espacios de nombres distintos pero nombres locales idénticos, es posible que los fragmentos de
código
Java
que utilizan estos tipos no se migren correctamente. Verifique los
fragmentos de código para ver que son correctos tras finalizar el asistente de migración.
- Tipos complejos con nombres locales idénticos a las clases Java
del paquete java.lang: si una aplicación declara tipos complejos (en WSDL o XSD) con nombres
locales idénticos a las clases del paquete java.lang de J2SE 1.4.2, es posible que los fragmentos de código
Java
que utilizan la clase java.lang correspondiente no se migren correctamente. Verifique los
fragmentos de código para ver que son correctos tras finalizar el asistente de migración.
- Variables BPEL de sólo lectura y lectura-escritura - En los
fragmentos de código
Java,
era posible establecer una variable BPEL en "sólo lectura", indicando que los cambios
efectuados en ese objeto no afectarían en absoluto al valor de la variable BPEL. También
era posible establecer una variable BPEL en "lectura-escritura", indicando que los
cambios efectuados en el objeto se reflejarían en la propia variable BPEL. A continuación
se muestran cuatro formas de acceder a un fragmento de código
Java
como de "sólo lectura" en un fragmento de código
Java
de BPEL 5.1:
getMyInputVariable()
getMyInputVariable(false)
getVariableAsWSIFMessage("MyInputVariable")
getVariableAsWSIFMessage("MyInputVariable", false)
A continuación se indican las dos formas de acceder a una variable BPEL como
de "lectura-escritura" en cualquier fragmento de código
Java
de BPEL 5.1:
getMyInputVariable(true)
getVariableAsWSIFMessage("MyInputVariable", true)
En la versión 6.x, el acceso
de sólo lectura y de lectura-escritura a las variables BPEL se maneja en función del
fragmento de código, lo que significa que puede añadir un comentario especial al
fragmento de código
Java
de BPEL para especificar si las actualizaciones de la variable BPEL deben descartarse o
conservarse una vez finalizada la ejecución del fragmento de código. Estos son los
valores de acceso por omisión para los tipos de fragmentos de código Java
de BPEL 6.x:
Actividad de fragmento de código Java de BPEL
Acceso por omisión: lectura-escritura
Alterar temporalmente el acceso por omisión con un comentario que contenga:
@bpe.readOnlyVariables names="variableA,variableB"
Expresión de fragmento de código Java de BPEL (utilizada en un tiempo de espera,
condición, etc.)
Acceso por omisión: sólo lectura
Alterar temporalmente el acceso por omisión con un comentario que contenga:
@bpe.readWriteVariables names="variableA,variableB"
Durante la migración,
estos comentarios se crearán automáticamente cuando se haya accedido a una variable
mediante un procedimiento que no sea por omisión en 6.x. En caso de que exista un
conflicto (es decir, que se haya accedido a la variable BPEL como "sólo lectura" y como
"lectura-escritura" en el mismo fragmento de código), se emitirá un aviso y el acceso se
establecerá en "lectura-escritura". Si recibe avisos de este tipo, asegúrese de
que establecer el acceso de la variable BPEL en "lectura-escritura" sea correcto en
su situación. Si no es correcto, debe corregirlo manualmente mediante el editor BPEL de WebSphere Integration Developer.
- Propiedades primitivas con múltiples valores en tipos complejos: en 5.1,
las propiedades con múltiples valores se representan mediante matrices del tipo de propiedad. Como tal, las llamadas para obtener y establecer la propiedad utilizan matrices. En 6.x, se utiliza java.util.List para esta representación. La migración automática gestionará todos los casos en que la propiedad con múltiples valores es algún tipo de objeto
Java,
pero si la propiedad es de tipo primitivo
Java
(int, long, short, byte, char, float, double y boolean), las llamadas para obtener y establecer toda la matriz no se
convierten.
En este caso la migración manual puede requerir la adición de un bucle para
envolver/desenvolver los primitivos en/de su clase de envoltura
Java
correspondiente (Integer, Long, Short, Byte, Character, Float, Double y Boolean) para su uso
en el resto del fragmento de código.
- Creación de instancias de las clases generadas que representan
tipos complejos: en 5.1, las clases generadas de tipos complejos definidos en una aplicación se
podían instanciar fácilmente en un fragmento de código
Java
mediante el constructor sin argumentos predeterminado. A continuación se muestra un ejemplo:
MyProperty myProp = new MyProperty();
InputMessageMessage myMsg = new InputMessageMessage();
myMsg.setMyProperty(myProp);
En 6.x, debe utilizarse una clase de fábrica especial para instanciar estos tipos, o
puede emplearse una instancia del tipo continente para crear el subtipo.
Si se ha definido una variable de proceso BPEL InputVariable con el tipo InputMessage, la versión
6.x del fragmento de código anterior sería:
com.ibm.websphere.bo.BOFactory boFactory=
(com.ibm.websphere.bo.BOFactory)
com.ibm.websphere.sca.ServiceManager.INSTANCE.locateService(
"com/ibm/websphere/bo/BOFactory");
commonj.sdo.DataObject myMsg =
boFactory.createByType(getVariableType("InputVariable"));
commonj.sdo.DataObject myProp =
myMsg.createDataObject("MyProperty");
El conversor de fragmentos de código intenta realizar este cambio, pero si el
orden en que se realizan las instanciaciones originales no sigue el patrón de primero el padre
y después el hijo deberá realizarse la migración manual (es decir, el conversor no intenta
reordenar de manera inteligente las sentencias de instanciación del fragmento de código).
- En
WebSphere
Business Integration Server Foundation 5.1, las referencias dinámicas se
representan como componentes de mensaje WSDL de tipo EndpointReferenceType o elemento
EndpointReference del espacio de nombres:
http://wsaddressing.bpel.srm.websphere.ibm.com
Tales referencias se migran al tipo de elemento service-ref estándar desde el espacio de nombres
de proceso de negocio estándar:
http://schemas.xmlsoap.org/ws/2004/03/business-process/
http://schemas.xmlsoap.org/ws/2004/08/addressing
Consulte la documentación del Editor BPEL para obtener instrucciones acerca de cómo importar
manualmente estas definiciones de esquema en el proyecto para que todas las referencias se
resuelvan adecuadamente.
- Tipo de mensaje de variable BPEL - Debe
especificarse un tipo de mensaje WSDL para todas las variables BPEL utilizadas en fragmentos de código
Java. Loa
fragmentos de código Java que acceden a variables BPEL
sin el atributo "messageType" especificado no pueden migrarse.
Avisos
Derechos restringidos de los usuarios del gobierno de los EE.UU.: utilización, duplicación o revelación restringidas
por el contrato GSA ADP Schedule Contract con
IBM
Corp.
Esta información se ha desarrollado para productos y servicios
ofrecidos en los EE.UU,
IBM
puede no ofrecer los productos, servicios o características tratados en esta documentación en otros países. El
representante local de
IBM
le puede informar acerca de los productos y servicios que actualmente están disponibles en su localidad. Las referencias hechas a productos, programas o servicios de IBM(R) 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 esta
documentación. La entrega 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 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, Japón
El párrafo siguiente no se aplica en el Reino Unido ni en ningún
otro país en el que tales disposiciones sean incompatibles con la legislación local:
INTERNATIONAL BUSINESS MACHINES CORPORATION SUMINISTRA ESTA PUBLICACIÓN "TAL
CUAL", SIN GARANTÍA DE NINGUNA CLASE, YA SEA EXPLÍCITA O IMPLÍCITA, INCLUIDAS, PERO
SIN LIMITARSE A ELLAS, LAS GARANTÍAS O CONDICIONES IMPLÍCITAS DE NO VULNERACIÓN, DE
COMERCIALIZACIÓN O IDONEIDAD PARA UN PROPÓSITO DETERMINADO. Algunas legislaciones no
contemplan la declaración de limitación de responsabilidad, 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 hecha en esta información a sitios Web no de IBM se
proporciona únicamente para su comodidad y no debe considerarse en modo alguno
como promoció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 de él con el fin de: (i) intercambiar la información entre los programas
creados independientemente y otros programas (incluido este) y (ii) utilizar mutuamente la información que se ha
intercambiado, deben ponerse en contacto con:
Intellectual Property Dept. for WebSphere Integration Developer
IBM Canada Ltd.
8200 Warden Avenue
Markham, Ontario L6G 1C7
Canada
Dicha información puede estar
disponible, sujeta a los términos y condiciones apropiados, incluyendo en algunos casos el pago de una cantidad.
El programa bajo licencia descrito en esta documentación 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 de 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.
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
pueden incluir 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 ilustra las técnicas de programación en diversas plataformas operativas. Puede copiar,
modificar y distribuir los programas de ejemplo de cualquier forma, sin tener que pagar a
IBM,
con intención de desarrollar, utilizar, comercializar o distribuir programas de aplicación que estén en conformidad con
la interfaz de programación de aplicaciones (API) de la plataforma operativa para la que están escritos los programas
de ejemplo. Los ejemplos no se han probado minuciosamente bajo todas las condiciones. Por lo tanto,
IBM
no puede garantizar ni dar por sentada la fiabilidad, la facilidad de mantenimiento ni el funcionamiento de los
programas. Usted puede copiar, modificar y distribuir los programas de ejemplo de cualquier forma, sin tener que pagar
a
IBM,
con el fin de desarrollar, utilizar, comercializar o distribuir programas de aplicación que estén en conformidad con
las interfaces de programación de aplicaciones (API) de IBM.
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:
(C) (el nombre de su empresa) (año). Algunas
partes de este código se derivan de programas de ejemplo de
IBM
Corp. (C) Copyright IBM Corp. 2000, 2007. 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 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 obtenga 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, WebSphere, Rational, DB2, Universal Database DB2, Tivoli, Lotus, Passport
Advantage, developerWorks, Redbooks, CICS, z/OS e IMS son marcas registradas de International Business Machines Corporation en Estados Unidos o en otros
países.
UNIX es una marca registrada de The Open Group en Estados Unidos o en otros países.
Java y todas las marcas registradas y logotipos basados en Java son marcas registradas de
Sun Microsystems, Inc. en Estados Unidos o en otros países.
Microsoft y Windows son marcas registradas de Microsoft Corporation en Estados Unidos o en otros países.
Linux es una marca registrada de Linus Torvalds en Estados Unidos o en otros países.
Adobe es
una marca registrada o marca comercial de Adobe Systems Incorporated en Estados Unidos o en otros países.
Otros nombres de empresas, productos o servicios pueden ser
marcas registradas o marcas de servicios de terceros.
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.
(C) Copyright IBM Corporation
2005, 2007. Reservados todos los derechos.