Modelando nuevas realidades

Hace unas semanas escribia sobre una dificultad que estamos teniendo con las aplicaciones actuales, donde el análisis de impacto que estamos haciendo se queda corto pues no mide lo que realmente cambio.

Esto me hizo pensar, sobre la evolución de las aplicaciones y como vienen cambiando la forma en que las desarrollamos.

En el GX24, se mostraron parte de las ramas de investigación que esta haciendo Artech para tratar de modelar las nuevas aplicaciones, donde los datos no están en bases de datos, sino que los orígenes de datos son diversos (bases de datos, sensores, archivos, servicios, etc) y donde se almacenan dichos datos también esta cambiando. Uno de los enfoques para tratar de modelar esto, son las Dynamic Transactions.  Con esto, se va a poder asociar a una transacción "cosas" diferentes que no son tablas, permitiendo usar la potencia del lenguaje Genexus para manejar dichos datos. No tengo detalles de la implementación, pero se me ocurre que en el futuro podremos:

  •  recorrer colecciones de datos estructurados (SDT collection) con for each
  •  leer y grabar en una tabla remota con los mismos for each
  •  hacer joins entre una tabla y un SDT
  •  manejar tablas en memoria  
  • leer de una balanza (puerto serial) sin tener que hacer programación especifica
  • levantar o bajar una barrera usando for each
Cualquiera de estas funcionalidades son de por si un aporte fundamental para poder programar aplicaciones mucho mas potentes, con lenguaje conocido y sencillo. 

Lo que me queda replicando en la cabeza, es que aun no tenemos la potencia de modelar las realidades de nuestras nuevas aplicaciones, que a medida que pasa el tiempo se vuelven mas interconectadas y complejas. 

Algunas de estas realidades son :

1) KB central en una version de GX y una aplicación satelite en otra version
Un ejemplo de esto, es cuando tengo una KB centralizada en Evolution 2 y necesito desarrollar de cobranzas con Smart Devices Offline, para lo cual tengo que desarrollar con Evolution 3 . Tengo varias opciones:
  • Migro toda la KB a la version Evo3 (es un proyecto en si mismo y puede ser imposible por diversos motivos). 
  • Mantengo la KB central en Evo2 y creo una KB en Evo 3 que tenga todo lo necesario, transacciones fundamentalmente. Desarrollo en dicha KB y agrego la tarea de sincronizacion de traerme todos los objetos que necesito de Ev2 a Ev3 cuando estos cambian. Tambien puede ser necesario pasar objetos de Ev3 a Ev2, con lo cual la cosa se complica un poco mas. 
  • Mantengo la KB central en Ev2 y creo la KB para cobranzas en Evo3 y agrego una capa de servicios o de Data View para poder interconectar dichos desarrollos. 

2) Varias KB. 
Por motivos de manejo y performance al desarrollar, se decidio hace tiempo dividir el modelo de la empresa en varias KB. Ahora se tienen varias aplicaciones, en diferentes data store sobre la misma base de datos. Se necesita al menos una persona para mantener la sincronizacion de los objetos comunes de la KB. 

Cualquier persona que haya que tenido que lidiar con varias KB que comparten objetos, tablas o servicios por varios años, sabe que no es facil lidiar con eso, pues la realidad cambia, cambian los objetos que la modelan y surgen problemas de sincronizacion. 

Como modelar esto? 

Algo en lo que estuve pensando, era como modelar estas realidades de forma de poder administrarlo  mejor. 

Una de las posibilidades es tener un MODELO DE DATOS, en el sentido amplio, que incluya los orígenes de datos diversos que mis aplicaciones consumen y por otro lado tener las diferentes aplicaciones que interactuan condicho modelo de datos. 

Dicho modelo de datos tendría:
  •  un conjunto de tablas de un modelo de datos relacional en una o mas bases de datos que mi aplicacion crea y maneja. Son todas las tablas reorganizadas por GeneXus. 
  • un conjunto de tablas que uso, pero no puedo cambiar su estructura, pues son manejadas por otros
  • un conjunto de servicios que la aplicacion crea y maneja (por ejemplo los servicios que se crean para ser consumidos por aplicaciones Smart Devices
  • un conjunto de servicios de terceros que la aplicación consume pero no puede cambiar
Un esquema rapido de esto, seria verlo como tiene Visual Studio, que tiene una SOLUCION (seria mi modelo de datos) y dentro de ellos los diferentes PROYECTOS (serian aplicaciones hechas con KB actuales).

Modelo de Datos y Servicios
     Aplicacion1
     Aplicacion2
     Aplicacion3

El modelo de datos, se encargaria de ver todas las transacciones, data store y servicios que publican las aplicaciones contenidas y realizaría la normalización y reorganización de cada una de ellas. 

Cada una de las aplicaciones, seria equivalente a una KB actual, podría estar en una versión diferentes de GeneXus y generaría la aplicación como hasta ahora. 

Llevándolo a un ejemplo de la vida real 

Solución LUCIA - Modelo de Datos
  •        Base LUCIA
  •        DB WikiProcedimientos
  •        DB WikiDocumentacion
  •        DB Data warehouse
       Aplicaciones
                KB LUCIA (Evolution 2)
                WikiProcedimientos (Evolution 3)
                WikiDocumentacion (Evolution 3)
                Análisis de Riesgo (Java nativo)

Podría trabajar con la KB como hasta ahora, haciendo build all solo de los objetos de dicha KB, o también hacer un build de toda la solución, con lo cual se harían un build de cada uno de las aplicaciones de la solución.

Me resulta bastante complejo de explicar en un post, lo que significa que aun no tengo el tema demasiado claro y tengo que madurarlo mas.
En resumen, quiero tener un modelo que abarque tome en cuenta todas las transacciones de diferentes KB de una solucion y sea compartido por todas las aplicaciones de dicha solucion.
                 
Varios cambios serian necesarios (o deseables) para que este esquema permita modelar mejor la realidad.

Data View modificables

Hoy definir un data view con una tabla asociada, implica que dicha tabla no es modificada por GeneXus. La limitante, es que las tablas solo se pueden definir dentro de un schema y la forma de definirlos en otro es a traves de data view. Seria deseable, poder marcar un dataview como reorganizable y que Genexus permita hacer los cambios, o en su defecto, permitir que las tablas tengan las propiedades que hoy se pueden definir en los data view, como otra base de datos, otro schema y que GeneXus las reorganice. 

Servicios como orígenes de datos

Es común importar un servicio y usarlo como fuente de datos. Hoy es sumamente engorroso mantener actualizado la definición de dichos servicios si los mismos cambian. Seria bueno tener una etapa en la reorganizacion que permita re-importar la definicion de dichos servicios si los mismos cambiaron, pero de forma facil. 




Comentarios

Entradas más populares de este blog

La nefasta influencia del golero de Cacho Bochinche en el fútbol uruguayo

Aplicación monolítica o distribuida?

Funcionalidades de GeneXus que vale la pena conocer: DATE Constants.