Hace mas de año y medio (o quiza dos :D) cuando el proyecto de interoperabilidad empezo a tener mayor credibilidad en nuestra coordinacion (convencer.... sigue siendo un trabajo harto dificil, tema de otro post :D), nos llegaron una serie de solicitudes para realizar integracion con aplicaciones escritas en COBOL dentro del IBM Mainframe....ejemplificaré el caso de la consulta de los datos de un asegurado.
Teniamos (y seguimos teniendo) una serie de restricciones para el uso de esos sistemas, una de ellas quizá la que motivo este post, es que los usuarios que nos proporcionan para el acceso al sistema en COBOL NO son multisesion.
El resumen de restricciones significativas en el diseño son:
+ Numero limitado de usuarios para consulta, p.e. 10 usuarios
+ La interfaz debe de ser sincrona
+ Los usuarios no son multisesion
+ El usuario COBOL sera revocado, si el sistema en COBOL detecta que se han tratado de conectar el usuario dos veces en el mismo periodo de tiempo
Bien, pues nuevamente recurriendo al libro enterprise integration patterns, encontramos el patron competing consumers.
Como podran ver en la documentacion, este patron permite compartir una Cola JMS entre varios consumidores, de manera que puedes controlar el numero de consumidores y ejecutar tareas en paralelo por cada consumo de mensaje. De esta manera atacamos la restriccion del numero limitado de usuarios, asi como la garantia de que solo el usuario este firmado en un mismo instante de tiempo dentro de la aplicacion COBOL.
El diseño final quedo de la siguiente manera:
Paso 0: Cuando se arranca el servidor, se cargan las startup classes, en las cuales se levantan los N numero de threads de acuerdo al numero de usuarios con los que contemos, en la base de datos se encuentran las contraseñas para cada usuario.
Paso 1: El web service recibe la peticion y genera el mensaje que se enviara a la cola JMS
Paso 2: El web service genera una queue temporal en la cual recibira la respuesta
Paso 3: El Web service agrega al mensaje el objeto de la cola temporal y publica el mensaje en la cola JMS
Paso 4: El Web service se suscribe a la cola temporal que genero en espera de la respuesta
Paso 5: El thread que este disponible recibe la peticion y con las clases de negocio descompone el mensaje para enviarlo via Iway 3270 al mainframe
Paso 6: Mediante el adaptador se navega en la aplicacion y se obtiene el resultado de negocio
Paso 7: El thread obtiene el objeto de la cola temporal en donde va a depositar la respuesta, genera el mensaje de regreso y lo publica a la cola temporal
Paso 8: El web service obtiene el mensaje de su cola temporal suscrito y procesa la salida final al usuario.
Listo!
Pues asi es como resolvimos el problema.. y se puso en accion el patron competing consumers... de aqui surgio un nuevo rol dentro de nuestra area... el GSWD = Green Screen Wrapper Developer jejejeje
Cualquier comentario bienvenido..
Por una integracion mejor, hasta la vista.
Saludos !!!
Tuzo
