Procedimientos recomendados para el proceso de migración de WebSphere InterChange Server

Las siguientes directrices están destinadas al desarrollo de artefactos de desarrollo 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 para el desarrollo de soluciones de integración nuevas. El contenido existente puede no ajustarse a estas directrices. También 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 especifican las mejores prácticas para el desarrollo de artefactos de WebSphere InterChange Server en general. Su ámbito está limitado a aquellas consideraciones que pueden afectar a la facilidad de los artefactos que pueden migrarse en el futuro.

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 mejores prácticas para el desarrollo general de soluciones basadas en WebSphere InterChange Server para facilitar la migración futura:
  • Utilizar WebSphere InterChange Server para soluciones de integración de procesos automatizados en tiempo real
  • Documentar el diseño del sistema y los componentes
  • Utilizar las herramientas de desarrollo para editar los artefactos de integración
  • Aprovechar las mejores prácticas de definición de normas con las herramientas y fragmentos de código Java

Aunque pueda parecer obvio, es importante que las soluciones de integración se ajusten al modelo de programación y a la arquitectura suministrados por WebSphere InterChange Server. Ésta es más adecuada a las soluciones de integración de procesos automatizados en tiempo real. Asimismo, 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 recomendada que mejorará en gran medida la 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, es esencial utilizar 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.

Al desarrollar código Java dentro de plantillas de colaboración, correlaciones, programas de utilidad de código habituales y otros componentes, debe tener en cuenta varias consideraciones:
  • 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 para los artefactos. Estas API se indican con detalle en las guías de desarrollo de WebSphere InterChange Server. Aunque en muchos casos se suministrarán API de compatibilidad en WebSphere Process Server, sólo se incluirán las API publicadas. Aunque WebSphere InterChange Server tiene muchas interfaces internas que los desarrolladores pueden utilizar, no puede garantizarse que estén soportadas en el futuro.

Al diseñar la lógica comercial y las normas de transformación en correlaciones y plantillas de colaboración, asegúrese de utilizar 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. 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.

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 excelentes que respetar en general, pero serán pertinentes en el caso de la portabilidad.

Programas de utilidad de código comunes

Como se ha indicado anteriormente, 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 de 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.

Agrupaciones de conexiones de base de datos

Las agrupaciones de conexiones de base de datos definidas por usuario son muy ú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. Sin embargo, la forma de gestionar las conexiones y transacciones puede variar.

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.

Objetos comerciales

Las recomendaciones principales para el desarrollo de objetos comerciales son utilizar sólo las herramientas suministradas para configurar artefactos, utilizar tipos y longitudes de datos explícitos para los atributos de datos y utilizar sólo las API documentadas.

Los objetos comerciales de WebSphere Process Server se basan en SDO (Service Data Objects), que utilizan atributos de datos fuertemente tipificados. En los objetos comerciales 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, sea explícito en la especificación de tipos de datos.

Dado que los objetos comerciales 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 comercial de WebSphere Process Server están sujetos a las normas de XSD NCName, por lo que no debe utilizar espacios ni signos ":" en los nombres de atributos de objeto comercial. Los nombres de atributo de objeto comercial con espacios o signos ":" no son válidos en WebSphere Process Server. Redenomine los atributos de objetos comerciales 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.

De nuevo es importante, como se ha indicado anteriormente, 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.

Plantillas de colaboración

Muchas de las directrices descritas anteriormente 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 & 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. Como se ha indicado anteriormente, 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á.

No utilice caracteres especiales en nombres de propiedad de plantillas de colaboración. Estos caracteres especiales no son válidos en los nombres de propiedad BPEL a los que se migrarán. Redenomine las propiedades para eliminar estos caracteres especiales antes de la migración para evitar errores sintácticos en el BPEL generado por la migración.

No haga referencia a variables utilizando "this." Por ejemplo, en lugar de "this.inputBusObj" utilice "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. Por ejemplo, "Object myObject = null;" Asegúrese de que todas las variables se inicialicen durante la declaración antes de la migración.

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

Correlaciones

Muchas de las directrices descritas anteriormente 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 un objeto comercial hijo en una correlación, utilice una subcorrelación para los objetos comerciales 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 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.

Si utiliza una matriz en un objeto comercial, no puede basarse 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 & 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 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. Como se ha indicado anteriormente, 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.

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.

Las recomendaciones clave para las relaciones son utilizar sólo las herramientas suministradas para configurar los componentes relacionados y utilizar sólo las API publicadas para las relaciones dentro de los artefactos de integración.

Es importante utilizar 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.

Asimismo, 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 Diseñador de relaciones.

Como se ha indicado anteriormente, es importante utilizar sólo las API publicadas para las relaciones dentro de los artefactos de integración.

Clientes de infraestructura de acceso

No desarrolle clientes nuevos que adopten las API de interfaz IDL CORBA. Esto no estará soportado en WebSphere Process Server.
Tareas relacionadas
Verificar la migración de WebSphere InterChange Server
Trabajar con los errores de migración de WebSphere InterChange Server

Comentarios
(C) Copyright IBM Corporation 2005, 2006. Reservados todos los derechos.