Cuando hablamos de integrar aplicaciones se nos viene a la menta los WebServices ya que es una forma simple de comunicar dos sistemas independientes sin importar la tecnología ya que es una solución muy simple, limpia y ademas son un estándar.
Una solución de integración por servicios quedaría algo a sí.
En la siguiente figura podemos apreciar que la aplicación A se comunica con la aplicación B a través de un WebService. Este diseño funciona pero no es lo suficiente robusto como para soportar si la aplicación B queda fuera de linea por alguna razón.
Imagines el escenario en donde un la aplicación B queda fuera de linea, lo cual se vería a sí
La invocación fallaría por lo que tendríamos dos escenarios
- La aplicación A continua sin importar que B este fuera de linea
- La aplicación A tendría que cancelar la operación que estuviera realizando debido a que es necesario que B reciba la petición.
Para solucionar este tipo de problemas podemos utilizar colas de mensajes(Queue) para encolar los mensajes y ser atendidos cuando la aplicación B pueda, esto incluye que si queda fuera de linea los mensajes son guardados hasta que B entra en linea nuevamente.
Un escenario con una cola de mensajes quedaría a sí.
En el siguiente escenario la aplicación A en vez de comunicarse directamente con la aplicación B dejara su mensaje en una cola de mensajes y no le interesara si B esta en linea o no, Incluso no le interesa que aplicación procese la solicitud logrando un desacoplamiento total. Imaginemos que la aplicación B queda obsoleta y que metemos una aplicación C la cual respeta el formato del mensaje de A, esto dará como resultado que a la aplicación A no le interesara quien procese la petición siempre y cuando sea procesada. Sin embargo esta solución tiene un gran detalle y es que al comunicarnos con colas de mensaje JMS solo se podrá hacer entre aplicaciones Java.
Para solucionar el problema de comunicación con aplicaciones no Java se puede utilizar una pequeña variante del diseño anterior.
Podemos crear un Proxy el cual se encargue de exponer un servicio que lo único que haga sea dejar el mensaje en la cola de mensajes. para esto podemos utilizar herramientas diseñadas para la virtualización de servicios como lo son los Enterprice Service Bus. De esta forma si A es una aplicación .NET y B java ya no importara por que la comunicación sera a través de WebServices.
Espero que estas soluciones les sean de utilidad.
Buen post sobre este tema de JMS. Justamente la aplicación de JMS ayuda a cumplir de otra manera con el pattern: ‘Reliable Messaging’, para que de alguna manera ante una falla en la comunicación entre la app#1 y app#2 (considerándolos como servicios HTTP), se asegurará que el mensaje se recepcionará si o si por la app#2, ya que le mensaje será guardado el tiempo que sea necesario en la JMS Queue. Lo que si creo que a nivel gráfico en la arquitectura debió de considerarse un servicio MDB intermedio que esté a la escucha del mensaje entre la Queue y app#2.
Muy interesante tu comentario, releable messaging es otra alternativa y lo podríamos usar incluso en una arquitectura mucho robusta. Aunque en lo personal yo tengo una filosofía para usar jms normalito o Releable messaging, y es que esta la uso cuando una de dos: son mensaje súper críticos o el destinatario de nuestros mensajes están fuera de nuestro alcance, es decir que son aplicaciones de terceros en donde yo no puedo estar seguro de su disponibilidad y me inclinaría por jms cuando los mensajes son transmitidos entre aplicaciones de mi arquitectura en donde yo estoy seguro que las aplicaciones estarán disponibles la mayoria del tiempo y si llegaran a fallar yo me enteraría.
Con respecto lo del MDB en realizada yo asumo que en ambos aplicativos existe un MDB o un simple JMS consumer.
¿que opinas¿