Para la nueva versión de GIA hemos tenido que estudiar una nueva tecnología que por lo menos para mi , me ha resultado muy interesante. Aunque no hemos puesto en producción nada aun que lo utilice, veo en estas tecnologías un potencial de desarrollo que quisiera compartir. Estas tecnologías son los colas de mensajes... En particular, MSMQ de microsoft y MQSeries de IBM, no tratare de dar ventajas de una u otra solución, sino de describir lo que se puede ganar si se tiene en cuenta esta tecnología para el desarrollo de una aplicación.
Programación asincrónica vs. sincrónicaTradicionalmente con GX y la mayoría de los lenguajes de programación se utiliza una metodología de desarrollo sincrónica, es decir, si un proceso debe ejecutar 4 fases, A, B, C y D, se programa de forma que cada etapa se ejecute una a continuación de la otra.
Inicio -> A -> B -> C -> D -> Fin
Pero, en algunos casos no es necesario realmente que alguna de esas etapas termine para que le siguiente pueda empezar, por ejemplo, pongamos un caso típico. El grabar un log de actividad, en muchas aplicaciones es necesario o preferible, que haya un log de todo lo que hagan los usuario, para eventualmente poder luego identificar quien y cuando realizo un cambio en alguna tabla critica, como puede ser las cotizaciones del día. O poder reproducir la evolución de un valor , por ejemplo el precio por kilo de la harina, cosa que obligaría tener una línea con el precio y la fecha que se modifico, complicando la búsqueda de valor vigente y aumentando la estructura necesaria para guardar esta información.
en tablas, sin log:
Producto*
Precio
en tablas, con log de cambios:
Producto*
Fecha de vigencia*
Precio
Usuario que modifico
Aunque en el primer caso es sencillo encontrar el valor vigente (el único que hay) no se sabe porque una liquidación de hace tres años dio lo que dio, (a menos que guardemos el precio en la propia liquidación), en el segundo caso aunque el histórico de los precios, es mas costoso encontrar el valor vigente y aumenta la cantidad de tablas y la de atributos.
Otra opción seria la de tener tablas de log, pero en algunos casos no es viable el de estar manteniendo estas tablas por el tiempo de ejecución es crítico en largos procesos y el tiempo que insume el tener que estar grabando tablas de log es demasiado. Otro problema podría ser que los datos se modifican muy frecuentemente y el volumen de log que se generaría sería demasiada para tenerla en la misma base de datos.
Para estos casos y otros, seria interesante el de contar con una cola de log, es decir, cuando se produce un evento que amerita el de tener una registro en una tabla de log, se podría enviar un mensaje a una cola con la información necesaria para registrar la modificación. La ventaja que tenemos con enviar un mensaje en vez de grabar una tabla son varias, una que es mas rápido, el mensaje queda en cola hasta que pueda ser procesado, por ejemplo por la noche cuando la actividad cae. Generalmente estos logs de actividad no son consultado inmediatamente luego de hacer la modificación, por lo que podrían estar disponibles a partir del otro día que se hizo la modificación. Con esto ganamos tiempo que en un proceso que requiere ser eficiente sin perder la propiedad de generar log de actividad.
Otra ventaja seria que si el log que se genera en muy grande, la base de datos donde se graba este log podría ser otra que la de producción ya que el proceso que lee de la cola grabaría un otra base distinta de la de producción, evitando así que la base de producción crezca en tamaño por los archivos de log. Otra ventaja mas, podría ser la seguridad, ya que al estar el log en otra base, que podría llegar a estar en otro sitio físico muy destino a la de la base de producción, en caso de accidentes en la base de producción (incendios, hackers, ladrones) la base de log podría estar en sitio seguro (las propias oficinas de CONCEPTO, por ejemplo)
Este sería el concepto de asincrónico, el de hacer una etapa del proceso cuando se pueda y no cuando se genera, en nuestro primer ejemplo, si la etapa C seria la de generar el log se los cambios que pasaron en las etapas A y B, pero no se puede esperar para ejecutar la etapa D, se puede enviar un mensaje a la cola de log con toda la información necesaria para realizar la etapa C, luego ejecutar la etapa D y cuando se pueda (a la noche o cuando sea) ejecutar todas las etapas C que se han generado ese día
Inicio -> A -> B - -> D -> Fin
|_ mensaje -> C
Otro ejemplo mas ambicioso podría ser la generación de los asientos de la facturación por cola de mensaje, cuando se hace una factura , se genera los asientos correspondientes, pero realmente estos asientos no son necesarios hasta fin de mes, se podría enviar un mensaje a una cola de asientos por generar, acelerando el proceso de facturación y dejando la generación de asientos para la noche... Bueno, creo que si uno lo piensa podría haber muchos ejemplos de cosas que realmente que se hacen a medida que se ejecutan un evento que realmente no son necesarias hacerlas en el momento y se podrían hacer asincrónicamente, mejorando los tiempos de respuesta de nuestras soluciones.
Bajando la pelota al pisoPor supuesto que desde GX no se puede manejar colas de mensajeria, se debería hacer con programas externos,
En Visual Fox serian algo asi:
oMsg = CreateObject("msmq.msmqmessage")
oMsg.Label = "Mi mensaje"
oMsg.Body = "Mi texto"
oMsg.Send(oSendQueue)
oMsg = oReadQueue.ReceiveCurrent(,,,0)
subject = oMsg.Label
body = oMsg.Body
En Java:
Send_msg.writeChar('Mi texto');
MQPutMessageOptions pmo = new MQPutMessageOptions();
Send_queue.put(Send_msg,pmo);
system_default_local_queue.get(retrievedMessage, gmo );
mensaje = retrievedMessage.readLine();
Para TerminarBueno, el objetivo de este articulo es el de crearles el interés y que tenga en cuenta utilizar colas de mensajes si es la mejor opción para su solución. Por mas información, no dude en consultar.
Referenciashttp://www.microsoft.com/msmq/
http://www-4.ibm.com/software/ts/mqseries/
No hay comentarios.:
Publicar un comentario