Visión general del aislamiento de módulos y destinos

Al desarrollar módulos, identificará servicios que varios módulos pueden utilizar. Al reforzar los servicios de este modo se minimiza el ciclo de desarrollo y los costes. Si dispone de un servicio que muchos módulos utilizan, aisle los módulos de invocación del destino, de manera que si se actualiza el destino, el cambio al nuevo servicio sea transparente al módulo llamante. En este tema se contrasta el modelo de invocación sencilla y el modelo de invocación aislada y se proporciona un ejemplo de cómo puede resultar de utilidad el aislamiento. Aunque se describe un ejemplo específico, no es el único modo de aislar módulos de destinos.

Modelo de invocación sencilla

Al desarrollar módulos, puede utilizar servicios que se encuentren en otros módulos. Para hacer esto, puede importar el servicio al módulo y luego invocar a ese servicio. El servicio importado se "conecta" con el servicio exportado por el otro módulo, ya sea en WebSphere Integration Developer o enlazando el servicio en la consola administrativa. El modelo de invocación sencilla ilustra este modelo.
Figura 1. Modelo de invocación sencillaEn la ilustración se muestra una aplicación, MyModule que invoca a un servicio, ServiceA. La invocación señala a una interfaz de importación de la aplicación que se conecta con una interfaz de exportación en ServiceA de la aplicación, DifferentModule.

Modelo de invocación aislada

Para cambiar el destino de una invocación sin detener la invocación de módulos, puede aislar los módulos de invocación del destino de la invocación. Esto permite que los módulos continúen procesando mientras cambia el destino porque no está cambiando el módulo en sí sino el destino en sentido descendente. En el Ejemplo de aislamiento de aplicaciones se muestra cómo el aislamiento permite cambiar el destino sin afectar al estado del módulo de invocación.

Ejemplo de aislamiento de aplicaciones

Utilizando el modelo de invocación sencillo, varios módulos que invocan al mismo servicio se parecerían bastante a varias aplicaciones que invocan a un solo servicio . APPA, APPB y APPC invocan a CalculateFinalCost.
Figura 2. Varias aplicaciones que invocan a un solo servicioEn la ilustración se muestran varios módulos que invocan directamente a CalculateFinalCost.
El servicio proporcionado por CalculateFinalCost debe actualizarse de manera que los nuevos costes se reflejen en todos los módulos que utilizan el servicio. El equipo de desarrollo crea y prueba un nuevo servicio UpdatedCalculateFinal para incorporar los cambios. Está preparado para implantar el nuevo servicio en producción. Sin el aislamiento, tendría que actualizar todos los módulos que invocan a CalculateFinalCost para invocar a UpdateCalculateFinal. Con el aislamiento, sólo tiene que cambiar el enlace que conecta el módulo de almacenamiento intermedio con el destino.
Nota: Con el cambio del servicio de esta manera se permite continuar para proporcionar el servicio original a otros módulos que puedan necesitarlo.
Utilizando el aislamiento, puede crear un módulo de almacenamiento intermedio entre las aplicaciones y el destino (consulte Modelo de invocación aislada que invoca a UpdateCalculateFinal).
Figura 3. Modelo de invocación aislada que invoca a UpdateCalculateFinalEn la ilustración se muestra ModA, ModB y ModC que invocan a CalculateFinalCost. La llamada se resuelve en la aplicación BufferMod que contiene un servicio denominado CalculateFinalCost. Este servicio sólo apunta al CalculateFinalCost real de la aplicación ActualMod.
Con este modelo, los módulos de invocación no cambian, sólo tiene que cambiar el enlace de la importación del módulo de almacenamiento intermedio al destino (consulte Modelo de invocación aislada que invoca a UpdatedCalculateFinal).
Figura 4. Modelo de invocación aislada que invoca a UpdatedCalculateFinalLa ilustración es similar a la anterior con el enlace de CalculateFinalCost en BufferMod que señala a UpdateFinalCost.
Si el módulo de almacenamiento intermedio invoca al destino de forma síncrona, cuando reinicia el módulo de almacenamiento intermedio (ya sea un módulo de mediación o un servicio para un módulo de empresa) los resultados devueltos a la aplicación original proceden del nuevo destino. Si el módulo de almacenamiento intermedio invoca al destino de forma asíncrona, los resultados devueltos a la aplicación original proceden del nuevo destino en la siguiente invocación.
Información relacionada
Cambio de destinos

Condiciones de uso |


(c) Copyright IBM Corporation 2005, 2006.
Este centro de información está basado en tecnología Eclipse (http://www.eclipse.org)