Utilizando el ruteo basado en contenido y JMS

Hola de nuevo por aqui...

Despues de dos semanas algo ajetreadas entre viajes cortos a la ciudad de pachuca, regresamos al trabajo con las pilas algo bajas, pero con el gusto de continuar con nuestra labor..

En el instituto tenemos sistemas de bastantes sabores... ¿cuantos? R= muchos :D, imperan dos ambientes: aplicaciones que se encuentran en la CD de mexico y monterrey , asi como aplicaciones regadas en las 32 delegaciones de la republica mexicana.

Hace aproximadamente un año nos pidieron el requerimiento de conectar un sistema que esta instalado individualmente en cada delegacion, tiene su servidor y esta completamente independiente...... con otro que se encuentra en el CENATI (centro nacional de tecnologias de informacion) de Monterrey, ventaja numero uno estaban desarrollados en Java (el central en Weblogic y los de las delegaciones en Websphere)....

El requerimiento puntual fue... entregar dictamentes a cada unidad de medicina familiar.. provenientes de el sistema central de salud en el trebajo...

El diseño final fue contener una cola JMS para cada una de las delegaciones y mediante el ruteo basado en contenido para realizar la entrega.... hubo quien sugirio publicar un webservice por cada delegacion para recibir.. en fin... y no es que sea malo.. pero para un ambiente completamente asioncrono las colas JMS funcionan a la perfecccion...

Como se puede ver en la imagen, el sistema de salud en el trabajo invoca de manera sincrona a un servicio web central, este se encarga de guardar el mensaje en una cola central asi como de transformar el mensaje... posteriormente existe un Message Driven Bean consumiendo de la cola central que se basa en el contenido ( Content Based Router, ) para entregar a la cola final que esta en MQ Series.

Algunas ventajas de este modelo: trabajo completamente asincrono, si algun aplicacion de medicina familiar esta abajo los mensajes quedan almacenados en su cola y sobretodo existe garantia de entrega.

Posteriormente hay que revisar algunas estrategias de consumo de colas JMS, porque no todo el codigo que se escribe para consumir es el mejor... ;)...

Por una integracion mejor, hasta la vista!!

Tuzo

competing consumers

Hola mis dos lectores!!!! otra vez por aqui dando lata :D

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

patterns in action ;)

De nuevo dando lata!!

Hace unas semanas llegando al trabajo enciendo mi compu y veo un correo en donde me indican que una de las interfaces que recibe dictamenes y los envia a un sistema medico NO estaba funcionando... tranquilamente entro al solaris y al ver el log... oh sorpresa!! .. mis threads estaban atorados y un alegre conjunto de mensajes me decia:

Mar 15, 2007 8:44:02 AM CST Error WebLogicServer BEA-000337 ExecuteThread: '14' for queue: 'weblogic.kernel.Default' has been busy fo
r "657" seconds working on the request "Http Request: /WSRecibeST1/recepcionST1.jws"

.. a lo que tranquilamente me di a la tarea de reiniciar mi servidor pensando que con eso se resolveria el problema y una vez levantado revisar que fue lo que paso... je je je ¡oh sorpresa! los alegres mensajes de mis threads seguian saliendo.... y pense "Pus si mi interfaz ha estado operando en casi un año sin problemas..." asi es Tuzo, pero no con el volumen que mandaron esos dias..

El diseño estaba de la siguiente manera:

... el proceso de envío de dictamenes envía un mensaje XML en formato HL7, el servicio de integracion transforma el Xml a un formato de Java y lo envia al endpoint del servicio RMI, ¿sencillo no?, en efecto pero con lo que no contaba, es que RMI necesita dos threads para procesar una peticion.. es decir por un thread atiende y en otro responde.. por lo que en el momento que me mandaron carga, mis threads de ejecucion se terminaron (tenía 15 :D) y RMI no me regresaba la respuesta hasta que no existiera un thread disponible.... asi que entre en un deadlock..

.. pues de alguna manera teniamos que resolver el problema: controlar el numero de peticiones al servicio RMI.

Revisando el libro Enterprise Integration Patterns, se encuentra un patron llamado Competing Consumers, pensando en aplicar este patron para controlar el numero de threds que envia datos al servicio RMI, nos empezo a llegar la luz.

Gustavo y su servilleta pensamos en utilizar la solucion de Aqualogic Service Bus para este caso.... buscando en la documentacion de ALSB encontramos dos cosas A) el patron throttling pattern que permite controlar el grado de concurrencia y B) el concepto WorkManager que define restricciones de carga en threads, asi que nos pusimos manos a la obra y juntando lo anterior mas unas cuantas colas JMS, el resultado quedo en lo siguiente:

... el servicio envia el mensaje a un proxy service, este lo almacena en una cola JMS y libera la conexion, posteriomente un suscriptor consume (de uno en uno) y ejecuta un business service que se encarga de enviar (uno a uno) a la interfaz del EAI para que esta envíe finalmente al servicio RMI. Para garantizar que nuestra solucion funcionaria en produccion, usamos jmeter para enviar 600 mensajes y respondio sin problemas, enviando todos los mensajes en 1 minuto al servicio final.. como veran, con esta solucion es posible controlar el numero de peticiones al servicio final mediante los WorkManagers.

Tambien pueden aplicar el patron Competing Consumers y tendrian el mismo efecto, en algun momento les comentare como este patron nos resolvio un problema al conectarnos con servicios Mainframe.

Pues esta fue la solucion aplicada..

Comentarios y sugerencias son bienvenidos.

Por una integracion mejor, hasta la vista

Tuzo