Encontre este blog de una persona llamada Jesus Rodriguez
Me llama la atencion el alto nivel tecnico que tiene, y la cantidad de temas de los que habla
Mostrando las entradas con la etiqueta integration. Mostrar todas las entradas
Mostrando las entradas con la etiqueta integration. Mostrar todas las entradas
lunes, 14 de julio de 2008
martes, 6 de noviembre de 2007
La importancia de los contratos
Hace unos dias en el trabajo me encomendaron la tarea de trabajar con unos compañeros que deseaban exponer unos servicios de Abastecimiento de medicamentos a sus proveedores....
Ellos ya habian avanzado un poco y me comentaban "Ya tenemos desarrollados unos WebServices", a lo que les pedi que me pasaran su WSDL
Al echarle un vistazo a ese documento me encontre algo como lo siguiente (entre otras cosas):
como operacion de entrada:
s:element name="ObtenerOrdenes"
como parametro:
element minOccurs="0" maxOccurs="1" name="SQL" type="s:string"
como respuesta:
s:any
Ok veamos que tenemos. El nombre OBTENERORDENES de entrada me suena a negocio hasta ahi todo va bien, el problema viene en el parametro que estan pasando se llama SQL, que por el solo nombre me pone a pensar que estan pasando sentencias de SQL para hacer la consulta (lo cual deja abierto al cliente a poner cualquier cosa dentro de la consulta)
Luego veamos la respuesta, si vemos regresa un Any (Que los que han leido el blog, siempre nos oponemos al uso de ANY como resultado o entrada) que cuando les pregunte me dijeron coloquialmente que ahi regresaban el "ResulSet" ajale!!! osea que si regresan la consulta tal cual de su base de datos.... y para finalizar en el servicio no hay ningun mensaje que indique los errores que pueden ocurrir.
Bien ya no pongo los demas metodos, porque solo estos me permiten ejemplificar la importancia de manejar un buen contrato.
Al diseñar un contrato de negocio de un servicio (independientemente si lo vas a hacer con: Web Services, RMI, COM, o palomas mensajeras) es muy importante definir los mensajes que estatas intercambiando entre el servicio, es decir, basicamente es constuir un layout (que tenga nombres, tipos de datos, tamaño y si es obligatorio el campo) de las ENTRADAS, SALIDAS y MENSAJES DE ERROR.
Asi de sencillo, en verdad utilizar esta practica nos ayudado mucho cuando tratamos de integrar aplicaciones.
Saludos
Tuzo
Ellos ya habian avanzado un poco y me comentaban "Ya tenemos desarrollados unos WebServices", a lo que les pedi que me pasaran su WSDL
Al echarle un vistazo a ese documento me encontre algo como lo siguiente (entre otras cosas):
como operacion de entrada:
s:element name="ObtenerOrdenes"
como parametro:
element minOccurs="0" maxOccurs="1" name="SQL" type="s:string"
como respuesta:
s:any
Ok veamos que tenemos. El nombre OBTENERORDENES de entrada me suena a negocio hasta ahi todo va bien, el problema viene en el parametro que estan pasando se llama SQL, que por el solo nombre me pone a pensar que estan pasando sentencias de SQL para hacer la consulta (lo cual deja abierto al cliente a poner cualquier cosa dentro de la consulta)
Luego veamos la respuesta, si vemos regresa un Any (Que los que han leido el blog, siempre nos oponemos al uso de ANY como resultado o entrada) que cuando les pregunte me dijeron coloquialmente que ahi regresaban el "ResulSet" ajale!!! osea que si regresan la consulta tal cual de su base de datos.... y para finalizar en el servicio no hay ningun mensaje que indique los errores que pueden ocurrir.
Bien ya no pongo los demas metodos, porque solo estos me permiten ejemplificar la importancia de manejar un buen contrato.
Al diseñar un contrato de negocio de un servicio (independientemente si lo vas a hacer con: Web Services, RMI, COM, o palomas mensajeras) es muy importante definir los mensajes que estatas intercambiando entre el servicio, es decir, basicamente es constuir un layout (que tenga nombres, tipos de datos, tamaño y si es obligatorio el campo) de las ENTRADAS, SALIDAS y MENSAJES DE ERROR.
Asi de sencillo, en verdad utilizar esta practica nos ayudado mucho cuando tratamos de integrar aplicaciones.
Saludos
Tuzo
miércoles, 12 de septiembre de 2007
Entre change management y pantallas verdes
Quizás este post debería estar más del lado de Tuzoftware .... Pero se vale... ;)
¿cuantas veces les ha tocado hacer un cambio en una aplicación? ¿Cuantas veces pensamos en las aplicaciones que se verán afectadas cuando cambiamos algo? ¿Quienes de nosotros tenemos un control de nuestras aplicaciones así como las dependencias que tenemos con otros sistemas?
¿Cuantas veces no les ha pasado que alguna área cambia versión de aplicación y las nuestras dejan de funcionar correctamente? nunca !!.. que bien!!! ... pero a los que nos ha pasado eso y fuera de los dolores de cabeza, a los jefes esperando, el tiempo encima.... todo, todo es desesperante.......... ahora combinen esa situación con una solución de integración mmm digamos ..... Mainframe si Mainframe, pantallas verdes, screen scraping, emuladores 3270... ¿Interesante escenario?
La finalidad de este post es tratar de mostrar una de las debilidades pienso yo, que existe en la integración de aplicaciones basada en captura de pantallas o screen scraping. Cabe resaltar que este tipo de integración tiene una ventaja importante: no es intrusivo en las aplicaciones a las que se trata de integrar.
Aquí en la empresa, tenemos varias interfaces basadas en este estilo de integración (échale un vistazo a esta liga ); como veras nosotros utilizamos Iway Telnet 3270, que es una serie de APIs que permiten interactuar con las pantallas verdes del mainframe... bien pues el punto flaco de estas interfaces es que están altamente acopladas por decirlo de alguna manera a las coordenadas, quien ha trabajado alguna vez con COBOL sabe de que le estoy hablando...
Bajo este esquema hasta un guión"-" te puede afectar (y mas si lo agregan de un día a otro :S, ahh y en la noche), sí, literalmente un guión te puede afectar.... eso fue lo que nos paso recientemente... se agrego un carácter a una pantalla de una aplicación dentro del mainframe y esto ocasiono que se movieran las posiciones de los campos, es decir, si para mi el campo 76 era NSS, ahora se había recorrido hasta la 78.... el punto delicado aquí es que la producción estaba parada mientras se detectaba el error, una vez que se detecto se dio marcha atrás a la versión de la aplicación mainframe....... mientras todo esto ocurría la operación se detuvo por al rededor de 3 horas...
Se aplico el cambio tal y como se debió de hacer desde un principio, es decir nos colocaron la versión de la aplicación mainframe en DESARROLLO hicimos los ajustes en nuestra interfase y liberamos a la par las nuevas versiones...
Todo el cuento anterior se pudo evitar teniendo un buen CONTROL DE CAMBIOS... se escucha tan sencillo y a veces trillado cuando nos hablan de esto en CMM, ITIL, RUP, en lo que ustedes quieran.... pero créanme que es muy importante...
Para muestra basta un botón... ¿recuerdas cuantos millones perdió TELCEL hace unos meses debido a un problema en su sistema?
Por una integración mejor, hasta la vista!!!
Tuzo
miércoles, 6 de junio de 2007
Software Factories & SOA
El concepto de Software Factories, planteado por Jack Greenfield plantea un modelo para construir software a partir de combinar modelos, herramientas, patrones y frameworks que permitan automatizar el desarrollo de software. Este diagrama que pongo, es la ruta de lectura del libro
La idea es, en lugar de poner en documentos todo el proceso, hacerlo vivir por medio de un software factory.
Es posible hablar del concepto de un software factory que permita automatizar el proceso de implantar un sistema de nomina o inventario. Es como dar una plantilla de un proceso y ajustarlo al punto en particular. Este concepto puede tumbar a los ERPs facilmente, o mejor, ojala los gigantes de los ERPs lo pudieran entender
Pero voy a un punto interesante, y continuando mi entrada de "ideas, ideas"
Estaba pensando ultimamente en un IDE que permitiera completar todo el ciclo de SOA, es decir, con un wizard que funcione asi
1. Tomar una aplicación existente de tu organización y hacer que se convierta en un servicio
(dar next)
2. Seleccionar, la infraestructura de SOA en la que va a ser publicado:
+ Como servicio del ESB
+ Como dato del ISB (information service bus)
+ Como regla de negocio del Rule Engine Broker
+ Como metadato del Registro UDDI
+ Como documento del repositorio documental
+ Como servicio de presentacion (mashup) del portal
+ Como proceso de negocio en el repositorio del BPM
(seleccione uno o mas)
3. Seleccionar las funciones de la aplicación que van a ser exportadas
4. Opciones avanzadas, personalización por cada tipo de servicio a ser publicado
5. Dar Finish para generar servicios
¿Que facil suena?
Ya me imagino la complejidad del pseudocaso de uso que acabo de narrar. De entrada el IDE va a necesitar varios GB de RAM para ejecutarse
Creo que la idea no debe ir por ahi
Cada opcion del "Wizard" que indico, equivale a un proceso de desarrollo para generar componentes de integración. En este blog hemos hablado de los antipatrones, y por supuesto hay patrones para construir dichos componentes
Entonces, por que no hacer un software factory por cada tipo de servicio, es decir, por dominio del problema y que plasme los patrones, frameworks que hemos hablado
Cada software factory, al ser una plantilla puede irse ajustando por cada tipo de aplicación que está integrando
Y el software factory ya ajustado, arrojaria distintos tipos de componentes de integración
Asi ya no son necesarios los wizards
Y ahora piensean, los software factories tienen como caracteristica el que se pueden ensamblar entre ellas, se puede hacer un pipeline de factories y se crean software factories compuestas
Es decir, se puede hacer todo un proceso de desarrollo de servicios de integración a partir de software factories
¿Ya esta la visión, ahora quien empieza a concretar?
La idea es, en lugar de poner en documentos todo el proceso, hacerlo vivir por medio de un software factory.
Es posible hablar del concepto de un software factory que permita automatizar el proceso de implantar un sistema de nomina o inventario. Es como dar una plantilla de un proceso y ajustarlo al punto en particular. Este concepto puede tumbar a los ERPs facilmente, o mejor, ojala los gigantes de los ERPs lo pudieran entender
Pero voy a un punto interesante, y continuando mi entrada de "ideas, ideas"
Estaba pensando ultimamente en un IDE que permitiera completar todo el ciclo de SOA, es decir, con un wizard que funcione asi
1. Tomar una aplicación existente de tu organización y hacer que se convierta en un servicio
(dar next)
2. Seleccionar, la infraestructura de SOA en la que va a ser publicado:
+ Como servicio del ESB
+ Como dato del ISB (information service bus)
+ Como regla de negocio del Rule Engine Broker
+ Como metadato del Registro UDDI
+ Como documento del repositorio documental
+ Como servicio de presentacion (mashup) del portal
+ Como proceso de negocio en el repositorio del BPM
(seleccione uno o mas)
3. Seleccionar las funciones de la aplicación que van a ser exportadas
4. Opciones avanzadas, personalización por cada tipo de servicio a ser publicado
5. Dar Finish para generar servicios
¿Que facil suena?
Ya me imagino la complejidad del pseudocaso de uso que acabo de narrar. De entrada el IDE va a necesitar varios GB de RAM para ejecutarse
Creo que la idea no debe ir por ahi
Cada opcion del "Wizard" que indico, equivale a un proceso de desarrollo para generar componentes de integración. En este blog hemos hablado de los antipatrones, y por supuesto hay patrones para construir dichos componentes
Entonces, por que no hacer un software factory por cada tipo de servicio, es decir, por dominio del problema y que plasme los patrones, frameworks que hemos hablado
Cada software factory, al ser una plantilla puede irse ajustando por cada tipo de aplicación que está integrando
Y el software factory ya ajustado, arrojaria distintos tipos de componentes de integración
Asi ya no son necesarios los wizards
Y ahora piensean, los software factories tienen como caracteristica el que se pueden ensamblar entre ellas, se puede hacer un pipeline de factories y se crean software factories compuestas
Es decir, se puede hacer todo un proceso de desarrollo de servicios de integración a partir de software factories
¿Ya esta la visión, ahora quien empieza a concretar?
miércoles, 9 de mayo de 2007
Entre servicios te veas
En una prueba de integración entre una aplicación .NET y otra desarrollada en Java nos apareció este mensaje:
¿Qué tiene de malo? (aparte de algunas faltas de ortografía) Son dos servicios que están intercambiando mensajes entre sí. No tienen interacción con el usuario, así que este tipo de mensajes, descriptivos y detallados, son completamente desaprovechados en este contexto.
Entonces ¿cuál es el modo correcto de devolver errores en este caso? No sé cual sea el modo correcto. Lo que a mi me gusta es el estilo de AppExchange Web Service API.
AppExchange (anteriormente conocida como Salesforce) es una empresa que ofrece software as a service (SaaS), en particular un CRM que compite directamente contra los grandes: Siebel, SAP y otros. Les ha ganado una gran tajada del mercado y sigue abriendo áreas de oportunidad. La API que comento la ofrecen mediante servicios web y tiene la funcionalidad de agregar, actualizar, borrar y buscar items de su mega repositorio de datos.
Así, en esas operaciones obviamente se envían y devuelven resultados en un contexto de integración de servicios. ¿Cómo le hacen? Va la referencia del API:
Tenemos la llamada create que recibe un arreglo de sObjects (tipo nativo de AppExchange) y como resultado devuelve un arreglo de objetos SaveResult. Ahora veamos SaveResult:
Nos devuelve un objeto con el identificador único (idField), una bandera de éxito o fracaso (successField) y un arreglo de objetos Error, igualmente veamos:
En fieldsField tenemos el o los nombres de los campos que provocaron el error; messageField es el texto descriptivo del error y finalmente statusCodeField que es el código que identifica el error dentro de un catálogo disponible en el WSDL del servicio.
Si bien tenemos un texto descriptivo, tenemos otras referencias (statusCodeField, successField) que nos permiten atender el problema y darle solución dentro de un contexto de integración.
A mi parecer es la falta de comprensión de los escenarios en los que se trabaja lo que provoca este tipo de diseños. Ya se requiere cambiar el modelo y empezar a modelar servicios. En algún momento habrá un servicio que se encargue de interactuar con el usuario y habrá que darle la suficiente información para que resuelva los problemas que lleguen a aparecer.
Por eso, entre servicios te veas, comportate como un servicio.
Finito.
Exito: 0
Código Error: 100
Desc. Error: mx.gob.imss.sigoi.quejaVerbal.exception.ValidaCampoException:
El campo Calidad de la persona que se comunica es requerido.
El campo Nombre de la persona que se comunica es requerido.
El campo Apellido paterno de la persona que se comunica es requerido.
El campo Lada de teléfono particular de la persona que se comunica tiene que ser numérico.
El campo Lada de teléfono particular de la persona que se comunica tiene una longitud no valida, menor a 2 Caracteres
El campo Teléfono particular de la persona que se comunica tiene que ser numérico.
El campo Teléfono particular de la persona que se comunica tiene una longitud no valida, menor a 8 Caracteres
El campo Teléfono celular de la persona que se comunica tiene que ser numérico.
El campo Teléfono celular de la persona que se comunica tiene una longitud no valida, menor a 12 Caracteres
El campo Correo electrónico de la persona que se comunica no tiene un formato adecuado
Se tiene que incluir al menos un medio de contacto valido de la persona que se
comunica: Lada y número de teléfono particular, número de teléfono celular, correo electrónico, o dirección completa
Es necesario capturar el NSS de la persona que se comunica
Es necesario capturar el NSS de la persona que solicita el servicio
El campo Calidad de la persona que solicita el servicio es requerido.
El campo Teléfono celular del usuario que solicita el servicio tiene que ser numérico.
El campo Teléfono celular del usuario que solicita el servicio tiene una longitud no valida, menor a 12 Caracteres
El campo Entidad federativa del usuario que solicita el servicio tiene que ser numérico.
El campo Entidad federativa del usuario que solicita el servicio no es un valor válido de catálogo
El campo Clasificación de la solicitud del planteamiento tiene que ser numérico.
El campo Clasificación de la solicitud del planteamiento no es un valor válido de catálogo
El campo Tema del planteamiento tiene que ser numérico.
El campo Tema del planteamiento no es un valor válido de catálogo
El campo Subtema del planteamiento tiene que ser numérico.
El campo Subtema del planteamiento no es un valor válido de catálogo
El campo Delegación de Adscripción del planteamiento no es un valor válido de catálogo
El campo Unidad Medica de Adscripción del planteamiento tiene que ser numérico.
El campo Unidad Medica de Adscripción del planteamiento no es un valor válido de catálogo
El campo Delegación o UMAE involucrada en la gestión o queja del planteamiento tiene que ser numérico.
El campo Delegación o UMAE involucrada en la gestión o queja del planteamiento no es un valor válido de catálogo
El campo Subdeleación y/o Unidad involucrada en la gestión o queja del planteamiento tiene que ser numérico.
El campo Subdeleación y/o Unidad involucrada en la gestión o queja del planteamiento no es un valor válido de catálogo
¿Qué tiene de malo? (aparte de algunas faltas de ortografía) Son dos servicios que están intercambiando mensajes entre sí. No tienen interacción con el usuario, así que este tipo de mensajes, descriptivos y detallados, son completamente desaprovechados en este contexto.
Entonces ¿cuál es el modo correcto de devolver errores en este caso? No sé cual sea el modo correcto. Lo que a mi me gusta es el estilo de AppExchange Web Service API.
AppExchange (anteriormente conocida como Salesforce) es una empresa que ofrece software as a service (SaaS), en particular un CRM que compite directamente contra los grandes: Siebel, SAP y otros. Les ha ganado una gran tajada del mercado y sigue abriendo áreas de oportunidad. La API que comento la ofrecen mediante servicios web y tiene la funcionalidad de agregar, actualizar, borrar y buscar items de su mega repositorio de datos.
Así, en esas operaciones obviamente se envían y devuelven resultados en un contexto de integración de servicios. ¿Cómo le hacen? Va la referencia del API:
SaveResult[] = sfdc.create(sObject[] sObjects);
Tenemos la llamada create que recibe un arreglo de sObjects (tipo nativo de AppExchange) y como resultado devuelve un arreglo de objetos SaveResult. Ahora veamos SaveResult:
private Error[] errorsField;
private string idField;
private bool successField;
Nos devuelve un objeto con el identificador único (idField), una bandera de éxito o fracaso (successField) y un arreglo de objetos Error, igualmente veamos:
private string[] fieldsField;
private string messageField;
private StatusCode statusCodeField;
En fieldsField tenemos el o los nombres de los campos que provocaron el error; messageField es el texto descriptivo del error y finalmente statusCodeField que es el código que identifica el error dentro de un catálogo disponible en el WSDL del servicio.
Si bien tenemos un texto descriptivo, tenemos otras referencias (statusCodeField, successField) que nos permiten atender el problema y darle solución dentro de un contexto de integración.
A mi parecer es la falta de comprensión de los escenarios en los que se trabaja lo que provoca este tipo de diseños. Ya se requiere cambiar el modelo y empezar a modelar servicios. En algún momento habrá un servicio que se encargue de interactuar con el usuario y habrá que darle la suficiente información para que resuelva los problemas que lleguen a aparecer.
Por eso, entre servicios te veas, comportate como un servicio.
Finito.
martes, 1 de mayo de 2007
Enterprise Information Integration
Hola mis queridos dos lectores!, de nuevo dando lata
Antes de comenzar, quiero agradecer nuevamente al Mtro. Heriberto Garcia por haberme invitado al congreso de TICs en la hermosa ciudad de Pachuca, así tambien a los asistentes que tuve en la platica relacionada con el ESB, en verdad fue una bonita experiencia, en breve publicare el codigo del ejemplo para que le echen un vistazo...
Bueno pues zapatero, a tus zapatos.... hoy en dia hemos escuchado acerca del termino Software Oriented Architecture, una vision arquitectonica que esta tomando un auge importante, aunque no todas las organizaciones estan preparadas aun para dar un paso hacia SOA (que ojo, SOA no es solo web services... ese es tema de otro post).
..una vision que hemos adoptado en el trabajo es es la siguiente: SOA = SODA + EII + BPM+ Registro + ESB y agregare cultura..
Esos temas los iremos tocando poco a poco, hoy hablare de el Enterprise Information Integration, ¿que es? bien... el la idea principal de EII, es que podemos crear un Modelo Virtual de Datos a partir de una fuente fisica, a estos servicios se les conoce como Data Services, esto es muy interesante ya que puedes exponer una fuente de datos como un servicio.
Una de las partes que me llama la atencion del EII, es que puedes federar informacion, es decir, puedes generar multiples modelos fisicos (Base de Datos, XML, File, Web Services) y mediante un modelo Logico puedes generar una sola vista a los datos, esto es muy interesante ya que modelas apartir de tus metadatos, no de las fuentes fisicas.
Algunos ejemplos que vienen a la mente, catalogos comunes, multiples bases de datos accesadas mediante un data service, federacion de multiples fuentes de datos, en fin.
En el trabajo tenemos el Aqualogic Data Services, actualmente estamos en el proceso de explotacion de la herramienta, en breve expondre los casos de uso que estamos echando a andar.
Aqui les dejo unas ligas interesantes acerca de este tema:
EII helps BI adapt to SOA
when to use EII
Understanding the Service Lifecycle within a SOA: Run Time
Espero que esta introduccion a los EIIs les sea de utilidad, estare publicando mas cosas acerca de este tema.
Comentarios, criticas y aportaciones bienvenidas.
Por una integracion mejor, hasta la vista!!
Tuzo.
Antes de comenzar, quiero agradecer nuevamente al Mtro. Heriberto Garcia por haberme invitado al congreso de TICs en la hermosa ciudad de Pachuca, así tambien a los asistentes que tuve en la platica relacionada con el ESB, en verdad fue una bonita experiencia, en breve publicare el codigo del ejemplo para que le echen un vistazo...
Bueno pues zapatero, a tus zapatos.... hoy en dia hemos escuchado acerca del termino Software Oriented Architecture, una vision arquitectonica que esta tomando un auge importante, aunque no todas las organizaciones estan preparadas aun para dar un paso hacia SOA (que ojo, SOA no es solo web services... ese es tema de otro post).
..una vision que hemos adoptado en el trabajo es es la siguiente: SOA = SODA + EII + BPM+ Registro + ESB y agregare cultura..
Esos temas los iremos tocando poco a poco, hoy hablare de el Enterprise Information Integration, ¿que es? bien... el la idea principal de EII, es que podemos crear un Modelo Virtual de Datos a partir de una fuente fisica, a estos servicios se les conoce como Data Services, esto es muy interesante ya que puedes exponer una fuente de datos como un servicio.
Una de las partes que me llama la atencion del EII, es que puedes federar informacion, es decir, puedes generar multiples modelos fisicos (Base de Datos, XML, File, Web Services) y mediante un modelo Logico puedes generar una sola vista a los datos, esto es muy interesante ya que modelas apartir de tus metadatos, no de las fuentes fisicas.
Algunos ejemplos que vienen a la mente, catalogos comunes, multiples bases de datos accesadas mediante un data service, federacion de multiples fuentes de datos, en fin.
En el trabajo tenemos el Aqualogic Data Services, actualmente estamos en el proceso de explotacion de la herramienta, en breve expondre los casos de uso que estamos echando a andar.
Aqui les dejo unas ligas interesantes acerca de este tema:
EII helps BI adapt to SOA
when to use EII
Understanding the Service Lifecycle within a SOA: Run Time
Espero que esta introduccion a los EIIs les sea de utilidad, estare publicando mas cosas acerca de este tema.
Comentarios, criticas y aportaciones bienvenidas.
Por una integracion mejor, hasta la vista!!
Tuzo.
miércoles, 4 de abril de 2007
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
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
viernes, 30 de marzo de 2007
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
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
Suscribirse a:
Entradas (Atom)